Apache Spark Cluster Manager 종류
Apache Spark는 다양한 환경에서 유연하게 동작할 수 있도록 여러 종류의 클러스터 매니저(Cluster Manager)를 지원함.
클러스터 매니저는 Spark 응용 프로그램이 실행되는 물리적/가상 자원을 효과적으로 관리하고, Executor(작업 실행 프로세스)를 스케줄링하는 핵심 역할을 담당함.
전문가 수준으로 이해하기 위해서는 각각의 클러스터 매니저가 어떤 원리로 자원을 할당하고, Spark가 어떤 방식을 통해 이들과 상호작용하는지 살펴봐야 함.
Standalone Cluster Manager : 동작 방식
1. Master-Slave 구조
Spark Standalone 클러스터는 하나의 Master 프로세스와 여러 Worker 노드(노드마다 Worker 프로세스 1개 이상)로 구성됨.
Master 프로세스가 Worker 노드들의 상태를 체크하고, 애플리케이션으로부터 받은 요청에 따라 Worker 노드에 Executor를 배치함.
2. Resource Allocation
Master는 Worker 노드로부터 자원(CPU 코어, 메모리 등)의 사용 가능 상태를 주기적으로 보고받음.
Job이 들어오면, Master는 사용 가능한 Worker에게 Executor(프로세스)를 생성하도록 지시함.
3. Application Scheduling
사용자 애플리케이션(드라이버)은 Master에게 Cluster 모드(submit)로 요청을 보내고, Master는 필요한 Worker 리소스를 할당함.
Client 모드가 아닌 Cluster 모드일 경우, 드라이버도 클러스터 내부에서 실행됨.
Standalone Cluster Manager : 특징
1. 구성이 간단
별도의 리소스 관리자(Hadoop YARN, Mesos 등)가 필요 없어, 로컬 환경에서 빠르게 테스트하거나 소규모 클러스터를 구성할 때 편리함.
2. 높은 안정성, 적은 복잡도
다른 외부 컴포넌트와의 연동이 필요치 않아 오버헤드가 적고, 장애를 파악하기 비교적 쉬움.
3. 확장성 제한
대규모 클러스터 환경보다는 중소규모 배포에 적합함.
자원 할당 정책이 단순하며, 엔터프라이즈 환경에서 복잡한 요구사항(멀티 테넌시, 다양한 배치 정책 등)을 충족시키기 위해서는 한계가 있을 수 있음.
Apache Hadoop YARN : 동작 방식
1. ResourceManager / NodeManager 구조
Hadoop YARN은 ResourceManager(RM)와 NodeManager(NM)로 구성됨.
ResourceManager는 클러스터 전체 자원 관리를 담당하고, NodeManager는 노드별 자원 사용 상태를 관리함.
2. ApplicationMaster
Spark 애플리케이션은 YARN 위에서 실행될 때, 'ApplicationMaster(AM)' 라는 프로세스를 통해 자원을 요청함.
Spark의 경우, 드라이버가 ApplicationMaster 역할을 수행하거나, YARN 클러스터가 AM을 별도로 기동할 수 있음.
모드에 따라 다름.
3. Container 단위 자원 할당
YARN은 CPU, 메모리와 같은 자원을 ‘Container’ 단위로 관리함.
Spark는 필요한 만큼의 Container를 요청하여 Executor를 띄우고, 작업을 처리함.
Apache Hadoop YARN : 특징
1. 대규모 클러스터 환경에서 검증된 안정성
Hadoop 환경과 밀접하게 통합되어 있고, 대규모 데이터 처리 파이프라인을 위해 최적화되어 있음.
맵리듀스와 함께 운영되는 기존 Hadoop 클러스터에 Spark를 쉽게 통합 가능.
2. 멀티 테넌시 및 정책 지원
Capacity Scheduler, Fair Scheduler 등 다양한 스케줄러를 통해 여러 애플리케이션 간에 리소스를 유연하게 분배할 수 있음.
우선순위, 큐(Queue) 기반의 정책 등을 지정하여 엔터프라이즈급 멀티 테넌시 구성 가능.
3. 복잡한 설정
YARN 자체가 꽤 많은 설정을 필요로 하며, Spark와 연동 시에도 yarn-site.xml, spark-defaults.conf 등 여러 설정이 필요함.
단순 테스트보다는 프로덕션 환경에서 대규모 클러스터를 관리할 때 장점이 두드러짐.
Apache Mesos : 동작 방식
동작 방식
1. Two-level Scheduling
Mesos에는 ‘Master’와 다수의 ‘Slave’가 있으며, Master는 Slave에서 사용 가능한 자원을 “offer” 형태로 프레임워크(예: Spark)에 제공함.
Spark 프레임워크(드라이버)는 이 offer를 받아, 필요한 만큼의 자원을 사용해 Executor를 실행함.
2. Framework(스파크)와 Mesos의 상호작용
Spark 드라이버가 Mesos Master로부터 자원 ‘offer’를 받고, 필요한 만큼 accept하여 Executor를 배포함.
스파크는 Mesos에 의해 배정된 노드 위에서 작업을 수행하고, 작업이 끝나면 자원을 반납함.
Apache Mesos : 특징
1. 범용성
Spark뿐만 아니라 다른 프레임워크(예: TensorFlow, Cassandra, Kafka 등)도 동시에 Mesos 위에서 실행할 수 있음.
여러 워크로드가 공존하는 데이터센터 수준의 대규모 환경에서 주로 사용됨.
2. 유연한 리소스 공유
Mesos의 오퍼 기반 스케줄링 방식을 통해, 각 프레임워크가 자신의 요구 사항에 따라 동적으로 자원을 획득, 반납이 가능함.
복잡한 환경에서도 효율적인 리소스 활용이 가능함.
3. 활용 사례가 제한적
YARN이 Hadoop 기반 환경에서 대중화되어 있고, 최근에는 Kubernetes의 부상으로 Mesos 사용 사례가 상대적으로 줄어드는 추세임.
그러나 일부 대규모 데이터센터(특히 Mesosphere / DC/OS 등)에서는 여전히 적극적으로 활용 중임.
Kubernetes : 동작 방식
1. Spark on Kubernetes 아키텍처
Spark는 Kubernetes 클러스터에 드라이버(Driver) Pod를 생성하고, 드라이버가 Executor Pod를 동적으로 요청하여 실행함.
Kubernetes의 kube-scheduler가 Pod 스케줄링(어느 노드에서 실행할 것인지 결정)을 담당하며, Spark는 쿠버네티스 API 서버와 통신하여 자원을 할당받음.
2. Pod 단위 격리와 네트워킹
Executor는 각각의 Pod 안에서 독립적으로 동작하므로, 다른 Executor나 애플리케이션과 네트워크, 리소스 측면에서 격리됨.
Spark 드라이버와 Executor 간 통신을 위해서는 Kubernetes 네트워크 플러그인(CNI)을 통한 설정이 이루어짐.
3. 자동 확장(Auto Scaling)
Kubernetes Horizontal Pod Autoscaler(HPA)나 Custom Autoscaler 등을 사용해 Spark Executor Pod 수를 동적으로 조절 가능함.
물론 Spark 자체 Dynamic Allocation 기능과의 조합이 필요함.
클러스터 내 리소스 사용량에 따라 Pod를 추가 배포하거나 제거할 수 있어, 효율적인 자원 활용이 가능함.
Kubernetes : 특징
1. Cloud-Native 아키텍처
컨테이너 이미지를 사용하고, Kubernetes가 제공하는 배포, 로깅, 모니터링, 보안 등 다양한 기능을 활용할 수 있음.
Helm 차트 등을 사용해 CI/CD 파이프라인과 연계하기에 용이함.
2. 플러그인 및 CRD(Custom Resource Definition)
Spark Operator를 통해 Spark 애플리케이션의 생명주기를 쉽게 관리(제출, 모니터링, 스케일링 등)할 수 있음.
쿠버네티스 친화적인 배포 환경을 구성하기에 적합함.
3. 네트워크 및 보안 설정
쿠버네티스 환경에서 Spark를 실행하려면 각 Pod 간 통신을 위한 네트워크 정책, Ingress 설정, RBAC 설정 등에 대한 이해가 필수적임.
많은 설정이 필요한 만큼, 잘 구성해두면 클라우드 네이티브 환경의 이점을 극대화할 수 있음.
정리 및 선택 가이드
1. Standalone
소규모, 테스트 또는 빠른 POC(Proof of Concept) 환경에서 사용하기에 적합.
외부 의존성이 적고 설정이 단순하나, 대규모 멀티 테넌시 환경에는 제약이 많음.
2. YARN
대규모 Hadoop 클러스터 및 에코시스템을 이미 사용 중인 경우 최적의 선택.
안정적이며, 풍부한 스케줄링 정책과 멀티 테넌시 지원.
3. Mesos
범용 리소스 오케스트레이션이 필요한 대규모 데이터센터에서 유용.
최근 Kubernetes의 인기로 인해 사용 빈도가 줄고 있지만, 특정 환경에서는 여전히 강력한 옵션.
4. Kubernetes
컨테이너 기반의 Cloud-Native 아키텍처 및 자동 확장이 필요한 환경에 적합.
DevOps, CI/CD 파이프라인, 마이크로서비스와 긴밀하게 결합 가능.
초기 설정이 다소 복잡할 수 있으나, 잘 구축하면 확장성과 유연성 극대화.
Spark 클러스터 매니저 선택은 조직의 기존 인프라, 규모, 운영 노하우에 따라 달라짐.
Hadoop YARN이나 Kubernetes처럼 대규모 워크로드와 복잡한 스케줄링, 멀티 테넌시 요구사항을 해결해야 한다면 해당 플랫폼과의 연동이 적합함.
반면, 단순히 Spark만 빠르게 테스트하고자 한다면 Standalone으로도 충분히 운영할 수 있음.
Mesos는 범용 자원 관리가 필요한 곳에서 선택하는 옵션으로 남아 있지만, 최근 컨테이너 오케스트레이션 트렌드와 클라우드 네이티브 전략을 생각한다면 Kubernetes가 가장 각광받고 있음.
결국, 어떤 워크로드를 어떤 규모로 실행할 것인지, 이미 구축된 인프라와 어떻게 통합할 것인지가 클러스터 매니저를 선택하는 핵심 기준임.
