ทำ Blue-Green Deployment ด้วย Nginx แบบง่าย ลด Downtime และ Rollback ไว

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

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

Blue-Green Deployment คืออะไร

แนวคิดหลักของวิธีนี้คือการมีแอปอยู่ 2 ชุด

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

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

ทำไมหลายทีมจึงชอบวิธีนี้

Blue-Green Deployment ได้รับความนิยมเพราะให้ประโยชน์ที่ชัดเจนมากในการใช้งานจริง

• สลับเวอร์ชันได้รวดเร็ว
• ลด downtime ได้มาก
• rollback ได้ง่ายเมื่อเกิดบั๊กหนัก
• เหมาะกับเว็บ API และระบบภายในทีม

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

โครงสร้างพื้นฐานแบบง่ายด้วย Nginx

รูปแบบที่ง่ายที่สุดคือให้ Nginx ทำหน้าที่รับ request จากผู้ใช้ที่หน้าบ้าน แล้ว proxy ต่อไปยังแอปเวอร์ชันที่ต้องการใช้งาน

ตัวอย่างเช่น

• Blue รันที่ localhost:3001
• Green รันที่ localhost:3002
• Nginx จะเลือกส่ง request ไปยังฝั่งใดฝั่งหนึ่ง

ตัวอย่าง config แบบเรียบง่าย:

upstream app_backend {
    server 127.0.0.1:3001;
}

server {
    listen 80;
    location / {
        proxy_pass http://app_backend;
    }
}

หากต้องการสลับไป Green ก็เพียงเปลี่ยนจาก port 3001 เป็น 3002 แล้วสั่ง reload Nginx

sudo nginx -s reload

ขั้นตอนการ deploy แบบใช้งานจริง

ลำดับการทำงานโดยทั่วไปจะเป็นดังนี้

1. ผู้ใช้กำลังใช้งาน Blue อยู่
2. ทีม deploy โค้ดเวอร์ชันใหม่ขึ้น Green
3. ทดสอบ Green ให้ผ่านก่อน
4. เปลี่ยน config ของ Nginx ให้ส่ง traffic ไปยัง Green
5. reload Nginx โดยไม่ต้องดับบริการ
6. หากมีปัญหา สามารถสลับกลับไป Blue ได้ทันที

จุดแข็งของแนวทางนี้คือการแยกการ “ปล่อยโค้ด” ออกจากการ “เปิดใช้งานจริง” ทำให้ทีมควบคุมความเสี่ยงได้ดีขึ้นมาก

เทคนิคเพิ่มเติม: ใช้ symbolic link ช่วยสลับเวอร์ชัน

แทนที่จะเข้าไปแก้ไฟล์ config ตรง ๆ ทุกครั้ง บางทีมเลือกใช้วิธีแยกไฟล์ เช่น

• blue.conf
• green.conf
• active.conf

จากนั้นให้ active.conf เป็น symbolic link ที่ชี้ไปยังไฟล์ของเวอร์ชันที่กำลังใช้งานอยู่ เวลาเปลี่ยนเวอร์ชันก็เพียงสลับลิงก์ แล้ว reload Nginx วิธีนี้ช่วยลดความผิดพลาดจากการแก้ config ด้วยมือ และทำให้ขั้นตอน deploy เป็นระเบียบมากขึ้น

อย่าลืมตรวจ config ก่อน reload

อีกหนึ่งขั้นตอนสำคัญที่ช่วยลดความเสี่ยงคือการเช็กความถูกต้องของ config ก่อนสั่ง reload ทุกครั้ง

sudo nginx -t

หาก config ผิด Nginx จะรายงานก่อน ทำให้สามารถแก้ไขได้ทันก่อนที่หน้าบ้านจะได้รับผลกระทบ ถือเป็นขั้นตอนเล็ก ๆ ที่ช่วยป้องกันความเสียหายได้มาก

ทำไมการ reload ของ Nginx จึงแทบไม่สะดุด

หลายคนเข้าใจว่า reload อาจทำให้บริการสะดุด แต่จริง ๆ แล้ว Nginx ออกแบบการทำงานส่วนนี้ได้ดีมาก

เมื่อสั่ง reload Nginx จะไม่ปิด process เดิมทันที แต่จะให้ worker เก่าค่อย ๆ ปล่อย connection ที่มีอยู่ให้จบก่อน ขณะเดียวกัน worker ใหม่จะเริ่มทำงานด้วย config ชุดใหม่ต่อทันที กลไกนี้เองที่ทำให้การสลับ Blue ไป Green หรือย้อนกลับ สามารถทำได้อย่างลื่นไหลและแทบไม่กระทบผู้ใช้

สิ่งที่ต้องระวังมากกว่า Nginx: Database Migration

แม้ว่าการสลับทราฟฟิกด้วย Nginx จะทำได้ง่าย แต่สิ่งที่ต้องระวังจริง ๆ มักอยู่ที่ฐานข้อมูล โดยเฉพาะกรณีที่ schema ใหม่ไม่สามารถทำงานร่วมกับแอปเวอร์ชันเก่าได้

ถ้าเกิดเหตุการณ์นี้ขึ้น การ rollback อาจทำได้ยากกว่าที่คิด วิธีที่ปลอดภัยกว่าคือทำ migration แบบ backward-compatible ก่อน เช่น

• เพิ่ม column ใหม่ได้ก่อน
• ยังไม่ลบ column เก่าทันที
• ให้ทั้ง Blue และ Green ใช้งานร่วมกันได้ในช่วงเปลี่ยนผ่าน
• เมื่อตรวจสอบจนมั่นใจแล้ว ค่อยลบโครงสร้างเดิมภายหลัง

แนวทางนี้ช่วยให้การสลับเวอร์ชันและการย้อนกลับทำได้ปลอดภัยขึ้นมาก

เพิ่ม Health Check ก่อนสลับไป Green

หากต้องการให้การ deploy แน่นขึ้นอีกระดับ ควรมี health check สำหรับตรวจสอบว่า Green พร้อมใช้งานจริงหรือยัง

ตัวอย่างเช่น ให้ระบบเรียก endpoint อย่าง /health และต้องตอบกลับ 200 ก่อน จึงค่อยสลับทราฟฟิกไปยังเวอร์ชันใหม่ หากผลตรวจยังไม่ผ่าน ก็ยังไม่ควรเปลี่ยน traffic

แนวคิดนี้ช่วยลดโอกาสที่ผู้ใช้จะถูกส่งไปยัง instance ที่ยังเริ่มต้นไม่สมบูรณ์ หรือยังเชื่อมต่อ dependency ภายนอกไม่ครบ

เรื่องที่มักถูกลืม: Session และการ Login

อีกประเด็นสำคัญคือการเก็บ session ไว้ใน memory ของแต่ละ instance เพราะเมื่อสลับจาก Blue ไป Green ผู้ใช้อาจหลุดออกจากระบบได้ทันที หาก session ของทั้งสองฝั่งไม่ใช้ข้อมูลร่วมกัน

แนวทางที่เหมาะสมคือ

• เก็บ session ไว้ใน Redis
• หรือออกแบบระบบให้ใช้ stateless token

วิธีนี้จะช่วยให้การสลับเวอร์ชันไม่กระทบประสบการณ์ของผู้ใช้ โดยเฉพาะระบบที่มีการ login อยู่ตลอดเวลา

สรุป

Nginx เป็นเครื่องมือที่ช่วยทำ Blue-Green Deployment ได้ง่ายและมีประสิทธิภาพ เหมาะกับระบบที่ยังไม่ใหญ่ถึงขั้นต้องใช้โครงสร้างซับซ้อนมาก เพียงแยกแอปออกเป็น 2 เวอร์ชันบนคนละ port ทดสอบเวอร์ชันใหม่ให้พร้อม แล้วสลับ proxy พร้อม reload อย่างปลอดภัย

เทคนิคนี้ช่วยลดความเสี่ยงจากการ deploy ลด downtime และทำให้ rollback ได้สบาย สำหรับหลายทีม นี่คือจุดเริ่มต้นที่คุ้มค่ามากก่อนจะขยับไปสู่ pipeline หรือแพลตฟอร์มที่ซับซ้อนขึ้นในอนาคต

แหล่งอ้างอิง

• http://app_backend;