Amazon EMR 완전 정리 (DEA-C01 시험 핵심)
들어가며
DEA-C01 시험의 Domain 1: Data Ingestion and Transformation (34%) 과 Domain 2: Data Store Management (26%) 에 걸쳐 등장하는 서비스가 바로 Amazon EMR(Elastic MapReduce) 입니다.
Hadoop이나 Spark 같은 빅데이터 프레임워크를 AWS에서 쉽게 실행할 수 있게 해주는 완전 관리형 서비스로, 시험에서는 클러스터 구조, 스토리지 옵션, 클러스터 유형이 자주 출제됩니다.
이 글에서는 시험 대비 관점에서 핵심 내용을 정리해보겠습니다.
---
Amazon EMR이란?
EMR의 기본 개념부터 정리합니다.
| 항목 | 내용 | | --- | --- | | 정의 | Apache Hadoop 기반 완전 관리형 빅데이터 처리 서비스 | | 지원 프레임워크 | Hadoop, Apache Spark, HBase, Presto, Flink | | 주요 활용 | 로그 분석, 금융 분석, ETL 작업 | | 인프라 | Amazon EC2 + Amazon S3 | | 접근 방법 | AWS 콘솔, CLI, SDK, EMR API, SSH |
EMR은 EC2 위에서 실행되며 SSH로 OS에 직접 접근할 수 있습니다. 완전 관리형이지만 기반 OS 접근이 가능한 점이 다른 관리형 서비스와의 차이점입니다.
---
클러스터 노드 구조 (3가지 노드 타입)
EMR 클러스터는 역할에 따라 3가지 노드로 구성됩니다. 이 구조는 시험에서 거의 매번 등장합니다.
| 노드 타입 | 역할 | 데이터 저장 | 연산 수행 | 특이사항 | | --- | --- | --- | --- | --- | | Master Node | 클러스터 전체 조율 및 관리 | X | X | 태스크 할당, 장애 복구, 클러스터 상태 관리 | | Core Node | 데이터 저장 + 연산 | O | O | 데이터 복제 담당, 클러스터 동작 중 필수 | | Task Node | 연산 전담 (선택 사항) | X | O | 스팟 인스턴스 활용 가능하여 비용 절감 |
Task Node는 데이터를 저장하지 않고 연산만 담당합니다. 스팟 인스턴스로 띄워 비용을 줄이는 시나리오가 시험에서 자주 출제됩니다.
!EMR 클러스터 노드 유형: Master, Core, Task
스토리지 옵션 비교 (HDFS vs EMRFS vs Local)
스토리지 옵션 비교는 DEA-C01에서 단골 출제 문제입니다.
| 스토리지 | 설명 | 영속성 | 주요 활용 | | --- | --- | --- | --- | | HDFS | 분산 파일 시스템, 128MB 블록 분할 및 복제 | 임시 (클러스터 종료 시 삭제) | 중간 처리 데이터, 임시 저장 | | EMRFS | S3를 Hadoop 파일 시스템처럼 사용 | 영구 (클러스터 종료 후에도 유지) | 입력/출력 데이터, 장기 보존 | | Local File System | EC2 인스턴스 로컬 디스크 | 임시 (인스턴스 종료 시 삭제) | 캐싱, 임시 처리 데이터 |
시험에서 "클러스터 종료 후에도 데이터를 유지해야 한다"는 시나리오가 나오면 EMRFS(S3)를 사용하는 것이 정답입니다. HDFS는 클러스터가 종료되면 데이터가 사라집니다.
---
외부 메타스토어 (External Metastore)
기본적으로 Hive 메타스토어는 Master Node의 로컬 MySQL에 저장됩니다. 클러스터가 종료되면 메타스토어도 함께 사라지는 문제가 있습니다.
이를 해결하기 위해 외부 메타스토어를 사용합니다.
| 옵션 | 특징 | | --- | --- | | AWS Glue Data Catalog | 완전 관리형, Athena 및 Redshift와도 통합 가능 | | Amazon RDS / Aurora | 고가용성 및 내구성, 대용량 메타데이터 관리에 적합 |
HDFS나 S3에 파일을 직접 추가했을 때 Hive가 새 파티션을 인식하지 못할 수 있습니다. 이때 MSCK REPAIR TABLE 명령어를 사용합니다.
이 명령은 파일 시스템에서 새 파티션을 스캔하여 Hive 메타스토어에 동기화합니다.
---
클러스터 유형: 일시적 vs 장기 실행
| 구분 | 일시적 클러스터 (Transient) | 장기 실행 클러스터 (Long-Running) | | --- | --- | --- | | 수명 | 작업 완료 후 자동 종료 | 지속적으로 실행 | | 주요 활용 | 배치 ETL, 주기적 처리 작업 | 인터랙티브 분석, 상시 서비스 | | 비용 | 작업 실행 시간만 과금하여 비용 효율 높음 | 클러스터 유지 시간 계속 과금 |
주기적 배치 처리에는 일시적 클러스터, 상시 접근이 필요하면 장기 실행 클러스터를 사용합니다.
---
Amazon EMR Serverless
EMR Serverless는 클러스터를 직접 프로비저닝하거나 관리하지 않고 Spark나 Hive 애플리케이션을 실행할 수 있는 서버리스 옵션입니다.
주요 특징은 다음과 같습니다.
클러스터 용량 최적화와 스케일링을 AWS가 자동 처리 Apache Spark, Apache Hive 지원 인프라 관리 오버헤드 없이 분석 워크로드에 집중 가능
시험에서 "클러스터 관리 없이 Spark 작업을 실행하고 싶다"는 시나리오가 나오면 EMR Serverless가 정답입니다.
---
AWS Graviton2와 Spark 메모리 오버헤드
AWS Graviton2 인스턴스
ARM 기반 커스텀 프로세서로, 동급 x86 인스턴스 대비 최대 40% 향상된 가격 대비 성능을 제공합니다. Spark나 Hadoop 같은 데이터 집약적 워크로드에 특히 효과적입니다.
Spark 메모리 오버헤드
Spark는 드라이버와 익스큐터에 요청된 메모리의 약 10% 추가 오버헤드가 발생합니다. Shuffle 작업이나 태스크 실행 등 내부 작업에 사용되며, 메모리 설정 시 이 오버헤드를 반드시 고려해야 OOM(Out-of-Memory) 에러를 방지할 수 있습니다.
---
빠르게 정리하는 핵심 암기 포인트
| 키워드 | 연결 개념 | | --- | --- | | EMR + Spark | 빅데이터 인메모리 처리 | | Master Node | 클러스터 관리만 (저장 및 연산 X) | | Core Node | 저장 + 연산 (필수) | | Task Node | 연산만 (선택, 스팟 인스턴스 활용) | | HDFS | 임시 저장 (클러스터 종료 시 삭제) | | EMRFS | S3 기반 영구 저장 | | MSCK REPAIR TABLE | Hive 파티션 메타데이터 동기화 | | 일시적 클러스터 | 배치 ETL, 비용 효율 | | EMR Serverless | 클러스터 관리 불필요 | | Graviton2 | x86 대비 최대 40% 가격 대비 성능 향상 |
---
마무리
Amazon EMR은 DEA-C01에서 빅데이터 처리 시나리오에 빠지지 않는 핵심 서비스입니다.
시험에서는 특히 다음 내용을 정확히 구분하는 것이 중요합니다.
3가지 노드 타입의 역할 차이 HDFS와 EMRFS의 영속성 차이 일시적 클러스터와 장기 실행 클러스터의 비용 차이
이 개념들만 확실히 정리해두면 DEA-C01 빅데이터 처리 관련 문제 대부분을 해결할 수 있습니다.