เติมเงินในบัญชี Google Cloud: GCP ยึด VM(Spot) มักถูกรีไซเคิล? แนวทางปฏิบัติสำหรับทางเลือกที่มีความพร้อมใช้งานสูงและการป้องกันการตัดกระแส

บน Google Cloud Platform (GCP) การยึด VM (ปัจจุบันเรียกรวมกันว่า Spot VM) ดึงดูดนักพัฒนาและบริษัทจำนวนมากด้วยส่วนลดสูงสุดถึง90% อย่างไรก็ตาม,

Spot VM อาจถูกบังคับให้กู้คืนโดย GCP (Preemption) ได้ตลอดเวลาและหน้าต่างปิดเครื่องที่หรูหราเพียง30วินาที

。

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

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

1.เหตุใด Spot VM จึงถูกรีไซเคิลเสมอ?

Spot VM ของ GCP ใช้พลังการประมวลผลที่ไม่ได้ใช้งานของศูนย์ข้อมูลของ Google เมื่อผู้ใช้ที่จ่ายเงินในมาตรฐานที่สูงขึ้น (On-Demand) ร้องขอพลังการประมวลผลหรือทรัพยากรในโซนว่าง (Zone) แน่นระบบจะให้ความสำคัญกับการกู้คืนพลังการประมวลผลของ Spot VM

ปัจจัยหลักที่พบบ่อยได้แก่:

พื้นที่ว่างยอดนิยมและรุ่นยอดนิยม: ตัวอย่างเช่น n2-standard us-central1-a เป็นที่นิยมอย่างมากและมีทรัพยากรที่ไม่ได้ใช้งานน้อยมาก

ความต้องการพลังงานในการประมวลผลสูงสุด: การใช้พลังงานในการประมวลผลของศูนย์ข้อมูลในช่วงกลางวันของวันธรรมดาโดยทั่วไปจะสูงกว่าในเวลากลางคืนและวันหยุดสุดสัปดาห์

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

ประการที่สอง GCP ยึด VM ทางเลือกที่มีความพร้อมสูงและโซลูชั่นไฮบริด

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

ตัวเลือกที่1: อินสแตนซ์กลุ่มผสมโฮสติ้ง (Hybrid MIG)

ใน GCP อย่าใช้กลุ่มอินสแตนซ์ Spot VM เพียงอย่างเดียวแต่สร้างไฟล์

สถาปัตยกรรมไฮบริดที่รวมอินสแตนซ์ตามความต้องการ (On-Demand) และอินสแตนซ์ Spot

。

หลักการใช้งาน: ปรับใช้ VM ตามความต้องการมาตรฐานเป็น "Base Capacity" เพื่อประมวลผลการรับส่งข้อมูลทางธุรกิจหลักและรับประกันบนพื้นฐานนี้คลัสเตอร์แบบขยายจะใช้ Spot VM เพื่อรองรับการรับส่งข้อมูลสูงสุด

ข้อดี: แม้ว่าโหนด Spot จะได้รับการกู้คืน100% แต่โหนดตามความต้องการที่ด้านล่างยังคงสามารถรับประกันการไหลของบริการพื้นฐานอย่างต่อเนื่องและลดความสามารถในการรับน้ำหนักพร้อมกันเพียงบางส่วนเท่านั้น

ตัวเลือกที่2: Multi-Zone & Multi-Machine Policy (Multi-Zone & Multi-Machine Policy)

อย่าใส่ไข่ทั้งหมดในพื้นที่ว่างเดียวกันหรือในรุ่นเดียวกัน

โหมดการทำงาน: สร้างกลุ่มอินสแตนซ์การโฮสต์ระดับภูมิภาค (Regional MIG) และกระจายอินสแตนซ์ Spot ในพื้นที่ว่างมากกว่า3แห่ง (เช่น

Us-central1-a/b/f)

การกระจายโควต้า: ด้วยการใช้โมเดลที่แตกต่างกัน (เช่นอนุญาตให้ e2-standard-4และ n2-standard-4ในเวลาเดียวกัน) เนื่องจากอัตราการใช้งานที่แตกต่างกันของแต่ละรุ่นความน่าจะเป็นที่พื้นที่ขนาดใหญ่จะถูกกู้คืนพร้อมกันจะลดลงอย่างทวีคูณ

โปรแกรมที่3: โยกย้ายไปยัง GKE(Kubernetes)+ Autopilot/Spot Node Pool

หากคุณกำลังเรียกใช้แอปพลิเคชันคอนเทนเนอร์การย้ายไปยังบริการคอนเทนเนอร์ GKE เป็นทางเลือกที่ดีกว่า

การตั้งเวลาที่ยืดหยุ่น: GKE รองรับสปอตโหนดพูล (Spot Node Pool) เมื่อโหนด Spot ได้รับการแจ้งเตือนการกู้คืน GKE จะเรียกใช้การดำเนินการ drain โดยอัตโนมัติเพื่อย้าย Pod ไปยังโหนดอื่นที่มีอยู่

กลยุทธ์การผสม: ตั้งค่าความสัมพันธ์และความอดทนของ Pod ปรับใช้พื้นผิวควบคุมหลักในพูลโหนดตามความต้องการและปรับใช้ Pod ที่ใช้งานได้อย่างยืดหยุ่นในพูลโหนด Spot

ตัวเลือกที่4: ซื้อ Commitment Discounts (ส่วนลดที่จองไว้) เป็นทางเลือกสำหรับ Spot

หากธุรกิจของคุณต้องทำงานอย่างต่อเนื่องและมีเสถียรภาพตลอด24/7และไม่สามารถเปลี่ยนเป็นสถาปัตยกรรมไร้สัญชาติได้ขอแนะนำให้ละทิ้ง Spot VM โดยตรงและเปลี่ยนไปใช้

CUD (Commission-Based Discounts สัญญาว่าจะใช้ส่วนลด)

。

ผลกระทบ: สัญญาว่าจะใช้เป็นเวลา1หรือ3ปี VM ตามความต้องการจะได้รับส่วนลดตั้งแต่37% ถึง57% ซึ่งช่วยประหยัดเงินและ100% จะไม่ถูกรีไซเคิล

3.แนวทางปฏิบัติสำหรับการกำหนดค่าหลักเพื่อป้องกันไม่ให้บริการ "หยุดชะงัก"

หากธุรกิจของคุณยังคงต้องใช้ Spot VM เพื่อลดต้นทุนคุณสามารถสร้างอุปสรรค "ป้องกันกระแสตัด" ที่สมบูรณ์ได้ในสี่ขั้นตอนต่อไปนี้:

1.กำหนดค่า30วินาทีปิดสคริปต์ (Shutdown Script) เพื่อจับสัญญาณ

เมื่อ GCP ตัดสินใจเรียกคืนโหนด Spot ก็จะออก

ACPI G2 Soft Off

ปิดสัญญาณและเก็บเวลาบัฟเฟอร์สูงสุด30วินาทีต้องใช้เวลา30วินาทีนี้ในการออกอย่างสง่างาม

ตั้งค่าในข้อมูลเมตา (Metadata)

Shutdown-script

:

แบช

#! /Bin/bash

#1.ส่งสัญญาณความล้มเหลวในการตรวจสุขภาพไปยังโหลดบาลานซ์/เกตเวย์เพื่อหยุดการรับส่งข้อมูลใหม่

Echo "Draining connection..." > /var/ www/html/healthcheck.html

#2.แจ้งบริการภายในเรียบตัดการเชื่อมต่อยาว (เช่น WebSocket, สถานะ TCP)

#3.ใส่ข้อมูลที่ไม่ได้ซิงค์ในเครื่องลงใน Cloud Storage หรือฐานข้อมูล

Gsutil c

P/tmp/ cache_state.json gs:// my-bucket/backups/

#4.ออกจากกระบวนการหลัก

Systemctl stop my-app-service

2.ด้านหน้า Cloud Load Balancing การเชื่อมต่อที่สง่างาม (Connection Draining)

หาก Spot VM ของคุณทำงานอยู่หลัง Cloud Load Balancer(CLB) คุณต้องเปิด

Connection Draining (ถอดการเชื่อมต่อ)

:

กลไกที่มีประสิทธิภาพ: เมื่อโหลดอีควอไลเซอร์รับรู้ว่าโหนดได้รับการกู้คืนหรือการตรวจสอบสุขภาพล้มเหลวมันจะปฏิเสธที่จะจัดสรรการรับส่งข้อมูลใหม่ให้กับ VM ทันทีแต่จะปล่อยเวลาว่างจำนวนหนึ่งสำหรับการเชื่อมต่อ TCP ที่มีอยู่ (เช่นตั้ง15-30วินาที)

พารามิเตอร์การกำหนดค่า: ขอแนะนำให้ตั้งค่าระยะเวลาการวาดเป็น20วินาที (ต้องน้อยกว่าขีดจำกัดการกู้คืน30วินาทีของ GCP) เพื่อหลีกเลี่ยงข้อผิดพลาด502/504ที่เกิดจากคำขอของผู้ใช้ที่ถูกบังคับให้ตัดการจับมือไปครึ่งทาง

3.การกำหนดค่า MIG Health Check กับ Autohealing (การรักษาอัตโนมัติ)

ผูกการตรวจสุขภาพ HTTP/TCP ในกลุ่มอินสแตนซ์ที่มีการจัดการ (MIG) และปรับกลยุทธ์การรักษาอัตโนมัติ (Autohealing) เพื่อตอบสนองได้เร็วที่สุด:

ช่วงเวลาการตรวจจับ (Check Interval): แนะนำให้ตั้งค่าเป็น5วินาที

เกณฑ์ที่ไม่แข็งแรง (Unhealthy Threshold): ตั้งค่าเป็น2ครั้ง

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

4.การแยกข้อมูลและสถานะภายนอก (Statess Design)

หลักการพื้นฐานที่สุดในการป้องกันการตัดกระแสคือ

บรรลุความไร้สัญชาติ

:

อย่าเก็บแคชชั่วคราวของเซสชั่นและการอัปโหลดไฟล์ของผู้ใช้ไว้ในดิสก์ภายในเครื่องของ Spot VM

ย้ายที่เก็บข้อมูลเซสชันไปยัง Cloud Memorystore (Redis) ฐานข้อมูลจะเชื่อมต่อกับ Cloud SQL และไฟล์จะถูกเก็บไว้ใน Cloud Storage ด้วยวิธีนี้แม้ว่า Spot VM จะปิดตัวลงอย่างกะทันหันผู้ใช้จะต้องรีเฟรชหน้าเว็บและเชื่อมต่อกับโหนดอื่นอีกครั้งและสถานะทางธุรกิจจะไม่ได้รับผลกระทบเลย

ประการที่สี่การดำเนินการและการบำรุงรักษาและเคล็ดลับการเพิ่มประสิทธิภาพการชำระบัญชีทรัพยากรบนคลาวด์

เมื่อดำเนินการวางแผนการดำเนินงานและการบำรุงรักษาทรัพยากรคอมพิวเตอร์ GCP นอกเหนือจากการเพิ่มประสิทธิภาพความทนทานต่อความผิดพลาดในการออกแบบสถาปัตยกรรมแล้วเรายังต้องให้ความสนใจกับความต่อเนื่องของบัญชีพื้นฐานและการเรียกเก็บเงิน

องค์กรขนาดเล็กและขนาดกลางหรือทีมพัฒนาจำนวนมากมักพบข้อจำกัดโควต้า (Quota) หรือรายการที่เกิดจากการหักบัตรเครดิตที่ผิดปกติเมื่อขยายคลัสเตอร์และดึงโหนด Spot เป็นกลุ่ม

ความเสี่ยงจากการปิดเครื่องเพื่อให้การทำงานของโครงสร้างพื้นฐานระบบคลาวด์เป็นไปอย่างราบรื่นหลายทีมจะเลือกใช้ช่องทางมืออาชีพ

เติมเงินบัญชี Google Cloud

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

สรุป

การรีไซเคิล GCP Spot VM บ่อยครั้งเป็นคุณลักษณะโดยธรรมชาติที่อยู่เบื้องหลัง "ราคาที่ต่ำเป็นพิเศษ" หากคุณต้องการใช้ประโยชน์จาก "อาวุธลดต้นทุน" นี้ให้เป็นประโยชน์กุญแจสำคัญคือ

เปลี่ยนการรีไซเคิลแบบพาสซีฟเป็นการป้องกันที่ใช้งานอยู่

:

เลเยอร์สถาปัตยกรรม: ใช้ "Spot on Demand" เพื่อผสมกลุ่มโฮสติ้งหรือย้ายไปที่สถาปัตยกรรม GKE

เลเยอร์การจราจร: เปิด Cloud LB Connection Draining กับการทดสอบสุขภาพอย่างรวดเร็ว

เลเยอร์แอปพลิเคชัน: จับสัญญาณสคริปต์ปิดเครื่อง30วินาทีและเปลี่ยนบริการให้เป็นสถาปัตยกรรมไร้สัญชาติโดยสิ้นเชิง

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