LINE DEVDAY 2014 - Big Data - 최철호

LINE DEVELOPER DAY 2014

개인적으로 제일 좋았던 세션이었습니다. :-)

Big Data (HBase & Analysis)

흑역사
Redis shard + My SQL 백업 체제가 이틀만에 30만 50만 유저 등록으로 주소록 백업 장애
“홍콩대란"으로 HBase 스토리지 전환 (2011.11)
 현재 14개 클러스터 1,165대 520테라 Snappy, 비휘발성 데이터는 다 hbase 저장
데이터분석용 2개 클러스터 387대 1페타 snappy fast_diff, 2조 5천억 레코드, 데이터 15일 이내의 TTL

OpStorage란?
Op : 클라이언트 서버 간의 모든 Event, 클라이언트가 가져가야 할 중간 저장소
fetchOps : 59.1% of LINE API calls
LEGY : API Server, Bot Server : LINE Storage Service Layer : Redis Cache, HBase01, HBase02

Why not MQ?
정렬된 사용자 별 Op
멀티디바이스 고려하여 어느 정도 저장해서 유지해야 할 필요
큰 장애에 대한 유실 대비

개선사항
Row scanning 성능 이슈 발생으로 Row bucket get 으로 트래픽 희생으로 성능 5배 향상
Dual Hbase cluster

HA 통한 성능개선
쓰기에 어느 한 쪽만 성공해도 완료되므로 성능을 보장 받음
읽기에 이빨이 빠질 수 있는데 빠진 쪽에 나머지 빠진 부분을 채우는데 (O(n)) 이므로 아주 느리진 않음 : 약 0.01% 발생 23억건 71만8천건 경합
결국, 이러한 별도로 동기화 하지 않아도 건건이 동기화를 할 수 있는 방법을 택했음
2개의 하이브 버전을 제공할 수 있도록 스토리지 프록시 게이트웨이 개발을 하고 있고 적용 예정임 

 Caching
 Redis sharding + hbase replication 상호 보완으로 어느 한 쪽에 노드가 죽어도 잘 운영됨

OpStorage Troubleshooting
GC promotion failed + HFile BlockCache 문제점 발견 but … 결국 코드리뷰
모니터링과 각종 인프라의 로그를 확인할 수 있어야 하는 환경이 있어서 가능했음
결국 scan 방식에서 get 방식으로 전환하였고 매번 get 을 2개 가져왔는데 실제로 2개 이상의 get 에서는 bloom filter 안쓰더라 ;ㅁ;
블룸필터를 위한 코드는 더 이상 사용하지 않는 것이 확인 되었으므로 블룸필터 제거했음

얻은 교훈
로그를 잘 남기자
모니터링 잘 하자
코드 읽는 습관을 들이자
운영툴링을 위한 개발하자

개인적인 회고
* 일반적인 소프트웨어 엔지니어링 기술이 오픈소스 인프라 운영/개발 시에도 너므 중요함
* 자료구조/알고리즘/분산환경 컴퓨팅 등의 기술에 대한 노력을 게을리 하면 안됨
* MongoDB 와 Hive 저장 시에 명시적인 기준이 필요하고 어떻게 분기할 것인지 결정
* 저장소를 액세스 하기 위한 API에 대한 필요성 느낌 - 추후 오픈소스 업그레이드 등
* Bloom Filter, CMS,  1G VM

* 서버튜닝을 위해서 Java 의 기본지식 - long 값이 32G 이상은 압축이 안되므로 31G 사용