ข้อดีข้อเสียของ Prime Video เปลี่ยนไปใช้สถาปัตยกรรมเสาหิน: คุ้มกับความเสี่ยงหรือไม่?

ลดต้นทุนหรือเสียสละความยืดหยุ่น?

เมื่อเร็วๆ นี้ Amazon Prime Video ได้เปลี่ยนบริการตรวจสอบวิดีโอสดจากไมโครเซอร์วิสเป็นโมโนลิธ ทำให้ต้นทุนลดลง 90%

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

คำศัพท์ที่ใช้กันทั่วไป:

VMS (บริการตรวจสอบวิดีโอ) : เครื่องมือนี้ช่วยให้ amazon ระบุปัญหาคุณภาพการรับรู้โดยอัตโนมัติ (เช่น บล็อกความเสียหายหรือปัญหาการซิงค์เสียง/วิดีโอ) และทริกเกอร์กระบวนการเพื่อแก้ไขปัญหาเหล่านั้น

MCS (บริการตัวแปลงสื่อ) : สิ่งนี้จะแปลงสตรีมเสียง / วิดีโออินพุตเป็นเฟรมหรือบัฟเฟอร์เสียงที่ถอดรหัสที่ส่งไปยังตัวตรวจจับ

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

สถาปัตยกรรมแบบกระจายเซิร์ฟเวอร์น้อยเริ่มต้น

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

มาแยกย่อยทีละขั้นตอนเพื่อความเข้าใจที่ดีขึ้น (fyi: มีการพิจารณาสมมติฐานบางอย่างเนื่องจากขาดข้อมูล/ความชัดเจนในบทความต้นฉบับ)

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

• เมื่อการแปลงเสร็จสิ้น MCS จะจัดเก็บสตรีมเสียง/วิดีโอในบัคเก็ต s3 และเรียกใช้บริการตัวตรวจจับข้อบกพร่องซึ่งทำงานแบบขนานและผลลัพธ์รวมจะถูกจัดเก็บอีกครั้งในบัคเก็ต S3 และยังส่งไปยังหัวข้อ SNS เพื่อให้ผู้บริโภคเป้าหมายดำเนินการตามนั้น
• ระบบทั้งหมดสร้างขึ้นโดยใช้สถาปัตยกรรมแบบไม่ใช้เซิร์ฟเวอร์ (AWS Step Functions และ Lambda) และสถาปัตยกรรมไมโครเซอร์วิส (MCS และตัวตรวจจับข้อบกพร่อง) ซึ่งค่าใช้จ่ายหลักมาจากเวิร์กโฟลว์การประสานและการถ่ายโอนข้อมูลระหว่างส่วนประกอบแบบกระจาย ไม่ต้องพูดถึง มีปัญหาคอขวดในการปรับขนาดสำหรับสตรีมแบบสดที่กำลังมาแรงด้วยการออกแบบปัจจุบัน

สถาปัตยกรรมเสาหิน

ในสถาปัตยกรรมที่อัปเดต ส่วนประกอบส่วนใหญ่ยังคงเหมือนเดิม (MCS, Detectors, Orchestrator) การเปลี่ยนแปลงที่สำคัญเพียงอย่างเดียวคือส่วนประกอบได้รับการรวมเข้าไว้ในอินสแตนซ์ ECS เดียว แต่สิ่งนี้หมายความว่าอย่างไร และมีผลกระทบต่อระบบอย่างไร? มาทำลายมันกันเถอะ

• Orchestration ซึ่งก่อนหน้านี้มีราคาแพงและใช้ AWS step functions และ Lambda ได้ถูกแทนที่ด้วยเลเยอร์ orchestration ใหม่ ซึ่งช่วยให้สามารถควบคุมส่วนประกอบได้ดีขึ้นภายในอินสแตนซ์เดียว ทำให้ประหยัดต้นทุนได้อย่างมาก
• ตัวแปลงสื่อ (MCS) ก่อนหน้านี้ทำงานเป็นไมโครเซอร์วิส แต่ตอนนี้ถูกย้ายไปยังอินสแตนซ์ ECS เดียว การเปลี่ยนแปลงนี้ช่วยให้สามารถแปลงและจัดเก็บข้อมูลในฮีปที่ใช้งานอยู่ ส่งผลให้การประมวลผลเร็วขึ้นและปรับปรุงประสิทธิภาพ
• สุดท้าย ตัวตรวจจับซึ่งใช้โมเดล ML เพื่อตรวจจับข้อบกพร่องในการสตรีมเสียง/วิดีโอ ได้ถูกย้ายไปยังอินสแตนซ์ ECS เดียว แม้ว่านี่หมายถึงการสูญเสียความสามารถในการปรับขนาดแนวนอน แต่การประหยัดต้นทุนทำให้การแลกเปลี่ยนที่คุ้มค่า อย่างไรก็ตาม เป็นที่น่าสังเกตว่าเครื่องตรวจจับอาจแตกหักได้เมื่อมีโหลดสูง ดังนั้นจึงยังมีความท้าทายบางประการที่ต้องเอาชนะ

• ข้อดี: การลดต้นทุนเนื่องจากการเรียกใช้ S3 Bucket อ่านเขียน Tier-1 เพิ่มเติมนั้นไม่จำเป็นอีกต่อไป เช่นเดียวกับฟังก์ชัน AWS Step และการดำเนินการที่มีค่าใช้จ่ายสูงของ Lambda สำหรับ Orchestration ได้ถูกแทนที่ด้วยส่วนประกอบแต่ละรายการ
• ข้อเสีย: สูญเสียความสามารถในการปรับขนาดในแนวนอน (เช่น ตัวตรวจจับที่ทำงานในอินสแตนซ์ ECS เดียวด้วย) สูญเสียความยืดหยุ่น เนื่องจากในอนาคตอาจมีผู้บริโภคหลายรายสำหรับสตรีมเสียง/วิดีโอ ซึ่งปัจจุบันเชื่อมต่ออย่างแน่นหนากับเครื่องตรวจจับ

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

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

ในโลกของการพัฒนาซอฟต์แวร์ ไม่มีโซลูชันใดที่เหมาะกับทุกขนาดหรือการออกแบบที่เหนือกว่าระหว่างบริการขนาดเล็กและสถาปัตยกรรมแบบเสาหิน ในกรณีของ Prime Video ที่เปลี่ยนไปใช้การออกแบบเสาหิน ส่งผลให้ต้นทุนลดลงอย่างมากถึง 90% และเข้ากันได้ดีกับกรณีการใช้งาน

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

อ้างอิง

• บล็อกวิดีโอชั้นนำของ Amazon ( ขยายขนาดบริการตรวจสอบเสียง/วิดีโอ Prime Video และลดค่าใช้จ่ายลง 90% — Prime Video Tech )

• นับยอดผู้ชมสตรีมสดแบบ Real Time ที่ High Scale !! | โดย Aashirwad Kashyap | สรุป ()
• ปรับใช้แอปพลิเคชัน Node.js บน Google Cloud ด้วย CI/CD | โดย Aashirwad Kashyap | บิตและชิ้น ()
• สร้างท่อส่งข้อมูลที่ยืดหยุ่นพร้อมเจาะลึกสถาปัตยกรรม AirFlow | โดย Aashirwad Kashyap | วัฒนธรรมเกินบรรยาย | ปานกลาง

ขอบคุณที่เป็นส่วนหนึ่งของชุมชนของเรา! ก่อนที่คุณจะไป:

• ปรบมือให้กับเรื่องราวและติดตามผู้เขียน
• ดูเนื้อหาเพิ่มเติมในสิ่งพิมพ์ Level Up Coding
• หลักสูตรสัมภาษณ์การเข้ารหัสฟรี ⇒ ดูหลักสูตร
• ติดตามเรา: Twitter | LinkedIn | จดหมายข่าว