אופטימיזציה של זמן האחזור של האפליקציה באמצעות איזון עומסים

במאמר הזה נסביר על אפשרויות לאיזון עומסים ונראה איך הבחירה של מאזן עומסים ספציפי ב- Google Cloudמשפיעה על זמן האחזור מקצה לקצה.

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

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

אפשרות תיאור זרימת תנועה היקף
מאזן עומסים חיצוני של אפליקציות (ALB) תומך בתנועת HTTP(S) ובתכונות מתקדמות, כמו מיפוי כתובות URL ופריקת SSL
משתמשים במאזן עומסי רשת בשרת proxy חיצוני לתנועה שאינה HTTP ביציאות ספציפיות. 		סשן ה-TCP או ה-SSL (TLS) מסתיים בממשקי הקצה של Google‏ (GFE), בקצה הרשת של Google, ותעבורת הנתונים מועברת דרך שרת proxy לשרתי הבק-אנד. עולמי
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי מאפשרת לתעבורת TCP/UDP לעבור דרך מאזן העומסים באמצעות כל יציאה. התכונה מופעלת באמצעות טכנולוגיית Maglev של Google כדי להפיץ את התנועה אל השרתים העורפיים. אזורי

מאזני עומסים פנימיים ו-Cloud Service Mesh לא תומכים בתעבורה שפונה למשתמשים, ולכן הם לא נכללים במאמר הזה.

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

מדידת זמן האחזור

כשמשתמש בגרמניה ניגש לאתר שמארח בus-central1, הוא יכול להשתמש בשיטות הבאות כדי לבדוק את זמן האחזור:

כשמשווים תוצאות, חשוב לזכור שזמן האחזור בקישורי סיבים אופטיים מוגבל על ידי המרחק ומהירות האור בסיבים, שהיא בערך 200,000 ק"מ לשנייה (או 124,724 מיילים לשנייה).

המרחק בין פרנקפורט, גרמניה לבין קאונסיל בלאפס, איווה (אזור us-central1), הוא בערך 7,500 ק"מ. עם סיבים אופטיים ישירים בין המיקומים, זמן האחזור הלוך ושוב הוא:

7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)

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

השוואת זמני האחזור

בקטע הזה מוצגת השוואה בין איזון עומסים בהגדרות הבאות:

  • ללא איזון עומסים
  • מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי
  • מאזן עומסים חיצוני של אפליקציות (ALB) או מאזן עומסי רשת חיצוני בשרת proxy

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

‫ תרחיש זמן האחזור.
תרחיש של זמן אחזור (לחצו כדי להגדיל).

ללא איזון עומסים

כשמשתמש שולח בקשת HTTP, אלא אם הוגדר איזון עומסים, התנועה זורמת ישירות מהרשת של המשתמש אל המכונה הווירטואלית (VM) שמתארחת ב-Compute Engine. במסלול פרימיום, תעבורת הנתונים נכנסת לרשת של Google בנקודת קצה PoP שקרובה למיקום של המשתמש. במסלול הרגיל, תעבורת המשתמשים נכנסת לרשת של Google בנקודת PoP שקרובה לאזור היעד. מידע נוסף זמין במאמר בנושא מסלולי שירות רשת.

‫ ארכיטקטורה ללא איזון עומסים.
ארכיטקטורה ללא איזון עומסים (לחצו כדי להגדיל).

בטבלה הבאה מוצגות התוצאות כשמשתמש בגרמניה בדק את זמן האחזור של מערכת ללא איזון עומסים:

‏Method תוצאה זמן אחזור מינימלי
שולחים פינג לכתובת ה-IP של המכונה הווירטואלית (התגובה מגיעה ישירות משרת האינטרנט) 
  ping -c 5 compute-engine-vm
  
  PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
  [...]
  --- compute-engine-vm ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms
‫110 אלפיות השנייה
TTFB 
  for ((i=0; i < 500; i++)); do curl -w  /
  "%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
  
  0.230
  0.230
  0.231
  0.231
  0.230
  [...]
  0.232
  0.231
  0.231
‫230 אלפיות השנייה

זמן האחזור של TTFB יציב, כפי שמוצג בתרשים הבא של 500 הבקשות הראשונות:

‫ תרשים של זמן האחזור ל-VM באלפיות השנייה.
זמן האחזור למכונה וירטואלית בגרף אלפיות השנייה (לחצו כדי להגדיל).

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

בקשת HTTP של לקוח/שרת.
בקשת HTTP של לקוח/שרת (לחצו כדי להגדיל).

מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי

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

‫ ארכיטקטורה עם מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.
ארכיטקטורה עם מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי (לחצו כדי להגדיל).

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

‏Method תוצאה זמן אחזור מינימלי
שולחים פינג למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי 
  ping -c 5 net-lb
  
  PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms
  [...]
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms
  --- net-lb ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4007ms
  rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms
‫110 אלפיות השנייה
TTFB 
 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s net-lb
 
 0.231
 0.232
 0.230
 0.230
 0.232
 [...]
 0.232
 0.231
‫230 אלפיות השנייה

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

איזון עומסים חיצוני

במאזני עומסים חיצוניים של אפליקציות (ALB), שרתי GFE משמשים כשרתי proxy לתנועה. ה-GFE האלה נמצאים בקצה של הרשת הגלובלית של Google. ‫GFE מסיים את סשן ה-TCP ומתחבר לחלק האחורי באזור הקרוב ביותר שיכול לשרת את התנועה.

‫ תרחיש של מאזן עומסים חיצוני של אפליקציות (ALB).
תרחיש לדוגמה של מאזן עומסים של אפליקציות (ALB) חיצוני (לחצו כדי להגדיל).

בטבלה הבאה מוצגות התוצאות כשמשתמש בגרמניה בדק את זמן האחזור של האפשרות HTTP-load-balancing.

‏Method תוצאה זמן אחזור מינימלי
שליחת פינג למאזן עומסים חיצוני של אפליקציות (ALB) 
 ping -c 5 http-lb
 
 PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms
 --- http-lb ping statistics ---
 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
 rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms
אלפית שנייה
TTFB 
 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s http-lb; done
 
 0.309
 0.230
 0.229
 0.233
 0.230
 [...]
 0.123
 0.124
 0.126
‫123 אלפיות השנייה

התוצאות עבור מאזן העומסים החיצוני של האפליקציות שונות באופן משמעותי. כשמבצעים פינג למאזן העומסים החיצוני של אפליקציות, זמן האחזור הלוך ושוב הוא קצת יותר מ-1 אלפית השנייה. התוצאה הזו מייצגת את זמן האחזור ל-GFE הקרוב ביותר, שנמצא באותה עיר שבה נמצא המשתמש. התוצאה הזו לא משקפת את זמן האחזור בפועל שהמשתמש חווה כשהוא מנסה לגשת לאפליקציה שמתארחת באזור us-central1. ניסויים שמשתמשים בפרוטוקולים (ICMP) ששונים מפרוטוקול התקשורת של האפליקציה (HTTP) עלולים להטעות.

כשמודדים את TTFB, הבקשות הראשוניות מציגות זמן אחזור דומה של התגובה. חלק מהבקשות משיגות את זמן האחזור המינימלי הנמוך יותר של 123 אלפיות השנייה, כפי שמוצג בתרשים הבא:

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

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

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

‫ בקשת HTTP שנצפתה לראשונה לעומת בקשת HTTP שנצפתה בפעם הבאה דרך GFE.
ההבדל בין בקשת HTTP שנצפתה לראשונה לבין בקשת HTTP שנצפתה בהמשך דרך GFE (לחצו כדי להגדיל).

התרחישים האלה מדגימים את זמן האחזור המופחת שהמשתמשים יכולים לחוות בסביבת ייצור. הטבלה הבאה מסכמת את התוצאות:

אפשרות פינג TTFB
ללא איזון עומסים ‫110 אלפיות השנייה לשרת האינטרנט ‫230 אלפיות השנייה
מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי ‫110 אלפיות השנייה למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי באזור ‫230 אלפיות השנייה
מאזן עומסים חיצוני של אפליקציות (ALB) ‫1 ms to the closest GFE ‫123 אלפיות השנייה

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

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

השפעות נוספות של זמן האחזור במאזן עומסים חיצוני של אפליקציות (ALB)

השפעות נוספות שניתן לראות במאזן עומסים חיצוני של אפליקציות (ALB) תלויות בדפוסי התנועה.

  • למאזן עומסים חיצוני של אפליקציות (ALB) יש חביון נמוך יותר עבור נכסים מורכבים בהשוואה למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי, כי נדרשים פחות סיבובי שליחה וקבלה לפני שהתגובה מסתיימת. לדוגמה, כשמשתמש בגרמניה מודד את זמן האחזור באותו חיבור על ידי הורדה חוזרת של קובץ בגודל 10MB, זמן האחזור הממוצע של מאזן עומסי רשת חיצוני הוא 1,911ms. זמן האחזור הממוצע של מאזן עומסים של אפליקציות (ALB) חיצוני הוא 1,341ms. כך נחסכים בערך 5 סיבובי שליחה וקבלה לכל בקשה. חיבורים קבועים בין ממשקי קצה של Google לבין שרתים עורפיים שמציגים תוכן מצמצמים את ההשפעות של התחלה איטית של TCP.

  • מאזן העומסים החיצוני של אפליקציות (ALB) מפחית באופן משמעותי את זמן האחזור הנוסף של לחיצת היד של TLS (בדרך כלל 1-2 הלוך ושוב נוספים). הסיבה לכך היא שמאזן העומסים של אפליקציות (ALB) החיצוני משתמש בפריקת SSL, ורק זמן האחזור לנקודת הנוכחות (PoP) בקצה רלוונטי. עבור המשתמש בגרמניה, זמן האחזור המינימלי שנמדד הוא 201ms באמצעות מאזן עומסים חיצוני של אפליקציות (ALB), לעומת 525ms באמצעות HTTP(S) דרך מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.

  • מאזן העומסים החיצוני של אפליקציות (ALB) מאפשר שדרוג אוטומטי של הסשן שגלוי למשתמש ל-HTTP/2. פרוטוקול HTTP/2 יכול לצמצם את מספר החבילות שנדרשות, באמצעות שיפורים בפרוטוקול הבינארי, בדחיסת הכותרות ובריבוב החיבורים. השיפורים האלה יכולים להפחית את זמן האחזור שנמדד אפילו יותר מזמן האחזור שנמדד כשעוברים ל-Application Load Balancer חיצוני. יש תמיכה ב-HTTP/2 בדפדפנים עדכניים שמשתמשים ב-SSL/TLS. במקרה של המשתמש בגרמניה, זמן האחזור המינימלי ירד עוד יותר מ-201 מילי-שניות ל-145 מילי-שניות כשנעשה שימוש ב-HTTP/2 במקום ב-HTTPS.

אופטימיזציה של מאזני עומסים חיצוניים של אפליקציות (ALB)

כדי לשפר את זמן האחזור של האפליקציה, אפשר להשתמש במאזן עומסים חיצוני של אפליקציות (ALB) באופן הבא:

  • אם חלק מהתנועה שאתם משרתים ניתנת לשמירה במטמון, אתם יכולים לשלב עם Cloud CDN. שירות Cloud CDN מפחית את זמן האחזור על ידי הצגת נכסים ישירות בקצה הרשת של Google. בנוסף, Cloud CDN משתמש באופטימיזציות של TCP ו-HTTP מ-HTTP/2 שמוזכרות בקטע השפעות נוספות של זמן האחזור במאזן עומסים חיצוני של אפליקציות (ALB).

  • אפשר להשתמש בכל שותף CDN עם Google Cloud. אם משתמשים באחד משותפי CDN Interconnect של Google, נהנים מהנחות על עלויות העברת נתונים.

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

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

  • כדי להקטין את זמן האחזור באפליקציות, כדאי לבדוק קריאות לשירות מרוחק (RPC) שמתקשרות בין מכונות וירטואליות. ההשהיה הזו מתרחשת בדרך כלל כשאפליקציות מתקשרות בין רמות או שירותים. כלים כמו Cloud Trace יכולים לעזור לכם לצמצם את זמן האחזור שנגרם כתוצאה מבקשות להצגת אפליקציות.

  • מאזני עומסים חיצוניים של רשת בשרת proxy מבוססים על GFE, ולכן ההשפעה על זמן האחזור זהה להשפעה שנצפית במאזן עומסים חיצוני של אפליקציות (ALB). מאחר שלמאזן עומסים חיצוני של אפליקציות (ALB) יש יותר תכונות מאשר למאזן עומסי רשת חיצוני לשרת proxy, מומלץ להשתמש במאזני עומסים חיצוניים של אפליקציות (ALB) לתנועת HTTP(S).

השלבים הבאים

מומלץ לפרוס את האפליקציה קרוב לרוב המשתמשים. מידע נוסף על אפשרויות שונות של איזון עומסים ב-Google Cloudזמין במסמכים הבאים: