yogae 블로그

Elasticsearch 비용 절약하기

yogae — Thu, 19 Sep 2024 23:02:17 +0900

아무것도 모르는 상태라서 Elasitcsearch Cloud를 사용했지만 규모가 커지면서 비용이 많이 발생하기 시작했습니다. 규모가 커지면서 비용문제가 지속되었고 비용을 줄이기 위해 조치했던 내용을 정리해보았습니다.

Elasticsearch Cloud에서 AWS Self Managed로 Migration

처음 Elasticsearch를 구성할 때는 Cloud를 사용하여 구성했습니다. 빠르게 production에 적용을 진행해야해서 Elasticsearch Cloud를 사용하여 운영을 시작했습니다. Elasticsearch Cloud를 사용할 때는 Elasticsearch Cloud에서 자동으로 진행되는 것들이 많았습니다. version upgrade나 설정 변경 시 자동으로 rolling update를 진행하여 클릭만 하면 되었습니다. AWS Self Managed로 운영하면서 이렇게 자동으로 진행되는 것을 하나하나 수동으로 진행해야한다는 사실을 알게되었습니다. Elasticsearch를 운영하면서 시간이 오래 걸리는 작업이 상당히 많다는 것을 알게되었습니다. 가능하다면 운영에 대한 준비를 많이 해야 시간을 절약할 수 있습니다.

데이터가 많아지면서 비용이 정말 빠르게 증가했고 Elasticsearch 운영 비용을 절약하기 위해 AWS에 EC2위에 Elasticsearch Cluster 구성을 진행했습니다. 데이터 Migration을 진행은 Elasticsearch Snapshot을 활용하여 Migration을 진행했습니다. Migration을 진행할때 CCR, CCS를 활용하는 방법도 확인해보았지만 License가 필요한 부분이 있어서 사용하지 못했고 Snapshot만을 활용했습니다.

> snapshot을 활용한 migration 진행 시 꼭 호환되는 Elasticsearch version을 확인해야 합니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html#snapshot-index-compatibility

Instance Type 선택 시 비용 고려사항

Elasticsearch Cluster를 AWS EC2로 Migration을 진행하면서 가장 고민했던 부분은 AWS EC2 Type을 선택하는 것이었습니다. EC2를 기본적으로 선택하면 EBS 최적화 인스턴스를 사용할 것입니다. EBS 최적화 인스턴스 선택하기 전에 EC2 Instance Storage를 지원하는 instance type을 사용하는 것을 고려해봐야한다. EC2 Instance Storage는 EC2 인스턴스에 직접 연결된 스토리지입니다. DB와 같은 장비를 구성할 때 IOS를 많이 사용하는 경우가 많지만 EBS를 사용하는 경우 IOS 추가적으로 구성하면 비용이 발생합니다. EC2 Instance Storage를 사용하는 매우 빠른 I/O 성능을 제공하여 IOS에 대한 추가적인 비용 발생을 고려하지 않아도 됩니다. 단점은 instace stop시 데이터가 사라진다는 것입니다. EC2 Instance Storage를 사용하는 경우 장애상황을 대비하여 HA를 구성해야하며, 가능하다면 추가적인 replica shard를 구성하여 운영하는 해야합니다.

2개의 tier로 Lifecycle 정책을 분리하여 관리하고 있습니다. tier에 따라서 EC2 Instance Storage를 선택하여 사용하고 있습니다. Hot tier의 경우 indexing을 담당하고 가장 많은 access를 보장하도록 구성했습니다. SSD EC2 Instance Storage인 i4i type을 선택하여 hot tier를 구성했습니다. warm는 과거 데이터를 저장하여 hot tier에 비해 access가 적었고 HDD EC2 Instance Storage인 d2 type을 사용하여 구성했습니다. i4i 장비는 2년 동안 hardware retirement event가 한 번도 발생하지 않았습니다. 하지만 d2 type의 장비의 경우 1년에 2번에서 3번은 발생하는 것으로 보입니다. ap-northeast-2에서는 d2 type이 부족한 현상이 발생하여서 d2 type 선택 시 주의해야합니다.

Instance Type 선택 시 추가적인 고려해야할 사항들은 아래 정리해보았습니다.

* he exact number of shards per 1 GB of memory depends on the use case, with the best practice of 1 GB of memory for every 20 shards on disk.

* There are no hard limits on shard size, but experience shows that shards between 10GB and 50GB typically work well for logs and time series data. You may be able to use larger shards depending on your network and use case.

* 적당한 Heap메모리는 전체 메모리의 절반 정도 수준에서 전체 메모리가 크다면 32GB보다 작은 값으로 설정합니다.

Data Transfer 비용도 고려해야합니다.

AWS에서 Elasticsearch Cluster를 운영하면서 데이터가 수백 TB가 넘어가면서 Data Transfer 비용이 무시 못할 비용이 발생하게 되었습니다. AWS에서는 동일한 리전 내 동일 가용 영역(AZ) 내에서의 데이터 전송은 무료이지만 같은 region이라도 다른 가용 영역(AZ) data가 이동하면 비용이 발생합니다.

Elasticsearch Cluster를 같은 AZ에 구성할 수 없어서 여러 AZ에 걸쳐서 shard를 배치시킵니다. Search query 요청이 들어오면 Elasticsearch의 동작 방식이 분산되어 있는 데이터를 찾기 위해서는 여러 node에 데이터를 query하고 해당 데이터를 반환하도록 구성되어 있습니다.

https://medium.com/@musabdogan/elasticsearchs-distributed-search-query-and-fetch-phases-df869d35f4b3

Elasticsearch’s Distributed Search: Query and Fetch Phases

To understand Elasticsearch’s distributed search, let’s take a moment to understand how querying and fetching work. Unlike simple CRUD…

medium.com

1. Data Transfer를 줄이기 위해서는 한 번에 search query에 참여하는 shard의 개수를 줄일 수 있도록 구성합니다.

2. Data Transfer간 전송되는 데이터 사이즈를 줄이기 위해서 compression 설정을 합니다.

3. Search 요청 시 _source를 지정하여 필요한 데이터만 반환하도록 합니다.

4. threshold rebalancing을 줄입니다.

Github Actions 관리하기(Organization secrets, Reusable workflows)

yogae — Wed, 29 Jun 2022 18:09:42 +0900

새로운 service를 만들때마다 workflow yml 파일을 복사 붙여넣기하여 사용하고 있었다. reusing workflows를 사용하여 workflow를 재사용할 수 있도록 구성했다. workflow를 구성하면서 손이가는 작업이 github actions의 secret를 설정하는 작업이었다. 이부분 또한 organization secret을 사용하여 정리해 보았다.

✏️ Organization secrets

Gihub Organization을 사용하고 있다면 Organization 안에서 사용할 수 있는 github actions secrets을 설정할 수 있다. Organization secrets을 사용하지 않았을 때는 repository별로 secrets를 설정해야했다. repository별로 다른 secrects를 설정해야한다면 문제 없겠지만 모든 repository에서 같은 secrets을 사용하는 경우가 많았다. repository를 새로 생성해야하면 secrets를 매번 새롭게 설정해야했다.

Organization의 admin만이 organization secrets을 설정할 수 있다. admin으로 접속하여 organization page에서 settings -> actions -> secrets으로 이동하여 organization secrets을 설정할 수 있다.

organization secrets은 repository별로 설정이 가능하다. repository를 다양한 사용자가 생성하고 사용하고 있어서 특정 repository에만 secrets에 접근할 수 있는 권한을 부여했다.

organization secrets은 개별 repository에서 설정한 secrects과 동일한 방법으로 접근이 가능하다. ORG_ prefix를 설정하여 개별 repository secrets과 분리했다.

...
jobs:
    deploy:
        runs-on: ubuntu-latest
        steps:
        	...
            - name: deploy
              run: |
                  yarn deploy
              env:
                  npm_token: ${{ secrets.ORG_NPM_TOKEN }}
            	  aws_access_key_id: ${{ secrets.ORG_ACTION_ACCESS_KEY_ID }}
                  aws_secret_access_key: ${{ secrets.ORG_ACTION_SECRET_ACCESS_KEY }}

secrets에 문제가 있거나 주기적으로 key를 변경해야하는 경우 한 번의 설정으로 여러 repository에 변경사항을 반영할 수 있다.

⭐️ Reusable workflows

reusing workflows 공식문서

reusing workflows의 yml은 아래와 같다.

name: node deploy reusable workflow

on:
    workflow_call:
        inputs:
            project_name:
                required: true
                type: string
            stage:
            	default: dev
                required: false
                type: string
        secrets:
            npm_token:
                required: true
            aws_access_key_id:
                required: true
            aws_secret_access_key:
                required: true
jobs:
    deploy:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v3
            - name: Setup Node.js
              uses: actions/setup-node@v3
              with:
                  node-version-file: ".nvmrc"
                  cache: "yarn"
                  registry-url: "https://registry.npmjs.org"
            - name: Get yarn cache directory path
              id: yarn-cache-dir-path
              run: echo "::set-output name=dir::$(yarn cache dir)"
            - name: Cache node modules
              uses: actions/cache@v3
              with:
                  path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
                  key: ${{ runner.os }}-yarn-${{ env.CACHE_NAME }}-${{ env.STAGE }}-${{ hashFiles('**/yarn.lock') }}
                  restore-keys: ${{ runner.os }}-yarn-${{ env.CACHE_NAME }}-${{ env.STAGE }}-
              env:
                  CACHE_NAME: ${{ inputs.project_name }}
                  STAGE: ${{ inputs.stage }}
            - name: yarn install local dependency
              run: yarn install
              env:
                  NODE_AUTH_TOKEN: ${{ secrets.npm_token }}
            - name: deploy
              run: |
                  yarn deploy
              env:
                  NODE_ENV: ${{ inputs.stage }}
                  DEPLOY_ALIAS: ${{ inputs.deploy_alias }}
                  AWS_ACCESS_KEY_ID: ${{ secrets.aws_access_key_id }}
                  AWS_SECRET_ACCESS_KEY: ${{ secrets.aws_secret_access_key }}

reusing workflows로 값을 전달할 수 있다. 암호화가 필요하지 않은 inputs과 암호화가 필요한 secret이 존재한다. jobs는 기존의 workflow를 사용하는 방법과 동일하게 사용할 수 있다.

reusing workflows 제한사항

- reusing workflows는 다른 reusing workflows를 호출할 수 없다.

- reusing workflows을 private repository에 저장한다면 같은 repository안에서만 reusing workflows를 호출하여 사용하야한다.

✏️ Reusing workflows 호출하기

reusing workflows 설정 시 private repository 사용한다면 주의해야하는 제한은 같은 repository에 Reusable workflows를 저장하여 사용해야한다는 것이다.

Reusable workflows stored within a private repository can only be used by workflows within the same repository.

여러 repository에서 사용할 수 있도록 구성해야 했기에 private repository로 설정할 수 없었고 public repository에 reusing workflows를 저장해야 했다.

private repository에서 reusing workflows

reusing workflows를 private repository에 저장하는 경우 같은 repository안에 있는 reusing workflows만 호출이 가능하다. 같은 repository에 있는 경우 아래와 같이 상대경로를 통해 reusing workflows를 호출할 수 있다.

name: test
on:
    pull_request:
        branches:
            - develop
jobs:
    node-deploy:
        uses: ./.github/workflows/{filename}@master
        with:
            project_name: test-project
            stage: test
        secrets:
            npm_token: ${{ secrets.ORG_NPM_TOKEN }}
            aws_access_key_id: ${{ secrets.ORG_ACTION_ACCESS_KEY_ID }}
            aws_secret_access_key: ${{ secrets.ORG_ACTION_SECRET_ACCESS_KEY }}

reusing workflows를 private repository에 생성하면 같은 respository에서만 호출하여 사용할 수 있어서 여러 repository를 관리해야한다면 public으로 변경하여 아래와 같은 방식의 설정이 필요한다.

public repository에서 reusing workflows

다른 repository에 저장되어 있는 reusing workflows를 호출하고자 한다면 {owner}/{repo}/.github/workflows/{filename}@{ref} 방식으로 호출할 수 있다.

name: test
on:
    pull_request:
        branches:
            - develop
jobs:
    node-deploy:
        uses: {owner}/{repo}/.github/workflows/{filename}@{ref}
        with:
            project_name: test-project
            stage: test
        secrets:
            npm_token: ${{ secrets.ORG_NPM_TOKEN }}
            aws_access_key_id: ${{ secrets.ORG_ACTION_ACCESS_KEY_ID }}
            aws_secret_access_key: ${{ secrets.ORG_ACTION_SECRET_ACCESS_KEY }}

lambda@edge를 사용한 요청 header 처리(user-agent, accept-language)

yogae — Wed, 5 Jan 2022 17:39:14 +0900

문제점

accept-language에 따라 다른 언어의 html을 보여주어야했습니다. accept-language header를 cloudfront whitelist에 추가하여 origin에 header를 전달하도록 구성했습니다. 하지만 accept-language header의 형태가 다양하여 cloudfront cache의 효율이 좋지 않았고 지원하지 않는 언어가 들어오는 경우 default language 설정이 필요했습니다.

user-agent header를 parsing하여 IE 브라우저로 접속 시 redirect 처리하고 있습니다. user-agent header 또한 cloudfront whitelist에 추가하여 origin으로 header를 전달하고 있었지만 cache 효율이 좋지 않았습니다.

해결방법

client 요청 시 header에 관련된 처리를 하는 lambda@edge를 생성하여 cache 효율을 높이고자 했습니다.

Lambda@Edge

lambda@edge 함수는 viewer request, viewer response, origin request, origin response 중 선택하여 동작할 수 있습니다. 모든 요청에 대한 cache key를 변경하려면 viewer request를 사용해야 합니다.

Lambda 함수를 트리거하는 데 사용할 CloudFront 이벤트를 결정하는 방법

Lambda@Edge 제한사항

lambda@edge는 기본 lamdba function을 사용하는 것보다 많은 제약사항이 있습니다.

$LATEST 또는 별칭이 아니라 번호가 매겨진 Lambda 함수 버전을 사용해야합니다.
Lambda 함수는 미국 동부 리전에 있아야 합니다.
Viewer request와 viewer response의 timetout 제한 5초, Origin request와 origin response timeout 제한 30초 입니다.
Viewer request와 viewer response의 package size 제한 1MB, Origin request와 origin response의 package size 제한 50MB 제한이 있습니다.
환경변수를 사용할 수 없습니다.

구현

header parsing

구현 시 lambda@edge의 1MB 제한사항 때문에 module 선택 시 size를 꼭 확인해야합니다. accept-language header를 accept-language-parser npm module을 사용하여 정형화 했습니다.

import { pick } from "accept-language-parser";

export class AcceptLanguageParser {
    private supportedLanguages: string[];
    private defaultLanguage: string;
    constructor(supportedLanguages: string[], defaultLanguage: string) {
        this.supportedLanguages = supportedLanguages;
        this.defaultLanguage = defaultLanguage;
    }

    public pickLanguage(acceptLanguage: string): string {
        const lang = pick(this.supportedLanguages, acceptLanguage, {
            loose: true,
        });
        if (lang) return lang;
        return this.defaultLanguage;
    }
}

const acceptLanguageParser = new AcceptLanguageParser(["en", "ko"], "ko");
const lang1 = acceptLanguageParser.pickLanguage("en-GB,en;q=0.8"); // en
const lang2 = acceptLanguageParser.pickLanguage("fr-CA', 'fr-FR', 'fr"); // ko

정형화한 값을 cloudfront origin으로 전달할 때는 querystring으로 전달하도록 구성했습니다.

import { parse, stringify } from "querystring";
import * as ua from "useragent";

const acceptLanguageParser = new AcceptLanguageParser(["en", "ko"], "ko");

export function handler(
    event: CloudFrontRequestEvent,
    context: Context,
    callback: Callback
) {
    const request = Records[0].cf.request;
      let userAgent;
      if (
        request.headers["accept-language"] &&
        request.headers["accept-language"][0]
    ) {
        const acceptLanguage = request.headers["accept-language"][0].value;
        delete request.headers["accept-language"]; // cloudfront cache 생성 시 accept-language header에 따라 cache가 생성되는 것을 방지하기 위해 삭제
          const lang = acceptLanguageParser.pick(acceptLanguage)
        request.querystring = stringify({ lang });
      }

      if (request.headers["user-agent"] && request.headers["user-agent"][0]) {
        userAgent = request.headers["user-agent"][0].value;
        delete request.headers["user-agent"];  // cloudfront cache 생성 시 user-agent header에 따라 cache가 생성되는 것을 방지하기 위해 삭제              
    }

      if(ua.is(userAgent).ie) callback(null, {
            status: "301",
            statusDescription: "Permanently Moved",
            headers: {
                location: [
                    {
                        key: "Location",
                        value: "{{url}}",
                    },
                ],
            },
        }); // ie 브라우저로 접근 시 redirect
     else callback(null, request);
}

배포 스크립트 작성

배포 스크립트는 node.js code를 작성하고 작성한 code를 packaging하여 s3에 upload하는 것까지 작성했습니다. s3에 올라간 package는 terraform으로 lambda@edge, cloudfront 설정을 했습니다. 아래 코드는 s3에 upload하는 shell 스크립트입니다.

    npm install && tsc
    npm pack --json | jq '.[0].filename' | xargs -I {} mv {} "$OUTPUT_FILENAME"

    mkdir "$TMP_FOLDER"
    mv "$OUTPUT_FILENAME" "$TMP_FOLDER"/"$OUTPUT_FILENAME"

    cd $TMP_FOLDER
    tar -xvzf "$OUTPUT_FILENAME"
    cd package && zip -r "../$OUTPUT_ZIP" . && cd ..
    ENC_METADATA=`openssl dgst -sha256 -binary $OUTPUT_ZIP | openssl enc -base64`
    aws s3 cp ./$OUTPUT_ZIP s3://{{s3 upload 위치}} --metadata sha256=$ENC_METADATA

작성 시 어려웠던 점은 node.js application package하는 것과 새로운 package를 s3 upload 시에만 terraform으 변경사항을 감지하고 배포할 수 있도록 구성하는 것이었습니다.

1. node.js application package

lambda@edge의 1MB 제한사항 때문에 devdependency가 들어가지 않도록 해야합니다. 이를 위해 package.json에 bundleDependencies를 사용했습니다.

{
 ...
    "dependencies": {
        "accept-language-parser": "^1.5.0",
        "useragent": "^2.3.0"
    },
    "bundleDependencies": [
        "accept-language-parser",
        "useragent"
    ],
}

bundleDependencies를 사용하면 npm pack 실행 시 bundleDependencies에 추가되어 있는 module만 node_modules에 추가하게 됩니다. 기존에는 yarn을 사용했지만 bundleDependencies설정이 yarn pack으로는 제대로 실행되지 않는 것을 확인되어 npm pack으로 실행하는 스크립트를 작성했습니다. .npmignore를 사용하여 ts 파일과 log file등 packaging에 필요 없는 file을 제거 했습니다.

npm pack실행의 결과물은 *.tgz입니다. tgz를 그대로 s3 upload할 수 없습니다. lambda에서 사용하는 file은 zip 형식이므로 tgz를 zip으로 변환해야합니다.

2. 새로운 package를 s3 upload 시에만 terraform 변경사항 감지

terraform에서는 변경사항이 있을 때만 배포되기 때문에 metadata를 사용하여 aws_lambda_function의 source_code_hash에 맞는 방식으로 encode한 hash 값을 설정해야 했습니다. aws_lambda_function의 source_code_hash에 잘못된 값을 넣으면 terraform에서 apply 때마다 변경사항이 발생하게 됩니다.

source_code_hash을 사용하는 방식 이외에도 s3 object를 versioning할 수 있도록 설정하여 version id를 aws_lambda_function에 설정하는 방식도 있습니다. s3 object를 versioning하는 방식을 사용하지 않고 있어 source_code_hash를 사용하는 방식으로 구성했습니다.

data "aws_s3_bucket_object" "header_parsing_lambda_edge_artifact" {
  bucket = "${node package를 upload한 s3 bucket}"
  key    = "${node package를 upload한 s3 key}"
}

data "aws_iam_policy_document" "assume_role_policy_doc" {
  statement {
    sid    = "AllowAwsToAssumeRole"
    effect = "Allow"

    actions = ["sts:AssumeRole"]

    principals {
      type = "Service"

      identifiers = [
        "edgelambda.amazonaws.com",
        "lambda.amazonaws.com",
      ]
    }
  }
}

resource "aws_iam_role" "lambda_at_edge" {
  name               = "lambda-edge-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy_doc.json
}

data "aws_iam_policy_document" "lambda_logs_policy_doc" {
  statement {
    effect    = "Allow"
    resources = ["*"]
    actions = [
      "logs:CreateLogStream",
      "logs:PutLogEvents",
      "logs:CreateLogGroup",
    ]
  }
}

resource "aws_iam_role_policy" "logs_role_policy" {
  name   = "log-policy"
  role   = aws_iam_role.lambda_at_edge.id
  policy = data.aws_iam_policy_document.lambda_logs_policy_doc.json
}

resource "aws_lambda_function" "header_parsing_lambda_edge" {
  function_name = "lambda-edge"

  # Find the file from S3
  s3_bucket         = "${node package를 upload한 s3 bucket}"
  s3_key            = "${node package를 upload한 s3 key}"
  source_code_hash  = chomp(data.aws_s3_bucket_object.header_parsing_lambda_edge_artifact.metadata["Sha256"])
  provider          = aws.aws_cloudfront

  publish = true
  handler = "dist/app.handler"
  runtime = "nodejs14.x"
  role    = aws_iam_role.lambda_at_edge.arn
}

resource "aws_cloudfront_distribution" "static_distribution" {
    ...

    ordered_cache_behavior {
        lambda_function_association {
            event_type = "viewer-request"
            include_body = false
            lambda_arn = aws_lambda_function.header_parsing_lambda_edge.qualified_arn
        }
    }
}

결과

cloudfront를 적극적으로 사용하고 있습니다. 하지만 accept-language, user-agent와 같이 형태가 다양한 header를 cloudfront origin으로 전달할 경우 cache hit 효율이 떨어집니다. lambda@edge를 사용하는 방법이 이러한 문제를 해결할 수 있는 방법이 될 수 있습니다. 하지만 lambda@edge 도입에 장벽으로 느껴지는 부분이 있었습니다.

첫번째 장벽은 lambda@edge의 제약사항이 많다는 것이었습니다. lambda packaging 시 size 제한으로 code 개발 시 항상 사용하는 module을 전부 제거해야만 했습니다. lambda timeout 제한이 있어 외부 요청이나 db 연결 시 timeout이 발생하지 않도록 주의해야 합니다. 이러한 제한 사항으로 설계시 어려움이 많이 느껴졌습니다. 두번째 장벽은 기존에 사용하는 lambda 배포 pipeline을 같이 사용할 수 없다는 것이었습니다. 기존에 serverless framework로 lambda를 관리하고 lambda 이외의 infra는 terraform으로 관리하고 있었습니다. cloudfront를 terraform으로 관리하고 있었고 serverless framework로 배포한 lambda@edge를 terraform에 연결하는 작업이 어려움이 있다고 판단되었습니다. 기존에 사용하는 serverless framework배포 방식을 선택하지 않고 terraform으로만 관리하는 방법으로 새롭게 구성해야했습니다.

lambda@edge을 도입하면서 cloudfront origin으로 설정한 application에서 header를 처리하는 로직을 제거할 수 있었습니다. header를 처리하는 로직을 분리하여 application에는 core 로직에만 중집할 수 있게 되었습니다.

Reference

python 절대경로 / 상대경로

yogae — Tue, 4 Jan 2022 17:59:06 +0900

unittest code를 작성하고 test code에서 module을 import할 때 너무나 많은 error가 발생했습니다. module을 찾을 수 없는 error와 attempted relative import with no known parent package error 등의 error가 발생했습니다. 이러한 error가 발생한 원인을 정확하게 파악하려 합니다.

`name`의 역할

python의 __name__은 모듈이 저장되는 변수이며 import로 모듈을 가져왔을 때 모듈의 이름이 들어갑니다. 파이썬 인터프리터를 통해 파이썬파일을 직접실행할 경우에는 파이썬에서 알아서 그파일의 name은 __main__이 됩니다. 파이썬 모듈을 import해서 사용할 경우에는 name은 원래 모듈 이름으로 설정됩니다. 그러므로 만약 해당 파일이 직접 실행시킬 때에만 실행되도록 설정하고 싶다면 if __name__ == '__main__':로 실행합니다.

절대경로와 상대경로

위와 같은 구조의 프로젝트가 있다고 한다고 합니다.

# add_two_numbers.py

from .lib.linked_list import LinkedList

상대경로는 내위치를 중심으로 표현한 경로를 말합니다. .은 현재위치를 ..은 상위 디렉터리를 나타냅니다.

# add_two_numbers.py

from lib.linked_list import LinkedList

절대경로는 절대경로는 변하지않는 고유경로입니다.

상대경로로 import하여 add_two_numbers.py을 직접 실행하는 경우 attempted relative import with no known parent package error가 발생합니다. 실행 후 상대경로를 통해 다른 모듈을 import 할때, 파이썬은 모듈의 이름 __name__에 기반을 두고 현재모듈의 위치를 찾는다. __name__이 직접 실행하는 경우 __main__으로 변경되어 위치를 찾을 수가 없게 됩니다. 직접 실행하는 python file의 경우 항상 절대경로를 사용해야한다고 적혀있습니다.

Intra-package References: Note that relative imports are based on the name of the current module. Since the name of the main module is always "main", modules intended for use as the main module of a Python application must always use absolute imports.

`sys.path`

sys.path는 디렉터리의 경로가 기록된 문자열 리스트입니다. 이 리스트에 경로를 추가하면 해당 경로에 있는 파이썬 파일을 import할 수 있습니다.

pip install <package> 명령을 실행하면 site-packages folder에 package가 설치됩니다. sys.path에 site-packages folder의 path가 등록되어 있어 다운 받은 package를 절대경로로 import하여 사용할 수 있습니다.

sys.path에는 기본적으로 몇 가지 경로가 미리 추가되어 있습니다. 직접 실행한 python file이 속한 folder의 위치가 추가되어 있습니다. 또한 위에서 언급한 site-packages의 위치, python 인터프이터의 위치 등이 추가되어 있습니다.

unittest 사용하면서 경로 설정 문제점

실행 방법에 따라 다른 경로 설정

unittest의 테스트 케이스를 작성은 아래와 같습니다.

# tests/test.py
import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

이 테스트 케이스를 실행하는 방법은 python -m unittest test.py로 실행합니다. 이와 같은 방법으로 실행하여 __name__의 값을 확인하면 test가 반환되는 것을 확인할 수 있습니다. __name__에서 __main__이 반환되지 않는 것으로 보아 직접실행되는 형태가 아닙니다. 직접실행하는 방법은 python test.py로 실행하는 것입니다. python test.py로 실행해야만 unittest.main()이 실행됩니다.

python -m의 실행은 모듈을 스크립트로 수행할 때 쓰는 옵션이라고 합니다. python -m unittest로 실행하면 unittest module이 스크립트로 실행되고 test.py는 unittest에 인자로 전달되어 import 형식으로 test.py가 실행되는 것으로 보입니다.

python -m unittest test.py로 실행하는 방법과 python test.py로 실행하는 방법이 import하는 경로의 차이가 발생합니다. python test.py로 직접 실행하는 경우 sys.path의 경로에 tests folder가 포함되지만 python -m unittest test.py로 실해하는 경우 shell의 현재 위치가 sys.path에 추가되어 있습니다. 따라서 경우 2가지 실행 방법에서 절대 경로를 설정한다면 다른 import 경로를 설정해야 합니다.

통합으로 test case를 실행할 때 다른 경로 설정

unittest로 test code를 작성할 때는 주로 하나의 파일만 실행합니다. test case를 작성을 완료하면 모든 test code를 한 번에 실행해야 합니다.

# test_attendace_service.py
import unittest
from unittest.mock import patch, MagicMock
from datetime import datetime
from flaskr.service import attendance_service
from flaskr.model import AttendanceModel, TopicModel, UserModel

.....

if __name__ == '__main__':
    unittest.main()

절대경로로 module을 import하여 test_attendace_service.py file 하나만 실행하는 경우 import 경로에 문제가 없이 동작하게 구성했습니다.

# all_tests.py
import glob
import unittest
import sys
import os
testdir = os.path.dirname(__file__)
sys.path.insert(0, os.path.abspath(
    os.path.join(testdir, "../../des_api_lambda")))

if __name__ == '__main__':
    loader = unittest.TestLoader()
    start_dir = 'tests'
    suite = loader.discover(start_dir)

    runner = unittest.TextTestRunner()
    runner.run(suite)

all_test.py에서는 sys.path에 project root folder의 위치를 추가하여 import 경로에 문제가 발생하지 않도록 구성했습니다.

Reference

https://blog.potados.com/dev/python3-import/

DAS / NAS / SAN

yogae — Fri, 29 Oct 2021 20:11:42 +0900

DAS, NAS, SAN는 스토리지의 종류이고, 연결방식의 차이가 있다.

DAS(Direct Attached Storage)

시스템에 직접 붙이는 외장 스토리지이다. PC나 노트북에 외장형 하드를 붙이는 방식이 DAS이다. 서버와 하드웨어를 1:1로 연결한다. 서버에 직접 외장 스토리지를 연결하므로 속도는 빠르고 확장은 쉽지만 연결 수에 한계가 있다.

NAS(Networt Attached Storage)

서버와 저장 장치가 이더텟 등의 LAN 방식의 네트워크에 연결된 방식이다. LAN은 TCP/IP 프로토콜을 기반이고 저장장치는 SCSI를 사용하므로 이들간의 통신을 휘해 중계 역할을 하는 파일 서버가 필요하다. DAS와 달리 PORT수 제한이 없어 확장성과 유연성이 뛰어나다. 하지만 접속 증가 시 성능의 저하가 있고 파일 전송 속도는 DAS보다 느리다. 파일시스템을 공유하기 때문에 보안에 비교적 취약하다.

SCSI: 컴퓨터에 주변기기를 연결할 때 직렬 방식으로 연결하기 위한 표준을 일컫는다. SATA와 비교되며, SCSI가 진화된 것이 SAS이다. 무엇보다 안정성이 높은 것이 최대의 장점이지만 가격이 매우 비싸다.

SAN(Storage Area Network)

SAN은 여러 기기로 이루어진 로컬 네트워크인 반면, NAS는 LAN(Local Area Network)에 연결되는 단일 스토리지 디바이스이다. SAN 기술의 근간은 FC(Fiber Channel 광 채널)에 두고 있으며 NAS는 TCP/IP에 기반을 두고 있다. 단점은 SAN 구축 시 많은 비용을 투자 해야한다.

3 계층 architecture

yogae — Fri, 29 Oct 2021 07:15:29 +0900

3 계층 architecture란?

어떤 플랫폼을 3계층으로 나누어 별도의 놀리적 물리적인 장치에 구축 및 운영하는 형태를 말한다.

계층과 레이어

레이어와 계층이 혼동되어 사용될 때가 있다. 레이어는 소프트웨어의 기능적 분할을 의미하지만, 계층은 이프라에서 실행되는 소프트웨어의 기능적 분할을 의미한다.

계층을 분리하여 사용하는 목적

각 계층을 담당하는 팀들을 구성하여 업무 분담이 가능해지므로 업무 효율성이 증가할 수 있다. 여러 대의 서버로 나누어 각 계층이 동작하므로 서버의 부하를 줄여줄 수 있다. 부하가 발생하는 특정 계층의 서버에 대해서만 스케일업을 고려할 수 있다.

3 계층 구조 구성

프레젠터이션 계층

정보를 표시하고 사용자로부터 정보를 수집한다. 애플리케이션의 사용자 인터페이스를 지원한다. 주로 웹 서버를 뜻한다.

애플리케이션 계층

논리 계층 또는 중간 계층이라고도 하는 애플리케이션 계층은 애플리케이션의 핵심이다. 이 계층에서는 프리젠테이션 계층에서 수집된 정보를 처리한다. 데이터 계층의 데이터를 추가, 삭제 또는 수정할 수도 있다.

데이터 계층

데이터 액세스 계층 또는 백엔드라고도 불리는 데이터 계층은 애플리케이션이 처리하는 정보가 저장 및 관리되는 곳이다. 주로 DBMS(Database Management System)이 이 계층에 해당한다. Python, Ruby 또는 PHP를 사용하여 개발되며, 예를 들어 e Django, Rails, Symphony 또는 ASP.NET 등의 프레임워크를 실행합니다.

Web server vs WAS(Web Application Server)

Web server

클라이언트의 request가 오면 요청에 대한 처리를 담당하며 정적문서를 요청하는 경우 요청에 응답한다. 정적 컨텐트가 아닐 경우 WAS로 처리를 위임하여 WAS에서 반환된 값을 응답한다.

WAS

DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 서버이다. HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.

Web server와 WAS 를 분리하는 이유

WAS는 DB 조회나 다양한 로직을 처리하느라 바쁘기 때문에 단순한 정적 컨텐츠는 Web server에서 빠르게 클라이언트에 제공하여 서버 부하를 방지한다. 만약 정적 컨텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라 수행 속도가 느려진다. 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성 을 위해 Web Server와 WAS를 분리한다.

AWS KMS

yogae — Sun, 17 Oct 2021 22:20:36 +0900

AWS에 데이터 저장 시 암호화 적용

클라이언트 측 암호화와 서버 측 암호화를 구분하는 기준은 어디서 암호화를 하느냐는 것이다. 클라이언트에서 암호화를 암호화하는 경우 CSE이고 AWS내의 서버에서 암호화를 하는 경우를 SSE라고 한다. S3에서 object 저장 시 암호화하여 저장하는 방식이 SSE에 해당한다. S3에 object를 업로드하기 전 object를 암호화하여 s3에 저장하는 방식은 CSE에 해당한다.

클라이언트 측 암호화(Client-Side Encrytion)
- 데이터를 전송하기 전에 암호화 수행
- 고객이 직접 암호화 키를 마련하고 직접 관리하거나, AWS KMS / CloudHSM내에 보관 관리
서버 측 암호화(Server-Side Encryption)
- AWS가 전송된 데이터에 대해 고객 대신 버서 측에서 암호화 작업 수행
- 총 58개 서비스 연동: S3, EBS ....
- 고객 관리 통제 하에 AWS KMS에 암호화키 보관

CMK

KMS를 조사하면서 혼동되었던 부분이 CMK와 데이터 키이다. CMK는 KMS에 내부에 저장되어 외부유출을 방지한다. AWS KMS는 데이터 키를 저장, 관리 또는 추적하지 않는다. Aws-sdk에서 특정 CMK를 지정하려면 keyid를 사용한다. CMK를 사용하여 데이터키를 생성하며 데이터키로 암/복호화를 한다.

CMK의 특징

CMK은 절대 평문 형태로 HSM을 벗어나지 않는다.
CMK는 HSM에 저장된 도메인 키로 암호화되며 암호화된 상태로 KMS 내부의 별도 저장공간(KMS Host)에 저장된다.
데이터키는 KMS 내부의 HSM에서 생성된다.
생성된 데이터키는 CMK로 암호화하여 평문 데이터키와 함께 전달된다.

CMK 종류

관리 주체에 따른 CMK 종류

customer managed key
- 생성, 소유 관리할 수 있는 CMK이다.
AWS managed key
- AWS KMS와 통합된 AWS service에 의해 생성, 괸리, 사용되는 CMK이다. 사용자가 직접 관리하거나 변경할 수 없다.
- 특정 AWS service에서는 AWS managed key만을 제공할 수 있다.
AWS owned key
- multiple AWS account에서 사용하기 위해 AWS service에서 소유하고 관리하는 CMK이다.
- 사용자가 생성, 관리할 필요없다. 하지만 사용자가 사용, CloudTrail 통한 사용 기록을 호가인할 수 없다.
- key의 사용 요금이 없다.

대칭키 / 비대칭키

AWS KMS key는 default로 대칭키를 사용한다. AWS KMS와 연동된 AWS service에서는 데이터를 암화하기 위해 대칭키를 사용한다(비대칭키 사용을 제공하지 않음).
비태칭키는 공개키와 비밀키로 구성된다. 비밀키는 암호화되지 않은 형태로 AWS KMS 외부로 전송되지 않는다. 비밀키를 사용하기 위해서는 AWS KMS API를 요출해야 한다.

데이터키

데이터키를 생성할 때 평문 데이터 키와 암호화된 데이터 키가 반환된다. 암호화된 데이터 키는 복호화에 사용되며, 데이터와 함께 저장해도 안전하다. 데이터 키는 AWS KMS에서 저장, 관리되지 않는다.

봉투암호화

봉투 암호화 동작 방식(대칭키 사용)

데이터 키 생성

var params = {
  KeyId: "alias/ExampleAlias", // The identifier of the KMS key to use to encrypt the data key. You can use the key ID or Amazon Resource Name (ARN) of the KMS key, or the name or ARN of an alias that refers to the KMS key.
  KeySpec: "AES_256"// Specifies the type of data key to return.
 };
 kms.generateDataKey(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // successful response
   /*
   data = {
    CiphertextBlob: <Binary String>, // 암호화된 데이터 키 - 데이터 복호화를 위해 사용
    KeyId: "arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", // The ARN of the KMS key that was used to encrypt the data key.
    Plaintext: <Binary String>// 데이터 키 - 데이터 암호화를 위해 사용하며 암호화에 사용하고 따로 저장하지 않고 삭제해야한다.
   }
   */
 });

평문 데이터 키를 이용하여 평문을 암호화합니다. 암호화가 완료되면 평문 데이터 키는 삭제합니다.

평문을 암호화하기위해서는 암호화 module을 사용해야한다(AWS Encryption SDK, crypto-js, ncrypt-js).

// 예시
var encrypted = CryptoJS.AES.encrypt("Message", "<1번에서 반환된 Plaintext - 데이터 키>");

암호화된 문자열과 암호화된 Data Key를 반환합니다.

봉투 복호화 동작 방식(대칭키 사용)

암호화된 데이터 키 복호화

 var params = {
  CiphertextBlob: <Binary String>, // The encrypted data (ciphertext).
  KeyId: "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"// A key identifier for the KMS key to use to decrypt the data.
 };
 kms.decrypt(params, function(err, data) {
   if (err) console.log(err, err.stack); // an error occurred
   else     console.log(data);           // successful response
   /*
   data = {
    KeyId: "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", // The Amazon Resource Name (ARN) of the KMS key that was used to decrypt the data.
    Plaintext: <Binary String>// The decrypted (plaintext) data.
   }
   */
 });

평문 Data Key를 이용하여 암호화된 문자열을 복호화하여 반환합니다. 복호화가 완료된 평문 Data Key는 삭제합니다.

// 예시
var decrypted = CryptoJS.AES.decrypt(encrypted, "<1번에서 반환된 Plaintext - 데이터 키>");

Reference

node.js multi processing, threading

yogae — Fri, 2 Apr 2021 19:02:48 +0900

Node.js로 multi threading, multi processing을 필요로하는 작업을 진행하게 되었다.

Node.js에서 multi threading을 위해서는 worker_thread(node version 10부터 사용가능)를 사용한다. Multi processing을 위해서는 child_process 또는 cluster를 사용한다.

process를 단순하게 병렬로 실행하는 것은 child_process로 가능하고, 로드밸런싱과 포트 공유가 필요하다면 cluster를 사용하는 것이 좋다.

multi threading과 multi processing 중 선택

multi threading, multi processing을 사용하여 모두 구현은 가능하지만 두가지의 장단점이 다르기 때문에 요구사항에 따라 선택해야 한다.

multi threading을 사용하는 것은 multi processing을 사용하는 것 보다 병렬처리를 가볍게 처리하는 방식이다. memory를 효율적으로 공유하고 적은 공간을 사용할 수 있다. Multi processing으로 구현하는 경우 메모리를 공유할 수 없고 통신(IPC)을 통해 데이터를 주고 받아야 한다.

multi processing은 CPU-intensive한 작업을 처리할 때 선택하는 것이 좋고 multi threading은 I/O-intensive한 작업을 처리할 때 선택하는 것이 좋다.

참고: Exploring the Worker Thread API in Node

worker_thread 사용 예시

const { Worker } = require('worker_threads')

const runService = (workerData) => {
  return new Promise((resolve, reject) => {
    const worker = new Worker(__filename,{ workerData });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0)
        reject(new Error(`Worker stopped with exit code ${code}`));
    })
  })
}

const run = async () => {
  const result = await runService('test')
}

run().catch(err => console.error(err))

cluster 사용 예시

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
// main process가 실행
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
// worker process가 실행
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

Javascript 파일을 처음 실행하는 process가 마스터가 된다. 마스터에서는 fork() 메서드를 통해서 새로운 worker를 생성한다.

VPC AWS ElasticSearch Service로 Cognito 인증 접근

yogae — Fri, 5 Feb 2021 22:55:53 +0900

VPC내에 ES를 사용하고 있다. VPC내 ES로 접근하기 위해서는 ssh tunneling을 사용하거나 proxy 서버를 구성하여 접근 해야한다.

ES를 보고서를 작성할 때만 사용하고 있어서 많은 설정이 필요 없는 ssh tunneling으로 사용하고 있었다. 하지만 점점 사용 빈도가 늘어나면서 매번 tunneling을 하는 것이 귀찮아졌다. kibana에 개발자가 아닌 사람이 접속할 상황이 생기고 점점 tunneling을 관리하기가 어려워졌다.

Amazon Cognito 인증으로 Kibana에 액세스하기 위해 SSH 터널 사용

위의 그림 처럼 tunneling을 사지 않고 proxy 서버를 통해 traffic이 VPC 내부에 있는 ES로 접근할 수 있도록 구성했다. ES에 접근 시 cognito의 login을 하여 인증된 사용자에게만 권한을 부여하고 ES를 사용할 수 있도록 구성했다.

Nginx Proxy Server 설정

기존에 ssh tunneling으로 사용하는 EC2 instance는 spot instance였다. Spot instance는 싸지만 언제든지 새로운 instance로 교체될 수 있다. 지속적으로 사용해야하는 경우 on-demand 또는 reserved instance를 생성해야한다.

Let’s encrypt

ALB를 사용하면 ACM 서비스를 이용하여 SSL 인증서를 관리할 수 있고 확장성이 용이한 구성을 할 수 있다. 하지만 ALB사용 시 유지비용이 추가된다. 회사 내부에서만 ES에 접근하는 상황이라 EC2 instance 하나만 사용했다.

ALB나 Cloudfront를 사용하지 않고 EC2 instance 만 사용하는 경우 ACM을 사용할 수 없다. SSL 인증서를 발급받기 위해 let’s encrypt를 사용했다. Amazon Linux2를 사용하는 경우 Let’s encrypt를 사용하는 방법은 아래 링크에 자세하게 설명되어 있다.

자습서: Amazon Linux 2에서 SSL/TLS 구성 - Amazon Elastic Compute Cloud

여러 가지 방법으로 사용자 지정 키를 EC2 인스턴스에 업로드할 수 있지만, 가장 간편하고 유익한 방법은 텍스트 편집기(예: vi, nano, 메모장)를 로컬 컴퓨터와 인스턴스에 모두 열고 두 편집기 간

docs.aws.amazon.com

Certbot으로 인증서를 발급받을 때 주의할 사항은 먼저 route53에 EC2의 public ip에 특정 도메인을 먼저 연결하고 EC2 instance의 Security Group 80 port를 열어야한다.

nginx proxy 설정

resolver 10.0.0.2 ipv6=off;
# 80 -> 443
server {
    listen 80;
    server_name $host;
    set $es_endpoint <ES_ENDPOINT>;
    return 301 https://<ES_ENDPOINT>;
}

server {
    listen 443 ssl;
    server_name $host;
    rewrite ^/$ https://$host/_plugin/kibana redirect;

    ssl_certificate /etc/nginx/cert.crt;
    ssl_certificate_key /etc/nginx/cert.key;

    ssl on;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    set $es_endpoint <ES_ENDPOINT>;
    set $cognito_endpoint <COGNITO_ENDPOINT>;

    location ^~ /_plugin/kibana {
        # Forward requests to Kibana
        proxy_pass https://$es_endpoint;

        # Handle redirects to Amazon Cognito
        proxy_redirect https://$cognito_endpoint https://$host;

        # Update cookie domain and path
        proxy_cookie_domain $es_endpoint $host;

        # Response buffer settings
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }

    location ~ \/(log|sign|error|fav|forgot|change|confirm) {
        # Forward requests to Cognito
        proxy_pass https://$cognito_endpoint;

        # Handle redirects to Kibana
        proxy_redirect https://$es_endpoint https://$host;

        # Handle redirects to Amazon Cognito
        proxy_redirect https://$cognito_endpoint https://$host;

        # Update cookie domain
        proxy_cookie_domain $cognito_endpoint $host;
    }
}

위의 내용을 /etc/nginx/conf.d/default.conf에 작성하여 nginx server를 재실행한다.

Amazon Cognito 인증으로 Kibana에 액세스하기 위해 NGINX 사용

Amazon Elasticsearch Service(Amazon ES) 클러스터가 Virtual Private Cloud(VPC)에서 실행됩니다. Amazon Cognito 인증으로 VPC 외부에서 Kibana에 액세스하기 위해 NGINX 프록시를 사용하려고 합니다.

aws.amazon.com

ElasticSearch Service 설정

ElasticSearch Service에 cognito 인증을 설정하기 위해서 인증 수정 버튼을 클릭한다.

인증 수정에서 사용할 user pool과 identity pool을 설정한다. console에서 설정하면 자동으로 앱클라이언트 설정과 앱클라이언트와 연결된 identity pool을 설정해준다.(자동으로 앱클라이언트가 생성된다.)

ES와 cognito를 연결했다면 권한을 설정해야한다. (위의 과정만 진행하면 kibana endpoint로 접근 시 로그인 페이지가 나오지 않고 바로 kibana로 접속된다.)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account id>:role/<인증된 사용자 역할>"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:<region>:<account id>:domain/<es domain name>/*"
    }
  ]
}

identity pool의 설정에서 인증된 사용자 역할을 위의 json에 채운다.

Airflow 기본 시용법 정리

yogae — Fri, 22 Jan 2021 16:53:50 +0900

Python을 사용하여 행동 로그를 분석하고 있다. 스크립트를 작성하여 필요할 때마다 실행하여 분석 데이터를 수집하였다. 로그 데이터를 분석을 시작하니 정말 다양한 요구사항이 있었다. 이러한 요구사항에 따라 script를 작성하다보니 script가 많아졌고 많은 script를 관리해야하는 문제가 생겼다. 또한, script간의 순서가 생기면서 workflow를 정의하고 관리하는 일이 많아졌다.

AWS에서 airflow를 관리형 서비스로 출시했다는 소식을 듣게 되었다. AWS의 관리형 airflow를 사용하면 좋지만 현재 python script를 관리의 목적 및 분석 workflow구성을 위해서만 사용하고 있어서 필요할 때마다 airflow를 local 환경에서 실행하여 사용하기로 했다. script를 주기적으로 실행해야하는 경우나 여러사람이 공유해야한다면 MWAA(Amazon Managed Workflows for Apache Airflow)를 찾아보면 좋을 것이다.

Basic Airflow architecture

Airflow 설치

export AIRFLOW_HOME=~/airflow

pip install apache-airflow

airflow의 설치는 위와같이 쉽게 할 수 있다. $AIRFLOW_HOME에 설정한 폴더에 airflow 설정 file airflow.cfg, sqlite db file airflow.db이 생성된다.

데이터 베이스

airflow db init

airflow users create \
    --username admin \
    --firstname Peter \
    --lastname Parker \
    --role Admin \
    --email spiderman@superhero.org

db를 초기화 하고 사용자를 생성한다.

airflow를 상태를 저장하기 위해 database를 사용한다. 기본으로 sqlite를 사용한다. 동시에 여러 task를 실행하기 위해서는 MySQL 또는 PostgreSQL을 사용해야한다. sqlite를 사용하는 경우 병렬로 task를 실행하여도 하나씩 처리하게 된다.

Airflow web server 실행

# start the web server, default port is 8080
airflow webserver --port 8080

# start the scheduler
# open a new terminal or else run webserver with ``-D`` option to run it as a daemon
airflow scheduler

Airflow Webserver와 Scheduler는 독립된 process에서 실행된다. Webserver만 실행하고 0.0.0.0:8080으로 접속하면 Airflow Web page를 볼 수 있다. 하지만 DAG를 실행하게 되면 Task가 실행중으로 남게 된다. Task가 계속 실행 중으로 남아있다면 Airflow scheduler를 확인해보자!

Airflow web server를 처음 실행하면 위의 사진과 다르게 여러개의 예제 DAGs를 볼수 있다. 예제 DAGs를 삭제하려면 airflow.cfg의 load_examples을 False로 설정해하고 DB를 초기화 해야한다. load_examples값만 False로 변경하면 예제 DAGs가 그대로 남아 있다.

위쪽 끝에 위치한 pause 토글 버튼이 처음 생성되었을 때는 pause로 되어 있다. DAG가 pause되어 있어도 DAG를 실행할 수는 있지만 task가 실행되지 않는다. 실행전에 pause 버튼을 확인하기 바란다.

DAG 작성

Airflow의 DAG 작성은 Python으로 작성해야한다.

from datetime import timedelta

# The DAG object; we'll need this to instantiate a DAG
from airflow import DAG

# Operators; we need this to operate!
from airflow.operators.bash import BashOperator
from airflow.utils.dates import days_ago
# These args will get passed on to each operator
# You can override them on a per-task basis during operator initialization
default_args = {
    'owner': 'airflow',
    'depends_on_past': False,
    'email': ['airflow@example.com'],
    'email_on_failure': False,
    'email_on_retry': False,
    'retries': 1,
    'retry_delay': timedelta(minutes=5),
    # 'queue': 'bash_queue',
    # 'pool': 'backfill',
    # 'priority_weight': 10,
    # 'end_date': datetime(2016, 1, 1),
    # 'wait_for_downstream': False,
    # 'dag': dag,
    # 'sla': timedelta(hours=2),
    # 'execution_timeout': timedelta(seconds=300),
    # 'on_failure_callback': some_function,
    # 'on_success_callback': some_other_function,
    # 'on_retry_callback': another_function,
    # 'sla_miss_callback': yet_another_function,
    # 'trigger_rule': 'all_success'
}
dag = DAG(
    'tutorial',
    default_args=default_args,
    description='A simple tutorial DAG',
    schedule_interval=timedelta(days=1),
    start_date=days_ago(2),
    tags=['example'],
)

# t1, t2 and t3 are examples of tasks created by instantiating operators
t1 = BashOperator(
    task_id='print_date',
    bash_command='date',
    dag=dag,
)

t2 = BashOperator(
    task_id='sleep',
    depends_on_past=False,
    bash_command='sleep 5',
    retries=3,
    dag=dag,
)
dag.doc_md = __doc__

t1.doc_md = """\
#### Task Documentation
You can document your task using the attributes `doc_md` (markdown),
`doc` (plain text), `doc_rst`, `doc_json`, `doc_yaml` which gets
rendered in the UI's Task Instance Details page.
![img](http://montcs.bloomu.edu/~bobmon/Semesters/2012-01/491/import%20soul.png)
"""
templated_command = """
{% for i in range(5) %}
    echo "{{ ds }}"
    echo "{{ macros.ds_add(ds, 7)}}"
    echo "{{ params.my_param }}"
{% endfor %}
"""

t3 = BashOperator(
    task_id='templated',
    depends_on_past=False,
    bash_command=templated_command,
    params={'my_param': 'Parameter I passed in'},
    dag=dag,
)

t1 >> [t2, t3]

Task를 정의할 때는 operator를 사용한다. Airflow에서 제공하는 operator는 여러가지가 있다. 위의 예제에서와 같은 Bash을 실행하는 BashOperator와 python을 실행하는 PythonOperator가 있다. DB와 aws s3 등 저장소 ETL 작업과 관련된 operator 등 다양한 operator를 제공한다. operator를 custom하게 생성하여 사용할 수도 있다.

Creating a custom Operator — Airflow Documentation

Airflow params 전달

Trigger DAG버튼을 클릭하면 위와 같은 json 입력창이 보인다. json형식으로 Task에 전달할 params를 작성하고 Trigger하면 params를 전달할 수 있다.

from airflow import DAG
from airflow.operators.python import PythonOperator

args = {
    'owner': 'airflow',
}

dag = DAG(
    dag_id='analysis_dag',
    default_args=args,
    schedule_interval=None,
    start_date=days_ago(2),
    tags=['example'],
)

def process_func(ds, **kwargs):
    params = kwargs['params']
    START_TIMESTAMP = params["START_TIMESTAMP"]
    END_TIMESTAMP = params["END_TIMESTAMP"]
      ...

PythonOperator(
  task_id='process_task',
  python_callable= process_func,
  dag=dag,
)

sh로 실행하는 경우

airflow dags trigger {dag_id} -c '{"START_TIMESTAMP": "START_TIMESTAMP", "END_TIMESTAMP": "END_TIMESTAMP"}'

airflow tags test {dag_id} {execution_date} -t '{"START_TIMESTAMP": "START_TIMESTAMP", "END_TIMESTAMP": "END_TIMESTAMP"}'

Variables

DB url과 같은 보안이 필요한 값은 Admin > Variables에 등록하여 사용할 수 있다.

from airflow.models import Variable

def example_func(ds, **kwargs):
    DB = Variable.get("DB_LOCAL")
      ....

PythonOperator(
    task_id='example_task',
    python_callable=example_func,
    dag=dag,
)

Task간 message 전송

Task간 message를 전송하는 방법이 조금 까다롭다. Task간에 message가 작은 경우(48KM 이하) XCOM을 사용하여 message를 전달할 수 있다. message 크기 제한 때문에 가능한 다른 저장소를 사용하고 XCOM에는 간단한 key 값이나 path값만 전달하여 사용하는 방식이 맞다고 생각된다.

from airflow.operators.python import PythonOperator

def example_xcom_push(ds, **kwargs):
     kwargs['ti'].xcom_push(
      key="example_xcom",value=str(1))

def example_xcom_pull(ds, **kwargs):
     pull_value = kwargs['ti'].xcom_pull(
        task_ids='', key='example_xcom')
     print(pull_value)    

push_task = PythonOperator(
   task_id='example_xcom_push_task',
   python_callable= example_xcom_push,
   dag=dag,
)

pull_task = PythonOperator(
   task_id='example_xcom_pull_task',
   python_callable= example_xcom_pull,
   dag=dag,
)

push_task >> pull_task

큰 사이즈 message 경우 local filesystem을 사용하거나 다른 저장소를 사용하여 전달해야 한다.

AWS configuration

Amazon Web Services Connection — apache-airflow-providers-amazon Documentation

yogae 블로그

Elasticsearch 비용 절약하기

Elasticsearch Cloud에서 AWS Self Managed로 Migration

Instance Type 선택 시 비용 고려사항

Data Transfer 비용도 고려해야합니다.

Github Actions 관리하기(Organization secrets, Reusable workflows)

✏️ Organization secrets

⭐️ Reusable workflows

reusing workflows 제한사항

✏️ Reusing workflows 호출하기

lambda@edge를 사용한 요청 header 처리(user-agent, accept-language)

문제점

해결방법

Lambda@Edge

Lambda@Edge 제한사항

구현

header parsing

배포 스크립트 작성

결과

Reference

python 절대경로 / 상대경로

__name__의 역할

절대경로와 상대경로

sys.path

unittest 사용하면서 경로 설정 문제점

실행 방법에 따라 다른 경로 설정

통합으로 test case를 실행할 때 다른 경로 설정

Reference

DAS / NAS / SAN

DAS(Direct Attached Storage)

NAS(Networt Attached Storage)

SAN(Storage Area Network)

3 계층 architecture

3 계층 architecture란?

계층과 레이어

계층을 분리하여 사용하는 목적

3 계층 구조 구성

프레젠터이션 계층

애플리케이션 계층

데이터 계층

Web server vs WAS(Web Application Server)

Web server

WAS

Web server와 WAS 를 분리하는 이유

AWS KMS

AWS에 데이터 저장 시 암호화 적용

CMK

CMK의 특징

CMK 종류

관리 주체에 따른 CMK 종류

대칭키 / 비대칭키

데이터키

봉투암호화

봉투 암호화 동작 방식(대칭키 사용)

봉투 복호화 동작 방식(대칭키 사용)

Reference

node.js multi processing, threading

multi threading과 multi processing 중 선택

worker_thread 사용 예시

cluster 사용 예시

VPC AWS ElasticSearch Service로 Cognito 인증 접근

Nginx Proxy Server 설정

Let’s encrypt

nginx proxy 설정

ElasticSearch Service 설정

Airflow 기본 시용법 정리

Airflow 설치

데이터 베이스

Airflow web server 실행

DAG 작성

Airflow params 전달

Variables

Task간 message 전송

AWS configuration

Reference

`name`의 역할

`sys.path`