.

Data_EngineeringTIL(20190711)

study program : https://www.fastcampus.co.kr/data_camp_hadoop

[학습목표]

• Hadoop 클러스터 구축방법 이해

[학습기록]

1. 하드웨어/네트워크 구성 및 인프라 설계

1) 하둡 인프라 아키텍처

• 1대로 구성 시 : 의사분산모드(통상 개발용)

의사(sudo=가짜)분산모드는 클라이언트, 마스터, 데이터 노드 전체가 1대의 컴퓨터 안에 모두 포함되어 있는 경우를 말한다. 의사분산모드는 보통 개발/테스트용으로 쓴다.

• 2대로 구성 시 : 이중화모드(클러스터 운용가능한 최소단위)

이중화모드 2대의 컴퓨터만 쓰는 것을 말한다. 마스터노드를 2대로 두고, 이 2대의 각각의 마스터노드는 동시에 각각 데이터노드의 역할을 수행한다. 또한 역할부여에 따라 2대 중 1대를 클라이언트로 쓸 수 있고, 아니면 2대 모두 클라이언트로도 쓸 수 있고, 또는 예를들어서 역할이 수집, 전처리, 분석이라면 3개의 클라이언트를 두대의 컴퓨터에 배분해서(컴퓨터1=수집 및 전처리 역할, 컴퓨터2=분석역할) 쓸수도 있다.

• 3대이상으로 구성 시 ~ : 분산모드

분산모드는 컴퓨터 3대 이상을 쓸때를 말한다. 예를들어서 클러스터 구성시 총 3대를 쓴다면 보통 클라이언트 한대를 따로 두고, 나머지 두대로 마스터노드와 데이터노드로 역할을 분배하여 사용한다.

2) 통상적인 하둡 아키텍처 구성양상

아래 그림에서 마스터 노드 1 이 네임노드이고, 마스터 노드 2는 세컨더리 네임노드 즉 보조네임노드이기 때문에 마스터 노드 1이 날라가면 클러스터 전체가 먹통이 되는 것을 방지하기 위해서 마스터 노드 2는 마스터 노드 1의 데이터들을 1시간마다 정기적으로 자동으로 백업한다.

통상적으로 사이언티스트는 클라이언트에만 접속하고, 엔지니어들이 마스터노드와 데이터노드에 접속해서 작업하는 것이 일반적인 양상이다.

위의 그림에서 보면 마스터 노드가 3대가 있는 것을 볼 수 있다. 보통 클러스터를 구성한다고 하면 마스터 노드를 3대를 두는 것이 일반적이다. 여기서 마스터 노드 3은 하둡에서 그 마스터 노드가 아니라 마스터 노드의 데이터들을 백업하고, 클러스터 관리(노드 헬스체크, 노드문제 시 해결 등)를 하는 역할을 한다.

클라이언트도 용도에 따라 여러대를 둘 수 있는데 주의해야할 점은 수집서버와 서비스용 서버는 망이 외부와 연결되어야 하기 때문에 별도로 둬야한다.

시각화 서버 역시 따로 두는것이 좋다. 데이터의 양이 엄청 큰데 분석기능과 뒤섞여 있으면 메모리가 터질 수 있다. 분석서버나 시각화서버 모두 메모리를 엄청 소비하기 때문이다.

웹서버도 가용성을 위해 두대 이상을 두는 것이 좋다.

특정 클러스터 규모 이상이 되면 네트워크 인프라도 동시에 확장시켜줘야 한다. 아니면 구축한 네트워크로 부터 들어오는 데이터 송신속도가 하둡 클러스터의 데이터 처리속도를 따라가지 못해서 비효율적일 수도 있기 때문이다.

또한 주의해야할점이 하둡 클러스터의 노드들끼리의 연결은 외부와 단절된 자체 내부망으로 구성해줘야 한다는 것이다. 에를 들어서 회사 내부망을 하둡클러스터의 노드들이 이용하는 망으로 써버리게 되면 맵리듀스 수행 시 데이터의 이동이 폭증하여 회사 내부의 업무망이 마비가 될수 있다.

• 하둡 클러스터의 개발/파일럿 구성

참고로 맵리듀스는 데몬이 아니다. 맵리듀스는 직접 쓰는 것이 아니라 피그나 하이브, 프레스토 이런것들을 통해서 쓸 수 있다.

2. 하둡 클러스터의 리소스 관리를 위한 YARN 이해

• 하둡의 저장소는 크게 HDFS와 HBase(데이터베이스인데 하둡에 저장한다고해서 Hadoop DataBase인 것이다)로 나뉘어진다. 그 밖에도 몇가지가 더 있고 최근에는 상당히 다양해지고 있다.

• 계산을 담당하는 기능이 얀이다.

• 데몬으로 도는 것이다.

• 얀에서의 마스터노드를 리소스 매니저라고 부른다.

• 어플리케이션은 시작과 끝이 존재하는 프로그램을 말한다.

예를들어 스파크로 어떤 코드실행 시작 누르면 지정된 코드가 수행되면서 끝이 존재한다.

반면에 데몬이라는 것이 있는데 데몬은 백그라운드에서 항상 돌고 있는 것을 말한다. YARN과 HDFS(또는 HBase)는 데몬이다.

위에 그림과 같이 클라이언트에서 뭔가 실행을 하면 전부 일단 리소스 매니저에 간다. 리소스 매니저는 컴퓨팅 자원을 할당해주는 역할을 한다. 자원을 할당해주려면 각 노드에서 노드매니저가 리소스 매니저로 3초마다 한번씩 신호를 보내준다. 어떤 신호냐면 자기 노드가 CPU가 총 몇개가 있는데 몇개는 사용하고 있고, 몇개는 놀고있고, 메모리도 얼마가 있는데 얼마를 쓰고있다, 또한 디스크용량이 얼마나 되는지 이런 신호를 보낸다.

참고로 노드 매니저는 각 노드별의 리소스 관리자인 것이다.

그래서 노드 매니저들로 부터 각 노드별 리소스 현황을 보고 받는 리소스 매니저가 클러스터 전체의 리소스를 관리하는 것이라고 할 수 있다.

그래서 이런 현황을 알고 있는 리소스 매니저(마스터)가 하둡에 있는 모든 데이터 노드를 관리하게 된다. 리소스 매니저는 제일 한가한 노드(노드매니저)에다가 클라이언트가 하고자 하는 일을 할당하게 된다. 그 일을 노드에서 구동을 하는데 그 일을 구동하는데 필요한 맵리듀스를 리소스 매니저에 보고한다. 예를들어 그 일을 실행하려면 맵이 10개가 돌아가야하고 리듀스가 10개 돌아가야합니다라고 위의 3번처럼 리소스 매니저에 보고하고 맵리듀스를 요청한다. 그러면 필요한 맵리듀스 양에 따라 잡을 리소스 매니저에서 각 노드의 상태를 고려해서 지정을 해준다. “사용자가 요청한 잡을 너가 해” 라고 시키는 것이다.

만약에 맵이나 리듀스를 복수개를 해야한하면 그거 역시 리소스매니저가 어떤 노드에서 실행할건지 지정해서 일을 시키게 된다.

아래 그림도 같은 맥락의 내용이다.

위의 그림을 살펴보면 프로그램이 돌아갈때 MRAppMaster(맵리듀스어플리케이션 마스터)라는게 돌아간다. 그리고 얀차일드(프로세스이름)라는게 돌아간다. 예를들어서 맵이 하나만 돌아가는 프로그램이라면 일을 시키는 맵리듀스어플리케이션 마스터 하나와 실질적으로 일을 하는 얀차일드 하나가 총 두개가 돌아간다. 이 두개가 돌아가는게 최소단위이다.

전통적인 하둡에는 맵을 몇개 돌릴지, 리듀스를 몇개돌릴지 프로그램 실행할때마다 지정해야 했는데 최근 하둡은 알아서 자동으로 해준다.

• 프로세스 실행 간 각 노드의 리소스 매니저와 노드매니저의 상호작용 예시

아래 그림에서는 가장 좌측상단에 있는 노드가 MRAppMaster인 것이다. 거기에서 맵리듀스1(남색블럭) 프로그램이 시작되면 MRAppMaster가 리소스 매니저에게 리소스 사용요청을 할 것이다. “나는 일단 맵이 맵1.1(파란색블럭), 맵1.2(파란색블럭) 총 두개가 있어야해. 그니까 리소스매니저야 나 두대의 노드만 좀 사용할 수 있게 허가좀 해주라”라고 요청을 하면 리소스매니저가 “오케이 니옆에 노드 두개를 쓰도록 허가해줄게”라고 두개의 노드를 지정해주면 맵리듀스1 프로그램의 맵 두개가 실행이 된다. 작업이 끝나면 맵1.1와 1.2 공간이 비워지게 된다. 이런 공간을 slot이라고 한다.

그리고 또 다른 프로그램 맵리듀스2(중간에 초록색블럭)을 실행한다. 그러면 해당 노드의 MRAppMaster가 구동되면서 “나는 맵이 2.1,2.2,2.3 3개에 리듀스2.1,2.2 2개 총 5개의 노드가 필요해! 리소스매니저야 나 노드 5개만 쓸 수 있도록 허가해주라”라고 리소스 매니저에게 요청하면 리소스 매니저는 아래 그림과 같이 노드 5개를 할당해준다. 그러면 맵과 리듀스가 순차적으로 실행되게 된다. 실행이 완료되면 해당 공간 역시 비워지게 된다. 만약에 다른 프로그램이 실행되면 그 공간을 점유할 것이다.

참고로 일반적으로는 CPU의 코어 하나당 한개의 슬롯을 할당할 수 있다.

데이터 저장은 HDFS의 Namenode가 알아서 해주고, 자원할당은 얀에 있는 리소스매니저의 노드매니저가 알아서 해주는 것이다.

참고로 슬롯개념은 구버전 하둡의 개념이고, 요즘에는 여러사람이 쓰다보니까 유저개념으로 바뀌었다. 유저마다 자원을 할당해줄 수 있다.

위의 중간그림에서 pro와,dev가 그룹이고, dev 밑에 eng,science가 실제 계정인 것이다.

prod capacity(실제 운영하는데 드는 capacity)가 40이다. dev(개발)은 60으로 할당했다. dev에는 두개의 계정이 있고. 각각 50씩 할당받았다. 이런식으로 자원을 여러유저가 동시에 사용할때 사용자 그룹이나 계정별로 이런식으로 자원할당이 가능하고 이걸 리소스매니저의 스케쥴러라는 얘가 해준다.

위에 중간그림처럼 설정하는 경우도 있는데 하둡에서는 그냥 저 설정파일을 디폴트로 두는 것을 권장한다.

위의 가장 아래그림처럼 얀은 세가지의 스케쥴링 옵션을 부여할 수 있다. 하나는 가장 먼저 요청한 일부터 수행하는 방법, 다른 옵션으로는 위의 중간그림처럼 유저별로 자원을 할당해주는 방법이 있다. 그런데 유저별로 이런식으로 자원을 할당해주게 되면 그림에서 볼 수 있듯이 자원을 풀로 전부 쓸 수 없기 때문에 자원의 낭비여지가 발생한다. 그래서 나온 방법이 마지막 옵션인 페어스케쥴러 방법이다. 이 세번째 방법이 최근에 가장 많이 쓰는 방법이다.

3. 하둡 클러스터 구동을 위한 주요 설정파일

아래 주요설정 파일만 잘 설정하면 하둡이 문제없이 구동된다.

통상 한번 클러스터를 잘 구성해놓으면 아래 설정파일 건들일은 거의 없을것이고, 만약에 그런 경우가 있다면 대부분 데이터노드의 추가와 삭제의 경우일 것이다. 이 경우에는 slaves 파일에서 데이터노드의 추가와 삭제에 대해 설정을 해주면 된다.

아래의 설정파일들에 대한 것들은 관리자의 관리 포인트이기 때문에 액셀등에 아래 설정파일들의 주요내용들을 잘 기록하여 관리해야한다.

예를들어서 hdfs-site.xml에서는 모든 데몬들은 포트가 부여되어 있고 제티라는 웹서버(사용자를 위한 UI)가 내장되어 있고, 각각 통신채널(포트)가 있는데 각 노드별로 부여된 이런 정보를 확인할 수 있다.

hdfs-site.xml에서는 하둡이 어디에 설치되어 있는지, 피그가 어디에 설치되어 있는지도 알 수 있다.

hdfs-site.xml는 일종의 관리 포인트인 것이다.