はじめに
マイクロサービスが相互に通信する方法によって、システム全体の結合、信頼性、およびパフォーマンスが決まります。この記事では、通信パターンを分析し、各ユースケースに適切なパターンを選択するためのガイドを示します。
1. 同期通信
1.1 要求と応答のパターン
┌──────────┐ HTTP/gRPC ┌──────────┐
│ Order │ ──────────────►│ Product │
│ Service │◄────────────── │ Service │
└──────────┘ Response └──────────┘
Order Service gọi Product Service để validate product trước khi tạo order.
Phải đợi response → coupling tạm thời (temporal coupling).
利点:
- シンプル、分かりやすく、デバッグが簡単
- すぐに対応
- 明示的なエラー処理 (HTTP ステータス コード)
短所:
- 時間的結合: 応答を受信するまで発信者はブロックされます
- カスケード障害: 製品サービスがダウンした場合 → 注文サービスも失敗します
- 呼び出しチェーン内のホップごとに遅延が増加します
1.2 同期のリスクを最小限に抑える
- サーキット ブレーカー: ダウンストリーム サービスに障害が発生したときに回線を遮断します
- タイムアウト: 適切なタイムアウトを設定します (長すぎない)
- バックオフを使用して再試行: 指数バックオフを使用して再試行します
- フォールバック: キャッシュされたデータまたはデフォルトの応答を返します。
- バルクヘッド: ダウンストリームごとに接続プールを分離します。
2. 非同期通信
2.1 メッセージキューのパターン
┌──────────┐ Enqueue ┌──────────┐ Dequeue ┌──────────┐
│ Order │ ──────────────►│ Queue │──────────────►│ Email │
│ Service │ │(RabbitMQ)│ │ Service │
└──────────┘ └──────────┘ └──────────┘
Fire-and-forget: Order Service gửi message, không đợi.
Email Service xử lý khi sẵn sàng (rate riêng).
Queue đảm bảo message không mất.
使用例:
- タスク分散（メール送信、画像リサイズ）
- ワークキュー (ビデオの処理、レポートの生成)
- 負荷平準化（トラフィックの急増を吸収）
2.2 イベント ストリーミング / Pub-Sub パターン
┌──────────┐ ┌──────────────┐
│ Order │──publish──────►│ Kafka │
│ Service │ OrderPlaced │ Topic: │
└──────────┘ │ orders │
└──┬───┬───┬───┘
│ │ │
┌──────────┘ │ └──────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Payment │ │Inventory │ │ Email │
│ Service │ │ Service │ │ Service │
└──────────┘ └──────────┘ └──────────┘
1 event → N consumers. Services không biết nhau → loose coupling.
Events được lưu trữ → có thể replay (event sourcing).
使用例:
- ドメイン イベント (OrderPlaced、Paymentconfirmed)
- サービス間でのデータ レプリケーション
- イベントソーシングと監査証跡
- リアルタイム分析
2.3 イベント通知とイベント伝達による状態転送
| パターン | イベントの内容 | 消費者は何を必要としているのか |
|---|---|---|
| イベントのお知らせ | IDのみ： {orderId: "123"} | ソース サービスを再度クエリする |
| イベントが発生した状態 | 完全なデータ: {orderId, items, total, ...} | 再度クエリする必要はありません |
推奨事項: Event-Carried State Transfer は結合を軽減するのに役立ちます (コンシューマはソースを再度呼び出す必要がありません)。
3. メッセージ ブローカーを比較する
| 特長 | ラビットMQ | アパッチカフカ | ナッツ |
|---|---|---|---|
| モデル | メッセージキュー | イベントストリーム/ログ | Pub/Sub + JetStream |
| 注文 | キューごと | パーティションごと | 主題ごと |
| 保持 | 消費→削除 | 設定可能 (日数/永久) | JetStream: 設定可能 |
| スループット | ~50,000 メッセージ/秒 | ~100万メッセージ/秒 | ~10M メッセージ/秒 |
| リプレイ | いいえ | はい (オフセットベース) | ジェットストリーム: はい |
| 消費者グループ | はい | はい | ジェットストリーム: はい |
| 複雑さ | 平均 | 高 (ZooKeeper/KRaft) | 低い |
| こんな用途に最適 | タスクキュー、RPC | イベントストリーミング、ソーシング | クラウドネイティブ、軽量 |
3.1 いつ何を使用するか?
RabbitMQ: Task queues (send email, process image)
Request-Reply pattern (RPC over messages)
Complex routing (exchanges, bindings)
Kafka: Domain events (OrderPlaced, PaymentConfirmed)
Event sourcing & CQRS
Data pipeline & streaming analytics
Audit trail (event log)
NATS: Lightweight microservices communication
Real-time messaging (chat, notifications)
Cloud-native, Kubernetes-native
Request-Reply + Pub/Sub combined
4. ハイブリッドアプローチ (生産パターン)
実際には、ほとんどのシステムは 両方の組み合わせ を使用します。
┌─────────────────────────────────────────────────┐
│ E-Commerce Communication │
├─────────────────────────────────────────────────┤
│ SYNCHRONOUS (REST/gRPC): │
│ • GET product details (query, cần response ngay)│
│ • Validate payment (command, cần kết quả) │
│ • Search products (query, real-time) │
├─────────────────────────────────────────────────┤
│ ASYNCHRONOUS (Kafka Events): │
│ • OrderPlaced → trigger Payment, Inventory │
│ • PaymentConfirmed → trigger Shipping │
│ • UserRegistered → trigger Welcome Email │
│ • ProductUpdated → update Search Index │
└─────────────────────────────────────────────────┘
概要
| パターン | いつ使用するか | トレードオフ |
|---|---|---|
| 同期 (REST/gRPC) | 即時応答が必要、データを問い合わせる | 密結合、カスケード障害 |
| 非同期キュー | タスク分散、負荷平準化 | 最終的な整合性 |
| 非同期イベント | ドメイン イベント、データ同期 | 複雑さ、デバッグが難しい |
| ハイブリッド | 制作推奨 | 両方を管理する必要がある |