서버 증설 없이 처리하는 대규모 트래픽

라이브 쇼핑 서비스가 피크 시간대에 큰 트래픽을 받으면서 Redis와 데이터베이스, 게이트웨이에 부하가 쌓였고, 단순한 서버 증설만으로는 비용과 병목 문제를 해결하기 어려웠습니다. 공통 데이터는 Local Cache와 Redis Pub/Sub으로 처리하고, 사용자별 데이터는 압축해 Redis 메모리를 아꼈으며, 포인트 지급은 RedLock으로 중복을 막고 Kafka 비동기 적재와 Consumer Throttling으로 DB 부하를 조절했습니다. 중복 API 요청을 클라이언트와 함께 제거하고 여러 API를 하나로 묶어 피크 트래픽 규모를 50% 줄였으며, 선착순 집계에는 Redis Increment와 Local Cache 방식을 상황에 맞게 적용했습니다. 서버·컴포넌트·서비스 지표를 모니터링하고 문제 파악부터 카나리 배포까지 반복하는 것이 증설 전에 성능을 개선하고 장애를 예방하는 핵심이라는 교훈을 얻었습니다.

• 모든 사용자에게 같은 데이터는 웹 서버의 Local Cache에 두고, Redis Pub/Sub으로 캐시 무효화를 전파할 수 있습니다.
• 사용자별 Redis 데이터는 저장 크기를 줄이되, 작은 데이터에 압축을 적용하면 오히려 용량이 늘 수 있습니다.
• 포인트 지급의 중복 방지에는 분산 락을 적용하고, DB 기록은 Kafka Consumer의 Throttling으로 처리량을 조절할 수 있습니다.
• Local Cache에서 선착순 인원을 집계하면 Redis 부하를 줄일 수 있지만, 엄격한 선착순 보장이 필요한지 먼저 확인해야 합니다.
• 성능 변경은 카나리 배포로 검증하고, 서버와 Redis·DB·Kafka 및 서비스 지표를 함께 모니터링해야 합니다.