Apache AirflowのDocker化: Docker ComposeによるプロフェッショナルなCeleryExecutorの構築 – ITFROMZERO

Table of Contents

Airflowインストール時の「依存関係の地獄（Dependency Hell）」を解決する

Apache Airflowを直接 pip install でインストールするのは、午後の時間を丸ごと無駄にする最短の方法です。私自身、cryptography のバージョンがシステムライブラリと衝突しただけで4時間も足止めを食らったことがあります。Airflowは単なるPythonスクリプトではなく、Webserver、Scheduler、Database、Workerからなる巨大なエコシステムなのです。

よくある問題は、ローカル環境では正常に動作するDAGが、サーバー上ではエラーになることです。その原因の多くは、Google CloudやAWS用のシステムライブラリの不足や、PostgreSQLのバージョン不一致にあります。バラバラのコンポーネントを管理していると、環境は非常に脆弱になります。環境変数を一つ変更しただけで、スケジューリングシステム全体が理由もわからず停止することさえあります。

なぜデフォルト設定は実務プロジェクトで使えないのか？

デフォルトでは、Airflowは SequentialExecutor と SQLite をデータベースとして使用します。このモードでは、一度に一つのタスクしか実行できません。毎朝ETL処理が必要なテーブルが50個あると想像してみてください。逐次実行（シーケンシャル）では、いつ終わるかわかりません。

実用的なパフォーマンスを得るには、メタデータ保存用の PostgreSQL と、キューイングシステムとしての Redis が必要です。これに CeleryExecutor を組み合わせることで、初めて分散実行が可能になります。ホストOS上でこれら5つのコンポーネントを個別に設定するのは苦行です。設定は複雑に絡み合い、デバッグは困難になり、DevOpsチームへの引き継ぎもほぼ不可能になります。

Airflowをデプロイする3つの一般的な方法

エンジニアは通常、以下の3つのアプローチを検討します：

直接インストール (Local Install): 数行のコードを素早くテストする場合にのみ適しています。スケーリングやチーム開発が必要になると悪夢に変わります。
マネージドサービス (Astronomer, AWS MWAA): 運用は非常に楽です。しかし、コストが非常に高く、予算を最適化したいラボ環境やスタートアップには向きません。
Docker Compose: これが「スイートスポット（最適解）」です。インフラ全体が一つの .yaml ファイルに収まり、開発環境から本番環境まで100%の同一性が保証されます。

最適解：CeleryExecutorとRedisによるDocker化

Docker Composeを使用してCeleryExecutorをデプロイすることは、プロフェッショナルなスケジューリングシステムを構築する最良の方法です。このアーキテクチャにより、重いタスクを処理するためにWorkerの数を柔軟に拡張できます。

1. 環境の準備

マシンに Docker Desktop と Docker Compose v2.0 以上がインストールされていることを確認してください。最低4GBのRAMが必要ですが、大規模なデータを処理するDAGを実行する場合は8GB以上に設定することをお勧めします。

2. 設定の初期化

環境変数の設定ミスが起こりやすいため、Composeファイルをゼロから自作するのは避けましょう。まずはコミュニティの標準設定から始めます。まずは、プロジェクトディレクトリを作成します：

mkdir airflow-docker && cd airflow-docker
mkdir -p ./dags ./logs ./plugins ./config
echo -e "AIRFLOW_UID=$(id -u)" > .env

AIRFLOW_UID の行は、Dockerがホストマシンにログを書き込む際のパーミッションエラーを防ぐためのものです。これは、多くの人が一日中悩まされる非常に一般的なエラーです。

3. docker-compose.yamlファイルのダウンロード

以下のコマンドで Apache Airflow の公式設定ファイルを取得します：

curl -LfO 'https://airflow.apache.org/docs/apache-airflow/stable/docker-compose.yaml'

このファイルにより、以下の重要なサービスが起動します：

postgres: メタデータの保存。
redis: ワーカーにタスクを転送するブローカー。
airflow-webserver: 管理UI画面。
airflow-scheduler: システム全体の制御を司る頭脳。
airflow-worker: 実際のPythonコードが実行される場所。

4. データベースの初期化

実行する前に、データベースの初期化と管理者ユーザーの作成が必要です：

docker compose up airflow-init

exited with code 0 という行が表示されれば、準備完了です。

5. システムの起動

いよいよ成果を確認しましょう：

docker compose up -d

デフォルトのアカウント airflow / airflow で localhost:8080 にアクセスします。Airflow APIからの長いJSONレスポンスを確認する必要がある場合は、重い拡張機能をインストールする代わりに、 JSON Formatter を使って読みやすく整形すると便利です。

CeleryWorkerを確認するための最初のDAGを作成する

並列実行能力を確認するために、./dags ディレクトリに test_dag.py ファイルを作成します：

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

def heavy_task():
    # データを処理中...
    print("データを処理中...")
    time.sleep(5)
    return "Done"

with DAG(
    dag_id='test_celery_executor',
    start_date=datetime(2023, 1, 1),
    schedule_interval=None,
    catchup=False
) as dag:

    task_1 = PythonOperator(task_id='run_1', python_callable=heavy_task)
    task_2 = PythonOperator(task_id='run_2', python_callable=heavy_task)

    task_1 >> task_2

WebserverでDAGを有効にし、手動で実行（trigger）してみてください。タスクが緑色に変われば、分散システムは正常に動作しています。

実戦経験からの注意点

運用中の「手痛い」ミスを避けるために、以下の点に注意してください：

リソース制限 (Resource Limit): コンテナが異常終了（Exit code 137）する場合、それはメモリ不足が原因です。Dockerの設定でリソース制限を増やしてください。
カスタムライブラリ (Custom Library): pandas や scikit-learn を使用する必要がある場合は、独自の Dockerfile を作成する必要があります。FROM apache/airflow を指定し、新しいイメージにライブラリを pip install してください。
ログのクリーンアップ: ./logs ディレクトリはすぐに肥大化します。ログを大容量ディスクにマウントするか、7日後に自動削除するスクリプトを設定してください。

Docker Composeを使いこなすことで、プロジェクトの引き継ぎに自信が持てるようになります。10ページにわたる手順書を送る代わりに、同僚に「docker compose up を叩けば動くよ！」と伝えるだけで済むのです。