LINE DEVDAY 2014 - Redis Keep alive 살아남아 응답하라 - 황정동

LINE DEVELOPER DAY 2014
 

서비스 가용성을 위한 Redis, HBase 쌍두마차 !

Why Redis ?

장점 : 일단 빠르다, NoSQL, 다양한 자료구조(HashSet, SortedSet) 지원한다

단점 : Single Thread (No lock But High performance), 메모리 기반 (Data loss 가능성), MySQL backup 한계점), 완전한 클러스터 솔루션 없음 (In-house 개발)

Redis cluster 운영

Shard 당 master-slave 구조 cluster-manager w/ zookeeper 운영했으나, master-slave 동시에 나가는 경우 발생하더라... 복구용이, 운영자동화 대안이 필수

그래서 ?
Dashboard 및 운영도구 개발을 통한 운영 자동화

MySQL backup 대안 필요로 Storage for Low latency, Big size data, 용도로 HBase 선택
Redis에 적합하지 않은 용도, 거의 대부분의 데이터가 HBase에 적재

써보니 Redis + hbase 조합 좋더라

Redis vs. HBase

Mutable or Immutable

Write-intensive or Read-intensive or 

Temporary or Persistent : short life-cycle, recoverable 

Architecture

Redis + HBase : storage APIs, background re-sync

중요한 데이터 읽고/쓰기

Write 3 times : redis + hbase#1 + hbase#2

Read short redis once
Read 2 hbase
Read 3 redis, hbase(s)

클러스터 부하가...

30g 이상 Redis Busy-save 시에 20분 이상 소요되며 Redis-master freezing.

그래서..
Multi-instance Cache Cluster

For read-intensive immutable data
: Cache cluster 생성 후 클러스터 크기 조정

  부하가 높은 경우 Replica 상승
For Mutable data

: Race-condition 등 다양한 문제로 Case by case 로 접근 중

Fail-over

: Active Redis, Backup HBase

  Redis 장애 시에 HBase 처리로 로드밸런싱

결국, API 를 통한 서비스 아키텍처와 HBase의 충분한 응답속도 덕분임

Late timeout & ReadHA

: 장애확산은 순식간, 장애는 장애를 부르고, 매일 장애분석/복구의 반복
  장애 발생 전에 알 수 없을까?

모니터링 도구 : Not watching, But anticipating
Anticipating : storage api call monitoring 후에 찜찜한 문제시 될 것 같은 request 를 cut 하고, hbase로 triggering - 연결 시도, 실행 시도 전에 Failover, Re-try 함께 시도

이제는 
Hbase + Redis : 이제 HBase도 충분히 빠르다

Write hbase first, redis later

Read redis first, hbase later

이런 일들을 합니다

수천대 Redis + HBase cluster

Storage libraries or APIs

OSS 디버깅 고치기

Cluster 확장, linux cpu affinity, logs