スタートガイド
概要
第1章 スタートガイド
1.1. 作業を開始する前の注意事項
マシンまたはコンテナープラットフォームが、Red Hat build of Keycloak で必要な使用方法に十分なメモリーと CPU を提供できることを確認してください。実稼働環境のサイズ設定を開始する方法の詳細は、CPU およびメモリーリソースのサイズ設定の概念 を参照してください。
OpenJDK 21 がインストールされていることを確認してください。
1.2. Red Hat build of Keycloak のダウンロード
Red Hat build of Keycloak を Red Hat の Web サイト からダウンロードして展開します。
このファイルを解凍すると、rhbk-26.0.12 という名前のディレクトリーが作成されます。
1.3. Red Hat build of Keycloak の起動
-
ターミナルから、
rhbk-26.0.12
ディレクトリーを開きます。 以下のコマンドを実行します。
Linux では、次を実行します。
bin/kc.sh start-dev
bin/kc.sh start-dev
Copy to Clipboard Copied! Windows では、次を実行します。
bin\kc.bat start-dev
bin\kc.bat start-dev
Copy to Clipboard Copied!
start-dev
オプションを使用すると、開発モードで Red Hat build of Keycloak が起動します。このモードでは、Red Hat build of Keycloak を初めて試して、すぐに起動して実行することができます。このモードは、Red Hat build of Keycloak の開発など、開発者にとって便利なデフォルト設定を提供します。
1.4. 管理者ユーザーの作成
Red Hat build of Keycloak にはデフォルトの管理者ユーザーがありません。Keycloak を起動する前に、管理者ユーザーを作成する必要があります。
- http://localhost:8080/ を開きます。
- ユーザー名とパスワードをフォームに入力します。
1.5. 管理コンソールへのログイン
- Red Hat build of Keycloak 管理コンソール に移動します。
- 前の手順で作成したユーザー名とパスワードでログインします。
1.6. レルムを作成します。
Red Hat build of Keycloak のレルムはテナントに相当します。各レルムにより、管理者はアプリケーションとユーザーの分離グループを作成できます。Red Hat build of Keycloak には、最初は master
と呼ばれる単一のレルムが含まれています。このレルムは、Red Hat build of Keycloak の管理にのみ使用し、アプリケーションの管理には使用しません。
次の手順を使用して、最初のレルムを作成します。
- Red Hat build of Keycloak 管理コンソール を開きます。
- master realm の横にある Red Hat build of Keycloak をクリックし、Create Realm をクリックします。
-
Realm name フィールドに
myrealm
と入力します。 - Create をクリックします。

1.7. ユーザーを作成します。
最初、レルムにはユーザーがいません。ユーザーを作成するには、以下を実行します。
- 現在のレルムがまだ myrealm であることを確認します。これは Manage の上に表示されています。
- 左側のメニューで Users をクリックします。
- Create new user をクリックします。
フォームに次の値を入力します。
-
Username:
myuser
- First name: 任意の名
- Last name: 任意の姓
-
Username:
- Create をクリックします。

このユーザーがログインするにはパスワードが必要です。初期パスワードを設定するには、以下を実行します。
- ページの上部にある Credentials をクリックします。
- Set password フォームにパスワードを入力します。
- ユーザーが最初のログイン時にこのパスワードを更新する必要がないように、Temporary を Off に切り替えます。

1.8. アカウントコンソールにログインします。
これで、アカウントコンソールにログインし、このユーザーが正しく設定されていることを確認できます。
- Red Hat build of Keycloak アカウントコンソール を開きます。
-
前の手順で作成した
myuser
とパスワードでログインします。
アカウントコンソールのユーザーとして、プロファイルの変更、2 要素認証の追加、ID プロバイダーアカウントの追加などを実行してアカウントを管理できます。

1.9. 最初のアプリケーションのセキュリティー保護
最初のアプリケーションに対してセキュリティー保護を行うには、まずアプリケーションを Red Hat build of Keycloak インスタンスに登録します。
- Red Hat build of Keycloak 管理コンソール を開きます。
- 左上隅にある master という単語をクリックし、myrealm をクリックします。
- Clients をクリックします。
- Create client をクリックします
フォームに次の値を入力します。
-
Client type:
OpenID Connect
Client ID:
myclient
-
Client type:
- Next をクリックします。
- Standard flow が有効になっていることを確認します。
- Next をクリックします。
Login settings で以下の変更を行います。
-
Valid redirect URIs を
https://www.keycloak.org/app/*
に設定します。 -
Web origins を
https://www.keycloak.org
に設定します。
-
Valid redirect URIs を
- Save をクリックします。

クライアントが正常に作成されたことを確認するために、Keycloak Web サイト の SPA テストアプリケーションを使用できます。
- https://www.keycloak.org/app/ を開きます。
- Save をクリックして、デフォルト設定を使用します。
- Sign in をクリックし、前に起動した Red Hat build of Keycloak サーバーを使用してこのアプリケーションを認証します。
1.10. 次のステップ
実稼働環境で Red Hat build of Keycloak を実行する前に、以下の操作を行うことを検討してください。
- PostgreSQL などの実稼働対応データベースへの切り替え。
- 独自の証明書を使用した SSL の設定。
- よりセキュアな管理者パスワードへの切り替え。
詳細は、サーバー設定ガイド を参照してください。
第2章 スケーリング
Red Hat build of Keycloak を開始した後、次のスケーリングおよびチューニングのガイドラインを使用して、インスタンスを必要なロードに適応させることを検討してください。
- リソースの利用を最小限に抑える
- 目標応答時間を達成する
- データベースプールの競合を最小限に抑える
- メモリー不足エラーや過剰なガベージコレクションのオーバーヘッドを解決する
- 水平スケーリングによる高い可用性を実現する
2.1. 垂直スケーリング
Red Hat build of Keycloak ワークロードを監視するときは、CPU またはメモリーの使用率が低すぎたり高すぎたりしていないかを確認します。Java 仮想マシン (JVM) で使用可能なリソースをより適切に調整するには、CPU およびメモリーリソースのサイズ設定の概念 を参照してください。
JVM で使用可能なメモリーの量を増やす前に、特にメモリー不足エラーが発生した場合は、ヒープダンプを使用してフットプリントの増加原因を特定することが最善策となります。応答時間が長すぎる場合は、HTTP 作業キューが大きすぎることを示している可能性があり、単にメモリーを増やすよりもロード制限を調整した方が効果的です。以下のセクションを参照してください。
2.1.1. 一般的なチューニングオプション
Red Hat build of Keycloak は、使用可能なコアの数に基づいて、使用されるスレッドの数を自動的に調整します。スレッド数を手動で変更すると、全体的なスループットが向上する可能性があります。詳細は、スレッドプールの設定の概念 を参照してください。ただし、スレッド数の変更は、データベース接続などの他の JVM リソースと組み合わせて行う必要があります。そうしないと、ボトルネックが別の場所に移動する可能性があります。詳細は、データベース接続プールの概念 を参照してください。
キューに入れられた作業のメモリー使用率を制限し、ロード制限を提供するには、スレッドプールの設定の概念 を参照してください。
データベース接続の取得時にタイムアウトが発生する場合は、利用可能な接続数を増やすことを検討する必要があります。詳細は、データベース接続プールの概念 を参照してください。
2.1.2. 垂直自動スケーリング
Kubernetes などの一部のプラットフォームでは、垂直方向に自動スケーリングするメカニズムが提供されています。垂直自動スケーリングは、サーバーインスタンスの再起動が必要な場合 (現時点で Java on Kubernetes の場合に該当)、Red Hat build of Keycloak では推奨されません。代わりに、CPU やメモリーの制限を高くして、必要に応じて JVM がそれらの制限内で適応できるようにすることを検討できます。
2.2. 水平スケーリング
単一の 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 build of 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 カスタムリソースはスケーラブルであるため、組み込みの自動スケーラー の対象にすることができます。