[analytics] Amazon EMR
페타바이트급 데이터를 여러 대가 나눠 처리해야 할 때. Hadoop·Spark 클러스터를 관리형으로 굴리는 EMR.
One-Line Summary
EMR(Elastic MapReduce)은 Hadoop·Spark·Hive·Presto 같은 빅데이터 프레임워크를 관리형 클러스터로 실행해, 페타바이트급 데이터를 대규모로 처리하는 서비스다. 시험에서는 대규모 빅데이터 배치 처리 / 기존 Hadoop·Spark 워크로드 이전 / Spot·트랜지언트 클러스터로 비용 절감 / S3(EMRFS) 연동 이 핵심이다. Spark는 EMR 위에서 도는 대표 처리 엔진이다.
Why It Exists
수 TB~PB급 데이터를 분산 처리하려면 Hadoop/Spark 클러스터가 필요한데, 이를 직접 구축·튜닝·유지하는 건 매우 어렵다. 반면 완전 서버리스(Glue)로는 세밀한 제어나 특정 프레임워크 요구를 못 맞출 때가 있다.
EMR은 이 클러스터를 관리형으로 제공하되, 프레임워크와 인스턴스를 세밀하게 제어할 수 있게 한다.
페타바이트급 데이터 (S3)
-> EMR 클러스터(Spark/Hive/Presto)로 분산 처리
- Master/Core/Task 노드로 구성
- S3를 저장소로(EMRFS), 클러스터는 처리에 집중
-> 결과를 S3/Redshift 등으로
시험 감각:
"대규모 Hadoop/Spark 처리 / 기존 Spark 잡을 그대로 / 클러스터 제어" = EMR.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
EMR | Elastic MapReduce | 관리형 빅데이터 클러스터 서비스 |
Spark | Apache Spark | 인메모리 분산 처리 엔진(EMR의 대표 워크로드) |
EMRFS | EMR File System | EMR이 S3를 저장소로 쓰게 해주는 파일시스템 |
Master/Core/Task | Node types | 클러스터의 조정/저장+연산/연산 전용 노드 |
Transient Cluster | Transient Cluster | 작업 끝나면 종료하는 일회성 클러스터 |
노드 구성과 Spot 비용 절감 (빈출)
| 노드 | 역할 | 비용 전략 |
|---|---|---|
| Master | 클러스터 조정 | 온디맨드(안정성 중요) |
| Core | 데이터 저장(HDFS) + 연산 | 온디맨드/RI (중단되면 데이터 손실 위험) |
| Task | 연산만 담당(데이터 저장 안 함) | Spot 인스턴스로 큰 비용 절감 |
Task 노드는 데이터를 안 갖고 있어 중단돼도 안전
-> Task 노드에 Spot 사용 = 저렴하게 연산 확장
시험 감각:
"EMR 비용을 낮춰라" = Task 노드에 Spot + 필요 시 트랜지언트 클러스터(작업 후 종료).
스토리지 — EMRFS(S3) 연동
EMR은 데이터를 HDFS(클러스터 로컬) 대신 S3(EMRFS) 에 두는 패턴이 흔하다. 그러면 클러스터를 꺼도 데이터가 S3에 남아, 처리와 저장을 분리(decoupling)할 수 있다.
데이터는 S3에 영구 보관 + 처리할 때만 EMR 클러스터 기동
-> 클러스터 종료해도 데이터 안전, 비용 절감
시험 감각:
"처리와 저장을 분리 / 클러스터를 꺼도 데이터 유지" = EMRFS로 S3 사용.
EMR vs Glue vs Athena (핵심 비교, 빈출)
| 구분 | EMR | Glue | Athena |
|---|---|---|---|
| 모델 | 관리형 클러스터 | 서버리스 ETL | 서버리스 SQL 조회 |
| 제어 수준 | 높음(프레임워크·튜닝) | 낮음(관리 최소) | 없음(쿼리만) |
| 적합 | 대규모·지속·커스텀 빅데이터 | 간헐적 ETL, 카탈로그 | S3 즉석 SQL |
| 운영 부담 | 큼 | 작음 | 없음 |
시험 감각:
"기존 Spark/Hadoop, PB급, 세밀한 제어" = EMR. "서버리스 ETL" = Glue · "S3 SQL 조회" = Athena.
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 간헐적 서버리스 ETL이면 되는데 EMR 상시 클러스터 | 운영·비용 과함 → Glue |
| 단순 S3 SQL 조회에 EMR | 조회는 Athena |
| EMR 비용 절감을 인스턴스 축소만으로 | Task 노드 Spot + 트랜지언트 클러스터가 정석 |
| Core 노드에 Spot 남발 | Core는 데이터 보관 → 중단 시 손실 위험, Spot은 Task에 |
| 데이터를 HDFS에만 두고 클러스터 상주 | EMRFS(S3) 로 저장·처리 분리하면 클러스터 꺼도 안전 |
| 실시간 스트림 처리를 EMR 배치로 | 실시간은 Flink |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "process petabytes / large-scale big data" | EMR |
| "run existing Apache Spark / Hadoop / Hive jobs" | EMR |
| "need control over the cluster/framework" | EMR |
| "reduce EMR cost" | Task 노드 Spot + 트랜지언트 클러스터 |
| "decouple storage and compute / keep data after cluster stops" | EMRFS(S3) |
| "serverless ETL, minimal ops" | EMR 아님 → Glue |
Memory Sentence
EMR은 관리형 Hadoop/Spark 클러스터로 PB급 빅데이터를 처리한다. Master/Core/Task 구조에서 Task 노드에 Spot을 써서 비용을 낮추고, 트랜지언트 클러스터로 작업 후 종료한다. 데이터는 EMRFS로 S3에 두어 처리·저장을 분리. 서버리스 ETL이면 Glue, S3 즉석 조회면 Athena.
References
댓글
아직 댓글이 없습니다.