HBase의 특징

개인적으로 어떤것이든 도입 필요성에 대해서 경영진을 설득할 때 그것에 대한 특징이 잘 설명된다고 생각한다. 그렇다면 다음에 진행할 프로젝트에서 HBase를 사용해야 한다고 경영진을 설득하는 방법에 대해서 알아보도록 하자.



다음 프로젝트에서 HBase를 사용하고 싶다면 다음과 같이 경영진을 설득할 수 있다.

Hadoop과 강한 연관성을 가지고 있다!

HBase에서 분산 환경을 구축하기 위해서는 HDFS위에서 실행되어야 한다. 어찌보면 제한사항으로 느껴질 수도 있지만 이미 Hadoop을 사용하고 있는 환경에서는 오히려 그것이 큰 장점이 될 수 있다. 설득의 포인트는 "기존의 Hadoop 시스템을 활용해서 NoSQL Database까지 운영할 수 있다"로 하면 된다.

기존 시스템을 활용할 수 있다는 것은 매우 강한 설득력을 가질 수 있다. 구체적인 목적을 가지고 Hadoop 시스템을 필요한 규모만큼만 운영하는 경우라면 "꼭 Hadoop을 활용할 필요가 있느냐?"는 질문을 받을 수 있다. 하지만 다행히 Hadoop 시스템을 구체적인 목적을 가지고 운영하는 경우는 많지 않다.

만약 Hadoop 시스템을 운영하고 있지 않은 경우라도 공략은 어렵지 않다. Hadoop 시스템을 도입하자고 경영진을 설득하는 것은 HBase에 비하면 너무나 쉽기 때문이다.

* 공략 키워드 : Big Data, Hadoop

Big Data 처리가 가능하고 MapReduce도 가능하다!

HBase는 Hadoop의 ecosystem으로 분류된다. 요즘같이 Big Data = Hadoop이라는 관계에 대해서 의문을 갖는 사람들이 많지 않다는 것을 이용하면 된다. 사실 Big Data + 대용량 데이터 처리는 HBase뿐만 아니라 다른 NoSQL Database들도 가능하다. 물론 기존에 많이 사용하던 RDBMS도 Sharding 등을 통해서 충분히 대용량 처리를 할 수 있다.



HBase는 대용량 데이터의 읽기, 쓰기 뿐만 아니라 MapReduce를 통한 처리도 가능하다. 이것을 교묘히 이용하면 성공할 수 있는 확률이 높아지게 된다. 공략의 방식은 다음과 같다.

  1. Big Data = Hadoop라는 관계를 강조한다.
  2. Hadoop의 MapReduce를 통해서 Big Data 처리를 한다는 것을 슬쩍이라도 얘기해야 한다. 이때 Hadoop이란 것을 강조해야 한다.
  3. HBase는 Hadoop의 ecosystem이라고 한다.
  4. 간단한 몇가지 정보를 흘려둔 후 경영진이 Big Data = Hadoop = HBase라는 공식을 머리속에 그려낼 수 있도록 시간을 준다.

데이터에 대한 MapReduce를 지원하는 Database가 HBase뿐만은 아니다. HBase와 비교되는 Cassandra도 MapReduce가 가능하다. 하지만 Hadoop의 ecosystem으로 분류되는 HBase에서 Hadoop의 MapReduce를 처리한다고 하면 다른 NoSQL Database보다 더 잘 할 수 있을 것 같은 기분이 든다.

* 공략 키워드 : HBase는 Hadoop의 ecosystem!

CAP이론에서 CP 모델을 가진다.

HBase는 데이터의 Consistency를 보장한다. 다시 말하면 HBase에 쓰기를 한 후 바로 다른 노드에서 읽기를 한 경우 가장 최근에 쓰여진 데이터를 읽는다는 것이 보장된다.



CAP이론을 들먹이면서 자주 비교되는 것이 Cassandra이다. HBase를 경영진에게 설득해야 하는 입장에서 Cassandra는 눈에 가시같은 존재이다. 만약 경영진이 Cassandra에 대해서 언급한다면 좀 치사한 방법이기는 하지만 Cassandra를 깎아내려서 HBase의 존재를 부각시키는 방법이 가장 좋다.

Cassandra는 CAP 이론에서 AP의 모델을 가진다. 극단적으로 말하면 Cassandra는 데이터의 Consistency를 보장하지 못한다. 그렇기 때문에 데이터의 Consistency가 필요한 경우라면 HBase를 사용하는 것이 더 유리하다고 주장한다.

데이터를 다루는 대부분의 경우에는 Consistency는 매우 중요한 속성 중 하나이다. 만약 Cassandra가 Consistency가 약하다는 말을 들으면 경영진도 쉽게 포기하게 될 것이다. 그렇기 때문에 HBase를 사용해야 한다고 경영진을 설득할 때에는 무조건 Consistency를 강조해야 한다. 

만약 경영진이 Cassandra에 대해서 좀 더 자세하게 물어보는 경우 대충 얼버무리면 된다. 만약 Cassandra가 읽기, 쓰기에 대해서 각각 Consistency Level을 설정하는 것이 가능하고 Consistency Level중 ALL은 클러스터 내의 모든 노드에 row를 저장한다는 것까지 경영진이 알게되면 문제가 복잡해지게 되니 조심해야 한다. 만약 경영진이 미리 Cassandra에 대해서 조사한 후 Consistency Level = ALL에 대해서 얘기하면 그럴 경우 하나의 노드가 반응하지 않을 경우 읽기/쓰기가 실패하게 되는 단점이 있다고 얘기해주면 된다.

그리고 Google의 BigTable도 CP 모델을 가진다고 얘기하면 HBase가 더 좋아보일 수도 있다.

* 공략 키워드 : Consistency 보장.

Automatic Failover를 제공한다.

HBase에서 데이터를 관리해주는 역할을 하는 것은 Region Server이다. 이 Region Server가 죽게되면 해당 Region Server의 역할을 다른 Region Server들로 재분배하여 처리할 수 있도록 한다. Failover기능은 다른 NoSQL들도 많이 가지고 있고 요즘에는 서비스를 운영하는데 필수이면서 당연한 기능으로 생각되기 때문에 Failover기능을 가지고 설득을 한다고 해서 큰 효과를 볼 수는 없다.

하지만 얼마나 잘 포장하느냐에 따라서 HBase데이터는 HDFS에 저장되고 Region Server는 데이터 관리만을 해주기 때문에 Region Server의 Automatic Failover 기능과 HDFS의 Replication에 의해서 데이터가 2중으로 보호되는것만 같은 착각을 하도록 할 수 있다. 하지만 사실은 HBase는 HBase의 시스템 뿐만 아니라 HDFS의 시스템 문제에도 영향을 받을 수 있기 때문에 너무 과대포장했다가 오히려 나중에 낭패를 볼 수도 있으니 주의해야 한다.

* 공략 키워드 : Region Server의 Automatic Failover를 제공.

테이블을 자동으로 Sharding할 수 있다.

데이터가 많아지면 테이블 관리도 신경써지게 된다. HBase는 테이블을 자동으로 Sharding하기 때문에 하나의 테이블에 많은 데이터가 들어가도 문제 없이 처리할 수 있다. 설득을 할 때 주요 공략 포인트는 다음과 같다.

  1. 서비스를 운영하면 점점 많은 데이터가 쌓이게 된다. (데이터 관리에 대한 불안감을 조성)
  2. MySQL등은 데이터가 많이 쌓이면 속도도 느려지고 테이블 관리도 어렵다. (단, 엔지니어 출신 경영진한테는 조심해야 한다. 그런 경영진은 RDBMS도 적절한 인덱스 관리와 Sharding을 하면 된다는 것을 알고있을 수 있다.)
  3. HBase는 자동으로 테이블의 데이터 크기를 관리할 수 있다. (꼭 HBase라고 해야 한다. 그래야 다른 NoSQL에 대해서 찾아보지 않는다. 경영진이 다른 NoSQL도 Sharding이 가능한지에 대해서 찾아보면 설득할 때 불리해질 수 있다.)
  4. Sharding이라는 단어는 가급적이면 사용하는 것이 좋다. 만약 경영진이 Sharding의 뜻을 물어보면 "데이터 분산 처리"라고 애매하게 답해줘야 한다.
그럴 일은 없지만 혹시라도 경영진이 어떤 방식으로 자동 Sharding을 하느냐에 대해서 물어본다면 절대 방심해서는 안된다. 자동 Sharding 방식에 대해서 물어보는 경우는 경영진이 어느정도 분산 관련 지식이 있다는 것을 의미한다. HBase는 rowkey 순서에 따른 Sharding을 하기 때문에 효율적인 분산을 위해서는 rowkey 디자인이 매우 중요하다는 사실은 경영진이 모르도록 하는 것이 더 좋을 수도 있다. 나중을 위한 보험 정도로 생각하면 된다.

* 공략 키워드 : 자동 Sharding, rowkey 순서에 따른 Sharding

자바 API를 사용해서 쉽게 개발이 가능하다. Thrift, Avro, Restful API도 제공한다.

자바 API는 다른 NoSQL들도 많이 제공하기 때문에 그쪽에 무게를 둬서 설득하면 안된다. Thrift에 무게를 두는 것이 설득을 더 쉽게 만들 수 있다. 다른 NoSQL들도 Thrift를 제공하지만 다음과 같이 설득해볼 수 있다.

  1. Thrift는 페이스북에서 개발해서 사용하고 있는 통신방식이라고 설명한다. 페이스북이라는 단어를 사용하면 경영진은 알 수 없는 신뢰감을 얻게된다.
  2. Thrift는 현재 Apache 프로젝트에 등록되어있다고 한다.
  3. HBase도 Apache 프로젝트라고 한다.
  4. 둘 다 Apache 프로젝트이기 때문에 둘 간에는 뭔가 더 특별한 것이 있을꺼라고 경영진이 착각할 시간을 준다.
주의할 점은 Cassandra도 Apache 프로젝트라는 얘기는 절대 해서는 안된다. 

* 공략 키워드 : 사용하기 쉬운 자바 API, Thrift, Avro, Restful API 제공


참고자료








신고
Posted by micacute
TAG ,