VPN บน EC2 แบบ Burstable: เครดิต CPU แบบ Standard หรือ Unlimited?

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

การทดสอบความเร็วยืมมาจากไหน

หนึ่งเครดิต CPU คือหนึ่ง vCPU ที่ทำงานเต็มอัตราเป็นเวลาหนึ่งนาที อินสแตนซ์แบบ Burstable หาเครดิตด้วยอัตราเส้นฐานของตนและใช้เครดิตเมื่อเกินเส้นฐานนั้น คืนที่ว่างงานสร้างยอดคงเหลือ เช้าที่วุ่นวายดึงมันออกไป

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

คณิตศาสตร์ที่คุณต้องทำ

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

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

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

สังเกตการอ่านครั้งที่สองด้วย ในตัวอย่างนี้ vCPU ที่ทำงานหนึ่งตัวคือประมาณครึ่งหนึ่งของความจุ CPU ทั้งหมด เปอร์เซ็นต์รวมปานกลางอาจซ่อนคอร์ที่อิ่มตัว ดังนั้นมองพฤติกรรมรายคอร์ควบคู่กับตัวเลขเครดิต

Standard และ Unlimited: ศูนย์เดียวกัน ความหมายต่างกัน

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

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

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

สิ่งที่ต้องเฝ้าดูระหว่างงานจริง

บันทึก CPUCreditUsage และ CPUCreditBalance ควบคู่กับระยะเวลาและอัตราของการถ่ายโอน ใน Unlimited ให้เพิ่ม CPUSurplusCreditBalance และ CPUSurplusCreditsCharged คู่มือการตรวจสอบเครดิต CPU ของ AWS อธิบายว่าแต่ละตัวรายงานอะไรและบ่อยเพียงใด

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

ข้อจำกัดที่ไม่ใช่ CPU

แบนด์วิดท์เครือข่ายมีเส้นฐานและพฤติกรรมการระเบิดของตัวเอง และขีดจำกัดอัตราแพ็กเก็ตหรือจำนวนการเชื่อมต่ออาจตึงก่อน CPU หน่วยความจำสำคัญเมื่อการใช้งาน VPN เก็บสถานะต่อการเชื่อมต่อ และอินสแตนซ์เล็กอาจหมดหน่วยความจำก่อนหมดเครดิตมาก

ยอดเครดิตที่ดีจึงพิสูจน์สิ่งหนึ่ง งบประมาณ CPU ไม่ใช่ข้อจำกัดในปัจจุบัน มันไม่ได้บอกอะไรเกี่ยวกับเส้นทางเครือข่าย และไม่ได้บอกอะไรเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อการทำงานพร้อมกันเพิ่มเป็นสองเท่า เฝ้าดูเมตริกเครือข่ายในหน้าต่างเดียวกับเมตริกเครดิต เพื่อให้ throughput ที่ลดลงมีสาเหตุที่เป็นไปได้แทนที่จะเป็นทฤษฎี

การเลือกเส้นฐานอย่างตั้งใจ

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

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