Redis) 이것이 레디스다 15 - 기타 고려사항

앞서 살펴본 임계점과 메모리 설정외에 다른 고려사항을 알아보자.

스냅샷

• AWS와 같은 가상환경에서 레디스를 사용한다면 스냅샷 파일의 위치는 반드시 로컬 파일 시스템을 사용하자.
  레디스의 스냅샷 이벤트가 발생하면 매우 짧은 시간에 매우 많은 디스크 입출력이 발생하는데,
  EBS 같은 외부 저장장치는 로컬 디스크에 비해 스냅샷 파일을 기록하는데 많은 시간이 소요된다.
  만약 외부 저장장치에 저장해야한다면 로컬 디스크에 스냅샷을 생성하고 외부에 복사하는 방법을 사용하자.

• 마스터와 스냅샷
  복제 구성을 한다면 마스터 노드의 스냅샷 설정을 꺼놓더라도 마스터 노드는 스냅샷을 생성한다.
  왜냐하면 슬레이브 노드에 데이터를 복사해야하기 때문에 필요한 작업이기 때문이다.
  이 같은 상황엔 redis.conf의 client-output-buffer-limit 설정을 확인해야한다.
  마스터 노드의 스냅샷 데이터를 슬레이브 노드로 전송하기 위한 버퍼를 생성하는데, 이 버퍼의 크기가 지정된 크기보다 커지면 슬레이브의 연결을 강제로 끊는다.
  이때 슬레이브는 끊어진 연결을 다시 연결하려하고 접속 후 마스터 노드는 스냅샷을 생성하고 이를 전송을 시도하고 접속이 끊겨지고를 반복하게된다.

• 가상화 환경과 fork 함수
  레디스는 AOF와 스냅샷을 위해 fork 함수와 Copy-On-Write를 사용하여 백그라운드 저장 프로세스를 생성한다.
  이때 fork 함수를 호출하는데 fork 함수는 운영체제가 많은 리소스를 사용하게 한다.
  레디스는 단일 스레드로 동작하기 때문에 fork 함수가 완료(fork 함수가 수행되어 자식 프로세스가 생성이 완료되는 시점)되기 전까지 다른 명령을 수행하지 못한다.
  (자식 프로세스가 생성된 이후에 수행하게 됨)
  특히 AWS가 사용하는 Xen 플랫폼의 경우 fork 함수 수행 시간이 매우 길다.
  이런 상황에서는 샤딩을 사용하여 응답시간을 확보하는 방법을 고려해야한다.

복제 구성

하나의 마스터에 너무 많은 슬레이브를 구성하지 않도록 한다.
하나의 마스터 노드에 많은 슬레이브가 구성되면 데이터를 복제하기 위한 네트워크 사용률이 데이터 서비스를 위한 네트워크 사용률보다 커지게 되어 응답이 느려지게 된다.
또한 데이터 복제 요청에 응답하기 위해 리소스 대부분을 복제에 사용하게 된다.