▲

GN⁺: 당신에겐 Redis가 필요하지 않을 수도 있습니다

 (viblo.se)
8P by neo 6일전 | ★ favorite | 댓글 4개
  • 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' 강연 추천
▲
iolothebard 6일전  [-]

레디스 사용여부를 떠나 도메인과 퍼시스턴스 사이에 캐싱 레이어를 끼워놓는(기본 구현은 바이패스) 건 전혀 오버엔지니어링이 아님. 로깅, 페이크데이터, 디버깅, 프로파일링, 어쩌면 진짜 캐싱…

답변달기
▲
nodelay 6일전  [-]

+1 저도 동의합니다. 레이어 하나 추가하는 것만으로도 여지 가 생기고, 수많은 일들을 해결할 수 있는 공간을 만들어주죠.

답변달기
▲
galadbran 6일전  [-]

레디스에 문제가 있다기 보다는 DB만으로 충분한데 왜 추가 구성 요소를 도입해서 관리 부담을 높여야 하느냐는 관점으로 보입니다.
좀 간략하게 설명하고 있는 편이라서, 이런 관점도 생각해봐야 한다는 정도로 받아들이면 좋을 것 같네요.
어플리케이션 로직을 단순하게 유지하면서 레디스 캐시를 도입하는 게 더 나은 선택일 수 있는 상황도 있으니
상황에 맞게 선택해야 하겠습니다.

답변달기
▲
neo 6일전  [-]
Hacker News 의견

  • 2015년 Uber에서 근무할 때, 우편번호 기반의 지리적 분할을 육각형 기반의 방식으로 전환하려고 했음

    • 도시를 수십 개의 우편번호로 나누는 대신, 수십만 개의 육각형으로 나누고 동적으로 영역을 생성하는 방식이었음
    • 피닉스에서 첫 출시가 있었고, 팀은 수요 가격 시스템을 확장하기 위해 밤을 새웠음
    • 글로벌 출시가 지연되었음
    • Redis를 좋아하는 엔지니어들이 많았음
    • 가격 서비스는 Redis를 기반으로 했고, 수백만 건의 요청을 처리했음
    • 비용이 많이 들었고, 확장성 문제도 있었음
    • 알고리즘을 개선하여 단일 기계에서 여러 도시의 동적 영역을 계산할 수 있었음
    • Isaac이라는 엔지니어가 주말 동안 구현하고 배포했음

  • Redis를 과도하게 사용하는 것에 대한 논쟁이 있었음

    • Redis는 멋지지만, 사용 시 네트워크 지연과 직렬화 오버헤드가 발생함
    • 데이터가 이미 분할되어 있다면, 일반적인 해시맵이 더 나을 수 있음
    • Java에서는 ConcurrentHashMap, Guava Caches, Caffeine Caches 등이 있음
    • 로컬 캐싱 구현이 네트워크를 사용하는 것보다 거의 항상 빠름
    • Redis는 과도하게 사용되는 경향이 있음

  • Redis 사용 문화가 그 인기에 비해 발전하지 않았음

    • Redis는 다양한 데이터 구조를 지원하며, 회사 문화가 발전할수록 더 많은 패턴을 배울 수 있음
    • Redis의 패턴 모음집이 없다는 것이 아쉬움

  • Redis와 비Redis의 문제가 아니라, 직렬화가 잘 되지 않는 데이터와의 작업 문제임

    • 카운터, 뉴스 피드, 채팅 메시지 등은 Redis가 더 효율적일 수 있음
    • 대부분의 경우 MySQL로도 충분히 처리 가능함

  • 소프트웨어 개발은 종종 다른 사람의 방식을 반복하는 경향이 있음

    • Memcached에서 시작하여 Redis로 발전했음
    • 데이터베이스의 복잡성을 피하기 위해 캐시를 사용하는 경향이 있음
    • 데이터베이스는 여전히 복잡하고 어려움

  • Redis는 유일한 프로덕션 준비된 "데이터 구조 서버"임

    • 여러 인스턴스에서 동일한 서비스를 접근할 때 유용함

  • 캐시가 필요하지 않을 수도 있음

    • 캐시를 도입하지 않고 아키텍처 개선에 집중한 경험이 있음

  • Redis의 API는 훌륭하지만, 운영상의 위험이 있음

    • 캐시로는 좋지만, 프로덕션 데이터 저장소로는 신뢰할 수 없음

  • Redis 사용을 추천하지 않는 경향이 놀라움

    • Redis는 여전히 훌륭한 데이터 구조와 성능을 제공함

  • Redis는 임시 캐시로는 괜찮지만, 트랜잭션이나 분산 저장소로는 부족함

    • 분산 잠금 문제에 대한 학습이 필요함
답변달기