רוב מאזני העומסים משתמשים בגישה של חלוקת תעבורה לפי שיטת round-robin או לפי גיבוב (hashing) שמבוסס על זרימה. עם זאת, יכול להיות שמאזני עומסים שמשתמשים בגישה הזו יתקשו להתאים את עצמם כשהביקוש עולה מעבר לקיבולת הזמינה של הצגת המודעות. במאמר הזה מוסבר איך אפשר לפתור את הבעיות האלה ולשפר את הקיבולת של האפליקציה הגלובלית באמצעות Cloud Load Balancing. התוצאה היא בדרך כלל חוויית משתמש טובה יותר ועלויות נמוכות יותר בהשוואה להטמעות מסורתיות של איזון עומסים.
המאמר הזה הוא חלק מסדרת מאמרים על שיטות מומלצות שמתמקדת במוצרי איזון העומסים של Google Cloud. למדריך שמשלים את המאמר הזה, ראו ניהול קיבולת באמצעות איזון עומסים. למידע מעמיק על זמן אחזור, אפשר לעיין במאמר אופטימיזציה של זמן האחזור באפליקציות באמצעות איזון עומסים.
אתגרים שקשורים לקיבולת באפליקציות גלובליות
הרחבת אפליקציות גלובליות יכולה להיות מאתגרת, במיוחד אם יש לכם תקציבי IT מוגבלים ועומסי עבודה בלתי צפויים ומשתנים. בסביבות ענן ציבורי כמו Google Cloud, הגמישות שמספקות תכונות כמו התאמה אוטומטית לעומס ואיזון עומסים יכולה לעזור. עם זאת, יש כמה מגבלות לשימוש בכלי לשינוי גודל אוטומטי, כפי שמוסבר בקטע הזה.
זמן האחזור בהפעלת מופעים חדשים
הבעיה הנפוצה ביותר שקשורה להתאמה אוטומטית לעומס היא שהאפליקציה המבוקשת לא מוכנה לטפל בתנועה שלכם מספיק מהר. בהתאם לתמונות של מופעי ה-VM, בדרך כלל צריך להריץ סקריפטים ולטעון מידע לפני שמופעי ה-VM מוכנים. לרוב עוברות כמה דקות עד שהאיזון בעומס יכול להפנות משתמשים למופעי מכונה וירטואלית חדשים. במהלך התקופה הזו, התנועה מופצת למופעי מכונות וירטואליות קיימים, שאולי כבר חורגים מהקיבולת.
אפליקציות שמוגבלות בגלל קיבולת ה-Backend
אי אפשר לבצע שינוי אוטומטי של קנה המידה בחלק מהאפליקציות. לדוגמה, למסדי נתונים יש לרוב קיבולת מוגבלת של קצה עורפי. רק מספר מסוים של חזיתות יכול לגשת למסד נתונים שלא ניתן להרחבה אופקית. אם האפליקציה שלכם מסתמכת על ממשקי API חיצוניים שתומכים רק במספר מוגבל של בקשות לשנייה, אי אפשר להגדיר לה גם שינוי גודל אוטומטי.
רישיונות לא גמישים
כשמשתמשים בתוכנה עם רישיון, הרישיון מגביל אתכם בדרך כלל לקיבולת מקסימלית מוגדרת מראש. לכן, יכול להיות שהיכולת שלכם להגדיל את הקיבולת באופן אוטומטי תהיה מוגבלת כי אי אפשר להוסיף רישיונות תוך כדי תנועה.
מרווח ביטחון קטן מדי במכונת ה-VM
כדי להתמודד עם פרצי תנועה פתאומיים, כדאי להגדיר במידרוג אוטומטי מרווח ביטחון גדול (לדוגמה, המנגנון מופעל ב-70% מקיבולת המעבד). כדי לחסוך בעלויות, יכול להיות שתתפתו להגדיר יעד גבוה יותר, למשל 90% מקיבולת המעבד. עם זאת, ערכי טריגר גבוהים יותר עלולים לגרום לצווארי בקבוק בהרחבת הקיבולת כשמערכת נתקלת בפרצי תנועה, למשל קמפיין פרסום שגורם לעלייה פתאומית בביקוש. צריך לאזן את גודל המרווח בהתאם לשינויים החדים בתעבורה ולמשך הזמן שנדרש למכונות הווירטואליות החדשות להיות מוכנות.
מכסות אזוריות
אם יש לכם עליות פתאומיות לא צפויות באזור מסוים, יכול להיות שמכסות המשאבים הקיימות יגבילו את מספר המכונות שאפשר להרחיב, כך שלא תוכלו לתמוך בעלייה הפתאומית הנוכחית. יכול להיות שיעברו כמה שעות או כמה ימים עד שהמכסה של המשאבים תוגדל.
איך מתמודדים עם האתגרים האלה באמצעות איזון עומסים גלובלי
מאזני עומסים חיצוניים של אפליקציות (ALB) ומאזני עומסי רשת חיצוניים בשרת proxy הם מוצרים גלובליים לאיזון עומסים שמועברים דרך שרתי Google Front End (GFE) שמסונכרנים באופן גלובלי. כך קל יותר לצמצם את הבעיות האלה שקשורות לאיזון עומסים. המוצרים האלה מציעים פתרון לאתגרים האלה כי התנועה מופצת לשרתי קצה אחורי באופן שונה מרוב הפתרונות האזוריים לאיזון עומסים.
ההבדלים האלה מתוארים בקטעים הבאים.
אלגוריתמים שמשמשים מאזני עומסים אחרים
רוב מאזני העומסים משתמשים באותם אלגוריתמים כדי לחלק את תנועת הגולשים בין השרתים העורפיים:
- כולם נגד כולם. החבילות מחולקות באופן שווה בין כל השרתים העורפיים, ללא קשר למקור ולייעד של החבילות.
- גיבוב (hashing). זרימות של חבילות נתונים מזוהות על סמך גיבוב של פרטי התנועה, כולל כתובת ה-IP של המקור, כתובת ה-IP של היעד, היציאה והפרוטוקול. כל התנועה שמפיקה את אותו ערך hash מועברת לאותו שרת קצה עורפי.
אלגוריתם הגיבוב (hashing) לאיזון עומסים הוא האלגוריתם שזמין כרגע למאזני עומסי רשת חיצוניים להעברת סיגנל ללא שינוי. מאזן העומסים הזה תומך בגיבוב של 2-tuple (מבוסס על כתובת ה-IP של המקור והיעד), בגיבוב של 3-tuple (מבוסס על כתובת ה-IP של המקור, כתובת ה-IP של היעד והפרוטוקול) ובגיבוב של 5-tuple (מבוסס על כתובת ה-IP של המקור, כתובת ה-IP של היעד, יציאת המקור, יציאת היעד והפרוטוקול).
בשני האלגוריתמים האלה, מופעים לא תקינים מוצאים מההפצה. עם זאת, העומס הנוכחי על השרתים העורפיים הוא בדרך כלל לא גורם בהפצת העומס.
חלק ממאזני העומסים של חומרה או תוכנה משתמשים באלגוריתמים שמעבירים תנועה על סמך מדדים אחרים, כמו הקצאת משקל לכל שרת, העומס הנמוך ביותר, זמן התגובה המהיר ביותר או מספר החיבורים הפעילים. עם זאת, אם העומס עולה מעל הרמה הצפויה בגלל פרצי תנועה פתאומיים, התנועה עדיין מופצת למופעי backend שעברו את הקיבולת שלהם, מה שמוביל לעלייה דרסטית בחביון.
חלק ממאזני העומסים מאפשרים כללים מתקדמים שבהם תעבורה שחורגת מהקיבולת של ה-Backend מועברת למאגר אחר או מופנית לאתר סטטי. כך תוכלו לדחות את התנועה הזו ולשלוח הודעה בסגנון 'השירות לא זמין, אפשר לנסות שוב מאוחר יותר'. חלק ממאזני העומסים מאפשרים להוסיף בקשות לתור.
פתרונות גלובליים לאיזון עומסים מיושמים לעיתים קרובות באמצעות אלגוריתם מבוסס DNS, שמציג כתובות IP שונות לאיזון עומסים אזוריים על סמך המיקום של המשתמש ועומס הבק-אנד. הפתרונות האלה מציעים יתירות כשל לאזור אחר עבור כל התעבורה או חלקה בפריסה אזורית. עם זאת, בכל פתרון שמבוסס על DNS, יתירות כשל נמשכת בדרך כלל כמה דקות, בהתאם לערך אורך חיים (TTL) של רשומות ה-DNS. באופן כללי, כמות קטנה של תנועה תמשיך להיות מופנית לשרתים הישנים הרבה אחרי שערך ה-TTL אמור לפוג בכל מקום. לכן, איזון עומסים גלובלי מבוסס-DNS הוא לא הפתרון האופטימלי לטיפול בתנועה בתרחישים של פרצי תנועה.
איך פועלים מאזני עומסים חיצוניים של אפליקציות (ALB)
מאזן העומסים החיצוני של אפליקציות משתמש בגישה שונה. התעבורה מועברת דרך שרתי GFE שנפרסו ברוב מיקומי הקצה של הרשת הגלובלית של Google. בשלב הזה יש יותר מ-80 מיקומים ברחבי העולם. אלגוריתם איזון העומסים מופעל בשרתי GFE.
מאזן העומסים של אפליקציות החיצוני זמין דרך כתובת IP יציבה אחת שמוכרזת באופן גלובלי בצמתי הקצה, והחיבורים מסתיימים על ידי כל אחד משרתי GFE.
ממשקי ה-GFE מחוברים זה לזה דרך הרשת הגלובלית של Google. נתונים שמתארים את השרתים העורפיים הזמינים ואת קיבולת ההגשה הזמינה לכל משאב מאוזן עומסים מופצים באופן רציף לכל שרתי ה-GFE באמצעות מישור בקרה גלובלי.
התעבורה לכתובות IP שמאוזנות עומסים מועברת באמצעות proxy למופעי קצה עורפי שמוגדרים בתצורה של מאזן העומסים החיצוני של האפליקציות, באמצעות אלגוריתם מיוחד לאיזון עומסים שנקרא Waterfall by Region. האלגוריתם הזה קובע את ה-backend האופטימלי לטיפול בבקשה, תוך התחשבות בקרבה של המופעים למשתמשים, בעומס הנכנס וגם בקיבולת הזמינה של ה-backend בכל אזור. בסופו של דבר, נלקחים בחשבון גם העומס והקיבולת ברחבי העולם.
מאזן העומסים החיצוני של אפליקציות מפזר את התנועה על סמך המופעים הזמינים. כדי להוסיף מופעים חדשים על סמך העומס, האלגוריתם פועל בשילוב עם קבוצות מופעים בהתאמה אוטומטית.
זרימת התנועה באזור
בנסיבות רגילות, כל תעבורת הנתונים נשלחת לאזור שהכי קרוב למשתמש. לאחר מכן מתבצע איזון עומסים בהתאם להנחיות הבאות:
בכל אזור, התנועה מחולקת בין קבוצות של מכונות וירטואליות, שיכולות להיות בכמה אזורים בהתאם לקיבולת של כל קבוצה.
אם הקיבולת לא שווה בין התחומים, התחומים נטענים באופן יחסי לקיבולת ההגשה הזמינה שלהם.
בתוך אזורים, הבקשות מתחלקות באופן שווה בין המופעים בכל קבוצת מופעים.
הסשנים נשמרים על סמך כתובת ה-IP של הלקוח או על סמך ערך קובץ Cookie, בהתאם להגדרת הזיקה לסשן.
אלא אם הקצה העורפי הופך ללא זמין, חיבורי TCP קיימים אף פעם לא עוברים לקצה עורפי אחר.
בתרשים הבא מוצגת חלוקת העומס במקרה כזה, שבו כל אזור נמצא מתחת לקיבולת שלו ויכול להתמודד עם העומס מהמשתמשים שהכי קרובים לאזור הזה.
תנועה עודפת לאזורים אחרים
אם אזור שלם מגיע לקיבולת המקסימלית שלו, כפי שנקבע על ידי קיבולת ההגשה שהוגדרה בשירותי הקצה העורפי, מופעל האלגוריתם Waterfall by Region (מפל לפי אזור), והתעבורה עוברת לאזור הקרוב ביותר שיש בו קיבולת זמינה. כאשר אזור מסוים מגיע לקיבולת המקסימלית שלו, התנועה עוברת לאזור הקרוב הבא, וכן הלאה. הקרבה של אזור למשתמש מוגדרת לפי זמן הלוך ושוב ברשת מ-GFE לשרתי הקצה של המופע.
התרשים הבא מציג את הגלישה לאזור הקרוב הבא כשבאזור אחד מתקבלת תנועה גדולה יותר ממה שהוא יכול לטפל בה באופן אזורי.
גלישה בין אזורים בגלל קצוות עורפיים לא תקינים
אם בדיקות התקינות מגלות שיותר ממחצית השרתים העורפיים באזור מסוים לא תקינים, שרתי ה-GFE מעבירים באופן יזום עומס תנועה קל לאזור הקרוב הבא. הפעולה הזו מתבצעת כדי למנוע מצב שבו התנועה נכשלת לחלוטין, כי האזור הופך ללא תקין. הגלישה הזו מתרחשת גם אם הקיבולת שנותרה באזור עם השרתים העורפיים הלא תקינים מספיקה.
בתרשים הבא מוצג מנגנון הגלישה בפועל, כי רוב השרתים העורפיים באזור מסוים לא תקינים.
כל האזורים שחורגים מהקיבולת
כשהתעבורה לכל האזורים מגיעה לקיבולת או מעליה, המערכת מאזנת את התעבורה כך שכל אזור יהיה באותה רמה יחסית של חריגה מהקיבולת. לדוגמה, אם הביקוש הגלובלי עולה על הקיבולת הגלובלית ב-20%, התנועה מופצת כך שכל האזורים מקבלים בקשות ב-20% מעל הקיבולת האזורית שלהם, תוך שמירה על התנועה מקומית ככל האפשר.
בתרשים הבא מוצג כלל הגלישה הגלובלי הזה בפעולה. במקרה כזה, אזור יחיד מקבל כל כך הרבה תנועה שלא ניתן לחלק אותה בכלל עם קיבולת ההגשה הזמינה ברמה הגלובלית.
גלישה זמנית מעל המגבלה במהלך שינוי גודל אוטומטי
התאמה אוטומטית לעומס מבוססת על מגבלות הקיבולת שהוגדרו בכל שירות לקצה העורפי, ומפעילה מופעים חדשים כשתנועת המשתמשים מתקרבת למגבלות הקיבולת שהוגדרו. יכול להיות שלא יהיה צורך בהעברת התנועה לאזורים אחרים, בהתאם לקצב העלייה ברמות הבקשות ולקצב שבו מופעלים מופעים חדשים. במקרים אחרים, הנתונים העודפים יכולים לשמש כמאגר זמני עד שמופעלים מופעים מקומיים חדשים ומוכנים לטפל בתנועה בזמן אמת. אם הקיבולת שהורחבה באמצעות שינוי גודל אוטומטי מספיקה, כל הסשנים החדשים מופצים לאזור הקרוב ביותר.
השפעות של זמן האחזור על גלישה
בהתאם לאלגוריתם Waterfall by Region, יכול להיות שיהיה עודף עומס תנועה קל שמאזן העומסים של אפליקציות (ALB) החיצוני ינתב לאזורים אחרים. עם זאת, סשנים של TCP ותעבורת SSL עדיין מסתיימים על ידי GFE שהכי קרוב למשתמש. האפשרות הזו מועילה לזמן האחזור של האפליקציה. פרטים נוספים זמינים במאמר אופטימיזציה של זמן האחזור של האפליקציה באמצעות איזון עומסים.
תרגול מעשי: מדידת ההשפעות של ניהול הקיבולת
כדי להבין איך מתרחשת הצפה ואיך אפשר לנהל אותה באמצעות מאזן עומסים מסוג HTTP, אפשר לעיין במדריך לניהול קיבולת באמצעות איזון עומסים שמצורף למאמר הזה.
שימוש במאזן עומסים חיצוני של אפליקציות (ALB) כדי לפתור בעיות שקשורות לקיבולת
כדי להתמודד עם האתגרים שצוינו קודם, מאזני עומסים חיצוניים של אפליקציות (ALB) ומאזני עומסי רשת חיצוניים לשרת proxy יכולים להעביר את העומס מעבר לקיבולת לאזורים אחרים. באפליקציות גלובליות, עדיף להגיב למשתמשים עם זמן אחזור כללי קצת יותר גבוה מאשר להשתמש בשרת קצה עורפי אזורי. באפליקציות שמשתמשות בקצה עורפי אזורי, זמן האחזור נמוך יותר, אבל הן עלולות להיות עמוסות מדי.
נחזור עכשיו לתרחישים שהוזכרו בתחילת המאמר ונראה איך מאזן עומסים חיצוני של אפליקציות (ALB) יכול לעזור לפתור אותם:
זמן האחזור בהפעלת מופעים חדשים. אם המידרוג האוטומטי לא מצליח להוסיף קיבולת מספיק מהר במהלך פרצי תנועה מקומיים, מאזן העומסים החיצוני של אפליקציות מעביר באופן זמני את העומס של החיבורים לאזור הקרוב הבא. כך אנחנו מוודאים שהסשנים הקיימים של משתמשים באזור המקורי יטופלו במהירות אופטימלית כי הם יישארו בשרתי הקצה העורפיים הקיימים, ושהסשנים החדשים של משתמשים יחוו רק עלייה קלה בזמן האחזור. ברגע שמגדילים את מספר השרתים העורפיים (backend instance) באזור המקורי, התנועה החדשה מנותבת שוב לאזור הקרוב ביותר למשתמשים.
אפליקציות שמוגבלות בגלל קיבולת ה-Backend. אפליקציות שלא ניתן להרחיב את הקיבולת שלהן באופן אוטומטי, אבל הן זמינות בכמה אזורים, עדיין יכולות להעביר את העומס לאזור הקרוב הבא אם הביקוש באזור מסוים חורג מהקיבולת שהוקצתה לצרכי עומס תנועה רגיל.
רישיונות לא גמישים. אם מספר רישיונות התוכנה מוגבל, ומאגר הרישיונות באזור הנוכחי מוצה, מאזן העומסים החיצוני של אפליקציות יכול להעביר את התעבורה לאזור שבו יש רישיונות זמינים. כדי שהפעולה הזו תתבצע, מספר המכונות המקסימלי צריך להיות זהה למספר הרישיונות במידרוג אוטומטי.
אין מספיק מרווח ב-VM. האפשרות של גלישה אזורית עוזרת לחסוך כסף, כי אפשר להגדיר התאמה אוטומטית לעומס (autoscaling) עם טריגר של שימוש גבוה ב-CPU. אפשר גם להגדיר קיבולת זמינה של ה-Backend מתחת לכל שיא אזורי, כי גלישה לאזורים אחרים מבטיחה שהקיבולת הגלובלית תמיד תהיה מספיקה.
מכסות אזוריות. אם המכסות של משאבי Compute Engine לא תואמות לביקוש, מאזן העומסים החיצוני של אפליקציות מפנה באופן אוטומטי חלק מהתעבורה לאזור שעדיין יכול להתרחב במסגרת המכסה האזורית שלו.
המאמרים הבאים
בדפים הבאים מופיע מידע נוסף על אפשרויות איזון העומסים של Google:
- מדריך בנושא ניהול קיבולת באמצעות איזון עומסים
- אופטימיזציה של זמן האחזור של אפליקציות באמצעות איזון עומסים
- Codelab בנושא רישות – מדריך למתחילים
- מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי
- מאזן עומסים חיצוני של אפליקציות (ALB)
- מאזן עומסי רשת חיצוני לשרת proxy