Istio Circuit Breaker: การปิดใช้งานคอนเทนเนอร์ที่ผิดพลาด

วันหยุดสิ้นสุดลงแล้ว และเรากลับมาอีกครั้งกับโพสต์ที่สองในซีรีส์ Istio Service Mesh

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

มันควรจะทำงานอย่างไรในอุดมคติ

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

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

มันทำงานจริงอย่างไร

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

Pool Ejection ใน Istio คืออะไร?

นี่คือจุดที่ Istio เข้ามาพร้อมกลไกการป้องกัน Circuit Breaker ซึ่งจะลบคอนเทนเนอร์ที่ผิดพลาดออกจากพูลทรัพยากรการกำหนดเส้นทางและการปรับสมดุลการโหลดชั่วคราวด้วยการนำขั้นตอนการดีดพูลออก

Istio ใช้กลยุทธ์การตรวจจับค่าผิดปกติเพื่อตรวจจับพ็อดที่ไม่ซิงค์กันและลบออกจากกลุ่มทรัพยากรเป็นระยะเวลาหนึ่ง ซึ่งเรียกว่าหน้าต่างการนอนหลับ

เพื่อแสดงวิธีการทำงานนี้ใน Kubernetes บนแพลตฟอร์ม OpenShift เรามาเริ่มด้วยภาพหน้าจอของไมโครเซอร์วิสที่กำลังทำงานปกติจากที่เก็บตัวอย่าง การสาธิตนักพัฒนา Red Hatที่นี่เรามีพ็อดสองพ็อด คือ v1 และ v2 ซึ่งแต่ละพ็อดรันคอนเทนเนอร์หนึ่งตัว เมื่อไม่ได้ใช้กฎการกำหนดเส้นทาง Istio Kubernetes จะตั้งค่าเริ่มต้นเป็นการกำหนดเส้นทางแบบ Round-Robin ที่สมดุลเท่ากัน:

การเตรียมพร้อมสำหรับความล้มเหลว

ก่อนดำเนินการ Pool Ejection เราจำเป็นต้องสร้างกฎการกำหนดเส้นทาง Istio ขึ้นมาก่อน สมมติว่าเราต้องการกระจายคำขอระหว่างพ็อดแบบ 50/50 นอกจากนี้ เราจะเพิ่มจำนวนคอนเทนเนอร์ v2 จากหนึ่งเป็นสอง ดังต่อไปนี้:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

ตอนนี้เราตั้งค่ากฎการกำหนดเส้นทางเพื่อให้การกระจายการรับส่งข้อมูลระหว่างพ็อดในอัตราส่วน 50/50

และนี่คือผลลัพธ์ของกฎนี้:

บางคนอาจพบข้อผิดพลาดกับความจริงที่ว่าหน้าจอนี้ไม่ใช่ 50/50 แต่เป็น 14:9 แต่สถานการณ์จะดีขึ้นเมื่อเวลาผ่านไป

เรากำลังทำให้เกิดข้อผิดพลาด

ตอนนี้ให้ปิดการใช้งานคอนเทนเนอร์ v2 หนึ่งในสองคอนเทนเนอร์ เพื่อให้เรามีคอนเทนเนอร์ v1 ที่มีสุขภาพดีหนึ่งคอนเทนเนอร์ คอนเทนเนอร์ v2 ที่มีสุขภาพดีหนึ่งคอนเทนเนอร์ และคอนเทนเนอร์ v2 ที่เสียหายหนึ่งคอนเทนเนอร์:

เรากำลังแก้ไขปัญหา

ตอนนี้เรามีคอนเทนเนอร์ที่ล้มเหลวแล้ว และถึงเวลาที่จะทำการดีดพูลออก (Pool Ejection) โดยใช้การกำหนดค่าแบบง่ายๆ เราจะยกเว้นคอนเทนเนอร์ที่ล้มเหลวนี้ออกจากการกำหนดเส้นทางทั้งหมดเป็นเวลา 15 วินาที โดยหวังว่ามันจะกู้คืนได้เอง (ไม่ว่าจะโดยการรีสตาร์ทหรือกู้คืนประสิทธิภาพ) นี่คือลักษณะของการกำหนดค่าและผลลัพธ์:

อย่างที่คุณเห็น คอนเทนเนอร์ v2 ที่มีปัญหาจะไม่ถูกใช้สำหรับการกำหนดเส้นทางคำขออีกต่อไป เนื่องจากถูกลบออกจากพูลแล้ว อย่างไรก็ตาม หลังจากผ่านไป 15 วินาที คอนเทนเนอร์จะกลับเข้าสู่พูลโดยอัตโนมัติ อันที่จริง เราได้สาธิตวิธีการทำงานของ Pool Ejection ไปแล้ว

มาเริ่มสร้างสถาปัตยกรรมกันเถอะ

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

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

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

เบรกเกอร์ในเชิงทฤษฎี

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

สิ่งสำคัญที่ต้องทราบคือ ทั้งหมดนี้เกิดขึ้นที่ระดับสถาปัตยกรรมระบบ ดังนั้น ในบางจุด คุณจำเป็นต้องสอนแอปพลิเคชันของคุณให้ทำงานร่วมกับ Circuit Breaker เช่น การกำหนดค่าเริ่มต้นในการตอบสนอง หรือหากเป็นไปได้ ให้ละเลยการมีอยู่ของบริการ ซึ่งทำได้โดยใช้รูปแบบ Bulkhead แต่อยู่นอกเหนือขอบเขตของบทความนี้

เบรกเกอร์ไฟฟ้าในทางปฏิบัติ

สำหรับตัวอย่างนี้ เราจะรันไมโครเซอร์วิสคำแนะนำสองเวอร์ชันบน OpenShift เวอร์ชัน 1 จะทำงานตามปกติ แต่ในเวอร์ชัน 2 เราจะเพิ่มการหน่วงเวลาเพื่อจำลองความล่าช้าของเซิร์ฟเวอร์ หากต้องการดูผลลัพธ์ ให้ใช้เครื่องมือ การล้อม:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

ทุกอย่างดูเหมือนจะทำงานได้ แต่แลกมาด้วยอะไร? ตอนแรกเรามีความพร้อมใช้งาน 100% แต่ลองพิจารณาให้ละเอียดขึ้น ระยะเวลาการทำธุรกรรมสูงสุดอยู่ที่ 12 วินาที เห็นได้ชัดว่านี่เป็นปัญหาคอขวด และจำเป็นต้องได้รับการแก้ไข

ในการดำเนินการนี้ เราจะใช้ Istio เพื่อป้องกันการเรียกใช้คอนเทนเนอร์ที่ทำให้ช้าลง นี่คือลักษณะการกำหนดค่าที่เกี่ยวข้องโดยใช้ Circuit Breaker:

บรรทัดสุดท้ายที่มีพารามิเตอร์ httpMaxRequestsPerConnection ระบุว่าควรปิดการเชื่อมต่อเมื่อพยายามสร้างการเชื่อมต่อที่สองเพิ่มเติมจากที่มีอยู่เดิม เนื่องจากคอนเทนเนอร์ของเรากำลังจำลองบริการที่ช้า สถานการณ์เช่นนี้จึงจะเกิดขึ้นเป็นระยะๆ จากนั้น Istio จะแสดงข้อผิดพลาด 503 และนี่คือสิ่งที่ Siege จะแสดง:

โอเค เรามี Circuit Breaker แล้ว ต่อไปจะเป็นอย่างไร?

ดังนั้นเราจึงได้ดำเนินการปิดระบบอัตโนมัติโดยไม่ต้องแตะต้องซอร์สโค้ดของบริการนั้นๆ เอง ด้วยการใช้ Circuit Breaker และขั้นตอนการดีดพูลที่อธิบายไว้ข้างต้น เราสามารถลบคอนเทนเนอร์ที่ช้าออกจากพูลทรัพยากรได้จนกว่าคอนเทนเนอร์เหล่านั้นจะกลับสู่สภาวะปกติ และตรวจสอบสถานะตามช่วงเวลาที่กำหนด ซึ่งในตัวอย่างของเราคือทุกๆ สองนาที (พารามิเตอร์ sleepWindow)

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

ในโพสต์ถัดไป: เราจะครอบคลุมการติดตามและการตรวจสอบ ซึ่งสร้างไว้ใน Istio หรือเพิ่มเข้าไปได้ง่าย รวมถึงวิธีการนำข้อผิดพลาดเข้าสู่ระบบโดยเจตนา

ที่มา: will.com