#162 - Quản lý chi phí hạ tầng dữ liệu tại Netflix
Những bài viết hay
Pharos - Tìm kiếm các tài xế lân cận — engineering.grab.com
Đã bao giờ bạn thắc mắc về những gì sẽ xảy ra sau khi bạn click vào nút "Đặt xe" trên ứng dụng Grab? Một trong những bài toán cốt lõi của các ứng dụng giao hàng và đặt xe là xác định các tài xế đang di chuyển gần nhất với người đặt xe theo thời gian thực. Có hai thách thức từ việc đáp ứng các yêu cầu đó trong thời gian thực:
Các phương tiện thường duy chuyển rất nhanh (đôi khi lên tới 20m/s), để cung cấp dịch vụ tìm tài xế gần nhất ta sẽ phải liên tục theo dõi các phương tiện và cập nhật vị trí liên tục.
Tính toán khoảng cách định tuyến (routing distance): để đáp ứng các yêu cầu nghiệp vụ, số lượng K các đối tượng gần nhất cần được tính toán dựa trên khoảng cách định tuyến thay vì khoảng cách theo đường chim bay. Do sự phức tạp của mạng lưới giao thông, tài xế có khoảng cách theo đường chim bay ngắn nhất có thể không phải là tài xế được chọn tối ưu nhất vì có thể đến điểm đón với khoảng cách định tuyến dài hơn do đi đường vòng. Để giải quyết bài toán này, người ta thường sử dụng giải thuật K Nearest Neighbour (KNN).
Tại Grab, các kỹ sư đã nghiên cứu và phát triển Pharos - một giải pháp scalable in-memory hỗ trợ khối lượng dữ liệu lớn, theo thời gian thực để giải quyết hai vấn đề nêu trên.
Làm thế nào để trở thành Solution Architect
Làm sao để trở thành một solution architect? Đó là câu hỏi của rất nhiều bạn lập trình viên. Ở bài viết sau tác giả Allen Helton chia sẻ một số góc nhìn về solution architect:
Bức tranh tổng thể (big picture). Là một solution architect, bạn cần hiểu rõ về bối cảnh (context) và bức tranh tổng thể của hệ thống. Đi tìm câu trả lời cho hàng loạt câu hỏi khi xây dựng một tính năng mới hay thay đổi tính năng hiện tại: sự thay đổi sắp tới có ảnh hưởng gì tới toàn bộ hệ thống? Những module nào liên kết với nhau? Tính năng hay ứng dụng bạn sắp xây dựng đóng vai trò như thế nào?
Học cách hỏi "tại sao?". Hiểu được hệ thống hoạt động như thế nào là điều cần thiết, tuy nhiên điều quan trọng hơn là phải hiểu tại sao nó hoạt động như vậy. Tại sao không làm cách này mà lại làm theo cách kia. Một khi đã thấu hiểu được những điều này, bạn có thể đưa gia một giải pháp thích hợp cho một vấn đề phức tạp.
Liên kết vấn đề để đến với giải pháp. Trở thành một solution architect, công việc của bạn không còn đơn thuần là viết code. Một khi hoàn thành xong thiết kế, bạn còn phải giải thích nó cho tất cả mọi người từ developer, product manager, thậm chí đến cả customer support. Do đó, bạn cần có các kỹ năng về giao tiếp tốt để có thể liên kết ý tưởng của bạn đến những khái niệm đơn giản để mọi người đều có thể hiểu được. Ngoài khả năng giao tiếp tốt, bạn đôi khi phải biết "đứng trên vai người khổng lồ". Đôi khi bạn cần "mượn" các thiết kế hay ý tưởng từ những người đi trước, hay nói cách khác bạn không cần phải "reinvent the wheel".
Nhìn về phía trước. Một solution architect tuyệt vời sẽ sống ở tương lai. Họ thiết kế hệ thống cho hiện tại để giúp công ty thành công trong tương lai. Việc thiết kế và xây dựng một hệ thống thường tốn nhiều công sức, thời gian và tiền bạc, do đó bạn cần chú ý đến mục tiêu của công ty trong một năm tới, năm hoặc mười năm tới công ty muốn đạt được điều gì.
Quản lý chi phí hạ tầng dữ liệu tại Netflix
Netflix đầu tư rất nhiều vào cơ sở hạ tầng dữ liệu của mình, bao gồm hàng chục nền tảng dữ liệu, hàng trăm producer và consumers với lượng dữ liệu lên đến hàng petabyte.
Tại nhiều tổ chức khác, một cách hiệu quả để quản lý chi phí cơ sở hạ tầng dữ liệu là thiết lập ngân sách và các biện pháp bảo vệ nặng nề khác để hạn chế chi tiêu. Tuy nhiên, do tính chất phân tán cao của cơ sở hạ tầng dữ liệu sự ưu tiên của Netflix vào quyền tự do và trách nhiệm, những quy trình đó là phản văn hóa và không hiệu quả.
Do đó, cách tiếp cận hiệu quả của Netflix là cung cấp sự minh bạch về chi phí và đặt bối cảnh hiệu quả càng gần với những người ra quyết định càng tốt. Họ xây dựng các dashboard một cách chi tiết cụ thể để phải ánh chân thực toàn bộ hệ thống cơ sở hạ tầng.
Trong bài viết, tác giả có đi miêu tả quá trình quản lý hạ tần của Netflix, từ đây chúng ta có thể học hỏi cách họ có thể giảm thiểu chi phí một cách tối ưu:
Có được cái nhìn tổng quát về chi phí cho mỗi nhóm, có khả năng tổng hợp chi phí trên tất cả các nền tảng khác nhau nhưng cũng phải duy trì khả năng chia nhỏ chi phí theo một đơn vị tài nguyên có ý nghĩa (table, index, column family, job, ...)
Hệ thống đề xuất lưu trữ tự động và time-to-live (TTL). Trong một số trường hợp, Netflix có thể cung cấp tính minh bạch và các đề xuất tối ưu hóa. Vì lưu trữ dữ liệu có nhiều mức sử dụng và chi phí, Netflix đã tự động phân tích để xác định thời lượng lưu trữ (TTL) tối ưu dựa trên các sử dụng dữ liệu. Cho đến nay, Netflix đã kích hoạt các đề xuất TTL cho các bảng kho dữ liệu lớn S3.
Giao tiếp và cảnh báo người dùng: Kiểm tra chi phí dữ liệu không nên là một phần công việc hàng ngày của bất kỳ team nào, đặc biệt là những team có chi phí dữ liệu không đáng kể. Về vấn đề đó, Netflix đã đầu tư vào hệ thống email push notifications để nâng cao nhận thức về chi phí dữ liệu giữa các nhóm có mức sử dụng dữ liệu đáng kể. Tương tự, Netflix chỉ gửi các đề xuất TTL tự động cho các bảng có tiềm năng tiết kiệm chi phí.
Góc Distributed System
Cùng xuất phát điểm là ELK như những công ty khác, Uber đã tiến hoá hệ thống Logging của họ như thế nào?
Uber sử dụng hệ thống ELK từ năm 2014 nhưng sớm nhận ra một số vấn đề khi hệ thống scale:
Log schema: engineers sử dụng cùng 1 field name với nhiều types khác nhau trong field values, dẫn tới type conflict trong elastic search.
Operational cost: Uber đã deploy hơn 20 cluster Elastic search và hơn 50 cluster Logstash cho mỗi region. Hệ thống càng lớn tần suất xảy ra sự cố càng nhiều dù cho nỗ lực automation tới cỡ nào.
Hardware cost: cho việc indexing fields trong Elastic Search.
Aggregation: Hơn 80% số query là aggregation về terms, histogram và percentile, trong khi Elastic Search không được design tốt cho fast aggregation query trên tập dữ liệu lớn. Ví dụ query bị timeout thường xuyên ở mức last 6h với 1.3TB dữ liệu log.
Uber đã cải tiến hệ thống Logging với những tiêu chí sau:
Functionalities: Schema-agnostic, hỗ trợ tốt aggregation query, hỗ trợ tốt multi-tenant và cross-tenant query
Efficiency and maintenance: hỗ trợ tốt deployment multi-tenant, giảm cost và sẵn sàng với việc scale 10 lần, tăng tính ổn định và đơn giản hoá việc vận hành.
Migrate dễ dàng từ hệ thống ELK cũ
Họ đã cải tiến thông qua sử dụng hệ thống ClickHouse (RDBMS) làm nền tảng lưu trữ log và xây dựng lớp abstraction bên trên để hỗ trợ schema-agnostic data model. Những cải tiến chính nằm ở table schema khi flatten raw JSON log giúp dễ dàng scale về tốc độ truy vấn lẫn deployment, log schema-free ingestion thông qua hệ thống kafka, xây dựng bộ công cụ query với type-aware thay thế cho bộ mặc định của ClickHouse, và Adaptive Indexing. Ngoài ra là các vấn đề về deployment multi-tenant, multi-region và việc migrate từ hệ thống ELK cũ qua hệ thống mới cũng được đề cập tới.
Cụ thể như thế nào mời bạn đọc bài viết chi tiết tại đây: https://eng.uber.com/logging/
Góc Database
Với xu hướng các dịch vụ tương tác trực tuyến ngày càng phát triển mạnh, các hệ thống kiến trúc truyền thống càng trở nên khó khăn hơn trong việc đáp ứng các yêu cầu về lưu trữ cho các nền tảng này. Đặc biệt là khi các nhu cầu này tạo ra những mâu thuẫn trong việc thiết kế hệ thống.
Cụ thể, một ứng dụng sử dụng MySQL làm cơ sở dữ liệu có thể rất tiện lợi và dễ dàng trong quá trình phát triển, tuy nhiên khi hệ thống cần mở rộng để phục vụ hàng triệu người dùng thì việc tái thiết kế lại hạ tầng lại khá tốn chi phí. Các hệ quản trị cơ sở dữ liệu quan hệ cung cấp nhiều tính năng hỗ trợ việc dựng sản phẩm nhanh chóng nhưng lại khó để mở rộng lên mức cho hàng trăm triệu người dùng. Các hệ thống NoSQL như BigTable, HBase hay Cassandra thì dễ dàng mở rộng, nhưng hạn chế về mặt API cũng như các model dữ liệu nhất quán lại gây cản trở trong quá trình phát triển ứng dụng. Ngoài ra, một bài toán nan giải khác phải đối mặt là quá trình sao lưu dữ liệu giữa các datacenter cách xa nhau nhưng vẫn phải đảm bảo độ trễ thấp.
Megastore là một hệ thống lưu trữ được phát triển để giải quyết những nhu cầu của các dịch vụ tương tác trực tuyến ngày nay, bao gồm: khả năng mở rộng, thuận tiện trong quá trình phát triển, độ trễ thấp, tính nhất quán của dữ liệu và tính khả dụng cao. Được kết hợp giữa khả năng mở rộng của hệ thống NoSQL và tính thuận tiện của hệ quản trị cơ sở dữ liệu quan hệ truyền thống, Megastore đảm bảo tính đồng nhất của dữ liệu cũng như độ khả dụng cao.
Nội dung của bài báo gồm có:
Cơ chế phân vùng dữ liệu và thiết kế tối ưu phù hợp cho các ứng dụng tương tác trực tuyến quy mô lớn của Megastore.
Thiết kế của data model và hệ thống lưu trữ cho phép việc xây dựng sản phẩm có tính khả dụng và mở rộng cao trở nên dễ dàng.
Giải thích chi tiết và so sánh hiệu năng thực tế của các thuật toán sao lưu.
Tổng hợp kinh nghiệm trong việc deploy hệ thống Megastore ở Google.
Code & Tools
This Week Sponsors
Remitano là một trong các sàn giao dịch P2P năng động tại nhiều quốc gia, Remitano cung cấp thị trường uy tín, an toàn tối đa và đơn giản cho hoạt động mua bán tiền mã hóa của hàng triệu khách hàng, với sản phẩm đầu tư đa dạng, giao dịch tức thời và đội ngũ hỗ trợ 24/7 bao gồm các chuyên gia ngân hàng có nhiều kinh nghiệm trong các sản phẩm tài chính, tiền điện tử, và hệ thống thanh toán, đảm bảo mang đến trải nghiệm tốt với mức phí thấp nhất cho người dùng.
Quotes
That’s what’s cool about working with computers. They don’t argue, they remember everything and they don’t drink all your beer.
- Paul Leary