Vắn tắt sự kiện downtime dịch vụ chat Slack vào ngày 04/01/2021

22

Vắn tắt sự kiện downtime hệ thống của dịch vụ chat nổi tiếng Slack vào ngày 04/01/2021Cuongquach.com | Slack đã đăng bài viết post-mortem miêu tả về các hoạt động kĩ thuật thời điểm gián đoạn hệ thống Slack ngày 04/01/2021 tại link: https://slack.engineering/slacks-outage-on-january-4th-2021/

thumnail-slack-outage-on-jan-4th-2021

Vắn tắt sự kiện downtime dịch vụ chat Slack vào ngày 04/01/2021

Trong bài viết này, mình cùng review vắn tắt nguyên nhân tại sao xảy ra sự kiện downtime hệ thống dịch vụ Slack ngày 04/01/2021 như một cách học các tình huống phát sinh từ các công ty lớn nhé.

Ngày 04/01/2021 , sau đợt nghỉ lễ đầu Tết tây năm mới và lễ Noel thì rất là nhiều nhân viên và người dùng trên khắp thế giới quay trở lại với guồng quay công việc và Slack là một công cụ được sử dụng nhiều trong môi trường doanh nghiệp cho các hoạt động trao đổi.

Vào thời gian 7am PST , Slack ghi nhận hệ thống có dấu hiệu bất ổn và sau khi kiểm tra các hệ thống alert, monitor,.. thì nhận thấy các chỉ số liên quan đến networking như chỉ số thể hiện thông tin về việc bị mất số lượng gói tin trên giây trong hệ thống mạng đáng kể. Các bạn cần lưu ý là hệ thống hạ tầng của Slack là trên AWS, sử dụng các AWS Account khác nhau để quản lý,… nên sẽ có nhiều VPC liên kết routing với nhau qua Transit Gateway của AWS.

Thời điểm ghi nhận packet/s bị mất nhiều Slack đã liên hệ lập tức với AWS Support để điều tra vấn đề này.

Trong cùng thời điểm này, hệ thống scale EC2 Instance của Slack phát sinh vấn đề ở lớp Web-tier với dịch vụ Apache đứng trước lớp backend-tier instances. Slack setup 2 cơ chế trigger để scale EC2 Instance.
– CPU Utilization
– Apache worker thread utilization

Thời điểm này, do các gói tin kết nối từ Web tier xuống Backend Instances tier bị mất gói tin do sự cố mạng, nên các Apache thread rơi vào trạng thái đợi phản hồi kết nối từ backend (hoặc retry kết nối nhiều lần) vô tình làm lượng CPU Utilization không sử dụng nhiều để xử lý nữa nên CPU utilization của cụm Cluster giảm xuống đáng kể

=> Nên lúc 7:00 AM PST, sự kiện đầu tiên là CPU Utilization giảm nên trigger auto scale down số lượng instance.

Kế đến phát sinh thêm, do nhiều request từ client đi vào và hệ thống mạng có vấn đề nên số lượng Apache thread process tăng cao liên tục do phải đợi phản hồi từ backend instance. Lúc này hệ thống Slack đã cố gắng tự động auto scale up lên đến 1200 instance,…

Ở quá trình scale up , Slack có sử dụng một dịch vụ nội bộ provision-service khi start một instance mới sẽ kết nối đến dịch vụ nội bộ của Slack trong AWS để kiểm tra , chuẩn bị cấu hình và kết nối vài API AWS nhằm thiết lập các tiêu chuẩn thông số cho một ec2 instance hoàn thiện việc sẵn sàng phục vụ trong hệ thống.

Lúc này hệ thống mạng vẫn đang bị lỗi, lúc này provision-service cũng rơi vào trạng thái overload luôn. Nên số lượng EC2 Instance scale up lên rất nhiều nhưng rơi vào trạng thái EC2 Instance không sẵn sàng sử dụng cũng rất nhiều.

Vậy là kết hợp giữa :

  • Nhiều web-tier EC2 Instance được scale lên theo nhu cầu trigger Apache thread utilization để nhận request mới từ client nhưng Apache thread phải treo đợi phản hồi từ backend do lỗi mạng. Nhưng các Web-tier EC2 Instance mới không thể sẵn sàng hoạt động vì provision-service bị quá tải chung.
  • Hệ thống mạng AWS có sự cố nên các kết nối đến backend tier từ Web-tier bị ảnh hưởng

=> Đã gây ra downtime.

Kế đến các kĩ sư AWS và Slack đã tiến hành xử lý và phục hồi hệ thống ở giai đoạn sau cũng như xác định nguyên nhân gây ra sự cố.

Nguyên nhân

Vào thời điểm 04/01/2021, một trong những Transit Gateway trong hạ tầng của Slack trở nên quá tải khiến cho việc lưu chuyển traffic từ các VPC web-tier đến các dịch vụ liên kết không thành công. Như chúng ta biết thì Transit Gateway được quản lý và vận hành bởi AWS với khả năng tự động mở rộng hệ thống TGW hạ tầng theo nhu cầu traffic gia tăng.

Tuy nhiên vào thời điểm client trở lại làm việc sử dụng Slack sau 1 kì nghỉ kéo dài, đã mang đến một lượng request rất nhiều đột biến và Transit Gateway của AWS đã không scale đủ nhanh để có thể trung chuyển lượng traffic giữa các VPC AWS khiến cho việc các gói tin bị mất tăng đột biến dẫn đến sự cố này.

Khi các kĩ sư Slack báo cáo cho kĩ sư AWS, họ đã thực hiện tăng số lượng TGW hạ tầng thiết bị đủ để đáp ứng với nhu cầu traffic tăng cao đó.

AWS báo rằng họ sẽ kiểm tra lại các thuật toán quản lý hạ tầng TGW của họ. Còn slack thì sẽ thiết lập một reminder để báo AWS scale sẵn hạ tầng TGW trước các sự kiện holiday comeback. Cũng như tối ưu kiểm tra thêm dịch vụ provision-service của họ.

Nguồn: https://slack.engineering/slacks-outage-on-january-4th-2021/

LEAVE A REPLY

Please enter your comment!
Please enter your name here