大手小売企業が20台のm5.4xlarge EC2インスタンスと5TB RDS MySQLで運用するモノリシックeコマースアプリケーションを段階的に分解する計画を立てている。最初のフェーズで「注文処理」と「在庫管理」を独

Question

大手小売企業が20台のm5.4xlarge EC2インスタンスと5TB RDS MySQLで運用するモノリシックeコマースアプリケーションを段階的に分解する計画を立てている。最初のフェーズで「注文処理」と「在庫管理」を独立サービスとして切り出す。要件：注文処理はピーク1万件/分・100ms以内のレスポンスが必要；在庫管理は日100万SKU更新・結果整合性許容・MySQL互換クエリが必須；チームはDockerに精通しているがKubernetes運用経験がない；既存CI/CDはCodePipeline/CodeBuildを使用；3ヶ月以内に初回サービスを本番稼働させ移行中もモノリスを継続稼働させること。このシナリオで最も適切なアーキテクチャはどれか。

Accepted Answer

正解: 注文処理をECS Fargate＋DynamoDB（DAXキャッシュ）へ切り出し、在庫管理をECS Fargate＋Aurora MySQL（個別インスタンス）へ切り出す。ALBの加重ターゲットグループで段階的にトラフィックを移行しモノリスと並行稼働させる。。ECS FargateはK8s経験不要で3ヶ月タイムラインに適合する。DynamoDB＋DAXが100ms要件を満たし、Aurora MySQL個別インスタンスでMySQL互換性と完全なデータ分離を両立する。ALB加重ルーティングで安全な段階移行が可能。

Answer

注文処理と在庫管理をEKS（EC2ノード）＋Istioサービスメッシュへ切り出し、移行期間中は両サービスが既存のRDS MySQLに接続し続ける。完全なDB分離はフェーズ2で実施し、ALB Ingressでトラフィックを段階的に移行する。 — EKS選択はKubernetes経験のないチームへの3ヶ月タイムラインで過大なリスクとなり、共有RDS MySQL継続接続はデータ疎結合の目的を果たせない。

Answer

注文処理と在庫管理をEKS（Fargateモード）へ切り出し、注文処理はDynamoDB＋DAX、在庫管理はDynamoDB Global Tablesを採用する。ALB Ingress Controllerで加重ルーティングしモノリスと並行稼働させる。 — EKS FargateはK8s経験不要だが初期構築が複雑で3ヶ月期限にリスクが高い。DynamoDB Global Tablesはシングルリージョン要件に不要な複雑さを追加する。

Answer

注文処理をECS Fargate＋ElastiCache Redis＋RDS MySQL個別インスタンスへ切り出し、在庫管理をLambda＋SQSの非同期処理へ切り出す。API Gatewayで新エンドポイントをルーティングし段階移行する。 — Lambdaはコールドスタートリスクでピーク1万件/分・100ms要件を安定して満たせず、ElastiCache RedisはACID保証がなく注文データの永続化に不適切。

解説

解説