ネットワーク＠マイクロサービスアーキテクチャ¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. リクエスト/レスポンスパターン¶
リクエスト/レスポンスパターンとは¶
マイクロサービス間で同期的に双方向で通信を実行する。
ドメインモデリングは、ステートソーシングパターンになる。
送信元と宛先で通信処理が同時に実行されるため、HTTPやgRPCによる同期通信を実行することになる。
また、マイクロサービス間で直接的にリクエストを送受信することになる。
使用することのできる通信プロトコルは以下の通りである。
| プロコトル | 説明 |
|---|---|
| 従来のTCP/IP | 従来のTCP/IPプロトコルを使用する。 |
| gRPC | HTTP/1.1に代わるHTTP/2 (例：gRPCなど) を使用する。HTTPプロトコルであると、通信相手のマイクロサービスのエンドポイントをコールした後、エンドポイントに紐づくコントローラーのメソッドが実行される。一方でgRPCであると、通信相手のマイクロサービスのメソッドを直接的に実行できる。そのため、HTTPよりもマイクロサービスの連携に適している。 ・https://techdozo.dev/grpc-for-microservices-communication/ |
リクエスト駆動型マイクロサービス¶
リクエスト/レスポンスパターンで稼働するマイクロサービスアーキテクチャのこと。
仲介コンポーネント¶
▼ ポイントツーポイントの場合¶
マイクロサービス間で直接的に通信する。
メッセージキューやメッセージブローカーを経由するよりも、各マイクロサービスの結合度が高まってしまう。
一方で、マイクロサービスの実装が簡単になる。
▼ メッセージキューやメッセージブローカーを経由する場合¶
メッセージキュー (例：AWS SQSなど) やメッセージブローカー (例：Apache Kafka、RabbitMQなど) を経由して、マイクロサービス間で通信する。
宛先マイクロサービスが永続化の責務を担っている場合は、処理の開始/終了を担保して処理完了の確実性を担保したがいい。
そのため、リクエスト/レスポンスパターンであってもマイクロサービス間に双方向のメッセージブローカーを設置する。
例えば、リクエスト/レスポンスパターンでオーケストレーションベースSagaパターンを採用する場合がある。
Sagaオーケストレーターの後続マイクロサービスの間にメッセージブローカーを置くのは、後続マイクロサービスのローカルトランザクションを確実に完了するためである。
タイムアウト時間¶
▼ マイクロサービスだけに着目する場合¶
ダウンストリーム側マイクロサービスよりもアップストリーム側マイクロサービスのタイムアウト時間を短くする。
マイクロサービス # 45秒
⬇⬆︎︎
⬇⬆︎︎︎︎
マイクロサービス # 30秒
⬇⬆︎︎
⬇⬆︎︎
マイクロサービス # 15秒
▼ サイドカープロキシにも着目する場合¶
ダウンストリーム側マイクロサービスよりもサイドカーのタイムアウト時間を短くする。
また、サイドカーよりもアップストリーム側マイクロサービスのサイドカーのタイムアウト時間を短くする。
アプリ # 45秒
⬇⬆︎︎
⬇⬆︎︎
サイドカー # 44秒
⬇⬆︎︎
-------------- # マイクロサービス間の境界
⬇⬆︎︎
サイドカー # 31秒
⬇⬆︎︎
⬇⬆︎︎
アプリ # 30秒
⬇⬆︎︎
⬇⬆︎︎
サイドカー # 29秒
⬇⬆︎︎
-------------- # マイクロサービス間の境界
⬇⬆︎︎
サイドカー # 16秒
⬇⬆︎︎
⬇⬆︎︎
アプリ # 15秒
サーキットブレイカー¶
マイクロサービス間の通信方式がリクエストロプライパターンの場合の障害対策である。
アップストリーム側マイクロサービスで問題が起こると、ダウンストリーム側マイクロサービスはタイムアウトになるまで処理を待機する。
その間、ダウンストリーム側マイクロサービスは他の処理を実行できなくなってしまうため、これを防ぐ。
- アップストリーム側マイクロサービスに障害 (あるいは設定した閾値の超過) が発生する
- アップストリーム側マイクロサービスへのルーティングを停止し、エラーのステータス (
503など) をダウンストリーム側マイクロサービスに返信する。 - 障害が回復次第、ルーティングを再開する。
blast-radiusを最小限にできる。
02. パブリッシュ/サブスクライブパターン¶
パブリッシュ/サブスクライブパターンとは¶
マイクロサービスからマイクロサービスに非同期的に一方向で通信する。
ドメインモデリングは、イベントソーシングパターンになる。
送信元と宛先で通信処理が独立して実行されるため、メッセージキューやメッセージブローカーを経由した非同期通信を実行することになる。
送信元マイクロサービスはメッセージブローカーやメッセージキューにメッセージをパブリッシュする。
サブスクライブには、宛先マイクロサービスによるプルベースと、メッセージブローカーやメッセージキューによるプッシュベース、がある。
- https://en.wikipedia.org/wiki/Message_queue
- https://qiita.com/yasuabe2613/items/3bff44e662c922083264#%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%83%B3%E3%82%B0%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB%E3%81%AE%E5%95%8F%E9%A1%8C%E9%A0%98%E5%9F%9F
- https://aiven.io/blog/introduction-to-event-based-programming#asynchronous-request-response-with-events
仲介コンポーネント¶
▼ ポイントツーポイントの場合¶
このパターンは存在しない。
▼ メッセージキューやメッセージブローカーを経由する場合¶
メッセージキュー (例：AWS SQSなど) やメッセージブローカー (例：Apache Kafka、RabbitMQなど) を経由して、マイクロサービス間で通信する。
モデリングがイベントソーシングの場合は、各マイクロサービスは非同期で通信した方がよく、一方向のメッセージブローカーを設置する。
特に、複数のダウンストリーム側マイクロサービスからのリクエストを集約するようなアップストリーム側マイクロサービスがある場合、そのダウンストリームにメッセージブローカーを配置すれば、アップストリーム側マイクロサービスのレートリミットを超過しないように、一定の間隔で通信を転送できる。
もしマイクロサービス間双方向に送信したい場合は、ダウンストリーム側マイクロサービスからメッセージを受信するメッセージブローカーと、アップストリーム側マイクロサービスから受信するメッセージブローカーを、別々に配置する。
イベント駆動型マイクロサービス¶
パブリッシュ/サブスクライブパターンで稼働するマイクロサービスアーキテクチャのこと。