ในยุคของการพัฒนาแอปพลิเคชันสมัยใหม่หรือการพัฒนาแอปพลิเคชันในรูปแบบ Container สิ่งที่ขาดไม่ได้เลยในการบริหารจัดการ Container เหล่านั้นไม่ว่าจะเป็น Upgrade, Scale และอื่น ๆ อีกมากมาย นั่นคือ Container orchestration ซึ่งถ้ากล่าวถึงจุดนี้คงไม่มีใครไม่รู้จัก Kubernetes
กลยุทธ์ที่ใช้ในการ deploy แอปพลิเคชันไปยัง Container orchestration อย่าง Kubernetes จะเป็นตัวกำหนดประสิทธิภาพ ความเร็ว และประสบการณ์ของผู้ใช้งาน แล้วอะไรคือวิธีที่ดีที่สุดที่ใช้ในการ deploy แอปพลิเคชัน?
เป็นที่รู้กันดีว่ามาตรฐานการพัฒนาแอปพลิเคชันสมัยใหม่ ให้ความสำคัญกับการพัฒนาที่รวดเร็วและต่อเนื่องเพื่อเพิ่มประสบการณ์การใช้งานที่ดีให้แก่ผู้ใช้งาน นั่นหมายความว่า แอปพลิเคชันก็จะมีอัปเกรดเวอร์ชันอยู่เสมอ ดังนั้นการ deploy แอปพลิเคชันให้ราบรื่นและไม่กระทบการใช้งานของผู้ใช้งานจึงเป็นส่วนสำคัญ
ในบทความนี้ จะได้เรียนรู้เทคนิคการ deploy แอปพลิเคชันใน Kubernetes ซึ่งก็มีหลายวิธี จึงมีความจำเป็นต้องเลือกกลยุทธ์ที่เหมาะสมเพื่อทำให้ระหว่างการอัปเดตแอปพลิเคชันนั้นไม่กระทบต่อผู้ใช้งานนั่นเอง
1. Recreate deployment
เป็นการปิดเวอร์ชันเก่าทั้งหมดแล้วเปิดใช้เวอร์ชันใหม่ เหมาะสมกับ development environment โดยใช้หลักการทำงานง่ายๆคือ แอปพลิเคชันเวอร์ชันเก่าทั้งหมดจะถูกปิดและทำลายลง จากนั้นจะถูกแทนที่ด้วยแอปพลิเคชันเวอร์ชันใหม่ทั้งหมด
ข้อดี
แอปพลิเคชันทั้งหมดจะถูกแทนที่ด้วยเวอร์ชันใหม่ ดังนั้น ผู้พัฒนา(developer) จะสามารถจัดการกับ process ได้ครั้งละหนึ่ง process และ codebase จะถูกจัดระเบียบอยู่เสมอ ซึ่งผู้พัฒนา(developer) สามารถมองเห็นเวิร์กโฟลว์ของตนได้อย่างเต็มที่
ข้อเสีย
ในทางกลับแอปพลิเคชันต้องหยุดทำงานชั่วคราว สำหรับแอปพลิเคชันที่สำคัญซึ่งจำเป็นต้องใช้งานได้ทุกวันตลอด 24 ชั่วโมง เช่น แพลตฟอร์มทางการแพทย์หรือซอฟต์แวร์เซิร์ฟเวอร์ วิธีการ deploy แบบนี้จึงไม่เหมาะสม
2. Ramped (Rolling deployment)
ถือเป็นค่าเริ่มต้น(Default) ของ Kubernetes Deployment Strategies เป็นการค่อยๆเปิดใช้เวอร์ชันใหม่และค่อยๆปิดเวอร์ชันเก่าในเวลาเดียวกัน วิธีนี้จะมีการสร้าง ReplicaSet สำหรับแอปพลิเคชันเวอร์ชันใหม่ จากนั้นจะเริ่มใช้งานแอปพลิเคชันเวอร์ชันใหม่อย่างช้าๆ โดยการแทนที่ pod เดิมทีละรายการจนกว่าจะเปิด pod ใหม่ครบทั้งหมด จากนั้นเวอร์ชันเดิมจะถูกลบออกและปิดตัวลง
ข้อดี
รูปแบบการ rolling deployment ช่วยให้สามารถ deploy ได้อย่างต่อเนื่องในแอปพลิเคชันที่มีการใช้งานอยู่ วิธีนี้ช่วยลดการหยุดทำงาน(downtime) ของแอปพลิเคชัน เหมาะสำหรับแอปพลิเคชันที่เป็น stateful ที่สามารถจัดการสมดุล(rebalancing) ของข้อมูลได้
ข้อเสีย
การถอยกลับ(rollout/rollback) อาจทำได้ช้า เนื่องจากต้องดำเนินการทีละน้อยๆ และยากต่อการจัดการสำหรับแอปพลิเคชันที่รองรับหลาย APIs รวมถึงยากต่อการควบคุมทราฟฟิค ดังนั้นสิ่งสำคัญคือทีม deploy ต้องตั้งค่าอัลกอริธึมเพื่อควบคุมทราฟฟิคของผู้ใช้งานให้ได้
3. Blue/green deployment
เป็นการเปิดเวอร์ชันใหม่ควบคู่ไปกับเวอร์ชันเก่าแล้วจึงสลับการรับส่งข้อมูลจากเวอร์ชันเก่าไปยังเวอร์ชันใหม่ เป็นวิธีที่ดีที่สุดต่อการจัดการเวอร์ชันของ APIs โดย Blue/green deployment นั้นมีความแตกต่างจาก Ramped deployment เนื่องจากแอปพลิเคชันเวอร์ชันเก่า “สีเขียว” ถูกปรับใช้ควบคู่ไปกับเวอร์ชันใหม่ “สีน้ำเงิน” หลังจากทดสอบว่าเวอร์ชันใหม่สามารถทำงานได้ตรงตามข้อกำหนด จากนั้นจึงจะอัปเดตออบเจ็กต์ Kubernetes Service ที่ทำหน้าที่เป็นตัวโหลดบาลานซ์เพื่อส่งปริมาณการใช้งานไปยังเวอร์ชันใหม่
ข้อดี
สามารถ rollout/rollback ได้รวดเร็ว และหลีกเลี่ยงปัญหาการกำหนดเวอร์ชันของแอปพลิเคชัน
ข้อเสีย
ต้องสามารถรองรับ ต้องมีทรัพยากรรองรับเพิ่มขึ้น ที่ต้องการเพิ่มขึ้นเป็น 2 เท่า อีกทั้งแอปพลิเคชันควรได้รับการทดสอบเป็นอย่างดีก่อนนำไปใช้จริง และค่อนข้างจัดการได้ยากถ้าเป็น stateful application
4. Canary deployment
วิธีนี้เป็นการให้ผู้ใช้งานเป็นผู้ทดสอบก่อนนำไปใช้จริงแบบเต็มรูปแบบ โดยการกำหนดเส้นทางผู้ใช้บางส่วนไปยังฟังก์ชันใหม่ ส่วนแอปพลิเคชันเวอร์ชันเดิมก็ยังคงทำอยู่ จากนั้นหลังจากผ่านไประยะหนึ่งหากไม่พบข้อผิดพลาดใดๆ ก็จะทำการขยายจำนวน replica ของเวอร์ชันใหม่และลบเวอร์ชันเก่าออกไป
การใช้เทคนิค ReplicaSet นี้ต้องเพิ่ม pod ให้ได้มากเท่าที่จำเป็นเพื่อให้ได้เปอร์เซ็นต์การเข้าการเข้าใช้งานที่เหมาะสม หากคุณต้องการส่งทราฟฟิก 1% ไปยังเวอร์ชัน B คุณต้องมีหนึ่ง pod ที่ทำงานด้วยเวอร์ชัน B และ 99 pod ที่ทำงานด้วยเวอร์ชัน A ซึ่งค่อนข้างไม่สะดวกในการจัดการ ดังนั้นหากคุณกำลังมองหาวิธีการจัดการทราฟฟิคที่ดีกว่า อาจจะใช้ตัวช่วยอย่าง load balancer เช่น HAProxy หรือ service mesh เช่น Linkerd ซึ่งช่วยให้สามารถควบคุมทราฟฟิคได้ดีขึ้น
ข้อดี
ด้วยการทดสอบประสิทธิภาพการทำงานจริง ผู้พัฒนา(developer) สามารถลดความเสี่ยงในการ deploy โดยมีแอปพลิเคชันสองเวอร์ชันที่ใช้งานได้ ดังนั้นผู้ใช้งานจึงไม่มีปัญหาการเข้าใช้งานไม่ได้(downtimes) นอกจากนี้ เวอร์ชัน Canary จะช่วยให้เห็นภาพความสามารถในการจัดการโหลด ความเร็วและประสิทธิภาพการใช้งานได้ด้วย
ข้อเสีย
ข้อเสียเปรียบหลักประการหนึ่งของวิธีนี้คือต้องใช้ทรัพยากรมาก เช่น (99% A/ 1%B = 99 pod A, 1 pod B) อีกทั้งยังใช้เวลาค่อนข้างนาน รวมถึงการทดสอบและการ deploy ต้องใช้เวลาในการตรวจสอบและประเมินผลอย่างละเอียด ด้วยเหตุนี้ผู้ใช้บางคนจึงไม่ได้ใช้ประโยชน์จากคุณลักษณะและได้อัปเกรดแอปพลิชันใหม่ได้ในทันทีหลังจากการปล่อยให้ใช้งาน(release) ซึ่งการใช้งานแอปพลิเคชันทั้งสองเวอร์ชันพร้อมกัน ผู้พัฒนา(developer) จำเป็นต้องคำนึงถึงและตรวจสอบข้อมูลใน database และ tech stack ให้รองรับการทำงานทั้ง 2 เวอร์ชันด้วย
5. A/B testing
วิธีนี้เหมาะสมที่สุดกับการทดสอบในกลุ่มตัวอย่าง ซึ่งเป็นเทคนิคที่ช่วยการตัดสินใจในธุรกิจโดยพิจารณาจากสถิติด้วย โดยสามารถประยุกต์ใช้ร่วมกับ canary deployment และเพิ่มด้วยเงื่อนไขในการกำหนดกลุ่มเป้าหมาย เช่น น้ำหนัก ค่าคุกกี้ การหาตำแหน่งทางภูมิศาสตร์ เวอร์ชันเบราว์เซอร์ ขนาดหน้าจอ ระบบปฏิบัติการ หรือภาษา เป็นต้น ซึ่ง Istio ก็เป็นอีกหนึ่งใน service mesh ที่รองรับการทำงานลักษณะนี้เนื่องจากมีความละเอียดในการแยก service instance โดยอาศัยข้อ HTTP header ในการ routing ได้
ข้อดี
รองรับการทำงานของแอปพลิเคชันได้มากกว่า 1 เวอร์ชันพร้อมกัน ซึ่งสามารถควบคุม traffic เพื่อรองรับการทดสอบประสิทธิภาพบนการใช้งานจริงและรองรับการย้อนกลับ (rollback) เทคนิคนี้จึงเป็นวิธีที่ดีที่สุดในการวัดประสิทธิภาพของฟังก์ชันการทำงานของแอปพลิเคชันโดยกลุ่มตัวอย่างที่ช่วยให้มีสถิติการใช้งานและพฤติกรรมของผู้ใช้งานจริง
ข้อเสีย
มีความซับซ้อนโดยต้องใช้กลุ่มตัวอย่าง และอาจเป็นเรื่องยากที่จะรับประกันความถูกต้องของผลการทดสอบ อีกทั้งยังมีความท้าทายอีกประการหนึ่งคือการ trace และสืบค้นในกรณเกิดปัญหา เนื่องจากแอปพลิเคชันทั้งเวอร์ชัน A และ B ทำงานพร้อมกันอยู่นั่นเอง
บทสรุป
การ deploy แอปพลิเคชันก็มีหลายวิธีให้เลือกใช้ สำหรับการใช้งานบน development หรือ staging environment เทคนิค Recreate หรือ Ramped deployment ก็ถือเป็นตัวเลือกที่ดี
ในส่วนของ production environment ในกรณีที่แพลตฟอร์มได้รับการทดสอบอย่างดีแล้วเทคนิค Ramped หรือ Blue/green deployment ก็จะเป็นตัวเลือกที่เหมาะสม แต่หากไม่มั่นใจในความเสถียรของแพลตฟอร์มหรืออาจมีผลกระทบจากการเปิดตัวซอฟต์แวร์เวอร์ชันใหม่ ก็ควรเลือกใช้ Canary deployment การทำเช่นนี้ทำให้ผู้ใช้งานสามารถทดสอบแอปพลิเคชันและการผสานรวมเข้ากับแพลตฟอร์มได้ แต่สุดท้ายแล้วหากธุรกิจต้องการทดสอบคุณลักษณะใหม่ในกลุ่มผู้ใช้เฉพาะ เช่น ผู้ใช้ทั้งหมดที่เข้าถึงแอปพลิเคชันโดยใช้โทรศัพท์มือถือจะถูกส่งไปยังเวอร์ชัน A ส่วนผู้ใช้ทั้งหมดที่เข้าถึงผ่านเดสก์ท็อปจะไปที่เวอร์ชัน B จากนั้น อาจต้องการใช้เทคนิค A/B testing โดยใช้ service mesh ในการกำหนดกลุ่มเป้าหมายนั่นเอง
ข้อมูลอ้างอิง
– https://www.techmagic.co/blog/best-application-deployment-strategies/
– https://blog.container-solutions.com/kubernetes-deployment-strategies
ผู้เขียน: ทีม DevOps ของ Blockfint ที่มีความเชี่ยวชาญ Cloud Native Services & Solutions
