Instiq
第4章 · ワークロードの移行とモダナイゼーションの加速·v2.0.0·更新 2026/8/6·読了目安 約10分

変更要約: SAP-C02 第4章を深掘り(比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応)

4.3クラウドへのモダナイゼーション

この節の要点

移行後の近代化——コンテナ(ECS/EKS/Fargate)サーバーレスマイクロサービス化ストラングラーフィグパターンによる段階的移行——を理解します。俊敏性・スケール・コスト効率を高めます。

モダナイゼーションはモノリスをコンテナ/サーバーレスへ、機能単位のマイクロサービスへ分解します。一気にではなく段階的に進めます。

4.3.1モダナイゼーションのパターン

モノリシックなアプリケーションを段階的に近代化する様子を示した図。実行基盤の選択として、Kubernetes が必要なら EKS、AWS ネイティブなオーケストレーションなら ECS、サーバー管理を不要にするなら Fargate(サーバーレスコンテナ)、イベント駆動の小さな処理なら Lambda(サーバーレス)を並べ、モノリスを機能ごとのマイクロサービスへ分解し、ストラングラーフィグパターン(API Gateway/ロードバランサーで新旧をルーティングし、機能を少しずつ新サービスへ移し替えて最終的に旧モノリスを廃止する)で段階的に移行する流れを示した図。
モダナイゼーションのパターン
  • コンテナEKS(Kubernetes)/ECS(AWS ネイティブ)。サーバー管理不要なら Fargate
  • サーバーレス:イベント駆動の小処理は Lambda。インフラ管理ゼロでスケール。
  • マイクロサービス:モノリスを機能単位に分解し、独立してデプロイ・スケール。
  • ストラングラーフィグ:新旧をルーターで併存させ、機能を少しずつ新サービスへ移して最後に旧を廃止。
試験ポイント

「Kubernetes 互換が必須=EKS」「AWS ネイティブなコンテナ=ECS」「サーバー管理不要のコンテナ=Fargate」「イベント駆動の関数=Lambda」「モノリスを安全に段階移行=ストラングラーフィグパターン」 は SAP-C02 で頻出です。一括書き換えはリスクが高く、段階的移行が推奨されます。

コツ

既存の Kubernetes 資産や移植性を重視するなら EKS、AWS への密結合で運用を簡素化したいなら ECS、いずれもサーバー管理を避けたいなら起動タイプに Fargate を選びます。

モダナイゼーションの設問では「実行基盤の選択軸」と「安全な移行の進め方」が問われます。ECS と EKS はどちらもコンテナオーケストレーションですが、ECS は AWS ネイティブで学習コストが低く IAM/ALB/CloudWatch と密に統合され、EKS は Kubernetes 標準 API でマルチクラウド移植性やエコシステム(Helm/Operator)を活かせます。両者とも起動タイプとして EC2(自前でノードを管理しコスト最適化やデーモン要件に対応)か Fargate(ノード管理ゼロのサーバーレス)を選べます。Lambda はイベント駆動・短時間・断続的なワークロードに最適で、リクエストがない間は課金されません——一方で実行時間やパッケージサイズの上限があり、常時高スループットや長時間処理にはコンテナが向きます。モノリスの解体は一括書き換え(ビッグバン)が高リスクなため、ストラングラーフィグパターンで API Gateway や ALB を「ファサード」に置き、機能を 1 つずつ新サービスへ切り出してルーティングを差し替え、最後に旧モノリスを廃止します。状態の分離(データベースの分割)や、サービス間の疎結合(SQS/SNS/EventBridge)も近代化の重要な構成要素です。

要件選ぶ基盤理由
Kubernetes 標準/移植性が必須EKSK8s API・既存資産/エコシステム活用
AWS ネイティブで運用を簡素化ECSIAM/ALB/CloudWatch と密統合
サーバー管理をしたくないFargate(起動タイプ)ノード管理ゼロのサーバーレス
イベント駆動・断続的な処理Lambdaアイドル時無課金・自動スケール
補足

シナリオ:肥大化した受注モノリスを、稼働を止めずに段階的にマイクロサービス化したい。まず「在庫照会」機能だけ切り出したい。→ ALB/API Gateway をファサードに置き、在庫照会のパスだけ新しい ECS(Fargate)サービスへルーティング。旧モノリスは残したまま動かし、検証できたら次の機能を順に移します(ストラングラーフィグ)。サービス間は EventBridge で疎結合にし、最後にモノリスを廃止します。

補足

FAQ:いつ Lambda、いつコンテナ? 断続的・イベント駆動・短時間(数分以内)で、アイドル時にコストをかけたくないなら Lambda。常時高負荷・長時間実行・特殊なランタイムや大きな依存が必要なら ECS/EKS(必要に応じ Fargate)。両者を併用し、フロントは Lambda、重い常駐処理はコンテナ、という分担も一般的です。

注意

ひっかけ:「巨大モノリスを安全に近代化」したいのに一括全面書き換え(ビッグバン)を選ぶのは誤り。リスクが高く、ロールバックも困難です。正解は ストラングラーフィグパターンによる段階移行。また「Kubernetes が要件にない」のに EKS を選ぶと運用が過剰になりがちで、その場合は ECS が無難です。

4.3.2この節のまとめ

  • 実行基盤=EKS/ECS/Fargate(コンテナ)・Lambda(サーバーレス)
  • 近代化=マイクロサービス化+ストラングラーフィグで段階移行

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. 既存の Kubernetes マニフェストとエコシステムをそのまま活かしてコンテナを運用したい。AWS で何を使いますか?

Q2. コンテナを動かしたいが、EC2 サーバーの管理・パッチ・スケーリングを一切したくない。どの起動方法を選びますか?

Q3. 巨大なモノリスを、リスクを抑えて少しずつマイクロサービスへ置き換えたい。最も適したアプローチはどれですか?

理解度を確認第4章「ワークロードの移行とモダナイゼーションの加速」の問題を解く

学習の記録を残しませんか

参考書はすべて無料で読めます。無料登録すると、問題集での演習・既読と進捗の記録・間違えた問題の復習・ハイライトが使えます。