Báo cáo hậu kiểm sự cố 73 giờ của Roblox năm ngoái

outsideris · 2022-01-31T21:31:10+09:00

Tóm tắt sự cố Sự cố kéo dài trong 72 giờ Có 2 nguyên nhân gốc rễ Khi bật tính năng streaming mới của Consul trong tình huống có tải đọc/ghi cao bất thường, đã phát sinh tranh chấp quá mức và suy giảm hiệu năng Trong một số điều kiện tải cụ thể, đã xuất hiện vấn đề hiệu năng ở BoltDB mã nguồn mở, thứ mà Consul sử dụng để quản lý write-ahead-log cho bầu chọn leader và sao chép dữ liệu Một cụm Consul duy nhất đã làm trầm trọng thêm tác động của các vấn đề này Sự cố bị kéo dài do phải tìm ra hai vấn đề có vẻ không liên quan này, vốn ẩn trong cách triển khai Consul Việc xác định nguyên nhân còn khó hơn vì hệ thống giám sát lẽ ra phải cung cấp khả năng quan sát tốt hơn về nguyên nhân sự cố lại phụ thuộc vào các hệ thống cũng bị ảnh hưởng như Consul Môi trường cụm và HashiStack Roblox đang vận hành 18.000 máy chủ và 170.000 container Đang sử dụng Nomad, Consul, Vault, thường được gọi chung là HashiStack Vào thời điểm đó, Roblox đã nâng cấp Consul từ 1.9 lên 1.10 để sử dụng tính năng streaming. Phát hiện ban đầu (10/28 13:37) Chiều ngày 18 tháng 10, hiệu năng của Vault giảm và tải CPU trên một máy chủ Consul tăng cao. Phân loại ban đầu (10/28 13:37 – 10/29 02:00) Độ trễ ghi tăng lên trong các metric của cụm Consul Nghi ngờ nguyên nhân là suy giảm hiệu năng phần cứng và bắt đầu thay thế một trong các node của cụm Consul Nhân viên HashiCorp tham gia và bắt đầu cùng xử lý Sau khi thay phần cứng, hiệu năng Consul vẫn tiếp tục giảm và đến 16:35 số lượng người chơi giảm còn 50% so với bình thường Vì Consul được dùng cho service discovery và Nomad cùng Vault cũng phụ thuộc vào Consul, nên Consul là SPoF. Lúc này họ đưa ra giả thuyết mới rằng lưu lượng là nguyên nhân. Họ cho rằng Consul không còn xử lý nổi tải do lưu lượng quá cao Thay toàn bộ node của cụm Consul bằng hệ thống mạnh hơn. (số core tăng gấp đôi, NVME SSD nhanh hơn) Việc di chuyển Consul gần như hoàn tất nhưng cụm vẫn không trở lại bình thường Thử khôi phục dịch vụ #1 (10/29 02:00 – 04:00) Quyết định quay về snapshot của cụm Consul trước khi sự cố xảy ra Dữ liệu người dùng vẫn ổn, và họ đánh giá rằng mất một phần dữ liệu hệ thống là chấp nhận được Sau khi khôi phục snapshot, họ chặn truy cập bằng iptables vì lo rằng tải từ các hệ thống vẫn liên tục giao tiếp với Consul sẽ gây vấn đề sau khôi phục Sau khi khôi phục snapshot, các chỉ số trông có vẻ tốt, nhưng khi gỡ chặn iptables thì hệ thống lại quay về trạng thái sự cố ban đầu Thử khôi phục dịch vụ #2 (10/29 04:00 – 10/30 02:00) Chặn lưu lượng bên ngoài và loại bỏ các cách sử dụng không thiết yếu, khiến những dịch vụ vốn chạy trên hàng trăm instance giảm xuống còn một chữ số Thử khôi phục dịch vụ lần nữa nhưng Consul lại rơi vào trạng thái bất thường Họ nhận ra ngoài các yếu tố suy giảm hiệu năng đã nghĩ tới ban đầu còn có nguyên nhân khác, nên bắt đầu nhìn vào bên trong Consul thay vì chỉ nhìn Consul từ góc độ Roblox Phân tích tranh chấp (10/30 02:00 – 10/30 12:00) Sau khi phân tích thêm 10 giờ, họ phát hiện các thao tác ghi của Consul đã bị chặn trong thời gian dài Dù chưa biết nguyên nhân gây tranh chấp, họ cho rằng việc đổi CPU ban đầu từ 64 core lên 128 core đã làm tình trạng tranh chấp nặng hơn Họ quyết định quay lại 64 core nhưng cũng không giúp ích gì Phát hiện nguyên nhân gốc rễ (10/30 12:00 – 10/30 20:00) Tính năng streaming của Consul đã được bật từ vài tháng trước và đang được triển khai dần dần vì nó làm giảm mức dùng CPU và băng thông mạng. Một ngày trước sự cố, vào 14:00 ngày 27, họ đã bật tính năng này ở backend định tuyến lưu lượng. Vì sau khi bật từ hôm trước nó vẫn hoạt động tốt nên ban đầu họ không nghĩ đây là nguyên nhân Sau khi phân tích hiệu năng, họ xác nhận có bằng chứng cho thấy mã streaming gây ra mức dùng CPU cao Sau khi tắt streaming và triển khai xong, họ xác nhận độ trễ ghi KV của Consul đã giảm xuống (cuối cùng cũng vậy!) HashiCorp cho biết streaming hiệu quả hơn, nhưng khi triển khai họ đã dùng ít thành phần kiểm soát đồng thời hơn (Go channel) so với long polling -> điều này làm tranh chấp trên một Go channel đơn lẻ trầm trọng hơn dưới tải cao, khiến hiệu quả giảm đi Dù đã thấy hướng đột phá, họ vẫn phát hiện hiện tượng bầu chọn leader gián đoạn, và một số leader vẫn gặp vấn đề độ trễ tương tự trước đó Họ xác định rằng nếu không bầu chọn vào một số leader cụ thể thì cụm sẽ bình thường, nên tập trung đưa dịch vụ trở lại trạng thái hoạt động ổn định Sau đó HashiCorp tiếp tục điều tra nguyên nhân gốc rễ và phát hiện vấn đề một số leader bị chậm là do BoltDB Khôi phục dịch vụ cache (10/30 20:00 – 10/31 05:00) Sau 54 giờ kể từ khi sự cố bắt đầu, họ đã sẵn sàng khôi phục dịch vụ Trong thời gian sự cố, database vẫn ổn nhưng hệ thống cache xử lý 1 tỷ request mỗi giây thì ở trạng thái bất thường. Sau khi khôi phục cache này và xác nhận nó hoạt động bình thường, thời gian từ lúc sự cố xảy ra đã là 61 giờ. Người dùng quay trở lại (10/31 05:00 – 10/31 16:00) Họ bắt đầu chuẩn bị khôi phục dịch vụ lúc 5 giờ ngày 31 và hoàn tất lúc 10 giờ. Họ điều tiết số lượng người chơi truy cập qua DNS, vừa tăng dần vừa theo dõi Sau 73 giờ, tất cả người chơi đã có thể truy cập trở lại. Phân tích bổ sung và các thay đổi sau sự cố HashiCorp và Roblox đã phát triển quy trình "compression" để giải quyết vấn đề hiệu năng Cải thiện telemetry: giữa hệ thống telemetry và Consul có phụ thuộc vòng, nên khi Consul gặp sự cố thì thiếu dữ liệu. Họ đã loại bỏ phụ thuộc vòng để hệ thống telemetry không còn phụ thuộc vào các hệ thống mà nó giám sát Mở rộng availability zone và datacenter Dọn dẹp dữ liệu KV không cần thiết hoặc dữ liệu đang được lưu trong Consul dù đã có hệ thống lưu trữ khác. Đang thử nghiệm phiên bản Consul mới thay BoltDB bằng bbolt, phiên bản kế nhiệm của nó Quá trình khởi tạo bootstrap đã làm chậm việc khôi phục nên họ đang tự động hóa phần này và phát triển các công cụ cùng quy trình mới

(blog.roblox.com)

16 điểm bởi outsideris 2022-01-31 | 1 bình luận | Chia sẻ qua WhatsApp

Tóm tắt sự cố

Sự cố kéo dài trong 72 giờ
Có 2 nguyên nhân gốc rễ
- Khi bật tính năng streaming mới của Consul trong tình huống có tải đọc/ghi cao bất thường, đã phát sinh tranh chấp quá mức và suy giảm hiệu năng
- Trong một số điều kiện tải cụ thể, đã xuất hiện vấn đề hiệu năng ở BoltDB mã nguồn mở, thứ mà Consul sử dụng để quản lý write-ahead-log cho bầu chọn leader và sao chép dữ liệu
Một cụm Consul duy nhất đã làm trầm trọng thêm tác động của các vấn đề này
Sự cố bị kéo dài do phải tìm ra hai vấn đề có vẻ không liên quan này, vốn ẩn trong cách triển khai Consul
Việc xác định nguyên nhân còn khó hơn vì hệ thống giám sát lẽ ra phải cung cấp khả năng quan sát tốt hơn về nguyên nhân sự cố lại phụ thuộc vào các hệ thống cũng bị ảnh hưởng như Consul

Môi trường cụm và HashiStack

Roblox đang vận hành 18.000 máy chủ và 170.000 container
Đang sử dụng Nomad, Consul, Vault, thường được gọi chung là HashiStack

Vào thời điểm đó, Roblox đã nâng cấp Consul từ 1.9 lên 1.10 để sử dụng tính năng streaming.

Phát hiện ban đầu (10/28 13:37)

Chiều ngày 18 tháng 10, hiệu năng của Vault giảm và tải CPU trên một máy chủ Consul tăng cao.

Phân loại ban đầu (10/28 13:37 – 10/29 02:00)

Độ trễ ghi tăng lên trong các metric của cụm Consul
Nghi ngờ nguyên nhân là suy giảm hiệu năng phần cứng và bắt đầu thay thế một trong các node của cụm Consul
Nhân viên HashiCorp tham gia và bắt đầu cùng xử lý
Sau khi thay phần cứng, hiệu năng Consul vẫn tiếp tục giảm và đến 16:35 số lượng người chơi giảm còn 50% so với bình thường
Vì Consul được dùng cho service discovery và Nomad cùng Vault cũng phụ thuộc vào Consul, nên Consul là SPoF.
Lúc này họ đưa ra giả thuyết mới rằng lưu lượng là nguyên nhân. Họ cho rằng Consul không còn xử lý nổi tải do lưu lượng quá cao
Thay toàn bộ node của cụm Consul bằng hệ thống mạnh hơn. (số core tăng gấp đôi, NVME SSD nhanh hơn)
Việc di chuyển Consul gần như hoàn tất nhưng cụm vẫn không trở lại bình thường

Thử khôi phục dịch vụ #1 (10/29 02:00 – 04:00)

Quyết định quay về snapshot của cụm Consul trước khi sự cố xảy ra
Dữ liệu người dùng vẫn ổn, và họ đánh giá rằng mất một phần dữ liệu hệ thống là chấp nhận được
Sau khi khôi phục snapshot, họ chặn truy cập bằng iptables vì lo rằng tải từ các hệ thống vẫn liên tục giao tiếp với Consul sẽ gây vấn đề sau khôi phục
Sau khi khôi phục snapshot, các chỉ số trông có vẻ tốt, nhưng khi gỡ chặn iptables thì hệ thống lại quay về trạng thái sự cố ban đầu

Thử khôi phục dịch vụ #2 (10/29 04:00 – 10/30 02:00)

Chặn lưu lượng bên ngoài và loại bỏ các cách sử dụng không thiết yếu, khiến những dịch vụ vốn chạy trên hàng trăm instance giảm xuống còn một chữ số
Thử khôi phục dịch vụ lần nữa nhưng Consul lại rơi vào trạng thái bất thường
Họ nhận ra ngoài các yếu tố suy giảm hiệu năng đã nghĩ tới ban đầu còn có nguyên nhân khác, nên bắt đầu nhìn vào bên trong Consul thay vì chỉ nhìn Consul từ góc độ Roblox

Phân tích tranh chấp (10/30 02:00 – 10/30 12:00)

Sau khi phân tích thêm 10 giờ, họ phát hiện các thao tác ghi của Consul đã bị chặn trong thời gian dài
Dù chưa biết nguyên nhân gây tranh chấp, họ cho rằng việc đổi CPU ban đầu từ 64 core lên 128 core đã làm tình trạng tranh chấp nặng hơn
Họ quyết định quay lại 64 core nhưng cũng không giúp ích gì

Phát hiện nguyên nhân gốc rễ (10/30 12:00 – 10/30 20:00)

Tính năng streaming của Consul đã được bật từ vài tháng trước và đang được triển khai dần dần vì nó làm giảm mức dùng CPU và băng thông mạng.
Một ngày trước sự cố, vào 14:00 ngày 27, họ đã bật tính năng này ở backend định tuyến lưu lượng.
Vì sau khi bật từ hôm trước nó vẫn hoạt động tốt nên ban đầu họ không nghĩ đây là nguyên nhân
Sau khi phân tích hiệu năng, họ xác nhận có bằng chứng cho thấy mã streaming gây ra mức dùng CPU cao
Sau khi tắt streaming và triển khai xong, họ xác nhận độ trễ ghi KV của Consul đã giảm xuống (cuối cùng cũng vậy!)
HashiCorp cho biết streaming hiệu quả hơn, nhưng khi triển khai họ đã dùng ít thành phần kiểm soát đồng thời hơn (Go channel) so với long polling -> điều này làm tranh chấp trên một Go channel đơn lẻ trầm trọng hơn dưới tải cao, khiến hiệu quả giảm đi
Dù đã thấy hướng đột phá, họ vẫn phát hiện hiện tượng bầu chọn leader gián đoạn, và một số leader vẫn gặp vấn đề độ trễ tương tự trước đó
Họ xác định rằng nếu không bầu chọn vào một số leader cụ thể thì cụm sẽ bình thường, nên tập trung đưa dịch vụ trở lại trạng thái hoạt động ổn định
Sau đó HashiCorp tiếp tục điều tra nguyên nhân gốc rễ và phát hiện vấn đề một số leader bị chậm là do BoltDB

Khôi phục dịch vụ cache (10/30 20:00 – 10/31 05:00)

Sau 54 giờ kể từ khi sự cố bắt đầu, họ đã sẵn sàng khôi phục dịch vụ
Trong thời gian sự cố, database vẫn ổn nhưng hệ thống cache xử lý 1 tỷ request mỗi giây thì ở trạng thái bất thường.
Sau khi khôi phục cache này và xác nhận nó hoạt động bình thường, thời gian từ lúc sự cố xảy ra đã là 61 giờ.

Người dùng quay trở lại (10/31 05:00 – 10/31 16:00)

Họ bắt đầu chuẩn bị khôi phục dịch vụ lúc 5 giờ ngày 31 và hoàn tất lúc 10 giờ.
Họ điều tiết số lượng người chơi truy cập qua DNS, vừa tăng dần vừa theo dõi
Sau 73 giờ, tất cả người chơi đã có thể truy cập trở lại.

Phân tích bổ sung và các thay đổi sau sự cố

HashiCorp và Roblox đã phát triển quy trình "compression" để giải quyết vấn đề hiệu năng
Cải thiện telemetry: giữa hệ thống telemetry và Consul có phụ thuộc vòng, nên khi Consul gặp sự cố thì thiếu dữ liệu. Họ đã loại bỏ phụ thuộc vòng để hệ thống telemetry không còn phụ thuộc vào các hệ thống mà nó giám sát
Mở rộng availability zone và datacenter
Dọn dẹp dữ liệu KV không cần thiết hoặc dữ liệu đang được lưu trong Consul dù đã có hệ thống lưu trữ khác.
Đang thử nghiệm phiên bản Consul mới thay BoltDB bằng bbolt, phiên bản kế nhiệm của nó
Quá trình khởi tạo bootstrap đã làm chậm việc khôi phục nên họ đang tự động hóa phần này và phát triển các công cụ cùng quy trình mới

1 bình luận

xguru 2022-02-01

Cảm ơn bạn đã dịch.

Sự cố kéo dài 72 giờ ở quy mô đó thật sự rất đáng sợ.