안녕하세요 제리정입니다.
이번 글에서는 hbase 환경을 구축하고 사용할때 겪을 수 있는 문제점 하나를 짚어 보려고 합니다.
최근에 기존 시스템에 대한 진단을 부탁받아 이것저것 확인중에 hotspotting이 발생한것을 확인하였습니다.

Hbase hotspotting 은 무엇인가?

hbase는 확장성을 보장하기 위해 multi region server 구성으로 동작합니다.
여러개 region server를 두고 적절히 데이터가 분산되어 있으면 확장성과 성능이 좋을수 밖에 없겠죠
반대로 특정 region server에 데이터가 몰리게 되고 이로 인해 쿼리 응답 성능도 당연히 안 좋아질 수 밖에 없겠죠

Hbase hotspotting은 왜 발생하는가?

잘못된 rowkey 설계로 인해 특정 region server로 데이터가 몰릴 수 있습니다. rowkey는 Hbase 전 클러스터에 분배될 수 있도록 적절히 설계 되어야 합니다.

왜 hotspotting문제를 당면하게 되었는가?

현재 구성된 노드는 적은 수의 region server로 구성되어 있습니다. timeseries데이터의 효율적인 적재 및 쿼리를 위해 opentsdb를 사용하고 있습니다. opentsdb는 rowkey를 생성하는 방식이 metric, timestamp, tag 로 구성됩니다.

opentsdb를 쓰는 경우 hotspotting문제를 어떻게 해결해야 하는가?

일반적으로 Hbase를 쓰는 경우라면 rowkey를 custom하게 생성하여 해결할 수 있습니다. 하지만 opentsdb의 경우 내부적으로 rowkey를 생성하고 있어 직접적인 해결은 불가능합니다.
opentsdb에서는 Hbase의 salting을 가이드 하고 있습니다. opentsdb 2.2.0부터 salting을 지원하기 때문에 해당 버전 이상 사용자에게는 try해볼 수 있는 옵션입니다.
salting option을 지정하면 기존 rowkey에 사용자가 지정한 bucket number를 다음과 같이 붙여 생성하여 cluster내에 고루 분산 될 수 있습니다. (++index % BUCKETS_NUMBER) + original_key
그러나 필자에게는 불행하게도 현재 구성된 서버에 저장된 데이터는 salting지원 되기 이전에 적재된 버전입니다.

Salting을 위한 migration 도전

migration할 방법이 아주 없는 것은 아닙니다. 별도로 table을 생성하고 pre-split과 salting이 가능하도록 옵션을 준 후 데이터를 이동 하는 방법이 있습니다. 다만 기존에 적재된 데이터의 볼륨이 적지 않기 때문에 고민중에 있습니다. 성공하게 되면 관련해서 글을 다시 써보겠습니다 :)