분산 처리의 필요성
분산 처리의 필요성을 이해하기 위해서는 병렬처리에 대해서 먼저 알아야합니다.
병렬처리
분산 처리의 이해에 기본이 되는 알고리즘이 Divide and Conquer’ 입니다.
이는 알고리즘에서 정렬, 탐색에서 흔히 사용되는 알고리즘이죠.
복잡하고 큰 데이터를 여러 개의 작은 데이터로 나워 각각을 하나의 단순한 문제로 만들어 해결하는 방식입니다.
즉, 큰 문제를 작은 여러 문제로 나눠 단순화하여 각각을 합쳐가면 큰 문제의 답을 도출해내는 방식이죠.
‘Divide and Conquer’의 가장 파워풀한 장점은 병렬성(Parallelism)입니다.
작은 문제들은 각각 독립적이기에 같은 수준의 문제를 해결하는 과정은 서로 영향을 주지 않습니다.
즉, 이는 동시에 여러 문제를 해결해 시간을 단축할 수 있다는 의미이죠.
쉽게 예시를 들어보이자면,
10개의 주문을 받아야하는 경우가 있을 때, 한 사람이 하나의 주문을 받고 있으면 o(10)=o(n)의 시간이 걸리겠죠.
반면에, 10명이 고객 1명씩 전담해서 주문을 받으면 o(1)의 시간이 걸리겠죠.
분산처리의 필요
병렬 처리가 하나의 컴퓨터 안에서 여러 개의 프로세서를 이용해 문제를 해결하는 것이 다라면 그냥 수십 개의 코어를 가진 슈퍼컴퓨터로만 빅데이터를 분석할 수 있겠죠. 그렇지만... 빅데이터 분석은 쉽지 않은 작업입니다. 도메인마다 빅데이터 분석 대상과 방법이 다르고 과정 중 여러 시행착오를 겪고 그때마다 일일히 분석하고 따져보고 적합한 방식을 도출해야하는 등 비용이 많이 듭니다.
이러한 비용을 최소화하고 효율성을 높이기위해 슈퍼컴퓨터 대신 분산처리 기술을 활용하는 것이죠!
이러한 분산 처리는 각종 시스템 자원의 투명성(Transparency)을 보장합니다.
투명성
투명성이란 다수의 컴퓨터로 구성된 시스템을 가상화해 마치 한 대의 컴퓨터 시스템인 것처럼 만드는 특성이다.
투명성의 특징
- 위치(Location)
파일, 입출력 장치, 프로그램, 데이터베이스 시스템 등의 자원이 어떤 컴퓨터에 있는지
알 필요 없이 이용할 수 있게 한다.- 이동(Migration)
자원을 한 컴퓨터에서 다른 컴퓨터로 이동시켜도 사용자가 이를 의식하지 않고
자원을 이용할 수 있게 한다.- 중복(Replication)
동일한 자원이 다수의 컴퓨터에 존재하고 있더라도 사용자에게는 하나의 자원으로
보이게 하는 것이다.- 이기종(Heterogeneity)
분산 시스템이 다른 종류의 하드웨어와 소프트웨어로 구성돼 있더라도 사용자는 이들의
상이함을 의식하지 않고 이용한다.- 장애(Fault)
분산 시스템의 구성 요소(하드웨어, 소프트웨어)가 장애를 일으켜도 서비스를 제공할 수 있게 한다.- 규모(Scale)
분산 시스템의 구성 요소를 추가하거나 제거하는 등 규모 변화에 대해서도 사용자는
이것을 의식하지 않고 시스템을 이용할 수 있게 한다.
모든 특징을 살펴보면 궁극에 어떤 내부사정이든 상관없이 사용자는 그것 알필요 없이 잘 사용만 할 수 있게 ㅎ면된다는 큰 맥락을 공유하고 있습니다.
분산 처리의 종류
분산 처리를 할 수 있는 시스템을 ‘분산 처리 시스템’이라고 부르는데, 하나의 컴퓨터 또는 서버에서 처리하는 방식을 넘어 네트워크에서 원격 컴퓨터와 통신하면서 하나의 목적을 위해 여러 서버에서 연산을 처리하도록 만든 시스템이빈다. 이렇게 여러 서버에서 연산하는 것을 ‘분산 처리’라고 한다.
클러스터
분산 처리를 위해서는 다수의 컴퓨터와 네트워크가 필요하며 이를 클러스터라고 합니다.
클러스터의 기본 구성은 컴퓨터, 고속 네트워크(LAN), 클러스터를 구현할 수 있는 소프트웨어입니다.
슈퍼컴퓨터가 하나의 컴퓨터 안에서 CPU, 메모리를 이용해 서로 통신했다면, 클러스터는 여러 컴퓨터가 LAN으로 통신해 데이터를 처리하는 것입니다.
클러스터는 상대적으로 저렴하고 저성능의 컴퓨터 여러대를 합쳐 슈퍼컴퓨터와 같은 성능을 끌어내는 것입니다.
처리해야할 작업량이 방대한 경우 로드밸런싱을 통해 클러스터로 구성된 여러 대의 컴퓨터에 나눠 처리해 생산성을 높일 수도 있죠, 이 클러스터링이 가장 흔한 경우인 웹서버 클러스터링이라고 합니다.
빅데이터 분석을 위해서는 데이터가 크니깐 이를 나누고 나뉘어진 데이터를 클러스터링된 각 컴퓨터에 보내 처리하고 그 처리된 데이터의 결과를 수집해서 원하는 분석데이터를 얻는 구조인 것입니다.
이러한 빅데이터 분석이 일반화될 수 있도록 클러스터를 쉽게 활용할 수 있는 프레임워크가 바로 "Hadoop"입니다.
Hadoop은 데이터를 나눠 클러스터로 보내고 그 결과를 수집하는 일련의 과정을 제공해 주며 이를 지원하는 프로그래밍이 구글이 만든 MapReduce입니다.
MapReduce
MapReduce는 구글의 웹 데이터 분석 모델로 페타바이트 이상의 대용량 데이터를 저사양 컴퓨터로 구성된 클러스터에서 처리하는 것이 목표였으며, 구글은 2004년 MapReduce 프레임워크와 구글의 분산 파일 시스템 논문을 함께 발표되었습니다.
Hadoop은 이 논문이 공개된 뒤 그 구조에 대응하는 체계로 개발된 것입니다.
MapReduce는 LISP와 같은 함수형 프로그래밍에서 일반적으로 사용하는 Map 함수와 Reduce 함수를 기반으로 합니다. Map()과 Reduce()를 구현함으로써 처리해야할 데이터를 병렬화하는 것이 목적이며 이렇게 병렬화된 데이터는 클러스터의 각 노드로 보내져서 동시에 처리할 수 있게 됩니다.
따라서 개발자는 Map()과 Reduce()만 구현하면 뒷단의 복잡한 분산 처리 과정은 프레임워크가 처리하여 개발자는 데이터 분석에만 집중할 수 있게 되는 것입니다.
MapReduce 데이터 처리 과정
Map
Map()는 임의 키-값 쌍을 읽어서 이를 필터링하거나, 다른 값으로 변환하는 작업을 담당합니다.
보통 어떤한 요소가 몇개 있는지 카운팅하는 작업에도 사용되며Reduce
Reduce는 이렇게 map을 통해 얻게된 카운팅 값을 그룹화하고 그룹화된 값을 집계하는 역할을 담당합니다.즉, 단어를 key값으로 하여 그 개수인 value를 누적, 집계하여 전체 데이터 처리 결과값을 얻을 수 있으며 이때 Map, Reduce 함수와 상관없이 프레임워크에서는 Shuffle이라는 과정을 통해 같은 key 값끼리는 같은 reduce 함수가 호출되도록 합니다.
Hadoop의 진화와 YARN
Hadoop을 통해 데이터를 클러스터 환경에 나눠 처리하는 개념을 배워보았습니다.
그러나 Hadoop에는 병목현상과 클러스터 내 자원의 비효율성이라는 문제점이 있었습니다.
내부적으로 Job Tracker가 다른 Task Tracker를 관리하는 구조인데 이는 즉, Job Tracker가 자원과 Job을 모두 관리한다는 의미입니다.
따라서, 만일 Job Tracker에서 지연이 발생하면 모든 클러스터 노드가 지연되는 것이고 여기서 병목현상이 발생합니다.
또한 하나의 노드에서 실행될 수 있는 MapReduce 작업의 개수가 제한되어있기에 클러스터 내 자원의 비효율적 사용이라는 문제점이 초래됩니다. 하나의 노드에서 작업을 완료해도 아직 처리되지 않은 노드의 작업을 나눠가질 수 없는 구조이죠.
이러한 문제 때문에 기존의 MapReduce 방식을 고전적인 방식으로 정의하고 이를 Hadoop 1.0,
이후 개선된 Hadoop을 Hadoop 2.0이라고 부르게 되엇습니다.
새 버전은 Yarn 아키텍처로 이뤄져있고 yarn은 1.0버전의 한계와 문제점을 해결했습니다.
(좌) 1.0 (우) 2.0
yarn은 1.0의 병목현상을 제거하기 위해 Job Tracker가 하던 관리 책임을 나누어 각각을 담당하는 컴포넌트를 만들었습니다.
Resource Manager(자원 관리)는 애플리케이션 자원을 할당하고, App Master(앱 관리자)를 관리합니다.
그리고 클러스터의 각 노드마다 node manager를 두어 노드의 컨테이너를 관리해 할당된 자원 이상으로 사용하지 않도록 조절합니다.
App master는 실행중인 애플리케이션의 생명주기를 관리하고 상태값을 앱 마스터에게 알립니다. 컨테이너는 실제 앱을 실행하고 상태값을 앱 마스터에게 알리는 구조입니다.
아키텍처를 보면 이전 버전보다 구성 컴포넌트가 더 많아진 것을 보실 수 있습니다.
하둡 1.0의 경우는 MapReduce만을 처리할 수 있는 플랫폼인 반면 하둡 2.0의 경우는 YARN 위에 다양한 솔루션을 올릴 수 있는 구조로 바뀌었습니다.
MapReduce는 물론 Storm on YARN(실시간 스트리밍 처리), HOYA(HBase), Spark on YARN, Apache Giraph on YARN과 같이 다양한 시도가 가능해졌다는 의로. MapReduce/YARN 개념을 이용하여 대용량의 데이터를 나누어 분배할 수 있게 되었습니다.
이는 어떻게 분배할 것인가를 생각할 요하게 되었으며 클러스터에는 데이터를 처리할 수 있는 여러 노드들이 있고, 해당 노드에 어떤 처리를 하도록 스케줄링을 할 필요가 생긴 것이죠.
