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

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

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

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

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

  • אופטימיזציה באמצעות תכונות מובנות: כדאי לבדוק אם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 היא פלטפורמה מאוחדת של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:

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

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

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

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

מאגר המקורות של הקוד

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

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

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

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

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

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

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

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

    • משאבים ב-Terraform Provider: מתחילים מאפס באמצעות אבני בניין בסיסיות. Google Cloud
    • מודולים ותוכניות לניהול של Terraform ב- Google Cloud: מתחילים מבסיס של מודולים של Terraform עם דעות מוצקות. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.
    • תוכנית Enterprise Foundations Blueprint: מתחילים מיסודות ומתחומי נחיתה מוגדרים. הגישה הזו מבוססת על מודולים ותוכניות לניהול של Terraform ב- Google Cloud.
    • ‫Cloud Foundation Fabric: מתחילים עם בסיס מוטה ואזורי נחיתה. ‫Cloud Foundation Fabric היא הטמעה עצמאית שמשתמשת במודולים משלה של Terraform. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.

השלמת ההערכה

אחרי שיוצרים את המלאי מסביבת 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 חיצוני) ‫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
בו-זמניות (concurrency) שהוקצתה מינימום מכונות
מקבילות שמורה לכל מופע
(מאגר המקבילות משותף בין פונקציות AWS Lambda בחשבון AWS שלכם).		 מספר מקסימלי של מופעים לכל שירות
לא רלוונטי (לא נתמך, בקשה אחת ממופה למופע אחד) בקשות מקבילות לכל מכונה
לא רלוונטי (תלוי בהקצאת הזיכרון) הקצאת מעבד (CPU)
הגדרות מדרגיות התאמה אוטומטית של גודל המופע לשירותים
מקביליות למשימות
הגדרת המכונה (מעבד, זיכרון) מגבלות על יחידת עיבוד מרכזית (CPU) וזיכרון
משך ההפעלה המקסימלי הזמן הקצוב לתפוגת הבקשה לשירותים
הזמן הקצוב לתפוגת המשימה לעבודות
AWS Lambda SnapStart תוספת מעבד (CPU) בהפעלה
משתני סביבה משתני סביבה
אחסון נתונים זמני חיבורים של נפחים בזיכרון
חיבורים ל-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 בקרת גישה באמצעות IAM של Google Cloud
תפקיד ביצוע Google Cloud's IAM role
גבולות הרשאות 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.

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

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

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

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

שינוי מבנה של תהליכי פריסה ותפעול

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

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

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

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

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

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

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

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

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

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

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

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

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

כחלק מהמעבר ל-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: אופטימיזציה של ביצועים.

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

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

מחברים:

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