2. 세션의 진행
Piljoong Kim (@PiljoongKim)
Solutions Architect
Amazon Web Services Korea
RTB
RTB 란?
RTB 플랫폼 구성요소
AWS 와 RTB
고객 사례
3. 얻을 수 있는 것
• RTB 가 뭔지 모름
– RTB 가 어떤것인지 정의해 볼 것
• 뭔지는 앎, 근데 뭘 해야할지 모름
– 무엇이 가능한지 알아볼 것
• AWS 에서 RTB 가 제대로 구현될 수 있는지 의문이 듦
– 충분하며, 이미 사용중인 고객 사례 알아볼 것
• AWS 에서 구현 및 운영해 볼까 생각 중임
– AWS 가 어떻게 도움을 줄 수 있는지 알아볼 것
9. RTB 란?
Real-time bidding (RTB), created by Jason Knapp, is a
means by which advertising inventory is bought and sold
on a per-impression basis, via programmatic
instantaneous auction, similar to financial markets. With
real-time bidding, advertising buyers bid on an
impression and, if the bid is won, the buyer’s ad is
instantly(typically in 100ms) displayed on the
publisher’s site.
10. Programmatic Buying
Programmatic Buying refers to the process of purchasing
digital advertising with the use of automated software's.
The software like DSP, SSP, and Ad Exchange helps to
automate the process as opposed to traditional process
of buying and selling which involved manual human
negotiations.
11. Programmatic Buying
즉,
• 타기팅과 개인화된 광고
• 퍼블리셔나 미디어 채널이 아닌,
오디언스, 소비자와 간접적으로 연결
되는 것
• 적절한 때에 적절한 사람에게 관련된
광고를 제공하는 것
• 불필요한 광고 지출을 줄이는 것
• RTB 를 포함하는 것
Programmatic
Buying
RTB
12. 프로그래매틱 시장 (US 시장)
• 2017년에는 광고 구매의 83%가
프로그래매틱으로 이루어질 것으로
예상
• RTB는 110억 달러(한화 약 12조) 규모,
2015년 광고 지출의 74% 차지
• 낮은 마진 – 효율적인 운용은 이점을
가짐
• 프로그래매틱 다이렉트 역시 증가
추세
13. RTB: 흐름
1. 페이지에 접속
2. Ad Network 에
노출을 공지하여 경매
시작
3. 바이어들이 경매
가격을 제시
4. 최고 입찰인에게
노출의 기회가 주어짐
5. 광고주의 광고가
전달됨
14. RTB: 광고 선정
3200
CPM
광고 위치
2000
CPM
2100
CPM
3400
CPM
1600
CPM
2600
CPM
3100
CPM
1800
CPM
1100
CPM
2300
CPM
1200
CPM
2900
CPM
3400 CPM 낙찰
RTB
15. RTB: 광고 경매 타임라인
사용자 식별
(10ms 이하)
Exchange 로
부터 시작됨
3rd
파티 데이터로
사용자에 대한
이해도를 높임
(10ms 정도)
DSP 로 부터
bid 요청을 받음
(50ms 정도)
bid 가격으로
광고를 구매
비지니스 로직
적용
낙찰된 광고를
사용자에게 전송
DSP 에 의해 수행
3rd
파티 데이터로
사용자에 대한
이해도를 높임
가장 매력적인
광고 선택사용자 식별
1 2 3 4 5 6
43
대게 이 과정을
100ms 타임아웃으로 진행
(어떤 곳은 150ms 까지)
가장 핫한 시간에,
AppNexus 는 초당
3백만번 처리를 수행
http://radar.oreilly.com/2014/12/how-browsers-get-to-know-you-in-milliseconds.html
16. RTB: 중요한 특성과 AWS
가변적인 트래픽 볼륨 / 높은 비용 중요한 응답시간
Auto Scaling
DynamoDB (<10ms)
ElastiCache (<1ms)
Direct Connect
예약 인스턴스
스팟 인스턴스
20. 입찰 트래픽 처리 시스템
• 부하 분산을 위해 ELB 를 활용
• Auto Scaling 및 API/CLI 를 활용하여 자동화
• 오픈 소스 Bidder 인 RTBkit(http://rtbkit.org/) 활용 가능
Availability Zone Availability Zone
Auto Scaling group
Auto Scaling group
Web Tier
App Tier
Low Latency
Data Store
Load
Balancing
21. RTBkit?
RTBkit is an open-source software
framework that takes much of the hard
engineering work out of creating a Real-
Time Bidder for online advertising. Its
open, service-oriented architecture can be
used to assemble a bidder as simple or
complex as desired. The RTBKit core
connects to ad exchanges via Exchange
Connectors and routes bid requests and
data through a configurable set of
components which can be extended to
implement a customized bidder.
CloudFormation is ready!
Pre-configured AMI is available!
http://rtbkit.org/
23. 분석 트래픽 처리 시스템
• Kinesis 를 활용하여 분석용 데이터를 수집 (KPL, KCL)
• Kinesis Firehose 를 활용하면 S3 또는 Redshift 로의 저장을 간소화 할 수
있음
Availability Zone Availability Zone
Auto Scaling group
Processing
Data
Ingestion
Long Term
Durable Data
Store
25. 캠페인 관리 시스템
• 광고 캠페인을 관리, 모니터링, 다른 광고주의 예산을 제어하는 시스템
• 보통의 잘 디자인된 웹 애플리케이션
• 입찰 트래픽 처리 시스템과 비슷, 하지만 영속 데이터의 가용성이 더 중요!
• RDS 와 CloudFront 를 활용
Availability Zone Availability Zone
Auto Scaling group
Auto Scaling group
Web Tier
App Tier
Multi-AZ RDS
Content
Delivery
Load
Balancing
AWS Elastic
Beanstalk
27. 낮은 지연 저장소
• 노출에 대한 입찰 여부 및 입찰금 조회와 결정에 이용 됨
• DynamoDB 또는 ElastiCache 활용 가능
• EC2 에 Aerospike, Cassandra, Couchbase 등 설치 후 운용 가능
Amazon
DynamoDB
Amazon
ElastiCache
Amazon
EC2
29. Amazon DynamoDB
• 빠르고 성능 예측이 가능한 분산 NoSQL
– 평균 서비스 지연 시간은 보통 수 밀리초 미만
– 문서 데이터 구조와 키 값 데이터 구조를 모두 지원
• 확장 및 용량 등 관리형 서비스로 제공
– HDD가 아니라 SSD 기반이라 빠른 속도
– 경험이 적은 운영 노하우 부분의 걱정을 덜 수 있음
30. 특징1: 관리자 필요없는 높은 신뢰성
• SPOF가 존재하지 않는 구성
• 데이터는 3개소의 AZ에 분산 저장되어 높은 신뢰성
• 스토리지는 필요에 따라 자동으로 분산 처리
31. 특징2: 처리량을 프로비저닝 가능
• Read및 Write 각각 필요한 만큼의 처리 용량을 할당
• 예를 들어 일반적인 Read Heavy DB라면
– Read: 1,000
– Write: 100
• 약간 Heavy한 DB의 경우
– Read: 500
– Write: 500
• 이 설정값은 DB 운영중에 온라인으로 변경 가능
32. 특징3: 저장 용량에 제한이 없음
• 사용한 만큼 지불하는 종량제 스토리지
• 데이터 용량 증가에 따른 노드 추가와 같은 작업이 불필요
34. 내구성 있는 장기간 저장소
• 대량의 데이터를 낮은 가격으로 저장하여야 함
• 데이터 변환, 농축, 리치 분석 등에 이용됨 => 다른 서비스들과의 통합성 중요!
• 확장성, 안정성, 고가용성을 제공하는 S3 이용 가능
Amazon S3
오브젝트 저장소 (어떤 것이든 저장 가능)
확장성과 99.999999999% 내구성 제공
36. 분석 플랫폼
• EMR 을 활용, Redshift 활용
• 기계학습 접근을 채택하는 경우가 많음:
– EMR + Spark MLlib
- Amazon Machine Learning (Amazon ML)
• 다양한 서비스를 활용하여 자동화 및 운영 효율성을 높일 수 있음
- Amazon Simple Workflow Service (SWF)
- AWS Data Pipeline
- AWS Lambda
MapReduceMachine Learning Long Term
Durable Data
Store
39. Availability Zone Availability Zone
Auto Scaling group
Auto Scaling group
Web Tier
App Tier
Low Latency
Data Store
Load
Balancing
Availability Zone Availability Zone
Auto Scaling group
Processing
Data
Ingestion
Long Term
Durable Data
Store
Availability Zone Availability Zone
Auto Scaling group
Auto Scaling group
Web Tier
App Tier
Multi-AZ RDSContent
Delivery
Load
Balancing
Ad
exchanges
Advertisers
User
Tracking
Website
MapReduceMachine Learning
분석 트래픽 처리
입찰 트래픽 처리
캠페인 관리
분석 플랫폼
저장소
RTB 플랫폼
40. 몇 가지 팁: Front End & Back End 서버
• 대부분 부하 분산을 위해 ELB를 사용, 하지만 HAProxy, NGINX 설치 사용도
가능!
• HTTP Persistent Connection 활성화 하기 (HTTP Keep-Alive)
• 개발자들의 피드백: 레가시 비더들은 C/C++, Java, Erlang 이 많았지만,
최근에는 Node.js, Python, Scala 가 많이 사용 됨
• 비더는 점점 더 모듈화 되고, 도커화(컨테이너) 되고 있음
• 트래픽이 증가하면, 개별 exchange 에 전용 ELB 와 ASG 를 사용
41. 몇 가지 팁: 낮은 지연 캐시
• DynamoDB, Redis, Aerospike 를 많이 사용하고 있음
• 지역간 복제가 중요해지며 Storm 활용에서 DynamoDB Streams + Lambda
활용이 점점 더 많아지고 있음
42. 몇 가지 팁: 데이터 수집 및 분석
• 비더에서 발생하는 데이터는 Apache Spark 와 같은 스트리밍 서비스를
활용
• Kinesis + Spark 또는 Kafka + Spark 가 많이 사용 됨
• 성능 향상과 비용절감을 위해 비더에서 발생하는 데이터를 일괄 처리
44. VidRoll
• 50,000개의 고유한 도메인에서 사용됨
• 매월 수억 건의 광고를 지원
• 비디오 플레이어는 100,000개의 웹
사이트에서 판매 됨
콘텐츠 게시자를 위한 동영상 기술 및 수익 창출 플랫폼
45. VidRoll 아키텍처
• 개발자들의 인프라에 대한
이해와 걱정을 없앰
• 8~10 명의 엔지니어가 주로
하던일을 2~3 명의 엔지니어가
할 수 있게 됨
• 기술인력 추가 없이 10배 이상
수익이 증가함
AWS
Lambda
Amazon API
Gateway
Amazon
DynamoDB
Amazon
Redshift
Amazon
Kinesis
46. PocketMath 의 하루
• 300억 건의 경매
• 수억의 입찰
• 수천만의 노출
• 60ms 이상은 입찰 실패
• 95% 가 10ms 이내로 처리됨
100% self-serve,
mobile demand-side platform (DSP)
for programmatic mobile
48. Inneractive
모바일 광고 공간을 구매하고 판매하기
위한 기술을 제공하는 모바일 ad exchange
• 예약 인스턴스와 스팟 인스턴스로
수만달러를 절약
• 이 수치는 AWS 월 청구 비용의 20~30
퍼센트 수준
• 100 예약 인스턴스 + 800 스팟 인스턴스
49. 이번 세션에서 얻어갈 점
• 애드테크는 AWS 와 잘 맞아요!
– 가변적인 트래픽 볼륨
– 중요한 응답 시간
– 글로벌로의 확장
• 인프라와 서비스도 자동화할 수 있어요!
– Auto Scaling
– CLI/ SDK 제공
– 다양한 파트너솔루션
• 항상 비용을 고려하세요!
– 다양한 EC2 인스턴스 종류; 목적에 맞는 인스턴스 사용
– 예약 인스턴스와 스팟 인스턴스 활용
52. 허니스크린 - 잠금화면 포인트 서비스
Reward & Benefit
유저가 잠금해제 할 때마다 리워드를 지급하고, 각종 할인
쿠폰 및 혜택 정보를 잠금화면을 통해 제공합니다.
Beautiful UI/UX
유저의 기존 스마트폰 사용 방식을 해치지 않는 UX/UI를 통
해 자연스러운 첫화면 서비스를 제공합니다.
Personalized Contents & Utility
유저가 좋아할만한 컨텐츠를 어디 찾아가지 않고 잠금화면에 바로
볼 수 있도록 유저의 관심사를 반영한 개인화된 컨텐츠를 제공합니
다.
53. 버즈스크린 - 잠금화면 포인트 SDK
사용자가 기존 앱 내의 메뉴에서
‘잠금화면 사용하기’ 설정만 하면…
…별도 앱 다운로드 없이
바로 잠금화면 기능 사용 가능!
54. 버즈애드 - Ad Serving Platform
27
[ Offerwall Type ]
국내외 최대 규모의 애드네트워크.
CPI(다운로드), CPV(Video),
CPL(Like) Instagram Follow 등 다
양한 광고 상품 라이브 중.
[ Lockscreen Ad Type ]
띠배너보다 Impression 당 단가
가 5~10배 높은 프리미엄 인벤
토리. Mediation 기능과 잠금화
면 소재 최적화 기술.
[ Native Ad Type ]
사용자 경험을 해치지 않으면서 효
율성을 높인 광고. 컨텐츠 내 피드
형(In-feed)과 동영상(Video) 타입
의 광고를 지원
55. AD serving with DynamoDB
■ 장점
- Fully managed NoSQL
- 빠른 응답 시간
- 쉬운 확장성
- 고가용성
■ 인덱스
- Hash key, Range key
- Local secondary index
- Global secondary index
■ RTB를 위한 요구 조건
- 요청에 대한 응답이 약 100ms 안에 이뤄져
야 함
- 서비스가 전 세계로 확장되는 경우 Cross-
region 대응이 용이해야 함
Amazon
DynamoDB
BuzzAd
HoneyScreen
BuzzScreen
App client
SDK client
SDK client
56. BuzzAD 활용 사례 - 타게팅
■ Custom Audience Targeting
- 광고 아이디 리스트를 직접 추출하여 해당 유저에게만 노출 또는 제외
■ Retargeting
- 특정한 액션을 수행한 사용자에게 맞춤 광고 노출
■ 액션형 인센티브 광고
- 이미 광고참여를 완료한 유저를 제외
Hash key - 광고ID Range Key - Profile Timestamp - 시간 Attribute1 - UA
ADID-1234 target-group-1 1468511492
ADID-1234 product-id-7 1468511422
ADID-1234 lineitem-id-2 1468511491
ADID-1235 user-agent 1468512491 iOS-Mozillaxxxx
57. BuzzAD 활용 사례 - Frequency Capping & Fraud Detection
■ Frequency Capping
- 유저당 광고 노출 빈도 제어
■ Realtime Fraud Detection
- 광고 Impression/Click 이상징후 감지
Hash key - 광고ID Range Key - 시간 lineitem_id type
ADID-1234 1468511492 1234 impression
ADID-1234 1468511422 2222 click
ADID-1234 1468511491 3333 allocation
ADID-1235 1468511492 3334 allocation
58. Redshift VS Hadoop
■ Hadoop with MapReduce
- 비정형 빅데이터 처리 가능
- MapReduce를 이용해 분석하는 것 자체가 어려운 작업
■ SQL on Hadoop
- Hive, Tajo, Impala, Presto 등 많은 기술이 등장
■ Redshift
- 어차피 SQL을 쓴다면?
■ 결론
- 하둡을 써야 할 특별한 이유가 있는것이 아니라면 Redshift를 추천
59. Redshift - 장점
■ 성능
- 에어비엔비 사례 (http://nerds.airbnb.com/redshift-performance-cost/)
- Runtime Hive: 28 minutes / Redshift: less than 6 minutes
- Runtime Hive: 182 seconds / Redshift: 8 seconds
- Hive 대비 약 5배의 성능 향상
■ 운영
- 하둡 클러스터 관리 대비 적은 운영 코스트
■ 비용
- 연간 테라바이트당 약 1,000 USD
- 3년 약정 시 - 75%
■ 빠른 개발 사이클
- 하둡 대비 빠르게 실험적인 쿼리를 만들고 수정
- 결과를 확인하는데에 걸리는 시간이 짧기 때문에 가능
60. Redshift - 활용
■ Unique 통계 분석
- 광고의 unique impression count
- 광고의 unique click count
■ CTR 분석
- 유저의 나이/성별/지역 등 프로파일 별 광고 CTR 분석
- 인벤토리 별 광고 CTR 분석
- 광고 타입 별 CTR 분석
■ 이상 징후 모니터링
- 광고 라이브 중 문제 발생시 빠르게 현상 파악 가능
- Impression/Click 트렌드를 초/분 단위로 세분화 하여 볼 수 있음
■ 코호트 리텐션 분석
- 유저의 1/3/7/30/90 일 리텐션 분석
- 유저의 성별/나이/유입채널 별 리텐션 분석
61. 데이터 수집 및 적재
■ Kinesis Firehose
- Redshift로 데이터를 적재하기 위한 가장 쉬운 방법
- Log forwarder로 Fluentd 사용
■ DB에서 직접 동기화
- 데이터양이 적은 경우
■ API Gateway & Lambda
- 애플리케이션에서 발생한 로그를 직접 수집
■ Consistency에 대한 고려
- 데이터 중복에 대한 인지 필요함
Amazon
Kinesis
Firehose
Amazon
S3
Amazon
Redshift
Amazon
EC2
Amazon
RDS
Amazon API
Gateway
AWS
Lambda
62. 대시보드 만들기
■ BI 툴 사용
- Periscope
- Looker
- Zeppelin
■ 시각화
- SQL 쿼리만으로도 간단하게 그래프 생성
- 비개발자도 대시보드 개발
■ 대시보드 캐싱
- 불필요한 쿼리를 줄임
63. 결론
■ 관리 비용 절감
- AWS를 사용하는 가장 큰 이유
- 100대 이상의 인스턴스를 포함한 버즈빌 전체 인프라를 한 사람이 파트타임으로 해결
■ 안전성
- AWS를 사용하는 두 번째 이유
- 직접 서버를 운영하는 것 보다 AWS에서 제공하는 서비스가 대부분의 경우 더 안정적
■ 해외 진출의 용이함
- 해외 진출시 인프라 구축에 대한 걱정이 필요 없음
- 리전간에 데이터 공유가 필요한 경우에도 대응이 쉬움
■ 성능
- DynamoDB/Redshift 모두 충분히 빠르다!