ある企業が大規模なモノリシック Java アプリケーション（Spring Boot）を段階的にマイクロサービス化する計画を立てています。現在のアプリケーションはリレーショナルデータベース（PostgreSQL）に強く依存しており、モノリス内の多数のモジュールが同じテーブルを共有しています。モダナイゼーションの第一ステップとして、新しい機能は独立したマイクロサービスとして開発し、将来的には既存のモノリスの機能も順次切り出す予定です。この「ストラングラーフィグ」アプローチで最も一般的な技術的課題はどれですか？
- A. モノリスと新しいマイクロサービスが同じデータベーステーブルを共有すると、データの整合性とスキーマ管理が複雑になる。解決策として、新しいマイクロサービスは独自のデータベース（Database per Service パターン）を持ち、モノリスとの同期は非同期イベント（EventBridge、SNS/SQS）または API レイヤー経由で行うことが推奨される
- B. API Gateway は既存のモノリスのエンドポイントと新しいマイクロサービスのエンドポイントを同時に管理できない
- C. マイクロサービスの開発言語はモノリスと同じ Java にする必要がある
- D. コンテナ化されたマイクロサービスは EC2 ベースのモノリスと共存できない
解答と解説を見る
正解: A
ストラングラーフィグパターンで最も一般的な技術的課題は「共有データベース（Shared Database）」問題です。モノリスと新しいマイクロサービスが同じテーブルを共有すると、スキーマ変更の影響範囲が広がり、マイクロサービスの独立したデプロイが困難になります。Database per Service パターン（各サービスが専用 DB を持つ）と非同期イベント連携がこの問題の標準的な解決策です。 C: マイクロサービスは任意の言語で開発できます（多言語アーキテクチャ）。モノリスと同じ言語にする必要はありません。 B: API Gateway はモノリスと新しいマイクロサービスの両方をバックエンドとして設定でき、ルーティングルールで切り替えられます。 D: コンテナ化されたマイクロサービスと EC2 ベースのモノリスは完全に共存できます。ネットワークレベルでの通信が可能です。
📚 関連サービスの解説: Amazon EventBridge ・ Amazon SNS