ในโลกของการพัฒนาซอฟต์แวร์ที่เปลี่ยนแปลงอย่างตลอดเวลา ครั้งจะ Deploying หรือ Update อะไรใหม่ๆ โดยไม่ส่งผลกระทบต่อผู้ใช้งานเป็นสิ่งสำคัญอย่างมากยิ่งขึ้นเรื่อยๆ มีหลากหลายแนวทาง จนเกิดหลักการสำหรับการพัฒนาซอฟต์แวร์ที่ตอบโจทย์ในการไม่ต้องปิดให้บริการ (Downtime) และสามารถกู้คือระบบเดิม (Rollbacks) ลดความเสียหายในกรณีที่เกิดปัญหาขึ้นมา โดยหลักการที่ว่านั้นคือ Blue/Green Deployment โดยในบทความนี้เราจะมาเล่ากันว่า Blue/Green Deployment คืออะไร มีลักษณะแนวคิดที่ต่างกันยังไง และข้อดี ข้อเสีย ของแต่ละ Deployment กัน
อะไรคือ Blue/Green Deployment
Blue/Green Deployment คือกระบวนการ Deploy ซอฟต์แวร์ระบบ สู่ Prodution ที่มั่นใจว่ากระบวนการนั้นจะราบรื่นทั้งในขณะ Deploying หรือ Update และการ Rollback ที่มีผลกระทบน้อยที่สุด โดยมีการสร้าง Production Environment ที่มีสภาพแวดล้อมเหมือนกันเป็นสองก้อนอิสระกัน แยกกำกับเป็นสี “น้ำเงิน” (Blue) และสี “เขียว” (Green) โดยส่วนของสีเขียวจะใช้เป็นการทดสอบ Deploy ซอฟต์แวร์ชุดใหม่ว่ามีปัญหาหรือไม่ ราบรื่นดีมั้ย โดยอีกสภาพแวดล้อมหนึ่งซึ่งเป็นของเดิมจะถูกกำกับเป็นสีน้ำเงิน ซึ่งเป็นเวอร์ชั่นซอฟต์แวร์ที่จะใช้งานจริงอยู่ ทั้งสองสภาวะนี้จะคุมผ่าน Router ในการพาผู้ใช้ไปในสภาพแวดล้อมใดหนึ่ง โดยไม่ต้องมีการปิดปรับปรุงเลย เพื่อประสบการณ์ของผู้งานที่ราบรื่นที่สุด
จุดประสงค์ของการทำ Blue/Green Deployment
Blue/Green Deployment มีจุดประสงค์เพื่อช่วยการ Deploy ซอฟต์แวร์ล่าสุดในหลายด้าน ดังนี้
- ไม่ต้องปิดระบบ (Zero Downtime): ถือเป็นธงหลักของหลักการนี้เลย นั่นคือทำอย่างไรให้ User ใช้งานต่อเนื่องตลอดการ Depoly ไม่รู้สึกถึงการเปลี่ยนแปลงในทางลบ เช่น งดให้บริการชั่วคราว ปิดปรับปรุงชั่วคราว
- กู้คืนระบบเดิมได้เร็ว: หากกรณีที่เวอร์ชั่นใหม่ที่ Deploy ไปพบปัญหา ก็สามารถย้อนกลับไปใช้ระบบเวอร์ชั่นก่อนหน้าได้ทันทีเพียง Route ผู้ใช้กลับสู่เวอร์ชั่นก่อนหน้า ลดความเสี่ยงระบบล่ม มีปัญหาได้อย่างทันท้วงที
มั่นใจในคุณภาพของ - ซอฟต์แวร์มากขึ้น: เมื่อมี Production Environment เหมือนกันอีกก้อน ที่ไม่ถูก Live จึงสามารถใช้พื้นที่นั้นทดสอบฟีเจอร์ ทดสอบระบบ หรือตรวจสอบการอัปเดตในสภาพแวดล้อมคล้ายการใช้งานจริงยิ่งขึ้น ก่อนจะ Launch
- รีดทรัพยากรได้ดียิ่งขึ้น: เพราะโจทย์ที่ต้องมี Production Environment คู่ แม้ดูเหมือนจะใช้ทรัพยากรมากกว่า แต่ก็หลักการนี้ช่วยท้าทายให้รีดทรัพยากรสูงสุดโดยการจัดแบ่งการใช้งาน เช่น staging, testing, หรืองาน pre-production บางอย่าง ปล่อยให้เกิดสถานะ idle น้อยที่สุด
- ลดความซับซ้อนในการพัฒนา: การมี Production Environment คู่ อาจฟังดูซับซ้อน แต่เพราะการทำซ้ำๆ กันนี้ ช่วยลดความซ้ำซ้อมในการพัฒนา คุมลักษณะที่คาดเดาได้ง่าย
กระบวนการคร่าวๆ ของ Blue/Green Deployment
- ทำการ Deploy: Deploy ตัวแอปพลิเคชันใหม่ลงใน “Green”
- ตรวจสอบ (Validation): ทำการทดสอบระบบอย่างเข้มงวดใน “Green” เพื่อให้มั่นใจว่าไม่เจอข้อผิดพลาดใดๆ และใช้งานได้อย่างมีประสิทธิภาพสูง พร้อมสำหรับการนำไปใช้งานจริง
- สลับ (Switch): เมื่อผ่านการตรวจสอบเรียนร้อยสมบูรณ User traffic จะถูกโยกจาก “Blue” ไปยัง “Green”
- ย้อนกลับ (Rollback): ถ้ากรณีพอใช้งานจริงแล้วพบปัญหาเข้า User traffic สามารถสลับฝั่งจาก “Green” ไปยัง “Blue” ได้ทันที
จุดแข็ง
- ไม่ต้องปิดระบบ (Downtime): ข้อได้เปรียบหลักเลย ก็คือการไม่ต้องปิดระบบชั่วคราว สามารถส่งมอบอัปเดตและฟีเจอร์ใหม่ๆ ให้การบริการต่อเนื่องไม่มีสะดุด
- ลดความเสี่ยงเมื่อเกิดปัญหา: สามารถกู้ระบบกลับได้อย่างทันที กรณีพบปัญหาในการอัปเดตหรือปล่อยเวอร์ชั่นใหม่
- แยกส่วนระหว่างกัน (Isolation): เมื่อต้องการจะส่งมอบฟีเจอร์ใหม่ ก็สามารถทดสอบในสภาพแวดล้อมจริงได้ก่อนจะนำขึ้นใช้งานจริง
จุดอ่อน
- ใช้ทรัพยากรสูง (Resource Intensive): เพราะต้องวางระบบที่เป็น Production จริงถึง 2 ส่วน ส่งผลให้มีค่าใช้จ่ายเพิ่มเติมและการใช้ทรัพยากรเป็นสองเท่า
- ความซับซ้อนสูง: เพราะต้องจัดการระบบเพิ่ม ทำให้การจัดการซับซ้อนยิ่งขึ้น
- Data Synchronization: การทำระบบฐานข้อมูลให้สามารถ Synchronization ระหว่างสองสภาพแวดล้อมอาจเป็นเรื่องที่ท้าทาย
สรุป
การทำความเข้าใจใน Blue/Green Deployment ถือเป็นสิ่งสำคัญสำหรับองค์กรให้บริการในงานที่อ่อนไหวต่อการต้องปิดปรับปรุงชั่วคราว ไม่ว่าธุรกิจเพิ่งจะเริ่มนำกลยุทธ์นี้มาใช้ หรือต้องการปรับปรุงคุณภาพการให้บริการ เปลี่ยนผ่านจากระบบเดิม กระบวนการ Blue/Green Deployment จึงเป็นกระบวนการที่มีประสิทธิภาพสูงสุดที่น่าพิจารณาใช้ต่อไป
