大手金融サービス企業が、15年前に開発したJava EEモノリシックアプリケーション（Oracle WebLogic上で稼働）のクラウドモダナイゼーションを計画しています。現在の環境と要件は以下の通りです。 【現在の環境】 ・Oracle WebLogicで稼働するJava EEモノリス（コード量50万行超、技術的負債が多い） ・Oracle RACデータベース（20TB） ・300以上のバッチジョブ（毎晩夜間に実行、複雑なジョブ依存関係あり） ・99.99%の可用性SLA ・PCI-DSS準拠要件（全データ暗号化・7年間の監査ログ保持） ・開発チーム50名（クラウドネイティブパターンの経験が乏しい） 【モダナイゼーション要件】 1. ストラングラーフィグ・パターン※による段階的なモダナイゼーション（ビッグバンマイグレーションは不可） 2. 移行期間中はモノリスと新マイクロサービスを並行稼働させること 3. 夜間バッチジョブを効率化し、スポットインスタンス等でコストを削減すること 4. 全体的なインフラ運用オーバーヘッドを削減すること ※ストラングラーフィグ・パターン: レガシーシステムを段階的に新システムに置き換えるアーキテクチャ手法。既存システムを生かしつつ、新機能を徐々にモダンな実装へ切り替えることでリスクを最小化する。 要件を最もよく満たすアプローチを2つ選択してください。
BはMGNリフト&シフトで既存WebLogic環境をまずEC2上に安定稼働させ、その後API Gateway＋Lambda＋EventBridgeによりストラングラーフィグを段階的に実現する最も安全なアプローチです。 DはAWS Batchがバッチコンピューティングに特化したマネージドサービスであり、スポットインスタンスとEventBridge Schedulerの組み合わせで要件を完全に満たします。 選択肢AはEKSコンテナ化とAurora移行の同時実施はビッグバン的で99.99%SLAリスクが高いです。 選択肢CはElastic BeanstalkはWebLogicを非サポート、全マイクロサービス一括切り出しはストラングラーフィグに反します。 選択肢EはStep Functionsは定型ワークフローの実行順制御に適するが、300以上の多様なバッチジョブの一括置換には柔軟性が低いです。