지금 하둡을 어떻게 볼 것인가
Article
마지막 시간입니다.
이 시리즈를 여기까지 읽으셨다면 이런 의문이 남아 있을 겁니다. "지금도 하둡을 쓰나?" 솔직하게 답하면, 예전만큼은 아닙니다. 그런데 무엇이 밀려났고 무엇이 남았는지를 구분해야 합니다. 이 구분이 이번 시간의 전부예요.
층별로 나눠 보면 분명합니다
3강에서 그린 층 구조를 다시 꺼내 봅니다. 층마다 사정이 달라요.
| 층 | 지금 | 무엇이 대신하나 |
|---|---|---|
| MapReduce (계산) | 거의 안 씁니다 | Spark 가 가져갔습니다 (18강) |
| HDFS (저장) | 클라우드에서는 잘 안 씁니다 | S3 같은 오브젝트 스토리지 |
| YARN (자원) | 줄고 있습니다 | 쿠버네티스 |
| Hive 메타스토어 | 여전히 널리 씁니다 | 이름만 바뀐 형태로 계속 남아 있습니다 |
| 하둡의 개념들 | 그대로 쓰입니다 | 대체 대상이 아닙니다 |
왜 클라우드 저장소로 옮겨갔나
HDFS 의 자리를 S3 같은 오브젝트 스토리지가 가져간 이유는 하둡이 못나서가 아닙니다. 전제가 달라졌기 때문이에요.
HDFS
장비를 직접 갖고 있을 때
- 저장과 계산이 같은 장비에 있습니다
- 그래서 계산을 데이터 옆으로 보낼 수 있습니다
- 장비를 늘리면 저장과 계산이 같이 늘어납니다
- 안 쓰는 시간에도 장비값이 나갑니다
S3 등
클라우드
- 저장과 계산이 분리돼 있습니다
- 계산할 때만 서버를 띄우고 끕니다
- 저장은 쓴 만큼만 냅니다
- NameNode 메모리 걱정이 없습니다
그래도 남은 것들
- 01
메타스토어
17강에서 본 그것입니다. 파일에 표 모양을 씌우는 기록은 여전히 필요해요. 클라우드 서비스들도 같은 역할의 물건을 각자 갖고 있습니다.
- 02
파티션
안 읽을 폴더를 건너뛰는 방식은 어디서나 그대로입니다. S3 에 저장하든 어디에 저장하든 날짜별 폴더로 나눕니다.
- 03
파일 형식
Parquet · ORC 는 하둡 생태계에서 나와 지금 표준이 됐습니다. 하둡을 안 써도 이 형식은 씁니다.
- 04
Shuffle 과 쏠림
13·16강의 내용입니다. 엔진이 무엇이든 같은 키를 모으는 비용과 한 키에 몰리는 문제는 그대로 있습니다.
- 05
자원과 작업의 분리
9강에서 본 YARN 의 발상입니다. 쿠버네티스도 같은 구조로 되어 있어요.
지금도 하둡을 쓰는 곳
밀렸다고 해서 사라진 것도 아닙니다.
데이터를 밖에 못 두는 곳
금융 · 공공 · 의료
- 규정상 데이터를 자체 시설에 둬야 합니다
- 클라우드 저장소를 쓸 수 없습니다
- 직접 세운 클러스터가 필요합니다
이미 크게 세워둔 곳
오래된 대규모 시스템
- 수백 대 클러스터와 수년치 데이터가 있습니다
- 옮기는 비용이 유지 비용보다 큽니다
- 새 작업만 다른 방식으로 붙이는 중입니다
이 시리즈에서 실제로 얻은 것
마지막으로 20강을 관통한 것들을 모아 봅니다. 도구 이름이 아니라 생각의 방식입니다.
- 나눌 수 있어야 늘릴 수 있다조각을 따로 처리할 수 있는 일만 장비를 늘린 만큼 빨라집니다 (2·12강)
- 고장은 막지 말고 견딘다복제·재시도·추측 실행이 전부 이 태도에서 나왔습니다 (1·7·16강)
- 옮기는 비용이 계산 비용보다 크다Shuffle 이 가장 비싼 이유이자 Combiner 를 쓰는 이유입니다 (13·15강)
- 안 읽는 것이 가장 빠르다파티션이 가장 큰 성능 개선인 이유입니다 (17강)
- 층을 나누면 갈아끼울 수 있다MapReduce 가 밀려도 HDFS 가 남은 이유입니다 (3·9·18강)
다음으로 갈 곳
이 시리즈는 개념까지만 다뤘습니다. 여기서 더 나아가고 싶다면 방향은 대체로 이렇습니다.
| 하고 싶은 것 | 다음에 볼 것 |
|---|---|
| 직접 돌려보기 | 작은 클러스터를 만들어 파일을 넣고 작업을 제출해 봅니다 |
| 실무에서 쓰이는 계산 | Spark 로 넘어갑니다. 이 시리즈의 개념이 그대로 쓰입니다 |
| 데이터 파이프라인 설계 | 수집·적재·가공·제공의 각 단계를 어떤 도구로 채울지 봅니다 |
| SQL 로 분석 | Hive 또는 클라우드의 조회 서비스로 실제 데이터를 다뤄봅니다 |
정리하면
- MapReduce · HDFS · YARN 은 각각 Spark · 클라우드 저장소 · 쿠버네티스에 자리를 내줬습니다
- 하둡이 못나서가 아니라 네트워크와 비용의 전제가 바뀌었기 때문입니다
- 메타스토어 · 파티션 · 파일 형식은 이름을 바꿔가며 계속 쓰입니다
- Shuffle 비용과 데이터 쏠림은 엔진이 무엇이든 그대로 있습니다
- 규정상 데이터를 밖에 못 두는 곳, 이미 크게 세워둔 곳에서는 지금도 씁니다
- 이 시리즈에서 실제로 남는 건 도구가 아니라 다섯 가지 생각의 방식입니다
마지막 확인 문제
새 프로젝트를 시작합니다. 하루 500GB 씩 쌓이는 로그를 분석해야 하고, 회사는 클라우드를 쓰며, 규정상 제약은 없습니다. 하둡 클러스터를 세워야 할까요?
정답 및 해설 보기충분히 고민해본 뒤 꼭 필요한 경우에만 열어보세요
대체로 안 세웁니다. 클라우드 저장소에 쌓고 필요할 때만 계산 자원을 띄우는 쪽이 낫습니다.
이유는 앞에서 본 그대로입니다. 하루 500GB 면 1년에 180TB 인데, 이걸 담을 클러스터를 24시간 켜두려면 장비와 운영 인력이 계속 듭니다. 반면 배치는 하루 몇 시간만 돌죠. 안 쓰는 시간에 돈이 나가는 구조를 굳이 만들 이유가 없어요.
그런데 이 결정을 내리려면 이 시리즈에서 본 것들을 알아야 합니다. 데이터를 어떤 폴더 구조로 나눌지(파티션), 파일을 얼마나 크게 모을지(작은 파일 문제), 어떤 형식으로 저장할지(Parquet), 집계할 때 어떤 키로 묶을지(쏠림). 저장소가 S3 로 바뀌어도 이 판단들은 그대로 필요합니다.
그래서 하둡을 안 쓰기로 결정하는 데에도 하둡을 아는 것이 도움이 됩니다. 이 시리즈가 하려던 일이 바로 그것이었어요.
시리즈를 마치며
20강을 함께 왔습니다.
1강에서 던진 질문은 "데이터가 커지면 뭐가 문제가 되나"였습니다. 답은 읽는 속도, 고장, 옮기는 비용 세 가지였고, 하둡의 모든 설계가 그 셋에서 흘러나왔죠. HDFS 의 블록과 복제, YARN 의 컨테이너와 스케줄러, MapReduce 의 Map 과 Reduce 가 전부 그 답이었습니다.
그리고 마지막에는 그 답들이 시대와 함께 바뀐다는 것까지 봤습니다. 도구는 바뀌지만 문제는 남고, 그 문제를 보는 눈이 진짜로 남는 것이었어요.
고생하셨습니다. 이제 어떤 분산 처리 도구를 만나도 "이건 무슨 문제를 풀려고 이렇게 생겼을까"를 물을 수 있게 되셨을 겁니다. 그 질문이 이 시리즈에서 가져가실 가장 쓸모 있는 물건입니다.