데이터베이스 크기 선정

데이터베이스 크기 선정 (Database Sizing)

이 페이지는 LiteLLM 프록시 뒤의 Postgres 인스턴스를 크기 선정해요. 가상 키나 사용량 추적을 쓰는 순간부터 필요해요. 아래 숫자는 게이트웨이 벤치마크(4 vCPU / 8GB 게이트웨이 인스턴스로 실행)에서 시작해 AWS, Azure, GCP의 관리형 상품으로 확장한 것이에요. Redis는 Redis Sizing에서 별도로 크기 선정해요. 이 크기 선정과 함께 가는 구성 손잡이는 Production Best Practices를, 데이터베이스에 실제로 무엇이 저장되는지는 What is stored in the DB를 보세요.

출처: 문서

본문

프록시가 데이터베이스에 요청하는 것 (What the proxy asks of the database)

Postgres는 인증 경로와 회계 경로에 있어요. 이 두 형태는 매우 달라요. 인증은 요청당 LiteLLM_VerificationToken, LiteLLM_UserTable, LiteLLM_TeamTable에 대한 소수의 인덱스된 포인트 읽기이며, 캐시되므로 정상 상태에서 데이터베이스에 거의 비용이 들지 않아요. 회계는 비싼 절반이에요. 지출은 키, 사용자, 팀, 조직 행에 다시 기록되어야 하고, 요청당 로그 행은 LiteLLM_SpendLogs에 들어가요. 필요한 인스턴스를 결정하는 것은 읽기 경로가 아니라 이 쓰기 경로예요. 그래서 지출 쓰기 일괄 처리와 (대략 1000 RPS 이상) Redis 트랜잭션 버퍼가 원시 요청 볼륨보다 데이터베이스 크기 선정에 더 중요해요.

요청률별 크기 (Sizing by request rate)

위 쓰기 경로에 맞춰 크기가 정해져요. 저장소는 LiteLLM_SpendLogs가 지배하므로 처리량보다 보존 기간을 추적해요. 프롬프트 없이 로그된 요청당 대략 1~2 KB, store_prompts_in_spend_logs가 활성화되면 10배를 예산하세요.

연결이 CPU보다 먼저 깨진다 (Connections break before CPU does)

가장 걸릴 가능성이 높은 실패는 포화된 데이터베이스 CPU가 아니라 FATAL: sorry, too many clients already예요. LiteLLM의 풀 한도는 워커 프로세스별이므로, 총 수요는 database_connection_pool_limit × workers_per_instance × instances이고, 중요한 인스턴스 수는 오늘의 복제본 수가 아니라 오토스케일러의 maxReplicas예요. 기본 풀 한도 10에서 maxReplicas: 100 배포는 1000 연결을 요구하는데, 이는 대부분의 관리형 Postgres 인스턴스가 기본 설정에서 받아들이는 것보다 많아요. 콘피그 참조의 나눗셈으로 풀을 크기 선정하고 maxReplicas를 데이터베이스가 실제로 서빙할 수 있는 수로 제한하세요.

각 클라우드는 인스턴스 메모리에서 기본 max_connections를 파생하므로, 크기를 조정하면 천장이 움직여요:

인스턴스가 서빙할 수 있는 것보다 더 많은 애플리케이션 연결이 필요하다면, 그 앞에 풀러(RDS Proxy, Azure flexible server에 내장된 PgBouncer, 또는 자체)를 두고 database_disable_prepared_statements: true를 설정해 Prisma가 풀링된 세션 간에 서버 측 prepared statement를 재사용하지 않게 하세요.

클라우드 권장사항 (Cloud recommendations)

AWS

Graviton general purpose 클래스의 RDS for PostgreSQL 사용. 최대 1K RPS에 db.m7g.large, 1K~5K에 db.m7g.xlarge, 그 너머는 db.m7g.2xlarge 이상. 전체 목록은 DB instance classes 참고. gp3 스토리지를 사용하세요. 어떤 크기에서든 기본 3000 IOPS와 125 MiB/s를 주고, Postgres 볼륨이 400 GiB를 넘으면 12,000 IOPS와 500 MiB/s까지 올라가므로, 위 표의 500GB 행이 용량뿐 아니라 처리량도 사줘요. 프로덕션은 Multi-AZ를 실행하고, 지출 쓰기 핫스팟이 설명할 수 없는 지연이 아니라 대기 이벤트로 보이도록 Performance Insights를 활성화하세요.

리더 엔드포인트를 원할 때는 대신 Aurora PostgreSQL을 고르세요. 이는 LiteLLM의 읽기 복제본 라우팅과 직접 짝을 이루며, 5K RPS 행을 넘기는 가장 깨끗한 방법이에요. Aurora의 max_connections 기본값은 RDS와 같은 메모리 공식을 사용해요.

Azure

General Purpose 티어의 Azure Database for PostgreSQL flexible server 사용. 최대 1K RPS에 D4ds_v5(4 vCore, 16GB), 1K~5K에 D8ds_v5(8 vCore, 32GB). 작업 세트가 캐시에 안 들어가면 Memory Optimized E8ds_v5 이상으로. compute options 목록이 모든 제품 이름을 담아요. Burstable 티어는 프로덕션에서 피하세요. 크레딧이 소진된 인스턴스는 지출 쓰기 경로를 멈추게 해요. IOPS가 디스크 크기와 독립적으로 프로비저닝되도록 Premium SSD v2 스토리지를 사용하고, zone-redundant 고가용성을 켜세요. 내장 PgBouncer가 위 연결 천장에 대한 가장 쉬운 답이에요. 활성화하고 DATABASE_URL을 포트 6432로 지정하고 database_disable_prepared_statements: true를 설정하세요.

GCP

Enterprise Plus 에디션의 Cloud SQL for PostgreSQL을 N2 머신 유형과 사용. 4 vCPU / 16GB로 최대 1K RPS, 8 vCPU / 32GB로 1K~5K. instance settings reference가 머신 시리즈를, editions comparison이 Enterprise Plus가 추가하는 것(데이터 캐시, 서브초 계획된 장애 조치 포함)을 다뤄요. Cloud SQL의 SSD IOPS는 vCPU 수와 디스크 크기 모두로 확장되므로(GB당 읽기 30·쓰기 30 IOPS, vCPU당 한도로 캡), 큰 머신의 작은 디스크는 플래그로 올릴 수 없는 처리량 천장이에요. 리전 고가용성과 자동 스토리지 증가를 활성화하세요.

데이터베이스를 작게 유지하세요 (Keep the database small)

쓰기 경로가 덜 할 때 크기 선정이 더 저렴해요. proxy_batch_write_at: 60으로 지출 쓰기를 일괄 처리하고, 오류 로그를 데이터베이스 밖으로 유지하며, 지출 로그 보존 기간을 설정해 LiteLLM_SpendLogs가 무한정 자라지 않게 하세요. 그 테이블이 보통 CPU보다 스토리지를 먼저 리사이즈하는 이유예요. UI에 요청별 행이 전혀 필요 없다면 disable_spend_logs: True가 가장 높은 볼륨의 삽입을 제거하면서 로깅 통합은 비용 데이터를 유지해요. store_prompts_in_spend_logs는 행 크기와 게이트웨이 pod의 메모리 바닥을 모두 배가시키므로 의도적으로만 활성화하세요.

모니터링할 것 (What to monitor)

활용도뿐 아니라 max_connections에 대한 연결 수를 지켜보세요. 하드 실패를 만드는 한도가 그것이기 때문이에요. LiteLLM 쪽에서 유용한 Prometheus 신호는 쓰기가 아니라 대기 중인 지출 업데이트용 litellm_in_memory_spend_update_queue_size와 litellm_redis_spend_update_queue_size, 그리고 현재 트랜잭션 버퍼 플러시 잠금을 보유한 pod용 litellm_pod_lock_manager_size예요. 단조 증가하는 큐 깊이는 데이터베이스가 쓰기 경로를 따라가지 못한다는 뜻이며, 이는 리사이즈하거나 버퍼를 켜야 할 신호예요.