中堅保険会社がオンプレミス基幹システムをAWSへ移行する計画を進めています。現在の構成は以下のとおりです。 【現構成】 - JBoss EAP 7上で稼働するJava EE 8アプリケーション（40台のサーバー） - Oracle Database 12c（データ量5TB、ストアドプロシージャおよびOracle Partitioning機能を多用） - IBM MQによるメッセージング基盤（JMS経由でアプリケーションと連携） - NFSv3共有ファイルシステムで保険証書PDFを約800万件格納 - Active Directoryによる認証基盤 【制約条件・要件】 - 予算制約によりアプリケーションコードの変更は不可 - 移行期間: 6ヶ月 - RTO: 4時間 / RPO: 1時間 - 自然災害発生時に保険請求件数が通常の10倍に急増するピーク対応が必要 - PCI DSSおよびFISC安全対策基準への継続的な準拠が必要 - 移行後の運用負荷軽減が経営要件 ソリューションアーキテクトとして最も適切な移行戦略はどれですか？
アプリケーションコード変更不可の制約から、OracleストアドプロシージャとOracle固有機能との互換性を維持するためRDS for Oracleが必須です。MGNによるリホストにより6ヶ月の期間制約を満たしつつ、マネージドサービス化で運用負荷を軽減できます。Amazon MQ for ActiveMQはJMS（Java Message Service: Javaアプリケーション間の非同期メッセージング標準API）プロトコルをサポートし、IBM MQからの移行でアプリケーション側の変更を最小化します。EFSはNFSv4.0/v4.1プロトコルをサポートし（NFSv3は非対応だが既存NFSv3共有の移行先として利用可能）、RDS Multi-AZでRTO/RPO要件を満たします。 選択肢BはAurora PostgreSQLへの移行でOracleのストアドプロシージャやPartitioningなどのOracle固有機能の書き直しが必要となり、コード変更不可の制約に違反します。 選択肢CはIBM MQをEC2上でそのまま継続稼働させる構成であり、マネージドサービスへの移行が行われないため「移行後の運用負荷軽減」要件を満たしません。またAuto Scalingグループが構成されておらず、自然災害時の10倍ピーク需要に対応できません。 選択肢DのAWS Elastic Disaster RecoveryはレプリケーションDR目的のサービスであり移行ツールではありません。RDS Single-AZではRTO/RPO要件を満たせず、Amazon MQ for RabbitMQはAMQP（Advanced Message Queuing Protocol）ベースであり既存のJMS連携との互換性に問題が生じます。なおFISCとは金融情報システムセンター（Financial Information Systems Center）の略で、日本の金融機関向けセキュリティガイドラインを策定する機関です。