בדיקות עומס של שירות Cloud Run יכולות לעזור לכם להחליט אם כשהעומס על המערכת יגדל היא תעמוד בזה. בדיקות עומס גם מאפשרות לכם לזהות צווארי בקבוק שמונעים מהשירות שלכם לגדול.
בדיקות שצריך להריץ לפני בדיקת העומס
לזהות בעיות בו-זמניות בסביבת פיתוח או בסביבת בדיקה קטנה ולטפל בהן, לפני שממשיכים לבדיקת עומסים. לפני שמבצעים בדיקת עומס, מודדים את בו-זמניות הקונטיינר ומוודאים ששירות Cloud Run מופעל באופן מהימן.
כדאי להתמקד בבדיקות של קונטיינרים עם מספרים מצטברים קטנים בהפעלות עם התאמה ידנית לעומס. כדי לבצע התאמה ידנית של קנה המידה ב-Cloud Run, אפשר להגדיר את מספר המכונות המקסימלי לערך שאליו רוצים להתאים את קנה המידה.
אם רק לאחרונה יצרתם את קובץ האימג' של הקונטיינר או שיניתם אותו, בדקו אותו בנפרד לפני שתבצעו בדיקת עומסים.
לפני שמריצים בדיקת עומס בקנה מידה גדול, כדאי לבדוק גם סוגים אחרים של בעיות בביצועים, כמו זמן אחזור ארוך מדי וניצול יתר של המעבד (CPU).
שימוש נכון ב-max instances
ב-Cloud Run נאכף מספר מקסימלי של מכונות כדי להגביל את ההתאמה לעומס (scaling) של שירות. מספר המכונות המקסימלי שמוגדר כברירת מחדל הוא 100. אם אתם צופים שבדיקת העומס תחרוג מברירת המחדל הזו, הקפידו לעבוד עם צוות ניהול החשבון שלכם ב-Google ולהגדיר מקסימום חדש. אם עדיין אין לכם קשר עם צוות ניהול החשבון, פנו Google Cloud למחלקת המכירות.
מספר המכונות המקסימלי שאפשר לבחור תלוי במגבלות המעבד (CPU), במגבלות הזיכרון ובאזור שבו אתם פורסים.
המגבלות האלה מנוהלות על ידי מכסה, ואפשר להגדיל אותן באמצעות בקשה להגדלת המכסה.
בדיקת עומס באזור europe-west1
באזור Google Cloud europe-west1 יש מגבלת מכסה גבוהה, ולכן Google ממליצה לבצע בדיקות עומסים ב-europe-west1.
אם אתם צופים שתתקרבו למגבלות המכסה, תאמו עם צוות ניהול החשבון ושלחו בקשת תמיכה עם פרטים על זמן הבדיקה והיקף הבדיקה.
בדיקת פרופיל מתאים של ניצול המעבד (CPU) ואתחול השירות
בתרחיש אידיאלי, פורסים גרסת בדיקה של השירות ב-Cloud Run ומבצעים בדיקת עומסים ישירות. עם זאת, במקרים מסוימים לא תוכלו לפרוס גרסת בדיקה של השירות. לדוגמה, יכול להיות שהשירות שלכם ב-Cloud Run הוא חלק מסביבה מורכבת שקשה לשכפל בסביבת בדיקה.
במקרים כאלה, אפשר להעריך את הביצועים של השירות באמצעות סימולציה עם שירות פשוט יותר, שבו השימוש ב-CPU וזמני האתחול דומים.
זמן האתחול חשוב במיוחד להרחבה מהירה. חשוב לזכור שגם בדיקה עם משהו פשוט מדי היא בעייתית. לדוגמה, אל תבצעו בדיקה באמצעות שירות hello world פשוט שמחזיר את הבקשות שהתקבלו בלי לעבד אותן.
שימוש במסגרת בדיקה כדי ליצור עומסים
אתם יכולים ליצור עומסי בדיקה שגורמים לעלייה חדה מבוקרת בתנועה באמצעות מסגרת בדיקה, כמו JMeter. כדי להגדיל את העומס, אתם יכולים להשתמש במספר קבוצות השרשורים של JMeter ובהשהיה בין הבקשות בבדיקת JMeter.
אפשר גם לשלוח בקשות HTTP פשוטות או להקליט סשן בדפדפן באמצעות JMeter. בעזרת אימות למפתחים, אתם יכולים לבדוק את השירות ב-Cloud Run בלי גישה לאינטרנט. כך אפשר לגשת ממסגרת בדיקה כמו JMeter, שפועלת במכונה וירטואלית של Compute Engine שמחוברת לענן וירטואלי פרטי (VPC) שמשויך לפרויקט.
אל תייצרו עומס באמצעות כלים שבהם אי אפשר לשלוט בקצב ובמקביליות. Pub/Sub הוא כלי לא מתאים ליצירת עומס, כי אי אפשר לשלוט בקצב התנועה ובמספר הלקוחות. אם אתם לא יודעים מהו קצב הבקשות ומהי כמות הבקשות בו-זמנית, לא תדעו מה אתם בודקים.
ניתוח מפורט של יומנים שיוצאו
אתם צריכים ניתוח של אירועים לפי שנייה כדי להבין את התגובה של שירות Cloud Run לעליות חדות ומהירות בתנועה. כדי לעשות את זה צריך ניתוח נתוני יומן, כי רמת הפירוט של נתוני המעקב לא מספיק גבוהה. ניתוח נתוני יומן מאפשר גם לחקור את הסיבות לבקשות עם זמן אחזור גבוה.
כשכותבים יומנים, אפשר לשפר את הביצועים של הרישום ביומן אם כותבים ישירות ל-stdout במקום להשתמש בספריית לקוח של Cloud Logging.
כדי להגדיר ייצוא של יומנים לפני שמתחילים את הבדיקה, יוצרים sink ביומן עם היעד BigQuery ומסנן הכללה, למשל:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
הימנעות מהפעלות במצב התחלתי (cold start) מזויפות
כדי לצמצם את מספר ההפעלות במצב התחלתי (cold start) שהמשתמשים חווים, צריך להגדיר מספר מינימלי של מכונות, לפחות 1.
מוודאים שהשירות מתרחב אופקית באופן לינארי
חזרו על הבדיקה בעומסים שונים כדי לוודא שהשירות של Cloud Run מתרחב אופקית באופן לינארי עם העומס, ולא מגיע לצוואר בקבוק מגביל בעומס נמוך מהצפוי בסביבת הייצור.
ניתוח התוצאות והצגה חזותית שלהן ב-Colaboratory
אפשר להשתמש בתרשימי המעקב המסכמים כדי לקבל הבנה ברמה גבוהה של התוצאות, בנוסף לניתוח המפורט של היומנים באמצעות יומנים שיוצאו.
תרשימי המעקב יכולים לעזור לכם לגלות:
- מה משך הזמן, בשניות, שבו נוצרים מארחים חדשים ומתבצעת להם אתחול?
- עד כמה הבקשות מפוזרות באופן שווה בין המכונות השונות?
- תוך כמה זמן אפשר להוריד את זמן האחזור באחוזונים שונים לערך של מצב יציב?
אתם יכולים להשתמש בממשק המשתמש של מסוף Google Cloud ל-BigQuery כדי לבחון את סכימת היומנים שיוצאו ולראות את התוצאות בתצוגה מקדימה. מריצים את השאילתות ומשרטטים את התוצאות באמצעות Colab, שמשולב עם BigQuery, Pandas ו-Matplotlab. בנוסף, Colab משתלב בקלות עם כלים עשירים להמחשה חזותית של נתונים, כמו Seaborn.
חיפוש צווארי בקבוק
בדיקות עומס יכולות לעזור לכם לגלות אם יש קוד לא יעיל וצווארי בקבוק שעלולים ליצור בעיות כשהעומס על המערכת יגדל. קוד לא יעיל מוביל לעלויות גבוהות יותר כי הוא צריך לטפל ביותר תנועה, אבל לא בהכרח מונע התרחבות. לדוגמה, תלות בתרגום מסד נתונים עם נעילה ברמת הטבלה יכולה להיות צוואר בקבוק שימנע את ההתאמה לעומס של שירות Cloud Run, כי אפשר לבצע רק טרנזקציה אחת בכל פעם.
בדיקת הביצועים כפי שהם נחווים על ידי הלקוח
אתם יכולים לשלוח שאילתות ליומנים שנוצרו על ידי JMeter, שבהם היומנים כוללים זמני אחזור שנמדדו אצל הלקוח. עם זאת, מכיוון שכלי בדיקה של שרתים כמו JMeter לא זהים לדפדפן או ללקוח בנייד, יכול להיות שתרצו גם להריץ בדיקה עם מסגרת מבוססת-דפדפן, כמו Selenium Webdriver, או מסגרת בדיקה של לקוח בנייד. חשוב להיזהר מזמני אחזור מקסימליים ארוכים מדי שנובעים מההפעלה של חיבור ה-TLS, כי הם עלולים להטות את התוצאות עם ערכים חריגים.
סיכום השיטות המומלצות
כדי להחליט אם כדאי לעבור ל-Cloud Run, ולוודא שהשירות יכול להתאים את עצמו לנפח התנועה המקסימלי הצפוי, כדאי לבצע בדיקת עומס. מריצים את הבדיקה עם כלי כמו JMeter. לייצא את היומנים ל-BigQuery כדי לנתח אותם לעומק.