大手メディア企業が、15年間運用してきたモノリシックなJava EEアプリケーション（JBoss EAP（Enterprise Application Platform：Red Hat社製のエンタープライズ向けJavaアプリケーションサーバー）上で稼働、WARファイル（Web Application Archive：Javaウェブアプリケーションの標準パッケージ形式）としてデプロイ、コード規模150万行）のAWS移行とモダナイズを計画している。現状の課題として、12の開発チームが単一コードベースを共有しており毎週のリリースに4時間の計画停止が発生していること、アプリケーションはオンプレミスのOracleデータベース（2TB）と密結合していること、トラフィックは平日9〜18時に集中し夜間・週末はほぼゼロであること、開発チームはJavaに精通しているがKubernetes運用経験はないことが挙げられる。経営層の要件は「12ヶ月以内にAWSへ移行し、各チームが他チームのリリースに依存せず独立してデプロイできる体制を構築すること」である。移行リスクを最小化しながら12ヶ月の期限内に要件を達成できる可能性が最も高いアプローチはどれか。
MGNによるリフト&シフトでまず12ヶ月内の移行を確実に完了させ、ALBのストラングラーフィグパターンで既存モノリスとマイクロサービスを並行稼働させながら段階的にECS Fargateへ切り出す計画はJavaチームの学習コストが低く現実的です。CodePipelineとECRの独立化で12チームの独立デプロイも実現できます。 選択肢AはElastic Beanstalkへの移行はデプロイ管理を簡素化するが独立デプロイ実現には直接つながらず、マイクロサービス分解の移行経路が不明確です。 選択肢BはLambda@EdgeはOrigin Requestイベントで異なるオリジンへのルーティングも技術的には可能ですが、150万行のコードを12ヶ月でLambdaとDynamoDBによるサーバーレスアーキテクチャへ全面書き換えることは時間的・技術的に非現実的です。 選択肢DはKubernetes未経験チームがEKS運用を習得しながら12ヶ月で全コードをSpring Bootに書き直すことは極めて困難です。