본문 바로가기
카테고리 없음

KeyCloak 스펙 산정하기

뭉기 2024. 1. 31. 14:55

 

Concepts for sizing CPU and memory resources[1] 글에 대한 내용입니다.

 

 

성능 권장사항:

  • 더 많은 파드(Pod)로 확장할 때 성능이 저하될 수 있습니다. 이는 추가적인 오버헤드 때문이며, 교차 데이터센터 설정을 사용할 경우 추가 트래픽과 작업으로 인해 성능이 더 저하될 수 있습니다.
  • 캐시 크기를 늘리면 Keycloak 인스턴스가 오랜 시간 동안 운영될 때 성능이 향상됩니다. 이는 응답 시간을 줄이고 데이터베이스의 IOPS를 감소시킵니다. 그러나 인스턴스가 재시작될 때 이러한 캐시를 채워야 하므로, 캐시가 채워진 후 안정된 상태를 기준으로 자원을 너무 타이트하게 설정하지 않는 것이 좋습니다.
  • 이러한 값들을 시작점으로 사용하고, 생산 환경으로 가기 전에 자체 부하 테스트를 수행하세요.

요약:

  • CPU 사용량은 테스트된 최대 처리량 내에서 요청 수에 따라 선형적으로 비례하여 증가합니다.
  • Memory 사용량은 테스트된 최대 처리량 내에서 활성 세션 수에 따라 선형적으로 비례하여 증가합니다.

권장사항:

  • 비활성 파드의 기본 메모리 사용량은 1GB의 RAM입니다.
  • RAM의 급격한 증가를 위해 추가적으로 1GB의 여유 공간을 남겨두세요.
  • 100,000개의 활성 사용자 세션당 세 노드 클러스터에서 파드당 500MB를 추가하세요(200,000 세션까지 테스트됨).
  • 이는 각 사용자가 단 하나의 클라이언트에만 연결한다고 가정합니다. 사용자 세션당 클라이언트 세션 수가 늘어날수록 메모리 요구사항이 증가합니다(아직 테스트되지 않음).
  • 초당 40개의 사용자 로그인에 대해 세 노드 클러스터에서 파드당 1 vCPU(초당 최대 300까지 테스트됨).
  • Keycloak은 대부분의 CPU 시간을 사용자가 제공한 비밀번호를 해싱하는 데 사용합니다.
  • 초당 450개의 클라이언트 자격 증명 부여에 대해 세 노드 클러스터에서 파드당 1 vCPU(초당 최대 2000까지 테스트됨).
  • 대부분의 CPU 시간은 각 클라이언트가 단일 요청만 실행하기 때문에 새로운 TLS 연결을 생성하는 데 사용됩니다.
  • 초당 350개의 리프레시 토큰 요청에 대해 세 노드 클러스터에서 파드당 1 vCPU(초당 최대 435 리프레시 토큰 요청까지 테스트됨).
  • 부하 증가시 CPU 사용량을 처리하기 위해 CPU 사용량의 200%를 추가로 남겨두세요. 이는 노드의 빠른 시작과 장애 조치 작업 처리에 필요한 충분한 용량을 보장합니다. 우리의 테스트에서 Keycloak의 성능은 파드가 제한되었을 때 현저히 감소했습니다.

계산 예시:

목표 크기:

  • 50,000개의 활성 사용자 세션
  • 초당 40개의 로그인
  • 초당 450개의 클라이언트 자격 증명 부여
  • 초당 350개의 리프레시 토큰 요청

계산된 한계:

  • 요청된 CPU: 3 vCPU (초당 40개 로그인 = 1 vCPU, 초당 450개 클라이언트 자격 증명 부여 = 1 vCPU, 350개 리프레시 토큰 = 1 vCPU)
  • CPU 한계: 9 vCPU (피크, 시작 및 장애 조치 작업을 처리하기 위해 요청된 CPU의 세 배를 허용하며 아직 숫자가 없는 리프레시 토큰 처리도 포함)
  • 요청된 메모리: 1.25GB (기본 1GB 메모리와 50,000개의 활성 세션에 대한 250MB RAM)
  • 메모리 한계: 2.25GB (요청된 메모리에 1GB 추가)

참조 아키텍처: 다음 설정은 다양한 시나리오에 대해 약 10분 동안 테스트를 실행하기 위해 사용되었습니다.

  • OpenShift 4.13.x가 AWS에서 ROSA를 통해 배포됨.
  • m5.4xlarge 인스턴스가 있는 Machinepool.
  • Operator 및 3개의 파드로 배포된 Keycloak.
  • PBKDF2 27,500 해시 반복으로 기본 설정된 사용자 비밀번호 해싱.
  • 클라이언트 자격 증명 부여는 리프레시 토큰을 사용하지 않음(기본 설정).
  • 100,000명의 사용자와 100,000개의 클라이언트로 씨딩된 데이터베이스.
  • 캐시와 사용자가 모두 캐시에 맞지 않아 일부 요청이 데이터베이스에서 데이터를 가져와야 하므로 기본적으로 10,000개 항목의 Infinispan 캐시.
  • 기본적으로 두 개의 소유자가 있는 항목으로 분산된 캐시에 모든 세션, 하나의 파드가 실패해도 데이터 손실 없음.
  • OpenShift의 역방향 프록시가 passthrough 모드에서 실행되어 클라이언트의 TLS 연결이 파드에서 종료됨.
  • 같은 OpenShift 내에 에페메럴 스토리지를 가진 PostgreSQL 배포.
  • 영구 저장소를 가진 데이터베이스를 사용하면 데이터베이스 지연 시간이 더 길어질 수 있으며, 이로 인해 응답 시간이 길어질 수 있지만 처리량은 비슷할 것으로 예상됩니다.

 

 

[1] https://www.keycloak.org/high-availability/concepts-memory-and-cpu-sizing

티스토리툴바