מופעים הם אבני הבניין הבסיסיות של App Engine, והם מספקים את כל המשאבים שנדרשים כדי לארח את האפליקציה בהצלחה. בכל רגע נתון, האפליקציה שלכם יכולה לפעול במופע אחד או בכמה מופעים, והבקשות מתחלקות בין כל המופעים. כל מופע כולל שכבת אבטחה כדי להבטיח שמופעים לא ישפיעו אחד על השני בטעות.
App Engine יכול ליצור מכונות ולהפסיק את הפעולה שלהן באופן אוטומטי כשיש שינויים בתעבורה, או שאתם יכולים לציין מספר מכונות להפעלה בלי קשר לכמות התעבורה. כדי לקבוע איך ומתי נוצרים מופעים חדשים, צריך לציין סוג של שינוי גודל לאפליקציה. הגדרות שינוי הגודל מוחלות ברמת הגרסה של App Engine כחלק מקובץ app.yaml.
סוגי התאמה להיקף
App Engine תומך בסוגי הסקיילינג הבאים, שקובעים איך ומתי נוצרים מופעים:
- אוטומטי (ברירת מחדל)
- בסיסי
- גלילה ידנית
אתם מציינים את סוג ההתאמה לגודל בקובץ app.yaml של האפליקציה.
כברירת מחדל, האפליקציה משתמשת בהתאמה אוטומטית לעומס (automatic scaling), כלומר App Engine ינהל את מספר המכונות הווירטואליות במצב בלי פעילות.
- התאמה אוטומטית לעומס
- התאמה אוטומטית לעומס יוצרת מופעים על סמך קצב הבקשות, זמני האחזור של התגובות ומדדים אחרים של האפליקציה. אפשר לציין ערכי סף לכל אחד מהמדדים האלה, וגם מספר מינימלי של מופעים שימשיכו לפעול בכל רגע נתון, על ידי הגדרת הרכיב
automatic_scaling.
- הרחבה בסיסית
- בשינוי גודל בסיסי נוצרים מופעים כשהאפליקציה מקבלת בקשות. כל מופע ייסגר כשהאפליקציה תהיה במצב בלי פעילות. התאמת קנה מידה בסיסית מתאימה במיוחד לעבודה לסירוגין או לעבודה שמבוססת על פעילות המשתמש.
- שינוי גודל ידני
- בשינוי גודל ידני מציינים את מספר המופעים שפועלים באופן רציף, ללא קשר לרמת העומס. כך אפשר לבצע משימות כמו הפעלות מורכבות ואפליקציות שמסתמכות על מצב הזיכרון לאורך זמן.
| תכונה | התאמה אוטומטית לעומס | שינוי גודל בסיסי | שינוי גודל ידני |
|---|---|---|---|
| זמן קצוב לתפוגה של בקשה | 10 דקות לבקשות HTTP ולמשימות בתור המשימות. אם האפליקציה לא מחזירה בקשה בתוך מגבלת הזמן הזו, App Engine מפסיק את הטיפול בבקשה ומפיק שגיאה שהקוד צריך לטפל בה. |
24 שעות לבקשות HTTP ולמשימות בתור המשימות. אם האפליקציה לא מחזירה בקשה במסגרת מגבלת הזמן הזו, App Engine מפסיק את הטיפול בבקשה ומפיק שגיאה כדי שהקוד יוכל לטפל בה.
מופע בסיסי עם קנה מידה יכול לבחור לטפל ב- |
זהה לשינוי גודל בסיסי. |
| שרשורים ברקע (Java בלבד) | אסור | מותר | מותר |
| מקום מגורים | המכונות מושבתות על סמך דפוסי השימוש. |
המקרים מושבתים על סמך הפרמטר idle_timeout. אם מכונה לא פעילה, למשל אם היא לא קיבלה בקשה במשך יותר מ-idle_timeout, המכונה מושבתת.
|
המופעים נשארים בזיכרון והמצב נשמר בין הבקשות. כשמופסקות דוגמאות, בקשת /_ah/stop מופיעה ביומנים. אם יש handler של /_ah/stop או shutdown hook רשום (Java, Python), יש לו 30 שניות להשלמה לפני שהכיבוי מתבצע.
|
| הפעלה וכיבוי | מופעים נוצרים לפי דרישה כדי לטפל בבקשות, ומושבתים באופן אוטומטי כשהם לא פעילים. |
המופעים נוצרים לפי דרישה כדי לטפל בבקשות, ומושבתים אוטומטית כשהם בלי פעילות, על סמך פרמטר ההגדרה idle_timeout. למופע שהופסק באופן ידני יש 30 שניות לסיים את הטיפול בבקשות לפני שהוא מופסק בכוח.
|
מערכת App Engine שולחת למופעים בקשת הפעלה באופן אוטומטי בצורה של בקשת GET ריקה אל /_ah/start. בדומה לשינוי גודל בסיסי, אם מפסיקים ידנית מכונה, יש לה 30 שניות לסיים את הטיפול בבקשות לפני שהיא מסתיימת בכוח.
|
| היכולת של מכונה לקבל כתובת | המופעים הם אנונימיים. |
אפשר לגשת למופע 'i' של גרסה 'v' של שירות 's' בכתובת ה-URL:
https://i-dot-v-dot-s-dot-app_id.REGION_ID.r.appspot.com.
אם הגדרתם
מיפוי של תת-דומיין עם תו כללי לדומיין בהתאמה אישית, תוכלו גם לפנות לשירות או לכל אחד מהמופעים שלו באמצעות כתובת URL מהצורה https://s.domain.com או https://i.s.domain.com.
אתם יכולים לשמור במטמון את המצב בכל מופע ולאחזר אותו בבקשות הבאות.
|
זהה לשינוי גודל בסיסי. |
| התאמה להיקף |
App Engine משנה את מספר המופעים באופן אוטומטי בתגובה לנפח העיבוד. ההתאמה הזו מתבססת על ההגדרות של automatic_scaling שמסופקות על בסיס כל גרסה בקובץ התצורה.
|
שירות עם קנה מידה בסיסי מוגדר על ידי הגדרת המספר המקסימלי של מופעים בפרמטר max_instances של ההגדרה basic_scaling. מספר המקרים הפעילים גדל בהתאם לנפח העיבוד.
|
אתם מגדירים את מספר המופעים של כל גרסה בקובץ התצורה של השירות. המספר הזה בדרך כלל תואם לגודל של מערך נתונים שמוחזק בזיכרון או לתפוקה הרצויה לעבודה אופליין. |
שינוי גודל של מופעים דינמיים
אפליקציות App Engine שמשתמשות בהתאמה בסיסית או התאמה אוטומטית לעומס מופעלות על ידי מספר כלשהו של מופעים דינמיים בכל זמן נתון, בהתאם לנפח הבקשות הנכנסות. ככל שמספר הבקשות לאפליקציה שלכם גדל, יכול להיות שגם מספר המופעים הדינמיים יגדל.
אפליקציות עם התאמה בסיסית לעומס
אם משתמשים בהתאמה בסיסית לעומס, App Engine מנסה לשמור על עלות נמוכה, גם אם זה עלול לגרום לזמן אחזור ארוך יותר ככל שנפח הבקשות הנכנסות גדל.
אם אף אחד מהמופעים הקיימים לא זמין להצגת בקשה נכנסת, מערכת App Engine מפעילה מופע חדש. גם אחרי שמתחילים מופע חדש, יכול להיות שחלק מהבקשות יתווספו לתור עד שתהליך ההפעלה של המופע החדש יסתיים. אם אתם צריכים את זמן האחזור הנמוך ביותר שאפשר, כדאי להשתמש בהתאמה אוטומטית לעומס (automatic scaling), שיוצרת מופעים חדשים מראש כדי למזער את זמן האחזור.
אפליקציות עם התאמה אוטומטית לעומס
אם משתמשים בהתאמה אוטומטית לעומס (automatic scaling), לכל מופע באפליקציה יש תור משלו לבקשות נכנסות. לפני שהתורים מתארכים מספיק כדי להשפיע באופן משמעותי על זמן האחזור של האפליקציה, App Engine יוצר באופן אוטומטי מופע חדש אחד או יותר כדי לטפל בעומס הגדל.
אתם יכולים להגדיר את ההגדרות של התאמה אוטומטית לעומס כדי להגיע לאיזון בין הביצועים הרצויים לבין העלות שאתם יכולים להרשות לעצמכם. הטבלה הבאה מתארת את ההגדרות האלה.
| הגדרות של התאמה אוטומטית לעומס | תיאור |
|---|---|
| יעד ניצול המעבד (CPU) | הגדרת סף יחס ניצול ה-CPU כדי לציין את סף השימוש ב-CPU שמעליו יופעלו עוד מופעים לטיפול בתנועה. |
| יעד ניצול תפוקה | הגדרה של סף התפוקה למספר הבקשות בו-זמנית, שאחריו יופעלו עוד מופעים כדי לטפל בתנועה. |
| מקסימום בקשות בו-זמניות | ההגדרה הזו קובעת את המספר המקסימלי של בקשות מקבילות שמופע יכול לקבל לפני שהמתזמן יוצר מופע חדש. |
כדי לראות את ההשפעות של ההגדרות האלה, אפשר לצפות בסרטון בנושא הגדרות של כלי התזמון ב-App Engine.
הקטנת קנה המידה
כשנפח הבקשות יורד, App Engine מצמצם את מספר המופעים. ההתאמה הזו של מספר השרתים עוזרת לוודא שכל המופעים הנוכחיים של האפליקציה משמשים ליעילות אופטימלית ולחיסכון בעלויות.
כשלא משתמשים באפליקציה בכלל, App Engine משבית את המופעים הדינמיים שמשויכים אליה, אבל טוען אותם מחדש ברגע שצריך. טעינה מחדש של מופעים עלולה לגרום לטעינת בקשות ולחביון נוסף עבור המשתמשים.
אפשר לציין מספר מינימלי של מכונות במצב סרק. הגדרת מספר מתאים של מופעים בלי פעילות לאפליקציה על סמך נפח הבקשות מאפשרת לאפליקציה לטפל בכל בקשה עם זמן אחזור נמוך, אלא אם נפח הבקשות גבוה באופן חריג.
הקטנת הקיבולת בהתאמה אוטומטית לעומס
אם האפליקציה משתמשת בהתאמה אוטומטית לעומס, יידרשו כ-15 דקות של חוסר פעילות כדי שהמופעים הלא פעילים יתחילו להיסגר. כדי להשאיר מכונה אחת או יותר במצב סרק, צריך להגדיר את הערך של min_idle_instances ל-1 או יותר.
שינוי קנה מידה ואצוות של בקשות
אם אתם שולחים קבוצות של בקשות לשירותים שלכם, למשל לתור משימות לעיבוד, מספר גדול של מופעים ייווצר במהירות. מומלץ לשלוט בזה על ידי הגבלת קצב של יצירת בקשות שנשלחות בכל שנייה, אם אפשר. לדוגמה, אם אתם משתמשים ב-Google Tasks, אתם יכולים לשלוט בקצב שבו המשימות נדחפות.
מחזור החיים של מופע
מצבים של מכונות
מופע של שירות עם שינוי גודל אוטומטי פועל תמיד. עם זאת, מופע של שירות עם התאמה ידנית או בסיסית לעומס יכול להיות פעיל או מושבת. כל המופעים של אותו שירות ואותה גרסה חולקים את אותו מצב. כדי לשנות את המצב של המופעים, צריך לנהל את הגרסאות. אתם יכולים:
- בדף Versions במסוףGoogle Cloud
- שימוש בפקודות
gcloud app versions startו-gcloud app versions stop
הפעלה
כל מופע של שירות נוצר בתגובה לבקשת הפעלה, שהיא בקשת HTTP ריקה מסוג GET אל /_ah/start. App Engine שולח את הבקשה הזו כדי ליצור מופע. משתמשים לא יכולים לשלוח בקשה אל /_ah/start. מופעים של קנה מידה ידני וקנה מידה בסיסי חייבים להגיב לבקשת ההתחלה לפני שהם יכולים לטפל בבקשה אחרת. אפשר להשתמש בבקשת ההתחלה לשתי מטרות:
- כדי להפעיל תוכנית שפועלת ללא הגבלת זמן, בלי לקבל בקשות נוספות.
- כדי לאתחל מופע לפני שהוא מקבל תנועה נוספת.
ההפעלה של מופעים עם שינוי גודל ידני, בסיסי ואוטומטי שונה. כשמפעילים מופע של קנה מידה ידני, App Engine שולח מיד בקשת /_ah/start לכל מופע. כשמפעילים מופע של שירות בסיסי עם שינוי גודל אוטומטי, מערכת App Engine מאפשרת לו לקבל תנועה, אבל הבקשה /_ah/start לא נשלחת למופע עד שהוא מקבל את בקשת המשתמש הראשונה. כמה מופעים של קנה מידה בסיסי מופעלים רק לפי הצורך, כדי לטפל בעלייה בנפח התנועה. מופעים עם התאמה אוטומטית לעומס לא מקבלים בקשות /_ah/start.
כשמופע מגיב לבקשת /_ah/start עם קוד סטטוס של HTTP 200–299 או 404, הוא נחשב כמופע שהופעל בהצלחה ויכול לטפל בבקשות נוספות. אחרת, App Engine יסיים את המופע. מכונות שמוגדרות בהן הגדלה ידנית של הקיבולת מופעלות מחדש באופן מיידי, ומכונות שמוגדרות בהן הגדלה בסיסית של הקיבולת מופעלות מחדש רק כשצריך אותן כדי לטפל בתנועת הגולשים.
כיבוי
תהליך ההשבתה עשוי להיות מופעל על ידי מגוון אירועים מתוכננים ולא מתוכננים, כמו:
- יש יותר מדי מקרים ולא מספיק בקשות לאפליקציה (תנועה).
- מפסיקים מכונה באופן ידני.
- אתם פורסים גרסה מעודכנת בשירות.
- המופע חורג מהזיכרון המקסימלי של
instance_classשהוגדר לו. - האפליקציה חורגת ממכסת שעות השימוש במופע.
- המופע שלכם מועבר למכונה אחרת, או כי המכונה הנוכחית שבה המופע פועל מופעלת מחדש, או כי App Engine העביר את המופע כדי לשפר את חלוקת העומס.
אחד היתרונות של פלטפורמת 'משלמים רק על מה שצריך' בסביבה הרגילה של App Engine, כפי שמתואר בקטע הקטנת קנה מידה, הוא שהמערכת משנה באופן אוטומטי את מספר המכונות לאפס כשאין תנועה. כך App Engine הופך לפתרון חסכוני לאפליקציות קטנות שלא מקבלות בקשות באופן רציף. כשצריך לכבות מכונה, בקשות חדשות שמגיעות מנותבות למכונות אחרות (אם יש כאלה), ולבקשות שנמצאות כרגע בתהליך עיבוד ניתן זמן להשלמה.
בדרך כלל, App Engine שולח אות STOP (SIGTERM) למאגר האפליקציות.
האפליקציה לא צריכה להגיב לאירוע הזה, אבל היא יכולה להשתמש בו כדי לבצע פעולות ניקוי נדרשות לפני שהקונטיינר נסגר. בתנאים רגילים, המערכת ממתינה עד 2 שניות עד שהאפליקציה מפסיקה לפעול, ואז שולחת אות KILL (SIGKILL). אם האפליקציה לא תופסת את האות SIGTERM, המופע מושבת באופן מיידי.
הנה כמה דוגמאות להודעות יומן שקשורות לסגירת מכונה:
[start] Quitting on terminated signal
[INFO] Handling signal: term
[INFO] Worker exiting (pid: 21)
[INFO] Worker exiting (pid: 24)
[INFO] Shutting down: Master
[start] Start program failed: termination triggered by nginx exit
הודעות היומן האלה לא מציינות מצב שגיאה, אלא מצביעות על תהליך רגיל של כיבוי המופע. שימו לב שהערכים [start] ו-Start ביומנים מתייחסים לתהליך פלטפורמה בשם start ואין להם קשר להפעלה של מופע או אפליקציה.
הבקשות בטעינה
כש-App Engine יוצר מופע חדש לאפליקציה, המופע צריך קודם לטעון את כל הספריות והמשאבים שנדרשים לטיפול בבקשה. זה קורה במהלך הבקשה הראשונה למופע, שנקראת בקשת טעינה. במהלך בקשת טעינה, האפליקציה עוברת אתחול, ולכן הבקשה אורכת זמן רב יותר.
השיטות המומלצות הבאות יעזרו לכם לקצר את משך הטעינה של הבקשות:
- טעינה רק של הקוד שנדרש להפעלה.
- גישה לדיסק כמה שפחות.
- במקרים מסוימים, טעינת קוד מקובץ zip או jar מהירה יותר מטעינה ממספר קבצים נפרדים.
בקשות warmup
בקשות לחימום הן סוג ספציפי של בקשות טעינה, שנועדו לטעון קוד של אפליקציה למופע מראש, לפני שמתבצעות בקשות פעילות.
מופעים של קנה מידה ידני או בסיסי לא מקבלים בקשת /_ah/warmup.
מידע נוסף על שימוש בבקשות חימום זמין במאמר הגדרת בקשות חימום.
זמן הפעולה התקינה של המכונה
App Engine מנסה להפעיל מופעים של התאמה ידנית לעומס (scaling) ושל התאמה בסיסית לעומס (scaling) ללא הגבלת זמן. עם זאת, בשלב הזה אין זמן פעולה מובטח למופעים של שינוי גודל ידני ושינוי גודל בסיסי.
NTP עם סביבה רגילה של App Engine
בסביבה הרגילה של App Engine יש שירותים של פרוטוקול זמן ברשת (NTP) שמשתמשים בשרתי NTP של Google. עם זאת, אי אפשר לערוך את שירות ה-NTP.
ניהול שירותים
בהתאם לסוג ההתאמה לגודל של המופע, אתם יכולים לנהל שירותים וגרסאות במסוף Google Cloud או ב-Google Cloud CLI.
הפסקת גרסה
כל גרסה ב-App Engine פועלת במופע אחד או יותר, בהתאם לכמות התנועה שהגדרתם שהיא תטפל בה.
כדי לקבל הוראות לשימוש בכלי הרצוי, לוחצים על הכרטיסייה הרלוונטית:
המסוף
כדי להפסיק או להשבית גרסה של השירות:
נכנסים לדף Versions של App Engine במסוף Google Cloud :
בוחרים גרסה מהטבלה ולוחצים על הפסקה.
gcloud
מריצים את הפקודה הבאה:
gcloud app versions stop --service=SERVICE VERSION
מחליפים את:
- SERVICE בשם של השירות.
- VERSION בשם הגרסה של השירות.
מחק שירות
אפשר להגדיר כל שירות כך שישתמש בזמני ריצה שונים ויפעל עם הגדרות ביצועים שונות. אי אפשר למחוק את שירות ברירת המחדל. אם מוחקים שירות, נמחקות גם כל הגרסאות הנלוות שלו בפרויקט.
כדי לקבל הוראות לשימוש בכלי הרצוי, לוחצים על הכרטיסייה הרלוונטית:
המסוף
כדי למחוק שירות:
נכנסים לדף Services של App Engine במסוף Google Cloud :
בוחרים שירות מהטבלה ולוחצים על מחיקה.
gcloud
מריצים את הפקודה הבאה:
gcloud app services delete SERVICE
מחליפים את:
- SERVICE בשם של השירות.