การปรับใช้เซิร์ฟเวอร์อย่างปลอดภัยด้วย Canary Test

• บทความถ่ายทอดประสบการณ์การทำ Canary Deployment ในสภาพแวดล้อม Kubernetes โดยคุณคิมแทโฮจาก VCNC ผู้ให้บริการ Tada.

• ชื่อ Canary Deployment มาจากการที่คนงานเหมืองในอดีตนำคานารีใส่กรงติดตัวลงไปในเหมือง เพื่อใช้ตรวจจับการรั่วไหลของก๊าซ.

• เมื่อต้องอัปเกรดเมเจอร์เวอร์ชันของ Spring Boot เวอร์ชันของไลบรารีที่พึ่งพาก็จะถูกเปลี่ยนตามไปด้วยแบบบังคับ จึงลองใช้ Canary Deployment เพื่อลดปัญหาด้านประสิทธิภาพหรือเหตุขัดข้องที่ยังทดสอบไม่ครอบคลุมให้น้อยที่สุด.

• ใช้ตัวจัดการแพ็กเกจ Helm สำหรับการปรับใช้บน Kubernetes โดยหน่วยแพ็กเกจของ Helm เรียกว่า "chart" และเมื่อทำการติดตั้ง chart ลงใน Kubernetes cluster ก็จะเกิด release ขึ้น.

• ได้สร้าง chart/release สำหรับ canary และเพิ่ม annotation ให้กับ Ingress controller เพื่อกำหนดให้มีเพียงสัดส่วนของคำขอตามที่ระบุเท่านั้นที่ถูกส่งไปยัง canary Ingress.

งานที่ต้องทำต่อไป

• เมื่อเกิดปัญหากับ canary release การแยกให้ออกว่าสาเหตุมาจากการเปลี่ยนแปลงของ canary หรือเป็นปัญหาที่เกิดอยู่เดิมนั้นทำได้ยาก จึงจำเป็นต้องมีวิธีเปิดกลุ่มควบคุมในสัดส่วนเท่ากันแล้วเปรียบเทียบ metric.

• เนื่องจากมีการส่งบางส่วนของคำขอไปยัง canary โดยไม่เกี่ยวกับตัวผู้ใช้ ต่อให้ canary มีปัญหา เมื่อมีการ retry คำขอ เวอร์ชันเดิมอาจเป็นผู้ประมวลผลและทำให้สำเร็จได้ แต่เมื่อมองภาพรวม สัดส่วนผู้ใช้ที่ได้เจอกับปัญหาของ canary อาจเพิ่มขึ้น ดังนั้นหากทำ routing ไปยัง canary ตามกลุ่มผู้ใช้ (คล้ายกับการทำ sticky ที่ LB) ก็น่าจะควบคุมได้มากขึ้น.