บล็อกนี้กล่าวถึงการออกแบบระบบระดับสูงของ Amazon Prime Video ที่มีฟังก์ชันจำกัดตามรายการด้านล่าง บล็อกนี้กล่าวถึงการตัดสินใจเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ นี่คือการทำซ้ำ -1 ของการออกแบบและการทำซ้ำเพิ่มเติมจะถูกเพิ่มในอนาคต

คำชี้แจงปัญหา :

ออกแบบระบบระดับสูงสำหรับวิดีโอ Amazon Prime กรณีการใช้งานสตรีมมิงแบบสดอยู่นอกขอบเขต และมีเพียงวิดีโอที่จัดเก็บ/เสร็จสมบูรณ์เท่านั้นที่อยู่ในขอบเขต

ความต้องการการทำงาน:

1. อัปโหลดวิดีโอ
2. ค้นหาวิดีโอ
3. ดูวิดีโอ

1. ไม่มี / แพลตฟอร์มบัฟเฟอร์น้อยที่สุด
2. ความพร้อมใช้งานสูงและความสม่ำเสมอในที่สุด
3. แอปพลิเคชั่นที่มีความหน่วงต่ำ
4. ความน่าเชื่อถือ: วิดีโอที่อัปโหลดไม่ควรสูญหาย

สมมติฐาน:

1. มีการกล่าวถึงผู้ใช้/นักแสดงเพียง 2 ประเภทเท่านั้น: ผู้สร้างเนื้อหาและผู้ดู
2. Amazon Prime Video เป็นระบบที่เน้นการอ่าน
3. ผู้ใช้งาน 50 ล้านคนและผู้สร้างเนื้อหาจำนวนจำกัดในช่วง 1K

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

การตัดสินใจออกแบบและการแลกเปลี่ยน:

1. ความพร้อมใช้งานสูงกว่าความสอดคล้อง : ระบบจะส่งคืนและเล่นวิดีโอเสมอ แม้ว่าจะไม่ใช่วิดีโอเวอร์ชันล่าสุดก็ตาม สำหรับแพลตฟอร์มเช่น Prime Video เราสามารถเลือกความสอดคล้องในท้ายที่สุดเหนือความพร้อมใช้งาน ตามทฤษฎีบทของ CAP เราไม่สามารถประนีประนอมกับ 'P' เช่น ความทนทานต่อพาร์ติชัน / พาร์ติชันเครือข่าย และเราจะเลือก 'A' มากกว่า 'C' เนื่องจาก : A) หากวิดีโอถูกอัปโหลดในเวลา 14:05 น. แทนที่จะเป็น 2:00 น. PM ผู้ใช้น่าจะโอเคกับสิ่งนี้ B) หากวิดีโอมีการบัฟเฟอร์หรือแล็กเนื่องจากความพร้อมใช้งานต่ำ จะทำให้ลูกค้าได้รับประสบการณ์ที่ไม่ดี
2. เลือกที่เก็บอ็อบเจ็กต์ (S3) สำหรับกรณีการใช้งานนี้ เนื่องจากไฟล์วิดีโอเป็นไฟล์แฟลตขนาดใหญ่ (GB) ไฟล์ที่เข้ารหัสจริงจะถูกบันทึกไว้ที่นี่
3. MetadataDB สามารถเป็น Relational DB เป็นข้อมูลเมตาของวิดีโอ เช่น Title, VideoLanguages, Size, VideoTime เป็นต้น โดยเป็นข้อมูลที่มีโครงสร้างทั้งหมด เราไม่ต้องการสคีมาที่ยืดหยุ่นสำหรับข้อมูลนี้
4. จำเป็นต้องมีคลัสเตอร์ ElasticSearch เนื่องจากฟังก์ชันการค้นหาเป็นข้อความแบบเต็มหรือการค้นหาในรูปแบบอิสระ เวอร์ชันเริ่มต้นของระบบสามารถสร้างได้โดยใช้ metadata DB แต่จะมีข้อจำกัดเสมอสำหรับดัชนีรองในฐานข้อมูล ดังนั้นเราจะต้องค้นหาแบบยืดหยุ่นในที่สุด
5. มีการดูวิดีโอบนอุปกรณ์ต่างๆ เช่น โทรศัพท์มือถือ พีซี และทีวี ดังนั้นเราจึงต้องการการเข้ารหัสวิดีโอที่แตกต่างกัน
6. วิดีโอจะถูกทำซ้ำและเผยแพร่ตามพื้นที่ทางภูมิศาสตร์เพื่อความน่าเชื่อถือ
7. VideoSplitter จำเป็นสำหรับการแยกไฟล์วิดีโอขนาดใหญ่ออกเป็นชิ้นเล็ก ๆ ซึ่งสามารถประมวลผลด้วยวิธีการลดแผนที่โดยส่วนประกอบภายในในลักษณะที่กำหนดได้
8. เราได้ใช้คิวการส่งผ่านข้อมูลระหว่างคอมโพเนนต์ เนื่องจากการประมวลผลนี้ควรทำแบบอะซิงโครนัส เราสามารถใช้บางอย่างเช่น Kafka หรือ AWS Kinesis ที่นี่สำหรับคิวการส่งผ่านข้อมูล
9. เราต้องการเครือข่ายการจัดส่งเนื้อหาสำหรับการเล่นวิดีโอที่มีความหน่วงแฝงต่ำ มันจะถูกผลักจากระบบไปยัง CDN วิดีโอยอดนิยมจะถูกส่งไปที่ CDN ในชั่วโมงที่ไม่ใช่ชั่วโมงเร่งด่วนเพื่อหลีกเลี่ยงความแออัดของเครือข่าย เราสามารถใช้ AWS Cloudfront หรือ Akamai CDN ได้เช่นเดียวกัน

1. กลยุทธ์การแคชสามารถกล่าวถึงในรายละเอียดได้
2. การเดินทางของผู้ใช้ที่แตกต่างกันสามารถกำหนดในลักษณะที่แยกจากกันมากขึ้น
3. สามารถเพิ่มการประมาณความจุเป็นส่วนอื่นได้

1. เครือข่ายการส่งเนื้อหา CDN :https://en.wikipedia.org/wiki/Content_delivery_network
2. ทฤษฎีบทหมวก:https://en.wikipedia.org/wiki/CAP_theorem
3. การเข้ารหัสวิดีโอ:https://en.wikipedia.org/wiki/Video_coding_format
4. ที่เก็บวัตถุ:https://en.wikipedia.org/wiki/Object_storage