2017 Ad-Tech on AWS 세미나ㅣKinesis Stream 사용기

Kinesis Stream 사용기
알아두면 쓸데있는 신비한 Kinesis Stream
나종협 @ Valuepotion

본 강연에서 다룰 내용
● AS-WAS
● WHY Kinesis Stream?
● AS-IS
● What is BETTER?
● HOW to use?
● Architecture on MULTI-Region
● NOTE that
● Conclusions

AS-WAS
<데이터 수집 플랫폼>
● 발생한 이벤트 데이터를 수집하기 위해서
● SDK 에서 보낸 HTTP Request 를 Web Application 으로 전송
● Web Application 은 전달 받은 데이터를 Fluentd Agent 로 다시 전송
● Fluentd Agent 는 GCP BigQuery 로 데이터를 최종 저장

AS-WAS > 문제는?
● 비용 : (AWS -> GCP) Outbound Traffic Cost
● 구성 : ELB IP 의 동적 변경으로 인한 커넥션 유실, TCP/IP Load Balancer Black Hole
● 실시간 : Real-Time Stream Processing 대응 및 확장성 부족
● 장애 : WebApp 에서 BigQuery 구간 동안 장애 발생 시, 대응 시나리오 부재
<데이터 수집 플랫폼>

WHY Kinesis Stream?
● 완전 관리 서비스
● 탄력적인 트래픽 대응
● 최대 7일 까지의 안전한 데이터 보관
● Real-Time Streaming Processing
( in kinesis documentation )

AS-IS
● Web Application 은 데이터 전송을 `Fluentd` 대신 `Kinesis Stream` 으로 전송
● 데이터 처리를 하기 위해 저장소로 사용하던 `BigQuery` 를 `S3 + Athena` 로 대체
● Real-Time Streaming Processing 을 위해 `Kinesis Consume Application` 연결

What is BETTER?
● 안정적인 데이터 수집
● Failure Point 수 감소 (2 → 1)
● Real-time Streaming Processing 대응 및 확장성 용이
● Outbound Traffic 비용 절감

Kinesis Producer Library (KPL)
HOW to use? - Produce
● https://github.com/awslabs/amazon-kinesis-producer (Java)
● SDK, Agent 보다 KPL 사용 권장
● Retryable
● Asynchronous
● Aggregation & Collection

Kinesis Client Library (KCL)
HOW to use? - Consume
● Java : https://github.com/awslabs/amazon-kinesis-connectors
● Kinesis Stream 에 있는 데이터를 다른 서비스로 보낼때 사용
● S3 Connector 를 Customizing (시간대별 파티셔닝) 하여 사용 중
Kinesis Connector Library
● Java : https://github.com/awslabs/amazon-kinesis-client
● Ruby : https://github.com/awslabs/amazon-kinesis-client-ruby

Architecture on MULTI-Region
SG 에서 단일리전으로
구성
이슈 없이 정상적으로
동작
Simple

KR Traffic 은 Seoul
Region 에서 받고 뒷단에는
동일하게 돌아가야 하는
요구사항 발생
Seoul Region 에 WebApp
을 하나 두고 SG 의
Kinesis 로 데이터
전송하도록 구성
SG WebApp 과 KR Kinesis
간의
Latency 이슈 발생
Latency 로 인하여 서버 성능
저하

Billing 이 바라보는
Elasticache 는 VPC
내부에 있기 때문에 다른
리전에서 접근 불가
따라서 SG 리전에서 KR
Kinesis 를 Consume 하는
Billing App 을 추가로 구성
KR S3 Emitter 는 KR
Kinesis 를 Consume 하되,
동일 버킷에 넣기 위해 SG
S3 에 데이터 저장.
Real-Time App 은
리전별로 저장소를
독립적으로 운영하여도
문제 없음

Episode
Multi-Region 구성 작업 중,
Real-Time, S3 Emitter 는
작업을 완료하였으나,
Billing 작업이 누락
되었었다.
그리하여 KR Kinesis
데이터에 대해 처리가
안되고 있는 장애 발생
다행이 KR Web App 에서
KR Kinesis 로 데이터는 잘
쌓이고 있는 상태
SG Region 에 KR Kinesis
를 바라보는 Billing App 을
급히 구성하여 뒤늦게라도
처리를 할 수 있었다.

Idempotent
NOTE that
● http://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html
● KPL 에서 데이터를 PUT 할 때 retry 로직에 의하여 중복 데이터 발생 가능
● KCL 에서 데이터를 GET 할 때 데이터를 처리하고 checkpointing 하기 전에 재시작 하는 경우
중복 데이터 발생 가능
● Kinesis Stream Shard 수 를 변경 시, KCL 이 중복 데이터 를 GET 가능
● ‘반드시 동일 데이터가 여러개 있을 수 있다는 것을 가정 해야함’

Low-Latency Processing
NOTE that
● http://docs.aws.amazon.com/streams/latest/dev/kinesis-low-latency.html
● 기본적으로 KCA 는 샤드당 1초에 한번씩 Kinesis Stream 으로 부터 데이터를 가져온다.
● 그렇기 때문에 Kinesis Stream 으로 부터 가져온 여러 Record 들을 1초 안에 처리해야 한다.
● 그렇지 않으면, 소비하는 양보다, 생산하는 양이 많아지기 때문에, 데이터가 쌓이게 된다.
● ‘즉, Record 들을 처리하는 KCA 는 Low-Latency Processing 을 보장해야한다.’
● 또한, GetRecords 를 샤드당 1초에 5번 까지만 가능.
○ Polling 주기를 1초로 할 경우 KCA 는 최대 5개까지 연결 가능.
○ Polling 주기를 200ms 로 할 경우 KCA 는 최대 1개까지만 연결 가능.

아쉬운 점
● KPL 의 Ruby 버전 미 지원. 누군가 만들어 줬으면 좋겠다.
● KCL 을 사용하려면 습득해야할 것이 많고, 많고, 많다.
○ 생각보다 적은 국내외 레퍼런스
○ 완전 관리형 서비스라지만...
○ Kinesis Documentation 일독/완독/정독 권장
● Shard Auto Scaling 지원 필요
● Kinesis Connector Library > S3 Connector Bug
○ 버퍼 기간 동안 데이터 인입이 중단되면 flush 해주지 않는다.
○ 주기적으로 PING 데이터를 넣어줘야한다.

Kinesis Stream 덕분에
대량의 데이터를
짧은 시간 안에 적은 비용으로
안정적으로 수집
신속하게 처리할 수 있었습니다
Conclusion

Beanstalk + Spotinst
Saving your cost up to 80%
나종협 @ Valuepotion

우리는 Beanstalk 를 너무 좋아합니다.
● 거의 대부분의 Application 을 Beanstalk 로 운영.
● 만약 Beanstalk 를 사용하지 않는다면, EC2, ELB, ASG, Nginx,
Tomcat, Deploy 등등등등 직접 설치/운영 필요.
● Beanstalk 는 대부분 알아서 해준다. 코드에만 집중 가능.
● 왜냐하면? 우리는 적은 인원으로 짧은 시간동안 많은걸 해야하는?
하고싶은? 스타트업.

Spot Instance 는 너무 매력적입니다.
● On-Demand Instance 와 비교하여 약 ~ 90% 까지 비용 절감 가능.
● 수요/공급에 의한 가격 변동으로 예기치 않은 인스턴스 중단은 치명적.

● 그래서 Beanstalk 에서 Spot Instance 를 사용하고 싶었다.
● 그러나 어떻게 해야할지 딱히 방법이 생각나지 않았다.
○ Beanstalk 에서 사용하는 AMI 로 Spot fleet 을 만들어야하나??
○ 그리고 ELB 에 등록??
○ 그럼 배포는??
○ 배포할때마다 새로 구성해줘야하나??
○ 두번 배포해야하나??
○ 그럼 이런 작업들을 스크립트로 만들어서 운영해야하나??
○ 아이 그거 참 귀찮네.
Beanstalk 와 Spot Instance 는 인연이 아니었었습니다.

● 남들은 어떻게 했나 검색해보자
● 검색해도 잘 안나오네
● 오 찾았다.
● https://forums.aws.amazon.com/message.jspa?messageID=707034

Q: 나.. 있자나..
Beanstalk 에
Spot Instance
사용하고 싶은데
되니?
A: 아니,
하지만
계획엔 있어
Q: 흠….
무려 2011 년도 글!

그 뒤로 ‘+1’ 들이
달리기 시작한다.
Beanstalk 에서
Spot 을 사용할 수
있게 해달라!!!
저도 동참하려던
찰라

그러다 뜬금
2014년에 다시 AWS
에서 답이 달린다
A: 현재로서는
Beanstalk 에서 Spot
Instance 를 사용할 수
있는 방법은 없어.
하지만 .ebextension
에 SpotPrice 를
설정할 수 있지.
(???)

Q: 음.. 그래? 그럼 Spot
Price 만 설정하면
Beanstalk 가 자동으로
Spot Instance 를
사용하는거야?
A: 응. 근데 완벽히
지원 하진 않아.
이를테면 Scale Up 시
인스턴스가 추가 될 때
Spot 으로 띄울 수
없어.
그리고 입찰가 보다
높아지면 Spot
Instance 가 종료될 수
있지.
(칫)

● 우선은 Spot Instance 보다 Beanstalk 를 선택할 수 밖에 없었다.
○ Spot Instance 의 가격이 너무 마음에 들지만,
○ Beanstalk 로 운영되는 시스템을 Spot Instance 를 기반으로 새로
구성하기엔 구축/운영 리소스가 너무 많다고 판단.
● 일단은 Beanstalk 의 인스턴스 타입, 서버 수 등을 다시 점검하고
최적화 하면서 운영.
Beanstalk > Spot Instance

1
회사가 성장함에 따라
서버 수 는 나날이 증가하고,
다음달에는 현재 트래픽에
10배 가 늘어날 예정이었다.
이중고
2
사장님은 비용걱정하지 말고
하고싶은대로 다 하라고
해놓고선,
그 다음날 와서는 비용이 많이
나온다고 뭐라뭐라 한다.

spotinst.com > Elastigroups
● 정말 방법이 없는지 다시 구글링을 시작하였다.
● 그러다 우연히 아래의 블로그 포스트를 발견
○ http://blog.spotinst.com/2016/01/03/new-deploying-with-elastic-beanstalk-on-sp
ot-instances/
● 하지만 믿지 않았다. 그냥 뭐 알고보면 비슷한 말장난 아닐까?

● AWS 공식 블로그에서도 소개가 되었다.
○ https://aws.amazon.com/ko/blogs/apn/how-to-deploy-a-high-availability-web-se
rvice-on-aws-using-spotinst/
● 진짜? 정말?
● 그래서 한번 살펴보았습니다.

● 이스라엘 국방부(IDF) 산하의 엘리트 기술그룹인 MAMRAM 출신의
젊은 엔지니어들에 의해 창업된 50명 규모의 스타트업 회사
● 2015년부터 미국을 시작으로 전세계에 서비스를 확대하고 있으며,
월평균 30%의 성장률을 기록, 600여개가 넘는 고객사.
● AWS 인프라를 자동으로 최적화하는 인텔리전트 워크로드 관리
기능을 제공
● 강력한 예측 알고리즘을 사용하여 비용 절감 효과를 가져오는
서비스

● Spot Instance 특성 상 갑자기 종료가 되어도 자동으로 새로운 Spot Instance 추가
● Spot Pool 에서 Instance 를 얻을 수 없을 경우 RI 또는 On-demand 로 대체
● 여러 AZ, 여러 Instance Type 할당 가능
● Spot Instance 에 대해서도 Auto-Scaling 설정 가능
● Beanstalk 에서 배포를 시작 하면, 기존의 Beanstalk Instance 들의 배포가
이루어지고, 이 후 자동으로 Spot Instance 들의 배포가 진행.
● Beanstalk Health 탭에 서도 Spot Instance 들의 상태 확인 가능.
‘Beanstalk 와 Spot Instance 의 높은 수준의 연동 가능’

● 최근 90일 간
● Spot Instance 를 161,855 시간, On-Demand Instance 를 153 시간 사용
● 원래 On-Demand 기준이라면 비용이 $21,955 이지만
● Spot Instance 를 사용하였기 때문에 실제 $3,485 이 청구 되었고
● 총 $18,470 / 84.13% 를 Save 할 수 있었다.

spotinst.com > Other Products
● Elastigroup > Stateful Applications
○ http://blog.spotinst.com/2017/04/06/new-service-stateful-spot-service/
○ 예를 들어, DB 서비스를 하고 있는 EC2 의 경우 Spot Instance 의 종료 또는 인스턴스
타입 교체 시, 데이터 스토리지(EBS)는 그대로 유지 가능.
● Elastigroup > Mr. Scaler
○ EMR 도 Spot Instance 로 구성이 가능
○ http://blog.spotinst.com/2015/12/24/running-hadoop-and-spark-using-amazon-emr-with-sp
otinst-mapreduce-group/
○ http://blog.spotinst.com/2016/01/19/new-elastic-map-reduce-breakthrough-auto-scaling-for
-task-nodes-is-here/
● Multai Load Balancer
● 이 외에도 굉장히 많은 기능들을 제공한다.

전 spotinst.com 직원이 아닙니다.
● 좋은 경쟁은 소비자를 이롭게 합니다.
● https://www.cmpute.io
● http://blog.cmpute.io/run-aws-elastic-beanstalk-spot-instances-save-80-ec2-costs/

체크 포인트
● 처음 시작 시 14일 trial 기간이 있음
● trial 지나고는 사용 못할 줄 알았는데, 계속 사용 가능했음
● 그렇게 몇달을 사용하다가 얼마전 메일이 날라옴
● ‘너네 최근에 사용량이 많아졌어. 그래서 계약을 해야 trial
딱지를 떼고 정식으로 사용할 수 있어’
● 계약내용은 saving cost 에서 ‘nn%’ 를 service fee 로 지불
● 그래서 했습니다. ;)

본 강연이 끝난 후…
● 돌아가셔서
● http://spotinst.com
● http://cmpute.io
● 꼭 한번 씩 해보시길 강력 추천 합니다!

2017 Ad-Tech on AWS 세미나ㅣKinesis Stream 사용기

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 2017 Ad-Tech on AWS 세미나ㅣKinesis Stream 사용기

Similaire à 2017 Ad-Tech on AWS 세미나ㅣKinesis Stream 사용기 (20)

Plus de Amazon Web Services Korea

Plus de Amazon Web Services Korea (20)

2017 Ad-Tech on AWS 세미나ㅣKinesis Stream 사용기