Amazon Web Services ブログ

Amazon MWAA v1.x から v2.x へのアップグレードのベストプラクティス

本記事は、2025 年 6 月 2 日に公開された Best practices for upgrading Amazon MWAA V1.x to V2.x を翻訳したものです。翻訳はプロフェッショナルサービスの佐藤が担当しました。

Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、データ駆動型の意思決定をする組織にとって重要な基盤となっています。複雑なデータパイプラインを管理するためのスケーラブルなソリューションとして、Amazon MWAA は AWS サービスとオンプレミスのシステム間でシームレスなオーケストレーションを実現します。AWS がインフラストラクチャを管理していますが、お客様は責任共有モデルに従って Amazon MWAA 環境の更新を慎重に計画し実行する必要があります。最新の Amazon MWAA バージョンへのアップグレードにより、重要なセキュリティパッチを通じたセキュリティの強化や、DAG の解析の高速化とデータベース負荷軽減による性能の向上など、大きなメリットが得られます。また、エコシステムの互換性を維持しながら高度な機能を使用でき、AWS からの優先的なサポートを受けることができます。アップグレードを成功させるカギは、適切なソリューションを選択し、体系的な実装アプローチに従うことにあります。

この記事では、Amazon MWAA 環境のアップグレードのベストプラクティスを紹介し、最新バージョンへのシームレスな移行のためのステップバイステップガイドを提供します。

ソリューションの概要

Amazon MWAA は 2 つの主要なアップグレードソリューションを提供します。

  • インプレースアップグレード – この方法は、計画的なシステム停止時間が認められる場合に最適です。既存のインフラストラクチャに直接新しいバージョンをデプロイします。Amazon MWAA では、Apache Airflow バージョン 2.x 以降を実行している環境でインプレースアップグレードがサポートされています。バージョン 1.10.z 以前を実行している場合、これらのバージョンではインプレースアップグレードをサポートしていないため、新しい環境を作成してリソースを移行する必要があります。
  • カットオーバーアップグレード – この方法は、稼働中のシステムへの影響を最小限に抑えるのに役立ちます。対象のバージョンで新しい Amazon MWAA 環境を作成し、古い環境から新しい環境に移行します。

各ソリューションは、データの整合性とシステムの信頼性を維持しながらアップグレードを支援する、異なるアプローチを提供します。

インプレースアップグレード

インプレースアップグレードは、アップグレードプロセスのためのメンテナンスウィンドウをスケジュールできる環境に適しています。このウィンドウ中、Amazon MWAA はワークフローの履歴を保持します。この方法は、計画的なシステム停止時間が認められる場合に最適です。これにより、履歴データが維持され、わかりやすいアップグレードプロセスが提供されます。また、この方法には、プロビジョニング中に問題が発生した場合のロールバック機能も含まれています。また、新しい環境を作成する必要がないため、リソースの使用も少なくて済みます。

AWS マネージメントコンソールで、1 回の操作でインプレースアップグレードを実行できます。このプロセスでは、多くのアップグレード手順を代わりに実行してくれるため、運用の手間を削減できます。

アップグレードプロセス中は、新しいタスクのスケジュールや実行はできません。Amazon MWAA はアップグレードプロセスを自動的に制御し、安全性を確保するための仕組みを組み込んでいます。プロビジョニングフェーズで問題が発生した場合、サービスは以前の安定バージョンへの復元を試みます。

インプレースアップグレードを開始する前に、DAG の互換性の問題がアップグレードプロセスに影響を与える可能性があるため、ターゲットバージョンとの DAG の互換性をテストすることをお勧めします。アップグレードを開始する前に、Amazon MWAA ローカルランナー (注) を使用して DAG の互換性をテストできます。アップグレードは、コンソールで新しいバージョンを指定するか、AWS Command Line Interface (AWS CLI) を使用して開始できます。以下は、AWS CLI を使用した Amazon MWAA アップグレードコマンドの例です：

aws mwaa update-environment --name <value> --airflow-version <value>

注: Apache Airflow バージョン 2.9 以降では、Amazon MWAA の本番環境で使用されている Docker イメージがオープンソース化されています。MWAAと同一の環境でテストを行う場合は、 aws-mwaa-docker-images の使用を推奨します。ただし、MWAA ローカルランナーも引き続き、 MWAA でサポートされているすべての Apache Airflow バージョンでテストやパッケージング要件の確認に使用することができます。

次の図は、Amazon MWAA のインプレースアップグレードのワークフローと状態を示しています。

詳細については、Amazon MWAA でのインプレースバージョンアップグレードの紹介をご参照ください。

カットオーバーアップグレード

カットオーバーアップグレードは、ダウンタイムを最小限に抑える必要がある場合の代替ソリューションを提供しますが、より多くの手動ステップと運用計画が必要です。このアプローチでは、新しい Amazon MWAA 環境を作成し、メタデータを移行し、環境間の移行を管理します。この方法は、アップグレードプロセスをより柔軟に管理できますが、インプレースアップグレードと比較して、より多くの計画と実行の労力が必要になります。

この方法は、複雑なワークフローを持つ環境で効果的に機能します。特にバージョンアップグレードと共に大きな変更を計画している場合に適しています。このアプローチにはいくつかの利点があります。本番環境のダウンタイムを最小限に抑え、環境を切り替える前に包括的なテストを実施し、必要に応じて元の環境に戻すことができます。また、移行中に設定を確認して更新することもできます。

カットオーバーアプローチについて、以下の点を考慮してください。2 つの環境を同時に実行する場合、両方の環境の料金が発生します。各 Amazon MWAA 環境の料金は、以下の要素に依存します：

  • 環境の稼働時間 (秒単位の精度で 1 時間ごとに課金)
  • 環境サイズ
  • ワーカーの自動スケーリング容量
  • スケジューラー容量

AWS は、自動スケーリングされた追加のワーカーのコストを個別に計算します。AWS Pricing Calculator を使用して、特定の構成のコストを見積もることができます。

既存環境と新しい環境を並行して稼働させる際のデータの重複や破損を防ぐため、べき等な DAG の実装を推奨します。Airflow スケジューラは、新しい環境で一部のメタデータテーブル (dag、dag_tag、dag_code) を自動的に設定します。ただし、以下の追加のメタデータコンポーネントの移行を計画する必要があります：

  • DAG 実行履歴
  • Variables (変数)
  • Slot pool の設定
  • SLA 違反の記録
  • XCom データ
  • ジョブ記録
  • ログテーブル

ダウンタイムを最小限に抑えることを優先し、追加の運用上の複雑性に対応できる場合は、このアプローチを選択できます。

カットオーバーアップグレードプロセスは、新しい環境の作成、新しい環境への移行、アップグレードの実行という 3 つの主要なステップで構成されています。以下の図は、全体のワークフローを示しています。

以下のセクションでは、カットオーバーアップグレードを実行するための主要なステップについて説明します。

前提条件

アップグレードプロセスを開始する前に、以下の手順を実行してください：

新しい環境の作成

新しい環境を作成するには、以下の手順を実行してください。

  • AWS CLI を使用して、新しい環境設定のテンプレートを生成します：

aws mwaa create-environment --generate-cli-skeleton > <new-env-name>.json

  • 生成された JSON ファイルを変更します：
    • バックアップファイル <env-name>.json から <new-env-name>.json に設定をコピーします。
    • 環境名を更新します。
    • 既存の環境から AirflowVersion パラメータの値を維持します。
    • 必要に応じて他の設定パラメータを確認し更新します。
  • 新しい環境を作成します:

aws mwaa create-environment --cli-input-json <content of new-env-name.json>

新しい環境への移行

元の環境を新しい環境に移行するには、以下の手順を実行してください：

  • mwaa-dr PyPI パッケージを使用して、リストア DAG を作成し実行します。
  • このプロセスでは、S3 バックアップバケットからメタデータを新しい環境にコピーします。
  • 新しい環境に、元の環境から期待されるメタデータが含まれていることを確認します。

アップグレードの実行

バージョンアップグレードを実行するには、以下の手順を実施してください。

  • 環境をアップグレードします:

aws mwaa update-environment --name <new-env-name> --airflow-version <target-version>

  • アップグレードのモニタリングをします:
    • コンソールで環境のステータスを追跡します。
    • エラーメッセージや警告がないかモニタリングします。
    • 環境が AVAILABLE に到達することを確認します。

移行のタイミングは慎重に計画してください。アップグレードの最中に元の環境でワークフローを動かし続けると、新旧の環境でワークフローの情報 (メタデータ) が食い違ってしまう恐れがあります。

クリーンアップ

モニタリングを通じてアップグレードされた環境の安定性を確認した後、クリーンアップ作業を開始できます:

  • AWS CLI コマンドを使用して、元の Amazon MWAA 環境を削除します:

aws mwaa delete-environment --name <old-env-name>

  • S3 バケットから未使用のバックアップデータを削除し、アップグレード用に作成した一時的な AWS Identity and Access Management (IAM) ロールとポリシーを削除し、DNS やルーティング設定を更新することで、関連リソースをクリーンアップします。

リソースを削除する前に、組織のバックアップ保持ポリシーに従い、コンプライアンス要件に必要なバックアップデータを維持し、アップグレード中に行った設定変更をドキュメント化してください。

このアプローチにより、テストの機会を確保しながら、必要に応じて元の環境に戻ることができる、制御されたアップグレードを実行できます。

モニタリングと検証

Amazon CloudWatch メトリクスを使用して、DAG 処理メトリクスとスケジューラーのハートビートに焦点を当てながら、アップグレードの進行状況を追跡できます。環境は、アップグレードプロセス中に UPDATING や CREATING などのいくつかの状態に移行します。環境が AVAILABLE 状態になったら、検証を開始できます。システムのアクセス性の確認、重要なワークフローの操作のテスト、外部接続の検証を行うことをお勧めします。詳細なモニタリングのガイドについては、Amazon Managed Workflows for Apache Airflow のモニタリングとメトリクス をご参照ください。

主な考慮事項

インフラストラクチャ・アズ・コード (IaC) のプラクティスを活用して、環境管理の一貫性と再現可能なデプロイメントをサポートすることを検討してください。データを保護するため、mwaa-dr を使用してアクティビティの少ない時間帯にメタデータのバックアップをスケジュールしてください。ワークフローを設計する際は、潜在的な中断に対処するためにべき等性のあるパイプラインを実装し、設定と依存関係のドキュメントを維持してください。

まとめ

Amazon MWAA の効果的なアップグレードは、運用要件に合ったアプローチを選択することから始まります。インプレースアップグレードまたはカットオーバーアップグレードのいずれを選択する場合でも、入念な準備とテストにより、制御された移行を実現できます。利用可能なツール、モニタリング機能、推奨プラクティスを活用することで、ワークフローの運用を維持しながら、最新の Amazon MWAA 機能へのアップグレードを実現できます。

Amazon MWAA の詳細とコード例については、Amazon MWAA ユーザーガイドと Amazon MWAA サンプルの GitHub リポジトリを参照してください。

Apache、Apache Airflow、および Airflow は、米国および/またはその他の国における Apache Software Foundation の登録商標または商標です。

著者について

Anurag Srivastava は、Amazon Web Services (AWS) のシニアビッグデータクラウドエンジニアとして、Amazon MWAA を専門に担当しています。 AWS 上でスケーラブルなデータパイプラインとワークフロー自動化ソリューションの構築に関して、お客様を支援することに熱心に取り組んでいます。

Sriharsh Adari は、Amazon Web Services (AWS) のシニアソリューションアーキテクトとして、ビジネス成果を起点として、AWS 上で革新的なソリューションを開発するお客様を支援しています。 長年にわたり、様々な業界のお客様のデータプラットフォーム変革を支援してきました。 テクノロジー戦略、データ分析、データサイエンスが主な専門分野です。 余暇にはスポーツを楽しみ、テレビ番組を一気見したり、タブラを演奏したりしています。

Venu Thangalapally は、シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データとアナリティクス、コンテナ、アプリケーションのモダナイゼーションに関する深い専門知識を持っています。 金融サービス業界のお客様と協力して、ビジネス目標を、測定可能な価値を提供する安全でスケーラブルかつコンプライアンスに準拠したクラウドソリューションに変換しています。 Venu は、テクノロジーを活用してイノベーションと運用効率の向上を推進することに情熱を注いでいます。 仕事以外では、家族と過ごすこと、読書、長距離散歩を楽しんでいます。

Chandan Rupakheti は AWS のシニアソリューションアーキテクトです。 AWS では、アナリティクス、サーバーレス、AdTech サービスが重なり合う領域を主な専門としています。 情熱的な技術リーダー、研究者、メンターとして、クラウドにおける革新的なソリューションの構築に長けています。 プライベートでは、家族や友人と過ごすことや、音楽を聴いたり演奏したりすることを楽しんでいます。