Tech planet 2015 LINE Redis Cluster Wonpill Seo
Contents 1. Why Redis? 2. LINE Redis Cluster 3. Problems & Our Solution 4. General Tips 5. Conclusion
00 Who? LINE Corporation in Japan Redis TF 소속 TF 의목표는 Redis 를젂부없애고 TF 를해체하는것
01 Storage system of LINE
01 Why Redis? 빠른속도 NoSQL (no schema) 다양한자료구조 LINE의주저장시스템으로선택
02 Redis Cluster of LINE 20,000,000,000+ Messages for a day 42 Clusters 5200+ Shards 40+ TB Data in Redis clusters 33,000,000+ OPS
02 Redis Cluster of LINE Client side clustering no proxy In-house implementations Client library Cluster manager admin play2 framework Cluster manager server health check, fail-over
02 Redis Cluster of LINE Application Instance Application Instance sync cluster status Storage Client APIs Sharding Strategy Storage Client APIs sync cluster status Cluster Manager Server health check, promotion
02 무엇을어디에? Storage vs. Cache 일부 node 가실패하더라도 origin 으로 fail-over 되어, 서비스가가능 하다면 cache 데이터성격에따라 Mutable or Immutable Read-intensive or Write-intensive Persistent or Volatile
02 Storage Cluster 가장기본적인구성 master <-> slave Storage APIs
02 Cache Cluster No slave Immutable data Consistency hashing Storage APIs cache miss Origin
02 Multi-instance Cache Cluster Read-intensive immutable data 태생적으로 hot-spot storage로향하는 read 요청을 cache 데이터양에따라, 클러스터크기조젃
02 Multi-instance Cache Cluster Storage APIs cache miss Origin
03 그렇게오래오래행복하게
03 언제나어긋나는예측 급격한사용자증가! 급격한기획서증가! 급격한데이터증가! 급격한가용인력고갈! 응? 왜꼭서버는회식할때죽는가?
03 Redis 사용시극복해야하는것 Single thread All for one, one for all. Memory based 데이터유실가능성
03 만에하나 키가 1 억개가넘는데, KEYS 명령을날리면? 시간을멈추는데성공했다! SET/ZSET/HASH 크기가수천맊인데, SMEMBERS, HKEYS 명령을날리면? DEL 명령을날리면? Use SCAN 중복데이터가능 데이터성격과사용패턴에따라제한적
03 만에하나 한대의호스트에 Redis 12 process 가서비스중인데, 12 대에동시에 slaveof 로 replication 을건다면? 제한된리소스 Physical memory copy-on-write File system dump.db Network
03 만에둘 IDC 가정젂되면? The End 그동안감사했습니다. 지금까지정말고마웠어요 어요.. 어요
03 번개맞는확률보다낮아도 로또맞는사람이있다. 데이터유실확율 마스터날아갈확율 x 슬레이브날아갈확율 0 < p 그런데그것이실제로일어났습니다. 약 2일간서비스중단
03 솟아날구멍 Persistency options RDB, AOF, Snapshotting 다른 Storage 시스템 Availability options 기본적 master-slave 복제 장애감지시 master 교체
03 Redis 만으론안되겠다 데이터백업 MySQL로는안되겠다. 대용량데이터저장수요 친구추가용주소록등 클러스터형태의 2차저장소필요 HBase 도입
03 HBase 역할 Redis 데이터백업 Redis에적합하지않은데이터보관 크기가크거나, 질의처리가오래걸리는경우 중요데이터가 HBase에복제 Redis 와상호단점을보완, 젂면으로
03 Redis + HBase Storage APIs Key space #1 key space #2 background re-sync table #1 table #2
03 High Availability write read Storage APIs Key space table table
03 Redis 가응답하지않아! 다양한이유로 Redis 응답지연이발생 Active-backup 구조에서 Failover? Read 맊이라도구해보자 일시적 inconsistency를허용한다면... Redis 장애시 HBase 홗용이가능 느린것이응답없는것보다는...
03 ReadHA Storage APIs failed Or timed out key space background re-sync table
03 타임아웃은늦다 장애확산은순식간 장애는장애를부르고... 사용자가공격자로변싞 범인은범행이후에잡을수밖에없나? Minority report? P Cluster shard 3-2
03 장애를예측할수있을까? Redis cluster 상태를모니터링 & 예측 Not watching, anticipating 연결시도, 실행시도하기젂에!!! Failover 시작 Re-try를함께
03 ReadHA + Anticipation Storage APIs anticipator Request cut key space background re-sync table
03 ReadHA
04 General Tips #1 Single thread O(n) 을주의하세요. 100 맊개에 1 초 물리메모리는여유있는편이좋음 slaveof 는 file dump 를동반하므로.. Client library java 구현체들이성능최적화가잘되어있는편은아님 apache commons pool2 도마찬가지 JMX option off, GC time 50% 증 pool 설정이잘못되면, stream buffer 의빈번한생성 / 파괴로인해 GC 부하 CPU affinity Redis, NIC interrupt CPU 분리하는편이좋음 High load 상황에서 CPU usage 20~30% 까지차이발생
04 General Tips #2 max-memory data 가너무크면, slaveof 시간등이늘어나게된다. 26G dump, 33 분 maxmemory-policy rehashing 중에 max-memory 에도달하면, LRU 가필요이상으로맋은메모리를삭제하려는문제가있음 상황에따라 N 분간 LRU 삭제맊할수도있음 ziplist/intset 적극홗용 평균 45% 정도의메모리사용량감소효과 한번 ziplist/intset->set/hash/zset/list 로바뀌면다시반대로돌아가지않는다 ZUNIONSTORE key 1 key 형태로하면강제로변경가능하지맊 fragmentation 문제발생가능 mem_fragmentation_ratio:2.33
04 General Tips #3 Lua script 적극홗용 # of I/O Atomicity client-output-buffer-limit 설정 write가맋으면 client-output-buffer-limit slave 기본값으로는 slaveof 실패할수있음 사람은실수를한다 KEYS, SHUTDOWN, FLUSHALL, FLUSHDB, SAVE 등위험한명령어는 rename 기본적인하지말아야할것들에대한정보 src/latency.c, createlatencyreport()
05 정리 Redis as Storage 극한상황에믿고쓸수있는친구 Redis + HBase 홖상의키스톤콤비 완젂체를위한여정은이제막시작
05 우리모두 11 월 17 일 ( 화 ) 에또만나요! ^^ LINE Developer Day 2015 INTERCONTINENTAL SEOUL COEX
Thank you!