שיטות מומלצות ב-Cloud Storage

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

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

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

מתן שמות

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

תעבורת נתונים

• אתם צריכים לבצע הערכה גסה של כמות תעבורת הנתונים שיישלחו ל-Cloud Storage. ספציפית, כדאי לחשוב על הנושאים הבאים:

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

  • רוחב פס. כמה נתונים יישלחו, ובאיזו מסגרת זמן? כדאי להשתמש בכלי כמו Wolfram Alpha כדי למנוע טעויות בחישובים.

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

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

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

• כאשר מטפלים בשגיאות, אתם צריכים:

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

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

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

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

אפשרויות של מיקומים ואחסון נתונים

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

רשימות ACL ובקרת גישה

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

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

  • אתם צריכים להימנע משימוש במידע רגיש כחלק משמות של קטגוריות או אובייקטים. לדוגמה, במקום לתת לקטגוריה שם כמו mysecretproject-prodbucket, עדיף לתת לה את השם somemeaninglesscodename-prod. באפליקציות מסוימות, יכול להיות שתרצו לשמור מטא-נתונים רגישים בכותרות מותאמות אישית של Cloud Storage כמו x-goog-meta, במקום לקודד את המטא-נתונים בשמות האובייקטים.

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

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

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

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

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

העלאות נתונים

• אם אתם משתמשים בקריאות חוזרות (callbacks) של XMLHttpRequest ‏(XHR) כדי לקבל עדכוני התקדמות, מומלץ לא לסגור ולפתוח מחדש את החיבור אם אתם מזהים שההתקדמות נעצרה. אם תעשו זאת, הפעולה הזו תיצור לולאת משוב חיובי בעייתית בתקופות של עומס ברשת. כשיש עומס על הרשת, קריאות חוזרות של XHR עלולות להתעכב מאחורי פעילות האישור (ACK/NACK) של זרימת ההעלאה. במקרה כזה, סגירה ופתיחה מחדש של החיבור תנצל יותר קיבולת רשת בדיוק בזמן שהכי פחות נוח לכם.

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

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

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

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

מחיקת נתונים

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