2.13. Operator を使用した複数のアベイラビリティーゾーンにまたがる Red Hat build of Keycloak のデプロイ
Red Hat build of Keycloak Operator を構成要素として、高可用性用に Red Hat build of Keycloak を導入します。
この章では、負荷テスト済みでアベイラビリティーゾーンの障害を回復する、OpenShift 用の高度な Red Hat build of Keycloak 設定について説明します。
この手順は、シングルクラスターデプロイメントの概念 の章で説明されているセットアップで使用することを想定しています。シングルクラスターデプロイメントの構成要素 の章で説明されている他の構成要素とともに使用してください。
2.13.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift クラスターが複数のアベイラビリティーゾーンにまたがってデプロイされており、各ゾーンにワーカープールが設定されている。
- Red Hat build of Keycloak Operator を使用した 基本的な Red Hat build of Keycloak のデプロイメント の理解。
- 複数のアベイラビリティーゾーンへの AWS Aurora のデプロイ の章を使用してデプロイされた Aurora AWS データベース。
2.13.2. 手順 リンクのコピーリンクがクリップボードにコピーされました!
- CPU およびメモリーリソースのサイジングの概念 の章を使用して、デプロイメントのサイジングを決定します。
- Red Hat build of Keycloak Operator のインストール の章の説明に従って、Red Hat build of Keycloak Operator をインストールします。
- 以下の設定ファイルには、複数のアベイラビリティーゾーンへの AWS Aurora のデプロイ で説明されている、Aurora データベースへの接続に関連するオプションが含まれています。
- Amazon Aurora PostgreSQL データベースで使用するために準備 したカスタムの Red Hat build of Keycloak イメージをビルドします。
ステップ 1 で計算したリソース要求および制限を含む次の値を使用して、Red Hat build of Keycloak CR をデプロイします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- データベースのステートメントキャッシュを許可するには、データベース接続プールの初期サイズ、最大サイズ、最小サイズが同一である必要があります。この数値はシステムのニーズに合わせて調整してください。Red Hat build of Keycloak の組み込みキャッシュにより、ほとんどのリクエストはデータベースに影響を与えないため、このように変更すると、1 秒あたり数百件のリクエストを処理できます。詳細は、データベース接続プールの概念 の章を参照してください。
- 2 3
- Red Hat build of Keycloak イメージへの URL を指定します。イメージが最適化されている場合は、
startOptimizedフラグをtrueに設定します。 - 4
- 負荷がかかっているシステムを分析できるように、メトリクスエンドポイントを有効にします。
2.13.3. デプロイメントの確認 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat build of Keycloak デプロイメントの準備ができていることを確認します。
oc wait --for=condition=Ready keycloaks.k8s.keycloak.org/keycloak oc wait --for=condition=RollingUpdate=False keycloaks.k8s.keycloak.org/keycloak
oc wait --for=condition=Ready keycloaks.k8s.keycloak.org/keycloak
oc wait --for=condition=RollingUpdate=False keycloaks.k8s.keycloak.org/keycloak
2.13.4. オプション: 負荷制限 リンクのコピーリンクがクリップボードにコピーされました!
負荷制限を有効にするには、キューに入れられるリクエストの数を制限します。
キューに入れられる HTTP リクエストの最大数による負荷制限
spec:
additionalOptions:
- name: http-max-queued-requests
value: "1000"
spec:
additionalOptions:
- name: http-max-queued-requests
value: "1000"
超過したリクエストはすべて HTTP 503 で処理されます。
複数の並行スレッドが、要求された CPU 制限に達した時点で OpenShift によるスロットリングを引き起こすため、http-pool-max-threads の値をさらに制限することを検討してもよいでしょう。
詳細は、負荷制限に関する スレッドプールの設定の概念 の章を参照してください。
2.13.5. オプション: スティッキーセッションの無効化 リンクのコピーリンクがクリップボードにコピーされました!
HAProxy によって実行される負荷分散は、OpenShift および Red Hat build of Keycloak Operator が提供するデフォルトのパススルー Ingress セットアップで実行される場合、ソースの IP アドレスに基づくスティッキーセッションを使用して実行されます。負荷テストを実行するとき、または HAProxy の前にリバースプロキシーがあるときは、1 つの Red Hat build of Keycloak Pod ですべてのリクエストを受信しないように、この設定を無効にすることができます。
Red Hat build of Keycloak カスタムリソースの spec に次の補足設定を追加して、スティッキーセッションを無効にします。