マイクロサービスアーキテクチャ
モノリシックアーキテクチャとの違い・サービス分割の原則・通信パターン・クラウド実装例を解説します。
マイクロサービスとは
マイクロサービスアーキテクチャとは、アプリケーションを「独立してデプロイ・スケール可能な小さなサービス群」に分割する設計パターンです。各サービスは独自のデータベースを持ち、API（REST/gRPC）またはメッセージキューで通信します。
モノリシックアーキテクチャでは 1 つのコードベースが全機能を担いますが、マイクロサービスでは機能単位のサービスに分割することで、チームごとの独立した開発・デプロイ・スケーリングが可能になります。Netflix・Amazon・Uber 等の大規模サービスが採用したことで広く知られるようになりました。
モノリス vs マイクロサービス
| 観点 | モノリス | マイクロサービス |
|---|---|---|
| 初期開発速度 | 速い（シンプル） | 遅い（インフラ準備が多い） |
| スケーラビリティ | 全体をスケール（非効率） | ボトルネックのみ独立スケール |
| デプロイ | 全体を一括デプロイ | サービスごとに独立デプロイ |
| 技術選定 | 統一（言語・フレームワーク固定） | サービスごとに最適技術を選択可 |
| 運用複雑性 | 低い（シンプル） | 高い（分散システムの複雑性） |
| チーム構成 | 小規模チームに向く | 複数チームの並列開発に向く |
サービス分割の原則
Bounded Context（境界付けられたコンテキスト）ごとにサービスを分割します。例：ECサイトなら「商品管理・在庫・注文・決済・配送・ユーザー」がそれぞれ独立したサービス候補です。境界はビジネスドメインに合わせて決定し、技術的な都合で分割しないことが重要です。
各サービスは「一つのことだけをうまくやる」設計にします。サービスが複数の責任を持ち始めたら分割のサインです。逆に、変更が常に同時に発生する機能は同一サービスにまとめる（凝集度を高める）のが原則です。
サービス間の API 変更時は後方互換性を維持し、他サービスの再デプロイなしに変更を反映できる設計にします。API バージョニング（/v1/、/v2/）やコンシューマ駆動契約テストが有効です。
サービス間通信パターン
HTTP/HTTPS で JSON を送受信する最も一般的なパターン。実装が容易でデバッグしやすい。呼び出し先サービスの可用性に依存するため、サーキットブレーカー（Hystrix / Resilience4j）パターンで障害伝播を防ぐ。
Protocol Buffers でシリアライズした HTTP/2 通信。JSON より高速・低オーバーヘッド。強い型付けでサービス間の契約を明確化。Kubernetes 環境のサービス間通信で特に有効。
SQS・SNS・Kafka・RabbitMQ 等のメッセージブローカーを経由して非同期通信。疎結合・耐障害性が高く、流量制御も容易。Saga パターンで分散トランザクションを実現。
クラウド実装例（AWS）
外部クライアントからの単一エントリポイント。認証（Cognito Authorizer）・スロットリング・ルーティングを担当。
各マイクロサービスをコンテナとして独立実行。サービスごとに異なる言語・ランタイムを選択可。EKS（Kubernetes）はサービスメッシュ（Istio/App Mesh）による通信制御・可観測性が充実。
各サービスに専用の ALB を配置し、独立したスケーリングとヘルスチェックを実現。ターゲットグループで Blue/Green デプロイを実装。
サービス間の非同期通信にSQS FIFO キューを使用。EventBridge でサービス間のイベント駆動通信とルーティングを実装。
分散トレーシング（X-Ray）でサービス間の呼び出しチェーンを可視化。CloudWatch Container Insights でサービスごとのメトリクス監視。
適用判断基準
- •スタートアップ・MVP など初期フェーズ
- •チームが 5〜10 名以下の小規模
- •ドメインの境界がまだ明確でない
- •分散システムの運用経験がない
- •早急な市場投入が最優先
- •複数チームが並列開発する規模（20名以上）
- •機能ごとにスケール要件が大きく異なる
- •頻繁なリリースサイクルが必要
- •モノリスのデプロイが遅く・リスクが高い
- •サービスごとに異なる技術スタックが必要
ArchitectAI でクラウドアーキテクチャ設計を自動化しましょう
無料で始める（10クレジット）