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