#145 - Bài toán Consensus trong mạng phân tán
Những bài viết hay
Netflix System Design Recommendation Open Connect — uxdesign.cc
Netflix là một dịch vụ xem phim trực tuyến phổ biến nhất toàn cầu. Netflix đã báo cáo có hơn 182 triệu người đăng ký trên toàn thế giới trong quý đầu tiên của năm 2020. Không có gì ngạc nhiên khi 16 triệu người đăng ký trong số này đã tham gia trong ba tháng đầu năm nay so với 5 triệu người đăng ký mới mỗi quý trước đó.
Trong bài viết, tác giả đề cập đến những thiết kế mang lại trải nghiệm người dùng thú vị nhất mà Netflix đã tích hợp vào hệ thống của mình.
Recommendation System: thuật toán recommendation của Netflix có lẽ đã trở nên phổ biến với nhiều người. Netflix có một lượng dữ liệu người dùng khổng lồ và vẫn đang tiếp tục thu thập thêm. Netflix sử dụng rất nhiều metrics để xây dựng hệ thống recommendation, ví dụ như: lịch sử xem và rating, những người xem có sở thích và lựa chọn tương đồng (Collaborative Filtering), Content Based Filtering (tên phim, thể loại, diễn viên, năm phát hành, … ), thông tin người dùng (thời gian xem, thiết bị xem, …)
Personalized Artworks: việc phân tích dữ liệu không chỉ dừng lại ở hệ thống recommendation. Netflix có định hướng dữ liệu cao và sử dụng phân tích của mình để thu hút bạn xem nhiều hơn. Nếu bạn đã từng đăng nhập qua các tài khoản khác nhau, bạn có thể nhận thấy rằng Netflix không sử dụng các hình ảnh tiêu đề giống nhau cho một chương trình, cho tất cả người dùng. Netflix xem xét các yếu tố khác nhau, như sở thích và thói quen của bạn, để chọn hình ảnh phù hợp nhất để thu hút và kích thích bạn chọn xem bộ phim đó.
Kiến trúc phân tầng của Netflix có thể chia ra làm 3 phần chính: Client, Back-end và CDN. Netflix tối ưu hoá CDN để mang đến tốc độ load phim nhanh nhất cho người dùng. Ngoài ra, dựa vào thiết bị xem phim của người dùng, Netflix sẽ tạo ra những files dung lượng khác nhau cho mỗi bộ phim, để đảm bảo người dùng có thể có trải nghiệm nhanh và chất lượng nhất có thể. Ngoài ra, thiết kế Micro-services của Netflix có thể coi là hình mẫu mà chúng ta có thể học tập.
Trong bài viết này, tác giả sẽ đi sâu và chi tiết hơn cách thiết kế từng hệ thống của Netflix, đặc biệt là cách Netflix sử dụng CDN, Proactive Caching, hay lưu trữ file trên AWS S3 như thế nào để mang đến nội dung mới cho người dùng nhanh nhất có thể.
How we scale Live streaming for millions of viewers simultaneously — engineering.fb.com
Ở Facebook, các dịch vụ như Facebook Live và Facebook Watch ngày càng trở nên phổ biến và được người dùng sử dụng thường xuyên. Do đó, các đài truyền hình chuyên nghiệp từ các giải đá bóng như La Liga, CONMEBOL, và UEFLA đã bắt đầu hợp tác với Facebook để đưa các trận đấu bóng đá lên Facebook livestream cho các khán giả của họ. Các đội ngũ kỹ sư ở Facebook đã phải tìm cách scale hệ thống livestream của họ để đáp ứng nhu cầu này khi mà trận đấu UEFA Champions League đã đạt mức 7,2 triệu người xem cùng một lúc trên khắp thế giới.
Bài viết sau đây nói cụ thể hơn cách mà Facebook scale hệ thống network của họ như thế nào để có thể tiếp nhận dữ liệu video một cách đáng tin cậy hơn và để đáp ứng lượng truy cập lớn trong cùng một lúc.
Scaling Slack’s Job Queue — slack.engineering
Trong bài viết sau đây, đội ngũ kỹ sư ở Slack giải thích cách mà họ đã tận dụng Apache Kafka như thế nào để cải thiện hệ thống job queue ở Slack. Như các bạn đã biết, job queue thường được sử dụng để đăng ký và chạy những tác vụ tốn thời gian lâu hoặc không cần thiết để trả lời về lại gấp ở trên web.
Job queue ở Slack mới đầu được thiết kế dựa trên Redis để chứa những tác vụ này trên memory và cho các workers có thể lấy và xử lý chúng. Tuy nhiên, trong một biến cố vào năm 2017, hệ thống ở Slack đã gặp trục trặc khi mà các ứng dụng tranh chấp tài nguyên database do quá tải dẫn tới các tác vụ trong job queue ở Redis không thể xử lý nhanh được. Do đó, memory ở những Redis cluster của họ đạt tới giới hạn dẫn tới việc các jobs không thể được bỏ thêm hay lấy ra nhanh được ở Redis job queue do sự giới hạn ở memory của từng máy chủ. Sau sự cố này, đội ngũ kỹ sư ở Slack đã đưa ra quyết định cải thiện hệ thống job queue của họ để đạt 3 tiêu chí chính:
Thay đổi Redis in-memory store với một storage khác bền vững hơn
Thiết lập một hệ thống scheduler cho các tác vụ để cải thiện chất lượng của dịch vụ và cung cấp thêm những tính năng cần thiết khác như là rate-limiting hay prioritization
Tách rời việc xử lý tác vụ từ Redis để giúp scale hệ thống dễ dàng hơn
Do hệ thống Redis ở thời điểm đó khá là phức tạp, các kỹ sư ở Slack đã quyết định áp dụng kế hoạch thay đổi hệ thống theo nhiều bước. Bước đầu tiên là dùng Kafka trước khi jobs được đưa vào Redis. Mời các bạn đọc bài viết sau đây để hiểu rõ hơn họ làm thế nào để áp dụng Kafka cho việc scale hệ thống ở bước này lên tới mức xử lý 1,4 tỷ tác vụ lúc cao điểm với 33k tác vụ mỗi giây.
The State of Developer Ecosystem in 2020 Infographic — www.jetbrains.com
Một report được thực hiện từ đầu năm 2020 với gần 20000 lượt khảo sát, sẽ cung cấp cho các bạn những góc nhìn về các công nghệ mới nổi, các ngôn ngữ lập trình phổ biến hiện này, và nhiều quan sát khát xung quanh thế giới lập trình.
Góc Database
Sau một thời gian đọc các paper khá là hardcore, góc Database tuần này mời các bạn cùng điểm qua một bài báo mang tính giải trí khá cao về việc "đặt tên cho Database". Link đọc bài báo.
Phải công nhận là "đặt tên biến" vẫn luôn là một trong các bài toán khó của dân lập trình các bạn nhỉ.
Góc Distributed System
Bài toán consensus giải quyết sự đồng thuận giữa các node/processor trong mạng phân tán, với khả năng chịu lỗi xảy ra (fault-tolerance) hoặc ở processor hoặc ở mạng truyền tin. Bài toán consensus là bài toán kinh điển luôn xuất hiện trong các hệ thống phân tán có nhiều tác nhân tham gia. Cách tiếp cận tự nhiên để đạt được sự đồng thuận là toàn bộ processor phải đồng ý 1 giá trị được số đông chấp nhận, ít nhất là quá bán (50%+1). Tuy nhiên, cách tiếp cận này luôn gặp vấn đề khi các processor lỗi có thể luôn cản trở việc đạt được đồng thuận hoặc không bao giờ đạt được đồng thuận. Do đó, bài toán đồng thuận luôn có giới hạn ở số lượng maximum các processor lỗi.
Có 3 điều kiện luôn được đặt ra trong bài toán consensus:
Termination (điều kiện kết thúc quá trình đồng thuận): các processor hoạt động đúng sẽ dần dần đưa ra giá trị quyết định.
Integrity (tính toàn vẹn / đồng bộ của quá trình đồng thuận): nếu tất cả processor hoạt động đúng đều đề xuất giá trị v, thì bất kì processor hoạt động đúng nào đều phải đồng ý giá trị v là quyết định.
Agreement (luật bất biến của quá trình đồng thuận): mọi processor hoạt động đúng đều phải đồng ý trên cùng 1 giá trị.
Điều kiện integrity có nhiều biến thể phụ thuộc từng thuật toán và mục đích sử dụng consensus. Ví dụ 1 integrity yếu hơn là giá trị quyết định có thể được chọn bởi 1 nhóm các processor hoạt động đúng thay vì tất cả.
Một chút lịch sử
Bài toán consensus lần đầu được đề cập vào năm 1978 bởi Robert Shostak với công bố về “Interactive consistency problem" khi ông làm việc ở dự án SIFT (Software Implemented Fault Tolerance) tại Computer Science lab ở SRI International (được NASA tài trợ). Lúc công bố, Shostak chứng minh được cần tối thiểu 3n+1 processor trong mạng để bài toán consensus có thể chạy được với n=1 processor bị lỗi. Sau này Leslie Lamport đặt lại bài toán 1 cách tổng quát hơn và chứng minh được cho trường hợp n>1.
Một bài toán nổi tiếng cũng từng được Grokking giới thiệu, chính là bài toán các vị tướng Byzantine. Các bạn có thể đọc paper sau để hiểu thêm về bài toán này trong Distributed System: https://lamport.azurewebsites.net/pubs/byz.pdf
Code & Tools
The Most Popular Databases: From 2006 to 2020 - A bar chart that shifts and changes over time-based on the popularity of different database systems (as determined by the TOPDB index)
This week sponsor
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
ChoTot create product 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, such as Airflow, Argo, Data Catalog, Google AI Platform, Google BigQuery, Google Analytics, Superset 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.
Principal platform software engineer
Quotes
A primary cause of complexity is that software vendors uncritically adopt almost any feature that users want.
- Niklaus Wirth