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

בדף הזה מתוארות שיטות מומלצות לשימוש ב-Cloud Storage לעומסי עבודה של מדיה. עומסי העבודה האלה כוללים לעיתים קרובות מוצרים שונים של Google Cloud כמו Media CDN,‏ Live Stream API,‏ Transcoder API ו-Video Stitcher API. Google Cloud

סקירה כללית

Google Cloud מציע פתרונות לאופטימיזציה של עומסי עבודה מהסוגים הבאים של מדיה:

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

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

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

העברת נתונים

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

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

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

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

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

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

מידע נוסף על בחירת סוג האחסון לקטגוריה זמין במאמר סוג אחסון.

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

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

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

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

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

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

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

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

אם אתם משתמשים ב-CDN של צד שלישי, CDN Interconnect מאפשר לספקים נבחרים ליצור קישור ישיר בין רשתות שכנות (direct peering) עם רשת הקצה של Google במיקומים שונים. תנועת הרשת שיוצאת מ- Google Cloudדרך אחד מהקישורים האלה נהנית מקישוריות ישירה לספקי CDN נתמכים, והחיוב מתבצע באופן אוטומטי במחירים מוזלים. כאן אפשר למצוא רשימה של ספקים מאושרים.

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

בחירת המיקום של מגן המקור

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

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

מוודאים שהאפשרות 'איחוד בקשות' מופעלת ב-CDN. כשמכווצים כמה בקשות לבקשה אחת, עלות הפעולה מסוג Class B ב-Cloud Storage יורדת. לרשתות 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 לנקודת המוצא

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

מעקב אחר QPS ופתרון בעיות שקשורות לשינוי גודל

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

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

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

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

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

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

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

שימוש בקטגוריות עם מרחב שמות היררכי להשגת QPS גבוה בהתחלה

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

כדי להגדיל את ה-QPS, כדאי להימנע משמות עוקבים לקטעי וידאו

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

שימוש בדלי אחסון שונים לכל שידור חי

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

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