#141 - Facebook scale các dịch vụ và ứng dụng của họ như thế nào?

Oct 04, 2020

Grokking Newsletter chính thức ra mắt chuyên mục mới "Góc Distributed System", nhằm giúp mang đến cho độc giả nhiều thông tin và kiến thức hơn.

Bên cạnh đó, xin mời các bạn độc giả của Grokking Newsletter tham gia vào group tại Facebook để nhận được các thông tin về các hoạt động meetup diễn ra hàng tuần của team Grokking.

Những bài viết hay

Top Five Differences between Data Lakes and Data Warehouses — www.bluegranite.com

Sự quan tâm đến Big Data thực sự đã tăng lên trong vài năm gần đây. Trong quá trình làm việc để xử lý các bài toán về dữ liệu, các giải pháp đưa ra thường liên quan nhiều đến Data Lake hay Data Warehouse. Qua bài viết, tác giữa muốn đề cập đến những sự khác biệt cơ bản giữa hai khái niệm này, qua đó giúp bạn đưa ra quyết định sáng suốt về cách quản lý dữ liệu của mình.

Với Data Warehouse, một trong những đặc tính cơ bản gồm:

Thể hiện một góc nhìn trừu tượng về business được tổ chức, sắp xếp theo chủ đề hay lĩnh vực nhất định
Dữ liệu đã được biến đổi và có cấu trúc ở mức cao.
Dữ liệu không được load vào Data Warehouse cho đến khi mục đích sử dụng được xác định.

Về Data Lake, có những đặc tính cụ thể sau:

Tất cả data được load vào Data Lake.
Một lượng lớn data ở lớp ngoài cùng hầu như chưa được xử lý và chuyển hoá về một cấu trúc nhất định
Ngoài ra, data vẫn được chuyển đổi và schema được xác định để đáp ứng nhu cầu phân tích.

Ngoài ra, có 5 khác biệt lớn giữa Data Lake so với Data Warehouse:

Data Laka lưu trữ toàn bộ data
Data Lake hỗ trợ tất cả các cấu trúc dữ liệu
Data Lake hỗ trợ tất cả các users
Data Lake dễ dàng thích ứng với những thay đổi
Data Lake cũng cấp một góc nhìn chi tiết nhanh hơn

Broccoli: Syncing faster by syncing less - Dropbox — dropbox.tech

Dropbox sync rất nhiều petabytes dữ liệu mỗi ngày cho hàng triệu desktop clients, vì vậy họ liên tục cải tiến nâng cấp cơ chế sync dữ liệu từ client-server để vừa nâng cao trải nghiệm người dùng (giảm độ trễ) và vừa tận dụng tối đa network server (chi phí lưu trữ/băng thông). Team Dropbox đã nghiên cứu và thử nghiệm trên một số thuật toán nén cho data stream gồm 7zip, zstd, zlib và Brotli và cuối cùng họ chọn Brotli và thực hiện một vài tùy chỉnh và thay đổi nhỏ để cho ra một bộ encoding dùng cho Dropbox: Broccoli.

Trong bài viết, các kĩ sư tại Dropbox đã chia sẻ về Broccoli, giải thích cách họ đã sử dụng và kết hợp bộ encode trên để tối ưu hóa việc nén dữ liệu giúp giảm độ trễ và băng thông khi sync dữ liệu từ client-server xuống tới 30%.

Very fast and scalable topic routing – part 1 - Messaging that just works — www.rabbitmq.com

RabbitMQ cũng như các hệ thống message queue khác sử dụng một thuật toán định tuyến để hướng các message đến hàng đợi. Ví dụ message với topic .stock.# sẽ hợp với usd.stock và vnd.stock.db nhưng không phải stock.xzy.

Ở hai bài https://www.rabbitmq.com/blog/2010/09/14/very-fast-and-scalable-topic-routing-part-1/ và https://www.rabbitmq.com/blog/2011/03/28/very-fast-and-scalable-topic-routing-part-2/, tác giả của RabbitMQ phân tích hai ứng cử viên là cây (trie) và DFA (deterministic finite automate) để cải thiện tốc độ hoạt động của hệ thống. Thông qua benchmark, tác giả nhận thấy cây tốt hơn DFA cả về tốc độ và tài nguyên sử dụng. Đồng thời kết quả của việc sử dụng cây giúp RabbitMQ v2.4.0 nhanh hơn phiên bản trước đó v2.3.1 từ 25 đến 145 lần.

Góc Distributed System

Scaling services with Shard Manager - Facebook Engineering — engineering.fb.com

Việc sử dụng sharding để scale các dịch vụ là không hề mới. Tuy nhiên Facebook khẳng định rằng họ là người tiên phong trong việc xây dựng một nền tảng sharding tổng quát (Generic Sharding Platform) giúp triển khai các ứng dụng của họ ở mức độ large scale, họ gọi nền tảng đó là Shard Manager.

Facebook khẳng định Shard Manager là nền tảng tập trung của họ quản lý hàng chục triệu shard được vận hành trên hàng trăm ngàn server là môi trường cho hàng trăm ứng dụng chạy trên đó. Trong đó có những ứng dụng quan trọng phục vụ trực tiếp người dùng như Facebook app, Messenger, WhatsApp và Instagram. Việc tích hợp ứng dụng vào Shard Manager được thực hiện thông qua 3 bước:

Implement 2 interface là `add_shard` và `drop_shard`
Khai báo nhu cầu về reliablility và efficiency thông qua bản mô tả ứng dụng khi tích hợp
Khai báo các ràng buộc nếu có trong quá trình cân bằng tải.

Shard Manager là một trong ba thành phần quan trọng nhất trong kiến trúc hạ tầng của Facebook, và cũng là thành phần nằm trên cùng trong lớp hạ tầng. Dưới Shard Manager có hai thành phần khác là:

Resource Allowance System - quản lý server vật lý
Twine - quản lý container

Shard Manager đã được đưa vào triển khai từ 9 năm trước và vẫn còn đang được phát triển thêm. Một số mục tiêu tiếp theo Facebook muốn đạt được với Shard Manager:

Mỗi ứng dụng cần có hàng chục triệu shard để hỗ trợ việc chia nhỏ ứng dụng ra các thành phần độc lập để dễ scale hơn
Hỗ trợ các loại ứng dụng phức tạp hơn
Đơn giản hoá hơn quy trình onboarding ứng dụng vào shard manager

Góc Database

Đối với các hệ thống dữ liệu phân tán, việc chia nhỏ (shard) dữ liệu ra lưu trữ trên nhiều node dữ liệu khác nhau là một bài toán phổ biến.

Ví dụ như bạn có một tập dữ liệu về người dùng bên dưới (3 triệu dòng, dùng username là khoá), bạn muốn truy xuất theo kiểu key-value lưu trên 3 node server khác nhau. Làm sao để lưu trữ và truy xuất hiệu quả?

Một kỹ thuật dễ nhất là sử dụng modulo hashing. Trong đó bạn sẽ tìm cách hash trường username thành một trong ba giá trị 0-2, (modulo 3). Nếu username được hash ra giá trị 0 thì sẽ lưu vào node 1, giá trị hash là 1 sẽ lưu vào node 2, tương tự với node 3.

Tuy nhiên, khi lượng dữ liệu tăng lên, bạn muốn tăng số lượng node lên 4-6 node chẳng hạn, thì kỹ thuật này sẽ trở nên bất lợi vì quá trình hash sẽ phải làm lại từ đầu để phân chia dữ liệu lại giữa các node.

Một phương pháp tốt hơn có tên gọi Consistent Hashing đã được đưa ra để giải quyết vấn đề này. Ý tưởng của phương pháp này chính là thay vì dùng modulo hashing dựa trên số lượng nodes thì bạn sẽ dùng modulo hashing cho một con số token ảo, và gán các token này vào server tương ứng.

Cụ thể, trong ví dụ ở trên, thay vì hash username với modulo 3, chúng ta có thể hash username ra cho 128. Và phân chia các token (0-127) vào 3 nodes tương ứng. Như vậy, dữ liệu vẫn sẽ được rải đều ra cả 3 server. Tuy nhiên khi cần thêm node mới thì chúng ta chỉ cần di chuyển các dòng dữ liệu nằm trong phạm vi token mà chúng ta muốn san sẻ ra cho node mới thay vì phải hash lại toàn bộ dữ liệu (như hình minh hoạ bên dưới)

Phương pháp này được đưa ra trong một bài báo cách nay 23 năm “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”. Từ đó đến nay, phương pháp này đã và đang được áp dụng rộng rãi trong nhiều hệ thống khác nhau như Cassandra, ScyllaDB, DynamoDB, … Mời các bạn cùng tìm hiểu.

Code & Tools

Quotes

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live

― John Woods