한발 한발 나아가기

1. O(n) 명령어 사용을 지양하자

레디스는 싱글 스레드기 때문에 한 번에 하나씩 명령에 처리할 수 있다. 따라서 데이터 양이 많은 경우 O(n) 명령어를 호출하면, 꽤 오랜 시간 동안 레디스가 다음 요청을 처리할 수 없게 된다. 그러므로 운영 환경에서는 특히나 오래 걸리는 명령어를 사용하지 말아야 한다.

대표적인 O(n) 명령어

• keys : 패턴에 맞는 모든 key들을 조회할 수 있다. 데이터 양이 많아질수록 느려지므로, 운영 환경에서는 scan 명령어를 사용하자.
• flushall : 전체 데이터베이스에 있는 모든 키들을 지우는 명령어
• flushdb : 선택된 데이터베이스에 있는 모든 키들을 지우는 명령어

참고로 memcached의 flush_all 명령어는 레디스보다 훨씬 빠르다. 그 이유는 동작 방식에서 차이가 있기 때문이다. 레디스는 데이터를 하나하나 지우는 방식으로 동작하기 때문에 시간 복잡도가 O(n)이다. 하지만 memcached는 모든 데이터를 지우지 않는 대신, 해당 명령어가 실행된 시간만 기록한다. 그리고 get 명령어가 호출된 시점에 유효성을 체크하고 결과를 반환하는 방식이다.(참고 링크)

2. persistence에서 주의사항

레디스를 단순 캐시가 아닌 데이터 저장소로 사용하는 경우라면 디스크에 백업하는 기능이 필요할 것이다. 레디스에서는 이를 위해 RDB와 AOF 두 가지 기능을 제공한다.

• RDB : 지정된 간격으로 데이터의 스냅샷을 파일로 저장한다.
• AOF : 서버에서 수신한 모든 write 명령을 기록한다. 그리고 서버 시작 시 해당 작업을 재수행하여 데이터를 복구하는 방식이다.

여기서 RDB를 사용할 때 주의할 점이 있다.

1. SAVE 명령어는 모든 작업을 멈추고 RDB 파일 생성 작업을 수행하므로 사용하지 않는다.
2. BGSAVE 명령어는 fork로 생성한 자식 프로세스에서 RDB 파일을 저장한다. 자식 프로세스로 인해 더 많은 메모리가 필요하므로, maxmemory 설정 시 주의한다.(참고 링크)
3. RDB 저장이 실패하면 write 명령이 실패할 수 있다. 레디스 설정을 통해 저장이 실패해도 write가 가능하게 바꿀 수 있다.

3. Replication에서 주의사항

1. 서버 재부팅 시 레디스가 자동으로 시작되도록 설정되어 있다면, 마스터에서 persistence 사용을 유지하는 것을 권장한다.

• 마스터 노드 다운 후에 데이터가 유실된 상태에서 재시작이 될 수 있다. 그런 경우 슬레이브 노드는 마스터와 재싱크되면서 데이터가 유실된다.

2. 마스터 노드 장애 시, 슬레이브가 마스터와 싱크 되는 것을 피하기 위해 연결을 끊을 수 있다.

3. 종종 발생하는 full sync를 위해서, 레디스는 사용자 설정과 무관하게 RDB 파일을 생성한다. fork 방식으로 RDB 파일이 생성되므로, maxmemory 설정 시 주의하자.

참고 링크

• https://redis.io/docs/
•  Redis 운영관리 - 강대명