7Rの「Refactor」戦略の代表例が、モノリシックなアプリケーションをマイクロサービスへ分割するモダナイゼーションです。本記事ではその代表的な移行パターンを解説します。

SAA レベル：基礎概念

モノリスとマイクロサービスの基本的な違い

項目	モノリス	マイクロサービス
デプロイ単位	アプリケーション全体で1つ	サービスごとに独立
スケーリング	アプリケーション全体を一括でスケール	サービスごとに個別スケール可能
技術選択の自由度	統一された技術スタック	サービスごとに異なる技術選択が可能

SAA 試験のポイント

モノリスの問題点は、一部の機能だけがボトルネックになっている場合でも、アプリケーション全体をスケールさせる必要があるという非効率性です。マイクロサービス化により、負荷の高い機能だけを個別にスケールできる、という基本的なメリットがSAAで問われます。

SAP レベル：高度な設計シナリオ

Strangler Fig（絞め殺しの木）パターン

SAP 試験のポイント

モノリスを一度にすべて書き換える「ビッグバンリライト」は、非常に高いリスクを伴います。SAPレベルでは、Strangler Figパターンを使い、モノリスの一部機能を少しずつ新しいマイクロサービスに置き換え、段階的に既存システムを「絞め殺す」ように縮小させていくアプローチが推奨されます。API Gatewayやロードバランサーでルーティングを制御し、置き換えた機能へのリクエストは新サービスへ、未置き換えの機能はモノリスへ振り分けます。

Phase 1: API Gatewayを導入し、すべてのリクエストをモノリス経由でルーティング
Phase 2: 「ユーザー認証機能」を新マイクロサービスとして切り出し、該当リクエストのみ新サービスへ
Phase 3: 「注文処理機能」を切り出し、同様にルーティング
   ...
Phase N: モノリスに残る機能がなくなり、完全にマイクロサービス化が完了

既存システムとの共存設計

SAP 試験のポイント

移行期間中は、モノリスと新マイクロサービスがデータを共有しながら共存する必要があります。共有データベースへの依存が残っている場合、新旧両方のシステムから同じテーブルにアクセスする設計になりがちで、これは長期的には技術的負債になります。SAPレベルでは、新サービスは独自のデータストアを持ち、モノリスとのデータ整合性はイベント駆動（CDC等）で同期するという設計が、より健全な移行として問われます。

設計上の落とし穴

「マイクロサービス化はすべての機能を対象にすべき」という判断は、過剰な複雑性を生む場合があります。SAPレベルでは、変更頻度が高く、独立してスケールする必要がある機能から優先的に切り出し、変更が少なく安定している機能は無理にマイクロサービス化しないという選択的なアプローチが問われることがあります（すべてを分割することが常に正解ではない）。

切り出す機能の優先順位付け

ビジネス上の変更頻度が高い機能（頻繁に新機能がリリースされる領域）を優先的に切り出すことで、アジリティの向上効果を早期に得られる
スケーラビリティのボトルネックになっている機能（トラフィック集中箇所）も優先度が高い

データベース分割の考慮

モノリスの単一データベースを分割する際は、トランザクション境界の見直しが必要になる（2-2のSagaパターンの記事とも直結する論点）
安易な分割は分散トランザクションの複雑性を招くため、ビジネスドメインの境界（Bounded Context）に沿った分割設計が重要

まとめ

SAA: モノリスとマイクロサービスの基本的な違い、マイクロサービス化のメリットを理解する。
SAP: Strangler Figパターンによる段階的移行、既存システムとの共存期間のデータ整合性設計、切り出し優先順位の判断ができる。

次は コンテナ化・EKS/ECSへの移行を見ていきましょう。