השוואה בין App Engine לבין Cloud Run

מזהה אזור

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

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

אישור

חשוב: Cloud Run היא פלטפורמה מודרנית לאירוח אפליקציות בניהול מלא, שמאפשרת גישה ליכולות מתקדמות כמו יחידות GPU, במחירים נמוכים יותר. מומלץ לבדוק את Cloud Run לפרויקטים הקרובים או למודרניזציה של האפליקציות הקיימות. למשתמשים חדשים Google Cloud , אנחנו ממליצים להשתמש ב-Cloud Run כחלופה המועדפת במקום ב-App Engine.

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

סקירה כללית

‫Cloud Run הוא השלב האחרון באבולוציה של Google Cloud המודל "בלי שרת", והוא מבוסס על הניסיון שנצבר בהפעלת App Engine במשך יותר מעשור. ‫Cloud Run פועל על חלק גדול מאותה תשתית כמו סביבת ברירת המחדל ב-App Engine, ולכן יש הרבה קווי דמיון בין שתי הפלטפורמות האלה.

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

סיכום ההשוואה

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

	סביבת ברירת המחדל ב-App Engine	סביבה גמישה ב-App Engine	Cloud Run
הסברים על המונחים	בקשת הצטרפות		לא רלוונטי
	שירות		שירות
	גרסה		גרסה קודמת
נקודות קצה של כתובות URL
כתובת URL של האפליקציה (default service)	https://PROJECT_ID.REGION_ID.r.appspot.com		לא רלוונטי
כתובת ה-URL של השירות	https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com		https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app https://SERVICE_IDENTIFIER.run.app
כתובת URL של גרסה או תיקון	https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com		https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app https://TAG---SERVICE_IDENTIFIER.run.app
התאמה לעומס (scaling)
התאמה אוטומטית לעומס	כן	כן	כן
שינוי גודל ידני	כן	כן	כן
צמצום הפעולה לאפס	כן	לא	כן
בקשות חימום	ניתן להגדרה	לא	אוטומטי
זמן קצוב לתפוגה של מופע ללא פעילות (אחרי סיום הבקשה האחרונה)	עד 15 דקות		תלוי בהגדרת החיוב. שימוש בחיוב על בסיס מופע כדי לדמות את ההתנהגות של App Engine
משך הבקשה הסתיים	התאמה אוטומטית לעומס: 10 דקות הגדלה ידנית/בסיסית של נפח התנועה: 24 שעות	60 דקות	אפשר להגדיר עד 60 דקות (ברירת מחדל: 5 דקות)
פריסה
מהמקור	כן		כן
קובץ אימג' של קונטיינר	לא	כן (סביבות זמן ריצה בהתאמה אישית)	כן
קונטיינרים מסוג Sidecar	לא		כן. קונטיינרים מסוג Sidecar פועלים לצד הקונטיינר הראשי ומשרתים בקשות אינטרנט.
בדיקות תקינות	אוטומטי. ‫App Engine מבצע בדיקות מוכנות ובדיקות פעילות במופעים שלכם.		ניתן להגדרה. אתם מגדירים בדיקות הפעלה ובדיקות תקינות באופן מפורש בהגדרות של משאב Cloud Run, ומציינים פרטים כמו סוג הבדיקה (TCP,‏ HTTP ו-gRPC), נתיב, יציאה, עיכוב ראשוני, תקופה, זמן קצוב לתפוגה, סף הצלחה וסף כשל.
משאבי מחשוב
vCPU	סוג המכונה vCPU* זיכרון F/B1 ‫.25 ‫384MB F/B2 ‫.5 ‫768MB F/B4 1 ‫1.5GB F/B4_1G 1 3GB B8 2 3GB ‫* שווי ערך של vCPU הוא משוער	עד 80 vCPU	עד 8 vCPU
זיכרון		עד 6.5GB לכל vCPU	עד 32GB
יחידות GPU	לא		כן. אפשר להגדיר יחידת GPU אחת לכל מופע של Cloud Run.
חיבורים של נפח אחסון	לא		כן. אפשר לטעון קטגוריה של Cloud Storage ישירות למערכת הקבצים של הקונטיינר.
מודל התמחור
עמלה לכל בקשה	לא		לא, כשמשתמשים בחיוב לפי מופע. כן, כשמשתמשים בחיוב לפי בקשה.
מספר מינימלי של מופעים במצב המתנה	אותה עלות כמו מופעים פעילים		עלות נמוכה יותר למקרים שבהם יש מכונות מינימליות במצב המתנה (ראו זמן שימוש במכונת קונטיינר לחיוב)
הנחות תמורת התחייבות לשימוש (CUD)	לא		כן
חיוב לפי מופע (עלות למופע לשעה)	מופע F4/B4: ‏ ‎$0.2	vCPU: $0.0526 זיכרון: ‎$0.0071	vCPU: ‏0.0648$ זיכרון: ‎$0.0072
אבטחה
הגדרות של תעבורת נתונים נכנסת (ingress)	כן	כן	כן
תפקיד המפעיל	לא		כן
IAP	כן	כן	כן
חומות אש	כן	כן	הגדרה באמצעות Google Cloud Armor
Secret Manager	כן, באמצעות ספריות לקוח של Cloud.		כן. אפשר לטעון כל סוד כנפח או להעביר סוד באמצעות משתני סביבה.
קישוריות
דומיינים מותאמים אישית	כן	כן	כן
קישוריות ל-VPC (כולל VPC משותף)	כן	לא רלוונטי	כן
הגדרות של תעבורת נתונים יוצאת (egress) ב-VPC	כן	לא רלוונטי	כן
איזון עומסים במספר אזורים	לא		כן
סטרימינג מהשרת	לא		כן
קישוריות – תעבורת נתונים יוצאת (egress) ישירה של VPC
שלב ההשקה	תצוגה מקדימה	לא רלוונטי	GA
תגים של רשתות	YAML	לא רלוונטי	נתמך
VPC Flow Logs	נתמך	לא רלוונטי	נתמך
NAT ציבורי	נתמך	לא רלוונטי	נתמך
Private NAT	לא נתמך	לא רלוונטי	נתמך
רשתות משנה עם כתובות IPv4 ו-IPv6	נתמך	לא רלוונטי	נתמך
שיטת ההגדרה	YAML	לא רלוונטי	מסוףGoogle Cloud , gcloud, ‏ YAML, ‏ Terraform
תמיכה ב-VPC משותף	נתמך	לא רלוונטי	נתמך
גישה לשירותים Google Cloud
Cloud SQL	כן	כן	כן
ספריות לקוח ב-Cloud	אם אתם משתמשים ב-Cloud Client Libraries ב-App Engine, לא תצטרכו לשנות שום דבר כשאתם עוברים ל-Cloud Run. ספריות הלקוח האלה פועלות בכל מקום, ולכן האפליקציה שלכם ניידת יותר.
שירותים בחבילה מדור קודם של App Engine	כן (Java, ‏ Python, ‏ Go, ‏ PHP בלבד)	לא	לא

מודל של משאבים

מודל המשאבים של Cloud Run דומה מאוד לזה של App Engine, אבל יש כמה הבדלים חשובים:

• ל-Cloud Run אין משאב Application ברמה העליונה או שירות default תואם.
• אפשר לפרוס שירותי Cloud Run באזורים שונים באותו פרויקט. ב-App Engine, כל השירותים בפרויקט נמצאים באותו אזור.
• ב-Cloud Run משתמשים במונח Revision (גרסה), במקום במונח Version (גרסה), כדי להתאים למודל המשאבים של Knative.
• שמות הגרסאות של Cloud Run הם בפורמט: SERVICE_NAME-REVISION_SUFFIX, כאשר REVISION_SUFFIX נוצר באופן אוטומטי או מוגדר באמצעות דגל הפריסה --revision-suffix=REVISION_SUFFIX.
• אי אפשר לשנות את הגרסאות ב-Cloud Run, כלומר אי אפשר לעשות שימוש חוזר בשמות כמו בגרסאות של App Engine (באמצעות דגל הפריסה --version=VERSION_ID).
• כתובות ה-URL של שירות Cloud Run מבוססות על מזהה שירות שנוצר באופן אוטומטי בפריסה הראשונה של השירות. מזהי השירות מופיעים בפורמט: SERVICE_NAME-<auto-generated identifier>. מזהה השירות הוא ייחודי ולא משתנה במהלך חיי השירות.
• ב-Cloud Run, רק כתובות ה-URL של השירות (SERVICE_IDENTIFIER.run.app ו-https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) חשופות כברירת מחדל. כדי להתייחס לשינוי ספציפי, צריך להגדיר תג תנועה. ב-App Engine, כתובות ה-URL של השירות ושל הגרסה נחשפות באופן אוטומטי.

פריסה והגדרה

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

ל-Cloud Run יש קובץ תצורה service.yaml, אבל הוא לא משמש באותו אופן כמו app.yaml. אי אפשר להשתמש ב-Cloud Run service.yaml כשפורסים מקוד מקור, כי אחד מהרכיבים הנדרשים הוא הנתיב לקובץ האימג' הסופי בקונטיינר. בנוסף, קובץ ה-service.yaml תואם למפרט של Knative, ויכול להיות שיהיה קשה לקרוא אותו למי שלא מכיר קובצי תצורה בסגנון Kubernetes. מידע נוסף על שימוש ב-service.yaml לניהול ההגדרות זמין במסמכי התיעוד של Cloud Run.

ללקוחות App Engine שמתחילים להשתמש ב-Cloud Run, השימוש בדגלי הפריסה של ה-CLI של gcloud תואם הרבה יותר לניהול ההגדרות של App Engine בזמן הפריסה.

כדי להגדיר את ההגדרה כשפורסים קוד חדש ב-Cloud Run, משתמשים בסימונים gcloud run deploy:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

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

ב-Cloud Run, אפשר גם לעדכן את ההגדרה בלי לפרוס מחדש את קוד המקור באמצעות gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

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

ניהול הגדרות

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

App Engine service-a version1	App Engine service-a version2
app.yaml
runtime: python39 service: service-a instance_class: F4	runtime: python39 service: service-a
ההגדרה שהוחלה
runtime: python39 service: service-a instance_class: F4 default values: .. ..	runtime: python39 service: service-a default values: instance_class: F1 .. ..

‫version1 מוגדר עם instance_class: F4, ואילו version2, שלא צוין לו ערך עבור instance_class, מוגדר עם ברירת המחדל instance_class: F1.

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

Cloud Run service-a revision1	Cloud Run service-a revision2
פקודת פריסה
gcloud run deploy service-a \ --cpu=4	gcloud run deploy service-a
ההגדרה שהוחלה
service: service-a vCPUs: 4 default values: .. ..	service: service-a vCPUs: 4 default values: .. ..

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

הגדרות ברירת המחדל

הגדרת תצורה	סביבת ברירת המחדל ב-App Engine	סביבה גמישה ב-App Engine	Cloud Run
משאבי מחשוב	F1	‫‎1 vCPU, .6GB	‫1 vCPU, ‏ 512MB
מקסימום בו-זמניות (בקשות)	10	ללא	80
משך הבקשה הסתיים	התאמה אוטומטית לעומס: 10 דקות הגדלה ידנית/בסיסית של נפח התנועה: 24 שעות	60 דקות	5 דקות
יעד ניצול המעבד (CPU)	60%	50%	60%
מספר מכונות מקסימלי	ללא	20	100
מינימום מכונות	0	2	0

נקודת כניסה

כשפורסים מקובץ מקור, ‏ App Engine קורא את פקודת נקודת הכניסה מהמאפיין entrypoint בקובץ app.yaml. אם לא מציינים נקודת כניסה, המערכת משתמשת בברירת מחדל ספציפית לזמן הריצה. כשמבצעים פריסה ממקור, Cloud Run משתמש ב-buildpacks של Google Cloud. לחלק מהשפות אין נקודת כניסה שמוגדרת כברירת מחדל, ולכן צריך לספק נקודת כניסה, אחרת הפריסה תיכשל. לדוגמה, חבילות buildpack של Python דורשות קובץ Procfile או הגדרה של משתנה הסביבה GOOGLE_ENTRYPOINT.

כדאי לעיין בתיעוד של buildpacks כדי לראות אם יש דרישות הגדרה ספציפיות לשפה.

חשוב: כשמבצעים פריסה ממקור באמצעות gcloud run deploy --source, אפשר להשתמש רק בשיטה Procfile כדי להגדיר את נקודת הכניסה.

בדיקות תקינות

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

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

ב-Cloud Run, אפשר להגדיר את הבדיקות הבאות:

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

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

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

התאמה לעומס (scaling)

למרות ש-Cloud Run וסביבת ברירת המחדל ב-App Engine חולקים תשתית דומה של התאמה לעומס (scaling), ב-Cloud Run יש תהליך יעיל יותר של התאמה מהירה לעומס (scaling) ויכולות של צמצום הפעולה לאפס. כתוצאה מכך, יש פחות הגדרות שאפשר לשנות. השיפור הזה מגביל את ההגדרות שאפשר לשנות ל:

• מקסימום בו-זמניות
• מספר מקסימלי ומינימלי של מופעים
• אמצעי בקרה מותאמים אישית של שינוי הגודל להגדרת ניצול היעד של CPU ושל מקביליות

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

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

העברת אמצעי בקרה של שינוי קנה מידה מ-App Engine ל-Cloud Run

בקטע הזה מוסבר איך למפות את הגדרות קנה המידה הקיימות של App Engine ל-Cloud Run.

מינימום מכונות (חימום)

כדאי להשאיר מספר מינימלי של מופעים במצב חם כדי לטפל בתנועת הבסיס ולמנוע הפעלות במצב התחלתי (cold start).

סביבת ההגדרה	הגדרות
סביבת ברירת המחדל ב-App Engine	min_instances: N
סביבה גמישה ב-App Engine	automatic_scaling:   min_num_instances: N
Cloud Run	ברמת השירות: scaling.min_instance_count: N ברמת הגרסה: template.scaling.min_instance_count: N

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

מספר מכונות מקסימלי

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

סביבת ההגדרה	הגדרות
סביבת ברירת המחדל ב-App Engine	max_instances: N
סביבה גמישה ב-App Engine	automatic_scaling:   max_num_instances: N
Cloud Run	ברמת השירות: scaling.max_instance_count: N ברמת הגרסה: template.scaling.max_instance_count: N

שיטת העברה: הגדרת מגבלה גלובלית ברמת השירות. ב-Cloud Run, המערכת אוכפת את ההגדרות הנמוכות יותר ברמת השירות וברמת התיקון. מידע נוסף זמין במאמר הגדרת מספר מקסימלי של מופעים לשירותים.

בו-זמניות

הגדרת קיבולת הבקשות של מופע יחיד.

סביבת ההגדרה	הגדרות
סביבת ברירת המחדל ב-App Engine	max_concurrent_requests: N
סביבה גמישה ב-App Engine	automatic_scaling:   target_concurrent_requests: N
Cloud Run	template.maxInstanceRequestConcurrency: N

אסטרטגיית העברה: אפשר לפעול לפי אחת משתי אסטרטגיות העברה:

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

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

ניצול יחידת העיבוד המרכזית (CPU)

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

סביבת ההגדרה	הגדרות
סביבת ברירת המחדל ב-App Engine	target_cpu_utilization: 0.X
סביבה גמישה ב-App Engine	automatic_scaling:   cpu_utilization:   target_utilization: N
Cloud Run	template.scaling.cpuUtilization: 0.X

שיטת העברה: משתמשים בדגל --scaling-cpu-target כדי להגדיר סף מותאם אישית לניצול המעבד. כברירת מחדל, המערכת לשינוי גודל אוטומטי ב-Cloud Run שומרת על ניצול של כ-60% מהמעבד במכונות פעילות. מידע נוסף זמין במאמר הגדרת אמצעי בקרה להתאמה אישית של קנה מידה לשירותים.

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

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

ניצול בו-זמניות

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

סביבת ההגדרה	הגדרות
סביבת ברירת המחדל ב-App Engine	target_throughput_utilization: 0.X
סביבה גמישה ב-App Engine	לא זמין
Cloud Run	template.scaling.concurrencyUtilization: 0.X

אסטרטגיית העברה: משתמשים בדגל --scaling-concurrency-target כדי להגדיר את סף ניצול היעד של פעולות בו-זמניות. כברירת מחדל, התכונה להתאמה אוטומטית לעומס ב-Cloud Run מנסה לשמור על מספר הבקשות המקבילות לכל מכונה ב-60% מהערך של מספר הבקשות המקבילות המקסימלי לכל מכונה. מידע נוסף זמין במאמר הגדרת אמצעי בקרה להתאמה אישית של קנה מידה לשירותים.

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

זמן אחזור

הגדרת חלון זמן להמתנה של משתמש שגורם להרחבת הקיבולת. ‫App Engine מגיב באופן חלקי לתורים של בקשות.

סביבת ההגדרות	הגדרות
סביבת ברירת המחדל ב-App Engine	min_pending_latency וגם max_pending_latency
סביבה גמישה ב-App Engine	לא זמין
Cloud Run	אין מקבילה ישירה

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

מכונות בלי פעילות

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

סביבת ההגדרות	הגדרות
סביבת ברירת המחדל ב-App Engine	‫min_idle_instances: N או max_idle_instances: N
סביבה גמישה ב-App Engine	לא זמין
Cloud Run	אין מקבילה ישירה

אסטרטגיית מיגרציה: אי אפשר להגדיר ב-Cloud Run מספר מינימלי או מקסימלי נפרד של מופעים לא פעילים. כדי לשמור על המופעים במצב ביניים (warm) ומוכנים לתנועה מיידית, וכדי לצמצם את ההשפעה של הפעלה במצב התחלתי (cold start) ב-Cloud Run, אפשר להשתמש בהגדרה scaling.min_instance_count, שמבטיחה שמספר מינימלי של קונטיינרים יפעל תמיד. מידע נוסף זמין במאמר מידע על שינוי גודל אוטומטי של מופעים בשירותי Cloud Run.

הזמן הקצוב לתפוגה של מופע לא פעיל

ב-App Engine, מופעים במצב המתנה נשארים פעילים למשך כ-15 דקות אחרי הבקשה האחרונה. ב-Cloud Run, ההתנהגות הזו נשלטת באמצעות הגדרת החיוב.

כדי לקבל התנהגות חיוב דומה לזו של App Engine, שבה הקצאת המעבד מתבצעת מחוץ לעיבוד הבקשות, צריך להשתמש בחיוב מבוסס-אינסטנס ב-Cloud Run.

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

שינוי גודל בסיסי

סביבת ההגדרות	הגדרות
סביבת ברירת המחדל ב-App Engine	basic_scaling: max_instances: N
סביבה גמישה ב-App Engine	לא זמין
Cloud Run	שינוי גודל אוטומטי שמוגדר כברירת מחדל. scaling.min_instance_count: 0 scaling.max_instance_count: N

כשמגדירים את ההגדרה basic_scaling בסביבת ברירת המחדל ב-App Engine, המערכת יוצרת מופעים כשהיא מקבלת בקשות, ומצמצמת את מספר המופעים לאפס אחרי תקופה של חוסר פעילות. אפשר לשכפל את ההתנהגות הזו ב-Cloud Run באמצעות התאמה אוטומטית לעומס על ידי הגדרת min-instances ל-0.

שינוי גודל ידני

הפעלת מספר קבוע של מכונות והשבתת התאמה אוטומטית לעומס.

סביבת ההגדרות	הגדרות
סביבת ברירת המחדל ב-App Engine	manual_scaling: instances: N
סביבה גמישה ב-App Engine	manual_scaling: instances: N
Cloud Run	scalingMode: MANUAL   manualInstanceCount: N

אסטרטגיית העברה: יש מיפוי ישיר ב-Cloud Run לשינוי גודל ידני. מגדירים את מצב שינוי הגודל ל-MANUAL ברמת השירות ב-Cloud Run, ומציינים את המספר המדויק של המופעים להפעלה באמצעות manualInstanceCount. ההשפעה של הפעולה הזו זהה להשפעה של השבתה מלאה של שינוי הגודל האוטומטי. מידע נוסף זמין במאמר בנושא שינוי גודל ידני ב-Cloud Run.

תקופת צינון

הגדרת תקופת צינון אחרי אירוע של הגדלת קיבולת לפני שמתרחש אירוע אחר.

סביבת ההגדרות	הגדרות
סביבת ברירת המחדל ב-App Engine	לא זמין
סביבה גמישה ב-App Engine	automatic_scaling:   cool_down_period_sec: N
Cloud Run	אין מקבילה ישירה

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

בקשות לחימום

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

• הגדרת האפליקציה להאזנה לבקשות
• הגדרה של בדיקת מוכנות מותאמת אישית

תוכן סטטי

בסביבה הרגילה של App Engine, אפשר להציג תוכן סטטי בלי להשתמש במשאבי מחשוב על ידי הצגה מ-Cloud Storage או על ידי הגדרה של handlers.ב-Cloud Run אין אפשרות להשתמש ב-handlers כדי להציג תוכן סטטי, לכן אפשר להציג את התוכן משירות Cloud Run (בדומה לתוכן דינמי) או מ-Cloud Storage.

התפקיד Cloud Run Invoker

בנוסף, Cloud Run מאפשר לשלוט בגישה לשירות באמצעות ניהול זהויות והרשאות גישה (IAM). אפשר להגדיר את קישורי מדיניות IAM לשירות באמצעות ה-CLI של gcloud, המסוף או Terraform.

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

פריסה

משתמשים בדגל הפריסה --allow-unauthenticated:

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

שירות קיים

משתמשים בפקודה gcloud run services add-iam-policy-binding:

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

כאשר SERVICE_NAME הוא שם השירות של Cloud Run.

לחלופין, אתם יכולים לקבוע למי תהיה גישה לשירות על ידי הקצאת תפקיד IAM‏ Cloud Run Invoker, שאפשר להגדיר אותו לכל שירות בנפרד.

פריסה

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

כאשר SERVICE_NAME הוא שם השירות ו-MEMBER_TYPE הוא סוג חשבון המשתמש. לדוגמה, user:[e-mail].

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

שירות קיים

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

כאשר SERVICE_NAME הוא שם השירות ו-MEMBER_TYPE הוא סוג חשבון המשתמש. לדוגמה, user:[e-mail].

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

משתני סביבה ומטא-נתונים

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

משתני סביבה שמוגדרים כברירת מחדל

שם App Engine	שם Cloud Run	תיאור
GAE_SERVICE	K_SERVICE	השם של השירות הנוכחי. ב-App Engine, אם לא מציינים ערך, ברירת המחדל היא default.
GAE_VERSION	K_REVISION	תווית הגרסה הנוכחית של השירות.
PORT	PORT	היציאה שמקבלת בקשות HTTP.
לא רלוונטי	K_CONFIGURATION	השם של ההגדרה ב-Cloud Run שיצרה את הגרסה.
GOOGLE_CLOUD_PROJECT	לא רלוונטי	מזהה הפרויקט ב- Google Cloud שמשויך לאפליקציה.
GAE_APPLICATION		המזהה של אפליקציית App Engine. המזהה הזה מתחיל בקידומת 'קוד אזור~', כמו 'e~' לאפליקציות שנפרסות באירופה.
GAE_DEPLOYMENT_ID		המזהה של הפריסה הנוכחית.
GAE_ENV		סביבת App Engine. מגדירים את הערך ל-`standard` אם נמצאים בסביבת ברירת המחדל.
GAE_INSTANCE		המזהה של המופע שבו השירות פועל.
GAE_MEMORY_MB		נפח הזיכרון שזמין לתהליך של האפליקציה, ב-MB.
‫NODE_ENV (זמין רק בסביבת זמן הריצה של Node.js)		אחרי פריסת השירות, מגדירים אותו כסביבת ייצור.
GAE_RUNTIME		סביבת זמן הריצה שצוינה בקובץ app.yaml.

נתיבים נפוצים של שרת מטא-נתונים

נתיב	תיאור	דוגמה
/computeMetadata/v1/project/project-id	מזהה הפרויקט שאליו שייך השירות	test_project
/computeMetadata/v1/project/numeric-project-id	מספר הפרויקט שאליו שייך השירות	12345678912
/computeMetadata/v1/instance/id	מזהה ייחודי של מופע מאגר התגים (זמין גם ביומנים).	16a61494692b7432806a16 (מחרוזת של תווים אלפאנומריים)
/computeMetadata/v1/instance/region ** לא זמין בסביבה הגמישה ב-App Engine	האזור שבו השירות הזה זמין. הערך שמוחזר הוא projects/PROJECT_NUMBER/regions/REGION	projects/12345678912/regions/us-central1
/computeMetadata/v1/instance/service-accounts/default/email	כתובת האימייל של חשבון השירות של זמן הריצה של השירות הזה.	service_account@test_project.iam.gserviceaccount.com
/computeMetadata/v1/instance/service-accounts/default/token	יוצר אסימון גישה מסוג OAuth2 לחשבון השירות של השירות הזה. נקודת הקצה הזו תחזיר תגובת JSON עם מאפיין access_token.	{ "access_token":"<TOKEN>", "expires_in":1799, "token_type":"Bearer" }

המאמרים הבאים

• מדריך למתחילים: פריסת שירות אינטרנט באמצעות Cloud Run
• האם האפליקציה שלי מתאימה ל-Cloud Run?
• העברת דומיין בהתאמה אישית ב-App Engine ל-Cloud Load Balancing
• מקורות מידע נוספים:
  • העברה מ-App Engine ל-Cloud Run באמצעות Docker‏ (Python: codelab, video, Java: codelab)
  • העברה מ-App Engine ל-Cloud Run באמצעות Buildpacks (Python: codelab, video, Java: codelab)