Redis

Redis 아키텍처 : 왜 빠른가?

단순히 "메모리에 저장해서" 라는 말로 설명하기엔 부족하다.

인메모리(In-Memory) 기반의 자료구조

Redis는 데이터를 단순히 String으로만 저장하지 않고, 자체적인 최적화 자료구조를 사용한다.

• Hash Table : 평균 "O(1)"의 접근 속도
• Skip List (Sorted Set) : O(logN)의 속도로 정렬된 데이터를 유지
• InSet/ZipList : 데이터 양이 적을 떄는 메모리 절약을 위해 선형적인 구조를 사용하다가, 커지면 동적으로 변경된다.

싱글 스래드 (Single-threaded) 이벤트 루프

Redis의 핵심 엔진은 싱글 스레드로 동작하며, 이는 다음의 이점을 가진다.

• Context Switching 비용 제로 : 멀티 스레드 환경에서 오버헤드가 없다.
• Lock-free : 자원 경합(Race condition)을 고려할 필요가 없어 코드가 단순하고 빠르다.
• I/O Multiplexing : epoll이나 kqueue 같은 비차단 I/O 메커니즘을 사용하여 수만 개의 클라이언트 연결을 효율적으로 처리한다.

자료구조의 효율적 구현

예를 들어, 리스트의 길이를 가져올 떄는 매번 세는 것이 아니라 별도의 변수에 저장해두는 등, 모든 연산이 최대한 O(1)에 가깝게 설계되어 있다.

사용사례

분산 락 (Distributed Lock)을 이용한 재고 및 선착순 관리

여행 상품(항공권, 숙소, 투어)은 재고가 한정적이며, 결제 직전 '가선점' 단계가 필수적이다.

• Redlock 알고리즘 :
  • 단일 인스턴스가 아닌 클러스터 환경에서 안정적인 락을 구현하기 위해 Redisson 라이브러리를 주로 활용한다.
  • RLock은 스핀 락 방식이 아닌 Pub/Sub을 이용해 락 해제 신호를 대기하므로 Redis 부하를 줄여준다.
• Atomic Counter :
  • DECR 명령어를 사용하여 원자적으로 재고를 차감한다.
  • DB를 조회하고 업데이트 하는 로직보다 훨씬 빠르며, Negative 체크를 통해 초과 예약을 방지한다.

위시리스트 및 최근 본 상품의 성능 최적화

위시리스트는 쓰기보다 읽기 빈도가 훨씬 높고, 사용자마다 데이터 셋이 작지만 개수가 많다.

• Sorted Set (ZSET) 활용 :
  • '위시리스트에 담은 시간'을 score로 설정하면 별도의 정렬 쿼리 없이 최신순 조회가 가능하다.
• Hash 구조의 필드 활용 :
  • 사용자 ID를 Key로 하고, 상품 ID를 Field, 상품의 간략한 메타정보(제목, 썸네일, URL)을 Value로 저장하면 DB Join 없이 리스트 페이지를 구성할 수 있다.
• Pipeline 활용 : 사용자가 여러 상품을 동시에 위시리스트에 담거나 조회할 때, 여러 명령을 한 번에 보내는 Pipelining을 통해 네트워크 RTT(Round Trip Time)를 줄일 수 있다.

CQRS 패턴의 Read Model (Materialized View)

주문 내역처럼 복잡한 Join이 필요한 읽기 작업의 성능을 높이기 위해 Redis를 사용한다

• Write-Behind 전략 : 주문이 발생하면 DB(Source of Truth)에 기록하고, 동시에 Redis에도 '사용자별 주문 요약' 형태의 JSON이나 Hash 데이터를 업데이트한다.
• 검색 성능 강화 : RediSearch 모듈을 사용하면 Redis 내에서 인덱싱과 전문 검색(Full-text search)이 가능하며, 파트너사가 자신의 상품 주문 현황을 필터링해서 볼 때 RDBMS보다 훨씬 빠른 응답을 줄 수 있다.

실시간 로그 및 이벤트 스트리밍 (Redis Streams)

주문 생성 후 실행되어야 하는 부수 작업들(알림톡 발송, 파트너 정산 데이터 생성, 데이터 분석 전송 등)을 처리할 때 사용한다.

• Redis Streams :
  • Kafka만큼 무겁지 않으면서도 **소비자 그룹(Consumer Group)**과 메시지 영속성을 지원한다.
  • 주문 서비스가 이벤트를 발행(XADD)하면, 여러 워커들이 각자의 속도에 맞춰 메시지를 소비(XREADGROUP)한다.
  • ACK 기반 처리 : 메시지 처리에 실패했을 떄 다시 처리할 수 있는 신뢰성을 제공하여, 여행 예약 확정 알림이 누락되는 일을 방지한다.