AWS Amazon MWAA の責任共有モデル

Apache Airflow のセットアップ – Amazon MWAA が Apache Airflow をセットアップします。インターネットで利用可能なのと同じ Apache Airflow ユーザーインターフェイスとオープンソースコードを使用します。詳細については、「Amazon Managed Workflows for Apache Airflow とは何ですか？」を参照してください。

マネージドコンポーネントのコンピューティング – Amazon MWAA は、環境の AWS Fargate コンピューティングをプロビジョニングして運用します。このコンピューティングは、Apache Airflow スケジューラ、ワーカー、およびウェブサーバーを実行します。Amazon MWAA は、Apache Airflow メタデータデータベースもプロビジョニングして運用します。環境ごとに、Amazon MWAA はウェブサーバーとメタデータデータベースをホストする AWS 所有の Amazon VPC を作成します。スケジューラとワーカーは、所有および設定する環境の Amazon VPC 内のプライベートサブネットに接続します。詳細については、「Amazon MWAA Migration Guide」の「Explore Amazon MWAA network architecture」を参照してください。

Apache Airflow メタデータデータベース – Amazon MWAA は、各環境の Apache Airflow メタデータデータベースをプロビジョニングして運用します。ワークフローが書き込むデータの量については、引き続きお客様の責任となります。詳細については、「管理するオペレーショナルエクセレンス」を参照してください。

バージョンイメージとパッチ適用 – Amazon MWAA は、Apache Airflow リリースを他の一般的なバイナリやPythonライブラリにバンドルするコンテナイメージを構築します。Amazon MWAA はこれらのイメージにパッチを適用します。環境の更新アクションを発行して新しいバージョンに移動するまで、環境は指定されたイメージバージョンを使用し続けます。詳細については、「Amazon MWAA のバージョンについて」を参照してください。イメージ定義は、 GitHubウェブサイトの amazon-mwaa-docker-images リポジトリで入手できます。

バージョンサポートライフサイクル – Amazon MWAA は、各 Apache Airflow バージョンの可用性とサポート終了日を公開します。Amazon MWAA は、アカウントの環境がサポート終了に近づいているバージョンを実行する Health Dashboard と、 を通じて通知します。現在のサポートのコミットメントと日付については、「」を参照してくださいEnd-of-supportバージョン。

マネージドコンポーネントの自動スケーリング – Amazon MWAA は、需要に応じてワーカーとウェブサーバーをスケーリングします。スケーリングは、設定した制限内にとどまります。環境クラス、ワーカーとウェブサーバーのスケーリング設定、スケジューラ数を選択します。詳細については、Amazon MWAA ワーカーの自動スケーリングの設定、Amazon MWAA ウェブサーバーの自動スケーリングの設定、および Amazon MWAA 環境クラスの構成 を参照してください。

データ暗号化 – Amazon MWAA は、保管中および転送中のデータを暗号化します。Amazon MWAA は、ユーザーに代わってカスタマー管理の KMS キーに必要な権限もアタッチします。詳細については、「Amazon Managed Workflows for Apache Airflow におけるデータ保護」を参照してください。

メトリクスとログ – Amazon MWAA は環境メトリクスを Amazon CloudWatch に発行します。Amazon MWAA は、有効にしたログタイプの Apache Airflow ログを CloudWatch Logs に配信します。詳細については、「Amazon MWAA でのモニタリングの概要」を参照してください。

コンプライアンスプログラム – サードパーティーの監査者は、 AWS セキュリティの有効性を定期的にテストおよび検証します。詳細については、「Amazon Managed Workflows for Apache Airflow のコンプライアンス検証」を参照してください。

DAG コード – Amazon S3 バケットのdagsフォルダにコピーする DAG 定義。これらの DAGs がアクセスする内容と実行するオペレーションは、お客様の責任となります。詳細については、「DAG の追加と更新」を参照してください。

Python 依存関係 – Amazon S3 バケットにrequirements.txtファイルをアップロードしてインストールするライブラリ。これには、ワークフローに必要なすべてのパッケージのセキュリティと互換性が含まれます。互換性のないパッケージやリソースを大量に消費するパッケージは、スケジューラとワーカーのパフォーマンスを低下させたり、コンテナの起動を妨げたりする可能性があります。詳細については、「Python 依存関係のインストール」および「requirements.txt での Python 依存関係の管理」を参照してください。

カスタムプラグイン – Amazon S3 バケットにアップロードするplugins.zipファイルの内容。アップロードする前に、ファイルの内容を確認することをお勧めします。詳細については、「カスタムプラグインのインストール」を参照してください。

起動スクリプト – 起動時に各コンポーネントで Amazon MWAA が実行するシェルスクリプト。また、スクリプトの Amazon S3 バージョン ID も指定します。詳細については、「Amazon MWAA でのスタートアップスクリプトの使用」を参照してください。

テスト — 環境にデプロイする前に、DAGs、カスタムプラグイン、Python依存関係を検証します。本番環境に適用する前に、開発環境で Apache Airflow バージョンアップグレードをテストすることをお勧めします。GitHub ウェブサイトの amazon-mwaa-docker-images コンテナイメージを使用して、ローカルで開発およびテストできます。

Amazon S3 バケットとそのコンテンツ – 環境に関連付けられたバケットのバケットポリシーとオブジェクト ACLs。Amazon MWAA は、ユーザーに代わってバケットのコンテンツをバックアップしません。DAGs、プラグイン、要件ファイルでディザスタリカバリ体制が必要な場合は、バージョニングを有効にしてクロスリージョンレプリケーションを設定することをお勧めします。また、他のオブジェクトをバケットに保存したり、バケットを別のサービスで使用したりしないことをお勧めします。

入力するデータ – 機密情報や機密情報をタグや名前フィールドなどの自由形式のフィールドに入れないことを強くお勧めします。

環境の状態のモニタリング — Amazon MWAA が環境に対して発行する CloudWatch メトリクスを確認します。これには、飽和と劣化を検出するのに役立つコンテナ、キュー、データベースメトリクスが含まれます。詳細については、「Amazon Managed Workflows for Apache Airflow のモニタリングとメトリクス」および「Amazon MWAA のコンテナ、キュー、およびデータベースメトリクス」を参照してください。

ダッシュボードとアラーム – 環境が制限に近づいたときに通知する CloudWatch ダッシュボードとアラームを作成します。詳細については、「Amazon MWAA のモニタリングダッシュボードとアラーム」を参照してください。

ログ分析 – 必要な Apache Airflow ログタイプの有効化。次に、スケジューラ、ワーカー、ウェブサーバー、タスクログを分析して、ワークフローの失敗を診断します。詳細については、「Amazon CloudWatch の Airflow ログへのアクセス」および「トラブルシューティング:CloudWatch ログ記録と CloudTrail のエラー」を参照してください。

CloudWatch サービスクォータ – アカウントの CloudWatch クォータが、環境が生成するログボリュームを処理できるようにします。などの CloudWatch Logs のクォータを超えると、ワーカーのパフォーマンスが低下するCreateLogStream可能性があります。詳細については、CloudWatch Logs のクォータ」を参照してください。

メタデータデータベースのメンテナンス — Apache Airflow メタデータデータベースを軽量に保つ。ワークフローで不要になったメタデータを定期的に削除します。無制限のメタデータデータベースは、スケジューラとウェブサーバーのパフォーマンスを低下させる可能性があります。詳細については、「Amazon MWAA 環境での Aurora PostgreSQL データベースのクリーンアップ」を参照してください。

DAG の設計とスケジュールの頻度 – DAG 数、DAG あたりのタスク数、スケジュール間隔によって、マネージドスケジューラの負荷が直接決まります。Amazon MWAA は、環境の容量を超えるワークロードをスロットリングまたは拒否しません。設定したリソースに収まるように DAGs を設計する必要があります。

タスクリソースガバナンス – タスクレベルのタイムアウト、Apache Airflow プールサイズ、DAG ごとの同時実行制限の設定。Amazon MWAA は、ユーザーに代わってタスクごとのガードレールを適用しません。これらの設定がないと、単一の長時間実行型または高同時実行型の DAG が使用可能なすべてのワーカーを消費できます。

容量とパフォーマンスのチューニング – 環境クラス、ワーカーとウェブサーバーのスケーリング制限、ワークロードに適した Apache Airflow 設定オプションを選択します。自動スケーリングは、設定した範囲内で動作し、環境の設計容量を超えるワークロードを補償しません。ワークロードプロファイルの環境クラスを適切なサイズにする必要があります。詳細については、「Amazon MWAA での Apache Airflow のパフォーマンス調整」および「Amazon MWAA 環境クラスの構成」を参照してください。

スタートアップスクリプトを通じて行う変更 – スタートアップスクリプトは、環境内のすべてのコンポーネントで実行されます。これらのコンポーネントの設定を変更できます。この方法で行った変更は、環境の安定性に対する影響を含め、お客様の責任となります。本番環境に適用する前に、スタートアップスクリプトをテストすることをお勧めします。詳細については、「Amazon MWAA でのスタートアップスクリプトの使用」を参照してください。

環境の更新 – 環境の更新を開始するのがアクションです。更新により、コンテナが再起動し、実行中のワークフローに影響する可能性があります。いつ更新するかを選択し、進行中のタスクへの影響を評価する責任があります。重要な DAGs が実行されていない場合は、選択した時間枠内に更新することをお勧めします。DAGs を一時停止および一時停止解除せずに更新するには、ワーカーがシャットダウンする前に進行中のタスクを終了できる正常な更新を検討してください。条件と制限が適用されます。詳細については、「Amazon MWAA 環境の更新」を参照してください。

第 1 レベルのトリアージ – AWS サポートを利用する前に、利用可能なメトリクスとログを使用して問題を診断します。 AWS サポートがユーザーを支援するために使用できる詳細レベルは、環境で有効にしたログ記録レベルによって異なります。

環境間のオーケストレーション – 複数の Amazon MWAA 環境間でワークフローを調整します。Apache Airflow REST API や外部センサーなどのメカニズムを使用して環境をリンクする場合、その調整ロジックはお客様の責任となります。

Amazon MWAA のベストプラクティスに従う – パフォーマンス、依存関係管理、環境設定に関する文書化されたガイダンスを適用します。詳細については、「Amazon Managed Workflows for Apache Airflow のベストプラクティス」を参照してください。

バージョンを最新の状態に保つ – Amazon MWAA バージョンを最新の状態に保つ責任があります。環境を新しい Apache Airflow バージョンにアップグレードすることは、ユーザーが開始するアクションです。詳細については、「Apache Airflow バージョンの変更」および「End-of-supportバージョン」を参照してください。

実行ロール – Amazon MWAA は、環境の作成後に既存の実行ロールに対するアクセス許可ポリシーを追加または編集することはできません。実行ロールは、環境に必要な追加のアクセス許可で更新する必要があります。詳細については、「Amazon MWAA 実行ロール」を参照してください。

IAM アクセスコントロール – 環境と Apache Airflow UI にアクセスできるユーザーを決定するポリシー。ユーザーが必要とするリソースとアクションにのみアクセス許可を付与します。詳細については、「AWS Identity and Access Management」および「Amazon MWAA 環境へのアクセス」を参照してください。

Apache Airflow ユーザー権限 – Apache Airflow はマルチテナントではありません。DAG 作成者は、Apache Airflow ユーザー権限を変更し、基盤となるメタデータデータベースとやり取りする DAGs を記述できます。DAG 書き込みアクセス権を持つ個別のチームには、個別の環境を使用することをお勧めします。詳細については、「Apache Airflow でのセキュリティのベストプラクティス」を参照してください。

Webserver アクセスモード – Apache Airflow UI へのアクセスPRIVATE_ONLYに PUBLIC_ONLYまたは を選択します。これは、ウェブサーバーエンドポイントがインターネットから到達可能かどうかを決定するセキュリティ上の決定です。詳細については、「Amazon MWAA の VPC のセキュリティ」を参照してください。

ネットワーク設定 – Amazon VPC、サブネット、セキュリティグループ、ネットワーク ACLs。これには、NAT ゲートウェイ上のトラフィックをルーティングするインバウンドルールとアウトバウンドルールが含まれます。独自の Amazon VPC エンドポイントを管理する場合は、それらのエンドポイントを作成する責任があります。詳細については、「Amazon MWAA の VPC のセキュリティ」および「Amazon MWAA での独自の Amazon VPC エンドポイントの管理」を参照してください。

暗号化キーの選択 — AWS 所有の KMS キーを使用するか、カスタマー管理の KMS キーを使用するか。カスタマーマネージド KMS キーを使用する場合は、必要なポリシーステートメントをキーにアタッチする必要があります。詳細については、「Amazon Managed Workflows for Apache Airflow におけるデータ保護」を参照してください。

シークレットと接続 — ワークフローが使用する認証情報。Secrets Manager にシークレットを保存することをお勧めします。詳細については、「AWS Secrets Manager シークレットを使用した Apache Airflow 接続の設定」を参照してください。

Apache Airflow 設定オプション – 環境で上書きする設定オプション。詳細については、「Amazon MWAA での Apache Airflow 設定オプションの使用」を参照してください。

AWS 責任共有モデル

AWS Well-Architected フレームワークにおける責任共有

Amazon Managed Workflows for Apache Airflow のベストプラクティス

Amazon MWAA での Apache Airflow のパフォーマンス調整

Amazon MWAA のモニタリングダッシュボードとアラーム

Amazon MWAA のコンテナ、キュー、およびデータベースメトリクス

Amazon MWAA のセキュリティのベストプラクティス