これを本番環境のサイジングの出発点として使用してください。負荷テストに基づいて、必要に応じて環境に合わせて値を調整してください。
|
概要
使用される CPU は、以下のテスト済み制限までリクエスト数に比例して線形にスケールします。
推奨事項
Realm データと 10,000 のキャッシュされたセッションのキャッシュを含む Pod の基本メモリ使用量は、1250 MB の RAM です。
コンテナでは、Keycloak はヒープベースのメモリにメモリ制限の 70% を割り当てます。また、約 300 MB の非ヒープベースのメモリも使用します。要求されるメモリを計算するには、上記の計算を使用してください。メモリ制限として、上記の値から非ヒープメモリを差し引き、結果を 0.7 で割ってください。
パスワードベースのユーザーログインが毎秒 15 件の場合ごとに、クラスターに 1 vCPU を割り当てます（毎秒最大 300 件でテスト済み）。
Keycloak は、ユーザーが提供したパスワードのハッシュ化に CPU 時間のほとんどを費やしており、ハッシュ反復回数に比例します。
クライアントクレデンシャルフロー認可が毎秒 120 件の場合ごとに、クラスターに 1 vCPU を割り当てます（毎秒最大 2000 件でテスト済み）。*
ほとんどの CPU 時間は、新しい TLS 接続の作成に費やされます。これは、各クライアントが単一のリクエストのみを実行するためです。
リフレッシュトークンリクエストが毎秒 120 件の場合ごとに、クラスターに 1 vCPU を割り当てます（毎秒最大 435 件のリフレッシュトークンリクエストでテスト済み）。*
負荷の急増に対応するために、CPU 使用率に 150% の追加ヘッドルームを残してください。これにより、ノードの高速な起動と、フェイルオーバータスクを処理するのに十分な容量が確保されます。Keycloak の Pod がテストでスロットリングされた場合、パフォーマンスは大幅に低下しました。
2500 を超える異なるクライアントで同時にリクエストを実行する場合、標準のキャッシュサイズがそれぞれ 10000 エントリである場合、すべてのクライアント情報が Keycloak のキャッシュに収まらないことがあります。このため、クライアントデータがデータベースから頻繁に再ロードされるため、データベースがボトルネックになる可能性があります。データベースの使用量を減らすには、users キャッシュサイズを同時使用クライアント数の 2 倍に、realms キャッシュサイズを同時使用クライアント数の 4 倍に増やしてください。
デフォルトでユーザーセッションをデータベースに保存する Keycloak は、Aurora PostgreSQL マルチ AZ データベースで最適なパフォーマンスを得るために、次のリソースを必要とします。
毎秒 100 件のログイン/ログアウト/リフレッシュリクエストごと
1400 Write IOPS を予算に計上してください。
0.35 から 0.7 vCPU の間を割り当てます。
vCPU 要件は範囲として示されています。データベースホストの CPU 使用率が飽和状態になると、リクエストあたりの CPU 使用率は低下しますが、応答時間は増加します。データベースの CPU 割り当て量が少ないと、ピーク負荷時の応答時間が遅くなる可能性があります。ピーク負荷時の高速な応答時間が重要な場合は、より大きな CPU 割り当て量を選択してください。例については下記を参照してください。
Keycloak インスタンスのサイジングは、前のセクションで説明したパスワードベースのユーザーログイン、リフレッシュトークンリクエスト、およびクライアントクレデンシャルフロー認可の実際および予測される数に依存します。
これらの 3 つの主要な入力に対する実行中の Keycloak インスタンスの実際の数を取得するには、Keycloak が提供するメトリクスを使用します。
イベントタイプ login のユーザーイベントメトリクス keycloak_user_events_total には、パスワードベースのログインと Cookie ベースのログインの両方が含まれていますが、このサイジングガイドの最初の概算入力として役立ちます。
Keycloak によって実行されたパスワード検証の数を確認するには、メトリクス keycloak_credentials_password_hashing_validations_total を使用します。このメトリクスには、使用されたハッシュアルゴリズムと検証の結果に関する詳細を提供するタグも含まれています。利用可能なタグのリストは次のとおりです。realm、algorithm、hashing_strength、outcome。
リフレッシュトークンリクエストとクライアントクレデンシャルフロー認可には、イベントタイプ refresh_token および client_login のユーザーイベントメトリクス keycloak_user_events_total をそれぞれ使用します。
詳細については、イベントメトリクスを使用したユーザーアクティビティの監視 および HTTP メトリクス ガイドを参照してください。
これらのメトリクスは、ユーザーアクティビティ負荷の日次および週次の変動を追跡し、システムのサイズ変更の必要性を示す可能性のある新たな傾向を特定し、サイジング計算を検証するために重要です。これらのユーザーイベントメトリクスを体系的に測定および評価することにより、システムがユーザーの行動と需要の変化に適切にスケールされ、応答性を維持できるようにすることができます。
目標サイズ
毎秒 45 件のログインとログアウト
毎秒 360 件のクライアントクレデンシャルフロー認可*
毎秒 360 件のリフレッシュトークンリクエスト（ログインの 1:8 の比率）*
3 Pod
計算された制限
Pod あたりのリクエスト CPU：3 vCPU
（毎秒 45 件のログイン = 3 vCPU、毎秒 360 件のクライアントクレデンシャルフロー認可 = 3 vCPU、360 件のリフレッシュトークン = 3 vCPU。合計で 9 vCPU になります。クラスターで実行されている 3 つの Pod で、各 Pod は 3 vCPU をリクエストします。）
Pod あたりの CPU 制限：7.5 vCPU
（ピーク、起動、およびフェイルオーバータスクを処理するために、追加の 150% のリクエスト CPU を許可します。）
Pod あたりのリクエストメモリ：1250 MB
（1250 MB の基本メモリ）
Pod あたりのメモリ制限：1360 MB
（1250 MB の予想メモリ使用量から 300 の非ヒープ使用量を差し引き、0.7 で割った値）
Aurora データベースインスタンス：ピーク負荷時の必要な応答時間に応じて、db.t4g.large または db.t4g.xlarge のいずれか。
（毎秒 45 件のログイン、毎秒 5 件のログアウト、毎秒 360 件のリフレッシュトークン。合計で毎秒 410 件のリクエストになります。この予想される DB 使用量は 1.4 から 2.8 vCPU で、DB アイドル負荷は 0.3 vCPU です。これは、2 vCPU db.t4g.large インスタンスまたは 4 vCPU db.t4g.xlarge インスタンスのいずれかを示します。応答時間がピーク使用時に高くなっても許容できる場合は、2 vCPU db.t4g.large の方が費用対効果が高くなります。このシナリオで 2 vCPU db.t4g.large インスタンスの CPU 使用率が 90% に達すると、ログインとトークンリフレッシュの中央応答時間が最大 120 ミリ秒増加しました。ピーク使用時の応答時間を短縮するには、このシナリオでは 4 vCPU db.t4g.xlarge インスタンスを検討してください。）
1 つの AWS リージョン内の 2 つの AZ を使用したアクティブ/アクティブ Keycloak 構成のサイジングを作成するには、次の手順に従います。
2 番目のサイトで上記と同じメモリサイジングで同じ数の Pod を作成します。
データベースのサイジングは変更されません。両方のサイトが同じデータベースライターインスタンスに接続します。
CPU リクエストと制限のサイジングに関しては、予想されるフェイルオーバーの動作に応じて異なるアプローチがあります。
2 番目のサイトの CPU リクエストと制限を上記と同じに保ちます。これにより、残りのサイトはスケールする必要なく、プライマリサイトからのトラフィックをすぐに引き継ぐことができます。
2 番目のサイトの CPU リクエストと制限を上記より 50% 削減します。いずれかのサイトで障害が発生した場合は、残りのサイトを 3 Pod から 6 Pod に手動、自動、または水平 Pod オートスケーラーを使用してスケールします。これには、クラスターまたはクラスターの自動スケーリング機能に十分な予備容量が必要です。
2 番目のサイトの CPU リクエストを 50% 削減しますが、CPU 制限は上記と同じに保ちます。これにより、残りのサイトはトラフィックを引き継ぐことができますが、ノードが CPU 負荷を経験し、ピークトラフィック時の応答時間が遅くなるという欠点があります。この構成の利点は、フェイルオーバー時に Pod の数をスケールする必要がないため、セットアップが簡単になることです。
さまざまなシナリオで約 10 分間のテストを実行するために上記の設定を取得するために、次の構成が使用されました。
ROSA 経由で AWS にデプロイされた OpenShift 4.17.x。
c7g.2xlarge インスタンスを備えたマシンプール。*
Operator でデプロイされ、アクティブ/アクティブモードの 2 つのサイトを備えた高可用性構成で 3 つの Pod を持つ Keycloak。
OpenShift のリバースプロキシは、クライアントの TLS 接続が Pod で終端されるパススルーモードで実行されます。
マルチ AZ 構成のデータベース Amazon Aurora PostgreSQL。
Argon2 と 5 回のハッシュ反復および最小メモリサイズ 7 MiB を使用したデフォルトのユーザーパスワードハッシュ化（OWASP が推奨するように）（これがデフォルトです）。
クライアントクレデンシャルフロー認可はリフレッシュトークンを使用しません（これがデフォルトです）。
20,000 ユーザーと 20,000 クライアントでシードされたデータベース。
デフォルトの 10,000 エントリでの Infinispan ローカルキャッシュ。そのため、すべてのクライアントとユーザーがキャッシュに収まるわけではなく、一部のリクエストはデータベースからデータをフェッチする必要があります。
すべての認証セッションは、デフォルトとして分散キャッシュに保存され、エントリごとに 2 人のオーナーがおり、データを失うことなく 1 つの Pod を障害にすることができます。
すべてのユーザーおよびクライアントセッションはデータベースに保存され、マルチサイト構成でテストされたため、インメモリでキャッシュされません。固定数のユーザーおよびクライアントセッションがキャッシュされるため、シングルサイト構成ではわずかに高いパフォーマンスが期待できます。
OpenJDK 21
* AWS の非 ARM CPU アーキテクチャ（c7i/c7a 対 c7g）の場合、クライアントクレデンシャルフロー認可とリフレッシュトークンのワークロードは CPU コアあたり最大 2 倍の操作数を配信できましたが、パスワードハッシュ化は CPU コアあたり一定の操作数を配信していました。ワークロードとクラウドの料金体系に応じて、独自のテストを実行し、混合ワークロードの独自の計算を行って、どちらのアーキテクチャがより良い料金体系を提供するかを確認してください。