Sai lầm 8 triệu USD của Uber: Bài học đắt giá về thiết kế hệ thống và động lực sai lệch

Trong vòng mười năm qua, Uber đã viết lại hệ thống sổ cái (ledger) của mình tới năm lần. Và ít nhất một lần, nếu không phải là tất cả, trong số những lần viết lại đó hoàn toàn có thể tránh được.

Nguyên nhân sâu xa của mỗi thế hệ phần mềm quản lý tiền tại Uber xuất phát từ những động lực sai lệch. Mọi thứ đều bắt đầu bằng một đề xuất mới, được phê duyệt như một giải pháp cuối cùng; theo thời gian, một điểm chết chí mạng xuất hiện; và cuối cùng, một đề xuất mới lại được đưa ra để thay thế nó.

Mỗi lần viết lại đều là dự án để thăng chức cho ai đó.

Hệ thống và dữ liệu

Ít nhất một trong số đó đã có thể tránh được: lần Uber chuyển sang sử dụng DynamoDB. Vào năm 2017, Uber đã triển khai nền tảng thanh toán mới của mình trên nền tảng này, và yếu tố then chốt mà mọi người dường như bỏ qua là DynamoDB là một cơ sở dữ liệu tính phí theo mức tiêu thụ.

Bạn phải trả tiền cho mỗi lần đọc và mỗi lần ghi.

Với mỗi chuyến xe tạo ra nhiều mục sổ cái, và Uber xử lý 15 triệu chuyến mỗi ngày, việc DynamoDB tuyệt vời về độ trễ thấp ở quy mô toàn cầu không còn quan trọng. Một người quản lý chi phí có tư duy thực tế lẽ ra đã phải chấm dứt sự điên rồ này ngay từ đầu.

Cái bẫy nhất quán và sự khác biệt giữa Thanh toán và Sổ cái

Trước hết, DynamoDB có phải là một lựa chọn tồi cho phần mềm tài chính không? Không hẳn. DynamoDB có nhiều tính năng đáng giá: di chuyển không thời gian chết, độ trễ thấp cho khán giả toàn cầu và tích hợp sẵn sao chép và chuyển đổi dự phòng.

Nếu bạn đang chấp nhận thanh toán ở quy mô toàn cầu, DynamoDB là một lựa chọn tuyệt vời. Mặc dù không thực thi tính tuyến tính hóa (linearizability) đầy đủ trên các phân vùng, DynamoDB có thể đảm bảo tính nhất quán trong một Region (Khu vực). Đối với hệ thống thanh toán quy mô toàn cầu, sự đánh đổi này là đáng giá vì các giao dịch thanh toán độc lập với nhau.

Tuy nhiên, một sổ cái (ledger) không phải là hệ thống thanh toán.

Một sổ cái không thể đơn giản nói rằng "hey, tài khoản này và tài khoản kia có thể xử lý độc lập". Phạm vi của hệ thống sổ cái là Toàn cầu; một kho dữ liệu không thể thực thi tính tuyến tính hóa đầy đủ sẽ không thể đáp ứng được, bất kể nó tốt đến mức nào về thông lượng và độ trễ.

Nói cách khác: DynamoDB hoạt động tốt trong thanh toán vì thanh toán có thể hy sinh tính nhất quán toàn cầu để có tính sẵn sàng cao hơn. Nhưng sổ cái không thể hy sinh tính nhất quán toàn cầu, ngay cả khi điều đó có nghĩa là tính sẵn sàng sẽ kém hơn.

Toán học trên giấy nháp (Napkin Math)

Đã đến lúc ai đó phải ngồi xuống và làm phép tính này. Mô hình giá dung lượng của DynamoDB dựa trên hai mô hình chính: Cung cấp (Provisioned) và Theo nhu cầu (On-demand).

Vào năm 2017, Uber thực hiện khoảng 11 triệu chuyến mỗi ngày. Giả sử 10 mục sổ cái cho mỗi chuyến và 5 đơn vị dung lượng ghi (WCU) cho mỗi mục, đó là 550 triệu lượt ghi mỗi ngày. Với giá 1,25 USD cho mỗi triệu lượt ghi, con số là 687 USD mỗi ngày.

687 USD mỗi ngày có vẻ không nhiều. Nhưng đó là 250.000 USD mỗi năm, chỉ tính cho việc ghi dữ liệu.

Với tốc độ tăng trưởng hàng năm là 3 lần, phép toán này trở nên không bền vững: đến năm thứ 3, chúng ta đang nói về 2,25 triệu USD mỗi năm. Nếu tính thêm chi phí đọc, chỉ mục và bảng toàn cầu, ở quy mô của Uber, chi phí đọc có thể ngang bằng với chi phí ghi.

Điều này có nghĩa là Uber đang đốt cháy 5 triệu USD cho một cái sổ cái khổng lồ.

Dựa trên dữ liệu của Uber, đến năm 2020, họ đã tích lũy 1,2 petabyte dữ liệu. Với mức giá 0,25 USD mỗi gigabyte, đó là 300.000 USD mỗi tháng. Cộng với chi phí ghi và lưu trữ, bạn đang nhìn vào một hóa đơn 8 triệu USD cho một hệ thống sổ cái vốn dĩ không cần phải tồn tại trên DynamoDB.

Thảm họa được ngụy tạo thành Case Study

Vậy bạn làm gì với một hóa đơn 8 triệu USD? Bạn biến nó thành một nghiên cứu điển hình (case study).

Kể từ năm 2020, Uber đã di chuyển dữ liệu từ DynamoDB sang hệ thống sổ cái nội bộ của họ, gọi là LSG (Ledger Store), được xây dựng trên cơ sở dữ liệu phân tán nội bộ DocStore của họ.

Tại sao không sử dụng giải pháp thay thế mã nguồn mở? Vì Uber thích tự xây dựng (in-house). Đó là cách Uber làm việc.

Bạn có thể lập luận rằng DocStore cung cấp các tính năng họ cần theo cách mà không có giải pháp nào khác làm được. Nhưng bạn đã sai! DocStore nội bộ của họ là một sự phù hợp hoàn hảo cho các yêu cầu cơ sở dữ liệu, ngoại trừ tính năng Change Data Capture (CDC). Họ đã phải xây dựng một khung truyền phát (streaming framework) có tên là "Flux" để hoàn tất việc di chuyển.

Vì vậy, để tôi hiểu đúng: DynamoDB là một lựa chọn tồi vì nó đắt đỏ, một điều mà bạn có thể tính toán trước được. Sau đó, bạn quyết định chuyển mọi thứ sang một kho dữ liệu nội bộ được xây dựng cho mục đích khác, vốn đã có sẵn khi bạn quyết định xây dựng trên DynamoDB. Và kho dữ liệu nội bộ đó không đủ tốt trên chính nó, nên bạn phải xây dựng thêm một khung truyền phát để hoàn tất việc di chuyển.

Và không ai bị sa thải vì chuyện này?

Nhưng thực tế là không ai đang tối ưu hóa cho chi phí. Họ đang tối ưu hóa cho lần thăng chức tiếp theo của mình. Mỗi lần viết lại là một đề xuất mới, một tài liệu thiết kế mới, một hệ thống mới để đưa vào hồ sơ năng lực. Động lực không bao giờ là chọn lựa chọn nhàm chán nhưng đúng đắn — mà là chọn cái phức tạp và ấn tượng.

Điều này làm phiền tôi nhất là: vào năm 2019, thật đau đớn khi rõ ràng Uber đã đưa ra một quyết định tồi tệ khi xây dựng LedgerStore trên DynamoDB.

Và yet, khi AWS mời Uber trình bày tại re:Invent 2019, họ đã nói có.

Khi bạn chủ động ngụy tạo một quyết định tồi tệ thành một nghiên cứu điển hình cho một công nghệ cơ sở dữ liệu, bạn không khác gì một người quản lý quỹ đầu cơ nói chuyện về cuốn sách của họ trên TV.

Đó là bản chất công nghệ của một kẻ đốt nhà viết hướng dẫn an toàn cháy nổ.

Uber không mắc sai lầm về sổ cái. Họ đã thiết lập những động lực sai lệch.

Và họ đã trả hàng triệu USD cho điều đó.