בדף הזה מוסבר על השיטות המומלצות לבדיקת עומס של שירות Cloud Run, כדי לקבוע אם הוא יתאים את עצמו לעומס בהצלחה במהלך השימוש בייצור, וכדי למצוא צווארי בקבוק שמונעים ממנו להתאים את עצמו לעומס.
בדיקות שצריך להריץ לפני בדיקות עומס
לזהות ולפתור בעיות של בו-זמניות (concurrency) בסביבת פיתוח או בסביבת בדיקה קטנה לפני שממשיכים לבדיקת עומסים. מומלץ למדוד את בו-זמניות הקונטיינר לפני שמבצעים בדיקת עומס, ולוודא ששירות Cloud Run מתחיל לפעול בצורה מהימנה.
מומלץ להתמקד בבדיקות של מאגרי תגים עם מספרים מצטברים קטנים בהפעלות שמתבצעות באופן ידני. אפשר להגדיר קנה מידה ידני ב-Cloud Run על ידי הגדרת maximum instances (מספר האינסטנסים המקסימלי) לערך שרוצים להגדיל את קנה המידה שלו.
אם יצרתם לאחרונה את קובץ האימג' של הקונטיינר או שיניתם אותו לאחרונה, כדאי לבדוק אותו בנפרד לפני שמבצעים בדיקת עומס.
כמו כן, לפני שמריצים בדיקת עומס בקנה מידה גדול, כדאי לבדוק בעיות אחרות בביצועים, כמו זמן אחזור מוגזם ושימוש ב-CPU.
שימוש ב-max instances בצורה הולמת
ב-Cloud Run יש מכסת מופעים כדי להגביל את קנה המידה של שירות. מספר ברירת המחדל של המכונות המקסימלי הוא 100. אם אתם צופים שבדיקת העומס תחרוג ממגבלת ברירת המחדל הזו, חשוב שתפנו לצוות ניהול החשבון שלכם ב-Google ותגדירו מגבלה חדשה. אם עדיין אין לכם קשר עם צוות תמיכה בחשבונות, פנו Google Cloud למחלקת המכירות.
מספר המופעים המקסימלי שאפשר לבחור תלוי במגבלות המעבד ובמגבלות הזיכרון, וגם באזור שבו אתם מבצעים את הפריסה.
המגבלות האלה מנוהלות על ידי מכסה, ואפשר להגדיל אותן באמצעות בקשה להגדלת המכסה.
בדיקת טעינה באזור europe-west1
באזור Google Cloud יש מכסת שימוש גבוהה, ולכן Google ממליצה לבצע בדיקות עומס ב-europe-west1.europe-west1
אם אתם צפויים להתקרב למגבלות המכסה, עליכם לתאם עם צוות ניהול החשבון ולשלוח בקשת תמיכה עם פרטים על הזמן וההיקף של הבדיקה.
בדיקת פרופיל מתאים של ניצול יחידת העיבוד המרכזית (CPU) ואתחול השירות
בתרחיש אידיאלי, אתם פורסים גרסת בדיקה של השירות ב-Cloud Run ומבצעים בדיקת עומס ישירות. עם זאת, במקרים מסוימים, יכול להיות שלא תוכלו לפרוס גרסת בדיקה של השירות. לדוגמה, שירות Cloud Run שלכם עשוי להיות חלק ממערכת אקולוגית מורכבת שקשה לשכפל בסביבת בדיקה.
במקרים כאלה, אפשר להעריך את הביצועים של השירות על ידי סימולציה שלו עם שירות פשוט יותר שצורך כמות דומה של CPU וזמני אתחול דומים.
זמן האתחול חשוב במיוחד לצורך הרחבה מהירה. חשוב לזכור שגם בדיקה עם משהו פשוט מדי היא בעייתית. לדוגמה, אל תבדקו באמצעות שירות hello world פשוט שמחזיר בקשות שהתקבלו בלי לבצע עיבוד.
שימוש ב-test harness ליצירת עומסים
אפשר ליצור עומסי בדיקה שגורמים לעלייה מבוקרת בתנועה באמצעות כלי בדיקה, כמו JMeter. כדי להגדיל את העומס, אפשר להשתמש במספר קבוצות השרשורים של JMeter ובזמן ההשהיה בין הבקשות בבדיקת JMeter.
אפשר גם לשלוח בקשות HTTP פשוטות או להקליט סשן בדפדפן באמצעות JMeter. בעזרת אימות מפתחים אפשר לבדוק את השירות ב-Cloud Run בלי גישה לאינטרנט. כך אפשר לגשת אליהם ממערכת בדיקה כמו JMeter, שפועלת במכונה וירטואלית של Compute Engine שמחוברת לענן וירטואלי פרטי (VPC) שמשויך לפרויקט.
אל תיצרו עומס מכלים שבהם אי אפשר לשלוט בקצב ובבו-זמניות (concurrency). 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 ו-Matplotlib. בנוסף, Colab משתלב בקלות עם כלים עשירים להמחשת נתונים כמו Seaborn.
איתור צווארי בקבוק
בדיקות עומס יכולות לעזור לכם לגלות קוד לא יעיל וצווארי בקבוק שמונעים את הרחבת המערכת. קוד לא יעיל מוביל לעלויות גבוהות יותר כי הוא צריך לטפל ביותר תנועה, אבל הוא לא בהכרח מונע שינוי גודל. לדוגמה, תלות בתרגום של מסד נתונים עם נעילה ברמת הטבלה יכולה להיות צוואר בקבוק שימנע את שינוי קנה המידה של שירות Cloud Run, כי אפשר לבצע רק טרנזקציה אחת בכל פעם.
בדיקת הביצועים כפי שהם נחווים על ידי הלקוח
אפשר לשלוח שאילתות ליומנים שמתועדים על ידי JMeter, שכוללים את זמני האחזור שנמדדו בלקוח. עם זאת, כדאי להריץ גם בדיקה באמצעות מסגרת מבוססת-דפדפן, כמו Selenium Webdriver, או מסגרת לבדיקת לקוח לנייד, כי כלים לבדיקת שרתים כמו JMeter לא זהים לדפדפן או ללקוח לנייד. צריך להיזהר מזמני חביון מקסימליים מוגזמים בגלל אתחול חיבור TLS, כי הם עלולים לעוות את התוצאות עם ערכים חריגים.
סיכום של השיטות המומלצות
מבצעים בדיקת עומס כדי לקבוע אם המעבר ל-Cloud Run הוא הבחירה הנכונה, ושהשירות יכול להתרחב כדי להתמודד עם התנועה המקסימלית הצפויה. מריצים את הבדיקה באמצעות כלי כמו JMeter. לייצא את היומנים ל-BigQuery לניתוח מפורט.