Introduction
일전에 Google MapReduce 논문을 리뷰한 적이 있었다. Google MapReduce는 Google 내부에서 사용되므로 large scale data processing이 필요한 많은 회사에서는 Hadoop MapReduce 및 ecosystem을 사용한다. 이 글에서는 MapReduce 작업을 수행할 때 성능 및 정합성 측면에서 고려하는 요소를 살펴보고자 한다.
Speculative Execution
/**
* Turn speculative execution on or off for this job.
*
* @param speculativeExecution <code>true</code> if speculative execution
* should be turned on, else <code>false</code>.
*/
public void setSpeculativeExecution(boolean speculativeExecution) {
ensureState(JobState.DEFINE);
conf.setSpeculativeExecution(speculativeExecution);
}
MapReduce job class의 설정으로서 speculative execution 옵션이 있다. 이 옵션은 MapReduce 수행 도중 특정 worker node에서 task 수행이 지연되고 있으면 해당 task와 동일한 backup task를 실행시키는 것을 허용한다.
이전에 다루었던 MapReduce 논문에서 3.6 Backup Tasks의 내용을 인용한다.
3.6 Backup Tasks
MapReduce의 수행시간을 길게하는 원인 중 하나로 straggler가 있다. straggler는 소수의 map task 혹은 reduce task를 수행하는 데 비정상적으로 긴 시간을 소요하는 machine을 의미한다. straggler는 여러 이유에서 발생한다. bad disk, scheduling으로 인한 CPU, memory, disk, network bandwidth 등 자원의 경합이 될 수 있다. 최근에 발견한 bug로는 processor cache를 disable 시키는 initialization code도 있었다.이러한 straggler로 인한 문제를 완화하기 위해서 general mechanism을 도입하였다. MapReduce operation이 수행 완료에 가까워지면 master는 남아있는 in-progress task에 대한 backup execution을 schedule 한다. 그러면 그 task는 primary 혹은 backup execution에서 완료하게 된다. 논문에서는 이 mechanism을 tune 하여 수 percent의 추가 자원을 사용하면서 수행 완료시간을 상당히 줄이는 결과를 얻었다.
논문의 5.4를 보면 알 수 있듯이 speculative execution을 활성화시킴으로써 부분 실패에 대한 작업 지연을 미리 예방하여 성능 향상에 기여한다. 하지만 언제나 speculative execution을 활성화시키는 것만이 능사는 아니다. 이는 MapReduce 작업의 실행 환경과 대상이 되는 application의 특성에 따라 달라질 수 있다.
엔터프라이즈 레벨 Hadoop cluster 환경에서는 다수의 MapReduce 작업이 한 cluster 내에서 실행된다. 각 MapReduce 작업 별 적당한 throughput과 예상 수행완료 시점을 정하기 위해서는 적정한 parallelism이 필요하며 map task, reduce task의 개수를 통해 parallelism을 정한다. 하지만 backup task가 실행되면 추가적인 병렬처리가 발생하게 되며 그에 따라 더 많은 resource, network를 사용하게 된다. 조금 더 통제된 리소스 관리가 필요하다면 speculative execution을 off 해야한다.
또한 application의 특성에 따라 달라질 수 있다. MapReduce 작업을 통해 application에 read/write를 수행하기도 하는데 만약 application에서 write에 대해 exactly-once semantic을 요구한다면 speculative execution을 반드시 off 해야한다. 만약 부분 실패에 따른 backup task가 생성되었는데 일정 기간 이후 원래 task가 처리되고 backup task 또한 처리된다면 중복 쓰기가 발생하기 때문이다.
Table Scan
MapReduce 작업 중에서는 기존의 storage를 읽어서 처리하는 경우도 있다. storage에 있는 다량의데이터를 읽기 때문에 해당 application이 가지고 있는 access pattern과 다르고, 또 MapReduce 작업으로 인해 큰 트래픽이 발생할 수도 있기 때문에 성능과 관련된 제어는 반드시 필요하다. 여기서 다루는 storage는 Hadoop HBase이지만 scan과 caching 및 batch와 관련된 제어는 다른 storage에도 비슷하게 적용될 수 있을 것이다.
Block Cache
HBase의 scan 설정 중에는 각 region 별 cache block을 제어하는 옵션이 있다. default로는 true로 되어있어 application 수행 중 빈번하게 read/write 되는 데이터에 효율적으로 접근할 수 있도록 한다. 하지만 MapReduce 작업을 위해서는 block cache를 비활성화 하는 것이 더 효율적일 수 있다. MapReduce 작업에서 full scan을 수행하여 storage 내 데이터 전체를 보는데 cache block이 적용되어 있으면 page fault가 과도하게 발생하여 오히려 performance degradation을 초래한다.
Caching vs Batch
HBase scan의 경우 한 row 당 한번에 RPC call이 발생한다. 이러한 방식은 크기가 작은 cell을 처리할 때 비효율적인데 cluster 내에서 빈번한 network transfer은 상당히 비싸기 때문이다. 따라서 한번의 RPC call을 통해 여러 row를 반환하는 것이 더 효율적일 수 있다.
HBase에서는 한번의 RPC을 통해 반환할 row, column 개수를 제어할 수 있다.
public Scan setCaching(int caching)public Scan setBatch(int batch)
높은 cache 비율은 더 신속한 scan을 제공하지만 memory를 더 사용하므로 주의해서 사용해야 한다.
아래는 HBase - The Definitive Guide 2nd 판에 있는 자료이며, RPC call 당 가져오는 row와 column 개수에 따라 총 몇번의 RPC call이 발생하는지 보여준다.
