Redis가 필요하지 않을 수도 있음

• Redis는 기술 업계에서 가장 긍정적인 평판을 얻고 있는 기술 중 하나임
  • 매우 잘 설계된 뛰어난 기술이고 자체에 결함이 있는 것은 아니지만, 항상 필요하진 않을 수 있음
• 10+년동안 3곳의 회사에서 같은 패턴을 봄:
  • 문제가 발생하고 Redis가 적합해 보였지만, 실제로는 상황을 개선하지 못했거나 근본적인 문제를 해결하지 못함
  • 그저 복잡성을 위해 복잡성을 더했을 뿐

첫 번째 사례: Tantan에서의 경험

• Tantan은 중국의 두 번째로 큰 데이팅 앱이며, PostgreSQL 기반의 50~100대의 고성능 데이터베이스 서버를 운영함
• 각 서버는 사용자 ID별로 샤딩되어 특정 사용자의 데이터는 하나의 서버에만 저장됨
• 문제 상황
  • '스와이프' 횟수를 저장하고 빠르게 업데이트해야 하는 요구사항 발생
  • 초기에는 Redis에 저장하는 것이 적합하다고 판단함
  • 고성능 Redis 서버 몇 대만 있으면 충분하다고 생각하고 설정 진행
• 재고 및 해결책
  • 팀 내에서 Redis 대신 PostgreSQL에 직접 저장하는 방안을 논의함
  • PostgreSQL 서버의 부하가 이미 높기 때문에 추가 부하는 미미할 것으로 예상
  • PostgreSQL에 저장한 후에도 성능 저하가 없었고, Redis 도입이 불필요했음

두 번째 사례: Bannerflow에서의 경험

• 배경
  • Bannerflow는 광고 제작 및 게시 플랫폼임
  • 새로운 마이크로서비스에서 Facebook 같은 소셜 네트워크에 광고 게시를 지원하기 위해 Redis 도입 결정
• 문제 상황
  • 로드가 Tantan에 비해 현저히 낮은 상황에서 Redis 도입이 필요했는지 불분명함
  • 초기 개발자가 떠난 후 Redis 도입 이유를 명확히 설명할 수 있는 사람이 없음
• 결과
  • Redis는 로드가 낮아 굳이 필요하지 않았음
  • 장기적으로 Redis를 제거하는 것이 최선이라는 결론에 도달

세 번째 사례: MAJORITY에서의 경험

• 배경
  • MAJORITY는 핀테크 회사로 외부 API 호출 결과를 캐싱하기 위해 Redis 도입
  • Redis는 위치 조회 데이터를 캐싱해 처리 속도를 높이고 비용을 절감하기 위해 도입됨
• 문제 상황
  • 동일한 데이터가 DB(Azure SQL)에도 저장됨
  • Redis 호출 대신 DB 호출로 교체해도 부하 증가가 거의 없을 것으로 예상됨
  • 잠금(lock) 처리가 필요해 Redis를 계속 사용하려 했으나, Azure SQL에서 충분히 처리 가능했음
• 결과
  • Redis 도입이 불필요하다는 결론에 도달
  • Redis 대신 Azure SQL 사용으로 전환 계획 수립

결론

• 세 가지 사례는 모두 서로 다른 도메인, 기술 스택, 로드 조건에서 발생했음
• 공통점은 불필요한 Redis 도입이었음
• Redis 도입 전에는 실제 필요성과 성능 이점을 충분히 고려해야 함
• Dan McKinley의 'Choose Boring Technology' 강연 추천