บันทึก. แปล: ในช่วงต้นเดือนสิงหาคม Red Hat เปิดเผยต่อสาธารณะเกี่ยวกับการแก้ปัญหาการเข้าถึงที่ผู้ใช้บริการพบในเดือนก่อน (ขึ้นอยู่กับการลงทะเบียนสำหรับคอนเทนเนอร์อิมเมจ ซึ่งบริษัทได้รับพร้อมกับการซื้อ CoreOS) ไม่ว่าคุณจะสนใจบริการนี้หรือไม่ เส้นทางที่วิศวกร SRE ของบริษัทใช้ในการวินิจฉัยและกำจัดสาเหตุของอุบัติเหตุนั้นถือเป็นคำแนะนำ
ในวันที่ 19 พฤษภาคม ในตอนเช้า (เวลาออมแสงตะวันออก, EDT) บริการ quay.io ขัดข้อง อุบัติเหตุดังกล่าวส่งผลกระทบต่อทั้งผู้บริโภค quay.io และโครงการโอเพ่นซอร์สที่ใช้ quay.io เป็นแพลตฟอร์มสำหรับการสร้างและจัดจำหน่ายซอฟต์แวร์ เรดแฮทให้ความสำคัญกับความไว้วางใจของทั้งสองฝ่าย
ทีมวิศวกรของ SRE เข้ามามีส่วนร่วมทันทีและพยายามทำให้บริการ Quay มีเสถียรภาพโดยเร็วที่สุด อย่างไรก็ตาม ในขณะที่พวกเขากำลังทำเช่นนี้ ลูกค้าสูญเสียความสามารถในการผลักดันอิมเมจใหม่ๆ และมีเพียงบางครั้งเท่านั้นที่พวกเขาสามารถดึงอิมเมจที่มีอยู่ได้ ด้วยเหตุผลที่ไม่ทราบสาเหตุ ฐานข้อมูล quay.io จึงถูกบล็อกหลังจากปรับขนาดบริการให้เต็มประสิทธิภาพ
«มีการเปลี่ยนแปลงอย่างไร" - นี่เป็นคำถามแรกที่มักถามในกรณีเช่นนี้ เราสังเกตเห็นว่าไม่นานก่อนเกิดปัญหา คลัสเตอร์ OpenShift Dedicated (ซึ่งรัน quay.io) ก็เริ่มอัปเดตเป็นเวอร์ชัน 4.3.19 เนื่องจาก quay.io ทำงานบน Red Hat OpenShift Dedicated (OSD) การอัพเดตเป็นประจำจึงเป็นกิจวัตรและไม่เคยทำให้เกิดปัญหา นอกจากนี้ ในช่วงหกเดือนที่ผ่านมา เราได้อัปเกรดคลัสเตอร์ Quay หลายครั้งโดยไม่หยุดชะงักในการให้บริการ
ขณะที่เราพยายามกู้คืนบริการ วิศวกรคนอื่นๆ ก็เริ่มเตรียมคลัสเตอร์ OSD ใหม่ด้วยซอฟต์แวร์เวอร์ชันก่อนหน้า เพื่อว่าหากมีสิ่งใดเกิดขึ้น พวกเขาสามารถปรับใช้ทุกอย่างบนนั้นได้
การวิเคราะห์สาเหตุที่แท้จริง
อาการหลักของความล้มเหลวคือการเชื่อมต่อฐานข้อมูลจำนวนมากถล่มทลาย ซึ่งทำให้อินสแตนซ์ MySQL ไม่สามารถใช้งานได้อย่างมีประสิทธิภาพ ทำให้ยากต่อการวินิจฉัยปัญหา เราได้กำหนดขีดจำกัดจำนวนการเชื่อมต่อสูงสุดจากไคลเอนต์เพื่อช่วยทีม SRE ประเมินปัญหา เราไม่สังเกตเห็นการรับส่งข้อมูลที่ผิดปกติไปยังฐานข้อมูล อันที่จริง คำขอส่วนใหญ่ถูกอ่าน และมีเพียงไม่กี่คำขอเท่านั้นที่ถูกเขียน
นอกจากนี้เรายังพยายามระบุรูปแบบในการรับส่งข้อมูลฐานข้อมูลที่อาจทำให้เกิดหิมะถล่มนี้ได้ อย่างไรก็ตาม เราไม่พบรูปแบบใดๆ ในบันทึก ในขณะที่รอคลัสเตอร์ใหม่ที่มี OSD 4.3.18 ให้พร้อม เราก็พยายามเปิดตัวพ็อด quay.io ต่อไป ทุกครั้งที่คลัสเตอร์มีความจุเต็ม ฐานข้อมูลจะหยุดทำงาน ซึ่งหมายความว่าจำเป็นต้องรีสตาร์ทอินสแตนซ์ RDS นอกเหนือจากพ็อด quay.io ทั้งหมด
ในช่วงเย็น เราได้ทำให้บริการมีความเสถียรในโหมดอ่านอย่างเดียวและปิดใช้งานฟังก์ชันที่ไม่จำเป็นให้ได้มากที่สุด (เช่น การรวบรวมขยะเนมสเปซ) เพื่อลดภาระในฐานข้อมูล อาการค้างได้หยุดลงแล้ว แต่ไม่เคยพบสาเหตุ. คลัสเตอร์ OSD ใหม่พร้อมแล้ว และเราได้ย้ายบริการ การรับส่งข้อมูลที่เชื่อมต่อ และการตรวจสอบอย่างต่อเนื่อง
Quay.io ทำงานได้อย่างเสถียรบนคลัสเตอร์ OSD ใหม่ ดังนั้นเราจึงกลับไปที่บันทึกฐานข้อมูล แต่ไม่พบความสัมพันธ์ที่จะอธิบายการอุดตันได้ วิศวกรของ OpenShift ทำงานร่วมกับเราเพื่อทำความเข้าใจว่าการเปลี่ยนแปลงใน Red Hat OpenShift 4.3.19 อาจทำให้เกิดปัญหากับ Quay หรือไม่ อย่างไรก็ตามไม่พบสิ่งใดและ ไม่สามารถจำลองปัญหาในสภาพห้องปฏิบัติการได้.
ความล้มเหลวครั้งที่สอง
เมื่อวันที่ 28 พฤษภาคม ก่อนเที่ยง EDT ไม่นาน quay.io ก็เกิดขัดข้องอีกครั้งด้วยอาการเดิมคือ ฐานข้อมูลถูกบล็อก และอีกครั้งที่เราทุ่มเทความพยายามทั้งหมดในการสืบสวน ก่อนอื่นจำเป็นต้องคืนค่าบริการก่อน อย่างไรก็ตาม คราวนี้การรีบูต RDS และการรีสตาร์ทพ็อด quay.io ไม่ได้ทำอะไรเลย: การเชื่อมต่อที่ถล่มทลายอีกครั้งได้ท่วมฐาน แต่ทำไม?
Quay เขียนด้วยภาษา Python และแต่ละพ็อดทำงานเป็นคอนเทนเนอร์เสาหินเดียว รันไทม์ของคอนเทนเนอร์รันงานหลายงานพร้อมกันพร้อมกัน เราใช้ห้องสมุด gevent ภายใต้ gunicorn เพื่อประมวลผลคำขอทางเว็บ เมื่อมีคำขอเข้ามาใน Quay (ผ่าน API ของเราเองหรือผ่าน API ของ Docker) คำขอนั้นจะถูกมอบหมายให้เป็นผู้ปฏิบัติงาน gevent โดยทั่วไปแล้วผู้ปฏิบัติงานรายนี้ควรติดต่อกับฐานข้อมูล หลังจากความล้มเหลวครั้งแรก เราพบว่าผู้ปฏิบัติงาน gevent กำลังเชื่อมต่อกับฐานข้อมูลโดยใช้การตั้งค่าเริ่มต้น
เมื่อพิจารณาจากจำนวนพ็อด Quay ที่มีนัยสำคัญและคำขอที่เข้ามานับพันคำขอต่อวินาที การเชื่อมต่อฐานข้อมูลจำนวนมากในทางทฤษฎีจึงอาจล้นหลามอินสแตนซ์ MySQL ได้ จากการตรวจสอบ เป็นที่ทราบกันว่า Quay ประมวลผลคำขอโดยเฉลี่ย 5 คำขอต่อวินาที จำนวนการเชื่อมต่อกับฐานข้อมูลใกล้เคียงกัน การเชื่อมต่อ 5 ครั้งอยู่ในความสามารถของอินสแตนซ์ RDS ของเรา (ซึ่งไม่สามารถพูดได้ประมาณหมื่น) ด้วยเหตุผลบางประการ จำนวนการเชื่อมต่อเพิ่มขึ้นอย่างไม่คาดคิดอย่างไรก็ตาม เราไม่ได้สังเกตเห็นความสัมพันธ์ใดๆ กับคำขอที่เข้ามา
ครั้งนี้เราตั้งใจแน่วแน่ที่จะค้นหาและกำจัดสาเหตุของปัญหา และไม่จำกัดตัวเองอยู่เพียงการรีบูตเครื่อง ไปยังฐานรหัส Quay มีการเปลี่ยนแปลงเพื่อจำกัดจำนวนการเชื่อมต่อกับฐานข้อมูลสำหรับผู้ปฏิบัติงานแต่ละคน เกเวนต์ หมายเลขนี้กลายเป็นพารามิเตอร์ในการกำหนดค่า: สามารถเปลี่ยนได้ทันทีโดยไม่ต้องสร้างอิมเมจคอนเทนเนอร์ใหม่ หากต้องการทราบว่าสามารถจัดการการเชื่อมต่อได้มากเพียงใด เราได้ทำการทดสอบหลายครั้งในสภาพแวดล้อมชั่วคราว โดยตั้งค่าต่างๆ เพื่อดูว่าสิ่งนี้จะส่งผลต่อสถานการณ์การทดสอบโหลดอย่างไร จึงได้มีการค้นพบว่า Quay เริ่มส่งข้อผิดพลาด 502 รายการเมื่อจำนวนการเชื่อมต่อเกิน 10 ครั้ง
เราปรับใช้เวอร์ชันใหม่นี้กับการใช้งานจริงทันที และเริ่มตรวจสอบกำหนดการเชื่อมต่อฐานข้อมูล ในอดีตฐานถูกล็อคไว้หลังจากผ่านไปประมาณ 20 นาที หลังจากผ่านไป 30 นาทีอย่างไร้ปัญหา เราก็มีความหวัง และอีกชั่วโมงต่อมาเราก็มีความมั่นใจ เราคืนค่าการเข้าชมไซต์และเริ่มการวิเคราะห์หลังชันสูตร
มีการจัดการเพื่อหลีกเลี่ยงปัญหาที่นำไปสู่การปิดกั้น เรายังไม่พบเหตุผลที่แท้จริงของมัน. ได้รับการยืนยันแล้วว่าไม่เกี่ยวข้องกับการเปลี่ยนแปลงใดๆ ใน OpenShift 4.3.19 เนื่องจากสิ่งเดียวกันนี้เกิดขึ้นในเวอร์ชัน 4.3.18 ซึ่งก่อนหน้านี้ทำงานร่วมกับ Quay โดยไม่มีปัญหาใดๆ
เห็นได้ชัดว่ามีสิ่งอื่นแอบแฝงอยู่ในกลุ่ม
การศึกษาโดยละเอียด
Quay.io ใช้การตั้งค่าเริ่มต้นเพื่อเชื่อมต่อกับฐานข้อมูลเป็นเวลาหกปีโดยไม่มีปัญหาใดๆ มีอะไรเปลี่ยนแปลง? เห็นได้ชัดว่าปริมาณการใช้งานบน quay.io เพิ่มขึ้นอย่างต่อเนื่องตลอดเวลา ในกรณีของเรา ดูเหมือนว่ามีการถึงค่าเกณฑ์บางอย่าง ซึ่งทำหน้าที่เป็นตัวกระตุ้นให้เกิดการเชื่อมต่อที่ล้นหลาม เรายังคงศึกษาบันทึกของฐานข้อมูลต่อไปหลังจากความล้มเหลวครั้งที่สอง แต่ไม่พบรูปแบบหรือความสัมพันธ์ที่ชัดเจนใดๆ
ในระหว่างนี้ ทีม SRE กำลังทำงานเพื่อปรับปรุงความสามารถในการสังเกตคำขอของ Quay และสถานภาพการบริการโดยรวม มีการใช้เมตริกและแดชบอร์ดใหม่แล้วแสดงให้เห็นว่าส่วนใดของ Quay ที่เป็นที่ต้องการของลูกค้ามากที่สุด
Quay.io ทำงานได้ดีจนถึงวันที่ 9 มิถุนายน เช้านี้ (EDT) เราเห็นการเพิ่มขึ้นอย่างมากของจำนวนการเชื่อมต่อฐานข้อมูลอีกครั้ง ครั้งนี้ไม่มีการหยุดทำงานเนื่องจากพารามิเตอร์ใหม่จำกัดจำนวนและไม่อนุญาตให้มีปริมาณงานเกิน MySQL อย่างไรก็ตาม เป็นเวลาประมาณครึ่งชั่วโมง ผู้ใช้หลายคนสังเกตเห็นว่า quay.io ทำงานช้า เรารวบรวมข้อมูลที่เป็นไปได้ทั้งหมดอย่างรวดเร็วโดยใช้เครื่องมือตรวจสอบที่เพิ่มเข้ามา จู่ๆ ก็มีรูปแบบหนึ่งเกิดขึ้น
ก่อนที่การเชื่อมต่อจะพุ่งสูงขึ้น มีคำขอจำนวนมากไปยัง App Registry API. App Registry เป็นฟีเจอร์ที่ไม่ค่อยมีใครรู้จักของ quay.io ช่วยให้คุณสามารถจัดเก็บสิ่งต่างๆ เช่น แผนภูมิ Helm และคอนเทนเนอร์ที่มีข้อมูลเมตาที่หลากหลาย ผู้ใช้ quay.io ส่วนใหญ่ใช้งานฟีเจอร์นี้ไม่ได้ แต่ Red Hat OpenShift ก็ใช้งานฟีเจอร์นี้อยู่ OperatorHub ซึ่งเป็นส่วนหนึ่งของ OpenShift จะจัดเก็บตัวดำเนินการทั้งหมดใน App Registry ตัวดำเนินการเหล่านี้เป็นพื้นฐานสำหรับระบบนิเวศปริมาณงานของ OpenShift และรูปแบบการดำเนินงานที่เน้นคู่ค้าเป็นศูนย์กลาง (การดำเนินงานวันที่ 2)
คลัสเตอร์ OpenShift 4 แต่ละคลัสเตอร์ใช้ตัวดำเนินการจาก OperatorHub ในตัวเพื่อเผยแพร่แค็ตตาล็อกของตัวดำเนินการที่พร้อมสำหรับการติดตั้ง และจัดเตรียมการอัปเดตให้กับตัวดำเนินการที่ติดตั้งไว้แล้ว ด้วยความนิยมที่เพิ่มขึ้นของ OpenShift 4 จำนวนคลัสเตอร์ทั่วโลกก็เพิ่มขึ้นเช่นกัน แต่ละคลัสเตอร์เหล่านี้จะดาวน์โหลดเนื้อหาตัวดำเนินการเพื่อเรียกใช้ OperatorHub ในตัว โดยใช้ App Registry ภายใน quay.io เป็นแบ็กเอนด์ ในการค้นหาสาเหตุของปัญหา เราพลาดความจริงที่ว่าเมื่อ OpenShift ได้รับความนิยมเพิ่มขึ้นเรื่อยๆ ภาระของหนึ่งในฟังก์ชัน quay.io ที่ไม่ค่อยได้ใช้ก็เพิ่มขึ้นเช่นกัน.
เราได้ทำการวิเคราะห์การรับส่งข้อมูลคำขอ App Registry และดูรหัสรีจิสทรี ข้อบกพร่องถูกเปิดเผยทันทีเนื่องจากการสืบค้นฐานข้อมูลไม่ได้เกิดขึ้นอย่างเหมาะสมที่สุด เมื่อโหลดน้อยก็ไม่ก่อปัญหา แต่เมื่อโหลดเพิ่มขึ้นก็กลายเป็นต้นเหตุของปัญหา App Registry พบว่ามีปลายทางที่มีปัญหาสองจุดซึ่งไม่ตอบสนองต่อการโหลดที่เพิ่มขึ้นได้ดี โดยจุดแรกให้รายการแพ็คเกจทั้งหมดในที่เก็บ ส่วนจุดที่สองส่งคืน blobs ทั้งหมดสำหรับแพ็คเกจ
ขจัดสาเหตุ
ตลอดสัปดาห์หน้า เราใช้เวลาเพิ่มประสิทธิภาพโค้ดของ App Registry และสภาพแวดล้อมของมัน การสืบค้น SQL ที่ไม่มีประสิทธิภาพอย่างชัดเจนได้รับการแก้ไขและการเรียกคำสั่งที่ไม่จำเป็นถูกกำจัด tar (มันถูกรันทุกครั้งที่ดึงข้อมูล blobs) เพิ่มแคชทุกครั้งที่เป็นไปได้ จากนั้นเราทำการทดสอบประสิทธิภาพอย่างกว้างขวางและเปรียบเทียบความเร็วของ App Registry ก่อนและหลังการเปลี่ยนแปลง
คำขอ API ที่ก่อนหน้านี้ใช้เวลาถึงครึ่งนาทีจะเสร็จสิ้นแล้วในหน่วยมิลลิวินาที. สัปดาห์หน้าเราได้ปรับใช้การเปลี่ยนแปลงกับการใช้งานจริง และตั้งแต่นั้นมา quay.io ก็ทำงานได้อย่างเสถียร ในช่วงเวลานี้ มีการรับส่งข้อมูลบนตำแหน่งข้อมูล App Registry เพิ่มขึ้นอย่างมากหลายครั้ง แต่การปรับปรุงดังกล่าวช่วยป้องกันการหยุดทำงานของฐานข้อมูลได้
เราได้เรียนรู้อะไรบ้าง?
เป็นที่ชัดเจนว่าบริการใดๆ พยายามหลีกเลี่ยงการหยุดทำงาน ในกรณีของเรา เราเชื่อว่าการขัดข้องที่เกิดขึ้นเมื่อเร็วๆ นี้ช่วยให้ quay.io ดีขึ้นได้ เราได้เรียนรู้บทเรียนสำคัญบางประการที่เราต้องการแบ่งปัน:
- ข้อมูลเกี่ยวกับผู้ที่ใช้บริการของคุณและวิธีที่จะไม่ฟุ่มเฟือย. เนื่องจาก Quay “เพิ่งใช้งานได้” เราจึงไม่ต้องใช้เวลาเพิ่มประสิทธิภาพการรับส่งข้อมูลและจัดการภาระงาน ทั้งหมดนี้ทำให้เกิดความรู้สึกผิดๆ เกี่ยวกับความปลอดภัยที่บริการสามารถขยายขนาดได้อย่างไม่มีกำหนด
- เมื่อบริการล่มสลาย การสำรองและใช้งานเป็นสิ่งสำคัญที่สุด. เนื่องจาก Quay ยังคงประสบปัญหาจากฐานข้อมูลที่ถูกล็อคในระหว่างการหยุดทำงานครั้งแรก ขั้นตอนมาตรฐานของเราจึงไม่มีผลกระทบตามที่ตั้งใจไว้ และเราไม่สามารถกู้คืนบริการโดยใช้ขั้นตอนเหล่านั้นได้ สิ่งนี้นำไปสู่สถานการณ์ที่ต้องใช้เวลาในการวิเคราะห์และรวบรวมข้อมูลโดยหวังว่าจะค้นหาสาเหตุที่แท้จริง แทนที่จะมุ่งเน้นไปที่การฟื้นฟูฟังก์ชันการทำงานทั้งหมด
- ประเมินผลกระทบของฟีเจอร์บริการแต่ละรายการ. ลูกค้าไม่ค่อยได้ใช้ App Registry ดังนั้นจึงไม่ใช่เรื่องสำคัญสำหรับทีมของเรา เมื่อคุณสมบัติบางอย่างของผลิตภัณฑ์แทบจะไม่ได้ใช้งาน จุดบกพร่องก็แทบจะไม่ปรากฏ และนักพัฒนาก็หยุดตรวจสอบโค้ด เป็นเรื่องง่ายที่จะตกเป็นเหยื่อของความเข้าใจผิดว่านี่คือวิธีที่ควรจะเป็น จนกระทั่งหน่วยงานนั้นพบว่าตัวเองเป็นศูนย์กลางของเหตุการณ์สำคัญทันที
ทำอะไรต่อไป
งานเพื่อรับรองเสถียรภาพของบริการไม่เคยหยุดนิ่งและเรากำลังปรับปรุงอย่างต่อเนื่อง เนื่องจากปริมาณการรับส่งข้อมูลบน quay.io ยังคงเพิ่มขึ้นอย่างต่อเนื่อง เราตระหนักดีว่าเรามีหน้าที่รับผิดชอบในการทำทุกอย่างเท่าที่ทำได้เพื่อรักษาความไว้วางใจของลูกค้า ดังนั้นเราจึงกำลังทำงานดังต่อไปนี้:
- ปรับใช้แบบจำลองฐานข้อมูลแบบอ่านอย่างเดียวเพื่อช่วยบริการจัดการการรับส่งข้อมูลที่เหมาะสมในกรณีที่เกิดปัญหากับอินสแตนซ์ RDS หลัก
- กำลังอัปเดตอินสแตนซ์ RDS เวอร์ชันปัจจุบันไม่ใช่ปัญหา แต่เราเพียงต้องการกำจัดเส้นทางที่ผิดพลาด (ซึ่งเราติดตามในระหว่างที่ล้มเหลว) การปรับปรุงซอฟต์แวร์ให้ทันสมัยอยู่เสมอจะช่วยลดปัจจัยอื่นในกรณีที่ไฟฟ้าขัดข้องในอนาคต
- แคชเพิ่มเติมทั่วทั้งคลัสเตอร์ เรายังคงมองหาพื้นที่ที่แคชสามารถลดภาระในฐานข้อมูลได้
- การเพิ่มไฟร์วอลล์แอปพลิเคชันเว็บ (WAF) เพื่อดูว่าใครกำลังเชื่อมต่อกับ quay.io และเพราะเหตุใด
- ตั้งแต่การเปิดตัวครั้งถัดไป คลัสเตอร์ Red Hat OpenShift จะละทิ้ง App Registry หันไปใช้ Operator Catalogs โดยอิงจากคอนเทนเนอร์อิมเมจที่มีอยู่ใน quay.io
- การทดแทน App Registry ในระยะยาวอาจสามารถรองรับข้อกำหนดเฉพาะของ Open Container Initiative (OCI) ได้ ปัจจุบันมีการใช้งานเป็นฟังก์ชัน Native Quay และจะพร้อมใช้งานสำหรับผู้ใช้เมื่อข้อกำหนดได้รับการสรุปแล้ว
ทั้งหมดข้างต้นเป็นส่วนหนึ่งของการลงทุนอย่างต่อเนื่องของ Red Hat ใน quay.io ในขณะที่เราย้ายจากทีม "สไตล์สตาร์ทอัพ" ขนาดเล็กไปสู่แพลตฟอร์มที่ขับเคลื่อนด้วย SRE ที่เป็นผู้ใหญ่ เรารู้ว่าลูกค้าของเราจำนวนมากพึ่งพา quay.io ในการทำงานประจำวัน (รวมถึง Red Hat ด้วย!) และเราพยายามที่จะโปร่งใสมากที่สุดเท่าที่จะเป็นไปได้เกี่ยวกับการหยุดทำงานล่าสุดและความพยายามอย่างต่อเนื่องในการปรับปรุง
ปล.จากผู้แปล
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «'
ที่มา: will.com