jaso extends j2ee

Neptune에서 put 연산은 일단 메모리에 저장된 다음 메모리가 일정 크기 이상 커지게 되면 파일시스템(분산파일시스템, hadoop 등)으로 저장하는 구조를 가지고 있습니다.
당연한 결과이지만 다음과 같은 상황을 발견하였습니다.


당연하겠죠...
문제는 파일시스템으로 저장하는 bandwidth가 얼마인지 알아야지만 put에 대한 bandwidth를 조절할 수 있다는 겁니다. 단순히 파일시스템의 I/O를 측정하면 될 것 같지만 좀 더 복잡한 문제가 있습니다.
Neptune의 경우 하나의 파일 I/O가 많이 발생하는 부분은 다음 4가지 상황입니다.
1. 메모리 -> 파일시스템(Minor Compaction)
2. 여러개의 파일을 하나로 Merge(Major Compaction)
3. 큰 파일을 두개로 분리(Split)
4. put 요청된 commit 로그 저장

여기서 메모리 문제만 보면 Minor Compaction에 가중치를 두어 수행하게 할 수 있겠지만 이럴 경우 Split이나 Major Compaction이 더디게 수행되고 이렇게 되면 get 성능 저하, Split 시간이 더 많이 소요되는 등 또 다른 문제점이 발생할 수 있습니다.
그리고 put bandwidth의 경우 사용자가 저장하는 데이터의 크기에 따라 다양하게 나타날 수 있습니다. 하나의 Cell Value내에 100 byte 저장할 때와 100K 저장할 때 TabletServer요청되는 데이터양은 크게 차이가 납니다.
이런 모든 것을 고려하여 TabletServer 파라미터들을 설정하여야 하는데 관련 파라미터는 다음과 같습니다.

1. tabletServer.maxMinorCompactionThread
   하나의 TabletServer에서 동시에 수행할 수 있는 Minor Compaction 갯수
   많으면 메모리를 더 빨리 확보할 수 있지만 파일시스템의 부하로 인해 일정 수준이상 늘릴 경우 더 느려질수 있음

2. tabletServer.maxMajorCompactionThread
   하나의 TabletServer에서 동시에 수행할 수 있는 Major Compaction 갯수
   neptunemaster.iolock.ratio 값과 연동되어 동작함.

3. tabletServer.maxSplitThread
   하나의 TabletServer에서 동시에 수행할 수 있는 Split 갯수
   neptunemaster.iolock.ratio 값과 연동되어 동작함.

4. tabletServer.put.heavyMemoryAcceptRate
   TabletServer의 heap 메모리가 일정 수준이하로 떨어질 경우 put 요청을 skip 시키고 클라이언트(NTable)이 재시도를 한다. 모든 요청을 skip 시키는 것이 아니라 이 값에 따라 일정한 비율로 skip 시킨다.

5. tabletServer.put.splitingAcceptRate
   Tablet이 split 중인 경우에는 minor compaction 작업이 수행되지 않기 때문에 너무 많은 put 요청이 오게되면 메모리 부족 현상이 발생할 수 있다. Tablet split인 경우  put 요청을 skip 시키고 클라이언트(NTable)이 재시도를 한다. 이때 NTable에서 sleep 하는 시간(ms).
  값이 크면 TabletServer에 부하는 줄어들지만 put의 성능이 저하된다.

6. tabletServer.heavyMemoryPutSleep
tabletServer.put.heavyMemoryAcceptRate에 의해 skip 된 put 요청은 NTable에서 일정 시간 sleep 후 다시 재시도한다. 이 값은 NTable에서 sleep 하는 시간(ms)을 나타낸다. 값이 크면 TabletServer에 부하는 줄어들지만 put의 성능이 저하된다.

7. tabletServer.tabletSplitPutSleep
tabletServer.put.splitingAcceptRate에 의해 skip 된 put 요청은 NTable에서 일정 시간 sleep 후 다시 재시도한다. 이 값은 NTable에서 sleep 하는 시간(ms)을 나타낸다. 값이 크면 TabletServer에 부하는 줄어들지만 put의 성능이 저하된다.

8. neptunemaster.iolock.ratio
전체 클러스터의 split/major compaction의 부하 수준을 결정한다. TabletServer가 하나 추가될 때 마다 클러스터 전체에서 동시에 수행할 수 있는 Split, Major Compaction Thread는 이 수치의 배수만큼 증가한다. 예를 들어 ratio가 2로 설정되어 있고 전체 TabletServer의 대수가 10대인 경우 동시에 수행할 수 있는 Thread는 20이 된다. 이렇게 제한을 두는 이유는 maxSplitThread 등의 값이 5로 설정되어 있고 TabletServer가 10대이면 50개의 Thread가 파일시스템으로 I/O 요청을 하게 되는데 이렇게 되면 파일시스템 측에 병목이 발생하여 commit 로그 저장, Minor compaction 수행에도 영향을 미치게 된다. 따라서 적절한 수준으로 파일시스템의 부하를 조정하기 위해 ratio를 설정 가능하도록 하였다.
이 값이 작으면 파일시스템 I/O 부하는 줄어들지만 하나의 Tablet의 크기가 커져 Split하는데 시간이 더 많이 소요될 수 있으며 Tablet의 데이터 파일의 갯수가 많아져 get 성능이 나빠지면 merge 수행하는데에도 시간이 더 많이 소요된다.

9. split.majorcompaction.ratio
neptunemaster.iolock.ratio에 의해 설정된 값 중 Split과 Major Compaction의 비율. 예를 들어 neptunemaster.iolock.ratio의 값에 의해 동시에 수행할 수 있는 갯수가 10인 경우 split.majorcompaction.ratio 값이 0.7 이면 7개는 Split이 3개는Major Compaction을 수행한다. 이 수치는 Split과 Major Compaction이 동시에 스케쥴링 되었을 때만 반영되고 Split만 스케쥴링되었을 경우 10개를 모두 Split에 할당한다.

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

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

Posted by 김형준