BigData/Spark & Spark Tuning
[Spark] YARN vs k8s vs mesos 스파크 리소스 및 작업 스케줄링
스파이디웹
2025. 1. 7. 23:22
728x90
spark에서 사용할 수 있는, 정확히는 hadoop의 YARN대신에 사용 할 수 있는 리소스와 작업 스케줄링을 담당하는 컴포넌트에 대해서 비교 해보겠습니다.
1. 아키텍처 및 설계 목적
| 항목 | YARN | Kubernetes | Mesos |
| 목적 | Hadoop 에코시스템 내에서 자원 관리를 위한 분산 리소스 관리 | 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 위한 오케스트레이션 | 다양한 워크로드 (컨테이너, Spark, Hadoop 등)를 통합 관리하는 범용 리소스 관리 |
| 주요 구성 요소 | ResourceManager, NodeManager, ApplicationMaster | Master(Node), Worker(Node), kubelet, kube-proxy, pod | Master, Agent(Slave), Framework (Marathon, Chronos 등) |
| 리소스 단위 | 컨테이너 (YARN 컨테이너) | Pod (컨테이너의 집합) | Task (하나의 작업 단위) |
| 자원 관리 방식 | 애플리케이션별 독립적인 ApplicationMaster가 자원을 요청하고 관리 | 마스터가 전체 클러스터 상태를 관리하고 스케줄링 | 메소스 마스터가 자원을 제공하고, 프레임워크가 자원을 할당받아 작업 수행 |
2. 확장성 및 유연성
| 항목 | YARN | Kubernetes | Mesos |
| 확장성 | 수천 개의 노드와 애플리케이션 관리 가능 (Spark, Hive 등과 통합) | 기본적으로 고가용성(HA) 및 수평 확장 설계 | 수십만 개의 노드와 다양한 애플리케이션 통합 관리 |
| 유연성 | 주로 데이터 처리 및 분석 워크로드에 최적화됨 | 다양한 애플리케이션 및 마이크로서비스에 적합 | 컨테이너와 비컨테이너 워크로드 모두 지원 (Spark, Hadoop, Docker 등) |
| 다중 워크로드 | Spark, MapReduce 등 주로 배치 처리 워크로드 | 마이크로서비스, CI/CD, 데이터 처리 등 다양함 | Spark, Hadoop, Kubernetes, Docker 등 혼합 가능 |
3. 리소스 관리 및 스케줄링
| 항목 | YARN | Kubernetes | Mesos |
| 스케줄링 방식 | 애플리케이션이 직접 자원을 요청하고 사용 | 마스터가 전체 클러스터 상태를 기반으로 스케줄링 | 마스터가 자원을 오퍼(offer)하고, 프레임워크가 선택 |
| 프레임워크 지원 | Spark, MapReduce, Tez 등 | 기본적으로 컨테이너 오케스트레이션 (Docker, containerd) | Marathon, Chronos, Aurora, Kubernetes 등 다양한 프레임워크 동시 실행 |
| 리소스 격리 | cgroups 기반 | cgroups 및 namespace를 이용한 격리 | cgroups 및 Mesos 컨테이너 실행 환경 (Containerizer) |
4. 고가용성(HA) 및 장애 복구
| 항목 | YARN | Kubernetes | Mesos |
| 고가용성 | ResourceManager HA, ApplicationMaster 재시작 지원 | 기본적으로 마스터 HA 및 노드 복구 기능 내장 | Mesos Master 및 Agent 모두 HA 구성 가능 |
| 장애 복구 | 애플리케이션 레벨에서 복구 | Pod 레벨에서 자동 복구 (Self-healing) | Task 재시작 및 장애 시 다른 노드에서 복구 가능 |
5. 운영 및 관리 용이성
| 항목 | YARN | Kubernetes | Mesos |
| 설치 및 설정 | Hadoop 에코시스템 구성 필요 | 다양한 클러스터 및 클라우드 환경에서 설정 가능 | 다양한 프레임워크 및 애플리케이션 설정 필요 (상대적으로 복잡) |
| 모니터링 및 로깅 | Hadoop 자체 모니터링 및 Ambari 등 사용 | Prometheus, Grafana 등 다양한 모니터링 도구와 통합 | Marathon, Mesos-Dashboard 등 사용 가능 |
6. 주요 사용 사례 및 장점
| 항목 | YARN | Kubernetes | Mesos |
| 주요 사용 사례 | 대규모 데이터 처리 및 분석 (Spark, Hive, HBase) | 마이크로서비스, 웹 애플리케이션, CI/CD 파이프라인 | 대규모 데이터 센터에서 다양한 워크로드 통합 |
| 장점 | - Hadoop 생태계에 최적화 - Spark 등과 긴밀하게 통합 - 대규모 데이터 배치 작업에 강력 |
- 컨테이너 기반의 배포 및 확장 용이 - 복구 및 자동 확장 기능 내장 - 마이크로서비스에 적합 |
- 범용 클러스터 관리자 - 다양한 워크로드 동시 실행 - 확장성이 뛰어남 (수십만 노드) |
7. 단점 및 고려사항
| 항목 | YARN | Kubernetes | Mesos |
| 단점 | - 컨테이너 기반 워크로드 관리에 비효율적 - 마이크로서비스 관리 기능이 부족 |
- 초기 학습 곡선이 높음 - 복잡한 설정 및 네트워크 구성 필요 |
- 운영 및 설정이 복잡 - 커뮤니티가 상대적으로 작음 |
| 고려사항 | Hadoop 환경에서만 효과적 | 마이크로서비스 아키텍처에서 강력 | 대규모 데이터센터에 적합하지만 관리 복잡성 존재 |
8. 추천 사용 사례
- YARN: 데이터 분석 및 배치 처리 파이프라인 (Spark, Hadoop 기반 데이터 파이프라인 구축)
- Kubernetes: 웹 애플리케이션, 마이크로서비스 아키텍처, CI/CD 파이프라인
- Mesos: 대규모 클러스터 및 다양한 워크로드를 통합 관리하는 데이터 센터
9. 속도 측면
리소스 할당 및 스케줄링 속도
| 항목 | YARN | Kubernetes | Mesos |
| 리소스 할당 방식 | 애플리케이션마다 ApplicationMaster가 직접 자원 요청 | 마스터가 Pod 단위로 상태를 모니터링하고 리소스 스케줄링 | 자원 오퍼(Offer) 방식으로 자원을 프레임워크에 제공 |
| 속도 | 느림 – ApplicationMaster가 자원 요청을 반복 수행 (약간의 지연) | 빠름 – 상태 기반 스케줄링으로 Pod 배포 속도 우수 | 매우 빠름 – 자원 오퍼 방식은 실시간에 가깝게 동작 |
| 특징 | Spark, Hadoop 등 대규모 배치 작업에서는 효율적이나 초기 할당 지연이 발생할 수 있음 | 컨테이너 기반 애플리케이션은 신속하게 배포되고 자동 복구도 빠름 | 다양한 프레임워크가 병렬적으로 자원을 사용해 병목 현상이 적음 |
애플리케이션 시작 및 확장 속도
| 항목 | YARN | Kubernetes | Mesos |
| 애플리케이션 시작 시간 | 상대적으로 느림 (초기 컨테이너 프로비저닝 및 AM 실행) | 빠름 (컨테이너 기반이므로 수 초 내 시작 가능) | 가장 빠름 (컨테이너 및 비컨테이너 워크로드 모두 실시간 배포 가능) |
| 확장 속도 | 확장성이 높지만 자원 확보 속도는 다소 느림 | 매우 빠름 – Pod를 필요에 따라 빠르게 확장/축소 | 빠름 – 리소스 오퍼 방식으로 자원 재할당 속도가 높음 |
| 특징 | 배치 작업 중심이므로 지속적 확장보다는 전체 자원 활용에 중점 | 수평 확장(Scale-out)에 최적화, 자동 확장 기능 포함 | 수십만 개의 노드에서도 빠르게 애플리케이션 실행 가능 |
작업 지연 및 병목 현상
| 항목 | YARN | Kubernetes | Mesos |
| 작업 지연 | ApplicationMaster 및 ResourceManager 간 통신 지연 발생 가능 | Pod 스케줄링 지연 발생 가능 (노드 자원 부족 시) | 자원 오퍼 방식으로 병목 현상 적음 |
| 병목 발생 위치 | ResourceManager의 자원 분배 지연 | 마스터가 모든 클러스터 상태를 모니터링하므로, 클러스터가 커질수록 부하 발생 | 프레임워크가 직접 자원을 선택하므로 병목 발생 가능성이 낮음 |
| 특징 | 데이터 처리량이 크면 효율적이지만, 작업 초기 지연이 문제 | 클러스터가 과부하 상태면 스케줄링 지연이 발생할 수 있음 | 병목이 적고, 프레임워크 간 자원 경쟁을 피하기 쉽음 |
Stand Alone 모드
Spark Standalone 모드에서는 리소스 관리 프레임워크로 Spark 자체 내장 클러스터 매니저가 사용, 별도의 외부 리소스 관리 시스템(YARN, Kubernetes 등) 없이 Spark가 자체적으로 클러스터의 리소스를 관리하고 작업을 스케줄링
728x90