LINE Messaging Platform에서 HBase와 Kafka 데이터 파이프라인 활용 사례
- DAY1 13:40-14:20 KST
- linke dev day link
- Youtube 영상 link
HBase
-
HBase 클러스터는 하둡과 주키퍼에 의존하는 클러스터 스토리지.
-
HBase 클러스터에는 유저와 디바이스, 설정 정보, 유저간 친구관계, 그룹으 ㅣ메타 정보, 유저 송수신 메시지 또는 유저가 메시지를 보내고 읽는 이벤트를 저장
-
데이터는 3개의 데이터노드에 복수로 분할된 블록으로 저장 (각 블록은 128MB 등)
-
리전은 HBase 를 수평으로 분할한 단위
-
HMaster 는 각 데이터를 리전별로 분할하여 할당함
-
각 리전 서버는 필요에 따라 데이터 노드에 접속하여 클라이언트 요청에 응답함.
-
장애가 발생해도 3개의 레플리카가 있으므로 하둡 데이터노드에 접속이 가능함.
- 리전도 다른 데이터노드에 할당하여 응답이 가능함
-
리전 서버에 리퀘스트를 송신하면, 리전 서버는 메모리상 데이트스토어를 갱신하고, HDFS 는 WAL 파일에 추가로 씀. WAL 파일에 쓰기 성공하면 데이터 영속화오 성공한 것으로 간주.
- 쓰기에 실패한 경우 롤백.
-
리전서버 A에 발생하여도. HMaster 는 리전 서버에 할당되어 있던 리전 1을 다른 리전서버B에 할당함.
- 메모리상 내용인 memstore 는 상실되지만, WAL 파일을 읽어 장애 발생 직전까지 내용으로 복구함
- -> 데이터의 신뢰성을 위해 WAL 파일을 사용함
-
소스 클러스터에서 레플리케이션 설정하면, HDFS 상의 WAL 파일을 읽어 각 엔트리를 레플리케이션 엔드포인트로 제공
- destination 클러스터의 각 리전 서버로 복제
- 복제가 실패하는 경우엔 HBase 의 리트라이 로직을 이용해 성공할 때 까지 리트라이 처리함
HBase 와 Kafka 파이프라인에 대해서.
- 마이그레이션 과정에서 HBase 1.2.5 클러스터에서 HBase 0.94 (통계 서버) 로 replicate 가 불가능한 문제에 맞닥뜨림
- replication 을 해결하기 위해 Custom replication endpoint 와 Kafka 를 통해 replicate 문제를 해결하였음.
kafka
-
프로듀서를 통해 key-value 형식의 데이터를 송신
- -> topic 내 여러 partition 에 데이터를 분산 처리
- -> consumer 에서 구독하여 데이터 수신
-
HBase 에 저장하는 메타 정보 등을 데이터 구조를 정의하여 Kafka 에 send
-
key로는 인코딩된 리전 식별자 또는 rowkey 를 사용하였음.
-
HBase 버전이 낮은 통계 서버에서는 데이터를 consuming 하여 저장
- -> replicate 를 실현.
-
비동기 처리이기 때문에 딜레이가 발생할 가능성이 있음.
HBase 와 Kafka 없이 이를 처리했어야했다면?
- 변경 발생시 변경 내용에 대해서 다른 서버에 어떻게 반영할 것인지.
- 카프카 송신이 실패했을 시 리트라이 로직과 어플리케이션 영향도,
- 카프카 데이터 송신 혹은 리트라이 중 어플리케이션 서버에 장애 발생시 모든 HBase 데이터를 송신 못할 가능성.
HBase 와 Kafka 를 사용하였기 때문에.
-
모든 데이터를 쓰기 대상을 송신하므로, 애플리케이션만 셋업하면 해결 가능성
-
리트라이 처리도 카프카 리트라이 처리 + 앱의 리트라이 로직 덕에 신뢰성 높음
-
단일 카프카 장애의 경우 퍼포먼스 영향 없음이 확인됨
-
신뢰성 문제는 리전 장애 발생하여도 서두에서 언급한 hbase, zookeeper 의 replication failover 덕분에 카프카에 송신이 가능함
-
표준에서는 지원하지 않는 replication 을 kafka 를 통해 구현할 수 있고, 다른 미들웨어로의 데이터 송신 및 마이그레이션도 실현 가능함.
-
HBase 의 WAL 을 카프카에 송신하고, 서비스와 앱이 다루기 쉬운 settings event 로 가공하여 kafka 로 송신, 다른 서비스에서 settings event 를 consuming 하여 사용하는 식으로 활용.
-
신년 00시 3~4배 트래픽 폭주가 발생하는데,
-
메시지 건수에 비례하여 각 컴포넌트 부하가 커지므로, 이 수치를 실시간에 가깝게 모니터링하고 싶다는 요구가 있음. (10초 이하)
-
메시지 건수 통계 분석을 위해 파이프라인을 활용하고 있음.
-
HBase 의 operation 테이블에 저장
- -> kafka 에 send
- -> consumer 에서 timestamp 100ms 단위로 묶어서 es 로 send
- -> 그라파나로 송신, 그라파나에서 시각화.
-
00시 뿐만 아니라 각국 신년에 따라 01:00, 02:00 시기에 트래픽 버스트하는 경우도 가시적으로 볼 수 있음.
-
어뷰저 탐지를 위해 영속화 스토리지인 HBase 의 장기간 데이터를 참조함
- 장기간 부정 데이터를 생성하는 부정 유저 탐지를 위해 파이프라인 활용
-
1분, 1일 등 시간범위로 글을 쓰는 유저를 탐지해서 send,
라인 사내에서 사용하는 패널티 게이트웨이에 전송하여 패널티를 저장, 라인 앱에서 해당 정보를 바탕으로 부정 유저의 리퀘스트를 차단.
future work
- alice 가 bob 를 친구추가하면 alice 가 key, bob 이 value 가 되는데 alice 로 lookup 은 되지만 bob 으로 lookup 이 안되는 문제가 있음. -> secondary index 문제를 고려중
- apache phoenix 에서 secondary index를 지원하는데, secondary index만을 위한 오버헤드 혹은 오버킬이 발생하므로 파이프라인을 고려중임.
- 서버에서 key - value, value - key 를 각각 HBase 에 저장하고 전송하는 것을 고려중
HBase's incremental backup
-
full backup 하여 스토리지 업로드하고, corn job 을 통해 incremental backup 을 취득함 -> 변동사항을 HFiles 로 취득하는 방안
-
-> 취득하는 동안 WAL 파일을 삭제할 수 없고, cron job 기동시 모든 WAL 파일이 클러스터 상에 남으므로 스토리지 사용량 문제가 있음
복원시에도 pain poinrt 가 존재. -
버그가 릴리즈된 시점까지 되감고 싶은 경우 시점을 선택하여 백업 가능 (다만 구간과 구간 사이의 정상 데이터는 유실)
