Blue-Green Deployment เทคนิคอัปเดตเว็บลื่น ลดล่ม และย้อนกลับได้ไว

การอัปเดตระบบบนโปรดักชันไม่ควรเป็นช่วงเวลาที่ทีมต้องคอยลุ้นว่าเว็บจะล่มหรือไม่ หลายทีมยังใช้วิธี deploy แบบทับของเดิม ซึ่งแม้จะทำได้เร็วในระยะแรก แต่เมื่อระบบเริ่มใหญ่ขึ้น วิธีนี้มักเพิ่มความเสี่ยงทั้งเรื่อง downtime, บั๊กบนโปรดักชัน และการย้อนกลับที่ทำได้ยาก

Blue-Green Deployment เป็นแนวทางที่ช่วยให้การปล่อยเวอร์ชันใหม่เป็นระบบมากขึ้น ลดผลกระทบต่อผู้ใช้ และทำให้การ rollback กลับไปเวอร์ชันเดิมทำได้แทบจะทันที

Blue-Green Deployment คืออะไร

แนวคิดหลักของ Blue-Green Deployment คือการมีสภาพแวดล้อม 2 ชุดที่ใกล้เคียงกันมากที่สุด

• Blue คือระบบที่กำลังให้บริการผู้ใช้อยู่ในปัจจุบัน
• Green คือระบบอีกชุดที่ใช้เตรียมเวอร์ชันใหม่

เมื่อทีมต้องการปล่อยฟีเจอร์หรืออัปเดตระบบ ก็จะนำโค้ดใหม่ไป deploy ที่ Green ก่อน จากนั้นทดสอบทุกอย่างให้พร้อม แล้วค่อยสลับทราฟฟิกจาก Blue ไปยัง Green เมื่อมั่นใจว่าระบบทำงานได้ถูกต้อง

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

ขั้นตอนการใช้งานแบบเข้าใจง่าย

ลำดับการทำงานของ Blue-Green Deployment โดยทั่วไปมีดังนี้

1. Deploy โค้ดเวอร์ชันใหม่ไปยังฝั่ง Green
2. รันทดสอบ เช่น health check และ smoke test บน Green
3. เมื่อมั่นใจแล้วจึงสลับทราฟฟิกจาก Blue ไป Green

ผลลัพธ์คือระบบใหม่จะเริ่มให้บริการทันที โดยที่ฝั่ง Blue ยังพร้อมเป็นแผนสำรองอยู่ตลอดเวลา

จุดเด่นสำคัญ: ลด downtime และ rollback ได้เร็วมาก

หลายคนมักเข้าใจว่า Blue-Green มีประโยชน์แค่เรื่องลด downtime แต่ความจริงแล้วจุดแข็งที่ทรงพลังมากคือ การ rollback ที่รวดเร็ว

ถ้าหลังสลับทราฟฟิกไป Green แล้วพบปัญหา เช่น บั๊กสำคัญ, ค่า error rate พุ่ง หรือประสิทธิภาพตกลง ทีมสามารถสลับทราฟฟิกกลับไปที่ Blue ได้ทันที โดยไม่ต้องรีบ rebuild หรือ redeploy ใหม่ทั้งระบบ

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

เรื่องที่ต้องระวังที่สุด: ฐานข้อมูล

แม้ Blue-Green จะดูเรียบง่ายในภาพรวม แต่ส่วนที่ต้องระวังมากที่สุดคือ การเปลี่ยนแปลง schema ของฐานข้อมูล

หากเวอร์ชันใหม่เปลี่ยน schema แบบที่ไม่สามารถใช้งานร่วมกับเวอร์ชันเดิมได้ การสลับกลับไป Blue อาจทำให้ระบบเดิมทำงานผิดพลาดทันที ดังนั้นการออกแบบ migration จึงเป็นหัวใจสำคัญของการใช้แนวทางนี้ให้ปลอดภัย

แนวทาง DB Migration แบบ Expand and Contract

เทคนิคที่นิยมใช้ในระบบจริงคือแนวทาง expand and contract โดยแบ่งเป็นหลายรอบเพื่อลดความเสี่ยง

• รอบที่ 1: Expand เพิ่มโครงสร้างใหม่โดยยังไม่ทำลายของเดิม เช่น เพิ่มคอลัมน์หรือตารางใหม่
• รอบที่ 2: ให้โค้ดเวอร์ชันใหม่รองรับทั้งโครงสร้างเก่าและใหม่ พร้อมค่อย ๆ ย้ายการอ่านข้อมูลไปยังรูปแบบใหม่
• รอบที่ 3: Contract เมื่อตรวจสอบแล้วว่าระบบนิ่งและไม่มีการใช้งานของเดิม จึงค่อยลบโครงสร้างเก่าออก

ตัวอย่างเช่น เดิมมีคอลัมน์ name แต่ต้องการแยกเป็น first_name และ last_name ไม่ควรลบ name ทันที ควรเพิ่มสองคอลัมน์ใหม่ก่อน แล้วให้ระบบเขียนข้อมูลลงทั้ง name, first_name และ last_name ไปพร้อมกัน เมื่อข้อมูลและพฤติกรรมระบบนิ่งแล้ว จึงค่อยเปลี่ยนการอ่านไปใช้คอลัมน์ใหม่ และสุดท้ายค่อยลบคอลัมน์เดิม

Blue-Green ใช้ได้ตั้งแต่ระบบเล็กจนถึงระบบใหญ่

แนวทางนี้ไม่ได้จำกัดอยู่แค่ระบบขนาดใหญ่เท่านั้น ทีมเล็กก็สามารถเริ่มใช้ได้เช่นกัน

• ระดับเริ่มต้น: สลับ DNS หรือสลับ reverse proxy
• ระดับที่ซับซ้อนขึ้น: สลับผ่าน load balancer หรือ ingress

เครื่องมือที่พบได้บ่อย ได้แก่

• Nginx หรือ HAProxy สำหรับสลับ upstream
• Kubernetes ที่ใช้ Service หรือ Ingress ช่วยสลับทราฟฟิก
• บริการคลาวด์ เช่น AWS ALB หรือ Cloud Run ที่รองรับแนวคิดลักษณะนี้

เคล็ดลับที่ช่วยให้การสลับราบรื่นขึ้น

หากต้องการให้การ deploy เนียนและปลอดภัยมากขึ้น ควรเตรียมองค์ประกอบต่อไปนี้

1. ทำ health endpoint โดยเฉพาะ

ควรมี endpoint สำหรับตรวจสุขภาพระบบ เช่น /healthz แยกจากหน้าเว็บทั่วไป เพื่อใช้ตรวจว่าระบบพร้อมรับทราฟฟิกจริงหรือไม่

สิ่งที่ควรเช็ก เช่น

• การเชื่อมต่อฐานข้อมูล
• การเชื่อมต่อ cache
• สถานะ queue หรือ queue lag
• dependency สำคัญที่ระบบต้องใช้

2. ใช้ readiness check ก่อนรับทราฟฟิก

ระบบไม่ควรรับทราฟฟิกทันทีหลังเริ่มต้นทำงาน แต่ควรรอจนผ่าน readiness check ก่อน เพื่อให้แน่ใจว่าบริการพร้อมใช้งานจริง

3. ค่อย ๆ ปล่อยทราฟฟิกหากระบบรองรับ

ในบางระบบอาจไม่จำเป็นต้องสลับจาก 0% ไป 100% ทันที แต่สามารถทยอยปล่อยทราฟฟิก เช่น 5% → 25% → 100% เพื่อดูสัญญาณผิดปกติก่อนขยายเต็มรูปแบบ

หากพบปัญหาในช่วงต้น ก็สามารถหยุดและ rollback ได้เร็วโดยกระทบผู้ใช้น้อยลง

ตัวชี้วัดที่ต้องติดตามหลังสลับทราฟฟิก

หลังจากสลับไปยัง Green แล้ว ยังไม่ควรถือว่าภารกิจจบทันที ทีมควรติดตามทั้งมุมเทคนิคและมุมธุรกิจควบคู่กัน

ตัวอย่างสัญญาณสำคัญที่ควรดู ได้แก่

• error rate
• latency โดยเฉพาะ p95 และ p99
• จำนวน response รหัส 500, 502, 503
• การใช้ CPU และ Memory
• ตัวชี้วัดทางธุรกิจ เช่น conversion rate หรือ checkout success

การมองเฉพาะว่าระบบยังตอบสนองได้อาจไม่พอ เพราะบางครั้งระบบไม่ล่มแต่คุณภาพการให้บริการหรือผลลัพธ์ทางธุรกิจลดลงอย่างชัดเจน

ควรเริ่มใช้อย่างไรสำหรับทีมที่เพิ่งเริ่มต้น

หากทีมยังไม่เคยใช้ Blue-Green Deployment มาก่อน วิธีเริ่มที่ปลอดภัยที่สุดคือเริ่มจากบริการที่ stateless ก่อน เช่น

• เว็บหน้าที่เน้นการอ่านข้อมูล
• API ที่ไม่ผูก session มากนัก
• บริการที่ไม่มีการเปลี่ยน schema ฐานข้อมูลบ่อย

เมื่อทีมคุ้นเคยกับกระบวนการสลับทราฟฟิก การตรวจสุขภาพ และการ rollback แล้ว จึงค่อยขยับไปยังบริการที่มี state หรือระบบที่เกี่ยวข้องกับฐานข้อมูลมากขึ้น

สรุป

Blue-Green Deployment คือแนวคิดที่ทำให้การปล่อยเวอร์ชันใหม่เป็นเรื่องที่ควบคุมได้มากขึ้น เปรียบเหมือนการมีเวทีสำรองพร้อมใช้งานอยู่ตลอดเวลา เราสามารถ deploy และทดสอบบนเวทีสำรองก่อน แล้วค่อยสลับผู้ใช้งานไปยังเวอร์ชันใหม่เมื่อมั่นใจ

ข้อดีสำคัญไม่ใช่แค่ลด downtime แต่รวมถึงการ rollback ที่รวดเร็ว ซึ่งมีผลอย่างมากต่อเสถียรภาพของระบบและความเชื่อมั่นของผู้ใช้ อย่างไรก็ตาม การออกแบบฐานข้อมูลและ migration ให้รองรับการย้อนกลับยังคงเป็นหัวใจสำคัญ

หากวางระบบให้ดี การ deploy จะไม่ใช่ช่วงเวลาที่ต้องภาวนาอีกต่อไป แต่จะกลายเป็นกระบวนการที่ทีมควบคุมได้อย่างมั่นใจ