열린마당
2012년 08월 23일 (목)
ⓒ 지디넷코리아, 김우용 기자 yong2@zdnet.co.kr
너도나도 데이터처리 플랫폼으로 하둡을 외치면서, 오픈소스 하둡을 찾는다는 목소리가 곳곳에서 들린다. 하지만 오랜 시간 하둡을 다뤄온 전문가들은 섣부른 접근을 경계한다.
대용량파일 분산처리시스템 하둡은 확장성과 처리속도 등에서 현존 솔루션 중 가장 앞서있다. 때문에 저렴하고 빠른 빅데이터 처리 환경을 구축하기 위한 필수 플랫폼으로 여겨진다.
하둡 전문가들은 이구동성으로 실전 경험을 강조했다. 책과 머리로 공부하는 것과 실제로 운영하는 하둡은 천양지차란 얘기다. 하둡은 마법이 아니란 말도 나온다.
하 둡을 한번이라도 다뤄본 이들은 초기에 잦은 시스템 장애에 곤란을 겪었다고 토로했다. 원인을 찾아 문제를 해결하는 과정이 오래 반복되면서 노하우를 쌓는 과정이 전문가들의 ‘경험’이다. 단기간 프로젝트에서 하둡은 초반의 시스템 장애 속출로 좌초되기 일쑤다.
하둡은 파일시스템을 비롯한 여러 요소를 모아놓은 플랫폼이다. 소프트웨어와 하드웨어를 모두 포함한 아키텍처를 이해해야 하둡의 진정한 성능을 낼 수 있다. 하둡 시스템이 어렵다는 인상을 주는 건 여기에 있다.
|
■하둡의 분산처리는 네트워크로 통한다
여러 문제들의 원인 가운데 네트워크도 중요한 요소다. 하둡의 기본적인 작동원리와 제공 기능이 네트워크와 맞물려 전체 성능에 영향을 미치기 때문이다.
과 거 서버 내외부의 통신(종단 네트워크)만 처리하면 됐던 스위치가 메시구조의 웹2.0과 가상화·클라우드를 만나면서 서버와 서버의 통신(횡단 네트워크)까지 처리해야 하는 상황이다. 종단 네트워크와 횡단 네트워크의 비중은 2대8일 정도로 서버와 서버 간 통신 시 발생하는 트래픽 비중이 월등히 높다.
하둡은 분산파일시스템(HDFS)와 맵리듀스 등을 포함한다. HDFS는 하나의 서버로 동작하는 게 아니라 여러 서버에 설치돼 운영된다. 데이터는 외장 스토리지 대신 서버 내장 디스크를 스토리지로 사용한다.
HDFS는 하나의 네임노드와 세컨드리 네임노드, 다수의 데이터 노드 서버로 이뤄진다. 네임노드는 디렉토리, 파일명, 파일블럭 등을 관리하고, 클라이언트의 파일접근 요청을 처리한다.
파 일은 블록 단위로 나뉜다. 최대 64MB 크기로 쪼개져 여러 데이터노드(디스크)에 분산 저장된다. 블록은 이 과정에서 다른 데이터 노드에 복제본을 저장한다. 기본적으로 3개의 데이터노드에 동일한 블록이 저장된다. 파일을 읽게 되면 네임노드는 데이터노드에 쪼개져있는 블록을 불러와 조합한다. 이처럼 하둡은 동기화와 복제 작업이 쉬지 않고 일어난다.
예를 들어 ‘파일시스템’란 단어를 저장하는 경우 1번 데이터노드에 ‘파일’, 2번 데이터노드에 ‘시스’, 3번 데이터노드에 ‘템’으로 저장된다. 네임노드는 각 블록의 데이터노드 위치를 파악하고 있다가 읽기 요청시 ‘파일시스템’이란 단어로 완성해 보여주는 것이다. 만약, 이 하둡시스템이 3대의 데이터노드를 갖고 있다면 1번에 저장된 ‘파일’이란 블록은 2번과 3번 데이터노드에도 동시에 저장된다. 나머지도 마찬가지다.
이를 네트워크 관점으로 보면 클라이언트가 데이터를 쓰고, 읽는 과정에서 거치는 네임노드, 세컨드리 네임노드, 데이터노드에서 I/O가 발생한다. 또한 데이터노드 간에도 복제본을 생성하는 I/O가 생긴다.
더 구나 하둡은 데이터노드 장애 시 복제본을 다른 데이터노드에 재생성하는 작업이 일어난다. 전문가들은 이를 ‘하둡의 자가 치유 기능’이라는 별칭으로 부른다. 하나의 데이터노드에 한개의 블록만 저장된 게 아니므로, 노드 하나가 죽었을 때 복제를 위한 I/O량이 폭발적으로 늘어난다.
■“빅데이터가 네트워크다”
각 노드는 물리적으로 나뉜 하드웨어로 볼 수 있다. 서버와 서버 사이에 I/O가 발생하는데 이 과정에서 이더넷 네트워크를 거치게 된다. 스위치는 I/O 트래픽을 적절한 곳에 넘겨주는 길이다. 1번 데이터노드가 죽었을 때 복제본이 다른 데이터노드에 새로 생성되면 그 트래픽이 엄청나다. 이때 백업받는 데이터노드의 자원이 과부하를 일으켜 동반 장애를 일으킨다.
결과적으로 작은 크기지만 빈도가 많다면 제한된 대역폭과 처리속도 한계로 네트워크가 죽어버린다. 이는 전체 시스템 장애로 이어진다. 조각난 파일들을 읽어내는 관문이 막힌 셈이기 때문이다.
이 를 위한 해결방안은 간단히 대역폭이 큰 인피니밴드를 떠올릴 수 있다. 고성능컴퓨팅(HPC)나 메인프레임, 어플라이언스 등에서 활용되는 인피니밴드는 고가란 점이 문제다. 저렴한 비용을 강점으로 내세우는 하둡과 조합되기 어렵다. 더구나 40Gbps 대역폭으로 길을 넓혀도 한계가 있다.
이를 위해 네트워크 업계는 대역폭과 버퍼를 늘리는 방법으로 접근했다. 이와 별개로 기본적인 패킷 처리 방식을 바꾸는 새로운 접근법이 나오게 된다. 이른바 ‘빅데이터 스위치’다.
시 스코시스템즈는 ‘빅데이터도 네트워크다’라고 설명한다. 데이터 처리 과정에서 CPU와 디스크 간의 무수한 입출력이 발생하고, 복수의 트랜잭션이 여러 서버를 오가며 동시다발적으로 일어나기 때문에 네트워크에 대한 고려가 필수적이란 설명이다.
전 통적인 이더넷 네트워크는 트래픽을 처리할 때 정합성을 검증한다. 공항의 보안검색대처럼 일단 세워놓고 머리부터 발끝까지 검사한 후 통과여부를 결정하는 형태다. 이를 ‘스토어앤드포워드 스위칭(Store and Foword)’이라 부른다. 아무리 작은 트랜잭션이라도 반복되면 정체가 생기고 네트워크가 죽는 상황이 벌어진다.
빅데이터 스위치는 전체를 검증하는 대신 패킷의 목적지만 검사한다. 목적지만 확인하고 다음단계로 이동시킨다. 이를 ‘컷스루스위칭(Cut and Through)'을 사용하는 것이다. 때문에 데이터가 아무리 커도 응답시간이 일정해 처리지연을 유발하지 않는다. 이를 이용하면 하둡의 확장성을 안정적으로 확보할 수 있다.
시스코코리아 관계자는 “빅데이터에서 네트워크를 고려하지 않으면 스케일아웃을 실현하기 어렵다”라며 “현재 빅데이터와 하둡을 사용할 때 대부분 네트워크를 스케일업하는데 집중하고 있어 어려움을 겪는 것이다”라고 설명했다.
전문가들은 “하둡을 처음 사용하다가 장애를 겪어서 문제점을 찾아보면 아키텍처 이해가 부족했던 것을 알게 된다”라며 “시행착오를 겪으면서 문제점을 해결해 나가다 보면 안정성을 유지하는 건 어렵지 않다”라고 설명했다.
※ 본 내용은 (주)메가뉴스(http://www.zdnet.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒ 지디넷코리아. 무단전재 및 재배포 금지
[원문출처 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120821153025&type=xml]
| 번호 | 제목 | 조회수 | 작성 |
|---|---|---|---|
| 공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 294090 | 2020-10-27 |
| 공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 284660 | 2020-10-27 |
| 313 | VM웨어 깜짝발표, vRAM 라이선스 폐지 | 5812 | 2012-08-29 |
| 312 | 삼성 타이젠, '脫 안드로이드 효과' 멀었나 | 5322 | 2012-08-29 |
| 311 | VM웨어, ‘못생긴 누이’라던 오픈스택에 구애…왜? | 6091 | 2012-08-28 |
| 310 | 트위터, 리눅스재단 합류 | 5624 | 2012-08-28 |
| 309 | DBMS업계, 빅데이터 주도권 경쟁 | 6145 | 2012-08-28 |
| 308 | "안 파는 SW기술ㆍ제품 기부하세요" | 5244 | 2012-08-28 |
| 307 | [9월 6일~8일] 2012 IT 엑스포 부산, 공개SW 우수성을 알리다 | 5610 | 2012-08-28 |
| 306 | 야인소프트, 통계 분석 언어 `R` 지원 | 5900 | 2012-08-23 |
| 305 | “SW 전문가 부족? 벤처에서 키워주마” | 5705 | 2012-08-23 |
| 304 | 빅데이터와 하둡, 네트워크 챙겨라 | 5790 | 2012-08-23 |
0개 댓글