DevOps 지식 허브
DevOps 지식 허브

데이터 손실 방지 모범 사례: RDB와 AOF 설정

RDB 스냅샷과 AOF 영구성을 숙달하여 Redis 데이터 손실을 방지하세요. 이 종합 가이드는 두 가지 방법을 비교하고, `redis.conf` 파일에서의 설정 방법을 상세히 설명하며, 모범 사례를 제시합니다. RDB와 AOF를 결합하는 방법, 최적의 `appendfsync` 정책을 선택하는 방법, AOF 재작성을 관리하는 방법, 그리고 모니터링을 구현하여 데이터 내구성과 장애 발생 후 빠른 복구를 보장하는 방법을 배우세요.

42 조회수

Redis 데이터 손실 방지를 위한 모범 사례: RDB vs. AOF 설정

인기 있는 인메모리 데이터 구조 저장소인 Redis는 장애로부터 데이터를 보호하기 위한 강력한 영속성 메커니즘을 제공합니다. 이러한 메커니즘, 즉 Redis 데이터베이스(RDB) 스냅샷 및 추가 전용 파일(AOF) 로깅을 이해하고 올바르게 구성하는 것은 데이터 손실을 최소화하고 신속한 복구를 보장하는 데 중요합니다. 이 글에서는 RDB와 AOF의 미묘한 차이를 자세히 살펴보고 복원력 있는 Redis 배포를 구축하기 위한 모범 사례를 안내합니다.

적절한 영속성 전략 또는 그 조합을 선택하는 것은 데이터 내구성, 복구 시간 및 시스템 성능에 직접적인 영향을 미칩니다. RDB는 시점 스냅샷을 제공하는 반면, AOF는 모든 쓰기 작업을 기록합니다. 각기 장단점이 있으며, 최적의 구성은 종종 애플리케이션의 데이터 손실 허용 범위 및 성능 요구 사항에 따라 달라집니다.

Redis 영속성 메커니즘 이해

Redis는 데이터를 디스크에 영속시키는 두 가지 주요 방법을 제공하여 서버를 다시 시작하거나 충돌한 후 데이터 세트를 복구할 수 있도록 합니다.

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

RDB는 Redis 데이터 세트의 시점 스냅샷입니다. 메인 Redis 프로세스를 포크(fork)한 다음 자식 프로세스가 전체 데이터 세트를 dump.rdb 파일에 쓰도록 하여 작동합니다. 이 프로세스는 백업 및 재해 복구에 효율적입니다.

RDB 작동 방식:

  • 포크(Forking): Redis는 fork() 시스템 호출을 사용하여 자식 프로세스를 생성합니다. 부모 프로세스는 클라이언트 요청 처리를 계속하는 동안 자식 프로세스는 포크 시점의 메모리 상태에 액세스합니다.
  • 직렬화(Serialization): 자식 프로세스는 전체 데이터 세트를 압축된 이진 형식으로 직렬화합니다.
  • 디스크 저장: 직렬화된 데이터는 지정된 파일(기본값은 dump.rdb)에 기록됩니다.

**RDB 구성 (redis.conf):

# 초 수와 변경된 키 수가 지정된 값 이상인 경우 DB를 저장합니다.
# 형식: save <seconds> <changes>
save 900 1       # 키가 1개 이상 변경되면 15분 후에 저장
save 300 10      # 키가 10개 이상 변경되면 5분 후에 저장
save 60 10000    # 키가 10000개 이상 변경되면 1분 후에 저장

# 덤프 파일의 이름입니다.
dbfilename dump.rdb

# RDB 파일을 저장할 디렉토리입니다.
dir /var/lib/redis

RDB 장점:

  • 작은 파일 크기: RDB 파일은 일반적으로 AOF 파일보다 작으므로 전송 및 로드가 더 빠릅니다.
  • 빠른 재시작: 대규모 데이터 세트의 경우 AOF 로그를 다시 재생하는 것보다 단일 RDB 파일을 로드하는 것이 더 빠릅니다.
  • 간단한 백업 전략: RDB 스냅샷은 시점 백업 생성에 이상적입니다.

RDB 단점:

  • 데이터 손실 가능성: Redis가 저장 작업 사이에 충돌하는 경우 마지막 스냅샷 이후에 기록된 데이터는 손실될 수 있습니다. 저장 빈도가 데이터 손실 가능 창을 결정합니다.

2. 추가 전용 파일(AOF)

AOF는 Redis 서버가 수신하는 모든 쓰기 작업을 기록합니다. Redis가 다시 시작될 때 AOF 파일의 명령을 다시 실행하여 데이터 세트를 재구성합니다. 이는 RDB보다 훨씬 높은 내구성을 제공합니다.

AOF 작동 방식:

  • 명령 로깅: 모든 쓰기 명령은 AOF 파일에 추가됩니다.
  • 추가 모드: 파일은 추가 전용 방식으로 기록됩니다.
  • fsync 정책: Redis가 AOF 버퍼를 디스크로 플러시하는 빈도(fsync)를 구성할 수 있습니다. 이는 내구성에 중요합니다.

**AOF 구성 (redis.conf):

# Append Only 모드를 활성화합니다.
aof yes

# AOF 파일의 이름입니다.
aof-rewrite-incremental-fsync yes

# AOF를 활성화하면 다음 다시 쓰기 모드는 지원되지 않습니다.
# AOF 영속성은 appendfsync(). 옵션은 다음과 같습니다:
# no: 절대 fsync하지 않고 OS가 데이터 버퍼를 플러시하도록 합니다. 빠르지만 데이터는
#     충돌 시 손실됩니다.
# everysec: 1초마다 fsync()합니다. 평균 지연 시간은 약 30ms이지만 일부 데이터는
#           충돌 시 손실될 수 있습니다.
# always: 쓰기 작업이 수행될 때마다 fsync()합니다. 더 안전하지만 속도가 빠르지는 않습니다.
appendfsync everysec

# AOF 파일이 너무 커지면 자동으로 다시 씁니다.
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

AOF 장점:

  • 높은 내구성: appendfsync always 또는 appendfsync everysec을 사용하면 AOF는 데이터 손실 위험을 크게 줄입니다.
  • 재구성: Redis는 명령을 다시 재생하여 데이터 세트를 재구성할 수 있습니다.

AOF 단점:

  • 더 큰 파일 크기: AOF 파일은 모든 작업을 기록하므로 시간이 지남에 따라 매우 커질 수 있습니다.
  • 느린 재시작: 큰 AOF 파일을 다시 재생하는 데는 RDB 스냅샷을 로드하는 것보다 더 오래 걸릴 수 있습니다.
  • AOF 다시 쓰기: Redis는 크기를 관리하기 위해 AOF 파일을 주기적으로 더 압축된 형태로 다시 씁니다. 이 프로세스는 리소스를 소비할 수 있습니다.

데이터 손실 방지를 위한 모범 사례

데이터 손실을 효과적으로 방지하려면 다음 모범 사례를 고려하십시오.

1. RDB 및 AOF 모두 사용 (권장)

가장 강력한 접근 방식은 RDB와 AOF 영속성을 모두 활성화하는 것입니다. 이는 두 가지 방법의 이점을 결합합니다.

  • 백업용 RDB: 재해 복구 및 빠른 재시작을 위한 편리한 시점 백업을 제공합니다.
  • 내구성을 위한 AOF: Redis가 RDB 스냅샷 사이에 충돌하더라도 데이터 손실이 최소화됩니다( appendfsync 설정에 따라 다름).

**구성 예시 (redis.conf):

# RDB 영속성 활성화
save 900 1
save 300 10
save 60 10000

# AOF 영속성 활성화
aof yes
appendfsync everysec

이것이 좋은 이유: 서버가 충돌하는 경우 Redis는 먼저 RDB 파일을 로드하려고 시도합니다. RDB 파일이 손상되었거나 누락된 경우 AOF 파일로 대체됩니다. appendfsync everysec 설정은 성능과 내구성 간에 좋은 균형을 이루어 최악의 시나리오에서 최대 1초의 데이터만 손실되도록 보장합니다.

2. 올바른 appendfsync 정책 선택

이것은 AOF 내구성에 가장 중요한 설정입니다. 선택은 애플리케이션의 데이터 손실 허용 범위에 따라 달라집니다.

  • appendfsync no: 최고의 성능이지만 데이터 손실 위험이 가장 높습니다(마지막 OS 플러시 이후 모든 쓰기).

  • appendfsync everysec: 대부분의 사용 사례에 권장됩니다. 최소한의 데이터 손실(최대 1초)로 좋은 성능을 제공합니다.

  • appendfsync always: 최고의 내구성, 그러나 빈번한 디스크 동기화로 인해 쓰기 성능에 상당한 영향을 미칠 수 있습니다.

권장 사항: appendfsync everysec으로 시작하십시오. 쓰기 성능과 데이터 손실 허용 범위를 모니터링하여 appendfsync always가 필요한지 또는 덜 중요한 데이터에 대해 no가 허용되는지 결정하십시오.

3. RDB 저장 시점 현명하게 구성

RDB의 경우 허용 가능한 데이터 손실 기간과 일치하는 저장 시점을 선택하십시오. 빈번한 저장은 데이터 손실을 줄이지만 CPU 부하를 증가시킵니다.

  • 예시: 5분간의 데이터 손실이 허용되지 않는 경우 해당 기간 내에 트리거되는 저장 시점(save 300 10 등)이 있는지 확인하십시오.
  • 균형: CPU 부하를 줄이기 위해 save 10 100과 같이 지나치게 공격적인 저장 시점은(반드시 필요한 경우가 아니면) 피하십시오.

4. AOF 다시 쓰기 효과적으로 관리

AOF 다시 쓰기는 AOF 파일 크기를 관리 가능하게 유지하는 데 필수적입니다. 파일이 상당히 커지면 다시 쓰기를 트리거하도록 auto-rewrite-percentage 및 auto-rewrite-min-size를 구성하십시오.

  • 기본값: aof-auto-rewrite-percentage 100은 AOF 파일이 마지막 다시 쓰기 크기의 두 배가 될 때 다시 씁니다. aof-auto-rewrite-min-size 64mb는 작은 파일에서 다시 쓰기가 너무 자주 발생하지 않도록 합니다.
  • 모니터링: AOF 파일 크기를 주시하십시오. 과도하게 커지면 이러한 매개변수를 조정하거나 BGREWRITEAOF를 사용하여 수동 다시 쓰기를 트리거하는 것을 고려하십시오.

5. 영속성 파일의 정기 백업 구현

영속성이 활성화된 경우에도 dump.rdb 및 AOF 파일을 별도의 위치에 백업하는 것이 좋습니다. 이렇게 하면 하드웨어 장애, 실수로 인한 삭제 또는 Redis 인스턴스 전체 저장소의 손상으로부터 보호할 수 있습니다.

  • 전략: 외부 도구나 스크립트를 사용하여 이러한 파일을 주기적으로 네트워크 저장소 또는 클라우드 버킷으로 복사하십시오.

6. Redis 상태 및 디스크 I/O 모니터링

사전 예방적 모니터링은 데이터 손실을 방지하는 데 중요합니다. 다음 사항에 주의하십시오.

  • Redis 로그: 영속성, 디스크 전체 오류 또는 느린 쓰기와 관련된 경고를 찾으십시오.
  • 시스템 지표: 디스크 I/O(특히 쓰기 지연 시간 및 처리량), CPU 사용량 및 메모리 소비를 모니터링하십시오.
  • Redis INFO persistence: 이 명령은 마지막 저장 시간 및 AOF 다시 쓰기 상태를 포함하여 RDB 및 AOF 상태에 대한 귀중한 통찰력을 제공합니다.

7. 고가용성을 위한 Redis Sentinel 또는 Cluster 고려

엄격하게 영속성 구성은 아니지만, Redis Sentinel 및 Redis Cluster는 마스터 노드를 사용할 수 없게 되면 복제본으로 자동 페일오버하여 고가용성을 제공합니다. 이는 다운타임을 크게 줄이고, 따라서 영속성 메커니즘이 함께 적용되는 경우 잠재적 데이터 손실 가능성을 줄입니다.

결론

Redis에서 데이터 손실을 방지하는 것은 안정적인 애플리케이션을 유지하는 데 중요한 측면입니다. RDB 및 AOF 영속성의 장단점을 이해하고, 두 메커니즘을 모두 사용하고, appendfsync 정책을 신중하게 선택하고, AOF 다시 쓰기를 관리하는 것과 같은 모범 사례를 구현함으로써 Redis 배포의 내구성을 크게 향상시킬 수 있습니다. 이러한 설정을 정기적인 백업 및 사전 예방적 모니터링으로 보완하면 데이터 손실에 대한 강력한 방어 기능을 제공하고 비즈니스 연속성을 보장할 것입니다.