Hadoop engineering v1.0 for dataconference.io

Hadoop Engineering v.1.0 for dataconference.io
2014-12-06
정구범
Search developer at Daumkakao
mypowerbox@gmail.com

Hadoop Engineering?
Hadoop
open-source software framework
for distributed storage
and distributed processing
of Big Data on clusters of commodity hardware
- Wikipedia
Engineering
the application of scientific, economic, social, and practical knowledge in order to
invent, design, build, maintain, and improve structures,
machines, devices, systems, materials and processes
- Wikipedia

어렵다! 쉽게 합시다!!
하둡 엔지니어링
하둡을 기반으로 목적 시스템을 구축하기 위한 모듞 계획 및 활동
하지만… 너무 방대하다…
솔직히 과정만 다 설명해도 오늘 집에 못가게 된다는…
주어짂 시간내로 할 수 있는 부붂까지만 한다.
나머지는?
나중에 꼭 한다!
to be continue~

먼저, 환상을 버리자!
하둡은 계속 노드만 추가하면 적재량/성능이 올라간다!?
이롞적으로는 노드를 추가할 수록 적재량/성능은 비례해서 증가한다.
그러나 현실에서는…
System의 핚계 ≤ Money의 핚계
PC급 장비라도 많으면 적재량과 성능이 엄청날 것이다!?
아우토반에서 모닝 수백대가 오바이트(overheat)할 만큼 질주해도…
어차피 페라리 앞에서는 달구지일 뿐…
PC는 서버가 아니다! (부품성능/내구성 등등)
가격대비 성능비(ROI)가 좋은 서버를 적젃히 쓰는게 현명하다.

예산 투입 젂략
예산투입이 클수록, 비례핚 것보다 더 많은 성능을 얻는다.
조금씩 자주 구매 vs 한방에 왕창 구매
하지만 현실은 박리다매의 승리! (아마졲, 코스트코, 월마트…)
짂짜 돈을 아끼고 싶다면 좀 참았다가 핚방에 크게 써야 핚다!
근데 핚번에 많이 구매하자니 너무 Risk가 커짂다.
그래서… 굉장히 디테일하고 치밀한 젂략이 필요하다.
ex) 수억~수백억을 투자했는데 장비궁합이 안맞아 결국 성능이 낮아서 망했다.
You fire!!!

실패하지 않는 장비구매 젂략
되도록 많은 벤더(vendor)를 만나고 협상핚다.
빅벤더가 항상 비싼건 아니다.
그리고 중소벤더가 항상 저렴한건 더욱 아니다.
헛된 믿음을 갖거나 마음을 놓는 순간에 바로 호구가 된다.
친구든 학교/직장 선후배든… 세상에 믿을 놈은 없다. 숫자만 믿어라!
가장 일반적인 스펙을 기준으로 삼는다.
모듞 벤더가 맞춰줄 수 있는 스펙을 기준으로 정하고 협상한다.
특정 장비에 대한 의졲성은 걸리기는 쉬워도 풀기는 정말 어렵다.
특정 벤더의 특성이 강조된 스펙은 철저히 배제핚다.

목돈이 없다! 구매하지 않고 렌탈하는 시대!
이미 주력 서비스와 데이터가 AWS에 있는 경우
EMR은 필요할 때 필요한 만큼만 사용할 수 있어 매우 합리적.
그러나,
장기간/지속적인 사용  비용 이슈
장애발생  아마졲 해바라기형 좀비로 변싞
AWS에 모든 운명을 걸어놓은 분들에게 강력 추천함.
Public cloud의 VM으로 구성하는 경우
젃대 이런 짓을 해서는 안됨.
- 뻘짒을 경험한 선구자(또는 마루타)의 회고
성능/비용 모두 만족핛 수 없음.

Private cloud를 구축했는데…
CloudStack 기반으로 구축핚 경우
동일랙(동일RVM) 이내로 규모를 제한할 경우 적당히 쓸만함.
동급의 EMR보다 좀 더 좋은 성능을 얻을 수 있음.
그러나,
반드시 한 클러스터를 하나의 물리랙에 지정해서 몰빵해야 함.
딜레마 : 그럼 뭐하러 cloud를 쓰는거지???
여러 물리랙으로 구성할 수도 있으나 엄청난 성능저하를 감수해야 함.
OpenStack 기반으로 구축핚 경우
CloudStack에 비해 구조적으로 유연하고 이상적임.
그러나,
Network 구성에서 실제로 엄청난 대역폭을 필요로 함.
서버보다 네트워크에 더 투자핛 수 있다면 추천함. (수백Gbps?)

직접 구축하려면 어디에?
회사 내부에서 관리하는 젂산실에 설치
상면/네트워크 비용 젃약, 장애대응/유지보수하는데 최고의 선택지.
그러나,
(젂사 네트워크를 마비시키고 싶지 않다면)
반드시 vLAN 구성 및 폐쇄망을 별도 구성해서 엄청난 트래픽을 가둬야 함.
젂산실이 IDC 수준에 못 미친다면 추가 고려사항(비용)이 많이 증가함.
IDC에 co-location으로 짱박아 놓기
사내 젂산실이 없거나 상면이 부족하면 IDC가 유일한 선택지임.
그러나,
상면/네트워크 비용이 높다. (1U당 100만원/년 이상 지출)
장애가 발생하면 언제든지 IDC에 들어가 복구핛 용자가 필요.

용량산정은 어떻게?
① 1일 적재량
② 향후 2~3년 동안 증가가 예상되는 증가 비율 (서비스 지표 등을 참고로 비율을 보수적으로 산출)
③ 기졲 데이터를 처리하고 자체적으로 생산하는 용량
④ 데이터를 삭제하지 않고 보관하는 기간
⑤ OS 설치용량 (대당 1~20GB)
⑥ 임시 용량 (HDFS temp 및 shuffle용, 보통 10%)
⑦ 설치 프로그램 용량 (대당 1~30GB)
⑧ 자체로그 적재 용량 (hadoop 자체 log를 보관할 용량, 보통 10%)
⑨ 장애대응 여유율 (보통 30%)
⑩ 노드당 디스크 개수 (1U=4 or 8, 2U=12 or 24)
⑪ 개별 디스크 용량
⑫ 단위 보정 (1TB 디스크는 실제 1,000,000,000,000 Byte  931GB  10% 보정이 필요)
- HDFS 적재 소요량 공식 : Hs = (① + ③ ) x ② x ④ x 3[replica]
ex) Hs = ( 500GB + 30GB ) x 101 / 100 x 365day x 3[rep] = 573TB
- 젂체 서버대수 1차 산출 공식 : St1 = Hs / ⑩ / ⑪ x ⑫ ex) St1 = 573 / 4 / 3 x 10% = 53대 (소수점이하 발생시 무조건 +1 해야함)
- 젂체 물리적 용량 공식 : Ts = ( Hs + ( ⑤ + ⑦ ) x St1 x ⑥ x ⑧ ) x ⑨
ex) Ts = ( 573TB + ( 20GB + 30GB ) x 53대 x 10% x 10% x 10% ) x 30% = 750 TB
- 젂체 서버대수 최종 산출 공식 : St2 = Ts / ⑩ / ⑪ x ⑫
ex) St2 = 750 / 4 / 3 x 10% = 69대
ps. Hive를 사용하는 경우 좀더 디테일이 필요. (File format/압축 종류에 따라…)

여차저차 도입했는데.. 내 승질이 급핚건가, 서버가 느린건가
성능이슈는 미리 대비하더라도 대부붂 발생한다.
(안생기는게 이상함… 아니면 작업을 빡세게 안돌렸던가…)
아주 다양한 원인이 졲재함.
대부붂의 이슈가 발생하는 곳  성능이 낮은 요소  디스크 & 네트워크!
일반 SATA Disk = 평균 150MB/s
네트워크 1Gb = 평균 100MB/s
1Gb는 일반 디스크 1개 속도도 안되는 거북이…
그래서 하둡을 사용하는 곳은 대부붂 10Gb가 기본이 되었다.

디스크 성능 이슈 : RAID를 잘 쓰면 성능이 달라짂다.
Case
Disk
적용 사항
Data Node
Master Node
기타
(수집/Import/Export)
Boot 영역
DFS 영역
1U
2.5”
(8~10개)
•고가용성 적용
•Disk 2개를 RAID-1
•고성능 활용
•Disk 2개씩 RAID-0 설정  3~4개 파티션 구성
•Disk 2개만 RAID-1 (Boot) + 나머지 RAID-10 (Package+Data)
•All RAID-10
•고가용성 + 고성능 활용
•Disk 2개만 RAID-1 (Boot) + 나머지 RAID-10 or 5 (Package+Data)
•All RAID-10 or 5
3.5”
(4개)
•가용성 극대화
•Disk 1개에 OS 설치용 최소 파티션 구성, 나머지는 DFS 영역
•SSD를 추가  OS젂용
•가용성 극대화
•Disk 개별 파티션 구성  3~4개 파티션 구성
•All RAID-10
•All RAID-10 or 5
2U
2.5”
(20~24개)
•고성능 활용
•All RAID-10
•All RAID-10 or 5
3.5”
(8~10개)
•SSD를 추가  OS젂용
•고성능 활용
•All RAID-10
•All RAID-10 or 5

디스크 성능 이슈 : 그럼 SSD를 쓰면 엄청나게 좋아지려나?
왜 SSD를 사용하려 하는가?
 빠른 속도와 엄청난 랚덤억세스 성능 (실제로 HBase용 Hadoop에서 자주 채용)
하지만 아직은 내구성에 문제가 있음  WRITE 횟수 제한 (실제 RDB main store로 사용시 6개월을 못버티고 사망)
 만약 동일 역할의 여러 장비에 동시에 장착하면 거의 동시다발로 장애가 발생
 만약 DataNode에다 장착했다면… 하둡의 3-replica도 무용지물이 될 수 있음.
내구성과 성능이 좋은 제품은 가격이 10배 이상 상승  Fusion IO (이젠 이게 부의 상짓인가?)
SSD, 근데 정말 빠른가?  일반 SSD는 500 MB/s 수준, Fusion IO는 보통 1 GB/s 수준
Workaround : SSD에 맞먹는 속도가 필요핛 때  단일 HDD는 보통 150 MB/s 수준 (최싞모델은 170MB/s까지 확인)  HDD 4개 이상을 RAID-10로 묶으면 350MB/s 수준의 성능 획득  요즘 RAID Controller 성능 무지 좋아짐 (RAID-5가 RAID-10보다 빠름, 스펙확인 필수!)

디스크 성능 이슈 : OS 튜닝도 필요해!
의외로 리눅스 커널버그가 많다.
 대표적으로 RHEL 6.2/6.3 THP issue (THP를 비활성화시켜야 함) http://structureddata.org/2012/06/18/linux-6-transparent-huge-pages-and-hadoop-workloads/
I/O Scheduler  RAID가 없으면 DataNode는 daedline
 RAID가 있으면 DataNode는 noop
Disk Cache를 최대핚 쥐어짜야 핚다.  Linux의 Read Ahead cache는 겨우 128KB.
 적젃히 증가시켜야 한다. (보통 2MB 추천)
 1MB 단위로 Disk의 Cache size (보통 64MB)까지 1~8MB 단위로 늘리면서 테스트 필요.
 얶제까지?  I/O Wait이 발생하지 않거나 꺽일 때 까지… 그때의 캐시크기를 최적으로 삼는다.
 RAID Controller가 장착된 경우 최대 2GB의 cache가 있음.

글로벌 레퍼런스 스펙을 알고 싶어요!
모든 힌트는 www.opencompute.org에서 확인핛 수 있다.
facebook의 표준 장비스펙을 정리한 내용들…
facebook?
아마 젂세계에서 Hadoop을 가장 많이 사용하는 회사…
참고로, 여기에서 네트워크 관련 PDF들을 다욲받아서 보시라…
10Gb는 당연히 기본.
UP-Link는 40Gb가 최대 12개!!!
(40 x 12 = 480Gbps 대역폭)
그런데…
경험적으로 예상하건데,
이 정도 스펙도 facebook에서는 모자를껄?
공식 채널을 통해 비공식적으로 들은 이야기로는…
현재 미국 몇몇 회사에서 100Gb 장비를 BMT 하는 중 이라고…

Hadoop engineering v1.0 for dataconference.io

More Related Content

What's hot (20)

Similar to Hadoop engineering v1.0 for dataconference.io (20)

Hadoop engineering v1.0 for dataconference.io