🥇ללא שרת על ידי מתלים

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

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

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

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

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

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

בואו נראה איך יראה תהליך פיתוח האפליקציות כעת.

מהצד של היזם

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

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

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

יש לבצע פונקציות ללא שרת בפרק זמן קצר (פסק זמן), אשר נקבע על ידי ספק השירות. לדוגמה, עבור AWS פסק הזמן הוא 15 דקות. המשמעות היא שפונקציות ארוכות טווח יצטרכו להשתנות כדי להתאים לדרישות - זה מה שמבדיל את Serverless מטכנולוגיות פופולריות אחרות כיום (מכולות ו- Platform as a Service).

אנו מקצים אירוע לכל פונקציה. אירוע הוא טריגר לפעולה:

אירוע
הפעולה שהפונקציה מבצעת

תמונת מוצר הועלתה למאגר.
דחוס את התמונה והעלה לספרייה

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

הלקוח משלם עבור הסחורה
התחל בעיבוד התשלום

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

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

מהצד של הספק

בדרך כלל, מחשוב ללא שרת מוצע על ידי ספקי שירותי ענן. הם נקראים אחרת: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.

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

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

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

הספק בנה ויצר את מערכת הפונקציה כשירות (FaaS) על התשתית שלו:

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

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

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

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

מהצד של הקוד הפתוח

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

Google מציע למפתחים את כלי הקוד הפתוח שלו - סכין. IBM, RedHat, Pivotal ו-SAP השתתפו בפיתוחה;
יבמ עבד על פלטפורמה ללא שרת OpenWhisk, שהפך אז לפרויקט של קרן אפאצ'י;
מיקרוסופט פתח חלקית את קוד הפלטפורמה פונקציות תכלת.

התפתחויות מתנהלות גם בכיוון של מסגרות ללא שרתים. ללא קוביות и ביקוע פרוסים בתוך אשכולות Kubernetes שהוכנו מראש, OpenFaaS עובד גם עם Kubernetes וגם עם Docker Swarm. המסגרת פועלת כמעין בקר - לפי בקשה, היא מכינה סביבת ריצה בתוך האשכול, ואז משיקה שם פונקציה.

מסגרות משאירות מקום להגדרת הכלי כך שיתאים לצרכים שלך. לכן, ב-Kubeless, מפתח יכול להגדיר את פסק הזמן של ביצוע הפונקציה (ערך ברירת המחדל הוא 180 שניות). Fission, בניסיון לפתור את בעיית ההתחלה הקרה, מציעה להשאיר כמה מכולות פועלות כל הזמן (אם כי הדבר כרוך בעלויות השבתה של משאבים). ו-OpenFaaS מציעה קבוצה של טריגרים לכל טעם וצבע: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs ואחרים.

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

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

מנקודת מבט של יתרונות וחסרונות

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

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

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

כמו לכל טכנולוגיה, ל-Serverless יש חסרונות.

לדוגמה, חיסרון כזה עשוי להיות זמן ההתחלה הקרה (בממוצע עד שנייה אחת עבור שפות כמו JavaScript, Python, Go, Java, Ruby).

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

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

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

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

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

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

לא כל המערכות יוכלו לעבוד באמצעות סכימת Serverless.

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

ברוח זו, ברצוני לעבור בצורה חלקה לנושא השימוש בגישה ללא שרת.

מהצד של האפליקציה

עבור 2018, אחוז השימוש ללא שרת גדל פעם וחצי. בין החברות שכבר הטמיעו את הטכנולוגיה בשירותיהן נמצאות ענקיות שוק כמו טוויטר, PayPal, Netflix, T-Mobile, Coca-Cola. יחד עם זאת, עליכם להבין ש-Serverless אינו תרופת פלא, אלא כלי לפתרון מגוון מסוים של בעיות:

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

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

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

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

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

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

ללא שרת ו-Selectel

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

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

חומרים המשמשים במאמר:

מקור: www.habr.com

ללא שרת על מתלים