Bốn cách để tránh lỗi xếp tầng trên CDN như Fastly

Công ty này cũng trong một tuyên bố cuối ngày 8/6 là sẽ hành động để ngăn chặn sự cố lan rộng như vậy trong tương lai.

Nick Rockwell, Phó chủ tịch cấp cao phụ trách kỹ thuật và cơ sở hạ tầng của Fastly cho biết trong tuyên bố: "Mặc dù đã có những tình hình cụ thể gây ra sự cố ngừng hoạt động này, nhưng chúng tôi nên lường trước nó. Chúng tôi cung cấp các dịch vụ quan trọng trong sứ mệnh và chúng tôi xử lý bất kỳ hành động nào có thể gây ra sự cố dịch vụ với mức độ nhạy cảm và ưu tiên cao nhất. Chúng tôi xin lỗi khách hàng và những người dựa vào chúng vì sự cố ngừng hoạt động".

Fastly hỗ trợ các trang web và ứng dụng tin tức như CNN, Guardian, New York Times và nhiều trang khác. Fastly cũng cung cấp phân phối nội dung cho Twitch, Pinterest, HBO Max, Hulu, Reddit, Spotify (SPOT) và các dịch vụ khác. Sự cố kéo dài 49 phút vào sáng 8/6 cũng đã làm ngừng trệ các trang web và nền tảng Internet lớn khác, bao gồm Amazon, Target và trang web của chính phủ Anh - Gov.uk. Nó ảnh hưởng đến hàng chục quốc gia trên khắp châu Mỹ, châu Âu và châu Á, cũng như Nam Phi.

Thủ phạm là một bản cập nhật phần mềm không hợp lệ được Fastly áp dụng vào ngày 12/5. Bản cập nhật đã cho thấy một lỗi do khách hàng cấu hình dịch vụ của họ kích hoạt trong các trường hợp cụ thể - đã xảy ra hôm 8/6. Fastly cho biết lỗi này đã khiến 85% mạng của Fastly phản hồi các lỗi.

Mặc dù Fastly có thể khắc phục lỗi trong vòng một giờ, nhưng Fastly vẫn phải tiếp tục triển khai bản sửa lỗi vĩnh viễn trên toàn mạng của mình. Công ty cũng cho biết đang xem xét các quy trình và thực tiễn của mình để xác định lý do tại sao lỗi không được phát hiện khi nó được triển khai vào tháng trước và sẽ tìm cách để mạng lưới của công ty hoạt động nhanh hơn nếu sự cố hôm 8/6 lại xảy ra.

"Sự cố ngừng hoạt động này diễn ra trên diện rộng và nghiêm trọng, và chúng tôi thực sự xin lỗi vì đã ảnh hưởng đến khách hàng của chúng tôi", Rockwell nói.

Sự cố trên theo nhiều chuyên gia CNTT nhận định có thể nói là tình huống xấu nhất đối với bất kỳ mạng CDN nào. Đầu tiên, một máy chủ gặp phải sự gia tăng lưu lượng truy cập khiến nó vượt quá dung lượng và nó sẽ ngừng hoạt động. Các máy chủ khác trên CDN - số lượng bị giảm đi một phần - vì phải chạy dự phòng cho máy chủ bị lỗi này. Máy chủ phải đảm nhận xử lý nhiều tải hơn (lưu lượng truy cập), nhưng không phải tất cả máy chủ đều có thể xử lý.

Khi các máy chủ bị lỗi hàng loạt, có khả năng toàn bộ điểm hiện diện (PoP) trên CDN sẽ "tối" và toàn bộ mô hình lỗi của máy chủ sẽ tự tái tạo ở cấp độ PoP, với toàn bộ PoP bị quá tải thay vì chỉ có máy chủ. Nguy cơ ngừng hoạt động dịch vụ trong khu vực hoặc thậm chí toàn cầu tăng lên theo từng thời điểm.

Việc sử dụng CDN đang tăng nhanh so với sử dụng Internet, có thể là do mức tiêu thụ video trên OTT trên toàn thế giới tăng lên. Theo một nghiên cứu gần đây của Cisco, ở các thị trường đang phát triển, ngày càng nhiều người truy cập Internet băng thông rộng, cho phép họ xem phim và chương trình truyền hình lần đầu tiên.

Trong khi đó, tại các thị trường lâu năm, ngày càng có nhiều người không dùng mạng dây và cáp, thay vào đó họ chọn xem nội dung video OTT. Đối với CDN, sự kết hợp của hai xu hướng này có thể tạo ra sự áp lực, nếu các nhà cung cấp mạng không lập kế hoạch trước để tăng lưu lượng truy cập.

CDN đã trở thành thành phần của web hiện đại, nghĩa là thời gian hoạt động liên tục của chúng là rất quan trọng đối với một số lượng lớn khách hàng. Dưới đây là một số giải pháp để tránh trường hợp xấu nhất là lỗi phân tầng.

Kiểm tra tải

Mọi thành phần trong hệ thống đều có giới hạn của nó. Kiểm tra tải là việc hiểu chính xác các giới hạn đó ở đâu và cấu hình hiệu suất thay đổi như thế nào khi các thành phần khác nhau đạt tối đa. Những gì cần xem là một hồ sơ hiệu suất đạt được với tốc độ không đổi, những gì cần tránh là một hệ thống mà hiệu suất tăng khi một thành phần đạt đến giới hạn của nó.

Phương pháp hay nhất là kết hợp thử nghiệm tải nghiêm ngặt trong môi trường phòng thí nghiệm được kiểm soát, cùng với việc giám sát rất cẩn thận hiệu suất trong quá trình triển khai trong quá trình sản xuất và vận hành. Rốt cuộc, không có thử nghiệm tải giống như khi sản xuất và vận hành. Cách tiếp cận này cung cấp khả năng hiển thị và sự tự tin ở mọi bước để đảm bảo hiệu suất được duy trì hoặc cải thiện. Bởi luôn giám sát quá trình sản xuất và vận hành sẽ nhận được phản hồi liên tục về kết quả thử nghiệm tải thay đổi theo thời gian.

Để đảm bảo an toàn cho khoảng 20 lần triển khai chạy trên mạng hàng tuần, cần sử dụng một chương trình có tên là CoalMine. CoalMine cho phép khai thác những thay đổi trong một số cấp độ của môi trường dàn dựng - từ thử nghiệm chuyên dụng nhưng các PoP giống hệt khi sản xuất và vận hành, đến các PoP bóng nhận lưu lượng sản xuất thực được phát lại (sử dụng một hệ thống nội bộ khác có tên là Ghostfish) và từ từ chuyển sang sản xuất thực tế.

CoalMine cũng cho phép hiển thị ngay lập tức cách mã hoặc cấu hình mới tác động đến bất kỳ số liệu nào trong số hàng trăm chỉ số cho mỗi máy chủ trong mạng. Mọi hoạt động triển khai đều trải qua quá trình quan trọng này, cho phép nắm bắt các vấn đề về hiệu suất và giữ cho tác động của chúng ở mức không đáng kể.

Giám sát và cảnh báo tại chỗ

Khi hiểu các giới hạn của hệ thống và tin tưởng vào giới hạn thấp hơn về hiệu suất khi bất kỳ phần nào của hệ thống đó đi vào giới hạn của nó, thì bước tiếp theo là đảm bảo bạn thực sự biết khi nào điều đó xảy ra. Điều này có nghĩa là cần phải có giám sát và cảnh báo tại chỗ cho phép nắm bắt ngay thông tin khi nào bất kỳ thứ gì đạt đến giới hạn của nó. Cảnh báo nâng cao mang lại cơ hội thực hiện hành động sửa chữa trước khi xảy ra bất kỳ sự cố hoặc lỗi nào về hiệu suất.

Điều hướng lưu lượng

Thông thường, hành động khắc phục đầu tiên được thực hiện là đảm bảo lưu lượng truy cập đang được phân phối tối ưu để tránh quá tải ở bất kỳ thành phần nào. Ví dụ, nếu chỉ một số máy chủ trong PoP nóng, lưu lượng truy cập có thể được định hình để được phân phối đồng đều hơn và đưa hiệu suất trở lại bình thường.

Khái niệm tương tự cũng áp dụng cho các quy mô lớn hơn. Trong một PoP, tải cũng có thể được cân bằng giữa các mạng. Ở quy mô khu vực, lưu lượng truy cập có thể được cân bằng giữa nhiều PoP và ở quy mô toàn cầu, có thể điều chỉnh cân bằng theo khu vực.

Trong mọi trường hợp, những hành động này đủ để giảm thiểu mọi rủi ro về hiệu suất kém hoặc lỗi.

Ngăn chặn lỗi

Lập kế hoạch thích hợp cho thảm họa là một cách tốt nhất để tránh lỗi xảy ra. Việc sử dụng dung lượng đáng kể của Edgecast CDN (30 + Tbps) sẽ không bị lỗi phân tầng trên quy mô lớn./.