איך AWS מבשלת את השירותים האלסטיים שלה. קנה מידה של שרתים ומסד נתונים

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

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

על הדובר: וסילי פנטיוחין (תַרְנְגוֹלֶת) התחיל כמנהל Unix בחברות .ru, עבד על חומרה גדולה של Sun Microsystem במשך 6 שנים, והטיף לעולם ממוקד נתונים ב-EMC במשך 11 שנים. זה התפתח באופן טבעי לעננים פרטיים, ובשנת 2017 עבר לעננים ציבוריים. כעת הוא מספק ייעוץ טכני כדי לעזור לחיות ולהתפתח בענן AWS.

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

למה אני מדבר על מכשיר אמזון?

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

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

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

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

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

על מה נדבר

בחרתי בגישה מגוונת – בחרתי 4 שירותים מעניינים שכדאי לדבר עליהם.

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

פונקציות ללא שרת (Lambda) הוא כנראה השירות הניתן להרחבה בענן.

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

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

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

שרתים

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

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

אופטימיזציה של חומרה והיפרוויזר

לעשות הכל בבת אחת ולעשות את זה טוב לא יעבוד. גם מה "טוב" לא היה ברור בתחילה.

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

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

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

בשלב הבא החלטנו לשפר את הגישה לאחסון נתונים חסום EBS - Elastic Block Storage. זה שילוב של רשת ואחסון. הקושי הוא שבעוד שכרטיסי ה-Network Accelerator היו קיימים בשוק, לא הייתה אפשרות פשוט לקנות חומרת Storage Accelerator. אז פנינו לסטארט-אפ מעבדות אנאפורנה, שפיתח עבורנו שבבי ASIC מיוחדים. הם אפשרו להרכיב אמצעי אחסון מרוחקים של EBS כמכשירי NVMe.

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

עד נובמבר 2017, הבנו שהגיע הזמן לשנות את ההיפרוויזר עצמו.

ה-Hypervisor החדש פותח על בסיס מודולי ליבת KVM שהשתנו.

זה איפשר להפחית מהותית את התקורה של אמולציית מכשירים ולעבוד ישירות עם ASICs חדשים. מקרים С5 היו המכונות הוירטואליות הראשונות עם hypervisor חדש שרץ מתחת למכסה המנוע. קראנו לו Nitro.

אבולוציה של מופעים על ציר הזמן.

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

במהלך השנתיים הבאות, מספר סוגי מופעי Nitro עלה על כמה תריסר: A1, C5, M5, T3 ואחרים.

סוגי מופעים.

כיצד פועלות מכונות Nitro מודרניות

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

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

קלפי ניטרו - ישנם ארבעה סוגים שלהם. כולם פותחו על ידי Annapurna Labs ומבוססים על ASIC נפוצים. חלק מהקושחה שלהם גם נפוצה.

ארבעה סוגים של כרטיסי Nitro.

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

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

מערכת כרטיסי Nitro, hypervisor ושבב אבטחה משולבת ברשת SDN או רשת מוגדרת תוכנה. אחראי על ניהול רשת זו (מטוס בקרה) כרטיס בקר.

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

שבב מעבד Inferentia Machine Learning.

מסד נתונים ניתן להרחבה

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

• SQL - שולחי לקוחות ובקשות עובדים על זה.
• הוראות עסקאות - הכל ברור כאן, ACID וכל זה.
• שמירה במטמון, אשר מסופק על ידי בריכות חיץ.
• רישום - מספק עבודה עם יומני ביצוע מחדש. ב-MySQL הם נקראים Bin Logs, ב-PosgreSQL - Write Ahead Logs (WAL).
• אחסון - הקלטה ישירה לדיסק.

מבנה מסד נתונים שכבות.

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

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

אמזון אורורה

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

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

רמות הרישום והאחסון נפרדות ממסד הנתונים.

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

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

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

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

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

סידרנו את האחסון.

כיצד לשנות את דרגות ה-DBMS

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

נניח שיש לנו אפליקציה שמתקשרת עם ה-DBMS דרך צומת מאסטר.

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

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

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

איך לשפר את המצב? הגדר פרוקסי בין היישום לצומת הראשי.

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

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

פתרון סופי עם Amazon Aurora ללא שרת

איך פתרנו את הבעיות הללו?

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

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

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

פרוקסי מבוזרים, מופעים חמים וניטור.

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

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

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

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

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

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

על HighLoad ++ וסילי פנטיוחין ימסור דו"ח "יוסטון יש לנו בעיה. עיצוב מערכות לכשלים, דפוסי פיתוח לשירותי ענן פנימיים של אמזון" באילו דפוסי עיצוב למערכות מבוזרות משתמשים מפתחי אמזון, מהן הסיבות לכשלים בשירות, מהי ארכיטקטורה מבוססת Cell, Constant Work, Shuffle Sharding – זה יהיה מעניין. פחות מחודש עד לכנס - להזמין את הכרטיסים שלך. 24 באוקטובר עליית מחיר סופית.

מקור: www.habr.com