행복한디벨로퍼

스파크(Spark) 스트리밍 성능(Processing Time) 개선

실시간 관심사 타겟팅 애플리케이션에서 더 많은 관심사 모수를 뽑아도록 작업한 로직을 배포하게되었다.

실시간 스파크 어플리케이션을 배포할 때 가장 유의해야 하는 것은 추가된 기능으로 인해 마이크로배치형태로 처리되는 작업들의 

수행시간이 현저히 길어지지 않았는가 모니터링하고 체크하는 것이다.

내가 이번에 추가한 로직도 성능에 영향을 미칠 것이라고 판단되어 배포전 실시간 스트리밍 처리 현황과 배포 후를 비교해보았다.

[ 새로운 기능이 추가되기 전 ] 

[ 새로운 기능이 추가된 후 ]

새로운 기능이 추가되기 전과 후의 차이를 보게되면 Processing Time이 더 길어짐에 따라서 Total Delay가 길어지는 것을 확인해 볼 수 있었다.

이 어플리케이션은 1분 단위의 마이크로배치로 돌아가기 때문에 배치간 작업은 1분 이내에 마무리가 되어야 그 다음 배치에 

영향을 미치지 않는다. 따라서 해당 어플리케이션을 튜닝해야하는 이슈가 있었고 어떻게 성능을 개선하면 좋을지 생각을 하다가 

기존 executor가 5개로 동작을 하고 있었는데 클러스터의 가용 vcore개수가 많음에도 불구하고 너무나도 적은 개수의 

executor만을 사용하여 실시간 작업을 처리하고 있었다.

이에 spark-submit 실행시 executor number개수를 5개에서 10개로 늘려주고 확인해보았다.

[ 성능 개선 후 (executor 개수(5->10) 조절) ]

조절 후 이미지를 보면 알겠지만 Processing Time이 반으로 줄어들면서 Total Delay부분도 줄어들었고 Scheduling Delay가 발생하지 

않는 것을 확인할 수 있었다. 어떻게 보면 되게 단순하게 어플리케이션의 성능을 개선했지만 스파크의 동작방식에 대한 이해와 작동되는 

클러스터에 대한 이해없이는 쉽게 나올 수 없는 해결책이었다고 생각이든다. 

그럼 executor 개수를 더 늘려주면 더 좋을까? 라고 누군가 묻는다면 불필요하게 executor의 개수만 무작정 늘린다고 해서 좋다고 

말할 수는 없다. 어플리케이션에 따라 프로세스를 처리하는데 적절한 executor의 개수가 존재한다고 생각이 들고 

스트리밍 어플리케이션은 그 기준은 Scheduling Delay가 발생하지 않는 선에서의 개수를 맞추어주면 된다. 

불필요하게 많은 executor는 너무 적은 데이터를 처리하게 되고 클러스터 전체로 보았을 때는 불필요한 오버헤드가 많이 발생할 수 있다. 

또한 executor들간 broadcast시에도 더 많은 네트워크I/O를 초래할 수 있기 때문에 무작정 executor를 많이 설정해 사용하는 것이 

좋은 방법만은 아니다.

또한 한가지 팁은 executor의 개수를 spark-submit시 명시적으로 주어 활용한다면 

--conf에 spark.yarn.max.executor.failures 해당 옵션을 주어서 사용하도록 하자.

ex ) executor 개수를 5개로 할당했으면 --conf "spark.yarn.max.executor.failures=10"으로 주어 설정해주도록 하자.

Worker만 무작정 늘린다고 Performance가 향상되는 것은 아니다^^

하둡1.0과 하둡2.0의 차이는 YARN으로 인해 많은 부분이 변화되었다.

그 차이에 대해서 알아보도록 하자.

[ 아키텍처의 변화 ]

[ 하둡 1.0과 2.0에서 리소스 관리 차이 ]

하둡 1.0에서 맵리듀스를 실행할 때는 슬롯 단위로 맵/리듀스 태스크 갯수를 관리했다.따라서 맵퍼는 모두 동작하는데 리듀서는 놀고 있거나 반대의 경우로 인해 클러스터 전체 사용률이 낮았다.

하지만 하둡 2.0에서 YARN(얀)이 도입되면서 슬롯이 아닌 컨테이너 단위로 리소스를 할당하게 되었다. 얀의 리소스 매니저는 전체 클러스터의 리소스 정보를 토대로 할당 가능한 컨테이너 개수를 계산하며, 맵리듀스는 필요한 컨테이너들을 할당 받아서 맵리듀스 태스크를 실행하게 된다. 

이 때 컨테이너 개수와 맵과 리듀스 태스크의 관계는 1:1의 관계가 아니며, 맵과 리듀스 태스크는 상황에 따라서 하나 이상의 컨테이너를 실행할 수도 있다. 그래서 관리자는 전체 클러스터의 리소스 상황과 얀에서 실행하는 잡들의 워크로드를 고려하여 리소스 설정을 진행해야 한다.

[ YARN의 도입으로 JobTracker의 역할이 Resource Manager와 Application Master로 분리 ] 

하둡 1.0에서는 JobTracker(잡트래커)가 클러스터 리소스 관리 및 어플리케이션 스케쥴링 등을 모두 담당했었다.

하지만 하둡 2.0에서는 클러스터마다 Application Master(어플리케이션 마스터)가 존재하고 각 서버마다 Node Manager(노드 매니저)가 할당되어 있고 리소스관리는 Resource Manager(리소스 매니저)가 어플리케이션 수행 및 스케쥴링 관리는 Application Master(어플리케이션 마스터)로 역할이 분리되어 운영된다.

[ Spark 등 분산처리 환경 지원 ]

하둡의 맵/리듀스 작업보다 성능이 훨씬 개선된 SPARK 및 분산처리 프레임워크를 사용할 수 있게 되었다. 스파크는 배치 처리 작업에 있어서 맵리듀스보다 10배정도 빠르며 인메모리 분석에서 100배나 빠르다고 알려져 있다.