ทุกวันนี้มี deployment strategy ให้เลือกใช้มากมาย และจะยิ่งเพิ่มขึ้นเรื่อย ๆ ตามกาลเวลา อย่างไรก็ตาม สองกลยุทธ์ที่ได้รับความนิยมและถูกนำไปใช้จริงในบริษัทชั้นนำมากที่สุดในปัจจุบันคือ Canary และ Blue-green deployment
เมื่อเปรียบเทียบ Blue-Green deployment กับ Canary แล้ว ไม่ใช่แค่เรื่องความเร็วหรือความเรียบง่าย แต่ปัจจัยสำคัญที่สุดอย่างหนึ่งในการเลือกระหว่างสองกลยุทธ์นี้คือ downtime ที่เกิดขึ้นระหว่างการ deploy
การเลือกกลยุทธ์ที่เหมาะสมระหว่าง Canary deployment กับ Blue-Green deployment เป็นสิ่งสำคัญ หากต้องการลด downtime และให้การอัปเดตหรือการปรับเปลี่ยนระบบดำเนินไปได้อย่างราบรื่น
มาดูกันว่าแต่ละกลยุทธ์มีอะไรให้บ้าง พร้อมเปรียบเทียบโดยตรงระหว่าง Blue-Green deployment กับ Canary รวมถึงประสบการณ์ของเราเองกับทั้งสองแนวทาง
Blue-Green Deployment คืออะไร และให้ประโยชน์อะไรบ้าง?
ใน Blue-Green deployment เวอร์ชันใหม่ของแอปพลิเคชันสามารถ deploy ได้ทันทีเมื่อผ่านการทดสอบและตรวจสอบแล้ว ทั้งหมดนี้เป็นไปได้เพราะมีสองสภาพแวดล้อมที่เหมือนกันทุกประการ นั่นคือ สภาพแวดล้อม blue และ green ซึ่งเป็นที่มาของชื่อ Blue-Green deployment
หลักการทำงานคือ สภาพแวดล้อมหนึ่งทำงานอยู่ (active) ส่วนอีกอันหยุดรอ (inactive) เวอร์ชันใหม่ของแอปพลิเคชันจะถูก deploy ไปยังสภาพแวดล้อมที่ inactive อยู่ (สมมติว่าเป็นฝั่ง green) เนื่องจากทั้งสองสภาพแวดล้อมมี resource, infrastructure และ configuration ที่เหมือนกันทุกอย่าง จึงสามารถค้นหาและแก้ไขปัญหาของการอัปเดตได้ก่อนที่จะ deploy จริง
เมื่ออัปเดตผ่านการทดสอบและทีม developer มั่นใจว่าทำงานได้ถูกต้องแล้ว traffic จะถูกสลับไปยังสภาพแวดล้อมที่ inactive อยู่ ทำให้สภาพแวดล้อม green กลายเป็น active และสภาพแวดล้อม blue ที่เคย active อยู่กลายเป็น inactive แทน
จากนั้น สภาพแวดล้อม blue ที่ inactive อยู่จะทำหน้าที่เป็น standby และสามารถใช้ทดสอบอัปเดตใหม่ได้ ขณะที่สภาพแวดล้อม green กำลังทำงานพร้อมรันอัปเดตที่เพิ่ง deploy ไป วิธีนี้แทบไม่มี downtime เลย เพราะ traffic ถูกสลับไปยังสภาพแวดล้อมที่ inactive ได้ทันที
นอกจากนี้ หากอัปเดตมีปัญหา ฟีเจอร์ rollback จะช่วยให้สลับกลับไปยังเวอร์ชันเก่าของแอปพลิเคชันได้ อย่างไรก็ตาม หาก developer เริ่มทำงานกับอัปเดตใหม่ในสภาพแวดล้อมที่ inactive ไปแล้ว การ rollback กลับไปยังสภาพแวดล้อมนั้นก็ไม่สามารถทำได้อีก เพราะเวอร์ชันเก่าไม่มีอยู่ในสภาพแวดล้อมนั้นแล้ว
มีหลายบริษัทที่ใช้กลยุทธ์นี้ ตัวอย่างที่เห็นได้ชัดคือ Spotify เนื่องจาก Spotify ต้องให้บริการตลอด 24/7 จึงเตรียมสภาพแวดล้อม backup ที่ inactive ไว้พร้อมเสมอเมื่อมีการปล่อยอัปเดตใหม่
Canary Deployment คืออะไร และให้ประโยชน์อะไรบ้าง?
ความแตกต่างหลักระหว่าง Canary deployment กับ Blue-Green คือ แทนที่จะมีสองสภาพแวดล้อมและ deploy อัปเดตไปยังผู้ใช้ทุกคนพร้อมกัน Canary deployment จะปล่อยอัปเดตให้ผู้ใช้กลุ่มเล็กๆ ก่อน
หากอัปเดตมีปัญหา ก็จะกระทบเฉพาะผู้ใช้กลุ่มเล็กๆ ที่ได้รับผลกระทบและให้ feedback กลับมา เมื่อแก้ไขปัญหาแล้ว อัปเดตจะถูกปล่อยให้ผู้ใช้กลุ่มใหญ่ขึ้น ซึ่งสามารถแจ้งปัญหาที่พบกลับมาให้ developer ได้อีกครั้ง
วงจรนี้จะทำซ้ำโดยขยายกลุ่มผู้ใช้ขึ้นเรื่อยๆ และแก้ไขปัญหาทั้งหมดไปทีละขั้น จนกว่าอัปเดตจะถูกปล่อยให้ผู้ใช้ครบ 100% ตัวอย่างเช่น เริ่มจากปล่อยให้ผู้ใช้ 2% ก่อน จากนั้น 25%, 75% และ 100% ตามลำดับ
การปล่อยแบบค่อยเป็นค่อยไปใน Canary deployment เมื่อเทียบกับ Blue-Green ช่วยให้การ rollout มีความควบคุมและยืดหยุ่นมากขึ้น developer สามารถทดสอบฟีเจอร์และอัปเดตในสภาพแวดล้อมที่ควบคุมได้ โดยมีเพียงผู้ใช้กลุ่มเล็กๆ ที่อาจพบปัญหา
Canary deployment ก็มีฟีเจอร์ rollback เช่นกัน แต่เนื่องจากการ deploy ทำแบบค่อยเป็นค่อยไปและเป็นขั้นตอน การ rollback จึงทำแบบเดียวกัน คือค่อยๆ ถอยกลับทีละขั้นจนกว่าจะถึงเวอร์ชันที่เสถียร
ตัวอย่างที่รู้จักกันดีของกลยุทธ์นี้คือ Netflix ที่ใช้ Canary ร่วมกับเครื่องมือชื่อ Chaos Monkey ซึ่งจงใจสร้าง failure ขึ้นในระบบ หาก failure นั้นกระทบสภาพแวดล้อม canary ทีม Netflix สามารถวิเคราะห์การตอบสนองของระบบและปรับแก้ได้ทันที วิธีนี้ช่วยให้ Netflix ยืนยันได้ว่าอัปเดตยังคงทำงานได้เสถียรแม้ในสภาวะที่มีปัญหา
Blue-Green Deployment กับ Canary: เปรียบเทียบ
ทั้งสองกลยุทธ์ต่างมีข้อดีในแบบของตัวเอง แต่ก็มีข้อจำกัดเช่นกัน ดังนั้นก่อนตัดสินใจ ควรชั่งน้ำหนักข้อดีและข้อเสียของ Blue-Green deployment กับ Canary ให้ดีก่อน
หากยังไม่แน่ใจว่าควรเลือกแบบไหนหลังจากอ่านส่วนนี้ ในตอนท้ายของบทความนี้ฉันได้รวมประสบการณ์ของเราเองกับทั้งสองกลยุทธ์และบทเรียนที่ได้รับไว้ด้วย
ลดเวลาหยุดเซิร์ฟเวอร์
หนึ่งในประเด็นหลักที่บทความนี้ให้ความสำคัญคือการลด downtime ในการ deploy ระหว่าง Blue-Green deployment กับ Canary จุดแข็งของ Blue-Green deployment คือความเร็ว เพราะสามารถ deploy อัปเดตหรือฟีเจอร์ใหม่ได้ทันทีผ่านการใช้สองสภาพแวดล้อม
ในทางกลับกัน การ deploy แบบ Canary ที่ค่อยๆ ปล่อยอัปเดตออกไปทีละน้อย ช่วยลด downtime ได้อย่างมีประสิทธิภาพ เพราะปัญหาที่เกิดขึ้นจะกระทบผู้ใช้เพียงกลุ่มเล็กๆ และเนื่องจากมีการเก็บ feedback ในทุกขั้นตอน การแก้ไขปัญหาจึงทำได้รวดเร็วกว่า โดยไม่ต้องหยุดระบบ
นอกจากนี้ แม้ทั้งสองแนวทางจะรองรับการ rollback แต่ Blue-Green deployment ทำได้ทันที ทำให้นักพัฒนามีแผนสำรองที่เชื่อถือได้หากเกิดปัญหาร้ายแรง อย่างไรก็ตาม อย่างที่กล่าวไปก่อนหน้านี้ หากกำลังพัฒนาเวอร์ชันใหม่ใน environment ที่ไม่ได้ใช้งานอยู่ เวอร์ชันสำรองนั้นจะไม่พร้อมใช้งาน
การ rollback ของ Canary ทำได้แบบค่อยเป็นค่อยไปเท่านั้น เช่นเดียวกับกระบวนการ deploy อย่างไรก็ตาม ฟีเจอร์นี้พร้อมใช้งานเสมอ เพราะเวอร์ชันที่เสถียรกว่าไม่ได้ผูกอยู่กับ environment ที่ใช้ทดสอบและพัฒนาอัปเดตใหม่
เมื่อเปรียบเทียบ Canary กับ Blue-Green ในแง่ของการลด downtime นั้น Canary มีข้อได้เปรียบด้านการควบคุมความเสี่ยงและการควบคุมแบบละเอียด แต่ถ้าพิจารณาเฉพาะเรื่องการลด downtime อย่างเดียว Blue-Green ทำได้ดีกว่า เนื่องจากการสลับระบบเกิดขึ้นทันที
อย่างไรก็ตาม เมื่อเปรียบเทียบระหว่าง Blue-Green กับ Canary deployment สิ่งสำคัญคือต้องพิจารณาปัจจัยอื่นนอกเหนือจากเรื่อง downtime ด้วย
ประเภทแอปพลิเคชัน
โดยทั่วไปแอปพลิเคชันแบ่งออกเป็นสองประเภทหลัก คือ แอปที่เน้นธุรกรรมหนาแน่น และแอปที่เน้นเนื้อหา สำหรับแอปประเภทแรก Blue-Green deployment เหมาะกว่ามาก เพราะให้ความสำคัญกับความพร้อมใช้งานสูงและ downtime ที่น้อยที่สุด ฟีเจอร์การสลับระบบและ rollback แบบทันทีจึงทำให้ Blue-Green เหนือกว่า Canary ในกรณีนี้
ในทางกลับกัน แอปที่เน้นเนื้อหาไม่ได้พึ่งพาธุรกรรมแบบ real-time เนื่องจากแอปเหล่านี้มักใช้กับแพลตฟอร์ม social media และบริการด้าน user engagement Canary จึงเป็นกลยุทธ์ที่เหมาะกว่า เพราะช่วยให้ปล่อยอัปเดตทีละน้อยและรับ feedback ได้ต่อเนื่องในทุกขั้นตอน
ต้นทุนโครงสร้างพื้นฐาน
อีกหนึ่งปัจจัยสำคัญในการเลือกระหว่าง Blue-Green กับ Canary deployment คือเรื่องค่าใช้จ่าย โดยธรรมชาติแล้ว Blue-Green deployment มีค่าใช้จ่ายสูงกว่า เพราะต้องดูแล environment แยกกันสองชุด
นั่นคือเหตุผลที่ production environment เดียวของ Canary เป็นตัวเลือกที่ประหยัดกว่ามาก และเหมาะกับทีมขนาดเล็กหรือแอปที่ไม่ต้องการทรัพยากรมาก
การขยายระบบและการดูแลรักษาระยะยาว
สุดท้าย แม้ว่า Blue-Green deployment จะขยายขนาดได้ แต่การดูแล environment สองชุดที่สมบูรณ์สำหรับแอปขนาดใหญ่นั้นต้องใช้ทรัพยากรมากและมีความซับซ้อนสูง เมื่อเวลาผ่านไป การจัดการและบำรุงรักษา environment ที่ซ้ำกันจะเพิ่ม overhead อย่างมาก โดยเฉพาะกับแอปที่มีโครงสร้างพื้นฐานซับซ้อน
เมื่อเปรียบเทียบ Canary กับ Blue-Green ด้านความสามารถในการขยายขนาดและการบำรุงรักษา Canary ชนะค่อนข้างชัดเจน การ deploy แบบ Canary ขยายขนาดได้ง่ายกว่าและคุ้มค่ากว่า เพราะไม่ต้องมี environment สองชุด
แนวทางนี้เน้นการขยายขนาดภายใน environment หลัก โดยค่อยๆ เพิ่มจำนวนผู้ใช้ที่ได้รับการเปลี่ยนแปลงใหม่ ในระยะยาว วิธีนี้จัดการได้ง่ายกว่ามาก เพราะช่วยลดความซับซ้อนของโครงสร้างพื้นฐานและทำให้การบำรุงรักษาทำได้ง่ายขึ้น
ประสบการณ์ของ Cloudzy กับ Blue-Green Deployment และ Canary Deployment
ในการให้บริการ DevOps แก่ลูกค้า เราเข้าใจดีว่าความพึงพอใจของผู้ใช้ ความพร้อมใช้งานสูง และ downtime ที่น้อยที่สุดล้วนมีผลโดยตรงต่อความสำเร็จทางธุรกิจ ในกรณีหนึ่ง ลูกค้าได้ติดต่อเราเพื่อขอความช่วยเหลือในการอัปเกรดโครงสร้างพื้นฐานครั้งใหญ่ และทีมงานต้องตัดสินใจว่าจะใช้ Blue-Green หรือ Canary deployment สำหรับระบบของพวกเขา
หลังจากพิจารณาอย่างถี่ถ้วนแล้ว เราตัดสินใจทดลองใช้ Blue-Green deployment ก่อน เพราะแทบไม่มี downtime เราตั้งค่า green environment ที่เหมือนกันทุกประการและเตรียมปล่อยการอัปเกรด มีแรงกดดันไม่น้อย เพราะเพียงกดปุ่มเดียว traffic ทั้งหมดจะถูกสลับไปยัง green environment และอย่างที่นักพัฒนาทราบดี ไม่ว่าจะทดสอบมากแค่ไหน ผลลัพธ์ก็ยังมีความไม่แน่นอนอยู่เสมอ
โชคดีที่ทุกอย่างผ่านไปด้วยดี การเปลี่ยนผ่านเป็นไปอย่างราบรื่น และแทบไม่มีปัญหาใดๆ เมื่อเวลาผ่านไป บริการและฐานผู้ใช้ของลูกค้าขยายตัวขึ้น เราจึงต้องปล่อยฟีเจอร์ใหม่ และการถกเถียงระหว่าง Blue-Green กับ Canary ก็กลับมาอีกครั้ง
อย่างไรก็ตาม ครั้งนี้ไม่ต้องถกเถียงกันมาก ฟีเจอร์เหล่านี้มีขนาดเล็กกว่าและไม่ได้มีความซับซ้อนใกล้เคียงกับการอัปเกรดโครงสร้างพื้นฐานครั้งก่อน เราจึงเลือกใช้ Canary อย่างเป็นธรรมชาติ เพราะสามารถปล่อยฟีเจอร์ให้ผู้ใช้กลุ่มเล็กๆ ก่อน และแก้ไขปัญหาจาก feedback ที่ได้รับ
นั่นเป็นการตัดสินใจที่ถูกต้อง แม้จะไม่มีปัญหาใหญ่ แต่ปัญหาเล็กๆ น้อยๆ เริ่มปรากฏขึ้น โดยถูกรายงานจากผู้ใช้ 5% ที่ได้รับฟีเจอร์นั้นไปแล้ว
ที่ Cloudzy เราเชื่อในการหาทางออกที่เหมาะกับแต่ละสถานการณ์ ไม่ว่าธุรกิจของคุณจะต้องการความเสถียรของ Blue-Green deployment หรือความยืดหยุ่นของ Canary deployment ทีม DevOps ของเรามีประสบการณ์และความรู้ที่พร้อมนำกลยุทธ์ที่ดีที่สุดไปใช้กับโครงสร้างพื้นฐานของคุณ ติดต่อเรา ที่นี่ วันนี้เพื่อเรียนรู้ว่าเราจะช่วยปรับปรุงกระบวนการ deploy ของคุณและทำให้ระบบทำงานได้อย่างต่อเนื่องได้อย่างไร
พูดถึง VPS เรานำเสนออัตราราคาที่แข่งขันได้ในตลาด VPS พร้อมฟีเจอร์ที่ครบครัน ได้แก่ มากกว่า 12 location ทั่วโลก, การเชื่อมต่ออินเทอร์เน็ตแบบ dedicated สูงสุด 10 Gbps, พื้นที่เก็บข้อมูล NVMe SSD ระดับ enterprise, โปรเซสเซอร์ AMD EPYC turbo-speed 3.23 GHz และ uptime 99.95% ดูรายละเอียดเพิ่มเติมได้ที่ ราคา VPS สำหรับข้อมูลเพิ่มเติม
สรุป
ท้ายที่สุดแล้ว เมื่อพูดถึง Canary กับ Blue-Green deployment คงพูดไม่ได้ว่าแนวทางใดดีกว่าอีกแนวทางอย่างชัดเจน ทุกอย่างขึ้นอยู่กับ use case และสิ่งที่เหมาะกับความต้องการเฉพาะของคุณ
คำถามที่พบบ่อย
ความแตกต่างหลักระหว่าง Blue-Green deployment กับ Canary deployment คืออะไร?
ความแตกต่างหลักระหว่าง Blue-Green และ Canary deployment อยู่ที่วิธีการปล่อยอัปเดต Blue-Green deployment ใช้ environment สองชุดที่เหมือนกัน โดยนำอัปเดตไปใช้กับชุดที่ไม่ได้ใช้งาน เพื่อให้สลับระบบได้ทันทีแทบไม่มี downtime ในทางตรงกันข้าม Canary deployment ปล่อยอัปเดตไปยังผู้ใช้กลุ่มเล็กๆ ก่อน ตรวจสอบปัญหา แล้วจึงค่อยๆ ขยายไปยังผู้ใช้ทั้งหมด
ระหว่าง Blue-Green deployment กับ Canary deployment อันไหนช่วยลด downtime ได้ดีกว่า?
Blue-Green deployment เหมาะกว่าสำหรับการลด downtime เพราะสลับระหว่าง environment ได้ทันที ช่วยลดการหยุดชะงักที่อาจเกิดขึ้น แม้ Canary deployment จะมีเป้าหมายลด downtime เช่นกัน แต่ทำผ่านการปล่อยอัปเดตทีละน้อย ซึ่งอาจมีปัญหาเล็กน้อยในเฉพาะกลุ่มผู้ใช้บางส่วน
Blue-Green deployment กับ Canary deployment มีค่าใช้จ่ายต่างกันอย่างไร?
Blue-Green deployment มีค่าใช้จ่ายสูงกว่าโดยทั่วไป เพราะต้องดูแล environment สองชุดที่สมบูรณ์ ในทางกลับกัน Canary deployment คุ้มค่ากว่า เนื่องจากไม่ต้องมีโครงสร้างพื้นฐานซ้ำกัน อัปเดตจะถูกปล่อยภายใน environment หลักเพียงชุดเดียว ทำให้เป็นตัวเลือกที่เหมาะกับทีมขนาดเล็กหรือแอปที่ไม่ต้องการทรัพยากรมาก
