パフォーマンスとスケーラビリティ

約4分

Istioを使用すると、豊富なルーティング、ロードバランシング、サービス間認証、監視などを備えたデプロイ済みサービスのネットワークを簡単に作成できます。アプリケーションコードを変更せずにこれらすべての機能を利用できます。Istioは、最小限のリソースオーバーヘッドでこれらの利点を提供することに努めており、最小限のレイテンシで高いリクエストレートを持つ非常に大規模なメッシュをサポートすることを目指しています。

IstioのデータプレーンコンポーネントであるEnvoyプロキシは、システムを流れるデータを処理します。IstioのコントロールプレーンコンポーネントであるIstiodは、データプレーンを構成します。データプレーンとコントロールプレーンでは、パフォーマンスに関する懸念事項が異なります。

Istio 1.24のパフォーマンス概要

Istioの負荷テストメッシュは、7万リクエスト/秒のメッシュ全体のリクエストで、**1000**個のサービスと**2000**個のPodで構成されています。

コントロールプレーンのパフォーマンス

Istiodは、ユーザーが作成した設定ファイルとシステムの現在の状態に基づいて、サイドカープロキシを構成します。Kubernetes環境では、カスタムリソース定義（CRD）とデプロイメントがシステムの設定と状態を構成します。ゲートウェイや仮想サービスなどのIstio設定オブジェクトは、ユーザーが作成した設定を提供します。プロキシの設定を生成するために、IstiodはKubernetes環境からの組み合わせられた設定とシステムの状態、およびユーザーが作成した設定を処理します。

コントロールプレーンは、数千ものサービスをサポートしており、これらは同数のユーザー作成仮想サービスおよびその他の構成オブジェクトを持つ数千ものポッドに分散されています。Istiod の CPU およびメモリ要件は、構成量と可能性のあるシステム状態に応じてスケールします。CPU 消費量は、以下の要因によってスケールします。

デプロイメント変更の頻度。
構成変更の頻度。
Istiod に接続するプロキシの数。

ただし、この部分は本質的に水平方向にスケール可能です。

Istiod インスタンスの数を増やすことで、構成がすべてプロキシに到達するまでの時間を短縮できます。

大規模な場合は、構成スコープを強くお勧めします。

データプレーンのパフォーマンス

データプレーンのパフォーマンスは、多くの要因に依存します。例えば

クライアント接続数
ターゲットリクエストレート
リクエストサイズとレスポンスサイズ
プロキシワーカースレッド数
プロトコル
CPU コア数
様々なプロキシ機能。特に、テレメトリフィルター（ロギング、トレーシング、メトリクス）は、中程度の影響を与えることが知られています。

レイテンシ、スループット、プロキシの CPU およびメモリ消費量は、これらの要因の関数として測定されます。

サイドカーとztunnelのリソース使用量

サイドカープロキシはデータパスに追加の処理を実行するため、CPU とメモリを消費します。Istio 1.24 では、1 KB のペイロードを含む 1 秒あたり 1000 件の HTTP リクエストの場合

ワーカースレッド 2 つを持つ単一のサイドカープロキシは約 0.20 vCPU と 60 MB のメモリを消費します。
ワーカースレッド 2 つを持つ単一のウェイポイントプロキシは約 0.25 vCPU と 60 MB のメモリを消費します。
単一の ztunnel プロキシは約 0.06 vCPU と 12 MB のメモリを消費します。

プロキシのメモリ消費量は、プロキシが保持する合計構成状態に依存します。リスナー、クラスタ、ルートの数が多くなると、メモリ使用量が増加します。

レイテンシ

Istio はデータパスにサイドカープロキシまたは ztunnel プロキシを追加するため、レイテンシは重要な考慮事項です。Istio が追加するすべての機能は、プロキシ内のパス長にも追加され、レイテンシに影響を与える可能性があります。

Envoy プロキシは、レスポンスがクライアントに送信された後に生のテレメトリデータを収集します。リクエストの生のテレメトリデータの収集に費やされた時間は、そのリクエストを完了するのにかかる合計時間には含まれません。ただし、ワーカーはリクエストの処理に忙しいため、次のリクエストの処理をすぐに開始しません。このプロセスは、次のリクエストのキュー待ち時間に追加され、平均レイテンシとテールレイテンシに影響します。実際のテールレイテンシはトラフィックパターンによって異なります。

Istio 1.24のレイテンシ

サイドカーモードでは、リクエストはクライアント側のサイドカープロキシ、次にサーバー側のサイドカープロキシを通過してからサーバーに到達し、その逆も同様です。アンビエントモードでは、リクエストはクライアントノードの ztunnel、次にサーバーノードの ztunnel を通過してからサーバーに到達します。ウェイポイントが構成されている場合、リクエストは ztunnel 間のウェイポイントプロキシを通過します。以下のチャートは、さまざまなデータプレーンモードを通過する http/1.1 リクエストの P90 および P99 レイテンシを示しています。テストを実行するために、5 台の M3 Large マシンと Flannel をプライマリ CNI として使用するベアメタルクラスタを使用しました。これらの結果は、ペイロードサイズ 1 KB、クライアント接続 4 つ、プロキシワーカー 2 つ、相互 TLS を有効にした状態で、1 秒あたり 500、750、1000、1250、および 1500 リクエストを使用して、http/1.1 プロトコルに対する Istio ベンチマークを使用して取得しました。

注：このテストは CNCF コミュニティインフラストラクチャラボで実行されました。ハードウェアが異なると、値も異なります。

P90 latency vs client connections

P99 latency vs client connections