Constraint Management for cluster operation safety and reliability at Twitter

Twitter · 2023 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Team Messaging (Kafka và PubSub) chạy hàng chục cụm Kafka broker trên hybrid Mesos, mỗi cụm từ vài chục đến vài trăm broker. Dữ liệu replicate n bản nên mất tối đa n-1 máy là an toàn; mất nhiều hơn thì lỗi publish.
• Nhiều lần cụm rơi vào under-replicated không phải do phần cứng mà do va chạm giữa các thao tác: hai operator cùng rút máy khỏi cụm mà không biết nhau; operator làm việc khác trong lúc automation đang rolling reboot kernel. Cộng thêm lỗi người: nhập sai batch size làm reboot quá nhiều máy một lúc, nhắm nhầm cụm production thay vì staging.

Thay đổi chính

• Dựng dịch vụ quản lý ràng buộc (constraint management) tập trung, biết trạng thái cụm và các thao tác đang diễn ra, làm trọng tài cuối cùng quyết định thao tác nguy hiểm (drain, reboot, kill/restart shard, thay host) có được chạy không. Nó không tự thực hiện bảo trì; việc đó thuộc một dịch vụ điều phối riêng.
• Ví dụ ràng buộc (lưu trong ConfigBus, nạp lúc chạy): tối đa X thao tác trên Y máy cùng lúc mỗi cụm (với Kafka: một shard một lúc); rate limit số lần một thao tác trên một cụm trong một khoảng thời gian (quan trọng khi automation tự xử lý page); mỗi máy chỉ một thao tác một lúc; nhiều bên cùng làm trên một cụm không được vượt ràng buộc; trong sự cố ảnh hưởng site, thao tác tự động không chạy trừ khi người dùng --force kèm --reason.
• Mô hình: cụm có tài nguyên (compute, storage, mạng) và vùng đệm (ví dụ dư 20% storage, 30% băng thông) một phần để phục vụ bảo trì. Ràng buộc là mức tối thiểu phải giữ và mức tối đa được rút ra cùng lúc (theo số máy, % cụm, theo rack, số host khoẻ tối thiểu…). Chủ cụm định nghĩa thêm query tỉ lệ thành công, ví dụ Messaging kiểm tra under-replication trước khi cho bảo trì.
• Moratorium: chủ cụm đóng băng mọi bảo trì (ví dụ giai đoạn cấm thay đổi); cờ khẩn cấp vẫn cho bảo trì khẩn.
• REST API: client xin thao tác trên một danh sách máy; dịch vụ dự đoán cụm có chịu mất các máy đó không và trả về tập con được phép; client báo bắt đầu/kết thúc từng máy. Mọi request và phản hồi vào audit log MySQL, dùng cho postmortem; dashboard trạng thái bảo trì từng cụm.
• Theo Twitter: số sự cố ảnh hưởng site giảm mạnh, bảo trì không còn chồng chéo.

Bài học cho SWE

• Khi người và automation cùng thao tác trên một cụm, an toàn cần một điểm cấp phép chung biết mọi thao tác đang diễn ra, không phải kỷ luật của từng bên (Tự động hoá vận hành và auto-remediation).
• "Còn đủ replica không" phải được kiểm tra trước khi rút máy, bằng chính tín hiệu của hệ (under-replication) chứ không chỉ đếm máy (Failover, replica và dự phòng dữ liệu).
• Tự động đóng băng automation khi đang có sự cố lớn, chỉ cho phép thao tác có người chịu trách nhiệm và lý do ghi lại.

Liên quan

• Twitter 2022 · Twitter 2023
• Tự động hoá vận hành và auto-remediation · Failover, replica và dự phòng dữ liệu