Redis 사이징

Redis 사이징 (Redis Sizing)

이 페이지는 LiteLLM Proxy 뒤의 Redis 인스턴스를 사이징해요. 게이트웨이 인스턴스가 둘 이상이 되면 바로 실행해야 해요. Postgres는 Database Sizing에서 별도로 사이징해요. Redis를 프록시에 연결하는 방법은 Production Best Practices의 Redis 섹션과 캐싱 설정을 참고해요.

출처: 문서

본문

프록시가 Redis에 요구하는 것

Redis는 요율 제한 카운터, 라우터·쿨다운 상태, 응답 캐시, 그리고 use_redis_transaction_buffer가 켜져 있을 때는 지출 업데이트 큐를 담아요. 이들은 모두 수명이 짧은 실시간 상태이지 내구성 있는 히스토리가 아니므로, Redis는 크기보다 지연에 민감한 작은 인스턴스로 다뤄야 해요. 높은 트래픽에서도 수 GB의 작업 집합(working set)이 정상이에요. RAM은 요청 속도의 함수가 아니라 캐시하고 싶은 것의 여유분(headroom)으로 보고, vCPU 수는 처리량을 결정짓는 것으로 봐야 해요. Redis 프로세스는 단일 스레드이고 TLS 종료가 같은 코어에서 명령 실행과 경쟁하기 때문이에요.

Redis가 없으면 각 인스턴스가 요율 제한을 독립적으로 적용하고 캐시 히트도 요청을 처리한 인스턴스에 국한돼요. 그래서 10개 포드로 구성된 플릿은 설정한 한도의 약 10배를 적용하게 돼요.

요청 속도별 사이징 (Sizing by request rate)

지속 RPS (Sustained RPS)	vCPU	RAM
Up to 1K	2	8GB
1K to 5K	4	16GB
5K+	8+	32GB+

Redis 7.0 이상을 실행해요. 정상 운영 중에 축출(eviction)이 일어나지 않도록 사이징하고, 축출 정책에 의존하기보다 용량을 추가하는 쪽을 선호해요. 요율 제한 카운터와 대기 중인 지출 업데이트는 실시간 회계 상태이므로, 압력 아래에서 축출하는 인스턴스는 캐시 히트만 잃는 게 아니라 지출 업데이트를 버리고 제한 창을 리셋하게 돼요. 트랜잭션 버퍼를 사용한다면 영속성(persistence)도 활성화해서, 장애 조치 시 Postgres로 아직 플러시되지 않은 대기 중 지출 업데이트를 버리지 않도록 해요.

대략 RPS 1000 이상이나 인스턴스 10개 이상이면 버퍼가 Postgres를 병목으로 만들지 않게 하는 핵심이 되므로, Redis는 선택적 캐시가 아니라 회계 경로의 일부가 돼요. Redis 트랜잭션 버퍼를 참고해요. 부하 아래에서 Got exception from REDIS No connection available이 보이면 더 큰 인스턴스로 가기 전에 cache_params의 max_connections를 올려보세요. 그 오류는 서버 포화가 아니라 클라이언트 측 풀 고갈이기 때문이에요.

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

AWS: Valkey 또는 Redis OSS 엔진 7.x 이상을 Graviton 노드의 ElastiCache로 사용해요. 1K RPS까지는 cache.m7g.large(6.38 GiB), 그 이상에서는 cache.m7g.xlarge(12.93 GiB)예요. 지원 노드 타입은 노드당 사용 가능한 메모리를 나열하는데, 이는 명목 인스턴스 메모리보다 적으므로 인스턴스 이름이 아니라 그 컬럼에 맞춰 사이징해야 해요. 프로덕션에서는 Multi-AZ 자동 장애 조치를 실행해요. 단일 노드를 넘어서면 더 큰 노드보다 LiteLLM의 Redis Cluster 설정으로 클러스터 모드를 선호해요. 샤딩이 카운터 키스페이스를 한 프로세스에 쌓지 않고 여러 프로세스에 퍼뜨리기 때문이에요. ElastiCache Serverless는 일반 캐싱에는 동작하지만, valkey-search 기반 시맨틱 캐싱에는 맞지 않아요(노드 기반 클러스터가 필요).

Azure: Azure Managed Redis를 Balanced 티어로 사용해요. 메모리 대 vCPU 비율이 4:1이고, Azure Cache for Redis와 달리 인스턴스에 vCPU가 둘 이상이에요. B5(6GB, 2 vCPU)는 카운터와 라우터 상태만으로 충분하고, 응답을 캐시하기 시작하면 B10(12GB, 4 vCPU)이 더 안전한 기본값이며, B20(24GB, 8 vCPU)이 5K RPS 행을 커버해요. 전체 목록은 티어·SKU 표를 참고하고, 제약이 용량이 아니라 처리량일 때는 Compute Optimized를 고려해요. 옛 Azure Cache for Redis에서는 Standard 대신 Premium 티어(P1 이상)를 사용해요. Basic과 Standard는 단일 vCPU에서 돌기 때문이에요. 영역 중복(zone redundancy)을 활성화하고, 트랜잭션 버퍼를 사용하면 데이터 영속성도 활성화해요.

GCP: Memorystore for Redis Cluster를 사용해요. 용량은 단일 인스턴스 크기가 아니라 노드 타입 × 샤드 수예요. redis-standard-small(노드당 5.2GB 쓰기 가능) 3샤드가 합리적인 바닥이고, redis-highmem-medium(10.4GB 쓰기 가능) 3샤드가 1K~5K 행을 커버하며, 그 이후에는 노드 타입을 키우기보다 샤드를 추가해요. Redis 성능은 단일 노드에서 vCPU와 선형적으로 확장되지 않으므로 Google 자체가 권장하는 가격-성능 방식이에요. 성능이 변동하고 SLA가 없는 redis-shared-core-nano는 건너뛰어요. Redis Cluster 설정으로 LiteLLM이 클러스터를 가리키게 해요.

모니터링할 것 (What to monitor)

maxmemory 대비 사용 메모리와 축출 카운터를 관찰해요. 여기서 축출은 캐시 히트율 문제가 아니라 조용한 정확성 손실이기 때문이에요. LiteLLM 쪽에서 유용한 Prometheus 신호는, 쓰는 대신 큐에 있는 지출 업데이트용 litellm_redis_spend_update_queue_size와 litellm_in_memory_spend_update_queue_size, 그리고 현재 트랜잭션 버퍼 플러시 잠금을 가진 포드용 litellm_pod_lock_manager_size예요. 클라이언트 연결 수도 중요해요. 각 관리형 서비스는 인스턴스 크기당 연결 수 상한이 있고, 게이트웨이는 워커당 풀을 열기 때문이에요.