들어가며

앞선 Phase 3 테스트를 통해 현재 사용중인 서버 인스턴스의 물리적 한계를 확인하고, 스레드와 커넥션의 1:1 매핑이라는 타협점을 찾아냈다. 하지만 이 테스트에서 고민이 들었던 지점은, 이 모든 수치는 시스템이 Warm-up 상태를 가정한 결과라는 점이었다.

Phase 3 테스트 결과에서 보았듯이, 동일한 코드임에도 불구하고 Cold 상태(TPS 146)와 Warm-up 상태(TPS 4666)의 처리량 차이는 약 4배에 달한다. 이 결과는 JIT 컴파일 최적화와 Redis Cache 100% hit 에 따른 것으로 분석했다.

여기서 자연스럽게 고민이 되는 지점이 있다. 바로, 실제 운영 환경에서도 위와 같은 Warm-Up 과정을 동일하게 거칠 수 있는가? 라는 부분이다.

모든 예열에는 비용이 따르기 마련인데, 만약 수천만 명의 유저 데이터를 다루는 서비스라면, 테스트에서 진행했던 캐시 Warm-Up을 할 수 있을지에 대해서는 고민이 필요할 것으로 보인다.

1. 1000만 명의 데이터에 대한 Cache Warming 가능?

지금까지 테스트했던 메서드에서 Redis Global Cache 를 사용해서 캐싱하고 있던 데이터는, 유저의 배송지 주소 정보였다.

이론적으로 모든 유저 배송지 정보를 Redis에 올려두면 DB 조회가 사라져 최상의 성능을 낼 수 있다. 하지만 이를 실현하기 위해 고려해야 할 현실적인 제약은 다음과 같다.

• 메모리 비용
  • 유저 한 명의 캐시 데이터가 1KB라고 가정해도, 1,000만 명이면 10GB의 메모리가 필요하다.
  • Redis는 인메모리 저장소이므로 이는 Redis 인스턴스 비용으로 직결된다.
• 데이터 정합성 유지
  • 선착순 주문 이벤트에 참여하는 유저가 배송지 주소를 변경할 일은 없겠지만, 모든 서비스 사용자들의 정보를 캐싱한다면 이야기는 달라진다.
  • 예열 시점과 실제 이벤트 시점 사이의 유저 정보 변경을 실시간으로 동기화해야 하는 복잡성이 발생한다.
• 비효율적인 자원 점유
  • 1,000만 명 중 실제 선착순 이벤트에 참여하는 인원이 10%뿐이라면, 나머지 900만 명을 위해 할당된 메모리는 명백한 자원 낭비가 된다.

2. 파레토 법칙에 따른 캐시 전략?

파레토의 법칙 또는 80 대 20 법칙은 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리킨다. 예를 들어, 20%의 고객이 백화점 전체 매출의 80%에 해당하는 만큼 쇼핑하는 현상을 설명할 때 이 용어를 사용한다. 2 대 8 법칙라고도 한다.