Twitter's Blobstore Hardware Lifecycle Monitoring and Reporting Service

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

blog.x.com chặn crawler; đọc qua trình duyệt, ghi chú bằng lời của wiki.

Bối cảnh

• Blobstore lưu ảnh, video và blob khác của Twitter, phần lớn trên máy bare metal ở data center riêng. Lúc đầu, máy vào ra khỏi cụm Blobstore trong vòng đời của nó mà không ai nhìn thấy: muốn biết trạng thái hạ tầng phải chạy vài query tay, không định kỳ; máy có thể nằm mãi ở một trạng thái mà không có alert; dung lượng vật lý không có alert, thiếu dung lượng thường chỉ lộ ra qua alert khác hoặc khi có người để ý.

Thay đổi chính

• Bốn trạng thái vòng đời: allocated (vừa được cấp từ đội Capacity, hoặc vừa sửa xong và cài lại) → managed (đúng cấu hình production) → maintenance (cần cập nhật kernel/firmware, hoặc có lỗi nghiêm trọng như đĩa lỗi I/O) → repair (đội Site Operations sửa, xong thì máy được xoá sạch và về allocated).
• Provisioner chạy trên mỗi máy mỗi 24 giờ vào giờ ngẫu nhiên: kiểm tra máy dựng đúng chưa, format đĩa dữ liệu, chạy Puppet; xong thì chuyển sang managed và đưa vào data center.
• Airflow quét máy chạy firmware/kernel cũ: tắt alert của máy, chuyển sang maintenance, nâng cấp, chuyển về managed, bật lại alert; lỗi thì báo Slack. Nâng cấp hỏng vẫn luôn trả lease để không sinh alert sai; phần lỗi để automation khác hoặc người xử lý.
• Metric cho mọi công cụ: đặt thành quy ước của team rằng công cụ mới nào cũng phát metric (số máy đang provision, ở allocated, gửi đi/đang ở repair, vào managed, danh sách máy bị reboot). Thư viện metric không thu được từ cron chạy dưới hai phút, nên họ dùng một tiến trình Python ngắn đẩy qua Scribe daemon tại chỗ.
• Tự động gửi máy hỏng đi sửa: lấy danh sách máy có node hỏng từ mapping service; bỏ máy đang maintenance (có thể đang tắt có lý do) hoặc đã có ticket; chạy uptime, timeout hoặc lỗi là máy có vấn đề. Lịch sử trạng thái lưu trong ZooKeeper; quá ngưỡng (ví dụ hơn 6 lần/tháng, hơn 3 lần/tuần, hơn 2 lần/ngày) thì rút khỏi cụm, tắt alert, chuyển repair, mở ticket Site Ops, xoá lịch sử; chưa quá thì reboot và cắt lịch sử còn một tháng. Tool cũng đếm đĩa chết toàn fleet và giới hạn tốc độ gửi máy sang Site Ops theo ưu tiên (số đĩa hỏng): máy chưa tới lượt thì để "chết tại chỗ" tới lần chạy sau; tới lượt thì fail toàn bộ đĩa, rút dữ liệu, gửi đi sửa.

Vì sao

• Không có hot swap đĩa, nên sửa phần cứng đồng nghĩa rút cả máy; làm bằng tay thì vừa tốn công vừa không nhìn thấy được tình trạng. Mô hình trạng thái rõ ràng + automation chuyển trạng thái + metric ở mỗi bước biến đội ngũ phần cứng, SRE và capacity cùng nhìn một bức tranh (Tự động hoá vận hành và auto-remediation, Observability và monitoring).

Bài học cho SWE

• Đặt tên trạng thái vòng đời của máy và cho mỗi chuyển trạng thái một chủ (automation hay đội nào).
• Automation sửa chữa cần giới hạn tốc độ theo năng lực của bên nhận (Site Ops), không chỉ theo số máy hỏng.
• Chạy tác vụ định kỳ trên mỗi máy vào giờ ngẫu nhiên để không dồn tải.
• Thao tác tự động thất bại vẫn phải trả lại khoá/lease để không sinh alert giả.

Liên quan

• Twitter 2023 · Twitter 2023 · Dropbox 2022 · Slack 2026
• Tự động hoá vận hành và auto-remediation · Observability và monitoring