Kiến trúc FAANG 11 - Samsung modernized architect for real-time analysis

Tiếp bài trước 

Nếu ai là fan của Samsung thì sẽ biết đến hệ sinh thái Samsung SmartThings , nền tảng iOT. Hệ sinh thái này cho phép user có thể kết nối mọi thiết bị của Samsung như smartphone, tivi, tủ lạnh, máy giặt từ bất cứ đâu. Ví dụ như ngồi ở công ty có thể dùng smartphone để bật điều hòa, tivi, check camera xem vợ đang làm gì

]

Phần core của nền tảng này là SmartThing Cloud lưu trữ data như device history (kiểu hàng ngày mở device lên để làm gì), usage statistics (thời gian sử dụng, độ tiêu thụ năng lượng…)

Với số lượng hàng trăm triệu user của Samsung thì lượng data từ các thiết bị điện tử này đẩy lên Cloud là cực kì lớn, vào khoảng 30+ TB dữ liệu một ngày (ngang cỡ 6K+ video JAV fullhd), nên Samsung cần có giải pháp batch data processing cho Big Data

]

Nói đến Bigdata thì Apache Spark framework được sử dụng để xử lý dữ liệu thời gian thực, build on top của Hadoop cluster. Spark App pull data từ các thiết bị sensor, device từ Device Gateway và Kafka để thực hiện ETL, rồi lưu kết quả và Hbase, các thiết bị như mobile app sẽ query data qua API gateway để hiện thị trên điện thoại của user

Nếu nhìn như mô hình trên thì Samsung dùng giải pháp self-hosted tức là tự deploy Kafka, Spark lên EC2 instance truyền thống (nằm trong các ASG)

Ví dụ như Kafka, như mô tả ở bài trước , thì Kafka cluster bao gồm nhiều broker instance manage bởi Zookeeper, thông tin này lưu trong zookeeper.properties

clientPort=2181
server.1=172.31.11.221:2888:3888
server.2=172.31.7.161:2888:3888
server.3=172.31.2.85:2888:3888

Mấy thông tin như server.1, 2 là các kafka broker, được assign IP, các broker này expose qua ELB. Mỗi khi broker instance được thêm bớt, thì file config trên được update. Nhìn chung thì script làm được việc này.

Các Spark App cũng được deploy trên EC2 theo cách tương tự như vậy

Lúc đầu architect này chạy ổn. Tuy nhiên vào mùa sale, số lượng user Smart Things tăng lên đột ngột thì hệ thống này xuất hiện issue.

Vì cách deploy theo kiểu self-hosted này, đồng nghĩa với việc các kĩ sư Samsung phải tự manage bằng cơm, resvered resources khi lượng request tăng lên đột ngột.

Các spark app bắt đầu consume RAM và Memory dẫn tới performance issue, outage. Hiện tượng tranh chấp resources xảy ra, giải thích về resources contention như sau

Ví dụ bạn sử dụng một ec2 instance type với 64G ram, 32vCPU, deploy một số ứng dụng như ES, Spark, Kafka. Mỗi ứng dụng này khi chạy đồng thời sẽ consume CPU/Memory resource ông nào chạy càng trâu thì càng chiếm lắm. Trong khi resource server thì chỉ có vậy, nhiều process đồng thời chiếm dụng memory/CPU/disk I/O dẫn tới deplay, slow down. Cái này cũng giống như play some vậy, ông này xài chỗ này thì ông còn lại phải chờ tới lượt mình

Để tránh resource contention thì kĩ sư Samsung có một bước gọi là allocate resource cho ứng dụng, cái này set trong file config của ứng dụng

Elastic search heap space

-Xms4g  
-Xmx4g

Spark resource allocation

Một Spark cluster gồm nhiều worker node, executor, task để execute data processing jobs

số lượng executor/task càng nhiều thì performance càng tăng nhưng đồng nghĩa memory/cpu consume càng nhiều, nên phải tính toán số lượng Executor/task hợp lý

#executor_per_node = (vcore_per_node-1)/spark.executor.cores
executor_per_node = (16–1)/5 = 3
#spark.executor.instances = (executor_per_node * number_of_nodes)-1
spark.executor.instances = (3*3)-1 = 8

Việc thực hiện autoscale và resource allocation theo cách như trên cũng tăng chi phí vận hành, vì phải thực hiện manually hoặc scripting

Ngoài ra Apache Spark hiện tại xử lý theo kiểu Microbatching, không hoàn toàn là realtime, near realtime only nên có delay, trải nghiệm không tốt cho người dùng

Kỹ sư của Samsung SmartCloud cần phải tìm ra giải pháp khác đảm bảo khả năng scalability và availability/maintainability cho hệ thống, tránh cách self-hosted solution như trên

Cuối cùng, giải pháp được lựa chọn là chuyển mô hình EC2 truyền thống sang serverless/full managed dùng EKS, Apache Flink on Kinesis Data analytic

Apache Flink có nhiều ưu điểm hơn so với Spark

Kiến trúc mới được đề xuất như sau

Đổi Kafka Self-hosted trên EC2 thành Managed Kafka của AWS, incoming traffict được đưa vào Kafka trước khi consume bởi Kinesis

50+ Spark App migrate sang 30+ Flink Apps trên Kinesis Data Analytics

Microservice được container và deploy trên EKS thay vì EC2 để leverage khả năng scale của k8s

Tuy nhiên việc migrate từ hệ thống cũ sáng mới có nhiều challeging. Một trong số đó là khả năng AutoScale của Kinesis

Apache Flink có thông số gọi là Parallel Execution, đại loại là số instance task được chạy parallelism quá trình scale out/in là tăng giảm con số này từ 1 đến 256 (max)

Theo documentation of AWS, Kinesis mất 15 phút để thực hiện scale out khi CPU usage vượt 75%, trong khi , trong khi scales down khi CPU < 10% mất tới 6 giờ. Như vậy là thời gian scale in quá nhanh còn scale out thì quá chậm dẫn tới tốn chi phí

Vì vậy Samsung tự build custom autoscaling thay vì dùng đồ có sẵn của AWS

Theo giải pháp này thì CloudWatch track CPU usage rồi trigger Lambda để thực hiện thay đổ parallelism values, dễ dàng customize và tốc độ scaling nhanh hơn so với build in của AWS

Sau khi thực hiện đo đạc metrics, kiến trúc mới hiệu quả hơn so với kiến trúc cũ