サービスメッシュの仕組み — 注文と在庫の通信を見守る担当

ひよこ

注文と在庫のアプリが話すところにも担当がいるの？

ペンギン先生

サービスメッシュは、サービス間の通信を管理する仕組みだよ。注文から在庫へ送る通信に、暗号化や送り先のルール、観測などを共通の仕組みとして適用するんだ。

ひよこ

アプリの横に置くのがサイドカー？

ペンギン先生

うん。Istioのサイドカーモードでは、各アプリのPodなどにEnvoyプロキシを添えるよ。対象の通信をそこへ通し、設定に従って扱う。すべての通信が無条件に取り込まれるわけではないんだ。

ひよこ

誰がプロキシのルールを決めるの？

ペンギン先生

設定を管理して配るのがコントロールプレーン、実際の通信を扱うのがデータプレーンだよ。Istioではistiodが設定などを配る。注文のデータが毎回istiodを通るわけではないよ。

ひよこ

サイドカーがない方式もある？

ペンギン先生

Istioのambientでは、ノードごとのztunnelがL4の通信を扱い、必要な対象にwaypointを加えてL7の機能を使うよ。waypointをノードごとに一つ置く方式、という説明は正しくないんだ。

ひよこ

入れれば全通信が暗号化される？

ペンギン先生

対象に入った通信と設定を確認しよう。IstioのサイドカーモードのPERMISSIVEは平文とmTLSの両方を受け入れる。mTLSを必須にする設定や適用範囲の確認が必要なんだ。

ひよこ

失敗したら再試行してくれる？

ペンギン先生

対応する経路と設定でリトライやタイムアウトを使えるよ。でも注文の作成を重複させない仕組みはアプリ側にも必要。リトライが集中して負荷を増やす場合も考えよう。

ひよこ

通信の流れも全部自動で見える？

ペンギン先生

プロキシは観測情報を出せるけれど、一つの処理としてトレースをつなぐにはアプリが追跡用のヘッダーを引き継ぐ必要があるよ。収集先やサンプリングの設定も確認するんだ。

ひよこ

小さなアプリにも入れるべき？

ペンギン先生

まず困っている通信の課題を見よう。運用する設定やプロキシも増えるし、導入だけで高速化する保証はない。必要な機能と運用できる体制から、導入や方式を選ぶといいよ。

まず、注文が在庫を確認する場面を見る

「注文を受けたアプリが、在庫のアプリへ残り数を聞く」と考えます。アプリが商品を判断する一方で、通信の経路や接続の保護などを共通の層へ任せるのがサービスメッシュの入口です。

図の実線は業務の通信、破線は設定の配布です。設定を配る司令塔へ、注文データを毎回送る図ではありません。ここでは仕組みを理解し、クラスタへの導入や設定変更は行いません。

データを運ぶ担当と、設定を配る担当

プロキシの位置や通信の取り込み方は方式ごとに異なります。サイドカーではアプリに添えて配置します。ambientではノードごとのztunnelを通し、必要ならwaypointでHTTPなどのL7機能を使います。プロキシが消えてすべてカーネル内になる、という意味ではありません。

暗号化・再試行・観測の条件を見る

Istioのサイドカーモードでは、PERMISSIVEの設定は平文とmTLSを受け入れます。暗号化を必須にしたいなら、ポリシーの適用範囲、対象に入ったワークロード、接続相手を確認します。認証できることと、その操作を許す認可も別です。

リトライは処理の再実行につながることがあります。注文などの書き込みには重複を防ぐ設計が必要です。タイムアウトや試行回数も、呼び出し全体の期限と合わせましょう。

分散トレースをつなぐには、アプリが受け取った追跡ヘッダーを後続の呼び出しへ渡す必要があります。プロキシの導入だけで、業務処理全体の追跡が必ず完成するわけではありません。

もう少し詳しく：導入する前の問い

通信先はどれだけ増えたか、共通ポリシーが必要か、観測で何を知りたいかを先に決めます。そのうえで必要な機能、対応プロトコル、方式、設定の管理体制を照合します。製品ごとの速さや重さを、条件のない順位で決めないようにしましょう。

ロードバランサーの仕組みは送り先の振り分け、サーキットブレーカーの仕組みは失敗が続く通信への対処を学べます。

ペンギン先生のまとめ

「サービスメッシュ」って出てきたら「サービス同士の通信を、共通のルールで見守る仕組み」と思えばだいたいOK！ 何を対象に、どのルールを適用したかも確かめよう。

参考資料

• Istio：Sidecar or ambient? — 二つのモードとL4/L7
• Istio：Security — PERMISSIVE・mTLS・認可
• Istio：Distributed tracing — ヘッダー伝播と観測