CPU 和記憶體資源大小調整概念 - Keycloak

效能建議

擴展到更多 Pod 時（由於額外開銷）以及使用跨數據中心設置時（由於額外流量和操作），效能將會降低。
當 Keycloak 實例運行較長時間時，增加快取大小可以提高效能。這將減少回應時間並減少資料庫上的 IOPS。儘管如此，當實例重新啟動時，這些快取仍需要填滿，因此不要基於快取填滿後測量的穩定狀態來設定過於緊繃的資源。
將這些值作為起點，並在投入生產之前執行您自己的負載測試。

總結

建議

一個 Pod 的基本記憶體使用量（包括 Realm 資料快取和 10,000 個快取的工作階段）為 1250 MB 的 RAM。
在容器中，Keycloak 為堆記憶體分配了 70% 的記憶體限制。它還將使用約 300 MB 的非堆記憶體。要計算請求的記憶體，請使用上述計算。作為記憶體限制，從上述值中減去非堆記憶體，然後將結果除以 0.7。
對於每秒 15 個基於密碼的使用者登入，請為叢集分配 1 個 vCPU（測試結果高達每秒 300 個）。

Keycloak 大部分 CPU 時間都花在雜湊使用者提供的密碼上，並且與雜湊迭代次數成正比。
對於每秒 200 個用戶端憑證授權，請為叢集分配 1 個 vCPU（測試結果高達每秒 2000 個）。

大部分 CPU 時間都花在建立新的 TLS 連線上，因為每個用戶端僅執行單個請求。
對於每秒 120 個刷新令牌請求，請為叢集分配 1 個 vCPU（測試結果高達每秒 435 個刷新令牌請求）。
為 CPU 使用量預留 150% 的額外空間以處理負載高峰。這可確保節點快速啟動，並有足夠的容量來處理容錯移轉任務。在我們的測試中，當 Keycloak 的 Pod 受到節流限制時，效能會顯著下降。

Keycloak 預設將使用者工作階段儲存在資料庫中，若要在 Aurora PostgreSQL 多可用區域資料庫上獲得最佳效能，需要以下資源

對於每秒 100 個登入/登出/刷新請求

vCPU 需求以範圍形式給出，因為隨著資料庫主機上的 CPU 飽和度增加，每個請求的 CPU 使用量減少，而回應時間增加。資料庫上的較低 CPU 配額可能會導致在峰值負載期間的回應時間變慢。如果峰值負載期間的快速回應時間至關重要，請選擇較大的 CPU 配額。有關範例，請參閱下文。

目標大小

計算出的限制

每個 Pod 請求的 CPU：3 個 vCPU

（每秒 45 個登入 = 3 個 vCPU，每秒 600 個用戶端憑證授權 = 3 個 vCPU，345 個刷新令牌 = 3 個 vCPU。總計為 9 個 vCPU。由於叢集中運行 3 個 Pod，因此每個 Pod 請求 3 個 vCPU）
每個 Pod 的 CPU 限制：7.5 個 vCPU

（允許額外 150% 的請求 CPU 來處理峰值、啟動和容錯移轉任務）
每個 Pod 請求的記憶體：1250 MB

（1250 MB 基本記憶體）
每個 Pod 的記憶體限制：1360 MB

（預期的 1250 MB 記憶體使用量減去 300 個非堆使用量，再除以 0.7）
Aurora 資料庫執行個體：根據峰值負載期間所需的回應時間，選擇 db.t4g.large 或 db.t4g.xlarge。

（每秒 45 個登入，每秒 5 個登出，每秒 360 個刷新令牌。總計為每秒 410 個請求。此預期的資料庫使用量為 1.4 到 2.8 個 vCPU，而資料庫的閒置負載為 0.3 個 vCPU。這表示 2 個 vCPU 的 db.t4g.large 執行個體或 4 個 vCPU 的 db.t4g.xlarge 執行個體。如果在峰值使用期間允許較高的回應時間，則 2 個 vCPU 的 db.t4g.large 會更具成本效益。在我們的測試中，一旦 2 個 vCPU db.t4g.large 執行個體的 CPU 飽和度達到 90%，在此情況下，登入和令牌刷新的中位回應時間會增加高達 120 毫秒。為了在峰值使用期間獲得更快的回應時間，請針對此情況考慮使用 4 個 vCPU 的 db.t4g.xlarge 執行個體。）

若要使用一個 AWS 區域中的兩個可用區域建立主動-主動 Keycloak 設定的大小，請按照下列步驟操作

關於 CPU 請求和限制的大小調整，根據預期的容錯移轉行為，有不同的方法

快速容錯移轉且成本更高: 將第二個站點的 CPU 請求和限制保持與上述相同。這樣一來，任何剩餘的站點都可以立即接管主要站點的流量，而無需擴展。
較慢的容錯移轉且更具成本效益: 將第二個站點的 CPU 請求和限制減少 50%。當其中一個站點發生故障時，手動、自動或使用水平 Pod 自動調整器將剩餘的站點從 3 個 Pod 擴展到 6 個 Pod。這需要在叢集或叢集自動擴展功能上有足夠的備用容量。
適用於某些環境的替代設定: 將第二個站點的 CPU 請求減少 50%，但將 CPU 限制保持與上述相同。這樣一來，剩餘的站點可以接管流量，但缺點是在峰值流量期間，節點會承受 CPU 壓力，因此回應時間會變慢。此設定的好處是不需要在容錯移轉期間擴展 Pod 的數量，因此設定更簡單。

參考架構

以下設定用於檢索上述設定，以針對不同情況執行約 10 分鐘的測試

透過 ROSA 在 AWS 上部署的 OpenShift 4.16.x。
具有 m5.4xlarge 執行個體的機器池。
使用運算子部署的 Keycloak，以及在主動/主動模式下具有兩個站點的高可用性設定中的 3 個 Pod。
以直通模式運行的 OpenShift 反向 Proxy，其中用戶端的 TLS 連接在 Pod 終止。
在多可用區域設定中的資料庫 Amazon Aurora PostgreSQL。
預設使用者密碼雜湊使用 Argon2 和 5 個雜湊迭代次數，以及最小記憶體大小 7 MiB ，如 OWASP 建議（這是預設值）。
用戶端憑證授權不使用刷新令牌（這是預設值）。
使用 20,000 個使用者和 20,000 個用戶端植入資料庫。
Infinispan 本機快取預設為 10,000 個項目，因此並非所有用戶端和使用者都適合快取，某些請求將需要從資料庫擷取資料。
所有驗證工作階段都按預設值儲存在分散式快取中，每個項目有兩個擁有者，允許一個 Pod 發生故障而不會遺失資料。
所有使用者和用戶端工作階段都儲存在資料庫中，並且不會快取在記憶體中，因為這是經過測試的多站點設定。對於單站點設定，預期效能會稍微高一些，因為會快取固定數量的使用者和用戶端工作階段。
OpenJDK 21