สมมติว่าลูกค้ากำลังกดยืนยันคำสั่งซื้อพอดีกับที่ทีมปล่อยแอปเวอร์ชันใหม่ ถ้าทีมต้องหยุดเซิร์ฟเวอร์ชุดเดิมเพื่ออัปเดต คำขอนั้นอาจค้างหรือล้มเหลว ลูกค้าก็ต้องเดาว่าควรกดซ้ำไหม
Blue/Green Deployment คือการเตรียมแอปเวอร์ชันใหม่ (Green) ควบคู่กับเวอร์ชันที่รับงานอยู่ (Blue) แล้วค่อยสลับเส้นทางเมื่อ Green ผ่านการทดสอบ บน AWS เราใช้ Application Load Balancer (ALB) ให้ลูกค้าเข้าโดเมนเดิมได้ตลอดการสลับ และเก็บ Blue ไว้ช่วงหนึ่งเผื่อต้องย้อนกลับ วิธีนี้ช่วยลดโอกาสที่ผู้ใช้จะสะดุดระหว่างปล่อยแอป ส่วนคำขอที่กำลังทำงานและข้อมูลที่เขียนไปแล้วต้องวางแผนแยกกัน
บทความนี้ต่อยอดจากตัวอย่างของ Cedric Sanhoudi ที่ใช้ Amazon EC2, Elastic Load Balancing, Amazon Route 53, AWS CloudFormation, AWS CodeDeploy และ Amazon CloudWatch ผมใช้เว็บรับคำสั่งซื้อสมมติเพื่อให้เห็นว่าทีมต้องตรวจอะไรตั้งแต่ก่อนเปิดทางให้ Green จนถึงตอนตัดสินใจปิด Blue. บทความต้นทางของ Cedric Sanhoudi
สลับแอปที่ ALB โดยใช้โดเมนเดิม
ให้ Route 53 ชี้ชื่อเว็บไปที่ ALB ตัวเดิม และตั้งกฎบน HTTPS listener ให้ส่งคำขอไปยัง target group หรือกลุ่มเซิร์ฟเวอร์ที่รับงาน ในตัวอย่างนี้ Blue และ Green ใช้ EC2 คนละชุดและมี target group ของตัวเอง ทีมจึงทดสอบ Green ผ่านเส้นทางที่จำกัดสิทธิ์ก่อนแก้กฎที่รับคำขอจริงได้ ถ้าใช้ CloudFormation จัดการโครงสร้างพื้นฐาน ให้ระบุด้วยว่าใครเป็นผู้ควบคุมกฎสลับทราฟฟิก เพื่อไม่ให้ pipeline กับการอัปเดต stack เขียนทับกัน กฎ ALB listener · การชี้ Route 53 ไปยัง load balancer
- เตรียม Green ให้พร้อมก่อนรับงานจริง ให้ ALB ตรวจ endpoint ที่ตอบได้เร็วและสะท้อนว่าแอปรับคำขอได้ แล้วทดสอบงานธุรกิจผ่านเส้นทางที่จำกัดสิทธิ์ เช่น ล็อกอิน สร้างคำสั่งซื้อด้วยบัญชีทดสอบ และเปิดรายการที่เพิ่งบันทึก แยกการทดสอบธุรกิจออกจาก health check ที่รันถี่ และระวังผลข้างเคียงอย่างการตัดเงินจริงหรือส่งอีเมลให้ลูกค้า
- สลับแล้วดูผลของ Green แยกจาก Blue จะสลับครั้งเดียวหรือเริ่มด้วยน้ำหนัก Blue 95 / Green 5 ก็ได้ตามความเสี่ยง ตัวเลขนี้เป็นเพียงตัวอย่างของสัดส่วนคำขอที่ตรงกฎ ไม่ใช่จำนวนลูกค้าหรือสัดส่วนที่เห็นทันทีเมื่อเปิด target group stickiness ตั้งเกณฑ์หยุดไว้ล่วงหน้า เช่น HTTP 5xx หรือ latency สูงกว่าค่าปกติ หรืออัตรายืนยันคำสั่งซื้อสำเร็จลดลง ใช้ CloudWatch ดูสัญญาณจาก target group และให้แอปรายงานผลธุรกรรมแยกตามเวอร์ชัน การกำหนดน้ำหนักใน ALB · การเฝ้าดู CodeDeploy ด้วย CloudWatch
- ให้คำขอเดิมจบก่อนปิด Blue เมื่อเลิกส่งคำขอใหม่ให้ Blue ให้เผื่อเวลาสำหรับคำขอที่ค้างอยู่ ตอนถอน target ออกจากกลุ่ม ALB มี deregistration delay สำหรับระบายงานค้าง ค่านี้ตั้งตามเวลาที่ระบบใช้จริง เช่น งานอัปโหลดหรือการเชื่อมต่อที่เปิดค้าง ไม่ควรยกค่าจากตัวอย่างมาใช้กับทุกแอป ทดสอบทั้งฝั่งแอปและ client ก่อนตั้งเวลาเก็บ Blue ให้ตรงกับช่วงที่ทีมยังต้องการย้อนกลับ การตั้งค่า deregistration delay ของ ALB
การให้น้ำหนัก ALB เป็นการแบ่งคำขอ ถ้ากลุ่ม Green ว่างหรือทุก target ไม่ผ่าน health check ระบบจะไม่ย้ายน้ำหนักไปให้ Blue ที่ยังปกติเอง ทีมต้องมีกติกาหยุดและทางสลับกลับที่ทดสอบแล้ว หากเลือก CodeDeploy แบบ Blue/Green บน EC2 ให้ใช้ขั้นตอนของมันในการลงแอปบนเครื่องชุดทดแทนและลงทะเบียนกับ load balancer ส่วนการกำหนดน้ำหนักเองในตัวอย่างข้างต้นเป็นการควบคุมกฎ ALB โดยตรง การย้อนด้วย CodeDeploy เป็นการ deploy revision เดิมอีกครั้ง และอาจตั้งให้เกิดอัตโนมัติเมื่อ deploy ล้มเหลวหรือ alarm ที่กำหนดทำงาน. พฤติกรรม weighted target groups · Blue/Green บน EC2 · การย้อนเวอร์ชันใน CodeDeploy
ระหว่างที่เก็บ Blue ไว้พร้อมกับ Green ทีมต้องเผื่อ capacity และค่าใช้จ่ายของ EC2 สองชุด ระยะที่คุ้มจะขึ้นอยู่กับว่านานแค่ไหนกว่าจะเห็นปัญหาจากงานจริง เช่น ระบบที่มีงานปิดยอดตอนสิ้นวันอาจต้องรอให้จบรอบนั้นก่อนตัดสินใจปิด Blue
ย้อนเส้นทางได้ แล้วข้อมูลยังใช้ได้ไหม
สมมติว่า Green เพิ่มตัวเลือกจัดส่งที่ Blue ยังอ่านไม่ออก ลูกค้าบันทึกคำสั่งซื้อด้วยตัวเลือกใหม่ไปแล้ว พอทีมสลับกลับ Blue ก็ยังอาจเปิดรายการนั้นไม่ได้ แม้ทุกเครื่องของ Blue จะตอบ health check ปกติ การสลับเส้นทางเปลี่ยนว่าแอปเวอร์ชันใดรับคำขอ ส่วนข้อมูลที่ Green เขียนไว้ยังอยู่ในฐานข้อมูลเดิม
ถ้าสองเวอร์ชันใช้ฐานข้อมูลร่วมกัน ผมจะวางการเปลี่ยน schema แบบ expand/contract เริ่มจากเพิ่มคอลัมน์หรือตารางโดยเก็บของเดิมไว้ จากนั้นย้ายหรือเติมข้อมูลย้อนหลังตามจำเป็นและทดสอบว่า Blue กับ Green ยังอ่านและเขียนข้อมูลที่อีกฝั่งเข้าใจได้ ตัวเลือกจัดส่งใหม่อาจอยู่หลัง feature flag จนกว่าจะพ้นช่วงย้อนกลับ ค่อยลบโครงสร้างเก่าหลังยืนยันว่าแอปและ worker ที่ยังใช้งานอยู่เลิกพึ่งมันแล้ว แนวทาง AWS สำหรับข้อมูลและ schema ระหว่าง Blue/Green
ลองซ้อมให้ Green สร้างคำสั่งซื้อทดสอบหนึ่งรายการแล้วให้ Blue เปิดและทำงานต่อจากรายการนั้น ตรวจด้วยว่า session ยังใช้ได้หลังสลับ และ worker ไม่หยิบงานเดิมไปทำซ้ำ ถ้า Green ส่งอีเมลหรือส่งคำขอตัดเงินไปแล้ว การเปลี่ยนเส้นทางจะไม่ย้อนผลข้างเคียงเหล่านั้น ทีมต้องมีวิธีป้องกันการทำซ้ำหรือแก้รายการแยกจากขั้นตอนสลับแอป
เพิ่มโดเมนเป็นงานอีกชุดหนึ่ง
ถ้าระบบต้องรับโดเมนเพิ่มเรื่อย ๆ เช่น shop-a.example.com หรือโดเมนที่ลูกค้าถือเอง ให้แยกสถานะการเปิดโดเมนออกจากสถานะการปล่อยแอป โดเมนควรเปิดใช้งานเมื่อ DNS, ใบรับรอง TLS และกฎส่งต่อคำขอตามชื่อโฮสต์พร้อมครบ
- ยืนยันสิทธิ์ในโดเมนและออกใบรับรอง ใช้ AWS Certificate Manager (ACM) และให้ผู้ดูแล DNS เพิ่ม CNAME สำหรับ validation เมื่อใช้วิธีตรวจผ่าน DNS ชื่อใต้โดเมนที่เราคุมอาจใช้ใบรับรอง
*.example.comได้ เช่นshop-a.example.comใบนี้ครอบคลุมเพียงหนึ่งระดับ จึงต้องระบุexample.comหรือชื่ออย่างshop-a.eu.example.comแยกตามชื่อที่ต้องการใช้ ชื่อเพิ่มเติมอาจอยู่ในรายการ SAN ของใบเดียวกันหรือใช้ใบแยก แล้วให้ ALB เลือกใบที่ตรงกับชื่อที่ client ส่งมาผ่าน SNI ACM DNS validation · ใบรับรองและ SNI บน ALB - เตรียมกฎปลายทางและชี้ DNS ตั้งกฎตามชื่อโฮสต์ไปยังแอปหรือ tenant ที่ถูกต้อง ถ้าโซนอยู่ใน Route 53 ใช้ Alias ชี้ไปยัง ALB ได้ทั้งโดเมนหลักและซับโดเมน ส่วน resolver ยังแคชคำตอบ DNS ตาม TTL ถ้าต้องย้ายระหว่าง ALB คนละตัวด้วย DNS ให้เผื่อเวลาที่ผู้ใช้บางรายยังเห็นปลายทางเดิม Alias และ TTL ใน Route 53
- ทดสอบจากฝั่งผู้ใช้ก่อนเปิดใช้ ตรวจว่าชื่อ resolve ไปตามที่ตั้งไว้ เปิด HTTPS ด้วยชื่อนั้นเพื่อยืนยันว่าใบรับรองตรง แล้วลองเรียกหน้าหรือ API ที่บอกได้ว่าคำขอไปถึง tenant ที่ถูกต้อง การทดสอบนี้ทำซ้ำได้โดยไม่ต้องรอ deploy รอบถัดไป
เลือกเครื่องมือตามสิ่งที่เปลี่ยน
| สิ่งที่ทีมกำลังเปลี่ยน | เครื่องมือและขอบเขต |
|---|---|
| เวอร์ชันแอปบน EC2 | ALB กับ target group สองชุดเหมาะเมื่ออยากทดสอบ Green แยกและคง Blue ไว้ระหว่างเฝ้าดู ส่วน CodeDeploy แบบ in-place อัปเดตแอปบนเครื่องชุดเดิมเป็นลำดับตาม deployment configuration ต้องเผื่อให้เครื่องที่เหลือรับงานไหว. รูปแบบ deployment ของ CodeDeploy |
| AMI หรือ launch template ของ EC2 | EC2 Auto Scaling Instance Refresh ทยอยแทนที่ instance ตามการตั้งค่า healthy capacity และ warm-up เหมาะกับการเปลี่ยนภาพเครื่องหรือค่าที่มากับการเปิดเครื่อง การทำงานของ Instance Refresh |
| เวอร์ชันคอนเทนเนอร์บน ECS | ตัวควบคุมแบบ native ของ Amazon ECS มี rolling, blue/green, linear และ canary ส่วนบริการที่ใช้ตัวควบคุม CodeDeploy มีขั้นตอนของตัวเอง ให้ตรวจว่า service ใช้ controller ใดก่อนเลือกวิธี Deployment controllers และ strategies ของ ECS |
| เส้นทางของ API | API Gateway custom domain ใช้ API mapping เชื่อม path กับ API stage เช่น /orders ไปยัง stage ที่กำหนด ถ้า API Gateway เป็นทางเข้าหลัก ให้ตรวจ routing ที่ชั้นนี้ด้วย API mappings |
| คอนฟิก CDN หรือความพร้อมของ origin | CloudFront continuous deployment ส่งทราฟฟิกบางส่วนไปทดสอบ staging distribution ก่อนนำคอนฟิกขึ้น primary ส่วน origin failover ส่งต่อไป origin สำรองตามเงื่อนไขสำหรับ GET, HEAD และ OPTIONS ที่ตั้งให้แคชได้ จึงใช้แทนการกู้คำสั่งซื้อที่ส่งด้วย POST ไม่ได้ สำหรับ Origin Shield หน้าที่คือเพิ่มชั้นแคชเพื่อลดคำขอถึง origin Continuous deployment · Origin failover · Origin Shield |
| แอปบน Amazon EKS | AWS Load Balancer Controller จัดการ ALB จาก Ingress ได้ และใช้ ExternalDNS อัปเดตระเบียน Route 53 ตามทรัพยากรที่กำหนด เมื่อใช้ IP targets และตั้ง pod readiness gate ตามเงื่อนไข controller จะรอให้ target ของ pod ผ่านการตรวจของ load balancer ก่อนให้ pod พร้อมรับงานในมุมของ Kubernetes Load balancing บน EKS · ExternalDNS · Pod readiness gate |
ก่อนปล่อยรอบถัดไป ลองซ้อมด้วยคำสั่งซื้อทดสอบหนึ่งรายการ สร้างบน Green แล้วสลับกลับ Blue ผ่านชื่อเว็บเดิม ถ้า Blue ยังเปิดรายการและทำงานต่อได้โดยไม่เกิดรายการซ้ำ ทีมจะรู้มากขึ้นว่าต้องเก็บ Blue ไว้นานเท่าไร และควรแก้จุดไหนก่อนเปิดให้ลูกค้าจริง