jaso extends j2ee

Hbase 0.19에 대한 성능 테스트 내용을 공유합니다. 아직 공식적으로 릴리즈 되지 않았기 때문에 현재 subversion에 있는 trunk를 다운로드 받아 테스트를 수행했습니다. hadoop은 0.19를 설치 했습니다.
테스트 환경은 1 + 9 환경이고 테스트 결과는 다음 URL에 있습니다.

http://code.google.com/p/openneptune/wiki/Performance

지난 금요일 저녁에 첫 테스트를 결과를 보고 순간 당황했습니다. neptune과 비교할 수 없을 정도로 성능이 좋았기 때문이죠..ㅋㅋㅋ 이런 정도의 성능이면 neptune은 Hbase와 경쟁할 수 없다라는 생각이 들었죠. 아무리 생각해도 write에 8000정도 나오는 것이
의심이 들었습니다. 그래서 PerformanceEvaluation 소스를 좀 봤더니 다음과 같이 구현되어 있었습니다.
  this.table.setAutoFlush(false);
  this.table.setWriteBufferSize(1024*1024*12);

의미는 클라이언트 API인 HTable 객체에서 commit() 요청시 바로 서버로 보내지 않고 client 측 cache에 저장하는데 client cache의 크기를 12MB로 설정한다는 것입니다. commit() 후에도 서버에 저장되지 않고 클라이언트 메모리에 남아 있는거죠... 강제로 flushCommits()를 호출하거나 cache가 가득차게 되면 한번에 서버로 전송하는 방식으로 처리하고 있습니다. 이렇게 할 경우 매번 RPC를 호출할 필요가 없기 때문에 좋은 성능을 낼 수 있는 거죠... 이 방법이 잘못되었다가 보다는 성능 테스트에 이런 방법을 사용했다는 것이 조금은 의도적이지 않나 생각해보니다. 기본적으로 AutoFlush 모드는 false 이거든요... 개발자가 저 수치만 믿고 개발했는데 속도가 저 정도의 속도가 안나올 수 있다는 거죠... 그리고 client 장애가 발생할 경우 commit()에서 정상 처리되었다고 return 받은 데이터 조차도 저장이 되지 않는 상황이 발생합니다.
이 기능은 임시성 데이터를 저장하는 경우에 활용하면 좋을 것으로 생각됩니다. 좋은 아이디어라서 neptune에 곧 적용할 예정입니다.
cache를 사용하지 않게 setAutoFlush(true)로 하고 테스트 한 경우에는 write가 2864 tps가 나옵니다. 기존과 비교하면 다소 성능 향상은 되었지만 8300과 비교하면 엄청난 차이죠. neptune의 경우 change log까지 모두 완벽하게 저장하기 때문에 데이터 유실이 전혀 없이 구현하면서도 2000 tps 정도가 나옵니다. 단순 수치적으로 보면 2/3 수준이지만 데이터의 안정성적인 측면이 강조됨면서 성능이 약간 희생된거죠..

read의 경우에는 성능을 향상을 위해 데이터 파일을 cache 하고 있습니다. 앞의 글에서도 언급했듯이 hadoop의 최대 성능은 높아야 RPC 오버헤드가 없다는 가정하에 1000 tps 미만입니다. hbase read의 경우 cache를 사용하면 1600 ~ 2000 tps 정도의 성능이 나옵니다. 이것은 cache hit 가 상당히 높은 경우입니다. 테스트 프로그램의 경우 1000 byte row를 약 1GB 저장하는 것이기 때문에 전체 데이터가 1GB 입니다. 이것을 9대의 RegionServer가 나누어서 서비스 하기 때문에 대부분의 파일 데이터를 cache에 올릴 수 있습니다. 메모리 부족으로 인한 cache clear도 거의 발생하지 않고요...
실제 상황에서도 이렇게 될까요? 하나의 RegionServer가 100GB 정도의 데이터를 서비스할 경우 1GB 메모리 cache를 사용한다면 cache는 겨우 1%만 됩니다. 따라서 테스트에서 나온 수치보다 더 낮은 성능이 나오게 되겠죠.
Hbase와 비슷하게 neptune에도 cache를 적용해 보았습니다. 1900 정도로 비슷하게 나오고 있습니다.
이렇게 Hbase에 성능에 대해 자세하게 분석하고 난 다음에서 다소 안심이 되었습니다. 이 정도 성능 차이는 튜닝을 통해 충분히 커버 가능한 범위이기 때문이죠.
앞의 0.18 성능 테스트에서도 나타난 증상이지만 Region이 major compaction, split이 수행되지 않는 거는 동일하게 나타났습니다. 전체 Region이 250개 정도에서 멈추고 더 이상 split이 되지 않았습니다. 하나의 Region이 2GB가 되었는데도 split이 발생하지 않았습니다. 아직 정식 릴리즈가 아니라서 그럴 수도 있겠죠...

이상으로 테스트 삽질기를 마치며 만드는 사람입장에서는 자신이 만드는 것이 경쟁 제품보다 더 좋은 성능이 나오기를 바라는 것이 당연하지만 좀 더 신중하게 테스트 하지 않는 경우 함정에 빠질 수 있게 테스트 코드를 릴리즈 하는 것이 조금 씁쓸했습니다.
다시 목표 수준이 정해졌으니 열심히 열코(열라 코딩) 해야겠죠.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준