איך מתמודדים עם עומס על השרת(ים) כיום? אחת התשובות- Load Balancer.
הרעיון של Load Balancer בעצם נהפך להכרח אצל הרבה חברות עקב הפריצה הענקית של המשתמשים באינטרנט. פעם עוד היה אפשר להרים את המחשב של אמא בתור שרת בסיסי בסלון כמו צוקרברג, אבל מהר מאוד זה הפסיק להיות לו כפתרון לגיטימי. בכלל, כיום אתרים ואפליקציות מתמודדות עם ריבוי בקשות עצום. הפתרון, נמצא איפשהוא בין שני סוגים של scaling לפניות.
הראשון: vertical scaling, שהוא אומר; שדרג את המכונה(שרת). תוסיף עוד RAM, תחליף ל- AMD RYZEN ותרביץ מכונה שתצליח לעמוד בריבוי הפניות. הבעיה הגדולה ביותר של זה היא שיש גבול עליון של כוח מחשובי שאפשר להגיע אליו יחסית מהר והגבול הזה גם ככה לא מספיק (לשרתים שמתקשים לעמוד בעומס).
השני: horizontal scaling, שהוא אומר; שכפל את השרתים כך שיש ריבוי מכונות כדי שכולם יוכלו להתחלק עם הריבוי משתמשים\בקשות.
הבעיה שנוצרה מ- horizontal scaling היא; איך לחלק את העבודה בין המכונות?, כלומר איך להחליט לאיזה שרת להפנות בקשה מסוימת. איך יודעים מתי שרת א’ פנוי ושרת ב’ לא פנוי?
אז הרעיון של Load Balancer נועד לפתור בין היתר את הבעיות הנ"ל. Load Balancer בסיסי הוא כמו ראוטר, המפנה את הבקשות אל המכונות הרלוונטיים. בדר"כ זה יהיה שרת שמתפקד כמו reverse proxy (או כ). הוא יושב בתקשורת באמצע של הקליינט והשרת (או חוות שרתים).
יש שני סוגים של Load Balancers פופולריים, L4 ו- L7. אז L4 מתייחס לכך שיש לו גישה רק לפורטים וה-IPים של הבקשה, ו7L מתייחס לכך שיש לו גישה לכל המידע בבקשת http (כמו body, routes, headers).
זה אומר ש- 4L יכול לבצע את הלוגיקה של הניתוב רק בעזרת הפורטים וה-IPים של הבקשה. ה-4L מתרגם את התקשורת TCP ומחליף את ה-IP שלו עצמו (הנמען של הבקשה מהקליינט) עם ה-IP של השרת שהוא מחליט לנתב אליו את הבקשה. זה נקרא NAT – Network Address Translation.
ל-L7 יש גישה למידע של הבקשה ולכן הוא יכול לבצע יותר לוגיקה בהתאם למידע. לדוגמה, להחזיר 401 כשה- authorization header של הבקשה ריק או לא תקין. L7 יודע גם לנתב בהתאם ל-routes, למשל ב- GET /images הוא ינתב לשרת הרלוונטי שמחזיר תמונות.
ל- L7 יש 2 תקשורות TCP, אחת של הקליינט, ואחת שהוא מייצר עם השרת המנותב. הסיבות ליצירת התקשורת השנייה היא למשל בשינוי המידע בפניה, ואז העברת המידע החדש עם התקשורת החדשה. בנוסף, הרבה פעמים L7 מיושם גם כ- SSL Termination Gateway (פיענוח של המידע המוצפן) במקום שהשרתים יצטרכו להיות up to date עם התעודות SSL שלהן. 7L הוא reverse proxy קלאסי עם יכולות ניתוב.
יש גם כמובן Internal Load Balancers (בשפה של AWS) שהם חבויים ולא ניתנים לגישה פומבית, אלא נמצאים בתוך רשת פרטית ומנהלים שם את הinfrastructure. דוגמה לכך היא ה- Docker Swarm שמנתב ומנהל את הסרביסים\שרתים שנמצאים בתוך השרת הפרטי.
יש סוגים שונים של לוגיקה לכל Load Balancer שבעזרתו הוא מנתב את הבקשות לשרתים השונים, והלוגיקה תלויה בצרכים של האתר\אפליקציה. ישנם אלגוריתמים כמו round robin, שהוא כמו לחלק קלפים לאנשים לפי הסדר; הבקשה מנותבת לשרת הראשון, אח"כ לשני, שלישי עד אחרון השרתים- ואז חוזר חלילה לשרת הראשון.
עוד אלגוריתם נקרא Weighted Response Time, אלגוריתם שמחשב מי השרת שמגיב הכי מהר- ואליו תנותב הבקשה. החישוב מתבצע בעזרת health checks שה- load balancer שולח בקשות מידי פעם ובודק את התקינות והמהירות תגובה של השרתים.
אלגוריתם נוסף הוא Source IP Hash, שזה אלגוריתם בו ה-IP של הקליינט וה-IP של השרת אליה נשלחה הבקשה נתפרים יחד להאש (מפתח ייחודי), כך שיהיה אפשר לדעת בדיוק לאיזה שרת הקליינט ניגש בבקשה הקודמת, במידה והבקשה\התקשורת נפגעה, או שיש לקליינט צורך ממשי להגיע לאותו שרת ספציפי. דוגמה לכך היא במקרים בהם הקליינט צריך גישה ל-session ספציפי, בשרת ספציפי.
ישנם מקרים בהם יש עומס של פעילות ביום וירידה חדה של פעילות בלילה. במקרים כאלה, יש צורך בלהעלות\להוריד שרתים בהתאם לעומס הבקשות בזמן אמת. רוב העננים מאפשרים את היכולות הללו, בעזרת שכפול ה-image של השרתים כך שכל השרתים יהיו זהים ומתחילים לבצע סקיילינג אוטומטי של השרתים. ב- AWS זה נקרא Auto Scaling, ובאז’ור זה נקרא Scaling Set.
על פניו load balancer נראה מסובך, אבל הביצוע עצמו הוא דיי straight forward. רוב העננים מאפשרים להרים אחד כזה בכמה קליקים מבלי לעשות עמידת ידיים. גם הקונפיגורציה והלוגיקה של הניתוב לא מסובכים כשמבינים על פני השטח איך הדברים עובדים (או צריכים לעבוד).
באז’ור למשל, צריך לעשות את הדברים הבאים:
-להגדיר רשת פרטית לשרתים ול- load balancer
-להגדיר שרתים שאליהם אנחנו רוצים לנתב
-להרים שרת load balancer (דרך אז’ור) בכמה קליקים
-להגדיר לו הגדרות כמו health checks, ssl, routing
-ליצור “Backend Pool” – בעצם לקשר את השרתים שלנו עם הבאלאנסר
- יש load balancer עובד!