Sự cố Amazon S3: "Khi cả thế giới Internet bỗng chốc thu bé lại chỉ bằng một dòng code"

    Nguyễn Hải,  

    Tại sao một dòng code lỗi lại có thể phá sập dịch vụ S3 cũng như 1/3 Internet thế giới, bài viết dưới đây cho ta thấy rõ nguyên nhân của nó.

    Cuối cùng, nguyên nhân cho sự cố máy chủ trên dịch vụ đám mây AWS của Amazon đã được làm rõ. Một câu lệnh gõ nhầm của nhân viên kỹ thuật đã làm các máy chủ đám mây của công ty tại khu vực Virginia ngừng hoạt động. Đây cũng là khu vực tập trung rất nhiều dịch vụ web đình đám của thế giới, một phần lớn trong họ lại đang phụ thuộc vào dịch vụ đám mây của Amazon.

    Sự cố trong dịch vụ đám mây của Amazon đã có tác động dây chuyền, làm cho dịch vụ của những trang web này bị tê liệt trong một thời gian. Tuy nhiên, tại sao một dịch vụ đám mây lâu năm và nổi tiếng như Amazon Web Service lại có thể dễ dàng gặp sự cố chỉ bởi một lỗi nhỏ như vậy, liệu có phải do hệ thống của họ quá mong manh trước những vấn đề này?

    Nhưng mới đây, một bài đăng trên blog của Amazone Web Services đã cho ta cái nhìn rõ hơn về nguyên nhân của sự cố này.

    Sáng ngày 28 tháng Hai vừa qua, nhóm kỹ thuật trong bộ phận Amazon Simple Storage Service (hay S3) tiến hành sửa một vấn đề làm cho hệ thống xử lý hóa đơn thanh toán của S3 hoạt động chậm hơn dự kiến. Để sửa lỗi này, lúc 9h37 sáng giờ PST (12h37 theo giờ Việt Nam) một thành viên chính thức của nhóm Amazon S3 thực thi một lệnh với dự định loại bỏ một lượng nhỏ máy chủ cho một trong các hệ thống phụ của S3, vốn đang được sử dụng cho quá trình xử lý thanh toán này.

    Thật không may, một trong những đầu vào của câu lệnh này đã bị nhập sai và số lượng máy chủ bị loại bỏ nhiều hơn dự định. Các máy chủ vô tình bị loại bỏ này lại đang được sử dụng để hỗ trợ cho 2 hệ thống phụ khác của Amazon S3: hệ thống phụ lưu chỉ mục (index subsystem) và hệ thống phụ phân bổ tài nguyên (placement subsystem). Và điều này là khởi nguồn gây nên sự cố của cả hệ thống sau đó.

    Quá nhiều hệ thống trên một hệ thống

    Hệ thống lưu chỉ mục dùng để quản lý metadata (siêu dữ liệu) và thông tin vị trí của tất cả các đối tượng trong dịch vụ S3 của khu vực này. Hệ thống phụ này rất cần thiết để phục vụ cho tất cả các truy vấn GET, LIST, PUT và DELETE. Còn hệ thống phụ phân bổ tài nguyên là để quản lý việc phân bổ các bộ lưu trữ mới và đòi hỏi hệ thống phụ chỉ mục hoạt động đúng chức năng để vận hành một cách chính xác. Hệ thống phân bổ tài nguyên này được sử dụng trong các truy vấn PUT để phân bổ bộ lưu trữ cho các đối tượng mới.

    Do vậy, khi các máy chủ trên bị loại bỏ, một tỷ lệ đáng kể dung lượng hệ thống bị mất làm cả hai hệ thống phụ này phải khởi động lại toàn bộ. Trong khi những hệ thống này đang được khởi động lại, dịch vụ lưu trữ Amazon S3 sẽ không thể phục vụ các truy vấn gửi tới.

    Hàng loạt các dịch vụ khác của AWS trong khu vực bờ đông nước Mỹ US-EAST-1 vốn lưu trữ trên dịch vụ S3, bao gồm giao diện điều khiển, các yêu cầu thay đổi cấu hình mới cho dịch vụ EC2 (Amazon Elastic Compute Cloud), hệ thống ổ đĩa ảo Amazon Elastic Book Store (EBS) – nơi sao lưu dữ liệu cho EC2, và AWS Lambda, tất cả đều bị ảnh hưởng khi không kết nối được với các API trên dịch vụ lưu trữ S3.

    Một hệ thống khổng lồ phải khởi động lại

    Các hệ thống phụ của dịch vụ S3 được thiết kế để hỗ trợ cho việc loại bỏ hoặc các vùng lưu trữ lớn bị hỏng mà không hoặc ít tác động đến các khách hàng. Amazon thiết kế nên các hệ thống này với giả định rằng, nếu có bộ phận nào đó bị lỗi bất thường, họ có thể loại bỏ và thay thế nó ngay cả khi một trong các bộ xử lý hoạt động cốt lõi của họ đang vận hành.

    Vì đây là các bộ phận nền tảng cho cả hệ thống của Amazon kể từ khi họ ra mắt dịch vụ S3 cho đến nay, nên công ty đã không khởi động lại hoàn toàn cả hệ thống lưu chỉ mục hay hệ thống phân bổ này tại các khu vực rộng lớn trong nhiều năm nay (từ tháng Ba năm 2006, thời điểm ra mắt dịch vụ S3 này).

    Không những vậy, việc tăng trưởng nhanh chóng của dịch vụ S3 trong những năm qua đã làm việc khởi động lại các hệ thống phụ này, cũng như việc kiểm tra xác thực đối với các siêu dữ liệu nạp vào hệ thống mất nhiều thời gian hơn dự kiến. Đến 12h26 giờ PST (3h26 chiều giờ Việt Nam), hệ thống lưu chỉ mục mới có đủ dung lượng để bắt đầu phục vụ các truy vấn GET, LIST và DELETE trên S3. Phải đến 1h54 chiều giờ PST (5h chiều giờ Việt Nam), toàn bộ hệ thống mới được phục hồi lại bình thường.

    Sự cố vừa qua đã buộc Amazon phải xem xét lại hệ thống của mình và họ đã chỉnh sửa lại các công cụ vận hành, để hạn chế tới mức tối đa tác động của các sự cố tới khách hàng. Không những vậy, bằng cách tách riêng mỗi dịch vụ thành các cell nhỏ, khi có sự cố xảy ra với mỗi dịch vụ, các kỹ thuật viên có thể khởi động lại các cell một cách riêng biệt mà không ảnh hưởng đến cả hệ thống.

    Mặc dù vậy, sự cố này lại một lần nữa cho ta thấy hệ thống Internet hiện tại đang phục vụ chúng ta mong manh và dễ vỡ như thế nào. Nhưng đó cũng là điều mà những người khổng lồ công nghệ của thế giới đang nỗ lực khắc phục với nhiều giải pháp đã và sẽ đến trong tương lai, điển hình như hệ thống trung tâm dữ liệu độc quyền Spanner của Google.

    Tham khảo AWS.Amazon

    Tin cùng chuyên mục
    Xem theo ngày

    NỔI BẬT TRANG CHỦ