Istio のトラフィックミラーリング
k8s クラスタに Service Mesh として Istio をデプロイした後は、Envoy プロキシがトラフィックを転送する特性を利用して、設定ファイルに数行追加するだけでトラフィックミラーリングを有効にできます。ミラーリングされたトラフィックのレスポンスはクライアントに返らず、既存の業務コードに対して完全に透過的です。うまく使えば本番環境で大きな価値を発揮します。
トラフィックミラーリングとは
トラフィックミラーリングはシャドウトラフィック（Shadow Traffic）とも呼ばれます。Envoy がクライアントのリクエストを実サービスに転送すると同時に、コピーを 1 つ作って指定のミラーサービスに送信します。ポイントは 2 つあります。
1）ミラーリクエストは「送りっぱなし」（fire-and-forget）です。Envoy はミラーサービスのレスポンスを待たず、ましてやそれをクライアントに返すこともありません。ミラーサービスの処理が遅くても、エラーになっても、ダウンしても、メインの経路には影響しません。
2）ミラーリングはトラフィックが業務コンテナに入る前に Sidecar プロキシによって行われるため、業務コードには一切の変更が不要で、ミラートラフィックを受け取るサービスをもう 1 セットデプロイするだけで済みます。
公式ドキュメントはこちら:镜像
典型的なユースケース
1、テスト環境:テストバージョンのコンテナサービスが本番インスタンスの実トラフィックを使うことができ、本番の重要な経路には影響しません。例えばステージング環境でリアルタイムのテスト検証をより適切に行えるようになり、リリース後に発生するさまざまな異常を減らし、開発チームにリリースへのより強い自信を与えてくれます 😂。リリースはほぼ見通しの立った状態にでき、夜遅くまで残業してデプロイする必要もなくなります。
2、データ収集:リクエスト情報を同期的に収集できるので、別のコンテナでリスク管理分析やログ記録を行い、対応するユーザープロファイル情報を得ることができます。
3、パフォーマンスと互換性の検証:新バージョンのサービス、リファクタリング後の API、フレームワークや依存を入れ替えた実装は、まずミラートラフィックでしばらく「並走」させ、新旧両側のログとメトリクスを比較し、挙動が一致することを確認してから正式にトラフィックを切り替えられます。
4、問題の再現:本番でまれに発生する異常なリクエストはテスト環境で再現するのが難しいものですが、詳細ログやデバッグスイッチを有効にしたインスタンスにトラフィックをミラーリングすれば、一次情報の現場をそのまま手に入れられます。
設定方法
Istio ではトラフィックミラーリングは VirtualService の mirror フィールドで宣言します。httpbin サービスに v1、v2 の 2 つのバージョンがあり、v1 に来るトラフィックのコピーを v2 にミラーリングしたい場合、書き方はおおよそ次のようになります。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- httpbin
http:
- route:
# 実トラフィック:すべて v1 に転送し、レスポンスをクライアントに返す
- destination:
host: httpbin
subset: v1
weight: 100
# ミラートラフィック:コピーを v2 に送り、レスポンスは破棄される
mirror:
host: httpbin
subset: v2
# ミラーリングのサンプリング比率。未指定ならデフォルト 100%
mirrorPercentage:
value: 100.0
各フィールドの意味は次のとおりです。
1）route.destination はメインルートで、実リクエストを誰に送るかを決めます。クライアントが受け取るのはこのレスポンスです。
2）mirror はミラーリング先を指定します。同じく host + subset の組み合わせで、subset は事前に DestinationRule で定義しておく必要があります。
3）mirrorPercentage はミラーリングのサンプリング比率を制御します。ミラーリング先のキャパシティが本番より小さい場合は、いきなり 100% にするより、1%、10% のように段階的に増やしていくほうがずっと安全です。
設定を書き終えたら kubectl apply -f で反映され、業務 Pod の再起動は一切不要です。これも Sidecar 方式の利点の一つです。
ハマりどころと注意点
1）ミラートラフィックの Host ヘッダには -shadow サフィックスが付加されます。例えば httpbin:8000 は httpbin-shadow:8000 になります。ミラーサービスが Host の検証やルーティングをしている場合は、この差異を事前に処理しておく必要があります。逆に、このサフィックスはログの中で実トラフィックとシャドウトラフィックを区別するのにも使えます。
2）ミラーリングされるのはリクエストであって、冪等性ではありません。書き込み系 API がミラーリングされると、シャドウ環境でもう一度実行されます。ミラーサービスが同じデータベース、同じ下流につながっていると、重複書き込みやサードパーティへの重複呼び出しを引き起こす可能性があります。ミラーサービスには独立したデータソースをつなぐか、ミラー側で書き込み操作をインターセプトするかのどちらかが必要です。
3）ミラーリングは送信帯域と Envoy のオーバーヘッドを増幅します。リクエストボディが大きい、QPS が高いサービスでは特に顕著なので、まず mirrorPercentage を小さい比率にして検証してから増やしましょう。
4）ミラーサービスのエラーはクライアントに影響しません。これは利点であると同時に盲点でもあります——シャドウ環境が落ちてもユーザーは気づかないため、別途監視とアラートを設定する必要があります。さもないと「並走」がとっくに止まっていたのに誰も気づかない、ということになりかねません。
まとめ
トラフィックミラーリングは「本番トラフィックで検証する」というリスクの高い行為を、低コストな操作に変えてくれます。VirtualService の設定を一つ書くだけで、業務コードはゼロ変更、メイン経路への影響もゼロです。ステージング検証、リスク管理分析、問題の再現といったシナリオはどれも恩恵を受けられます。主に気をつけるべきは、書き込み操作の副作用、Host ヘッダの -shadow サフィックス、そしてミラー側自身の監視です。この数点をきちんと処理すれば、常備しておく価値のある非常に優れたツールになります。
COMMENTS