Slack chuyển sang kiến trúc cellular

• Trong 1,5 năm qua, Slack đã chuyển từ cấu trúc đơn sang cấu trúc dựa trên cell để tăng tính dự phòng (redundancy) và giới hạn tác động của sự cố toàn site
• Quá trình này được thúc đẩy bởi nhu cầu cải thiện khả năng phục hồi của dịch vụ Slack sau sự cố gián đoạn mạng vào tháng 6/2021 khiến khách hàng Slack bị suy giảm dịch vụ
• Kiến trúc cellular cho phép mỗi dịch vụ hoạt động như một dịch vụ ảo trên từng vùng sẵn sàng (AZ), nhờ đó sự cố ở một AZ sẽ không ảnh hưởng đến các AZ khác
• Kiến trúc này cũng bao gồm khả năng drain lưu lượng khỏi AZ đang gặp sự cố, qua đó cô lập AZ đó một cách hiệu quả khỏi phần còn lại của hệ thống
• Cơ chế drain được thiết kế để nhanh, không lỗi, diễn tiến dần dần và độc lập với tài nguyên của AZ đang được drain
• Việc chuyển sang kiến trúc cellular còn bao gồm chiến lược siloing, cho phép dịch vụ chỉ nhận và gửi lưu lượng trong chính AZ của nó. Điều này giúp khoanh vùng mọi sự cố trong một AZ duy nhất
• Việc triển khai cơ chế di chuyển lưu lượng tập trung vào hệ thống định tuyến truy vấn của người dùng tới các dịch vụ cốt lõi
• Kiến trúc mới hỗ trợ drain AZ bằng cách tận dụng các tính năng của Envoy như weighted clusters và phân bổ trọng số động thông qua RTDS
• Quá trình chuyển đổi này đã thay đổi cách Slack vận hành và xây dựng dịch vụ, đồng thời cung cấp những công cụ mạnh mẽ mới cho quản lý lưu lượng và giảm thiểu sự cố
• Slack cho biết sẽ đi sâu hơn vào chi tiết triển khai kỹ thuật trong các bài blog tiếp theo và thảo luận về cách kiến trúc mới đã ảnh hưởng đến hoạt động của họ

[GN⁺]

Ý kiến Hacker News

• Việc Slack chuyển sang kiến trúc cellular đã thu hút sự chú ý vì cách tiếp cận vận hành và giám sát rất đặc thù của họ.
• Chiến lược của công ty là xử lý các request trong một AWS Availability Zone (AZ) duy nhất, nhằm đơn giản hóa vận hành và giúp việc giám sát dễ dàng hơn.
• Cách tiếp cận này cho phép dễ dàng phát hiện và giảm thiểu sự cố trong một cụm đơn lẻ bằng cách so sánh metric giữa các cụm.
• Tuy nhiên, chiến lược này cũng tạo ra sự trùng lặp về compute, cache và các thành phần khác, vì phần lớn dịch vụ phải chạy trên nhiều cụm.
• Một số người dùng đặt câu hỏi về hiệu quả của hệ thống API request của Slack, vốn có thể fan-out thành hàng trăm RPC tới backend dịch vụ.
• Có tranh luận về sự khác biệt giữa việc dùng AWS Availability Zone affinity và việc đơn giản loại bỏ một AZ bị down ở điểm định tuyến phía trên.
• Có ý kiến lo ngại về tính dư thừa của việc chạy mọi thứ trong AWS USE1, vì các vấn đề liên quan đến USE1 có thể ảnh hưởng đến nhiều dịch vụ.
• Một số người đặt câu hỏi về cách dữ liệu người dùng được xử lý trong kiến trúc này, đặc biệt là khi xảy ra lỗi trên diện rộng giữa các AZ.
• Một số người dùng nhớ lại những kiến trúc tương tự mà họ từng làm việc trước đây, chẳng hạn như một hệ điều hành phân tán tên là Metal Cell.
• Cũng có thảo luận về khả năng các tác vụ tiêu tốn nhiều tài nguyên có thể tiếp tục chạy vô thời hạn trong một AZ bị cô lập, ngay cả khi không còn request mới từ người dùng.
• Người dùng cũng thắc mắc hiện tại Slack được viết bằng ngôn ngữ lập trình nào, liệu có còn là Hack/PHP hay không.
• Một số người dùng bày tỏ sự thất vọng về hiệu năng của Slack, và so sánh bất lợi nó với các ứng dụng chat khác như Discord.