แก้โค้ด webhook นิดเดียว แต่ Conversion หายทั้งวัน: วางระบบ Deploy แบบ Canary ให้อัปเดตได้โดยไม่เสี่ยงทั้งระบบ
สรุปสั้น ๆ
การอัปเดตระบบ tracking แบบเปลี่ยนทุก traffic พร้อมกันในครั้งเดียว หมายความว่าถ้าโค้ดใหม่มีบั๊ก ผลกระทบจะเกิดกับทุกคนทันที Canary deploy คือการทยอยปล่อยโค้ดใหม่ให้รับ traffic ทีละเปอร์เซ็นต์น้อย ๆ ก่อน เพื่อจำกัดความเสียหายถ้าเกิดปัญหาจริง
ทีมเทคนิคของธุรกิจขายเครื่องสำอางแบรนด์หนึ่งอัปเดตโค้ด webhook เพื่อเพิ่มฟิลด์ข้อมูลใหม่ที่ทีมการตลาดขอ ทดสอบบนเครื่องพัฒนาแล้วดูเรียบร้อยดี พอ deploy ขึ้นระบบจริงพร้อมกันทั้งหมด กลับพบว่าโค้ดใหม่มี bug เล็ก ๆ ที่ทำให้ event บางประเภทถูกปฏิเสธเงียบ ๆ กว่าจะรู้ตัวก็ผ่านไปเกือบทั้งวัน เพราะ traffic ทุกคนถูกส่งไปที่โค้ดใหม่พร้อมกันหมดตั้งแต่วินาทีแรกที่ deploy
ปัญหานี้ไม่ได้เกิดจากการทดสอบไม่รอบคอบเสมอไป บางบั๊กเกิดขึ้นเฉพาะกับข้อมูลบางรูปแบบที่ไม่ได้อยู่ในชุดทดสอบ หรือเกิดเฉพาะตอนมี traffic จริงในปริมาณสูงเท่านั้น สิ่งที่ทำได้จริงคือลดขนาดความเสียหายเมื่อบั๊กหลุดมาถึงระบบจริง ไม่ใช่พยายามทำให้การทดสอบสมบูรณ์แบบร้อยเปอร์เซ็นต์ซึ่งเป็นไปไม่ได้จริง
แนวทางที่ตอบโจทย์นี้คือ canary deploy ซึ่งยืมชื่อมาจาก 'นกคานารีในเหมืองถ่านหิน' ที่คนงานเหมืองใช้ตรวจจับก๊าซพิษก่อนที่จะเป็นอันตรายกับคนทั้งหมด หลักการคือปล่อยโค้ดใหม่ให้รับ traffic แค่ส่วนน้อยก่อน แล้วค่อย ๆ ขยายเมื่อมั่นใจว่าไม่มีปัญหา
หลักการทำงานแบบคร่าว ๆ
- deploy โค้ดใหม่ควบคู่ไปกับโค้ดเดิมที่ยังทำงานอยู่ ไม่ใช่แทนที่ทันที
- ตั้งค่าให้ traffic ส่วนน้อย เช่น 5% ของ webhook ที่เข้ามา ถูกส่งไปที่โค้ดใหม่ ส่วนที่เหลือ 95% ยังไปที่โค้ดเดิม
- เฝ้าดูตัวชี้วัดสำคัญของ traffic ส่วน 5% นั้นอย่างใกล้ชิด เช่นอัตราส่งสำเร็จ อัตรา error เทียบกับโค้ดเดิม
- ถ้าตัวเลขปกติดีในช่วงเวลาที่กำหนด (เช่น 30 นาทีถึง 1 ชั่วโมง) ค่อยขยายสัดส่วน traffic ที่ไปโค้ดใหม่เพิ่มขึ้นทีละขั้น เช่น 5% ไป 25% ไป 50% จนถึง 100%
- ถ้าตัวเลขผิดปกติเมื่อไหร่ ให้ดึง traffic กลับไปที่โค้ดเดิมทั้งหมดทันที (rollback) โดยไม่ต้องรอแก้บั๊กเสร็จก่อน
ตัวชี้วัดที่ควรเฝ้าดูระหว่าง canary
- อัตรา error หรือ event ที่ถูกปฏิเสธของ traffic ส่วนใหม่ เทียบกับส่วนเดิมในช่วงเวลาเดียวกัน
- เวลาตอบสนอง (latency) ของโค้ดใหม่ เทียบกับโค้ดเดิม ถ้าช้าลงผิดปกติแม้ไม่มี error ก็ควรระวัง
- จำนวน event ที่ผ่านเข้ามาจริง เทียบกับที่คาดว่าควรจะมี เพื่อจับกรณีที่ event บางประเภทหายไปเงียบ ๆ โดยไม่มี error ชัดเจน คล้ายกับสิ่งที่ต้องเฝ้าดูในแดชบอร์ดสุขภาพ pipeline และควรเทียบกับสถิติที่ระบบเคยพังแบบเงียบมาก่อนเพื่อรู้ว่าอาการแบบไหนควรเฝ้าระวังเป็นพิเศษ
ไม่ใช่ทุกการอัปเดตต้องทำ canary
การเปลี่ยนแปลงเล็กน้อยที่ไม่กระทบ logic การประมวลผลข้อมูล เช่นแก้ข้อความแจ้งเตือนภายในหรือปรับ log format อาจไม่จำเป็นต้องผ่านขั้นตอน canary เต็มรูปแบบ เพราะความเสี่ยงต่ำอยู่แล้ว ควรสงวนกระบวนการนี้ไว้กับการเปลี่ยนแปลงที่กระทบการรับหรือส่งข้อมูล Conversion โดยตรง
ธุรกิจขนาดเล็กที่มี traffic ต่อวันไม่มาก อาจไม่เห็นความต่างชัดเจนจากการแบ่ง traffic เป็นเปอร์เซ็นต์เล็ก ๆ ในกรณีนี้ทางเลือกที่ทำได้จริงกว่าคือ deploy ในช่วงเวลาที่ traffic ต่ำที่สุดของวัน แล้วเฝ้าดูใกล้ชิดในชั่วโมงแรกแทน
เตรียมพร้อมสำหรับ rollback ไว้เสมอ ไม่ใช่หวังว่าจะไม่ต้องใช้
หัวใจของ canary deploy ไม่ได้อยู่ที่การแบ่ง traffic อย่างเดียว แต่อยู่ที่ความสามารถในการดึงกลับไปใช้โค้ดเดิมได้เร็วเมื่อจำเป็น ทีมควรซ้อมกระบวนการ rollback ไว้ล่วงหน้า ไม่ใช่รอเจอปัญหาจริงแล้วค่อยมาคิดว่าจะย้อนกลับยังไง เพราะเวลาทุกนาทีที่ระบบมีปัญหา คือ Conversion ที่หายไปจริง หลักการเดียวกันนี้ควรใช้คู่กับการวางแผนสำรองข้ามภูมิภาคสำหรับธุรกิจที่พึ่งพา CAPI เป็นหลัก
สรุป
ไม่มีการทดสอบไหนที่รับประกันได้ร้อยเปอร์เซ็นต์ว่าโค้ดใหม่จะไม่มีปัญหา สิ่งที่ทีมควบคุมได้จริงคือขนาดของความเสียหายเมื่อปัญหาเกิดขึ้น ซึ่งนั่นคือสิ่งที่ canary deploy ตอบโจทย์
สำหรับระบบที่ Conversion ทุกตัวมีความหมายทางธุรกิจจริง การลงทุนเวลาตั้งกระบวนการ deploy ที่ปลอดภัยกว่า คุ้มค่ากว่าความเสี่ยงที่จะเสียข้อมูลทั้งวันจากการอัปเดตครั้งเดียวที่พลาด
- canary deploy ปล่อยโค้ดใหม่ให้รับ traffic ทีละน้อยก่อนขยายเต็มระบบ
- ต้องเฝ้าดูตัวชี้วัดสำคัญระหว่างช่วง canary และเตรียมพร้อม rollback เสมอ
- ไม่ใช่ทุกการเปลี่ยนแปลงต้องทำ canary เต็มรูปแบบ ควรใช้กับส่วนที่กระทบข้อมูล Conversion โดยตรง
คำถามที่พบบ่อย
canary deploy ต้องใช้เครื่องมือพิเศษไหม
มีเครื่องมือระดับองค์กรที่ช่วยจัดการเรื่องนี้อัตโนมัติ แต่ทีมขนาดเล็กก็ทำแบบง่าย ๆ ได้ด้วยการรันสองเวอร์ชันคู่กันแล้วใช้ load balancer แบ่ง traffic เอง ไม่จำเป็นต้องมีเครื่องมือซับซ้อนตั้งแต่วันแรก
ควรแบ่ง traffic เริ่มต้นกี่เปอร์เซ็นต์
ส่วนใหญ่เริ่มที่ 5-10% เพื่อจำกัดความเสียหายให้น้อยที่สุดถ้ามีปัญหา แต่ก็ต้องมากพอที่จะเห็นสัญญาณผิดปกติได้จริงถ้าปริมาณ traffic โดยรวมของธุรกิจต่ำ อาจต้องปรับสัดส่วนขึ้นเพื่อให้ได้ข้อมูลเพียงพอ
ถ้าไม่มี traffic มากพอจะทำ canary ได้จริงไหม
ทำได้ยากขึ้นเพราะข้อมูลตัวอย่างจากส่วน canary จะน้อยเกินกว่าจะเชื่อถือได้ ธุรกิจที่ traffic น้อยอาจใช้วิธี deploy ช่วง traffic ต่ำแล้วเฝ้าดูใกล้ชิดแทนจะเหมาะกว่า
canary deploy กับการทดสอบบน staging environment ต่างกันยังไง
staging คือสภาพแวดล้อมจำลองที่ไม่มี traffic จริง ใช้ทดสอบก่อน deploy ส่วน canary คือการทดสอบด้วย traffic จริงบางส่วนบนระบบ production เอง ทั้งสองอย่างควรทำร่วมกัน ไม่ใช่เลือกอย่างใดอย่างหนึ่ง
ใช้เวลานานแค่ไหนกว่าจะขยายจาก 5% ไป 100%
ขึ้นอยู่กับความมั่นใจของทีมและปริมาณ traffic แต่โดยทั่วไปมักใช้เวลาไม่กี่ชั่วโมงถึงหนึ่งวันสำหรับการเปลี่ยนแปลงทั่วไป ส่วนการเปลี่ยนแปลงที่กระทบข้อมูลสำคัญมากอาจยืดออกเป็นหลายวันเพื่อความมั่นใจ
บทความที่เกี่ยวข้อง
