בעיות מוכרות בסביבה הגמישה של App Engine

מזהה אזור

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, המחרוזת REGION_ID.r כלולה בכתובות ה-URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

מידע נוסף על מזהי אזורים

רשימה מלאה של בעיות מוכרות ודיווח על בעיה חדשה זמינים בכלי למעקב אחרי בעיות.

  • אחרי שמפעילים את האפליקציה באמצעות gcloud app deploy, יכול להיות שצריך לחכות דקה או שתיים עד שהאפליקציה תתחיל לפעול בכתובת https://PROJECT_ID.REGION_ID.r.appspot.com. עד אז, יכול להיות שיופיעו שגיאות HTTP 503.

    בדרך כלל, שגיאות כאלה נרשמות ביומן של מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) ב-App Engine בתור backend_timeout או failed_to_pick_backend. מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) שולח בקשות לשירות בסביבה הגמישה של App Engine, בלי קשר למצב התקינות של מופעים ספציפיים. אחרי שמבצעים פריסה של גרסה חדשה, לוקח זמן עד שמאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) מעדכן את ההגדרה שלו עם שרתי הקצה העורפי החדשים. במהלך המעבר הזה, הזמינות של שירותי הקצה העורפי לא עקבית. כשמעבירים תנועה לגרסה החדשה, מאזן העומסים הגלובלי החיצוני של האפליקציות (ALB) עשוי לנסות לשלוח תנועה למופעים שלא מוכנים לקבל בקשות באופן מלא, וכתוצאה מכך יחזיר שגיאות 503. יכול להיות שזה יגרום גם לשגיאות 502, במיוחד כשמשתמשים במאזן עומסים קלאסי של אפליקציות.

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

    • המדיניות שבתוקף לגבי constraints/compute.vmExternalIpAccess מוגדרת כ-DENY_ALL.
    • המדיניות שבתוקף לגבי constraints/compute.vmExternalIpAccess מוגדרת כך שרק מקרים ספציפיים של מכונות וירטואליות מורשים.
    • המדיניות שבתוקף לגבי constraints/compute.requireOsConfig מושבתת בפרויקט כדי למנוע עדכונים של מטא-נתונים.

    המערכת לא מזהה את המגבלות האלה באופן אוטומטי, ויכול להיות שהפריסות ייכשלו בגלל חריגה מזמן קצוב לתפוגה. כדי לבדוק את מדיניות הארגון של הפרויקט, מריצים את הפקודה gcloud beta resource-manager org-policies describe compute.vmExternalIpAccess --project=my-project --effective. אפשר גם לשנות את מדיניות הארגון עבור פרויקט ספציפי.

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

  • אחרי שפורסים גרסה חדשה של שירות קיים בסביבה הגמישה של App Engine עם gcloud app deploy, יכול להיות שהמדד 'ספירה/שנייה' שמוצג בתרשים 'סיכום' בלוח הבקרה של App Engine ירד באופן משמעותי. המדד יחזור בהדרגה למספר הבקשות הצפוי ב-5 עד 10 הדקות הבאות.

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

    כדי לוודא שהמדד הזה לא מושפע מפריסת גרסה חדשה:

    1. פורסים את הגרסה החדשה באמצעות gcloud app deploy --no-promote.
    2. מחכים 15 דקות אחרי שהפריסה מסתיימת.
    3. העברת התנועה לגרסה החדשה.

    אם אתם פורסים באמצעות --no-promote אבל מקצים כמות כלשהי של תנועה לגרסה החדשה לפני חלון 15 הדקות אחרי שהפריסה מסתיימת, יכול להיות שהמדד הזה יושפע.

  • בסביבה הגמישה של App Engine, אי אפשר להגדיר את app.yaml כך שהאפליקציה תפנה אוטומטית בקשות לשימוש ב-HTTPS. זה שונה מהסביבה הרגילה של App Engine, שבה אפשר להשתמש בהגדרה secure.

    לחלופין, אפשר לטפל בהפניה האוטומטית בקוד של האפליקציה על ידי ניתוח הערך של הכותרת X-Forwarded-Proto. אפשר גם לעודד את הלקוחות להשתמש בכותרת Strict-Transport-Security.

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

  • אי אפשר ליצור חיבור SSH למכונת VM באמצעות IAP.

  • בסביבה הגמישה של App Engine, הזמן הקצוב לתפוגה של בקשה הוא 60 דקות. עם זאת, אם האפליקציה שלכם מוגדרת לשימוש ברשת VPC עם כללי חומת אש מחמירים ליציאה (למשל, דחיית יציאה אל 0.0.0.0), יכול להיות שתיתקלו בניתוקים של בקשות שנמשכות יותר מ-10 דקות.

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

    כדי לעקוף את ההגבלה הזו, מבצעים את השלבים הבאים:

הפחתה לא צפויה במספר המופעים

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

    1. השקת עדכונים למופעים של סביבה גמישה
    2. כשל אזורי (בעיות של חוסר במלאי, למשל כשהאזור שלכם נמצא בקיבולת המקסימלית של המעבד שבחרתם וכו')

    בסביבה גמישה של App Engine נעשה שימוש ב-3 אזורים כדי להפיץ את המכונות שלכם, ובמקרה כזה מומלץ להקצות 50% יותר מכונות מהנדרש.

מדדים לא עקביים של Cloud Load Balancing

בלוח הבקרה של הסביבה הגמישה של App Engine מוצגים כל המדדים רק לבקשות שמנותבות דרך קצה עורפי שמנוהל על ידי סביבה גמישה. אם אתם משתמשים בסביבה הגמישה של App Engine עם Cloud Load Balancing, מדדים מסוימים בטבלת המדדים של App Engine מדווחים כמדדים מהטבלה loadbalancing. מידע נוסף זמין במאמר בנושא רישום ביומן ומעקב של איזון עומסים ב-HTTP(S).

‫InterruptedException ב-runtimes באמצעות JVM במהלך כשל בבדיקת התקינות

כשבדיקת תקינות נכשלת, מכונת ה-VM מושבתת. כסימפטום לכך שהקונטיינר של האפליקציה לא תקין, ה-JVM מגיב עם שגיאות InterruptedException ו-NullPointerException. ה-handler יכול להגיב לאות SIGTERM שנשלח על ידי הקונטיינר במהלך הכיבוי, כדי לבצע פעולות ניקוי או ניפוי באגים שנדרשות, וכך למנוע חריגים.