피드로 돌아가기
Ruby on Rails Performance: 7 Lessons from Scaling FirstPromoter
Dev.toDev.to
Backend

주당 35.5M 요청 처리, Rails 기반 대규모 트래픽 최적화 전략

Ruby on Rails Performance: 7 Lessons from Scaling FirstPromoter

Robert Kovacs2026년 4월 9일6intermediate

Context

사용자 급증으로 인한 PostgreSQL의 실시간 COUNT(*) 쿼리 부하 발생. 수백만 건의 레코드 스캔으로 인한 분석 쿼리 타임아웃 현상 지속. 대규모 웹훅 처리 시 발생하는 데이터베이스 경합 및 메모리 스파이크 문제 직면.

Technical Solution

  • counter_culture 도입 및 활성 데이터 대상의 선택적 캐시 갱신 전략으로 백그라운드 작업 부하 감소
  • 읽기 전용 복제본(Read Replica) 기반의 비동기 데이터 정산 구조 설계로 기본 DB 부하 분산
  • Redis를 활용한 웹훅 큐잉 및 원자적 카운터(Atomic Counter) 구현으로 DB 쓰기 경합 해소
  • Sidekiq 프로세스를 중요도 및 경로별로 분리하고 sidekiq-limit_fetch를 통한 큐별 동시성 제한 설정
  • 복잡한 시계열 집계 및 대량 데이터 스캔 쿼리를 PostgreSQL에서 Google BigQuery로 마이그레이션
  • 모델별 특성에 맞춘 가변적 배치 사이즈(Batch Size) 튜닝으로 메모리 사용량과 처리 속도 최적화

Impact

  • 대시보드 통계 엔드포인트 응답 속도: 10s+ $\rightarrow$ 2.5s
  • 프로모터 목록 로딩 시간: 500ms 미만으로 단축
  • 분석 쿼리 실행 시간: 30s 타임아웃 $\rightarrow$ 2s 미만
  • API 요청 P95 지연 시간: 3.4s 이내 달성
  • 주당 요청 처리량: 15.7M $\rightarrow$ 35.5M 증가

Key Takeaway

범용 DB의 한계를 인정하고 데이터의 성격(트랜잭션 vs 분석)에 따라 저장소를 분리하는 폴리글랏 저장소 전략의 중요성 확인.


수십만 건 이상의 행을 스캔하는 분석 쿼리 발생 시 RDBMS 대신 BigQuery와 같은 OLAP 저장소 전환을 검토할 것

원문 읽기