以此作为调整生产环境大小的起点。根据您的负载测试，根据需要调整您环境的值。
|
摘要
在低于测试限制的情况下，已使用的 CPU 随请求数量线性扩展。
建议
Pod 的基本内存使用量（包括 Realm 数据缓存和 10,000 个缓存会话）为 1250 MB RAM。
在容器中，Keycloak 为基于堆的内存分配 70% 的内存限制。它还将使用大约 300 MB 的非堆内存。要计算请求的内存，请使用上面的计算方法。作为内存限制，从上面的值中减去非堆内存，然后将结果除以 0.7。
对于每秒 15 个基于密码的用户登录，为集群分配 1 个 vCPU（测试最高可达每秒 300 个）。
Keycloak 将大部分 CPU 时间用于哈希用户提供的密码，这与哈希迭代次数成正比。
对于每秒 120 个客户端凭据授权，为集群分配 1 个 vCPU（测试最高可达每秒 2000 个）。*
大多数 CPU 时间用于创建新的 TLS 连接，因为每个客户端仅运行单个请求。
对于每秒 120 个刷新令牌请求，为集群分配 1 个 vCPU（测试最高可达每秒 435 个刷新令牌请求）。*
为 CPU 使用率预留 150% 的额外余量，以处理负载峰值。这确保了节点的快速启动，以及足够的容量来处理故障转移任务。在我们的测试中，当 Keycloak 的 Pod 受到限制时，性能显着下降。
当并发执行请求的客户端超过 2500 个时，并非所有客户端信息都能放入 Keycloak 的缓存中，因为这些缓存各自使用 10000 个条目的标准缓存大小。因此，数据库可能成为瓶颈，因为客户端数据会频繁地从数据库重新加载。为了减少数据库使用量，将 users 缓存大小增加到并发使用客户端数量的两倍，并将 realms 缓存大小增加到并发使用客户端数量的四倍。
Keycloak 默认将用户会话存储在数据库中，对于 Aurora PostgreSQL 多可用区数据库上的最佳性能，需要以下资源
对于每秒 100 个登录/注销/刷新请求
预算为 1400 次写入 IOPS。
分配 0.35 到 0.7 个 vCPU。
vCPU 需求以范围形式给出，因为随着数据库主机上 CPU 饱和度的增加，每个请求的 CPU 使用率会降低，而响应时间会增加。数据库上较低的 CPU 配额可能会导致峰值负载期间响应时间变慢。如果峰值负载期间的快速响应时间至关重要，请选择更大的 CPU 配额。请参阅下面的示例。
Keycloak 实例的大小调整取决于上一节中描述的基于密码的用户登录、刷新令牌请求和客户端凭据授权的实际和预测数量。
要检索正在运行的 Keycloak 实例的这三个关键输入的实际数量，请使用 Keycloak 提供的指标
用户事件指标 keycloak_user_events_total 中事件类型为 login 的指标包括基于密码的登录和基于 cookie 的登录，但它仍然可以作为本大小调整指南的第一个近似输入。
要找出 Keycloak 执行的密码验证次数，请使用指标 keycloak_credentials_password_hashing_validations_total。该指标还包含标签，提供有关所用哈希算法和验证结果的一些详细信息。以下是可用标签的列表：realm、algorithm、hashing_strength、outcome。
对于刷新令牌请求和客户端凭据授权，分别使用事件类型为 refresh_token 和 client_login 的用户事件指标 keycloak_user_events_total。
有关更多信息，请参阅使用事件指标监控用户活动和HTTP 指标指南。
这些指标对于跟踪用户活动负载的每日和每周波动、识别可能表明需要调整系统大小的新兴趋势以及验证大小调整计算至关重要。通过系统地测量和评估这些用户事件指标，您可以确保您的系统保持适当的规模，并对用户行为和需求的变化做出响应。
目标大小
每秒 45 次登录和注销
每秒 360 次客户端凭据授权*
每秒 360 次刷新令牌请求（登录的 1:8 比率）*
3 个 Pod
计算的限制
每个 Pod 请求的 CPU：3 个 vCPU
（每秒 45 次登录 = 3 个 vCPU，每秒 360 次客户端凭据授权 = 3 个 vCPU，360 个刷新令牌 = 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 设置的大小，请按照以下步骤操作
在第二个站点上创建与上述相同数量的 Pod，并具有相同的内存大小调整。
数据库大小调整保持不变。两个站点都将连接到同一个数据库写入器实例。
关于 CPU 请求和限制的大小调整，根据预期的故障转移行为，有不同的方法
对于第二个站点，保持 CPU 请求和限制与上述相同。这样，任何剩余的站点都可以立即接管来自主站点的流量，而无需扩展。
对于第二个站点，将 CPU 请求和限制减少 50%。当其中一个站点发生故障时，将剩余站点从 3 个 Pod 扩展到 6 个 Pod，可以手动、自动或使用 Horizontal Pod Autoscaler。这需要在集群或集群自动扩展功能上有足够的备用容量。
将第二个站点的 CPU 请求减少 50%，但保持 CPU 限制与上述相同。这样，剩余站点可以接管流量，但缺点是节点将在峰值流量期间承受 CPU 压力，从而导致响应时间变慢。这种设置的好处是，在故障转移期间无需扩展 Pod 的数量，这更容易设置。
以下设置用于检索上述设置，以针对不同场景运行约 10 分钟的测试
OpenShift 4.17.x 部署在 AWS 上，通过 ROSA。
具有 c7g.2xlarge 实例的机器池。*
Keycloak 使用 Operator 部署，并在具有两个站点的活动/主动模式的高可用性设置中部署 3 个 Pod。
OpenShift 的反向代理在直通模式下运行，客户端的 TLS 连接在 Pod 处终止。
数据库 Amazon Aurora PostgreSQL 采用多可用区设置。
默认用户密码哈希使用 Argon2 和 5 次哈希迭代，最小内存大小为 7 MiB 按照 OWASP 建议（这是默认值）。
客户端凭据授权不使用刷新令牌（这是默认值）。
数据库已使用 20,000 个用户和 20,000 个客户端进行种子填充。
Infinispan 本地缓存默认为 10,000 个条目，因此并非所有客户端和用户都适合缓存，并且某些请求将需要从数据库中获取数据。
所有身份验证会话都在分布式缓存中，按照默认设置，每个条目有两个所有者，允许一个 Pod 发生故障而不会丢失数据。
所有用户和客户端会话都存储在数据库中，并且未在内存中缓存，因为这是在多站点设置中测试的。对于单站点设置，预计性能会略高，因为固定数量的用户和客户端会话将被缓存。
OpenJDK 21
* 对于 AWS 上非 ARM CPU 架构 (c7i/c7a vs. c7g)，我们发现客户端凭据授权和刷新令牌工作负载能够提供高达每个 CPU 核心操作数量两倍的操作，而密码哈希处理每个 CPU 核心提供恒定数量的操作。根据您的工作负载和云定价，请运行您自己的测试并为您混合的工作负载进行自己的计算，以找出哪种架构为您提供更好的定价。