jaso extends j2ee :: 오랜만에 hbase 성능 테스트

오랜만에 hbase 성능테스트를 하였습니다. 버전은 stable 버전으로 릴리즈된 0.20.6을 사용하였습니다.
이전에도 테스트를 수행했는데 이번에 테스트한 것과 같이 대량으로 데이터를 저장하는 테스트가 아닌 속도 위주의 테스트만 진행했었습니다. 이번에 테스트한 내용은 다음과 같습니다.
1. Hadoop/HBase
- Hadoop 0.20.2
- HBase: 0.20.6
- 서버: NameNode 1, DataNode 6, 각 서버에 TaskTracker, HBase Region Server 실행
- Region Server Max Heap: 4GB

2. 테스트 프로그램
- Map only로 32개의 map task가 각 서버에 6개씩 실행
- 한 MapTask에서 1000byte 1 row를 1GB 씩 저장
- 전체 1000개의 Task 수행(약 1TB 저장 테스트)

3. 테스트 결과
- 전체 작업 52% 진행 후 task kill됨
- 작업 kill 당시 Region 갯수: 4098, 서버당 약 680개
- kill 원인은 한건 put하는데 10분 이상 걸려 mapreduce 작업 타임아웃에 걸림
- 실행 시간 각 MapTask가 32개씩 병렬로 수행되는 구조이기 때문에 32개 * (1024 * 1024 * 1024)/1000 만큼의 갯수가 매번 32개 Task가 종료될때마다 저장됨 따라서 Hbase의 TPS(Transaction per Second) 는 다음과 같이 계산 가능
TPS = (32개 * (1024 * 1024 * 1024)/1000) / 32개 map task 실행시간

실행 시간은 hbase에 레코드가 많이 쌓일수록 많이 소요되어 있으며 다음과 같다.

hbase에 데이터가 없는 경우에는 약 7000 TPS 정도 나오지만 테이터 어느 정도 저장된 상태에서는 3000 ~ 4000 정도로 절반 이하로 떨어진다. 이 상태에서 계속해서 데이터가 입력되면 더 이상 데이터를 받아 줄 수 없는 상태가 된다.

4. 시사점
- 본 테스트의 결과는 6대의 hbase 클러스터로 어느 정도의 throughput을 낼 수 있는지 측정을 하는 것이 었다. 결론적으로는 약 5000 ~ 7000 정도의 TPS의 성능이 나오지만 이런 트래픽이 지속적으로 유입되는 경우에는 저장할 수 없다.
- 이런 증상은 cloudata(www.cloudata.org)도 거의 유사한데 원인은 관리하는 Region(Tablet)이 많아지면 그 만큼 메모리 관리와 디스크 저장에 오버헤드가 크기 때문이다. hadoop을 파일시스템으로 사용하는 경우 한번의 write가 세개의 서버에 I/O가 발생하기 때문에 오버헤드가 훨씬 더 크다고 할 수 있다.
- 솔루션 내부적으로 어떻게 잘 스케쥴링 하느냐가 관건인데 아직까지는 최적화가 많이 필요할 것으로 생각된다.
- 현재의 대안은 hadoop 클러스터와 hbase 클러스터의 크기를 조절하는 방법도 생각해 볼 수 있다. 예를 들어 hadoop을 30대에 설치 했다면 hbase는 1/3 정도인 10대의 서버에만 설치하는 것이다. 이렇게 함으로써 클러스터 전체의 I/O 부하를 줄이면 최소한 데이터가 입력되지 않는 상황은 발생하지 않을 것으로 예측된다. -> 실제 장비 부족으로 테스트를 수행하지는 않음

크리에이티브 커먼즈 라이센스