大規模セキュリティポリシーのパフォーマンス テスト
リクエストのレイテンシに対するセキュリティポリシーの影響。
概要
Istioは、サービスシステムに簡単に構成できる幅広いセキュリティポリシーを提供しています。適用されるポリシーの数が増加するにつれて、システムのレイテンシ、メモリ使用量、およびCPU使用量の関係を理解することが重要です。
このブログ記事では、一般的なセキュリティポリシーのユースケースと、セキュリティポリシーの数またはセキュリティポリシー内の特定のルールの数がリクエストの全体的なレイテンシにどのように影響するかについて説明します。
セットアップ
幅広いセキュリティポリシーと、それらのポリシーのさらに多くの組み合わせがあります。最も一般的に使用される6つのテストケースについて説明します。
以下のテストケースは、Envoyサイドカーがデプロイされていないベースラインで、FortioクライアントがFortioサーバーにリクエストを送信する環境で実行されます。以下のデータは、Istio パフォーマンス ベンチマーク ツールを使用して収集されました。
これらのテストケースでは、リクエストはルールに一致しないか、セキュリティポリシーの最後のルールにのみ一致します。これにより、RBACフィルターがすべてのポリシールールに適用され、すべてのポリシーを確認する前にポリシールールに一致することがなくなります。これは必ずしも独自のシステムで発生することではありませんが、このポリシー設定は、各テストケースの最悪のパフォーマンスのデータを提供します。
テストケース
相互TLS STRICTとプレーンテキストの比較。
可数のプリンシパルルールと`PeerAuthentication`ポリシーを持つ単一の認証ポリシー。プリンシパルルールは、システムに適用される`PeerAuthentication`ポリシーに依存します。
可数の`requestPrincipal`ルールと`RequestAuthentication`ポリシーを持つ単一の認証ポリシー。 `requestPrincipal`は、システムに適用される`RequestAuthentication`ポリシーに依存します。
可数の`paths`ルールと`sourceIP`ルールを持つ単一の認証ポリシー。
単一のパスルールまたは`sourceIP`ルールで構成される可数の認証ポリシー。
可数の`JWTRules`ルールを持つ単一の`RequestAuthentication`ポリシー。
データ
各テストのy軸はレイテンシ（ミリ秒）、x軸は同時接続数です。各グラフのx軸は、低負荷（qps=100、conn=8）、中負荷（qps=500、conn=32）、高負荷（qps=1000、conn=64）を表す3つのデータポイントで構成されています。
プリンシパルルールが10個と1000個の認証ポリシーの場合、ポリシーがない場合と比較して10個のプリンシパルルールのレイテンシの増加は、10個のプリンシパルと比較して1000個のプリンシパルのレイテンシの増加よりも大きくなります。
認証ポリシーの数がランタイムにどのように影響するかをテストするために、テストは2つのケースに分けられます
すべての認証ポリシーに単一の`sourceIP`ルールがあります。
すべての認証ポリシーに単一のパスルールがあります。
結論
一般に、セキュリティポリシーを追加しても、システムに比較的高いオーバーヘッドは追加されません。最もレイテンシを追加するポリシーは次のとおりです。
`JWTRules`ルールを持つ認証ポリシー。
`requestPrincipal`ルールを持つ認証ポリシー。
プリンシパルルールを持つ認証ポリシー。
低負荷（qpsとconnが低いリクエスト）では、ほとんどのポリシーのレイテンシの差は最小限です。
Envoyプロキシサイドカーは、ポリシーが大きい場合でも、ほとんどのポリシーよりもレイテンシを増加させます。
非常に大きなポリシーのレイテンシの増加は、サイドカーがない場合と比較してEnvoyプロキシサイドカーを追加した場合のレイテンシの増加と比較的似ています。
2つの異なるテストで、`sourceIP`ルールがパスルールよりもわずかに遅いことがわかりました。
独自の規模の大きなセキュリティポリシーを作成し、それらを使用してパフォーマンステストを実行することに興味がある場合は、パフォーマンスベンチマークツールのREADMEを参照してください。
セキュリティポリシーテストの詳細については、設計ドキュメントを参照してください。まだアクセス権がない場合は、Istioチームドライブに参加できます。
