เมื่อต้นปีที่ผ่านมา Slack มีเหตุล่ม 3 ชั่วโมง สัปดาห์นี้ทีมงานก็ออกมารายงานถึงสาเหตุของการล่มครั้งนั้น โดยจุดเริ่มต้นเกิดระหว่างการอัพเกรด Consul แม้จะอัพเกรดเพียงบางส่วน

ทาง Slack ใช้ Consul สำหรับทำ service discovery ให้กับ memcached กระบวนการอัพเกรดครั้งนั้นเป็นการอัพเกรดทีละ 25% โดยอัพเกรด 25% แรกไปก่อนแล้วและไม่มีปัญหาอะไร โดยระหว่างอัพเกรด โหนดที่อัพเกรดจะถอดตัวออกไปและใส่โหนดใหม่ที่ cache ว่างเข้ามาแทน แต่ระหว่างการอัพเดตครั้งนั้นระบบมีโหลดสูง และเมื่อกำลังอัพเกรดก็มี memcached บางส่วนถูกล้างข้อมูล

ปัญหาเกิดขึ้นเมื่อการคิวรี Group Direct Message (GDM) นั้น ไม่ได้ค้นหาแยกตาม shard ของคลัสเตอร์ Vitess (คลัสเตอร์ MySQL) แต่กลับทำ scatter query ส่งคิวรีไปทุก shard เพื่อหาข้อมูล และเมื่อแคชหายไป ตัวไคลเอนต์ก็จะยิงคิวรีเข้า Vitess ทำให้โหลดโดยรวมสูงขึ้น คลัสเตอร์ Vitess เริ่มเกิด timeout ทำให้ข้อมูลไม่ถูกแคช เกิดเป็นปัญหาวนลูปคือไคลเอนต์ที่ขอข้อมูลไม่ได้ก็พยายามยิงคิวรีเข้าไปเรื่อยๆ และแคชก็ไม่มีข้อมูลทำให้ยิงคิวรีตรงเข้า Vitess ไปเรื่อยๆ อีกเช่นกัน

ทาง Slack สรุปบทเรียนโดยปรับกระบวนการอัพเกรด Consul ไม่ให้สร้างปัญหาแบบนี้อีก และแก้ไข scatter query เดิมให้คิวรีแยกตาม shard เพื่อไม่ให้เกิดโหลดสูงอีกครั้ง

ที่มา - Slack