サービスメッシュはどう動く？マイクロサービス間通信の裏側

マイクロサービス同士が通信するとき、その間に入って通信を管理してくれるインフラ層のことだよ。サービスが10個、50個と増えてくると、誰が誰と通信してるか把握するのが大変になるよね。それを全部まとめて面倒見てくれる仕組みなんだ。

マイクロサービスが増えると、通信の暗号化、障害時のリトライ、トラフィックの制御、どこで遅延が起きてるかの可視化…これを全サービスに個別実装するのは大変すぎるんだよ。サービスメッシュを入れれば、アプリのコードを変えずにこれらを一括で管理できるんだ。

バイクの横に付けるサイドカーをイメージしてみて。各サービスの隣にEnvoyっていう軽量プロキシが1つずつ配置されるんだよ。サービスAからBに通信するとき、AのサイドカーがリクエストをキャッチしてBのサイドカーに転送し、BのサイドカーがBに渡す。全通信がこのサイドカー経由になるから、暗号化もリトライも一箇所で制御できるんだ。

データプレーンは実際にデータを運ぶ部分、つまりさっき説明したEnvoyサイドカーの集合体だよ。コントロールプレーンはそのサイドカーたちに設定を配る司令塔。Istioだとistiodっていうコンポーネントがコントロールプレーンの役割を果たしていて、ルーティングルールや証明書の配布を一元管理してるんだ。

たとえばカナリアリリース。新バージョンにまず全体の5%だけトラフィックを流して、問題なければ徐々に増やすとかね。あとサーキットブレーカーで、障害のあるサービスへの通信を自動遮断したり、リトライやタイムアウトのポリシーをYAMLで設定するだけで全サービスに適用できるよ。

mTLSが大きいね。サービス間の通信を自動的に暗号化して、お互いの身元も証明書で確認する。ゼロトラストセキュリティの考え方で、同じクラスタ内でも信頼せず全通信を暗号化するんだ。サービスメッシュならアプリコードを一行も変えずにこれが実現できるよ。

そうそう。全通信がサイドカーを通るから、分散トレーシングでリクエストがどのサービスをどの順番で通ったかを追跡できるし、レイテンシやエラー率のメトリクスも自動収集されるんだ。障害が起きたとき『どこで遅延してるか』が一目でわかるのは運用者にとって本当にありがたいよ。

Istioは機能が豊富で大規模環境に強いけど、設定が複雑で学習コストが高い。Linkerdはシンプルで軽量、Rustで書かれたプロキシを使っていてリソース消費が少ないんだ。最近はCilium Service Meshっていう第三の選択肢も注目されていて、eBPFというLinuxカーネル技術を使ってサイドカー自体を不要にするアプローチなんだよ。

eBPFベースのメッシュはカーネルレベルで通信を処理するから、サイドカーのオーバーヘッドがなくなってパフォーマンスが向上するんだ。Istioもアンビエントメッシュっていうモードを導入していて、サイドカーの代わりにウェイポイントプロキシをノード単位で配置する方式に移行しつつあるよ。サービスメッシュはまだまだ進化の途中だね。

2026年時点では併存している状態だね。サイドカー方式は成熟していて実績が豊富、eBPFやアンビエントメッシュは新しくて高性能だけどまだ機能面で追いついていない部分もある。大事なのは自分のチームの規模や運用力に合ったものを選ぶことで、マイクロサービスが5個程度ならサービスメッシュ自体がオーバースペックかもしれない。ツールに振り回されず、課題に合った道具を選ぶのがエンジニアの腕の見せどころだよ。