Cách Netflix tối ưu chi phí hạ tầng dữ liệu
(netflixtechblog.com)Do cấu trúc hạ tầng phân tán của Netflix và văn hóa nội bộ “tự do và trách nhiệm”, việc tối ưu hóa là một công việc khá khó khăn, nên họ đã phát triển các bảng điều khiển tùy chỉnh để cung cấp tính minh bạch về chi phí và đặt ngữ cảnh liên quan đến tối ưu hóa gần hơn với những người ra quyết định.
Cách họ xây dựng “bảng điều khiển hiệu quả dữ liệu” này và những bài học rút ra
- Môi trường nền tảng dữ liệu của Netflix: có thể phân thành hai nhóm
-
Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
-
Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto
** Hiển thị mức sử dụng và chi phí trong nháy mắt **
Tập hợp chi phí của mọi nền tảng, đồng thời kèm theo thông tin có thể chia nhỏ từng khoản chi phí thành các đơn vị có ý nghĩa.
→ Đơn vị: bảng, chỉ mục, column family, job, v.v.
Nguồn của thông tin chi phí này về cơ bản dựa vào dữ liệu billing AWS được phân loại theo dịch vụ và tag, nhưng chỉ như vậy thì không thể phân biệt theo từng tài nguyên/từng đội, nên họ đã dùng các phương pháp sau.
- Nền tảng dựa trên EC2
→ Định nghĩa các metric gây ra nút thắt cổ chai (bottleneck metric) cho từng nền tảng
→ Ví dụ, Kafka bị ràng buộc bởi mạng, còn Spark bị ràng buộc bởi CPU và bộ nhớ.
→ Sử dụng Atlas, log nền tảng và REST API để phân tách metric theo từng tài nguyên và phân bổ chi phí
- Nền tảng dựa trên S3
→ Gắn S3 Prefix cho từng tài nguyên, rồi tính chi phí theo từng tài nguyên dựa trên giá lưu trữ
- Dashboard View
Sử dụng bảng điều khiển tùy chỉnh dựa trên Apache Druid để phân bổ từng khoản chi phí cho các đội.
Khách hàng chính của thông tin chi phí này là các nhóm kỹ thuật và dữ liệu, để họ có thể hành động dựa trên thông tin đó.
Ngoài ra, cũng cung cấp cho các lãnh đạo kỹ thuật cái nhìn ở mức cao hơn.
Tùy theo use case, có thể nhóm và xem theo đơn vị tài nguyên dữ liệu hoặc theo đơn vị tổ chức, đồng thời có thể xem dữ liệu dưới dạng snapshot và time series
** Khuyến nghị lưu trữ tự động - Time to Live (TTL) **
Trong một số kịch bản, họ không chỉ dừng ở việc cung cấp tính minh bạch mà còn đưa ra các khuyến nghị tối ưu hóa.
Lưu trữ dữ liệu có mức sử dụng cao và cũng có động lượng chi phí lớn (kiểu lưu xong rồi quên mất),
nên họ đã tự động hóa việc phân tích để xác định thời gian lưu trữ tối ưu (TTL) dựa trên mẫu sử dụng dữ liệu.
Khuyến nghị TTL được áp dụng cho các bảng dùng cho kho dữ liệu lớn trên S3
- Tính toán chi phí và logic nghiệp vụ
Chi phí S3 lớn nhất phát sinh từ các bảng giao dịch, thường được partition theo ngày.
Có thể xác định các partition ngày được truy cập bằng cách dùng access log của S3 và ánh xạ S3 prefix-to-table-partition.
Xem hoạt động truy cập (đọc/ghi) trong 180 ngày gần nhất để xác định ngày Lookback tối đa.
Giá trị TTL của bảng được quyết định bởi ngày Lookback này.
Dựa trên TTL đã tính toán đó, họ tính ra khoản tiết kiệm hằng năm có thể đạt được
- Dashboard View
Các chủ sở hữu dữ liệu có thể xem chi tiết mẫu truy cập dữ liệu, so sánh giá trị TTL được khuyến nghị với giá trị hiện tại, đồng thời kiểm tra mức tiết kiệm chi phí có thể có
** Giao tiếp và thông báo cho người dùng **
Việc kiểm tra chi phí dữ liệu không nên trở thành công việc thường nhật của các nhóm kỹ thuật, nhất là với những khoản chi phí dữ liệu không có nhiều ý nghĩa.
Vì vậy, họ đã phát triển chức năng gửi email push notification chỉ tới những đội có mức sử dụng dữ liệu cao để nâng cao nhận thức về chi phí dữ liệu.
Ngoài ra, chỉ với những bảng có khả năng tiết kiệm chi phí thì hệ thống mới tự động gửi giá trị TTL được khuyến nghị.
Hiện tại, những email này được gửi hằng tháng
** Bài học và thách thức **
- Việc xác định và duy trì metadata của từng tài sản là rất quan trọng đối với phân bổ chi phí
→ Để làm điều này, họ đã xây dựng kho lưu trữ metadata có tên là Netflix Data Catalog (NDC)
→ Nhờ việc truy cập và tìm kiếm dữ liệu trở nên dễ dàng hơn, có thể quản lý cả dữ liệu hiện có lẫn dữ liệu mới
→ Sử dụng NDC làm điểm khởi đầu cho việc tính chi phí
- Dữ liệu xu hướng theo thời gian là một thách thức
→ Dữ liệu xu hướng đòi hỏi gánh nặng quản lý lớn hơn nhiều so với snapshot
→ Rất khó để cung cấp một góc nhìn nhất quán do sự không khớp dữ liệu và độ trễ xử lý
→ Họ đã phải giải quyết hai bài toán
- Thay đổi quyền sở hữu tài nguyên: snapshot phải tự động phản ánh các thay đổi quyền sở hữu, còn với chế độ xem time series thì ngay cả các thay đổi đó cũng cần được phản ánh trong metadata
- Mất trạng thái khi phát sinh sự cố dữ liệu: metadata của tài nguyên được trích xuất từ nhiều nguồn khác nhau qua API, nên nếu thất bại trong quá trình thu thập thì trạng thái sẽ bị mất. Những dữ liệu này chỉ mang tính tạm thời, nên chỉ dựa vào trích xuất API là có giới hạn. Cần tìm các giải pháp thay thế như bơm dữ liệu sang phía Keystone
** Kết luận **
Nếu bạn có một nền tảng dữ liệu phân tán cao, thì việc tạo vòng phản hồi thông qua bảng điều khiển như thế này và tích hợp ngữ cảnh về mức sử dụng cũng như chi phí có thể cải thiện hiệu quả đáng kể.
Nếu có thể, nên nâng cao hiệu quả bằng các khuyến nghị tự động.
Trong trường hợp của Netflix, việc khuyến nghị thời gian lưu giữ dữ liệu đã cho thấy ROI rất cao.
Thông qua bảng điều khiển này và các khuyến nghị TTL, họ đã có thể giảm hơn 10% dung lượng lưu trữ của toàn bộ kho dữ liệu.
2 bình luận
Hóa ra tính năng gợi ý không chỉ dành cho người xem.
Hay đấy. Tôi chợt nhớ đến một nghiên cứu mà tôi từng đọc ở đâu đó, nói rằng nếu có thể nhìn thấy thiết bị theo dõi thời gian thực thì ngay cả cơ không tự chủ cũng có thể cử động.