- AWS đã báo cáo sự cố vận hành từ tối thứ Năm, với một trục trặc liên quan đến tình trạng quá nhiệt tại trung tâm dữ liệu ở khu vực US-East-1 Bắc Virginia, ảnh hưởng đến các nền tảng giao dịch như Coinbase và FanDuel
- Trong cập nhật lúc 3:29 chiều thứ Sáu (ET), AWS cho biết việc khôi phục hoàn toàn vẫn được dự kiến sẽ mất thêm vài giờ, và tiến độ khôi phục chậm hơn so với ước tính trước đó
- AWS giải thích rằng sự cố xảy ra tại một Availability Zone duy nhất trong khu vực đó, và họ đang đưa thêm công suất hệ thống làm mát vào hoạt động để khôi phục phần cứng còn lại
- FanDuel cho biết sau khi điều tra các khó khăn kỹ thuật khiến người dùng không thể truy cập nền tảng, họ xác định vấn đề có liên quan đến sự cố AWS trên diện rộng; người dùng phàn nàn rằng họ bị thua cược do không thể cash out
- Coinbase cho biết sự cố tại nhiều khu vực AWS đã gây ra gián đoạn kéo dài cho các dịch vụ giao dịch cốt lõi, và đăng rằng các vấn đề chính đã được giải quyết hoàn toàn
Tiến trình khôi phục
- Trong bản cập nhật lúc 9:51 sáng thứ Sáu (ET), AWS cho biết: “Chúng tôi đang tích cực làm việc để đưa thêm công suất hệ thống làm mát vào hoạt động, điều này sẽ cho phép chúng tôi khôi phục phần cứng còn lại trong khu vực bị ảnh hưởng”
- AWS đang xử lý sự cố của các instance EC2 cung cấp năng lực máy chủ ảo
- Bảng điều khiển AWS Health lần đầu đăng lúc 8:25 tối thứ Năm (ET) rằng họ đang “điều tra sự cố instance”
- AWS không đưa ra thêm bình luận
Ảnh hưởng theo từng dịch vụ
- FanDuel cho biết trên X lúc 9 giờ tối thứ Năm (ET) rằng họ đã nhận thức được các khó khăn kỹ thuật hiện tại khiến người dùng không thể truy cập nền tảng và đang điều tra
- Khoảng 2 giờ sau, FanDuel cập nhật rằng vấn đề có liên quan đến sự cố AWS trên diện rộng
- Người dùng FanDuel phàn nàn rằng họ bị thua cược vì không thể cash out trên nền tảng
- Coinbase cũng đăng trên X vào thứ Sáu rằng sự cố tại nhiều khu vực AWS đã gây ra “gián đoạn kéo dài cho các dịch vụ giao dịch cốt lõi”
- Coinbase cho biết trong bài đăng đó rằng các vấn đề chính đã được giải quyết hoàn toàn
Bối cảnh thị trường đám mây
- AWS chiếm khoảng một phần ba thị trường công nghệ hạ tầng đám mây
- AWS cung cấp dịch vụ cho hàng triệu công ty
1 bình luận
Ý kiến trên Hacker News
AWS US-East 1 vẫn là gót chân Achilles của Internet
Có thể triển khai trên nhiều region và availability zone, nhưng AWS đã nhiều lần lặp lại các sự cố mà vấn đề ở US-East 1 gây ảnh hưởng rộng hơn, khiến mức độ dư thừa và khả năng phục hồi không cao như AWS ngụ ý
Mọi dịch vụ định danh và truy cập của public cloud ngoài Trung Quốc, tức thứ mà nhân viên gọi là “IAM cho partition aws”, đều được tập trung ở us-east-1. Muốn nhìn tài khoản, thanh toán và quyền hạn một cách nhất quán thì trên thực tế gần như cần kiểu tập trung này
IAM cũng không phải một software stack hoàn toàn độc lập mà phụ thuộc vào một số dịch vụ như DynamoDB, còn các dịch vụ đó lại phụ thuộc vòng vào IAM
Trong lúc us-east-1 gặp sự cố thì đôi khi vẫn có thể tiếp tục dùng token hoặc session xác thực cũ ở region khác, nhưng có thể không cấp được token mới. Tôi còn nhớ thời trước khi làm việc có lần người trực on-call được dặn đừng đóng SSH session hay tab trình duyệt AWS console vì có thể bị khóa ngoài cho tới khi sự cố kết thúc
Trong 3 năm qua tôi gần như vận hành startup trên use-1, và chỉ gặp đúng một lần region outage, mà đó cũng chỉ là outage một phần nên đa số instance không bị ảnh hưởng
Thành thật mà nói, vì hệ thống của khách hàng cũng đều ở use-1 nên việc outage có tương quan với phía khách hàng cũng là một lợi thế
Trong xứ sở phép màu tưởng tượng, tải được phân tán đều giữa nhiều nhà cung cấp cloud, và không tồn tại điểm lỗi đơn
Mối tình đầu cũng có kết đẹp, cặp song sinh thì giỏi cả tiếng Anh lẫn tiếng Hàn, và ai cũng biết không nên phụ thuộc vào duy nhất AWS khi triển khai dịch vụ quy mô lớn
Chi phí y tế ở Mỹ cũng ở mức có thể chi trả được. Nhưng thực tế là lại thêm một ngày nữa trôi qua, và chỉ riêng AWS US-East 1 cũng có thể quật ngã phần lớn Internet
2 region thì cần dung lượng gấp đôi, 3 region thì cần chuẩn bị 1,5 lần dung lượng, và trong cấu hình multi-region thì máy phải được chạy sẵn. Không nên mong có thể bật instance hay giành được dung lượng trong lúc đang outage, và cũng phải gánh thêm độ phức tạp của multi-region hosting
Việc cấu hình nhiều region/availability zone trông lộ liễu như lớp sơn bề ngoài vậy mà mọi người vẫn cùng nhau tin như một tín điều của tôn giáo cloud thì cũng hơi buồn cười
Những vụ cá cược kiểu này rất nguy hiểm. Vì những người như nhân viên có thể làm AWS sập cũng có thể đặt cược
Những vụ cược này không vô hại như vẻ ngoài của chúng, vì người đặt cược thường có thể ảnh hưởng hoặc thay đổi kết quả
Nói chung tôi đồng ý với lập luận rằng các thị trường dự đoán như vậy có thể khuyến khích giao dịch nội gián và các kịch bản tiêu cực. Chúng tạo ra động cơ kiếm lời bằng cách lợi dụng tình huống đó
Tôi cứ nghĩ làm mát trong data center gần như luôn được tính toán trước và họ sẽ không lắp nhiều hơn mức có thể làm mát
Ở đây tôi tò mò không biết là thiết bị làm mát bị hỏng, có nguyên nhân bên ngoài gây quá nhiệt, hay là Amazon đã overbook công suất làm mát của data center
Họ không nói rõ nguyên nhân chi tiết, nhưng có vẻ đường ống giữa mỗi tầng và mái nhà không được dự phòng hóa, và việc sửa chữa mất gần 24 giờ
Việc làm mát data center, cũng như mọi thứ khác, vừa tồn tại over-provisioning vừa tồn tại under-provisioning
Thiết bị trao đổi nhiệt lớn thường theo cấu hình N+1, còn ở các cơ sở nhỏ có tải rất quan trọng thì là 2N/3N, nên đó là over-provisioning. Vì chúng phải được tắt định kỳ để bảo trì, có tỷ lệ hỏng cao hơn các thành phần data center truyền thống, và cần sửa chữa cơ khí đòi hỏi nhân lực chuyên môn cùng thời gian cung ứng dài
Ở cơ sở lớn, khi N càng lớn thì hệ thống làm mát đạt N+3 trở lên cũng không hiếm. Lúc nào đó cũng có thứ đang được bảo trì, hoặc có thiết bị phải chờ linh kiện vì linh kiện đó không còn được sản xuất và phải chế lại thủ công trên kệ, rẻ hơn thay cả hệ thống
Mặt khác, nếu toàn bộ năng lực tính toán của cơ sở đột ngột tăng từ mức tiêu thụ điện trung bình lên 100% thì sẽ vượt quá công suất làm mát, nên nó cũng là under-provisioning. Điện và các tuyến khác cũng thường bị quá tải, và bản chất ngành này gần như là bán vượt mức
Bình thường đây không phải vấn đề lớn. Tải tính toán hiếm khi tăng vọt lên 100% toàn công suất, và dù có tăng vọt cũng không kéo dài, hơn nữa không ai xây dựng cơ sở mà đặt công suất làm mát hay điện ngay sát lằn ranh
Vấn đề xuất hiện khi nhiều sự kiện giao nhau. Hệ thống làm mát được thiết kế để xử lý 200% tải trung bình nhằm chừa đủ dư địa cho bảo trì và sự cố
Vào thứ Ba, kỹ thuật viên đến kiểm tra một thiết bị thì phát hiện ổ bi lỗi, phải lấy linh kiện từ bang khác nên để tránh rủi ro phá hỏng cụm quạt, họ tắt thiết bị đó qua đêm
Hai thiết bị làm mát bên cạnh phải làm việc mạnh hơn một chút, rồi một cái trong số đó có động cơ hơi lệch hoặc cầu chì bị lỏng nên nóng lên, và linh kiện đã cầm cự nhiều năm cuối cùng nổ vì mức hoạt động tăng lên
Giờ thì ở cơ sở N+2 đã mất hai thiết bị, nhưng vì thiết kế cho 200% tải trung bình nên vẫn chưa chí mạng
Nếu thiết bị thứ ba ở phía đối diện thiết bị hỏng đầu tiên cũng bung lỗi dưới tải cao hơn thì cơ sở N+2 mất ba thiết bị. Dù vậy, vì vẫn được thiết kế cho 200% tải trung bình nên vẫn chưa phải thảm họa lớn
Nhưng lúc đó là 4 giờ sáng nên nhân viên vận hành tại chỗ không thể sửa lỗi này, còn nhà cung cấp phải tới 7 giờ mới thức dậy và 9 giờ mới tới nơi. Trong lúc đó tải bắt đầu tăng
Chuyện như vậy diễn ra mỗi ngày ở một data center nào đó tại Mỹ, và có lẽ ở mọi data center thì mỗi năm cũng xảy ra cỡ một lần
Phần biến thành tin tức là khi nó gặp thêm một sự kiện tiếp theo. Một khách hàng lớn quyết định đây là thời điểm thích hợp để bắt đầu một batch job quy mô lớn. Một công ty fintech chạy mô hình lớn trước giờ mở cửa thị trường, hoặc một công ty dầu khí chạy phân tích nhanh cho mỏ mới
Họ bật thêm 10.000 VM. Bình thường thì ổn vì vẫn còn công suất dư
Nhưng hệ thống làm mát chỉ được lên kế hoạch cho 200% công suất làm mát trung bình, còn node lần này không phải node bận vừa phải mà là node chạy tính toán số cường độ cao được tối ưu hóa, kéo điện tối đa và xả nhiệt tối đa
Không chỉ tải theo tổng số máy tăng mà tác động nhiệt thải trung bình cũng lớn hơn. Thế là sự cố dây chuyền nổ ra và hệ thống làm mát thành N-4
Quạt server bắt đầu quay nhanh hơn nên tiêu thụ nhiều điện hơn, và hệ thống làm mát thành N-5. Cảnh báo reo khắp nơi
Cơ chế an toàn của các thiết bị làm mát lần lượt kích hoạt do tải và áp suất môi chất lạnh tăng lên, khiến hệ thống làm mát thành N-6, N-7, rồi về 0
Tôi tò mò không biết trong năm nay ở EU, Hetzner có uptime tốt hơn AWS không
Tôi thấy UI của Hetzner quá rối, khó quản lý
Bài liên quan: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
Lúc nào cũng là East 1. Bỏ chuyện đùa sang một bên, tôi không hiểu vì sao east-1 lại sập thường xuyên hơn hẳn các region khác
Về mặt kiến trúc thì có vẻ nó phải khá giống các region khác chứ
Tải ở đó lớn hơn các region khác, và khi xây dựng ban đầu họ ít kinh nghiệm hơn nên có lẽ cũng có nhiều technical debt và nợ về kiến trúc/kỹ thuật hơn
Theo tôi nhớ thì cũng có những dịch vụ phụ thuộc vào east-1 như một điểm lỗi đơn, ví dụ IAM hoặc một số cấu hình S3
Coinbase nói nhiều availability zone đã sập, nhưng thông báo của AWS lại nói chỉ có một availability zone duy nhất bị ảnh hưởng
Tôi tò mò không biết có ai hiểu rõ hơn không
Tôi đang chạy hệ thống ở us-east-1, và trong lúc sự cố diễn ra tôi thấy các vấn đề kết nối gián đoạn khó giải thích, chưa từng gặp trước đây, ngay cả bên ngoài az4
Chỉ có EBS volume của một availability zone bị xấu đi một chút ở vài môi trường, và rõ ràng đó là vấn đề của một availability zone duy nhất (use-az4)
Lần trước tôi thấy câu “nếu là bạn thì bạn sẽ không để bạn mình dùng USE1”, và khi Slack hiện thông báo rằng USE1 cùng tất cả những gì triển khai ở đó đều chết sạch thì tôi lại nhớ tới câu này
Trong phần bình luận ở đây có nhiều ý quen thuộc rằng us-east-1 bị tập trung hóa, là điểm lỗi đơn của AWS, cần phải sửa và không nên triển khai ở đó
Nhưng lần này là vấn đề của một data center trong một zone thuộc một region đa zone
IAM/R53 v.v. đúng là được tập trung ở đó, và việc chuyển các dịch vụ ấy sang kiến trúc phi tập trung, liên region là điều tốt. Nhưng bản thân us-east-1 đã là region nhiều zone với 6 zone, và zone thứ 7 dự kiến vào năm 2026, trong mỗi zone lại còn có nhiều data center
Theo tôi nhớ, khi các dịch vụ toàn cục như IAM bị sập thì thường không phải kiểu “nếu là cross-region thì đã không chết”, mà là lỗi triển khai hoặc lỗi phụ thuộc
Lần này không phải outage của dịch vụ toàn cục AWS. Thứ có vẻ bị ảnh hưởng lớn hơn có lẽ là MSK, mà điều đó có khả năng là vấn đề phía Kafka hơn là vấn đề AWS
Tôi thắc mắc vì sao người ta không xây những thứ này gần biển. Các cơ sở cần nhiều công suất làm mát như nhà máy điện hạt nhân cũng thường làm vậy mà
Có vẻ chỉ cần dùng tuần hoàn 2 vòng với bộ trao đổi nhiệt để tản nhiệt là được
Vào thập niên 1990, khoảng một nửa lưu lượng Internet toàn cầu đi qua MAE-East, và kết quả là AWS đặt region đầu tiên ở đó. us-east-1 ra mắt sớm hơn eu-west-1 2 năm và sớm hơn us-west-1 3 năm
Khi ngày càng có nhiều người biết xây data center và nhiều nhà cung cấp có thể hỗ trợ, Dulles Corridor đã trở thành trung tâm lớn của data center thuộc nhiều công ty
Trong AWS, us-east-1 là region đầu tiên nên áp đảo về mức độ phức tạp và kỳ quặc, và nhiều control plane của các dịch vụ AWS khác phụ thuộc vào đây. Vì vậy nó sập thường xuyên hơn các region khác, và mỗi khi sập thì thành tin tức toàn quốc, khác với eu-south-2 ở Tây Ban Nha
NoVA chỉ là một ví dụ của data center chứ không phải nhà máy, nhưng vẫn là cùng loại cụm kinh tế như chủ đề nghiên cứu từng giúp Paul Krugman nhận giải Nobel Kinh tế
Một lần là data center SOMA của Hosting.com nóng đến mức họ phải xịt nước từ trên mái xuống để làm mát, và lần khác là data center Chai Wan của Alibaba nóng tới mức mọi thứ chạy ở đó, bao gồm cả control plane, đều sập
Vì thế tôi không nghĩ việc ở gần biển mang lại lợi ích bổ sung về tản nhiệt khẩn cấp. Khả năng thải nhiệt ra ngoài là hữu hạn, và dù ở ven biển hay giữa Nebraska thì toàn bộ hệ thống vẫn phải được thiết kế để đáp ứng một mức hiệu năng nhất định
Trên slide có các yếu tố ảnh hưởng tới quyết định chọn địa điểm data center, trong đó có nhiều mục liên quan đến việc tìm đủ không gian và nguồn nhân lực lành nghề để vận hành data center đó. Ông cũng nói đôi khi yếu tố chính trị can thiệp vào việc chọn vị trí data center tiếp theo
Đất ven biển đắt hơn nhiều, còn nếu ra vùng bờ biển xa xôi thì khả năng tiếp cận điện có thể không tốt
Các địa điểm ven biển cũng thường hứng chịu thời tiết cực đoan nặng hơn
Còn có những chuyện khó lường nữa. Nhà máy điện hạt nhân Diablo Canyon từng gặp vấn đề đường lấy nước làm mát bằng nước biển bị tắc vì mảnh vụn và dòng sứa di chuyển
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
Nước cũng phải đủ sâu, nếu không thì nó sẽ nóng lên tới nhiệt độ bề mặt. Ngoài ra cách này còn phải cạnh tranh được về giá với làm mát bay hơi truyền thống
Ví dụ kinh điển trong sách giáo khoa về cách làm này hoạt động tốt là Toronto. Ở đó có một hồ nước ngọt sâu tương đối gần bờ, còn khu trung tâm thì bất động sản đắt đỏ nên cách truyền thống bị hạn chế
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System