Cloud Load Balancing מספק מנגנונים לחלוקת תעבורת המשתמשים בין כמה מופעים של אפליקציה. הם עושים זאת על ידי פיזור העומס על פני מופעים של האפליקציה, וכך מספקים למשתמשי הקצה ביצועים אופטימליים של האפליקציה. בדף הזה מתוארות כמה שיטות מומלצות שיעזרו לכם לוודא שמאזן העומסים מותאם לאפליקציה שלכם. כדי להבטיח ביצועים אופטימליים, מומלץ להשוות את דפוסי התנועה של האפליקציה שלכם.
מיקום של שרתים עורפיים קרוב ללקוחות
ככל שהמשתמשים או אפליקציות הלקוח קרובים יותר לעומסי העבודה (הקצה העורפי של מאזן העומסים), כך זמן האחזור ברשת ביניהם קצר יותר. לכן, כדאי ליצור את ה-backends של מאזן העומסים באזור שקרוב ביותר למיקום שבו צפויה להגיע תעבורת הנתונים של המשתמשים לחלק הקדמי של Google. במקרים רבים, כדי לצמצם את זמן האחזור ללקוחות בחלקים שונים בעולם, צריך להריץ את השרתים העורפיים בכמה אזורים.
מידע נוסף זמין בנושאים הבאים:
הפעלת שמירה במטמון באמצעות Cloud CDN
מפעילים את Cloud CDN ואת השמירה במטמון כחלק מהגדרת ברירת המחדל של מאזן העומסים החיצוני הגלובלי של אפליקציות (ALB). מידע נוסף זמין במאמר בנושא Cloud CDN.
כשמפעילים את Cloud CDN, יכולות לעבור כמה דקות עד שהתשובות מתחילות להיכנס למטמון. שירות Cloud CDN שומר במטמון רק תשובות עם תוכן שניתן לשמירה במטמון. אם התגובות לכתובת URL מסוימת לא נשמרות במטמון, צריך לבדוק אילו כותרות תגובה מוחזרות עבור כתובת ה-URL הזו, ואיך הוגדרה האפשרות לשמירה במטמון עבור ה-Backend. פרטים נוספים זמינים במאמר בנושא פתרון בעיות ב-Cloud CDN.
בחירת פרוטוקול של כלל העברה
במאזן עומסים גלובלי חיצוני של אפליקציות (ALB) ובמאזן עומסים קלאסי של אפליקציות, מומלץ להשתמש ב-HTTP/3, שהוא פרוטוקול אינטרנט שמבוסס על IETF QUIC. פרוטוקול HTTP/3 מופעל כברירת מחדל בכל הדפדפנים העיקריים, ב-Android Cronet וב-iOS. כדי להשתמש ב-HTTP/3 באפליקציות, צריך לוודא שתעבורת ה-UDP לא חסומה או מוגבלת ברשת, ושהפרוטוקול HTTP/3 לא הושבת בעבר במאזני העומסים החיצוניים הגלובליים של האפליקציות. לקוחות שלא תומכים עדיין ב-HTTP/3, כמו דפדפנים ישנים או ספריות רשת, לא יושפעו. מידע נוסף אפשר למצוא במאמר בנושא HTTP/3 QUIC.
במאזן עומסים חיצוני אזורי של אפליקציות, אנחנו תומכים ב-HTTP/1.1, ב-HTTPS וב-HTTP/2. גם HTTPS וגם HTTP/2 דורשים תקורה מוקדמת כדי להגדיר TLS.
בחירת פרוטוקול של שירות לקצה העורפי
הבחירה שלכם בפרוטוקול ה-Backend (HTTP, HTTPS או HTTP/2) משפיעה על זמן האחזור של האפליקציה ועל רוחב הפס ברשת שזמין לאפליקציה. לדוגמה, שימוש ב-HTTP/2 בין מאזן העומסים לבין שרת עורפי (backend instance) עשוי לדרוש הרבה יותר חיבורי TCP למופע מאשר HTTP(S). אי אפשר להשתמש ב-HTTP/2 בטכניקה של איגום חיבורים, שהיא אופטימיזציה שמצמצמת את מספר החיבורים האלה באמצעות HTTP(S). כתוצאה מכך, יכול להיות שתראו השהיות גבוהות בשרת העורפי כי החיבורים לשרת העורפי מתבצעים בתדירות גבוהה יותר.
הפרוטוקול של שירות הקצה העורפי משפיע גם על האופן שבו התנועה מוצפנת בזמן ההעברה. במאזני עומסים חיצוניים מסוג HTTP(S), כל תעבורת הנתונים שמועברת לשרתי בק-אנד שנמצאים בתוך רשתות VPC מוצפנת באופן אוטומטי. Google Cloud ההצפנה הזו נקראת הצפנה אוטומטית ברמת הרשת. עם זאת, הצפנה אוטומטית ברמת הרשת זמינה רק לתקשורת עם קבוצות של מכונות ועם קצוות עורפיים של NEG אזוריים. לכל סוגי ה-backend האחרים, מומלץ להשתמש באפשרויות פרוטוקול מאובטחות כמו HTTPS ו-HTTP/2 כדי להצפין את התקשורת עם שירות לקצה העורפי. פרטים נוספים זמינים במאמר הצפנה ממאזן העומסים אל קצה העורף.
משך חיבור מומלץ
תנאי הרשת משתנים, וקבוצת השרתים העורפיים עשויה להשתנות בהתאם לעומס. באפליקציות שמייצרות הרבה תנועה לשירות יחיד, חיבור שפועל לאורך זמן הוא לא תמיד ההגדרה האופטימלית. במקום להשתמש בחיבור יחיד לקצה העורפי ללא הגבלת זמן, מומלץ לבחור משך חיים מקסימלי לחיבור (למשל, בין 10 ל-20 דקות) או מספר מקסימלי של בקשות (למשל, בין 1,000 ל-2,000 בקשות), שאחריו ייעשה שימוש בחיבור חדש לבקשות חדשות. החיבור הישן נסגר כשכל הבקשות הפעילות שמשתמשות בו מסתיימות.
כך אפליקציית הלקוח יכולה ליהנות משינויים במערך השרתים העורפיים, כולל שרתי ה-proxy של מאזן העומסים וכל אופטימיזציה מחדש של הרשת שנדרשת כדי לשרת את הלקוחות.
קריטריונים לבחירת מצב איזון
כדי לשפר את הביצועים, כדאי לבחור את קבוצת השרתים העורפיים לכל בקשה חדשה על סמך השרת העורפי שמגיב הכי מהר. אפשר לעשות את זה באמצעות מצב האיזון RATE. במקרה כזה, המערכת בוחרת בקבוצת השרתים העורפיים עם זמן האחזור הממוצע הנמוך ביותר בבקשות האחרונות, או, ב-HTTP/2 וב-HTTP/3, בקבוצת השרתים העורפיים עם מספר הבקשות הממתינות הנמוך ביותר.
מצב האיזון UTILIZATION חל רק על קצה עורפי של קבוצת מופעים, ומפיץ את התנועה על סמך השימוש במופעי מכונות וירטואליות בקבוצת מופעים.
הגדרת זיקה לסשן
במקרים מסוימים, כדאי שאותו שרת קצה עורפי יטפל בבקשות שמגיעות מאותם משתמשי קצה, או שקשורות לאותו משתמש קצה, לפחות למשך תקופה קצרה. אפשר להגדיר את זה באמצעות זיקה לסשן, הגדרה שמוגדרת בשירות הקצה העורפי. התכונה 'זיקה לסשן' שולטת בהפצה של חיבורים חדשים מלקוחות אל הבק-אנד של מאזן העומסים. אפשר להשתמש בזיקה לסשן (session affinity) כדי לוודא שאותו בק-אנד מטפל בבקשות מאותו משאב, למשל בקשות שקשורות לאותו חשבון משתמש או מאותו מסמך.
ההגדרה של זיקה לסשן חלה על כל משאב השירות לקצה העורפי, ולא על כל קצה עורפי בנפרד. עם זאת, מפת URL יכולה להפנות לכמה שירותי קצה עורפי. לכן, לא צריך להשתמש רק בסוג אחד של זיקה לסשן (session affinity) למאזן העומסים (LB). בהתאם לאפליקציה, אפשר להשתמש בשירותי קצה עורפי שונים עם הגדרות שונות של זיקה לסשן (session affinity). לדוגמה, אם חלק מהאפליקציה שלכם מציג תוכן סטטי למשתמשים רבים, סביר להניח שלא תהיה תועלת משימוש בזיקה לסשן (session affinity). במקום זאת, תשתמשו בשירות לקצה העורפי עם Cloud CDN כדי להציג תגובות שנשמרו במטמון.
מידע נוסף זמין במאמר בנושא זיקה לסשן.