- Sự cố của AWS, dịch vụ đám mây lớn nhất thế giới, đã khiến hàng nghìn trang web và ứng dụng dừng hoạt động, đồng thời đưa ra cảnh báo rằng hạ tầng internet đang phụ thuộc quá mức vào một số ít doanh nghiệp
- Các dịch vụ lớn như Snapchat, Roblox, Signal, Duolingo cùng các tổ chức công cộng và tài chính như Lloyds Bank, Ring, HMRC cũng nằm trong phạm vi bị ảnh hưởng
- AWS quy nguyên nhân là lỗi hệ thống nội bộ tại khu vực US-East (miền Đông Hoa Kỳ), loại trừ khả năng tấn công mạng và đã khôi phục phần lớn dịch vụ chỉ trong vài giờ
- Các chuyên gia cho rằng, “diễn ngôn dân chủ và nền tảng báo chí độc lập không nên bị phụ thuộc vào cơ sở hạ tầng của một số doanh nghiệp”, và nhấn mạnh nhu cầu đa dạng hóa cơ sở hạ tầng đám mây
- Cấu trúc tập trung quanh các tập đoàn đám mây lớn đã bộc lộ sự mong manh của internet toàn cầu và châm ngòi cho cuộc thảo luận về chủ quyền công nghệ của hạ tầng công cộng
Tổng quan sự cố
- Sự cố quy mô lớn của các dịch vụ toàn cầu xảy ra do lỗi nội bộ tại AWS US-East-1 (khu vực Đông Hoa Kỳ)
- Sự cố bắt đầu khoảng 8 giờ sáng thứ hai theo giờ địa phương (16h theo giờ Anh)
- Amazon thông báo tỷ lệ lỗi API và độ trễ (latency) tăng lên
- Theo Downdetector, hơn 2.000 công ty trên toàn cầu bị ảnh hưởng, với hơn 1,9 triệu người Mỹ, 1 triệu người Anh và 410.000 người Úc báo cáo sự cố
- AWS chỉ ra sự cố ở tiểu hệ thống giám sát bộ cân bằng tải nội bộ là nguyên nhân và xác nhận không phải tấn công mạng
- Một lỗi liên quan đến DynamoDB của AWS khiến phản hồi API thất bại
- AWS tạm thời áp dụng giới hạn số lượng yêu cầu để ngăn chặn tình trạng bùng nổ lưu lượng truy cập
- AWS chính thức công bố đã khôi phục vận hành bình thường vào buổi tối, nhưng một số dịch vụ vẫn nhận được báo cáo gián đoạn liên tục
Phạm vi ảnh hưởng
- Các dịch vụ chính: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton và nhiều nền tảng khác
- Tại Anh, có sự gián đoạn khi truy cập các dịch vụ tài chính như Lloyds, Halifax, Bank of Scotland và cả website của HMRC (Tổng cục Thuế Anh)
- Người dùng Ring Doorbell than phiền dịch vụ giám sát mở cửa đã bị gián đoạn
- Các nền tảng toàn cầu như Epic Games, Pokémon Go, Wordle cũng ghi nhận không thể truy cập
Phân tích chuyên gia
- Dr. Corinne Cath-Speth (Article 19): “Việc nền tảng của diễn ngôn dân chủ và báo chí độc lập phụ thuộc vào cơ sở hạ tầng của một số ít doanh nghiệp là rất rủi ro. Việc đa dạng hóa đám mây là cấp thiết”
- Cori Crider (Future of Technology Institute): “Anh cần thoát khỏi sự phụ thuộc vào các công ty công nghệ lớn của Hoa Kỳ. Đây là ví dụ điển hình khi sự cố tại một chỗ của AWS khiến toàn bộ nền kinh tế hiện đại gần như tê liệt”
- Madeline Carr (UCL): “Nhờ năng lực vốn của các công ty đám mây lớn, an ninh và khả năng mở rộng vẫn được duy trì, nhưng một cấu trúc gắn cả thế giới vào cùng một rủi ro là cực kỳ nguy hiểm”
- Steven Murdoch (UCL): “Rất có thể nguyên nhân là do sai sót vận hành nội bộ của AWS chứ không phải tấn công mạng”
Phản ứng của chính phủ và quy định
- Chính phủ Anh cho biết đã kích hoạt cơ chế liên lạc khẩn cấp với AWS và theo dõi sát sao tình hình khôi phục
- Ủy ban Tài chính của Hạ viện Anh yêu cầu AWS phải được chỉ định là “bên thứ ba trọng yếu (critical third party)” trong lĩnh vực tài chính
- Khi được chỉ định, AWS sẽ thuộc phạm vi giám sát của cơ quan quản lý tài chính và có thể giúp đảm bảo ổn định hạ tầng tài chính
- Chủ tịch Meg Hillier phê phán rằng AWS đã tuyên bố rằng họ cung cấp “khả năng phục hồi”, nhưng trên thực tế lại bộc lộ sự dễ tổn thương
Bối cảnh và hàm ý
- AWS nắm hơn 30% thị phần đám mây toàn cầu và giữ vị trí dẫn đầu
- Cùng với Microsoft Azure và Google Cloud, AWS đang hình thành một cấu trúc độc quyền “ba nhà cung cấp đám mây lớn”
- Năm 2024, đã từng xảy ra sự cố màn hình xanh trên máy tính cá nhân Windows toàn cầu do lỗi phần mềm của CrowdStrike
- Vụ việc này lại làm nổi bật rủi ro hệ thống do sự tập trung hóa hạ tầng kỹ thuật số và thổi bùng thảo luận của các chính phủ về chủ quyền công nghệ và chiến lược phân tán đám mây
3 bình luận
Cố lên, Naver Cloud!
"Nếu không thích dùng cloud thì tự xây dựng và dùng đi" rồi thì còn có thể bàn luận gì nổi nữa nhỉ.
Multi-cloud à? Việc triển khai và vận hành thì cũng không có ai làm giúp bạn đâu.
Bình luận Hacker News
Đang có cuộc thảo luận về việc một số dịch vụ đang bị gián đoạn tại AWS us-east-1, và có một luồng thảo luận dài liên quan tại đây
Ngay cả khi sự cố Fastly năm 2021 xảy ra, những “chuyên gia” cũng đưa ra những phê phán tương tự nhưng trên thực tế không có thay đổi rõ ràng nào. Một tuần sau đó, các chủ đề kiểu này cũng vắng bóng trên báo. Người trong ngành biết vận hành ở quy mô AWS khó đến mức nào. Một biện pháp dự phòng thật sự cho tình huống này đòi hỏi chi phí khổng lồ, nên đối với đa số doanh nghiệp lợi ích của nó gần như không đáng kể. Nếu một dịch vụ thực sự “sống còn” thì đúng là nên thiết kế để phòng ngừa sự cố như vậy. Việc không thể đăng nhập được vào Fortnite cho thấy việc dự phòng như vậy không hề dễ trong thực tế và chi phí của nó như thế nào. Báo chí thường không nói nhiều về vai trò của multi-region hay multi-cloud trong ngày thường rồi khi có sự cố mới nhắc đến rồi nhanh chóng quên. Cuối cùng họ chỉ tò mò nguyên nhân kỹ thuật. Sự chỉ trích của các “chuyên gia” không đi kèm bước tiếp theo thì chẳng có nhiều ý nghĩa. Điều đáng nói hơn là phải có phân tích sau sự cố mang tính xây dựng và không đổ lỗi thay vì phê phán rồi thôi
Những “chuyên gia” ở đây là những người không có kinh nghiệm vận hành hạ tầng hay cloud thực tế. Ví dụ, Dr Corinne Cath-Speth là tiến sĩ nhân học, Cori Crider là luật sư, Madeline Carr là giảng viên ngành chính trị. Tức là họ là người viết nghiên cứu và cho phỏng vấn báo chí, chứ không vận hành dịch vụ hosting thực tế
Nếu đi tới bài học rằng phải chấp nhận downtime hơn 16 giờ mỗi năm thì có lẽ vì cách phê phán cloud lock-in như vậy. Một vài giờ bị ngừng hoạt động khiến người dùng cảm nhận rõ ngay, nhưng thực tế giảm hiệu năng trong 8,742 giờ còn lại có thể còn tai hại hơn. Nếu công ty nào mà có thể chết vì chỉ 16 giờ downtime, thì cả tôi và người đọc đều không hiểu kinh doanh của họ. Tôi quan tâm hơn tới high availability, địa lý dự phòng (geo-redundancy) và tính bền vững của hệ thống
Không cần thiết phải chi thêm chi phí khổng lồ. Không phải dịch vụ nào cũng phải chịu đựng mức đó. Nếu dùng các nhà cung cấp khác nhau, có thể tránh được việc tất cả đều bị ảnh hưởng cùng lúc
Việc redundancy multi-region/multi-cloud mà báo chí thường nêu thực tế lại hiệu quả thấp. Trông có vẻ chỉ một region bị ảnh hưởng, nhưng thực tế nhiều trường hợp dịch vụ chịu tác động trên nhiều region. Multi-cloud hot standby càng phức tạp thì càng đắt đỏ. Áp dụng sau khi đã vận hành mà không có kế hoạch ban đầu là cực kỳ khó
Có lẽ nên thử thay chữ “cloud” hay “internet” bằng “kho hàng ở Virginia”. Chẳng hạn “Dịch vụ của chúng tôi hoàn toàn nằm trong kho hàng ở Virginia”, “Mọi file của tôi đều ở kho hàng ở Virginia”, “Kho hàng ở Virginia được thiết kế để chịu nổi cả chiến tranh hạt nhân”... bản gốc
Đã có khá nhiều nhà cung cấp VPS rồi, và vẫn có không ít trường hợp nói chi phí giảm khi chuyển sang đó, nên thực tế đây chủ yếu là vấn đề lock-in cloud và marketing
Hiện nay, doanh nghiệp không còn dùng nhiều dịch vụ IaaS cấp thấp như EC2 mà dùng nhiều dịch vụ PaaS cấp cao của AWS hơn, ví dụ DynamoDB, RedShift. Azure, Google Cloud cũng tương tự. Khi phụ thuộc vào các dịch vụ cấp cao như vậy, việc chuyển sang VPS như Hetzner hay tự host trở nên cực kỳ phức tạp vì phải cài đặt và vận hành lại toàn bộ stack AWS. Không phải cứ cài PostgreSQL là xong
Bất kỳ bài viết nào nói đã giảm chi phí khi dùng VPS đều thường có phản biện kiểu “AWS là web-scale, không bao giờ chết; VPS thì uptime chỉ 1 ngày trong tháng”
Tôi cũng tò mò liệu EC2 - loại VPS mà Amazon cung cấp - có bị ảnh hưởng trong sự cố này không
Phần lớn ý kiến chuyên gia thực ra dồn về bối cảnh địa chính trị hơn (ví dụ: cả hệ thống quốc gia phụ thuộc thời gian thực vào doanh nghiệp nước ngoài) thay vì kỹ thuật. Với công ty bình thường, phụ thuộc vào một nhà cung cấp duy nhất không phải quá phức tạp và không làm tỷ lệ lỗi tăng quá đáng; không cần bắt buộc phải dùng multi-cloud. Dùng một bên có thể còn giúp giảm tần suất downtime
Cả ngành đều dường như mắc kẹt trong lock-in cloud. Không biết từ giờ có thể đảo ngược được không. Tôi cũng cho rằng Docker là một trong những nguyên nhân của lock-in tương tự như các ông lớn cloud
Với vai trò kỹ sư vận hành hoặc nhân viên hỗ trợ thực tế, khi đến 1 giờ sáng phát hiện cả AWS sập và mọi thứ đổ bể, không có ai đang muốn thay đổi tình trạng này
Tôi tò mò tại sao Docker lại là vấn đề
Tôi đã rời công việc cloud lâu rồi, nhưng thời điểm đó các primitive cơ bản của mọi provider đã dần đồng nhất nhau. Cũng tự hỏi liệu multi-cloud redundancy có tốn kém quá mức, hoặc khoảng cách kỹ thuật quá lớn, hay có thực sự cần phải bàn về mặt kinh doanh. slide pets vs cattle
Triển khai/vận hành trên nhiều cloud cùng lúc là gánh nặng quản lý và gánh nặng nhận thức quá lớn cho một đội ngũ. Duy trì kỹ năng chuyên môn cho hạ tầng của từ hai cloud trở lên đòi hỏi rất nhiều nhân lực. Những đội nhỏ hoặc team nhanh nhẹn thì không phù hợp. Tính đơn giản của việc dùng một cloud duy nhất gắn liền với uptime tốt hơn. Các công ty lớn cũng thấy có lợi khi mua hàng với khối lượng lớn trên một cloud để giảm đơn giá. Và chẳng ai bị sa thải vì chọn AWS
Multi-cloud thực tế ít hiệu quả khi một cloud khác cũng không thể ứng phó khi region của chính nó gặp sự cố. Nhà cung cấp vẫn cố giữ 100% chuẩn riêng, và control plane vẫn là Kubernetes. Vậy là tất cả đều gom về Kubernetes
Tất cả cloud đều cung cấp compute rẻ, nhưng phí egress network lại vô lý đắt. Cài multi-cloud khiến chi phí traffic tăng đột biến, và tôi nghĩ rằng điều này có chủ đích
Thực tế các cloud dường như thu lợi nhuận từ phí egress. Vì vậy cấu hình multi-cloud, thậm chí redundancy theo region hay AZ ngay trong một cloud, với nhiều cloud và ứng dụng đều quá đắt. Nếu có sự cố toàn cầu trong một cloud thì redundancy theo region cũng vô dụng. Hơn nữa khi một cloud down, việc chuyển traffic sang cloud khác rất khó và chi phí nhân công không tương xứng với lợi ích. Với phần lớn ứng dụng, tốt hơn là chấp nhận vài giờ downtime và dùng tiền/nhân lực cho việc khác
Khách hàng lưu trữ nhiều file/dữ liệu trên cloud; nếu nhà cung cấp và cloud không cùng nhau thì vận hành dịch vụ không dễ và còn bất lợi cho việc thu hút khách hàng thực tế. Khi nhà cung cấp trở thành chuẩn thị trường, khách hàng cũng dồn dữ liệu trên cloud đó, khiến việc dùng lưu trữ trên hai cloud khó biện minh về chi phí. Tôi cũng từng bắt đầu theo hướng nền tảng trung lập, nhưng thực tế tất cả khách hàng tiềm năng đều đang dùng cùng một cloud, nên độ phức tạp đã giảm
Không thể nào dự đoán trước việc AWS us-east-1 năm nay sẽ chỉ đạt được uptime hai chữ số 9
Với tư cách người dùng AWS gần 20 năm, tôi không hiểu vì sao lại chọn us-east-1 - nơi có lưu lượng nhiều nhất và quan trọng nhất. Đây là vùng cũ nhất và không ổn định nhất
Tôi cũng muốn biết liệu EC2 có thực sự bị ảnh hưởng không
Nhiều người nghĩ rằng nếu mọi thứ cùng down thì được coi là trường hợp đặc biệt, nhưng nếu là dịch vụ phục vụ khách hàng bình thường thì không hề như vậy
Nguyên nhân của sự cố này là do một hệ thống con nội bộ xử lý health check cho network load balancer gặp lỗi. trang trạng thái dịch vụ AWS