본문은 대규모 고객(whale customers)을 위한 대시보드 성능 문제에서 시작하여, 일반적인 캐싱 솔루션의 함정을 지적합니다.
대시보드 문제와 ‘실시간’ 데이터의 재정의
-
문제점: 2,000명의 고객 중 소수의 대규모 고객(Fortune 500) 대시보드가 수많은 API 호출과 데이터 처리로 인해 극도로 느려지는 현상 발생.
-
초기 최적화: 데이터베이스 인덱스, N+1 쿼리 해결, 비용이 많이 드는 호출 메모이제이션 등 시도.
-
기대치 재조정: 고객과의 대화를 통해 ‘실시간’의 의미를 재정의.
- 일별 요약(Daily rollups): 전날 마감 기준 데이터로 충분한 경우, 밤에 한 번 처리.
- 오늘의 활동(Today’s activity): 빠르게 계산 가능한 몇 가지 실시간 지표만 제공.
‘새벽 1시 작업’의 숨겨진 비용: 캐시 오염
-
일반적인 해결책: 매일 새벽 1시에 2,000명의 모든 고객 대시보드 보고서를 생성하고 캐시.
-
문제점: 대규모 고객만을 위한 최적화가 모든 고객에게 적용되어 불필요한 CPU, 메모리, DB 부하를 발생. 백그라운드 큐가 중요하지 않은 작업으로 넘쳐나 핵심 작업 지연.
-
캐시 오염(Cache Pollution): 불필요한 캐싱 작업이 시스템을 비대화하고, 큐를 지연시키며, 캐싱 전략의 탄소 발자국을 증가시키는 현상.
캐싱 빈도 및 범위의 중요성
-
빈도 조절: 보고서 실행 빈도를 실제 로그인 패턴(주중/주말, 공휴일)에 맞춰 조정. 예를 들어, 주말에는 캐싱을 중단하거나 범위를 축소.
-
선별적 작업: 모든 사용자나 조직을 대상으로 반복 작업하는 대신, 실제로 캐싱이 필요한 특정 조직이나 대규모 데이터셋을 가진 고객에게만 적용. (예: 오늘 로그인한 조직, 최적화가 필요한 대규모 데이터셋 고객).
효과적인 캐싱 전략
-
선택적 사전 캐싱: 대규모 고객(예: 2,000명 중 50명)에게만 야간 요약 캐시를 생성. 나머지는 요청 시 렌더링.
-
로그인 시 캐시: 대규모 고객이 로그인할 때 백그라운드 작업을 큐에 넣어 대시보드를 미리 준비. 로그인 페이지에서 쿠키 값으로 사용자 예측하여 선제적 캐싱 가능.
-
요청 시 캐시 + 폴백: 캐시 데이터가 없으면 즉시 새로 생성. 캐시가 항상 존재할 것이라는 가정은 위험.
이러한 전략들은 시스템의 유연성을 높이고, 자원 낭비를 줄이며, 캐시 오염을 방지하는 데 기여합니다.