Keycloak を起動したら、これらのスケーリングとチューニングのガイドラインを使用して、必要な負荷に合わせてインスタンスを調整することを検討してください。
リソース使用率の最小化
目標レスポンス時間の達成
データベースプール競合の最小化
メモリ不足エラーまたは過剰なガベージコレクションオーバーヘッドの解決
水平スケーリングによる高可用性の提供
Keycloak のワークロードを監視する際に、CPU またはメモリが過剰または過少に使用されていないか確認してください。Java Virtual Machine (JVM) で利用可能なリソースをより適切に調整するために、CPU およびメモリサイジングの概念を参照してください。
特にメモリ不足エラーが発生した場合、JVM で利用可能なメモリ量を増やす前に、ヒープダンプを使用してフットプリントの増加に何が寄与しているかを特定するのが最善です。過剰なレスポンス時間は、HTTP ワークキューが大きすぎる可能性も示唆しており、単にメモリを増やすよりも、負荷分散のためのチューニングの方が適切かもしれません。次のセクションを参照してください。
Keycloak は、利用可能にするコア数に基づいて、使用するスレッド数を自動的に調整します。スレッド数を手動で変更すると、全体的なスループットを向上させることができます。詳細については、スレッドプールの構成に関する概念を参照してください。ただし、スレッド数の変更は、データベース接続などの他の JVM リソースと連携して行う必要があります。そうしないと、ボトルネックを別の場所に移動してしまう可能性があります。詳細については、データベース接続プールの概念を参照してください。
キューに入れられたワークのメモリ使用率を制限し、負荷分散を提供するには、スレッドプールの構成に関する概念を参照してください。
データベース接続の取得でタイムアウトが発生している場合は、利用可能な接続数を増やすことを検討する必要があります。詳細については、データベース接続プールの概念を参照してください。
単一の Keycloak インスタンスは、可用性の問題の影響を受けやすいです。インスタンスがダウンすると、別のインスタンスが起動するまで完全な停止が発生します。異なるマシン上で 2 つ以上のクラスタメンバーを実行することで、Keycloak の可用性を大幅に向上させることができます。
単一の JVM には、処理できる同時リクエスト数に制限があります。追加のサーバーインスタンスは、データベースや分散キャッシュなどの関連リソースがスケーリングを制限するまで、スループットのほぼ線形のスケーリングを提供できます。
一般に、Keycloak Operator に水平スケーリングの懸念事項を処理させることを検討してください。Operator を使用する場合は、水平方向にスケールするために、Keycloak カスタムリソースの spec.instances を必要に応じて設定します。詳細については、Keycloak Operator を使用した HA のための Keycloak のデプロイを参照してください。
Operator を使用していない場合は、以下を確認してください。
インスタンスが別々のマシンにある場合、より高い可用性が可能です。Kubernetes では、これを強制するために Pod アンチアフィニティを使用します。
分散キャッシュを使用します。マルチサイトクラスタの場合は、クラスタメンバーが同じ状態を共有するために外部キャッシュを使用します。関連する構成の詳細については、分散キャッシュの構成を参照してください。組み込みの Infinispan キャッシュには、水平スケーリングに関する考慮事項が含まれています。
インスタンスは、互いを検出する方法が必要です。詳細については、分散キャッシュの構成のディスカバリを参照してください。
このキャッシュは、ストレッチクラスタとも呼ばれる、複数のアベイラビリティゾーンにまたがるクラスタには最適ではありません。組み込みの Infinispan キャッシュの場合、すべてのアベイラビリティゾーンにインスタンスを 1 つずつ配置するようにしてください。目標は、レスポンス時間を増幅する不要なラウンドトリップを通信で回避することです。Kubernetes では、Pod アフィニティを使用して Pod のこのグループ化を強制します。
このキャッシュは、複数のメンバーが同時に参加または離脱することを正常に処理しません。特に、メンバーが同時に離脱すると、データ損失につながる可能性があります。Kubernetes では、デフォルトのシリアル処理で StatefulSet を使用して、Pod が順番に起動および停止されるようにすることができます。
サイト全体が利用できなくなった場合にサービスの可用性を失うことを避けるには、マルチサイトデプロイメントの詳細について高可用性ガイドを参照してください。マルチサイトデプロイメントを参照してください。
水平自動スケーリングを使用すると、Keycloak インスタンスをオンデマンドで追加または削除できます。起動時間は瞬時ではないこと、および起動時間を最小限に抑えるために最適化されたイメージを使用する必要があることに注意してください。
組み込みの Infinispan キャッシュクラスタを使用する場合、クラスタメンバーを動的に追加または削除するには、Infinispan キャッシュのリバランスを実行する必要があります。キャッシュに多数のエントリが存在する場合、これはコストがかかる可能性があります。この時間を最小限に抑えるために、セッション関連キャッシュのエントリ数をデフォルトで 10000 に制限しています。この最適化は、構成で persistent-user-sessions 機能が明示的に無効にされていない場合にのみ可能です。
Kubernetes では、Keycloak カスタムリソースはスケーラブルです。つまり、組み込みのオートスケーラーのターゲットにすることができます。たとえば、平均 CPU 使用率に基づいてスケーリングするには、次のようにします。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: keycloak-hpa
namespace: keycloak-cluster
spec:
scaleTargetRef:
apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
name: keycloak
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80| メモリのスケーリングは、永続セッションが有効になっている場合は一般に不要であり、リモート Infinispan を使用している場合はまったく不要になるはずです。永続セッションまたはリモート Infinispan を使用していて、メモリの問題が発生する場合は、問題を完全に診断し、CPU およびメモリサイジングの概念ガイドを見直すのが最善です。メモリ要求と制限を調整することが、水平スケーリングよりも推奨されます。 |
追加情報については、Kubernetes ドキュメント、特にカスタムメトリクスの使用方法に関する情報などを参照してください。