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

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

סקירה כללית

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 אחרות, עדיין אפשר להקטין את העלות הכוללת של הבעלות כשמציגים תוכן ממטמון Media CDN במקום ממקור התוכן.

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

אלה האפשרויות להגדרה כשמגדירים 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. בהנחה ששיעור המציאות במטמון (cache hit) של ה-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 בקטגוריה על ידי חימום מראש של הקטגוריה

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

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

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

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

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

קטגוריות ב-Cloud Storage עם מרחב שמות היררכי (HNS) מספקות עד פי שמונה יותר בקשות לשנייה (QPS) בהשוואה לקטגוריות בלי HNS. ה-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 גבוה יותר.

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

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

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