ネットワーク＠マイクロサービスアーキテクチャ¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. マイクロサービス間通信の方式¶
リクエストリプライ方式¶
▼ リクエストリプライ方式とは¶
マイクロサービス間で相互通信を実行する。
送信側と受信側で通信処理が同時に実行されるため、HTTPやgRPCによる同期通信を実行することになる。
また、マイクロサービス間で直接的にリクエストを送受信することになる。
▼ 直接的な通信¶
リクエストリプライ方式では、直接的にマイクロサービス間の通信を実行する。
使用することのできる通信プロトコルは以下の通りである。
| プロコトル | 説明 |
|---|---|
| 従来のTCP/IP | 従来のTCP/IPプロトコルを使用する。 |
| gRPC | HTTP/1.1に代わるHTTP/2.0 (例：gRPCなど) を使用する。HTTPプロトコルであると、通信相手のマイクロサービスのエンドポイントをコールした後、エンドポイントに紐づくコントローラーのメソッドが実行される。一方でgRPCであると、通信相手のマイクロサービスのメソッドを直接的に実行できる。そのため、HTTPよりもマイクロサービスの連携に適している。・https://techdozo.dev/grpc-for-microservices-communication/ |
イベント駆動方式¶
▼ イベント駆動方式とは¶
マイクロサービスからマイクロサービスに一方通行の通信を実行する。
送信側と受信側で通信処理が独立して実行されるため、メッセージキューを介した非同期通信を実行することになる。
▼ メッセージキューを介した通信¶
イベント駆動方式では、メッセージキューを介してマイクロサービス間の通信を実行する。
メッセージキューにより、マイクロサービスの通信の方向が一方向になるように制限できる。
特に、複数のダウンストリーム側マイクロサービスからのリクエストを集約するようなアップストリーム側マイクロサービスがある場合、その前段にメッセージキューを配置すれば、アップストリーム側のマイクロサービスのレートリミットを超過しないように、一定の間隔で通信を転送できる。
もしマイクロサービス間双方向に送信したい場合は、ダウンストリーム側マイクロサービスからメッセージを受信するメッセージキューと、アップストリーム側マイクロサービスから受信するメッセージキューを、別々に配置する。
メッセージキュー (例：AWS SQS、など) やメッセージブローカー (例：Apache Kafka、など) を使用する。
02. 通信に伴う処理¶
タイムアウト時間¶
▼ マイクロサービスだけに着目する場合¶
ダウンストリーム側マイクロサービスよりもアップストリーム側マイクロサービスのタイムアウト時間を短くする。
MS # 45秒
⬇⬆︎︎
⬇⬆︎︎︎︎
MS # 30秒
⬇⬆︎︎
⬇⬆︎︎
MS # 15秒
▼ サイドカープロキシにも着目する場合¶
ダウンストリーム側マイクロサービスよりもサイドカーのタイムアウト時間を短くする。
また、サイドカーよりもアップストリーム側マイクロサービスのサイドカーのタイムアウト時間を短くする。
MS # 45秒
⬇⬆︎︎
⬇⬆︎︎
サイドカー # 44秒
⬇⬆︎︎
--------------
⬇⬆︎︎
サイドカー # 31秒
⬇⬆︎︎
⬇⬆︎︎
MS # 30秒
⬇⬆︎︎
⬇⬆︎︎
サイドカー # 29秒
⬇⬆︎︎
--------------
⬇⬆︎︎
サイドカー # 16秒
⬇⬆︎︎
⬇⬆︎︎
MS # 15秒
03. 障害対策¶
ロードバランシング¶
▼ サーキットブレイカー¶
アップストリーム側マイクロサービスに障害が発生した時に、ダウンストリーム側マイクロサービスにエラーを返してしまわないよう、一旦マイクロサービスへのルーティングを停止し、直近の成功時の処理結果を返信する。
マイクロサービス間に配置され、他のマイクロサービスに連鎖的に起こる障害 (カスケード障害) を吸収する仕組みのこと。
blast-radiusを最小限にできる。
