8.3. スティッキーセッションの有効化

通常のクラスターデプロイメントは、プライベートネットワークにあるロードバランサー (リバースプロキシー) および 2 つ以上の Red Hat build of Keycloak サーバーで構成されます。パフォーマンスの観点からは、ロードバランサーが特定のブラウザーセッションに関連するすべての要求を同じ Red Hat build of Keycloak バックエンドノードに転送すると便利です。

なぜなら、Red Hat build of Keycloak は、現在の認証セッションとユーザーセッションに関連するデータを保存する裏で、Infinispan の分散キャッシュを使用しているためです。Infinispan の分散キャッシュは、所有者の数が限られています。つまり、セッション関連のデータはクラスターノードにのみ保存され、他のノードはそれにアクセスする場合はリモートでデータを検索する必要があります。

たとえば、ID 123 の認証セッションが node1 の Infinispan キャッシュに保存され、node2 がこのセッションを検索する必要がある場合は、特定のセッションエンティティーを返すために、ネットワーク経由で要求を node1 に送信する必要があります。

特定のセッションエンティティーが常にローカルで利用可能な場合に利点があります。これは、スティッキーセッションを使用して実行できます。パブリックフロントエンドロードバランサーと 2 つのバックエンド Red Hat build of Keycloak ノードを持つクラスター環境のワークフローは次のようになります。

この観点から、ロードバランサーが次の要求をすべて node2 に転送することは有用です。なぜなら、これは ID 123 の認証セッションの所有者であるノードであり、Infinispan がこのセッションをローカルで検索できるからです。認証が終了すると、認証セッションはユーザーセッションに変換されます。その場合も ID 123 と同じになるため、node2 に保存されます。

クラスターの設定にスティッキーセッションは必須ではありませんが、上記の理由でパフォーマンスの観点から推奨されます。AUTH_SESSION_ID cookie をスティックするようにロードバランサーを設定する必要があります。この変更を加えるのに適した手順は、ロードバランサーによって異なります。

プロキシーがバックエンドノードからの cookie を処理せずにセッションアフィニティーをサポートする場合は、ノードを cookie にアタッチせず、リバースプロキシー機能に依存するのみにするために、spi-sticky-session-encoder-infinispan-should-attach-route オプションを false に設定する必要があります。

bin/kc.[sh|bat] start --spi-sticky-session-encoder-infinispan-should-attach-route=false

デフォルトでは、spi-sticky-session-encoder-infinispan-should-attach-route オプションの値は true であるため、ノード名は cookie にアタッチされ、リバースプロキシーには後続の要求の送信先であるノードが示されます。