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

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

การตั้งค่าการกำหนดค่า

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

เพื่อให้ทุกอย่างง่ายขึ้น ให้เราเปรียบเทียบบริการที่มีข้อกำหนดสำหรับการมี vCPU 1 ตัวและหน่วยความจำประมาณ 2 GB เท่านั้น สำหรับ Lambda vCPU จะปรับขนาดร่วมกับขนาดหน่วยความจำที่กำหนดค่าได้ Lambda ได้รับ1 vCPU ต่อหน่วยความจำ 1.769 GBดังนั้นนี่จะเป็นตัวเลือกของเราสำหรับ Lambda Fargate สามารถกำหนดค่าได้ทั้งจำนวน vCPU และขนาดหน่วยความจำ ดังนั้นเราจึงสามารถเลือก 1 vCPU และหน่วยความจำ 2 GB ที่จะใช้งานได้ สำหรับ EC2 สำหรับค่า vCPU และหน่วยความจำที่ต่ำ เช่นนี้ในประเภทอินสแตนซ์ EC2 รุ่นปัจจุบันทางเลือกเดียวของเราคือเลือกใช้ตระกูล T ที่มีประสิทธิภาพการ ทำงานแบบขยายได้. สิ่งนี้นำมาซึ่งความซับซ้อนอีกระดับ เนื่องจากอินสแตนซ์มีราคาตามการใช้งานที่ต่ำกว่าหรือเท่ากับประสิทธิภาพของ CPU พื้นฐาน และค่าใช้จ่ายเพิ่มเติมเกิดขึ้นเมื่อปริมาณการใช้เกินเกณฑ์พื้นฐาน อย่างไรก็ตาม ใน ประเภทอินสแตนซ์ รุ่นก่อนหน้าประเภทอินสแตนซ์ m1.small เหมาะกับความต้องการค่อนข้างดีด้วย 1 vCPU และหน่วยความจำ 1.7 GB ดังนั้นเราจะใช้อินสแตนซ์ประเภทนี้แทนประเภทอินสแตนซ์ตระกูล T นอกจากนี้ ตัวเลือกต่อไปนี้ไม่ได้รับการพิจารณาเปรียบเทียบเพื่อความง่าย:

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

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

การกำหนดราคา EC2 นั้นต่ำที่สุด ตามมาด้วย Fargate ในขณะที่ราคาของ Lambda นั้นสูงกว่า Fargate สองเท่า ราคา EC2 สามารถลดลงได้อีกโดยใช้ประเภทอินสแตนซ์แบบขยายได้ในตระกูล T ทั้งนี้ขึ้นอยู่กับความต้องการที่แท้จริงของปริมาณงานของคุณ

ปัจจัยการเรียกเก็บเงินและการเริ่มต้น

ดังที่เราเห็นข้างต้น ค่าใช้จ่ายในการรัน Lambda ค่อนข้างสูงเมื่อเทียบกับ Fargate และ EC2 ให้เราตรวจสอบปัจจัยที่อาจส่งผลต่อสาเหตุที่เรายังคงเลือก Lambda สำหรับการประมวลผลได้แม้ว่าราคาจะสูงกว่าก็ตาม

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

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

ประการที่สอง การหมุนอินสแตนซ์ EC2 ใหม่ใช้เวลาประมาณหนึ่งนาทีหรือมากกว่านั้น ซึ่งคล้ายกับการเริ่มต้นงาน Fargate ใหม่ เมื่อเปรียบเทียบกันแล้ว การสร้างอินสแตนซ์ Lambda ใหม่มักใช้เวลาไม่กี่ร้อยมิลลิวินาทีสำหรับรันไทม์ด้วยภาษาที่แปล และใช้เวลาไม่กี่วินาทีสำหรับรันไทม์ด้วยภาษาที่คอมไพล์

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

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

ทั้งอินสแตนซ์ EC2 และงาน Fargate จำเป็นต้องใช้ 100 % ของเวลาเพื่อไม่ให้ประสบปัญหาในการเริ่มต้น ในทางกลับกัน การเรียกเก็บเงินของแลมบ์ดาขึ้นอยู่กับเวลาจริงที่โค้ดตัวจัดการของคุณทำงานเพื่อให้บริการทราฟฟิกไปยัง API ของเว็บ ดังนั้น การใช้แลมบ์ดาจึงเป็นที่นิยมมากกว่าจนกว่าจะใช้แลมบ์ดาประมาณ 40 ถึง 50 % ของเวลา แม้ว่าราคาจะสูงกว่าสำหรับพลังการประมวลผลเท่าเดิมก็ตาม สิ่งนี้ทำให้ Lambda เหมาะสำหรับงานประมวลผลที่รวดเร็ว ตัวอย่างเช่น งาน IO เช่น การอ่านข้อมูลจาก DynamoDB เป็นต้น

ตัวอย่างโลกแห่งความเป็นจริง

เราใช้ฟังก์ชัน Lambda กับหนึ่งในโปรเจ็กต์ของเราเพื่อจัดการคำขอ API มีการกำหนดค่าหน่วยความจำ 2 GB เพื่อลดความล่าช้าในการเริ่มเย็นเป็นหลัก มิฉะนั้น อาจมีการกำหนดค่าที่ต่ำกว่า มันใช้ไลบรารี่ .NET ที่มีมากกว่า 4 MB ดังนั้นความแตกต่างระหว่างการเริ่มเย็นระหว่างเช่น 512 MB ของหน่วยความจำและ 2 GB จะสังเกตได้

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

ตามเมตริกการใช้งานรายวัน ฟังก์ชันถูกเรียกใช้โดยเฉลี่ยประมาณ 250,000 ครั้งต่อวัน ซึ่งคิดเป็น 2.89 คำขอต่อวินาที ระยะเวลาการดำเนินการโดยเฉลี่ยอยู่ที่ประมาณ 250 มิลลิวินาที 2.89 คูณ 250 เท่ากับ 723 โดยประมาณ หมายความว่าฟังก์ชันนี้ถูกใช้ไปประมาณ 70 % ของเวลาทั้งหมด

เมตริกช่วงเวลา 1 นาทีที่ละเอียดยิ่งขึ้นแสดงว่ารูปแบบการเรียกใช้นั้นไม่ชัดเจน อย่างไรก็ตาม โดยทั่วไปแล้ว โหลดจะถูกจัดการโดยอินสแตนซ์ของฟังก์ชันที่เกิดขึ้นพร้อมกันน้อยกว่า 10 อินสแตนซ์เล็กน้อย

เมตริกที่รวบรวมได้ส่งสัญญาณว่าเราผ่านเกณฑ์ที่การเรียกเก็บเงินของ Lambda เหมาะสมที่สุดแล้ว เป็นไปได้ ในการจัดการทราฟฟิกด้วยพลังการประมวลผลเท่าเดิมและมีพื้นที่ให้เติบโต เราสามารถใช้งาน Fargate แบบหลาย AZ ได้ 2 งาน โดยแต่ละงานมี 0.5 vCPU และหน่วยความจำ 1 GB จากกราฟด้านบน ค่านี้จะลดค่าใช้จ่ายการเรียกเก็บเงินรายเดือนจาก $53.50 เป็น $36.04 เราสามารถพยายามลดต้นทุนให้ต่ำลงได้โดยใช้อินสแตนซ์ EC2 ที่สามารถขยายได้ขนาดที่เหมาะสมและโฮสต์คอนเทนเนอร์หรือแอปที่นั่น แน่นอนว่านี่เป็นเพียงแนวคิดทางทฤษฎีคร่าวๆ ที่ต้องมีการตรวจสอบในแอปพลิเคชันจริง

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

เราคือACTUM Digitalและงานชิ้นนี้เขียนโดยMilan Gatyasหัวหน้าฝ่ายเทคโนโลยี .NET ของ Apollo Division อย่าลังเลที่จะติดต่อ