Alibaba Cloud Service Mesh:構成プッシュ最適化の概要

最適化戦略の選択

以下の表は、適切なアプローチを選択するのに役立つ3つの機能を比較しています。

サービス検出セレクター

名前空間ラベルに基づいてラベルセレクターを構成します。コントロールプレーンは、一致する名前空間内のサービスのみを検出し、処理し、それらの構成のみをサイドカーにプッシュします。

適用シナリオ： データプレーンに多数の名前空間とサービスが含まれているが、各名前空間のワークロードは少数の特定の名前空間内のサービスのみを呼び出す場合。

設定手順については、「サービス検出セレクターを使用したコントロールプレーンの構成プッシュ効率の向上」をご参照ください。

サイドカー推奨

Service Mesh (ASM) は、サイドカーによって生成されたアクセスログを分析し、サービス間の呼び出しの依存関係を特定します。この分析に基づいて、ASM は各ワークロードの Sidecar リソースを推奨および作成します。各 Sidecar リソースは、ワークロードの構成を実際に呼び出すサービスのみに制限します。

これには2つの利点があります。

• 各サイドカーは、そのワークロードに関連するサービスの構成のみを保存します。

• 無関係なサービスが変更された場合、または関連するサービスの仮想サービスなどのリソースが変更された場合でも、コントロールプレーンはそのサイドカーに新しい構成をプッシュしません。

適用シナリオ： サービス検出セレクターだけでは十分な最適化が得られない場合。例えば、単一の名前空間に多数のサービスが含まれており、サイドカーの構成サイズを最小限に抑えたい場合。ASM はアクセスログ分析に基づいて Sidecar リソースを推奨および作成するため、YAML ファイルを手動で記述する必要はありません。

プッシュパフォーマンスへの測定された影響については、「サイドカー推奨による構成プッシュ最適化の効果」をご参照ください。

設定手順については、「アクセスログ分析に基づいて自動的に推奨されるサイドカーの使用」をご参照ください。

適応型 xDS 最適化

サイドカー推奨と同様に、適応型 xDS 最適化はワークロードごとの Sidecar リソースを生成して構成の範囲を定めます。以下の点で異なります。

• 完全自動。 呼び出しの依存関係が変更されると、Sidecar リソースは自動的に生成および更新されます。手動構成や定期的な再推奨は不要です。

• Log Service への依存なし。 この機能は、データプレーンでアクセスログを収集するために Log Service を有効化する必要はありません。

• エグレスゲートウェイベース。 istio-axds-egressgateway という名前のエグレスゲートウェイがデータプレーンにデプロイされます。この機能は、選択したワークロードにのみ適用されます。選択したワークロードからのすべての HTTPトラフィックは、このゲートウェイを介してルーティングされ、コントロールプレーンはこれを使用して呼び出しの依存関係を分析します。

適用シナリオ： 特に Sidecar リソースや手動構成の調整に慣れていない場合でも、構成プッシュ最適化への最も簡単なパスを望む場合。

設定手順については、「適応型 xDS 最適化を使用したコントロールプレーンの構成プッシュ効率の向上」をご参照ください。