redis 사용시 주의점과 부가 기술

레디스 사용시 주의점과 부가기술

RDB기능

  • 레디스에서 디스크에 메모리 상태를 그대로 받아 저장(메모리스냅숏)하는 기능
  • 레디스 서버 장애요인 99.9%를 차지. 설정으로 끌 수 있음.
  • RDB 작업이 실패하면 ‘쓰기 거부’ 상태가 돼 추가 장애를 낼 수 있다.
  • 아마존 웹서비스 서버 기준 60GB짜리 메모리 서버 테스트시 RDB 작업에 10분 정도가 걸린다. 싱글쓰레드 문제를 겪지 않기 위해 ‘Fork()’라는 분기 기능을 쓸 수 있지만 이 경우 메모리를 2배로 사용, 용량부족에 따른 오류와 원인을 알수 없는 장애를 낼 수 있음.

AOF기능

  • AOF는 레디스 프로토콜로 통신한 내용들을 명령어, 키, 이름 등 형식 그대로 저장한다
  • AOF도 RDB와 같이 주의해야 함.

레디스 마스터 & 슬레이브 관리

  • 슬레이브는 마스터의 데이터 저장을 보조한다.
  • 마스터가 죽었다가 되살아날 때 자신의 정보를 모두 없애고 그 데이터를 그대로 베낀다.
  • 아무 데이터가 없는 마스터를 시스템에 연결하면 슬레이브에 남은 데이터를 마스터에 되살릴 수 없음.
  • 복구할 데이터를 가진 시스템에 ‘슬레이브오브노원’이라는 명령어로 그걸 마스터로 승격시켜야 함.
  • 메모리가 부족한 상태에서 슬레이브가 붙는다면 장애가 발생할 수 있음. 슬레이브가 마스터에 연결할 때, 설정과 상관없이 sync를 위한 RDB 생성하고 이것을 seed로 전송한 후 뒤의 차이를 sync함. write가 많은 서버라면 memory overflow발생.

레디스 인스턴스 갯수

  • Core 수나 메모리에 따라서 적절히 Redis 인스턴스를 여러 개 띄워주는 것 고려
  • N개의 인스턴스를 실행한다면 (Memory-(운영체제필요메모리))/(N+1) 정도의 규칙으로 적절히 나누어 주어 분산시도
  • 하나의 서버에서 하나의 인스턴스만 실행하면, 16G 메모리라면, 최악을 대비해서 7G 정도만 사용해야 하지만 여러 개의 인스턴스를 실행한다면 4G*3개 정도의 인스턴스를 운영고려

레디스센티넬

  • 마스터가 죽었다고 판단시 다른 슬레이브를 마스터로 승격하고 사용자측에 마스터가 바뀌었다는 알림을 보내는 도구
  • 살았는지 판단하는 단계(네트워크 단절, 주관적 다운, 객관적 다운)를 거쳐 페일오버를 수행
  • 완성도는?

레디스 부하분산

  • 트위터에서 만든 티웸프록시, 페이스북 메신저 시스템에 적용된 샤딩 시스템.

티웸프록시

  • 클라이언트에서 데이터가 들어오면 해싱값을 만들어 여러대의 레디스 서버에 나누어 줌.
  • 서버당 1개의 커넥션을 만들기 때문에 속도가 빠르고 보안상 안전하며 부하를 줄임.
  • 레디스센티넬과 묶어 고가용성(HA) 구성도 가능
  • 키 세트가 여러 서버로 분산돼 레디스 서버 전체 데이터를 다루던 명령어 효과가 반감되는 단점도 있다.

셀 아키텍처

  • 페이스북 메신저에 적용
  • 전체 인프라가 각각 독립된 하드웨어(HW)로 구성되는 셀로 나뉘는 것으로 장애를 분산시킬 수 있다.
  • 샤딩은 여러 데이터센터에 서비스를 나눠 운영하는 것이라 재해 발생에 따른 서비스 장애 범위를 줄일 수 있는 역할.
  • 셀 아키텍처의 단점으로 “독립적인 장비 인프라를 셀마다 풀세트로 갖춰야 하기 때문에 서비스 구성에 따른 비용 부담

참고:
- [http://www.zdnet.co.kr/news/news_view.asp?artice_id=20131119174125]
- [https://charsyam.wordpress.com/2013/11/17/%EC%9E%85-%EA%B0%9C%EB%B0%9C-%ED%95%9C-%EC%84%9C%EB%B2%84%EC%97%90-%ED%95%98%EB%82%98%EC%9D%98-redis%EB%A5%BC-%EB%9D%84%EC%9A%B0%EC%8B%9C%EB%82%98%EC%9A%94-%EC%95%84%EB%8B%88%EB%A9%B4-%EC%97%AC/]