1.3オーケストレーションとストリーミング処理

複数の取り込み・変換ステップは順序立てて自動実行（オーケストレーション）します。また、ストリームをその場で集計する処理も重要です。

1.3.1オーケストレーションと処理

• Step Functions：ステートマシンでパイプラインの順次/分岐/並列/リトライを編成する。
• Managed Workflows for Apache Airflow（MWAA）：Airflow の DAG でデータパイプラインを編成する（既存 Airflow 資産に向く）。
• Managed Service for Apache Flink：ストリームをその場で集計/変換する（ウィンドウ集計など）。
• Lambda：軽量な変換やイベント駆動の処理に使う（Firehose の変換にも組み込める）。

パイプラインは「編成（オーケストレーション）」と「ストリーム処理」を分けて考えます。編成には Step Functions（ステートマシンで順次/分岐（Choice）/並列（Map）/リトライ/エラー処理を宣言的に記述・サーバーレス・多数の AWS サービスと直接連携）と MWAA（Managed Workflows for Apache Airflow）（Python の DAG で記述・既存 Airflow 資産やコミュニティ Operator を活かす）があり、軽量な単純連鎖なら Glue ワークフロー、イベント駆動の起動には EventBridge（スケジュール/イベントルール）も使えます。ストリームをその場で集計・変換するなら Managed Service for Apache Flink（ウィンドウ集計・SQL/Java・イベント時間処理）、軽量な1件変換や Firehose 内変換は Lambda です。判断軸は「複雑な分岐や多サービス連携＝Step Functions」「Airflow 互換／既存 DAG＝MWAA」「ストリームのリアルタイム集計＝Flink」「短い変換＝Lambda」。失敗時の再実行・可観測性（CloudWatch ログ/メトリクス・X-Ray）も運用設計の要点です。

1.3.2取り込み・移行の in-scope サービス

DEA-C01 では、データの入口として多様な取り込み・移行サービスが問われます。外部データの取り込みでは、Amazon AppFlow が SaaS（Salesforce/Zendesk 等）と AWS の間でノーコードのデータ連携を行い、AWS Data Exchange はサードパーティのキュレーション済みデータ製品を購読して分析基盤へ取り込みます。アプリからの送信は Amazon API Gateway をマネージドな HTTP/REST の入口にし、スロットリングや認証を効かせて Lambda/Kinesis へ流します。 オンプレミスからの移行では使い分けが重要です。AWS DataSync は NFS/SMB ファイルを S3/EFS/FSx へ高速・増分・スケジュールで同期し、AWS Transfer Family は SFTP/FTPS/FTP のファイル授受を S3/EFS へサーバー運用なしで受け止めます。サーバー全体のリフト＆シフトは AWS Application Migration Service（MGN）がブロックレベルの継続レプリケーションで担い、その前段の計画には AWS Application Discovery Service でサーバーの構成・依存・利用状況を収集します。回線が細い・ペタバイト級のデータは AWS Snow Family で暗号化物理デバイスによりオフライン輸送し、Snowball Edge ではエッジ前処理も行えます。

1.3.3この節のまとめ

• 編成＝Step Functions / MWAA（Airflow）
• リアルタイム集計＝Flink、軽量変換＝Lambda
• 取り込み＝AppFlow/Data Exchange/API Gateway、移行＝DataSync/Transfer Family/MGN/Snow Family