איך מנהלים מכונות

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

‫App Engine יכול ליצור מכונות ולהפסיק את הפעולה שלהן באופן אוטומטי כשיש שינויים בתעבורה, או שאתם יכולים לציין מספר מכונות להפעלה בלי קשר לכמות התעבורה. כדי לקבוע איך ומתי נוצרים מופעים חדשים, צריך לציין סוג של שינוי גודל לאפליקציה. הגדרות שינוי הגודל מוחלות ברמת הגרסה של App Engine כחלק מקובץ app.yaml.

סוגי התאמה להיקף

‫App Engine תומך בסוגי הסקייל הבאים, שקובעים איך ומתי נוצרים מופעים:

  • אוטומטי (ברירת מחדל)
  • בסיסי
  • גלילה ידנית

מציינים את סוג הגידול בקיבולת בקובץ app.yaml של האפליקציה. כברירת מחדל, האפליקציה משתמשת בגידול אוטומטי בקיבולת, כלומר App Engine ינהל את מספר המופעים הלא פעילים.

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

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

מופע בסיסי עם קנה מידה יכול לבחור לטפל ב-/_ah/start ולהפעיל תוכנית או סקריפט במשך שעות רבות בלי להחזיר קוד תגובת HTTP.

 זהה לשינוי גודל בסיסי.
שרשורים ברקע (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 מפעיל מכונה חדשה. גם אחרי הפעלת מכונה חדשה, יכול להיות שחלק מהבקשות יוכנסו לתור עד שתהליך ההפעלה של המכונה החדשה יסתיים. אם חשוב לכם להשיג את זמן האחזור הנמוך ביותר שאפשר, כדאי להשתמש בסקייל אוטומטי, שיוצר מכונות חדשות מראש כדי למזער את זמן האחזור.

אפליקציות עם התאמה אוטומטית לעומס

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

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

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

כדי לראות את ההשפעות של ההגדרות האלה, אפשר לצפות בסרטון בנושא הגדרות של כלי התזמון ב-App Engine.

הקטנה

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

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

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

הקטנת הקיבולת בהתאמה אוטומטית לעומס

אם האפליקציה שלכם משתמשת בהתאמה אוטומטית לעומס (automatic scaling), יידרשו כ-15 דקות של חוסר פעילות כדי שהמופעים הלא פעילים יתחילו להיסגר. כדי להשאיר מופע אחד או יותר לא פעילים, צריך להגדיר את הערך של min_idle_instances ל-1 או יותר.

שינוי קנה מידה ואצוות של בקשות

אם אתם שולחים קבוצות של בקשות לשירותים שלכם, למשל לתור משימות לעיבוד, מספר גדול של מכונות ייווצר במהירות. מומלץ לשלוט בכך על ידי הגבלת קצב של יצירת בקשות, אם אפשר. לדוגמה, אם אתם משתמשים ב-Google Tasks, אתם יכולים לשלוט בקצב שבו המשימות נדחפות.

מחזור החיים של מופע

מצבים של מכונות

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

הפעלה

כל מופע של שירות נוצר בתגובה לבקשת הפעלה, שהיא בקשת 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 מהירה יותר מטעינה ממספר קבצים נפרדים.

בקשות חימום

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

מידע נוסף על שימוש בבקשות חימום זמין במאמר הגדרת בקשות חימום.

זמן הפעולה התקינה של המכונה

‫App Engine מנסה להפעיל מכונות עם התאמה ידנית לעומס (scaling) או התאמה בסיסית לעומס (scaling) ללא הגבלת זמן. עם זאת, בשלב הזה אין זמן פעולה מובטח למופעים של שינוי גודל ידני ושינוי גודל בסיסי.

פרוטוקול NTP עם סביבה רגילה של App Engine

בסביבה הרגילה של App Engine יש שירותים של פרוטוקול זמן ברשת (NTP) שמשתמשים בשרתי NTP של Google. עם זאת, אי אפשר לערוך את שירות ה-NTP.

ניהול שירותים

בהתאם לסוג ההתאמה לגודל של המופע, אפשר לנהל שירותים וגרסאות במסוף Google Cloud או ב-Google Cloud CLI.

הפסקת גרסה

כל גרסה ב-App Engine פועלת במופע אחד או יותר, בהתאם לכמות התנועה שהגדרתם שהיא תטפל בה.

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

המסוף

כדי להפסיק או להשבית גרסה של השירות:

  1. נכנסים לדף Versions של App Engine במסוף Google Cloud :

    כניסה לדף Versions

  2. בוחרים גרסה מהטבלה ולוחצים על הפסקה.

gcloud

מריצים את הפקודה הבאה:

  gcloud app versions stop --service=SERVICE VERSION

מחליפים את:

  • SERVICE בשם של השירות.
  • ‫VERSION בשם הגרסה של השירות.

מחק שירות

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

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

המסוף

כדי למחוק שירות:

  1. נכנסים לדף Services של App Engine במסוף Google Cloud :

    כניסה לדף Services

  2. בוחרים שירות מהטבלה ולוחצים על מחיקה.

gcloud

מריצים את הפקודה הבאה:

  gcloud app services delete SERVICE

מחליפים את:

  • SERVICE בשם של השירות.