DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

최고의 Redis 지속성 전략 선택: RDB vs AOF

Redis RDB와 AOF 지속성, 데이터 손실 트레이드오프, 복구 속도, 쓰기 오버헤드, 프로덕션 구성 선택을 비교합니다.

최고의 Redis 지속성 전략 선택: RDB vs AOF.

Redis는 메모리에 데이터를 저장하므로, 쉽게 재구축할 수 없는 데이터에 의존하기 전에 지속성 전략이 필요합니다. RDB와 AOF 중 선택은 얼마나 많은 데이터를 잃을 수 있는지, Redis가 얼마나 빨리 재시작되는지, 워크로드가 얼마나 많은 디스크 I/O를 생성하는지에 영향을 미칩니다.

주기적인 스냅샷으로 충분할 때 RDB를 사용하세요. 더 엄격한 내구성이 필요할 때 AOF를 사용하세요. 실용적인 내구성과 더 쉬운 백업이 모두 필요할 때 둘 다 사용하되, 실제 데이터셋으로 복구를 테스트하세요.

Redis 지속성 이해하기

Redis의 지속성은 인메모리 데이터셋을 디스크에 저장하여 서버 재시작이나 충돌 후 다시 로드할 수 있는 기능을 말합니다. 지속성이 없으면 서버가 중지되거나 충돌할 때 Redis에 저장된 모든 데이터가 손실됩니다. Redis는 이를 달성하기 위해 두 가지 뚜렷한 방법을 제공합니다:

  • RDB (Redis Database): 데이터셋의 특정 시점 스냅샷.
  • AOF (Append-Only File): 서버가 수행한 모든 쓰기 작업의 로그.

두 방법 모두 고유한 특성을 가지며 다양한 시나리오에 적합합니다.

Redis 데이터베이스 (RDB)

RDB 지속성은 지정된 간격으로 Redis 데이터셋의 특정 시점 스냅샷을 수행합니다. RDB 저장 작업이 트리거되면 Redis는 자식 프로세스를 포크합니다. 그런 다음 자식 프로세스는 전체 데이터셋을 임시 RDB 파일에 씁니다. 파일이 완료되면 이전 RDB 파일이 새 파일로 교체됩니다.

RDB 작동 방식

  1. 포킹: Redis 서버가 새 자식 프로세스를 포크합니다.
  2. 스냅샷 생성: 자식 프로세스가 전체 데이터셋을 임시 RDB 파일에 쓰기 시작합니다.
  3. 완료: 자식 프로세스가 쓰기를 마치면 이전 RDB 파일을 새 임시 파일로 교체합니다.
  4. 정리: 자식 프로세스가 종료됩니다.

이 프로세스는 부모 프로세스가 응답 상태를 유지하므로 스냅샷이 생성되는 동안 Redis가 클라이언트 요청을 계속 처리할 수 있도록 보장합니다.

RDB의 장점

  • 컴팩트한 백업: RDB 파일은 바이너리 압축되어 Redis 데이터셋을 매우 컴팩트하게 표현합니다. 따라서 백업 및 재해 복구에 이상적입니다.
  • 빠른 재시작: RDB 파일을 다시 로드하는 것은 특히 대규모 데이터셋의 경우 AOF 파일을 재생하는 것보다 훨씬 빠릅니다. 단일 사전 형식화된 바이너리 파일을 로드하기 때문입니다.
  • 최소 디스크 I/O: RDB 저장은 구성된 간격으로만 발생하므로 저장하지 않을 때 Redis는 최소한의 디스크 I/O를 수행합니다. 이는 정상 작동 중 더 높은 성능으로 이어질 수 있습니다.
  • 전송 용이성: 단일 컴팩트 파일이므로 RDB 백업은 재해 복구 또는 아카이브 목적으로 원격 데이터 센터로 쉽게 전송할 수 있습니다.

RDB의 단점

  • 잠재적 데이터 손실: 주요 단점은 데이터 손실 가능성입니다. 저장 지점 사이에 Redis가 충돌하면 마지막 성공적인 RDB 저장 이후에 기록된 모든 데이터가 손실됩니다.
  • 포크 중 성능 스파이크: 매우 큰 데이터셋의 경우 초기 fork() 작업이 느려져 특히 메모리 사용량이 높을 때 짧은 기간 동안 Redis 서버를 차단할 수 있습니다.
  • 실시간 지속성 아님: RDB는 실시간 데이터 지속성을 위해 설계되지 않았습니다. 몇 분의 데이터 손실이 허용되는 시나리오에 가장 적합합니다.

RDB 구성

RDB 지속성은 redis.conf에서 save 지시문을 사용하여 기본적으로 활성화됩니다. 여러 save 규칙을 지정할 수 있습니다:

# 900초(15분)마다 최소 1개 키가 변경되면 데이터베이스 저장
save 900 1

# 300초(5분)마다 최소 10개 키가 변경되면 데이터베이스 저장
save 300 10

# 60초마다 최소 10000개 키가 변경되면 데이터베이스 저장
save 60 10000

# RDB 지속성 비활성화 (모든 save 지시문을 주석 처리하거나 아래와 같이 명시적으로 설정)
# save ""

redis-cli에서 SAVE(차단) 또는 BGSAVE(비차단) 명령을 사용하여 수동으로 RDB 저장을 트리거할 수도 있습니다.

추가 전용 파일 (AOF)

AOF 지속성은 Redis 서버가 수신한 모든 쓰기 작업을 기록합니다. 전체 데이터셋을 주기적으로 저장하는 대신 AOF는 데이터셋을 수정하는 명령을 기록합니다. Redis가 재시작되면 AOF 파일의 이러한 명령을 다시 실행하여 원래 데이터셋을 재구성합니다.

AOF 작동 방식

  1. 명령 로깅: Redis가 실행하는 모든 쓰기 명령이 AOF 파일에 추가됩니다.
  2. fsync 정책: Redis는 AOF 버퍼가 디스크에 동기화되는 빈도를 제어하기 위해 다양한 fsync 정책을 제공합니다:
    • appendfsync always: 모든 명령 후에 동기화합니다. 최고의 내구성을 제공하지만 가장 느립니다.
    • appendfsync everysec: 초당 한 번 동기화합니다. 내구성과 성능 사이의 좋은 균형입니다(기본값 및 권장).
    • appendfsync no: 운영 체제가 AOF 버퍼를 디스크로 플러시하도록 합니다. 최고의 성능을 제공하지만 내구성이 가장 낮습니다.
  3. AOF 재작성: 시간이 지남에 따라 중복 명령(예: 동일한 키를 여러 번 업데이트)으로 인해 AOF 파일이 매우 커질 수 있습니다. AOF 재작성은 현재 데이터셋을 재구성하는 데 필요한 명령만 포함하는 새롭고 더 작은 AOF 파일을 생성하여 AOF 파일을 최적화합니다. 이 프로세스는 RDB의 포킹 메커니즘과 유사합니다.

AOF의 장점

  • 더 나은 내구성: appendfsync always 또는 everysec를 사용하면 AOF가 주기적인 RDB 스냅샷보다 더 강력한 내구성을 제공합니다. everysec를 사용하면 Redis는 일반적으로 승인된 쓰기의 약 1초 손실로 제한하지만 운영 체제 또는 디스크 오류가 여전히 내구성에 영향을 줄 수 있습니다.
  • 더 적은 데이터 손실: 충돌 시 fsync 정책에 따라 데이터 손실이 훨씬 적거나 전혀 없습니다.
  • 검사 가능한 형식: AOF는 Redis 프로토콜 명령을 저장하므로 RDB 파일보다 Redis 도구로 더 쉽게 검사하고 복구할 수 있습니다.

AOF의 단점

  • 더 큰 파일 크기: AOF 파일은 명령을 저장하므로 일반적으로 동일한 데이터셋에 대해 RDB 파일보다 훨씬 큽니다.
  • 느린 복구: 시작 시 큰 AOF 파일을 재생하는 것은 Redis가 각 명령을 실행해야 하므로 RDB 파일을 로드하는 것보다 느릴 수 있습니다.
  • 성능 영향: fsync 정책에 따라 AOF는 더 많은 디스크 I/O를 유발하여 쓰기 성능에 잠재적으로 영향을 줄 수 있습니다. appendfsync always는 특히 영향이 큽니다.
  • AOF 재작성 오버헤드: AOF 재작성은 파일 크기 관리를 돕지만 재작성 프로세스 자체가 CPU 및 I/O 리소스를 소비하고 데이터셋이 매우 큰 경우 RDB 포킹과 유사하게 Redis를 일시적으로 차단할 수 있습니다.

AOF 구성

AOF를 활성화하려면 redis.conf에서 appendonly yes를 설정해야 합니다:

# AOF 지속성 활성화
appendonly yes

# 추가 전용 파일의 이름 (기본값: "appendonly.aof")
appendfilename "appendonly.aof"

# appendfsync 옵션: always, everysec, no
appendfsync everysec

# 기본 크기의 두 배이고 최소 64MB일 때 AOF 파일 자동 재작성
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs. AOF: 비교 개요

기능 RDB (Redis 데이터베이스 백업) AOF (추가 전용 파일)
메커니즘 특정 시점 스냅샷 (바이너리 파일) Redis 프로토콜 형식의 쓰기 작업 로그
데이터 손실 저장 지점 사이의 잠재적 손실 everysec로 보통 약 1초; always로 가장 강력함
성능 정상 작동 중 더 높은 쓰기 성능, fork() 시 잠재적 차단 강력한 fsync로 쓰기 속도 저하, 더 일관된 I/O
파일 크기 매우 컴팩트한 바이너리 파일 일반적으로 더 크며, 작업에 따라 증가
복구 시간 대규모 데이터셋에 대해 더 빠름 대규모 데이터셋에 대해 더 느림 (명령 재생)
백업 용이성 단일 컴팩트 파일; 백업/재해 복구에 용이 더 큰 파일, 재작성 없이 관리가 어려울 수 있음
가독성 사람이 읽을 수 없음 RDB보다 검사 가능
Redis 기본값 예 (save 지시문 포함) 아니요 (기본적으로 appendonly no)

하이브리드 접근 방식: RDB와 AOF 함께 사용

Redis는 RDB 스냅샷과 AOF를 함께 사용할 수 있습니다. AOF가 활성화되면 Redis는 일반적으로 더 최신 상태이므로 시작 복구에 AOF를 사용합니다. 최신 Redis는 aof-use-rdb-preamble yes가 활성화된 경우 재작성된 AOF 파일 내에서 RDB 프리앰블을 사용할 수도 있어 재작성 및 재시작 속도를 높입니다.

  • 더 빠른 재작성: 하이브리드 AOF의 RDB 부분은 재작성 프로세스를 위한 훨씬 빠른 초기 스냅샷을 제공합니다.
  • 더 빠른 재시작 (잠재적으로): Redis가 재시작될 때 먼저 AOF 파일의 RDB 부분을 로드하고(더 빠름) 그런 다음 후속 AOF 명령을 재생합니다.
  • 더 나은 내구성: 여전히 AOF의 최소 데이터 손실 이점을 누릴 수 있습니다.

하이브리드 AOF가 활성화되어 있다고 가정하기 전에 Redis 버전과 구성을 확인하세요.

올바른 지속성 전략 선택

이상적인 지속성 전략은 데이터 내구성, 성능 및 복구 시간에 대한 애플리케이션의 특정 요구 사항에 따라 달라집니다.

1. RDB만 사용해야 하는 경우

  • 주요 사용 사례: 캐시 / 중요하지 않은 데이터: Redis가 주로 캐시로 사용되어 충돌 시 일부 데이터 손실이 허용되거나 데이터를 다른 소스에서 쉽게 재구성할 수 있는 경우.
  • 높은 성능 요구 사항: 쓰기 성능이 가장 중요하고 가끔 데이터 손실이 허용되는 경우.
  • 재해 복구 백업: RDB 파일은 장기 보관 또는 재해 복구를 위한 주기적인 스냅샷을 만드는 데 탁월합니다. BGSAVE를 cron으로 예약한 다음 .rdb 파일을 오프사이트로 이동할 수 있습니다.
  • 메모리 효율성: 디스크 공간이 매우 제한된 경우.

2. AOF만 사용해야 하는 경우

  • 주요 사용 사례: 절대적 내구성: 모든 단일 쓰기 작업이 중요하고 몇 초의 데이터 손실도 허용되지 않는 경우(예: 금융 거래, 중요 사용자 데이터). 이 경우 appendfsync always를 고려할 수 있지만 상당한 성능 비용이 따릅니다.
  • 디버깅/감사: AOF의 사람이 읽을 수 있는 특성은 데이터 변경 사항을 이해하는 데 유용할 수 있습니다.

3. RDB와 AOF를 모두 사용해야 하는 경우 (대부분의 중요 애플리케이션에 권장)

  • 균형 잡힌 내구성 및 복구: 이는 일반적으로 데이터 내구성이 중요하지만 효율적인 재시작 및 백업도 원하는 프로덕션 시스템에 권장되는 접근 방식입니다.
  • 견고성: 추가 보호 계층을 제공합니다. 하나의 지속성 방법이 손상되더라도 다른 방법으로 복구할 수 있습니다.
  • 하이브리드 AOF: 지원되고 활성화된 경우 RDB 프리앰블 AOF 형식을 활용하세요.

실용적인 팁과 모범 사례

  • 디스크 사용량 모니터링: RDB와 AOF 모두 상당한 디스크 공간을 소비할 수 있습니다. 특히 AOF 재작성 또는 RDB 저장 전에 디스크 공간이 부족하지 않도록 사용량을 모니터링하세요.
  • fsync 정책: AOF의 경우 appendfsync everysec이 가장 일반적이고 권장되는 선택으로, 내구성과 성능 사이의 좋은 균형을 제공합니다. 중요 데이터에는 appendfsync no를 피하세요.
  • AOF 재작성: 과도한 리소스 소비 없이 AOF 파일이 정기적으로 최적화되도록 auto-aof-rewrite-percentage 및 auto-aof-rewrite-min-size를 신중하게 구성하세요.
  • 별도 디스크/위치: 가능하면 지속성 파일(AOF 및 RDB)을 운영 체제 및 애플리케이션 로그와 다른 디스크나 파티션에 저장하여 I/O 경합을 방지하세요.
  • 외부 백업: 지속성 전략에 관계없이 강력한 재해 복구를 위해 RDB 및 AOF 파일을 정기적으로 오프사이트 위치(예: S3, Google Cloud Storage)에 백업하세요.
  • 복구 테스트: 선택한 지속성 전략으로 복구 프로세스를 정기적으로 테스트하여 데이터가 성공적으로 복원될 수 있는지 확인하세요.

핵심 요점

습관이 아니라 복구 요구 사항에 따라 지속성을 선택하세요. 캐시 전용 Redis는 종종 RDB를 사용하거나 지속성을 사용하지 않을 수 있습니다. 세션, 대기열 또는 애플리케이션 상태에 사용되는 Redis는 일반적으로 AOF, 테스트된 백업 및 데이터가 충분히 빠르게 돌아온다는 것을 증명하는 재시작 훈련이 필요합니다.