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

Last reviewed 2025-12-31 UTC

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

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

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

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

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

התרשים הבא ממחיש את נתיב תהליך המיגרציה שלכם.

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

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

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

למידע נוסף על השלבים של המסגרת הזו, קראו את המאמר Migrate to Google Cloud: Get started.

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

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

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

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

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

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

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

אחרי שיוצרים את המלאי, מומלץ לאסוף מידע על כל עומס עבודה של 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 של עומסי העבודה ונקודות הקצה (endpoints) של 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, ב-reserved concurrency או ב-provisioned concurrency כדי להפחית את זמן האחזור.
  • משתני הסביבה שהגדרתם, וגם אלה שמוגדרים על ידי AWS Lambda ועומס העבודה תלוי בהם.
  • התגים ובקרת הגישה שמבוססת על מאפיינים.
  • מכונת המצבים לטיפול בתנאים חריגים.
  • תמונות הבסיס וקובצי התצורה (כמו קובץ Docker) של חבילות פריסה שמשתמשות בקובצי אימג' של קונטיינרים.

אמצעי בקרת גישה והרשאות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תכנון, הקצאה והגדרה של סביבת 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 Gateway חיצוני) ‫WebSockets (נתמך באופן מקורי)
לא רלוונטי (אין תמיכה בחיבורי gRPC) חיבורי gRPC
הפעלה אסינכרונית שילוב עם Cloud Tasks
הפעלה מתוזמנת שילוב עם Cloud Scheduler
טריגר מבוסס-אירוע בפורמט אירוע קנייני הפעלה מבוססת-אירועים בפורמט CloudEvents
שילוב של Amazon SQS ו-Amazon SNS שילוב עם Pub/Sub
‫AWS Lambda Step Functions שילוב של Workflows
הגדרת המשאבים של 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)
הגדרות מדרגיות התאמה לעומס (autoscaling) של מכונות בשירותים
מקביליות במשימות
הגדרת המכונה (מעבד, זיכרון) מגבלות על המעבד (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)
מוקדמות גרסאות

בנוסף למאפיינים שמפורטים בטבלה הקודמת, כדאי גם להביא בחשבון את ההבדלים בין האופן שבו AWS Lambda ו-Cloud Run מקצים מכונות של סביבת ההפעלה. ‫AWS Lambda מקצה מכונה אחת לכל בקשה מקבילה. עם זאת, ב-Cloud Run אפשר להגדיר את מספר הבקשות בו-זמנית שמכונה יכולה לטפל בהן. כלומר, התנהגות ההקצאה של AWS Lambda מקבילה להגדרה של מספר הבקשות המקסימלי בו-זמנית לכל מכונה ל-1 ב-Cloud Run. אם מגדירים את המספר המקסימלי של בקשות מקבילות ליותר מ-1, אפשר לחסוך בעלויות באופן משמעותי כי המעבד והזיכרון של המכונה משותפים לבקשות המקבילות, אבל החיוב עליהן מתבצע רק פעם אחת. רוב מסגרות ה-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 Identity and Access Management בקרת גישה באמצעות IAM של Google Cloud
תפקיד הרצה תפקיד ה-IAM שלGoogle Cloud
גבולות ההרשאות הרשאות IAM וקהלים בהתאמה אישית שלGoogle Cloud
אמצעי בקרה לניהול נתונים שירות מדיניות הארגון
חתימת קוד Binary Authorization
גישה מלאה ל-VPC אמצעי בקרה פרטניים על הגישה לתעבורת נתונים יוצאת ב-VPC

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

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

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

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

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

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

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

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

שינוי מבנה הקוד (refactoring) של תהליכי הפריסה והתפעול

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

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

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

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

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

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

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

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

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

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

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

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

ארגון מחדש של תהליכי התפעול

כחלק מהמעבר ל-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: תחילת העבודה.

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

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

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

מחברים:

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