Amazon là một khối monolith, cho tới năm 2001
Amazon tách monolith thành microservices từ năm 2001 vì quá nhiều team dùng chung một khối. Prime Video gộp lại năm 2023 vì chỉ có một team.
Mình thấy một tấm ảnh chụp một chuyên gia đang trình bày trước hội trường, dáng rất đạo mạo. Trên màn chiếu sau lưng người đó là hai dòng chữ:
Mình cắt ảnh còn đúng phần màn chiếu, và sẽ không nói người đó là ai. Mình cũng không biết slide trước và slide sau tấm đó nói gì, nên không biết người trình bày đã dẫn khán giả tới kết luận nào. Thứ mình có chỉ là hai dòng chữ đó, và một câu hỏi: câu đó đúng hay sai?
Câu trả lời ngắn là đúng, nhưng chỉ tới khoảng năm 2001. CTO của Amazon đã kể chuyện này trong một cuộc phỏng vấn năm 2006. Slide không ghi năm, cũng không ghi lúc đó có bao nhiêu team cùng phải sửa cái khối ấy, và theo mình con số thứ hai quan trọng hơn.
1998 tới 2001: monolith thật
Tài liệu cũ nhất mình tìm được là một bản nội bộ tên "Distributed Computing Manifesto", ghi ngày tạo 24/5/1998. Werner Vogels, CTO của Amazon, công bố toàn văn nó vào tháng 11/2022, 24 năm sau [1]. Ngay đoạn đầu, nhóm kỹ sư viết thẳng lý do họ phải đổi kiến trúc: Amazon cần một kiến trúc mới nếu muốn chịu được gấp 10 lần lượng đơn hàng lúc đó. Ở đoạn thứ hai, họ chỉ ra vấn đề: các ứng dụng truy cập thẳng vào database, và cấu trúc data model nằm cứng trong code của từng ứng dụng.
Vì mọi ứng dụng đọc thẳng cùng một data model, nên "data model changes have to be accompanied by application changes even if functionality remains the same": đổi một cột là phải sửa mọi ứng dụng đang đọc cột đó, kể cả khi không ai thêm tính năng gì.
Manifesto mới là bản đề xuất. Năm 2006, Jim Gray phỏng vấn Vogels cho ACM Queue, và Vogels kể rằng Amazon.com khởi đầu là một ứng dụng monolith tên Obidos, chứa mọi business logic lẫn display logic, và tình trạng đó kéo dài "until 2001 when it became clear that the front-end application couldn't scale anymore" [2].
Vậy slide đó đúng với Amazon từ lúc ra đời tới khoảng năm 2001, tức 25 năm trước.
Cái giá của một khối monolith tăng theo số team
Trong cuộc phỏng vấn đó, Jim Gray hỏi lại ngay: "Was that performance scalability, or was it manageability, or facilities?" Tức là cái khối đó chết vì chạy chậm, vì khó quản lý, hay vì hết chỗ đặt máy?
Vogels trả lời bằng chuyện ai sở hữu cái gì. Những phần cần scale riêng lại phải dùng chung tài nguyên với code không ai nắm rõ, "there was no isolation and, as a result, no clear ownership", và cả front-end lẫn back-end đều bị kìm lại vì được "shared by many different teams". Trang giới thiệu two-pizza team của AWS sau này viết gọn hơn: "Our tightly coupled architecture and organization were simply not helping us move as fast as we wanted, or needed, to be" [3].
Giả sử mỗi team, trong mỗi lần release, có 95% khả năng thay đổi của mình không làm hỏng gì. Nếu \(N\) team cùng đưa thay đổi vào một khối và release chung, thì lần release đó chỉ sạch khi cả \(N\) team cùng không làm hỏng:
\[P_{\mathrm{release}} = 0{,}95^{N}\]
| Số team chung một lần release | Xác suất cả lần release sạch |
|---|---|
| 1 | 95% |
| 3 | 85,7% |
| 10 | 59,9% |
| 30 | 21,5% |
| 100 | 0,6% |
Với 3 team, gần 9 trên 10 lần release vẫn trơn tru; với 100 team, gần như lần nào cũng có một team làm hỏng và 99 team kia phải chờ.
Đó là "no isolation" mà Vogels nói. Cách chữa của Amazon là cắt khối đó ra để mỗi team release riêng, nghĩa là đưa \(N\) về 1 cho từng team, và giữ mỗi team đủ nhỏ, "ideally, this is a team of less than 10 people" [3].
2007: một trang gọi hơn 150 service
Cũng trong bài phỏng vấn năm 2006, Vogels mô tả Amazon sau khi tách: mỗi service giữ dữ liệu của riêng nó, không ai được truy cập thẳng vào database của service khác, và khi bạn mở trang chủ Amazon.com, "the application calls more than 100 services to collect data and construct the page for you" [2]. Một năm sau, paper Dynamo ở hội nghị SOSP 2007 ghi một con số lớn hơn: một page request thường gọi hơn 150 service [4].
Áp cùng phép nhân đó cho lời gọi service: giả sử mỗi service trả lời được 99,9% số lần, và trang chỉ hiển thị khi đủ cả 150 service trả lời:
\[P_{\mathrm{page}} = 0{,}999^{150} \approx 0{,}861\]
Tức là cứ khoảng 7 lần tải trang thì 1 lần hỏng. Khi Amazon tách khối monolith ra, phép nhân dời từ lúc deploy sang lúc chạy: trước kia 100 team phải cùng không làm hỏng một lần release, giờ 150 service phải cùng trả lời một request.
Paper Dynamo kể một việc Amazon phải làm để trang vẫn chạy khi một phần hệ thống hỏng: dịch vụ giỏ hàng phải luôn đọc và ghi được, để khách vẫn thêm được hàng vào giỏ "even if disks are failing, network routes are flapping, or data centers are being destroyed by tornados", và Dynamo là hệ lưu trữ họ tự viết cho đúng yêu cầu đó [4].
Tháng 10/2019, AWS thông báo mảng Consumer của Amazon đã tắt database Oracle cuối cùng, sau khi chuyển 75 PB dữ liệu từ gần 7.500 database, với hơn 100 team tham gia, mỗi team tự chọn loại database hợp với mình [5].
Amazon chịu được những chi phí đó vì họ có hàng trăm team: tách ra thì không team nào phải chờ team khác để release.
2023: Prime Video gộp lại vì chỉ có một team
Tháng 3/2023, blog kỹ thuật của Prime Video đăng một bài của Marcin Kolny, kể về một công cụ giám sát chất lượng từng luồng video mà khách đang xem [6]. Phiên bản đầu được dựng theo kiểu serverless: AWS Step Functions điều phối, mỗi detector chạy thành một microservice riêng trên Lambda, còn các frame video được cắt ra và gửi qua lại giữa các thành phần bằng một bucket S3. Hệ thống đó chỉ chịu được khoảng 5% tải dự kiến, vì mỗi giây của mỗi luồng video tạo ra nhiều lần chuyển trạng thái trong Step Functions, và Step Functions tính tiền theo từng lần chuyển trạng thái. Việc đẩy từng frame lên S3 rồi kéo về cũng đắt.
Họ gộp tất cả vào một process. Chi phí hạ tầng giảm hơn 90%.
Tháng 5/2023, bài Prime Video lan đi với những tiêu đề kiểu "chuyển từ microservices sang monolith giảm 90% chi phí" [7], và không ít bài viết, cả tiếng Anh lẫn tiếng Việt, kể lại nó thành "Amazon bỏ microservices để quay về monolith". Bài gốc thì kể ngay từ đầu rằng công cụ này thuộc về một team duy nhất, team Video Quality Analysis.
Với phép nhân ở khâu release, \(N = 1\): chỉ có một team, nên tách công cụ thành nhiều service không giúp ai đỡ phải chờ ai. Còn ở khâu chạy, họ vẫn trả tiền cho từng lần chuyển trạng thái và từng frame đi qua S3. Bài viết của họ nói gọn: "distributed approach wasn't bringing a lot of benefits in our specific use case".
Khi số detector vượt sức một máy, team Prime Video nhân bản cả process ra nhiều bản, mỗi bản chạy một nhóm detector, rồi thêm một lớp điều phối nhẹ để chia request. Nên "monolith" ở đây vẫn chạy trên nhiều instance ECS, chỉ không còn tách từng thành phần qua mạng nữa.
Vậy là giờ monolith mới đúng, microservices là một trào lưu đã qua
Ngay trong tuần bài Prime Video lan đi, chính Vogels viết một bài tên "Monoliths are not dinosaurs" [8]. Bài đó không bênh phe nào, và câu Vogels nhấn mạnh là "there is not one architectural pattern to rule them all". Ví dụ đi ngay sau câu đó xoay quanh số team: một startup 5 kỹ sư có thể chọn monolith, và nhu cầu của họ "fundamentally different" so với một doanh nghiệp có hàng chục team kỹ sư. Amazon năm 2001 và Prime Video năm 2023 chỉ khác nhau ở \(N\).
Đào sâu: bản memo không công khai
Nếu bạn đi nghe đủ nhiều talk về microservices, sớm muộn gì cũng gặp "Bezos API mandate": một bản memo khoảng năm 2002, trong đó Jeff Bezos ra lệnh mọi team phải giao tiếp qua service interface, ai không làm sẽ bị đuổi việc. Nhiều người trích nó như trích một tài liệu gốc.
Bản memo đó không công khai. Nguồn duy nhất của câu chuyện là một bài viết dài của Steve Yegge, người từng làm ở Amazon rồi chuyển sang Google, đăng ngày 12/10/2011 trên Google+ [9]. Bài đó vốn chỉ định cho đồng nghiệp ở Google đọc, và Yegge lỡ tay để ở chế độ công khai. Chính Yegge cũng rào trước rằng mandate có từ "back around 2002 I think, plus or minus a year", và nội dung của nó "went something along these lines".
Câu chuyện đó có thể đúng. Tinh thần của nó khớp với những gì Vogels mô tả năm 2006: không ai được truy cập thẳng vào database của service khác. Nhưng cái danh sách mà nhiều slide trích như nguyên văn thực ra là lời một người kể lại theo trí nhớ 9 năm sau, và chính người đó ghi chú "cộng trừ một năm".
Viết lại slide đó
Nếu được sửa slide đó, mình không bỏ chữ nào. Mình chỉ thêm vào hai thứ:
Vì sao?
Amazon (trước 2001) = Một khối monolith khổng lồ, mọi thứ kết nối chằng chịt với nhau, và rất nhiều team cùng phải thay đổi nó một lúc
Mình vẫn không biết người trình bày đã nói gì sau slide đó. Có thể họ kể đúng câu chuyện này, đủ năm, đủ lý do, và chỉ tấm ảnh là thiếu. Có thể họ dùng nó để khuyên một phòng đầy những team 5 người hãy tách hệ thống ra thành microservices.
Lần tới khi ngồi dưới hội trường và nghe ai đó nói "Amazon đã làm thế này", bạn có thể hỏi lại hai câu: năm nào, và lúc đó bao nhiêu team cùng phải thay đổi thứ đó? Nếu câu trả lời cho câu thứ hai là "một", thì ví dụ gần với bạn nhất có lẽ là một team nhỏ ở Prime Video năm 2023.
Còn nếu bạn thấy mình đọc sai chỗ nào trong các tài liệu ở trên, mình rất muốn được cãi lại.
Bình
Phụ lục: Citations (9)
- Werner Vogels (công bố); nhóm kỹ sư senior của Amazon (tác giả gốc). The Distributed Computing Manifesto. All Things Distributed. 2022-11-16. Tài liệu nội bộ Amazon tạo ngày 24/5/1998, sửa ngày 10/7/1998. Lý do đổi kiến trúc: chịu được gấp 10 lần lượng đơn hàng; ứng dụng dính chặt vào data model.
- Jim Gray, Werner Vogels. A Conversation with Werner Vogels: Learning from the Amazon technology platform. ACM Queue, Vol. 4, No. 4. 2006-05. Amazon.com khởi đầu là một ứng dụng monolith (Obidos) 'to hold all the business logic, all the display logic', tới 2001 thì front-end hết scale nổi; 'no isolation and, as a result, no clear ownership'; trang chủ gọi hơn 100 service.
- Amazon's Two Pizza Teams. AWS Executive Insights. Our tightly coupled architecture and organization were simply not helping us move as fast as we wanted, or needed, to be. Không ghi ngày đăng.
- Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, Werner Vogels. Dynamo: Amazon's Highly Available Key-value Store. SOSP 2007. 2007-10. Một page request thường gọi hơn 150 service; SLA về độ trễ đo ở 99.9th percentile; data store của service chỉ truy cập được trong ranh giới service đó.
- Jeff Barr. Migration Complete - Amazon's Consumer Business Just Turned off its Final Oracle Database. AWS News Blog. 2019-10-15. 75 PB dữ liệu trong gần 7.500 database Oracle; hơn 100 team của mảng Consumer tham gia.
- Marcin Kolny. Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%. Prime Video Tech (primevideotech.com, đã gỡ). 2023-03-22. URL gốc primevideotech.com giờ redirect 301 về aboutamazon.com. Bản dùng ở đây là bản in PDF lưu ngày 8/5/2023. Team VQA sở hữu công cụ; gộp về một process, chi phí hạ tầng giảm hơn 90%.
- Reduce costs by 90% by moving from microservices to monolith: Amazon internal case study raises eyebrows. DevClass. 2023-05-05. Một trong các bài báo lan truyền case Prime Video tháng 5/2023.
- Werner Vogels. Monoliths are not dinosaurs. All Things Distributed. 2023-05-05. there is not one architectural pattern to rule them all; startup năm kỹ sư khác doanh nghiệp có hàng chục team.
- Steve Yegge. Stevey's Google Platforms Rant. Google+ (bản lưu của UW CSE 452). 2011-10-12. Nguồn duy nhất của 'Bezos API mandate'. Yegge ghi: 'back around 2002 I think, plus or minus a year' và 'something along these lines'.