הפרקטיקות הטובות ביותר לפיתוח ב- AWS Lambda

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

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

‍

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

‍

פונקציות למבדה תמיד מתופעלות מ-VPC המשויך ל-AWS. כברירת מחדל, לפונקציה שלכם יש יכולת מלאה לבצע בקשות רשת לכל כתובת אינטרנט ציבורית – מה שכולל גישה לכל אחד מה-APIים הציבוריים של AWS. לדוגמא, הפונקציה שלכם יכולה להתקשר עם כאלו של AWS DynamoDB, PutItem, Query לתיעודים ועוד. אתם צריכים לאפשר לפונקציות שלכם גישת VPC רק כאשר אתם צריכים לתקשר עם משאב פרטי שנמצא בתת רשת פרטי, כמו למשל אינסטנס RDS.

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

‍

‍

‍

הפיצו קוד נפוץ לשכבת למבדה (קרי, AWS SDk)

‍

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

‍
שימו לב לגודל החבילה ולתלותיות שלה

‍

פונקציות למבדה דורשות שתאחדו את כל התלותיות הנחוצות (או שתצרפו שכבה) – ככל שחבילת ההפצה שלכם גדולה, כך הפונקציה שלכם תבצע "הפעלה קרה" לאט יותר. הסירו כל מה שלא נחוץ, כמו תיעוד או ספריות שאינן נחוצות. אם אתם משתמשים בפונקציות ג'אווה עם ה-AWS SDK, אתם רק צריכים לצוות את המודלים שאתם באמת צריכים להשתמש בהם – ולא את כל ה-SDK.

טוב:

<dependency>
   <groupId>software.amazon.awssdk</groupId>
   <artifactId>dynamodb</artifactId>
   <version>2.6.0</version>
</dependency>

רע:

<!-- https://mvnrepository.com/artifact/software.amazon.awssdk/aws-sdk-java -->
<dependency>
   <groupId>software.amazon.awssdk</groupId>
   <artifactId>aws-sdk-java</artifactId>
   <version>2.6.0</version>
</dependency>

‍

פקחו על ההסכמה הכללית בענן (וקבעו אזהרות מראש)

‍

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

‍

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

‍

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

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

‍

‍

מאת: מערכת IsraelClouds

רוצים להתעדכן בתכנים נוספים בנושאי AWS? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה