ある大手損害保険会社が、15年以上稼働するオンプレミスのIBM WebSphere Application Server（WAS 8.5）上のSOAPベースのポリシー管理システムをAWSに段階的に移行する計画を策定しています。 現在の構成： ・IBM WAS 8.5上で稼働する32のSOAPサービス（認証、契約管理、保険金請求、代理店管理等） ・全国20,000以上の代理店が接続する代理店ポータルが既存SOAPエンドポイントを利用（URLの変更は契約上6ヶ月前の通知が必要） ・パートナー保険会社12社が本システムのAPIを業務統合に使用 ・Oracle Database 11g（5TB、2,000以上のパッケージ関数・ストアドプロシージャ） ・ピーク時のトラフィック：3,000 TPS、99.99%のSLAを維持 移行要件： ・ストラングラーフィグパターンを採用し、段階的にAWSへ移行（フェーズ1：認証サービス、フェーズ2：契約管理・代理店管理、フェーズ3：保険金請求） ・代理店ポータルおよびパートナーシステムへのSOAPエンドポイントURLの変更は移行期間中不可 ・Oracle DBのストアドプロシージャはAurora PostgreSQLに段階的に変換 ・移行完了まで最大18ヶ月、ダウンタイムゼロが必須 ストラングラーフィグパターンの実装として最も適切なアーキテクチャはどれですか？
選択肢BのAmazon API Gatewayはカスタムドメイン名（Custom Domain Name）とAPIステージマッピングにより、既存のSOAPエンドポイントURLを変更せずに維持できます。VPC Linkを利用することで、VPC内のNLBを経由してオンプレミスのWASに透過的にリクエストを転送でき、移行フェーズごとに振り分け先をECS Fargateとオンプレミスで柔軟に切り替えるストラングラーフィグパターンの実装に最適です。SCT+DMSのCDCモードはOracle DBとAurora PostgreSQLの継続的な整合性を保ちながら、ストアドプロシージャを段階的に変換・移行するための標準的な手法です。 選択肢AのNetwork Load Balancerはレイヤー4（TCP）ロードバランサーであり、SOAPエンドポイントのパスやXMLヘッダーに基づくAPIレベルのルーティングやカスタムドメイン管理機能を持たないため、ストラングラーパターンに必要な細粒度のトラフィック制御が困難です。 選択肢CのLambda@EdgeはCloudFrontエッジロケーションで実行され、レスポンスボディ最大5MB・リクエスト最大1MBの制限があるため大きなSOAPペイロードを処理できない場合があります。またCloudFrontはSOAP/XMLネイティブ処理機能を持たず、API GatewayのようなAPIプロキシとして必要な認証連携やWAF統合等の機能が不足しています。 選択肢DのApplication Migration Service（MGN）はサーバー全体のリフト&シフトに特化したサービスであり、個々のSOAPサービス単位での段階的な分離・移行というストラングラーフィグパターンの本質的な目的とは合致しません。WASサーバーをEC2に移行後にコンテナ化するアプローチは実質的に一括移行となり、移行リスクが高くなります。