[빅데이터 전문가의 하둡관리] 6. 클러스터에서 애플리케이션 실행하기 - 스파크 프레임워크

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788931555752

빅데이터 전문가의 하둡 관리 - 교보문고

위 책의 내용을 읽으며 공부한 내용을 요약 및 정리한 글입니다. 자세한 내용은 위 책에서 알 수 있습니다.

 

스파크는 무엇인가?

스파크의 목표는 인터랙티브하고 반복적인 컴퓨팅을 하는 데 있어 맵리듀 모델이 갖고 있는 비효율성을 극복하는 것이다.

왜 스파크인가?

맵리듀스는 지난 수년 간 하둡 클러스터의 핵심적인 프로세싱 프레임워크로 많이 사용되어왔다. 다음은 맵리듀스 프로그램의 단점이다.

• 프로그램 개발 편의성: 맵리듀스는 어떤 업무를 수행하는 단계들이 필요하다. 즉, 각각의 애플리케이션을 위한 특별한 시스템이 필요하다.
• 맵리듀스는 각 계산 단계들 사이에 중간 데이터를 디스크에 입력한다. 데이터를 다시 사용하는 분석이나 반복적인 알고리즘 같은 애플리케이션에게는 상당히 비효율적이다.

다음은 맵리듀스와 비교했을 때 스파크가 갖고 있는 장점이다.

속도

하둡은 데이터가 있는 곳에서 프로세싱이 이뤄져야 한다는 아이디어에 바탕을 두고 있다. 스파크는 이런 기본적인 아이디어에 더해 데이터는 메모리에서 처리돼야 하고, 프로세싱을 잘할 수 있도록 실행 계획을 사용해야 한다는 원칙을 갖고 있다.

• 데이터 스토리지로 메모리 사용. 스파크는 메모리를 순수하게 계산하는 데 사용하는 맵리듀스와 달리 애플리케이션이 동작하는 동안 계산과 데이터 스토리지 둘 다를 위해 메모리를 사용한다.
• 비용이 덜 드는 셔플
• 더 적은 I/O 동기화 베리어

스파크는 맵리듀스처럼 잡을 여러 단계가 있는 비순환 방향 그래프로 변환시킨다. 비순환 방향 그래프가 더 복잡할수록 맵리듀스와 비교했을 때 스파크의 실행 능력이 더 뛰어나다.

스파크의 우월함을 설명하는 2개의 핵심적인 요소가 있다. 스파크의 실행 엔진과 인메모리 클러스터 컴퓨팅이다.

스파크의 향상된 실행 엔진

스파크는 맵리듀스와 달리 잡을 꼭 두 단계로 제한하지 않는다. 원한다면 얼마든지 단계를 만들어 낼 수 있다. 스파크는 잡이 여러 단계로 이뤄져 있음을 인지하고, 이 정보를 이용해 잡 실행을 최적화할 수 있다. 데이터 셔플과 디스크 I/O를 최소화하는 방향으로 최적화할 수 있다.

스파크의 인메모리 계산

I/O 지연 시간은 항상 전체 잡 실행 시간에서 상당 부분을 차지한다.

 

스파크는 데이터 프로세싱 파이프라인에 캐시를 할지, 어떤 데이터를 캐시해야 할지를 정한다. 데이터를 한 번만 쓴다면 어떤 데이터도 캐시하지 않을 수도 있다.

 

스파크는 클러스터를 이루고 있는 서버에서 실행되도록 만들어졌다. 분산 스토리지에서 잘 동작한다. 스파크가 데이터 지역성을 지원하고 있기 때문이다. 데이터가 있는 곳으로 실행할 코드를 보내는 것이다.

사용과 접근의 용이함

다양한 언어를 지원하고, 맵리듀스로 힘든 다양한 오퍼레이션이 가능하다.

다목적 프레임워크

• 배치 프로세싱
• 상호 분석 / 인터랙티브 분석
• 스트림 프로세싱
• 머신 러닝
• 그래프 컴퓨팅

맵리듀스를 가지고 배치 이외의 다른 작업을 할 때, 다른 프레임워크를 사용할 필요가 있다. 개발자의 생산성을 저해한다. 반면, 스파크를 사용하면 모든 작업을 실행하는 데 옹일한 프레임워크를 사용할 수 있다. 이는 또한 다수의 프레임워크에 데이터를 저장하기 위해 복제하지 않아도 된다는 것을 의미한다.

특히 반복적인 데이터 프로세싱 및 상호 분석에 유리하다.

스파크 실행 모드

로컬 모드

단일 서버 사용, 비분산형 모드. 개발 및 테스트 용도로 사용한다.

클러스터 모드 

• 스파크 독립형 클러스터: 실행하기는 매우 쉬우나, 환경 설정에 제한이 있고 확장 가능성이 별로 없다. 테스트 또는 개발용
• 메소스: 스파크가 지원되는 기본 플랫폼
• 하둡 얀: 얀 위에서 랩리듀스나 임팔라와 같이 서로 다른 애플리케이션 프레임워크가 함께 실행될 수 있다.

클러스터 매니저 이해하기

독립형 클러스터 매니저의 아키텍처

워커와 마스터 프로세스를 사용한다. 워커 프로세스는 각각의 클러스터 노드들에 있는 CPU/램 같은 리소스들을 관리한다. 마스터는 리소스 풀을 만들고 이를 여러 애플리케이션에 할당하는 일을 한다.

• 드라이버 프로그램: 데이터 프로세싱 로직으로 구성된 메인 스파크 애플리케이션이다.
• 익스큐터: 각 워커 노드에서 실행되는 JVM 프로세스. 익스큐터는 드라이버 프로그램이 서밋하는 잡을 프로세싱.
• 태스크: 태스크는 데이터 처리 잡의 하위 구성 요소다.

독립형 스파크 클러스터 설정 방법

• 스파크 바이너리들을 6개의 노드 모두에 설치(1개의 마스터와 5개의 워커 노드들)
• 클러스터 모드 노드의 PATH 환경 변수에 /path/to/스파크/sbin를 설정

마스터 프로세스와 워커 프로세스 시작/중지하기

서버들 중 하나에서 마스터 프로세스 시작시킨다.

/path/to/spark/sbin/start-master.sh

모든 클러스터 노드들에 있는 워커 프로세스들을 시작한다.

/path/to/spark/sbin/start-slave.sh <master-URL>

 

마스터, 워커 프로세스 시작 및 중지 스크립트

/path/to/spark/sbin/stop-master.sh
/path/to/spark/sbin/stop-slave.sh

얀에서 스파크 실행하기

얀으로 스파크를 실행한다면 워커 노드들에서 동작하는 리소스 매니저와 노드 매니저가 스파크 애플리케이션 프로세스들을 관리한다.

얀이 스파크 독립형 클러스터 매니저보다 더 바람직한 이유

• 맵리듀스, 스파크 그리고 테즈 같은 프레임워크들을 동일한 클러스터에서 함께 사용하는 것은 매우 자주 있는 일이다. 얀은 이런 모든 애플리케이션이 동일한 클러스터 리소스 풀을 공유하게 한다.
• 캐패시티 스케줄러와 페어 스케줄러 같은 얀 스케줄러를 사용해 클러스터의 작업 부담을 나누고 우선순위를 매길 수 있다.
• 스파크 애플리케이션을 스파크 독립형 클러스터를 통해 실행하면 애플리케이션은 얀 클러스터의 모든 노드에 익스큐터 프로세스를 실행한다. 얀 클러스터라면 익스큐터의 수를 설정할 수 있다.
• 하둡 클러스터에 커버로스를 활성화시켜 프로세스 사이에 인증을 강화하는 것이 쉽다.

얀과 스파크가 함께 연동되는 방식

스파크 애플리케이션은 클라이언트로 동작한다. 이 애플리케이션이 얀의 리소스 매니저에게 잡을 제출한다.

 

얀은 클러스터에서 잡을 소유하고 실행하는 애플리케이션마스터들(애플리케이션 마다 하나씩 생성)을 갖고 있다. 애플리케이션마스터는 잡 실행을 위해 필요한 리소스를 리소스 매니저와 협상한다. 애플리케이션마스터가 리소스를 할당받으면 클러스터 노드에 컨테이너를 실행한다. 컨테이너는 각 노드에서 실행되는 노드매니저와 협력한다.

 

애플리케이션의 생성과 리소스들의 분할에 관한 모든 것은 맵리듀스 애플리케이션이나 스파크 애플리케이션이 동일하게 동작한다. 애플리케이션마스터는 프로세싱 프레임워크에서 제공되는 것을 사용해야 한다는 점을 이해해야 한다. 스파크는 자체 애플리케이션마스터를 라이브러리로 제공한다.