#152 - Uber xây dựng nền tảng Real-Time Push Message như thế nào?

Dec 20, 2020

Grokking xin mời các bạn tham gia Grokking Techtalk #40 với hai chủ đề: MLOps Platform và Database Technologies.

Ở bài talk đầu tiên, sẽ nói về cách ba hệ thống Redis, Elastic Search và Cassandra tổ chức cluster cũng như sự trade-off giữa tính nhất quán (consistency) và khả năng đáp ứng (availability) của ba hệ thống này.

Ở bài tiếp theo, chúng ta sẽ cùng tìm hiểu cách Amazon Web Services (AWS) đã thiết kế & xây dựng 1 trong những nền tảng MLOps được ứng dụng rộng rãi nhất trên thế giới - Amazon SageMaker.

- Thời gian: 08:30 - 12:00 Thứ 7, 26/12/2020

- Địa điểm: Grab Vietnam - Tòa nhà Mapletree Business Center, số 1060 Đại Lộ Nguyễn Văn Linh, Phường Tân Phong, Quận 7, Thành phố Hồ Chí Minh

- Link đăng ký cho sự kiện: https://bit.ly/grk-techtalks-reg

Các bạn có thể xem thông tin chi tiết về event tại đây

Những bài viết hay

Uber’s Real-Time Push Platform — eng.uber.com

Đối với các ứng dụng có nhiều thành phần tham gia như Uber (tài xế, người đặt xe, cửa hàng ...), khi có một thay đổi bất kì , mobile app cần cập nhật sự thay đổi trên giao diện người dùng. Thông thường chúng ta sử dụng cơ chế Polling for updates. Sau một khoảng thời gian nhất định, thường là vài giây, mobile app sẽ gửi một request lên backend server để hỏi xem có thay đổi gì không. Hướng tiếp cận này gây ra một số vấn đề như:

Gây quá tải cho hệ thống backend
Tiêu tốn pin
Tốn băng thông(bandwidth)
Cold Startup: khi số lượng các requests cần phải gọi lên server nhiều, ứng dụng có thể bị đứng màn hình lúc mới mở ứng dụng

Để giải quyết các vấn đề trên, các kĩ sư công nghệ tại Uber đã chuyển từ Poll for updates sang Push for updates bằng cách xây dựng Push message platform mang tên RAMEN (Realtime Asynchronous Messaging Network) với bốn nguyên tắc thiết kế chính sau đây:

Chuyển đổi dễ dàng từ poll sang push mà không cần phải viết lại các APIs hiện tại
Dễ phát triển: developer không phải thay đổi code quá nhiều để chuyển từ poll sang push
Tất cả các gói tin phải được gửi đi một cách đáng tin cậy và có cơ chế retry nếu có lỗi xảy ra
Giảm thiểu lượng data truyền giữa backend và mobie app

RAMEN gồm 2 thành phần chính:

Push Message Creation System: hệ thống này đảm nhận tránh nhiệm tạo message payload bao gồm giải quyết 2 bài toán sau:

Khi nào cần tạo message? Khi có một thay đổi nào đó, hệ thống sẽ trigger một event cho Fireball service, Fireball service sẽ dựa vào configurations để quyết định có cần push message cho client hay không.
Tạo message như thế nào? Sau khi đã quyết định cần phải push một message cho client, công việc tiếp theo là tạo message payload do API Gateway đảm nhận.

Push Message Delivery System: hệ thống này đảm nhận trách nhiệm gửi message được tạo bởi Push Message Creation System tới client. RAMEN sử dụng Server-Sent Events (SSE).

Ngoài ra để tối ưu hoá cho việc push message, các kĩ sư tại Uber định nghĩa một số Metadata như Priority, Time to live, Deduplication(chi tiết vui lòng xem trong bài viết gốc).

Sau một thời gian hoạt động, RAMEN gặp một số vấn đề về scale, cho nên từ năm 2017, Uber engineer team sử dụng một số công nghệ như Netty, Apache, Zookeeper, Apache Helix, Redis và Apache Cassandra để cải thiện khả năng scale cho hệ thống.

Tự học Data Science như thế nào?

Khoa học công nghệ thường xuyên thay đổi và phát triển không ngừng, bạn càng làm nhiều, càng phải tự tìm tòi nạp thêm kiến thức, kỹ năng phù hợp với công việc và định hướng của bản thân. Vì vậy, đối với ngành khoa học dữ liệu, cũng như nhiều ngành khoa học công nghệ khác, việc tự học là vô cùng cần thiết.

Sau đây, tác giả sẽ chia sẻ một số nguồn tự học tiêu biểu để các bạn tham khảo. Bài viết giới thiệu những kênh tự học đặc biệt hữu ích với các bạn mới bước chân vào lĩnh vực Data Science hoặc đang muốn trau dồi thêm nhiều kiến thức và kinh nghiệm trong lĩnh vực này. Bài viết được chia làm 3 phần Học – Hỏi – Luyện & Thi: Các khóa học online, Forum & Blog, Các cuộc thi học máy & khoa học dữ liệu.

Nhìn chung, có rất nhiều nguồn tài liệu để các bạn tự học và tham khảo, nhưng hãy nhớ là học đi đôi với hành. Nếu chưa có kinh nghiệm làm việc trong lĩnh vực này, bạn nên chọn cho mình một dự án cá nhân nào đó để áp dụng những kiến thức đã học. Học lý thuyết mà không thực hành thì “chữ thầy trả thầy” nhanh lắm.

MuZero - Kẻ Lật Đổ Vương Triều Alpha! — codelearn.io

Tháng 11 năm 2019, DeepMind xuất bản bài báo với tựa đề “Mastering Atari, Go, Chess and Shogi by Planning with a Learned Model” để giới thiệu về MuZero – thế hệ kì thủ kế vị AlphaZero. Bài báo này đã gây được tiếng vang lớn trong cộng đồng Trí tuệ nhân tạo vào thời điểm bấy giờ. Điều gì đã khiến MuZero trở nên khác biệt với AlphaGo hay AlphaZero đến vậy?

Tuy AlphaZero không cần học hỏi nước cờ của con người, nhưng AlphaZero vẫn sử dụng môi trường trò chơi được định nghĩa rõ ràng như luật chơi, nước đi khả thi… Điều này làm khả năng áp dụng của AlphaZero bị giới hạn ở những trò chơi 2 người chơi có luật rõ ràng, có kết quả chung cuộc, ví dụ như cờ vua, khi ván cờ khép lại, ta luôn có kết quả thắng/thua/hòa để đánh giá lại.

Nhưng trong nhiều lĩnh vực thực tế như robot, điều khiển công nghiệp, trợ lí thông minh hay các trò chơi điện tử (như bộ trò chơi Atari – bộ những trò chơi điện tử dành cho một người chơi), chúng ta sẽ không có kết quả cuối cùng mà sẽ nhận được intermediate rewards (phần thưởng tức thì) sau mỗi hành động. Vậy làm sao để có thể khái quát hóa khả năng học hỏi của AlphaZero lên những bài toán đời thực?

Câu trả lời là: MuZero không nhận bất cứ kiến thức nào về luật chơi cả!

Bí mật trong cách tiếp cận mới của MuZero là kiến thức về quy luật trò chơi không còn được “mã hóa” nữa. Ngược lại, MuZero sẽ tự học luật chơi thông qua cơ chế self-play (tự chơi). Tuy cơ chế tự chơi đã xuất hiện ở AlphaZero, nhưng phải đến MuZero, cơ chế này mới thực sự được làm chủ và độc lập.

Cơ chế lựa chọn hành động dựa trên cây tìm kiếm Monte Carlo được tái sử dụng. Tuy nhiên với MuZero, các quy tắc của trò chơi không cần phải lập trình trực tiếp vào cây tìm kiếm Monte Carlo nữa, mà MuZero sẽ tự mình quản lý những representation (biểu diễn) về luật chơi. Điều này cũng tương tự một đứa trẻ đang tự học ngữ pháp theo cách hiểu “con nít” của riêng chúng nó vậy. Có thể nói, đây là một bước đột phá đáng ghi nhận trong lĩnh vực Học tăng cường nói riêng và Trí tuệ nhân tạo nói chung.

Góc Distributed System

Partial Network Fault in Raft

Trong khi vận hành, các node có thể không có thông tin kết nối đầy đủ với các node khác trong hệ thống. Trong nhiều trường hợp, điều này dẫn tới hệ thống không thể bầu chọn được leader, hoặc việc bầu chọn diễn ra không ổn định (ví dụ: leader liên tục chuyển qua lại giữa các node khiến hoạt động toàn hệ thống không thể tiếp diễn). Ví dụ với kết nối như trong hình, và node 1 đang là leader.

Do node 4 không nhận được tín hiệu từ leader 1, node 4 sẽ khởi tạo quá trình leader election. Khi đó node 2 sẽ cập nhật thông tin, động thời buộc leader 1 lui xuống thành follower.
Sau một thời gian, node 1 không nhận được tín hiệu từ leader trong mạng, khởi tạo quá trình bầu leader cho chính nó và trở thành leader. Node 2 cập nhật thông tin và buộc node 4 trở thành follower trở lại.
Tuy nhiên, khi đó ta lại quay lại trường hợp đầu: node 4 bị timeout và tiếp tục khởi tạo quá trình bầu leader. Do vậy, việc bầu leader trở nên không ổn định.

Cloudflare cũng đã có một incident tương tự trong thời gian gần đây liên quan về partial network fault khi vận hành https://blog.cloudflare.com/a-byzantine-failure-in-the-real-world/ (Lưu ý: lỗi được nêu trong bài viết không phải là Byzantine mà là Partial Network Fault, như một số comment ở dưới bài viết có ghi chú).

Bài viết sau sẽ trình bày 2 cơ chế khắc phục trong các trường hợp như trên:

PreVote: một node khi muốn bầu bản thân làm leader sẽ phải thăm dò trước, tránh tình trạng chiếm quyền khi leader hiện tại vẫn đang hoạt động tốt.
CheckQuorum: cho phép leader thường xuyên kiểm tra nếu bản thân có kết nối với quá bán các node trong mạng nữa không. Trong trường hợp có vấn đề về kết nối, leader hiện tại sẽ chủ động step down nhường cho một node khác trở thành leader.

Raft does not Guarantee Liveness in the face of Network Faults

Code & Tools

This Week Sponsors

Established in 2012, Chotot.com is the leading online classified website in Vietnam with more than 1,2 billion monthly page views, 10 million monthly users, 3,6 million transactions in 2019. With the motto “Muốn Là Có” (“A Way to Your Wants”), Chotot.com provides an effective online marketplace for Vietnamese to buy and sell various types of products easily. For more information, please visit www.chotot.com.

Góc Tuyển Dụng

Cho Tot creates products using a variety of open source and cloud native technologies, to name some: Kubernetes, Kafka, Elastic Search, PostgreSQL, MongoDB, TimescaleDB. We utilize Google Cloud Platform services such as Google Kubernetes, AI Platform, Cloud Composer, Data Catalog, BigQuery, Google Analytics for our infrastructure needs while running our heavy workloads on our own on-premises infrastructure. Visit careers.chotot.com to learn more about our vacancies and company culture.

Quotes

You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile

- Martin Fowler