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

AOF와 RDB 영속성 성능 트레이드오프 비교

Redis AOF와 RDB 영속성의 지연 시간, 내구성, 복구 시간, 파일 크기 및 프로덕션 구성 측면에서의 트레이드오프를 비교합니다.

AOF와 RDB 영속성 성능 트레이드오프 비교

Redis 영속성은 손실을 감수할 수 있는 데이터의 양과 서버가 처리할 수 있는 디스크 작업 간의 트레이드오프입니다. 그러나 영속성이 활성화되어 데이터를 디스크에 저장하여 재시작 후 복구할 수 있게 되면, 개발자는 메커니즘을 선택해야 합니다. Redis의 두 가지 주요 영속성 방법은 스냅샷(RDB) 과 추가 전용 파일(AOF) 입니다. 각각의 성능 영향, 내구성 특성 및 구성 트레이드오프를 이해하는 것은 속도와 데이터 안전성에 대한 특정 애플리케이션 요구 사항을 충족하도록 Redis를 튜닝하는 데 중요합니다.

RDB 스냅샷은 컴팩트하고 로드 속도가 빠릅니다. AOF는 쓰기를 더 자주 기록하고 일반적으로 더 나은 복구 지점을 제공하지만, 더 많은 디스크 I/O 비용이 발생합니다.

Redis 영속성 이해하기

Redis는 전체 데이터 세트를 휘발성 메모리에 저장합니다. 영속성 메커니즘은 이 데이터를 디스크로 이동하여 Redis가 재시작 시 데이터 세트를 다시 로드할 수 있도록 하여 서비스 중단이나 재부팅 시 데이터 가용성을 보장하는 데 필요합니다. RDB와 AOF는 모두 근본적으로 다른 접근 방식을 통해 이 목표를 달성하며, 이는 뚜렷한 성능 프로필로 이어집니다.

1. Redis 데이터베이스(RDB) 스냅샷

RDB는 지정된 간격으로 전체 데이터 세트의 컴팩트한 특정 시점 스냅샷을 생성합니다. 이 데이터를 바이너리 파일(dump.rdb)에 저장합니다.

RDB 작동 방식 및 성능 영향

RDB 영속성은 BGSAVE 명령(백그라운드 저장)에 크게 의존합니다. 저장이 트리거되면:

  1. 포크: Redis는 메인 프로세스를 자식 프로세스로 포크합니다.
  2. 스냅샷: 자식 프로세스는 전체 데이터 세트를 디스크의 RDB 파일에 씁니다.
  3. 메인 스레드 영향 없음(대부분): 메인 Redis 스레드는 자식이 디스크 I/O를 처리하는 동안 쓰기 작업 중에 차단되지 않고 클라이언트 요청을 계속 처리합니다.

성능 고려 사항:

  • 쓰기 지연 시간: 일반적으로 RDB는 작업이 오프로드되므로 저장 작업 중 쓰기 지연 시간에 미치는 영향이 최소화됩니다. 주요 성능 비용은 포크가 발생하고 대용량 파일 쓰기 중에 필요한 CPU 스파이크와 초기 I/O 버스트입니다.
  • 복구 시간: RDB는 단일 최적화 파일이므로 재시작 시 매우 빠르게 로드되어 복구 지연 시간을 최소화합니다.
  • 내구성 트레이드오프: 예약된 저장 사이(예: 5분마다)에 Redis가 충돌하면 마지막 저장 이후의 모든 쓰기가 손실됩니다. 이로 인해 RDB는 AOF보다 내구성이 떨어집니다.

RDB 저장 구성

RDB 저장은 redis.conf 파일의 save 지시문을 사용하여 시간 간격과 변경 횟수를 지정하여 구성합니다:

save 900 1     # 900초(15분) 동안 1개의 키가 변경되면 저장
save 300 10    # 300초(5분) 동안 10개의 키가 변경되면 저장
save 60 10000  # 60초(1분) 동안 10000개의 키가 변경되면 저장

2. 추가 전용 파일(AOF) 영속성

AOF는 Redis 서버가 수신한 모든 쓰기 작업을 추가 전용 로그 파일에 기록합니다. Redis가 재시작되면 이러한 명령을 순차적으로 재생하여 데이터 세트를 재구성합니다.

AOF 작동 방식 및 성능 영향

RDB와 달리 AOF는 트랜잭션 로깅에 중점을 둡니다. 성능 프로필은 Redis가 운영 체제가 버퍼링된 데이터를 물리적 디스크에 쓰도록 강제하는 빈도를 결정하는 fsync 정책에 크게 의존합니다.

AOF Fsync 정책:

정책 appendfsync 설정 내구성 성능 영향
매초 everysec 정상 작동 시 양호; 충돌 시 약 1초 분량의 승인된 쓰기 손실 가능 좋은 균형; 일반적인 프로덕션 선택.
동기화 안 함 no 낮음(OS 버퍼에 의존) 가장 빠름; OS 충돌 시 데이터 손실 위험 최대.
항상 always 가장 강력한 AOF 내구성 정책 가장 느림; 모든 쓰기 시 디스크 동기화로 인한 상당한 지연 시간 증가.

성능 고려 사항:

  • 쓰기 지연 시간: appendfsync always를 사용하면 모든 쓰기 명령이 디스크 동기화의 지연 시간을 발생시켜 RDB 또는 인메모리 작업에 비해 작업 속도가 크게 느려집니다. everysec을 사용하면 fsync를 배치 처리하여 이를 크게 완화합니다.
  • 복구 시간: AOF 파일은 커질 수 있으며 수백만 개의 명령을 재생하는 것은 컴팩트한 RDB 파일을 로드하는 것보다 오래 걸려 복구 지연 시간이 높아집니다.
  • 파일 크기: AOF 파일은 데이터 구조의 최종 상태가 아닌 명령(예: SET key value)을 저장하기 때문에 일반적으로 RDB 파일보다 훨씬 큽니다.

AOF 활성화 및 구성

AOF는 기본적으로 비활성화되어 있으며 redis.conf에서 appendonly yes를 설정하여 활성화합니다. 중요한 설정은 appendfsync입니다:

appendonly yes
appendfilename "appendonly.aof"
# 내구성과 속도 트레이드오프에 권장되는 설정
appendfsync everysec

성능 트레이드오프 분석: AOF vs. RDB

RDB와 AOF 중에서 선택하려면 원시 운영 속도(지연 시간) 또는 보장된 데이터 복구 중에서 우선순위를 정해야 합니다.

지연 시간 및 처리량

  • RDB(원시 속도에 최적): 쓰기가 백그라운드 프로세스에 의해 처리되므로 메인 Redis 스레드는 저장 중에 직접적인 I/O 영향을 거의 받지 않습니다. 이는 일반적으로 BGSAVE 포크가 발생할 때 시스템에 부하가 심하지 않는 한 전체 쓰기 지연 시간을 낮춥니다.
  • AOF(always 모드): 이 구성은 디스크 지연 시간이 모든 클라이언트 쓰기 명령에 직접 도입되어 p99 지연 시간이 높아지므로 가장 느립니다.
  • AOF(everysec 모드): fsync 작업이 버퍼링되고 덜 빈번하므로 대부분의 작업에서 RDB와 거의 유사한 성능을 제공합니다.

내구성 및 데이터 손실 위험

  • AOF(내구성에 최적): 특히 appendfsync always를 사용할 때 가장 높은 내구성을 제공합니다. everysec을 사용하더라도 데이터 손실은 1초로 제한됩니다.
  • RDB(내구성에 최악): 저장 일정에 따라 데이터 손실이 몇 분 또는 몇 시간까지 발생할 수 있습니다.

복구 시간

  • RDB(빠른 복구): 최적화된 컴팩트 바이너리 형식으로 인해 재시작 시간이 더 빠릅니다.
  • AOF(느린 복구): 대용량 명령 로그를 재생하는 것은 스냅샷을 로드하는 것보다 오래 걸려 재시작 중 가동 중지 시간이 증가합니다.

모범 사례: 두 영속성 방법 모두 사용

높은 성능과 강력한 내구성 보장을 모두 요구하는 환경에서는 RDB와 AOF 영속성을 동시에 활성화하는 것이 권장되는 접근 방식입니다.

둘 다 활성화되면 Redis는 최대 데이터 일관성을 달성하기 위해 시작 시 재생을 위해 AOF 파일을 사용합니다. 주기적으로 RDB 스냅샷을 계속 생성합니다.

왜 둘 다 사용하나요?

  1. 더 나은 복구 선택: Redis는 일반적으로 둘 다 활성화된 경우 AOF가 더 완전하기 때문에 먼저 로드합니다. RDB를 유지하면 백업 및 재해 복구를 위한 추가 폴백 아티팩트가 제공됩니다.
  2. 운영 유연성: RDB는 컴팩트하여 보관하기 쉬운 반면, AOF는 데이터 손실 기간을 좁힙니다. 함께 사용하면 다양한 장애 모드를 처리할 수 있습니다.

둘 다 사용하기 위한 구성 스니펫:

# 1. RDB 활성화
save 900 1

# 2. 'everysec' 동기화로 AOF 활성화
appendonly yes
appendfsync everysec

AOF 파일 크기 관리(다시 쓰기)

AOF의 중요한 운영상의 문제는 파일 크기 증가입니다. 시간이 지남에 따라 AOF 파일은 이전 값을 덮어쓰는 경우에도 모든 수정 사항을 기록하므로 방대해질 수 있습니다. 이를 해결하기 위해 Redis는 AOF 다시 쓰기를 제공합니다.

AOF 다시 쓰기는 데이터 세트의 현재 상태를 재구성하는 데 필요한 최소 명령 집합만 포함하는 새롭고 최적화된 AOF 파일을 생성합니다. 이 프로세스는 현재 AOF 파일의 크기가 기본 크기의 특정 배수 이상으로 커지면 자동으로 트리거됩니다.

auto-aof-rewrite-percentage 100  # AOF 파일이 기본 크기보다 100% 커지면 다시 쓰기
auto-aof-rewrite-min-size 64mb    # 파일이 최소 64MB가 아니면 다시 쓰지 않음

다시 쓰기에 대한 경고: RDB 저장과 마찬가지로 AOF 다시 쓰기에는 프로세스 포크가 포함됩니다. 시스템의 메모리가 제한된 경우, 이 임시 메모리 사용량 두 배 증가(라이브 인스턴스와 다시 쓰여지는 복사본)는 불안정성이나 스와핑으로 이어질 수 있습니다.

결론

빠른 재시작, 컴팩트한 백업 및 낮은 쓰기 오버헤드가 최근 쓰기 손실보다 더 중요한 경우 RDB를 사용하세요. 모든 쓰기를 동기화하지 않고 더 좁은 복구 기간이 필요한 경우 appendfsync everysec과 함께 AOF를 사용하세요. 많은 프로덕션 시스템에서 둘 다 활성화하면 내구성, 백업 편의성 및 복구 옵션의 실용적인 조합을 얻을 수 있습니다.