Redis on kubernetes

1. Redis 사용처

RDBMS만큼의 정합성과 영속성을 보장할 필요가 없는 데이터들을 빠르게 처리하거나 일정 기간동안만 보관하고 있기 위한 용도로 레디스(Redis), memcached 등의 in-memory 기반 저장소가 많이 사용

2. 레디스 주요 스팩 정리

1. 단일 인스턴스, 센티넬(Sentinel), 클러스터(Cluster) 세가지 모드로 설치가 가능하다.

- 기본적으로 단일인스턴스도 high availability 을 보장한다.  
- 레디스는 마스터에서 슬레이브로 단방향 비동기 복제(unidirectional asynchronous replication)를 사용한다.  
- 센티넬(Sentinel)  
	: 서버가 분할되지 않은 단일 데이터베이스를 관리하는 목적으로 redis 를 쓸때 적합함  
	: 안정적 운영을 위해서는 최소 3개 이상의 sentinel instance 필요  
	: redis와 별도의 process 를 가지고,   
	: 지속적으로 master/slave 가 제대로 동작을 하고있는지 모니터링  
	: redis 연결시 Sentinel 에 연결해서 master 조회해야함.  
- 클러스터(Cluster)  
	: 여러 인스턴스 간에 데이터가 분할되고, 자체적으로 관리하고, 별도의 구성요소가 필요없는 서비스 구성시 사용  
	: 클러스터 안에서 내부 상호 연결을 통해서 자체적으로 오류 감지  
	: 기본인스턴스 실패시 복제본중 하나가 자동 승격  
	: Redis Cluster 기능을 지원하는 client를 써야만 데이터 액세스 시에 올바른 노드로 redirect가 가능  
- 참고 [개발 언어별 유명 redis client 비교 분석(https://www.compose.com/articles/a-tour-of-the-redis-stars-2/)]  
- jedis 를 사용하는 이유  
a) 가장 많은 Contributor 를 보유하고 있는 오픈소스 프로젝트이며 가장 오래된 클라이언트이다.  
       - 컨트리뷰터 수가 다른 프로젝트와 많은 차이가 날 만큼 많다.  
        Jedis : 108 / lettuce : 12 / redisson : 26  
        또한 국내에서 Redis 로 유명하고 책도 많이 쓰신 카카오 강대명씨가 커미터로 활동하고 계신 프로젝트가 바로 Jedis 다.  

b) jedis는 이슈와 피드백이 많다.  
   다른 클라이언트에 비해서 Jedis는 사용자가 많고, 커밋 시점이 오래되었고 지금도 활발한 편이여서 이슈나 피드백이 많다.  
   따라서, 예제소스 찾기가 쉬우며 그만큼 레퍼런스가 많은 편이다.  
c) Jedis는 사용이 간편하다.  
  처음 접근하기에 사용이 간편하고 버그에 대한 피드백도 빠른편, 그리고 여러가지 기능을 붙이지 않는 것도 장점이다  
  (출처: http://blessldk.blogspot.com/2016/05/redis-java.html)  

2. 데이터 지속성 Persistence 관점에서 두가지로 설정이 가능하다.

- 스냅샷(RDB file 포함), 로그 변경( AOF 사용 - append only file )  
- 스냅샷  
	: 일정시간별로 특정 시점 복구를 위한 스냅샷을 찎는다.  
	: RDB file 은 압축된 사용자 데이터 덤프를 의미함  
	: restart 시간이 빠르다  
	: 멈췄을때 데이터 유실 가능성이 더 높다.  
	: 몇 분 정도의 데이터 유실 가능성을 감내 할 수 있다면 RDB를 쓰는것을 추천  
- 로그 변경  
	: 매초 또는 변경될때마다 AOF 파일의 변경사항을 flush 하도록 설정 가능  
	: AOF가 변경되어 크기가 커지면 데이터 집합을 복구하는 데 시간이 오래 걸림  
	: 읽기 쉬운 포멧이지만 RDB보다 용량이 크다  
	: 어느 시점에 server가 down되더라도 데이타 유실이 발생하지 않는다  
- RDB와 AOF 방식의 장단점을 상쇠하기 위해서 두가지 방식을 혼용해서 사용하는 것이 바람직한데  
	주기적으로 snapshot으로 백업하고, 다음 snapshot까지의 저장을 AOF 방식으로 수행한다.  
	이렇게 하면 서버가 restart될 때 백업된 snapshot을 reload하고, 소량의 AOF 로그만 replay하면 되기 때문에, restart 시간을 절약하고 데이타의 유실을 방지할 수 있다.  
> 참고: http://bcho.tistory.com/654  
>  https://redis.io/topics/persistence