Airflow 공식 Docker 이미지를 사용하는 서버로 onGCP 구축

16042 단어 gcpairflow
이 기사는 GCP의 VM 실례에 에어플로우 서버를 구축·운용한 사례를 소개한다.
Airflow 배경 사용
당사(주식회사 unerry)는 다른 회사와 데이터 인수인계를 진행하고 있습니다.
이러한 협업이 시작된 당초 다른 사건마다 마이크로의 실례 서버를 구축하고 클라우드 펀션+클라우드 Schedule을 사용했다.
그러나 사건이 늘어날 때 문제가 되는 것은 고장 등으로 데이터가 지연돼 제공되지 않을 경우 개별 시행상황에 따라 각 매뉴얼에 대량 재집행하는 데 시간이 걸린다는 점이다.
Airflow는 excution입니다.날짜라는 개념이 있어서 과거의 업무의 재집행은 쉽다.1
또 DAG의 일람표로 여러 작업을 관리할 수 있어 기쁘다는 점이 도입의 계기가 됐다.
이런 느낌이에요.2

GCP에는 경영진의 Cloud Composier가 있습니다.
네, 그런데 이거 비싸요.도쿄 지역이라면 작은 구성이라도 한 달에 500달러 정도가 든다.
당사는 데이터 협업 이외에도 정기적으로 비교적 무거운 분석 처리3를 진행하지만 R언어나 조개껍질을 사용한다면 반드시 파이톤으로 처리하는 것은 아닙니다.관리 임무를 수행할 수 있으면 좋겠기에 GCE에 에어플로우를 만들어 사용했다.4
기본적으로 파이썬 처리이고 에어플로우를 병렬 처리한 후 CPU를 사용한다.이 경우 Cloud Composier도 선택 항목으로 나열됩니다.5
GCP에서 사용되는 리소스
  • VM 인스턴스
  • Container-Optimized OS
  • 로드 밸런서
    HTTPS용

  • Container Registry
  • 배치된 후 설명된 Airflow의 사용자 정의 이미지
  • Cloud SQL
  • MySQL의 경우
  • 모니터의 경고
  • 관리자가 아니기 때문에 감시해야 한다.본사는 아래의 내용을 감시한다.
  • Uptime Check(HTTPS의 생사 확인)
  • 디스크 사용량
  • 스토리지 사용량
  • IAM
  • 에어플로우용 서비스 계정 만들기, 클라우드 펀션 소스에 대한 개별적인 권한 부여 허용 등
  • 다음은 본문에서 서술한 범위이다
    에어플로우의 Docker 이미지의 사용자 정의, Container-optimized OS의cloud-init, 데이터베이스 초기화.다른 특별한 일이 없기 때문에, 사랑을 끊는다.
    Airflow의 Docker 이미지 사용자 정의
    공식 이미지에 따라 조작할 수 있지만 실제 적용에는 다음과 같은 내용이 추가됐다.
  • Cloud SDK
  • BashOperator에서 gcloud 명령을 사용하기 위해
  • 현재 로그 삭제 케이스
    Clean-logs.sh를 포함하지만 빈 디렉터리를 삭제할 수 없습니다 6
  • Dockerfile
    FROM apache/airflow:2.2.2
    
    USER root
    
    RUN echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" > /etc/apt/sources.list.d/google-cloud-sdk.list && \
        curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key --keyring /usr/share/keyrings/cloud.google.gpg add - && \
        apt-get update && \
        apt-get install -y google-cloud-sdk
    
    COPY --chown=airflow:root custom-clean-logs.sh /custom-clean-logs
    RUN chmod a+x /custom-clean-logs
    
    USER airflow
    
    custom-clean-logs.sh
    #!/usr/bin/env bash
    
    set -euo pipefail
    
    readonly DIRECTORY="${AIRFLOW_HOME:-/usr/local/airflow}"
    readonly RETENTION="${AIRFLOW__LOG_RETENTION_DAYS:-15}"
    
    trap "exit" INT TERM
    
    readonly EVERY=$((15*60))
    
    echo "Cleaning logs every $EVERY seconds"
    
    while true; do
      echo "Trimming airflow logs to ${RETENTION} days."
      find "${DIRECTORY}"/logs \
        -type d -name 'lost+found' -prune -o \
        -type f -mtime +"${RETENTION}" -name '*.log' -print0 | \
        xargs -0 rm -f
    
      # 公式のclean-logs.shにこれを足しています
      echo "Delete empty directories."
      find "${DIRECTORY}"/logs -type d -empty -delete
    
      seconds=$(( $(date -u +%s) % EVERY))
      (( seconds < 1 )) || sleep $((EVERY - seconds))
    done
    
    Container-Optimzed OS용 cloud-init
    cloud-init.yml의 내용을 VM 실례가 만들어졌을 때의 사용자 정의 메타데이터에 키user-data의 값으로 붙여넣습니다.다음은 자사 데이터 협업 에어플로우의 설정 내용이다.7
    #cloud-config
    
    # AirflowのDockerイメージがairflowユーザーで動作するためホスト側もairflowユーザーを作成します
    users:
    - name: airflow                               
    
    write_files:
    # Airflow起動時の環境変数ファイル
    - path: /var/airflow/env
      content: |
        AIRFLOW_HOME=/var/airflow
        AIRFLOW__CORE__SQL_ALCHEMY_CONN=mysql+mysqldb://dbuser:dbpassword@cloud_sql_proxy:3306/dbname
        AIRFLOW__CORE__EXECUTOR=LocalExecutor
        AIRFLOW__CORE__PARALLELISM=4
        AIRFLOW__WEBSERVER__BASE_URL=
        AIRFLOW__WEBSERVER__WORKERS=2
        AIRFLOW__WEBSERVER__ENABLE_PROXY_FIX=True
      owner: airflow:airflow
    
      # AIRFLOW_HOME:                         DAGやログなどの配置場所になります。お好みで。
      # AIRFLOW__CORE__SQL_ALCHEMY_CONN:      データベースの接続設定です。
      # AIRFLOW__CORE__EXECUTOR:              一台構成かつ並列実行したいのでLocalExecutorを指定します。
      # AIRFLOW__CORE__PARALLELISM:           並列数はマシンスペックと相談で。デフォルトの32で低スペックマシンだとメモリ不足で死にます。
      # AIRFLOW__WEBSERVER__BASE_URL:         デフォルトはhttp://localhost:8080なのですが、空にしておかないとタスクのログが見れません。
      # AIRFLOW__WEBSERVER__WORKERS:          デフォルトは4ですが、そんなに必要ないと思うのでケチってます。
      # AIRFLOW__WEBSERVER__ENABLE_PROXY_FIX: ロードバランサ用の設定です。
    
    # systemd のユニットファイル - Cloud SQL Proxy
    - path: /etc/systemd/system/cloud_sql_proxy.service
      content: |
        [Unit]
        Description=Cloud SQL Proxy daemon
        After=network.target
    
        [Service]
        ExecStart=/usr/bin/docker run --name=cloud_sql_proxy --rm --net=db gcr.io/cloudsql-docker/gce-proxy:latest /cloud_sql_proxy -instances=abechan-no-project-id:asia-northeast1:airflow=tcp:0.0.0.0:3306
        ExecStop=/usr/bin/docker stop cloud_sql_proxy
        Restart=on-failure
    
    # systemd のユニットファイル - Airflow WebServer
    - path: /etc/systemd/system/airflow-webserver.service
      content: |
        [Unit]
        Description=Airflow webserver daemon
        After=network.target
    
        [Service]
        Environment="HOME=/home/airflow"
        ExecStartPre=/usr/bin/docker-credential-gcr configure-docker
        ExecStart=/usr/bin/docker run --name=airflow-server --rm --net=db -p 80:8080 --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 airflow webserver
        ExecStop=/usr/bin/docker stop airflow-server
        Restart=on-failure
    
    # systemd のユニットファイル - Airflow Scheduler
    - path: /etc/systemd/system/airflow-scheduler.service
      content: |
        [Unit]
        Description=Airflow scheduler daemon
        After=network.target
    
        [Service]
        Environment="HOME=/home/airflow"
        ExecStartPre=/usr/bin/docker-credential-gcr configure-docker
        ExecStart=/usr/bin/docker run --name=airflow-scheduler --rm --net=db --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 airflow scheduler
        ExecStop=/usr/bin/docker stop airflow-scheduler
        Restart=on-failure
    
    # systemd のユニットファイル - Airflow のログ削除シェル
    - path: /etc/systemd/system/airflow-clean-logs.service
      content: |
        [Unit]
        Description=Airflow clean-logs daemon
        After=network.target
    
        [Service]
        Environment="HOME=/home/airflow"
        ExecStartPre=/usr/bin/docker-credential-gcr configure-docker
        ExecStart=/usr/bin/docker run --name=airflow-clean-logs --rm --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 bash /custom-clean-logs
        ExecStop=/usr/bin/docker stop airflow-clean-logs
        Restart=on-failure
    
    runcmd:
    - mkdir -p /var/airflow/scripts              # BashOperatorから叩きたいシェルの置き場所
    - mkdir -p /var/airflow/dags                 # DAGのディレクトリ
    - mkdir -p /var/airflow/logs                 # ログのディレクトリ
    
    - usermod -u 50000 airflow                   # コンテナからホスト側ボリュームを見た時にパーミッションエラーになるので、AirflowのDockerイメージのユーザーIDにあわせています
    - groupmod -g 50000 airflow                  # ↑と同じ理由でグループID
    - chown -R airflow:airflow /var/airflow/
    
    - docker images -aq | xargs docker rmi       # インスタンスを再起動した時に最新のイメージ(キャッシュされたものではなく)を取得したいのでインスタンス起動時に削除しています
                                                 #   => こうしておくとDockerイメージのタグをlatestなどで固定していてもインスタンスの再起動で更新を反映できます
    
    - docker network create -d bridge db         # AirflowのコンテナからCloud SQL Proxyのコンテナに接続するためのブリッジ
    
    - systemctl daemon-reload                    # 以下、systemd関連
    - systemctl start cloud_sql_proxy.service
    - systemctl start airflow-webserver.service
    - systemctl start airflow-scheduler.service
    - systemctl start airflow-clean-logs.service
    
    데이터베이스 초기화

  • Container-Optimzed OS의 VM 인스턴스에 로그인한 후 bash 셸에서 Airflow 이미지를 시작합니다.
    docker run -it --rm --net=db --env-file=/var/airflow/env -v /var/airflow:/var/airflow gcr.io/abechan-no-project-id/airflow-custom:2.2.2 bash
    

  • Airflow 컨테이너에서 데이터베이스를 초기화하고 관리자 사용자 만들기
    airflow db init
    airflow users create -u abechan -p password -r Admin -e mail@address -f firstname-is-secret -l lastname-is-abechan
    
  • 최후
    처음엔 에어플로우의 취미를 기르기 어렵다고 생각했지만, 습관의 문제 때문에 지금 없어서는 안 될 도구로 편리하다.소량의 관리가 힘들다는 고민이 많으신 분들은 도입을 고려해 봐도 될까요?
    파이톤에 리눅스에 직접 설치할 수 있지만 Docker 이미지는 환경 변수를 통해 다양한 제어를 할 수 있어 쉽게 구축할 수 있어 추천합니다.
    취미가 강하다
    데이터 협업을 위한 에어플로우이며, 이 외에 배치 처리를 분석하는 에어플로우가 한 대 더 있다.
    이러한 분석 처리에서 Airflow에서 규격을 높이는 VM 실례를 일시적으로 구축하고 처리가 끝난 후 실례를 삭제한다
    Airflow에서 수행되는 로트는 주로 Cloud Function/Cloud Run/자주 실행되는 VM 인스턴스+SSH 원격 실행 등을 통해 처리
    실제로 Cloud Composier를 사용하는 곳도 있습니다(자세한 내용은 비밀로 해주세요)
    운용 후 디스크 사용량이 조금씩 증가하는 현상을 만났다
    문장은 일부 정보의 마스크와 낡은 부분의 최신화를 사용했다

    좋은 웹페이지 즐겨찾기