モダナイゼーション戦略の設計 モノリスを止めずに分割する

SAP-C02では「既存のモノリシックなアプリケーションを、どこから・どの技術へ・どんな順番で切り出すか」を問う設問が繰り返し出ます。単にサービス名を覚えるだけでは解けず、可用性・改修コスト・組織体制といった要件から最適解を選ぶ力が必要です。この記事ではその判断軸を整理します。

覚え方は「分割・置換・接続」の3つの観点です。どの機能を切り出すか（分割）、切り出した先をどのコンピュートに載せるか（置換）、旧システムとどう共存させるか（接続）。この順に考えると選択肢を機械的に絞り込めます。

分割：ストランガーパターンで段階移行する

全面刷新（ビッグバン移行）はリスクが高く、試験でもまず選ばれません。定石はモノリスの前段に Application Load Balancer や API Gateway を置き、パス単位で新しいマイクロサービスへ振り分けを切り替えるストランガーパターンです。「無停止で段階的に移行したい」「問題があればすぐ切り戻したい」という要件ならこれを選びます。たとえば決済機能だけを新サービスに向け、残り9割のパスは旧環境のまま、といった進め方ができます。

置換：移行先コンピュートの使いどころ

切り出した機能をどこで動かすかは、実行時間・常時性・運用体制で決まります。

接続：データ分割とトランザクション

サービスごとにデータストアを持たせる

サービスを分けても単一の巨大DBを共有し続けると、結局モノリスのままです。参照系の負荷が高い機能はAuroraのリードレプリカやDynamoDBへ切り出し、キーによる単純検索が中心で秒間数万リクエストを捌く必要があるならDynamoDB、複雑な結合や既存SQL資産を活かすならAuroraを選びます。

分散トランザクションはSagaで扱う

複数サービスをまたぐ更新は2相コミットではなく、補償トランザクションを並べるSagaパターンで実装します。処理順序と失敗時の巻き戻しを明示したいならAWS Step Functions、サービス同士を疎結合にイベントで繋ぐならAmazon EventBridgeが定番です。

チェックリスト

• ストランガーパターンで切り出す順序と切り戻し方法を説明できる
• Lambda・Fargate・EKS・EC2を要件から選び分けられる
• サービスごとのデータストア分割の是非を判断できる
• Sagaパターンと、Step Functions・EventBridgeの使い分けを説明できる
• モダナイズとリホストのどちらが要件に合うか見極められる

まとめ

モダナイゼーションは「分割・置換・接続」の3点セットで考え、要件が速度なのか最適化なのかを最初に見極めるのが近道です。仕上げに クイズ で知識を定着させ、出題範囲の最新版は AWS認定 公式ページ で必ず確認してください。