9.4. スティッキーセッション
通常のクラスターデプロイメントは、プライベートネットワークにあるロードバランサー (逆引きプロキシー) および 2 つ以上の Red Hat Single Sign-On サーバーで構成されます。パフォーマンスの観点で、ロードバランサーが特定のブラウザーセッションに関連するすべてのリクエストを同じ Red Hat Single Sign-On バックエンドノードに転送すると良いでしょう。
その理由は、Red Hat Single Sign-On は、現在の認証セッションとユーザーセッションに関連するデータを保存するために、Infinispan の分散キャッシュを使用しているためです。Infinispan の分散キャッシュは、デフォルトで 1 所有者で設定されます。つまり、特定のセッションは 1 つのクラスターノードにのみ保存され、他のノードはそれにアクセスする場合はリモートでセッションを検索する必要があります。
たとえば、ID 123
の認証セッションが node1
の Infinispan キャッシュに保存され、node2
がこのセッションを検索する必要がある場合は、特定のセッションエンティティーを返すために、ネットワーク経由でリクエストを node1
に送信する必要があります。
特定のセッションエンティティーが常にローカルで利用可能な場合に利点があります。これは、スティッキーセッションを使用して実行できます。パブリックフロントエンドロードバランサーと 2 つのバックエンド Red Hat Single Sign-On ノードを持つクラスター環境のワークフローは次のようになります。
- ユーザーが最初のリクエストを送信して、Red Hat Single Sign-On のログイン画面を表示する
- この要求はフロントエンドロードバランサーにより提供されます。このロードバランサーは、これをランダムなノード (例: node1) に転送します。厳密に言及されているので、ノードはランダムにする必要はありませんが、他の基準 (クライアント IP アドレスなど) に従って選択できます。これらはすべて、基盤のロードバランサーの実装および設定 (逆引きプロキシー) によって異なります。
- Red Hat Single Sign-On は、ランダム ID (例: 123) で認証セッションを作成し、Infinispan キャッシュに保存します。
-
Infinispan の分散キャッシュは、セッション ID のハッシュに基づいてセッションのプライマリー所有者を割り当てます。詳細は、Infinispan のドキュメント を参照してください。Infinispan が、
node2
をこのセッションの所有者として割り当てたとしましょう。 -
Red Hat Single Sign-On は、
<session-id>.<owner-node-id>
のような形式で cookieAUTH_SESSION_ID
を作成します。この例では、123.node2
になります。 - ブラウザーで Red Hat Single Sign-On ログイン画面と AUTH_SESSION_ID クッキーを持つユーザーに対して応答が返されます。
この観点から、ロードバランサーが次のリクエストをすべて node2
に転送する利点があります。これはID 123
の認証セッションの所有者であるノードであり、Infinispan がこのセッションをローカルで検索できるためです。認証が終了すると、認証セッションはユーザーセッションに変換されます。これは、ID 123
が同じであるため、node2
にも保存されます。
クラスターの設定にスティッキーセッションは必須ではありませんが、上記の理由でパフォーマンスの観点から推奨されます。AUTH_SESSION_ID
cookie をスティッキーするようにロードバランサーを設定する必要があります。これは、ロードバランサーによって異なります。
起動時にシステムプロパティー jboss.node.name
を使用するには、Red Hat Single Sign-On で、ルートの名前に対応する値を使用することが推奨されます。たとえば、-Djboss.node.name=node1
は、node1
を使用してルートを特定します。このルートは Infinispan キャッシュによって使用され、ノードが特定のキーの所有者である場合に AUTH_SESSION_ID クッキーに割り当てられます。このシステムプロパティーを使用した起動コマンドの例を以下に示します。
cd $RHSSO_NODE1 ./standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node1
実稼働環境では、ルート名はバックエンドホストと同じ名前を使用する必要がありますが、必須ではありません。別のルート名を使用できます。たとえば、プライベートネットワーク内で Red Hat Single Sign-On サーバーのホスト名を非表示にする場合などです。
9.4.1. ルートの追加を無効化
一部のロードバランサーは、バックエンド Red Hat Single Sign-On ノードに依存する代わりに、ルート情報を追加するように設定できます。ただし、上記で説明されているように、Red Hat Single Sign-On によるルートの追加が推奨されます。Red Hat Single Sign-On は特定のセッションの所有者で、そのノード (必ずしもローカルノードではない) にルーティングできるエンティティーを認識するため、この方法によりパフォーマンスが向上します。
以下を Red Hat Single Sign-On サブシステム設定の RHSSO_HOME/standalone/configuration/standalone-ha.xml
ファイルに追加すると、Red Hat Single Sign-On による AUTH_SESSION_ID cookie へのルート情報の追加を無効にできます。
<subsystem xmlns="urn:jboss:domain:keycloak-server:1.2"> ... <spi name="stickySessionEncoder"> <provider name="infinispan" enabled="true"> <properties> <property name="shouldAttachRoute" value="false"/> </properties> </provider> </spi> </subsystem>