אבוד על ידי sophiagworld

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

מניסיונו של המחבר, אין זו רשימה ממצה, אבל אכן יָעִיל עצה. אז בואו נתחיל.

תורגם בתמיכה פתרונות ענן של Mail.ru.

שלב ראשון

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

תשתית כקוד

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

פריסה של 100 מכונות וירטואליות

• עם אובונטו
• 2 GB RAM כל אחד
• יהיה להם את הקוד הבא
• עם הפרמטרים האלה

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

המודרניסט שבי אומר שאתה יכול להשתמש ב-Kubernetes/Docker כדי לעשות את כל האמור לעיל, והוא צודק.

בנוסף, ניתן לספק אוטומציה באמצעות Chef, Puppet או Terraform.

שילוב ואספקה ​​רציפים

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

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

אין דבר יותר יפה מלראות את הקרציות האלה

עבור טכנולוגיה זו אתה יכול להעריך Github, CircleCI או Jenkins.

מאזני עומסים

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

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

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

RayID, מזהה מתאם או UUID עבור בקשות

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

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

המשתמש מגיש בקשה למערכת א', ואז א' יוצר קשר ב', אשר יוצר קשר עם ג', מאחסן אותו ב-X, ואז הבקשה מוחזרת ל-A

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

רמה ממוצעת

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

רישום מרכזי

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

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

פונקציונליות מחסנית של ELK

סוכני ניטור

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

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

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

קנה מידה אוטומטי בהתאם לעומס

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

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

מערכת ניסויים

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

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

רמה מתקדמת

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

פריסות כחול-ירוק

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

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

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

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

• זה שהוא ממש עכשיו (נ);
• הגרסה הבאה (N+1). 

אתה אומר למאזן העומס לנתב מחדש אחוז מהתנועה לגרסה החדשה (N+1) תוך כדי מעקב פעיל אחר רגרסיות.

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

ראשית, אנו שולחים בדיקה ממש קטנה כדי לראות אם פריסת N+1 שלנו עובדת עם כמות קטנה של תעבורה:

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

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

זיהוי אנומליות והפחתה אוטומטית

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

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

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

זה הכל!

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

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

מה עוד כדאי לקרוא בנושא:

1. לך ומעבד מטמון
2. Kubernetes ברוח הפיראטיות עם תבנית ליישום
3. הערוץ שלנו Around Kubernetes בטלגרם

מקור: www.habr.com