第10章 サーバーキャッシュ設定

Red Hat Single Sign-On には、2 種類のキャッシュがあります。DB の負荷を減らして、データをメモリーに維持することで、データベースの前にあるキャッシュのタイプが 1 つあり、全体的に応答時間を削減します。レルム、クライアント、ロール、およびユーザーメタデータはこの種類のキャッシュに保存されます。このキャッシュはローカルキャッシュです。より Red Hat Single Sign-On サーバーがあるクラスター内にある場合でも、ローカルキャッシュはレプリケーションを使用しません。代わりに、ローカルにコピーのみを保持し、エントリーが更新されても無効化メッセージが残りのクラスターに送信され、エントリーはエビクトされます。別個のレプリケートされたキャッシュ work があります。この作業では、ローカルキャッシュから削除されるエントリーについて、無効化メッセージをクラスター全体に送信します。これにより、ネットワークトラフィックが大幅に削減され、効率的な状態になり、機密メタデータをネットワーク経由で送信しないようにします。

2 つ目のキャッシュは、ユーザーセッション、オフライントークンの管理、およびログイン失敗の追跡を処理し、サーバーがパスワードのシャッシングやその他の攻撃を検出できるようにします。これらのキャッシュに保持されるデータは一時的なものですが、メモリーのみはクラスター全体に複製される可能性があります。

本章では、クラスター化されたデプロイメントと非クラスターデプロイメント向けのこれらのキャッシュの設定オプションについて説明します。

注記

これらのキャッシュの高度な設定については、JBoss EAP 設定ガイドの Infinispan セクションを参照してください。

10.1. エビクションとの有効期限

Red Hat Single Sign-On には複数の異なるキャッシュが設定されます。セキュアなアプリケーション、一般的なセキュリティーデータ、設定オプションに関する情報を保持するレルムキャッシュがあります。また、ユーザーメタデータを含むユーザーキャッシュもあります。両方のキャッシュを 10000 エントリーに制限し、最も最近使用されたエビクションストラテジーを使用します。それぞれがクラスター設定のエビクションを制御するオブジェクトリビジョンキャッシュにも関連付けられます。このキャッシュは暗黙的に作成され、設定されたサイズの 2 倍になります。認証データを保持する authorization キャッシュにも同様のが適用されます。keys キャッシュは外部キーについてのデータを保持し、専用のリビジョンキャッシュを持つ必要はありません。むしろ、有効期限 が明示的に宣言されているため、キーは定期的に期限切れになり、外部クライアントまたは ID プロバイダーから定期的にダウンロードされます。

これらのキャッシュのエビクションポリシーおよび最大エントリーは、操作モード に応じて、standalone.xml、standalone-ha.xml、または domain.xml で設定できます。設定ファイルには、以下のような infinispan サブシステムの一部があります。 

<subsystem xmlns="urn:jboss:domain:infinispan:9.0">
    <cache-container name="keycloak">
        <local-cache name="realms">
            <object-memory size="10000"/>
        </local-cache>
        <local-cache name="users">
            <object-memory size="10000"/>
        </local-cache>
        ...
        <local-cache name="keys">
            <object-memory size="1000"/>
            <expiration max-idle="3600000"/>
        </local-cache>
        ...
    </cache-container>

許可されるエントリーの数を制限するか、拡張するには、object 要素または特定のキャッシュ設定の expiration 要素を追加または編集します。

さらに、個別のキャッシュ sessions、clientSessions、offlineSessions、offlineClientSessions、loginFailures、および actionTokens もあります。これらのキャッシュはクラスター環境で配布され、デフォルトでバインドされないサイズに設定されます。バインドされている場合、一部のセッションが失われる可能性があります。期限切れのセッションは、制限なしでこれらのキャッシュのサイズを増やしないように、Red Hat Single Sign-On が内部でクリアされます。多数のセッションが原因でメモリーの問題が発生する場合は、以下を試行できます。

  • クラスターのサイズを増やします (より多くのノードは、セッションがノード間で均等に分散されることを意味します)
  • Red Hat Single Sign-On サーバープロセスのメモリーを増やす。
  • 所有者の数を減らし、1 箇所にキャッシュが 1 度保存されるようにします。詳細は、「レプリケーションおよびフェイルオーバー」 を参照してください。
  • 分散キャッシュの L1 ライフスパンを無効にします。詳細は、Infinispan ドキュメントを参照してください。
  • セッションのタイムアウトを減らします。これは、Red Hat Single Sign-On の管理コンソールの各レルムに個別に実行できます。ただし、エンドユーザーのユーザービリティーに影響する可能性があります。詳細は、タイムアウト を参照してください。

他にもレプリケートされたキャッシュ (work) があり、大半はクラスターノード間でメッセージを送信するために使用されます。また、デフォルトではバインドされません。ただし、このキャッシュのエントリーは非常に短くなるため、このキャッシュでメモリーの問題は発生しません。