ベストプラクティス：サービスメッシュのパフォーマンスベンチマーク
Istioのデータプレーンのパフォーマンスを評価するためのツールとガイダンス。
サービスメッシュは、トラフィックポリシー、オブザーバビリティ、セキュアな通信など、アプリケーションのデプロイに多くの機能を追加します。ただし、環境にサービスメッシュを追加するには、時間（レイテンシの増加）またはリソース（CPUサイクル）のコストがかかります。サービスメッシュがユースケースに適しているかどうかを判断するには、サービスメッシュでデプロイされたアプリケーションのパフォーマンスを評価することが重要です。
今年初めに、Istioバージョン1.1のパフォーマンス向上に関するブログ記事を公開しました。Istio 1.2のリリースに続き、本番環境に対応したKubernetes環境でIstioのデータプレーンのパフォーマンスをベンチマークするのに役立つガイダンスとツールを提供します。
全体的に、Istioのサイドカープロキシのレイテンシは、同時接続数に比例して増加することがわかりました。1秒あたり1000リクエスト（RPS）、16接続の場合、Istioはリクエストごとに50パーセンタイルで**3ミリ秒**、99パーセンタイルで**10ミリ秒**を追加します。
Istioツールリポジトリには、Istioのデータプレーンのパフォーマンスを測定するためのスクリプトと手順があり、別のサービスメッシュ実装であるLinkerdでスクリプトを実行する方法に関する追加手順も含まれています。パフォーマンス テスト フレームワークの各手順のベスト プラクティスを詳しく説明しているため、手順に従ってください。
1. 本番環境に対応したIstioインストールを使用する
大規模なサービスメッシュのパフォーマンスを正確に測定するには、適切なサイズのKubernetesクラスターを使用することが重要です。4つ以上のvCPUと15 GBのメモリを搭載した3つのワーカーノードを使用してテストを行います。
次に、そのクラスターで本番環境に対応したIstioの**インストールプロファイル**を使用することが重要です。これにより、コントロールプレーンポッドの自動スケーリングなどのパフォーマンス指向の設定を実現し、リソース制限が大量のトラフィック負荷に適していることを保証します。デフォルトのIstioインストールは、ほとんどのベンチマークユースケースに適しています。数千のプロキシ挿入サービスを使用した広範なパフォーマンスベンチマークのために、Istioコントロールプレーンに追加のメモリとCPUを割り当てる調整されたIstioインストールも提供しています。
Istioのデモインストールは、小規模な試用クラスターにデプロイするように設計されており、Istioの機能を紹介するために完全なトレースとアクセスログが有効になっているため、パフォーマンステストには適していません。
2. データプレーンに焦点を当てる
ベンチマークスクリプトは、Istioデータプレーン、つまりアプリケーションコンテナ間のトラフィックを仲介するEnvoyプロキシの評価に焦点を当てています。なぜデータプレーンに焦点を当てるのでしょうか？それは、大規模なアプリケーションコンテナでは、データプレーンの**メモリ**と**CPU**の使用量がIstioコントロールプレーンの使用量をすぐに上回るためです。これがどのように発生するか、例を見てみましょう。
2,000個のEnvoy挿入ポッドを実行し、それぞれが1秒あたり1,000リクエストを処理するとします。各プロキシは50 MBのメモリを使用しており、これらすべてのプロキシを設定するために、Pilotは1 vCPUと1.5 GBのメモリを使用しています。合計で、Istioデータプレーン（すべてのEnvoyプロキシの合計）は100 GBのメモリを使用していますが、Pilotは1.5 GBです。
**レイテンシ**の理由から、データプレーンのパフォーマンスに焦点を当てることも重要です。これは、ほとんどのアプリケーションリクエストがコントロールプレーンではなく、Istioデータプレーンを通過するためです。2つの例外があります。
- **テレメトリレポート：**各プロキシは生のテレメトリデータをMixerに送信し、Mixerはメトリック、トレース、その他のテレメトリに処理します。生のテレメトリデータはアクセスログに似ているため、コストがかかります。アクセスログの処理はCPUを消費し、ワーカースレッドが次の作業単位を取得できないようにします。スループットが高いほど、次の作業単位がキューでワーカーによって取得されるのを待機している可能性が高くなります。これは、Envoyのロングテール（99パーセンタイル）レイテンシにつながる可能性があります。
- **カスタムポリシーチェック：**カスタムIstioポリシーアダプターを使用する場合、ポリシーチェックはリクエストパス上にあります。これは、データパス上のリクエストヘッダーとメタデータがコントロールプレーン（Mixer）に送信されるため、リクエストレイテンシが長くなることを意味します。**注：**最も一般的なポリシーユースケース（RBAC）はEnvoyプロキシによって完全に実行されるため、これらのポリシーチェックはデフォルトで無効になっています。
Mixer V2がすべてのポリシーとテレメトリ機能をプロキシに直接移動すると、これらの例外はどちらも将来のIstioリリースで解消されます。
次に、Istioのデータプレーンのパフォーマンスを大規模にテストする場合、リクエスト/秒の増加だけでなく、**同時**接続数の増加に対してもテストすることが重要です。これは、現実世界のハイスループットトラフィックが複数のクライアントから発生するためです。提供されているスクリプトを使用すると、任意の数の同時接続で、RPSを増加させながら、同じ負荷テストを実行できます。
最後に、テスト環境では、多数のポッドではなく、2つのポッド間のリクエストを測定します。クライアントポッドは、サーバーポッドにトラフィックを送信するFortioです。
2つのポッドのみでテストするのはなぜでしょうか？スループット（RPS）と接続（スレッド）をスケールアップすると、サービスレジストリの合計サイズ、つまりKubernetesクラスター内のポッドとサービスの合計数を増やすよりも、Envoyのパフォーマンスに大きな影響を与えるためです。サービスレジストリのサイズが大きくなると、Envoyはより多くのエンドポイントを追跡する必要があり、リクエストごとの検索時間は増加しますが、ごくわずかな定数です。サービスが多く、この定数がレイテンシの懸念事項になる場合は、Istioは各Envoyが認識するサービスを制限できるSidecarリソースを提供します。
3. プロキシの有無にかかわらず測定する
相互TLS認証など、多くのIstio機能はアプリケーションポッドの横にあるEnvoyプロキシに依存していますが、一部のメッシュサービスのサイドカープロキシ挿入を選択的に無効にすることができます。本番環境向けにIstioをスケールアップする場合は、ワークロードにサイドカープロキシを段階的に追加することをお勧めします。
そのため、テスト スクリプトは3 つの異なるモードを提供します。これらのモードは、リクエストがクライアントとサーバーの両方のプロキシ (both)、サーバープロキシのみ (serveronly)、どちらのプロキシも経由しない場合 (baseline) の Istio のパフォーマンスを分析します。
また、パフォーマンステスト中に Istio のテレメトリを停止するためにMixerを無効にすることもできます。これにより、Mixer V2 の作業が完了したときに期待されるパフォーマンスと一致する結果が得られます。Istio は、Istio のテレメトリを無効にした場合と同様に動作するEnvoy ネイティブテレメトリもサポートしています。
Istio 1.2のパフォーマンス
このテスト環境を使用して、Istio 1.2のデータプレーンのパフォーマンスを分析する方法を見てみましょう。Linkerdデータプレーンで同じパフォーマンステストを実行するための手順も提供しています。現在、Linkerdではレイテンシベンチマークのみがサポートされています。
Istioのサイドカープロキシレイテンシを測定するために、リクエストスループット（RPS）を一定に保ちながら、同時接続数が増加するにつれて、50、90、99パーセンタイルを調べます。
16の同時接続と1000 RPSの場合、リクエストがクライアントプロキシとサーバープロキシの両方を通過するときに、Istioはベースライン（P50）に**3ミリ秒**を追加することがわかりました。（ピンク色の線 `base` を緑色の線 `both` から引きます）。64の同時接続では、Istioはベースラインに**12ミリ秒**を追加しますが、Mixerが無効になっている場合（`nomixer_both`）、Istioは**7ミリ秒**のみを追加します。
90パーセンタイルでは、16の同時接続でIstioは**6ミリ秒**を追加します。64の接続では、Istioは**20ミリ秒**を追加します。
最後に、99パーセンタイルでは、16の接続でIstioはベースラインに**10ミリ秒**を追加します。64の接続では、IstioはMixerを使用すると**25ミリ秒**、Mixerを使用しないと**10ミリ秒**を追加します。
CPU使用率については、リクエストスループット（RPS）を増加させ、同時接続数を一定にして測定しました。Mixerを有効にした状態で3000 RPSでのEnvoyの最大CPU使用率は**1.2 vCPU**であることがわかりました。1000 RPSでは、1つのEnvoyは約半分のCPUを使用します。
まとめ
Istioのパフォーマンスをベンチマークする過程で、いくつかの重要な教訓を学びました。
- 本番環境を模倣した環境を使用する。
- データプレーントラフィックに焦点を当てる。
- ベースラインと比較して測定する。
- 合計スループットだけでなく、同時接続数も増やす。
16接続で1000 RPSのメッシュの場合、Istio 1.2は50パーセンタイルでベースラインに**わずか3ミリ秒**のレイテンシを追加します。
また、最新のパフォーマンスデータについては、Istioのパフォーマンスとスケーラビリティガイドもご覧ください。
お読みいただきありがとうございました。ベンチマークをお楽しみください！
