Itlc2015

Kiến trúc hệ thống quảng cáo lớn trên nền scala.

@huydx (Φφ) CyberAgent Inc

Agenda• Giới thiệu

• Quảng cáo trên Internet: Programmatic Ad

• Scale về kiến trúc / middleware trong một hệ thống quảng cáo lớn

• Scale về code thông qua functional programming và scala

• Demo





• Demo

Giới thiệu bản thân• Name: Huy

• Position: Software Engineer • Location: Tokyo/Japan

• Favourite Language: Ruby/Scala/Java

• Other • Admin/cofounder of Ruby Vietnam

• cofounder of kipalog.com / ktmt blog

http://kipalog.com

CyberAgent• Thành lập 1998 (17 năm)

• Các dịch vụ chính: mạng xã hội (ameba (40tr users)), quảng cáo trên internet (adagency, adtech), game, investment

• Doanh thu 1 năm ~ 2.4 tỉ USD

• ~5000 nhân viên

Adtech Studio• Chuyên nghiên cứu, phát triển các hệ thống quảng cáo (DSP, SSP, AdNetwork, Affiliate, DMP…)

• Một vài con số (trên toàn bộ studio):

• Network Uplink: 160GBS

• Overall QPS: ~2-3millions/per sec

• Overall data size: ~ 30PB

• Overall server instance: ~1-2000 servers (AWS, DC)

• Ngôn ngữ: Scala, Java, PHP, Ruby, Go





• Demo

• Bài nói sẽ nói chính về programmatic advertising bao gồm: banner ad và in-feed ad, chủ yếu về khía cạnh kĩ thuật

Chú ý

Quảng cáo== đem thông tin của người cần bán

đến người cần mua

Quảng cáo != evil

Nhưng How???

• Tại sao hiện tại chúng ta phải hứng chịu nhiều quảng cáo tồi?? • Do hiển thị quảng cáo qua thoả thuận trực tiếp

• Do không có đủ thông tin người dùng

• Do máy móc, thuật toán chưa đủ "thông minh"

• Do người cần mua và người cần bán không đến được với nhau

•......

openRTB ra đời

•RTB == real time bidding

•Việc hiển thị quảng cáo diễn ra tại realtime thông qua việc "bán" view của user tại thời điểm user visit website

•Advantage:

•User "ngon" sẽ được mua với giá đắt •User "tồi" sẽ được mua với giá rẻ

• --> có lợi cho cả bên bán lẫn bên mua

người bán

user1, visit

2. phát lệnh bán

3. đấu giángười bán

người mua

người mua

1000vnd

2000vnd

3000vndngười bán

4. hiển thị quảng cáo của bên thắng

openRTB == ngôn ngữ để bên mua nói chuyện với bên bán

Đặc điểm: • Fix format thay vì fix protocol (có thể sử dụng cả json, xml hay protobuf) • Format khá uyển chuyển để chứa đủ thông tin cho việc đấu giá trở nên hiệu quả

Những khó khăn

• Scale hệ thống (~millions qps)

• Scale dữ liệu lớn ( TB~PB)

• bidding Logic RTB

• Tracking user giữa mobile/web

• Thuật toán để đưa quảng cáo đến đúng với người dùng





• Demo

Hệ thống phụ trách• DMP system • QPS: ~10000req/s (140 instances) • Hadoop: ~100nodes • Cassandra: 15nodes (7TB) • Aerospike: 14nodes (~2TB RAM!) • MySQL: ~100GB • Datasize: 4.5billions cookie data

Stack

Architecture in short

front server

log aggregator

(fluentd)

redshift

hdfs

BI tool

aerospike(user data) (fast layer)

cassandra(user data)

(slow layer) hadoop (batch layer)

sparkML job


front server

log aggregator

(fluentd)

redshift

hdfs

BI tool




sparkML job

Why Aerospike

Aerospike• Rất nhanh với SSD • Ghi trực tiếp vào SSD không qua OS • 99.99% request sẽ dưới 1ms

• Vertical scale với P2P cluster • Cross-datacenter replication • Rất ổn định ( chưa thấy chết bao giờ ) • Tuy nhiên giá server đắt do: • Phải trang bị RAM lớn cho index • Phải trang bị SSD đúng chuẩn

Aerospike rất được tin dùng bởi các công ty quảng cáo lớn như: Appnexus, bluekai,

adform… :))))

Tại sao cần cả cassandra và aerospike

• Aerospike server quá đắt (1server 200GB Ram ~ 10k$)

• Khi cho data từ batchlayer vào thì việc rebuild index của aerospike ảnh hưởng performance

• Cassandra có performance khi batch write rất tốt, tuy nhiên tốc độ read lại không đảm bảo


front server

log aggregator

(fluentd)

redshift

hdfs

BI tool




sparkML job

Một chút về spark/hadoop

Hadoop & Spark• Hadoop là solution không thể thiếu để xử

lý dữ liệu lớn • Tuy nhiên Map/Reduce java code quá

nhiều boilerplate • Unit test khó viết (MRUnit đã không còn

update từ 1 năm trước) • Đang viết lại toàn bộ xử lý qua Spark

Hadoop & Spark• Why Spark • Code được viết bằng scala (yay!) • Compability với hadoop (hadoopApiFile) • Ít boiler plate, code sáng sủa hơn rất

nhiều • Dễ viết test hơn nhờ khái niệm RDD • Đi kèm với bộ mlib để xử lý machine

learning

Hadoop & Spark

• Một vài trick thú vị • Lzo encode để giảm lượng dữ liệu + lzo

có thể đọc được trực tiếp từ mapper • Serialize data dưới dạng protobuffer có

thể speed up tốc độ xử lý • Spark có thể đọc trực tiếp dữ liệu từ S3 -

> giảm chi phí HDFS


front server

log aggregator

(fluentd)

redshift

hdfs

BI tool




sparkML job

Tạo BI tool với redshift• Redshift là columnar database của amazon

• Hỗ trợ truy vấn dữ liệu theo PostgreSQL syntax

• Adhoc query trở nên dễ dàng hơn rất nhiều (window function support)

• Redshift scale rất tốt chỉ với thêm instance

• Điểm yếu: giá cao, không insert được data realtime (chỉ support batch insert/ bulk load)


front server

log aggregator

(fluentd)

redshift

hdfs

BI tool




sparkML job

Front server với • Scala lightway webframework ( trong thời

gian gần sẽ thành akka-http) • Actor model (thông qua akka) • Tận dụng core rất tốt (% sự dụng trên mỗi

core thường là xấp xỉ nhau) • Fault-tolerance với rất nhiều pattern thú vị

(tham khảo let-it-crash: reaper pattern, backpressure streaming….)

Every one


front server

log aggregator

(fluentd)

redshift

hdfs

BI tool




sparkML job

Fluentd• Là một giải pháp aggregate log từ "source"

đến "destination" <made in japan> • Một số đặc điểm thú vị • Dựa trên cơ chế plugin • Code viết trên ruby -> dễ debug, dễ đọc, dễ

viết • Fault tolerance tốt (cơ chế buffer, retry... khá

thông minh)

fluentd agent

fluentd agent

fluentd agent

fluentd agent

1xx instances

fluentd server

fluentd server

fluentd server

3 instances

redshiftbuffer &

bulk upload





• Demo

Tại sao lại cần functional

programming

Thực ra là không cần

MonadMonoidFunctorRing

EndofunctorSemigroupKleisliFreeMonad

https://michaelochurch.wordpress.com/2012/04/24/functional-programming-is-a-ghetto/

• Bạn không cần biết tất cả những khái niệm trên để hiểu về functional programming (FP)

• Nắm vững một số “ cách nghĩ” (concept) của FP giúp code của bạn (có thể) trong sáng hơn, (có thể) ít bug hơn, và (có thể) scale tốt hơn rất nhiều

Important!

• Tách biệt “ hiệu ứng phụ” (side effect) với những đoạn code thuần ("pure code")

• pure code là những đoạn code với cùng 1 đầu ra sẽ “ luôn luôn” output ra 1 kết quả (Referential transparency)

• Một số ví dụ về side effect • Mutable variable (re-assignment) • Thao tác IO (database) • Logger, Cache…

Một số “ cách nghĩ” của FP

• Thay vì nghĩ về từng bước giống như imperative programming thì hãy nghĩ về luồng xử lý (how)

• First class function (truyền xử lý, hay là truyền how) (ví dụ như sử dụng hàm map trong ruby hay scala thay vì for loop)

• Function combination: kết hợp nhiều xử lý con thành 1 xử lý to (for comprehension)


• Luôn cố gắng tổng quát hoá mọi bài toán bằng hết mức có thể (generic). Ví dụ:

• Monoid type class mô hình tất cả các đối tượng có khả năng thao tác với nhau thông qua binary operator (ví dụ như phép +, phép *)

• Option type class mô hình tất cả các đối tượng có khả năng chứa giá trị null -> tránh trường hợp NPE trong java

• Chuyển vất vả về library designer, người dùng (application programmer sẽ rất “ nhàn”)

Recommend cuốn “ From Mathematics to Generic Programming” của Alexander A. Stepanov


Một số tính năng của FP hay được sử dụng

• Basic • Kết hợp nhiều function

• Sử dụng linh hoạt Option/Either/Future

• FP Iterator style như foldLeft hay là @tailrec • Pattern matching

• Advance

• Monadic composition

• Type class

Hiệu quả đạt được• Tránh mutable state sẽ giúp code có thể lý

luận được chỉ nhờ đọc code, tránh được các thể loại bug khó phát hiện (heisenbug)

• Generic hoá giúp code dễ mở rộng • Sử dụng function pipelining (kết hợp nhiều xử

lý con thành 1 xử lý nhỏ) một cách thành thạo sẽ giúp code dễ hiểu hơn nhiều

Điểm bất lợi của FP• Functional programming không dễ • Khó scale về mặt con người • Khó thực hiện ở giai đoạn “ start up” khi cần

tốc độ nhiều hơn là chất lượng code • Tìm ra một giới hạn “ vừa đủ” để áp dụng là

rất khó vì thế giới FP rất rộng lớn

Giải quyết• Thực hiện các buổi học nhóm thường xuyên

trong nội bộ công ty • Thắt chặt tuyển dụng (những người thành

thạo FP thường sẽ <ít có> khả năng là một lập trình viên "tồi" !!!)

• Học haskell, closure trước (bắt tay vào học FP trên scala sẽ không tự nhiên bằng haskell hay closure)

Một số tài liệu tham khảo•Paper •http://monkey.org/~marius/funsrv.pdf (your server as a function)

•Book •Functional programming in scala •Functional Programming Patterns in Scala and Clojure: Write Lean Programs for the JVM •Learn your haskell for great good

•Slide •http://www.slideshare.net/pnicolas/advanced-scala-concepts

http://monkey.org/~marius/funsrv.pdf

http://www.slideshare.net/pnicolas/advanced-scala-concepts

Demo session (openrtb +

a little bit of FP)

Engineering

Itlc2015