เหตุขัดข้องของ GCP ที่ Railway สรุป และการตัดสินใจย้ายออกจาก Google Cloud

 (blog.railway.app)
1 คะแนน โดย GN⁺ 2023-12-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Railway ประสบเหตุระหว่างให้บริการแพลตฟอร์มบน Google Cloud เมื่อ เครื่องบางส่วนใน us-west หยุดทำงานตามลำดับ และการ failover อัตโนมัติล้มเหลว ทำให้ต้องกู้คืน workload ของผู้ใช้ด้วยการดำเนินการแบบ manual
  • แต่ละ instance ออฟไลน์แบบ rolling ประมาณ 10 นาที และหลังเริ่มเหตุเมื่อ 16:40 UTC การ failover ของ workload ทั้งหมดและการกู้คืนบริการเสร็จสิ้นเมื่อ 20:53 UTC
  • ในช่วง 18 เดือนก่อนหน้า Railway เผชิญปัญหา เครือข่ายไม่เสถียร, การลด quota ของ Artifact Registry และปัญหาการตอบสนองของฝ่าย support จึงสร้าง network stack และ registry ของตนเอง
  • ระหว่างการตรวจสอบ พบ CPU soft lockup และ stack trace ของ kvm_wait, __pv_queued_spin_lock_slowpath โดย Railway มองว่าปฏิสัมพันธ์ระหว่าง guest ของ GCP กับ hypervisor เป็นสาเหตุที่เป็นไปได้มาก
  • Railway ตัดสินใจยุติการใช้บริการ Google Cloud และย้ายไปยัง bare metal instance ของตนเอง โดยเปิด instance แรกแล้ว และมีแผนย้ายทั้งหมดในปี 2024

เหตุขัดข้องแบบ rolling ใน us-west

  • Railway ให้บริการแพลตฟอร์มพัฒนาแอปพลิเคชันบนผลิตภัณฑ์ Google Cloud Platform เช่น Google Compute Engine มาโดยตลอด
  • ตั้งแต่วันที่ 1 ธันวาคม 2023 เวลา 16:40 UTC เครื่องบางส่วนใน fleet us-west เริ่มไม่ตอบสนองทีละเครื่อง
    • แต่ละ instance อยู่ในสถานะออฟไลน์ประมาณ 10 นาที
    • เหตุขัดข้องดำเนินไปในลักษณะ rolling
    • ไม่เกิดการ failover อัตโนมัติ จึงต้องทำ failover แบบ manual
  • เวลา 20:53 UTC การ failover ของ workload ทั้งหมดสำเร็จและบริการถูกกู้คืน
  • จากผลการตรวจสอบ Railway สรุปว่าปฏิสัมพันธ์ที่เกี่ยวข้องกับ การถ่ายโอนหน่วยความจำจาก userspace ไปยัง kernel ของ guest บน GCP อาจทำให้เกิด softlock ได้ในบางกรณีที่มีแรงกดดันด้านทรัพยากร

ปัญหา Google Cloud ที่สะสมมาตลอด 18 เดือน

  • Railway เผชิญปัญหาการดำเนินงานหลายอย่างที่เกี่ยวข้องกับ Google Cloud ในช่วง 18 เดือนที่ผ่านมา

  • เครือข่ายไม่เสถียร

    • ในปี 2022 ผลิตภัณฑ์คลาวด์ของ Google เกิด การเชื่อมต่อเครือข่ายหลุด อย่างต่อเนื่อง
    • หลังจาก escalate ไปยัง Google หลายครั้ง Railway จึงสร้าง networking stack ของตนเอง
    • stack ของตนเองเป็นเครือข่าย eBPF/IPv6 Wireguard ที่ resilient และปัจจุบันขับเคลื่อนการ deploy ทั้งหมด
    • หลังจากนั้นปัญหาเครือข่ายก็หายไป

  • Quota ของ Artifact Registry

    • Railway ระบุว่าในปี 2023 Google ลด quota ของ Artifact Registry ลงแบบตามอำเภอใจจนแทบเป็น 0
    • throughput การ deploy image ลดลงมาก ทำให้ build ล่าช้า
    • ต่อมา Railway สร้าง ผลิตภัณฑ์ registry ของตนเอง และปัญหา throughput ของ registry ก็หายไปเช่นกัน

การตอบสนองของ support และการตัดสินใจย้ายไป bare metal

  • แม้ Railway จะจ่ายเงินให้ Google Cloud ปีละหลายล้านดอลลาร์ แต่บริษัทมองว่าไม่ได้รับการตอบสนองที่เพียงพอในสถานการณ์ที่การดำเนินการของ Google ส่งผลต่อ workload ของ Railway และลูกค้ารายอื่น
  • หลังผู้ก่อตั้งโพสต์ปัญหาที่เกี่ยวข้องบน X Google ได้ติดต่อกลับ และ Railway ได้หารือสาเหตุของปัญหากับ VP ของ Google
  • ตามข้อมูลของ Railway วิศวกร Google รายหนึ่งสามารถเปลี่ยน quota ของ GCP ได้ตามอำเภอใจ
    • VP ของ Google เห็นพ้องว่าปัญหานี้เป็นเรื่องที่ยอมรับไม่ได้
    • ตั้งแต่เดือนมิถุนายนเป็นต้นมา Railway ยังคงร้องขอ postmortem, คำตอบอย่างเป็นทางการ และนโยบายป้องกันการเปลี่ยน quota ตามอำเภอใจ
  • ระหว่างกระบวนการนี้ Railway ระบุว่า Google เปลี่ยน ToS โดยไม่แจ้งเตือนล่วงหน้า ทำให้ค่าใช้จ่ายของ Railway เพิ่มขึ้น 20%
    • Google ระบุว่าจะตอบประเด็นนี้ด้วย แต่ Railway บอกว่ายังไม่ได้รับคำตอบ
  • ในไตรมาสที่ผ่านมา Railway ตัดสินใจภายในว่าจะยุติบริการ Google Cloud ทั้งหมดและย้ายไปยัง bare metal instance ของตนเอง
    • bare metal instance แรกถูกเปิดใช้งานเมื่อไม่กี่สัปดาห์ก่อน
    • การย้าย instance ทั้งหมดมีกำหนดดำเนินการในปี 2024

ลำดับเหตุขัดข้องวันที่ 30 พฤศจิกายนและ 1 ธันวาคม

  • วันที่ 30 พฤศจิกายน 2023 เวลา 21:41 UTC เครื่องหนึ่งออฟไลน์เมื่อ Google รีสตาร์ทเครื่อง
    • Railway มีระบบอัตโนมัติสำหรับตรวจจับและแก้ไขสถานการณ์เช่นนี้
    • กล่องดังกล่าวถูก failover ได้ตามปกติ และไม่มีการแจ้ง page
  • วันที่ 1 ธันวาคม 2023 เวลา 16:52 UTC กล่องหนึ่งออฟไลน์ในสถานะที่เข้าถึงไม่ได้
    • แม้ทำ failover อัตโนมัติแล้วก็ยังไม่กลับมาปกติ
    • วิศวกร on-call หลักถูกเรียกตัว และระหว่างตรวจสอบ กล่องอื่นก็ออฟไลน์ตามไปและไม่ฟื้นตัว
  • Railway เริ่มทำ failover กล่องเหล่านั้นแบบ manual
    • แต่ละ host มี downtime ประมาณ 10 นาที
    • ไม่นานนักมีกล่องราว 12 เครื่องได้รับผลกระทบ ทำให้บุคลากรของบริษัทราวครึ่งหนึ่งต้องดำเนินการตาม runbook
  • เนื่องจากรูปแบบ serial log คล้ายกับ live migration อัตโนมัติของ Google Cloud ในตอนแรกจึงเข้าใจว่าเป็นการรีสตาร์ทตามปกติของ Google ที่ทำงานผิดพลาด
    • ส่งอีเมลไปยังผู้รับผิดชอบฝั่ง Google แล้ว แต่ได้รับ automatic reply ว่าไม่อยู่ทันที

เบาะแสจาก log ของ serial console

  • สิ่งแรกที่ Railway ตรวจสอบคือ log ของ serial console
    • log นี้ออกมาจาก kernel โดยตรงผ่าน serial device ที่ถูก virtualize
  • ใน log ปรากฏ CPU core ที่ soft-locked และ stack trace ของ CPU ที่ถูกล็อก
    • รายการตัวอย่างคือ kvm_wait, __pv_queued_spin_lock_slowpath
  • ครั้งสุดท้ายที่ Railway เห็น log และพฤติกรรมคล้ายกันคือช่วงการรีสตาร์ทที่ Google เริ่มในเดือนธันวาคมปีก่อน
    • ตอนนั้นก็เกิดรูปแบบเดียวกันกับกล่องสามเครื่อง
  • การตรวจสอบเพิ่มเติมพบ kernel error ที่สอดคล้องกับเธรดเกี่ยวกับ nested kernel virtualization และ soft lockup ของ GCP
  • เนื่องจาก Railway ไม่ได้ใช้ virtualization ของตนเองบน host ดังกล่าว จึงมองข้อความที่เกี่ยวข้องกับ kvm และ paravirtualization ว่าเป็นสัญญาณของ โค้ด guest kernel ที่มีปฏิสัมพันธ์กับ hypervisor ของ GCP
  • ดูเหมือนว่า GCP จัดการปัญหาคล้ายกันว่า ไม่สามารถทำซ้ำได้ แต่ Railway เชื่ออย่างหนักแน่นว่าเหตุครั้งนี้อยู่ในตระกูลเดียวกัน

สาเหตุที่คาดการณ์และมาตรการบรรเทา

  • Railway มองว่าการถ่ายโอนหน่วยความจำจาก userspace ไปยัง kernel ของ guest บน GCP มีปฏิสัมพันธ์ที่อาจร้ายแรง และทำให้เกิด softlock ได้ในสถานการณ์แรงกดดันด้านทรัพยากรที่พบได้ยาก
  • หากลงรายละเอียดมากขึ้น บริษัทมองว่า paravirtualized memory management และวิธีที่ page ถูก map และ remap ใน hypervisor เกี่ยวข้องกับสถานการณ์แรงกดดันด้านทรัพยากรบางแบบ
  • อีกจุดร่วมคือรายงานที่คล้ายกันเกือบทั้งหมดมาจาก ผู้ใช้ GCP
  • ข้อเท็จจริงที่ว่า Google ประมวลผลคำสั่ง MMIO ส่วนใหญ่ใน userspace ก็สอดคล้องกับข้อสันนิษฐานของ Railway
  • หากการประเมินนี้ถูกต้อง กล่องอาจ softlock ได้เพราะ rate limit, threshold หรือเงื่อนไขที่ไม่เปิดเผย แม้ตัวชี้วัด CPU, memory และ IOPS จะยังต่ำกว่าขีดจำกัดที่สังเกตได้
    • เครื่องในขณะนั้นอยู่ที่ประมาณ 50% ของ resource limit ที่ประกาศไว้
  • หลังรีบูตแบบ manual Railway ได้ปิดใช้งานบริการภายในบางส่วนเพื่อลดแรงกดดันด้านทรัพยากรบน instance ที่ได้รับผลกระทบ และหลังจากนั้น instance ก็เสถียรขึ้น

ผลกระทบต่อผู้ใช้

  • ระหว่างการ failover แบบ manual เครื่องแต่ละเครื่องเกิด downtime 10 นาทีต่อ host
  • เนื่องจากผู้ใช้หลายรายรัน workload หลายบริการ เมื่อกล่องออฟไลน์ต่อเนื่องกัน downtime จึงอาจสะสมได้หลายครั้ง
  • Railway ขอโทษผู้ใช้ และระบุว่ากำลังย้ายไปยัง bare metal ของตนเองเพื่อความน่าเชื่อถือที่สูงขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-04
ความคิดเห็นจาก Hacker News

  • เราเป็นบริษัทซอฟต์แวร์เล็ก ๆ ที่มีแค่ 2 คน และก็มีปัญหากับ Google มาหลายปีเพราะ Google Adwords เช่น:
    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/
    ถ้า Google ยังไม่เต็มใจให้การสนับสนุนที่เหมาะสมกับผู้เขียนต้นฉบับที่จ่ายเงินก้อนใหญ่ให้ Google แล้ว ธุรกิจ รายเล็ก อย่างพวกเราจะมีความหวังอะไรได้บ้าง

  • โดยรวมแล้วผมมองว่าในช่วงไม่กี่ปีที่ผ่านมา GCP หลงทิศไปแล้ว เมื่อไม่กี่ปีก่อน มันยังเป็นตัวเลือกที่ดีกว่า AWS อย่างมีนัยสำคัญในแง่ประสิทธิภาพต่อราคาของคอมพิวต์ สตอเรจ และแบนด์วิดท์ และเราเคยยืนยันเรื่องนี้ด้วยการทดสอบประสิทธิภาพอย่างละเอียดกับ workload ของเรา รวมถึงทำ cost modeling แล้ว
    ตอนนั้นการซัพพอร์ตก็ยอดเยี่ยม ตั๋วปัญหาเครือข่ายที่คลุมเครือซึ่งเราเปิดไปช่วงแรกถูก escalate อย่างรวดเร็ว มีวิศวกรจากหลายภูมิภาคมารับช่วงแก้ต่อ และสุดท้ายก็มีการ rollback การเปลี่ยนแปลงฝั่ง GCP ตัวแทนฝ่ายขายก็ช่วยเชื่อมเราเข้ากับ resource ภายในได้เร็ว ทำให้ประสบการณ์โดยรวมเป็นบวก
    ตอนนี้ AWS ไล่ทันอย่างชัดเจนในด้านประสิทธิภาพต่อราคา และสำหรับ managed service หลายตัวก็ยังนำหน้าอยู่หลายปี ขณะที่ซัพพอร์ตของ GCP แย่ลงมาก ดูเหมือนส่วนใหญ่จะถูกส่งต่อไปยังผู้ให้บริการซัพพอร์ตภายนอก และดูเหมือนพวกเขาไม่ได้มี visibility ต่อโครงสร้างพื้นฐานจริงของ GCP มากไปกว่าเราเท่าไร
    ประสบการณ์กับฝ่ายขายก็แย่ลงมาก และผู้ดูแลบัญชีคนปัจจุบันถือเป็นผลลบอย่างชัดเจน เราลงทุนกับ GCP ไปมาก แต่ไม่เห็นสัญญาณว่าจะดีขึ้น จึงกำลังเดินหน้า ลดค่าใช้จ่ายบน GCP อย่างจริงจัง และแม้เมื่อก่อนผมเคยเป็นคนเชียร์ GCP แต่ตอนนี้ยากที่จะแนะนำให้เอาโปรเจกต์ใหม่ขึ้น GCP

  • จริงอยู่ที่ผู้ให้บริการคลาวด์ทุกรายมีปัญหา ในช่วง 2 ปีที่ผ่านมา ผมพบและรายงานปัญหาหลายอย่างที่เกี่ยวกับ Keyspaces, Amazon Aurora, และ App Runner ในงาน ซึ่งทั้งหมดนำไปสู่ประสิทธิภาพที่ลดลง และซัพพอร์ตของ AWS ก็ทำให้เสียเวลาโดยพาไปขุดผิดจุด
    หลังจาก escalate อยู่หลายสัปดาห์ เจ้าของโปรเจกต์ถึงยอมรับปัญหา และบางส่วนก็เป็นปัญหาที่พวกเขารู้อยู่แล้ว แต่ทีมซัพพอร์ตกลับทำให้เราเสียเวลา ตอนนี้เรายังติดอยู่กับ Keyspaces แต่ต่อไปถ้าไม่ใช่บริการหลักอย่าง EC2, EBS, S3 ก็จะไม่ใช้แล้ว ออกไปนอกเหนือจากนั้นคือเสี่ยง

    • จริงที่สุด บริการของ AWS สักครึ่งหนึ่งดูเหมือนออกแบบมาแย่ หรือดำเนินงานแย่ หรือทั้งสองอย่าง CloudWatch นี่บั๊กเยอะและช้าเป็นพิเศษ จนแทบดูเหมือนกับดักสำหรับมือใหม่
      เวลาเห็นบริษัทใช้ CloudWatch กับ log ทั้งหมด ผมจะเดาว่าเป็นเพราะขาดประสบการณ์และไม่รู้จักทางเลือกอื่น ๆ แต่บริการคอมพิวต์ยังเชื่อถือได้

  • การโทษ GCP เพราะ compute instance ตัวหนึ่งล่มนี่ดูตลก ผู้เขียนต้นฉบับเองก็ยอมรับว่าเป็นเหตุการณ์ที่หายาก แต่ใน AWS ผมเจอบ่อยว่า instance ถูกบังคับหยุดหรือหายไปเลย ความทนทาน 99.95% กับ 99.999% ต่างกันมาก
    ถ้าเอาสถาปัตยกรรมเดียวกันไปวางบน AWS ตามประสบการณ์แล้วคงล่มต่อเนื่อง เอกสารของ AWS และประสบการณ์ของผมบอกว่าองค์ประกอบพื้นฐานของ AWS เสถียรน้อยกว่า GCP มาก

    • ดูเหมือนบทความไม่ได้พูดถึง AWS เท่าไร ประเด็นหลักก็ดูไม่ใช่การที่ instance ตัวหนึ่งล่ม แต่เป็นการขาด การสื่อสารและการสนับสนุน แม้กับพาร์ตเนอร์องค์กรรายใหญ่
      ดูเหมือนพวกเขาจะย้ายไป bare metal ซึ่งมีข้อดีชัดเจนคือสามารถบอกวิศวกร on-call โดยตรงให้แก้ให้ได้ไม่ทางใดก็ทางหนึ่ง
    • SLA ของ EC2 และ GCP Compute ต่างก็อยู่ที่ 99.99% เท่ากันพอดี และถ้าต่ำกว่านี้จะคืนเงิน 10% ถ้าตกต่ำกว่า 95% จะคืนเงิน 100%
      [0] https://aws.amazon.com/compute/sla/
      [1] https://cloud.google.com/compute/sla
    • ต่างจากประสบการณ์ของผมมาก ใช้ AWS มาหลายปี มีแค่ครั้งเดียวที่ instance ถูกหยุดเพราะงานเบื้องหลังแปลก ๆ ของ AWS ที่ไม่เกี่ยวกับแอปพลิเคชัน และผมไม่เคยเจอหรือแม้แต่ได้ยินว่า instance หายไปเฉย ๆ
    • ในคลาวด์ โดยทั่วไปแล้ว อย่างที่มีคนบอกไว้ ควรออกแบบสถาปัตยกรรมบนสมมติฐานว่า ทุกอย่างล้มเหลวอยู่เสมอ

  • ผมเคยมีปฏิสัมพันธ์กับ Google Cloud Support ค่อนข้างมาก โดยเฉพาะเรื่อง managed service และพูดตามตรงว่าไม่ได้น่าประทับใจเท่าไรเมื่อเทียบกับประสบการณ์ซัพพอร์ตที่ยอดเยี่ยมเสมอในสภาพแวดล้อม AWS ขนาดใกล้เคียงกัน
    แต่ถ้ามีใครใน Google Cloud ช่วยได้ดีจริง ๆ ก็ควรชมเขาให้มาก ๆ เพราะเรื่องแบบนั้นหายาก การให้ feedback เชิงบวกแรง ๆ เพื่อให้เขาได้รับรางวัลตอบแทนก็ไม่ได้เป็นภาระอะไรมาก ผมเองเคยมีประสบการณ์ที่ยอดเยี่ยมจริง ๆ อยู่สี่ครั้ง และทุกครั้งก็ส่งข้อความหา TAM ทันที หวังว่าคนเหล่านั้นจะได้รับรางวัลและได้เลื่อนตำแหน่ง

    • เห็นด้วย การถกเถียงแบบนี้มักไหลไปเหมือนสงคราม vi/emacs และบนหน้าแรก HN ก็มักมีแต่เสียงบ่น
      ผมใช้ GCP กับโปรเจกต์ต่าง ๆ เป็นครั้งคราวมาประมาณ 10 ปี และสร้างธุรกิจที่ประสบความสำเร็จหลายตัวบนมันด้วย มันไม่ได้สมบูรณ์แบบ แต่โดยรวมก็พอใจ
      ในทางกลับกัน ผมเคยใช้ AWS เยอะมากตอนอยู่ทีมที่สร้าง Cloud Foundry เวอร์ชันโฮสต์ช่วงแรก ๆ และไม่อยากกลับไปอีก มันวุ่นวายไม่จบสิ้น

  • เคยมีฟีเจอร์หนึ่งใน GCP ที่ดูเป็นระดับองค์กรสุด ๆ พังขึ้นมา และปรากฏชัดว่าฟีเจอร์นั้นไม่เคยทำงานได้ถูกต้องเลยจนถึงตอนนั้น พยายามแก้เงียบ ๆ แต่ก็ทำให้เกิด downtime ด้วย และคนจาก GCP ในสายที่ควรอธิบายสาเหตุ กลับเอาแต่ย้ำเตือนว่าทุกคนอยู่ภายใต้ NDA
    ถ้ายอมรับข้อเท็จจริงข้างต้น อุตสาหกรรมที่ถูกกำกับดูแลคงกลายเป็นฝันร้าย

    • ผมสงสัยมาตลอดว่า NDA จะห้ามไม่ให้พูดกับหน่วยงานกำกับดูแล ตำรวจ อัยการ หรือหน่วยงานรัฐจริง ๆ หรือแม้แต่การเปิดโปงภายในได้ไหม ผมอยากเชื่อว่าอาชญากรรมควรถูกรายงานได้เสมอ

  • “วันที่ 1 ธันวาคม เวลา 8:52 น. PST มีกล่องหนึ่งออฟไลน์และไม่สามารถเข้าถึงได้ จากนั้นหลัง failover มันควรกลับมาเองโดยอัตโนมัติ แต่กลับไม่กลับมา วิศวกร on-call หลักได้รับการแจ้งเตือนและกำลังตรวจสอบอยู่ ระหว่างนั้นกล่องอีกใบก็ออฟไลน์และไม่กลับมาเช่นกัน”
    นี่ฟังไม่สมเหตุสมผล เครื่องรีสตาร์ทแล้วเกิดความขัดข้องระดับหายนะงั้นเหรอ? VM รีบูตกันเป็นครั้งคราวอยู่แล้ว แต่ถ้าออกแบบให้คอนฟิกทั้งหมดพังถล่มเองในสถานการณ์แบบนั้น ต่อให้ย้ายไป AWS หรือแม้แต่ใช้ colocation เองก็คงไม่ถูกใจอยู่ดี

    • ควรอ่านบทความให้ละเอียดกว่านี้ แม้แต่ส่วนที่ยกมาก็ไม่ได้บอกว่าเครื่อง “รีสตาร์ท” แต่บอกว่า หลัง crash แล้วไม่กลับมาออนไลน์อีก
      และในบทความก็ไม่ได้บอกตรงไหนว่านี่เป็น “ความขัดข้องระดับหายนะ” Railway ไม่ได้ล่มทั้งระบบ แต่ Railway เป็นบริษัทด้านการ deploy จึงขายต่อทรัพยากรคอมพิวต์สำหรับ deploy แอปพลิเคชันของลูกค้า ดังนั้นถ้า VM หนึ่งล่มและ failover อัตโนมัติไม่ทำงาน ลูกค้าบางรายที่รันบริการบนเครื่องนั้นก็จะมี downtime
      ในบทความยังบอกด้วยว่า “ระหว่างที่เราทำ failover เครื่องเหล่านี้ด้วยมือ มี downtime 10 นาทีต่อโฮสต์ เนื่องจากผู้ใช้จำนวนมากรัน workload แบบหลายบริการ downtime นี้อาจทวีคูณขึ้นได้เมื่อกล่องต่าง ๆ ออฟไลน์ต่อเนื่องกันไป เราขออภัยผู้ใช้ทุกคนอย่างสุดซึ้ง”

  • ที่น่าสนใจคือ ผมเริ่มคิดว่าใน GCP ดูเหมือนจะมี threshold ที่ไม่ได้ทำเอกสารไว้ อยู่ค่อนข้างบ่อย
    เคยเจอเรื่องคล้าย ๆ กันใน Cloud Run ด้วย มีเหตุการณ์ scaling ที่อธิบายไม่ได้ด้วยเกณฑ์ตามเอกสารอย่างการใช้งาน CPU และจำนวนคำขอพร้อมกันที่ใช้ควบคุม scaling
    หลังคุยกับซัพพอร์ตแบบเสียเงินไปมานานมาก ถึงได้รู้ว่ามีเกณฑ์เพิ่มเติมที่เกี่ยวกับระยะเวลาของคำขอ แต่แน่นอนว่าไม่มีใครอธิบายรายละเอียดได้

    • เราก็เคยเจอขีดจำกัดที่ไม่ได้ทำเอกสารไว้ใน Cloud Run เหมือนกัน เป็น quota ที่คลุมเครือเกี่ยวกับจำนวนแพ็กเก็ตเครือข่ายสูงสุดต่อวินาทีต่ออินสแตนซ์ และใช้เวลาตามหาสาเหตุถึง 6 เดือน โกรธมากจริง ๆ
      ตอนนี้ดูเหมือนจะมีเขียนไว้ที่นี่แล้ว: https://cloud.google.com/run/quotas#cloud_run_bandwidth_limi...
    • ยังมีการเปลี่ยนแปลงที่ไม่แจ้งล่วงหน้าด้วย ปี 2022 เคยมี Firefox outage เพราะ GCP:
      https://hacks.mozilla.org/2022/02/retrospective-and-technica...

  • ฟังดูเป็นประสบการณ์ที่น่าหงุดหงิดจริง ๆ อย่างไรก็ตาม ผมค่อนข้างสับสนว่า nested virtualization เกี่ยวข้องกับปัญหานี้อย่างไร ในเมื่อไม่ได้ใช้ virtualization ภายใน VM soft lock โดยทั่วไปเป็นสัญญาณกว้าง ๆ ว่าความคืบหน้าหยุดไป
    คอมเมนต์เกี่ยวกับคำสั่ง MMIO ก็ชวนงงคล้ายกัน ถ้ากำลังพูดถึง instruction emulation ผมไม่เข้าใจว่ามันเกิดขึ้นที่ไหนแล้วทำไมถึงสำคัญ ยังไงมันก็ช้าและน่าจะถูกผูกไว้กับ user space อยู่แล้ว ถ้าต้องทำงานเร็ว ก็ควรแทบไม่มีการออกจาก guest ตั้งแต่แรก และยิ่งไม่ควรมี emulation
    รู้สึกเหมือนผู้เขียนหงุดหงิด แล้วพยายามคว้าทุกอย่างที่พอเข้าใจได้เกี่ยวกับเหตุการณ์ล่าสุดมาเป็นสาเหตุ

  • “ในปี 2022 เราเจอ network blip ต่อเนื่องในผลิตภัณฑ์ Google Cloud หลัง escalate กับ Google หลายครั้งจนเหนื่อย เราจึงสร้าง networking stack ของเราเอง คือเครือข่าย eBPF/IPv6 Wireguard ที่ยืดหยุ่น ซึ่งขับเคลื่อนทุก deployment จากนั้นจู่ ๆ ปัญหาเครือข่ายก็หายไป”
    ตามที่ผมเข้าใจ เครือข่ายสำหรับ VM คือ VLAN ที่โปรแกรมลงบนสวิตช์ และถ้าสร้าง VPC ก็น่าจะเป็นการสร้าง VLAN ดังนั้นถ้าเครือข่ายพื้นฐานไม่เสถียร ผมสงสัยว่า UDP/WireGuard ซึ่งเป็น overlay จะเสถียรกว่าได้อย่างไร
    เพิ่มเติมคือ ถ้าลูกค้าแบบนี้เจอปัญหานี้บน AWS แค่ 1/10 กองทัพ solution architect ก็คงมาปักหลักในห้องประชุมทุกสองสัปดาห์เพื่อตรวจทานสถาปัตยกรรม และดึง support engineer เข้าสายให้แล้ว

    • ไม่ใช่การโปรแกรมสวิตช์เพื่อสร้าง VLAN แต่ทั้งหมดจัดการด้วย overlay network
      แม้จะเป็นข้อมูลเก่า แต่ช่วยให้พอเห็นภาพได้: https://www.usenix.org/conference/nsdi18/presentation/dalton
    • เดาว่า optimization ด้านเครือข่ายอันฉลาดของ Google อาจชนกับทราฟฟิกของพวกเขา
      การสร้าง networking stack เองทำให้เลี่ยง optimization เหล่านั้นได้ และ WireGuard ถูกสร้างอยู่บน UDP ที่โดยธรรมชาติไม่น่าเชื่อถืออยู่แล้ว จึงอาจรับมือกับความขัดข้องเป็นครั้งคราวได้ดีกว่า