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

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

סקירה כללית

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

  • הפקת מדיה: כולל עומסי עבודה כמו פוסט-פרודקשן של סרטים, כולל עריכת וידאו, שדורשים משאבי מחשוב רבים ולעיתים קרובות משתמשים במעבדי GPU למחשוב עתיר ביצועים (HPC). בדרך כלל, נתונים שקשורים למדיה ונמצאים ב-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, ‏ 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 מאפשר לספקים נבחרים ליצור קישורי פירינג ישירים עם רשת הקצה של Google במיקומים שונים. תנועת הרשת שיוצאת מ- Google Cloudדרך אחד מהקישורים האלה נהנית מקישוריות ישירה לספקי CDN נתמכים, והחיוב מתבצע באופן אוטומטי במחיר מופחת. רשימה של ספקים מאושרים זמינה במאמר ספקי שירותים שאושרו על ידי Google.

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

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

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

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

מוודאים שהאפשרות 'איחוד בקשות' מופעלת ב-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) בקטגוריה על ידי חימום מראש של הקטגוריה או על ידי הפעלת מרחב שמות היררכי בקטגוריה. לפני שמטמיעים שינוי גודל בקטגוריה, צריך לבצע את המשימות הבאות:

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

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

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

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

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

הטמעת קנה מידה של 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 של שם האובייקט המקורי ולהוסיף את 6 התווים הראשונים של הגיבוב כקידומת לשם האובייקט. האובייקט החדש יהיה my-bucket/2fa764-2016-05-10-12-00-00/file1.. למידע נוסף, קראו את המאמר שימוש במוסכמה למתן שמות שמפזרת את העומס באופן שווה בין מפתחות. אם אתם לא יכולים להימנע ממתן שמות עוקבים לקטעי וידאו, השתמשו בקטגוריות שבהן מופעל מרחב שמות היררכי כדי לקבל מספר גבוה יותר של שאילתות לשנייה.

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

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

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