1.16. パフォーマンスおよびスケーラビリティー
デフォルトの ServiceMeshControlPlane
設定は実稼働環境での使用を目的としていません。それらはリソース面で制限のあるデフォルトの OpenShift Container Platform インストールに正常にインストールされるように設計されています。SMCP インストールに成功したことを確認したら、SMCP 内で定義した設定をお使いの環境に合わせて変更する必要があります。
1.16.1. コンピュートリソースでの制限の設定
デフォルトでは、spec.proxy
には cpu:10m
および memory:128M
の設定があります。Pilot を使用している場合、spec.runtime.components.pilot
には同じデフォルト値があります。
以下の例の設定は、1 秒あたり 1,000 サービスおよび 1,000 要求をベースとしています。ServiceMeshControlPlane
で cpu
および memory
の値を変更できます。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators をクリックします。 - Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
-
Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、
ServiceMeshControlPlane
の名前 (basic
など) をクリックします。 スタンドアロンの Jaeger インスタンスの名前を
ServiceMeshControlPlane
に追加します。- YAML タブをクリックします。
ServiceMeshControlPlane
リソースのspec.proxy.runtime.container.resources.requests.cpu
およびspec.proxy.runtime.container.resources.requests.memory
の値を設定します。バージョン 2.2 ServiceMeshControlPlane の例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.2 proxy: runtime: container: resources: requests: cpu: 600m memory: 50Mi limits: {} runtime: components: pilot: container: resources: requests: cpu: 1000m memory: 1.6Gi limits: {}
- Save をクリックします。
-
Reload をクリックして、
ServiceMeshControlPlane
リソースが正しく設定されていることを確認します。
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 番目のパーセンタイルレイテンシーに追加します。