HBase의 -ROOT-, .META. 테이블에 문제가 생겼다면

들어가는 말

기존 RDBMS의 한계를 극복하고 데이터베이스의 새로운 패러다임을 실현하고자 만들어진 HBase는 대용량 데이터 처리를 위한 분산 데이터베이스이다. 기존 RDBMS와는 다른 점 중에 첫번째로 꼽는 것이 바로 SQL을 지원하지 않는다는 것이었다. 하지만 HBase의 경우 Phoenix가 등장하면서 이런 NoSQL의 특징(?)은 사라진지 오래다. 오늘 하려는 얘기는 HBase의 역사나 아키텍처와 같은 개념적인 것이 아니고 실제 이 데이터베이스를 운영하다가 한 번 쯤은 만나게 되는 장애 상황을 극복하는 것에 대한 것이다. 장애의 유형이야 여러가지 겠지만 그 중에서도 심심치 않게 발생하지만 쉽게 복구가 가능한 메타 테이블의 장애와 그 복구 방법을 알아 보도록 하자.

HBase의 메타 테이블

기존 RDBMS의 경우도 실제 데이터가 저장되는 테이블과 이러한 테이블의 존재를 설명해주는 메타 테이블이 존재했다. 보통은 시스템 카탈로그 또는 시스템 딕셔너리 등으로 불린다. 마찬가지로 HBase에서도 이런 역할을 하는 메타 테이블이 존재한다. -ROOT-와 .META.가 그것이다. 테이블 이름의 앞뒤에 각각 하이픈(-)과 마침표(.)가 있음에 주의하도록 하자. 여기서 이 메타 테이블의 구조나 용도에 대한 설명은 생략하겠다. 궁금하신 분들은 Lars George가 쓴 HBase The Definitive Guide에서 그 내용을 확인할 수 있다. 중요한 것 한 가지를 추가로 언급해야겠다. 지금 설명하는 HBase의 버전 말인데, HBase는 오픈소스이고 그 말은 지금도 굉장히 빠른 속도로 진화하고 있다는 것이다. 즉, 최신의 HBase는 이 글에서 설명하는 내용과 다를 수 있다는 점을 기억하기 바란다. 이 글에서 설명하는 HBase는 0.94 버전이다.

[그림 1] 이 글에서 설명하는 HBase의 버전은 0.94

HBase는 분산 데이터베이스라고 했다. 그래서 테이블들의 데이터를 분산파일시스템에 저장한다. 물론 여기서 분산파일시스템은 HDFS를 말한다. 또 다수의 컴퓨터로 구성된 클러스터에서 분산 데이터베이스의 원활한 동작을 위해 ZooKeeper를 사용한다는 것도 기억해두자. 다시 본론으로 돌아와서 HBase의 메타 테이블은 HDFS와 ZooKeeper에 각각 그 정보들이 저장된다.

[그림 2] 분산파일시스템인 HDFS에 저장된 HBase의 메타 테이블

[그림 3] zookeeper에 저장된 HBase의 메타 테이블 정보

 

HBase의 메타 테이블 장애 상황은 단일고장점

단일고장점(SPOF, Single Point of Failure), 분산 데이터베이스는 데이터를 여러 대의 컴퓨터에 나눠서 저장하고 쿼리에 응답할 때도 병렬로 응답하는 것을 골자로 하고 있다. 그러므로 이들을 지휘하는 Master가 필요하다. 그런데 이 Master에 문제가 생기면 전체 클러스터가 먹통이 되는 것이다. 이러한 상황이 발생하게 되는 어쩔 수 없는 포인트인 Master가 바로 단일고장점이다. 즉 HBase의 수 많은 테이블들의 존재를 입증하는 메타 테이블이 고장나면 이 또한 단일고장점으로써 서비스 불능 상태를 초래하게 된다. 글이 길어지므로 여기선 그 원인에 대한 설명을 생략하기로 한다.

[그림 4] 테이블의 리전정보를 담고 있는 메터 테이블에 문제가 생겨 테이블 접근 불가

 

HBase의 관리툴을 이용한 1차 복구 시도

HBase는 hbck라는 관리툴을 제공하고 그 옵션 중에 fixMeta, repair와 같은 것들이 있다. 그 말은 실제 운영환경에서 이 툴과 옵션을 쓸 일이 종종 있다는 것, 그리고 메터 테이블이 쉽게 깨질 수 있다는 것을 반증한다. 보통 앞서 [그림 4]와 같은 상황을 만나면 메터 테이블에 문제가 있음을 감지하고 이를 복구하려는 시도를 하게 된다. 그런데 이 복구 시도가 다음과 같이 실패하는 상황에 직면하면 난감 그 자체다. 예외의 내용을 읽어보면 다음과 같다. .META. 테이블에서 언급한 리전에 대한 정보가 -ROOT- 테이블엔 없다는 것이다.

Exception in thread "main" java.io.IOException: HRegionInfo was null or empty in -ROOT-, row=keyvalues={.META.,,1/info:server/1502323864970/Put/vlen=18/ts=0, .META.,,1/info:serverstartcode/1502323864970/Put/vlen=8/ts=0}

[그림 5] HBase의 관리툴인 hbck의 -fixMeta 옵션 실행의 실패

이젠 어떻게 해야 할까!

이 글의 핵심이다. 이런 상황, 즉 HBase의 hbck 마저도 고칠 수 없는 메터 테이블의 단일고장점 문제에 직면한 상황에 대한 해법. 간단하다. 그리고 효과적이다. 다음의 절차에 따라 차분하게 진행하면 된다. 서두에 언급했던 것처럼 HDFS와 ZooKeeper 두 곳에 메터 테이블에 관련된 정보가 상호 보완적으로 존재한다는 점을 기억하자. 기본적으로 HBase의 메터 테이블들은 서비스가 기동될 때 존재 유무를 보고 없는 경우에 새로 만든다. 문제는 HDFS에 없으면 새로 만들고 마찬가지로 ZooKeeper에도 없으면 새로 만드는데 HDFS에 새로 만들었다고 ZooKeeper에 있는 정보를 지우고 다시 만들지는 않는다는 것이다.  그러므로 깔끔하게 양 쪽의 데이터를 모두 지우고 재구축하자는 것이다. 이 때 주의할 마지막 한 가지는 HBase 서비스 기동 시에 새로 만든다는 것이 메터 테이블의 스키마, 그릇이지 거기에 담길 내용은 아니라는 점. 

그러므로 재기동 후에 hbase hbck -fixMeta -repair 와 같이 그 내용을 담는(재구성하는) 명령을 수행해줘야 한다.

1. HBase 서비스 종료

2. ZooKeeper에서 /hbase/table94/-ROOT-, /hbase/table94/.META. 삭제

3. HDFS에서 /hbase/-ROOT-, /hbase/.META. 삭제

4. HBase 서비스 기동

5. hbase -fixMeta, -repair 실행

6. hbase shell에서 status로 리전서버와 리전할당 확인

7. 특정 테이블을 scan 하여 정상적으로 데이터 보이는지 확인

마치면서

출근하면 어김 없이 기다리고 있는 것이 "장애지원" 요청이다. 하둡을 제대로 이해했다면 스스로 해결할 수도 있을텐데 하는 안타까움에 빅데이터 플랫폼의 이해에 대한 교육 커리큘럼 설계와 교재 제작, 그리고 교육도 시행해봤다. 그런데 여전히 엔지니어들은 어려워한다. 그 어려움 이면에 도사리고 있는 것은 '두려움'일 것이다. 어렴풋하게 알고 있는 것은 아는 것이 아니다. 두려움은 모르는 것에서 기인한다. 정확히 알았다면, 어떻게 될지를 알수만 있다면 더 이상 두렵지 않을 것이다.

하둡 엔지니어를 꿈꾸고 있다면 정확히 이해하고 알기 위해 노력해야 한다. 시간을 많이 투자해야 한다. 그런데 오픈소스 소프트웨어의 특성 상 친절하고 자세한 그러면서도 깊이 있는 문헌을 찾기가 쉽지 않다는 것이 큰 걸림돌이다. 시간이 허락하는 대로 일하면서 겪었던 하둡 관련 장애와 그 증상, 원인 그리고 조치 방법 등을 글로 남겨 볼까 한다.