גישה ללא שרת לפיתוח מהיר של שירות וידאו עובד

אני עובד במיקור חוץ, כאשר העיקרון העיקרי יכול להיות מתואר במשפט "למכור הרבה, לעשות את זה מהר". ככל שנעשה זאת מהר יותר, כך נרוויח יותר. וכן, רצוי שהכל יעבוד לא על קביים ונוזלים, אלא ברמת איכות מקובלת. אספר לכם על הניסיון שלי כאשר היה צורך לפתח שירות קידום מכירות בפרק זמן קצר.

בהתחשב you חשבון שורש ב-AWS, ללא הגבלות על בחירת ערימת טכנולוגיה, קצה אחורי וחודש אחד לפיתוח.

משימה: ליישם שירות קידום מכירות שבו משתמשים מעלים בין סרטון אחד לארבעה סרטונים שנמשכים בין שנייה לארבע שניות, אשר מוטמעים לאחר מכן בסדרת הסרטונים המקורית.

החלטה

לכתוב שירות אופניים משלך בזמן כל כך קצר זה לא רעיון טוב. בנוסף, על מנת שהשירות יעמוד בעומס ושכולם יקבלו את הסרטון הנכסף, תידרש תשתית. ורצוי לא עם תג המחיר מהמטוס. לכן, אנו מתמקדים מיד בפתרונות מוכנים בהתאמה אישית מינימלית.

הפתרון הסטנדרטי לעבודה עם וידאו הוא FFmpeg, כלי עזר לקונסולות חוצות פלטפורמות, שבאמצעות טיעונים, מאפשר לך לחתוך ולדובב אודיו. כל מה שנותר לעשות הוא לכתוב עטיפה ולשחרר אותה לחיים. אנחנו כותבים אב טיפוס שמחבר שני סרטונים ביחד, ו...הכיף מתחיל. הספרייה מבוססת על .NET Core 2, היא אמורה לפעול על כל מכונה וירטואלית, אז אנחנו לוקחים מופע של AWS EC2 והכל יעבוד

טקסט נסתרלא, זה לא יעבוד
.
למרות ש-FFmpeg מפשט את המשימה, לפתרון עובד באמת צריך ליצור מופע EC2 ולתכנן עבורו תשתית רשת, כולל 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 Event עבור כל שינוי סטטוס. זה מאפשר לנו ליישם טריגרים של למבדה להשלמת עיבוד וידאו.

כך נראית הארכיטקטורה הסופית:

הקצה האחורי כולו שוכן בשתי למבדות. אחד נוסף מיועד לסיבוב סרטונים אנכיים, מכיוון שלא ניתן לבצע עבודה כזו במעבר אחד.

אנו נמקם את החזית בצורה של אפליקציית SPA כתובה ב-JS והידור באמצעות פאג בדלי S3 ציבורי. כדי להוריד את הסרטונים עצמם, אנחנו לא צריכים שום קוד שרת - אנחנו רק צריכים לפתוח את נקודות הקצה של REST ש-S3 מספק לנו. הדבר היחיד הוא אל תשכח להגדיר מדיניות ו-CORS.

חסרונות

• AWS MediaConvert, מסיבה לא ידועה, מחיל רק סאונד על כל קטע וידאו בנפרד, אבל אנחנו צריכים שיר עליז מכל שומר המסך.
• יש לעבד סרטונים אנכיים בנפרד. AWS לא אוהב פסים שחורים ומעמיד את הגלילים ב-90°.

משטח החלקה קל

למרות כל היופי של Stateless, אתה צריך לעקוב אחר מה שצריך לעשות עם הסרטון: הדבק או הוסף אודיו לרצף הווידאו המוגמר. למרבה המזל, MediaConvert תומכת בהעברת מטא נתונים דרך העבודות שלה, ואנחנו תמיד יכולים להשתמש בדגל פשוט בצורת "isMasterSoundJob", ולנתח את המטא נתונים האלה בכל שלב.

Serverless מאפשר בצורה מושלמת עבודה עם NoOps - גישה המניחה את חוסר הצורך של צוות נפרד האחראי על תשתית הפרויקט. לכן, זה היה עניין קטן - אנחנו פורסים את הפתרון ב-AWS ללא השתתפות של מנהלי מערכת, שממילא תמיד יש להם מה לעשות.
וכדי להאיץ את כל זה, אנו ממצים את סקריפט הפריסה עד כמה שניתן ב-AWS CloudFormation, המאפשרת לפרוס באמצעות כפתור אחד ישירות מ-VS. כתוצאה מכך, קובץ של 200 שורות קוד מאפשר לך להוציא פתרון מוכן, למרות שהתחביר של CloudFormation יכול להיות מזעזע אם אתה לא רגיל אליו.

בסך הכל

ללא שרת הוא לא תרופת פלא. אבל זה יעשה את החיים הרבה יותר קלים במצבים עם שלושה גבולות: "משאבים מוגבלים - לטווח קצר - כסף קטן."

מאפיינים של יישומים מתאימים ללא שרתים

• ללא תהליכים ארוכי טווח. מגבלת ה-API Gateway היא 29 שניות, המגבלה הקשה של למבדה היא 5 דקות;
• מתואר על ידי ארכיטקטורה מונחה אירועים;
• מתפרק לרכיבים מחוברים באופן רופף כמו SOA;
• אינו דורש עבודה רבה עם מצבך;
• כתוב ב-.NET Core. כדי לעבוד עם .NET Framework, עדיין תצטרך לפחות Docker עם זמן הריצה המתאים.

יתרונות הגישה ללא שרת

• מפחית את עלויות התשתית;
• מפחית את עלות אספקת הפתרון;
• מדרגיות אוטומטית;
• פיתוח בחוד החנית של הקידמה הטכנולוגית.

חסרונות, עם דוגמה ספציפית

• מעקב ורישום מבוזר - נפתרו חלקית באמצעות AWS X-Ray ו-AWS CloudWatch;
• ניפוי באגים לא נוח;
• התחלה קרה כאשר אין עומס;
• ממשק משתמש עוין של AWS הוא בעיה אוניברסלית :)

מקור: www.habr.com