הנחיות לקצב הבקשות ולחלוקת הרשאות גישה

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

התאמה לעומס (auto-scaling)

‫Cloud Storage הוא שירות מרובה דיירים (multi-tenant), כלומר המשתמשים חולקים את אותה קבוצה של משאבים בסיסיים. כדי לנצל את המשאבים המשותפים בצורה הטובה ביותר, הקיבולת הראשונית של כל קטגוריה היא:

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

קצבי הקריאה והכתיבה הראשוניים האלו הם בממוצע 2.5PB לכתיבה ו-13PB לקריאה בחודש לאובייקטים של 1MB. ככל שקצב הבקשות בקטגוריה מסוימת גדל, Cloud Storage מבצע התאמה לעומס (autoscaling) באופן אוטומטי ומגדיל את קיבולת ה-IO של אותה קטגוריה על ידי פיזור עומס הבקשות בין מספר שרתים.

זמן פיזור מחדש של העומס

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

הוספת מפתחות אובייקטים לאינדקס

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

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

שיטות מומלצות

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

הגדלה הדרגתית של קצב הבקשות

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

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

  • מתקבלות שגיאות עם קודי התגובה 408 ו-429.
  • מתקבלות שגיאות עם קודי התגובה 5xx.

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

שימוש במוסכמה למתן שמות שמפזרת את העומס באופן שווה בין מפתחות

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

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

לדוגמה, אם שמות האובייקטים המקוריים שרוצים להשתמש בהם הם:

my-bucket/2016-05-10-12-00-00/file1
my-bucket/2016-05-10-12-00-00/file2
my-bucket/2016-05-10-12-00-01/file3
...

אפשר לחשב את גיבוב ה-MD5 של שם האובייקט המקורי ולהוסיף את 6 התווים הראשונים של הגיבוב כקידומת לשם האובייקט. שמות האובייקטים החדשים הופכים להיות:

my-bucket/2fa764-2016-05-10-12-00-00/file1
my-bucket/5ca42c-2016-05-10-12-00-00/file2
my-bucket/6e9b84-2016-05-10-12-00-01/file3
...

קידומת אקראית ארוכה יותר מאפשרת התאמה לעומס (autoscaling) אפקטיבית יותר, כשעולים לקצבי קריאה וכתיבה גבוהים מאוד. לדוגמה, קידומת בת תו אחד של ערך הקסדצימלי אקראי יעילה כדי לספק התאמה לעומס (auto-scaling) מערכים של 5,000/1,000 קריאות/כתיבות לשנייה, לערכים של 80,000/16,000 קריאות/כתיבות לשנייה. כי לקידומת יש 16 ערכים פוטנציאליים. אם בתרחיש שלכם אין צורך בקצבים גבוהים יותר, קידומת אקראית באורך תו אחד יעילה באותה מידה להגדלת קצבי הבקשות כמו קידומת אקראית באורך שני תווים או יותר.

רנדומיזציה בשם אחרי תחילית משותפת תקפה לאותה תחילית

שימו לב שהמחרוזת האקראית לא חייבת להופיע בתחילת שם האובייקט. הוספת מחרוזת אקראית אחרי קידומת משותפת עדיין מאפשרת להתאמה לעומס (scaling) לעבוד, אבל ההשפעה תהיה מוגבלת לאותה קידומת, בלי להתייחס לשאר הקטגוריה.

לדוגמה:

my-bucket/images/animals/4ce4c6af-6d27-4fa3-8a91-5701a8552705/1.jpg
my-bucket/images/animals/9a495e72-1d85-4637-a243-cbf3e4a90ae7/2.jpg
...
my-bucket/images/landscape/585356ac-ce89-47a8-bdd2-78a86b58fee6/1.jpg
my-bucket/images/landscape/2550ae5b-395e-4243-a29b-bbf5aece60ef/2.jpg
...
my-bucket/images/clouds/1.jpg
my-bucket/images/clouds/2.jpg
...

השמות שניתנו למעלה יעילים כדי לאפשר התאמה לעומס (auto-scaling) של אובייקטים ב-images/animals וב-images/landscape,, אבל לא ב-images/clouds.

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

כפי שצוין למעלה, שימוש במחרוזת אקראית אחרי קידומת משותפת עוזרת רק להתאמה לעומס (auto-scaling) בקידומת הזו. כשהבקשות עוברות לקידומת חדשה, יכול להיות שכבר לא תופק תועלת מההשפעה הקודמת של ההתאמה לעומס (auto-scaling). זאת בעיה במיוחד כאשר הקידומות מגיעות בדפוס סדרתי.

לדוגמה, אם בכל שעה כותבים קבצים עם קידומת חדשה המבוססת על חותמת זמן:

my-bucket/2016-05-10-00/cf9a7b95-0d2e-4466-9596-840ff388ddbd
my-bucket/2016-05-10-00/f1e16a88-16b8-4c66-ba66-a225c87be80c
my-bucket/2016-05-10-00/646d8272-4a88-4dc2-b2d4-d537c778df41
...
my-bucket/2016-05-10-01/bdcba6de-ac25-4c27-8550-0d08f249e69d
my-bucket/2016-05-10-01/a32c867c-09a9-4d65-9668-ddd4ebe4138b
my-bucket/2016-05-10-01/d619485c-5243-4a4e-8ef3-0f7e1d26ce1d
...

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

סידור מחדש של פעולות בכמות גדולה כדי לפזר את העומס באופן שווה בין המפתחות

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

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

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