[실전 레디스] Chaprter 05_레디스 운용 관리

 

 

데이터 영속성

레디스는 인메모리 데이터베이스의 특성상 기본적으로 모든 데이터를 메모리에서 처리한다.

따라서 서버가 재시작되면 데이터가 유실될 수 있다.

 

레디스에는 영속성을 위한 설정이 있지만, 영속성 관련 기능을 모두 활성화하는 것은 권장하지 않는다. 트레이드오프를 고려하여 적절한 영속성 전략을 짜는 것이 중요하다.

 

레디스는 스냅숏과 AOF를 통해 데이터의 영속성을 보장한다.

위 두 가지 방법을 조합해서 아래 네 가지 방식으로 영속성 전략을 짤 수 있고, 이 방법으로 백업 생성도 가능하다.

1) 스냅숏

2) AOF

3) 스냅숏 + AOF

4) 영속성 사용하지 않음

 

AOF의 디폴트 값: 비활성화

 

스냅숏의 디폴트 값

• 1시간 내에 최소 하나 이상의 키가 변경되는 경우
• 5분 내에 최소 100개 이상의 키가 변경되는 경우
• 1분 내에 최소 10,000개 이상의 키가 변경되는 경우

 

스냅숏

스냅숏은 특정 시점의 데이터베이스 내에 있는 내용을 RDB라는 형식의 파일로 저장한다.

여기서 RDB Redis DataBase이다.

스냅숏은 자동 혹은 수동으로 생성할 수 있고, 수동 생성 시 SAVE(동기 방식), BGSAVE(비동기 방식) 명령어를 사용한다.

 

레디스는 기본적으로 싱글 스레드로 요청을 처리하고 있어서 SAVE 명령어를 사용하면, 동일한 스레드에 RDB 파일을 생성한다. 다만 이 동작은 덤프 중 다른 요청을 차단하기 때문에 운영환경에서는 권장되지 않는다.

 

AOF

스냅숏은 특정 시점의 상태를 저장하는데, 만약 레디스 서버에 문제가 생긴다면 마지막 스냅숏 이후 데이터는 손실될 것이다.

AOF의 경우 거의 실시간 백업처럼 작성 중인 파일 끝에 계속 추가하여 기록하기 때문에 내구성이 높다. 실행된 명령을 계속 추가하여 기록하기 때문에 RDB 파일보다 크기가 커지는 경향이 있다.

만약 재시작을 하게 된다면, AOF 파일의 명령어 내용을 다시 메모리에 적재하는 방식으로 처리되어 파일 크기가 클 수록 재시작 시간이 길어진다.

 

스냅숏은 자동, 수동 생성이 가능했으나 AOF는 수동 생성만 가능하다.

 

 

캐시 서버로서 레디스 아키텍처

레디스의 용도는 크게 두 가지로 나뉜다.

1) 캐시 서버

2) 데이터 저장소(영구 저장)

 

만약 1)번과 같이 캐시 서버로 사용한다면, 캐시 전략이 필요하다.

책에서는 이런 케이스에서 사용 가능한 몇 가지 패턴을 설명하며, 동시에 패턴에 맞는 아키텍처에 대한 설명도 하고 있다.

 

본격적인 설명에 앞서 지연 로딩 패턴과 Write-Through 패턴을 알고 있어야한다.

 

읽기 관점 아키텍처

읽기 관점 아키텍처에는 아래 두 가지 패턴이 있다.

• 지연 로딩 패턴
• Read-Through 패턴

 

지연 로딩 패턴

• 데이터를 읽어오는 관점에서 접근한 아키텍처
• 원본 데이터는 RDBMS에 저장, 레디스는 그 앞단에 배치하는 형태로 사용
• 장점
  • 레디스 캐시 노드 장애 시 다운타임 축소 가능
  • 백엔드로의 데이터 접근에 필ㅇ한 지연 시간의 영향 최소화
• 단점
  • 가져온 데이터가 오래되었을 수 있음
  • 캐시 미스 시 오버헤드 큼

 

Read-Through 패턴

• 지연 읽기 패턴의 변형과 같은 아키텍처
• 레디스에 데이터 요청 후 캐시 미스 발생 시 데이터베이스에서 캐시로 데이터를 읽어오는 방식 사용
• 지연 읽기 패턴과의 차이
  • 데이터를 읽어오는 작업을 애플리케이션에서 직접 처리할 필요 없음
  • 라이브러리 등 사용하여 데이터베이스에서 레디스로 데이터 읽어오는 과정 처리 필요

 

쓰기 관점 아키텍처

쓰기 관점 아키텍처에는 다음 세 가지 패턴이 있다.

• Write-Through 패턴
• Write-Back 패턴
• Write-Around 패턴

 

 

Write-Through 패턴

• 데이터 쓰기 작업을 할 때의 관점에서 접근한 아키텍처
• 처리 흐름
  • 애플리케이션은 데이터베이스에 데이터를 저장
  • 애플리케이션은 위와 같은 데이터를 레디스 서버에도 저장
• 장점
  • 레디스 서버 내부 캐시 데이터가 항상 최신 상태 유지
  • 읽기 작업 시 오버헤드가 적음
• 단점
  • 사용하지 않는 캐시 데이터 생성 가능성 존재
  • 쓰기 작업 시 데이터베이스와 캐시에 모두 쓰기를 해야 하기 때문에 오버헤드 큼

 

정리: Write-Through 패턴은 읽기 작업보다 쓰기 작업 중의 지연 시간이 증가해도 괜찮은 경우 효과적인 방법

 

 

Write-Back 패턴

• 캐시에 저장 후 일정 시간이 지연되면 데이터베이스를 비동기 방식으로 주기적 업데이트 진행
• RDBMS인 경우, 데이터를 영구적으로 저장하는 시점에 정규화하여 테이블에 저장
• 장점
  • 레디스 서버 내부 캐시 데이터가 항상 최신 상태 유지
  • 쓰기 작업을 빠르게 처리 가능
• 단점
  • 데이터 손실 위험 높음

 

Write-Around 패턴

• 데이터를 직접 데이터베이스에 저장하는 방식
• AWS DMS와 같은 CDC 기능 사용하여 데이터베이스에서 레디스로 레플리케이션 후 레디스에서 직접 데이터 읽을 수 있음
• 장점
  • 데이터 손실 위험 낮음
• 단점
  • 구현 방법과 읽기 관점의 아키텍처에 따라 달라질 수 있음

 

 

모범 사례

1. TTL 설정

2. 제거 정책 설정

3. 백업

4. 커넥션 풀링

5. 재시도 처리

 

캐시 노드 크기 조정

레디스 클러스터

레디스 클러스터를 구축하는 경우 최소 세 개의 캐시 노드를 마스터로 설정해야한다.

 

레디스 클러스터가 필요한 경우

• 부하가 높은 쓰기 작업을 처리하는 경우
• 높은 가용성이 요구되는 경우

위의 상황과 사용 중인 클라이언트가 레디스 클러스터를 지원하는지 확인하여 사용 여부를 결정하면 된다.

 

실제 용도에 맞는 요구사항 추정

만약 사용하기로 결정했다면, 아래와 같은 내용들을 고려한다.

1. 전체 데이터량
2. 최대치일 때 총 키의 개수
3. 하나의 키 당 평균 크기 및 최대 크기
4. 초당 키의 작업 수
5. 네트워크 트래픽
6. 실행되는 명령어 내역

 

이 경우 데이터의양에 따라 샤드, 메모리, 분산 처리 등에 영향이 있을 수 있으며, 대규모 데이터를 다루는 경우 앞에서 배운 자료형, 명령어 유형도 고려할 필요가 있다.

 

클라우드의 크기 조정

클라우드를 사용하는 경우 백업 기능 지원 여부, 노드 크기별 특성 및 레디스 버전 별 서비스 기능 등을 고려해야 한다.

 

 

보안

기본적으로 레디스는 신뢰할 수 있는 환경에서만 접근 가능하도록 설계되어 있다.

지난 4장 설명에도 언급했지만 레디스는 아래와 같이 권장하고 있다.

레디스 공식 문서에는 '레디스를 퍼블릭 인터넷에 직접 노출하지 말라'고 권장하고 있다. 따라서 레디스 포트를 외부에 공개하지 않는게 1차적 보안 수단이다.

 

따라서 접근 제어, 인증 보다 성능과 구현의 단순성에 초점이 맞춰져 있다.

만약 신뢰할 수 없는 환경이라면 ACL 기능을 사용하거나, 사용자 입력 검증을 추가하는 방식을 권장한다.

 

ACL

• 특정 리소스에 대해 접근 권한과 가능한 작업을 지정한 목록으로 제어
• 버전 6부터 ACL 기능 지원
• 독립적으로 사용 가능

사용자 입력 검증

• 웹 애플리케이션 등이 맡게 됨

 

벤치마크

레디스 처리 속도는 CPU, 네트워크 대역폭, 데이터 크기, 캐시 히트율, RTT 등 다양한 요인의 영향을 받는다.

레디스 사용 시 애플리케이션의 특성을 고려하여 처리 속도 확인하는 것이 중요하다.

 

redis-benchmark 명령어를 사용하면 앞서 언급된 요인들에 대한 벤치마크 수행이 가능하다.

 

redis-benchmark 명령어에는 다양한 옵션들이 존재하고, --help 옵션 사용 시 실행 방법과 예시를 포함한 옵션 상세 내용이 가능하다.

 

 

멀티 스레드 처리

레디스는 기본적으로 싱글 스레드로 요청을 처리한다.

하지만 부분적으로 멀티 스레드로 처리하는 경우도 있다.

 

레디스 6.0 이상에서는 옵션으로 I/O 부분의 멀티 스레드 처리를 활성화할 수 있다. 이를 알기 위해 레디스가 요청을 받을 때 어떻게 동작하는지 알아야한다.

 

1. 레디스는 메인 스레드로 연결 설정 요청을 받는다.
2. 소켓을 생성하고 읽기 작업에 대한 정보를 대기 큐에 넣는다.
3. 메인 스레드에서 읽기 이벤트를 처리하고, I/O 스레드에 순서대로 작업을 할당한다.
4. 메인 스레드에는 I/O 스레드가 소켓에서 읽기 작업이 완료되기를 기다린 후 분석 명령을 받아 실행한다.
5. 메인 스레드는 I/O 스레드가 결과를 소켓에 저장하기를 기다린다.
6. 저장한 이후 메인 스레드는 큐에서 요청을 삭제하고 다음 요청을 받는다.

 

분석된 명령 내용을 실행하는 데이터 접근 부분은 여전히 싱글 스레드로 처리된다. 이 부분에서 멀티 스레드를 사용하면, 락 경쟁 등을 고려하여 시스템 설계가 되어야한다.

때문에 성능 저하나 복잡한 구조가 되어 버리며, 간단하고 빠른 처리를 위해 레디스는 싱글 스레드 사용을 채택하고 있다.