행복한디벨로퍼

스파크(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가 향상되는 것은 아니다^^

[ 자바성능튜닝교육 회고 ]

월요일(20171030), 화요일(20171031) 이틀간 회사내에서 '자바성능튜닝’에 대한 교육을 6시간에 걸쳐 수강하였다.

교육도 들었겠다 관련해서 간단히 들었던 내용과 생각을 정리해보려한다.

먼저 성능을 튜닝하기 위해서는 무작정 '튜닝할거야' 라고 달려드는게 아니다.

첫 번째로 튜닝을 하고자 하는 어플리케이션의 어떤 부분에서 병목이 발생하고 있는지 살펴볼 필요가 있다.

어떤 부분에서 병목이 발생하는지 발견했다면 튜닝을 하기전 요청에 대한 response time을 철저하게 체크하고 확인해보자.

추후 효율적으로 튜닝이 되었는지 확인을 위한 필수적인 부분이다.

일반적인 어플리케이션에서 병목이 발생하는 부분은 대부분 DB관련된 부분일 확률이 높다.

성능 튜닝에 있어서 기본은  throughput(처리량), response time(응답시간)이 척도가 될 수 있다.

먼저 throughput(처리량)의 경우 특정한 시간내에 얼마나 많은 transaction을 처리할 수 있느냐가 중요하다.

처리량은 보통 TPS, TPM, TPH로 표시한다.

일반적으로는 TPS를 가장 많이 사용하고 TPS는 높으면 높을 수록 좋다.

반면에 요청에 대한 response time(응답시간)은 당연히 짧으면 짧을 수록 좋다고 할 수 있다.

만약 성능측정툴(scouter, jmap, jvh)등을 통해서 어플리케이션 내부를 튜닝할 경우에는 실제로 

cpu를 가장 많이 사용하는 모듈(메소드, 라이브러리)을 확인하고 코드 개선이 필요하다.

응답시간을 가장 많이 잡아먹는 메소드를 먼저 선행 튜닝하도록 하자.

다음과 같은 경우는 당연히 a 메서드에 대한 튜닝을 진행하는게 어플리케이션 전체 효율을 높이는데 효과적일 것이다.

또한 어플리케이션 개발 초기에 특정 프레임워크를 사용할 경우 먼저 선행 성능 측정이 필요하다.

만약 어플리케이션의 특정 프레임워크의 버전을 올려 배포해야 하는 상황이라면 기능 개선 작업과 함께 

배포하여 테스트하는 것은 지양하는 것이 좋다. 실제로 문제가 발생했을 때 프레임워크 버전업으로 인한 문제인지

추가된 로직들에 의한 문제인지 확인이 힘들기 때문이다. 

만약 간단하게 서버에 떠있는 자바 인스턴스에 대한 모니터링이 필요하다면 jvmtop 을 사용하는 것을 추천한다.

생각보다 손쉽게 해당 인스턴스의 CPU점유 및 쓰레드, 내부에서 동작하고 있는 메서드들에 대한 정보를 확인할 수 있다.

https://github.com/patric-r/jvmtop

위의 내용 모두 중요하지만 가장 기본은 역시 코딩을 할 때 해당 코드가 어떻게 동작할지 어떻게 하면 메모리, cpu를 적게 사용할 수 있을지

고민하면서 효율적인 코드를 작성하는 것이다.

'좋은 코드가 좋은 시스템을 만든다’

MAC 터미널에서 혹시나 메이븐(maven)을 통해 빌드해야하는 경우가 있을 경우 메이븐(maven)을 설치해주어야 한다.

밑의 url에 들어가 tar.gz 파일을 다운받아서 압축을 풀어준다.

http://maven.apache.org/download.cgi

그 후 mvn 명령어로 손쉽게 메이븐(maven)을 사용하기 위해 환경변수를 설정해준다.

vi ~/.bash_profile

vi로 열어서 압축을 푼 곳의 디렉토리 위치를 설정해준다.

#path setting
export M2_HOME=/Users/nhnent/Documents/apache-maven-3.5.2   (본인의 압축 푼 경로에 맞게!!!)
export M2=$M2_HOME/bin
export PATH=$M2:$PATH

저장 후 설정 변경을 위해 다음 명령을 실행한다.

source ~/.bash_profile

실행 후 echo $PATH 를 해보면 본인의 PC에 설정된 path들의 리스트가 출력된다.

해당 리스트에 메이븐(maven) PATH가 정상적으로 추가되었다면 mvn -version을 통해 확인해 볼 수 있다.

mvn -version 명령을 내렸을 경우 이런 버전을 나타내는 stdout이 출력되지 않았다면 정상적으로 설치되지 않은 경우이기 떄문에

설치 경로 및 환경변수를 다시 한 번 확인이 필요하다.