Zero-Downtime Deployment — บทเรียนจากข้อผิดพลาดที่เกิดขึ้นทุกครั้งที่ Deploy

"Deploy เสร็จแล้วครับ" — แต่ผู้ใช้เห็นหน้า error

เวลาตี 2 ของวันจันทร์ ทีม DevOps กด deploy เวอร์ชันใหม่ของเว็บไซต์ ทุกอย่างผ่าน CI/CD pipeline เรียบร้อย — image ถูก build, push ขึ้น registry และ rollout เสร็จสมบูรณ์ Terminal แสดงข้อความ "deployment successfully rolled out"

แต่ใน 10 วินาทีก่อนหน้านั้น ผู้ใช้ที่กำลังเปิดเว็บไซต์อยู่เห็นสิ่งนี้:

502 Bad Gateway

ไม่ใช่ครั้งแรก และไม่ใช่ครั้งสุดท้าย ทุกครั้งที่ deploy มี "ช่องว่าง" ประมาณ 5-15 วินาทีที่เว็บไซต์ไม่สามารถเข้าถึงได้ ทีมจึงเลือก deploy ตอนดึก ๆ เพื่อลดผลกระทบ

แต่คำถามที่แท้จริงคือ — ทำไมระบบที่ออกแบบมาเพื่อ zero-downtime ถึงมี downtime ทุกครั้งที่ deploy?

Root Cause: 2 จุดที่ทำลาย Zero-Downtime

เมื่อเปิด deployment configuration ออกมาดู เราพบปัญหาทันที — 2 จุดเล็ก ๆ ที่ถูกมองข้ามไป

ปัญหาที่ 1: ระบบได้รับอนุญาตให้ "ฆ่า" service เดิมก่อนที่ service ใหม่จะพร้อม

Configuration บอกว่า "ระหว่าง deploy ยอมให้ service ใช้งานไม่ได้สูงสุด 1 ตัว" เมื่อรวมกับการที่เรามี service เดียว หมายความว่าระบบ ปิด service เก่าทันที ก่อนที่ service ใหม่จะพร้อม

ลำดับเหตุการณ์ที่เกิดขึ้น:

1. ระบบเริ่ม deploy version ใหม่
2. สร้าง service ใหม่ (ยังไม่พร้อมรับ traffic)
3. ปิด service เก่า ทันที
4. ไม่มี service ไหนรับ traffic ได้ → 502
5. Service ใหม่พร้อม → กลับมาปกติ

ช่วงเวลาระหว่างข้อ 3 กับ 5 คือ "ช่องว่าง" ที่ผู้ใช้เห็น error

ปัญหาที่ 2: ไม่มี health check

แม้จะแก้ปัญหาที่ 1 แล้ว ถ้าไม่มี health check ระบบจะถือว่า service ใหม่ "พร้อม" ทันทีที่เริ่มทำงาน — ไม่สนว่าข้างในจะโหลดเสร็จหรือยัง

นี่คือสาเหตุที่แม้แต่ระบบที่ตั้ง configuration ถูกแล้วก็ยังอาจเจอ error ได้ในช่วงสั้น ๆ

วิธีแก้: 3 การเปลี่ยนแปลง ไม่ถึง 10 บรรทัด

เราแก้ปัญหาด้วย 3 สิ่ง:

1. เพิ่ม health check endpoint — endpoint เบา ๆ ที่ตอบกลับทันทีเมื่อ service พร้อมรับ traffic จริง ๆ ไม่ต้องโหลดหน้าเว็บ ไม่ต้อง render อะไร — แค่ตอบว่า "พร้อมแล้ว"

2. เพิ่ม readiness check — ระบบจะตรวจสอบ health check ทุก 5 วินาที ถ้า service ใหม่ยังไม่ตอบ ก็ยังไม่ส่ง traffic เข้าไป ถ้าล้มเหลว 3 ครั้งติดจะหยุดส่ง traffic ทันที

3. ห้ามปิด service เก่าจนกว่า service ใหม่จะพร้อม — ระหว่าง deploy จะมี 2 service ทำงานพร้อมกันชั่วคราว จนกว่า service ใหม่จะผ่าน health check แล้วจึงค่อยปิด service เก่า

ผลลัพธ์: Timeline หลังแก้ไข

t=0s    สร้าง service ใหม่ (v2) ← service เก่า (v1) ยังรับ traffic อยู่
t=3s    เริ่มเช็ค health check ของ v2
t=8s    v2 ตอบกลับสำเร็จ → ถูก mark ว่า Ready
t=8s    เริ่มส่ง traffic ไป v2 ด้วย
t=9s    ส่ง shutdown signal ให้ v1 (graceful shutdown)
t=9s+   Traffic ทั้งหมดไปที่ v2 — ไม่มีช่วงว่างแม้แต่วินาทีเดียว

Deploy กี่ครั้งก็ได้ กลางวันก็ได้ ไม่มี downtime อีกต่อไป

เปรียบเทียบ Deployment Strategies

เมื่อเข้าใจปัญหาแล้ว มาดูภาพรวมของ deployment strategies ที่ใช้กันในอุตสาหกรรม:

Recreate Strategy

ปิด service ทั้งหมด → สร้างใหม่ทั้งหมด ง่ายที่สุด แต่ มี downtime เสมอ เหมาะกับระบบที่ต้อง break change เช่น database schema migration

Rolling Update (ที่เราใช้)

ค่อย ๆ แทนที่ service เก่าด้วย service ใหม่ทีละตัว เมื่อ config ถูกต้องจะได้ zero-downtime โดยใช้ resource เพิ่มเล็กน้อยชั่วคราว เหมาะกับ stateless web applications

Blue-Green Deployment

มี 2 environment เต็มรูปแบบ (Blue = production, Green = staging) เมื่อ Green พร้อม ก็สลับ traffic ทั้งหมดทันที ข้อดีคือ rollback ง่ายมาก ข้อเสียคือ ใช้ resource 2 เท่าตลอดเวลา

Canary Deployment

ปล่อย traffic เพียง 5-10% ไปหา version ใหม่ก่อน ถ้าไม่มีปัญหาค่อย ๆ เพิ่มเป็น 25%, 50%, 100% เหมาะกับ feature ใหม่ที่มีความเสี่ยงสูง ต้องการ observability ที่ดีจึงจะใช้ได้ผล

สรุปเปรียบเทียบ

* เมื่อ configuration ถูกต้อง

บทสรุป

ปัญหา 502 ระหว่าง deploy ไม่ใช่เรื่องของ technology ที่มีข้อจำกัด แต่เป็นเรื่องของ configuration ที่ไม่สมบูรณ์ การเปลี่ยน เพียง 2 จุด — เพิ่ม health check และบอกระบบว่าห้ามปิด service เก่าก่อนที่ใหม่จะพร้อม — ทำให้ระบบที่เคยมี downtime ทุกครั้งที่ deploy กลายเป็น zero-downtime ได้ทันที

สิ่งที่เราเรียนรู้จากเรื่องนี้: ในโลกของ infrastructure ปัญหาที่ใหญ่ที่สุดมักมาจากสิ่งที่เล็กที่สุด — ไม่ใช่ architecture ที่ผิด ไม่ใช่ technology ที่ไม่ดี แต่เป็น config เพียง 2 บรรทัดที่ถูกมองข้ามไป

ระบบขององค์กรคุณ deploy แล้วมี downtime ไหม?

หลายองค์กรที่เราร่วมงานด้วยเจอปัญหาเดียวกัน — deploy ตอนกลางคืนเพราะกลัว downtime, ผู้ใช้เจอ error แบบ random ที่ทำซ้ำไม่ได้, หรือใช้ downtime window ที่ยาวเกินจำเป็น

ที่ Enersys เราเชื่อว่า technical excellence ไม่ใช่แค่การเลือกใช้เทคโนโลยีที่ดีที่สุด แต่คือการเข้าใจมันอย่างลึกซึ้งพอที่จะรู้ว่าอะไรจะพังเมื่อไหร่ — แล้วป้องกันมันก่อนที่จะเกิด

ถ้าทีมของคุณยังต้อง deploy ตอนดึกเพราะกลัว downtime — ให้เราช่วยดูได้