AWS Data Pipeline 移行ガイド｜Glue/SF/MWAA選定

1. この記事について

1-1. 本記事のゴール

本記事を読み終えると、AWS Data Pipelineの現況(新規受付終了・メンテナンスモード)を正確に理解したうえで、自社のワークロード特性に応じてGlue・Step Functions・MWAAのいずれへ移行すべきかを、公式の移行推奨に沿って判断できるようになります。

読了後にできること:

• Data Pipelineが新規受付終了・メンテナンスモードである根拠を、公式一次情報から説明できる
• 定期バッチ・Spark ETLが中心のワークロードはGlueへ、複数AWSサービスのオーケストレーションが中心のワークロードはStep Functionsへ、Airflow資産・Python DAGが中心のワークロードはMWAAへ、という選定ロジックを理解できる
• Data Pipelineの主要概念(Pipeline定義・Activity・DataNode・Precondition等)が、移行先の何に対応するかを概念マッピング表で把握できる
• 移行時に起きやすい詰まりポイント・アンチパターンを事前に回避できる

本記事の構成:

各章は移行先ごとに独立して参照できるよう構成しています。自社ワークロードの移行先がまだ決まっていない場合は§2から、すでに移行先が決まっている場合は該当する§3〜§5から読み進めることをおすすめします。

本記事の前提知識:

本記事は、以下の知識を前提として解説します。いずれも既存記事(1-2参照)で詳しく扱っているため、不安がある場合は先にそちらを確認することをおすすめします。

• AWS IAM(ロール・ポリシー)の基本的な設定方法
• Glue・Step Functions・MWAAのいずれかについて、コンソールから最小構成のジョブ・ステートマシン・DAGを作成した経験
• Data Pipelineでの現在のワークロードの内容(Activity・DataNode・Preconditionの構成)を把握していること

上記の前提知識がまだ十分でない場合も、§2の内容自体は前提知識なしで読み進められる構成にしています。実際の移行手順(§3〜§5)へ着手する前に、必要に応じて既存記事で基礎を補ってください。

1-2. 読者像

想定する読者は、大きく2タイプです。

既存Data Pipeline運用者が本記事で解決したい典型的な悩み:

• 新規受付終了・メンテナンスモードという状態が、既存パイプラインの運用継続にどう影響するのか正確に理解したい
• 3つの移行先候補のうち、自社のワークロードにはどれが最適なのか判断基準がない
• Data Pipeline特有の概念(Activity/DataNode/Precondition等)が、移行先でどう表現されるのか対応関係が分からない

新規ワークフロー構築の検討者が本記事で解決したい典型的な悩み:

• 定期バッチ処理の基盤として何を選定候補に入れるべきか、Data Pipelineは選定対象から外すべきなのか判断したい
• Glue・Step Functions・MWAAという候補それぞれの向き不向きを、実装に踏み込んで比較したい

いずれの読者も、移行先であるGlue・Step Functions・MWAAそのものの基礎的な使い方(ジョブ作成・ステートマシン設計・DAG運用の基本操作)は既知、またはこの後で紹介する既存記事を読むことを前提とし、本記事は「Data Pipelineからの移行」という論点に絞って解説します。

本記事が想定していない読者(既存記事が適しています):

• Glueによるデータ統合・ETLの基礎そのものを学びたい方
• Step Functionsのステートマシン設計・オーケストレーションの基礎そのものを学びたい方
• MWAAの構築・DAG運用の基礎そのものを学びたい方

移行先各サービスの基礎運用は、Glueは既存記事「AWS Analytics/Data Lake本番運用 Vol1」、Step Functions・MWAAは既存記事「AWS Application Integration本番運用 Vol2」で扱っています。本記事ではこれらの基礎運用そのものは再解説せず、Data Pipelineからの選定・移行手順・概念マッピングに集中します。

自組織がどちらの読者タイプに近いか判断する目安:

すでにData Pipelineでワークロードを運用している場合は「既存Data Pipeline運用者」、これから定期実行の基盤を新規に選定する場合は「新規ワークフロー構築の検討者」に該当します。どちらの読者タイプであっても、§2で扱うData Pipelineの現況と移行先3サービスの選定軸は共通して役立つ内容です。

1-3. なぜ今これを書くか

AWS Data Pipelineは、公式ドキュメント(datapipeline what-is/migration、取得日2026-07-18)において「AWS Data Pipeline is no longer available to new customers」かつ「AWS Data Pipeline service is in maintenance mode and no new features or region expansions are planned」と明記されています。既存顧客は引き続き通常どおり利用できますが、新機能追加やリージョン拡張は予定されていません。

AWS Data Pipelineの現況(取得日2026-07-18):

この状態は、今すぐ既存パイプラインが停止するという意味ではありません。しかし新機能追加が見込めない以上、長期運用を前提とするワークロードは移行計画を早期に立てておくことが望ましい状況です。AWS公式の移行ガイドは、用途別の分岐と概念マッピング表を提供していますが、日本語で3つの移行先を横断的に整理した実装記事はまだ手薄です。

移行の検討を先送りした場合に起きやすいこと:

• 「まだ動いているから」と先送りするうちに、移行先の選定基準を整理する余裕がなくなる
• 移行先を決めた後になって、Data Pipeline特有の概念(Precondition等)が移行先にそのまま存在せず、設計をやり直すことになる
• 3つの移行先を横並びで比較しないまま1つに決めてしまい、後から他の候補の方が適していたと気づく

これらはいずれも、移行先の選定基準と概念マッピングを事前に押さえておけば避けられる問題です。本記事では§2〜§6でこれらを順に解消していきます。

本記事の差別化ポイント:

AWS公式の移行ガイドは英語中心で、用途別の分岐と概念マッピング表を提供していますが、日本語で3つの移行先を横断的に整理した実装記事は手薄です。本記事は以下の3点で差別化を図ります。

• 日本語ネイティブで、Data Pipelineからの移行という論点に絞った体系的な解説
• Glue・Step Functions・MWAAという3つの移行先を、用途別に分岐させる選定ロジック(公式の移行推奨に準拠)
• 概念マッピング表・移行手順・アンチパターンまでを含めた、実装に踏み込んだ内容

なお、移行先であるGlue・Step Functions・MWAAの基礎的な使い方は既存記事に委譲し、本記事では「Data Pipelineからの移行」という論点に集中します。移行先サービスの基本操作にまだ不慣れな場合は、先に該当する既存記事で基礎を押さえたうえで本記事に戻ることをおすすめします。

本記事は、Data Pipelineの現況把握(§2)から移行先ごとの実行手順(§3〜§5)、そして概念マッピングとチェックリストによる仕上げ(§6)まで、一連の流れで移行を完走できるように構成しています。途中の章から読み始めても内容が理解できるよう、各章の冒頭で前提となる情報を簡潔に振り返ります。

移行先サービスの本番運用を先に押さえたい方はこちら

2. 前提・移行元の現況・移行判断の枠組み

2-1. AWS Data Pipelineの現況(取得日2026-07-18)

AWS Data Pipelineは、公式ドキュメント(datapipeline what-is/migration、取得日2026-07-18)において以下のように明記されています。

AWS Data Pipeline is no longer available to new customers. Existing customers can continue to use the service as normal.

AWS Data Pipeline service is in maintenance mode and no new features or region expansions are planned.

この2つの記述から、以下の3点が確認できます(取得日2026-07-18時点、公式一次情報)。

1. 新規顧客への提供は終了している。これから新規にData Pipelineを使い始めることはできません。
2. 既存顧客は通常どおり利用を継続できる。今すぐ既存パイプラインの実行が止まるわけではありません。
3. 新機能追加・リージョン拡張の予定はない(メンテナンスモード)。今後、機能面で拡充されることは見込めません。

よくある誤解と正しい理解:

既存パイプラインが動いているからといって移行を先送りし続けると、新機能が見込めないサービスに長期運用ワークロードを預け続けることになります。この状態を正確に理解したうえで、次の2-2・2-3で移行先の選定に進みます。

出典: AWS Data Pipelineの概要ページ、およびAWS公式移行ガイド(migration.html)(取得日2026-07-18)。両ページとも本記事執筆時点で内容の変化はありません。

「既存顧客は通常どおり利用を継続できる」という記述の実務上の意味も、あわせて確認しておきます。ここでいう「通常どおり」とは、既存のPipeline定義がそのまま実行され続け、スケジュール実行・データ処理も従来どおり動作するという意味です。一方で、メンテナンスモードである以上、以下のような点は見込めません。

• 新しいActivityタイプやDataNodeタイプの追加
• 新しいAWSリージョンへのサービス展開
• コンソールUIやAPIの機能拡充

つまり「壊れて動かなくなる」リスクではなく、「機能面で取り残される」リスクが本質です。既存ワークロードがシンプルで安定稼働している場合、当面の運用継続自体に支障はありません。しかし新しいデータソースへの対応や、他のAWSサービスとの新しい連携が必要になった時点で、Data Pipeline側での対応は期待できないため、その時点で初めて移行を検討するのでは後手に回りやすい、という点が実務上の要点です。

よくある質問:

• Q. 猶予期間中は移行を急がなくてよいか? A. 緊急性は運用要件次第ですが、様子見の期間として使うのはおすすめできません。新機能追加が見込めない以上、猶予期間は「移行先の選定・計画・実行を進めるための時間」として使うのが実務的です。
• Q. 一部のPipelineだけ移行を後回しにできるか? A. 技術的には可能です。ただし新規受付終了・メンテナンスモードという状態は全Pipelineに共通するため、後回しにしたPipelineも遅かれ早かれ移行が必要になります。優先度をつける場合も、全Pipelineの移行完了時期をまず見積もっておくことをおすすめします。
• Q. 移行先は必ず1つに決めなければならないか? A. いいえ。2-3で扱うとおり、ワークロードの特性によっては複数の移行先を併用する構成も選択肢になります。
• Q. 移行を後回しにしても実務上気づきにくいのではないか? A. 機能面の停止は静かに進むため、移行を先送りしても直後に不具合として顕在化するとは限りません。しかし新しいデータソースへの対応や他サービスとの新連携が必要になったタイミングで初めて制約に気づくと、その時点から移行計画を立て始めることになり、対応が後手に回ります。棚卸しと判断だけでも早めに済ませておくことをおすすめします。

§2-1で押さえておくべきポイントのまとめ:

• 新規受付終了・メンテナンスモードだが、既存顧客は通常どおり利用継続できる(即時停止ではない)
• 新機能追加・リージョン拡張は予定されていない(機能面で今後拡充される見込みはない)
• 出典はAWS公式移行ガイドを含む公式ドキュメント(取得日2026-07-18)

この正確な理解を関係者間で共有したら、次は移行先3サービスの概観を確認します。

社内展開時のポイント:

社内の関係者にこの状況を説明する際は、「サービスが終了する」という表現よりも「新規受付終了・メンテナンスモードにより、既存運用は継続できるが機能拡充は見込めない状態」という表現の方が正確です。「終了」という言葉だけが独り歩きすると、既存パイプラインの緊急停止を連想させ、必要以上に慌てた対応を招きかねません。逆に「まだ動いているから大丈夫」という理解のまま止まってしまうと、機能面の制約に気づかないまま長期運用を続けてしまいます。この2つの誤解の中間にある正確な状態を共有することが、移行計画をスムーズに進めるための第一歩です。

2-2. 移行先3サービスの概観

AWS公式の移行ガイド(migration.html)は、Data Pipelineのワークロード特性に応じて、Glue・Step Functions・MWAAの3つの移行先を案内しています。それぞれの特徴を整理します。

3サービスとも東京リージョンで提供されており、EOLの兆候はありません(取得日2026-07-18)。Data PipelineのPipelineが担っていた「定期実行・依存関係管理・複数ステップの連携」という役割は、この3サービスのいずれかに引き継がれることになりますが、どれが最適かはワークロードの性質によって変わります。

AWS Glueは、Sparkを実行基盤とするサーバーレスデータ統合サービスです。データカタログによるスキーマ管理と、ビジュアルETL(Glue Studio)による処理フロー設計が中核機能で、70以上のデータソースへのコネクタを備えています。Data Pipelineで組んでいた「RDSからS3への定期エクスポート」「DynamoDBのバックアップ」のようなSpark寄りのETL処理は、Glueの得意領域と重なります。課金はジョブ実行時間(DPU時間)に応じた従量課金です。

AWS Step Functionsは、AWSサービス間の連携を状態遷移として記述するサーバーレスオーケストレーションサービスです。ASL(Amazon States Language、JSON形式)でワークフローを定義し、Lambda・ECS・SNS/SQS・EMRなど250以上のAWSサービスをネイティブに統合できます。Data Pipelineが担っていた「複数のAWSリソースを順序立てて呼び出す」役割は、Step Functionsのステートマシンにそのまま対応します。課金はタスク単位(状態遷移数)の従量課金です。

Amazon MWAAは、Apache Airflowをマネージドで提供するサービスです。Python DAGでワークフローを記述し、800以上のオペレーター(Airflowプロバイダー経由)を利用できます。すでにAirflow資産を持つチームや、複雑な依存関係・条件分岐をコードで柔軟に表現したいチームに向いています。課金は環境の稼働時間に応じた従量課金です。

移行に伴う概念的な役割の変化(詳細な対応表は§6):

Data Pipelineの「Pipeline定義」が担っていた役割は、移行先ごとに異なる形で引き継がれます。ここでは全体像として、役割がどの単位に対応するかを大まかに押さえておきます。

この対応関係はあくまで概念レベルの大枠であり、実際のAPI・設定項目レベルでの詳細なマッピングと移行手順は、移行先ごとに§3〜§5で個別に扱います。ここでは「Data Pipelineの各概念が、移行先では何にあたるのか」という見取り図を先に持っておくことで、2-3の判断軸を検討する際の材料にしてください。

上記の表を補足すると、Pipeline全体の定義という単位は、Glueでは複数Jobを束ねるWorkflowという単位に、Step Functionsでは1つのステートマシンという単位に、MWAAでは1つのDAGファイルという単位に、それぞれ引き継がれます。この「1つのPipelineが、移行先では何個の単位に分割されるか」という粒度の違いは、移行設計の初期段階で見落としやすい点です。

個々の処理単位であるActivityも、移行先によって粒度の考え方が変わります。GlueのJobは比較的大きな処理単位(1つのSparkジョブ全体)を指すのに対し、Step FunctionsのStateはより細かい単位(1回のLambda呼び出し・1つのAPI呼び出し等)を指すことが多く、MWAAのTaskはOperatorひとつに対応する単位です。Data PipelineでActivityを細かく分割していた場合、Glueへ移行する際にはそれらを1つのJobに集約するか、複数Jobに分けるかの設計判断が必要になります。

DataNode(データの入出力先)についても、Glueではデータカタログのテーブル・接続情報として管理され、Step FunctionsではState自体の入出力パラメータとして直接記述され、MWAAではConnection・Hookという設定オブジェクトとして管理されます。この違いにより、Data Pipeline側で暗黙的に定義していたデータの入出力先を、移行先では明示的に登録し直す作業が必要になります。

Precondition(実行条件)は、Data Pipelineでは「S3にファイルが存在するまで待つ」「DynamoDBテーブルにデータがあるまで待つ」といった形で使われていましたが、Glueではトリガー条件として、Step FunctionsではChoice状態による分岐として、MWAAではセンサー(Sensor)または条件分岐演算子として、それぞれ別の仕組みで表現し直す必要があります。

なお、Glueの基礎的なジョブ作成・データカタログ運用、Step Functions・MWAAの基礎的なステートマシン設計・DAG運用については、既存記事(1-2参照)で解説済みのため、本記事では移行の文脈に必要な範囲のみに触れ、基礎運用そのものは再解説しません。

2-3. 移行先選定の判断軸

3つの移行先のどれを選ぶべきかは、現在Data Pipelineで運用しているワークロードの特性によって決まります。以下の判断フローに沿って、自社ワークロードの特性を確認してください。

移行先選定の判断フロー:

判断にあたっては、以下の観点も分岐要素として確認してください。

• オンプレサーバーとの連携要否: Data PipelineにはTaskRunnerを介したオンプレミス連携機能がありました。この要件が残っている場合、MWAAのカスタムオペレーターやStep FunctionsのAPI連携で代替可能かを個別に確認する必要があります。
• Hadoop/EMRエコシステムへの依存度: EMRジョブの起動・監視が中心の場合、Glue(Spark基盤)またはStep Functions(EMRステップ制御)のどちらで置き換えるかは、既存のSparkジョブ資産の再利用しやすさで判断します。
• 既存のワークフロー記述言語: Data Pipelineの独自JSON定義をそのまま移行しやすいのはStep Functions(ASLも同じくJSON形式)ですが、複雑な依存関係や条件分岐を多用している場合はMWAAのPython DAGの方が表現力で上回ることがあります。

典型的な判断シナリオ:

具体的なワークロード例に沿って、判断の流れを確認します。

• シナリオA(定型バッチETL): 毎晩RDSのスナップショットをS3にエクスポートし、Sparkで整形してデータレイクに格納する処理をData Pipelineで組んでいる場合。処理の中心がSpark ETLであるため、Glueへの移行が第一候補です。既存のSparkスクリプト資産があれば、Glue Studio・Glueジョブへの移植コストは比較的小さく抑えられます。
• シナリオB(複数サービス連携): Lambdaでの前処理→EMRジョブの起動→処理完了後にSNS通知、という複数AWSサービスを順序立てて呼び出すワークフローをData Pipelineで組んでいる場合。処理の中心がオーケストレーションであるため、Step Functionsへの移行が第一候補です。EMRステップの起動・監視もStep Functionsから直接制御できます。
• シナリオC(Airflow資産の移植): オンプレミスまたは自前運用のAirflowで組んでいたDAGを、部分的にData Pipelineへ移してきた経緯があり、Python DAGとしての資産・運用ノウハウがすでに社内に蓄積されている場合。MWAAへの移行が第一候補です。既存のDAGコード・カスタムオペレーターの多くをそのまま持ち込めます。

これらの判断軸を組み合わせても移行先が1つに絞りきれない場合、複数の移行先を併用する構成(例: Spark ETL部分はGlue、全体のオーケストレーションはStep Functions)も選択肢になります。実際には単一のワークロードの中に複数の特性が混在するケースも多く、その場合は工程ごとに最適な移行先を割り当てる設計が現実的です。

自社のPipeline棚卸し手順:

判断軸を検討する前に、まず自社で運用中のPipelineを漏れなく洗い出しておく必要があります。Data Pipelineコンソールの一覧画面、またはAWS CLIのaws datapipeline list-pipelinesで全Pipeline IDを取得し、各Pipelineについてaws datapipeline describe-pipelinesまたはget-pipeline-definitionでActivity・DataNode・Preconditionの構成を確認します。この棚卸しを通じて、各Pipelineが「Spark ETL中心」「オーケストレーション中心」「Airflow資産の移植」のどれに該当するかを分類し、2-3の判断フローに当てはめてください。

棚卸しの際は、以下の観点も併せて記録しておくと、後続の移行手順(§3〜§5)での見積もりがしやすくなります。

• 各Pipelineの実行頻度(日次・週次・イベント駆動等)
• 各Activityで実行しているスクリプト・コマンドの種類(Shell/Spark/Hive/EMRステップ等)
• 各DataNodeが参照しているデータストア(S3/DynamoDB/RDS/Redshift等)
• Preconditionで待ち受けている条件の種類

この棚卸し結果は、そのまま2-3のセルフチェックリストの回答材料になります。

判断のためのセルフチェックリスト:

移行工数の目安(既存資産の有無による違い):

移行先を決めたあと、実際にどの程度の工数がかかるかは、既存資産の有無によって大きく変わります。目安として、3つの移行先それぞれについて工数が変動する要因を整理します。

工数の目安を把握しておくことで、移行先選定と同時に大まかなスケジュール感を関係者と共有しやすくなります。正確な工数見積もりは、実際の移行手順(§3〜§5)を確認したうえで行うことをおすすめします。

判断に迷う場合のフォールバック:

上記の判断軸・チェックリスト・工数目安を確認してもなお1つに絞りきれない場合は、以下の優先順位で検討することをおすすめします。

1. 既存資産の再利用しやすさを最優先する: 新しい技術を学習するコストより、既存のSparkスクリプト・DAG資産をそのまま活かせるかどうかを優先します。
2. 将来の拡張方向性で決める: 今後AWSサービス間の連携を増やしていく計画があるならStep Functions、データ処理・分析基盤を強化していく計画があるならGlue、Airflowエコシステムへの投資を続ける計画があるならMWAA、というように中期的な方向性で判断します。
3. 小規模な検証から始める: 判断がつかない場合、最も影響の小さいPipeline 1つを選び、候補の移行先で試験的に移行してみたうえで、残りのPipelineの移行先を決める進め方も有効です。

チームのスキルセットも判断軸に加える:

技術的な適合度だけでなく、実際に移行後の運用を担うチームのスキルセットも判断軸として重要です。Sparkの知見が豊富なデータエンジニアリングチームであればGlueへの移行後もスムーズに運用できますが、Sparkに不慣れなチームがGlueを選ぶ場合は、移行後の学習コストを見込んでおく必要があります。同様に、Step Functionsの運用にはAWSサービス全般への理解が、MWAAの運用にはPython・Airflowの知見が求められます。技術的な適合度とチームのスキルセットが一致しない場合、移行先を変更するか、移行後の学習期間を計画に織り込むかのいずれかを検討してください。

§2のまとめ:

ここまでで、Data Pipelineの現況(新規受付終了・メンテナンスモード)、移行先3サービスの概観、そして移行先を選ぶための判断軸を整理しました。

自社ワークロードの特性がどの移行先に近いか判断できたら、該当する§3(Glue)・§4(Step Functions)・§5(MWAA)へ進んでください。§6では、ここで整理した概念対応の詳細版と、移行後の検証項目・チェックリストをまとめて確認できます。

3. 移行先別ガイド① — AWS Glue への移行

§2-3の判断フローで「Spark ETL・定型テンプレートが中心」と判断した場合、移行先の第一候補はAWS Glueです。本章では、Glueへの移行が適するワークロードの見極め方から、Data Pipeline概念とGlue概念の対応、移行手順の概略、詰まりやすいポイントまでを順に解説します。Glue自体のジョブ作成・データカタログ運用の基礎的な使い方は、既存記事「AWS Analytics/Data Lake本番運用 Vol1」で解説済みのため、本章では再解説せず、移行に必要な範囲だけを扱います。

3-1. どのようなワークロードがGlue適合か

Glueが適合するかどうかは、処理の中心がSparkベースのデータ変換にあるかどうかで判断します。

判断の目安は「処理の主目的がデータの変換・統合(ETL)かどうか」です。Data PipelineでHiveActivity・EmrActivityを多用していたり、ShellCommandActivity内でSparkジョブを起動していた場合は、Glue適合度が高いワークロードです。

3-2. 概念マッピング: Data Pipeline → Glue

§2-2で整理した大枠の対応を、Glueへの移行に必要な粒度までもう一段掘り下げます。

Data Pipelineで単一のActivityが担っていた処理は、Glueでは「Crawlerでスキーマ検出」「Jobでデータ変換」という2段階に分けて設計し直すケースが多くあります。この点は移行時に見落としやすいポイントです。

3-3. 移行手順の全体像

① データソースの棚卸しとカタログ登録

§2-3の棚卸し手順で洗い出したPipelineのDataNodeについて、参照先のS3バケット・RDSテーブル等をGlue Crawlerでスキーマ検出し、データカタログに登録します。Crawlerは登録済みのデータソースを定期的に再クロールしてスキーマ変更を検出できますが、実行頻度を上げすぎるとクロール自体のコストが積み上がるため、データソースのスキーマ変更頻度に応じた実行間隔を設定します。

② Jobへの変換

HiveActivity・EmrActivityでSpark/Hive処理を実行していた場合、既存のスクリプト資産をGlue ETL Job(Spark実行環境)にそのまま近い形で移植できます。一方、ShellCommandActivityで単純なシェルコマンドやPythonスクリプトを実行していた場合は、Python Shell Jobへの移行を検討しますが、EC2インスタンス上に個別インストールしていたツール・ライブラリへの依存がある場合は、Glueの実行環境で同等のライブラリが利用できるか事前に確認が必要です。

③ Workflowでのオーケストレーション化

Data PipelineのActivity間の依存関係(dependsOn)は、GlueではWorkflowのトリガーとして表現し直します。前段Jobの成功をトリガーに次のJobを起動する「Job成功時トリガー」を連鎖させることで、Pipelineが持っていた依存関係のグラフをWorkflow上に再現できます。

④・⑤ 並行稼働検証と切替

移行の最終段階では、Data Pipeline側を稼働させたままGlue側でも同じ処理を並行実行し、出力データの件数・内容が一致することを確認してから切り替えます。いきなり切り替えて問題が発生すると切り戻しのコストが大きいため、少なくとも数回分の実行サイクルを並行稼働させて検証することをおすすめします。

3-4. 詰まりポイント/アンチパターン

Glueへの移行時に実際につまずきやすいポイントを、アンチパターンとして整理します。

これらのアンチパターンは、いずれもData Pipeline側の設計をそのままGlueに持ち込もうとした際に発生しやすいものです。Glueの実行モデル(Job/Crawler/Workflowという単位の違い)を踏まえて設計し直すことが、移行を円滑に進める鍵になります。

4. 移行先別ガイド② — AWS Step Functions への移行

§2-3の判断フローで「複数のAWSサービスを跨ぐオーケストレーションが中心」と判断した場合、移行先の第一候補はAWS Step Functionsです。本章では、Step Functionsへの移行が適するケース、Data Pipeline概念との対応、ASLへの変換の考え方、EventBridge/SSMとの併用パターン、移行手順の概略までを解説します。Step Functions自体のステートマシン設計の基礎的な使い方は、既存記事「AWS Application Integration本番運用 Vol2」で解説済みのため、本章では再解説しません。

4-1. Step Functionsへの移行が適するケース

Step Functionsが適合するかどうかは、処理の中心がAWSサービス間の連携・制御にあるかどうかで判断します。

判断の目安は「複数のAWSリソースをどの順序・どのような条件で呼び出すか」を制御することが処理の主目的かどうかです。Data PipelineでActivity同士の依存関係(dependsOn)を多用し、各Activityが実質的に「別のAWSサービスを呼び出すだけ」だった場合は、Step Functions適合度が高いワークロードです。

4-2. 概念マッピング: Data Pipeline → Step Functions

Data Pipelineの最大の違いは、Activity Worker(Task Runner)という仲介の仕組みが不要になる点です。Data PipelineはEC2上で動くTask Runnerが各Activityを実行する構成でしたが、Step FunctionsはAWSサービスを直接呼び出すため、Task Runnerに相当する常駐プロセスの運用自体が不要になります。

4-3. ASLへの変換の考え方

Data PipelineのPipeline定義とStep FunctionsのASLは、どちらもJSON形式で処理の流れを記述する点が共通しており、構造的な発想の転換は比較的小さく済みます。ただし、Activityの種類ごとに変換パターンが異なります。

以下は、S3間のコピー処理を行うShellCommandActivityを、ASLのTask状態に変換するイメージです。

{
  "Comment": "Data PipelineのCopyActivity相当をStep Functionsで表現",
  "StartAt": "CopyS3Object",
  "States": {
 "CopyS3Object": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:s3:copyObject",
"Parameters": {
  "Bucket": "destination-bucket",
  "CopySource": "source-bucket/source-key",
  "Key": "destination-key"
},
"Retry": [
  {
 "ErrorEquals": ["States.ALL"],
 "IntervalSeconds": 30,
 "MaxAttempts": 3,
 "BackoffRate": 2.0
  }
],
"End": true
 }
  }
}

AWS SDK統合(arn:aws:states:::aws-sdk:サービス名:API名)を使うと、Lambda関数を経由せずにAWS APIを直接呼び出せます。Data PipelineのShellCommandActivityでAWS CLIコマンドを実行していた処理の多くは、この形でLambdaレスに変換できる場合があります。一方、AWS API呼び出しだけでは完結しない独自ロジック(データの加工・条件判定等)が含まれる場合は、Lambda Task状態に変換し、そのロジックをLambda関数のコードとして書き起こします。

Retry/Catchフィールドは、Data Pipelineの再試行設定(ActivityのretryDelay・maximumRetries)に相当する機能で、Task状態ごとに宣言的に設定できます。Data Pipeline側で個別に実装していたリトライロジックがある場合、その多くはRetryフィールドの設定に置き換えられます。

4-4. EventBridge/SSMとの併用

スケジュール実行(EventBridge Scheduler)

Step Functions自体はスケジュール実行の仕組みを持たないため、Data Pipelineが担っていた定期実行は、EventBridge Schedulerと組み合わせて実現します。EventBridge Schedulerのcron式・rate式でステートマシンの実行(StartExecution)をトリガーする構成にすることで、Data Pipelineのスケジュール設定をほぼそのまま移植できます。

パラメータの受け渡し(SSM Parameter Store)

Data PipelineではRuntime parameter(実行時パラメータ)をActivity間で受け渡すことができましたが、Step Functionsでは各Task状態の入出力(JSONPath)で値を受け渡すのが基本です。ただし、複数のステートマシン実行を跨いで共有する設定値(接続先エンドポイント・しきい値等)は、SSM Parameter Storeに格納し、Task状態からAWS SDK統合(aws-sdk:ssm:getParameter)で参照する構成にすると、ステートマシン定義自体を変更せずに設定値だけを更新できます。

イベント駆動処理への拡張

Data Pipelineはスケジュール実行が中心でしたが、Step Functionsへの移行を機に、S3イベント・EventBridgeカスタムイベントをトリガーとしたイベント駆動処理へ拡張できます。ただし本記事はあくまで移行の文脈に絞るため、イベント駆動設計そのものの詳細は既存記事「AWS Application Integration本番運用 Vol2」を参照してください。

4-5. 移行手順の全体像

4-6. 詰まりポイント/アンチパターン

5. 移行先別ガイド③ — Amazon MWAA への移行

§2-3の判断フローで「Airflow資産・Python DAGによる複雑な依存関係管理が中心」と判断した場合、移行先の第一候補はAmazon MWAAです。本章では、MWAAへの移行が適するケース、Data Pipeline概念との対応、Python DAG設計への発想転換、オブザーバビリティ・backfill/retryの活用、移行手順の概略までを解説します。MWAA自体の構築・DAG運用の基礎的な使い方は、既存記事「AWS Application Integration本番運用 Vol2」で解説済みのため、本章では再解説しません。

5-1. MWAAへの移行が適するケース

MWAAが適合するかどうかは、既存のAirflow資産の有無と、依存関係の複雑さで判断します。

判断の目安は「Pythonコードで依存関係・条件分岐を柔軟に記述する必要があるか」「既にAirflow資産・運用ノウハウが社内にあるか」です。Data PipelineでActivity間の依存関係が複雑に入り組んでいたり、動的にタスク数が変わる処理を組んでいた場合は、MWAA適合度が高いワークロードです。

5-2. 概念マッピング: Data Pipeline → MWAA

Data Pipelineとの最大の違いは、依存関係やPreconditionを「設定項目」としてではなく「Pythonコード」として記述する点です。この発想転換については5-3で詳しく扱います。

5-3. Airflow資産の移植とDAG設計への発想転換

既存Airflow資産の持ち込み

オンプレミスまたは自前運用のAirflowから既にDAGコード資産がある場合、そのDAGファイルをMWAA環境のS3バケット(DAGフォルダ)に配置するだけで、多くの場合は大きな改修なしにそのまま動作します。カスタムオペレーター・カスタムフックを使っている場合は、requirements.txtにパッケージを追加し、MWAA環境の依存関係インストールを通じて利用可能にします。既存資産がない場合、Data PipelineのPipeline定義をDAGとして新規に書き起こす作業が必要です。

設定からコードへの発想転換

Data Pipelineでは、Activity・DataNode・Preconditionを主にJSON設定として記述していましたが、MWAAではこれらをPythonコードとして記述します。以下は、Data PipelineのCopyActivity(S3間コピー、前段の成功待ち)相当を、MWAAのDAGとして書き起こすイメージです。

from airflow import DAG
from airflow.providers.amazon.aws.sensors.s3 import S3KeySensor
from airflow.providers.amazon.aws.transfers.s3_to_s3 import S3ToS3Operator
from datetime import datetime, timedelta

with DAG(
 dag_id="data_pipeline_copy_migration",
 schedule="0 3 * * *",
 start_date=datetime(2026, 7, 1),
 catchup=False,
 default_args={"retries": 3, "retry_delay": timedelta(minutes=5)},
) as dag:
 wait_for_source = S3KeySensor(
  task_id="wait_for_source_object",
  bucket_name="source-bucket",
  bucket_key="source-key",
 )
 copy_object = S3ToS3Operator(
  task_id="copy_s3_object",
  source_bucket_name="source-bucket",
  source_bucket_key="source-key",
  dest_bucket_name="destination-bucket",
  dest_bucket_key="destination-key",
 )
 wait_for_source >> copy_object

この例のように、Data PipelineのPreconditionはS3KeySensor、Activityの依存関係は>>演算子によるタスク間の順序定義、再試行設定はdefault_argsのretries・retry_delayとして、それぞれPythonコードに置き換わります。JSON設定を1対1で機械的に置き換えるのではなく、「このワークフローをPythonコードとしてどう表現するか」という発想でDAGを設計し直すことが、MWAAへの移行を円滑に進める鍵になります。

動的なタスク生成

Data Pipelineでは表現しづらかった「入力データの件数に応じてタスク数を動的に変える」といった処理も、MWAAではPythonのループやDynamic Task Mappingで表現できます。これはMWAAならではの拡張余地であり、移行を機に処理の柔軟性を高められる点でもあります。

5-4. オブザーバビリティ(リッチUI)・backfill/retry

オブザーバビリティ

MWAAはAirflow標準のWeb UIをそのまま提供しており、DAGごとの実行履歴・各タスクのログ・依存関係グラフ(Graph View)・実行時間の推移(Gantt Chart)を、Data Pipelineコンソールより詳細に可視化できます。Data Pipelineでは個々のActivityの実行状況をコンソールから追いづらい場面がありましたが、MWAAのリッチUIでは、どのタスクがどの理由で失敗したかをグラフ上から直接掘り下げて確認できます。

backfill(過去日付分の再実行)

Data Pipelineでも過去分の再実行は可能でしたが、MWAAのbackfillはDAG設計に標準で組み込まれた機能です。start_dateと実行対象期間を指定してAirflow CLIからairflow dags backfillを実行すると、過去の各実行日に対応するタスクインスタンスをまとめて生成・実行できます。日次バッチの欠損分をまとめて埋めたい場合や、DAGのロジック変更後に過去分を再計算したい場合に活用します。

retry(再試行)

5-2・5-3で触れたとおり、Task単位でretries・retry_delayを設定でき、さらにretry_exponential_backoff(指数バックオフ)のような細かい制御も可能です。Data Pipeline側でActivityごとに個別実装していたリトライロジックがある場合、その多くはOperatorの標準引数への置き換えで完結します。

5-5. 移行手順の全体像

5-6. 詰まりポイント/アンチパターン

6. 概念マッピングと移行チェックリスト

§3〜§5では、Glue・Step Functions・MWAAそれぞれへの移行を個別に解説してきました。本章では、これらを横並びで整理した概念マッピング表を仕上げとして提供したうえで、移行前後の検証項目とロールバック方針を確認し、記事全体をまとめます。

6-1. Data Pipeline → 3サービス 概念マッピング総合表

§2-2で示した大枠の対応と、§3〜§5で個別に扱った詳細を統合し、AWS公式移行ガイド(migration.html)の概念マッピング表に忠実な形で、Data Pipelineの主要概念が3つの移行先でそれぞれ何に対応するかを横並びで整理します。

3サービスに共通する変化として、Data Pipelineが必要としていたActivity Worker(Task Runner、EC2上で常駐するプロセス)相当の仲介の仕組みが、いずれの移行先でも不要になる点が挙げられます。Glue・Step Functions・MWAAは、いずれもマネージドサービス自体がActivityの実行を直接担うため、Task Runner相当の常駐プロセスを自前で運用する必要がなくなります。この対応表は、移行先を1つに決めた後でも、他の2サービスとの違いを確認する際のリファレンスとして活用してください。

6-2. 移行前後の検証項目

移行を完了とみなす前に、以下の観点で移行元(Data Pipeline)と移行先の出力・挙動を比較検証します。§3〜§5で個別に触れた並行稼働検証を、記事全体を通じたチェックリストとして統合します。

これらの検証は、§3-3・§4-5・§5-5で述べた「並行稼働による検証」の期間中に、実際の実行結果を突き合わせながら1項目ずつ確認していきます。特に出力データの整合性と実行順序の再現性は、切替後に気づくと影響範囲が広がりやすいため、切替前に重点的に確認してください。

6-3. ロールバック方針

移行先への切替後に問題が発覚した場合に備え、切替前にロールバック方針を決めておくことが重要です。

切替前の準備

• Data Pipeline側のPipeline定義・スケジュール設定を、無効化するだけで残し、削除しない(即座に再有効化できる状態を維持する)
• 移行先(Glue/Step Functions/MWAA)への切替日時と、Data Pipeline側の無効化日時を記録しておく
• 切替直後の実行結果を確認するまでの期間(例: 数回分の実行サイクル)は、担当者が能動的に監視する体制を組む

ロールバック判断基準の例

ロールバック実行時の注意

Data Pipeline側を再有効化する際は、無効化していた期間中に本来実行されるはずだったスケジュールが欠落していないかを確認し、必要であれば手動実行で補います。また、移行先(Glue/Step Functions/MWAA)側で既に実行されてしまった処理がある場合、Data Pipeline側の再開時に処理が重複しないよう、再開前に移行先の処理を確実に停止してください。

ロールバックはあくまで最終手段であり、6-2の検証項目を切替前に丁寧に確認しておくことで、ロールバックが必要になる事態そのものを避けやすくなります。

6-4. 記事全体のまとめ

本記事では、新規受付終了・メンテナンスモードとなったAWS Data Pipelineについて、移行先3サービス(Glue・Step Functions・MWAA)への移行を、選定基準・概念マッピング・移行手順・アンチパターンという観点から一貫して解説してきました。

3つの移行先はいずれも、Data Pipelineが担っていたActivity Worker(Task Runner)相当の仲介の仕組みを不要にする点で共通しています。一方で、Pipeline定義という単位がWorkflow・ステートマシン・DAGのいずれに対応するか、Precondition(実行条件)がトリガー条件・Choice状態・Sensorのいずれで表現し直されるかは、移行先ごとに設計の発想が異なります。この違いを理解したうえで、6-1の総合対応表と6-2の検証項目を移行プロジェクトのチェックリストとして活用してください。

移行の第一歩は、§2-3で述べたPipeline棚卸しから始まります。自社ワークロードの特性を洗い出し、判断フローに沿って移行先を決めたら、該当する§3〜§5の手順に沿って移行を進め、6-2・6-3の検証・ロールバック方針を準備したうえで切替を実行してください。移行先各サービスの基礎的な使い方でつまずいた場合は、既存記事「AWS Analytics/Data Lake本番運用 Vol1」(Glue)・「AWS Application Integration本番運用 Vol2」(Step Functions/MWAA)もあわせて参照することをおすすめします。

移行先サービスの本番運用を先に押さえたい方はこちら