개요
학교 데이터베이스 강의와 개인 공부에서는 relational dbms(rdbms)만 사용해보았습니다. 그러나 올해 세미나 수업에서 다양한 분의 강연을 들으며 현업에서는 rdbms를 넘어 mongodb, redis 같은 nosql dbms도 많이 사용하는 것을 느꼈습니다. 그러다 현장 실습에서 redis dbms를 보았습니다.
Redis 특징
레디스는 Nosql에 속하며 인메모리(in-memory) 자료구조입니다. 일반적으로 디스크 저장장치(ssd, hdd 등)에서 작동하는 dbms들과 달리 램에 상주하기 때문에 더 빠른 속도를 가집니다. 레디스는 인메모리라는 특성상 전력 공급 중단 등의 사고 발생 시 데이터 손실이 발생할 수 있다는 특징이 있습니다. 관련 키워드로 검색을 하니 레디스 공식 문서를 볼 수 있었습니다. 레디스 홈페이지에서 한국어는 제공되는 것 같지 않아 '레디스 공식 문서(Redis Documentation)'에서 '레디스 지속성(Managing Redis - Persistence)' RDB, AOF 방식의 장단점 부분을 간략하게 번역 및 요약해보았습니다.
Redis Persistence(지속성)
레디스는 2가지 방식으로 사고를 방지하기 위한 지속성을 제공합니다. 첫번째 방법은 RDB(Redis Database)이고, 두번째 방법은 AOF(Append Only File)입니다. RDB는 db의 스냅샷(snapshot)을 틈틈히 저장하고, 이를 기반으로 복구합니다. AOF는 서버가 받은 쓰기 명령들(write operations)의 로그(log)를 남겨, 이를 기반으로 복구합니다. 두 방식을 같이 사용하는 것도 가능합니다.
이제 각각의 장단점을 살펴보겠습니다.
RDB: 스냅샷을 남기는 방법
장점
- 스냅샷 방식이므로 저장되어 있는 시점들 중에 원하는 시간으로 복구할 수 있습니다.
- RDB는 single compact file로 AWS S3(스토리지) 등에 저장해 두었다면, 재난 복구에 매우 효과적입니다.
- 프로세스를 포크(fork)하여 자식 프로세스가 백업을 진행하기 때문에, 부모 프로세스는 디스크 i/o 등이 없어서 성능이 좋습니다.
- 데이터 셋(set)이 클 때, AOF보다 빠릅니다.
단점
- 데이터 저장 시점 이후에 변경된 내용은 복구할 수 없습니다. (인메모리라는 특성 때문입니다.) 스냅샷 간격을 줄이는 방식으로 피해를 최소화할 수 있습니다.
- 자식 프로세스를 포크(fork)할 때 성능 하락이 있을 수 있습니다. 여기서 '왜 쓰레드를 사용하지 않을까?'라는 의문이 들어서 관련 내용을 검색해보았고, '레디스(Redis) 와 싱글스레드(Single Thread)' 글에서 궁금증을 해결할 수 있었습니다.)
AOF: 로그를 남기는 방법
장점
- 서버의 디스크 동기화(fsync) 설정에 따라 다르지만, RDB보다 더 최근의 정보까지 기록할 수 있습니다. 따라서 재난 발생시 '손실 데이터 크기의 기댓값'이 RDB보다 AOF가 작습니다.
- AOF 로그는 더하기만 가능한(append only) 파일이기 때문에 검색(seek) 등이 없어 파일 손상 위험이 작습니다.
- 로그 파일이 너무 커지면, 백그라운드에서 같은 결과를 만들어내는 최소한의 로그 셋(log set)으로 로그 파일을 재작성합니다.
- 변경 명령들의 나열이라 이해하고 해석하기 쉽습니다.
단점
- 일반적으로 AOF 로그 파일이 RDB 파일보다 용량이 더 큽니다.
- 디스크 동기화 옵션에 따라 성능에 차이가 발생합니다. 로그의 디스크 동기화를 꺼둔다면(disable) RDB와 동일한 성능일 것입니다. 하지만, 모든 로그 업데이트 시에 디스크와 동기화하면 성능 하락의 폭은 클 것입니다.
현장 실습을 하면서 공식 문서들을 읽어볼 기회들이 생겼는데, 확실히 지식을 쌓는 것에 많은 도움이 되는 것 같습니다. 열심히 공부해야겠습니다.
