שיטות מומלצות לעומסי עבודה של מדיה

בעזרת Cloud Storage אתם יכולים לאחסן ולהציג נכסי אודיו ווידאו, תוך אופטימיזציה של ביצועי הסטרימינג, צמצום זמן האחזור של ההפעלה וניהול העלויות. כדי לתמוך בתהליכי עבודה של מדיה, אתם יכולים לשלב את Cloud Storage עם מוצריCloud de Confiance by S3NS כמו Media CDN,‏ Live Stream API,‏ Transcoder API ו-Video Stitcher API. במאמר הזה מתוארות השיטות המומלצות לשימוש ב-Cloud Storage לעומסי עבודה של מדיה.

סקירה כללית של עומסי עבודה של מדיה

ב-Cloud de Confiance by S3NS יש פתרונות לאופטימיזציה של סוגי עומסי העבודה הבאים בתחום המדיה:

  • הפקת מדיה: כולל עומסי עבודה כמו פוסט-פרודקשן של סרטים, כולל עריכת וידאו, שדורשים משאבי מחשוב רבים ולעיתים קרובות משתמשים במעבדי GPU למחשוב עתיר ביצועים (HPC). בדרך כלל, נתונים שקשורים למדיה ונמצאים ב-Cloud Storage מעובדים על ידי אפליקציות שפועלות ב-Compute Engine או ב-Google Kubernetes Engine, והפלט של התהליך הזה נכתב בחזרה ל-Cloud Storage. בעומסי העבודה האלה צריך להגדיל את נפח העיבוד המצטבר של קריאה וכתיבה מ-Cloud Storage לאשכול מחשוב עם זמן השבתה קצר יותר של ה-GPU. הם גם דורשים זמני אחזור נמוכים של קריאה וכתיבה, כי זה חיוני להפחתת זמן אחזור ארוך.
  • ניהול נכסי מדיה: כולל ארגון של נכסי המדיה לאחסון, לאחזור ולשימוש יעילים.
  • הצגה והפצה של תוכן: כולל סטרימינג של מדיה למשתמשים, כולל שירותי וידאו על פי דרישה (VOD) וסטרימינג בשידור חי. במהלך VoD, כשמשתמשים מבקשים תוכן שלא נשמר במטמון ברשת להעברת תוכן (CDN), התוכן נשלף מהקטגוריות של Cloud Storage. בבקשות לסטרימינג בשידור חי, התוכן נכתב בקטגוריית האחסון ונקרא מה-CDN בו-זמנית.

שיטות מומלצות לעומסי עבודה של מדיה

בקטעים הבאים מפורטות שיטות מומלצות שרלוונטיות לעומסי עבודה של מדיה.

העברת נתונים

משתמשים ב-Storage Transfer Service כדי להעלות יותר מ-1TiB של קובצי מדיה גולמיים ממקור מקומי, כמו מצלמת וידאו או אחסון מקומי, ל-Cloud Storage. ‫Storage Transfer Service מאפשר להעביר נתונים בצורה חלקה בין מערכות אחסון של אובייקטים וקבצים. להעברות קטנות יותר, בחרו את השירות להעברת נתונים אל Cloud Storage וממנו או בין מערכות קבצים, בהתאם לתרחיש ההעברה שלכם.

מיקום הקטגוריה

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

סוג האחסון (storage class)

סוג האחסון שצריך לבחור משתנה בהתאם לסוג עומס העבודה של המדיה. אלה סוגי האחסון המומלצים לעומסי עבודה שונים של מדיה:

  • כדי לנהל נכסי מדיה, כמו סרטונים בארכיון, סוג האחסון שמוגדר כברירת מחדל לקטגוריה צריך להיות Archive storage. אתם יכולים לציין סוג אחסון שונה לאובייקטים עם צורכי זמינות או גישה שונים.
  • בעומסי עבודה של הפקת מדיה והצגת תוכן, הנתונים נקראים לעיתים קרובות מקטגוריה של Cloud Storage, ולכן כדאי לאחסן אותם ב-Standard storage.

למידע נוסף על בחירת סוג האחסון לקטגוריה, ראו סוג אחסון (storage class).

ניהול מחזור החיים של הנתונים

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

אם דפוסי הגישה לנתונים צפויים, אתם יכולים להגדיר את מחזור החיים של קטגוריה. אם תדירות הגישה לנתונים לא ידועה או בלתי צפויה, אתם יכולים להגדיר את התכונה "סיווג אוטומטי" בקטגוריה. בעזרת Autoclass, ‏ Cloud Storage מעביר באופן אוטומטי נתונים שלא ניגשים אליהם לעיתים קרובות לסוגי אחסון נתונים בשימוש נדיר (cold storage) יותר.

שיטות מומלצות לעומסי עבודה של הצגת תוכן והפצת תוכן

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

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

שימוש יעיל ב-CDN

שימוש ברשת להעברת תוכן (CDN) לפני הקטגוריה של Cloud Storage משפר את חוויית משתמשי הקצה, כי ה-CDN שומר את התוכן במטמון, וכך מפחית את זמן האחזור ומגביר את היעילות של רוחב הפס. רשת CDN מאפשרת להפחית את עלות הבעלות הכוללת (TCO) על ידי הפחתת עלויות רוחב הפס, אופטימיזציה של ניצול המשאבים ושיפור הביצועים. השימוש ב-Media CDN עוזר להפחית את העלות הכוללת של הבעלות (TCO) על הצגת התוכן למשתמשי הקצה, כי עלות המילוי במטמון של Media CDN היא אפס. אתם יכולים להשתמש ב-Media CDN כמקור לרשתות CDN אחרות של צד שלישי. עם רשתות CDN אחרות, עדיין תהיה הפחתה מסוימת ב-TCO כשמציגים תוכן מהמטמון של Media CDN במקום מהמקור.

אם אתם משתמשים ב-CDN של צד שלישי, CDN Interconnect מאפשר לספקים נבחרים ליצור קישורי פירינג ישירים עם רשת הקצה של Google במיקומים שונים. תנועת הרשת שיוצאת מ- Cloud de Confiance by S3NSדרך אחד מהקישורים האלה נהנית מקישוריות ישירה לספקי CDN נתמכים, והחיוב מתבצע באופן אוטומטי במחיר מופחת. כאן אפשר למצוא רשימה של ספקי שירות שאושרו על ידי Google.

אלה האפשרויות שאפשר להגדיר כשיוצרים CDN:

בחירת המיקום של Origin Shield

המיקום של Origin Shield הוא מטמון בין ה-CDN לבין Cloud Storage. אם ה-CDN מאפשר לבחור את המיקום של מגן המקור, צריך לפעול לפי ההנחיות של ה-CDN כדי להחליט אם מומלץ לבחור את מגן המקור כך שיהיה קרוב יותר לאזור של הקטגוריה של Cloud Storage או למיקום שבו מרוכזת תעבורת הנתונים של משתמשי הקצה. מגן מקור הוא אמצעי הגנה שמונע עומס יתר על שרת המקור. רשתות CDN עם הגנה על המקור עוזרות להגדיל את פריקת העומס מהמקור על ידי הוספת מטמון נוסף בין המקור לבין ה-CDN. לדוגמה, Media CDN מספק תשתית קצה עם שכבות עמוקות, שנועדה לצמצם באופן פעיל את מילוי המטמון ככל האפשר.

הפעלת איחוד בקשות

מוודאים שהאפשרות request collapsing (כיווץ בקשות) מופעלת ב-CDN. כיווץ של כמה בקשות לבקשה אחת מפחית את עלות הפעולה של Cloud Storage מסוג Class B. לרשתות CDN יש מטמונים מבוזרים שפרוסים ברחבי העולם, אבל הן מספקות דרך לכווץ כמה בקשות של משתמשי קצה לבקשה אחת למקור. לדוגמה, Media CDN מצמצם באופן פעיל כמה בקשות של משתמשים למילוי המטמון של אותו מפתח מטמון לבקשת מקור אחת לכל צומת קצה, וכך מפחית את מספר הבקשות שנשלחות לקטגוריות.

הגדרת אופן הפעולה של הניסיון החוזר ב-CDN

חשוב להגדיר ניסיון חוזר לכל בעיה בשרת עם קוד תגובה HTTP 5xx‏ – 502, 503, 504 ב-CDN. רשתות CDN תומכות בניסיונות חוזרים במקור, ומאפשרות לנסות שוב בקשות שנכשלו במקור. רוב רשתות ה-CDN מאפשרות לציין את מספר הניסיונות החוזרים למקור הנוכחי. במאמר ניסיון חוזר של בקשות למקור מוסבר איך שולחים מחדש בקשות למקור ב-Media CDN.

אפשרויות מיקום להפצת תוכן

בעומסי עבודה שקוראים נתונים מ-Cloud Storage שלא נשמרו במטמון ב-CDN, כמו הצגת תוכן והפצה של תוכן מסוג VoD, כדאי להביא בחשבון את הגורמים הבאים כשבוחרים מיקום לקטגוריה:

  • כדי לבצע אופטימיזציה של העלות, לקטגוריות שנוצרו באזור יחיד יש את עלות האחסון הנמוכה ביותר.
  • כדי לבצע אופטימיזציה לזמינות, כדאי להביא בחשבון את הנקודות הבאות:
    • ברוב עומסי העבודה של המדיה, מומלץ להשתמש בקטגוריות של שני אזורים כי הן משכפלות את האובייקטים בשני אזורים כדי לשפר את הזמינות.
    • בתרחישי שימוש שבהם נדרשים הצגת תוכן וניתוח נתונים עם שכפול נתונים בשני מקומות שונים, כדאי להשתמש בקטגוריות במספר אזורים כדי להשיג זמינות גבוהה ככל האפשר.
  • כדי לבצע אופטימיזציה של זמן האחזור ולהפחית את עלויות הרשת, כדאי להביא בחשבון את הדברים הבאים:
    • ב-VOD, בחרו את האזורים שהכי קרובים לרוב משתמשי הקצה או את האזור עם ריכוז התנועה הגבוה ביותר.
    • במהלך סטרימינג בשידור חי, הקטגוריות מקבלות בקשות כתיבה מממירי קידוד ובקשות קריאה מרשת CDN ששומרת במטמון ומפיצה את התוכן למשתמשי הקצה. כדי לשפר את ביצועי הסטרימינג, בחרו קטגוריות אזוריות שנמצאות באותו מיקום של משאבי המחשוב שמשמשים להמרת קידוד.

אופטימיזציה של אורך קטע הווידאו בשידורים חיים

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

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

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

הגדלה הדרגתית של מספר השאילתות לשנייה (QPS)

לקטגוריות של Cloud Storage יש קיבולת קלט/פלט ראשונית של 1,000 כתיבות של אובייקטים בשנייה ו-5,000 קריאות של אובייקטים בשנייה. בעומסי עבודה של שידורים חיים, ההנחיה היא להגדיל את הבקשות בהדרגה, החל מ-1,000 כתיבות בשנייה ו-5,000 קריאות בשנייה, ולהכפיל את קצב הבקשות כל 20 דקות. השיטה הזו מאפשרת ל-Cloud Storage לחלק מחדש את העומס בין כמה שרתים, ומשפרת את הזמינות ואת זמן האחזור של הקטגוריה על ידי הפחתת הסיכויים לבעיות בהפעלה.

באירוע של סטרימינג בשידור חי עם מספר גבוה יותר של QPS, כדאי להטמיע התאמה לעומס (scaling) בקטגוריה על ידי חימום מראש של הקטגוריה או על ידי הפעלת מרחב שמות היררכי בקטגוריה. לפני שמטמיעים התאמה לעומס (scaling) בקטגוריה, צריך לבצע את המשימות הבאות:

הערכת מספר השאילתות לשנייה (QPS) למקור

נניח שבשידור חי עם מיליון צופים, ה-CDN יקבל מיליון QPS. אם נניח ששיעור המציאה במטמון (cache hit) של ה-CDN הוא 99.0%, תעבורת הנתונים שתגיע ל-Cloud Storage תהיה 1%. מספר השאילתות לשנייה יהיה 1% מסך הצופים (מיליון), כלומר 10,000 שאילתות לשנייה. הערך הזה גבוה מהקיבולת הראשונית של פעולות הקלט/פלט.

מעקב אחרי QPS ופתרון בעיות שקשורות להתאמה לעומס

כדאי לעקוב אחרי ה-QPS ולפתור שגיאות שקשורות לשינוי קנה המידה. מידע נוסף מופיע במאמר סקירה כללית על מעקב ב-Cloud Storage . כדי לעקוב אחרי בקשות הקריאה והכתיבה, בודקים את התרשים Total read/list/get request count ואת התרשים Total write request count במסוףCloud de Confiance . אם תגדילו את ה-QPS בקטגוריות מהר יותר מההנחיות להגדלה הדרגתית שצוינו בקטע הקודם, יכול להיות שתקבלו את השגיאה 429 Too many requests. איך פותרים את השגיאה "429 Too many requests"

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

הטמעת קנה מידה של QPS בקטגוריה באמצעות חימום מראש של הקטגוריה

כדי לזרז את תהליך ההתאמה לקראת אירוע של סטרימינג בשידור חי, אפשר לחמם מראש את הקטגוריה. לפני האירוע בשידור חי, צרו תעבורת נתונים סינתטית לקטגוריה שתואמת למספר ה-QPS המקסימלי שאתם מצפים ששרת המקור של ה-CDN יקבל באירוע, בתוספת מאגר נתונים זמני של 50% שמביא בחשבון את שיעור המציאה במטמון (cache hit) הצפוי של ה-CDN. לדוגמה, אם הערכתם שה-QPS לשרת המקור הוא 10,000, אז התנועה המדומה צריכה לטרגט 15,000 בקשות לשנייה כדי להכין את שרת המקור לאירוע.

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

כשיוצרים את התנועה המדומה, צריך להשתמש בגישה של התאמה הדרגתית, החל מ-5,000 בקשות לשנייה ועד שמגיעים ליעד. הקצו מספיק זמן לפני האירוע כדי להגיע לעומס המשוער. לדוגמה, כדי להגיע ל-15,000 בקשות לשנייה, הכפלת העומס בכל 20 דקות מ-5,000 בקשות לשנייה בהתחלה תימשך כ-30 דקות.

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

שימוש בקטגוריות עם מרחב שמות היררכי כדי להשיג מספר גבוה של שאילתות לשנייה (QPS) בהתחלה

בקטגוריות של Cloud Storage עם מרחב שמות היררכי מופעל, מספר השאילתות לשנייה (QPS) הראשוני גבוה עד פי 8 בהשוואה לקטגוריות בלי HNS. המספר הגבוה יותר של QPS בהתחלה מאפשר להגדיל בקלות את עומסי העבודה שדורשים הרבה נתונים, ומספק תפוקה משופרת. מידע על המגבלות בקטגוריות שבהן מופעל מרחב שמות היררכי מופיע במאמר מגבלות.

כדי להגדיל את מספר השאילתות לשנייה, כדאי להימנע משמות עוקבים לקטעי וידאו

כשמגדילים את מספר השאילתות לשנייה, הבקשות מפוזרות בין כמה שרתים. עם זאת, יכול להיות שתיתקלו בצווארי בקבוק בביצועים כשכל האובייקטים משתמשים בתחילית לא אקראית או עוקבת. שימוש בשמות אקראיים לחלוטין במקום שמות עוקבים מספק את פיזור העומסים הטוב ביותר. עם זאת, אם רוצים להשתמש במספרים רציפים או בחותמות זמן כחלק משמות האובייקטים, כדאי להוסיף רנדומיזציה באמצעות ערך גיבוב (hash) לפני המספר הסידורי או החותמת. לדוגמה, אם שם האובייקט המקורי שרוצים להשתמש בו הוא my-bucket/2016-05-10-12-00-00/file1, אפשר לחשב את גיבוב ה-MD5 של שם האובייקט המקורי ולהוסיף את ששת התווים הראשונים של הגיבוב כקידומת לשם האובייקט. האובייקט החדש יהיה my-bucket/2fa764-2016-05-10-12-00-00/file1.. למידע נוסף, קראו את המאמר שימוש במוסכמה למתן שמות שמפזרת את העומס באופן שווה בין מפתחות. אם אתם לא יכולים להימנע ממתן שמות עוקבים לקטעי וידאו, השתמשו בקטגוריות שבהן מופעל מרחב שמות היררכי כדי לקבל מספר גבוה יותר של שאילתות לשנייה.

שימוש בקטגוריות שונות לכל שידור חי

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

המאמרים הבאים