Amazon EMR Deep Dive 필기노트

2019-10-30

Data Engineering

Data_Engineering_TIL_(20191030)

[학습한 Contents]

1) 주제 : AWS 월간 웨비나 / Amazon EMR Deep Dive - AWS EMR 활용 및 구축 패턴 by 홍준혁

2) URL : https://www.youtube.com/watch?v=C1WRfjaUBEg

[필기노트]

본 세션의 주요주제

1) EMR과 기존의 Hadoop과 대비해서 공통점, 차이점, 장단점

2) EMR 아키텍처

3) EMR 구축과 운영 노하우

4) EMR을 활용한 구축패턴

EMR과 기존의 Hadoop과 대비해서 공통점, 차이점, 장단점

하둡은 고가용성의 분산된 대용량 데이터를 처리하고 저장하는 하나의 플랫폼이라고 할 수 있다.
대용량 데이터 처리를 위한 프레임워크

[분산처리]

[하둡 분산파일시스템]

여러개의 저사양 서버를 마치 하나인것처럼 묶어서 분산된 환경의 데이터를 저장하고 분산된 환경에서 데이터를 처리하게 된다. 즉 하둡은 수천대의 컴퓨팅장치에 대용량 데이터를 저장하고 처리할 수 있는 플랫폼이다.

Hadoop 1.0버전

하둡은 다양한 요구사항에 따라 변화하고 있다. 하둡 1.0버전은 분산파일시스템 위에 데이터를 처리하는 데이터 프로세싱과 클러스터의 리소스 관리를 단일계층에서 수행하는 방식이었다. 데이터를 읽어서 처리하는 맵리듀스로 이루어진 대표적인 환경이다.

[클러스터 리소스 관리 및 데이터 처리]

[하둡 분산파일시스템]

Hadoop 2.0버전

기업의 비지니스 환경에 하둡의 적용을 위해서 하둡 2.0에서는 리소스와 데이터 처리를 분리하여 다양한 어플리케이션을 지원하는 플랫폼으로 발전하게 되었다.

[데이터 처리]

[클러스터 리소스 관리]

[하둡 분산파일시스템]

하둡을 활용하는 다양한 어플리케이션

분산된 환경을 지원하는 여러 어플리케이션이다. 여러 신규 어플리케이션이 지속적으로 생겨나고 있다. 또는 기존 상용어플리케이션도 하둡을 다양한 방식으로 지원하고 있다. 우리는 이를 에코시스템이라고 부른다. 하둡과 기업의 비지니스, 기업의 어플리케이션을 지원하는 다양한 에코시스템을 통해서 업무의 목적에 따라 다양한 환경을 구축할 수 있게 되었다.

하둡과 에코시스템을 통해 얻을 수 있는 이득

그래서 우리는 하둡을 통해서 다양한 형태의 데이터를 수집할 수 있게 되었고, 수집된 데이터를 분석하고 혹은 실시간 데이터를 처리할 수 있다. 혹은 머신러닝 딥러닝 같은 고급분석 기술도 하둡과 에코시스템을 통해 활용할 수 있게 되었다.

1) 대용량 데이터 분석

2) 실시간 데이터 처리

3) ML/DL 등에 활용

4) 엔터프라이즈 업무와 상호연동

하둡의 향후 보완사항

1) 하둡 클러스터 변화가 업무환경이 변하는 속도를 따라갈 수 있어야 한다.

2) 어플리케이션 호환성 확보

3) 데이터간 연계 구성

4) 중요 데이터 백업/복구

AWS EMR

1) 관리형 하둡 플랫폼

관리적인 측면에서 많은 번거롭고 어려운 점을 줄여줌

2) 맵리듀스, 스파크, 프레스토 등 활용가능

3) 수분내 클러스터 구축가능

새로운 신규비지니스 아이더가 발생하였을때 이 아이디어를 빠르게 테스트하고 활용할 수 있다.

4) 오픈소스 기반의 경험 재활용

다양한 오픈소스에 대한 경험을 동일한 환경에서 사용할 수 있도록 제공

5) 사전 검증된 호환성 제공

6) 클라우드의 유연성을 내포

7) 다양한 AWS Service와 연계 용이

8) AWS의 보안기능 제공

9) 사용한만큼 지불하는 과금시스템

10) 소프트웨어나 설정파일 튜닝 등 커스터마이징 가능

AWS EMR 아키텍처

EMR 클러스터 구성 및 역할

마스터노드

1) EMR 클러스터의 머리역할

2) 전체 하둡 클러스터의 리소스(CPU,하드,메모리,네트워크 등) 관리를 위한 리소스매니저 역할

3) 분산된 환경에 저장된 데이터의 관리를 수행하는 네임노드 역할

4) 기타 EMR에서 제공하는 여러 아파치 에코 어플리케이션 활용시 다양한 사용자 접속을 위한 Ui를 마스터노드에 포함하였음. 그래서 사용자는 마스터노드에 접속해서 다양한 관리 및 작업의 수행이 가능함

코어노드

1) 실제 작업이 수행되는 노드

2) 마스터노드가 관리를 위한 노드라면 코어노드는 실제 작업을 담당하고 있다.

3) 우리가 수행해야하는 작업의 형태 혹은 저장되어야 하는 데이터의 양을 위해서 클러스터 운영중에 확장 및 축소가 가능하다.

예를들어서 우리가 수행해야하는 job이 더 많은 저장공간을 필요로 하는 경우 혹은 더 많은 cpu,메모리 리소스가 필요한 경우에 코어노드를 확장함으로써 자원을 조절할 수 있다.

4) 마스터노드는 하둡 파일시스템을 갖고 있지는 않다. 하지만 코어노드는 하둡의 파일시스템을 갖고 있다.

5) 마스터노드는 클러스터 전체를 관리하는 리소스매니저를 갖고 있지만, 코어노드는 실제 잡의 수행에 대한 노드매니저를 갖고 있다.

테스크노드

1) 테스크노드는 저장영역인 하둡의 파일시스템을 갖고 있지 않다.

2) 코어노드는 하둡의 파일시스템, cpu, 메모리 등의 리소스를 갖고 있는데 만약에 작업양이 많아서 보다많은 cpu와 메모리가 필요한 경우에는 하둡의 파일시스템은 굳이 필요없는데 이런경우 테스크노드를 추가하여 cpu와 메모리의 리소스를 확보하여 보다 빠른작업을 할 수 있다.

테스크노드는 작업의 처리를 위한 리소스를 가질뿐 저장공간을 가지지 않기 때문에 실제 테스크노드가 작업의 처리를 위해서는 코어노드의 하둡 파일시스템으로부터 데이터를 읽어서 처리하게 된다. 만약 나의 어플리케이션이 수행하는 과정에서 mapper 또는 reducer가 부족해서 작업의 지연이 발생하는 경우 우리는 테스크 노드를 추가해서 이런 리소스를 확보해서 우리가 원하는 잡을 좀더 빠르게 처리할 수 있다.

또한 작업이 처리가 된 후 만약에 테스크노드가 필요가 없다면 우리는 테스크노드를 바로 제거해서 비용을 절약할 수 있다.

또한 테스크노드를 활용하는 장점중에 하나는 저장소인 HDFS를 갖고있지 않아서 추가하거나 혹은 제거하여도 HDFS에서 발생하는 데이터복제로 인한 I/O가 추가생성되지 않는다. 따라서 운영중인 업무의 I/O에 영향을 주지 않고도 우리가 리소스를 확장하고 축소 할 수 있다.

EMR 구성팁 : 업무변화에 따라 리소스 할당 및 해제

업무상황에 따라 코어, 테스크노드를 유연하게 추가 또는 제거하여 활용한다.

기존 하둡클러스터는 어떠한 이유로 예를들어 리소스가 부족해서 혹은 디스크 공간이 부족해서 노드가 추가되면 그 노드를 사용하던 사용하지 않던 인프라의 비용, 관리의 비용이 추가적으로 발생을 했다. 하지만 EMR에서 제공하는 코어, 테스크노드 확장기능을 이용하면 추가비용이 상대적으로 적고 간편하게 클러스터 크기를 조절할 수 있다.

온프라미스에서의 동적인 자원확장의 용이성이 EMR에서는 훨씬 크다고 할 수 있다.

EMR 구성팁 : 스팟 인스턴스를 활용한 비용절감

또한 EMR은 온디멘드 인스턴스 뿐만 아니라 스팟 인스턴스를 제공하고 있다. 그래서 온디멘드 인스턴스 비용대비 저렴한 스팟 인스턴스를 활용하면 더 많은 리소스를 더욱 저렴하게 사용할 수 있다.

스팟인스턴스 활용예시

EMR 클러스터 생성 시 스팟 인스턴스의 갯수와 가격의 입찰을 조절해서 보다 효율적인 EMR 클러스터 구축이 가능하다.

EMR 구성팁 : 다양한 종류의 인스턴스를 활용한 EMR 구성

기존의 온프라미스 환경에서 하둡의 클러스터를 추가할때 업무의 목적과 용도, 성능 등의 맞추어 획일화 된 노드구성을 하였는데 우리가 수행하는 작업의 형태에 따라 다양한 리소스의 타입이 필요할 수 있다. 예를들어서 연산이 많이 필요한 경우에는 cpu와 메모리 사양요구가 커지게 되고, 혹은 데이터를 읽고 쓰는 행위와 같은 I/O가 많이 필요한 경우에는 디스크를 보다 더 고성능으로 갖추어야 한다. EMR은 노드의 역할에 따라 혹은 작업의 환경에 따라 다양한 인스턴스 타입을 결정할 수 있다. 그래서 비용적인 측면, 성능적인 측면 모두 효율화 할 수 있다.

EMR 인스턴스 확장 및 축소업무의 예시

1) 일/주간/월간 등의 일정시점에 수행되는 배치업무

2) 멀티 워크로드 동시수행

다양한 워크로드들이 동시에 수행되는 경우

3) 가변 데이터 용량처리 및 고정된 처리시간 달성

어떤날은 데이터가 많이 늘어나고, 어떤날은 데이터가 줄어들지만 동일한 처리시간을 달성해야하는 경우

클러스터 축소 시 주의사항

클러스터 규모를 축소하는 경우 특히 코어노드의 경우에 축소를 하는경우 코어노드는 하둡의 파일시스템인 HDFS를 갖고 있기 때문에 코어노드가 축소되는 경우 기존 운용중인 업무에 대한 영향도를 최소화하고 데이터를 보호하기 위해 I/O 부하가 적은 시간에 선택하는 것을 권장한다. 또한 데이터의 저장공간이 빠짐으로써 실제 남아있는 여유공간이 어느정도 되는지를 사전에 확인해서 축소시에 기존의 남은 저장공간이 부족해서 발생할 수 있는 애러를 방지해야한다.

EMR 클러스터 생성과정

STEP 1) 인스턴스(노드)의 사양을 선택

인스턴스의 사양이 결정되면 우리는 노드의 규모를 결정하면 된다. 마스터노드, 코어노드, 테스크노드의 개수를 초기에 선택을 할 수 있다. 결정 시 베이직 옵션과 상세옵션중에 선택해서 결정하면 된다.

STEP 2) 클러스터에 적용하고 싶은 하둡애코 어플리케이션을 선택

EMR은 다양한 하둡애코 어플리케이션을 지원하고 있다.

STEP 3) 클러스터 접근방법 선택

클러스터 생성완료!!

클러스터 생성후에도 콘솔에서 자원확장, 보안그룹 설정 등 다양한 설정적용이 가능하다.

클러스터 접근방법

EMR 클러스터로의 접근은 DNS 기반의 인포메이션을 제공하고 있다. 즉 마스터노드 DNS를 통해서 사용자가 마스터노드에 접속할 수 있다.

이를통해 우리가 적용한 하둡애코 어플리케이션의 ui역시 접속해서 관리할 수 있다.

각 어플리케이션이 사용하고 있는 포트는 http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-web-interfaces.html 에서 확인할 수 있다.

효율적인 EMR 운영방안

EMR은 다양한 종류의 스토리지 데이터처리가 가능

1) HDFS

2) S3(EMRFS)

3) DynamoDB

4) Kinesis

기존에 온프라미스 환경에서는 HDFS + YARN(분산프로세스 지원을 위한 툴)이 한몸이었다. 즉 HDFS와 YARN이 단일노드 안에서 항상 같이 존재하게 되었다. 그래서 저장소가 부족해도 혹은 분석작업이 많아서 리소스가 부족해서 업무의 지연이 발생해도 항상 같이 늘려야만 했다.

그래서 프로세싱인 얀과 저장소인 HDFS를 같이 늘리다보면 결국에는 각 작업의 형태 또는 각 작업의 수행시간에 의해 낭비되는 자원이 발생할 수 있다.

만일 다양한 업무를 하둡 클러스터에서 수행하고자 한다면 처음에는 작은수의 하둡애코 어플리케이션을 이용해서 데이터를 처리할 것이다. 하지만 다양한 요구조건이 추가될때마다 혹은 비지니스의 로직이 복잡해질수록 다양한 어플리케이션을 설치하고 구성해야한다. \

그런데 한정된 자원에서 다양한 어플리케이션이 단일 하둡클러스터를 사용을 한다고하면 업무의 지연, 리소스 규모의 문제, 어플리케이션 조합활용의 문제등이 발생할 수 있다.

그렇다고 하둡클러스터를 용도에 맞게 분리해버리면 아래 그림과 같이 동일한 데이터를 각각의 서로다른 클러스터에서 활용을 할 수 없는 데이터의 고립현상이 발생하게 된다.

결국에는 비용의 낭비가 발생하고 서로 데이터가 각각의 클러스터간의 이동을 해야하기 때문에 실제 비지니스 즉 어플리케이션이 수행됨에 있어서 업무의 지연이 발생한다. 당연히 여러 클러스터를 우리가 관리를 해야하므로 관리에 많은 시간을 투자해야한다.

그래서 AWS EMR은 이렇게 해결했다.

EMR은 저장공간과 연산을 분리하였다. 즉 서로간의 의존성을 분리하므로써 연산을 위해서 리소스가 더 많이 필요한 경우 앞에서 언급했듯이 테스크노드를 추가하고 확장함으로써 업무처리를 편리하게 할 수 있다. 혹은 저장공간의 입장에서는 HDFS 뿐만 아니라 S3를 EMR 클러스터의 스토리지영역으로 활용할 수 있게 함으로써 저장공간 측면에서 최적화 할 수 있다. 또한 S3를 사용함으로써 여러 클러스터 혹은 다양한 서비스에서 단일 데이터를 접근할 수 있다는 말이기 때문에 다양한 데이터 활용도 가능하다.

예시

아래의 그림은 실제 EMR 클러스터 위에 아파치 에코시스템인 하이브를 활용해서 데이터를 저장하는 테이블과 거기에 데이터를 넣는 명령어이다.

기존에는 테이블을 만들때 노란색 글씨 로케이션에 하둡의 PATH를 활용했다. 로케이션 PATH 부분에 HDFS경로가 아니라 S3를 지정해서 활용 할수도 있다.

다중 클러스터의 환경에서 동일한 S3에 접속포인트를 사용하여 클러스터가 여러목적으로 나뉘어진다고 해도 동일한 데이터를 처리할 수 있다.

업무에서 바뀌는 건 오직 저장소의 로케이션 뿐..

안쓸때는 끄세요

또한 저장소와 연산을 분리함으로써 전기를 사용하듯이 필요할때는 사용하고 필요하지 않을때는 사용하지 않을 수 있다. 그래서 비용을 절약할 수 있다.

그럼 하이브 메타스토어는?

만약에 하이브와 같은 아파치에코 어플리케이션을 사용한다면 메타스토어를 관리해야한다. 여기서 메타스토어라고 하는 것은 테이블의 정보, 컬럼의 속성 등 다양한 데이터에 대한 정보를 기록하고 있게 된다. EMR은 스타트와 터미네이트라는 라이프 사이클을 갖고 있다. 그래서 EMR을 터미네이트를 시키게되면 하이브의 메타스토어 정보가 사라지게 된다. 테이블이나 혹은 데이터가 EMRFS에 저장되어 있어 영구적으로 보관이 된다 하더라도 하이브 메타스토어가 사라지면 테이블의 정보, 컬럼 정보 등 다양한 환경을 다시 처음부터 구축해야 한다.

따라서 이런 하이브의 메타스토어를 별도의 관리형 데이터베이스를 하이브의 메타스토어로 활용할 수 있다.