Cookieでユーザーに返されます。対して以降のリクエストすべてを転送するなら有益なのです。スティッキー・セッションはクラスターの設定のために必須ではありませんが、上記の理由からパフォーマンスをあげるために有効です。Cookieで固定するようロードバランサーを設定する必要があります。どのように行うかはロードバランサーによります。使用し、経路名に対応する値を使用することをお勧めします。Cookieに関連付けられます。このシステム・プロパティーを使用した起動コマンドの例を以下に示します。-Djboss.node.name=node1通常、プロダクション環境では経路名はバックエンド・ホストと同じ名前を使うべきですが、必要ではありません。プライベート・ネットワーク内のKeycloakサーバーのホスト名を隠す場合などに、別の経路名を使用できます。経路の追加を無効にするいくつかのロードバランサーは、バックエンドのKeycloakノードに頼るのではなく、経路情報を自身で追加するように設定できます。前述のとおり、Keycloakによる経路の追加が推奨されます。これは、Keycloakが特定のセッションの所有者であり、必ずしもローカルノードではないノードにルーティングできるエンティティーを認識しているため、このようにパフォーマンスが向上するためです。Cookieへの経路情報の追加を無効にすることができます。</spi></subsystem>マルチキャストネットワークの設定デフォルトのクラスタリング・サポートには、IPマルチキャストが必要です。マルチキャストは、ネットワークのブロードキャスト・プロトコルです。このプロトコルは、起動時にクラスターの検出と参加に使用されます。Keycloakが使用する分散キャッシュのレプリケーションや無効化のためのメッセージをブロードキャストするためにも使用されます。クラスタリング・サブシステムはJGroupsスタックで動作しています。クラスタリング用のバインドアドレスは、デフォルトIPアドレスとして127.0.0.1を持つプライベート・ネットワーク・インターフェースにバインドされています。セクションを編集してください。IPマルチキャストなしでKeycloakをクラスタリングすることは可能ですが、このトピックはこのガイドの説明範囲を超えています。クラスター通信のセキュリティー保護クラスター・ノードがプライベート・ネットワークで隔離されている場合は、クラスターに参加したり、クラスター内の通信を表示したりするために、プライベート・ネットワークへのアクセスが必要です。クラスター通信の認証と暗号化を有効にすることもできます。プライベート・ネットワークが安全である限り、認証と暗号化を有効にする必要はありません。どちらの場合も、Keycloakはクラスター上で機密情報を送信しません。Guide’を参照してください。シリアライズされたクラスターの起動Keycloakクラスター・ノードは並行して起動することができます。Keycloakサーバー・インスタンスが起動すると、データベースの移行、インポート、初回の初期化を行います。DBロックは、クラスター・ノードが同時に起動した場合、起動アクションが競合するのを防ぐために使用されます。デフォルトでは、このロックの最大タイムアウトは900秒です。ノードがこのタイムアウト時間を超えてロック状態のままだった場合、起動は失敗します。通常は、デフォルト値を増減する必要はありません。ファイルで、念のためこの増減を設定することができます。このファイルの場所は、動作モードに依存します。</provider></spi>クラスターの起動クラスター内でのKeycloakの起動は動作モードによって異なります。--host-config=host-slave.xml追加のパラメーターまたはシステム・プロパティーを使用する必要があります。システム・プロパティーです(スティッキー・セッションのセクションで説明しています)。トラブルシューティングクラスターを実行すると、両方のクラスターノードのログに以下のようなメッセージが表示されます。node2/keycloak]ノードが1つだけ表示されている場合、クラスターホストが同じクラスターに参加していない可能性があります。通常、プライベート・ネットワーク上にクラスターノードを置き、ファイアウォールは置かずに通信するのがベスト・プラクティスです。その代わり、ネットワークへのパブリック・アクセス・ポイントでは、ファイアウォールを有効にすることができます。何らかの理由によりクラスターノードでファイアウォールを有効にする場合、ポートをいくつか開く必要があります。デフォルト値は、マルチキャスト・アドレス230.0.0.4のUDPポート55200とマルチキャスト・ポート45688です。JGroupsスタックの診断機能などの追加機能を有効にするには、ポートをさらに開く必要がありますので、その点は注意してください。Keycloakは、InfinispanまたはJGroupsにクラスタリング作業のほとんどを委譲します。JGroupsを参照してください。フェイルオーバーのサポート(高可用性)、エビクション、有効期限およびキャッシュ・チューニングに関心がある場合は、サーバー・キャッシュ設定を参照してください。サーバー・キャッシュ設定Keycloakには、2つのタイプのキャッシュがあります。1つ目のキャッシュは、データベースの前に置かれていて、DBの負荷を減らし、データをメモリーに保持することで全体の応答時間を短縮します。レルム、クライアント、ロール、およびユーザー・メタデータは、このタイプのキャッシュに保持されます。このキャッシュはローカル・キャッシュです。クラスターにより多くのKeycloakサーバーがある場合でも、ローカル・キャッシュはレプリケーションを使用しません。その代わり、ローカル・キャッシュはローカルにのみコピーを保持し、エントリーが更新された場合は無効化メッセージが残りのクラスターに送られてエントリーは追い出されます。これは、どのエントリーがローカル・キャッシュから取り除かれるかについて、クラスター全体に無効化メッセージを送信するタスクになります。これによって、ネットワーク・トラフィックが大幅に減少し、効率化され、機密なメタデータのネットワーク経由での送信が回避されます。2つ目のキャッシュは、ユーザー・セッション、オフライン・トークン、ログイン・エラーの履歴保持の管理を担当し、サーバーがパスワード・フィッシングやその他の攻撃を検出できるようにします。これらのキャッシュ内のデータは一時的で、メモリーにのみ保持されるものですが、クラスター全体にレプリケーションされる可能性があります。この章では、クラスター構成と非クラスター構成の両方のためのキャッシュ用設定オプションについて説明します。Infinispanのセクションを参照してください。退避と有効期限Keycloakには、さまざまなキャッシュの設定があります。その一つにレルムキャッシュというものがあり、セキュリティー保護されたアプリケーション、一般的なセキュリティー・データおよび設定オプションに関する情報を保持しています。ユーザー・メタデータを含むユーザー・キャッシュがあります。このキャッシュのデフォルト値は最大10000エントリーで、最近最も使われなかったものを退避する戦略が使用されます。これらのキャッシュはそれぞれ、クラスター構成内での退避を制御するオブジェクト・リビジョン・キャッシュにも関連付けられています。このキャッシュは暗黙的に作成され、設定されたサイズの2倍のサイズがあります。キャッシュについても同様です。キャッシュは外部キーに関するデータを保持し、専用のリビジョン・キャッシュを保持する必要はありません。宣言されているので、キーは定期的に期限切れとなり、外部のクライアントやアイデンティティー・プロバイダーから定期的にダウンロードされます。内で設定することができます。設定ファイルには、infinispanサブシステムの次のような部分があります。要素を追加または編集するだけでできます。いったキャッシュもあります。これらのキャッシュはクラスター環境で分散され、デフォルトではサイズが制限されていません。制限がある場合、一部のセッションが失われる可能性があります。制限なしにこれらのキャッシュサイズが増大することを避けるために、期限切れのセッションはKeycloak自身によって内部的にクリアされます。多数のセッションが原因でメモリーの問題が発生した場合は、次の操作を試すことができます。クラスターのサイズを大きくします(クラスター内のノードが多いほど、セッションはノード間でより均等に分散されます)Keycloakサーバープロセスのメモリーを増やしますキャッシュが1つの場所に保存されるように、所有者の数を減らします。詳細はレプリケーションとフェイルオーバーを参照してください分散キャッシュのl1-lifespanを無効にします。詳細については、Infinispanのマニュアルを参照してください。セッション・タイムアウトを減らします。これはKeycloak管理コンソールの各レルムで個別に実行できます。これはエンドユーザーのユーザビリティーに影響する可能性があります。