עיצוב המערכת של אפליקציית צפייה בשידורי שמע הוא ייחודי באופן בו הוא עוסק בצורכי העסקיים האידיוסינקרטיים. לרוב, צפיית שמע דורשת כמות גדולה של נתונים שיש להעביר בתוך רוחב הפס של ערוץ התקשורת ברשת.
שירות צפיית שמע מוצלח חייב להתמודד עם מיליוני משתמשים פעילים ואלפי ספקי תוכן ממיקומים גיאוגרפיים שונים. מכשירים ופלטפורמות שונים (טלפון חכם, שולחן עבודה, רמקול חכם) עשויים לתמוך בפורמטי שמע שונים כגון MP3, FLAC, ALAC, וכו'.
בפוסט הבלוג הזה, נחקור את הפרטים הקטנים בעיצוב של מערכת מורכבת כזו המכסה דרישות פונקציונליות ואינפרה-פונקציונליות.
דרישות פונקציונליות
דרישות הפונקציונליות יכסו יכולות נדרשות ליוצרי התוכן ולמשתמשי אודיו או למאזינים.
- ניהול תוכן. יוצר התוכן יכול להעלות, למחוק או לעדכן אודיו בכל פורמט. כל אודיו צריך לכלול מטא-נתונים כגון כותרת, יוצר, תיאור, קטגוריה ותגיות מטא-נתונים.
- הודעות. יוצר התוכן מקבל התראות על הצלחה או כישלון בהעלאת האודיו. המאזין או המשתמש באודיו מקבל התראות על העלאת האודיו בהצלחה.
- צפייה חלקית. המשתמשים יכולים לנגן, לעצור, להשתמש בפונקציית הקדימה ולהוריד אודיו בפורמט המועדף עליהם.
- מנוי. המשתמשים צריכים להיות מסוגלים להירשם לאודיו שבחרו כדי לקבל התראות על תוכן חדש או מעודכן.
- התחברות משתמש. יוצרים של תוכן חייבים להיות מאומתים ומורשים לגשת למערכת. משתמשים יכולים להירשם למערכת כדי להגדיר את הפרופילים שלהם.
- חיפוש. המשתמשים צריכים להיות מסוגלים לחפש אודיו בהתבסס על מאפיינים מסוימים או מטאדאטה.
הערה: שידור חי ושירותי תשלום אינם בתחום המאמר הזה.
דיאגרמת רצף של מקרה השימוש הפונקציונלי
עיצוב ארכיטקטוני
בואו נגדיר רכיבי שירות לתמוך בדרישות הפונקציונליות.
הדרישה הפונקציונלית הראשונה היא להעלות אודיו בכל פורמט כגון MP3, FLAC, ALAC וכו'. קבצי האודיו הללו יכולים להכיל כמות מרשימה של נתונים. קודק האודיו משחק תפקיד מכריע באחסון, שידור והשמעה יעילים של נתונים אלו. ישנם בעיקר שני סוגים של קודקים:
- קודק ללא אובדן – מדחס אודיו מבלי לאבד נתונים וניתן לשחזר אותו לחלוטין מבלי לאבד איכות.
- קודק עם אובדן – מסיר חלק מהנתונים שעוזרים להפחית את הגודל באופן משמעותי. זה עלול לפגוע באיכות הצליל.
ספק התוכן עובד בדרך כלל עם פורמטים ללא אובדן להקלטה ועריכה. זה מבטיח שאין אובדן באיכות בזמן הפעלת השמע, החלקת אפקטים וההפקה הסופית. במונחים פשוטים, מיזוג שמע הינו השלב הסופי בתהליך הפקת השמע.
פעם שהשמע הסופי עבר את התהליך של המיזוג, הוא משודר לפורמט באיבודים עבור הפצה כללית. בפורמט באיבודים, הגודל מתקצץ במידה רבה, מה שהופך את הזרימה וההורדה לקלים ומהירים יותר.
השמע הדחוס צריך להיות מועבר למכשיר המאזין עם רוחב פס רשת נתמך. רוחב הפס עשוי להשתנות באופן דינמי, כאשר עומס הרשת משתנה בהתאם למספר המשתמשים המחוברים או לתנודות המשתמש בין אזורי רשת שונים בזמן ההאזנה לשמע.
כדי לתמוך ברוחב הפס הדינמי הזה של הרשת, הקודק היכול להשתמש במנגנון "קצב פס תגובה" (adaptive bit rate). זרימת קצב פס תגובה זוהתה באופן דינמי את רוחב הפס של המשתמשים, ומיישרת את הזרימה בהתאם. היא יכולה להחליף באופן דינמי את קצב הזרימה בהתאם לרוחב הפס הנוכחי של המשתמש. תוצאת זאת היא הפחתת זמן ההמתנה, זמני התחלה מהירים וחוויית משתמש טובה לחיבורים גבוהים ונמוכים כאחד.
המקודד מקודד את המקור היחיד של קובץ השמע ברמות פסים שונות. זרמי הבתים הללו מארוזים ומאוחסנים באחסון אובייקטים כדי להיות זמינים למאזין. לאחר העלאת השמע בהצלחה, שירות ההודעות שולח התראה לספק התוכן.
היוצרת ספקת מטא-נתונים בקשת העלאת השמע, שניתן לשמור ישירות במסד נתונים NoSQL דרך Audio Data service. הנתונים הללו יתווספו למבנה המפתחי על מנת להציע יכולות חיפוש משופרות למאזין שמע.
מערכת השמע דורשת שירות אימות ואישור כדי לטפל ברישום משתמשים חדשים, התחברות באמצעות פרטי המשתמש, ואישור על פי תפקידים הקשורים למשתמשים (מאזינים וספקי תוכן). שירות שער API Gateway שיכול לנהל אימות ואישור במרכז. שירות זה ניתן לשימוש לבצע מיתוג בקשות, ולאורכן תהליך זרימת העבודה מהחזית לשירות בצד אחורי.
המשתמש בשמע (מאזין) יכול לחפש אודיו שמעני, שיעבר ל-שירות נתוני Audio כדי להחזיר את מיקומם של השמע(ים) הרלוונטי(ים), תוך משיכת מידע ממאגר המטא-נתונים של השמע. המשתמש לוחץ על הקישור, וזה יחזיר את הבתים של השמע מארוזים ומאוחסנים על ידי ה-שירות אריזה.
שירות פרופיל משתמש ניהל פרטי משתמש, עוקבים, ומעקבים.
התרשים לעיל מתאר את זרימת התהליך הבסיסית "העלאת שמע" המופעלת על ידי ספק התוכן וזרימת התהליך "האזנה לשמע" המופעלת על ידי משתמש/מאזין השמע.
התבנית לעיצוב של צינור וסינון עם שימוש בתור הודעות משמשת לתמיכה בזרימת הנתונים בין השירותים לצורך התגמול בתהליך באופן יעיל עם פרלליזם ועמידות בפני תקלות.
עכשיו, בואו נעבור לדרישות לא פונקציונליות.
דרישות לא פונקציונליות
- גמישות בהתרחבות. המערכת צריכה לתמוך באלפי משתמשים סטטיים ולהיות מסוגלת להתרחב ולהתכפל.
- עמידות בפני תקלות. המערכת צריכה להיות עמידת תקלות, לרוב עם נתונים חוזרים, ועם זמן עומד נמוך.
- ביצועים. המערכת צריכה להציג לטיניות נמוכה ותגובה גבוהה במהלך ניגון תוכן.
- אבטחה. המערכת חייבת להיות מוגנת מפני גישה לא מורשית או לתקיפות מזיקות כגון DDoS.
גמישות בהתרחבות
מערכת השמע צריכה להתמודד עם אלפי יוצרי תוכן פעילים. כדי לנהל את העומס, העיצוב כולל הרצת מספר רב של מופעים של השירות של API Gateway, השירות של App Web, והשירות של נתוני השמע שנפתחים על ידי מאזני משקל.
עם זאת, זה לא יהיה גמיש עם הגדלת מספר יוצרי התוכן. קבצי השמע רגילים גדולים, ויעשו שימוש גבוה ברשת ובמחשב במהלך העברה דרך מרכיבי השירות הרבים. כדי לייעל את שימוש במשאבי המערכת, ניתן להשתמש ב-URL מוחתם (נקרא גם URL מוחתם מראש) לספק גישה בלתי מוגבלת בזמן למאגר האובייקטים להעלאת קבצי שמע ישירות. זה מסיר את הצורך לנתב תעבורת דרך API Gateway ושירות API Web. ה-URL-ים החתומים ניתנים להגדרת הרשאות גרנולריות וכללי תפוגה לבטיחות טובה יותר.
זה מכסה את דרישות הסקלביליות להעלאת קבצי האודיו על ידי ספקי תוכן.
מיליוני בקשות חיפוש מהמאזינים לאודיו עשויות לפגוע במערכת, מה שיגרום לשירות נתוני האודיו להיות עמוס. כדי להרחיב את המערכת התומכת בפעולת החיפוש המאסיבית הזו, ניתן להשתמש בדגם העיצוב של הפרדת אחריות השאילתות של תוכן (CQRS). פעולות הקריאה והכתיבה מהמאגר יכולות להתנהל באופן עצמאי, תוך תמיכה בדרישות שונות של השהיה, סקלביליות ואבטחה.
עמידות בפני תקלות
ישנם ממדים שונים לעיצוב עמידות בפני תקלות. כמה מהם כבר כלולים בעיצוב.
- שימוש במספר מופעים של שירות לסקלביליות ועמידות בפני תקלות
- תור מסרים עם עיבוד צינור לתמיכה בעמידות בפני תקלות ברמת זרימת הנתונים
- הפרדת שירות המרה ושירות אריזת נתונים
- מספר מופעי DB עם רפליקה
- אזורי זמינות המתיישרים עם אזורים גיאוגרפיים כגון מזרח ארה"ב, מערב ארה"ב ואזור האוקיאנוס השקט לצורך פריסת המערכת כולה התומכת באזור ספציפי ובסיס משתמשים.
ביצועים
רשת הפצת תוכן (CDN) היא רשת מפוזרת של שרתים שמאוגדים יחד כדי לספק תוכן, כמו קבצי אודיו ווידאו, מהר ויעיל יותר. היא מאחסנת את התוכן בשרת הקצה כדי לספק ביצועים טובים יותר עם שהות נמוכה.
אבטחה
CDN משפר גם את האבטחה על ידי הספקת פתרונות להפחתת התקפות DDoS ומדידות אבטחה נוספות.
שירות החבילות יפיץ את קבצי השמע ל-CDN כדי שיחוסנו בשרתי הקצה. שירות הנתונים השמעיים יעדכן את מיקום ה-CDN במטא-נתוניו שינותבו אל שירות החיפוש לשאילתות משתמשים.
התרשים לעיל מתאר את ארכיטקטורת הרכיבים ברמה גבוהה של מערכת שמע טיפולית.
מסקנה
בלב של מערכת שמע טובה נמצאים קידמה, ביצועים ועמידות בפני תקלות כדי לספק חוויית משתמש טובה עם פשטות מינימלית, לטנציה נמוכה ואמינות.
Source:
https://dzone.com/articles/system-design-of-an-audio-streaming-system