Phân tích hậu sự cố về vụ việc Kagi tuần trước

Khắc phục sự cố mất ổn định dịch vụ Kagi.com

• Đang điều tra - Sự cố phát sinh sau khi triển khai và đội ngũ đang xử lý. (12 tháng 1, 16:45 UTC)
• Đang giám sát - Đã hoàn tác thay đổi cấu hình được cho là nguyên nhân của sự cố và đang tiếp tục giám sát để dịch vụ trở lại bình thường. (12 tháng 1, 18:30 UTC)
• Cập nhật - Để khôi phục hoàn toàn tính ổn định, sẽ tạm thời ngắt lưu lượng và chuyển hướng người dùng đến trang này. Sẽ cung cấp thêm chi tiết khi tình hình tiến triển trong lúc khôi phục tải cho dịch vụ theo cách có kiểm soát. (12 tháng 1, 20:26 UTC)
• Đang giám sát - Lưu lượng đã được khôi phục và đang tiếp tục theo dõi để dịch vụ trở lại hoàn toàn bình thường. (12 tháng 1, 21:14 UTC)
• Đã giải quyết - Tất cả dịch vụ đang hoạt động bình thường. Bày tỏ lời cảm ơn tới người dùng đã chờ trong lúc sự cố được khắc phục.

Phân tích hậu sự cố

• Zac, lãnh đạo kỹ thuật của Kagi, đã chia sẻ bản phân tích hậu sự cố chi tiết về đợt gián đoạn dịch vụ tuần trước.
• Để ứng phó với sự cố này, kỹ sư cấp cao Seth và kỹ sư DevOps Luan đã cùng phối hợp xử lý.
• Có những tác nhân lạm dụng dịch vụ và khai thác các điểm nghẽn của hạ tầng; nhóm đã thực hiện các biện pháp giảm thiểu ngay lập tức và đang cải thiện nhiều khía cạnh trong mã nguồn cũng như truyền thông.

Diễn biến sự cố

• Khoảng 5 giờ 30 chiều ngày 12 tháng 1, nhóm nhận biết có vấn đề hạ tầng thông qua giám sát nội bộ và các báo cáo sự cố từ người dùng.
• Bản chất của sự cố khiến người dùng ở nhiều khu vực gặp tình trạng tải chậm hoặc hết thời gian chờ trang.
• Việc xử lý mất khá nhiều thời gian, và bài viết giải thích bối cảnh, diễn tiến cũng như kế hoạch sắp tới.

Quá trình khắc phục sự cố kỹ thuật

• Ban đầu, sự cố xảy ra trùng với việc vô tình nâng cấp thêm tài nguyên RAM cho VM.
• Hệ thống giám sát báo cáo độ trễ cao và vấn đề với connection pool cơ sở dữ liệu của ứng dụng.
• Connection pool đã đạt trạng thái bão hòa, nghĩa là tổng số kết nối đã vượt quá giới hạn kết nối tối đa được cấu hình.
• Trong lúc đánh giá tình trạng nội bộ của cơ sở dữ liệu và hiệu năng truy vấn, nhóm đã thử thay thế một số instance để xem có giúp giảm tắc nghẽn hay không.
• Việc thay thế một phần instance có vẻ hữu ích, nên nhóm đã tạm dừng lưu lượng người dùng để đặt lại hoàn toàn tất cả connection pool cùng lúc.
• Khi xem xét trạng thái cơ sở dữ liệu, nguyên nhân gốc đã trở nên rõ ràng: mức độ tranh chấp cao trên các hàng trong bảng người dùng.
• Sự tranh chấp này làm tăng mạnh độ trễ ghi, tạo backpressure lên connection pool của ứng dụng, và cuối cùng làm cạn kiệt toàn bộ các kết nối khả dụng.
• Từ trước đến nay, Kagi sử dụng cơ sở dữ liệu single-core rẻ nhất có trên GCP, điều này luôn tiềm ẩn nguy cơ khiến cơ sở dữ liệu dễ bị tê liệt.
• Nhóm đã xác định được các tác nhân xấu, bao gồm những tài khoản được tạo trong vòng 24 giờ và một tài khoản người dùng duy nhất đã thực hiện hơn 60.000 lượt tìm kiếm trong thời gian ngắn.
• Nhóm đã gỡ quyền tìm kiếm của tài khoản đó và phát hành một hotfix để vô hiệu hóa thao tác ghi cụ thể gây ra vấn đề.
• Đến nửa đêm, sự cố đã được giải quyết hoàn toàn, và nhóm tiếp tục giám sát chặt chẽ các tín hiệu cho thấy những tác nhân này quay trở lại.

Hành động tiếp theo

• Nhóm đã rút ra nhiều bài học từ sự cố này và đã bắt đầu triển khai ngay các kế hoạch nhằm tăng cường hệ thống hơn nữa cũng như cải thiện quy trình truyền thông khi xảy ra sự cố.
• Trước hết, nhóm thừa nhận rằng các cập nhật trên trang trạng thái đã không đủ nhanh.
• Nhóm sẽ chuyển sang một nền tảng trang trạng thái cho phép công khai giám sát nội bộ tự động tới người dùng dễ dàng hơn, ताकि người dùng có thể nắm tình trạng sức khỏe của nền tảng theo thời gian thực.
• Nhóm đang trực tiếp giảm thiểu các truy vấn gây ra vấn đề và chạy kiểm thử tải để xem còn các điểm yếu tương tự nào khác hay không.
• Nhóm sẽ cài đặt thêm giám sát để nhanh hơn trong việc chỉ đúng vị trí cần chú ý trong hạ tầng, tránh lãng phí thời gian đuổi theo tín hiệu sai như lần này.
• Nhóm đang tăng cường các hệ thống phát hiện kiểu lạm dụng này; vì chúng không chỉ ảnh hưởng hiệu năng mà còn trực tiếp làm phát sinh chi phí, nên cần thiết lập các giới hạn tự động để thực thi.
• Các giới hạn mới đã được áp dụng ngay tại thời điểm bài viết này được đăng, và nhóm sẽ theo dõi tác động của chúng cũng như tiếp tục điều chỉnh khi cần.
• Nếu bạn cho rằng quyền truy cập vào Kagi của mình bị chặn nhầm, hãy liên hệ [e-mail].

Ý kiến của GN⁺

• Kagi đã gặp vấn đề độ trễ ghi do tranh chấp hàng trong bảng người dùng, điều này tạo backpressure lên connection pool của ứng dụng và dẫn đến gián đoạn dịch vụ.
• Vấn đề này là hệ quả của rủi ro phát sinh từ việc Kagi sử dụng cơ sở dữ liệu single-core rẻ nhất trên GCP.
• Thông qua sự cố này, đội ngũ Kagi cho thấy nỗ lực nâng cao tính ổn định và minh bạch của dịch vụ bằng cách tăng cường hệ thống, cải thiện giao tiếp với người dùng và thiết lập các giới hạn tự động để ngăn chặn lạm dụng. Những nỗ lực này phản ánh cam kết của Kagi trong việc cung cấp một dịch vụ đáng tin cậy hơn cho người dùng.

[GN⁺]

Ý kiến trên Hacker News

• Ý kiến về sự cố xảy ra đồng thời với đợt nâng cấp hạ tầng

  • Họ cho biết việc sự cố xảy ra đúng lúc đang nâng cấp hạ tầng bằng cách bổ sung RAM cho VM chỉ hoàn toàn là trùng hợp.
  • Họ nhắc rằng những "trùng hợp" như vậy xảy ra thường xuyên và khiến người ta phải nghi ngờ chính sự tồn tại của mình trong lúc khắc phục sự cố.
  • Họ cảnh báo rằng nếu rơi vào trạng thái hoảng loạn khi xử lý sự cố, người ta có thể áp dụng một bản vá nóng làm hỏng thứ khác, và điều đó có thể trở thành một phiên bản tàn nhẫn của định luật Murphy đối với quản trị viên hệ thống và lập trình viên.

• Trải nghiệm của người dùng về trang trạng thái của Kagi

  • Một người dùng cho biết họ cảm thấy bất an vì trang trạng thái của Kagi hiển thị mọi thứ vẫn hoạt động bình thường.
  • Họ so sánh với các dịch vụ từng sử dụng trước đây, nơi trang trạng thái được cập nhật ngay lập tức để họ biết vấn đề không nằm ở thiết bị của mình.
  • Họ nói vẫn sẽ tiếp tục dùng Kagi, nhưng hy vọng như bài phân tích sau sự cố đã đề cập, mã của trang trạng thái sẽ được chuyển sang một dịch vụ/nền tảng khác.

• Bình luận chia sẻ kinh nghiệm cá nhân

  • Một người chia sẻ rằng cá nhân họ đã nhiều lần gặp đúng kiểu gián đoạn dịch vụ này và từng cố giải quyết các vấn đề liên quan đến tình trạng của connection pool cơ sở dữ liệu.
  • Họ chỉ ra rằng các chỉ số bão hòa thông thường của cơ sở dữ liệu như CPU%, IOPS... không thay đổi nhiều trong những đợt gián đoạn như vậy, mà thay vào đó tranh chấp lock có thể là nguyên nhân.
  • Họ đề xuất rằng với RDBMS mà Kagi đang dùng, nên vẽ biểu đồ cho độ trễ I/O toàn cục, thời gian lấy lock, thời gian thực thi truy vấn, v.v.

• Bình luận về trải nghiệm của startup

  • Có ý kiến cho rằng mọi startup rồi cũng sẽ gặp những vấn đề như thế này vào một thời điểm nào đó.
  • Có thể họ chưa có đủ thời gian hoặc nguồn lực để xây dựng khả năng ngăn chặn sự cố, hoặc đơn giản là chưa nghĩ loại vấn đề đó sẽ xảy ra.
  • Người này nói tính minh bạch và việc học hỏi là quan trọng, nhưng đôi khi bồi hoàn cũng quan trọng, và gợi ý Kagi nên cân nhắc cấp search credit cho quãng thời gian dịch vụ không dùng được.

• Bình luận về khả năng quan sát đối với hệ thống nội bộ

  • Có ý kiến chỉ ra rằng lẽ ra họ phải nhận ra vấn đề sớm hơn, và dashboard Datadog cùng truy vấn Splunk phù hợp đáng ra phải giúp làm rõ vấn đề nhanh hơn rất nhiều.
  • Họ khuyên nên đầu tư vào giám sát tốt hơn và biến đây thành một trải nghiệm học hỏi.

• Ý kiến của người dùng trả phí về độ tin cậy của Kagi

  • Một người dùng trả phí từng trải qua downtime của Kagi nói rằng việc đó khiến họ nhận ra bấy lâu nay mình đã xem độ tin cậy của Google là điều hiển nhiên.
  • Họ nói việc mất quyền truy cập vào công cụ tìm kiếm có thể là một trở ngại lớn; họ yêu Kagi nhưng việc gặp downtime vẫn là một trải nghiệm khó chịu.
  • Họ hy vọng trải nghiệm này sẽ giúp Kagi trở thành một dịch vụ mạnh mẽ và đáng tin cậy hơn.

• Bình luận về scraper gây ra gián đoạn dịch vụ

  • Trước việc một scraper do người dùng chạy đã khiến dịch vụ ngừng hoạt động trong 7 giờ, có người đặt câu hỏi liệu trong lúc kiểm thử họ có từng hỏi "nếu phát sinh rất nhiều lượt tìm kiếm thì sẽ ra sao?" hay chưa.

• Bình luận về trải nghiệm dùng Kagi và bài phân tích sau sự cố

  • Một người chia sẻ rằng sau vài tuần dùng Kagi, khi tuần trước nó không tải ngay lập tức, họ thậm chí không biết nên làm gì.
  • Họ nói rằng trước cả khi bài phân tích sau sự cố được công bố, họ đã quên mất vụ việc, đồng thời gửi lời cảm ơn tới đội ngũ đã làm ra một công cụ tìm kiếm mà người dùng không cần phải bận tâm khi sử dụng.

• Bình luận về cơ sở dữ liệu một lõi dùng trên GCP

  • Có phản hồi tích cực trước việc Kagi đã sử dụng cơ sở dữ liệu một lõi rẻ nhất có trên GCP.
  • Người này gợi ý nên cân nhắc một giải pháp như PolyScale, có thể xử lý mức tăng đột biến của tải đọc và đẩy hiệu năng lên hơn nữa.

• Bình luận về automated scraping

  • Có ý kiến nhắc rằng sau khi tài khoản bị khóa, người dùng đã liên hệ và khẳng định tài khoản đó được dùng để tự động scrape kết quả.
  • Họ khuyến nghị thiết lập giới hạn QPS (số truy vấn mỗi giây) cho mọi yêu cầu RPC / API / HTTP đi vào, đặc biệt là các yêu cầu công khai.