מחשוב ענן מוסבר: 11 מושגי הארכיטקטורה שאתם חייבים להכיר (כיתת אמן 4K).

מה מכסה הסרטון הזה

• - קיר הארכיטקטורה ותוכנית האב
• - 01. קנה מידה אנכי מול אופקי
• - 02. ארכיטקטורת איזון עומסים (L4 מול L7 & בדיקות תקינות)
• - 03. קנה מידה אוטומטי ואלסטיות
• - 04. Serverless (FaaS & Firecracker MicroVMs)

תמליל מתורגם

תורגם מהקריינות המקורית באנגלית. זמינות אודיו וכתוביות נשלטת על ידי YouTube.

- קיר הארכיטקטורה ותוכנית האב

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

0:34 בכיתת אמן זו, נעבור על כל התוכנית הארגונית: מ- קנה מידה ואיזון עומסים ועד ל-Serverless, ניתוק מונע-אירועים, היררכיות אחסון, ורשתות ענן. שלטו באחד עשר המושגים הללו, ותוכלו לתכנן כל Backend ב-AWS, GCP, או Azure. זהו The Daily Diff, מאחורי הקלעים.

- 01. קנה מידה אנכי מול אופקי

0:57 מושג מספר אחת: קנה מידה. כאשר היישום שלכם חווה גידול בתעבורה, יש לכם שתי דרכים מהותיות שונות לטפל בעומס: קנה מידה אנכי, או קנה מידה אופקי. קנה מידה אנכי, או הגדלה, פירושו לקחת את המכונה הקיימת שלכם ולהוסיף עוד משאבים: שדרוג מארבע ליבות מעבד לשלושים ושתיים, או החלפת שלושים ושניים גיגה-בייט של RAM ב- מאה עשרים ושמונה. קנה מידה אנכי אינו דורש שינויים ארכיטקטוניים כלל: הקוד שלכם

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

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

- 02. ארכיטקטורת איזון עומסים (L4 מול L7 & בדיקות תקינות)

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

2:47 מאזני עומסים פועלים בשתי שכבות רשת עיקריות. מאזני עומסי רשת של שכבה 4 פועלים בשכבת התעבורה, מנתבים מנות TCP ו-UDP גולמיות בהתבסס על כתובת IP ופורט עם חביון של מיקרו-שניות ומיליוני בקשות בשנייה. מאזני עומסי יישומים של שכבה 7 בודקים את פרוטוקול ה-HTTP עצמו: קוראים נתיבי URL, כותרות בקשה, קבצי Cookie, ומתודות HTTP. זה מאפשר ניתוב מבוסס נתיב: שליחת בקשות slash-api לאשכול ה-Backend שלכם ובקשות slash-static לאחסון

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

- 03. קנה מידה אוטומטי ואלסטיות

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

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

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 במשך שנים, צוותי שיווק הציגו את Serverless כקוד קסום הרץ בשמיים. במציאות, Serverless עדיין משתמש בשרתים - אבל אתם לא הבעלים, לא מתקנים, ולא משלמים עליהם כאשר לא רץ קוד. עם Function-as-a-Service כמו AWS Lambda או Google Cloud Functions, אתם כותבים פונקציית handler עצמאית. כאשר מתרחשת בקשת HTTP, העלאת קובץ S3, או שינוי מסד נתונים, זמן הריצה בענן מפעיל באופן ארעי

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

5:55 Serverless הוא בלתי מנוצח עבור צינורות אירועים ו-APIs ספורדיים, אבל גרוע עבור WebSockets מתמשכים או הרצות אימון של מספר שעות.

- 05. ארכיטקטורה מונעת אירועים (EDA וניתוק)

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

6:37 כאשר לקוח לוחץ על קנה, שירות התשלום אינו קורא לשירותים הנמוכים. הוא פשוט מפרסם אירוע בשם OrderPlaced ל- אוטובוס אירועים מרכזי כמו Amazon EventBridge או נושא SNS. התשלום מסתיים בחמישים מילי-שניות. עובדים נמוכים לתשלום, הפחתת מלאי וקבלות דוא"ל מושכים הודעות באופן עצמאי מתורי SQS הייעודיים שלהם. אם שירות הדוא"ל יורד לשעה, הודעות ממתינות בבטחה מאגורות בתור ללא אף הזמנה שנשמטה.

- 06. תזמור קונטיינרים (Docker ו-Kubernetes)

7:13 מושג מספר שש: תזמור קונטיינרים. Docker פתר את בעיית האריזה: הוא עוטף את קוד היישום שלכם, ספריות מערכת, תצורה, וזמן ריצה לתמונה בלתי ניתנת לשינוי שפועלת באופן זהה על ה-MacBook שלכם ובענן. אבל אריזת קונטיינר קלה. הרצת חמש מאות קונטיינרים על פני חמישים מכונות וירטואליות פיזיות היא המקום שבו ההנדסה נשברת. לכן קיימים מתזמני קונטיינרים כמו Kubernetes ו-AWS ECS.

7:41 מתזמן מספק מישור בקרה: שרת API, אחסון מצב etcd, ומתזמן אינטליגנטי. אתם מצהירים על המצב הרצוי שלכם: אני רוצה עשרה עותקים של שירות האימות שלי עם שני גיגה-בייט RAM לכל אחד. המתזמן בודק את האשכול, ממקם Pods על צמתים עם זיכרון פנוי, מגדיר רשת פנימית, ומפייס ברציפות את המציאות. אם צומת סובל מכשל חומרה, Kubernetes מזהה את האובדן ומתזמן מחדש באופן מיידי את כל ה-Podים שנעקרו על

- 07. 4 עמודי התווך של אחסון בענן (S3, EBS, DBs ו-Redis)

8:16 צמתים בריאים. מושג מספר שבע: היררכיית אחסון הענן. מתחילים מתייחסים לעתים קרובות לאחסון ענן כדלי יחיד שבו אתם זורקים קבצים. בארכיטקטורת פרודקשן, אחסון מחולק לארבעה עמודי תווך נפרדים בהתבסס על דפוסי גישה וחביון. ראשית הוא אחסון אובייקטים, כמו Amazon S3 או Google Cloud Storage. אתם ניגשים לקבצים באמצעות ממשקי API של HTTP REST באמצעות קריאות PUT ו-GET פשוטות. הוא מציע קיבולת אופקית אינסופית בשני סנט לגיגה-בייט בחודש,

8:49 מה שהופך אותו לאידיאלי לווידאו, העלאות משתמשים, יומנים וגיבויים. שנית הוא אחסון בלוקים, כמו Amazon EBS. אלה הם כוננים קשיחים וירטואליים המותקנים ישירות למכונה וירטואלית ספציפית באמצעות חיבורי אינטרנט מהירים. הם מתארגנים למערכות קבצים סטנדרטיות כמו ext4, תומכים בגישת קריאה וכתיבה אקראית מהירה הנדרשת על ידי מנועי מסדי נתונים. שלישית הם מסדי נתונים מנוהלים: מנועי מסדי נתונים יחסיים כמו PostgreSQL ב-RDS המספקים עסקאות ACID וצירופים מורכבים,

9:21 ומנועי NoSQL כמו DynamoDB המספקים חביון של מילי-שניות בודדות בסקאלה ענקית. ורביעית הם מטמוני זיכרון כמו Redis. קריאת נתונים מ-RAM אורכת מיקרו-שניות ולא מילי-שניות. מטמונים יושבים מול מסד הנתונים שלכם, מגנים עליו מתעבורת קריאה חוזרת ומנהלים אסימוני סשן משתמשים נדיפים.

- 08. זמינות גבוהה והתשיעיות (Multi-AZ Failover)

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

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

10:50 בשלושים שניות ללא התערבות אנושית.

- 09. עמידות לעומת זמינות (מדוע 11 תשיעיות אינן זמן פעולה)

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

11:24 תסתכלו על Amazon S3 Standard. הסכם רמת השירות שלה מציע תשעים ותשע נקודה תשע אחוז זמינות, המאפשרת כשלוש וארבעים דקות של השבתה בכל חודש שבה בקשת API עשויה להחזיר שגיאת חמש מאות. אבל S3 מבטיח עמידות של אחד עשר תשיעיות: תשעים ותשע נקודה תשע תשע תשע תשע תשע תשע תשע תשע תשע אחוז. אם אתם מאחסנים עשרה מיליון קבצים ב-S3, אתם יכולים לצפות סטטיסטית לאבד

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

- 10. תשתית כקוד (Terraform מול Console Drift)

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

12:48 כמו Terraform, OpenTofu, Pulumi, או AWS CDK, אתם מגדירים את כל ארכיטקטורת הענן שלכם בקבצי תצורה הצהרתיים המאוחסנים ב-Git. כל שינוי ליציאה פתוחה או שכפול מסד נתונים עובר דרך בקשת משיכה וביקורת עמיתים. הפעלת terraform plan מציגה תצוגה מקדימה של ההבדל המדויק ב-API לפני שמשהו נוגע, והעלאת העתק זהה של ערימת הייצור שלכם לוקחת ארבע דקות במקום ארבעה שבועות.

- 11. רשתות ענן (VPC, Subnets, NAT וקבוצות אבטחה)

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

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

- 12. התכנית הארגונית המלאה ופסק הדין

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

15:02 פסק הדין של שיעור המאסטר היום: SHIP IT. הפסיקו לשנן מאות ראשי תיבות של שיווק ענן. שלטו באחד עשר דפוסי הארכיטקטורה הללו, נתקו את המצב שלכם, ובנו מערכות שלא יכולות להיכשל. ספרו לי איזה קונספט ענן גרם לכם לכאב הראש הגדול ביותר כשהתחלתם לבנות בתגובות. וכדי לקבל את דף העזר המלא של הארכיטקטורה, הירשמו לניוזלטר ב-daily diff dot dev,

15:28 קישור למטה. וזה ההבדל להיום. אני ניקו מ-Axrisi. מזג באחריות.

מקורות

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io