Cloud Run היא פלטפורמת אפליקציות מנוהלת להרצת קוד, פונקציות או קונטיינרים על גבי התשתית של Google, שאפשר להתאים לעומס.
בקיצור, Cloud Run מאפשר למפתחים להקדיש את הזמן שלהם לכתיבת הקוד, ולהשקיע מעט מאוד זמן בהפעלה, בהגדרה ובשינוי של קנה המידה של שירות Cloud Run. כדי להיות פרודוקטיביים עם Cloud Run, לא צריך ליצור אשכול או לנהל תשתית.
שירותים ומשימות
ב-Cloud Run, הקוד יכול לפעול כשירות או כמשימה..
בטבלה הבאה מוצגות האפשרויות שזמינות בכל סוג של משאב Cloud Run.
| משאב | תיאור |
|---|---|
| שירות | השירות מגיב לבקשות HTTP שנשלחות לנקודת קצה (endpoint) ייחודית ויציבה, באמצעות מופעים חסרי מצב (stateless) שמתבצעת בהם התאמה אוטומטית של קנה המידה על סמך מגוון מדדי מפתח. השירות גם מגיב לאירועים ולפונקציות. |
| משימה | מבצע משימות שניתנות להרצה מקבילית, שמופעלות באופן ידני או לפי לוח זמנים, ופועלות עד לסיום. |
שירותי Cloud Run
שירות Cloud Run מספק את התשתית שנדרשת להפעלת נקודת קצה אמינה של HTTPS. באחריותכם לוודא שהקוד מקשיב ביציאת TCP ומטפל בבקשות HTTP.
בתרשים הבא מוצג שירות Cloud Run שמריץ כמה מופעי קונטיינר כדי לטפל בבקשות ובאירועים מהלקוח באמצעות נקודת קצה של HTTPS.
שירות רגיל כולל את התכונות הבאות:
- נקודת קצה (endpoint) ייחודית של HTTPS לכל שירות
- לכל שירות ב-Cloud Run יש נקודת קצה של HTTPS בתת-דומיין ייחודי של דומיין
*.s3nsrun.fr– ואפשר גם להגדיר דומיינים מותאמים אישית. Cloud Run מנהל את TLS בשבילכם ותומך ב-WebSockets, ב-HTTP/2 (מקצה לקצה) וב-gRPC (מקצה לקצה). - התאמה מהירה לעומס (auto-scaling) על סמך בקשות
- Cloud Run מתרחב במהירות כדי לטפל בכל הבקשות הנכנסות או כדי לטפל בניצול מוגבר של המעבד (CPU) מחוץ לבקשות, אם הגדרת החיוב מוגדרת לחיוב מבוסס-אינסטנס. שירות יכול להתרחב במהירות עד אלף מופעים, או אפילו יותר אם תבקשו להגדיל את המכסה. אם הביקוש יורד, Cloud Run מסיר קונטיינרים לא פעילים. אם אתם חוששים לגבי עלויות או עומס יתר על מערכות במורד הזרם, אתם יכולים להגביל את המספר המקסימלי של המופעים.
- שינוי גודל ידני אופציונלי
- כברירת מחדל, Cloud Run מתאים את מספר המכונות באופן אוטומטי כדי לטפל בתעבורת נתונים גדולה יותר, אבל אפשר לשנות את ההתנהגות הזו באמצעות התאמה ידנית לעומס כדי לשלוט בהתנהגות ההתאמה לעומס.
- ניהול תנועה מובנה
כדי להקטין את הסיכון בפריסת גרסה חדשה, ב-Cloud Run אפשר לבצע השקה הדרגתית, כולל ניתוב תנועה נכנסת לגרסה האחרונה, חזרה לגרסה קודמת ופיצול תנועה לכמה גרסאות בו-זמנית.
לדוגמה, אפשר להתחיל בשליחת 1% מהבקשות לגרסה חדשה, ולהגדיל את האחוז הזה תוך מעקב אחרי נתוני הטלמטריה.
- שירותים ציבוריים ופרטיים
אפשר להגיע לשירות Cloud Run מהאינטרנט, או להגביל את הגישה בדרכים הבאות:
- מציינים מדיניות גישה באמצעות Cloud IAM.
- שימוש בהגדרות של תעבורת נכנסת כדי להגביל את הגישה לרשת האפשרות הזו שימושית אם רוצים לאפשר רק תעבורה פנימית מ-VPC ושירותים פנימיים.
- אפשר להשתמש רק במשתמשים מאומתים עם שרת proxy לאימות זהויות (IAP).
כדי להציג נכסים שניתנים לשמירה במטמון ממיקום קרוב יותר ללקוחות, אפשר להשתמש בשירות Cloud Run עם רשת להעברת תוכן (CDN), כמו Firebase Hosting ו-Cloud CDN.
התאמה להיקף הפרסום לאפס ומספר מינימלי של מופעים
כברירת מחדל, אם החיוב מוגדר כחיוב לפי מופע, Cloud Run מוסיף מופעים ומסיר מופעים באופן אוטומטי כדי לטפל בכל הבקשות הנכנסות או כדי לטפל בניצול מוגבר של המעבד (CPU) מחוץ לבקשות.
אם לא יתקבלו בקשות לשירות שלכם, גם המופע האחרון שנותר יוסר. התנהגות כזו נקראת בדרך כלל 'התאמה לאפס'. לאחר מכן, אם אין מופעים פעילים כשמתקבלת בקשה, Cloud Run יוצר מופע חדש. כך זמן התגובה לבקשות הראשונות האלה מתארך, בהתאם למהירות שבה מאגר התגים מוכן לטפל בבקשות.
כדי לשנות את ההתנהגות הזו, אפשר להשתמש באחת מהשיטות הבאות:
- הגדרת Cloud Run כך שמספר מינימלי של מופעים יישארו פעילים, כדי שהשירות לא יצטמצם לאפס מופעים
- שימוש בשינוי גודל ידני כדי לקבל יותר שליטה על שינוי הגודל.
תמחור לפי שימוש בשירותים
האפשרות של שינוי קנה מידה לאפס היא אטרקטיבית מסיבות כלכליות, כי אתם משלמים על המעבד והזיכרון שהוקצו למופע ברמת פירוט של 100 אלפיות השנייה. אם לא מגדירים מספר מינימלי של מופעים, לא מחויבים אם לא נעשה שימוש בשירות. יש תוכנית נדיבה בחינם. מידע נוסף זמין במאמר בנושא תמחור.
יש שתי הגדרות חיוב שאפשר להפעיל:
- מבוסס על בקשות
- אם מופע לא מעבד בקשות, לא תחויבו. אתם משלמים עמלה לכל בקשה.
- מבוסס-מופע
- אתם מחויבים על כל משך החיים של מופע. אין עמלה לכל בקשה.
יש תוכנית נדיבה בחינם. מידע נוסף על תמחור זמין במאמר בנושא הגדרות חיוב, שבו מוסבר איך להפעיל חיוב לפי בקשה או חיוב לפי מופע בשירות.
מערכת קבצים של קונטיינר חד-פעמי
מכונות ב-Cloud Run הן זמניות. לכל מאגר יש שכבת-על של מערכת קבצים שניתנת לכתיבה בזיכרון, שלא נשמרת אם המאגר נסגר. Cloud Run קובע מתי להפסיק לשלוח בקשה למופע ולסגור אותו, למשל כשמצמצמים את קנה המידה.
כדי לקבל אזהרה כש-Cloud Run עומד להשבית מופע, האפליקציה יכולה ללכוד את האות SIGTERM. כך הקוד יכול לרוקן מידע (Flush) את המאגרים המקומיים ולשמור את הנתונים מחנויות מקומיות במאגר נתונים חיצוני.
כדי לשמור קבצים באופן קבוע, צריך לשלב עם Cloud Storage או לטעון מערכת קבצים ברשת (NFS).
מתי כדאי להשתמש בשירותי Cloud Run
שירותי Cloud Run מתאימים לקוד שמטפל בבקשות, באירועים או בפונקציות. תרחישים לדוגמה:
- אתרים ואפליקציות אינטרנט
- ליצור את אפליקציית האינטרנט באמצעות הסטאק המועדף, לגשת למסד נתוני ה-SQL ולעבד דפי HTML דינמיים.
- ממשקי API ומיקרו-שירותים
- אפשר ליצור API בארכיטקטורת REST, API ל-GraphQL או מיקרו-שירותים פרטיים שמתקשרים באמצעות HTTP או gRPC.
משימות ב-Cloud Run
אם הקוד מבצע פעולה ואז מפסיק, למשל באמצעות סקריפט, אפשר להשתמש בעבודת Cloud Run כדי להריץ את הקוד. אפשר להריץ את העבודה משורת הפקודה באמצעות Google Cloud CLI, על ידי תזמון עבודה חוזרת.
משימות מערך הן דרך מהירה יותר להריץ משימות
עבודה יכולה להפעיל מופע יחיד כדי להריץ את הקוד – זו דרך נפוצה להריץ סקריפט או כלי.
עם זאת, אפשר גם להשתמש במערך של משימות, ולהתחיל במקביל הרבה מקרים זהים ועצמאיים. משימות מערך הן דרך מהירה יותר לעיבוד משימות שאפשר לפצל לכמה משימות עצמאיות.
בתרשים הבא אפשר לראות איך עבודה עם שבע משימות אורכת יותר זמן כשהיא מתבצעת ברצף, לעומת אותה עבודה כשאפשר לעבד ארבע משימות עצמאיות במקביל:
לדוגמה, אם משנים את הגודל של 1,000 תמונות מ-Cloud Storage וגוזרים אותן, עיבוד רציף שלהן יהיה איטי יותר מעיבוד מקביל שלהן עם הרבה מופעים, כש-Cloud Run מנהל את שינוי הגודל האוטומטי.
מתי כדאי להשתמש במשימות Cloud Run
משימות ב-Cloud Run מתאימות להרצת קוד שמבצע עבודה (משימה) ומפסיק לפעול כשהעבודה מסתיימת. הנה כמה דוגמאות:
- סקריפט או כלי
- להריץ סקריפט כדי לבצע העברות של מסדי נתונים או משימות תפעוליות אחרות.
- Array job
- ביצוע עיבוד מקבילי מאוד של כל הקבצים בקטגוריה של Cloud Storage.
- משימה מתוזמנת
- ליצור ולשלוח חשבוניות במרווחי זמן קבועים, או לשמור את התוצאות של שאילתת מסד נתונים כ-XML ולהעלות את הקובץ כל כמה שעות.