하야시 쇼고 님의 "실전 레디스" 책을 정리한 포스팅 입니다.
1. 레디스 아키텍처
읽기 관점 아키텍처
지연 로딩 패턴
- 데이터를 읽어오는 관점에서 접근한 아키텍처
- 원본 데이터는 RDBMS에 저장하고, 레디스는 그 앞단에 배치하는 형태로 사용
- 애플리케이션은 레디스에 데이터를 요청함
- 요청된 데이터가 레디스 서버에 존재하는지, 유효 기간 내인지에 따라 처리 내용을 분기함
Read-Through 패턴
- 지연 읽기 패턴의 변형과 같은 패턴
- 데이터베이스에서 데이터를 읽어오는 작업을 애플리케이션에서 직접 처리할 필요 없음 (라이브러리 사용)
쓰기 관점 아키텍처
Write-Through 패턴
- 데이터 쓰기 작업을 할 때의 관점에서 접근한 아키텍처
- 애플리케이션은 데이터베이스에 데이터를 저장함
- 애플리케이션은 1번과 같은 데이터를 레디스 서버에도 저장함
Write-Back 패턴
- 데이터를 캐시에 먼저 저장한 후, 일정 시간이 지나면 데이터베이스에 비동기적으로 반영하는 방식
- 장점
- 쓰기 성능을 높임
- 데이터베이스 부하를 줄일 수 있음
- 일시적으로 데이터 변경이 많을 때 유리
- 단점
- 데이터 손실 위험
- 데이터 일관성 문제
- 적절한 동기화 전략 필요
- 예
- 대량의 트랜잭션이 발생하는 이벤트 기간
- 쓰기 연산이 많고, 일부 데이터 손실이 허용되는 경우 (로그 데이터, 추천 시스템 등)
Write-Around 패턴
- 데이터를 직접 데이터베이스에 저장하는 방식
- 데이터베이스에서 레디스로 변경 내용을 레플리케이션하고, 레디스에서 직접 데이터를 읽어옴
아키텍처 안티 패턴
- 레디스 서버의 다운으로 애플리케이션이 동작하지 않는 경우
데이터 저장소로서의 레디스 아키텍처
- 관계계형 데이터베이스에서 구현하기 어려운 경우
- 작은 데이터의 빈번한 쓰기 작업이 필요한 경우
주의 사항
- 레디스의 기능이 데이터 저장소로서 요구사항을 충족하는 경우
- 복구 방법 확인 필요
- 관계형 데이터베이스와 함께 사용할 경우, 롤백 발생 시 데이터 일관성 측면에서 애플리케이션 구현에 문제가 없는지
- 레디스의 레플리케이션 기능이나 스냅숏 생성을 사전에 준비하기
2. 모범 사례
TTL 설정
- Redis는 기본적으로 데이터 소실이 허용되는 데이터를 저장하므로 장기 저장이 불필요함
- 최소 보관 시간을 TTL로 설정하여 불필요한 메모리 낭비를 방지할 수 있음
제거 정책 설정
- 메모리 사용량이 maxmemory에 도달하면 maxmemory-policy에 따라 키 제거함
# 모든 키 대상
maxmemory-policy allkeys-lru # 오래된 데이터 자동 정리
maxmemory-policy allkeys-lfu # 가장 적게 사용된 데이터 자동 정리
maxmemory-policy allkeys-random # 아무 데이터나 자동 정리 (공간이 부족할 때, 무작위로 삭제해도 상관없는 경우)
# TTL이 설정된 키 대상
maxmemory-policy volatile-ttl # 가장 만료 시간이 가까운 데이터 삭제
대상
- volatile-: TTL이 설정된 키 대상
- allkeys-: 모든 키 대상
전략
- LRU, LFU, 랜덤, TTL 기반 정책 선택 가능
백업
스냅숏 생성 시 고려사항
- COW 로 인해 두 배의 메모리 필요
- 서비스 영향이 적은 시간대에 실행하여 서비스를 원활히 운영하기
- 마스터가 아닌 레플리카에서 수행 (단, 비동기 동기화로 인해 일관성이 깨질 가능성 있음)
- 지연 발생 시 완전 동기화가 필요할 수 있으며, 이때 마스터 노드에도 메모리 용량이 필요하므로 여유가 있는지 필수로 확인하기
커넥션 풀링
- 새로운 연결 생성 시, 비용과 오버헤드가 증가하므로 커넥션 풀링으로 해결함
- maxclients 지시자로 셋팅 가능 (최대 개수는 커널 소프트 제한 영향을 받음)
재시도 처리
- 통신 장애 시, 클라이언트에서 재시도 수행
- 재시도 고려 요소, 횟수, 타임아웃, 간격, 상한선
- 지수 백오프 알고리즘: 실패 시 대기시간을 두배로 증가시키고 재시도하기
- 지터 적용: 클라이언트의 동시 재시도를 방지함. (과부하를 예방함)