들어가며
기존 EMR은 Spark나 Hive 작업을 수행하기 위해 사용자가 직접 EMR 클러스터를 생성하고 관리해야 했습니다. 하지만 작업량이 일정하지 않은 환경에서는 클러스터를 계속 실행해야 하므로 비용이 증가하고 운영 부담도 커질 수 있습니다.
이러한 문제를 해결하기 위해 AWS는 EMR Serverless를 제공하고 있으며, Kubernetes 환경에서 Spark를 실행할 수 있는 EMR on EKS도 함께 지원하고 있습니다.
이번 글에서는 EMR Serverless의 동작 방식과 주요 기능을 살펴보고, 마지막으로 EMR on EKS가 어떤 서비스인지 간단히 알아보겠습니다.
1. EMR Serverless란?
EMR Serverless는 클러스터를 직접 생성하거나 관리하지 않아도 Spark와 Hive 작업을 실행할 수 있는 서버리스 서비스입니다.
기존 EMR에서는 작업을 수행하기 전에 Master Node와 Core Node 등을 포함한 클러스터를 먼저 생성해야 했습니다. 반면 EMR Serverless는 작업(Job)을 제출하면 필요한 리소스를 AWS가 자동으로 생성하고 작업이 끝나면 다시 정리합니다.
사용자는 Spark나 Hive 버전을 선택하고 Job만 제출하면 되므로 인프라 운영 부담을 크게 줄일 수 있습니다.
1-1) 기존 EMR과의 차이
| EMR | EMR Serverless |
| 클러스터 직접 생성 | 클러스터 생성 불필요 |
| 노드 관리 필요 | AWS가 자동 관리 |
| 실행 중인 클러스터 비용 발생 | 작업 실행 시간만 과금 |
| 사용자가 확장 관리 | 자동 확장 및 축소 |
2. EMR Serverless 실행 과정
EMR Serverless는 다음과 같은 순서로 작업을 수행합니다.
- Job Submitter
- 사용자가 Spark Job을 EMR Serverless에 제출합니다.
- User Driver
- Spark 애플리케이션을 실행하고 작업(Task)을 생성하여 Executor에 전달합니다.
- System Driver
- AWS가 리소스를 할당하고 S3, Glue 등 AWS 서비스와의 연동을 관리합니다.
- User Executors
- 여러 Executor가 데이터를 병렬로 처리하여 Spark 연산을 수행합니다.
- System Executors
- 처리 결과를 Amazon S3에 저장하고, Glue Data Catalog 등 시스템 작업을 수행합니다.
Spark 스크립트나 Hive 쿼리를 제출하면 EMR Serverless가 필요한 컴퓨팅 자원을 자동으로 할당합니다. 작업이 완료되면 결과와 로그를 저장하고 사용한 리소스를 자동으로 정리합니다.
3. EMR Serverless Application Lifecycle
EMR Serverless Application은 다음과 같은 생명 주기를 가집니다.
- Creating : 새로운 Application을 생성하는 단계입니다.
- Created : 생성이 완료되었으며, 아직 실행되지는 않은 상태입니다.
- Starting : 작업을 실행하기 위해 필요한 Worker와 리소스를 준비하는 단계입니다.
- Started : Application이 실행 중이며 Spark Job을 수행할 수 있는 상태입니다.
- Stopping : 실행 중인 작업을 종료하고 리소스를 정리하는 단계입니다.
- Stopped : 작업은 종료되었지만 Application은 유지되어 다시 시작할 수 있는 상태입니다.
- Terminated : Application이 완전히 삭제된 상태로, 다시 사용하려면 새로 생성해야 합니다.
Application은 생성(Create) → 실행(Start) → 중지(Stop) → 삭제(Terminate) 순서로 관리되며, 필요할 때 다시 시작하거나 완전히 삭제할 수 있습니다. Stopped 상태는 애플리케이션을 유지한 채 다시 시작할 수 있지만, Terminated 상태는 애플리케이션이 삭제되어 새로 생성해야 한다는 점이 가장 큰 차이입니다.
4. Pre-Initialized Capacity란?
EMR Serverless는 작업이 시작될 때 필요한 Worker를 자동으로 생성합니다. 하지만 Worker를 생성하는 과정에서 초기 실행 시간이 발생할 수 있는데, 이를 Cold Start라고 합니다. Pre-Initialized Capacity는 일부 Worker를 미리 준비해 두는 기능입니다.
이를 활용하면 Spark 작업이 시작될 때 Worker 생성 시간을 줄일 수 있어 더 빠르게 작업을 시작할 수 있습니다.
다만 Worker를 미리 유지하는 만큼 추가 비용이 발생할 수 있으므로, 자주 실행되는 작업에서 사용하는 것이 일반적입니다.
5. EMR on EKS란?
EMR on EKS는 Amazon EKS(Kubernetes) 환경에서 Spark 작업을 실행할 수 있는 서비스입니다.
기존 EMR은 EMR 클러스터를 생성하여 Spark 작업을 수행하지만, EMR on EKS는 이미 운영 중인 Kubernetes 클러스터 위에서 Spark Job을 실행합니다.
즉, Spark를 위해 별도의 EMR 클러스터를 구축하는 것이 아니라 Kubernetes의 자원을 함께 활용하는 방식입니다.
이러한 구조를 통해 Kubernetes에서 실행 중인 다른 애플리케이션과 리소스를 공유할 수 있으며, Spark 작업도 동일한 Kubernetes 환경에서 관리할 수 있습니다.
이번 글에서는 개념만 다루었으며, EMR on EKS의 실행 구조와 Kubernetes 연동 방식은 별도의 글에서 자세히 살펴보겠습니다.
6. EMR, EMR Serverless, EMR on EKS 비교
| 구분 | EMR | EMR Serverless | EMR on EKS |
| 실행 환경 | EMR 클러스터 | 서버리스 | Amazon EKS |
| 클러스터 관리 | 사용자 | AWS | Kubernetes |
| 자동 확장 | 가능 | 자동 | Kubernetes 기반 |
| 적합한 환경 | 장시간 실행 작업 | 간헐적인 배치 작업 | Kubernetes 운영 환경 |
7. 마치며
이번 글에서는 EMR Serverless와 EMR on EKS의 기본 개념을 살펴보았습니다.
EMR Serverless는 클러스터를 직접 관리하지 않고도 Spark와 Hive 작업을 실행할 수 있어 운영 부담을 줄이고 작업량에 따라 리소스를 자동으로 조절할 수 있다는 장점이 있습니다. 또한 Application Lifecycle과 Pre-Initialized Capacity를 통해 작업 실행 방식과 성능을 조절할 수 있다는 점도 확인할 수 있었습니다.
반면 EMR on EKS는 Kubernetes 환경에서 Spark 작업을 실행할 수 있도록 지원하는 서비스로, 이미 Amazon EKS를 운영하고 있는 환경에서 더욱 효율적으로 활용할 수 있습니다.
EMR은 실행 환경에 따라 다양한 형태를 제공하므로, 작업 특성과 운영 환경에 맞는 서비스를 선택하는 것이 중요하다는 것을 배울 수 있었습니다.
'Data Engineering > AWS' 카테고리의 다른 글
| Amazon EMR | EMR은 데이터를 어디에 저장하고 AWS 서비스와 어떻게 연동될까? (0) | 2026.07.23 |
|---|---|
| Amazon EMR란? (0) | 2026.07.23 |
| Amazon Athena | Federated Query로 다양한 데이터 소스를 SQL로 조회하기 (0) | 2026.07.23 |
| Apache Iceberg와 Glue Data Catalog 연동 이해하기 (0) | 2026.07.22 |
| AWS Athena | Workgroup, 비용 최적화, 보안 (0) | 2026.07.21 |