העברה מ-AWS אל Google Cloud: העברה מ-AWS Lambda אל Cloud Run

Last reviewed 2025-12-31 UTC

‫Google Cloud Google Cloud מספקת כלים, מוצרים, הנחיות ושירותים מקצועיים שיעזרו לכם להעביר עומסי עבודה ללא שרת (serverless) מ-Amazon Web Services‏ (AWS) Lambda אל Google Cloud. למרות ש- Google Cloud מספקת כמה שירותים שבהם אפשר לפתח ולפרוס אפליקציות ללא שרת (serverless), המאמר הזה מתמקד במיגרציה אל Cloud Run, סביבת זמן ריצה ללא שרת. יש דמיון בין AWS Lambda לבין Cloud Run, למשל הקצאת משאבים אוטומטית, שינוי גודל על ידי ספק שירותי ענן ומודל תמחור של תשלום לפי שימוש.

במאמר הזה מוסבר איך לתכנן, להטמיע ולאמת תוכנית להעברת עומסי עבודה בלי שרת (serverless) מ-AWS Lambda ל-Cloud Run. בנוסף, הוא כולל הנחיות למי שרוצה להעריך את היתרונות הפוטנציאליים של מעבר כזה ואת התהליך שלו.

המסמך הזה הוא חלק מסדרה של מסמכים בנושא מעבר מ-AWS אלGoogle Cloud , והוא כולל את המסמכים הבאים:

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

כדי לבצע את ההעברה אל Google Cloud, מומלץ לפעול לפי מסגרת ההעברה שמתוארת במאמר העברה אל Google Cloud: תחילת העבודה.

התרשים הבא מדגים את התהליך של המעבר.

נתיב העברה עם ארבעה שלבים.

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

  1. הערכה וגילוי של עומסי העבודה והנתונים.
  2. מתכננים ובונים בסיס ב- Google Cloud.
  3. העברת עומסי העבודה והנתונים אל Google Cloud.
  4. אופטימיזציה של Google Cloud הסביבה

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

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

העברת עומסי עבודה בלי שרת (serverless) לרוב לא מסתכמת רק בהעברת פונקציות מספק שירותי ענן אחד לספק שירותי ענן אחר. אפליקציות מבוססות-ענן מסתמכות על רשת של שירותים שמחוברים ביניהם, ולכן יכול להיות שיהיה צורך להחליף שירותים תלויים של AWS בשירותים של Google Cloud כדי לבצע מיגרציה מ-AWS ל- Google Cloud . לדוגמה, נניח שפונקציית Lambda שלכם מבצעת אינטראקציה עם Amazon SQS ו-Amazon SNS. כדי להעביר את הפונקציה הזו, סביר להניח שתצטרכו להשתמש ב-Pub/Sub וב-Cloud Tasks כדי להשיג פונקציונליות דומה.

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

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

תכננו את ההעברה בצורה אסטרטגית. אל תתייחסו להעברה כאל אירוח מחדש (lift and shift). אפשר להשתמש בהעברה כהזדמנות לשפר את העיצוב הכולל ואת איכות הקוד של האפליקציה בלי שרת (serverless).

הערכת סביבת המקור

בשלב ההערכה, קובעים את הדרישות והתלות כדי להעביר את סביבת המקור אל Google Cloud.

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

שלב ההערכה כולל את המשימות הבאות:

  1. יוצרים מלאי מקיף של עומסי העבודה.
  2. מקטלגים את עומסי העבודה בהתאם למאפיינים ולתלות שלהם.
  3. הדרכה ולימוד של הצוותים בנושא Google Cloud.
  4. יצירת ניסויים והוכחות היתכנות ב- Google Cloud.
  5. חישוב עלות הבעלות הכוללת (TCO) של סביבת היעד.
  6. בוחרים את אסטרטגיית ההעברה של עומסי העבודה.
  7. בוחרים את כלי ההעברה.
  8. מגדירים את תוכנית ההעברה ואת לוח הזמנים.
  9. בודקים את תוכנית ההעברה.

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

יצירת מלאי של עומסי עבודה ב-AWS Lambda

כדי להגדיר את היקף ההעברה, יוצרים מלאי ואוספים מידע על עומסי העבודה של AWS Lambda.

כדי ליצור את המלאי של עומסי העבודה של AWS Lambda, מומלץ לבצע את הפעולות הבאות:

  1. כדי לגלות את נכסי AWS Lambda, משתמשים בMigration Center. Migration Center הוא פלטפורמה מאוחדת שלGoogle Cloudשעוזרת לכם להאיץ את המעבר המלא לענן מהסביבה הנוכחית שלכם אל Google Cloud.

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

  3. כדי לבדוק את היומנים, משכי הזמן, ההפעלות המקבילות והשגיאות של הפעלות AWS Lambda מהזמן האחרון, משתמשים ב-CloudWatch. ‫CloudWatch מספק כמה סוגים של מדדים ל-AWS Lambda. מידע נוסף על צפייה במדדים של AWS Lambda זמין במאמר בנושא צפייה במדדים של פונקציות AWS Lambda.

  4. כדי להעריך את מלאי עומסי העבודה שלכם ב-AWS Lambda, אתם יכולים להשתמש ב-Gemini CLI. לדוגמה, אתם יכולים להוסיף את קובצי המלאי שמפרטים את עומסי העבודה של AWS Lambda להקשר של Gemini CLI, ואז לבקש מ-Gemini לעזור לכם להעריך את האובייקטים האלה. מידע נוסף זמין במאמר העברות ל-Google Cloud שמבוססות על Gemini.

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

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

תרחיש לדוגמה ועיצוב

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

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

מאגר קוד מקור

אם אתם צריכים לבצע רפקטורינג בעומסי העבודה של AWS Lambda כדי להפוך אותם לתואמים ל-Cloud Run, כדאי ליצור מלאי של קוד המקור של פונקציות AWS Lambda. כדי ליצור את המלאי הזה, צריך לעקוב אחרי בסיס הקוד, שבדרך כלל מאוחסן במערכות לניהול גרסאות כמו Git או בפלטפורמות פיתוח כמו GitHub או GitLab. מלאי קוד המקור חיוני לתהליכי DevOps, כמו צינורות של אינטגרציה רציפה (CI) ופיתוח רציף (CD), כי גם התהליכים האלה יצטרכו לעבור עדכון כשמבצעים מיגרציה ל-Cloud Run.

פריטי מידע שנוצרו בתהליך פיתוח (Artifacts) של פ

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

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

הפעלה, טריגרים ופלט

‫AWS Lambda תומך בכמה מנגנוני הפעלה, כמו טריגרים, ובמודלים שונים של הפעלה, כמו הפעלה סינכרונית והפעלה אסינכרונית. לכל עומס עבודה של AWS Lambda, מומלץ לאסוף את המידע הבא שקשור לטריגרים ולהפעלות:

  • הטריגרים והמיפויים של מקורות האירועים שמפעילים את עומס העבודה.
  • האם עומס העבודה תומך בהפעלות סינכרוניות ואסינכרוניות.
  • כתובות ה-URL של עומסי העבודה ונקודות הקצה (endpoint) של HTTP(S).

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

  • משאבי היעד שאליהם עומס העבודה עשוי לשלוח אירועים.
  • יעדים שמקבלים רשומות מידע עבור הפעלות אסינכרוניות.
  • הפורמט של האירועים שעומס העבודה מעבד.
  • איך עומס העבודה שלכם ב-AWS Lambda והתוספים שלו מקיימים אינטראקציה עם ממשקי API של AWS Lambda או עם ממשקי API אחרים של AWS.

כדי שעומסי העבודה שלכם ב-AWS Lambda יפעלו, יכול להיות שהם יאחסנו נתונים קבועים ויבצעו אינטראקציה עם שירותים אחרים של AWS. לכל עומס עבודה של AWS Lambda, מומלץ לאסוף את המידע הבא על נתונים ושירותים אחרים:

  • האם עומס העבודה ניגש לעננים וירטואליים פרטיים (VPC) או לרשתות פרטיות אחרות.
  • איך עומס העבודה מאחסן נתונים קבועים, למשל באמצעות אחסון נתונים זמני ו-Amazon Elastic File System ‏ (EFS).

סביבות זמן ריצה והפעלה

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

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

אם עומסי העבודה של AWS Lambda פועלים בסביבות זמן ריצה ספציפיות לשפה, כדאי לשקול את הנקודות הבאות לגבי כל עומס עבודה של AWS Lambda:

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

הגדרת עומס עבודה

כדי להגדיר את עומסי העבודה בזמן ההעברה מ-AWS Lambda ל-Cloud Run, מומלץ לבדוק איך הגדרתם כל עומס עבודה ב-AWS Lambda.

לכל עומס עבודה של AWS Lambda, אוספים מידע על הגדרות המקביליות והמדרגיות הבאות:

  • הגדרות בו-זמניות.
  • הגדרות המדרגיות.
  • ההגדרה של המופעים של עומס העבודה, מבחינת כמות הזיכרון הזמין וזמן הביצוע המקסימלי המותר.
  • האם עומס העבודה משתמש ב-AWS Lambda SnapStart, במקבילות שמורות או במקבילות שהוקצו כדי להפחית את זמן האחזור.
  • משתני הסביבה שהגדרתם, וגם אלה ש-AWS Lambda מגדיר ועומס העבודה תלוי בהם.
  • התגים ובקרת הגישה מבוססת-המאפיינים.
  • מכונת המצבים לטיפול בתנאים חריגים.
  • קובצי הבסיס וקובצי ההגדרות (כמו Dockerfile) של חבילות פריסה שמשתמשות בקובצי אימג' של קונטיינרים.

בקרת גישה והרשאות

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

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

דרישות רגולטוריות ותאימות

כדי להבין את דרישות התאימות והרגולציה של כל עומס עבודה של AWS Lambda, צריך לבצע את הפעולות הבאות:

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

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

הערכת תהליכי הפריסה והתפעול

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

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

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

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

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

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

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

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

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

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

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

  • אימות. בודקים איך מתבצע האימות מול סביבת המקור.

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

השלמת ההערכה

אחרי שיוצרים את המלאי מסביבת AWS Lambda, משלימים את שאר הפעילויות בשלב ההערכה, כפי שמתואר במאמר מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה.

תכנון ובנייה של הבסיס

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

  • תמיכה בעומסי העבודה בסביבת Google Cloud .
  • כדי להשלים את ההעברה, צריך לחבר את סביבת המקור ואת סביבת Google Cloud היעד.

שלב התכנון והבנייה מורכב מהמשימות הבאות:

  1. בניית היררכיית משאבים.
  2. מגדירים את ניהול הזהויות והרשאות הגישה (IAM) של Google Cloud.
  3. הגדרת חיוב.
  4. הגדרת חיבור לרשת.
  5. חיזוק האבטחה.
  6. הגדרת רישום ביומן, מעקב והתראות.

מידע נוסף על כל אחת מהמשימות האלה זמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.

העברת עומסי עבודה של AWS Lambda

כדי להעביר את עומסי העבודה מ-AWS Lambda ל-Cloud Run, צריך לבצע את הפעולות הבאות:

  1. תכנון, הקצאה והגדרה של סביבת Cloud Run.
  2. במקרה הצורך, אפשר לבצע רפקטורינג בעומסי העבודה של AWS Lambda כדי להפוך אותם לתואמים ל-Cloud Run.
  3. שינוי מבנה של תהליכי הפריסה והתפעול כדי לפרוס את עומסי העבודה ב-Cloud Run ולעקוב אחריהם.
  4. העברת הנתונים שדרושים לעומסי העבודה של AWS Lambda.
  5. בודקים את תוצאות ההעברה מבחינת פונקציונליות, ביצועים ועלות.

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

תכנון, הקצאה והגדרה של סביבת Cloud Run

השלב הראשון בתהליך ההעברה הוא עיצוב סביבת Cloud Run כך שתוכל לתמוך בעומסי העבודה שאתם מעבירים מ-AWS Lambda.

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

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

בחירת המשאבים המתאימים ב-Cloud Run

לכל עומס עבודה של AWS Lambda שרוצים להעביר, בוחרים את משאב Cloud Run המתאים לפריסת עומסי העבודה. ‫Cloud Run תומך במשאבים העיקריים הבאים:

  • שירותי Cloud Run: משאב שמארח סביבת זמן ריצה בקונטיינר, חושף נקודת קצה ייחודית ומתאים אוטומטית את תשתית הבסיס בהתאם לביקוש.
  • משימות Cloud Run: משאב שמבצע קונטיינר אחד או יותר עד לסיום.

בטבלה הבאה מפורט המיפוי של משאבי AWS Lambda למשאבי Cloud Run העיקריים האלה:

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

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

תכנון ההגדרה של משאבי Cloud Run

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

טריגרים של שירותים ב-Cloud Run והפעלת משימות

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

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

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

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

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

תכונה של AWS Lambda תכונה של Cloud Run
טריגר HTTPS (כתובות URL של פונקציות) הפעלת HTTPS
טריגר HTTP/2 (נתמך באופן חלקי באמצעות שער API חיצוני) הפעלת HTTP/2 (נתמך באופן מובנה)
‫WebSockets (נתמך באמצעות שער API חיצוני) ‫WebSockets (נתמך באופן מקורי)
לא רלוונטי (אין תמיכה בחיבורי gRPC) חיבורי gRPC
הפעלה אסינכרונית שילוב עם Cloud Tasks
הפעלה מתוזמנת שילוב עם Cloud Scheduler
טריגר מבוסס-אירועים בפורמט אירועים קנייני הפעלה מבוססת-אירועים בפורמט CloudEvents
שילוב של Amazon SQS ו-Amazon SNS שילוב עם Pub/Sub
AWS Lambda Step Functions שילוב של תהליכי עבודה
הגדרת משאבים ב-Cloud Run

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

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

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

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

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

תכונה של AWS Lambda תכונה של Cloud Run
מקביליות מוקצית מינימום מכונות
מקבילות שמורה לכל מופע
(מאגר המקבילות משותף בין פונקציות AWS Lambda בחשבון AWS שלכם).		 מספר מקסימלי של מופעים לכל שירות
לא רלוונטי (לא נתמך, בקשה אחת ממופה למופע אחד) בקשות מקבילות לכל מופע
לא רלוונטי (תלוי בהקצאת הזיכרון) הקצאת CPU
הגדרות מדרגיות שינוי גודל אוטומטי של מופעים לשירותים
מקביליות למשימות
הגדרת המכונה (מעבד, זיכרון) מגבלות על יחידת עיבוד מרכזית (CPU) וזיכרון
משך ההפעלה המקסימלי הזמן הקצוב לתפוגת הבקשה לשירותים
הזמן הקצוב לתפוגת המשימה לעבודות
AWS Lambda SnapStart חימום מוגבר של המעבד בזמן ההפעלה
משתני סביבה משתני סביבה
אחסון נתונים זמני חיבורים של נפחים בזיכרון
חיבורים ל-Amazon Elastic File System טעינת נפח אחסון של NFS
אין תמיכה בהרכבת נפחי אחסון ב-S3 טעינת נפח אחסון של Cloud Storage
‫AWS Secrets Manager בעומסי עבודה של AWS Lambda סודות
כתובות URL של עומסי עבודה ונקודות קצה (endpoint) של HTTP(S) כתובות URL שמוקצות אוטומטית
שילובים של Cloud Run עם מוצרים Google Cloud
סשנים קבועים (באמצעות מאזן עומסים חיצוני) זיקה לסשן (session affinity)
מוקדמות Revisions

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

אבטחה ובקרת גישה ב-Cloud Run

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

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

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

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

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

תכונה של AWS Lambda תכונה של Cloud Run
בקרת גישה באמצעות ניהול זהויות והרשאות גישה ב-AWS בקרת גישה באמצעות IAM של Google Cloud
תפקיד הרצה Google Cloudתפקיד IAM
גבולות הרשאות Google Cloudהרשאות IAM וקהלים מותאמים אישית
אמצעי בקרה לניהול נתונים Organization Policy Service
חתימת קוד Binary authorization
גישה מלאה ל-VPC בקרת גישה מפורטת ליציאה מ-VPC

הקצאה והגדרה של משאבי Cloud Run

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

ארגון מחדש של עומסי עבודה ב-AWS Lambda

כדי להעביר את עומסי העבודה שלכם מ-AWS Lambda ל-Cloud Run, יכול להיות שתצטרכו לבצע בהם שינויים. לדוגמה, אם עומס עבודה מבוסס-אירועים מקבל טריגרים שמכילים אירועים של Amazon CloudWatch, יכול להיות שתצטרכו לשנות את מבנה עומס העבודה הזה כדי שהוא יקבל אירועים בפורמט CloudEvents.

כדי לעזור לכם לבצע ארגון הקוד מחדש (Refactoring) בעומסי העבודה של AWS Lambda, אנחנו ממליצים להשתמש ב-Gemini Code Assist וב-Gemini CLI. מידע נוסף זמין במאמר העברות ל-Google Cloud שמבוססות על Gemini.

יש כמה גורמים שיכולים להשפיע על כמות ארגון הקוד מחדש (Refactoring) שצריך לבצע בכל עומס עבודה של AWS Lambda, למשל:

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

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

שיפור תהליכי הפריסה והתפעול

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

  • הקצאה והגדרה של משאבים בסביבת Google Cloud היעד במקום הקצאת משאבים בסביבת המקור.
  • מפתחים ומגדירים עומסי עבודה ומפריסים אותם ב- Google Cloudבמקום להפריס אותם בסביבת המקור.

בשלב ההערכה, מוקדם יותר בתהליך הזה, אספתם מידע על התהליכים האלה.

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

  • יכול להיות שיישמתם את התהליכים האלה בסביבת המקור, ואתם מתכוונים לעצב וליישם תהליכים דומים ב- Google Cloud. לדוגמה, אפשר לבצע רפקטורינג בתהליכים האלה כדי להשתמש ב-Cloud Build, ב-Cloud Deploy וב-Infrastructure Manager.
  • יכול להיות שהטמעתם את התהליכים האלה בסביבת צד שלישי אחרת מחוץ לסביבת המקור. במקרה כזה, צריך לשנות את התהליכים האלה כך שיפעלו בסביבת Google Cloud היעד ולא בסביבת המקור.
  • שילוב של הגישות הקודמות.

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

למידע נוסף על תכנון והטמעה של תהליכי פריסה ב- Google Cloud:

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

  1. הקצאת מאגרי פריטי מידע שנוצרו בתהליך פיתוח (Artifact) ב- Google Cloud. לדוגמה, אפשר להשתמש ב-Artifact Registry כדי לאחסן פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ויחסי תלות בגרסת build.
  2. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים גם בסביבת המקור וגם ב-Artifact Registry.
  3. מבצעים רפקטורינג בתהליכי הפריסה כדי לפרוס את עומסי העבודה בסביבת היעד שלGoogle Cloud . לדוגמה, אפשר להתחיל בפריסה של קבוצת משנה קטנה של עומסי העבודה ב- Google Cloud, באמצעות ארטיפקטים שמאוחסנים ב-Artifact Registry. לאחר מכן, מגדילים בהדרגה את מספר עומסי העבודה שנפרסים ב- Google Cloud, עד שכל עומסי העבודה להעברה יפעלו ב-Google Cloud.
  4. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים רק ב-Artifact Registry.
  5. במקרה הצורך, מעבירים גרסאות קודמות של הארטיפקטים כדי לפרוס ממאגרי המידע בסביבת המקור אל Artifact Registry. לדוגמה, אפשר להעתיק קובצי אימג' של קונטיינרים אל Artifact Registry.
  6. להוציא משימוש את המאגרים בסביבת המקור כשאין בהם יותר צורך.

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

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

אם אתם משתמשים ב-Artifact Registry כדי לאחסן את הארטיפקטים, מומלץ להגדיר אמצעי בקרה שיעזרו לכם לאבטח את מאגרי הארטיפקטים, כמו בקרת גישה, מניעת זליגת נתונים, בדיקת נקודות חולשה ו-Binary Authorization. מידע נוסף זמין במאמר בנושא שליטה בגישה והגנה על ארטיפקטים.

שיפור תהליכי התפעול

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

‫Cloud Run משולב עם שירותי התפעול הבאים:

העברת נתונים

בשלב ההערכה בתהליך הזה, אמורים לקבוע אם עומסי העבודה של AWS Lambda שאתם מעבירים תלויים בנתונים שנמצאים בסביבת AWS או יוצרים נתונים כאלה. לדוגמה, יכול להיות שהחלטתם שאתם צריכים להעביר נתונים מ-AWS S3 ל-Cloud Storage, או מ-Amazon RDS ומ-Aurora ל-Cloud SQL ול-AlloyDB ל-PostgreSQL. מידע נוסף על העברת נתונים מ-AWS אל Google Cloudזמין במאמר מעבר מ-AWS אל Google Cloud: תחילת העבודה.

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

אימות תוצאות ההעברה

אימות ההעברה של עומס העבודה הוא לא אירוע חד-פעמי, אלא תהליך מתמשך. חשוב להתמקד בבדיקות ובוולידציה לפני, במהלך ואחרי המעבר מ-AWS Lambda ל-Cloud Run.

כדי להבטיח שההעברה תתבצע בהצלחה, עם ביצועים אופטימליים ומינימום שיבושים, מומלץ להשתמש בתהליך הבא כדי לאמת את עומסי העבודה שמועברים מ-AWS Lambda אל Cloud Run:

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

אופטימיזציה של Google Cloud הסביבה

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

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

חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.

מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים מעבר אל Google Cloud: אופטימיזציה של הסביבה וGoogle Cloud Well-Architected Framework: אופטימיזציה של ביצועים.

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

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: