สรุปการอ่านหนังสือ Release It 2nd edition บทที่ 6 เรื่อง Stability Patterns

ในช่วงวันหยุดหยิบหนังสือ Release It 2nd edition มาอ่าน เน้นบทที่ 6 ว่าด้วยเรื่อง Stability Patterns ซึ่งอธิบายถึงรูปแบบของการวางสถาปัตยกรรมของระบบที่ดี เป็นแนวทางในการออกแบบระบบ เพื่อลด ขจัดปัดเป่า จากปัญหาต่าง ๆ ที่อาจจะเกิดขึ้น หรือลดความอันตรายจากข้อผิดพลาดต่าง ๆ ลงไป

ไม่ใช่ต้องตื่นมากดึก ๆ เพื่อมาแก้ไขระบบ ไม่ใช่ต้องยกเลิกงานทั้งหมด เพื่อมาแก้ไขระบบ ถ้าเป็นแบบนี้คงไม่ต้องทำอะไรกันพอดี !!

ดังนั้นมาสร้างระบบดี ๆ กันหน่อย

โดยในหนังสือนั้นมีรูปแบบที่แนะนำมากมาย

ประกอบไปด้วย

• Timeout
• Circuit breaker
• Bulkheads
• Steady state
• Failfast
• Let It crash
• Test harnesses
• Decouple middleware
• Shed load
• Create back pressure
• Governor

มันจะเยอะไปไหนเนี่ย ? มาดูรายละเอียดแบบคร่าว ๆ ของแต่ละเรื่องกันหน่อย ซึ่งเลือก Timeout กับ Circuit breaker มาอธิบาย เพราะว่าน่าจะใช้บ่อยสุดแล้ว แต่เรื่องอื่น ๆ ก็น่าสนใจและจำเป็นต้องรู้เช่นกัน มาเริ่มกันดีกว่า

Timeout

น่าจะเป็นเรื่องปกติ ๆ ที่ใคร ๆ ก็ต้องกำหนด timeout หรือเวลาการรอสิ่งต่าง ๆ ยกตัวอย่างเช่น

• การเชื่อมต่อไปยัง service ต่าง ๆ
• การเชื่อมต่อผ่านระบบ network
• การเชื่อมต่อไปยัง remote file system

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

จากบทความเรื่อง Microservices Aren’t Magic: Handling Timeouts อธิบายเรื่องของ Timeout ได้อย่างน่าสนใจ ลองอ่านเพิ่มเติมได้

ถ้าหมดเวลาที่รอแล้วก็จะโยน error ออกมา จากนั้นก็ทำการจัดการหรือ handle ต่อไป ว่าจะทำอย่างไรต่อไป ขึ้นอยู่กับ use case ของการทำงาน เช่น

• แจ้งผู้ใช้งานไปว่าระบบมีความผิดพลาด ให้ลองใหม่
• ระบบทำงาน retry หรือลองทำงานใหม่อีกครั้ง ซึ่งจะมีการกำหนด interval การทำงานหใม่อีกด้วย รวมทั้งมีจำนวนการ retry สูงสุดไว้ด้วย

ดังนั้นเราทำการกำหนด timeout ของการทำงานผ่านระบบ network ไว้หรือยัง เพราะว่าส่วนใหญ่จะไม่กำหนดนะ หรือหนักกว่านั้น ทำการกำหนด timeout ไว้นานมาก ๆ นั่นคือผู้ใช้งานต้องรอไปเรื่อย ๆ หรือ ตลอดไปหรือไงนะ !! ยังไม่พอ ในระบบของเรานั้นมีส่วนจัดการเกี่ยวกับ timeout กี่ที่กันนะ ? ถ้าบอกว่าเยอะ หลายที่เลย หมายความว่า การจัดการลำบากมาก ๆ !! ดังนั้นควรรวมมาไว้ที่เดียวดีกว่านะ ยกตัวอย่างการใช้งาน gateway เพื่อจัดการเรื่อง

• การจัดการ connection ต่าง ๆ
• การจัดการความผิดพลาดต่าง ๆ
• การจัดการการดึงข้อมูลจาก database
• การจัดการการประมวลผลที่ใช้เวลานาน ๆ

จะทำให้เราจัดการปัญหาต่าง ๆ ที่เกิดขึ้นได้ง่ายขึ้น ด้วยรูปแบบที่เรียกว่า Circuit Breaker ต่อไป

Circuit Breaker

ชื่อมันคุ้น ๆ นะ ตัดก่อนตาย เตือนก่อนวายวอด นั่นมัน Safe-T-Cut นี่หว่า มาดูในส่วนของ software กันบ้าง หลังจากที่เกิดปัญหาขึ้นมาแล้ว เราจะทำอย่างไรกันต่อดี ระบบที่ดีจะมีตัวจัดการ หนึ่งในนั้นคือ Circuit Breaker ซึ่งมันต่างจากการ retry หรือการทำงานซ้ำ เพราะว่า Circuit Breaker จะไม่ทำงานซ้ำในที่ ๆ มันพังอยู่ มาดูการทำงานของ Circuit Breaker หน่อย ปกติจะมี 2 สถานะคือ ปิด กับ เปิด ค่า default คือ ปิด แต่เมื่อเกิดปัญหาขึ้นมา เช่น timeout แล้ว Circuit Breaker จะทำการบันทึกจำนวนปัญหาไว้ เมื่อปัญหาต่าง ๆ ถึงจำนวนที่กำหนดหรือค่า threshold จะเปลี่ยนสถานะจากปิดเป็นเปิด นั่นคือไม่มีใครสามารถเรียกใช้งานการทำงานนั้น ๆ ได้ จนกว่าจะผ่านเวลาที่กำหนดไว้ (Timeout) จากนั้นจะทำการค่อย ๆ เปลี่ยนสถานะของ Circuit Breaker จากเปิดไปเป็นเปิดครึ่งเดียว นั่นคือ อนุญาตให้เรียกใช้งานส่วนงานนั้น ๆ ได้ ถ้าทำงานสำเร็จก็จะเปลี่ยนสถานะไปเป็นปิด นั่นคือใช้งานได้ปกติ แต่ถ้าทำงานผิดพลาดเช่นเดิม ก็จะเปลี่ยนสถานะเป็นเปิด แล้วก็รอวนไป แสดงการทำงานดังรูป ส่วนการใช้งานจริง ๆ ก็แล้วแต่ use case อีกแล้ว อาจจะไม่ต้องรอให้พังก็ได้ แค่ timeout ก็พอ จากนั้นก็ทำการจัดการปัญหาในหลาย ๆ แบบ ทั้งส่งรายละเอียดของปัญหาที่เข้าใจง่ายออกไปให้ผู้ใช้งาน บางระบบ ก็ไปเปิดระบบงานใหม่ขึ้นมา หรือ route การทำงานไปยังที่ใหม่กันก็เป็นไปได้ และมักจะใช้สิ่งที่เรียกว่า Fallback เพื่อส่งค่าสำเร็จล่าสุด หรือ ข้อมูลที่ cache ไว้กลับไป เพื่อลดผลกระทบที่จะเกิดขึ้นต่อระบบ แน่นอนว่ามันกระทบต่อ business แน่นอน ดังนั้นสิ่งที่สำคัญมาก ๆ คือการคุยและตกลงกับเจ้าของระบบว่า ถ้าเกิดปัญหาต่าง ๆ ขึ้นมา หรือ Circuit Breaker อยู่ในสถานะเปิดแล้ว จะต้องจัดการอย่างไรบ้าง ? อย่าให้แต่ทาง IT หรือทีมพัฒนาคิดละ !! อีกอย่าง อย่าลืมเก็บ log การเปลี่ยนสถานะของ Circuit Breaker ด้วยนะ เพื่อทำให้เราและ operation รู้การทำงานด้วย

โดยสรุป

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