"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 ใหม่จะพร้อม
ลำดับเหตุการณ์ที่เกิดขึ้น:
- ระบบเริ่ม deploy version ใหม่
- สร้าง service ใหม่ (ยังไม่พร้อมรับ traffic)
- ปิด service เก่า ทันที
- ไม่มี service ไหนรับ traffic ได้ → 502
- 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 ที่ดีจึงจะใช้ได้ผล
สรุปเปรียบเทียบ
| Strategy |
Downtime |
Resource เพิ่ม |
Rollback |
ความซับซ้อน |
| Recreate |
มี |
ไม่เพิ่ม |
ช้า (deploy ใหม่) |
ต่ำ |
| Rolling Update |
ไม่มี* |
เล็กน้อย ชั่วคราว |
ปานกลาง |
ต่ำ-กลาง |
| Blue-Green |
ไม่มี |
2x ตลอด |
ทันที (สลับกลับ) |
กลาง |
| Canary |
ไม่มี |
เล็กน้อย |
ทันที (หยุด canary) |
สูง |
* เมื่อ 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 — ให้เราช่วยดูได้
