איזון עומס מוסבר בפשטות

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

אז מה זה בעצם מאזן עומסים

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

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

איך הוא מחליט לאן לשלוח כל בקשה

יש כמה אלגוריתמים נפוצים, וכל אחד מתאים למצב שונה:

• Round Robin. הכי פשוט - שרת ראשון, אחר כך שני, אחר כך שלישי, וחוזר חלילה. עובד טוב כשכל השרתים דומים בעוצמה ובעומס.
• Least Connections. שולח את הבקשה לשרת עם הכי מעט חיבורים פעילים כרגע. עדיף כשבקשות שונות לוקחות זמן שונה, כי Round Robin עלול להעמיס יותר מדי על שרת שכבר עסוק בבקשה כבדה.
• IP Hash. מחשב חתימה מכתובת ה-IP של הלקוח ותמיד שולח אותו לאותו שרת. שימושי כשצריך שאותו משתמש תמיד יגיע לאותו שרת, למשל בגלל מידע שנשמר מקומית.
• Weighted. נותן משקל שונה לכל שרת לפי העוצמה שלו - שרת חזק יותר מקבל יותר בקשות מאשר שרת חלש יותר.

L4 מול L7 - שתי רמות של איזון עומס

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

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

מאזן עומסים ברמת האפליקציה (Layer 7) מסתכל בפועל בתוך הבקשה - הכתובת שביקשו, ה-headers, אפילו התוכן. זה מאפשר ניתוב חכם - למשל, כל בקשה ל-/api/images הולכת לקבוצת שרתים שמותאמת לעיבוד תמונות, וכל בקשה ל-/api/checkout הולכת לקבוצה אחרת. זה גמיש יותר אבל גם יקר יותר מבחינת ביצועים כי צריך לפענח את הבקשה.

בדיקות תקינות - מה קורה כששרת נופל

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

זה בדיוק מה שנותן למערכות מבוזרות את היכולת "לספוג" נפילה של שרת בודד בלי שהמשתמשים בכלל ירגישו.

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

חשוב להבין שאיזון עומס לא קורה רק בכניסה למערכת. במערכות גדולות, יש לרוב איזון עומס בכמה שכבות - בין הלקוחות לשרתי הווב, בין שרתי הווב לשירותים הפנימיים, ולפעמים אפילו בגישה למסד הנתונים כשיש לו כמה עותקים לקריאה (read replicas). זה לא רכיב בודד, זו תבנית שחוזרת בכל מקום שיש בו יותר מעותק אחד של משהו.

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

יש לכם שאלה על איזה אלגוריתם מתאים למקרה שלכם? בואו לדבר על זה בדיסקורד.

לסיכום

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