マイクロサービスの通信管理はIstioに任せなさい

「マイクロサービス、便利そうだから導入してみたら、サービス間の通信の管理が地獄になった」——こんな声をよく聞きます。サービスが10個、20個と増えていくと、「AがBに通信できるか」「通信が失敗したときのリトライはどうするか」「どのサービスがボトルネックか」を管理するのが急に難しくなります。これを解決するのがサービスメッシュ、そして代表的なツールが「Istio」です。

サービスメッシュをたとえで説明すると「交通整理の警官」のようなものです。車（リクエスト）がどこから来て、どこへ向かい、渋滞（レイテンシ）はどこで起きているか——これをすべて把握して制御する存在です。アプリケーションのコードを一切変えずに、通信ルール・リトライ・タイムアウト・暗号化（mTLS）を外から注入できるのがIstioの最大の魅力です。

新人エンジニアC：「サービスAからサービスBへのリクエストが時々タイムアウトするんですが、原因がわからなくて…」
シニアエンジニアD：「Istioのダッシュボード（Kiali）で通信フローを見てみよう。どのサービスがどこに通信してるか一目でわかるよ」
C：「え、コードに何も書かなくていいんですか？」
D：「Istioがサイドカーコンテナとして通信をすべて横取りしてくれるから、アプリは何も意識しなくていい」

IstioをKubernetesクラスターにインストールするにはistioctl（公式CLIツール）を使います。

# istioctlのダウンロードとインストール
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.x.x
export PATH=$PWD/bin:$PATH

# クラスターへのインストール（デモプロファイルで試す場合）
istioctl install --set profile=demo -y

# 名前空間にIstioサイドカー自動注入を有効化
kubectl label namespace default istio-injection=enabled

これだけで、defaultネームスペースにデプロイされるすべてのPodに「Envoyプロキシ」がサイドカーとして自動注入されます。アプリケーション間のすべての通信がこのプロキシを経由するようになります。

次に、たとえばサービスAからサービスBへの通信が失敗したとき、3回まで自動でリトライするルールをYAMLで定義してみましょう。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: service-b
spec:
  hosts:
  - service-b
  http:
  - retries:
      attempts: 3
      perTryTimeout: 2s
    timeout: 10s
    route:
    - destination:
        host: service-b

このYAMLをapplyするだけで、コードを一行も変えることなくリトライとタイムアウトが設定できます。「交通整理の警官」が「3回まで迂回路を試してから諦める」ルールを持つようになったイメージです。サービスが増えるほどIstioの恩恵は大きくなります。マイクロサービス化を進めるなら、早めにサービスメッシュの導入を検討しましょう。