GitHub รายงานเหตุการณ์เว็บล่มเมื่อวันที่ 22 ตุลาคมที่ผ่านมา พร้อมกับระบุถึงบทเรียนที่ได้จากการล่มครั้งนี้

เรื่องทั้งหมดเริ่มจากการบำรุงรักษาอุปกรณ์ไฟเบอร์ 100G ที่เริ่มทำงานไม่เต็มประสิทธิภาพ โดยการเปลี่ยนอุปกรณ์ทำให้เน็ตเวิร์คที่เชื่อมระหว่างศูนย์ข้อมูลหลัก คือฝั่งตะวันตก (US West) และฝั่งตะวันออก (US East) ดับไปเป็นเวลา 43 วินาที

ระบบฐานข้อมูลของ GitHub ใช้คลัสเตอร์ MySQL โดยก่อนเน็ตเวิร์คดับ เซิร์ฟเวอร์หลัก (primary) ที่รับข้อมูลเขียนฐานข้อมูลอยู่ที่ US East โดยคลัสเตอร์ถูกควบคุมด้วย Orchestrator ของ GitHub เอง เมื่อเน็ตเวิร์คดับไป ตัว Orchestrator ก็พยายามเลือกเซิร์ฟเวอร์ในศูนย์ข้อมูล US West เป็นเซิร์ฟเวอร์หลักใหม่ และส่งข้อมูลการเขียนลงฐานข้อมูลไปยัง US West อย่างไรก็ตาม มีข้อมูลการเขียนส่วนหนึ่งที่ US East เขียนไปแล้ว ไม่กี่วินาที แต่ US West ไม่ได้รับ ทำให้คลัสเตอร์ไม่สามารถกลับมาซิงก์กันได้

ทีมงานตัดสินใจหยุดงานที่ต้องเขียนลงฐานข้อมูล เช่น การรับ push เพื่อรักษาความถูกต้องของข้อมูลเอาไว้ โดยสถานะสุดท้ายคือ US West มีข้อมูลที่ US East ไม่มีอยู่นาน 40 นาที ขณะที่ US East มีข้อมูลที่ US West ไม่มีอยู่ไม่กี่วินาที

หลังจากนั้นทางออกคือการสร้างคลัสเตอร์ขึ้นใหม่จากไฟล์แบ็กอัพ กระบวนการ restore ฐานข้อมูลขนาดใหญ่ปกติก็ใช้เวลาหลายชั่วโมงอยู่แล้ว แม้นโยบายของ GitHub จะสำรองฐานข้อมูลทุก 4 ชั่วโมงและทดสอบไฟล์สำรองอย่างน้อยวันละครั้ง แต่ก็ไม่เคยมีการซ้อมสร้างคลัสเตอร์ใหม่ทั้งหมดจริงๆ ทำให้ใช้เวลานาน และหลังจากกู้เรียบร้อยแล้วก็ยังต้องวิเคราะห์ล็อก MySQL ว่ามีข้อมูลอะไรผิดพลาดหรือไม่

ทาง GitHub ระบุว่าหลังจากนี้จะคอนฟิก Orchestrator ใหม่ ให้เลี่ยงการเลือกเซิร์ฟเวอร์หลักข้ามทวีป ซึ่งทำให้คลัสเตอร์แยกเป็นสองส่วนในครั้งนี้ ทาง GitHub เชื่อว่าการย้ายเซิร์ฟเวอร์หลักในโซนเดียวกันโดยปกติค่อนข้างปลอดภัย

ในระยะยาว ทางบริษัทมีแนวทางจะออกแบบให้ระบบทนทานมากขึ้นโดยเตรียมออกแบบ active/active/active แนวคิดคือศูนย์ข้อมูลหนึ่งสามารถล่มไปทั้งศูนย์ได้โดยผู้ใช้ยังไม่ได้รับผลกระทบ

ที่มา - GitHub Blog