次の方法で共有

Azure Kubernetes Service (AKS) への Apache Airflow のデプロイの概要

このガイドでは、Helm を使用して Azure Kubernetes Service (AKS) へ Apache Airflow をデプロイします。 AKS クラスターを設定し、Helm をインストールし、Helm チャートを使用して Airflow をデプロイし、Airflow UI を調べる方法を学習します。

重要

オープンソース ソフトウェアは、AKS のドキュメントとサンプル全体で説明されています。 デプロイするソフトウェアは、AKS サービス レベル アグリーメント、限定保証、Azure サポートから除外されます。 AKS と共にオープンソース テクノロジを使用する場合は、それぞれのコミュニティとプロジェクト保守担当者から受けられるサポート オプションを調べ、計画を策定してください。

たとえば、Ray の GitHub リポジトリでは、応答時間、目的、サポート レベルが異なる複数のプラットフォームについて説明しています。

Microsoft は、AKS 上に展開するオープンソース パッケージを構築する責任を負います。 その責任には、ビルド、スキャン、署名、検証、修正プログラム プロセスの完全な所有権と、コンテナー イメージ内のバイナリの制御権が伴います。 詳細については、AKS の脆弱性管理に関するページと「AKS のサポート範囲」を参照してください。

Apache Airflow とは?

Apache Airflow は、バッチ指向ワークフローの開発、スケジューリング、監視のために構築されたオープンソース プラットフォームです。 Airflow は、柔軟な Python フレームワークにより、ほぼすべてのテクノロジとシームレスに統合されるワークフローの設計を可能にします。 Airflow では、有向非巡回グラフ (DAG) で表される Python ワークフローを定義する必要があります。 Airflow は任意の場所にデプロイできます。デプロイ後は、Airflow UI にアクセスしてワークフローを設定できます。

Airflow アーキテクチャ

大まかに言えば、Airflow には以下のものが含まれます。

  • DAG、タスク インスタンス、XComs などの状態を追跡するメタデータ データベース。
  • 監視と管理のための Airflow UI を提供する Web サーバー。
  • DAG とタスク インスタンスのトリガーを担当するスケジューラ。
  • タスク インスタンスの実行を処理する Executor。
  • タスクを実行するワーカー。
  • コマンド ライン インターフェイス (CLI) などのその他のコンポーネント。

AKS 上の Apache Airflow アーキテクチャのスクリーンショット。

運用環境向けの Airflow 分散アーキテクチャ

Airflow のモジュール型の分散アーキテクチャは、運用環境のワークロードに対して以下に示すいくつかの重要な利点を提供します。

  • 関心の分離: 各コンポーネントには個別の役割があり、システムをシンプルで保守が容易な状態に保ちます。 スケジューラは DAG とタスク スケジュールを管理し、ワーカーはタスクを実行することで、各要素はそれに固有の機能に集中し続けます。
  • スケーラビリティ: このアーキテクチャは、ワークロードの増加に応じた容易なスケーリングを可能にします。 複数のスケジューラまたはワーカーを同時に実行し、ホストされたデータベースを利用して自動スケーリングを行い、需要の増加に対応できます。
  • 信頼性: コンポーネント同士は切り離されているため、1 つのスケジューラまたはワーカーの障害によってシステム全体が停止することはありません。 一元化されたメタデータ データベースにより、システム全体の一貫性と継続性が確保されます。
  • 拡張性: このアーキテクチャは柔軟であり、Executor やキュー サービスなどのコンポーネントを必要に応じてスワップ アウトしてカスタマイズすることを可能にします。

この設計により、複雑なデータ パイプラインを管理する際のスケーリング、信頼性、柔軟性のための堅牢な基盤が提供されます。

Airflow Executor

Airflow を運用可能状態にする際の非常に重要な設計上の決定は、正しい Executor を選択することです。 タスクを実行する準備ができたら、Executor がその実行を管理します。 Executor は、タスクを実行するワーカーのプールとやり取りします。 最も一般的に使用される Executor は以下のとおりです。

  • LocalExecutor: ホスト システム上でタスク インスタンスを並列に実行します。 この Executor はテストに最適ですが、大規模なワークロードではスケーラビリティが制限されます。
  • CeleryExecutor: Celery プールを使用して複数のマシンにタスクを分散し、異なるノード上でワーカーを実行することで水平方向のスケーラビリティを提供します。
  • KubernetesExecutor: この Executor は、Kubernetes 内の Airflow デプロイ用に調整されており、Kubernetes クラスター内のワーカー ポッドを動的に起動します。 優れたスケーラビリティを提供し、強力なリソース分離を実現します。

Airflow を運用環境に移行する際には、ワーカーのスケーリングが不可欠になり、KubernetesExecutor がニーズに最適になります。 ただし、ローカル テストでは、LocalExecutor が最もシンプルな選択肢です。

次のステップ

Azure Kubernetes Service (AKS) で Apache Airflow を実行するためのインフラストラクチャを作成する

共同作成者

Microsoft では、この記事を保持しています。 当初の寄稿者は次のとおりです。

  • Don High | プリンシパル カスタマー エンジニア
  • Satya Chandragiri | シニア デジタル クラウド ソリューション アーキテクト
  • Erin Schaffer |コンテンツ開発者 2