เราประหยัดค่าใช้จ่ายในการจัดการปริมาณการรับส่งข้อมูลได้ 38% ด้วยการใช้เกตเวย์ที่สร้างขึ้นบนคลาวด์ แต่เกือบจะทำให้ระบบจัดส่งสินค้าสดในยุโรปล้มเหลวในช่วงวัน Black Friday

เมื่อสัปดาห์ที่แล้วการประชุมการขายใหม่ของโปรโมชั่นของวันศุกร์สีดําเพิ่งสิ้นสุดลงและทีมแบ็คเอนด์การจัดส่งสดในยุโรปของเรา 3 คนยังคงเย็นอยู่: 17% ของคําขอนัดหมายห่วงโซ่เย็นในวันพรีเซลกลับไปที่ 429 โดยตรงปริมาณการร้องเรียนของผู้ใช้เพิ่มขึ้นเป็นสามเท่าเกือบจะทําให้โปรโมชั่นประจําปีสามเดือนที่เตรียมไว้

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

What exactly is a cloud-native gateway?

พูดง่ายๆ ก็คือ: มันคือจุดเข้าสู่การรับส่งข้อมูลที่ทำงานอยู่ภายในคลัสเตอร์ K8s คุณไม่จำเป็นต้องเช่าเซิร์ฟเวอร์เพิ่มเติมเพื่อติดตั้งมันเองคุณแค่ต้องดูแลกฎเกณฑ์การเส้นทาง (routing rules) และกลยุทธ์การจำกัดปริมาณการใช้งาน (throttling strategies) เท่านั้น ส่วนเรื่องความยืดหยุ่นของทรัพยากรและการอัปเกรดการบำรุงรักษา (operational maintenance upgrades) นั้น ผู้ให้บริการคลาวด์จะจัดการให้ทั้งหมดเราใช้เวอร์ชันปัจจุบันซึ่งสามารถรองรับการร้องขอได้ถึง 20,000 ครั้งต่อวินาทีสำหรับแต่ละอินสแตนซ์เดียว ดังนั้นไม่จำเป็นต้องวางแผนขนาดความจุล่วงหน้า

หลังจากการแปลง เราได้รับผลตอบแทนที่แท้จริงสามรายการ

หลังจากเกิดข้อขัดข้องในวันจำหน่ายล่วงหน้า เราใช้เวลา 3 วันในการย้ายไปใช้เกตเวย์แบบคลาวด์เนทีฟ และในวันแข่งขัน Black Friday ไม่มีปัญหาการจำกัดการใช้งาน (throttling) ที่เกิดจากข้อผิดพลาดเกิดขึ้นอีกเลย นอกจากนี้ยังมีข้อดีอีกสามประการที่เกินความคาดหมาย:

• ค่าใช้จ่ายลดลงโดยตรง: ก่อนหน้านี้เราเช่าเซิร์ฟเวอร์ 4 คอร์ 8G สองเครื่องแยกต่างหากเพื่อเรียกใช้เกตเวย์แบบดั้งเดิมบวกกับการดําเนินงานและบํารุงรักษาการใช้เวลา 8 ชั่วโมงต่อเดือนในการอัพเกรดเวอร์ชันคํานวณค่าใช้จ่ายรายเดือน 1200 ยูโร ตอนนี้เกตเวย์พื้นเมืองคลาวด์จ่ายตามปริมาณการโทรใช้จ่ายเพียง 740 ยูโรต่อเดือนลดต้นทุนการจัดการการใช้งานดาต้าได้ถึง 38% โดยตรง
• ในที่สุดกลยุทธ์การ จํากัด กระแสก็สามารถใช้งานได้อย่างชัดเจน: เกตเวย์ก่อนหน้านี้สามารถกําหนดเกณฑ์การ จํากัด กระแสตามอินเทอร์เฟซทั่วโลกเท่านั้น ตอนนี้เราสามารถกําหนดกฎอิสระสําหรับสถานการณ์ธุรกิจที่แตกต่างกัน - ตัวอย่างเช่นอินเทอร์เฟซการแก้ไขที่อยู่ส่งคําขอสูงสุด 5000 ครั้งต่อวินาทีแม้ว่ามันจะระเบิด แต่ก็จะไม่ส่งผลกระทบต่อการชําระเงินและการเชื่อมโยงการนัดหมายที่ตามมา
• HTTPS ใช้เวลาการจับมือลดลงครึ่งหนึ่งโดยตรง: ก่อนหน้านี้ใบรับรอง SSL ของเราอยู่ในเซิร์ฟเวอร์เกตเวย์ของเราเองความล่าช้าในการจับมือของผู้ใช้ในภูมิภาคต่างๆของยุโรปสามารถทําได้ถึง 200ms ตอนนี้ผู้ผลิตคลาวด์แคชใบรับรองไปยังโหนดขอบและความล่าช้าในการจับมือของคําขอส่วนใหญ่สามารถกดได้ภายใน 80ms

อย่าเร่งรีบขึ้นรถนะ พวกเราเคยเจอปัญหาเหล่านี้มาแล้ว

ไม่ใช่ว่าเกตเวย์แบบคลาวเนทีฟ (cloud-native gateway) จะมีแต่ข้อดีเสมอไป ในระหว่างที่เราทำการเปลี่ยนมาใช้เกตเวย์แบบนี้ เราก็เจอปัญหาสองอย่างที่เกือบทำให้ต้องทำงานใหม่:

ประการแรกคือปัญหาความล่าช้าของการเริ่มต้นเย็นเพิ่งตัดวันแรกที่เราทําการทดสอบความดันและพบว่าหลังจากไม่มีคําขอเป็นเวลา 10 นาทีติดต่อกันเวลาตอบสนองของคําขอคลื่นแรกก็เพิ่มขึ้นเป็นมากกว่า 300ms ต่อมาเราก็รู้ว่าอินสแตนซ์ที่ยืดหยุ่นของผู้ผลิตคลาวด์จะเริ่มต้นตามความต้องการและจําเป็นต้องตั้งค่าการสํารองอินสแตนซ์ขั้นต่ําสําหรับอินเทอร์เฟซหลักมิฉะนั้นการจราจรจะหมดเวลาอย่างฉับพลันเมื่อไม่ได้ใช้งาน

ข้อที่สองคือข้อ จํากัด ของปลั๊กอินที่กําหนดเองก่อนหน้านี้เราเขียนปลั๊กอินเพื่อขอการตรวจสอบการตรวจสอบและทํางานบนเกตเวย์แบบดั้งเดิม เมื่อเราตัดเราพบว่าเกตเวย์พื้นเมืองบนคลาวด์ที่เราใช้รองรับปลั๊กอินในรูปแบบ WebAssembly เท่านั้น ใช้เวลาสองวันในการเปลี่ยนโค้ดเพื่อปรับให้เสร็จสมบูรณ์ หากคุณมีตรรกะที่กําหนดเองจํานวนมากควรดูขอบเขตการสนับสนุนปลั๊กอินของผู้ผลิตก่อน

ควรจะเปลี่ยนหรือไม่นะ? ลองดูเกณฑ์การตัดสินใจสองข้อนี้ก่อนเลย

สถานการณ์ที่คุณควรเปลี่ยน:

• ทีมมีจำนวนผู้เขียนโปรแกรมหลังบ้าน (backend developers) น้อยกว่า 5 คน และไม่มีบุคลากรที่เชี่ยวชาญด้านการดูแลระบบ (ops personnel) ดังนั้นไม่อยากเสียเวลาไปกับการบำรุงรักษาหรืออัปเกรดเซิร์ฟเวอร์เกตเวย์
• การเปลี่ยนแปลงของปริมาณการใช้งาน (Traffic Fluctuations) นั้นสูงมาก ตัวอย่างเช่น ในช่วงที่มีการส่งเสริมการขาย (Promotions) ปริมาณการใช้งานอาจเพิ่มขึ้นถึง 3-10 เท่าของปกติ และเราไม่ต้องการเช่าเซิร์ฟเวอร์จำนวนมากล่วงหน้าเพราะอาจทำให้เกิดการสูญเสียเงินจากการใช้งานที่ไม่จำเป็นในช่วงเวลาปกติ

สถานการณ์ที่คุณไม่ควรเปลี่ยนแปลง:

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

สามคำแนะนำเล็กๆ สำหรับผู้ที่เริ่มต้นใช้งานเป็นครั้งแรก

• ไม่จําเป็นต้องตัดเต็มรูปแบบก่อนนํา 10% ของการจราจรไปยังเกตเวย์พื้นเมืองของคลาวด์เพื่อทํางานเป็นเวลาหนึ่งสัปดาห์ไม่มีความผิดปกติในการตรวจสอบแล้วค่อยๆตัด เราเริ่มต้นด้วยการตัดอินเทอร์เฟซการวิเคราะห์ที่อยู่ก่อนไม่มีปัญหาในการย้ายการจราจรเต็มรูปแบบ
• อินเทอร์เฟซหลักต้องกำหนดจำนวนอินสแตนซ์ขั้นต่ำไว้ อย่าประหยัดเงินเล็กน้อยนั้น เราได้จัดเตรียมอินสแตนซ์ถาวรไว้ 2 ตัวสำหรับอินเทอร์เฟซหลักทั้งสอง คือ การจองและการชำระเงินสำหรับระบบโซ่อุณหภูมิ และตั้งแต่นั้นมาก็ไม่เคยเกิดปัญหาเรื่องการเริ่มต้นทำงานช้า (cold start timeout) อีกเลย
• ไม่จําเป็นต้องซื้อรุ่นที่มีคุณสมบัติสูงสุด ส่วนใหญ่ของขนาดการจราจร ฟังก์ชันของรุ่นพื้นฐานจะเพียงพออย่างสมบูรณ์ เราใช้รุ่นพื้นฐานในขณะนี้ไม่จําเป็นต้องเพิ่มเงินภายใน 20,000 QPS

คำตอบสุดท้ายสำหรับคำถามที่ทีมงานถามกันบ่อยที่สุด: จะถูกผูกขาดกับผู้ให้บริการคลาวด์หรือไม่?

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