急成長中のEコマース企業が、オンプレミスで15年間運用してきたモノリシックアプリケーションのモダナイゼーションを計画しています。 【現在の構成と課題】 - Python/Djangoモノリス（コードベース約120万行、技術的負債が深刻） - PostgreSQL（2TB）、Elasticsearch 7.x、Redis 6.xが同一データセンターで稼働 - 最大同時接続数: 通常期1万 / 年末セールピーク時10万（約10倍の変動） - デプロイ頻度: 月1回（モノリスの複雑な依存関係によりリスクが高く頻度を抑制中） - チーム構成: バックエンド10名・フロントエンド5名（マイクロサービス経験者は少ない） - 現在の主要課題: ①ピーク時のスケールアウト不可能な機能が存在（決済・在庫・推薦エンジン） ②月次デプロイによる機能リリース遅延 ③特定の重いバッチ処理が全体のパフォーマンスに影響 【モダナイゼーション目標】 - デプロイ頻度を週複数回に向上 - 決済・在庫・推薦エンジンを独立してスケーリング可能にする - 移行期間中のビジネス継続性を確保（移行によるサービス停止ゼロ） - 移行期間: 18ヶ月 最も適切なモダナイゼーション戦略はどれですか？
Strangler Figパターンを適用し、まず高負荷の決済・在庫・推薦エンジンを切り出してAmazon ECS on Fargateのマイクロサービスとして再実装。Amazon API GatewayとALBを組み合わせてモノリスとマイクロサービスへのルーティングを制御。既存モノリスはAWS MGNでEC2に移行して並行稼働。PostgreSQLはRDS for PostgreSQL Multi-AZ、ElasticsearchはOpenSearch Service、RedisはElastiCache for Redisに順次移行。CI/CDをAWS CodePipeline+CodeDeployで構築し段階的に移行する。 120万行のレガシーモノリスを一括移行するリスクを回避するため、Strangler Figパターンによる段階的なモダナイゼーションが最適です。ボトルネックである決済・在庫・推薦エンジンを先行してマイクロサービス化することで独立スケーリングを実現しつつ、AWS MGNによるモノリスのEC2移行で移行期間中のサービス継続性を確保します。ECS on Fargateはマイクロサービス経験の少ないチームでもEKSより運用負荷が低く適切です。API GatewayとALBの組み合わせにより、モノリスと新マイクロサービスへのトラフィックを段階的に切り替えることができます。 選択肢Bはコールドスタートの影響や120万行のリファクタリングコストを考えると18ヶ月では現実的でなく、決済処理やチェックアウトなどEコマースで求められる安定した低レイテンシー要件とも相性が悪いです。 選択肢Cはスケーリング課題の根本解決にならず、EKSの運用複雑度がチームの経験と合いません。 選択肢Dは特定コンポーネントの独立スケーリングに対応できず、ピーク時10倍の変動への対応が困難です。