Azure ล่ม 2 ครั้งซ้อน! ตั้งค่าพลาดสะเทือนคลาวด์ทั่วโลก

เมื่อช่วงปลายสัปดาห์ที่ผ่านมา Microsoft แจ้งการหยุดชะงักของบริการบนแพลตฟอร์มคลาวด์ Azure ติดต่อกันสองวัน ส่งผลให้ระบบจัดการ Virtual Machines (VM) ล่มในวันแรก ตามด้วยเหตุการณ์ล่มของบริการ Managed Identity for Azure resources ในอีกวันถัดมา ซึ่งแต่ละเหตุการณ์ส่งผลกระทบต่อการทำงานของบริการต่างๆ ที่ขึ้นอยู่กับแพลตฟอร์มนี้อย่างกว้างขวาง

เหตุการณ์แรกเกิดขึ้นตั้งแต่ช่วง 19:46 UTC ของวันที่ 2 กุมภาพันธ์ 2569 ซึ่งเมื่อแปลงเป็นเวลาไทยก็ตรงกับ 02:46 น. ของวันที่ 3 กุมภาพันธ์ โดยปัญหาดังกล่าวเกี่ยวข้องกับระบบจัดการ Virtual Machine management ops — หรือกล่าวให้เข้าใจง่ายคือ ฟังก์ชันที่ใช้สร้าง ปรับขนาด หยุด/เริ่ม หรือจัดการ VM ไม่สามารถทำงานได้ตามปกติ

บริการที่ต้องพึ่งพาส่วนขยาย (extensions) หรือการดำเนินการกับ VM จึงประสบข้อผิดพลาดและถูกบล็อกไม่ให้ทำงานต่อไป เช่น Azure Arc Enabled Servers, Azure Kubernetes Service (AKS), Azure DevOps, Azure Container Apps และ GitHub Actions เป็นต้น

Microsoft ระบุว่าปัญหานี้เกิดขึ้นตั้งแต่ช่วงเช้ามืดเวลาไทยและกินเวลายาวไปจนถึง ประมาณ 06:05 UTC ของวันที่ 3 กุมภาพันธ์ (13:05 น. ตามเวลาไทย) ก่อนที่ทีมวิศวกรจะสามารถแก้ไขและฟื้นฟูระบบจนหลายบริการกลับมาออนไลน์ได้อีกครั้ง

Managed Identity ล่มซ้ำ! กระทบภูมิภาคอเมริกาและบริการสำคัญ

เพียงไม่กี่ชั่วโมงหลังจากสถานการณ์ VM เริ่มดีขึ้น Azure ก็เจอเหตุการณ์ล่มครั้งที่สอง ในส่วนของบริการ Managed Identity for Azure resources ซึ่งเป็นระบบจัดการตัวตนและการยืนยันสิทธิ์สำหรับทรัพยากร Azure ที่ช่วยให้แอปพลิเคชันและบริการต่างๆ รับโทเค็นเพื่อเข้าถึงทรัพยากรโดยไม่ต้องจัดการความลับ (secrets) ด้วยตนเอง

บริการ Managed Identity ใน ภูมิภาค East US และ West US ของสหรัฐฯ มีปัญหาระหว่าง 00:10 UTC ถึง 06:05 UTC ของวันที่ 3 กุมภาพันธ์ 2569 ส่งผลให้ไม่สามารถสร้าง อัปเดต ลบทรัพยากร หรือรับโทเค็นสำหรับการยืนยันตัวตนได้ ทำให้บริการที่พึ่งพา Managed Identity อย่างเช่น Azure Synapse Analytics, Azure Databricks, Azure Stream Analytics, Azure Container Apps, Azure Firewall และ Azure AI Video Indexer ประสบผลกระทบและล้มตามไปด้วย

Microsoft ระบุว่าปัญหานี้เกิดจาก ปริมาณคำร้องขอที่พุ่งสูงขึ้นจนเกินขีดจำกัดของบริการ Managed Identity ทำให้ระบบพยายาม retry คำร้องขอจำนวนมากจนเผชิญกับคอขวดและไม่สามารถตอบสนองได้ทัน ก่อนที่ทีมวิศวกรจะขยายขีดความสามารถและค่อยๆ ฟื้นฟูบริการให้กลับมาเสถียรอีกครั้งในช่วงสายของวันที่ 3 กุมภาพันธ์ (เวลาไทย)

ที่มา