2.2. 水平スケーリング
1 つの Red Hat build of Keycloak インスタンスの場合は、可用性の問題の影響を受けます。インスタンスがダウンした場合、別のインスタンスが起動するまで完全に停止します。異なるマシンで 2 つ以上のクラスターメンバーを実行すると、Red Hat build of Keycloak の可用性が大幅に向上します。
単一の JVM で処理できる同時リクエストの数に制限があります。追加のサーバーインスタンスでは、関連するリソース（データベースや分散キャッシュなど）がそのスケーリングを制限するまで、スループットのほぼ線形スケーリングを行うことができます。
通常、Red Hat build of Keycloak Operator が水平的なスケーリングに関する懸念を処理できることを検討してください。Operator を使用する場合は、必要に応じて Keycloak カスタムリソースの spec.instances を水平スケーリングに設定します。詳細は、Red Hat build of Keycloak Operator を使用した HA 用 Red Hat ビルドの Keycloak のデプロイ を参照してください。
Operator を使用していない場合は、以下を確認してください。
- インスタンスがより高いマシン上にある可能性があります。Kubernetes で、Pod のアンチアフィニティーを使用してこれを適用します。
分散キャッシュを使用します。マルチサイトクラスターの場合、クラスターメンバーに外部キャッシュを使用して同じ状態を共有します。関連する設定の詳細は、分散キャッシュの 設定 を参照してください。組み込み Infinispan キャッシュには、以下のような水平スケーリングに関する考慮事項があります。
- 自分の企業はお互いを発見する手段が必要である。詳細は、分散キャッシュの設定 の 検出 を参照してください。
- このキャッシュは、ストレッチクラスターとも呼ばれる複数のアベイラビリティーゾーンにまたがるクラスターには最適ではありません。組み込み Infinispan キャッシュでは、1 つのアベイラビリティーゾーンにすべてのインスタンスが含まれるようにします。目標は、応答時間に拡張する通信における不要なラウンドトリップを回避することです。Kubernetes では、Pod のアフィニティーを使用してこの Pod グループを適用します。
- このキャッシュは、複数のメンバーへの同時参加または退出を適切に処理しません。特に同時に出るメンバーは、データが失われる可能性があります。Kubernetes では、デフォルトのシリアル処理で StatefulSet を使用して、Pod が順次開始および停止されるようにすることができます。
サイト全体が利用できない場合にサービスの可用性が失われないようにするには、マルチサイトデプロイメントの詳細について、高可用性ガイド を参照してください。マルチサイトデプロイメント を参照してください。
2.2.1. 水平自動スケーリング
水平自動スケーリングでは、オンデマンドで Red Hat build of Keycloak インスタンスを追加または削除できます。起動時間はインスタンス化されず、最適化されたイメージを使用して開始時間を最小限に抑える必要があることに注意してください。
組み込み Infinispan キャッシュクラスターを使用する場合は、クラスターメンバーを動的に追加または削除するには Infinispan が Infinispan キャッシュのリバランスを実行する必要があり、これらのキャッシュに多くのエントリーが存在する場合はコストがかかる可能性があります。この時間を最小限にするために、セッション関連のキャッシュ内のエントリー数はデフォルトで 10000 に制限します。この最適化は、設定で persistent-user-sessions 機能が明示的に無効にされていない場合にのみ可能であることに注意してください。
Kubernetes では、Keycloak カスタムリソースは拡張可能であることを意味します。つまり、組み込みオートスケーラーの対象に することができます。
