2.18. パフォーマンスおよびスケーラビリティー
				デフォルトの ServiceMeshControlPlane 設定は実稼働環境での使用を目的としていません。それらはリソース面で制限のあるデフォルトの OpenShift Container Platform インストールに正常にインストールされるように設計されています。SMCP インストールに成功したことを確認したら、SMCP 内で定義した設定をお使いの環境に合わせて変更する必要があります。
			
2.18.1. コンピュートリソースでの制限の設定 リンクのコピーリンクがクリップボードにコピーされました!
					デフォルトでは、spec.proxy には cpu: 10m および memory: 128M という設定があります。Pilot を使用している場合、spec.runtime.components.pilot には同じデフォルト値があります。
				
					以下の例の設定は、1 秒あたり 1,000 サービスおよび 1,000 要求をベースとしています。ServiceMeshControlPlane で cpu および memory の値を変更できます。
				
手順
- 
							OpenShift Container Platform Web コンソールで、Ecosystem 
Installed Operator をクリックします。  - 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、components.kiali.container、およびcomponents.global.oauthproxyの値を設定します。サンプルバージョン 2.6 ServiceMeshControlPlane
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat OpenShift Distributed Tracing Platform (Jaeger) の値を設定するには、「Distributed Tracing Platform Jaeger の設定とデプロイ」を参照してください。
 - Save をクリックします。
 
検証
- 
							Reload をクリックして、
ServiceMeshControlPlaneリソースが正しく設定されたことを確認します。 
2.18.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 は、データプレーンを設定します。データプレーンおよびコントロールプレーンには、さまざまなパフォーマンスに関する懸念点があります。 
2.18.2.1. Service Mesh コントロールプレーンのパフォーマンス リンクのコピーリンクがクリップボードにコピーされました!
Istiod は、ユーザーが作成する設定ファイルおよびシステムの現在の状態に基づいてサイドカープロキシーを設定します。Kubernetes 環境では、カスタムリソース定義 (CRD) およびデプロイメントはシステムの設定および状態を構成します。ゲートウェイや仮想サービスなどの Istio 設定オブジェクトは、ユーザーが作成する設定を提供します。プロキシーの設定を生成するために、Istiod は Kubernetes 環境およびユーザー作成の設定から、組み合わせた設定およびシステムの状態を処理します。
Service Mesh コントロールプレーンは、数千のサービスをサポートし、これらは同様の数のユーザーが作成する仮想サービスおよびその他の設定オブジェクトと共に数千の Pod 全体に分散されます。Istiod の CPU およびメモリー要件は、設定数および使用可能なシステムの状態と共にスケーリングされます。CPU の消費は、以下の要素でスケーリングします。
- デプロイメントの変更レート。
 - 設定の変更レート。
 - Istiod へのプロキシー数。
 
ただし、この部分は水平的にスケーリングが可能です。
2.18.2.2. データプレーンのパフォーマンス リンクのコピーリンクがクリップボードにコピーされました!
データプレーンのパフォーマンスは、以下を含む数多くの要因によって変わります。
- クライアント接続の数
 - ターゲットの要求レート
 - 要求サイズおよび応答サイズ
 - プロキシーワーカーのスレッド数
 - プロトコル
 - CPU コア数
 - プロキシーフィルターの数およびタイプ (とくに Telemetry v2 関連のフィルター)。
 
レイテンシー、スループット、およびプロキシーの CPU およびメモリーの消費は、これらの要素の関数として測定されます。
2.18.2.2.1. CPU およびメモリーの消費 リンクのコピーリンクがクリップボードにコピーされました!
Sidecar プロキシーはデータパスで追加の作業を実行するため、CPU およびメモリーを消費します。Istio 1.12.3 の時点で、プロキシーは 1 秒あたり 1000 要求ベースで 0.5 vCPU を消費します。
プロキシーのメモリー消費は、プロキシーが保持する設定の状態の合計数によって異なります。多数のリスナー、クラスター、およびルートは、メモリーの使用量を増やす可能性があります。
通常、プロキシーは通過するデータをバッファーに入れないため、要求レートはメモリー消費には影響を及ぼしません。
2.18.2.2.2. その他のレイテンシー リンクのコピーリンクがクリップボードにコピーされました!
Istio はデータパスにサイドカープロキシーを注入するため、レイテンシーは重要な考慮事項です。Istio は認証フィルター、Telemetry フィルター、およびメタデータ交換フィルターをプロキシーに追加します。すべての追加フィルターはプロキシー内のパスの長さに追加され、これはレイテンシーに影響を及ぼします。
Envoy プロキシーは、応答がクライアントに送信された後に未加工の Telemetry データを収集します。リクエストの生のテレメトリーの収集に費やされた時間は、そのリクエストの完了にかかる合計時間には影響しません。ただし、ワーカーは要求処理にビジー状態になるため、ワーカーは次の要求の処理をすぐに開始しません。このプロセスは、次の要求のキューの待機時間に追加され、平均のレイテンシーおよびテイルレイテンシー (Tail Latency) に影響を及ぼします。実際のテイルレイテンシーは、トラフィックのパターンによって異なります。
メッシュ内で、要求はクライアント側のプロキシーを通過してから、サーバー側のプロキシーを通過します。Istio 1.12.3 のデフォルト設定 (Istio と Telemetry v2) では、2 つのプロキシーは、ベースラインのデータプレーンのレイテンシーに対してそれぞれ約 1.7 ms および 2.7 ms を 90 および 99 番目のパーセンタイルレイテンシーに追加します。