궁금한 이야기 Y

그들이 AWS 위에서

데이터 파이프라인을 운영하는 법

AWSKRUG 데이터 사이언스

Aug 8, 2019

1ambda @ yanolja

bit.ly/2Kfgt1y

본 슬라이드에 나온 내용은 �회사의 입장을 대변하지 않으며

개인적 견해임을 미리 밝힙니다.

AWS, Cloud Native, Enterprise (동영상 링크)

AWS, Data Pipeline (슬라이드)

• kun @ apache.org

(Apache Zeppelin Committer) 활동 언제 다시 할거니

• kun @ yanolja (Data Engineer) 데이터 노동자
• 1ambda.blog (Blog 😎)

​

AWS, Kubernetes, Build Pipeline (동영상 링크)

1. 궁금한 이야기 Y - 그들은 무슨 데이터를 다루나?
2. AWS 위에서 데이터 파이프라인 구축하기
3. 오픈소스를 이용해 사용자 (수백명+) 데이터 활용 돕기
4. Kubernetes 위에서 개인별 분석환경 제공하기

​

Contents

bit.ly/2Kfgt1y

오늘 할 이야기는

“사례 1번"

에 관한 이야기

“오늘 들은 내용을 적용하면 문제가 다 해결 되나요?”

부대찌개 문제를 틀리면 3일을 펭귄으로 사는데�데이터 인프라를 잘못 구축하면 며칠을 펭귄으로 살아야 할까? 197일쯤?

데이터의 생산부터 소비까지 파이프라인 과정에서 �각 주체들이 빠르고 쉽게 데이터를 다룰 수 있는 방법 1 에 대해 논의

​

• 가능하면 적은 인원으로 최대한의 데이터를 (사이즈) 다루고 싶어요
• 비용이 많이 들지 않게 데이터 인프라를 구축할 수 있을까요?
• 운영 (마케팅, 정산 등) 작업을 (일부) 자동화 할 수는 없을까요?
• 분석가가 자유롭게 이용할 수 있는 개인별 분석 환경을 주고 싶어요�분석가 님이 미쳐 날뛰고 있습니다

​

​

​

오늘 할 이야기는

생산

소비

회사마다 다른 것들

데이터 사이즈 “Uber 는 저걸 쓴다던데..” 일단 이곳은 샌프란시스코가 아닙니다

• 데이터의 사이즈에 따라 필요되는 인프라가 다 다릅니다.

​

사용자 수 “우리 사용자 수는 2500명이지만, 지금은 딥러닝이 대세이므로 제가 한번..."

• 사용자 수가 2500명이면, 개인화 딥러닝 추천 (구현 2개월) 보다는 그거 할 때가 아닌 읍읍�인기상품 (구현 3일) 이 더 낫지 않을까요?

도메인 “모빌리티 (택시) 는 실시간으로 Flink Streaming 을…”

• 도메인에 따라 (숙박, 모빌리티 등) 중요시 하는 데이터와 그 주기 (실시간) 이 달라요.�

데이터 사용자의 지식 수준 너와 나 “AirBnB 분석가는 머신러닝을 쓴대요”

• 어떤 회사는 다수의 사람이 SQL 에 익숙하지만, 어떤 회사는 그렇지 않을수도 있어요.

​

​

“데이터에는 정답이 없습니다” by 팀장님

“다만 남들의 Best Practice 를 참고해 볼 수는 있습니다”

• 궁금한 이야기 Y - 그들은 무슨 데이터를 다루나?
• 클라우드 (AWS) 위에서 데이터 파이프라인 구축하기
• 오픈소스를 이용해 사용자 (수백명+) 데이터 활용 돕기
• Kubernetes 위에서 개인별 분석환경 제공하기

Contents

bit.ly/2Kfgt1y

| 국내 숙박

| 해외 숙박

같아 보이지만 �업체 형태나 �숙박 형태에 따라 �데이터의 구조와 �분석 형태가 많이 다름

1) 어느 숙박 카테고리에 단박 (1일) / 연박 (2일 +) 이 많을까?

• 모텔 / 호텔 / 펜션 / 게스트하우스

2) 어떤 카테고리가 더 계절을 많이 탈까?

3) ADR (평균 객실 단가) 는 어느곳에서 더 중요할까?

4) 경쟁 업체 비교를 한다면, 어떤 기준으로 선정해야 할까?

• 강원도에 있는 펜션간 거리는?
• 삼성역에 있는 부띠끄 모텔간 거리는?
• 가까운 호텔끼리만 경쟁업체 비교를 하는것은 의미가 있을까?

​

​

​

| 레저

| 티켓

| 건설

| 교육

| 비품

X 커머스

재고, 상품, 주문, �정산, 쿠폰, 포인트, 고객, …�+ B2B (업주 관련 통계 등)

​

데이터 파이프라인

= 데이터 수집 (흩어진걸 모아서 한 곳에 저장)

+= 데이터 처리 (유용하게 가공)

+= 데이터 조회 (저장된 것을 사람이 소비)

+= 데이터 서비스 (서비스에 다시 내보내기)

사랑은 돌아오는거야!

숙박업 도메인 이야기 조금

엔지니어 분들이

이 슬라이드를 싫어합니다

OTA - Online Travel Agency

해외 (글로벌) OTA

OTA - 사실은 잘 보면 Group 들

Booking Holdings

Expedia Group

• 50 만개 이상의 숙박 업체
• 재고 소싱 뿐만 아니라
• 추천 (Recommendation) API 등

OTA - 그룹 내 다양한 데이터를 이용해 서비스로 제공

EPS (Expedia 외부 연동 솔루션)

채널 매니저란 것도 있습니다

CMS - Channel Management System

일반적으로 하나의 업체는

• 여러 OTA 등록 (야놀자, 네이버 등 국내 포함)
• 그러나 건물의 객실은 물리적으로 유한 (e.g 20개)

오버 부킹이 제일 두렵습니다

​

​

한 OTA (야놀자) 에서 판매되면

• 나머지 OTA (Agoda, Booking.com, Airbnb 등 ) 모두 가서 재고를 수정해야 할까?

옆집이 가격을 내려서, 나도 내리고 싶은데

• 연동된 20개 OTA 모두 가서 가격을 수정해야 할까?

CMS 는 한 곳에서 재고 / 가격 (숙박업에서 가장 중요한) 을 관리할 수 있도록 도와줌

PMS - Property Management System 다음은 SMS 냐

숙박업의 경우, 업체 입장에서는

• 자신의 객실을 관리할 수 있는 시스템이 필요 (타임라인 등)
• 고객이 카드키를 넣고 빼거나 (Check-in, Check-out) 청소중일 경우 등 실시간으로 시스템 반영

플랫폼 입장에서는 PMS 와 연동되어 있을 경우 고객의 물리적 객실 재고를 실시간으로 모두 파악 가능 😎

​

​

숙박업에선 데이터를 �어떻게 사용하나요? 🤭

숙박 재고의 경우 다음의 특성이 존재

• 아이템 (Property - 호텔 A) 의 옵션 (Room Type - 디럭스, 스위트) 이 다양할 수 있음 (커머스와 유사)
• 하나의 옵션에 여러개의 부가옵션 (Rate Plan - 조식 1인 포함) 이 붙을 수 있음
• 하나의 아이템-옵션 이 날짜에 의해 뻥튀기 (커머스와 차이)
• 씨마크 호텔 스위트 디럭스 룸 조식 포함 1개 -> 90 일치 예약 = 90 개

= 아이템 X 옵션 X 날짜 만큼의 재고가 생성

= 같은 아이템 X 옵션이어도 날짜에 따라 가격이 달라짐 (= 다른 상품)

부가 옵션 (Rate Plan) 의 경우 정말 다양한 조합이 존재

• 조식 포함 (1인, 2인), 환불 불가, 공항 픽업, 공항 픽업 + 샌딩
• 모든 경우에 대해 판매될 수 있는 상품이 생성

= 아이템 X 옵션 X 날짜 X Rate Option 만큼의 상품이 생성

​

​

​

숙박업 데이터 생김새 - 재고 (Room Type, Rate Plan)

동일한 Room Type 에

• 다른 Rate Plan 을 조합

​

숙박업 데이터 생김새 - 재고 (Room Type, Rate Plan)

업주 입장에선 (높은) 가격이 제일 중요

고객 입장에서도 (낮은) 가격이 제일 중요

​

플랫폼 입장에서는 아래 내용을 모두 고려

• 과거의 가격 변동 (작년 동일 날짜)
• 시즌 (여름 성수기 등), 공휴일
• 최근의 가격 추이 (리모델링)
• 주변 업체들의 가격 변화
• 사용자 (Customer) 들의 수요
• 공급자 (Seller) 들의 재고
• 업주와 고객이 모두 만족하는 가격을 Smart Pricing 옵션을 키면 자동으로 설정

숙박업 데이터 활용 샘플 - Dynamic Pricing (AirBnB)

본론으로 다시 돌아가서

엔지니어분들 �표정이 좋지 않아졌어요. 😨

• 궁금한 이야기 Y - 그들은 무슨 데이터를 다루나?
• 클라우드 (AWS) 위에서 데이터 파이프라인 구축하기
• 오픈소스를 이용해 사용자 (수백명+) 데이터 활용 돕기
• Kubernetes 위에서 개인별 분석환경 제공하기

Contents

bit.ly/2FW9nwF

데이터 인프라

= 데이터 수집 (흩어진걸 모아서 한 곳에 저장)

+= 데이터 처리 (유용하게 가공)

+= 데이터 조회 (저장된 것을 사람이 소비)

+= 데이터 서비스 (서비스에 다시 내보내기)

B2C 더하기 B2B

X 커머스

재고, 상품, 주문, �정산, 쿠폰, 포인트, 고객, …�+ B2B (업주 관련 통계 등)

​

그들 = 3명

나를 뺀다 = 2명�(발표자는 9개월 전에 Join, 오니까 이미 모든게 되어있..)

@isaac.choo, @eunseons

입사 당일

어서와

리얼 월드는 처음이지?

서비스 데이터 분석을 위해

• 스타트업 초기에는 서비스 DB 에 직접 쿼리 (Read Replica)�다른 저장소는? 물리적으로 분할되어 있으면?
• 비즈니스 규모가 커지며 DB 를 물리적으로 분할하고�여러 DB 를 Join 한 분석 필요 (Order, Member, ..)
• DB 뿐만 아니라 ElasticSearch, ElastiCache 등 �다른 종류의 저장소와도 같이 보고 싶은 분석 요구
• Client (App/Web), Server Log 등 �이벤트 스트림저장 / 분석 필요
• DB 수준으로는 처리 불가능한 복잡한 / 대규모 컴퓨팅 필요 �(e.g. 50 Core, 400 GiB for a single job) DB는 거들뿐

​

​

​

​

​

Data Infra - 왜 데이터 인프라가 필요한가요?

파이프라인 기초�Batch 와 Stream

Data Infra - Batch & Stream

Batch - 주기적으로 데이터를 처리합니다.�(e.g. 1일, 1시간 등)

Data Infra - Batch 레이어

Stream - 데이터를 실시간으로 처리합니다.�(e.g. 즉시, N 초 Windowing 등)

Data Infra - Stream 레이어

Tumbling Window

​

Data Infra - Stream 레이어 (2,Window)

Sliding Window

​

Batch 는 이미 존재하는 데이터를 Bulk 로 로딩하나,

Stream 은 흘러 들어오는 데이터를 다룸 �지나간 것은 지나간대로

​

특정 기간동안의 상태 (User Session 등) 계산 위해�Streaming 프레임워크는 Application State 를 지원 (Spark, Flink 등)

• Application 내에서 집계 저장 (Incremental View)

​

State 는 메모리 (1차) 저장되므로

• 사이즈 (Key) 가 무한해 질 수 없음 (사용자 ID 등 )
• 특정 기간동안 (N 일) 등으로 Window 제한
• Key 는 TTL 등 설정해 오래되면 제거

​

일부 프레임워크는 Batch 와 Stream API 를 유사하게�구성해 로직을 재활용 하도록 지원 (Spark Structured)

Data Infra - Stream 레이어 (3, State)

Batch 와 Stream 레이어 집계를 합산�(기간별 + 실시간)

Data Infra - Serving 레이어

현재까지의 해당 업체 광고 클릭 수 �= 2019.01.01 ~ 어제까지의 모든 클릭 수 (Batch)

+= 오늘 00:00:00 부터의 클릭 수 (Stream)�

서빙 레이어는 고비용. 꼭 필요한 경우에만 사용�일반적으로는 배치 또는 스트림만 이용�

Data Infra - Serving 레이어 (2)

Coupang Experiment Platform : �지표(Metric) 연산 프레임워크의 변천사

​

서빙 레이어 (Batch + Stream 집계) 는 고비용

• Batch, Stream, Merge 총 3단계 집계 필요
• 집계 뿐만 아니라 저장소도 3개 필요

S3 (or RDS) Dynamo (or ES), RDS (or Druid 등)

(Batch) (Stream) (Serving)

​

따라서 일반적인 집계 (통계 등) 은 Batch 로 끝내고

실시간 집계가 필요한 경우만! (e.g. CPC 광고)

​

실시간 (Stream) 이라고 해서 항상 정확하지 않음�상당히 (N 시간) 늦게 들어오는 로그들이 있기 때문에 �일반적으로는 Batch 가 따라가면서 보정하는 형태��실시간에 가까워질 수록 여러분이 자다가 깨어날�확률이 높아집니다 😎

Data Infra - Serving 레이어 (3)

Data Infra - Serving 레이어 (4)

서빙 레이어 관련 읽을 거리

• Uber’s Big Data Platform: 100+ Petabytes with Minute Latency
• Hudi: Uber Engineering’s Incremental Processing Framework on Apache Hadoop
• Pinot: Near Realtime Analytics @ Uber
• Pinot Joins Apache Incubator
• Engineering Restaurant Manager, our UberEATS Analytics Dashboard

​

Druid 관련 읽을거리 삽질은 그만하고 싶어요 AWS Managed 로 내주세요

• Druid vs Pinot (Medium)
• Druid vs Pinot (Github Issue)
• Druid 관련 블로그 (한국어, Popit)

​

기초적인 내용을 알아봤으니

본격적으로 시작해볼까요?

데이터 인프라

= 데이터 수집 (흩어진걸 모아서 한 곳에 저장)

+= 데이터 처리 (유용하게 가공)

+= 데이터 조회 (저장된 것을 사람이 소비)

+= 데이터 서비스 (서비스에 다시 내보내기)

해야 할 것들이 이리도 많은데 🙊

​

Data Infrastructure - AWS (Example)

그들 = 3명

목표

• 운영 비용을 최소화
• 인프라 비용을 최소화
• 한 곳으로 모아 (S3), 통일된 언어로 조회 (SQL)

수집 대상

• 클라이언트 로그 (App / Web)
• 서버 로그 (Nginx / Application)
• Database 스냅샷 (Daily, Hourly)
• 기타 Storage 스냅샷 (Daily, Hourly)

Redis, ElasticSearch 등

• AWS 가 남기는 로그들�ELB / CloudTrail / CloudFront

​

Data Infra - 수집

Client 로그

Data Infra - Client 로그 샘플

노출 (Impression) / 클릭 (Click) / 뷰 (View) 등

앱 (iOS / Android / Web 등) 내에서 발생하는 로그

• 리스트 내 클릭, 업체별 뷰 카운트 등 �단순 통계부터 광고 등 서비스 용도로 사용 될 수 있음

​

작은 규모에서는 GA, Firebase 등의 이벤트 로깅 이용

규모가 커지면서 다양한 케이스, 해상도 (detail) 등을�위해 스키마 (형태)를 직접 정의해 사용하기도 함

​

​

Client 로그 (앱이나 웹에서 발생하는 이벤트 e.g. GA)

• Click / Impression (노출) 등 사용자의 액션 / 이벤트
• Server 로그와는 다르면서 유용한 정보를 포함
• 결제 로그 등의 경우 서드파티에 Feeding 되어�마케팅 성과 등 측정 용도로 사용될 수 있음

​

따라서 세심한 관리가 필요

좋은 퀄리티를 위해서는 별도의 툴들이 필요

• Client 로그 스키마 정의 도구
• Client 로그 검증 (QA) 도구
• Client 로그 입수량 확인 등�오픈소스로 누군가 내면 대박날거에요

Data Infra - 수집 (Client 로그)

일반적인 해결 방법은 Kafka

Kafka 는 고비용

- 운영 리소스 필요 (Upgrade, Monitor, ..)

- 일정 이상의 (3+) Broker 인스턴스 필요

- Zookeeper 클러스터 필요 (3+)

- 앞단에서 받아줄 ELB / Nginx / API 필요

차라리 이럴바엔..

​

​

Data Infra - 수집 (Client)

Data Infra - 수집 (Client)

설마 이 짤방을 모르신다면!

Data Infra - 수집 (Client)

​

​

Kinesis 는 Client SDK 존재 (App / Web)

• Android / iOS / Web
• AWS 관리형 서비스 �(Upgrade, Scaling, Monitoring)
• 써보니 비용도 더 저렴
• Payload 개당 1MB (Kinesis Limitation)

​

Data Infra - 수집 (Client)

다만 Connector 지원이 Kafka 에 비해 미비 😓

• Spark Structured Streaming
• Logstash Output 등

Server 로그

Data Infra - 수집 (Server)

서버 로그는 크게 2 가지로 나눌 수 있음

• WEB (Nginx)
• WAS (Application)

​

일반적으로 두 가지 형태로 수집

• Agent (Log File 을 읽어 Kafka 등으로 전송)
• Library (App 내에서 직접 Kafka 등으로 전송)

​

Agent 는 주로 WEB / WAS 의 Log File (stdout)

Library 는 중요 Event (e.g.결제, 로그인 등) 를 전송

• 일부 회사의 경우 Event 는 별도 Format 으로 관리

(Google ProtoBuf, Apache Avro 등)

Kinesis 로 직접 전송할 경우

• Java / Python / Ruby / Node / .NET SDK 지원
• Kinesis Agent 지원 (파일 읽어서 전송)
• AWS 관리형 서비스 �(Upgrade, Scaling, Monitoring)
• Payload 개당 1MiB (Kinesis Limitation)

Data Infra - 수집 (Server)

AWS EB (Beanstalk) 의 경우 로그 파일을 S3 퍼블리싱

• 수집 딜레이가 있으나 편하게 사용

Kinesis

• IP:PORT 기반의 접근 제어가 아니라 IAM 기반�EC2 (EB) 에 IAM Role 필요, 따라서�다수의 AWS Account 이용시 헬게이트 될 수 있음
• 대안으로 MSK (Managed Kafka)�4월에 도쿄 Region 에 런치, 5월 MSK GA�8월에 서울 Region 출시�갓 나온 매니지드는 쓰는게 아니라고 배웠�하지만 인간의 욕심은 끝이 없고 같은 실수를...

Data Infra - 수집 (Server)

Kinesis 로 보낸 아이들은 어떻게 되나요?

수집 대상

• 클라이언트 로그 (App / Web)
• 서버 로그 (Nginx / Server)

​

처리를 위해 EMR 을 이용

• AWS EMR 을 관리 할 때 몇 가지 팁들

Data Infra - 수집 (Kinesis)

EMR 은 일종의 Amazon 관리형 데이터 처리 프레임워크�다만 조금 비쌀뿐. Task Spot 을 애용합시다

• 버튼 누르면 원하는 만큼 리소스 늘려줌�수십 코어 수백 GB 도 5분 안에
• Spark (Streaming, Batch)
• Flink (주로 Streaming)
• Presto (빠르고 강렼한 분산 SQL Engine)
• 기타 Hbase, Zeppelin, Jupyter 등 설치

Data Infra - 수집 (Kinesis)

​

Spark Streaming 으로 가공해 (세션 ID 등. e.g. GA)

- Stream 레이어: 다른 Kinesis Stream 으로 보내거나

(별도 저장소 필요시 카운터 값 등 Dynamo 저장)�

- Batch 레이어: S3 에 저장 (SQL 쿼리 조회 가능)

- 준 실시간 View 를 위해 Hot S3 (1분 이내)

- 늦게 들어온 로그까지 처리한 Cold S3 (수시간 내)

Data Infra - 수집 (Kinesis)

Log (시계열) 데이터는 조회시 속도, 편의성을 위해 �어느시점에 들어온 것인지 파티션 단위로 관리

• 일 단위: p_ymd 2019/06/08
• 시간 단위: p_ymdh 2019/06/08/15

​

이 경우 늦게 들어온 로그는 어떻게 처리할지 정의해야 함

• (생성) Event Time 은 2019.06.08 15:30:01
• (수집) Kinesis Server Time 은 2019.06.08 16:01:01

​

로그가 늦게 들어오는 이유는 다양함! 문제는 언제 들어올지 알 수 없음 (Q. 미래의 로그가 들어온다면? 🤔)

늦게 들어오는 15시 로그를 위해, 6 시간동안 기다릴 수 있으나 (15 + 6 = 21)

“그러면 현재 들어오고 있는 로그는 어떻게 확인할 수 있을까?”

• 최근 6시간 동안의 로그 Hot S3 (1분 이내 적재)
• 6시간 늦게 들어온 로그까지 처리한 Cold S3

Data Infra - 수집 (Hot, Cold)

Storage 스냅샷

수집 대상

• Database 스냅샷 (Daily, Hourly)
• Redis 스냅샷 (Daily, Hourly)
• ElasticSearch 스냅샷 (Daily, Hourly)
• + 기타 사용하는 저장소 (Storage) 들

Data Infra - 수집 (Storage)

​

​

Storage 의 경우 다음의 문제와 씨름해야 함

• 숫자 (신규 DB, 기존 DB 컬럼 변경)
• 종류 (DB 도 특성이 다 다르고, ES, EC 등 존재)
• 규모 (예약과 같은 DB 의 경우 양이 나날이 늘어감)

​

현재는 입수 대상인 DB 의 컬럼 변경 사항을�자동으로 파악해서 데이터 관련자들에게 매일 알림

Data Infra - 수집 (Storage)

수집 대상: 저장소 (Storage)

​

EMR 이용해서 Batch 프로세싱 (Spark, PySpark)

• Daily, Hourly 로 Dump
• Scheduler 는 Digdag 사용

​

S3 를 메인 저장소로 사용

• Parquet: Columnar 포맷�(Presto Predicate Pushdown, 사이즈)

​

Hive MetaStore

• Metastore MySQL 은 별도의 RDS�”lower_case_table_names” 꼭 0 으로
• EMR 클러스터 중 하나를 HMS 로 사용
• Partition 추가는 별도의 스크립트로 운영

​

Data Infra - 수집 (Storage)

잠깐! Columnar 포맷이 뭐죠? 먹는건가요?

Parquet 는 Row (행) 이 아니라 Column (열) 기반 포맷

​

VCNC Apache Spark에서 Parquet 제대로 활용하기

​

기본적인 아이디어는

• “SELECT *” (ALL) 을 하는 경우보다는�직접 컬럼을 선택하는 경우가 잦음

=> 연산시 같은 컬럼 내 값들을 �비슷한 Disk 위치에 묶어두면 조회가 빠르지 않을까?

​

• 특정 컬럼들은 ENUM (LOGIN/LOGOUT) 값 처럼 �적은 종류의 값만 들어있음

=> LOGIN/LOGIN/LOGIN 을 매번 저장하지 않고, �값의 인덱스와 그 위치만 저장한다면 사이즈가 줄지 않을까?

​

Data Infra - 수집 (Parquet)

잠깐! Hive Meta 뭐죠?�마시는건가요?

Hive 메타스토어는 일종의 Schema 저장소 (RDS + Server)

• 실제 데이터는 S3 에 위치 (Parquet)
• Query 시 사용할 DB, Table, Partition 과 �해당 데이터들의 S3 위치를 가지고 있음

​

Managed 서비스로 AWS Glue Catalog 가 존재 하지만 IAM 으로 접근제어

Data Infra - 수집 (Storage - Hive MetaStore)

좌측 DDL 에서 볼 수 있듯이

• 테이블 생성시 데이터 경로 (S3) 지정
• 이후 파티션 추가 (Spark 작업에서 하거나 별도 스크립트)
• 이후 바로 Presto 에서 바로 쿼리 가능

​

읽을거리

• VCNC: Apache Spark 에서 Parquet 제대로 활용하기
• Hive: External vs Managed Table

Data Infra - 수집 (Storage - Hive MetaStore, 2)

테이블 생성

파티션 생성

데이터 조회

AWS 서비스 로그

수집 대상

• 클라이언트 로그 (App / Web)
• 서버 로그 (Nginx / Server)
• Database 스냅샷 (Daily, Hourly)
• Redis 스냅샷 (Daily, Hourly)
• ElasticSearch 스냅샷 (Daily, Hourly)
• AWS 가 서비스가 남기는 로그들

​

일부 AWS 서비스는 지정된 S3 Bucket 에 로그를 저장

• ELB (CLB, ALB, NLB, ...)
• CloudTrail (AWS Audit 로그, 누가 무엇을 했는지)
• CloudFront (CDN Access Log)

​

​

Data Infra - 수집 (AWS 로그)

AWS 가 남겨주는 서비스 로그의 경우 S3 에 저장

• 따라서 Hive Metastore 에 Schema 만 작성해주면 (DDL) 즉시 Presto 에서 쿼리 가능

​

다만 다수의 AWS Account 를 사용할 경우 관리가 복잡해짐

​

AWS 가 남겨주는 서비스 로그의 경우

• Owner 는 AWS 의 계정 (사용자 계정이 아님)
• 사용자 계정을 단지 Full Access 권한을 추가할 뿐

Data Infra - 수집 (AWS 로그)

S3 의 경우 Role-based (IAM) 로 권한 관리

• 다수의 AWS Account 를 사용하는 경우�한 Account 로 몰아서 저장 (Call Limit, 합병 등)
• 예를 들어 전사 ELB 로그는 Data AWS Account 에

​

AWS 가 남겨주는 로그의 실제 Owner 는 AWS 쪽 Account�단지 사용자 계정 (Prod) 에 Full Access 권한만 주는 것.

​

그럼 EMR (Presto) 로 조회하는 Data 쪽 계정은?

S3 Object 를 다 찾아 Data 쪽 계정을 권한 추가 하기 어려움

• AWS Call Limit?
• S3 Batch Operation? (2019. 05 추가)

권한 준다 하더라도 Data 쪽 계정이 사용하는 툴 (e.g Presto) 가 �assume-role 기능을 지원하지 않으면? 망했어요

Data Infra - 수집 (AWS 로그)

AWS 가 남기는 S3 는 EMR 이 위치한 Account 에서 관리!

• Assume role (A 계정이 B 계정의 Role 의 권한을 이용)�을 지원 하지 않는 라이브러리 / 툴이 있을 수 있음 e놈들..
• 최대한 Assume Role 을 사용 안 하는 것이 운영 포인트 �(e.g. IP:PORT 기반 접근 제어 등)

아마 난 안될거야. DynamoDB 사랑해요

Data Infra - 수집 (AWS 로그)

한장으로 요약해주세요

슬라이드 너무 많아�현기증나요

데이터는 일단 모두 S3 에 적재 (S3 as a Table)

• 포맷은 Parquet (사이즈 작고, 빠름)
• 범용 분석 언어인 SQL 로 모든 데이터 조회
• 쿼리 엔진은 Facebook 이 만든 Presto 이용�강력한 JSON, Aggregation, Geo-spatial 함수 제공
• Batch 는 물론 Stream 데이터도 1분 내 SQL 조회
• SQL 을 지원하는 어떤 툴에서도 쿼리 가능�Zeppelin, Redash, Jupyter (PyHive), Tableau 등�Y 사는 다양성을 존중합니다 취향 또는 용도에 맞추어 사용

​

​

​

​

​

​

Data Infra - 수집 (요약)

데이터 인프라

= 데이터 수집

+= 데이터 처리

+= 데이터 조회

+= 데이터 서비스

데이터 처리는 S3 (원본) + 별도 스토리지 적재

• 요구사항에 따라 저장소 결정 (EC, ES, …)
• 원본은 Presto 에서 조회 가능하도록 S3 적재
• Spark 는 필요시 Yarn Cluster 모드로 사용 모니터링을 위해 약간의 툴링 작업이 필요
• 재작업이 언제나 있으니 Batch Application 유연하게 작성 (환경변수 받아 기간 조절 등)
• 논리적인 데이터 티어 구조를 정의하면 사용 및 관리가 용이해짐 (t1, t2, t3, …)
• Table 이름 규칙도 잡아놓으면 운영이 편리�“lesiure_impression_timeseries_hourly”�“place_summary_aggr_30d_daily”

​

​

​

​

​

Data Infra - 처리 = 원본 적재 후 별도의 가공 단계 (요약)

데이터 티어 구조

Data Infra - Data 티어 구조

데이터는 수집 이후 가공 과정을 거치게 됨. 데이터의 성격에 따라 티어를 나누어 관리

• 수집 티어 t1 (원천 테이블)
• t1_log : 로그성 이벤트 (Client, Server, ..)
• t1_db : 데이터베이스 스냅샷
• t1_meta : ElasticSearch, Redis 등 스냅샷
• 가공 티어 t2 (가공된 공용 테이블)
• t2_customer : 잘게 나누어진 서비스 DB 의 고객 관련된 정보를 모아 가공한 2차 테이블들
• t2_seller (서비스의 테이블 또는 필드가 너무 파편화 되어 있을 경우 분석시에 매우 유용)

(레거시, 인수 합병 등 이유로 너무 많은 서비스 테이블을 조인 할 경우)

• 서비스 티어 t3 (서비스용, 혹은 특수 목적)
• t3_seller_exported_jdbc : JDBC (MySQL 등) 으로 내보내진 서비스용 데이터의 원본 테이블
• t3_customer_exported_dynamo

ya!!! 인수합병 하는 소리좀 안나게 하라!

Application, Table 구조

Data Infra - Table 이름 규칙

도메인과 상관없이 공통으로 적용될 수 있는 Table 구조에 관해 논의 (Batch 기준)

• 데이터의 성격
• (원천) Timeseries : 시계열 데이터 (로그 등)
• (원천) Snapshot : 덤프 데이터 (DB 등)
• (가공 후) Aggregated : 특정 기준으로 Aggregated
• 집계 주기: 일별 (daily) / 시간별 (hourly)
• 타겟 데이터 범위: 최근 30일, 최근 7일 등 (unique count 등 2일 이상 기간 내 고유값 필요 한 경우)

예를 들어, 경쟁업체 관련된 테이블 데이터 생성시

• place_comparative_client_aggr_1d_daily : 경쟁업체 최근 1일치 Client 관련 메트릭을 매일 적재
• place_comparative_db_aggr_30d_daily : 경쟁업체 최근 30일치 DB 관련 메트릭을 매일 적재

원천 테이블을 Aggregated 없이 가공했다면

• leisure_impression_timeseries_hourly : 레저 노출 로그를 시간별로 가공해 적재
• place_order_snapshot_daily : 업체 주문 스냅샷을 일별로 가공해 적재

​

Table 을 만드는 Batch Application 의 구조에 관해 논의

• 재작업은 언제나 있다! (장애 / 운영성 작업 / 신규 컬렉션 생성 = 2015. 01. 01 부터 등)
• 따라서 Application 을 유연하게 만들어 쉽게 대처할 수 있도록 하는것이 필요

​

오늘은 월요일! 주말과 오늘 오전까지 Daily 배치가 장애 😭 (토 / 일 / 월)

• 날짜를 환경변수로 받아 Application 을 3번 실행 (Digdag, Script 등)
• 그런데, 코드가 잘못되어 2월부터 다시 모두 적재해야한다면? 120번+ 실행해야 할까?
• 재적재가 긴급하지 않다면, 현재 EMR 클러스터에서 �Application 내에서 시작점과 이터레이션 횟수를 환경변수로 받아 1번만 실행 (길게)
• 빠르게 복구해야 한다면 별도의 EMR 클러스터를 띄우고 120개 Application 을 병렬로 (빠르게)
• 따라서 두 가지 모두 환경변수로 설정 가능해야 함

PlaceImpression_1Range_20190608_PROD : 업체별 노출수를 20190618 기준으로 1번 적재

PlaceImpression_30Range_20190508_PROD : 업체별 노출수를 20190508 부터 20190606 까지 적재

​

Data Infra - Batch Application 구성 팁

여러 Storage 에 Sink 로 내보내는 경우 부분 실패 또는 부분 적재가 필요할 수 있음

​

가공후 S3 에 원본 + RDS 에 서비스용 적재 경우

• S3 에 성공적으로 적재
• RDS (JDBC) 는 커넥션 등 문제로 실패

​

이 경우 S3 만 읽어서 재적재 가능하도록 구성하면

• 별도의 컴퓨팅 필요 없이 빠르게 복구
• 샘플링 해 Dev RDS 에 넣을 수 있음�(e.g 통계 등 Dev 환경 데이터가 무의미한 경우

​

Data Infra - Batch Application 구성 팁 (2)

EMR 운영 관련 팁

“EMR 사용하시는 분!”

• Apache Spark
• Yarn Cluster Mode

Batch / Stream / Presto 용 EMR 클러스터를 구분해 운영

• Batch 의 경우 운영성 작업은 기존 컬렉션에 �영향을 주지 않도록 필요시 별도 EMR 생성�(장애 복구, N 개월 등 장기간의 신규 컬렉션 생성)

​

• Stream 은 용도에 따라서 EMR 클러스터 분리�(Flink, Spark, …)

​

• Presto 는 DaaS / EDA 클러스터 분리
• DaaS: Data as a Service, 서비스용 (머신이 소비)�배치 등 주로 새벽시간에 사용률 높음
• EDA: Exploratory data analysis, 탐색용 (사람이 소비)�리포트용 배치 / Ad-hoc 쿼리 등 업무시간에 사용률 높음

​

DaaS / EDA 는 사용률 높은 시간에 Task 인스턴스를 Spot 다량 추가

Data Infra - EMR 클러스터 운영 (Example)

• 컴퓨팅 속도 차이가 안나게 모두 같은 인스턴스 타입으로, Disk 는 넉넉히 (EBS는 사이즈에 따라 IO 차이)
• 비용 절감을 위해 Master / Core 는 On-demand, Task 는 Spot 으로 �(Yarn Cluster 모드에서는 Application Master 이 Core 에서 동작하므로 Core 는 on-demand)

Data Infra - EMR 클러스터 운영 (Example)

• Batch 용도 일 경우 Static Group 을 두어 Batch Job 이 많은 시점 (새벽 등) 에 노드 증가 스케쥴링
• Static Group 은 A/B 를 두어 번갈아면서 증/감 (A: 0->5, B: 10->0)�Group 을 하나만 사용시 (e.g A 그룹만 사용시, 작업 많은 새벽시간에 10, 이후 5) �오래된 인스턴스부터 종료되지 않기 때문에 (어떤 5 개가 종료될지 모름) 추후 강제 Spot 회수 발생�아니면 ASG scale-in protection 을 돌릴 노드를 시간순으로 정렬하고 프로텍션 걸고 나중에 풀고
• Batch 용도 일 경우 Dynamic Group 을 두어 장애 복구등 운영성 작업 필요시 해당 그룹 노드 수동 증가

Data Infra - EMR 클러스터 운영 (Sample)

Data Infra - Spark (Yarn) Client / Cluster 모드

Driver (main) 이 Client 에서 실행

• Client 리소스를 사용 (작업이 많으면? 문제)
• 로그가 Client 에 남아 디버깅 편리

​

Driver (main) 이 Cluster 에서 실행

• Yarn Cluster 리소스를 사용
• 로그가 Client 에 남지 않아 디버깅 불편

​

Data Infra - Spark Client / Cluster 모드

일반적인 방법 이외에도 AWS 에서는 EMR Job 을�Yarn Cluster 모드로 Submit 위해 Step API 제공

• IAM Permission 만 있으면 어디서나 Submit

​

waitAppCompletion 값이 참일경우 다음 Step 실행 X

• spark.yarn.submit.waitAppCompletion: "false"�(Spark 일 경우)

• EMR Master UI (YARN RM) 를 들어갈 수 없는 경우 (외부, VPN 등) 위해 �별도의 모니터링 스크립트 작성해 놓으면 운영이 편함 (Yarn REST 후 JQ 파싱)�EMR 모니터링 페이지 VPN 에서 열어주세요��“./yarn-app.sh APP=SparkDaily* STATUS=FAILED FROM=2019-06-08T09:30:00”

​

• 완료는 Digdag S3_wait 으로 처리

​

• 실패는 Digdag SLA + Spark App 내 Driver Exception Handler 에서 Slack으로

Data Infra - Spark Yarn Cluster 모드 모니터링

Data Infra - Spark Yarn Cluster 모드 모니터링 (스크린샷)

Digdag SLA 알림

Spark Driver 실패 알림

파이프라인 스케쥴링 팁

배치 스케쥴링: 배치는 스케쥴링 / 재작업을 항상 염두에 두어야 함

특정 시점에 작업을 시작 / 실패시 재시도 / 작업간 의존성 관리 등

Workflow Orchestration 도구 필요

​

• Digdag (유사 제품으로 Apache Airflow) �Jenkins 는 Workflow 를 다룰 수 있지만 특화된 도구는 아니에요.
• YAML 로 DAG (directed acyclic graph) 관리
• S3 Wait Plugin (S3 에 특정 파일이 만들어질 때 까지 대기)�(Spark 의 경우 _success 파일 등)
• SLA (지정된 시간 이내에 작업 미완료시 에러)
• Slack, Email 등 Notification 연동 (Success, Failure, …)

​

​

​

Data Infra - Batch 레이어 스케쥴링

Data Infra - Digdag

• 작업간 의존성 (순차 실행)
• 병렬 실행 후 전체 작업 끝날때까지 대기
• 실패시 재시도 (Attempt)

​

기타 기능 들

• ruby, python 등 스크립트 실행 지원
• s3_wait 등 각종 플러그인

​

​

Data Infra - Digdag Dag File Example

다른 Dag 을 호출하거나�설정 파일 Include 가능

​

Loop 를 지원

: 3월 1일부터 31일 데이터 복구

​

If 문 등 기초적 문법 지원

​

Data Infra - Digdag File Structure Example

일별 / 시간별 배치 스크립트와 운영용 스크립트 별도 관리

Stream Application

“EMR 사용하시는 분!”

• Spark / Flink Streaming
• Stateful Streaming

Streaming 프레임워크는 Application State 를 지원

• Flink Streaming State, Spark Streaming State
• State 들은 S3, EFS 등 저장소에 백업되고�장애 등 문제 발생시 복구 될 수 있음 (Checkpoint)
• Flink 는 외부에서 조회 (Query) 가능한 State 지원
• 프레임워크 수준에 따라서 State 지원이 비성숙할 수 있음 (Spark Streaming)
• 프레임워크에 따라 커넥터 (Kinesis 등) 공식 지원이 없을 수 있음 (Spark Structured Streaming)

Data Infra - Stream State

​

​

State 를 유지하는 이유는 결국 최종 Output 을 위함�(e.g. 업체별 광고 클릭수를 DynamoDB 에 저장)

​

따라서 Application 내 State 를 유연하게 가져갈 필요

• 재작업시 Kinesis 에서 14:00:00 KST 부터 소비�(Window 가 없다고 가정)
• State 는 리셋 후 다시 14:00:00 부터 집계
• 최종 Output 도 14:00:00 부터 리셋 (값이 작아짐)
• 서빙 레이어가 API 라면 복구까지 캐싱된 결과를 서빙

​

Application State 를 복구의 기준으로 삼으면

• 항상 실패한 시점을 찾고 (14:35:17.401 KST)�그 시점부터 복구해야만 함
• Application State 를 Source of Truth 로 다루면,
• Application State 가 깨지면?
• Application State 모델 변경이 일어나면?
• Application State 디버깅은? (현재 값 확인)

​

​

​

Data Infra - Stream State (2)

​

엔지니어가 아닌 분들의�표정이 좋지 않아졌어요. 😨

• 궁금한 이야기 Y - 그들은 무슨 데이터를 다루나?
• 클라우드 (AWS) 위에서 데이터 파이프라인 구축하기
• 오픈소스를 이용해 사용자 (수백명+) 데이터 활용 돕기
• Kubernetes 위에서 개인별 분석환경 제공하기

Contents

bit.ly/2Kfgt1y

데이터 인프라

= 데이터 수집

+= 데이터 처리

+= 데이터 조회

+= 데이터 서비스

사용자나 업무에 따라 데이터 관련 지식과 사용 도구가 다를 수 있음

• Spark 로 통계 데이터를 적재하는 엔지니어 라고 쓰고 노예라고 읽
• R 이나 Python 으로 다음달 예약 고객을 예측하는 분석가
• SQL 로 푸시 타게팅 사용자를 뽑아내는 마케터
• Excel 에 익숙한 영업 조직
• 버튼을 눌러 기간별로 정산 데이터를 뽑아내는 운영자
• 버튼을 누르지 않아도 리포트 형태로 보고서를 받는 Top Team � 일급 시민
• 플랫폼의 공급자 쪽에 위치한 Seller (업주, 판매자)�판매 분석, 광고 성과 등

​

​

데이터 세계에서의 시민들

생산 고통

소비 고통

아프니까 데이터다

데이터를 조회할 수 있는 툴과 언어는 너무 많다!

• Zeppelin, Redash, Tableau, Jupyter, ...Excel?

​

사용자에 따라 데이터 관련 지식의 수준이 천차만별

• Spark 로 통계 데이터를 적재하는 엔지니어
• R 이나 Python 으로 다음달 예약 고객을 예측하는 분석가
• SQL 로 푸시 타게팅 사용자를 뽑아내는 마케터
• Excel 에 익숙한 영업 조직
• 버튼을 눌러 기간별로 정산 데이터를 뽑아내는 운영자
• 리포트 형태로 보고서를 받는 Top Team

​

모든 조건을 만족시키는 단 하나의 툴은 존재하지 않음

• 다양한 도구를 제공하되 조회를 위한 범용 언어를 선택
• 데이터 세계에서 SQL (= 지구촌 공용어 영어)
• 지속적인 사내 가이드가 필요 “이 데이터는 여기 있어요", “쿼리 샘플" 등등
• 데이터는 이미 S3 에 적재되어 있으니 EMR Presto 를 이용해 컴퓨팅

​

Data Infra - 데이터 조회 (SQL)

“사내 구성원이 1000명이면�엑셀 (구글 시트) 사용자는 �몇 명이나 될 까요?”

틀리면 3일간 펭귄 프사로 살아야 합니다

비즈니스 직군 (영업, 마케팅 등) 은 Excel 이 더 익숙하신 분들이 많음

• 따라서 공유해서 사용하는 업무용 Google Sheet (Excel) 을 테이블로 입수
• URL, Sheet 이름, 저장할 테이블 이름, 언제 가져올지 (시간별, 오전 9시 등)
• 업무용 Excel 데이터와 사내 데이터를 Join (합쳐서) 해 볼 수 있음

​

비즈니스 쪽 추가적인 요구사항들

- 호텔 하드블럭이 저녁까지 안 팔리면 알람을 받고 싶어요

- 강원 지역에서의 지역별 쿠폰이 다 소진되면 � 추가적으로 쿠폰을 발행하기 위해 알람을 받고 싶어요

- DAU, 동접 수 등을 그래프로 슬랙에서 보고 싶어요

​

엔지니어 입장에서는 비용이 크지 않으나, �비즈니스적으로 큰 가치를 가질 수도 있는 일들

(Query 결과가 특정 값이면 Slack, Email 로 Alert 보내기)

​

데이터를 더 널리 전파하기, SQL 로 보는것을 넘어

왜 프레스토 합니까 사용 당신은? 항상 감사하십시오 AWS 에게

• Facebook 제작, Uber, Twitter, Alibaba, Netflix 등 Production 사용
• EMR 에서 지원 (별도의 설치 필요 X), Audit 플러그인 존재
• 빠름 빠름 빠름 (Hive vs Presto, Parquet Predicate Pushdown)
• 다양한 커넥터 지원 (JDBC, ES, Redis, Cassandra, HBase, Mongo 등)
• 강력한 쿼리 파워 JSON, Geospatial, Aggregation 함수
• HTTP 프로토콜 지원 (Node.js, ...)
• UI 제공 (Kill Query, Cluster Status 등)

​

읽을거리

• Presto Summit 2019 Slides
• Presto Summit 2018 Slides

Data Infra - 데이터 조회 (Presto)

Redash, Zeppelin, Jupyter, Tableau 를 주된 탐색 도구로 이용

• Zeppelin (EMR Zeppelin 이 아니라 별도 운영)
• 빠른 탐색 및 차팅 (Charting) 용도
• 수만개 이상의 Rows Visualization 또는 대용량 다운로드엔 부적합
• 보안 이슈로 인해 SQL (Presto) 인터프리터만 제공
• Redash:
• 대시보드 및 시뮬레이션 (인기상품, 기간 또는 가중치 변경 등 쿼리 파라미터 지원)
• 대용량 CSV 다운로드 지원 (수십, 수백만 Rows 이상)
• Alert (특정 조건 하에 Slack 등으로 Noti)
• 각종 커넥터 지원 (Presto, JDBC, Mongo, ES, Redis, Dynamo, Druid, BigQuery, …)
• Jupyter (EMR Jupyter 가 아니라 별도 운영)
• 개인별 분석 환경 (3 CPU, 6 GiB 컨테이너) on AWS EKS
• Python, R, Julia, Tensorflow, PySpark, Scala (Almond) 등 이미지 제공 (jupyter/docker-stack)
• 추후 Spark on Kubernetes 를 통해 Cluster 컴퓨팅 지원 계획
• Tableau: 전사 공용 지표, 영업 관련 데이터 등 (데이터 분석팀이 별도 운영)

Data Infra - 데이터 조회 (탐색 도구들)

Re:dash

이것만 알아 가도�오늘 본전은 (5000원)�뽑았�이미 햄버거를 먹었..

​

Redash:

• 오픈소스, AirBNB 의 SuperSet 과 비슷한 범용 대시보드
• 대시보드 및 시뮬레이션 (인기상품, 기간 또는 가중치 변경 등 쿼리 파라미터 지원)
• 대용량 CSV 다운로드 지원 (수십, 수백만 Rows+)
• 스케쥴링 지원 (매일, 특정 시간 등)
• Alert (특정 조건 하에 Slack 등으로 Noti)
• 각종 커넥터 지원 (Presto, JDBC, Mongo, ES, Redis, Dynamo, Druid, BigQuery, …)

​

사용 용도

• 데이터 프로덕트 Prototype (HTML 이미지 렌더링 가능)
• 간단한 마케팅 운영 툴
• 내부 시스템 로그 조회용 (CloudTrail, ELB 등)

Data Infra - Re:dash (리대시 활용)

​

Redash 쿼리 파라미터

• 일반 변수, 날짜 (Date Range), 타임스탬프 (Timestamp) 등 타입

Data Infra - Re:dash (쿼리 파라미터)

변수 사용

다양한 변수 타입

​

Redash 쿼리 파라미터

• Dropdown (A, B, C, D 등 선택) 파라미터 가능�(다른 쿼리의 결과로 부터도 Dropdown 생성 가능)
• Date Range (날짜 기간), Date Time Range (초별 기간)

Data Infra - Re:dash (쿼리 파라미터, 2)

Drop Down

Time Range

​

Redash 스케쥴링 및 얼럿

• 특정 주기마다 / 특정 시점마다 (오전 9:00 등) 스케쥴 실행 가능
• Slack, Email, PageDuty 등 Alert 가능 (쿼리 결과를 그래프로 그려서 Alert 을 보내면?)

Data Infra - Re:dash (Scheduling, Alert)

Alert 플러그인 타입들

Data Infra - Re:dash 로 CloudTrail 로그 조회

​

CloudTrail 은 JSON 포맷 (느린) 에 양이 많은 경우가 있음

• Presto 는 JSON 함수가 강력해 활용이 쉬움
• 특정 AWS 계정의 지정된 예외를 찾기 위해 Query Parameter 추가 해 사용 (계정, 예외, 기간)

아래 예제는 A 계정에서 ThrottlingException 이 분당 많이 발생하는 사용자를 찾아내 정렬

​

데이터 결과를 보다 유연한 형태로 제공해 커뮤니케이션 도구로 사용

기획자 / 내부 운영자에게 Table 형태로 숫자만 가져가는 것 보다 이리 저리 돌려볼 수 있는 자유도 제공

• 데이터 프로덕트의 Prototype 및 간단한 마케팅 운영툴 (Schedule, Alert 가능)
• 결과 내에서 다시 재검색 및 Pagination 도 지원 (Result 를 별도 DB 에 저장)

(아래 스크린샷 및 데이터는 모두 Dummy 데이터, 구글 검색 이미지)

Data Infra - Re:dash 로 데이터 프로토타이핑

Data Infra - Re:dash 로 데이터 프로토타이핑 (2)

​

​

Presto 의 geo-spatial 함수를 이용해 보아요�(위도 경도를 이용해 근처 아이템 탐색 등)

데이터 인프라

= 데이터 수집

+= 데이터 처리

+= 데이터 조회

+= 데이터 서비스

개인화 추천

개인화 푸시 (리타게팅)

A/B, MAB 등 실험 플랫폼

가격 조절 (AirBNB 의 Smart Pricing)

공급 조절

기타 데이터로 할 수 있는 모든 것 (B2B, B2C)

Data Infrastructure - 데이터 서비스 (혹은 데이터 프로덕트)

설명이 너무 많아요�다 됐고 그래서�뭘로 인프라 만들었나요?

TMI

Terraform - Code as Infrastructure

Terraform

​

Code 로 EC2 (서버) 를 만들고 �필요하다면 추후에 코드를 재활용

AWS (UI Console)

​

버튼을 눌러 EC2 (서버) 를 만들고�필요하다면 추후에 다시 기억을 떠올려..

왜 테라폼으로�데이터 인프라를�이전 했는가?

AWS Account 이전 �요청을 받았습니다�역시 전세는 위험해

AWS API (EC2 리스트 확인 등) 은 대부분 Call Limit (기간당 요청 제한) 이 있음

• AWS Console (Web) 을 여는 것도 AWS Call 수를 소비함
• 회사 내 엔지니어가 많아지면 많아질수록 AWS Call 수가 기하 급수적으로 증가

“ElasticBeanstalk 화면에 아무것도 나오지 않습니다!” “배포가 안되요!”

• CloudFormation, Terraform 등 자동화, IaC 등이 늘어나면서 또 증가
• Call Limit 은 요청해도 잘 안늘려준다고 함 (분당 ThrottlingException 등 사용자가 직접 증빙 준비)�

일반적으로는 Dev, Prod, Data 등 용도에 따라서 Account 를 분리

• VPC 는 Peering 해 서로 다른 Account 간 Private 네트워크 간 연결 SE 분들 감사합니다!
• IAM 기반의 Access Control 리소스는 다른 Account 간 접근 위해�Assume Role 등 이용 (Dynamo, Kinesis, …)
• 다만 특정 라이브러리 / 프레임워크의 경우 Assume Role 지원이 없을 수 있음�AWS Account 옮기기 전에 미리 확인 필요 😭

Terraforming Data Infra - AWS Call Limit ✈️

따라서 입주민들이 �많아지면 많아질수록 �AWS Call Limit 이 자주 발생�민원이 들어옵니다

그리고 일반적으로�Data 팀은 Service 팀에 비해 �다양한 AWS 리소스�더 많은 IAM 권한을 사용�나 빼고 모두 로그아웃 해주세요�혼자있고 싶으니까

그러므로 데이터 팀은�별도의 AWS Account 를 �사용하는편이 정신건강에 좋음�AdministratorAccess 가 �가지고 싶었어요

Terraforming Data Infra - 여러개의 AWS 계정 사용 ✈️

AWS IAM 의 Assume Role

• 다른 Account 의 Role 을 가장해 (Assume)�현재 Account 에서 다른 Account 의 리소스 사용

​

데이터 팀은 다수의 Account 를 다뤄야 하기 때문에�Assume Role 에 익숙해 질 것! 하지만 같은 실수를 매번 반복하지

​

​

​

우측 그림은 Data 계정의 Terraform 커맨드 서버에서

다른 Account 로 assume role 이용해,

각 계정의 Role (P, D, X 등) 의 권한으로

해당 계정의 리소스를 다루는 경우를 설명

근데 왜 테라폼으로�데이터 인프라를�이전 했습니까?

관리되지 않는 �기존 인프라 히스토리

기존 데이터 인프라 구성: 손으로 버튼 눌러서 만듦

• 내 인생처럼 꼬여있는 Security Group
• 무엇이 무엇을 호출하는지 알 수 없다!
• 그때 그때 추가하다보니 파악 불가능. 제거는 더 불가능 😧
• 결국은 0.0.0.0/0 으로 Allow, 그러나 같은 VPC 내부라도 모르는 접근은 제어가 필요!
• 모든걸 허용하는 자비로운 IAM Permission (이름이 보통 All 이나 Full 로 끝남)
• 커스텀 설정이 난해
• 가끔 UI 에서 제공하지 않는 중요한 옵션들이 있음 (영원히 있는 줄 모르는 옵션들)
• bootstrap action 등 추가 설정에 대한 관리가 어려움
• 가끔 보이는 개방적인 인스턴스 친구들 (Public Subnet)
• 다시 만들려면 UI 눌렀던 버튼과 선택했던 옵션들이 기억나지 않음�판사님 저는 어제 먹은 점심도 기억이 나지 않습니다

​

Terraforming Data Infra - 테라폼을 사용하지 않을 때

장점은 일단 귀찮음 테라폼은 지정된 옵션을 넣지 않으면 적용이 불가

• Terraform Resource 적용을 위해 거의 대부분의 옵션을 이해하고 사용하게 됨 그리고 다시 까먹
• UI 에서 제공하지 않는 (보이지 않는) 옵션들 세팅 가능
• Bootstrap Action 등 커스텀 설정 관리 / 재사용 용이
• Security Group, IAM 최적화 및 히스토리 관리 (Commit, Comment 등)
• “terraform apply” 커맨드는 앞으로 무슨 변경재앙이 일어날지 미리 알려줌

Terraforming Data Infra - 테라폼을 사용할 때

Terraforming Data Infra - Terraform 관련 팁들

1. 모든걸 Terraform 으로 관리하려 하지 말 것

팀 내에는 Terraform 을 모르는 사람도 충분히 있을 수 있음

ASG 처럼 운영성으로 UI 에서 값을 변경하는경우가 존재. 이런 값들은 ignored_changes 에 등록

​

2) 다만 Security Group, IAM 은 Rule 과 Policy 등 디테일하게 Terraform 으로 관리할 것

이름 규칙과 Description (주석) 을 한 곳에서 관리해야 통일성 및 히스토리 파악 용이

​

3) Community 모듈의 경우 변화가 생길 수 있으니 VPC 나 EKS 등 복잡하고, � 크리티컬한 모듈은 Clone 해 사용

​

4) IAM 은 추후 권한을 회수 당하거나 할 수 있으니 별도의 프로젝트로 분리 제발 이 권한만은 흑흑

​

5) EMR 의 경우 Step (Job) 이 많아지면서 나중에 기하급수적으로 plan 이 느려짐 � 같은 모듈이나 프로젝트에 영향을 주므로, 별도의 프로젝트로 분리 후 필요한 리소스만 apply� “tf apply -target module.module-emr_PROD.aws_emr_cluster...”

​

6) 큰 하나의 프로젝트보다는, 작게 쪼개진 프로젝트가 운영이 편함. 상호 참조는 remote state 로

​

​

​

​

​

AWS EC2 인스턴스에는 Bootstrap Action 이라는 기능이 존재

• 인스턴스 생성시 사용자 지정 스크립트 등을 실행이 가능 (EC2, EB, EKS, EMR, ECS 등)

따라서 Bootstrap Action 을 Script 로 만들어 놓으면 아래 처럼 활용 가능 (이후에는 Terraform 에서 재활용)

• AWS 는 Memory, Disk 모니터링을 Cloudwatch 에서 제공하지 않으므로�Bootstrap Action 내에서 aws-mon-script 를 설치하고 crontab 에 등록해 �Memory, Disk 등 Cloudwatch Custom Metric 전송 (EMR Master 등 중요한 인스턴스엔 필수로)

​

• Standalone 으로 쓰는 인스턴스의 (Bastion, Zeppelin 등) 경우에는 백업 후 설정이 항상 귀찮음�/data 에 별도 EBS 를 attach 하고 bootstrap action 내에서 fstab 에 추가 (파일시스템 마운트)�이후 지정된 서비스용 linux 계정 추가 (service, zeppelin 등) 를 하면 �머신이 변경되어도 (동일 타입) 같은 디렉토리 (/data) 같은 계정으로 같은 파일들을 사용할 수 있음�(해당 EBS 는 DLM 으로 쉽게 백업)

​

• EMR Master, Bastion 등 고정 IP 필요한 경우는 Secondary IP 등 할당 해 운영 편하게 (X.X.X.10)

특정 대역 (X.X.X.10 ~ 19) 을 예약 하기 위해 (선점 방지) ENI 를 미리 만들어 둘 수 있음

�

Terraforming Data Infra - Terraform 관련 팁들 (2)

데이터 팀 특성상 다양한 (관리형) 스토리지 를 사용하게 됨

AWS 는 관리형 스토리지에 대해서 다양한 Cloudwatch Metric 을 제공

• RDS 라면 Connection 수나 남은 Memory, Disk 등. (Aurora 는 DeadLock 도)
• ElasticSearch, ElastiCache, Kinesis, ...

​

따라서 중요한 메트릭은 미리 Cloudwatch Alert 걸어 놓을 것.

​

Cloudwatch 의 Metric 들을 (Custom 포함, 이전 슬라이드의 EC2 Disk, Memory 등)

은 aws-to-slack 같은 terraform 모듈 이용하면 쉽게 Slack 으로 전송 (Cloudwatch - > SNS -> Lambda)

​

Terraforming Data Infra - Terraform 관련 팁들 (3) ✈️

Kinesis 메트릭

Custom 메트릭 (EMR Master Memory)

Terraforming Data Infra - 프로젝트 구조

프로젝트는 잘게 썰어서 구성

DB 등 별도의 Account 는 다른 프로젝트로

파일 이름은 IDEA 에서�검색이 쉽도록�prefix / postfix 붙여서 생성�

• 궁금한 이야기 Y - 그들은 무슨 데이터를 다루나?
• 클라우드 (AWS) 위에서 데이터 파이프라인 구축하기
• 오픈소스를 이용해 사용자 (수백명+) 데이터 활용 돕기
• Kubernetes 위에서 개인별 분석환경 제공하기

Contents

bit.ly/2Kfgt1y

기존 데이터 조회 시스템으로는 해결이 어려운 문제들

• Python 등 스크립팅 언어 분석 환경 제공 (R, Julia, Scala)
• 고오급 분석 라이브러리 (xgboost, Prophet, …)
• 커스텀 차트 (Plotly, …)
• API Call (Python HTTP Request)�베이지안 기반의 A/B 테스팅 결과 API Server 호출 등

​

• Zeppelin (EMR Zeppelin 아니고 별도 운영)
• 보안 이슈로 인해 SQL 인터프리터만 제공 (Presto)�Shell, Python 등을 열 경우 EC2 에 접근 가능�해당 EC2 의 Role 이용 / Meta API 로 키 획득 (치명적)
• Zeppelin on Kubernetes 는 0.9 부터 이용 가능
• 현재는 scale-out 이 어려움 😕 (잦은 리스타트😭 )

​

​

​

Jupyter on Kubernetes - 데이터 조회 시스템

Jupyter?

Jupyter on Kubernetes - Jupyter

Jupyter 는 데이터 분석에 널리 사용되는 도구 업계 표준. 하지만 Google Colab 이 나와버렸어요

• Python, R, Julia, Scala 등 커널 지원

​

​

Netflix 에서는 Jupyter 를 위한 Scheduling 등 인프라 제공 (Notebook Innovation at Netflix)

빨간 점선 박스는 Netflix 가 Jupyter Notebook 인프라를 위해 만든 별도 오픈소스들

​

​

​

Notebook Infrastructure - Jupyter @ netflix

“Kubernetes 를 들어보신분!”

• Container / Pod
• Node
• Helm Chart
• Volume

Jupyter on Kubernetes - Jupyter vs Jupyter Hub

​

본래 Jupyter 는 개인 노트북에서 실행되는 개인별 노트북

JupyterHub 는 다수의 사용자에게 Jupyter 할당 할 수 있도록 만들어짐

• Google Auth, LDAP 등 인증 및 사용자 관리
• Cluster 리소스를 나누어 사용
• 접속한지 오래된 노트북은 자동으로 Shutdown (Culling)

​

Q. JupyterHub 를 어떻게 Kubernetes 에 설치합니까?

Kubernetes (AWS EKS) 위에 쉽게 JupyterHub 설치 가능: Jupyter Zero to Kubernetes

설치는 방법은 문서에 잘 나와있으니 설치보다는 고통받았던 내용이나 팁들에 관해서 설명 😎

​

여러종류의 컨테이너를 사용자에게 제공 할 수 있음

• jupyter/docker-stack (Python, Tensorflow, R, Julia, Scala, …)
• 필요시 docker 이미지 상속받아 원하는 이미지 제공 가능
• ECR 에 푸시하면 별도 docker-secret 만들 필요 없이�권한 있는 EKS 에서 바로 이미지 Fetch 가능

Jupyter on Kubernetes - Zero to Kubernetes

Jupyter on Kubernetes - 다양한 컨테이너 제공

사용자가 매번 시작시 �필요한 컨테이너 골라서 사용 가능

​

conda 환경 및 커널 EBS 에 저장 가능�다음에도 같은 conda 환경 이용 (= pyenv)

​

jupyter/docker-stack 의 �기본 컨테이너만 8 가지

�필요하면 추가로 빌드해서�이미지 제공가능 (tensorflow-gpu 등)

​

​

​

​

​

​

​

​

​

​

​

Kubernetes 기본 기능 중 Pod 별로 Resource (CPU, Memory, GPU) 를 조절 할 수 있음

​

​

​

​

​

​

​

GPU는 'extra_resource_guarantees': {"nvidia.com/gpu": "2"}’ 처럼 세팅 가능

​

​

​

​

​

​

Jupyter on Kubernetes - Resource 관리

컨테이너마다 guarantee 할 리소스가 부족하면 당연하게도 컨테이너가 생성되지 않음

• 리소스가 부족하다는 알람을 받고 / 수동으로 EKS 노드를 늘리기 번잡하므로
• Kubernetes Cluster Autoscaler 기능을 이용
• AWS ASG 기능을 이용하기 위해 IAM 퍼미션 필요

​

Jupyter 컨테이너 생성시 리소스가 부족하면 �지정된 한도 (max) 내에서 알아서 Node 를 추가

추가되는 동안 Jupyter 는 Pending

Node 가 추가되면 자동으로 Jupyter 생성

일정 시간후 사용률이 떨어지면 늘어난 노드 제거

​

​

​

​

​

​

​

​

​

Jupyter on Kubernetes - Cluster Autoscaler

Jupyter on Kubernetes - EKS 노드 그룹 관리

Kubernetes Node Selector 를 이용해 Pod (컨테이너) 를 지정된 Node 그룹에 할당 가능

EKS (Kubernetes) 는 Node 를 그룹지어 Pod (컨테이너) 를 할당 할 수 있음

• Hub, Proxy 등 Jupyter 용 System pod 들은 t3.medium (저렴한) on-demand instance
• Jupyter pod 들은 c5.2xlarge 등 리소스 큰 컴퓨팅 용 머신으로 spot instance (스케쥴링 없다 가정)

(JupyterLab System Pods) t3.small * 720 (1달) = 약 $19

(Computing Pods = Jupyter) c5.2xlarge * 720 * 2대 * 0.3 (spot) = 약 $166 (16 CPU, 32 GiB)

(EKS 고정비용) 0.2 * 720 = 약 144$

만약 Computing 노드를 일 10시간씩 평일 5일만 쓰고, 나머지 시간엔 ASG desired = 0 처리하면�(max = N 으로 두어 여전히 요청시 사용 가능하게, Cluster Autoscaler)

(Computing) c5.2xlarge * 200 * 2대 * 0.3 (spot) = 약 $46

c5.18xlarge * 200 * 1대 * 0.3 (spot) = 약 $208 (72 CPU, 144 GiB)

$208 + $19 + $144 + (EBS + EFS 비용 약간) = 월 $400 로 72 Core 144 GiB Jupyter 시스템제공

월 $600 이면 144 Core, 288 GiB 😎

Jupyter on Kubernetes - EKS 노드 그룹 관리 (2)

Jupyter 노트북 결과 파일 (.ipynb 확장자) 를 HTML 로 렌더링 해 공유할 수 있음 (e.g. Github)

오픈 소스 프로젝트로 NbViewer 가 존재 �누가 이것도 Audit / ACL / 검색 있는 버전으로 오픈소스 내면 대박날거에요

​

​

Jupyter on Kubernetes - 노트북 공유 NBViewer

Jupyter on Kubernetes - 노트북 공유 NBViewer 설치

여러개의 Jupyter 컨테이너에서 작성한 ipynb 파일을 NbViewer 컨테이너에서 바로 렌더링 하려면?�다운받고 업로드하고 하면 또 한 세월이니

우선 여러개의 Jupyter 컨테이너에서 작성한 파일을 즉시 NbViewer 컨테이너에서 읽을 수 있어야

1) Kubernetes Node 디스크를 Jupyter 컨테이너와 NbViewer 컨테이너에 마운트� Node (Host) 디스크를 마운트 한다는 순간부터 정상적인 방법은 아닌것 같다. 디스크 풀 나면?

2) S3 를 Disk 처럼 Mount 해서 쓸 수 있는 방법을 찾아본다 S3-fuse? � 더 쉬운 방법이 있을 거 같아 AWS 에 돈 만내면 말입니다

3) Jupyter 컨테이너와 NbViewer 컨테이너에 NFS (공유 파일 시스템을) 마운트

AWS 에는 EFS 라는 NFS 서비스가 존재

• Zero to Kubernetes EFS 세팅하기
• Kubernetes EFS 세팅하기

​

PVC Storage Class 를 “” 로 세팅 후, PV 를 직접 EFS 로 생성 (efs-provisioner 사용 X)

NBViewer k8s deployment manifest 에서는 “claimName: efs-jupyter-shared”

Jupyter on Kubernetes - EFS (Example)

Jupyter Container (singleuser) EFS 설정 NBViewer Deployment 용 EFS PV

Jupyter on Kubernetes - Meta API 🙈

사용자에게 Web Shell 류 (Shell, Python, Scala 등) 를 그냥 열어주면 안되는 이유�누가 열어둔 EC2, EMR Jupyter 나 Zeppelin 가 있다면 몰래 들어가서 한번 해보세요. �비트코인 채굴하는 소리가 나요

EC2 에는 Meta API 를 통해서 인스턴스 정보를 얻어올 수 있음. (권한 있으면 AWS Key 도 조회 가능)

따라서 Jupyter 컨테이너에서는 Meta API 접근을 Disable 해야 함

• 따라서 Jupyter 컨테이너는 모든 사용자가 루트가 아니라 jovyan 이라는 가상의 사용자 (uid 1000)
• root 권한 줄경우 iptable 등 조절해 meta API 접근 가능
• AWS ECS 등 컨테이너 서비스를 사용자에게 제공해 줄 경우 절대로 root 사용자로 제공해서는 안됨

​

​

​

​

​

다만 이 경우 Meta API 접근이 불가능하므로, EKS Node 에 있는 기본 IAM Role 도 사용할 수 없음�만약 Jupyter 에 별도의 권한을 주고 싶다면 (공용 S3 접근 등) kiam 등 이용해 Pod 별로 IAM 권한 설정

​

​

Jupyter on Kubernetes - Meta API :(

Jupyter Hub 를 위한 EKS 팁들

• JupyterHub 를 위한 별도의 EKS Cluster 를 만드는게 마음이 편리

기존 EKS 에 namespace 받아 쓰려면 kiam 등 세팅이 복잡

차라리 JupyterHub config 에서 Jupyter Container 의 Meta API 접근 끄고 별도의 EKS 사용

Kubernetes 클러스터 만드는게 부담스럽지 않은 시대에 13만원 아끼려고 고생을 할 필요는 없지 않을까� 환율이 좀 올랐던데

• EBS 백업은 (메인 스토리지) AWS DLM 기능을 이용하면 편리!
• EBS 가 가진 태그 이름만 부여하면, 특정 주기마다 백업 및 오래된 백업본은 삭제

Jupyter on Kubernetes - Zero to Kubernetes

사용자별로 격리된 분석 환경 제공 (개별 컨테이너)

다양한 언어 및 환경 제공 (Python, Tensorflow, Scala Almond, R, Julia, …)

운영 코스트가 거의 없음 ya!! 신난다!

• EKS 마스터는 AWS 가 관리
• EKS 노드는 죽으면 ASG 로 부활 (장애나 Spot 회수 당했을 경우 등)
• EKS 노드가 (리소스) 부족하면 Cluster AutoScaler 가 늘림, 시간이 지나면 사용량 보고 다시 제거
• JupyterHub 시스템 컨테이너 죽으면 Kubernetes 가 살림
• 업그레이드 시에도 사용자 컨테이너 (Jupyter) 에는 영향 X, Hub 등 시스템 Pod 만 일시 접근 불가
• 사용하지 않은지 오래된 (N 시간 등) Jupyter 컨테이너는 알아서 제거 (JupyterLab Culling)
• 모니터링은 Prometheus Operator 깔고 Grafana 로 Metric 보고 Grafana Alert 을 Slack 전송

비용이 저렴

• Jupyter 컨테이너는 EKS Spot 노드에만 할당 가능 (noteSelector)
• Spot 이용시 약 월 $400 로 주 5일 (업무시간 10시간) / 72 Core 144 GiB 클러스터 사용 가능
• 야근 / 주말 시간동안은 min = 0, desired = 0 후 max 값만 지정해 요청시 서비스 제공 가능하게만

각 사용자가 작성한 노트북을 즉시, 쉽게 공유 가능 (NbViewer + EFS)

Jupyter on Kubernetes - 요약

머신러닝 인프라 일단 머신러닝 엔지니어를 뽑읍시다

• Kubeflow 는 Audit / ACL 등 관리 기능이 없고, �Jupyter 에서 바로 kubectl 커맨드가 가능해 현재는 인프라 서비스로 제공이 어려워 보여요
• BigQuery ML, AutoML Table 등 GCP 이용 위해 어떻게 데이터를 S3 -> GCP 로 쉽고 싸게 이동할지
• GPU 머신을 싸게 사용하는 법 Google Colab GPU 를 후킹

클러스터 컴퓨팅

• 현재 클러스터 컴퓨팅은 Presto 만 지원 (Spark 수준의 Aggr 은 일반적으로 Presto 에서 모두 가능)
• Presto 로 컴퓨팅 후 Jupyter 에서 Dataframe 으로 받아 (Spark, Pandas) 2차 가공하는 형태
• 따라서 Jupyter 에서 바로 대규모 컴퓨팅을 어떻게? Spark on Kubernetes? ML 은? 응?

(임의의 사용자의 Cluster 접근을 안전하게 제어할 수 있는 방법이 필요)

노트북 스케쥴링 인프라

• Jupyter 에서 분석뿐만 아니라 결과물을 다시 서비스에 내보내려면 Parameter / Scheduling 필요
• netflix 의 nteract/paparmill, nteract/bootstore 등이 있으나 다 Jupyter (Lab 이 아닌) 위주

노트북 공유 시스템

• fine-grained Audit / ACL / Search 가 제공되는 Jupyter Notebook 공유 시스템 누가 오픈소스로

Jupyter on Kubernetes - TODO

데이터 엔지니어가 말하는

Data 그리고 AWS

Data 엔지니어의 포지션

• 서비스의 뒷단
• Application (서비스) 엔지니어보다 비교적 다종다양한 시스템들을 다루고
• Application (서비스) 엔지니어가 효율적으로 일할 수 있도록 도움 (가끔 자주 귀찮게 함)

따라서 Data 엔지니어 입장에서, DevOps 엔지니어들의 도구들을 눈여겨 볼 필요가 있음

• Data 엔지니어도 꽤 삶이 편해지는 툴 들이 존재

Terraform, Ansible, Kubernetes, Jenkins, Grafana, Prometheus 등

다만 툴에 너무 의미를 부여하지 말 것!

• Kubernetes 도 그저 도구일 뿐. 가치를 만들어내지 못하면 결국 이쁜 쓰레기�전사 공용 인프라 제공 팀이 아닌 이상 Kops 니 EKS 니 구분은 크게 무의미.

일단 본인은 데이터 팀

• 비용 약간 더 태우고, 운영 리소스 줄여서 그 시간에 다른 일을 🙂

자본주의 사회의 회사에 고용된 엔지니어는 비즈니스 가치 (= 매출에 도움) 를 만들어 내야

Summary - 데이터 엔지니어가 바라보는 Data, AWS

DataOps 가 있다면

• 분석이나 가공 과정에서 데이터가 깨지지 않도록 서비스팀 데이터 변화에 지속적으로 관여�(Client / Server 로그, DB 스키마 등 변화를 자동 감지 / Noti / QA 툴 등 제공)

​

• Application 엔지니어 입장에서 부담 없이 쓸 수 있는 데이터 인프라 제공

​

“DB 테이블 이름만 알려주면 바로 입수 되서 한 시간 뒤 부터 바로 조회할 수 있어요"�“Redash 에서 서비스 DB 부담 없이 바로 1년치 데이터도 빠르게 쿼리할 수 있어요"�“버튼만 누르면 8 GiB Jupyter 컨테이너 즉시 띄워 분석할 수 있어요. GPU 도 원하면 드려요"

​

• Application 엔지니어가 데이터 툴에 익숙해 지게끔 여러 장치들을 만들 것�ELB 로그 확인용 대시보드 (기간과 LB 이름만 고르면 바로 조회되는)

​

• 사내 데이터 활용 교육을 정기적으로 / 꾸준히 할 것 (데이터 소개, Redash 등 툴 활용 가이드)

​

​

Summary - 데이터 엔지니어가 바라보는 데이터, AWS

에이더블유에스는

Summary - 데이터 엔지니어가 바라보는 Devops, AWS

좋은데, 너무 Lock-in 되고 있진 않은지?

• Kinesis, Dynamo 등 AWS 특화 관리형 서비스들..
• 여유가 있다면 플랫폼 중립적인 툴들을 고민하고 도입하겠으나 �매년 회사가 2배씩 커져가고 비즈니스 요구사항이 빠르게 변화하는 상황에서는 �속도가 중요하니 비용을 더 태우더라도 운영 리소스를 줄이는 형태로 가는게 맞지 않을까

​

갓 나온 Managed 는 쓰지 않는것이 정신 건강에 좋습니다 하지만 MSK 가 나와버렸어요

• EKS 업그레이드 하다가 (1.11 > 1.12) VPC CNI 플러그인 버그 (1.4) 로 고통받았

가끔 기대하지 못한 곳에서 이상함. Support 를 잘 이용합시다

• EMR 마스터가 터졌는데 (물리 머신 Failure), 왜 그걸 물어봐야만 알려주는 것이죠? 😡�(게다가 비슷한 시각에 만들어진 EMR 마스터 여러개가 왜 같은 물리머신에 할당되는지?)

​

​

​

Default 로 쓰면 가격이 저렴하지 않으나, 궁리하면 저렴하게 쓸 수 있는 방법이 있다! 공밀레

Summary - 데이터 엔지니어가 바라보는 Devops, AWS

지난번 발표에서 MSK 노래를 불렀더니 (2019-06)

드디어 MSK 가 Seoul Region 에 나왔습니다! 여러분들에게 최신 정보를 드리고자 이 한몸 바쳐

• 2019년 8월 1일 출시

특징

• AZ 3개 필요: a, c 만 있을 경우 b zone 서브넷 생성 필요 (2019. 05 추가)
• 비용은 약 2.1 배 응? (m5.large on-demand 기준), ZK 포함
• Disk 는 100 GB 단위로만 증가 가능, 한번 증설시 최소 6시간 대기 필요 �(500 GB -> 600 GB 약 3분 소요)
• MSK Default 설정이 잘 잡혀 있음 (변경 가능한 MSK 설정)�현재는 Custom 설정은 CLI (또는 Terraform) 으로만 생성
• Cloudwatch Metric 은 Cluster / Per Broker / Per Topic 지원�Per Broker, Per Topic 은 유료 (현재는 한 번 설정하면 변경 불가)

하지만 (개선 사항으로 로드맵에는 존재)

• Scale-out 현재 불가 (Broker 수 늘릴 수 없음)
• Scale-up 현재 불가 (Instance Spec 늘릴 수 없음)
• Cluster Version Upgrade 현재 불가

​

Summary - 데이터 엔지니어가 바라보는 Devops, AWS

그들을 모집합니다

갈아만든 공돌이를 모집 읍읍

팀장님! 이 슬라이드는 저희집 고양이가 만들었습니다.�

지원서 링크

지원서 링크

Thanks

Ending Credit

choo.issac @ yanolja.di

eunseons @ yanolja.di

kirk @ yanolja.se

woonjo@ yanolja.se

sh @ yanolja.ba 쉘님