ประสิทธิภาพตามขนาด: เรื่องราวของการเพิ่มประสิทธิภาพต้นทุนของ AWS

ฉันเพิ่งเปิดตัวแพลตฟอร์มการวิเคราะห์สกุลเงินดิจิทัล โดยคาดว่าจะมีผู้ใช้รายวันจำนวนไม่มาก อย่างไรก็ตาม เมื่อผู้ใช้ YouTube ยอดนิยมบางคนพบว่าไซต์นี้มีประโยชน์และเผยแพร่บทวิจารณ์ การเข้าชมก็เพิ่มขึ้นอย่างรวดเร็วจนทำให้เซิร์ฟเวอร์ทำงานหนักเกินไป และแพลตฟอร์ม (Scalper.AI) ก็ไม่สามารถเข้าถึงได้ สภาพแวดล้อม AWS EC2 ดั้งเดิมของฉันต้องการการสนับสนุนเพิ่มเติม หลังจากพิจารณาโซลูชันที่หลากหลาย ฉันตัดสินใจใช้ AWS Elastic Beanstalk เพื่อปรับขนาดแอปพลิเคชันของฉัน สิ่งต่างๆ ดูดีและดำเนินไปอย่างราบรื่น แต่ฉันรู้สึกทึ่งกับค่าใช้จ่ายในหน้าแดชบอร์ดการเรียกเก็บเงิน

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

ทำไมฉันถึงเลือก AWS

เป้าหมายของ Scalper.AI คือการรวบรวมข้อมูลเกี่ยวกับคู่สกุลเงินดิจิทัล (สินทรัพย์ที่แลกเปลี่ยนเมื่อทำการซื้อขายในการแลกเปลี่ยน) ดำเนินการวิเคราะห์ทางสถิติ และให้ข้อมูลเชิงลึกเกี่ยวกับสถานะของตลาดแก่ผู้ค้า crypto โครงสร้างทางเทคนิคของแพลตฟอร์มประกอบด้วยสามส่วน:

• สคริปต์การนำเข้าข้อมูล
• เว็บเซิร์ฟเวอร์
• ฐานข้อมูล

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

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

Scalper.AI ทำงานได้อย่างเสถียร และผู้ใช้ของฉันไม่ต้องเสียเวลาหยุดทำงานอีกต่อไป แน่นอน ฉันคาดว่าจะมีการใช้จ่ายเพิ่มขึ้นตั้งแต่ฉันเพิ่มบริการพิเศษ แต่ตัวเลขนั้นมากกว่าที่ฉันคาดไว้มาก

ฉันจะลดต้นทุนระบบคลาวด์ได้อย่างไร

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

อินสแตนซ์ประสิทธิภาพที่ขยายได้

ความท้าทายแรกของฉันคือการสนับสนุนการใช้พลังงานของ CPU สำหรับโครงการที่กำลังเติบโตของฉัน สคริปต์การนำเข้าข้อมูลของ Scalper.AI ให้ผู้ใช้วิเคราะห์ข้อมูลแบบเรียลไทม์ สคริปต์ทำงานทุก ๆ สองสามวินาทีและป้อนแพลตฟอร์มด้วยการอัปเดตล่าสุดจากการแลกเปลี่ยน crypto การทำซ้ำของกระบวนการนี้แต่ละครั้งจะสร้างงานแบบอะซิงโครนัสหลายร้อยงาน ดังนั้นการรับส่งข้อมูลที่เพิ่มขึ้นของไซต์จึงจำเป็นต้องใช้พลังงาน CPU มากขึ้นเพื่อลดเวลาในการประมวลผล

อินสแตนซ์ที่ถูกที่สุดที่ AWS เสนอพร้อม vCPU สี่ตัว a1.xlarge จะมีค่าใช้จ่ายประมาณ 75 ดอลลาร์สหรัฐฯ ต่อเดือนในขณะนั้น แต่ฉันตัดสินใจกระจายโหลดระหว่างอินสแตนซ์ t3.micro สองอินสแตนซ์ที่มี vCPU สองตัวและ RAM 1GB ต่อตัว อินสแตนซ์ t3.micro ให้ความเร็วและหน่วยความจำเพียงพอสำหรับงานที่ฉันต้องการด้วยค่าใช้จ่ายเพียงหนึ่งในห้าของ a1.xlarge อย่างไรก็ตาม บิลของฉันยังคงมากกว่าที่คาดไว้เมื่อสิ้นเดือน

ด้วยความพยายามที่จะเข้าใจเหตุผล ฉันค้นหาเอกสารของ Amazon และพบคำตอบ: เมื่อการใช้งาน CPU ของอินสแตนซ์ต่ำกว่าเส้นพื้นฐานที่กำหนดไว้ อินสแตนซ์จะรวบรวมเครดิต แต่เมื่ออินสแตนซ์มีมากกว่าการใช้งานพื้นฐาน มันจะใช้เครดิตที่ได้รับก่อนหน้านี้ หากไม่มีเครดิต อินสแตนซ์จะใช้ "เครดิตส่วนเกิน" ที่ Amazon จัดหาให้ ความสามารถในการรับและใช้เครดิตทำให้ Amazon EC2 เฉลี่ยการใช้งาน CPU ของอินสแตนซ์ตลอด 24 ชั่วโมง หากการใช้งานโดยเฉลี่ยสูงกว่าค่าพื้นฐาน อินสแตนซ์จะถูกเรียกเก็บเงินพิเศษในอัตราคงที่ต่อ vCPU ต่อชั่วโมง

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

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

การถ่ายโอนข้อมูลขาออก

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

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

ค่าใช้จ่ายในการถ่ายโอนข้อมูลคิดเป็น 30% ของราคา AWS ที่เพิ่มขึ้น การโอนขาเข้า EC2 นั้นฟรี แต่จะมีการเรียกเก็บค่าธรรมเนียมการโอนขาออกต่อ GB (0.09 USD ต่อ GB เมื่อฉันสร้าง Scalper.AI) เมื่อฉันได้เรียนรู้วิธีที่ยาก สิ่งสำคัญคือต้องระมัดระวังโค้ดที่ส่งผลต่อข้อมูลขาออก การลดการดาวน์โหลดหรือการโหลดไฟล์หากทำได้ (หรือตรวจสอบพื้นที่เหล่านี้อย่างระมัดระวัง) จะปกป้องคุณจากค่าธรรมเนียมที่สูงขึ้น เพนนีเหล่านี้เพิ่มขึ้นอย่างรวดเร็ว เนื่องจากค่าบริการสำหรับการถ่ายโอนข้อมูลจาก EC2 ไปยังอินเทอร์เน็ตขึ้นอยู่กับปริมาณงานและอัตราเฉพาะภูมิภาคของ AWS ข้อแม้สุดท้ายที่ลูกค้า AWS ใหม่หลายคนไม่ทราบ: การถ่ายโอนข้อมูลระหว่างสถานที่ต่างๆ จะมีราคาแพงกว่า อย่างไรก็ตาม การใช้ที่อยู่ IP ส่วนตัวสามารถป้องกันค่าใช้จ่ายในการถ่ายโอนข้อมูลเพิ่มเติมระหว่างโซนความพร้อมใช้งานที่แตกต่างกันในภูมิภาคเดียวกัน

ที่อยู่ IP แบบยืดหยุ่น

แม้ในขณะที่ใช้ที่อยู่สาธารณะ เช่น ที่อยู่ Elastic IP (EIP) ก็สามารถลดค่าใช้จ่าย EC2 ของคุณได้ EIP คือที่อยู่ IPv4 แบบคงที่ที่ใช้สำหรับการประมวลผลบนคลาวด์แบบไดนามิก ส่วน "ยืดหยุ่น" หมายความว่าคุณสามารถกำหนด EIP ให้กับอินสแตนซ์ EC2 ใดก็ได้ และใช้จนกว่าคุณจะเลือกที่จะหยุด ที่อยู่เหล่านี้ช่วยให้คุณสามารถสลับอินสแตนซ์ที่ไม่มีประสิทธิภาพกับอินสแตนซ์ที่มีประสิทธิภาพได้อย่างลงตัวโดยทำการแมปที่อยู่ใหม่เป็นอินสแตนซ์อื่นในบัญชีของคุณ คุณยังสามารถใช้ EIP เพื่อระบุระเบียน DNS สำหรับโดเมนเพื่อให้ชี้ไปที่อินสแตนซ์ EC2

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

ยุติและหยุดสถานะ

AWS มีตัวเลือกสองทางในการจัดการสถานะของอินสแตนซ์ EC2 ที่รันอยู่: ยุติหรือหยุด การยกเลิกจะเป็นการปิดอินสแตนซ์ และเครื่องเสมือนที่จัดเตรียมไว้จะไม่สามารถใช้งานได้อีกต่อไป วอลลุม Elastic Block Store (EBS) ที่แนบไว้จะถูกถอดและลบ และข้อมูลทั้งหมดที่จัดเก็บไว้ในอินสแตนซ์จะสูญหาย คุณจะไม่ถูกเรียกเก็บเงินสำหรับอินสแตนซ์อีกต่อไป

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

แต่มีคุณสมบัติที่สามารถขยายใบเรียกเก็บเงิน AWS ของคุณได้เมื่อถึงสิ้นเดือน แม้ว่าคุณจะยุติอินสแตนซ์แทนที่จะหยุด นั่นคือ สแนปชอต EBS สิ่งเหล่านี้คือการสำรองข้อมูลส่วนเพิ่มของโวลุ่ม EBS ของคุณที่จัดเก็บไว้ใน Simple Storage Service (S3) ของ Amazon แต่ละสแน็ปช็อตเก็บข้อมูลที่คุณต้องการเพื่อสร้างโวลุ่ม EBS ใหม่ด้วยข้อมูลก่อนหน้าของคุณ หากคุณยุติอินสแตนซ์ โวลุ่ม EBS ที่เกี่ยวข้องจะถูกลบออกโดยอัตโนมัติ แต่สแนปชอตของอินสแตนซ์จะยังคงอยู่ เนื่องจาก S3 คิดค่าบริการตามปริมาณข้อมูลที่จัดเก็บ เราขอแนะนำให้คุณลบสแนปชอตเหล่านี้หากคุณไม่ใช้งานในเร็วๆ นี้ AWS มีคุณสมบัติในการตรวจสอบกิจกรรมการจัดเก็บต่อวอลุ่มโดยใช้บริการ CloudWatch:

1. ขณะลงชื่อเข้าใช้คอนโซล AWS จากเมนู บริการ ด้านบนซ้าย ให้ค้นหาและเปิดบริการ CloudWatch
2. ที่ด้านซ้ายของหน้า ภายใต้เมนู Metrics collapsible ให้คลิก All Metrics
3. หน้านี้จะแสดงรายการบริการที่มีเมตริก เช่น EBS, EC2, S3 และอื่นๆ คลิก EBS จากนั้นคลิก Per-volume Metrics (หมายเหตุ: ตัวเลือก EBS จะมองเห็นได้ก็ต่อเมื่อคุณกำหนดค่าวอลุ่ม EBS ในบัญชีของคุณเท่านั้น)
4. คลิกที่แท็บ แบบสอบถาม ในมุมมอง Editor ให้คัดลอกและวางคำสั่ง SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId จากนั้นคลิก Run (หมายเหตุ: CloudWatch ใช้ภาษาถิ่นของ SQL ที่มีรูปแบบเฉพาะ)

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

เงินพิเศษในกระเป๋าของคุณ

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

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

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