เจาะลึก: จาก 'บั๊ก' ตัวจิ๋ว ลุกลามสู่เหตุการณ์ AWS ล่มสะเทือนโลกได้อย่างไร

 

เหตุการณ์ที่ Amazon Web Services (AWS) ล่มครั้งใหญ่เมื่อวันจันทร์ที่ผ่านมา ทำเอาแอปและบริการดังๆ ทั่วโลกใช้งานไม่ได้ไปตามๆ กัน ทั้งหมดนี้มีจุดเริ่มต้นมาจาก "กลิตช์" (glitch) หรือข้อผิดพลาดเล็กๆ เท่านั้นเองครับ

ทาง Amazon ได้ออกมา "ชันสูตร" (postmortem assessment) เหตุการณ์เมื่อวันพฤหัสบดี เล่าว่า บั๊กที่ว่านี้เกิดขึ้นตอนที่ระบบอัตโนมัติสองตัว พยายามจะอัปเดตข้อมูลชุดเดียวกันในเวลาเดียวกันพอดีเป๊ะ (simultaneously)

จากเรื่องเล็กๆ มันก็เลย "ลุกลามบานปลาย" (snowballed) กลายเป็นเรื่องใหญ่ยักษ์ที่วิศวกรของ Amazon ต้องรีบวิ่งวุ่นกันแก้ปัญหาเลยทีเดียว

ผลกระทบจากการที่บริการคลาวด์ยักษ์ใหญ่นี่ล่มน่ะเหรอครับ... ก็คือคนสั่งอาหารไม่ได้, เครือข่ายโรงพยาบาลมีปัญหา, เข้าแอปธนาคารมือถือไม่ได้ หรือแม้แต่ระบบรักษาความปลอดภัยกับอุปกรณ์สมาร์ทโฮมในบ้านก็เดี้ยงไปด้วย บริษัทยักษ์ใหญ่ระดับโลกอย่าง Netflix, Starbucks หรือสายการบิน United Airlines ก็เจ๊งไปชั่วขณะ ลูกค้าเข้าใช้บริการออนไลน์ของพวกเขาไม่ได้เลย

Amazon ก็ออกมาขอโทษขอโพยนะครับ บอกว่า "เราขออภัยในผลกระทบที่เกิดขึ้น... เรารู้ว่ามันหนักหนาสาหัสกับลูกค้าหลายคนมาก เราจะทำทุกอย่างเพื่อเรียนรู้จากเหตุการณ์นี้และใช้มันเพื่อปรับปรุงความเสถียรของเราให้ดียิ่งขึ้นไปอีก"

ถ้าว่ากันในทางเทคนิค ปัญหามันเกิดจากโปรแกรม 2 ตัว "แย่งกันเขียน" (competing to write) ข้อมูล DNS เดียวกันครับ

อธิบายง่ายๆ DNS มันคือ "สมุดหน้าเหลืองของอินเทอร์เน็ต" (internet’s phonebook) ครับ พอสองคนแย่งกันเขียน ผลลัพธ์คือ... กลายเป็น "ข้อมูลว่างเปล่า" (empty entry) ครับ พังเลยทีนี้

คุณ Angelique Medina จาก Cisco เขาอธิบายเสริมได้เห็นภาพมากครับ เขาบอกว่า "การเปรียบเทียบกับสมุดโทรศัพท์นี่ใช่เลย... คนที่อยู่ปลายสาย (บริการต่างๆ) เขาก็ยังอยู่นะครับ แต่ถ้าคุณไม่รู้เบอร์โทรเขา (ไม่รู้จะติดต่อเขายังไง) คุณก็มีปัญหา... และสมุดโทรศัพท์ที่ว่า มันก็ดัน 'หายวับไปกับตา' (went poof) ครับ"

มีอีกคำอธิบายที่เจ๋งมาก จากศาสตราจารย์ Indranil Gupta แห่งมหาวิทยาลัยอิลลินอยส์ เขาเปรียบเทียบเหมือนอยู่ในห้องเรียน

ลองนึกภาพนักเรียน 2 คน คนนึงทำงานเร็วมาก อีกคนทำงานช้ากว่า ทั้งคู่ต้องมาจดโน้ตลงใน "สมุดเล่มเดียวกัน" (shared notebook)

ไอ้เจ้าคนช้าเนี่ย "นานๆ จะตั้งใจที แต่พอทำทีงานก็อาจจะไปขัดแย้งกับไอ้คนเร็ว" ส่วนไอ้คนเร็วก็ "พยายามจะ 'แก้ไข' ทุกอย่างให้มันถูกต้องเร็วๆ" ตลอดเวลา สุดท้ายก็เลยลบงานของไอ้คนช้าทิ้ง เพราะคิดว่ามัน "เก่าไปแล้ว" (outdated)

ผลลัพธ์เหรอครับ... ก็คือ "หน้ากระดาษว่างเปล่า" (empty page) ในสมุดเล่มนั้น พออาจารย์มาตรวจก็ไม่เจออะไรเลย

ไอ้ "หน้ากระดาษว่างเปล่า" ที่ว่าเนี่ยแหละครับ ที่ทำให้ฐานข้อมูล DynamoDB ของ AWS ล่มก่อนเลย พอตัวนี้ล่ม มันก็ส่งผลกระทบเป็น "โดมิโน" (cascading effect) ไปยังบริการอื่น เช่น EC2 (ที่ให้นักพัฒนาเช่าเซิร์ฟเวอร์) และ Network Load Balancer (ตัวจัดการจราจรในระบบ)

ที่แย่ไปกว่านั้นคือ พอ DynamoDB กลับมาออนไลน์ได้ปุ๊บ เจ้า EC2 ก็พยายามจะปลุกเซิร์ฟเวอร์ทั้งหมดของมันให้ตื่นพร้อมกันในทีเดียวเลย ผลคือ... ระบบรับไม่ไหวครับ (couldn’t keep up)

ตอนนี้ Amazon กำลังแก้ไขระบบหลายอย่างครับ ที่แน่ๆ คือการแก้ปัญหา "Race Condition" (สถานการณ์ที่ระบบแย่งกันทำงาน) ที่ทำให้สองระบบมันเขียนทับงานกันเองตั้งแต่แรก และยังเพิ่มชุดทดสอบสำหรับบริการ EC2 ให้เข้มงวดขึ้นด้วย

ศาสตราจารย์ Gupta ทิ้งท้ายไว้ได้น่าคิดครับ เขาบอกว่าเหตุการณ์ล่มครั้งใหญ่แบบนี้ "มันก็เกิดขึ้นได้ครับ" (they just happen) มันไม่มีทางเลี่ยงได้ 100% หรอก "ก็เหมือนกับที่คนเราป่วยนั่นแหละ"

"แต่สิ่งที่สำคัญจริงๆ คือวิธีที่บริษัทตอบสนองต่อเหตุการณ์นั้น และการสื่อสารกับลูกค้าให้พวกเขารับทราบข้อมูลอยู่ตลอดเวลาต่างหาก... นั่นแหละคือหัวใจสำคัญ"

#DRKRIT drkrit.com #กระแสไอที #ข่าวไอที #ไทยสมาร์ทซิตี้