ניתוח מפורט של AWS Lambda

תרגום המאמר הוכן במיוחד עבור תלמידי הקורס "שירותי ענן". מעוניינים להתפתח בכיוון זה? צפו בכיתת המאסטר מאת אגור זואב (TeamLead ב-InBit) "שירות AWS EC2" והצטרפו לקבוצת הקורסים הבאה: מתחילים ב-26 בספטמבר.

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

AWS למבדה

AWS Lambda הוא שירות מחשוב נטול שרתים מונע אירועים המאפשר לך להריץ קוד מבלי לספק או לנהל שרתים ולהרחיב שירותי AWS אחרים באמצעות לוגיקה מותאמת אישית. Lambda מגיבה אוטומטית לאירועים שונים (הנקראים טריגרים), כגון בקשות HTTP דרך Amazon API Gateway, שינויים בנתונים ב-Amazon S3 buckets או בטבלאות Amazon DynamoDB; או שאתה יכול להריץ את הקוד שלך באמצעות קריאות API באמצעות AWS SDK ומעברי מצב ב-AWS Step Functions.

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

מתי לעבור ללמבדה?

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

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

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

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

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

אבטחה

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

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

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

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

מודל אחריות משותפת ישים ל-AWS Lambda

זמן ריצה של למדה

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

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

המישור השני הוא מישור הנתונים. לו, כמו מטוס הבקרה, יש משימות משלו. מישור הבקרה מספק ממשקי API לניהול פונקציות (CreateFunction, UpdateFunctionCode) ושולט כיצד Lambda מתקשרת עם שירותי AWS אחרים. מישור הנתונים שולט ב-Invoke API, המריץ פונקציות של Lambda. לאחר קריאת פונקציה, מישור הבקרה מקצה או בוחר סביבת זמן ריצה קיימת שהוכנה מראש לאותה פונקציה, ולאחר מכן מבצעת בה את הקוד.

AWS Lambda תומכת במגוון שפות תכנות, כולל Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 ואחרות, דרך סביבות זמן הריצה המתאימות. AWS מעדכנת אותם באופן קבוע, מפיצה תיקוני אבטחה ומבצעת פעולות תחזוקה אחרות בסביבות אלו. Lambda מאפשרת לך להשתמש גם בשפות אחרות, בתנאי שאתה מיישם את זמן הריצה המתאים בעצמך. ואז תצטרכו לדאוג לתחזוקה שלו, כולל ניטור בטיחותו.

איך כל זה עובד ואיך השירות יבצע את הפונקציות שלך?

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

AWS Lambda דגם בידוד

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

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

המנגנונים הבאים משמשים כדי לבודד סביבות ביצוע שונות:

• cgroups - הגבלת גישה למשאבי CPU, זיכרון, אחסון ורשת עבור כל סביבת זמן ריצה;
• מרחבי שמות - קיבוץ מזהי תהליך, מזהי משתמש, ממשקי רשת ומשאבים אחרים המנוהלים על ידי ליבת לינוקס. כל זמן ריצה פועל במרחב השמות שלו;
• seccomp-bpf - מגביל את קריאות המערכת שניתן להשתמש בהן בזמן הריצה;
• iptables וטבלאות ניתוב - בידוד של סביבות ביצוע זו מזו;
• chroot - מספק גישה מוגבלת למערכת הקבצים הבסיסית.

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

למרות שמספר זמני ריצה של אותו חשבון AWS יכולים לפעול ב-microVM יחיד, בשום פנים ואופן לא ניתן לשתף microVMs בין חשבונות AWS שונים. AWS Lambda משתמשת בשני מנגנונים בלבד כדי לבודד מיקרו-VMs: מופעי EC2 ו-Firecracker. בידוד אורחים בלמבדה על סמך מקרי EC2 קיים מאז 2015. Firecracker הוא hypervisor חדש בקוד פתוח שתוכנן במיוחד על ידי AWS לעומסי עבודה ללא שרת והוצג ב-2018. החומרה הפיזית המריץ microVMs מתחלקת בין עומסי עבודה בין חשבונות שונים.

שמירת סביבות ומצבי תהליך

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

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

העברת נתונים שיחות

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

במהלך קריאות תגובה לבקשה, המטען זורם מ-API לעיבוד בקשות (API Caller), כגון AWS API Gateway או AWS SDK, אל מאזן העומס, ולאחר מכן אל שירות השיחות של Lambda (Invoke Service). האחרון קובע את הסביבה המתאימה לביצוע הפונקציה ומעביר לשם את המטען להשלמת הקריאה. מאזן העומס מקבל תעבורה מוגנת TLS דרך האינטרנט. התנועה בתוך שירות Lambda - לאחר מאזן העומס - עוברת דרך VPC פנימי באזור AWS ספציפי.

מודל עיבוד שיחות AWS Lambda: מצב בקשה-תגובה

ניתן לבצע שיחות לאירועים באופן מיידי או להוסיף לתור. במקרים מסוימים, התור מיושם באמצעות Amazon SQS (Amazon Simple Queue Service), המעביר שיחות לשירות מילוי השיחות של Lambda באמצעות תהליך סקר פנימי. התעבורה המשודרת מוגנת על ידי TLS, ואין הצפנה נוספת של נתונים המאוחסנים באמזון SQS.

קריאות אירועים לא מחזירות תגובות - ה- Lambda Worker פשוט מתעלם מכל מידע תגובה. שיחות מבוססות אירועים מאמזון S3, Amazon SNS, CloudWatch ומקורות אחרים מעובדות על ידי Lambda במצב אירועים. שיחות מזרמי אמזון Kinesis ו-DynamoDB, תורי SQS, מאזן עומס יישומים ושיחות API Gateway מעובדות בצורה של תגובה לבקשה.

ניטור

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

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

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

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

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

מסקנה

AWS Lambda מציעה סט רב עוצמה של כלים לבניית יישומים מאובטחים וניתנים להרחבה. רבים משיטות האבטחה והתאימות ב-AWS Lambda זהות לאלו בשירותי AWS אחרים, אם כי יש יוצאים מן הכלל. החל ממארס 2019, Lambda תואמת ל-SOC 1, SOC 2, SOC 3, PCI DSS, תאימות לחוק הניידות והאחריות של ביטוח בריאות (HIPAA) ותקנות אחרות. לכן, כאשר אתה שוקל ליישם את היישום הבא שלך, שקול את שירות AWS Lambda - הוא עשוי להיות המתאים ביותר למשימה שלך.

מקור: www.habr.com