출처: http://www.jaso.co.kr/241
Hadoop 성능 관련 참고 사항
본글은 개인적인 의견입니다.
Hadoop을 적용하기로 한 회사 또는 조직이라면 반드시 한대의 머신에서 수행했을 때와 속도 차이를 비교하는 테스트를 수행할 것입니다. 이때 가장 많이 사용하는 것이 grep 일 것입니다. 한대의 머신에서 수행하는 경우에는 주로 Linux에서 제공하는 "grep" 명령을 사용하고 hadoop에서는 examples에서 제공하는 grep 테스트 코드를 사용할 것입니다. 이렇게 할 경우 데이터 사이즈가 크지 않고(10GB 미만) 클러스터를 구성하는 머신이 작은 경우 큰 효과를 볼 수 없다는 쪽으로 결론 날 가능성이 많습니다.
원인은 다양한 곳에 있습니다. Hadoop의 examples에 있는 grep의 성능과 linux에 있는 grep의 명령의 성능 때문일 수도 있습니다. 자바의 IO 성능 문제 때문일 수도 있습니다. 이런 경우 성능 측정을 몇가지 튜닝 또는 확인해봐야 할 사항이 있습니다.
1. grep, IO 성능 차이
examples에서 제공하는 grep 프로그램을 사용하지 않고 Hadoop의 streamming 작업을 이용해서 Linux의 grep 명령이 Map으로 수행되도록 합니다.
2. 한 노드에 수행되는 Task의 수를 조정
mapred.tasktracker.map.tasks.maximum 값을 조정합니다.(defaul=2)
한 노드에 동시에 수행되는 Task의 갯수를 장비의 사양에 맞게 조정합니다.
3. Reduce의 갯수를 조정.
Reduce의 경우 Map의 결과를 모두 복사해야지만 수행되는데 이 시간이 생각보다 많이 걸립니다. 특히 Map의 갯수가 많고 Reduce가 1로 설정된 경우 복사 시간이 더많이 소요되는데 이 수치도 조정해 봅니다.
4. 마지막으로 가장 중요한 것인데 클러스터에 참여하는 노드수에 맞게 파라미터를 조정합니다.
Yahoo에서 Hadoop을 사용하는 클러스터는 주로 몇백대 이상으로 구성되어 있습니다.
따라서 운영관련 파라미터 값들도 이 수치에 맞춰져 있을 것입니다. 대표적인 수치가 JobTracker-TaskTracer간의 heartbeat 메세지 주기입니다. 이 수치는 TaskTracker가 Task를 할당받는 주기라고 할 수 있는데 기본적으로 5초로 설정되어 있고 변경할 수도 없습니다(소스를 변경하면 가능합니다.) 이것을 5초로 구성한 이유는 JobTracker의 부하 때문이라고 생각합니다. 이수치를 1초로 줄일 경우 1000대의 TaskTracker가 운영 중인 경우라면 JobTracker는 초당 1000개의 request를 받을 것입니다. 이 request 뿐만 아니라 Task의 status 정보 등 다양한 request까지 받아야 하는까 더 많겠죠.
일단 제 생각에는 장비의 증가에 따른 성능 개선 효과는 수행되는 애플리케이션과 Map-Reduce의 관계에 따라 조금씩 틀려지겠지만 최대 70% 정도 나오지 않을까 생각합니다. 예를 들어 장비를 10대 투입하면 1대 장비에서 수행했을 때 보다 10배가 빨라지는 것이 아니라 최대 7배 정도만 빨라진다는 거죠. 이런 수치에 너무 실망할 필요는 없습니다. 이런 성능 향상 수치가 선형적으로 증가하기 때문에 속도 향상이 더 필요하면 프로그램 변경 없이 단지 장비만 몇대 더 추가하면 문제를 해결할 수 있으니까요. 또 한대의 장비로 프로그램을 구성할 경우 데이터가 아주 큰 경우 여러 단계로 나누어 작업해야 할 경우가 많습니다. 이거 프로그램하기도 만만치 않고요. Hadoop을 사용할 경우에는 이런 고민은 많이 감소됩니다.
Hadoop 성능 관련 참고 사항
본글은 개인적인 의견입니다.
Hadoop을 적용하기로 한 회사 또는 조직이라면 반드시 한대의 머신에서 수행했을 때와 속도 차이를 비교하는 테스트를 수행할 것입니다. 이때 가장 많이 사용하는 것이 grep 일 것입니다. 한대의 머신에서 수행하는 경우에는 주로 Linux에서 제공하는 "grep" 명령을 사용하고 hadoop에서는 examples에서 제공하는 grep 테스트 코드를 사용할 것입니다. 이렇게 할 경우 데이터 사이즈가 크지 않고(10GB 미만) 클러스터를 구성하는 머신이 작은 경우 큰 효과를 볼 수 없다는 쪽으로 결론 날 가능성이 많습니다.
원인은 다양한 곳에 있습니다. Hadoop의 examples에 있는 grep의 성능과 linux에 있는 grep의 명령의 성능 때문일 수도 있습니다. 자바의 IO 성능 문제 때문일 수도 있습니다. 이런 경우 성능 측정을 몇가지 튜닝 또는 확인해봐야 할 사항이 있습니다.
1. grep, IO 성능 차이
examples에서 제공하는 grep 프로그램을 사용하지 않고 Hadoop의 streamming 작업을 이용해서 Linux의 grep 명령이 Map으로 수행되도록 합니다.
2. 한 노드에 수행되는 Task의 수를 조정
mapred.tasktracker.map.tasks.maximum 값을 조정합니다.(defaul=2)
한 노드에 동시에 수행되는 Task의 갯수를 장비의 사양에 맞게 조정합니다.
3. Reduce의 갯수를 조정.
Reduce의 경우 Map의 결과를 모두 복사해야지만 수행되는데 이 시간이 생각보다 많이 걸립니다. 특히 Map의 갯수가 많고 Reduce가 1로 설정된 경우 복사 시간이 더많이 소요되는데 이 수치도 조정해 봅니다.
4. 마지막으로 가장 중요한 것인데 클러스터에 참여하는 노드수에 맞게 파라미터를 조정합니다.
Yahoo에서 Hadoop을 사용하는 클러스터는 주로 몇백대 이상으로 구성되어 있습니다.
따라서 운영관련 파라미터 값들도 이 수치에 맞춰져 있을 것입니다. 대표적인 수치가 JobTracker-TaskTracer간의 heartbeat 메세지 주기입니다. 이 수치는 TaskTracker가 Task를 할당받는 주기라고 할 수 있는데 기본적으로 5초로 설정되어 있고 변경할 수도 없습니다(소스를 변경하면 가능합니다.) 이것을 5초로 구성한 이유는 JobTracker의 부하 때문이라고 생각합니다. 이수치를 1초로 줄일 경우 1000대의 TaskTracker가 운영 중인 경우라면 JobTracker는 초당 1000개의 request를 받을 것입니다. 이 request 뿐만 아니라 Task의 status 정보 등 다양한 request까지 받아야 하는까 더 많겠죠.
일단 제 생각에는 장비의 증가에 따른 성능 개선 효과는 수행되는 애플리케이션과 Map-Reduce의 관계에 따라 조금씩 틀려지겠지만 최대 70% 정도 나오지 않을까 생각합니다. 예를 들어 장비를 10대 투입하면 1대 장비에서 수행했을 때 보다 10배가 빨라지는 것이 아니라 최대 7배 정도만 빨라진다는 거죠. 이런 수치에 너무 실망할 필요는 없습니다. 이런 성능 향상 수치가 선형적으로 증가하기 때문에 속도 향상이 더 필요하면 프로그램 변경 없이 단지 장비만 몇대 더 추가하면 문제를 해결할 수 있으니까요. 또 한대의 장비로 프로그램을 구성할 경우 데이터가 아주 큰 경우 여러 단계로 나누어 작업해야 할 경우가 많습니다. 이거 프로그램하기도 만만치 않고요. Hadoop을 사용할 경우에는 이런 고민은 많이 감소됩니다.
