Quyết định rời Google Cloud của Railway sau khi tổng kết sự cố GCP

 (blog.railway.app)
1 điểm bởi GN⁺ 2023-12-04 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong quá trình vận hành nền tảng dựa trên Google Cloud, Railway đã gặp sự cố khi một số máy tại us-west lần lượt ngừng hoạt động và cơ chế chuyển đổi dự phòng tự động thất bại, khiến họ phải can thiệp thủ công để khôi phục workload của người dùng
  • Mỗi instance riêng lẻ bị offline khoảng 10 phút theo kiểu rolling, sự cố bắt đầu lúc 16:40 UTC và đến 20:53 UTC thì toàn bộ workload đã được failover và dịch vụ được khôi phục
  • Trong 18 tháng trước đó, Railway đã gặp các vấn đề như mạng không ổn định, quota Artifact Registry bị thu hẹp, và vấn đề phản hồi từ bộ phận hỗ trợ, nên đã tự xây dựng network stack và registry riêng
  • Trong quá trình điều tra, họ ghi nhận CPU soft lockup cùng stack trace kvm_wait, __pv_queued_spin_lock_slowpath, và Railway cho rằng nguyên nhân nhiều khả năng nằm ở tương tác giữa guest của GCP và hypervisor
  • Railway quyết định ngừng sử dụng dịch vụ Google Cloud và chuyển sang bare metal instance tự vận hành; họ đã đưa instance đầu tiên vào hoạt động và dự kiến hoàn tất việc chuyển đổi trong năm 2024

Sự cố rolling tại us-west

  • Railway đã vận hành nền tảng phát triển ứng dụng trên các sản phẩm Google Cloud Platform như Google Compute Engine
  • Từ 16:40 UTC ngày 1/12/2023, một số máy trong fleet us-west lần lượt rơi vào trạng thái không phản hồi
    • Mỗi instance bị offline khoảng 10 phút
    • Sự cố tiếp diễn theo kiểu rolling
    • Do failover tự động không hoạt động, họ phải thực hiện failover thủ công
  • Đến 20:53 UTC, tất cả workload đã được failover thành công và dịch vụ được khôi phục
  • Sau điều tra, Railway kết luận rằng tương tác liên quan đến truyền bộ nhớ từ userspace sang kernel trong guest GCP có thể hiếm khi gây ra softlock trong điều kiện áp lực tài nguyên

Các vấn đề với Google Cloud tích lũy trong 18 tháng

  • Trong 18 tháng qua, Railway đã gặp nhiều vấn đề vận hành liên quan đến Google Cloud

  • Mạng không ổn định

    • Năm 2022, các sản phẩm cloud của Google xảy ra tình trạng mất kết nối mạng kéo dài
    • Sau nhiều lần escalation lên Google, Railway đã tự xây dựng network stack riêng
    • Stack này là mạng eBPF/IPv6 Wireguard có khả năng phục hồi cao và hiện đang chạy toàn bộ deployment
    • Sau đó, các vấn đề mạng biến mất

  • Quota Artifact Registry

    • Railway cho biết vào năm 2023, Google đã tùy ý giảm quota Artifact Registry xuống gần như bằng 0
    • Thông lượng xử lý triển khai image giảm mạnh, khiến build bị chậm
    • Sau đó Railway tự xây dựng sản phẩm registry của riêng mình, và vấn đề thông lượng registry cũng biến mất

Phản hồi hỗ trợ và quyết định chuyển sang bare metal

  • Railway cho rằng dù đã trả cho Google Cloud hàng triệu USD mỗi năm, họ vẫn không nhận được mức phản hồi tương xứng trong những tình huống mà hành động của Google ảnh hưởng đến workload của Railway và khách hàng khác
  • Sau khi nhà sáng lập đăng các vấn đề liên quan lên X, Google đã liên hệ và Railway đã thảo luận nguyên nhân với các VP của Google
  • Theo Railway, một kỹ sư của Google có thể tự ý thay đổi quota GCP
    • Các VP của Google được cho là đã đồng ý rằng điều này là không thể chấp nhận được
    • Từ tháng 6 đến nay, Railway vẫn tiếp tục yêu cầu bản tổng kết sự cố, câu trả lời chính thức và chính sách ngăn chặn việc thay đổi quota tùy tiện
  • Trong quá trình đó, Railway cho biết Google đã thay đổi ToS mà không cảnh báo trước, khiến chi phí của Railway tăng 20%
    • Google nói sẽ phản hồi cả về vấn đề này, nhưng Railway cho biết họ vẫn chưa nhận được câu trả lời
  • Trong quý trước, Railway đã đưa ra quyết định nội bộ là chấm dứt toàn bộ dịch vụ Google Cloud và chuyển sang bare metal instance riêng
    • Instance bare metal đầu tiên đã được đưa lên vài tuần trước
    • Việc chuyển toàn bộ instance dự kiến diễn ra trong năm 2024

Diễn biến sự cố ngày 30/11 và 1/12

  • Vào 21:41 UTC ngày 30/11/2023, một máy bị offline khi Google khởi động lại máy đó
    • Railway có sẵn hệ thống tự động phát hiện và xử lý những tình huống như vậy
    • Máy đó được failover bình thường và không phát sinh cảnh báo page
  • Vào 16:52 UTC ngày 1/12/2023, một máy khác bị offline trong trạng thái không thể truy cập
    • Ngay cả sau failover tự động, hệ thống vẫn không phục hồi bình thường
    • Kỹ sư on-call chính được gọi vào, và trong lúc điều tra thì các máy khác cũng tiếp tục offline rồi không phục hồi
  • Railway bắt đầu failover thủ công các máy
    • Mỗi host ghi nhận khoảng 10 phút downtime
    • Chẳng bao lâu đã có khoảng 12 máy bị ảnh hưởng, và gần một nửa công ty phải làm theo runbook để ứng phó
  • Do mẫu serial log tương tự tính năng live migration tự động của Google Cloud, ban đầu họ cho rằng đây là một đợt khởi động lại thường lệ của Google nhưng có vấn đề
    • Họ đã gửi email cho đầu mối phụ trách phía Google nhưng ngay lập tức chỉ nhận được thư trả lời tự động vắng mặt

Các dấu hiệu xuất hiện trong log serial console

  • Điều đầu tiên Railway kiểm tra là serial console log
    • Các log này được xuất trực tiếp từ kernel thông qua thiết bị serial được ảo hóa
  • Trong log xuất hiện stack trace của CPU core bị soft-lock và CPU bị khóa
    • Ví dụ gồm kvm_wait, __pv_queued_spin_lock_slowpath
  • Lần gần nhất Railway thấy log và hành vi tương tự là trong đợt Google khởi động lại vào tháng 12 năm trước
    • Khi đó cũng có ba máy xuất hiện cùng một hiện tượng
  • Điều tra thêm cho thấy các lỗi kernel trùng khớp với các thread liên quan đến nested kernel virtualization của GCP và soft lockup
  • Vì Railway không dùng ảo hóa riêng trên các host đó, họ xem các thông điệp liên quan đến kvm và paravirtualization là tín hiệu của mã kernel guest đang tương tác với hypervisor của GCP
  • Có vẻ GCP đã xử lý các vấn đề tương tự theo hướng không thể tái hiện, nhưng Railway tin chắc rằng sự cố lần này thuộc cùng một nhóm nguyên nhân

Nguyên nhân suy đoán và biện pháp giảm thiểu

  • Railway cho rằng có một tương tác tiềm ẩn nghiêm trọng trong quá trình truyền bộ nhớ từ userspace sang kernel của guest GCP, và trong những điều kiện áp lực tài nguyên hiếm gặp, nó có thể gây ra softlock
  • Cụ thể hơn, họ cho rằng vấn đề liên quan đến cơ chế quản lý bộ nhớ được paravirtualize và cách các page được map/remap trong hypervisor dưới những điều kiện áp lực tài nguyên nhất định
  • Họ cũng xem việc gần như mọi báo cáo tương tự đều đến từ người dùng GCP là một điểm chung đáng chú ý
  • Việc Google xử lý phần lớn lệnh MMIO ở userspace cũng phù hợp với giả thuyết của Railway
  • Nếu nhận định này đúng, box có thể bị softlock do các giới hạn tốc độ, ngưỡng hoặc điều kiện không được công khai, ngay cả khi các chỉ số CPU, bộ nhớ và IOPS vẫn thấp hơn mức giới hạn quan sát được
    • Khi đó các máy chỉ ở khoảng 50% mức giới hạn tài nguyên được công bố
  • Sau khi reboot thủ công, Railway đã vô hiệu hóa một số dịch vụ nội bộ để giảm áp lực tài nguyên trên các instance bị ảnh hưởng, và sau đó các instance đã ổn định trở lại

Ảnh hưởng tới người dùng

  • Trong quá trình failover thủ công, mỗi máy ghi nhận 10 phút downtime cho mỗi host
  • Vì nhiều người dùng chạy workload đa dịch vụ, nên khi các box lần lượt offline, downtime có thể bị cộng dồn nhiều lần
  • Railway xin lỗi người dùng và cho biết họ đang chuyển sang bare metal riêng để đạt độ tin cậy cao hơn

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-04
Ý kiến trên Hacker News

  • Chúng tôi là một công ty phần mềm nhỏ chỉ có 2 người, và trong nhiều năm cũng gặp rất nhiều vấn đề với Google vì Google Adwords. Ví dụ:
    https://successfulsoftware.net/2015/03/04/google-bans-hyperl...
    https://successfulsoftware.net/2016/12/05/google-cpa-bidding...
    https://successfulsoftware.net/2020/08/21/google-ads-can-cha...
    https://successfulsoftware.net/2021/05/04/wtf-google-ads/
    Nếu họ còn không có ý định cung cấp hỗ trợ tử tế cho tác giả bài gốc, người trả cho Google một khoản tiền rất lớn, thì tôi tự hỏi những doanh nghiệp nhỏ như chúng tôi còn hy vọng gì

  • Nhìn chung, tôi cho rằng trong vài năm qua GCP đã mất phương hướng. Chỉ vài năm trước, xét về hiệu năng trên giá của compute, storage và băng thông, đây là lựa chọn tốt hơn AWS một cách đáng kể; chúng tôi đã xác nhận điều đó bằng cả kiểm thử hiệu năng chi tiết và mô hình hóa chi phí cho workload của mình
    Hỗ trợ khi đó cũng rất tuyệt. Một ticket ban đầu về vấn đề mạng mơ hồ nhanh chóng được escalated, các kỹ sư ở nhiều khu vực tiếp nhận nối tiếp nhau để xử lý, và cuối cùng một thay đổi phía GCP đã được hoàn tác. Nhân viên kinh doanh cũng nhanh chóng kết nối chúng tôi với các nguồn lực nội bộ, nên toàn bộ trải nghiệm rất tích cực
    Giờ thì AWS đã bắt kịp rõ ràng về hiệu năng trên chi phí, và ở nhiều dịch vụ managed vẫn đi trước vài năm. Ngược lại, hỗ trợ của GCP đã tệ đi rất nhiều, phần lớn dường như được chuyển sang các nhà thầu hỗ trợ bên ngoài, và khả năng quan sát vào hạ tầng GCP thực tế của họ trông cũng chẳng hơn chúng tôi là bao
    Trải nghiệm với sales cũng tệ hơn hẳn, và người phụ trách hiện tại rõ ràng là một điểm trừ. Chúng tôi đã đầu tư lớn vào GCP, nhưng không thấy dấu hiệu cải thiện nên đang tích cực thực hiện việc cắt giảm chi tiêu cho GCP; trước đây tôi từng là người ủng hộ GCP, nhưng giờ rất khó khuyên đưa dự án mới lên GCP

  • Đúng là nhà cung cấp cloud nào cũng có vấn đề. Trong 2 năm qua, trong công việc tôi đã phát hiện và báo cáo nhiều vấn đề liên quan đến Keyspaces, Amazon Aurora, App Runner; tất cả đều dẫn tới suy giảm hiệu năng, còn hỗ trợ AWS thì khiến chúng tôi tốn thời gian đào bới nhầm chỗ
    Chỉ sau vài tuần escalated, các project lead mới thừa nhận vấn đề; trong đó có một số vấn đề họ đã biết từ trước, vậy mà đội hỗ trợ vẫn để chúng tôi mất thời gian. Trước mắt chúng tôi còn bị khóa vào Keyspaces, nhưng từ giờ nếu không phải các dịch vụ cốt lõi như EC2, EBS, S3 thì tôi không muốn dùng nữa. Bước ra ngoài phạm vi đó là nguy hiểm

    • Đúng là vậy. Có cảm giác khoảng một nửa dịch vụ của AWS được thiết kế tệ, vận hành tệ, hoặc cả hai. CloudWatch đặc biệt nhiều bug và chậm, gần như trông như một cái bẫy cho người mới
      Khi thấy một công ty dùng CloudWatch cho toàn bộ log, tôi thường đoán đó là do thiếu kinh nghiệm và không biết nhiều lựa chọn thay thế. Dù vậy, các dịch vụ compute thì đáng tin cậy

  • Đổ lỗi cho GCP vì một compute instance bị down nghe thật buồn cười. Chính tác giả bài gốc cũng thừa nhận đây là sự kiện hiếm, còn trên AWS tôi từng thường xuyên gặp chuyện instance bị buộc dừng hoặc thậm chí biến mất hoàn toàn. Độ bền 99.95% và 99.999% khác nhau rất lớn
    Nếu đưa cùng kiến trúc đó lên AWS thì theo kinh nghiệm của tôi, chắc hẳn nó sẽ liên tục gặp sự cố. Theo tài liệu AWS và trải nghiệm của tôi, các thành phần nền tảng của AWS kém ổn định hơn GCP rất nhiều

    • Bài viết có vẻ không thực sự bàn về AWS. Vấn đề cốt lõi cũng không phải là một instance bị down, mà dường như là giao tiếp và hỗ trợ thiếu sót ngay cả với một đối tác doanh nghiệp lớn
      Có vẻ họ định chuyển sang bare metal, và lợi thế rõ ràng là có thể nói trực tiếp với kỹ sư on-call rằng hãy sửa bằng mọi cách
    • SLA của EC2 và GCP Compute đều chính xác là 99.99%; nếu thấp hơn mức này thì được hoàn 10%, và nếu xuống dưới 95% thì được hoàn 100%
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • Rất khác với trải nghiệm của tôi. Dùng AWS nhiều năm, tôi chỉ một lần bị dừng instance vì một tác vụ nền kỳ lạ của AWS không liên quan đến ứng dụng, và hình như tôi chưa từng gặp hay nghe chuyện instance cứ thế biến mất
    • Trên cloud, nói chung như ai đó từng nói, bạn phải thiết kế kiến trúc với giả định rằng mọi thứ luôn có thể hỏng

  • Tôi đã tương tác khá nhiều với Google Cloud Support, đặc biệt là liên quan đến các dịch vụ managed, và thành thật mà nói thì không mấy ấn tượng so với trải nghiệm hỗ trợ luôn rất tốt trong môi trường AWS có quy mô tương tự
    Tuy vậy, nếu có ai đó ở Google Cloud thực sự hỗ trợ tốt, bạn nên khen họ thật nhiều. Vì chuyện đó hiếm, việc giúp họ được ghi nhận bằng phản hồi tích cực mạnh mẽ cũng chẳng phải gánh nặng lớn. Bản thân tôi đã có bốn trải nghiệm thật sự xuất sắc, và lần nào tôi cũng nhắn ngay cho TAM. Tôi hy vọng những người như vậy được thưởng và thăng tiến

    • Đúng vậy. Những cuộc thảo luận kiểu này dễ trôi thành tranh luận vi/emacs, và trên trang nhất HN thường chỉ có các lời phàn nàn
      Tôi đã dùng GCP rải rác cho các dự án khoảng 10 năm, và cũng xây được vài doanh nghiệp thành công trên đó. Không hoàn hảo, nhưng nhìn chung tôi hài lòng
      Ngược lại, khi ở trong đội xây dựng phiên bản hosting ban đầu của Cloud Foundry, tôi đã dùng AWS khá nhiều, và không muốn quay lại. Đó là một chuỗi náo loạn bất tận

  • Từng có một tính năng rất kiểu enterprise trên GCP bị hỏng, và rõ ràng là tính năng đó chưa từng hoạt động đúng cho đến thời điểm ấy. Họ cố âm thầm sửa nhưng lại gây downtime, và những người phụ trách phía GCP trong cuộc gọi lẽ ra phải giải thích nguyên nhân thì chỉ liên tục nhắc rằng mọi người đều đang chịu ràng buộc bởi NDA
    Nếu thừa nhận sự thật trên thì với các ngành bị quản lý chặt sẽ là ác mộng

    • Tôi luôn thắc mắc liệu NDA có thể ngăn người ta nói với cơ quan quản lý, cảnh sát, công tố viên, hoặc một cơ quan nhà nước thực thụ, hay thậm chí tố giác nội bộ hay không. Tôi muốn nghĩ rằng tội phạm thì lúc nào cũng phải có thể báo cáo được

  • “Vào 8:52 sáng PST ngày 1/12, một box bị offline và không thể truy cập. Và lẽ ra sau failover nó phải tự quay lại, nhưng đã không quay lại. Trong lúc kỹ sư on-call chính nhận cảnh báo và điều tra, một box khác cũng offline và không quay lại”
    Điều này vô lý. Máy restart mà lại thành sự cố thảm họa à? VM đôi khi vẫn reboot. Nhưng nếu họ thiết kế để toàn bộ cấu hình tự sụp đổ trong kịch bản đó, thì dù chuyển sang AWS hay thậm chí dùng colocation riêng tôi cũng sẽ không hài lòng

    • Cần đọc bài kỹ hơn. Ngay cả đoạn bạn trích cũng không nói máy “restart”, mà nói sau khi crash thì không trở lại online
      Và trong bài cũng không chỗ nào nói đây là “sự cố thảm họa”. Không phải toàn bộ Railway bị sập, nhưng Railway là công ty triển khai, họ bán lại tài nguyên compute để triển khai ứng dụng khách hàng. Vì vậy nếu một VM ngừng hoạt động và auto failover không chạy, thì với những khách hàng cụ thể đang chạy dịch vụ trên máy đó sẽ là downtime
      Bài cũng viết: “Trong lúc chúng tôi failover thủ công các máy này, có 10 phút downtime cho mỗi host. Vì nhiều người dùng chạy workload gồm nhiều service, việc các box lần lượt offline có thể khiến downtime này tăng lên nhiều lần. Chúng tôi thành thật xin lỗi tất cả người dùng”

  • Điều thú vị là tôi bắt đầu nghĩ rằng trên GCP có vẻ khá phổ biến các ngưỡng không được tài liệu hóa
    Tôi cũng từng gặp chuyện tương tự với Cloud Run. Có những sự kiện scaling không giải thích được bằng các tiêu chí trong tài liệu là mức sử dụng CPU và số request đồng thời vốn được nói là dùng để điều chỉnh scaling
    Sau một thời gian dài qua lại với hỗ trợ trả phí, tôi mới biết có thêm một tiêu chí liên quan đến thời lượng request, nhưng tất nhiên chẳng ai giải thích chi tiết được

  • Nghe như một trải nghiệm thật sự bực bội. Tuy vậy tôi hơi bối rối không rõ nested virtualization liên quan gì đến vấn đề này, khi họ đâu có dùng ảo hóa bên trong VM. Soft lock thường chỉ là một tín hiệu bao quát rằng tiến trình không tiến triển
    Phần bình luận về lệnh MMIO cũng gây lẫn lộn tương tự. Nếu đang nói về mô phỏng lệnh, tôi không hiểu việc nó xảy ra ở đâu thì quan trọng thế nào. Dù sao nó cũng chậm và sẽ bị ràng buộc vào user space; nếu cần chạy nhanh thì bản thân việc thoát khỏi guest gần như không nên xảy ra, chứ đừng nói đến emulation
    Cảm giác là tác giả quá bức xúc nên đang bám lấy bất cứ điều gì trong phạm vi có thể hiểu được về sự cố gần đây để tìm nguyên nhân

  • “Năm 2022, chúng tôi gặp các sự cố chập chờn mạng kéo dài trên sản phẩm Google Cloud. Sau nhiều lần escalation với Google, chúng tôi mệt mỏi và tự xây networking stack của riêng mình: một mạng eBPF/IPv6 Wireguard linh hoạt vận hành toàn bộ deployment. Và rồi bỗng nhiên các vấn đề mạng biến mất”
    Theo tôi hiểu, mạng cho VM là VLAN được lập trình vào switch, và khi tạo VPC thì có lẽ là tạo VLAN; nếu mạng nền bên dưới không ổn định thì tôi tò mò không biết overlay UDP/WireGuard có thể ổn định hơn bằng cách nào
    Nói thêm, với kiểu khách hàng này, nếu ở AWS mà xảy ra chỉ 1/10 vấn đề như vậy thôi thì cả một đội solution architect hẳn đã ngồi trong phòng họp hai tuần một lần để rà soát kiến trúc và kéo kỹ sư hỗ trợ vào cuộc gọi

    • Không phải lập trình switch để tạo VLAN; tất cả được xử lý bằng overlay network
      Tài liệu cũ nhưng hữu ích để nắm ý tưởng: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • Tôi đoán có thể các tối ưu hóa mạng thông minh của Google đã xung đột với traffic của họ
      Khi tự xây networking stack, họ đã đi vòng qua các tối ưu hóa đó; và WireGuard về bản chất được xây trên UDP vốn không đáng tin cậy, nên có lẽ xử lý các lỗi chập chờn tốt hơn