Category: Amazon EMR*


Apache Flink를 이용한 AWS기반 실시간 스트림 처리 파이프라인 구성하기

오늘날 비즈니스 환경에서, 다양한 데이터 소스의 꾸준한 증가에 맞추어 데이터는 계속적으로 생성되고 있습니다. 따라서, 원시 데이터의 대규모 스트림을 통해 실행 가능한 통찰력을 얻기 위한 데이터를 지속적으로 수집하고, 저장하고, 처리하는 능력을 갖춘다는 것은 조직의 경쟁력 측면에서 장점이라 하겠습니다.

Apache Flink스트림 프로세싱 파이프라인의 기반을 갖추는 데 매우 적합한 오픈소스 프로젝트 입니다. 스트리밍 데이터의 지속적인 분석에 적합한 고유한 기능을 제공합니다. 하지만, Flink를 기반으로 파이프라인 을 구축하고 유지하려면 때때로 물리적 자원 및 운영상의 노력 외에 상당한 전문 지식이 필요합니다.

이 글을 통해서 Amazon EMR, Amazon KinesisAmazon Elasticsearch Service (ES)를 사용하는 Apache Flink를 기반으로 일관성 있고 확장 가능하며 안정적인 스트림 프로세싱 파이프라인에 대한 레퍼런스 아키텍처를 설명해드리고자 합니다. AWSLabs GitHub 저장소는 레퍼런스 아키텍처를 실제로 탐색하는데 필요한 아티팩트(artifact)를 제공합니다. 리소스에는 샘플 데이터를 Amazon Kinesis Stream으로 수집하는 프로듀서(producer) 애플리케이션과 실시간으로 데이터를 분석하고 그 결과를 시각화하기 위해 Amazon ES로 보내는 Flink 프로그램이 포함되어 있습니다.

실시간으로 택시 데이터 지리적 위치 분석하기
택시의 차량 운영 최적화와 관련하여 다음과 같은 시나리오를 생각해보겠습니다. 뉴욕시에서 현재 운영중인 수많은 택시들로부터 운행 정보를 지속적으로 확보합니다. 그리고 이 데이터를 사용하여 수집된 데이터를 실시간으로 분석하고 데이터에 기반한 의사 결정을 내림으로써 운영을 최적화하고자 합니다.

예를 들어, 현재 택시 수요가 많은 지역을 의미하는 핫스팟(Hot spot)을 식별해서 빈 택시들이 이 곳으로 이동하도록 할 수 있습니다. 또, 현재 교통 상황을 파악해서 가까운 공항으로 가기 위한 대략적인 운행 시간을 고객에게 알려드릴 수도 있습니다. 당연히, 이러한 결정은 현재의 수요와 교통 상황을 상세하게 반영하고 있는 정보를 기반으로 합니다. 유입되는 데이터는 지속적이면서도 시간에 맞춰 적절하게 분석되어야 합니다. 이와 관련한 KPI와 이를 통해 도출되는 인사이트는 실시간으로 대시보드에서 액세스할 수 있어야 합니다.

이 글의 목적에 맞게, 뉴욕시에서 수집된 택시 운행 이력 데이터셋을 Amazon Kinesis Streams로 재생해서 운행 이벤트를 만들어보겠습니다. 이 데이터셋은 New York City Taxi & Limousine Commission 웹사이트에서 얻을 수 있으며, 지리적 위치 정보와 택시 운행 관련 요금 정보 등이 포함되어 있습니다.

보다 현실적인 시나리오에서는, AWS IoT를 사용하여 택시에 설치된 원격 측정 유닛에서 데이터를 수집한 다음 이 데이터를 Amazon Kinesis Streams로 처리할 수도 있습니다.

높은 신뢰성과  확장 가능한 스트림 프로세싱 파이프라인 아키텍처
파이프라인이 택시를 운영하고 최적화하기 위한 중앙 집중형 툴을 제공하므로, 단일 노드의 장애에 대한 내성을 갖는 아키텍처를 구축하는 것은 매우 중요합니다. 파이프라인은 유입되는 이벤트의 변화율에 맞춰 적응할 것입니다. 따라서, 이벤트 수집, 실질적인 처리, 확보한 인사이트의 시각화를 다른 구성 요소들로 분리합니다. 인프라의 구성요소들 간의 결합도를 낮추고, 관리형 서비스를 사용해서 장애에 대해 파이프라인의 견고성(robustness)을 증가시킬 수 있습니다. 또, 인프라의 여러 부분을 확장시킬 수 있고 전체 파이프라인을 구축하고 운영하는데 필요한 노력을 줄일 수 있습니다.

기대하는 데이터 통찰력을 얻기 위한 쿼리 계산으로부터 택시를 통해 전송된 이벤트의 수집과 저장을 분리하여, 인프라의 견고성을 상당히 증가시킬 수 있습니다.

이벤트는 처음에는 Amazon Kinesis Streams를 통해 유지됩니다. Amazon Kinesis Streams는 재생 가능하고 순서가 있는 로그(log)를 보유하며 여러 가용 영역(Availability Zone)에 이벤트를 중복 저장합니다. 이후에, 스트림에서 이벤트를 읽어서 Apache Flink에서 처리합니다. Flink는 내부 상태를 지속적으로 스냅샷으로 남겨놓기 때문에, 스냅샷에서 내부 상태를 복원하고 스트림에서 재처리가 필요한 이벤트를 재생하여 오퍼레이터 또는 전체 노드에서 발생한 장애를 복구 할 수 있습니다.

이벤트 저장을 위해 이렇게 한 곳에 로그를 보유하는 또 다른 장점은 여러 애플리케이션에서 데이터를 소비(Consume)할 수 있다는 점입니다. 벤치마크 테스트 및 일반 테스트를 위해 다른 버전의 Flink 애플리케이션을 나란히 실행시키는 것도 가능합니다. 또는, 장기간 아카이빙을 위해 스트림에서 Amazon S3로 데이터를 저장하는 데에 Amazon Kinesis Firehose를 사용할 수 도 있고, 그런 다음 Amazon Athena를 사용하여 과거의 기록을 상세하게 분석할 수도 있습니다.

Amazon Kinesis Streams, Amazon EMR, Amazon ES는 간단한 API 호출을 통해 생성 및 확장할 수 있는 관리형 서비스입니다. 따라서 이러한 서비스를 사용하면 비즈니스 가치를 제공하기 위한 전문 작업에 집중할 수 있습니다. 파이프라인 전체를 구축하고, 운영하고, 확장하기 위해 필요한 것들이 구분되어 있지 않은 무거운 작업을AWS로 수행하시기 바랍니다. 파이프 라인 생성은 AWS CloudFormation으로 완전히 자동화 될 수 있습니다. 개별 구성 요소는 Amazon CloudWatch를 통해 모니터링되고 자동으로 확장될 수 있습니다. 오류 사항 감지 및 자동 완화 역시 지원됩니다.

이후 부분에서는, AWS에서 레퍼런스 아키텍처를 만들고 실행하는 것에 관련된 부분에 중점을 두겠습니다. Flink에 대한 자세한 사항은, API를 이용하여 Flink 프로그램을 어떻게 구현하는지 다루는 Flink training session 을 참조하시기 바랍니다. 이 세션에서 사용된 시나리오는 이 글에서 다루는 내용과 상당히 비슷합니다.

레퍼런스 아키텍처 빌드 및 실행

실제 택시 운행 분석 애플리케이션을 위해, 다음 2 개의 CloudFormation 템플릿을 사용하여 레퍼런스 아키텍처를 만들고 실행합니다:

  • 첫번째 템플릿은 택시 운행을 스트림으로 수집하고 Flink로 운행 정보를 분석하기 위한 런타임 아티팩트(artifact)를 구축합니다.
  • 두번째 템플릿은 애플리케이션을 실행시키는 인프라 리소스를 생성합니다.

Flink 애플리케이션과 CloudFormation템플릿을 비롯한, 레퍼런스 아키텍처를 구축하고 실행시키는데 필요한 리소스는 AWSLabs GitHub 저장소의 flink-stream-processing-refarch에 있습니다.

런타임 아티팩트(Artifacts) 빌드 및 인프라 생성

우선 첫번째 CloudFormation 템플릿을 실행해서 AWS CodePipeline 파이프라인을 생성합니다. 이 파이프라인은 서버리스 방식으로 AWS CodeBuild를 사용해서 아티팩트를 만듭니다. 여기에 Maven을 설치하고 Flink Amazon Kinesis 커넥터 및 기타 런타임 아티팩트를 수동으로 구축할 수 있습니다. 파이프라인의 모든 단계가 성공적으로 완료되면, CloudFormation 템플릿의 출력 섹션에 지정되어 있는 S3 버킷에서 아티팩트를 검색할 수 있게 됩니다.

첫번째 템플릿이 생성되고 런타임 아티팩트가 만들어지면, 두번째 CloudFormation 템플릿을 실행합니다. 이를 통해 앞에서 설명한 레퍼런스의 리소스를 생성합니다. (SSH 접속을 위한 Key Pair가 없을 경우 두번째 CloudFormation 템플릿 실행 전에 미리 생성하여 준비합니다)

다음 단계를 진행하기 전에 위의 템플릿 2개가 모두 성공적으로 생성될 때까지 기다립니다. 약 15분 정도 걸릴 수 있으니, CloudFormation이 모든 작업을 마칠 때까지 자유롭게 커피 한 잔 하면서 기다립니다.

Flink 런타임 시작 및 Flink 프로그램 제출하기
Flink 런타임을 시작하고, 분석을 하는 Flink 프로그램을 서브밋(submit)하기 위해, EMR 마스터 노드에 연결합니다. 인프라 프로비저닝과 런타임 아티팩트 빌드를 위해 사용된 2개의 CloudFormation 템플릿의 실행 결과를 다음 명령어와 관련 파라미터를 통해 확인할 수 있습니다.

$ ssh -C -D 8157 hadoop@«EMR master node IP»

CloudFormation 템플릿을 통해 프로비저닝 된 EMR 클러스터는 노드당 4개의 vCPU를 지닌 2개의 c4.xlarge 코어 노드로 구성됩니다. 일반적으로, 태스크 매니저당 슬롯의 개수와 노드 코어의 수를 동일하게 맞춥니다. 여기서는, 2개의 태스크 매니저와 각 태스크 매니저 당 4개의 슬롯을 지닌 long-runnig Flink 클러스터로 시작하면 적절하겠습니다 (EMR 마스터 노드에 접속한 상태에서 다음 명령어를 실행합니다):

$ flink-yarn-session -n 2 -s 4 -tm 4096 -d

Flink 런타임이 실행되고 나면, 택시 스트림 프로세서 프로그램은 Amazon Kinesis 스트림 내의 운행 이벤트를 실시간으로 분석하기 위해 Flink 런타임에 제출 됩니다.

$ aws s3 cp s3://«artifact-bucket»/artifacts/flink-taxi-stream-processor-1.0.jar .
$ flink run -p 8 flink-taxi-stream-processor-1.0.jar --region «AWS region» --stream «Kinesis stream name» --es-endpoint https://«Elasticsearch endpoint»

Flink 애플리케이션이 실행 중이니, 스트림에서 유입되는 이벤트를 읽습니다. 그런 다음 이벤트 시간에 따라 타임 윈도우 내에서 이들을 집계하여 결과를 Amazon ES로 전송합니다. Flink 애플리케이션은 소규모 요청으로 Elasitcsearch 클러스터에 과부하가 걸리지 않도록 배치 레코드를 처리하고, 배치 처리 요청에 서명을 통해서Elasticsearch 클러스터의 보안 구성이 가능하도록 합니다.

브라우저에서 프록시(proxy)를 활성화 해놓았다면, 마스터 노드에 대한 SSH 세션을 수립하는 동적 포트 포워딩을 통해서Flink 웹 인터페이스를 볼 수 있습니다.

택시 운행 이벤트를 Amazon Kinesis Stream으로 입력
이벤트를 수집하기 위해, 택시 스트림 프로듀서 애플리케이션을 사용합니다. 이 애플리케이션은 미국 뉴욕 시에서 기록한 택시 운행의 이력 데이터셋을 S3로부터 읽어와서 8개의 샤드(shard)가 있는 Amazon Kinesis Stream으로 재생합니다. 택시 운행에 외에도, 프로듀서 애플리케이션은 워터마크 이벤트를 스트림으로 가져옵니다. 이를 통해서 프로듀서가 이력 데이터셋을 재생하는 시간을 Flink 애플리케이션이 결정할 수 있게 됩니다.

$ ssh -C ec2-user@«producer instance IP»
$ aws s3 cp s3://«artifact-bucket»/artifacts/kinesis-taxi-stream-producer-1.0.jar .
$ java -jar kinesis-taxi-stream-producer-1.0.jar -speedup 1440 -stream «Kinesis stream name» -region «AWS region»

이 애플리케이션은 이번 블로그에서 논의한  레퍼런스 아키텍처에만 특화된 것은 아닙니다. 예를 들어 Apache Flink 대신 Amazon Kinesis Analytics를 기반으로 유사한 스트림 처리 아키텍처를 구축하는 식으로 다른 목적에도 쉽게 재사용이 가능합니다.

Kibana 대시보드 탐색

전체 파이프라인이 실행중이므로, Flink 애플리케이션에 의해 실시간으로 제공되는 인사이트를 보여주는 Kibana 대시보드를 볼 수 있습니다:

https://«Elasticsearch end-point»/_plugin/kibana/app/kibana#/dashboard/Taxi-Trips-Dashboard

이 글의 목적에 맞게 Elasticsearch 클러스터는 인프라를 생성하는 CloudFormation 템플릿의 파라미터로 지정된 IP 주소 범위의 연결을 허용하도록 구성됩니다. 프로덕션-준비 상태의 애플리케이션의 경우, 이러한 설정이 맞지 않을 수도 있고 설정 자체가 불가능할 수도 있습니다. Elasticsearch 클러스터에 안전하게 연결하는 방법에 대한 자세한 내용은 AWS 데이터베이스 블로그의 Amazon Elasticsearch Service에 대한 액세스 제어 설정을 참조하시기 바랍니다.

Kibana 대시 보드에서 왼쪽의 지도는 택시 운행의 시작 지점을 시각화하여 보여주고 있습니다. 사각형이 빨간색에 가까울수록 해당 위치에서 더 많은 택시 운행이 시작됨을 의미합니다. 오른쪽의 그래프 차트는 John F. Kennedy 국제 공항과 LaGuardia Airport까지의 택시 운행 평균 시간을 각각 보여줍니다.

이러한 정보를 가지고, 현재 수요가 많은 지역에 빈 택시를 사전 조치하여 보내고 현지 공항으로의 운행 시간을 보다 정확하게 예측함으로써 택시 차량 운영 최적화가 가능해집니다.

이제 기본 인프라를 확장시킬 수 있습니다. 예를 들면, 스트림의 샤드 용량을 확장 시킵니다. Elasticsearch 클러스터의 인스턴수 갯수 또는 타입도 변경합니다. 아울러, 전체 파이프라인이 스케일 조정 중에도 제대로 동작하고 응답하는지 확인합니다.

AWS 에서 Apache Flink 실행

앞에서 본 것처럼, Flink 런타임은 YARN을 통해서 배포될 수 있습니다. 따라서 EMR은 AWS 상에서 Flink를 실행시키기에 매우 적합합니다. 하지만, Flink 애플리케이션을 빌드하고 실행시키기 위해 해야할 AWS에 관련된 고려사항이 몇 가지 있습니다:

  • Flink Amazon Kinesis 커넥터 빌드
  • Amazon Kinesis 컨슈머(Consumer) 환경 설정 수정
  • Amazon Kinesis에 워터마크를 서브밋해서 이벤트 시간 처리를 가능하게 함
  • Flink를 Amazon ES에 연동

Flink Amazon Kinesis 커넥터 빌드

Flink는 Amazon Kinesis Streams를 위한 커넥터를 제공합니다. 다른 Flink 아티팩트와는 달리, Amazon Kinesis 커넥터는 Maven central에서는 사용할 수 없습니다. 따라서 여러분이 직접 빌드하셔야 합니다. Maven 3.3.x의 경우 부적절하게 가려진 의존성(dependency)으로 인한 출력이 만들어질 수 있으므로, Maven 3.3.x 이상의 배포판 보다는 Maven 3.2.x로 Flink 빌드를 권장합니다.

$ wget -qO- https://github.com/apache/flink/archive/release-1.2.0.zip | bsdtar -xf-
$ cd flink-release-1.2.0
$ mvn clean package -Pinclude-kinesis -DskipTests -Dhadoop-two.version=2.7.3 -Daws.sdk.version=1.11.113 -Daws.kinesis-kcl.version=1.7.5 -Daws.kinesis-kpl.version=0.12.3

Flink Amazon Kinesis 커넥터를 받고 나면, 로컬 Maven 저장소에 .jar 파일들을 임포트 할 수 있습니다.

$ mvn install:install-file -Dfile=flink-connector-kinesis_2.10-1.2.0.jar -DpomFile=flink-connector-kinesis_2.10-1.2.0.pom.xml

Amazon Kinesis consumer 환경 설정 적용
Flink는 최근 EMR 클러스터와 관련된 role에서 AWS 자격 증명을 얻을 수 있도록 지원하기 시작했습니다. Flink 애플리케이션 소스 코드에서 AWS_CREDENTIALS_PROVIDER 속성을 AUTO로 설정하고 Properties 객체에서 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY 파라미터를 생략하여 이 기능을 활성화합니다.

Properties kinesisConsumerConfig = new Properties();
kinesisConsumerConfig.setProperty(AWSConfigConstants.AWS_CREDENTIALS_PROVIDER, "AUTO");

자격 증명은 인스턴스의 메타데이터에서 자동으로 검색되므로 장기 자격 증명을 Flink 애플리케이션 또는 EMR 클러스터의 소스 코드에 저장할 필요가 없습니다.

프로듀서 애플리케이션은 초당 수천 개의 이벤트를 스트림으로 가져오므로, 단일 GetRecords 호출에서 Flink가 가져온 레코드 수를 늘리는 데 도움이 됩니다. 이 값을 Amazon Kinesis 에서 지원하는 최대값으로 변경하시기 바랍니다.

kinesisConsumerConfig.setProperty(ConsumerConfigConstants.SHARD_GETRECORDS_MAX, "10000");

Amazon Kinesis에 대한 워터마크 제출을 통한 이벤트 타임 프로세싱 지원
Flink는 여러 가지 개념의 타임, 특히 이벤트 타임을 지원합니다. 이벤트 타임은 스트리밍 응용 프로그램에 매우 적합한데, 이는 쿼리에 대해 안정적인 의미의 결과를 내주기 때문입니다. 이벤트 타임은 프로듀서 또는 프로듀서에 근접한 경우에 의해 결정됩니다. 네트워크로 인한 이벤트 순서의 재지정이 쿼리 결과에 미치는 영향은 매우 작습니다.

이벤트 타임을 실현하기 위해, Flink는 일정한 시간 간격으로 프로듀서가 보낸 워터마크를 사용하여 소스의 현재 시간을 Flink 런타임에게 알립니다. Amazon Kinesis Streams와 통합할 때 Flink 에 워터 마크를 제공하는 두 가지 방법이 있습니다:

  • 스트림에 워터마크를 수동으로 추가
  • 스트림 수집 과정에서 이벤트에 자동으로 추가되도록 ApproximalArrivalTime을 이용

Amazon Kinesis 스트림에서 시간 모델을 이벤트 시간으로 설정하면, Flink는 Amazon Kinesis에서 제공하는 ApproximalArrivalTime 값을 자동으로 사용합니다.

StreamExecutionEnvironment env = StreamExecutionEnviron-ment.getExecutionEnvironment(); 
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);

또는, 스트림의 해당 이벤트에서 워터 마크 정보를 추출하는 사용자 정의 Timestamp Assigner 연산자를 지정하여 프로듀서가 정해 놓은 시간을 사용하도록 선택할 수도 있습니다.

DataStream<Event> kinesis = env
	.addSource(new FlinkKinesisConsumer<>(...))
	.assignTimestampsAndWatermarks(new PunctuatedAssigner())

PunctuatedAssigner 를 사용할 경우, 모든 개별 샤드에 워터 마크를 가져오는 것이 중요합니다. 왜냐하면Flink는 스트림별 샤드를 개별적으로 처리하기 때문입니다. 이는 스트림의 샤드를 나열하여 해결할 수 있습니다. 워터마크가 전송될 샤드의 해시 범위에 대해 해시 키를 명시적으로 세팅해서 특정 샤드에 워터마크를 수집합니다.

Amazon Kinesis를 이용하여 택시 운행 정보를 수집하는 프로듀서는 후자의 접근법을 사용합니다. 구현에 관련된 자세한 사항은 AWSLabs GitHub 저장소의flink-stream-processing-refarch를 참고하시기 바랍니다.

Amazon ES와 Flink의 연동
Flink는 Elasticsearch에 대한 몇 가지 커넥터를 제공합니다. 그러나 이러한 모든 커넥터는 단지 Elasticsearch의 TCP 전송 프로토콜을 지원합니다. 반면 Amazon ES는 HTTP 프로토콜을 사용합니다. Elasticsearch 5부터는 TCP 전송 프로토콜이 더 이상 사용되지 않습니다. HTTP 프로토콜을 지원하는 Flink 용 Elasticsearch 커넥터는 여전히 동작하지만, Jest 라이브러리를 사용하여 Amazon ES에 연결할 수 있는 사용자 정의 싱크(sink)를 빌드 할 수 있습니다. 싱크(sink)는 IAM 자격 증명으로 요청에 서명 할 수 있어야합니다.

Elasticsearch 싱크의 전체 구현에 대한 자세한 내용은 Flink 애플리케이션의 소스 코드가 포함 된 flink-taxi-stream-processor AWSLabs GitHub 저장소를 참조하십시오.

요약

이 글에서는 Apache Flink를 기반으로 일관성 있고 확장 가능하며 안정적인 스트림 처리 아키텍처를 구축하는 방법에 대해 설명했습니다. 또한 관리형 서비스를 활용하여 짧은 대기 시간 및 높은 처리량 스트림 처리 파이프라인을 구축하고 유지 관리하는 데 필요한 전문 지식과 운영 노력을 줄이는 방법을 보여줌으로써 전문 지식을 비즈니스 가치를 제공하는 데에 집중할 수 있습니다.

오늘부터 Amazon EMR에서 Apache Flink를 사용해보시기 바랍니다. AWSLabs GitHub 저장소에는 주어진 예제를 실행하는 데 필요한 리소스가 포함되어 있으며 빠르게 시작하는 데 도움이 되는 추가 정보가 포함되어 있습니다.

이 글은 AWS Bigdata 블로그의 Build a Real-time Stream Processing Pipeline with Apache Flink on AWS의 한국어 번역으로, AWS 프로페셔널 서비스의 남궁영환 컨설턴트께서 번역해 주셨습니다.

 

Amazon EMR 인스턴스 집합(Instance Fleets) 기능 출시!

인스턴스 집합(instance fleets) 기능이 Amazon EMR 클러스터에서도 사용할 수 있습니다. 이는 인스턴스 프로비저닝과 관련된 다양한 옵션과 스마트한 기능을 제공합니다. 5개 인스턴트 타입에 대해 가중치 기반 컴퓨팅 용량 및 스팟 인스턴스 가격 입찰을 할 수 있습니다. EMR 클러스터를 만들 때, 이들 인스턴스 유형에 대해 온-디멘드 및 스팟 용량을 자동으로 제공합니다. 이를 통해 클러스터에 원하는 용량을 신속하게 확보 및 유지 관리하는 것이 보다 쉽게 가능해질 뿐 아니라 비용 또한 효율적입니다.

원하는 가용 영역(AZ)를 지정할 수 있으며, EMR은 리전 내 AZ 중 하나에서 클러스터를 실행할 수 있습니다. EMR은 인스턴스 집합에서 사용 가능한 타입으로 인스턴스를 교체하여 스팟 인스턴스가  중단되는 경우 클러스터를 재조정할 수 있습다. 이를 통해 클러스터 내 전체 컴퓨팅 용량을 쉽게 ​​유지할 수 있습니다. 인스턴스 집합은 인스턴스 그룹 대신 사용할 수 있습니다. 그룹과 마찬가지로 클러스터에는 마스터, 코어 및 태스크 집합이 있습니다.

AWS 관리 콘솔 업데이트를 살펴보고 어떻게 작동하는지 살펴 보겠습니다.

먼저 EMR console 로 이동하여 Create Cluster 버튼을 클릭합니다. 그러면 우리를 익숙한 EMR 프로비저닝 콘솔 왼쪽 상단의 고급 옵션으로 이동할 수 있습니다.

최신 EMR 버전을 선택한 후 (인스턴스 집합은 5.0.x를 제외한 EMR 버전 4.8.0 이상에서 사용 가능), 다음을 클릭하십시오. 여기에 하드웨어 옵션에서 새 Instance Fleet 옵션을 선택합니다.

Screenshot 2017-03-09 00.30.51

이제는 클러스터 요구 사항을 충족시킬 수 있는 몇 가지 인스턴스 타입을 추가해야 합니다.

CoreFleetScreenshot

EMR은 가능한 비용 효율적인 방식으로 요구 사항을 충족 할 수 있도록 각 인스턴스 집합 및 가용 영역에서 컴퓨팅 용량을 제공합니다. EMR 콘솔을 사용하여 vCPU를 각 인스턴스 타입에 대해 가중치 기반 용량에 쉽게 매핑 할 수 있으므로, vCPU 용량 단위를 쉽게 사용할 수 있습니다 (코어 집합에 총 16 개의 vCPU 필요). vCPU 단위가 가중치 인스턴스 타입에 대한  자체 기준과 일치하지 않으면, 임의의 단위를 포함하여 자체 가중치를 정의하도록 “대상 용량(Target Capacity)”선택을 변경할 수 있습니다 (이는 API/CLI가 용량 단위를 사용하는 방식입니다).

사용자가 정의한 시간 제한 내 원하는 스팟 용량을 얻을 수 없는 경우, 클러스터를 프로비저닝 할 때 나머지 클러스터 용량을  위해 On-Demand 인스턴스로 변경할 수 있습니다. 이들 기능은 AWS SDK 및 CLI에서도 사용할 수 있습니다.

먼저 my-fleet-config.json에 구성 json을 만듭니다.

Json
[
  {
    "Name": "MasterFleet",
    "InstanceFleetType": "MASTER",
    "TargetOnDemandCapacity": 1,
    "InstanceTypeConfigs": [{"InstanceType": "m3.xlarge"}]
  },
  {
    "Name": "CoreFleet",
    "InstanceFleetType": "CORE",
    "TargetSpotCapacity": 11,
    "TargetOnDemandCapacity": 11,
    "LaunchSpecifications": {
      "SpotSpecification": {
        "TimeoutDurationMinutes": 20,
        "TimeoutAction": "SWITCH_TO_ON_DEMAND"
      }
    },
    "InstanceTypeConfigs": [
      {
        "InstanceType": "r4.xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 1
      },
      {
        "InstanceType": "r4.2xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 2
      },
      {
        "InstanceType": "r4.4xlarge",
        "BidPriceAsPercentageOfOnDemandPrice": 50,
        "WeightedCapacity": 4
      }
    ]
  }
]

구성이 완료되었으므로 AWS CLI의 ’emr’하위 명령을 사용하여 해당 구성으로 새 클러스터를 만들 수 있습니다.

Bash
aws emr create-cluster --release-label emr-5.4.0 \
--applications Name=Spark,Name=Hive,Name=Zeppelin \
--service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile="EMR_EC2_DefaultRole,SubnetIds=[subnet-1143da3c,subnet-2e27c012]" \
--instance-fleets file://my-fleet-config.json

오늘 부터 추가 비용 없이 신규 기능을 사용할 수 있으며, 자세한 사항은 EMR 인스턴스 집합 도움말를 참고하시기 바랍니다. 이 글 작성에 도움을 주신 EMR 서비스 팀에게 감사드립니다!

– Randall;

이 글은 New – Amazon EMR Instance Fleets의 한국어 번역입니다.

AWS 3월 온라인 세미나 – 서버리스 IoT, Amazon EMR, Active Directory on AWS

AWS 클라우드를 아껴주시는 한국 고객 분들을 위해 지속적으로 AWS 월간 웨비나 시리즈를 진행하고 있습니다. 이번 3월 웨비나에서는 AWS 클라우드 소개, 서버리스 IoT 서비스 백엔드 및 Windows Active Directory, 빅데이터 분석 서비스인 Amazon EMR  심층 분석 등 다양한  온라인 세미나를 준비하였습니다. 관심 있는 분들의 많은 참여를 바랍니다.

온라인 세미나 일정

비지니스 기초 | AWS와 함께하는 클라우드 컴퓨팅
연사: 이재현 AWS 어카운트 매니저
일시: 2017년 3월 28일 (화) 오전 10:00 – 오전 11:30
대상: 클라우드 컴퓨팅에 대해 궁금하시거나 AWS 클라우드에 대해 알기를 원하시는 모든 분들 (비지니스 기획 및 IT 담당자)

강연 요약: AWS 클라우드는 IT의 새로운 기준을 정립하며 클라우드 컴퓨팅 산업을 혁신하고 있습니다. 이 세미나에서는 클라우드 컴퓨팅의 개념과 AWS가 제공하는 서비스 및 솔루션의 특장점, 주요 사용사례에 대해 말씀드리고 질답 시간을 가질 예정입니다. 부디 참석하셔서 귀사의 사업과 서비스에 적용할 수 있는 정보를 얻어가시기 바랍니다.

발표 자료 및 동영상 다시 보기

기술 기초 | 서버리스 IoT 백엔드 구축 방법
연사: 윤석찬 AWS 테크에반젤리스트
일시: 2017년 3월 28일 (화) 오후 02:00 – 오후 03:30
대상: IoT 서비스를 운영 중인 IT 관리자, 아키텍트 및 개발자 및 IoT 워크로드를 AWS 클라우드에 운영하고자 하는 모든 분들

강연 요약: AWS IoT 서비스의 주요 개념과 함께 일반적인 인터넷 기기 및 스마트 홈을 위한 IoT 서비스 구현 패턴을 알아봅니다. 이를 위해 데이터 상태 관리, 데이터 분석 및 자원 관리 등의 패턴을 통해 비용 효율적이고 확장 가능한 아키텍처를 살펴봅니다. AWS Lambda, API Gateway, DynamoDB 등 서버리스 빌딩 블록과 AWS IoT를 연계한 iRobot의 아카텍처 사례를 함께 살펴봄으로서 IoT 기반 서비스 구현 및 이전에 통찰력을 얻으실 수 있습니다.

발표 자료 및 동영상 다시보기

기술 심화 | Amazon EMR Deep Dive
연사: 홍준혁 AWS  솔루션즈 아키텍트
일시: 2017년 3월 29일(수) 오전 10:00 – 오전 11:30
대상: Hadoop 및 Spark 클러스터를 운영 중인 IT 관리자, 아키텍트 및 개발자 및 빅데이터 워크로드를 AWS 클라우드에 운영하고자 하는 모든 분들

강연 요약: 데이터양이 많아지면서 데이터를 가치있게 사용하기 위해서 데이터를 어떻게 효율적으로 가공할 수 있을까 하는 요구가 증대하고 있습니다. 본 세션에서는 빅데이터 처리 기법으로 활용할 수 있는 Amazon EMR 고급 활용 기법을 알려 드리며, Hadoop, Hive, Spark, Tez 등과 같은 다양한 Application을 어떤 식으로 활용할 수 있을지에 대한 기법을 알려 드립니다.

발표 자료 및 동영상 다시 보기

기술 심화 | AWS에서 Active Directory 구축 및 연동 옵션 살펴보기
연사: 김용우 솔루션즈 아키텍트
일시: 2017년 3월 29일(수) 오후 2:00 – 오후 3:30
대상: 윈도 서버를 운영 중인 IT 관리자, 아키텍트 및 보안 엔지니어 및 윈도 기반 워크로드를 AWS 클라우드에 운영하고자 하는 모든 분들

강연 요약: AWS에서는 SharePoint, Dynamics 및 Exchange와 같은 Microsoft 애플리케이션을 좀 더 안전하고 관리가 간편하며 성능이 뛰어난 접근 방식으로 실행할 수 있는 클라우드 플랫폼을 제공합니다.  이를 위해 AWS상에서  Active Directory 구축 및 안정적인 운영을 위한 다양한 옵션과 Best Practice를 알아봅니다.

발표 자료 및 동영상 다시 보기

3월 AWS 온라인 세미나를 통해 AWS를 통해 비지니스를 성공하는 방법과 다양한 AWS 서비스를 통해 다양한 IT 워크로드를 구축하는 방법에 대해 알아보시기 바랍니다.

– AWS 코리아 마케팅팀;

Amazon EMR 클러스터 자동 확장 기능 추가

Amazon EMR 팀은 최근 신규 버전을 계속 출시하면서, 이번 분기에만 다양한 기능을 추가하였습니다.

오늘부터 Amazon EMR 클러스터에 대한 자동 확장 기능을 제공합니다. 이제 수평 확장 및 감소 기능을 사용하여 작업량 변경에 대한 클러스터의 코어 및 작업 노드 수를 조정하고 자원 사용을 최적화 할 수 있습니다.

수평 확장(Scale-out) 정책: 컴퓨팅 용량을 추가하여 더 큰 문제를 해결할 수 있습니다. Apache Spark 및 Apache Hive와 같은 응용 프로그램을 자동으로 증가하는 처리 능력을 활용할 수 있습니다.

수평 감소(Scale-in) 정책: 인스턴스 사용 시간이 끝나거나 전체 작업의 로드가 줄어들때 용량을 제거합니다. YARN 관리 콘테이너에서 노드가 하나 줄어 들면, YARN은 다른 노드에서 재실행됩니다. (자세한 사항은 Configure Cluster Scale-Down Behavior 문서를 참고하세요.)

자동 스케일링 사용하기
자동 스케일링을 사용하려면, 먼저 EC2 인스턴스를 시작하고 종료 할 수 있는 권한을 부여하는 IAM 역할이 클러스터와 연결되어 있어야합니다. 여러분이 EMR 콘솔에서 클러스터를 작성하는 경우, EMR_AutoScaling_DefaultRole를 만듭니다. 기본 값 있는 그대로 사용하거나 필요에 따라 사용자 정의로 지정할 수 있습니다. 프로그래밍 방식 또는 명령줄을 통해 클러스터를 만드는 경우, 아래와 같이 직접 만들 수 있습니다. 더 자세하 것은 create the default roles from the command line을 참고하세요.

Bash
$ aws emr create-default-roles

콘솔에서 클러스터를 만들 때 고급 옵션을 클릭하여 자동 확장 정책을 편집 할 수 있습니다.

연필 아이콘을 클릭하면 정책 정보 수정을 할 수 있습니다. 저의 예제는 아래와 같습니다.

본 정책이 YARNMemoryAvailablePercentage에 의해 실행하기 때문에 Spark, TEZ, Hadoop MapReduce 등의 프레임워크를 실행할 때, 메모리가 낮은 상태에서 활성화될 것입니다. 아래 옵션처럼 다양한 통계치를 선택할 수도 있습니다.

제가 만든 자동 스케일링 정책은 아래와 같습니다.

동일한 통계 셋을 선택할 수도 있고, 각 정책의 Cooldown period(재사용 대기 시간)을 설정할 수도 있습니다. 이 값은 확장 기능이 운영되는 사이의 최소 시간을 설정하고 변경 사항이 적용될 때 통계치를 안정적으로 유지합니다.

기본 정책(YARNMemoryAvailablePercentageContainerPendingRatio에 의해 실행)은 콘솔에서도 사용 가능합니다.

정식 출시
Amazon EMR의 자동 스케일링에 대한 자세한 정보는 Scaling Cluster Resources을 참고하시고, 본 기능은 오늘 부터 emr-5.1.0 버전에서 사용 가능합니다.

Jeff;

이 글은 New – Auto Scaling for EMR Clusters의 한국어 번역입니다.

Amazon EMR – 전송 및 저장 중 데이터 암호화 옵션 기능 추가

AWS 고객 중에는 Amazon EMR(Apache HadoopApache Spark 관련 도구 포함)를 사용하여 다양한 유형의 중요한 업무에 대한 빅 데이터 분석 사례를 가지고 있습니다. 아래 업체들은 바로 대표적인 예입니다.

  • Yelp 매일 테라 바이트 이상의 로그 파일과 사진 데이터 처리
  • Expedia 사용자 클릭 스트림 및 행동 관련 데이터 처리
  • FINRA 매일 수십억 건의 증권 거래 기록 분석
  • DataXu 매월 30 조 개의 광고 제공 기회 판단 분석

이러한 고객 (자세한 내용은 빅 데이터 사용 사례 참조)은 미션 크리티컬한 중요한 데이터를 안전하게 처리해야 합니다.

AWS는 EMRFS을 사용하는 Amazon S3와 HDFS의 투명한 데이터 암호화 등 EMR 데이터 암호화 옵션을 여러 가지 제공합니다. 이러한 솔루션은 이미 저장된 데이터를 보호하는 경우에는 우수합니다. 다만, 임시 파일에 저장되어있는 데이터와 작업 단계 사이에 전송 중인 데이터에 대한 암호화를 처리하지 않습니다. 각 암호화 옵션은 각자 활성화 후 구성 해야 하기 때문에 암호화 구현을 하는 부분이 쉽지 않습니다.

새로운 암호화 기능 지원
AWS는 오늘 부터 Amazon EMR에서 새로운 포괄적인 암호화 방식을 출시합니다. 앞으로 Amazon EMR에서 사용하는 Apache Spark, Apache Tez, Hadoop MapReduce에 저장된 데이터와 전송 중인 데이터를 쉽게 암호화 할 수 있습니다.

저장 데이터의 암호화는 다음 스토리지 유형에 대처하고 있습니다.

  • EMRFS 통해 S3에 저장된 데이터
  • 각 노드의 로컬 파일 시스템에 저장된 데이터
  • HDFS를 사용하여 클러스터에 저장된 데이터

전송 중인 데이터의 암호화는 다음 프레임웍의 오픈 소스 암호화 기능을 이용합니다.

  • Apache Spark
  • Apache Tez
  • Apache Hadoop MapReduce

Amazon EMR 보안 설정을 통해 새로운 기능을 사용할 수 있습니다. EMR 콘솔, the EMR CLIEMR API을 사용할 수 있습니다.

아래에서 보시다시피, EMR 콘솔에 몇 가지 보안 설정을 추가하였습니다.

새로 만드시려면, Create을 선택합니다.

이름을 입력하고 새로운 기능의 형식과 원하는 모드를 선택합니다. 모드와 형식에 따라, 콘솔이 추가 정보 입력을 요청합니다.
S3 암호화:

로컬 디스크 암호화:

전송 중인 데이터 암호화:

인증서 공급자 유형을 PEM 파일로 한 경우, 암호화에 사용하려는 PEM 파일을 포함한 Zip 파일의 S3의 위치를 ​​입력하십시오. 사용자 정의를 선택한 경우, JAR 파일의 S3 위치와 사용자 인증서 공급자의 클래스명을 입력하십시오.

원하는 대로 설정 한 후 [Create]를 클릭합니다. 보안 설정이 콘솔에 표시됩니다.

이러한 작업을 완료 한 후, 새로 EMR 클러스터를 만들 때 설정을 선택할 수 있습니다. 본 기능은 Amazon EMR 자료 4.8.0 또는 5.0.0을 사용하는 클러스터에서 사용할 수 있습니다. 자세한 내용은 a href=”http://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/emr-data-encryption.html”>Amazon EMR Encryption with Security Configurations를 참조하십시오.

Jeff;

이 글은 Additional At-Rest and In-Transit Encryption Options for Amazon EMR의 한국어 번역입니다.

Amazon EMR 5.0.0 – 주요 버전 업데이트, 사용자 UI 개선, 디버깅 향상 등

Amazon EMR 팀은 올해 새로운 버전을 무서운 기세로 출시하고 있습니다. 올해 출시를 되돌아 봅시다.

  • EMR 4.7.0 – Apache Tez, Apache Phoenix, Presto, HBase, Mahout (6월)
  • EMR 4.6.0 – 대량 데이터에 대한 실시간 접근를 위해 HBase 추가 (4월)
  • EMR 4.5.0 – Hadoop, Presto, Spark와 EMRFS 추가 (4월)
  • EMR 4.4.0 – Sqoop, HCatalog, Java 8 등 (3월)
  • EMR 4.3.0 – Spark, Presto, Ganglia (1월)

오늘은 EMR 5.0.0이 발표되었습니다. 이제 EMR은 16개의 오픈 소스 Hadoop 에코 시스템 프로젝트를 지원하고 있습니다. Spark와 Hive의 주요 버전 업그레이드, Tez를 Hive와 Pig 기본으로 사용, Hue와 Zeppelin의 UI 개선 및 디버깅 기능 개선이 포함되어 있습니다.

아래 도표는 최근 출시를 통해 EMR이 어떻게 진화해 왔는지 살펴 볼 수 있습니다.

이제 EMR 5.0.0의 새로운 기능을 확인해 보겠습니다!

16가지 오픈 소스 Hadoop 에코 시스템 프로젝트 지원
Amazon EMR 4.0.0에서 EMR 빌드 및 패키징 프로세스를 관리하기 위해 Apache Bigtop를 사용하기 시작했습니다. 최근에 주요 오픈 소스 버전을 가능한 한 빠르게 탑재할 수 있도록 한다는 목표를 위해 Hadoop 생태계에서 새 패키지를 추가하면서도, 출시 주기를 단축 할 수 있었던 것은 Bigtop 사용 덕분입니다.

이러한 목표하에 EMR 5.0은 총 16가지 Hadoop 에코 시스템 프로젝트를 지원하고 있으며, 그 중에는 Apache Hadoop, Apache Spark, Presto, Apache Hive, Apache HBase, Apache Tez 등을 포함합니다. EMR 클러스터를 만들 때 필요한 응용 프로그램을 직접 선택할 수 있습니다.

Spark와 Hive의 주요 버전 업그레이드
이번 EMR 버전에서는 Hive(Tez 및 Hadoop MapReduce의 SQL 기반 인터페이스)가 1.0에서 2.1로 업데이트 되고, 동시에 Java 8로 이전했습니다. 또한, Spark(대량 인메모리 데이터 처리 엔진)도 1.6.2에서 2.0로 업데이트되고, 동시에 Scala 2.11로 전환했습니다. Spark와 Hive 주요 버전 업데이트를 통해 새로운 기능, 성능 개선, 그리고 버그 수정을 포함하고 있습니다. 예를 들어, Spark는 Structured Streaming API 추가, SQL 지원 개선 등이 포함되어 있습니다. 그러나, Spark와 Hive 신규 버전은 100% 하위 호환성을 가지고 있지 않습니다. 따라서, 여러분 코드가 잘 동작하는지 확인 하신 후, EMR 5.0.0로 업데이트 해 주시기 바랍니다.

이번 릴리스에서 Hive 2.1 Pig 0.16에서는 Hadoop MapReduce 대신 Tez이 기본 엔진이 성능이 개선 된 쿼리의 대기 시간을 줄일 수 있습니다. 이 업데이트는 MapReduce는 Hadoop MapReduce 작업을 직접 수행 된 경우에만 사용되게되었습니다. (Hive와 Pig는 Tez를 사용하고, Spark는 자체 프레임 워크를 가지고 있습니다.)

사용자 인터페이스 개선
또한, EMR 5.0.0에서는 Apache Zeppelin(대화형 데이터 분석 도구)을 0.5.6에서 0.6.1로 업데이트, Hue(Hadoop 데이터를 분석하기 위한 인터페이스)를 3.7.1에서 3.10로 업데이트 했습니다. 이러한 웹 기반 도구의 새 버전에서는 새로운 기능과 다수 마이너 개선 사항이 포함되어 있습니다.

Zeppelin은 Spark와 자주 사용되며, Hue는 Hive, Pig, HBase와 함께 사용됩니다. 새로운 버전의 Hue는 여러 쿼리를 하나의 동일한 페이지에서 수행 할 수 있게되었습니다.

Hue는 Oozie워크 플로우 디자인을 할 수도 있습니다.

디버깅 기능 개선
마지막으로, EMR 5.0.0 디버깅 기능 개선 기능도 포함되어 있습니다. 특정 EMR 작업 단계가 왜 실패했는지를 쉽게 확인할 수 있습니다. 콘솔에는 스택 트레이스 일부와 로그 파일 (Amazon S3에 저장)에 대한 링크가 표시되어, 쉽게 문제를 확인하고 해결하고 오류를 수정할 수 있습니다.

지금 시작하기
EMR 5.0.0 오늘부터 모든 AWS 리전에서 시작할 수 있습니다! EMR Console을 열고 Create cluster를 클릭 한 후, Release 메뉴에서 emr-5.0.0을 선택하면됩니다.

더 자세히 보기
새로운 EMR의 출시를 더 자세하게 알고 싶은 경우에는 8월 23일 온라인 세미나 Introducing Amazon EMR Release 5.0: Faster, Easier, Hadoop, Spark, and Presto에도 참여하시기 바랍니다.

Jeff;

이 글은 Amazon EMR 5.0.0 – Major App Updates, UI Improvements, Better Debugging, and More의 한국어 번역입니다.

Elastic Map Reduce 4.0.0 버전 출시 – 최신 업데이트 추가

Amazon EMRApache HadoopApache Spark 등 빅데이터 프레임 워크를 쉽게 AWS 내에서 실행하여 대량 데이터 분석을 할 수 있도록 지원하는 클러스터 관리 플랫폼입니다. 이러한 프레임 워크와 Apache HiveApache Pig 등 관련 오픈 소스 프로젝트를 함께 사용하여 데이터 분석 목적과 지능형 비즈니스(BI) 분석 등을 할 수 있습니다. 2009년에 처음 출시한 이후 (Announcing Amazon Elastic MapReduce), 그동안 다양한 콘솔 기능 지원과 많은 주요 기능 추가를 진행해왔습니다. 최근 몇 가지 기능 추가 소식은 아래와 같습니다.

오늘 Amazon EMR 4.0.0 버전을 발표합니다.

신규 버전은 기존 플랫폼에 많은 변화를 가져옵니다.특히, Hadoop 및 Spark의 최신 버전을 포함하고 있어 기존 클러스터에 설치 가능한 응용 프로그램의 설정 방법이 크게 개선됩니다. Hadoop과 Spark의 몇 가지 표준 및 규약을 준수하도록 일부 포트 및 경로 설정을 조정했습니다. 다른 AWS 서비스가 특정 버전 별로 출시하지 않고 뒤에서 지속적으로 자주 업데이트가 이루어지고 있는 것과는 달리 EMR은 기존 오픈 소스 버전 기반 출시를 해오고 있기 때문에 특정 EMR 버전에서만 사용할 수 있는 기능과 응용 프로그램을 사용하는 프로그램이나 스크립트를 작성할 수 있습니다.

만약 현재 AMI 버전 2.x 또는 3.x를 사용하시는 경우, 4.0.0으로 어떻게 마이그레이션할 것인지는 EMR 버전별 가이드를 읽어 보시기 바랍니다.

응용 프로그램 업데이트
EMR 사용자는 Hadoop 플랫폼 생태계 내 여러 응용 프로그램을 사용할 수 있습니다. 이 버전의 EMR은 다음 업데이트가 추가되었습니다:

  • Hadoop 2.6.0 – 다수의 일반 기능과 사용성 개선 사항이 포함
  • Hive 1.0 – 성능 개선, SQL 지원의 추가 몇 가지 보안 기능 포함
  • Pig 0.14 – ORCStorage 클래스 성능 개선, Predicate Pushdown, 버그 수정 등
  • Spark 1.4.1SparkR을 위한 바인딩과 새로운 Dataframe API 및 다양한 기능 추가 및 버그 수정 포함

콘솔에서 빠른 클러스터 생성
콘솔에서 빠른 클러스터 설정(Quick cluster configuration)을 사용하여 EMR 클러스터를 만들 수 있습니다:

응용 프로그램 설정 편집 개선
Amazon EMR AMI 버전 2.x 및 3.x에서는 클러스터 내 응용 프로그램 설정을 위해 bootstrap action을 주로 사용하였습니다. Amazon EMR 버전 4.0.0에서는 클러스터를 만들 때 응용 프로그램의 기본 설정을 편집하는 직접적인 방법을 제공하도록 개선하였습니다. 편집할 설정 파일의 목록과 그 파일의 변경 사항 설정 개체를 전달할 수 있는 기능을 추가했습니다. 설정 객체는 CLI 또는 EMR API와 콘솔에서 만들어 볼 수 있습니다. 설정 정보는 로컬이나 Amazon Simple Storage Service (S3)에 저장하여 참조 할 수 있습니다 (콘솔을 사용하는 경우, 설정 값을 지정하거나 설정 파일을 사용하기 위해 클러스터를 만들 때 Go to advanced options를 클릭하십시오).

더 자세한 내용은 응용 프로그램 설정 문서를 살펴 보시기 바랍니다.

새로운 패키징 시스템 / 표준 포트와 경로
신규 버전에서는 Apache Bigtop 기반의 새로운 패키징 시스템을 출시했습니다. 이를 통해 더 빨리 새로운 응용 프로그램이나 새 버전을 EMR에 추가 할 수 있습니다.

또한, EMR 버전 4.0.0의 많은 포트와 경로를 오픈 소스 표준으로 변경했습니다. 이러한 변경 사항에 대한 자세한 정보는 4.x 변경 사항 문서를 살펴 보시기 바랍니다.

Spark를 위한 EMR 추가 설정

EMR 개발팀에서는 몇 가지 기술 팁을 여러분께 공유 드리고자 합니다.

Spark on YARN은 Spark 응용 프로그램에 사용되는 executor의 수를 동적으로 확장 할 수 있습니다. 하나의 executor가 사용하는 메모리(spark.executor.memory)와 코어(spark.executor.cores)는 spark-defaults에서 지정할 필요가 있으나, YARN은 Spark 응용 프로그램이 필요한 만큼의 executor를 자동으로 할당하게 됩니다. 동적 executor 할당을 활성화하려면 spark-defaults 설정 파일에서 spark.dynamicAllocation.enabled을 true로 설정합니다. 또한, Spark shuffle service가 Amazon EMR에서는 처음부터 활성화되어 있으므로 직접 설정할 필요가 없습니다.

클러스터 작성 시 maximizeResourceAllocation 옵션을 true로 하면 executor가 각 노드에서 사용 가능한 자원을 최대한 활용하도록 설정할 수 있습니다. 클러스터를 만들 때 설정 개체에서 “spark” 클래스 속성을 추가하여 설정할 수 있습니다. 이 옵션은 core node group 노드에서 사용 가능한 최대 CPU와 메모리 자원을 계산하여 이 정보를 바탕으로 관련 spark-defaults 값을 설정합니다. 클러스터 생성 시 지정된 첫 번째 core node의 숫자로 spark.executor.instances을 설정하여 executor 수도 정합​​니다. 참고로 이러한 설정은 동적 executor 할당과 함께 사용할 수 없습니다.

이러한 옵션에 대한 더 자세한 내용은 Configure Spark 문서를 살펴 보시기 바랍니다.

정식 출시
위의 모든 기능은 지금부터 이용 가능하며, 오늘부터 사용하실 수 있습니다.

만약 대규모 데이터 처리 및 EMR 사용이 처음이라면, Amazon EMR 시작하기 문서를 참조하십시오. 새로운 동영상 소개와 교육 및 프로페셔널 서비스에 대한 정보를 볼 수 있습니다. 빠르고 효율적으로 EMR에 대해 공부하실 수 있습니다.

Jeff;

이 글은 Elastic MapReduce Release 4.0.0 With Updated Applications Now Available의 한국어 번역입니다.

Amazon EMR, Apache Spark 지원 시작

Amazon EMR에서 새로 출시한 막강 기능을 소개하기 위해 제 동료 존 프리츠(Jon Fritz)의 글을 게재합니다.
Jeff;


Amazon EMR(Elastic MapReduce) 서비스가 Apache Spark를 지원하게 된 점을 알려드리게 되어 기쁩니다. Amazon EMR은 Hive, Pig, HBase, Presto, Impala, 및 그 외 여러가지 하둡 생태계 애플리케이션을 이용하여 방대한 데이타를 처리하기 쉽게 해 드리는 서비스입니다. 스파크(Spark) 또한 이 목록에 공식적으로 추가 시키게 되어 저희 Amazon EMR팀도 기쁘게 생각합니다. 물론 많은 고객들이 이미 예전부터 별도 스크립트를 이용하여 스파크를 설치해 사용해 왔지만, 이제부터는 Amazon EMR 콘솔 또는 CLI, API등을 통해 스파크가 설치된 Amazon EMR을 바로 띄울 수 있습니다.

Apache Spark: 차세대 Hadoop MapReduce

저희는 대규모 스케일 데이터 프로세싱과 배치 프로세싱, 비정형 데이타 애드 혹(ad hoc) 분석, 머신 러닝 등에서 하둡 맵리듀스(Hadoop MapReduce)를 매우 성공적으로 활용하는 고객 사례를 많이 보았습니다. 이제 하둡 생태계의 새로운 분산처리 프레임워크인 아파치 스파크는 잡(job) 처리성능의 꾸준한 향상과 특정 워크로드의 개발 가속도 등을 통해 매력적인 엔진임을 스스로 증명해 보였습니다.

스파크는 DAG(Directed Acyclic Graph, 비순환 방향 그래프) 실행 엔진을 이용하여 데이타 변환을 위한 질의계획(query plan)을 더욱 효율적으로 만들 수 있습니다. 또한, 스파크는 인메모리(in-memor) 및 무장애(fault-tolerant) 분산 RDD(Resilient Distributed Datasets), 중간 결과값, 입력, 출력을 디스크 대신 메모리에 보관하기 등의 기술도 제공합니다. 이 두 가지 기능 요소로 인해 특정 워크로드에서는 하둡 맵리듀스에 비해 훨씬 우수한 성능을 보여줄 수 있습니다. 하둡 맵리듀스는 잡을 맵리듀스 프레임워크에 순차적으로 들어가도록 강제하고 중간 결과값은 디스크에 저장함으로써 부가적인 I/O를 만들어내기 때문이죠. 스파크의 향상된 성능은 특히 머신러닝과 빠른응답을 요구하는 질의문 등에 흔히 사용하는 인터랙티브 워크로드 (interactive workload)에서 빛을 발합니다. 거기에 더해 Scala, Python, Java API 등을 자체 지원하고 SQL 및 인기 있는 여러가지 머신러닝 알고리듬, 그래프 처리, 스트림 처리 등을 위한 라이브러리도 내장하고 있습니다. 이런 강력한 통합 개발 옵션을 이용하면, 스파크 애플리케이션을 개발하고 운영하는 것이 하둡 맵리듀스 API 위에 얹어 놓은 여러 추상화 계층 위에서 작업하는 것보다 더 간편할 수 있습니다.

Spark on Amazon EMR 소개

오늘부터 Amazon EMR이 아파치 스파크도 지원합니다. 여러분은 Amazon EMR 콘솔 또는 AWS 커맨드 라인 인터페이스(CLI), Amazon EMR API 등을 통해 확장 가능하면서(scalable) AWS가 관리해 주는 스파크 클러스터를 Amazon Elastic Compute Cloud (EC2) 인스턴스 타입 위에 쉽고 빠르게 생성할 수 있습니다. Amazon EMR 컨테이너에서 엔진 구동 시, 스파크는 EMRFS 이점을 활용해 Amazon Simple Storage Service(S3) 데이타 직접 접근하기, Amazon S3에 로그 밀어넣기, 비용을 낮추기 위한 EC2 스팟 인스턴스 등을 이용할 수 있으며, 또한 Amazon EMR에 통합되어 있는 IAM 역할(Roles), EC2 보안그룹 (security groups), S3 저장소 암호화 (server-side 및 client-side) 등의 AWS 보안 기능도 사용할 수 있습니다. 거기에 더해, Amazon EMR에 스파크를 구동하는 데에는 기존에 Amazon EMR을 구동하는 비용 외에 더 추가되는 비용은 없다는 것도 장점입니다.

스파크는 빠른 응답을 위한 스파크 SQL (Spark SQL), 인터랙티브 SQL 질의, 확장가능한 분산 머신러닝 알고리듬을 내장한 독창적인 MLlib 라이브러리, 무장애(resilient) 스트림처리 애플리케이션을 위한 스파크 스트리밍 (Spark Streaming), 그래프 처리용 GraphX 등을 내장하고 있습니다. 또한, 추가적으로 스파크 모니터링이 필요할 때에는 Amazon EMR 위에 강글리아(Ganglia)를 설치할 수도 있습니다. 배치잡이 필요하다면 EMR Step API를 통해 스파크 스텝을 추가하는 식으로 스파크에 워크로드를 보낼 수도 있고, 인터렉티브한 워크플로우가 필요하다면 스파크 API를 이용하거나 클러스터 마스터 노드에서 스파크 셸(Spark Shell)을 통해 직접 질의를 주고받을 수도 있습니다.

고객 활용 사례

오늘 출시 이전부터 이미 많은 고객들이 Amazon EMR 위에 부트스트랩 액션을 통해 스파크를 설치해 사용왔습니다. 몇 가지 사용 사례를 들면:

  • 퓰리쳐상을 수상한 일간지인 워싱턴 포스트사는 독자들에게 보여주기 위한 부가 콘텐츠 추천 엔진으로 스파크를 사용합니다.
  • 사용자와 지역 비즈니스를 잊는 소비자 애플리케이션인 옐프(Yelp)는 전시 광고 클릭 비율을 높이기 위해 스파크에 내장된 머신러닝 라이브러리인 MLlib를 활용합니다.
  • 대형 복합 미디어 정보 회사인 허스트 코퍼레이션(Hearst Corportation)사 미디어 기사 효과와 토픽 트렌드를 실시간으로 보기 원해 200개가 넘는 웹사이트 자산에서 나오는 클릭스트림 데이터를 빠르게 처리하기 위해 스파크 스트리밍을 이용합니다.
  • 크룩스(Krux)사는 본사의 데이터관리 플랫폼 제품이 Amazon S3에 저장되어 있는 로그 데이터를 처리할 수 있도록 만들기 위해 스파크를 도입하고 EMRFS (EMR File System)를 활용합니다.

스파크로 분석하기 – 초간단 예제

Spark on Amazon EMR을 이용하여 데이타 처리하기 작업을 얼마나 빨리 시작할 수 있는지 예제를 보여드릴텐데요, 미국 국내 항공편에서 비행편 지연과 취소에 대해 몇 가지 질문을 해보겠습니다.

미국 연방교통국(The Department of Transportation)은 지난 1987년까지의 비행편 정보를 담은 데이타를 공개해 두었습니다. CSV 포맷인 해당 파일을 제가 다운 받아서 컬럼 기반의 Parquet 포맷(좀 더 나은 성능을 보임)으로 변환 시킨 다음에, 누구나 접근할 수 있는 읽기 전용 S3 버킷에 업로드 해두었습니다 (s3://us-east-1.elasticmapreduce/samples/flightdata/input). 데이타 세트는 압축 상태로 4GB 정도 (압축 풀린 상태에서는 79GB) 이고 162,212,419개 행(rows)을 담고 있기 때문에 질의문을 던지려면 스파크 같은 분산 프레임워크를 사용하는 게 합리적입니다. 제가 던지려는 질의는 비행기를 가장 많이 출발 시킨 공항 10개, 15분 이상 항공편이 지연되었던 건수가 가장 많은 공항, 60분 이상 지연되었던 건수가 가장 많은 공항, 비행 취소 건수가 가장 많은 공항 등입니다. 그리고 분기별 항공취소 건수도 궁금하고 가장 인기 있는 경유 공항 10개도 알고 싶네요.

이 질문들을 우선 SQL 질의문으로 작성했구요, 이를 실행하기 위해 스칼라 프로그래밍 언어로 스파크 애플리케이션을 작성했습니다. 코드는 여기서 다운받을 수 있습니다. s3://us-east-1.elasticmapreduce.samples/flightdata/sparkapp/FlightExample.scala 코드 일부를 아래에 발췌 했으니 함께 보시죠.

val parquetFile = hiveContext.parquetFile("s3://us-east-1.elasticmapreduce.samples/flightdata/input/")

//Parquet files can also be registered as tables and then used in SQL statements.
parquetFile.registerTempTable("flights")

//Top 10 airports with the most departures since 2000 
val topDepartures = hiveContext.sql("SELECT origin, count(*) AS total_departures FROM flights WHERE year >= '2000' GROUP BY origin ORDER BY total_departures DESC LIMIT 10")
topDepartures.rdd.saveAsTextFile(s"$OutputLocation/top_departures")

인메모리 RDD 안에 “flights”라는 테이블을 만들고, 각 SQL 질의들은 I/O 비용을 줄이기 위해 이 테이블을 이용한다는 점에 유의해 주세요. 그리고, EMR안에 있는 스파크는 S3 데이타를 HDFS에 복사할 필요 없이 직접 접근하기 위해 EMRFS를 사용합니다. 이 애플리케이션은 제가 JAR로 묶어서 여기에 올려두었습니다 https://s3.amazonaws.com/us-east-1.elasticmapreduce.samples/flightdata/sparkapp/flightsample_2.10-1.3.jar.

이 애플리케이션을 m3.xlarge 노드 세 개로 구성한 Amazon EMR 클러스터에 스파크와 함께 띄워보겠습니다. 샘플 데이터 세트가 미국 동부 리전에 있기 때문에, 클러스터도 해당 리전에서 띄워야 한다는 점 꼭 기억해 주세요. Amazon EMR 콘솔에서 Create Cluster 페이지로 가셔서, Termination ProtectionLogging을 비활성화 시키세요 (Cluster Configuration 항목에 있습니다). Software Configuration 항목으로 내려가서 Additional Application에 스파크(Spark)를 추가하세요.

Configure and add를 클릭한 다음에, Arguments 텍스트상자에 -x 를 입력하세요. 이 파라미터는 스파크 익스큐터(executor) 기본설정값을 바꾸는 것인데요, 이 익스큐터가 여러분 애플리케이션을 실제로 수행하는 그 프로세스입니다.

AMI 3.8에 내장된 스파크는 아파치 기본값인 익스큐터 2개와 램(RAM) 1GB로 설정되어 있기 때문에, 여러분의 스파크 애플리케이션을 구동 시킬 때에는 이 설정을 덮어쓰기 해서 클러스터 자원을 더 많이 활용토록 하는 것이 좋습니다. -x는 클러스터 생성 시 만든 코어노드 수 만큼 익스큐터를 생성케 하고, 각 익스큐터마다 RAM과 vcores 값을 해당 코어노드가 허용하는 최대값으로 설정합니다. 실제 잡 수행성능은 익스큐터 설정에 따라 다르기 때문에, 미리 테스트를 해보고 설정 최적값을 찾아보시길 권합니다. 또한, 실제 스파크 수행(Spark-submit) 명령줄에 추가 파라미터를 전달함으로써 이 설정값을 덮어쓰는 것도 가능합니다.

다음으로, 스텝 2개를 추가하기 위해 페이지 바닥쪽에 있는 Steps 항목으로 내려가세요. 첫 번째 스텝에서는 S3에 있는 스파크 애플리케이션 JAR 파일을 클러스터 마스터 노드로 복사할 껍니다. Custom Jar 스텝을 추가하면서 JAR 위치를 s3://elasticmapreduce/libs/script-runner/script-runner.jar로 설정하고 Arguments 텍스트상자에는 /home/hadoop/bin/hdfs dfs -get s3://us-east-1.elasticmapreduce.samples/flightdata/sparkapp/flightsample_2.10-1.3.jar /mnt/를 입력하세요. Action on failure 옵션은 Terminate cluster로 설정한 다음 Add를 클릭하세요.

두 번째 스텝으로는 스파크 애플리케이션(Spark application) 스텝을 추가합니다.

Configure and add를 클릭하면 뜨는 설정 페이지에서 Deploy ModeClient를 선택하세요. 이는 애플리케이션을 로컬 경로에서 시작시키기 위함입니다 (첫 번째 스텝에서 S3에 있는 애플리케이션을 클러스터로 복사해 두어야 합니다). Spark-submit options에는 --class FlightSample를 입력하고 Application location란에는 /mnt/flightsample_2.10-1.3.jar를 입력하세요. Arguments에는 스파크 결과값을 저장할 S3 버킷 경로를 집어넣은 다음에, Action on failureTerminate cluster를 선택하고 Add를 클릭합니다.

Amazon EMR은 클러스터를 띄우고 여러분의 애플리케이션을 실행한 다음에, 잡(job)이 끝나면 클러스터를 종료(terminate)시킵니다. EMR 콘솔에서 Cluster Details 페이지를 보면 작업의 진행상황을 모니터할 수도 있구요. 일단 작업이 완료되면, 해당 질의문 결과값은 여러분이 지정한 S3 버킷에서 확인할 수 있습니다. 여러분이 직접 해보시도록 여기에 그 결과를 적지 않겠습니다만, 시카고 오헤어 공항을 자주 이용하신다면 꼭 한 번 이 예제를 돌려보세요.

오늘 바로 Amazon EMR 클러스터에 스파크를 얹어서 띄워보세요!

Spark on Amazon EMR에 대한 더 자세한 내용은 Spark on Amazon EMR 페이지를 방문해 보시기 바랍니다..

존 프리츠(Jon Fritz), AWS 시니어 제품 매니저

이 글은 New – Apache Spark on Amazon EMR의 한국어 번역으로서, 미국 AWS 프로페셔널 컨설턴트로 일하고 있는 이종남님께서 수고해 주셨습니다.