כשמריצים מחסנית של אפליקציות על משאבים מבוזרים בענן, תעבורת הרשת צריכה להיות מנותבת בצורה יעילה למשאבים הזמינים בכמה מיקומים. בחלק הזה של Google Cloud המדריך לאמינות התשתית מתוארות טכניקות לניהול תעבורה ועומסים, שאפשר להשתמש בהן כדי לשפר את האמינות של עומסי העבודה בענן.
תכנון קיבולת
כדי לוודא שלאפליקציה שפרסתם ב- Google Cloud יש מספיק משאבי תשתית, אתם צריכים להעריך את הקיבולת הנדרשת ולנהל את הקיבולת שנפרסה. בקטע הזה מפורטות הנחיות שיעזרו לכם לתכנן ולנהל את הקיבולת.
תחזית של עומס האפליקציה
כשמבצעים תחזית לגבי העומס, צריך לקחת בחשבון גורמים כמו מספר המשתמשים והקצב שבו האפליקציה עשויה לקבל בקשות. בתחזיות, כדאי להתייחס למגמות היסטוריות של עומס, לשינויים עונתיים, לעליות חדות בעומס במהלך אירועים מיוחדים ולצמיחה שנובעת משינויים עסקיים כמו התרחבות לאזורים גיאוגרפיים חדשים.
הערכת דרישות הקיבולת
על סמך ארכיטקטורת הפריסה, ובהתחשב ביעדי הביצועים והמהימנות של האפליקציה, צריך להעריך את הכמות של משאביGoogle Cloud שנדרשים כדי לטפל בעומס הצפוי. לדוגמה, אם אתם מתכננים להשתמש בקבוצות של מופעי מכונה מנוהלים (MIG) ב-Compute Engine, אתם צריכים להחליט על הגודל של כל MIG, על סוג המכונה הווירטואלית ועל המספר, הסוג והגודל של הדיסקים הקשיחים הקבועים. אפשר להשתמש בGoogle Cloud מחשבון עלויות כדי להעריך את העלות של משאבי Google Cloud .
תכנון יתירות מספקת
כשמעריכים את דרישות הקיבולת, צריך לספק יתירות מספקת לכל רכיב במערך האפליקציות. לדוגמה, כדי להשיג יתירות של N+1, לכל רכיב במערך האפליקציה צריך להיות לפחות רכיב יתיר אחד מעבר למינימום שנדרש לטיפול בעומס התחזית.
השוואה של האפליקציה לנקודת מידוד
מריצים בדיקות עומס כדי לקבוע את יעילות המשאבים של האפליקציה. יעילות המשאבים היא היחס בין העומס על האפליקציה לבין המשאבים שהאפליקציה צורכת, כמו CPU וזיכרון. יעילות המשאבים של אפליקציה עלולה להיפגע כשהעומס גבוה במיוחד, והיעילות עשויה להשתנות לאורך זמן. מומלץ לבצע את בדיקות העומס בתנאי עומס רגילים ובתנאי עומס שיא, ולחזור על בדיקות ההשוואה במרווחי זמן קבועים.
ניהול מכסות
Google Cloud מכסות של שירותים הן מגבלות לכל פרויקט, שעוזרות לכם לשלוט בצריכת משאבי הענן. יש שני סוגים של מכסות: מכסות משאבים הן המשאבים המקסימליים שאפשר ליצור, כמו מספר אשכולות Google Kubernetes Engine (GKE) אזוריים באזור מסוים. מכסות לקצב שליחת בקשות מגבילות את מספר בקשות ה-API שאפשר לשלוח לשירות בתקופה מסוימת. המיכסות יכולות להיות אזוריות, גלובליות או לפי אזור. מומלץ לבדוק את מכסות המשאבים הנוכחיות ואת מכסות הקצב של יצירת בקשות ל-API בשירותים שאתם מתכננים להשתמש בהם בפרויקטים. מוודאים שהמכסות מספיקות לקיבולת שאתם צריכים. במקרה הצורך, אפשר לבקש להגדיל את המכסה.
שמירת קיבולת מחשוב
כדי לוודא שהקיבולת של משאבי Compute Engine זמינה כשצריך, אפשר ליצור הזמנות. הזמנה מספקת קיבולת מובטחת באזור ספציפי למספר מסוים של מכונות וירטואליות מסוג מכונה שתבחרו. אפשר להגדיר הזמנה ספציפית לפרויקט, או לשתף אותה בין כמה פרויקטים. מידע נוסף על הזמנות זמין במאמר בחירת סוג הזמנה.
מעקב אחר הניצול והערכה מחדש של הדרישות מעת לעת
אחרי שפורסים את המשאבים הנדרשים, צריך לעקוב אחרי ניצול הקיבולת. יכול להיות שתזהו הזדמנויות לאופטימיזציה של העלויות על ידי הסרת משאבים לא פעילים. חשוב להעריך מחדש את דרישות הקיבולת באופן תקופתי, ולשקול שינויים בהתנהגות האפליקציה, ביעדי הביצועים והמהימנות, בעומס המשתמשים ובתקציב ה-IT.
התאמה אוטומטית לעומס (Automatic scaling)
כשמריצים אפליקציה במשאבים שמפוזרים בכמה מיקומים, האפליקציה נשארת זמינה במהלך הפסקות שירות באחד מהמיקומים. בנוסף, יתירות עוזרת להבטיח שהמשתמשים יחוו התנהגות עקבית של האפליקציה. לדוגמה, כשחל זינוק בעומס, המשאבים המיותרים מבטיחים שהאפליקציה תמשיך לפעול ברמה צפויה. אבל כשהעומס על האפליקציה נמוך, יתירות עלולה לגרום לניצול לא יעיל של משאבי הענן.
לדוגמה, רכיב עגלת הקניות של אפליקציית מסחר אלקטרוני צריך לעבד תשלומים עבור 99.9% מההזמנות תוך 200 אלפיות השנייה אחרי אישור ההזמנה. כדי לעמוד בדרישה הזו בתקופות של עומס גבוה, יכול להיות שתצטרכו להקצות קיבולת מיותרת של מחשוב ואחסון. אבל כשהעומס על האפליקציה נמוך, יכול להיות שחלק מהקיבולת שהוקצתה לא ישמש או שהשימוש בו יהיה חלקי. כדי להסיר את המשאבים שלא נמצאים בשימוש, צריך לעקוב אחרי השימוש ולהתאים את הקיבולת. התאמה אוטומטית לעומס עוזרת לכם לנהל את הקיבולת בענן ולשמור על רמת הזמינות הנדרשת בלי להוסיף תקורה תפעולית של ניהול משאבים מיותרים. כשהעומס על האפליקציה גדל, התאמה אוטומטית לעומס (autoscaling) עוזרת לשפר את הזמינות של האפליקציה על ידי הקצאה אוטומטית של משאבים נוספים. בתקופות של עומס נמוך, התאמה אוטומטית לעומס מסירה משאבים שלא נמצאים בשימוש, ועוזרת לצמצם את העלויות.
בשירותים מסוימים של Google Cloud , כמו Compute Engine, אפשר להגדיר שינוי גודל אוטומטי למשאבים שמקצים. שירותים מנוהלים כמו Cloud Run יכולים להגדיל את הקיבולת באופן אוטומטי בלי שתצטרכו להגדיר שום דבר. דוגמאות ל Google Cloudשירותים שתומכים בהתאמה אוטומטית לעומס. זו רשימה חלקית.
- Compute Engine: קבוצות של מכונות מנוהלות (MIG) מאפשרות לכם לשנות את גודלן של אפליקציות חסרות מצב (stateless) שנפרסות במכונות וירטואליות של Compute Engine באופן אוטומטי, כך שהקיבולת תתאים לעומס הנוכחי. מידע נוסף זמין במאמר בנושא קבוצות של מופעים עם שינוי גודל אוטומטי.
- GKE: אתם יכולים להגדיר אשכולות GKE כך שגודל מאגרי הצמתים ישתנה אוטומטית בהתאם לעומס הנוכחי. למידע נוסף, אפשר לעיין במאמר בנושא מידרוג אוטומטי של אשכולות. באשכולות GKE שמוקצים במצב Autopilot, המערכת משנה את גודל הצמתים ועומסי העבודה באופן אוטומטי בהתאם לתנועת הגולשים.
- Cloud Run: שירותים שמוקצים ב-Cloud Run מתרחבים אוטומטית למספר המכונות של הקונטיינר שדרוש לטיפול בעומס הנוכחי. כשהאפליקציה לא נמצאת בעומס, השירות מצטמצם אוטומטית למספר מכונות קונטיינר אפס. מידע נוסף זמין במאמר מידע על התאמה אוטומטית לעומס של מכונות קונטיינר.
- פונקציות Cloud Run: כל בקשה לפונקציה מוקצית למופע של הפונקציה. אם נפח הבקשות הנכנסות חורג ממספר המופעים הקיימים של הפונקציה, פונקציות Cloud Run מפעילות אוטומטית מופעים חדשים של הפונקציה. מידע נוסף זמין במאמר בנושא סביבת ההפעלה של פונקציות Cloud Run.
- Bigtable: כשיוצרים אשכול במופע של Bigtable, אפשר להגדיר את האשכול כך שגודלו ישתנה באופן אוטומטי. מערכת Bigtable עוקבת אחרי העומס על המעבד ועל נפח האחסון, ומשנה את מספר הצמתים באשכול כדי לשמור על שיעורי הניצול של משאבי המטרה שציינתם. למידע נוסף אפשר לעיין במאמר בנושא שינוי גודל אוטומטי ב-Bigtable.
- Managed Service for Apache Spark: כששולחים עומס עבודה של Apache Spark, השירות המנוהל ל-Apache Spark משנה באופן דינמי את קנה המידה של משאבי עומס העבודה, כמו מספר תהליכי הביצוע, כדי להפעיל את עומס העבודה בצורה יעילה. מידע נוסף זמין במאמר בנושא Managed Service for Apache Spark for Spark autoscaling.
איזון עומסים
איזון עומסים עוזר לשפר את מהימנות האפליקציה על ידי ניתוב התנועה רק למשאבים הזמינים, ועל ידי הבטחה שלא יהיה עומס יתר על משאבים בודדים.
כשבוחרים ומגדירים מאזני עומסים לפריסה בענן, כדאי להביא בחשבון את ההמלצות הבאות שקשורות למהימנות.
איזון עומסים של תנועה פנימית
כדאי להגדיר איזון עומסים גם לתנועה בין השכבות של מחסנית האפליקציות, ולא רק לתנועה בין הלקוחות החיצוניים לבין האפליקציה. לדוגמה, במערך של אפליקציית אינטרנט בת 3 שכבות, אפשר להשתמש במאזן עומסים פנימי כדי ליצור תקשורת מהימנה בין שכבות האינטרנט והאפליקציה.
בחירת סוג מתאים של מאזן עומסים
כדי לאזן עומסים של תנועה חיצונית לאפליקציה שמפוזרת על פני כמה אזורים, אפשר להשתמש במאזן עומסים גלובלי או בכמה מאזני עומסים אזוריים. מידע נוסף זמין במאמר היתרונות והסיכונים של איזון עומסים גלובלי לפריסות מרובות אזורים.
אם השרתים העורפיים נמצאים באזור יחיד ואתם לא צריכים את התכונות של איזון עומסים גלובלי, אתם יכולים להשתמש במאזן עומסים אזורי, שהוא עמיד להפסקות חשמל באזורים.
כשבוחרים את סוג מאזן העומסים, צריך לקחת בחשבון גורמים נוספים מלבד הזמינות, כמו שליטה גיאוגרפית בסיום TLS, ביצועים, עלות וסוג התנועה. מידע נוסף זמין במאמר בחירת מאזן עומסים.
הגדרת בדיקות תקינות
התכונה'שינוי גודל אוטומטי' עוזרת לוודא שיש לאפליקציות מספיק משאבי תשתית כדי להתמודד עם העומס הנוכחי. אבל גם אם יש מספיק משאבי תשתית, יכול להיות שאפליקציה או חלקים ממנה לא יגיבו. לדוגמה, יכול להיות שכל המכונות הווירטואליות שמארחות את האפליקציה יהיו במצב RUNNING. אבל יכול להיות שתוכנת האפליקציה שפרוסה בחלק מהמכונות הווירטואליות קרסה. בדיקות תקינות של איזון עומסים מוודאות שמאזני העומסים מעבירים את תעבורת האפליקציה רק אל השרתים העורפיים שמגיבים. אם השרתים העורפיים הם קבוצות של מכונות וירטואליות לניהול מופעים (MIG), כדאי להגדיר שכבת בדיקות תקינות נוספת כדי לתקן באופן אוטומטי את המכונות הווירטואליות שלא זמינות. כשמגדירים תיקון אוטומטי לקבוצת MIG, המכונות הווירטואליות שלא זמינות נמחקות באופן יזום, ונוצרות מכונות וירטואליות חדשות.
הגבלת קצב של יצירת בקשות
לפעמים, יכול להיות שיהיה באפליקציה שלכם גידול מהיר או מתמשך בעומס. אם האפליקציה לא מתוכננת להתמודד עם העומס המוגבר, יכול להיות שהיא או המשאבים שבה ישתבשו, והאפליקציה לא תהיה זמינה. העומס המוגבר עשוי להיגרם מבקשות זדוניות, כמו מתקפות מניעת שירות מבוזרות (DDoS) שמבוססות על רשת. עלייה פתאומית בעומס יכולה לקרות גם בגלל סיבות אחרות, כמו שגיאות בהגדרות של תוכנת הלקוח. כדי לוודא שהאפליקציה יכולה להתמודד עם עומס יתר, כדאי להשתמש במנגנונים מתאימים להגבלת קצב הבקשות. לדוגמה, אתם יכולים להגדיר מכסות למספר בקשות ה-API ששירות מסוים יכול לקבל. Google Cloud
טכניקות להגבלת קצב יכולות גם לעזור לכם לבצע אופטימיזציה של העלות של תשתית הענן. לדוגמה, אם מגדירים מכסות ברמת הפרויקט למשאבים ספציפיים, אפשר להגביל את החיוב שהפרויקט יכול לצבור על המשאבים האלה.
Network Service Tier
Google Cloud מסלולי שירות הרשת מאפשרים לכם לבצע אופטימיזציה של הקישוריות בין מערכות באינטרנט לבין עומסי העבודה שלכם ב-Google Cloud . אם יש לכם אפליקציות שמשרתות משתמשים ברחבי העולם ויש להן בק-אנד ביותר מאזור אחד, כדאי לבחור במסלול פרימיום. תעבורת נתונים מהאינטרנט נכנסת לרשת עם הביצועים המיטביים של Google ב-point of presence (PoP) שהכי קרובה למערכת ששלחה אותה. ברשת של Google, תעבורת הנתונים מנותבת מנקודת הכניסה (PoP) למשאב המתאים Google Cloud , כמו מכונה וירטואלית ב-Compute Engine. תעבורת נתונים יוצאת נשלחת דרך הרשת של Google ויוצאת בנקודת ה-PoP שהכי קרובה ליעד. שיטת הניתוב הזו עוזרת לשפר את תפיסת הזמינות של המשתמשים באמצעות הפחתה של מספר הצעדים ברשת בין המשתמשים לנקודות PoP שהכי קרובות אליהם.