1.16. パフォーマンスおよびスケーラビリティー


デフォルトの ServiceMeshControlPlane 設定は実稼働環境での使用を目的としていません。それらはリソース面で制限のあるデフォルトの OpenShift Container Platform インストールに正常にインストールされるように設計されています。SMCP インストールに成功したことを確認したら、SMCP 内で定義した設定をお使いの環境に合わせて変更する必要があります。

1.16.2. テスト結果の読み込み

アップストリームの Istio コミュニティーの負荷テストのメッシュは、1 秒あたり 70,000 のメッシュ全体の要求を持つ 1000 サービスと 2000 サイドカーで設定されます。Istio 1.12.3 を使用してテストを実行後、以下の結果が生成されました。

  • Envoy プロキシーは、プロキシーを通過する 1 秒あたり/要求 1000 件あたり 0.35 vCPU および 40 MB メモリー を使用します。
  • Istiod は 1 vCPU および 1.5 GB のメモリーを使用します。
  • Envoy プロキシーは 2.65 ms を 90 % レイテンシーに追加します。
  • レガシー istio-telemetry サービス (Service Mesh 2.0 ではデフォルトで無効にされます) は、Mixer を使用するデプロイメントについて、1 秒あたりの 1000 のメッシュ全体の要求ごとに 0.6 vCPU を使用します。データプレーンのコンポーネントである Envoy プロキシーは、システムを通過するデータフローを処理します。Service Mesh コントロールプレーンコンポーネントである Istiod は、データプレーンを設定します。データプレーンおよびコントロールプレーンには、さまざまなパフォーマンスに関する懸念点があります。

1.16.2.1. Service Mesh コントロールプレーンのパフォーマンス

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

Service Mesh コントロールプレーンは、数千のサービスをサポートし、これらは同様の数のユーザーが作成する仮想サービスおよびその他の設定オブジェクトと共に数千の Pod 全体に分散されます。Istiod の CPU およびメモリー要件は、設定数および使用可能なシステムの状態と共にスケーリングされます。CPU の消費は、以下の要素でスケーリングします。

  • デプロイメントの変更レート。
  • 設定の変更レート。
  • Istiod へのプロキシー数。

ただし、この部分は水平的にスケーリングが可能です。

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

データプレーンのパフォーマンスは、以下を含む数多くの要因によって変わります。

  • クライアント接続の数
  • ターゲットの要求レート
  • 要求サイズおよび応答サイズ
  • プロキシーワーカーのスレッド数
  • プロトコル
  • CPU コア数
  • プロキシーフィルターの数およびタイプ (とくに Telemetry v2 関連のフィルター)。

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

1.16.2.2.1. CPU およびメモリーの消費

サイドカープロキシーはデータパスで追加の作業を実行するため、CPU およびメモリーを消費します。Istio 1.12.3 の時点で、プロキシーは 1 秒あたり 1000 要求ベースで 0.5 vCPU を消費します。

プロキシーのメモリー消費は、プロキシーが保持する設定の状態の合計数によって異なります。多数のリスナー、クラスター、およびルートは、メモリーの使用量を増やす可能性があります。

通常、プロキシーは通過するデータをバッファーに入れないため、要求レートはメモリー消費には影響を及ぼしません。

1.16.2.2.2. その他のレイテンシー

Istio はデータパスにサイドカープロキシーを挿入するため、レイテンシーは重要な考慮事項になります。Istio は認証フィルター、Telemetry フィルター、およびメタデータ交換フィルターをプロキシーに追加します。すべての追加フィルターはプロキシー内のパスの長さに追加され、これはレイテンシーに影響を及ぼします。

Envoy プロキシーは、応答がクライアントに送信された後に未加工の Telemetry データを収集します。要求についての未加工の Telemetry の収集に費やされる時間は、その要求の完了にかかる合計時間には影響を与えません。ただし、ワーカーは要求処理にビジー状態になるため、ワーカーは次の要求の処理をすぐに開始しません。このプロセスは、次の要求のキューの待機時間に追加され、平均のレイテンシーおよびテイルレイテンシー (Tail Latency) に影響を及ぼします。実際のテイルレイテンシーは、トラフィックのパターンによって異なります。

メッシュ内で、要求はクライアント側のプロキシーを通過してから、サーバー側のプロキシーを通過します。Istio 1.12.3 のデフォルト設定 (Istio と Telemetry v2) では、2 つのプロキシーは、ベースラインのデータプレーンのレイテンシーに対してそれぞれ約 1.7 ms および 2.7 ms を 90 および 99 番目のパーセンタイルレイテンシーに追加します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.