大手製造業企業が、20台のオンプレミスアプリケーションサーバーで稼働する大規模モノリシックJavaアプリケーション（1日200万トランザクション処理）をAWSのマイクロサービスアーキテクチャへ段階的に移行する計画を立てています。 現在の構成： ・PostgreSQLデータベース（5TB、複雑なストアドプロシージャとトリガーを多数含む） ・ビジネスモジュール間の同期内部API呼び出しによる密結合アーキテクチャ ・95パーセンタイルレスポンスタイム：100ms以下 ・EDI（Electronic Data Interchange：企業間電子データ交換）統合が複数の取引先と本番稼働中 移行の制約： ・計画メンテナンスウィンドウなしのゼロダウンタイム移行 ・移行期間中のデータ整合性の完全維持 ・すべてのトランザクションに対する完全な監査証跡の保持 ・移行チームのKubernetes運用経験が限定的 ・既存EDI統合を中断なく継続 上記すべての制約を満たしつつ移行リスクを最小化する戦略として、正しい組み合わせを2つ選んでください。
MGNはエージェントベースの継続的ブロックレベルレプリケーションによりゼロダウンタイム移行を実現し、Strangler Figパターンとの組み合わせで段階的リスク分散が可能です。ECS Fargateは限定的なKubernetes経験という制約に合致しEKSより運用負荷が低いです。DMS CDCはトランザクション整合性を保ちながらソースからターゲットへの単方向レプリケーションでオンラインDB移行を実現し、SCTでストアドプロシージャの変換可否を事前評価できます。 選択肢CはKubernetes経験不足の制約に反し、ビッグバン方式は移行リスクが極めて高いです。 選択肢DはDynamoDBへの全面移行は、5TBの複雑なリレーショナルスキーマ移行コストが現実的ではありません。 選択肢EのTransfer Family＋Step Functionsは有用コンポーネントですが、これ単体では移行戦略として不完全です。