Redis 영속성 기구 심층 가이드

AOF 영속성

Redis는 메모리 기반이므로 Redis 서버가 충돌하면 데이터가 손실됩니다. 데이터 손실을 방지하기 위해 Redis는 RDB와 AOF라는 두 가지 영속성 메커니즘을 제공합니다. 먼저 AOF에 대해 소개하겠습니다.

AOF(Append Only File) 영속성은 모든 쓰기 작업을 AOF 파일의 끝에 추가 전용 방식으로 기록합니다. 기본적으로 AOF는 Redis에서 비활성화되어 있습니다. 다시 시작하면 Redis는 AOF 파일의 명령을 다시 실행하여 데이터를 복원합니다. 주로 실시간 데이터 영속성 문제를 해결합니다.

AOF 로그는 명령이 실행된 후에만 기록됩니다. 명령을 먼저 기록하고 실행하지 않는 이유는 무엇일까요? Redis는 AOF 로그에 쓸 때 구문 검사를 수행하지 않기 때문입니다. 명령을 먼저 기록하고 실행하면 잘못된 명령이 기록될 위험이 있으며, 이로 인해 Redis가 AOF 로그에서 데이터를 복원하려고 할 때 오류가 발생할 수 있습니다.

로깅은 명령 실행 후에 발생하므로 현재 쓰기 작업을 차단하지 않습니다. 그러나 두 가지 위험이 있습니다.

• 명령이 실행된 후 로그가 기록되기 전에 시스템이 충돌하면 데이터가 손실됩니다.
• AOF는 현재 명령을 차단하지 않지만 다음 작업을 차단할 수 있습니다.

이러한 위험을 완화하는 가장 좋은 방법은 appendfsync 설정에서 제공하는 세 가지 AOF 쓰기 전략을 활용하는 것입니다.

• always: 동기식 쓰기. 각 명령 실행 후 로그가 즉시 디스크에 기록됩니다.
• everysec: 각 명령 후 로그가 AOF 메모리 버퍼에 기록되고 매초 디스크에 동기화됩니다.
• no: 로그는 AOF 메모리 버퍼에만 기록되고 운영 체제가 디스크에 플러시할 시기를 결정합니다.

always 전략은 데이터 손실을 최소화하지만 성능이 낮습니다. no 전략은 성능이 더 좋지만 데이터 손실 위험이 더 큽니다. 일반적으로 everysec이 좋은 절충안입니다.

시간이 지남에 따라 더 많은 명령이 수신되면 AOF 파일이 계속 커져 성능 문제가 발생할 수 있습니다. 로그 파일이 너무 커지면 어떻게 될까요? AOF 재작성이 필요한 시점입니다! 시간이 지남에 따라 AOF 파일에는 잘못되거나 만료된 명령과 같은 중복 명령이 누적됩니다. AOF 재작성 메커니즘은 이러한 명령을 단일 명령(예: 일괄 처리 명령)으로 병합하여 파일 크기를 줄이고 압축합니다.

AOF 재작성으로 인해 차단이 발생합니까? AOF 로그는 주 스레드에서 쓰지만 재작성은 다릅니다. bgrewriteaof라는 백그라운드 하위 프로세스에서 수행됩니다.

• AOF의 장점: 더 높은 데이터 일관성 및 무결성, 데이터 손실이 초 단위로 제한됩니다.
• 단점: 동일한 데이터 세트에 대해 AOF 파일이 RDB 파일보다 큽니다. 복구도 더 느립니다.

RDB 영속성

많은 작업 로그가 있을 때 AOF 영속성으로 인해 복구가 매우 느릴 수 있으므로 충돌 후 더 빠르게 복구할 수 있는 방법이 있을까요? 네, RDB입니다!

RDB는 메모리 내 데이터를 스냅샷 형태로 디스크에 저장하여 작동합니다. 각 작업을 기록하는 AOF와 달리 RDB는 특정 시점의 데이터 상태를 기록합니다.

스냅샷이란 무엇입니까? 현재 데이터의 사진을 찍어 해당 이미지를 저장하는 것으로 생각할 수 있습니다.

RDB 영속성은 지정된 간격으로 지정된 횟수의 쓰기 작업 후에 Redis가 메모리의 데이터 세트 스냅샷을 디스크에 쓴다는 의미입니다. 이것이 Redis의 기본 영속성 방법입니다. 작업이 완료되면 지정된 디렉토리에 dump.rdb 파일이 생성됩니다. Redis가 다시 시작되면 dump.rdb 파일을 로드하여 데이터를 복원합니다. RDB는 여러 가지 방법으로 트리거될 수 있습니다.

• save: 수동으로 트리거되고 동기식으로 저장되며 현재 Redis 서버를 차단합니다.
• bgsave: 수동으로 트리거되고 비동기식으로 저장됩니다. Redis 프로세스가 하위 프로세스를 포크합니다.
• save m n: 자동으로 트리거됩니다. 데이터 세트가 _m_초 내에 _n_번 수정되면 자동으로 bgsave가 트리거됩니다.

bgsave 명령을 사용하여 전체 스냅샷을 실행함으로써 Redis는 주 스레드를 차단하지 않습니다. bgsave 명령은 RDB 파일을 생성하기 위해 하위 프로세스를 포크하는 반면 서버 프로세스는 명령 처리를 계속합니다.

스냅샷 중에 데이터를 수정할 수 있습니까? Redis는 운영 체제의 COW(Copy-On-Write) 메커니즘을 사용하므로 스냅샷을 찍는 동안 쓰기를 계속 처리할 수 있습니다.

bgsave는 주 스레드를 차단하지 않지만 빈번한 전체 스냅샷은 여전히 성능 오버헤드를 발생시킵니다. 예를 들어 fork를 통해 하위 프로세스를 생성해야 하며, 이로 인해 생성 중에 주 스레드가 차단됩니다. 이 경우 증분 스냅샷이 더 나은 접근 방식이 될 수 있습니다.

• RDB의 장점: AOF에 비해 대규모 데이터 세트의 복구가 더 빠르며 백업 및 전체 복제와 같은 대규모 데이터 복구 시나리오에 적합합니다.
• 단점: 실시간 또는 초 단위 영속성을 달성할 수 없습니다.

Redis 4.0부터 RDB와 AOF의 하이브리드 영속성이 지원됩니다. 메모리 스냅샷은 정기적인 간격으로 찍고 스냅샷 사이에 모든 명령 작업은 AOF를 사용하여 기록합니다.

RDB와 AOF 중에서 선택하는 방법

• 데이터 손실을 허용할 수 없는 경우 RDB와 AOF를 함께 사용하십시오.
• Redis를 캐시로만 사용하고 몇 분의 데이터 손실을 허용할 수 있다면 RDB만 사용하는 것으로 충분합니다.
• AOF만 사용하기로 선택한 경우 everysec 쓰기 전략을 사용하는 것이 좋습니다.

---

Leapcell은 백엔드 프로젝트 호스팅을 위한 최고의 선택입니다.

Leapcell은 웹 호스팅, 비동기 작업 및 Redis를 위한 차세대 서버리스 플랫폼입니다.

다국어 지원

• Node.js, Python, Go 또는 Rust로 개발하십시오.

무제한 프로젝트를 무료로 배포

• 사용량에 대해서만 지불하십시오. 요청도 없고 요금도 없습니다.

탁월한 비용 효율성

• 유휴 요금 없이 사용한 만큼 지불하십시오.
• 예: $25는 평균 응답 시간 60ms에서 694만 건의 요청을 지원합니다.

간소화된 개발자 경험

• 간편한 설정을 위한 직관적인 UI.
• 완전 자동화된 CI/CD 파이프라인 및 GitOps 통합.
• 실행 가능한 통찰력을 위한 실시간 메트릭 및 로깅.

간편한 확장성 및 고성능

• 쉬운 동시성 처리를 위한 자동 확장.
• 운영 오버헤드가 없으므로 구축에만 집중하십시오.

설명서에서 자세히 알아보십시오!

X에서 팔로우하세요: @LeapcellHQ