[Database] Redis의 특징

Redis를 사용하는 이유

Redis는 In-Memory DB로써 디스크가 아닌 메모리에서 데이터를 처리하기 때문에 접근 속도가 빠르며, 사용자가 많은 경우에도 높은 성능을 보인다.

Redis의 특징

• key - value 구조

• String, Lists, Sets, Sorted Sets, Hashes 등 다양한 자료구조 지원

• 싱글 스레드로 동작

  즉, 한 번에 하나의 명령만 처리할 수 있다. 따라서 처리 시간이 오래 걸리는 명령은 피하는 것이 좋다. -> 가급적 O(1) 명령 사용

• 여러 프로세스에서 동시에 같은 key에 대한 갱신을 요청할 경우, Atomic 처리로 데이터 부정합을 방지해준다.

• 메모리 활용 + 영속화 지원

  Redis는 기본적으로 snapshot 기능을 제공하여 메모리의 데이터를 *.rdb 파일로 저장하여 해당 시점으로 복구할 수 있다.

Redis의 영속화 지원

Redis는 In-Memory DB이기 때문에, 서버 장애가 발생했을 경우 데이터 유실의 위험이 있다.

이러한 문제를 방지하기 위해 memory에 저장되어 있는 데이터를 disk로 백업하는 기능을 지원하며, AOF 방식과 RDB 방식이 있다.

AOF (Append Only File)

입력, 수정, 삭제 명령이 실행될 때마다 LOG 파일(ex. appendonly.aof)에 기록하며, 이 파일을 통해 테이터를 복구할 수 있다.

• 장점
  • 입력/수정/삭제 명령이 실행될 때마다 LOG 파일에 기록하므로, 실시간 데이터를 백업할 수 있다.
  • 명령 실행 기록을 그대로 LOG파일 하단에 저장하기 때문에. 저장 속도가 빠르며 데이터 손실이 거의 없다.
• 단점
  • 명령 실행 기록을 모두 기록하기 대문에 파일의 size가 커질 수 있다.
    • rewrite를 통해 최종 데이터만 남기고 모두 삭제하여 size를 줄일 수 있다.
  • 데이터 복원 소요시간이 길다.

RDB (snapshot)

특정한 간격으로 메모리에 운영 중인 데이터를 압축된 크기로 저장하는 방식이다.

• 장점

  • 압축하여 저장하기 때문에 AOF 보다 size 가 작으며, 로딩/복구 속도가 빠르다.

• 단점

  • 전체 데이터를 지정한 시간에 백업을 진행하기 때문에 실시간 데이터 백업이 어렵다.
  • 전체 데이터를 백업하므로 백업 시간이 오래걸린다.
  • 데이터 백업 중 서버가 다운될 경우 데이터가 유실된다.

RDB의 저장 방식 (save / bgsave)

RDB 저장 방식에는 SAVE와 BGSAVE가 있다.

SAVE

SAVE는 순간적으로 redis를 중지시키고 snapshot을 disk에 저장한다 -> blocking 방식

SAVE의 동작 순서

1. main process가 데이터를 새 RDB temp 파일에 쓴다.
2. 쓰기가 끝나면 기존 파일을 지우고, 새 파일로 교체한다.

BGSAVE

BGSAVE는 Background SAVE로써, 별도의 자식 프로세스를 띄운 후, 명령어 수행 당시의 snapshot을 disk에 저장하기 때문에 redis는 동작을 멈추지 않는다 -> non-blocking 방식

BGSAVE의 동작 순서

1. child process를 fork() 한다.
2. child process는 데이터를 새 RDB temp 파일에 쓴다.
3. 쓰기가 끝나면 기존 파일을 지우고, 이름을 변경한다.
   
   

또한 redis.conf 파일을 통해 주기적으로 snapshot 저장을 수행하도록 할 수도 있지만, 수동으로 실행할 수도 있다.

SAVE 또는 BGSAVE

❓ AOF와 RDB 중 무엇을 사용해야 할까?

1. 캐시 저장소로써 사용할 경우

만일 redis를 캐시로만 사용한다면 백업 기능은 사용하지 않는 게 좋다. 오히려 저장 공간 낭비가 될 수 있기 때문이다.

2. 어느 정도의 데이터 손실은 괜찮은 경우

만일 백업은 필요하지만 어느 정도의 데이터 손실이 발생해도 괜찮은 경우, RDB를 단독으로 사용하는 것을 고려해볼 수 있다. (여기서의 데이터 손실은 마지막 백업 시점과 장애 발생 시점 사이에 저장된 데이터들이다)

3. 데이터 손실이 일어나면 안 되는 경우

장애 상황 직전까지 모든 데이터가 보장되어야 할 경우 AOF를 사용하는 것을 고려할 수 있다.

✅ AOF와 RDB를 섞어서 사용하자

사실 두 가지 방식 각각 장단점이 있기 때문에, AOF와 RDB를 모두 사용하는 방식을 많이 사용한다.

RDB로는 주기적인 백업을 진행하며, RDB 백업 기준으로 AOF 로그를 초기화하여 메모리 절약 + 실시간 데이터를 유지하는 방법이 많이 사용된다.

이렇게 하면 서버가 restart될 때 백업된 snapshot을 reload 하고, 비교적 적은 양의 AOF 로그만 replay하면 되기 때문에 restart 시간을 절약하고 데이타의 유실을 방지할 수 있다.

➕ snapshot 추가 실험

dump.rdb 파일이 redis의 기본 snpashot 파일 이름이다.

redis CLI에 접속하여 CONFIG GET dir 명령어를 입력하면 snapshot file을 포함한 data들이 저장되는 위치를 반환한다.

만일 저장 위치가 지정되지 않은 상황이라면, 다음과 같이 지정할 수 있다.

dir ${저장위치}

또한, CONFIG GET save 명령어를 통해 snapshot file이 저장되는 주기/조건을 확인할 수 있다.

만일 save가 지정되지 않은 상황이라면, 다음과 같이 추가할 수 있다.

save 60 1

이는 60초 동안 1번 이상의 key 변경 발생 시 snapshot을 저장한다는 뜻이다.