מאפס עד סקייל עם שירות אלחוטי ב- AWS

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

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

ללא שרתים

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

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

הסקלה אוטומטית

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

מיקוד בחדשנות

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

יעילות עלות

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

זמן מהיר לשוק

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

תחזור תחזור תחזור תחזורתחזור תחזור תחזור תחזורהקיצור בתחזוקה הפעילה

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

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

בניית ממשקי שירות רשת עם AWS "שרת-פחות"

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

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

קיימים שני רכיבים עיקריים בארכיטקטורה זו — חישוב ואחסון.

מחשוב ללא שרתים

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

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

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

אחסון ללא שרתים

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

ספקי ענן ראשיים מציעים מגוון רחב של אפשרויות אחסון לא-שרתי לצרכים ספציפיים, כגון S3, ElastiCache, Aurora ועוד.

מקרי שימוש אחרים

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

עיבוד נתונים

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

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

עיבוד קבצים בזמן אמת

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

אתגרים

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

התחלת קריר

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

ניטור ואיתור באגים

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

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

מסקנה

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