Redis 2017

Redis 운영관리
강대명 (CHARSYAM@NAVER.COM)

WHO AM I?
Redis Contributor
Udemy Data Engineer
Kakao Story-Senior Backend Engineer
Naver Mail-Senior Backend Engineer

주제
Redis 운영 사례
Redis 장애 사례

Redis Performance #1
Redis는 Single Threaded
Connection이 안정적인 상황에서
Xeon 에서 150,000 TPS 도 가능
Connection이 불안정하면
극도로 느려질 수 있음.
사례 – 1~2만에서 ~ 15만까지…
Get/set 만 이용

한번에 많은 개수의 데이터를 순회해야 하는 명령
을 피해야 함 – 인재(人災)
메모리 관리를 잘 해야함. 스왑을 쓰기 시작하면 프
로세스를 종료하기 전까지는, 스왑을 안 쓸 방도가
없음.

메모리를 적게 사용하도록 설정이 필요.
Set/Sorted Set/Hash를 많이 사용하는데, 그 데
이터 양이 적을 때는 강제로 ziplist 형태를 사용하도록
설정을 수정, 한 collection에 들어가는 아이템의 개수
가 적어야 한다.
Ziplist를 쓰면 메모리 사용량이 20% 이상 줄어듬.

Redis Sorted Set #1
SkipList - O(log(N))
링크드 리스트에 급행 열차 처럼, 몇단계 뒤를 가르
키는 노드 레벨이 존재 – 해당 방식으로 쉽게 데이
터를 찾을 수 있다.

Redis Sorted Set #6
Sorted Set 같은 경우에는 Value로의 접근을 위해서
HashTable 도 유지를 하게 됨.
SkipList + HashTable을 유지하므로 메모리 사용량이
많음.
Collection의 개수가 적고 사이즈가 적으면 ziplist 가
유리함.
Ziplist 는 선형 검색이므로 개수가 많아질수록 느려짐

Redis Monitoring #1
하나의 Redis 서버의 정보를 자세히 보여주는 것보
다, 같은 그룹의 여러대의 서버를 동시에 보여주는
것이 훨씬 유용함.
Memory 보다 RSS 의 사용량이 더 중요함.
Telegraf, Grafana 등으로 쉽게 구축 가능

Redis Monitoring #2
Used_memory RSS

Redis Monitoring Metrics
항목 내용
RSS 실제 사용 메모리, 물리메모리 70%
정도면 이전 고려 필요.
KEY 개수
Client 수 클라이언트 수가 흔들리면, 문제 발생
초당 커맨드 처리량
Hit Ratio
Eviction

Look-Aside Cache
ClientClientClient
API
Server
API
Server
API
Server
L
B
DB
Cache1. Cache에서
먼저 읽는다.
2. 없으면 DB에서
읽어온다
3. DB에서 읽은 내용을 다시
Cache에 쓴다.

Write Back
ClientClientClient
API
Server
API
Server
API
Server
L
B
DB
Cache1. Cache에 먼저
쓴다.
2. 적당한 타이밍에 DB에
쓴다.

Cache As Main Store
ClientClientClient
API
Server
API
Server
API
Server
L
B
Cache1. Cache에 먼저
쓴다.

다음 중 Failover가
중요한 경우는?

1,2,3 번
모두 중요할수도…
모두 안중요할수도…

Redis Failover
Coordinator 기반 DNS/VIP 기반

Coordinator 기반 #1
API
Server
Coordinator
Cache #1
Cache #2
CurrentRedis: Cache #1

API
Server
Coordinator
Cache #1
Cache #2
1. CurrentRedis 를
Cache#2로 변경
2. CurrentRedis 를 변경
Event가 통지

API
Server
Coordinator
Cache #1
Cache #2
1. API Server 가 Cache
#2로 접속을 변경

Coordinator Failover
Zookeeper/Consul/Etcd 같은 종류를 사용할
수 있음(Eureka 라든지…)
코드가 Coordinator의 이벤트를 처리할 수 있도
록 개발이 되어야 함.
어차피 동적으로 설정 변경을 한다고 하면, 이런 방
식을 도입을 해야함.

VIP 기반 #1
API
Server
Cache #1
192.168.0.101
VIP 192.168.0.100: Cache #1
Cache #2
192.168.0.102

VIP 기반 #2
API
Server
Cache #1
192.168.0.101
VIP 192.168.0.100: Cache #2
Cache #2
192.168.0.102
1. VIP 192.168.0.100 을
192.168.0.102.와 연결 2. Cache #1의 모든 연결을 끊음

VIP 기반 #3
API
Server
Cache #1
192.168.0.101
VIP 192.168.0.100: Cache #2
Cache #2
192.168.0.102

DNS 기반 #1
API
Server
Cache #1
192.168.0.101
.zsearch-cache001.suki.io: Cache #1
Cache #2
192.168.0.102
DNS TTL을 0로 설정

DNS 기반 #2
API
Server
Cache #1
192.168.0.101
Cache #2
192.168.0.102
1. DNS search-cache001.suki.io 의
주소를 Cache #2로 변경 2. Cache #1의 모든 연결을 끊음

DNS 기반 #3
API
Server
Cache #1
192.168.0.101
Cache #2
192.168.0.102

DNS/VIP Failover
기존 코드의 변경 없이 적용 가능.
VIP 방식은 어디서나(PasS 등으로 제공할때), DNS
방식은 서비스 내부에서만 적용가능
실제로 RackSpace 는 PaaS 형태의 서비스를 제공하므로
VIP로 Failover 제공
K모사는 DNS 방식을 이용.
 DNS방식은 언어, 프레임워크마다 고려할 사항이 있음
Ex) JVM DNS Caching 이슈.
DNS TTL을 0으로 설정, Pool 구조로 접근해야 함.

Failover 시 주의사항
Failover 시, coordinator를 이용하든 dns/vip
방식을 이용하든, 위의 failover 절차가 끝난 다음
에 변경 이벤트를 트리거해야 한다.

Redis Migration #1
새 버전의 Redis로 업그레이드 하거나 메모리가 부
족한 Redis 서버를 새 서버로 이전하기 위해서 많
이 사용함.
해당 과정을 자동화 함으로써, 유지보수에 이용
다만 Redis Replication 과정 자체에서 master
에 부담을 많이주므로 반대로 Master 장애를 유
발할 수도 있다.

Redis Migration #2
B를 A의 slave 로 설정
기존 Redis 서버는 A
새로운 Redis 서버는 B
B에 Read only 설정을 끔
클라이언트의 설정을 B로 변경
Sync가 완료되었는지 확인
A와 B 의 관계를 끊음

Redis Migration #3
slaveof A:IP A:PORT(in B)
기존 Redis 서버는 A
새로운 Redis 서버는 B
config set slave-read-only
no
클라이언트의 설정을 B로 변경
Check master_link_status
is up
slaveof no one

Redis Sharding #1
Memory 분배가 더 적절히 일어나는 방향으로
Operation 수가 적절히 분배되는 방향으로
ID Range, ID Modular, Consistent Hashing

Redis Sharding #2
Cache 형태의 Data
Look-Aside Cache 형태
보통 Consitent Hashing을 많이 이용
버려도 되거나, 새로 쉽게 만들 수 있는 데이터
캐시가 모자라면 그냥 장비 추가
일부 데이터 유실

Redis Sharding #3
스토리지 형태의 Data
Write Back 또는 스토리지로 사용할 경우
중요한 데이터는 M/S로 사용
Range or Modular 형태로 구분
미리 큰 그룹을 구성해 둠.
 데이터가 꽉 차면 해당 장비만 Migration으로 더 큰 사
이즈를 할당하는 방법으로 처리

권장설정 - 공통
RDB off
maxclient 설정 50000
Protected-mode no
메모리 사용량을 줄이기 위해서 해당 값 조절
*-max-ziplist-entries
*-max-ziplist-value
특정 command disable

권장설정 - Cache
권장 설정 공통 이용

권장설정 - Storage
AOF on
Master-Slave
부하가 큰 경우에는 Master에만 AOF on
auto-aof-rewrite-percentage 0

Redis 운영 #1
물리 서버 하나에 Redis 서버 한대를 올리는 것 보다는 메모리를
적게 사용하도록 n개의 instance를 실행하는게 좋음
메모리 모니터링이 필수

CPU 4 core, 32G Memory
Mem: 24G
Mem: 8G
Mem: 8G
Mem: 8G
more reliable

Redis 운영 #2
그룹별로 중요한 정보만 보여주는 대시보드를 만든다.
메모리 사용량이 얼마 이상이 되면, 메신저등을 통해서 알람
을 받는다.
마이그레이션 과정은 자동화된 스크립트를 통해서 처리한다.
Ex) redis_migration_tool [src] [target]

Redis 운영 #3
M/S로 구성된 서비스의 경우는 장애시 자동으로 Failover를
수행한다.
Redis 서버의 업그레이드나 설정 변경등은 ansible, chef,
Capistrano 등의 tool을 이용
200대 Redis 설치나 업그레이드에 시간이 얼마나 걸릴까
요?(설치는 금방, 업그레이드는 순차적으로…)

Redis Failover System #1
API
Server
Coordinator
Cache #1
Cache #2
Health Checker #1
Health Checker #2
Health Checker #3
Leader
Leader 가 Cache 상태 모니터링
캐시 그룹 목록과 master/slave
정보는 coordinator에 저장

API
Server
Coordinator
Cache #1
Cache #2
Health Checker #1
Health Checker #2
Health Checker #3
Leader
Cache#1 장애 확인

API
Server
Coordinator
Cache #1
Cache #2
Health Checker #1
Health Checker #2
Health Checker #3
Leader
Leader가 CurrentRedis 변경

API
Server
Coordinator
Cache #1
Cache #2
Health Checker #1
Health Checker #2
Health Checker #3
Leader
API Server가 Cache 주소 변경

API
Server
Coordinator
Cache #1
Cache #2
Health Checker #1
Health Checker #2
Health Checker #3
Leader
Leader 가 장애시
Leader가 변경

기본 설정을 사용
Redis 의 기본 설정은 서비스 운영과 맞지 않음
 RDB 관련 설정을 끄고
 Maxclient 설정을 올려야함.(커널 설정도 확인)

느린 명령의 실행
느린 명령의 실행은 대표적으로 할 수 있는 실수
Keys 의 사용
해당 명령을 disable
큰 collection 의 삭제
Redis 4.0 부터는 lazy deletion이 가능(config)
Lazyfree-lazy-eviction
Lazyfree-lazy-expire
Lazyfree-lazy-server-del

AOF Rewrite는 수동으로
기본적으로 AOF Rewrite가 발생.
여러 대의 노드에서 동시에 AOF Rewrite가 발생
하면 메모리/IO 사용량이 급증
해당 작업이 필요할 때 시간을 정해서 개별적으로
AOF Rewrite 작업을 수행

결론
Redis 의 특성을 파악해야 한다.
다른 컴포넌트와 마찬가지로 해당 장애에 대한 자동화된
Failover 와 Migration 에 대한 고려가 필요.
사람이 살아야 서비스가 산다.

Redis 2017

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Redis 2017

Semelhante a Redis 2017 (20)

Mais de DaeMyung Kang

Mais de DaeMyung Kang (20)

Redis 2017