[발 번역] Apache HBase 는 어떻게 스케일링 하는가?

오래간만에 발 번역을 하게 됩니다. 이걸 번역할 시간이 없긴 한데, 공부 겸으로 제가 관심이 가는 분야로 이해도를 높이기 위해서 -_-, 발로 다시 번역을 시작했습니다.  원 글은 http://blog.cloudera.com/blog/2013/04/how-scaling-really-works-in-apache-hbase/ 에서 보실 수 있습니다.

How Scaling Really Works in Apache HBase

얼핏보면, Apache HBase 아키텍처는 master/slave 모델을 따르고, 마스터가 모든 요청을 받지만, 실제 작업은 slave 들에서 실제로 작업이 완료되는 걸로 보입니다. 그러나 이건 옳지 않고, 이 글에서, 실제로 master 와 slave에 의해서 어떻게 작업이 처리되는지 설명하려고 합니다.(역자 주: 여기서 master/slave 모델이라고 하는 것은 HBase Master 와 Region Server 들을 의미합니다. 일반적인 DB 의 Replication을 생각하지 마시고, Master 노드가 작업을 분배하고  실제 Worker들이 작업을 처리하는 모델을 생각하시면 됩니다.)

Regions and Region Servers

HBase 는 HDFS 기반으로 low-latency random reads 와 write 를 다루는 하둡 스토리지 매니저이고 페타데이터를 다룰 수 있습니다. HBase의 재미난 기능 중에 하나는 오토-샤딩입니다. 오토-샤딩은 시스템의 테이블이 너무 커졌을 때 동적으로 재분배 해주는 기능입니다.

Region 은 HBase 에서 수평 확장을 위한 기본 단위입니다. Region 은 함께 저장되는, 연결되어 있고, 정렬되어 있는 데이블 데이터의 부분집합입니다.

처음에는 테이블에는 오직 한개의 Region만 있고, 아래에서 볼 수 있듯이, Region이 row들이 추가되어 너무 커지면, Region 은 적당히 반으로 가르는 중간 키를 이용해서 나눠지게 됩니다.

HBase 에서 Slave는 Region Server  라 불리고, 각 Region Server 는 region들의 집합을 관리하는 역할을 하고 하나의 Region은( 데이터 row들의 범위를 가지는) 오직 하나의 Region Server 에 의해서만 처리됩니다.

HBase 아키텍처는 두 개의 메인 서비스로 구성되는데, 클러스터를 조직화하고, 관리 작업을 수행하는 HMaster와 각 테이블 데이터의 부분을 서비스하는 HRegionServer 로 되어 있습니다.

HMaster, Region Assignment, and Balancing

이전에 언급했듯이, HBase Master는 HBase 클러스터를 조직화하고, 관리하는 작업을 하게 됩니다.

Region Server는 하나 이상의 Region을 서비스하고, 각 Region은 하나의 Region Server에 시작시 할당됩니다. Master는 로드밸런싱의 결과로 Region을 원래의 Region Server 에서 다른쪽으로 이동하도록 결정할 수 있습니다.

Region과 Region Server의 매핑은 META라고 불리는 시스템 테이블에 의해서 유지되고, META 를 읽음으로서, 어떤 키가 어느 Region에 속하고 서비스 받는지 알 수 있습니다. 이것은 Read 와 Write 작업에 master가 전혀 참여하지 않고, 클라이언트가 직접 요청되는 데이터를 처리하는 Region Server와 통신할 수 있다는 의미입니다.

Locating a Row-Key: Which Region Server is Responsible?

row 를 쓰거나 읽기 위해서, 클라이언트는 master와 연결된 필요가 없고, 직접적으로 해당 row를 가진 Region Server에 연결될 수 있다. scan 의 경우에, 다뤄야 할 키들의 집합을 가진 Region Server들에 직접적으로 연결될 수 있다.

Region Server를 찾기 위해서, 클라이언트는 META 테이블로 쿼리한다.

META는 Region 들을 모니터링 하기 위해서 사용되는 시스템 테이블입니다. 서버의 이름과 테이블 이름을 비교하기 위한 Region 식별자, 그리고 시작 row-key 를 가지고 있습니다. start-key 와 다음 Region 의 start-key를 이용해서 클라이언트는 특정 Region에 속해있는 row의 범위를 알 수 있습니다.

클라이언트는 Region의 위치를 위한 캐시를 유지하고, 이것은 같은 Region을 확인해야 할 때, 매번 META table을 확인해야 하는 것을 피하게 해줍니다. Region이 나눠지거나, 다른 Region Server로 이동할 때(할당 정책이나, 밸런싱 때문에), 클라이언트는 예외를 받게 되고, 이로 인해 META 테이블에서 가져온 새로운 정보로 캐시가 갱신되게 됩니다.

 META 역시 다른 테이블과 유사하기 때문에, 클라이언트는 META 서버가 어디에 있는지 찾아야 할 필요가 있고, META 의 위치는 ZooKeeper 노드에 Master에 의해서 저장되게 됩니다.  그리고 클라이언트는 META가 저장된 Region Server의 주소를 바로 가져오게 됩니다.

HBase 는 BigTable 에 기반해서 설계가 되었고, -ROOT-라고 불리는 또 다른 테이블이, META 위치를 가지고 있고, Apache ZooKeeper 가 그 위치를 가리키고 있다. HBase 0.96 에서는 META가 나눠지지 않고, 하나의 Region으로만 구성되기 때문에, 이런 구조가 제거되고, ZooKeeper에만 의존하게 되었다.(역자 주: -ROOT- 테이블이 드랍되고 META 의 위치가 주키퍼에 바로 저장되게 되었다. https://issues.apache.org/jira/browse/HBASE-3171)

Client API: Master and Regions Responsibilities

HBase Java client API는 두 가지 주요 인터페이스가 있다.

  • HBaseAdmin 은 테이블의 생성/삭제/수정시에 “table schema”과 연결되도록 해준다. Region의 할당과 할당해제시, Region을 합치거나, 제거를 요청했을 때, 등등에 클러스터와 연결되게 한다. 이 인터페이스는 Master와 통신한다.
  • HTable 은 클라이언트가 get, put, delete, 그 외의 다른 데이터 명령어를 통해서 특정 테이블의 데이터를 다룰 수 있도록 해준다. 요청된 키를 처리하는 Region Server와 바로 통신하도록 해준다.

이 두 인터페이스는 서로 다른 역활을 한다. HBaseAdmin은 관리자 명령과 Master와 동작하고 HTable 은 Region과 통신하고 데이터를 처리한다.

Conclusion

여기서 살펴봤듯이, Master/Slave 아키텍처를 가지는 것이 모든 작업이 마스터를 통한다는 것은 아닙니다. HBase 클라이언트는, 데이터를 읽고 쓰기 위해서, 실제로,  모든 데이터 작업이 HTable 을 통해서 , 요청한 row key를 다루는 특정 Region Server  에 바로 요청하게 됩니다. Master는 테이블의 생성, 수정, 삭제 연산에만 사용됩니다.(HBaseAdmin)

Master라는 개념이 존재하지만, HBase 클라이언트는 데이터 연산시에는 master에 의존하지 않으므로, master가 다운되더라도 데이터 서비스를 할 수 있다.

Matteo Bertozzi 는 플랫폼팀의 소프트웨어 엔지니어이며 HBase 커미터입니다.