แนวทางแบบไร้เซิร์ฟเวอร์เพื่อการพัฒนาบริการวิดีโอที่ใช้งานได้อย่างรวดเร็ว

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

ได้รับ: บัญชีรูทบน AWS ไม่มีข้อจำกัดในการเลือกสแต็กเทคโนโลยี หนึ่งแบ็กเอนด์ และหนึ่งเดือนสำหรับการพัฒนา

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

การตัดสิน

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

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

ข้อความที่ซ่อนอยู่ไม่ มันจะไม่ทำงาน
.
แม้ว่า FFmpeg จะทำให้งานง่ายขึ้น แต่สำหรับโซลูชันที่ใช้งานได้จริง คุณต้องสร้าง EC2 instance และออกแบบโครงสร้างพื้นฐานเครือข่ายสำหรับอินสแตนซ์นั้น รวมถึง Load Balancer ด้วย งานง่ายๆ ในการปรับใช้ตั้งแต่เริ่มต้นจะซับซ้อนขึ้น "เล็กน้อย" และโครงสร้างพื้นฐานเริ่มเรียกร้องเงินทันที - ทุก ๆ ชั่วโมงจำนวนเงินสำหรับรันไทม์จะถูกถอนออกจากบัญชีลูกค้า

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

อย่างไรก็ตาม แม้ว่านักพัฒนา AWS สำหรับ .NET จะไม่ชอบอย่างเห็นได้ชัด แต่พวกเขาก็สนับสนุน .NET Core 2.1 เป็นรันไทม์ ซึ่งให้โอกาสในการพัฒนาอย่างเต็มรูปแบบ

และเชอร์รี่บนเค้ก - AWS มีบริการแยกต่างหากสำหรับการทำงานกับไฟล์วิดีโอ - AWS Elemental MediaConvert

สาระสำคัญของงานนั้นเรียบง่ายอย่างเหลือเชื่อ: เราใช้ลิงก์ S3 ไปยังวิดีโอขาออก เขียนผ่าน AWS Console, .NET SDK หรือเพียงแค่ JSON ว่าเราต้องการทำอะไรกับวิดีโอแล้วเรียกใช้บริการ โดยตัวมันเองจะใช้คิวสำหรับการประมวลผลคำขอที่เข้ามา อัปโหลดผลลัพธ์ไปยัง S3 เอง และที่สำคัญที่สุดคือสร้างเหตุการณ์ CloudWatch สำหรับการเปลี่ยนแปลงสถานะแต่ละครั้ง ซึ่งช่วยให้เราใช้ทริกเกอร์แลมบ์ดาเพื่อประมวลผลวิดีโอให้เสร็จสมบูรณ์ได้

นี่คือลักษณะของสถาปัตยกรรมขั้นสุดท้าย:

แบ็กเอนด์ทั้งหมดอยู่ในแลมบ์ดาสองตัว อีกวิธีหนึ่งคือการหมุนวิดีโอแนวตั้ง เนื่องจากงานดังกล่าวไม่สามารถทำได้ในรอบเดียว

เราจะวางส่วนหน้าในรูปแบบของแอปพลิเคชัน SPA ที่เขียนด้วย JS และคอมไพล์ผ่าน pug ในบัคเก็ต S3 สาธารณะ หากต้องการดาวน์โหลดวิดีโอด้วยตนเอง เราไม่จำเป็นต้องมีรหัสเซิร์ฟเวอร์ เราเพียงแค่ต้องเปิดตำแหน่งข้อมูล REST ที่ S3 มอบให้เรา สิ่งเดียวคืออย่าลืมกำหนดค่านโยบายและ CORS

ข้อผิดพลาด

• AWS MediaConvert ใช้เสียงกับแต่ละส่วนของวิดีโอแยกกันด้วยเหตุผลบางประการที่ไม่ทราบสาเหตุ แต่เราต้องการเพลงที่ร่าเริงจากสกรีนเซฟเวอร์ทั้งหมด
• วิดีโอแนวตั้งจะต้องได้รับการประมวลผลแยกกัน AWS ไม่ชอบแถบสีดำและวางลูกกลิ้งไว้ที่ 90°

ลานสเก็ตง่าย

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

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

เบ็ดเสร็จ

Serverless ไม่ใช่ยาครอบจักรวาล แต่มันจะทำให้ชีวิตง่ายขึ้นมากในสถานการณ์ที่มีขีดจำกัดสามประการ: “ทรัพยากรมีจำกัด—ระยะสั้น—เงินน้อย”

ลักษณะของแอปพลิเคชันที่เหมาะสำหรับ Serverless

• โดยไม่มีกระบวนการทำงานระยะยาว ขีดจำกัดฮาร์ด API ของเกตเวย์คือ 29 วินาที ขีดจำกัดฮาร์ดแลมบ์ดาคือ 5 นาที
• อธิบายโดยสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์
• แบ่งออกเป็นส่วนประกอบที่เชื่อมต่อกันอย่างหลวมๆ เช่น SOA;
• ไม่ต้องการงานมากกับสภาพของคุณ
• เขียนด้วย .NET Core หากต้องการทำงานกับ .NET Framework คุณจะต้องมี Docker เป็นอย่างน้อยและมีรันไทม์ที่เหมาะสม

ประโยชน์ของแนวทางแบบไร้เซิร์ฟเวอร์

• ลดต้นทุนโครงสร้างพื้นฐาน
• ลดต้นทุนในการส่งมอบโซลูชัน
• ความสามารถในการปรับขนาดอัตโนมัติ
• การพัฒนาที่ล้ำหน้าของความก้าวหน้าทางเทคโนโลยี

ข้อเสียพร้อมตัวอย่างเฉพาะ

• การติดตามและการบันทึกแบบกระจาย - แก้ไขบางส่วนผ่าน AWS X-Ray และ AWS CloudWatch
• การดีบักที่ไม่สะดวก
• Cold Start เมื่อไม่มีโหลด
• ส่วนต่อประสานผู้ใช้ที่ไม่เป็นมิตรของ AWS เป็นปัญหาสากล :)

ที่มา: will.com