한 대로는 감당이 안 되는 순간
Article
하둡을 배우기 전에 먼저 답하고 넘어가야 할 질문이 하나 있습니다.
"데이터가 커지면 정확히 뭐가 문제가 되나요?"
이 질문을 건너뛰고 HDFS니 MapReduce니 하는 이름부터 외우면, 왜 그렇게 복잡하게 만들었는지 끝까지 이해가 안 됩니다. 낯선 용어만 잔뜩 외운 채로 남게 되죠.
이 시리즈는 하둡을 설치하지 않습니다. 명령어도 거의 나오지 않아요. 대신 "왜 이렇게 생겼는가"를 끝까지 따라가 봅니다. 그림 몇 장으로 구조가 손에 잡히면, 나중에 실제로 클러스터를 만지든 Spark 로 넘어가든 길을 잃지 않습니다.
첫 시간에는 코드 한 줄 없이, 컴퓨터 한 대가 무너지는 지점만 정확히 짚어보겠습니다.
상황을 하나 정해두고 가겠습니다
쇼핑몰 서버가 남기는 접속 기록이 있다고 해볼게요.
- 하루치 로그: 약 300GB
- 1년치를 모으면: 약 100TB
- 하고 싶은 일: "지난 1년간 가장 많이 검색된 단어 100개"
엑셀은 당연히 안 되고, 평소 쓰던 데이터베이스에 넣어봐도 답이 안 나옵니다. 왜 안 나오는지가 핵심입니다.
먼저 무너지는 건 저장 공간이 아닙니다
100TB 를 담을 디스크는 살 수 있습니다. 저장 자체는 돈으로 해결되는 문제예요. 그런데 그 100TB 를 처음부터 끝까지 한 번 읽는 데 얼마나 걸리는지 계산해보면 이야기가 달라집니다.
디스크 하나가 데이터를 읽어내는 속도는 초당 100MB 안팎입니다.
디스크 한 대로는 11일이 넘게 걸립니다. 아무 계산도 하지 않고 그냥 읽기만 했을 때가 그래요. 오늘 질문을 던지면 답은 다음 주에 나옵니다. 그 사이에 데이터는 또 3TB 쌓이고요.
두 번째 벽은 고장입니다
디스크 100대로 나눠 읽으면 3시간이면 끝납니다. 좋습니다. 그런데 장비가 100대가 되는 순간, 없던 문제가 새로 생깁니다.
디스크 한 대가 1년 안에 고장 날 확률을 2% 라고 해볼게요. 한 대만 쓸 때는 신경 쓸 일이 거의 없습니다. 몇 년에 한 번 있을까 말까 한 사고니까요. 그런데 1,000대를 돌리면 1년에 스무 대쯤은 반드시 죽습니다. 확률이 올라간 게 아니라 대수가 늘었을 뿐인데 결과가 완전히 달라집니다.
- 장비 1대고장은 사고입니다. 나면 사람이 고칩니다
- 장비 100대고장은 가끔 있는 일이 됩니다
- 장비 1,000대고장은 일상입니다. 매주 일어납니다
여기서 갈림길이 나옵니다.
- 고장을 막는 쪽으로 갈 것인가 — 비싸고 튼튼한 장비를 삽니다
- 고장을 견디는 쪽으로 갈 것인가 — 싼 장비를 쓰되, 죽어도 일이 안 멈추게 만듭니다
하둡은 두 번째를 골랐습니다. 이 선택 하나가 하둡의 거의 모든 설계를 설명해줍니다. 앞으로 보게 될 복제, 하트비트, 재시도, 추측 실행이 전부 이 결정에서 흘러나온 것들이에요.
세 번째 벽은 데이터를 옮기는 비용입니다
100대에 데이터를 나눠 뒀다고 해볼게요. 계산은 어디서 할까요?
한 대에 프로그램을 띄우고 나머지 99대에서 데이터를 끌어오는 방식이 먼저 떠오릅니다. 익숙한 그림이죠. 데이터베이스에서 데이터를 받아 서버가 처리하는 방식이 늘 그랬으니까요. 그런데 그건 100TB 를 네트워크로 통째로 실어 나른다는 뜻입니다. 디스크보다 네트워크가 훨씬 좁습니다.
데이터를 계산 쪽으로
익숙한 방식
- 100TB 가 네트워크를 타고 흐릅니다
- 받는 쪽 한 대가 병목이 됩니다
- 장비를 늘려도 별로 안 빨라집니다
계산을 데이터 쪽으로
하둡의 방식
- 옮기는 건 프로그램 몇 MB 뿐입니다
- 각 장비가 자기 디스크만 읽습니다
- 장비를 늘린 만큼 빨라집니다
프로그램은 몇 MB, 데이터는 100TB 입니다. 어느 쪽을 옮기는 게 싼지는 재볼 것도 없죠. 그런데 이 뒤집기가 말처럼 간단하지는 않습니다. 프로그램을 100대에 뿌리려면 "이 프로그램은 조각 단위로 따로 돌려도 결과가 같다"는 보장이 있어야 하거든요. 그 보장을 강제하는 틀이 바로 MapReduce 입니다.
세 개의 벽, 세 개의 답
| 벽 | 한 대일 때 | 하둡의 답 |
|---|---|---|
| 읽는 속도 | 100TB 훑는 데 11일 | HDFS — 파일을 잘라 여러 대에 흩어 둡니다 |
| 고장 | 죽으면 전부 멈춥니다 | 복제 — 같은 조각을 3벌씩 둡니다 |
| 옮기는 비용 | 데이터를 끌어옵니다 | MapReduce — 계산을 조각 옆으로 보냅니다 |
하둡은 이 세 벽에 대한 답을 각각 하나씩 들고 있습니다. 그래서 하둡이 하나의 프로그램이 아니라 여러 덩어리로 나뉘어 있는 거예요. 그 덩어리들의 이름과 자리는 3강에서 지도로 그려보겠습니다.
정리하면
- 데이터가 커질 때 먼저 무너지는 건 저장 공간이 아니라 읽어내는 속도입니다
- 장비를 1,000대로 늘리면 고장은 사고가 아니라 평상시 상태가 됩니다
- 그래서 하둡은 고장을 막는 대신 견디는 쪽을 골랐습니다
- 100TB 를 옮기는 것보다 몇 MB 짜리 프로그램을 옮기는 게 훨씬 쌉니다
- 이 세 가지가 각각 HDFS · 복제 · MapReduce 로 이어집니다
확인 문제
디스크 100대에 데이터를 나눠 두고, 그중 한 대에만 프로그램을 띄워 나머지 99대에서 데이터를 받아와 계산했습니다. 장비를 200대로 늘리면 처리 시간이 절반이 될까요?
정답 및 해설 보기충분히 고민해본 뒤 꼭 필요한 경우에만 열어보세요
아닙니다. 거의 그대로거나 오히려 느려집니다.
이 방식의 진짜 병목은 디스크가 아니라 계산하는 한 대로 몰리는 네트워크입니다. 장비를 200대로 늘리면 데이터를 보내는 쪽만 늘어날 뿐, 받는 쪽 통로의 크기는 그대로예요. 오히려 한 대에 몰리는 트래픽이 심해집니다.
장비를 늘린 만큼 빨라지려면 읽는 곳과 계산하는 곳이 같아야 합니다. 이게 다음 시간에 볼 스케일아웃의 조건입니다.
다음 강의
더 좋은 컴퓨터 한 대를 살 것인가, 평범한 컴퓨터를 여러 대 묶을 것인가. 스케일업과 스케일아웃의 갈림길에서 하둡이 어느 쪽을 골랐는지, 그리고 그 선택의 대가로 무엇을 포기했는지 살펴보겠습니다.