Redis는 인메모리이지만 데이터가 재시작 후에도 살아남도록 디스크에 persistence할 수 있습니다. 두 가지 메커니즘 — RDB(특정 시점 스냅샷)와 AOF(연산의 추가 전용 로그) — 을 제공하며 내구성/성능 트레이드오프가 다릅니다.
RDB는 일정 간격으로 데이터셋의 스냅샷을 찍어 압축된 바이너리 파일로 저장합니다.
✓ 압축된 단일 파일 백업; 빠른 재시작 (스냅샷 로드)
✓ 백업과 재해 복구에 좋음; 성능 영향 적음
✗ Redis 크래시 시 마지막 스냅샷 이후 데이터 손실 가능 (예: 최근 몇 분)
→ 저장 지점 설정: 예 "≥1 변경 시 900초 후, ≥10 변경 시 300초 후 저장"
RDB는 주기적으로 전체 데이터셋을 압축 파일로 저장합니다 — 효율적이고 백업에 좋지만, 크래시 시 마지막 스냅샷 이후 변경이 손실됩니다.
AOF는 모든 쓰기 연산을 파일에 기록; 재시작 시 Redis가 로그를 재생하여 데이터 재구축.
✓ 더 내구성 — 데이터 손실 적음 (매초 또는 매 쓰기마다 fsync 가능)
✓ 로그를 재작성/압축하여 관리 가능하게 유지
✗ 더 큰 파일; RDB보다 느릴 수 있음; 재시작(재생)이 더 느릴 수 있음
→ fsync 정책: always(가장 안전, 가장 느림), everysec(좋은 균형), no(가장 빠름, 가장 위험)
AOF는 모든 쓰기를 기록하고 재시작 시 재생하여 데이터를 재구축합니다 — 더 내구성 있지만(데이터 손실 적음) 더 큰 파일과 잠재적으로 느린 성능/재시작을 동반합니다.
RDB → 더 나은 성능, 압축 백업, 빠른 재시작, 단 잠재적 데이터 손실 큼
AOF → 더 나은 내구성(최소 데이터 손실), 단 더 큰 파일, 느림
모범 사례: 둘을 함께 사용 → 백업용 RDB + 내구성용 AOF
→ Redis는 둘 다 사용 가능; 복구용 AOF, 스냅샷/백업용 RDB
또는: 순수 cache 용도 → persistence를 완전히 비활성화 가능 (데이터 재생성 가능)
Redis persistence를 이해하는 것은 Redis가 중요한 데이터를 보유할 때 데이터 내구성을 적절히 보장하는 데 중요하므로, Redis를 올바르게 사용하는 가치 있는 지식입니다.
Redis는 주로 인메모리이지만 디스크에 persistence 가능(데이터가 재시작과 크래시 후에도 살아남음)하다는 사실이 두 메커니즘과 그 트레이드오프와 함께 이해해야 할 중요한 점입니다. RDB(특정 시점 스냅샷)는 압축 백업, 빠른 재시작, 낮은 성능 영향을 제공하지만 크래시 시 마지막 스냅샷 이후 데이터 손실 위험이 있습니다 — 백업에 좋고 일부 데이터 손실이 허용될 때 적합합니다. AOF(모든 쓰기 연산을 기록, 재시작 시 재생)는 더 나은 내구성(최소 데이터 손실, fsync 정책으로 구성 가능)을 제공하지만 더 큰 파일과 잠재적으로 느린 성능/재시작을 동반합니다.
트레이드오프(성능과 압축 백업의 RDB 대 내구성의 AOF)와 흔한 둘을 함께 쓰는 모범 사례(스냅샷/백업의 RDB와 내구성의 AOF)를 이해하는 것은 건전한 구성 판단을 반영합니다.
또한 순수 caching 용도(데이터를 출처에서 재생성 가능)에서는 persistence를 완전히 비활성화할 수 있음을 인식하는 것도 중요합니다 — Redis가 항상 내구성을 필요로 하지는 않습니다.
사용 사례에 따라 올바른 persistence 구성을 선택하는 것(내구성 요구 대 성능, 또는 순수 cache에는 없음)이 핵심 실무 기술입니다.
Redis가 중요한 데이터(세션, 큐, 주 데이터)를 보유할 때 데이터 내구성이 중요하고, RDB, AOF, 그 트레이드오프, 모범 사례(둘 다, 또는 caching에는 없음)를 이해해야 Redis를 적절히 구성할 수 있으므로, Redis persistence를 이해하는 것은 Redis를 책임감 있게 사용하는 데 가치 있고 실무적으로 관련된 지식이며 — Redis가 보유한 데이터에 알맞은 수준의 내구성을 보장하고, 단순 caching을 넘어선 Redis 이해를 반영하는 주제입니다.