Redis ‐ Redis Data Persistence - woojin-playground/Backend-PlayGround GitHub Wiki

Redis - Redis Data Persistence

영속성이란?

  • 데이터를 생성한 프로그램이 종료되더라도, 그 데이터가 사라지지 않고 유지되는 성질을 의미한다.
  • 영속성이란, 데이터를 기억하기 위해 메모리 밖(DB, 파일 등)으로 꺼내어 영구히 보관하는 메커니즘을 말한다.

RDB

  • Redis는 인메모리 데이터를 주기적으로 파일에 저장하는데 Redis 프로세스가 장애로 인해 종료되더라도 해당 파일을 읽어들이면 이전 상태를 동일하게 복구할 수 있다.
  • RDB 방식은 스냅샷 이벤트가 발생할 때마다 저장된다.
  • RDB(Snapshot)는 순간적으로 메모리에 있는 내용을 스냅샷을 떠서 Disk에 옮겨 담는 방식이다. 스냅샷을 뜬다는 말은 특정 시점의 메모리에 있는 데이터를 바이너리 파일로 저장한다는 뜻이다.
  • .rdb 확장자를 가지며 .rdb 파일은 AOF 파일보다 사이즈가 작다. 따라서 로딩 속도가 AOF보다 빠르다.
  • RDB 방식은 메모리 Snapshot을 그대로 저장하기 때문에 서버를 재구동시 Snapshot을 다시 읽으면 되므로 속도가 빠르나 Snapshot을 추출하는데 시간이 오래 걸리고 도중에 서버가 꺼지면 이후의 데이터가 모두 사라진다는 단점이 있다.

1. SAVE(동기 저성)

  • 동작 : 현재 실행 중인 Redis 프로세스가 직접 디스크에 데이터를 쓴다.
  • 서버 차단(Blocking) : SAVE가 진행되는 동안 Redis는 다른 어떤 클라이언트 요청도 처리할 수 없다.(싱글 쓰레드 기반)
  • 위험성 : 데이터가 클수록 그에 비례해 저장 시간이 길어지며, 그동안 서비스는 완전히 먹통이 된다. 그래서 운영 환경에서는 추천하지 않는다.

2. BGSAVE(백그라운드 저장)

  • 동작 : fork() 시스템 콜을 호출하여 자식 프로세스를 생성한다. 실제 저장은 이 자식 프로세스가 담당하고 부모 프로세스는 계속해서 사용자 요청을 처리한다.
  • 핵심 기술 : Copy-on-Write
    • fork를 한다고 해서 메모리를 그대로 복사해서 2배로 쓰는 개념이 아니라 처음에는 부모와 자식이 같은 메모리 페이지를 공유하다가 부모 프로세스에 쓰기 작업이 발생할 때만 해당 메모리 페이지를 복사한다.
    • 덕분에 메모리 사용량을 효율적으로 관리하면서도 중단 없는 서비스를 제공할 수 있다.

3. 자동 저장(save 설정)

  • 개발자가 일일이 명령어를 치지 않아도 조건에 따라 자동으로 BGSAVE를 실행하는 설정이다.
  • 동작 : 조건이 만족되면 Redis가 내부적으로 BGSAVE를 호출한다. 서비스 운영 중 데이터 유실을 최소화하기 위한 안전장치이다.

AOF

  • AOF는 Redis 서버에 전달되는 모든 쓰기(Write) 명령을 순서대로 파일에 저장한다.
  • 서버가 재시작되면 이 파일에 기록된 명령들을 처음부터 다시 실행(Replay)하여 데이터를 복구한다.
  • 이 때 파일에 기록된 데이터를 실제 디스크로 물리적으로 내려쓰는(Sync) 주기에 따라 세 가지 정책으로 나뉜다.

1. appendfsync always

  • 동작 : 쓰기 명령이 실행될 때마다 즉시 디스크에 기록한다.
  • 장점 : 최대 안정성, 서버가 갑자기 꺼져도 데이터 유실이 거의 없다.
  • 단점 : 명령마다 디스크 I/O가 발생하므로 Redis의 최대 장점인 속도가 급격히 느려진다.

2. appendfsync everysec

  • 동작 : 명령을 메모리 버퍼에 모아두었다가 1초에 한 번씩 디스크에 쓴다.(Redis의 기본 설정)
  • 장점 : 성능과 데이터 보존 사이의 가장 합리적인 타협점. 성능 저하가 적으면서 유실되는 데이터는 최대 1초분으로 제한된다.

3. appendfsync no

  • 동작 : Redis가 직접 디스크 동기화를 요청하지 않고, OS가 판단해서 디스크에 쓰도록 맡긴다.(보통 30초 주기)
  • 장점 : 최대 성능, 디스크 쓰기 부하가 가장 적다.
  • 단점 : 서버 장애 시 최대 수십초 분량의 데이터가 유실될 수 있어 매우 위험하다.

BGREWRITEAOF(파일 압축/재작성)

  • AOF는 모든 로그를 다 적기 때문에 시간이 지날수록 파일 크기가 무한정 커진다는 치명적인 단점이 있다.
  • 이를 해결하는 방법이 바로 BGREWRITEAOF(Background Rewrite AOF)이다.
  • 동작 : 현재 메모리에 있는 데이터를 기반으로 최단 경로 명령어 리스트를 새로 작성한다.
  • 백그라운드 처리 : RDB의 BGSAVE처럼 시스템 콜을 호출해 작업을 수행하므로 메인 서버가 멈추지 않는다.

Hybrid

  • Redis. 4.0부터 도입된 하이브리드 영속성 방식은 RDB 빠른 복구와 AOF 데이터 안정성을 모두 취하는 메커니즘이다.
  • 앞부분 동작 방식 : 재작성이 시작되면 Redis는 현재 메모리에 있는 데이터를 기반으로 바이너리 형태의 RDB 스냅샷을 생성하여 AOF 파일의 앞부분에 작성한다.
    • 빠른 로딩 가능 : 텍스트 형태의 AOF 로그보다 훨씬 크기가 작고, 엔진이 해석할 필요 없이 메모리에 바로 넣을 수 있어 로딩 속도가 압도적으로 빠르다.
  • 뒷부분 동작 방식 : RDB 스냅샷을 만드는 도중에도 사용자의 새로운 쓰기 명령은 계속 들어오는데 이 최신 명령들은 RDB 뒤에 기존 AOF 텍스트 형태로 붙는다.
    • 최소 데이터 손실 : 재작성 도중 발생한 데이터 변화까지 기록해 데이터 손실을 방지한다.