Redis Persistence - RDB, AOF 장단점

 

Redis는 file로 남겨서 메모리 데이터가 사라졌을 때 복구할 수 있는 방법을 제공한다.

 

 

 

 

1) RDB (Redis DB)

 

• 주기적으로 특정 시점의 snapshot을 남긴다.
• 최소 5분 이상의 간격으로 세팅해야 한다.

 

• redis.conf 의 save 파라미터로 지정한다
  • ex) save 900 1 : 900초 동안 1번 이상 key 변경 발생 시 저장
• save 조건은 여러개 지정 가능하다. 하나라도 만족하면 수행한다.

 

장점

• 성능 손해를 최소화
• backup파일이 AOF에 비해 작고 복구 쉽다
• restart 시간이 빠르다.

 

단점

• 마지막으로 snapshot이 남은 시점과 다음 주기 사이에 장애가 발생한다면 cache 데이터가 유실될 수 있다.
• 디스크에 남기는 child process를 만들기 위해 fork()를 수행할 때 이 시간동안 client에 응답을 주지 못할 수 있다.
  • 데이터가 클수록, cpu 성능이 안좋을수록 영향이 크다.
  • 몇 ms~1초 정도 소요된다.

 

몇분 정도 유실 가능성을 감내할 수 있다면 RDB 추천

 

---

2) AOF (Append Only File)

 

• 모든 write operation (입력/수정/삭제) 마다 Log를 쌓는다.
• 처음부터 모두 실행하면 데이터가 모두 복구된다.
• 해당 file은 append만으로 쓰여진다.
• Logging되는 데이터 자체가 redis protocol과 일치해서 AOF로부터의 복구가 쉽다.
• file이 너무 커질경우를 위해서 rewrite 기능으로 파일이 너무 카지지 않도록 관리한다.

 

 

장점

• 모든 데이터가 백업되고 복구 가능하므로 가장 안전하다.
• AOF파일에 쓰인 내용은 redis protocol과 일치하므로 이해하기 쉽다.

 

 

단점

• RDB에 비해 성능 손해가 크다.
• write query 응답 속도가 느리다.
• backup 파일이 크다.
• 복구시간이 오래 걸린다.

 

---

 

fsync 옵션

 

자신이 원하는 안정성에 따라서 속도와의 trade-off를 고려하여 선택한다.

 

1) no fsync at all

운영체제가 fsync 하는 주기(리눅스 30초) 마다 파일에 sync된다. -> 가장 빠르고, 가장 불안전하다.

 

2) fsync every second

매 초마다

 

3) fsync at every query

매 쿼리마다

-> 가장 안전하고 가장 느리다.

 

 

---

 

3) RDB + AOF

 

RDB의 주기 사이는 AOF로 중간과정을 남긴다.

 

---

 

TIP

• persistence의 성능의 병목지점은 Disk이다. SSD를 써야한다.
• 성능을 위해서는 Replication 을 이용하여 보장하는 것이 좋다.
• 중요한 데이터의 경우 Redis Cache에 hit되지 않으면 원본데이터(RDBMS)을 조회하도록 구현해놓는것은 필수이다.

 

 

---

 

생각해볼 점

 

1. 성능의 지속적인 손해가 있음에도 AOF로 persistence를 쓰는 것

2. Cache의 복구에 불편함과 불안전함이 있지만 RDB로 persistence를 써서 성능의 손해를 최소화 하는 것

3. 장애로부터의 복구에 불편함이나 손해가 있더라도 persistence를 쓰지 않고 성능의 이점을 극대화 하는 것