ทำไมเว็บไซต์อี-คอมเมิร์ซของคุณต้องการแนวทาง Multi-Cloud ที่ใช้งานได้จริงในช่วงเทศกาลวันหยุด

สำหรับผู้นำอี-คอมเมิร์ซ เทศกาลวันหยุดมีความแน่นอนสองประการ: การเข้าชมของผู้ชมหยุดเป็นจำนวนมากและความเสี่ยงของการหยุดทำงานของคลาวด์ผู้ให้บริการที่เพิ่มขึ้น การหยุดทำงานของคลาวด์ขนาดใหญ่ดูเหมือนจะเกิดขึ้นบ่อยขึ้นและรุนแรงขึ้น ตัวอย่างเช่น ภูมิภาค US-East-1 ของ AWS มีประวัติการหยุดทำงานในช่วงเทศกาลวันหยุดที่สำคัญ ในทำนองเดียวกัน ทุกๆ ปีในเดือนมกราคม Microsoft Azure มักจะมีปัญหาเรื่องความล่าช้าของเครือข่ายหรือการหยุดทำงานของเครือข่ายเนื่องจากแผนการปล่อยหรือทดสอบในบางภูมิภาค และเราต้องมองย้อนกลับไปในเดือนมิถุนายนปีที่แล้วเมื่อการหยุดทำงานของ Google Cloud ที่สำคัญส่งผลกระทบต่อแอปพลิเคชันหลากหลาย เพื่อเตือนให้เราได้ว่าไม่มีผู้ให้บริการเดียวที่ไม่มีจุดอ่อน

หากคุณเป็นผู้รับผิดชอบการดำเนินงานอี-คอมเมิร์ซ คุณไม่ต้องการพบว่าแม้ว่าคุณได้ตั้งค่าทุกอย่างให้ถูกต้อง แต่มีสิ่งหนึ่งที่หยุดทำงานในช่วงเวลาที่สำคัญที่สุดของปี เทรนด์การหยุดทำงานและปัญหาเหล่านี้อาจไม่อยู่ในเรดาร์ของคุณ และโดยแท้จริงแล้วไม่ควรอยู่ หากคุณเป็นวิศวกรความน่าเชื่อถือของไซต์ คุณไม่ควรต้องกังวลว่าผู้ให้บริการคลาวด์จะหยุดทำงานหรือไม่ และคุณไม่ควรพยายามปรับโครงสร้างพื้นฐานของคุณในขณะเกิดปัญหาแทน คุณควรพิจารณาอีกครั้งเกี่ยวกับสิ่งที่คุณรู้เกี่ยวกับคลาวด์หลายแห่ง

แอปพลิเคชัน Multi-Cloud

หากองค์กรของคุณจ่ายค่าใช้จ่ายให้กับ AWS, Azure และ GCP คุณมีคลาวด์ทั้งสามอยู่ที่ความพร้อมใช้งานของคุณ แต่นั่นบอกว่าเมื่อคุณไปสู่ระดับที่ลึกกว่านั้น คุณควรตรวจสอบว่าเกิดอะไรขึ้นเมื่อคุณไปถึงระดับที่ลึกกว่านั้น แอปพลิเคชันบางตัวของคุณเป็นของ AWS, Azure หรือ GCP เฉพาะเจาะจงหรือไม่? มันจะยังคงทำงานได้หรือไม่หากผู้ให้บริการคลาวด์หนึ่งหยุดทำงานและคุณต้องเปลี่ยนไปใช้อีกคลาวด์หนึ่งโดยเร็ว?

แอปพลิเคชันของคุณต้องทำงานได้อย่างสมบูรณ์แบบบนคลาวด์ใดๆ ก็ตาม นั่นคือสิ่งที่เรียกว่าการตั้งค่า Multi-Cloud ที่แท้จริง หากคุณต้องการเป็นกลางในเรื่องคลาวด์ คุณไม่สามารถจ่ายค่าใช้จ่ายสำหรับ Multi-Cloud ได้เพียงอย่างเดียว คุณต้องแน่ใจว่าแอปพลิเคชันของคุณก็เป็น Multi-Cloud เช่นกัน

นอกจากนี้ การพึ่งพาผู้ให้บริการเดียวทำให้เกิดข้อจำกัดที่มีผลต่อความสามารถในการคำนวณ อัตราการจำกัด API และความพร้อมใช้งานในภูมิภาค การตั้งค่า Multi-Cloud ที่แท้จริงจะเพิ่มขีดความสามารถในการคำนวณของคุณและให้ความทนทานต่อข้อจำกัดเหล่านี้ มันปลดปล่อยความสามารถของคุณในการปรับขนาดตามความต้องการเกินขีดจำกัดของผู้ให้บริการเดียว เพื่อขยายความสามารถอย่างรวดเร็วข้ามภูมิภาค และเพื่อให้แน่ใจว่ามีการทำงานที่สม่ำเสมอในช่วงวันช็อปปิ้งที่มียอดสูงสุด แต่การมีแอปพลิเคชันที่สามารถพกพาได้และเป็นกลางในเรื่องคลาวด์เป็นเพียงขั้นตอนแรก ขั้นตอนต่อไปคือการนำไปใช้ในโครงสร้างที่มีความทนทานอย่างแท้จริง

การปรับขนาดไปสู่แนวทาง Active-Active

สิ่งนี้ต้องใช้การเตรียมการอย่างจริงจังโดย DevOps เป็นเรื่องที่ยากมากที่จะสร้างกลยุทธ์การฟื้นตัวจากภัยพิบัติแบบ Business Continuity Disaster Recovery (BCDR) ที่มีความแม่นยำ 100% เนื่องจากเมื่อทำงานแบบสดๆ มีจุดอ่อนหลายจุด คุณไม่ต้องการทดสอบกลยุทธ์ BCDR ของคุณในช่วงการหยุดทำงาน ดังนั้นคุณอาจรู้สึกว่าทุกสิ่งที่คุณสามารถทำได้คือการคาดการณ์เหตุการณ์ที่อาจเกิดขึ้นแล้วเตรียมการตามนั้น

คำแนะนำของฉันสำหรับวิศวกรความน่าเชื่อถือของไซต์คือการออกแบบสำหรับการล้มเหลวโดยค่าเริ่มต้น ซึ่งหมายความว่าคุณมีคลาวด์รองหรือแม้กระทั่งคลาวด์ที่สามที่ทำงานในสถานะที่ใช้งานได้ กลยุทธ์ BCDR ที่จำกัดอยู่ในผู้ให้บริการเดียวคือจุดอ่อนเดียว หากผู้ให้บริการมีเครือข่ายหลักหรือโครงข่ายหลักการควบคุมล้มเหลว แผนการกู้คืนของคุณจะสูญเปล่า

ในช่วงเทศกาลวันหยุด เป็นเรื่องปกติที่จำนวนผู้เข้าชมจะเพิ่มขึ้นอย่างรวดเร็ว ทำให้แพลตฟอร์มหรือแอปพลิเคชันของคุณเริ่มทำงานในความสามารถที่ลดลง หากคุณได้สร้างสำเนาของแอปพลิเคชันที่ทำงานแล้ว คุณสามารถเปลี่ยนไปใช้การกระจายภาระงานเพื่อกระจายคำขอไปยังอินสแตนซ์อื่นของแอปพลิเคชันของคุณ

แนวทาง Active-Active หมายความว่าคุณมีผลิตภัณฑ์ที่สมบูรณ์แบบซ้ำซ้อนและทำงานที่อื่น หากผู้ให้บริการคลาวด์หลักของคุณประสบกับการเสื่อมสภาพหรือการหยุดทำงานอย่างรุนแรง คุณสามารถเปลี่ยนการรับส่งข้อมูล 100% ไปยังผู้ให้บริการรองที่สองผ่าน DNS หรือการกระจายภาระงานระดับโลก โดยไม่หยุดชะงักให้กับลูกค้าของคุณ

ต้นทุนจริงของการไม่ไปสู่ Multi-Cloud

แม้ว่าต้นทุนในการใช้งานคลาวด์รองจะไม่เล็กนัก แต่ก็ไม่สำคัญเมื่อเทียบกับผลกระทบทางธุรกิจของการหยุดทำงานครั้งใหญ่: การขอโทษลูกค้าหลังจากความล้มเหลวของความน่าเชื่อถือ การพยายามให้ความมั่นใจกับพวกเขาและบอกว่ามันจะไม่เกิดขึ้นอีก และการพยายามชักชวนให้พวกเขาไม่ไปหาคู่แข่งของคุณ มาทำให้เราไม่ลืมรายได้ที่พลาดไปจากยอดขายที่คุณไม่สามารถชนะกลับมาได้ ที่ FluidCloud ฉันเห็นสถานการณ์นี้เกิดขึ้นซ้ำๆ: บริษัทต่างๆ ลงทุนอย่างมากในผู้ให้บริการเดียวเพียงเพื่อพบว่าตัวเองอยู่ในสถานการณ์ที่ไม่ดีโดยไม่มีการแก้ไขทันที

อย่างไรก็ตาม การควบคุมค่าใช้จ่ายของคุณยากพอที่จะใช้คลาวด์ผู้ให้บริการเดียว ค่าใช้จ่ายคลาวด์ของคุณมีลักษณะเหมือนกราฟที่เพิ่มขึ้นอย่างช้าๆ หากคุณใช้คลาวด์หลายแห่ง กราฟนั้นจะยิ่งดูสูงขึ้น

เมื่อคุณทำซ้ำโครงสร้างพื้นฐานจากคลาวด์หลัก คุณไม่ต้องการให้ค่าใช้จ่ายของคุณเพิ่มขึ้นสองเท่า ดังนั้นฉันจึงแนะนำให้มุ่งเน้นไปที่คลาวด์ที่มีราคาถูกกว่าซึ่งให้ประสิทธิภาพที่แข่งขันได้ในราคาประหยัด หากคุณมีคลาวด์รองทำงานในคลาวด์ที่มีราคาถูกกว่า คุณยังคงมีการสำรองแบบ Active-Active ที่สมบูรณ์ แต่ด้วยต้นทุนที่ต่ำกว่า นั่นคือผลลัพธ์ที่ดีทั้งสองด้าน

ความคิดสุดท้าย

การทำงานของแอปพลิเคชันแบบ Active-Active บนผู้ให้บริการคลาวด์หลายแห่งไม่เพียงแต่หมายถึงการสร้างสำเนาเท่านั้น แต่ยังหมายถึงการสร้างความทนทานแบบเรียลไทม์ เพื่อให้แน่ใจว่าธุรกิจของคุณไม่มีจุดอ่อนเดียว และสามารถให้ความเร็วที่สม่ำเสมอได้แม้ในช่วงการรับส่งข้อมูลที่สูง

ในช่วงเทศกาลวันหยุดนี้ อย่าเพียงแต่หวังว่าจะมีความน่าเชื่อถือเท่านั้น แต่ให้สร้างความน่าเชื่อถือให้เกิดขึ้น พัฒนาระบบของคุณให้ทำงานอย่างสม่ำเสมอ ไม่ว่าผู้ให้บริการคลาวด์หรือภูมิภาคใดจะล้มเหลว ส่งมอบประสบการณ์ลูกค้าที่สมบูรณ์แบบโดยการยอมรับโครงสร้าง Multi-Cloud ที่ใช้งานได้จริงและ Active-Active