spark on kubernetes vs EMR

도입배경

• 기존에 EMR을 사용해서 Data Mart 데이터 생성작업을 처리하고 있었는데
• spark on kubernetes 를 도입해서 기존 batch를 모둔 전환했습니다.
• 2019년 말에 전환 했지만 장단점에 대해서 정리하고자 문서화 합니다.

Spark on Kubernetes

• 관련 reference
  • https://spark.apache.org/docs/latest/running-on-kubernetes.html
• 기존 local, yarn, mesos 등으로 resource관리하였는데 kubernetes를 resource manager로 대체하는 구조
• 실행
  • spark이 설치된 container에서 submit할수도 있지만,
  • spark operator 설치로 API등으로 실행가능
  • https://github.com/GoogleCloudPlatform/spark-on-k8s-operator
• 장점 vs EMR
  • resource manager
    • kubernetes 를 설치한 상태에서 yarn이나 hadoop등의 중앙집중화된 platform을 설치하지 않고 k8s master에 submit함으로써 실행/관리
  • task(resource) dependency
    • Airflow를 예로 들어 하나의 DAG에서 동시에 여러task실행할때 resource가 여러task를 실행하기에 충분함에도 하나의 task가 EMR source를 다 쓴다거나 해서 다른 task를 기다린다거나하는 case가 발생하기도 함
    • spark on k8s에서는 task끼리 완전히 dependent하기때문에 다른 task 실행에 대한 신경을 쓸필요가 없음
  • memory사용(세금)
    • EMR 사용시 기본적으로 EMR관리를 위해 사용하는 메모리 비율이 있는데
    • k8s 사용하게 되면 demonset 비용이 있기는 하지만
    • ec2 instance에서 EMR보다 더 많은 메모리를 사용할수 있는 장점이 있음
  • 비용
    • EMR비용에 대한 절약
    • spot instance를 사용시 다양한 instance type을 지정할수 있어서 instance down시 좀더 유연한 대처가능
  • executor 자유로운 설정
    • 하나의 DAG에 작업량 차이가 많은 task가 있을경우 = executor 편차가 심할때 = ex) executor가 5개인 task와 100개인 task가 하나의 DAG에 있을경우
    • EMR은 100개의 executor를 받을수 있는 node를 구성해야하고 DAG가 끝날때 까지(물론 좀 더 빨리 끝나긴하겠지만) 대량의 node를 유지해야하는 반면에
    • spark on kubernetes는 해당task만 대량의 executor를 사용하고 종료시 반납하므로 node를 지속적으로 많이 사용하지 않게됨
• 단점 vs EMR
  • spark on kubernetes의 단점인데 아직 yarn resource manager와 비교해서 안되는 기능들이 있음(3.3기준)
    • dynamic allocation
    • external shuffle service