รายงานเหตุขัดข้องของ Google Cloud – 2025-06-13

 (status.cloud.google.com)
3 คะแนน โดย GN⁺ 2025-06-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 12 มิถุนายน 2025 คำขอ API ภายนอกใน Google Cloud, Google Workspace และ Google Security Operations มีข้อผิดพลาด 503 เพิ่มขึ้น ส่งผลกระทบต่อลูกค้าทั่วโลก
  • การตรวจสอบ นโยบายโควตา แบบใหม่ใน Service Control ไปเจอกับข้อมูลนโยบายที่มีฟิลด์ว่าง ทำให้เกิดลูปแครชจาก null pointer และเส้นทางนี้ไม่ได้ถูกรันระหว่างการ rollout
  • การเปลี่ยนแปลงนโยบายถูกจำลองจากตาราง Spanner ระดับภูมิภาคไปทั่วโลกภายในไม่กี่วินาที ทำให้การติดตั้ง Service Control ในแต่ละรีเจียนเข้าสู่เส้นทางความล้มเหลวเดียวกันและลุกลามเป็น เหตุขัดข้องระดับโลก
  • ทีม SRE เริ่มตอบสนองภายใน 2 นาที ระบุสาเหตุได้ภายใน 10 นาที และ rollout แบบ red-button เสร็จภายในราว 40 นาที แต่ us-central1 ใช้เวลาฟื้นตัวนานสุดราว 2 ชั่วโมง 40 นาที
  • มาตรการป้องกันการเกิดซ้ำมุ่งที่การหยุดการเปลี่ยนแปลงใน Service Control, ปิดใช้งาน feature flag โดยค่าเริ่มต้น, การกระจายข้อมูลที่จำลองแบบทั่วโลกอย่างค่อยเป็นค่อยไป, และการปรับปรุงการจัดการข้อผิดพลาดกับ randomized exponential backoff

ขอบเขตของเหตุขัดข้องและไทม์ไลน์

  • ผลิตภัณฑ์ Google Cloud, Google Workspace และ Google Security Operations ได้รับผลกระทบจากข้อผิดพลาด 503 ที่เพิ่มขึ้นในคำขอ API ภายนอก
  • เวลาสำคัญทั้งหมดอ้างอิงตามเขตเวลา US/Pacific
    • เริ่มเกิดเหตุขัดข้อง: 12 มิถุนายน 2025 10:49
    • บรรเทาปัญหาได้ทุกรีเจียนยกเว้น us-central1: 12:48
    • เหตุขัดข้องสิ้นสุด: 13:49
    • ระยะเวลารวม: 3 ชั่วโมง
    • ขอบเขตผลกระทบ: ทั่วโลก
  • ลูกค้าพบปัญหาการเข้าถึง API และส่วนติดต่อผู้ใช้เป็นช่วงๆ ในบริการที่ได้รับผลกระทบ
  • ทรัพยากรสตรีมมิงและ IaaS ที่มีอยู่เดิมไม่ได้รับผลกระทบ

เส้นทางการตรวจสอบที่ Service Control รับผิดชอบ

  • Google และ Google Cloud API ให้บริการผ่าน Google API management and control plane
  • management and control plane นี้ตรวจสอบสิ่งต่อไปนี้สำหรับทุกคำขอ API
    • คำขอได้รับการอนุญาตหรือไม่
    • ผ่านการตรวจสอบอย่างนโยบายและโควตาเพื่อไปยัง endpoint ได้หรือไม่
  • ไบนารีหลักของระบบตรวจสอบนโยบายคือ Service Control
  • Service Control เป็นบริการระดับรีเจียน และใช้ datastore ระดับรีเจียนที่อ่านข้อมูลโควตาและนโยบาย
  • metadata ของ datastore นี้ถูกจำลองไปทั่วโลกแทบจะทันที เพื่อการจัดการนโยบายโควตาของ Google Cloud และลูกค้า

สาเหตุโดยตรง: ฟิลด์นโยบายว่างและ null pointer

  • เมื่อวันที่ 29 พฤษภาคม 2025 มีการเพิ่มฟีเจอร์ใหม่ใน Service Control สำหรับการตรวจสอบนโยบายโควตาเพิ่มเติม
  • การเปลี่ยนแปลงโค้ดและการปล่อยไบนารีถูก rollout เป็นรายรีเจียน แต่เส้นทางโค้ดที่ล้มเหลวต้องอาศัยการเปลี่ยนแปลงนโยบายเฉพาะจึงจะถูกรัน ทำให้ไม่ได้รับการตรวจสอบระหว่าง rollout
  • โค้ดที่มีปัญหามี red-button สำหรับปิดเส้นทางการส่งนโยบายนี้อยู่แล้ว แต่ไม่มีการจัดการข้อผิดพลาดที่เหมาะสมและไม่มีการป้องกันด้วย feature flag
  • null pointer ไม่ได้ถูกจัดการอย่างเหมาะสม จนนำไปสู่การแครชของไบนารี Service Control
  • Google ระบุว่าหากมีการป้องกันด้วย feature flag ก็น่าจะตรวจพบปัญหาได้ใน staging ระหว่างการเปิดใช้งานแบบค่อยเป็นค่อยไปทีละรีเจียน โดยเริ่มจากโปรเจ็กต์ภายใน

กระบวนการลุกลามไปทั่วโลก

  • ราว 10:45 PDT ของวันที่ 12 มิถุนายน 2025 มีการใส่การเปลี่ยนแปลงนโยบายลงในตาราง Spanner ระดับรีเจียนที่ Service Control ใช้สำหรับนโยบาย
  • ข้อมูลนโยบายนี้มี ฟิลด์ว่าง ที่ไม่ได้ตั้งใจรวมอยู่ด้วย
  • เนื่องจากการจัดการโควตาทำงานในระดับโลก metadata ดังกล่าวจึงถูกจำลองไปทั่วโลกภายในไม่กี่วินาที
  • Service Control ของแต่ละรีเจียนทำการตรวจสอบโควตากับนโยบายใน datastore ของรีเจียน แล้วอ่านฟิลด์ว่างดังกล่าว ทำให้เส้นทางโค้ดที่พบ null pointer ถูกเรียกใช้งาน
  • ผลลัพธ์คือไบนารีในแต่ละ deployment ของแต่ละรีเจียนเข้าสู่ crash loop

การตอบสนองและความล่าช้าในการกู้คืน

  • ทีม SRE เริ่มคัดแยกและตอบสนองภายใน 2 นาทีหลังเริ่มเกิดเหตุขัดข้อง
  • ภายใน 10 นาทีสามารถระบุสาเหตุรากและเริ่มใช้ red-button
  • red-button พร้อมสำหรับ rollout ราว 25 นาทีหลังเริ่มเกิดเหตุขัดข้อง
  • ภายใน 40 นาทีหลังเริ่มเหตุ การ rollout ของ red-button เสร็จสิ้น และเริ่มเห็นสัญญาณการฟื้นตัวจากรีเจียนขนาดเล็ก
  • ในรีเจียนขนาดใหญ่อย่าง us-central1 งานของ Service Control ที่รีสตาร์ตขึ้นมาใหม่สร้าง herd effect ต่อโครงสร้างพื้นฐานที่พึ่งพา โดยเฉพาะตาราง Spanner และก่อให้เกิดภาระเกิน
  • Service Control ไม่มีการใช้ randomized exponential backoff ที่เหมาะสมเพื่อหลีกเลี่ยงปัญหานี้
  • us-central1 ใช้การ throttling การสร้างงานและ route ทราฟฟิกไปยัง multi-regional database เพื่อลดภาระ ก่อนจะใช้เวลานานสุดราว 2 ชั่วโมง 40 นาที จึงแก้ไขได้สมบูรณ์
  • หลังจากนั้น Service Control และ API serving ก็ฟื้นตัวสมบูรณ์ในทุกรีเจียน
  • ผลิตภัณฑ์ Google และ Google Cloud ที่เกี่ยวข้องทยอยฟื้นตัวตามลำดับ โดยบางรายการใช้เวลานานกว่าเนื่องจากสถาปัตยกรรม

หน้าสถานะและการสื่อสารกับลูกค้า

  • รายงานเหตุขัดข้องแรกบน Cloud Service Health ถูกเผยแพร่หลังเริ่มการแครชราว 1 ชั่วโมง
  • สาเหตุของความล่าช้าคือโครงสร้างพื้นฐานของ Cloud Service Health เองก็ล่มจากเหตุขัดข้องครั้งนี้
  • ลูกค้าบางรายไม่สามารถรับรู้สัญญาณเหตุขัดข้องหรือประเมินขอบเขตผลกระทบต่อธุรกิจและโครงสร้างพื้นฐานได้ เพราะระบบ monitoring ที่รันอยู่บน Google Cloud ก็ล้มเหลวเช่นกัน
  • Google ระบุว่าจะปรับปรุงการสื่อสารภายนอกทั้งแบบอัตโนมัติและแบบ manual เพื่อให้ลูกค้าได้รับข้อมูลที่จำเป็นต่อการตอบสนองต่อปัญหา การจัดการระบบ และการสนับสนุนลูกค้าได้เร็วขึ้น
  • Google ยังระบุว่าจะรับประกันว่าโครงสร้างพื้นฐานด้าน monitoring และการสื่อสารจะยังให้บริการลูกค้าได้ต่อไป แม้ Google Cloud และผลิตภัณฑ์ monitoring พื้นฐานจะล่มก็ตาม

มาตรการเร่งด่วนและแผนป้องกันการเกิดซ้ำ

  • ทันทีหลังการกู้คืน มีการ หยุด ทั้งการเปลี่ยนแปลงในสแตก Service Control และการ push นโยบายด้วยตนเอง
  • Google ระบุว่าจะให้ความสำคัญกับมาตรการต่อไปนี้และดำเนินการให้เสร็จอย่างปลอดภัย
    • แยกสถาปัตยกรรมของ Service Control ให้เป็นโมดูลเพื่อแยกฟังก์ชันออกจากกัน และเปลี่ยนเป็นโครงสร้าง fail open เพื่อให้ยังประมวลผลคำขอ API ต่อได้ แม้การตรวจสอบที่เกี่ยวข้องจะล้มเหลว
    • ตรวจสอบทุกระบบที่บริโภคข้อมูลซึ่งถูกจำลองแบบทั่วโลก
    • แม้จะมีความต้องการทางธุรกิจที่ต้องการความสอดคล้องเกือบทันทีในระดับโลก ก็จะให้การจำลองข้อมูลกระจายออกไปอย่างค่อยเป็นค่อยไป เพื่อมีเวลาเพียงพอสำหรับการตรวจสอบและตรวจจับปัญหา
    • ปกป้องการเปลี่ยนแปลงไบนารีสำคัญทั้งหมดด้วย feature flag และปิดไว้เป็นค่าเริ่มต้น
    • ปรับปรุงการวิเคราะห์แบบสถิตและแนวปฏิบัติการทดสอบ เพื่อจัดการข้อผิดพลาดให้ถูกต้องและทำ fail open ได้เมื่อจำเป็น
    • ตรวจสอบและรับประกันว่าระบบใช้ randomized exponential backoff
    • ปรับปรุงการสื่อสารกับลูกค้า
    • รักษาการทำงานของโครงสร้างพื้นฐานด้าน monitoring และการสื่อสารแม้ระหว่างที่ Google Cloud และผลิตภัณฑ์ monitoring พื้นฐานขัดข้อง

บริการที่ได้รับผลกระทบและผลกระทบตกค้าง

  • มีผลิตภัณฑ์ Google Cloud จำนวนมากได้รับผลกระทบ โดยรายการรวมถึง Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk, Google Security Operations และอื่นๆ
  • ในกลุ่มผลิตภัณฑ์ Google Workspace มี AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search และ Google Tasks ที่ได้รับผลกระทบ
  • บางผลิตภัณฑ์ยังมี ผลกระทบตกค้าง หลังจากบรรเทาเหตุขัดข้องหลักแล้ว
    • Google Cloud Dataflow มี backlog ที่ค่อยๆ ถูกเคลียร์ และยังมีความล่าช้าใน us-central1
    • Vertex AI Online Prediction ยังมีข้อผิดพลาด 5xx สูงต่อเนื่องในบางโมเดลของ Model Garden และต่อมาฟื้นตัวสมบูรณ์ ณ เวลา 18:18 PDT
    • Personalized Service Health มีความล่าช้าในการอัปเดต และแนะนำให้ลูกค้าใช้แดชบอร์ด Cloud Service Health

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

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

 
kunggom 2025-06-16

ลิงก์ไปยังบทความเวอร์ชันที่ไม่ใช่ GN+