第11章 CPU およびメモリーリソースのサイジングの概念
この章は、実稼働環境のサイジングの開始点として使用してください。負荷テストに基づいて、必要に応じて環境に合わせて値を調整してください。
11.1. パフォーマンスに関する推奨事項
- より多くの Pod にスケーリングする場合 (オーバーヘッドの追加のため)、および複数のデータセンターにまたがるセットアップを使用する場合 (トラフィックと運用の拡大のため)、パフォーマンスが低下します。
- Red Hat build of Keycloak インスタンスを長時間実行する場合、キャッシュサイズを増やすと、パフォーマンスが向上する可能性があります。これにより、応答時間が短縮され、データベースの IOPS が減少します。ただし、このキャッシュはインスタンスの再起動時にいっぱいにする必要があるため、キャッシュがいっぱいになった後に測定した安定状態に基づいてリソースを厳しく設定しないでください。
- 以下の値は開始点として使用し、実稼働に移行する前に独自の負荷テストを実行してください。
概要:
- 使用される CPU は、以下のテスト済みの上限まで、リクエストの数に比例して増加します。
推奨事項:
- Pod の基本メモリー使用量は、レルムデータのキャッシュとキャッシュされた 10,000 セッションを含め、RAM 1250 MB です。
- コンテナーでは、Keycloak はメモリー制限の 70% をヒープベースのメモリーに割り当てます。また、ヒープベース以外のメモリーも約 300 MB 使用します。要求されるメモリーを計算するには、上記の計算を使用してください。メモリー制限を求めるには、上記の値からヒープ以外のメモリーを減算し、その結果を 0.7 で割ります。
1 秒あたり 15 件のパスワードベースのユーザーログインにつき 1 つの仮想 CPU をクラスターに割り当てます (1 秒あたり最大 300 までテスト済み)。
Red Hat build of Keycloak は、ユーザーが指定したパスワードのハッシュ化にほとんどの CPU 時間を費やします。CPU 時間はハッシュ化の反復回数に比例します。
1 秒あたり 200 件のクライアントクレデンシャルグラントにつき 1 つの仮想 CPU をクラスターに割り当てます (1 秒あたり 2000 までテスト済み)。
各クライアントは 1 つのリクエストのみを実行するため、ほとんどの CPU 時間は新しい TLS 接続の作成に費やされます。
- 1 秒あたり 120 件のリフレッシュトークンリクエストにつき 1 つの仮想 CPU をクラスターに割り当てます (1 秒あたり 435 件のリフレッシュトークンリクエストまでテスト済み)。
- 負荷の急増に対処するために、CPU 使用率に 150% の余裕を残しておきます。これにより、ノードの高速起動と、フェイルオーバータスクを処理するための十分な容量が確保されます。当社のテストでは、Pod がスロットリングされたときに Red Hat build of Keycloak のパフォーマンスが大幅に低下しました。
Red Hat build of Keycloak は、デフォルトでユーザーセッションをデータベースに保存しますが、Aurora PostgreSQL multi-AZ データベースで最適なパフォーマンスを確保するためには次のリソースが必要です。
1 秒あたり 100 回のログイン/ログアウト/更新リクエストごとに以下が必要です。
- 1400 Write IOPS のバジェット。
- 0.35 から 0.7 の範囲での仮想 CPU の割当。
仮想 CPU 要件は範囲として指定されます。データベースホストの CPU 飽和度が増加すると、要求ごとの CPU 使用率は低下しますが、応答時間は長くなります。データベースの CPU クォータが低いと、ピーク負荷時の応答時間が長くなる可能性があります。ピーク負荷時の応答時間を短縮することが重要な場合は、より大きな CPU クォータを選択してください。以下はその例です。
11.1.1. 計算例 (シングルサイト)
ターゲットサイズ:
- 1 秒あたり 45 回のログインとログアウト
- 1 秒あたり 600 件のクライアントクレデンシャルグラント
- 1 秒あたり 360 件のリフレッシュトークンリクエスト (ログイン比率は 1:8)
- 3 Pod
制限の算定:
Pod あたりの CPU リクエスト: 3 仮想 CPU
(1 秒あたり 45 件のログイン = 3 仮想 CPU、1 秒あたり 600 のクライアントクレデンシャルグラント = 3 仮想 CPU、345 のリフレッシュトークン = 3 仮想 CPU。合計で 9 仮想 CPU。クラスター内で 3 Pod が実行されている場合、各 Pod は 3 仮想 CPU をリクエストします。)
Pod あたりの CPU 制限: 7.5 仮想 CPU
(ピーク、起動、フェイルオーバータスクを処理するために、追加で要求される CPU の 150% を確保)
Pod あたりのメモリーリクエスト: 1250 MB
(1250 MB ベースメモリー)
Pod あたりのメモリー制限: 1360 MB
(1250 MB の予想メモリー使用量から 300 MB (ヒープ以外のメモリー使用量) を引き、0.7 で割った値)
Aurora データベースインスタンス: ピーク負荷時に必要な応答時間に応じて、
db.t4g.largeまたはdb.t4g.xlargeのいずれか。(1 秒あたり 45 回のログイン、1 秒あたり 5 回のログアウト、1 秒あたり 360 のリフレッシュトークン。合計すると 1 秒あたり 410 件のリクエストになります。予想される DB 使用量は 1.4 - 2.8 仮想 CPU で、DB アイドル負荷は 0.3 仮想 CPU です。これは、2 仮想 CPU の
db.t4g.largeインスタンスまたは 4 仮想 CPU のdb.t4g.xlargeインスタンスのいずれかを示します。ピーク使用時に応答時間が長くなることが許容される場合、2 仮想 CPU のdb.t4g.largeの方がコスト効率が高くなります。このシナリオでの当社のテストでは、2 仮想 CPU のdb.t4g.largeインスタンスで CPU 飽和度が 90% に達すると、ログインとトークン更新の平均応答時間が最大 120 ミリ秒増加しました。このシナリオの場合、ピーク使用時の応答時間を短縮するには 4 仮想 CPU のdb.t4g.xlargeインスタンスを検討してください。)
11.1.2. マルチサイトセットアップのサイズ設定
1 つの AWS リージョンに 2 つの AZ を持つアクティブ/アクティブ Keycloak セットアップのサイズ設定を作成するには、次の手順に従います。
- セカンダリーサイトで、上記と同じメモリーサイズを持つ同数の Pod を作成します。
- データベースのサイズは変更されません。両方のサイトは同じデータベースライターインスタンスに接続します。
CPU リクエストと制限のサイズ設定に関しては、期待されるフェイルオーバー動作に応じてさまざまなアプローチがあります。
- フェイルオーバーが速く、コストが高い
- セカンダリーサイトでも、CPU リクエストと制限を上記のままにします。この場合、スケーリングをしなくても他のサイトはプライマリーサイトからのトラフィックをすぐに引き継ぐことができます。
- フェイルオーバーが遅く、コスト効率が高い
- セカンダリーサイトで、上記の CPU リクエストと制限を 50% 削減します。いずれかのサイトに障害が発生した場合、手動、自動、または Horizontal Pod Autoscaler を使用して、残りのサイトを 3 Pod から 6 Pod にスケーリングします。これには、クラスターに十分な予備容量またはクラスターの自動スケーリング機能が必要です。
- 一部の環境向けの代替設定
- セカンダリーサイトの CPU リクエストを 50% 削減しますが、CPU 制限は上記のままにします。この場合、残りのサイトがトラフィックを処理できますが、ノードの CPU 負荷が高くなり、ピークトラフィック時の応答時間が遅くなります。このセットアップの利点は、フェイルオーバー時に Pod の数を増やす必要がないため、設定が簡単になる点です。
