Spark Yarn Cluster vs Spark Mesos Cluster (vs 기타 다양한 모드) : [첫번째] 수행성능 및 활용성 비교

Spark Yarn Cluster 모드와 Spark Mesos Cluster 모드의 성능 비교를 하기에 앞서.....
Spark 를 여러 모드로 사용해본 기억을 더듬어 보았다..대략 이정도...

1. Spark + Shark + parquet 
2. Spark + Shark
3. Spark + Tachyon + parquet
4. Spark + Shark + Tachyon
5. Spark + Tachyon + parquet
6. Spark + Tachyon
7. Spark Stand Alone Cluster
8. Spark Yarn Cluster
1. Yarn Client Mode
2. Yarn Cluster Mode
9. Spark Mesos Cluster

[1~2번 조합에 대하여..]

초창기에 실험했던 조합이다. 2~3년전인가... spark 가 0.6~0.7 요정도였던 시기였던 듯..
그때는 Scala 가 익숙치 않았었고, Spark가 지원하는 세세한 라이브러리들의 기능들이 빈약해서, SQL on Hadoop 용도로의 활용 에만 꼳혀 있었던 터라...Shark 를 써보려고 무던히 애를 썻었다.

-> [결론] Shark 쪽에 Error 가 너무 많아서.. Production 화 하지는 못했고, Adhoc 용도로만 사용했었다. Parquet 파일포맷과의 호환성도 최악이었다. 요즘은 조금 상황이 다르지만, 당시에는 버전업이 자주 되었고, 버전업 때마다 하위 호환성은 최악이었으며, 타 Legacy 와의 Compatibility 이슈가 매우 빈번하였다.

[3~6번 조합에 대하여..]

-> Tachyon 은 메모리 기반의 분산 NFS 형태로, Parquet 포맷 원천 HDFS 상 파일을 De-Normalize 하여 Plain 포맷으로 올려놓고(마치 DW와 Mart 의 조합처럼...), 빠르게 읽고 쓰고 하는 용도로 사용했었고, 꽤 성능이 우수하였다. HDFS 상의 Parquet 보다, Tachyon 상의 PLAIN TSV 포맷 텍스트 파일의 성능이 더 좋았으며, NFS 처럼 마운트가 가능하여, Legacy 와의 호환성도 매우 좋았다.

-> [결론] 이 시점 부터 월배치 수행 정도로 조금씩 Production에서도 활용하기 시작.. 여전히 약간 불안...일배치를 돌릴 정도로 안정적이진 못했음. ( 버전이 아직 1.0되기 전 시점인지라..)

[7~9번 조합에 대하여..]

-> 1.0 버전 이상이 되면서, 안정성과 SQL 자체 지원. 그리고, 다양한 특화 라이브러리 자체 지원등 여러가지 활용성이 좋아졌고, 드디어 Production 에 사용하기 시작했다.
-> 작년 중순부터였던 듯..

-> [결론] 전반적으로 Spark Stand Alone Cluster 모드가 테스트 시점에는 가장 쉽고, 성능도 단일 프로세스를 Serial 하게 쓸때는 나름 빠르게 나온다. Adhoc 분석 시스템일때는 이 모드로 쭉 써도 무방할듯. 그러나, 프로덕션 환경에서 동시에 병렬 수행되는 Spark  Job 이 5~6개 이상일 정도로 활용성이 증가 된 환경에서는, Stand Alone 모드로 사용이 불가능에 가깝다. 즉, 이 시점부터 Spark Yarn Mode 로 사용할지, Mesos Mode 로 사용할지 고민에 빠지게 된다....

1. 실험환경
1. HW 및 데이타
1. 실험에 사용된 Data 는 수TB 이상의 데이타 이며, TSV 포맷이다. 두 시스템에서 사용된 HW는 100% 동일한 HW이다. 
2. 버전
1. Hadoop 2.7.1
2. Spark 1.4.1
3. Mesos 0.22.1
3. Business Logic 구현 언어
1. Scala
2. Spark Yarn Mode vs Spark Mesos Mode 성능 비교 
1. CPU & Memory 자원을 거의 쓰지 않고, Disk IO 와 Network IO 를 극단적으로 많이 쓰는 Business Logic 수행.


1. mesos cluster (FAIR  모드)



1. 605초 걸렸다. (2차 시도에서도 606초)
2. 물론 mesos 모드에서는 Fair 모드 여부와 Fine Grain 여부 등등 성능과 좌우되는 다양한 옵션이 존재하긴 하지만...다소 느리지만 안정적인 General 옵션으로 수행하였음.
2. yarn client 모드

1. 219초 무려 3배 가까이 빠르다. (2차 시도에서도 216초)
3. yarn cluster 모드

1. 225초. Client 모드보다 살짝 느리지만...비슷한 수준. (2차 시도에서도 221초)
2. CPU 와 Memory 를 많이 쓰는 Group By & Sort & Aggregation 로직이 포함 된 Business Logic 수행.
1. mesos cluster 모드

1. 29초 걸렸다. (2차 시도는 30초)
2. yarn client 모드

1. 1차시도 57초. 2차 시도 59초. 결과는 Mesos 의 그것과 동일.
2. 오홋....드디어 Mesos 가 저력을 발휘... Mesos 가 2배 정도 빠름. 다시말하여, Yarn Client 모드는 Mesos 보다 2배 정도 느렸다.
3. yarn cluster 모드

1. 61초.
2. 여전히 yarn client 보다 3~4초 느리고. mesos 보다 2배 느리다..
3. 결론
1. Disk 와 Network 만 극단적으로 사용하고 CPU 나 Memory를 거의 쓰지 않는 극단적인 로직에선 Yarn이 성능이 좋았다. 그 이유는 Yarn 은 HDFS 에서 바로 연산을 하기 때문일 것이다. 
2. 반면, Mesos Layer 가 추가 된 아키텍처에서는 동일 머신에 Mesos Cluster 가 있음에도 불구하고, Mesos 의 Memory Cache Layer 로 다시한번 Data 셔플이 일어나면서 Over Head 가 한단계 더 있어서 일거라 예상이 된다.
3. 실제, tmp 디렉토리에 Mesos 쪽에서 남기는 셔플된 데이타들이 꽤 된다. 
4. 그러나, IO 만 극단적으로 사용하는 Business Logic 은 극히 드물다. 사실 우리의 경우 그런류의 배치는 50개 중에 1개가 있을까 말까이다... 대부분은 컬럼 한두개 이상으로 Partition 되도록 Directory 정책을 Collection 시점에 적용하고 있어, Full Data 로딩이 거의 없고, Full Data 로딩을 하는 경우에도 Filter 로직으로 셔플은 일어나지 않고, N대의 분산 머신에서 RDD 자체에 로딩을 하지 않도록(mesos tmp 에 file block 들이 쌓이지 않도록), 데이타 로딩 시점에 제한 로직을 가하고 있다. (다 로딩하고 SparkSQL 에서 where 로 데이타를 줄이거나 하진 않는다는 의미이다..)
5. 대부분의 경우 CPU와 Memory를 많이 먹는 Group By Aggregation 로직이 많은데, 이 경우는 역시 Mesos 가 2배 정도 빠른 성능을 보여주었다. ( Yarn 이 설치된 동일 HW에 Mesos 가 구동되었고, Yarn으로 할때는 Mesos 데몬을 내려주고 했어도 그렇다.)
6. 성능과는 다른 이야기 이지만, Mesos 의 장점은 좀더 있다.. 바로 요런거...
1. Yarn 모드로 spark submit 할때는 core 사용갯수. executor 메모리, driver 메모리, executor 갯수를 실험적으로 매우 적절히 사용해야 한다. 
1. 물론 하드웨어가 핑핑 남아돌면, 다 충분히 크게 주면 되지 않냐는 반문이 있을 수 있다. 하지만, 메모리 등을 너무 크게 주면 GC 에서 예기치 못한 장애가 유발 될 수 있다. 
2. Spark 메뉴얼은 아래처럼 권고하고 있다.
3. Use more executors with smaller heap sizes. This will reduce the GC pressure within each JVM heap.  
4. 그러나 heap size 를 줄이는 경우 반대로 heap memory 부족 에러도 훨씬 자주 접한다.
5. 즉, 어느 한쪽으로 치우쳐도 안되고 job 에 따라 적절히 줘야 하는데...Job 이 수백개인 경우...그리고, 데이타 크기나 새로 인입되는 job 이 한달에 10개 이상이라고 한다면... 그러면, 적절히 최적화 해놓은 해당 값들이 다 틀어진다..TT
6. Mesos 는 그런거를 추상화 해준다.
7. Job 이 적을때랑 많을때 지가 알아서 cpu 코어 갯수나 memory 나 executor 의 갯수를 다이나믹하게 할당하고, job 이 좀 몰리면, 적절하게 분할 배분 수행시킨다.
8. 관리적인 측면에서 이건 매우 큰 이점이며, 약간 이상의 성능은 충분히 커버하고도 남을 정도로 중요한 요소이기도 하다. 특히 안정성 측면에서..
9. ( Yarn 도 이런 설정이 불가능 한것은 아니다.. Yarn Dynamic Resource Allocation 으로 검색 해 보시길.. 메커니즘은 약간 다른것 같다. 특히, excutor가 remove 될때 RDD 가 같이 사라지는 문제가 있어, 이 문제를 해결하기 위해 RDD  를 전달 하는 external shuffle 메커니즘이 Mesos  의 그것과 좀 다르다. 아키텍처 특성상.. Mesos 는 해당 Tier 자체가 공유 Memory 를 고려한 프레임워크 인지라 이런 공유 RDD 처리가 좀더 메크러운 것 같다.)
2. 추가적으로 Hadoop Eco System 에는 Hadoop 보다 훨씬 많은 노드가 NoSQL 이나 다른 Service Layer 에 존재 할 수 있다.. 좀 헝그리하게 시스템을 운영하는 경우라면..(우리처럼 TT) Mesos 를 모든 장비에 깔아주면.. 모든 시스템을 쥐어 짜듯 죄다 활용할 수 있어서... 모니터링 콘솔들을 보고 있자면, 놀고 있어도 일하는 거 같고... 왠지 알아주는 사람 없지만, 회사에 수(or 수십)억원을 Save 시켜주고 있다는 느낌을 혼자(TT) 받을 수 있다.
3. 모니터링 또한 Mesos 의 모니터링 콘솔이 훨씬 직관적이고 잘 되어 있다. 현재 얼마나 cpu 를 쓰고 있고, 메모리를 쓰고 있고, 몇개의 executor 가 job 별로 할당되어 있고.... 어떤 job 이 대기 타고 있는지 1초만에 확인 가능한 단일 view 를 제공한다. yarn 은 여러번의 클릭을 하고 머릿속에서 종합해야 할 일들이다. 물론 스케줄러가 좀더 큰 그림의 진행 상황을 별도로 보여주는 레이어로 존재할지라도..현 시점의 Job 상황을 HW 리소스 와 함께 맵핑하여 본다는 건 실무에서 꽤 필요한 부분이다.
4. Spark Streaming 이나 SparkR 에서도 할이야기들이 좀 더 있지만...요건 별도 Post 하는 걸로...