תרגום המאמר: דגם השרשור של שליחים - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

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

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

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

סקירת שרשורים

Envoy משתמש בשלושה סוגים שונים של זרמים:

רָאשִׁי: שרשור זה שולט באתחול וסיום תהליכים, בכל עיבוד ה-API של XDS (xDiscovery Service), כולל DNS, בדיקת תקינות, ניהול אשכולות וזמני ריצה כלליים, איפוס סטטיסטיקה, ניהול וניהול תהליכים כללי - אותות לינוקס. הפעלה מחדש חמה וכו'. קורה בשרשור הזה הוא אסינכרוני ו"לא חוסם". באופן כללי, השרשור הראשי מתאם את כל תהליכי הפונקציונליות הקריטיים שאינם דורשים כמות גדולה של מעבד כדי לפעול. זה מאפשר לכתוב את רוב קוד הבקרה כאילו היה פתיל בודד.
עוֹבֵד: כברירת מחדל, Envoy יוצר שרשור עובד עבור כל שרשור חומרה במערכת, ניתן לשלוט בכך באמצעות האפשרות --concurrency. כל שרשור עובד מפעיל לולאת אירועים "לא חוסמת", אשר אחראית להאזנה לכל מאזין; בזמן כתיבת שורות אלה (29 ביולי 2017) אין ריסוק של המאזין, קבלת חיבורים חדשים, יצירת ערימת פילטרים עבור החיבור, ועיבוד כל פעולות הקלט/פלט (IO) במהלך חיי החיבור. שוב, זה מאפשר לכתוב את רוב קוד הטיפול בחיבור כאילו היה פתיל בודד.
שטיפת קבצים: לכל קובץ ש-Envoy כותב, בעיקר יומני גישה, יש כרגע שרשור חסימה עצמאי. זאת בשל העובדה שכתיבה לקבצים המאוחסנים במטמון על ידי מערכת הקבצים גם בעת שימוש O_NONBLOCK יכול לפעמים להיחסם (אנחה). כאשר שרשורי עובדים צריכים לכתוב לקובץ, הנתונים למעשה מועברים למאגר בזיכרון שבו הם נשטפים בסופו של דבר דרך השרשור שטיפת קובץ. זהו אזור קוד אחד שבו מבחינה טכנית כל שרשורי העובדים יכולים לחסום את אותה נעילה תוך כדי ניסיון למלא מאגר זיכרון.

טיפול בחיבורים

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

יש לכך מספר השלכות חשובות:

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

מה המשמעות של אי-חסימה?

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

Envoy משתמש במספר מנעולי תהליכים ארוכים:

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

אחסון מקומי של חוטים

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

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

מערכת ה-TLS (אחסון מקומי של חוטים) של Envoy פועלת באופן הבא:

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

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

Envoy משתמש בזה בשתי דרכים שונות:

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

שרשור עדכון אשכול

בחלק זה, אתאר כיצד TLS (אחסון מקומי של שרשור) משמש לניהול אשכול. ניהול אשכולות כולל xDS API ו/או עיבוד DNS, כמו גם בדיקת תקינות.

ניהול זרימת אשכולות כולל את הרכיבים והשלבים הבאים:

מנהל האשכולות הוא רכיב ב-Envoy המנהל את כל הזרמים המוכרים של האשכולות, ה-API של Cluster Discovery Service (CDS), ה-API של Secret Discovery Service (SDS) ו-Endpoint Discovery Service (EDS), DNS ובדיקות תקינות חיצוניות. היא אחראית ליצירת תצוגה "עקבית בסופו של דבר" של כל אשכול במעלה הזרם, הכוללת מארחים שהתגלו כמו גם מצב בריאותי.
בודק הבריאות מבצע בדיקת תקינות אקטיבית ומדווח למנהל האשכול על שינויים במצב הבריאות.
CDS (Cluster Discovery Service) / SDS (Secret Discovery Service) / EDS (Endpoint Discovery Service) / DNS מבוצעים כדי לקבוע חברות באשכול. שינוי המצב מוחזר למנהל האשכול.
כל חוט עובד מבצע ברציפות לולאת אירוע.
כאשר מנהל האשכול קובע שהמצב של אשכול השתנה, הוא יוצר תמונת מצב חדשה לקריאה בלבד של מצב האשכול ושולח אותה לכל שרשור עובד.
במהלך התקופה השקטה הבאה, שרשור העובד יעדכן את תמונת המצב במשבצת ה-TLS המוקצה.
במהלך אירוע I/O שאמור לקבוע את המארח לאיזון העומס, מאזן העומס יבקש חריץ TLS (Thread Local storage) כדי לקבל מידע על המארח. זה לא דורש מנעולים. שימו לב גם ש-TLS יכול גם להפעיל אירועי עדכון כך שמאזני עומסים ורכיבים אחרים יכולים לחשב מחדש מטמונים, מבני נתונים וכו'. זה מעבר להיקף הפוסט הזה, אבל נעשה בו שימוש במקומות שונים בקוד.

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

תת-מערכות אחרות שעושות שימוש ב-TLS

TLS (אחסון מקומי של שרשור) ו-RCU (עדכון העתקת קריאה) נמצאים בשימוש נרחב ב-Envoy.

דוגמאות לשימוש:

מנגנון לשינוי פונקציונליות במהלך הביצוע: הרשימה הנוכחית של פונקציונליות מופעלת מחושבת בשרשור הראשי. לאחר מכן כל שרשור עובד מקבל תמונת מצב לקריאה בלבד באמצעות סמנטיקה של RCU.
החלפת טבלאות מסלולים: עבור טבלאות מסלולים המסופקות על ידי RDS (שירות גילוי נתיב), טבלאות המסלולים נוצרות בשרשור הראשי. תמונת המצב לקריאה בלבד תסופק לאחר מכן לכל שרשור עובד באמצעות סמנטיקה של RCU (Read Copy Update). זה הופך את טבלאות המסלול לשינוי יעיל מבחינה אטומית.
שמירה במטמון של כותרות HTTP: כפי שמתברר, חישוב כותרת ה-HTTP עבור כל בקשה (בזמן הפעלת ~25K+ RPS לכל ליבה) הוא די יקר. Envoy מחשב באופן מרכזי את הכותרת בערך כל חצי שנייה ומספק אותה לכל עובד באמצעות TLS ו-RCU.

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

מלכודות ביצועים ידועות

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

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

סיכום

מודל השרשור של Envoy נועד לספק קלות תכנות והקביליות מסיבית על חשבון זיכרון וחיבורים שעלולים לבזבז אם אינם מוגדרים כהלכה. מודל זה מאפשר לו לבצע ביצועים טובים מאוד בספירת חוטים ותפוקה גבוהים מאוד.
כפי שציינתי בקצרה בטוויטר, העיצוב יכול לרוץ גם על גבי ערימת רשת מלאה במצב משתמש כגון DPDK (Data Plane Development Kit), מה שיכול לגרום לכך ששרתים קונבנציונליים יטפלו במיליוני בקשות בשנייה עם עיבוד L7 מלא. יהיה מאוד מעניין לראות מה ייבנה בשנים הקרובות.
הערה מהירה אחרונה: נשאלתי פעמים רבות מדוע בחרנו ב-C++ עבור Envoy. הסיבה נותרה שהיא עדיין השפה התעשייתית היחידה בשימוש נרחב בה ניתן לבנות את הארכיטקטורה המתוארת בפוסט זה. C++ בהחלט לא מתאים לכל הפרויקטים או אפילו להרבה פרויקטים, אבל למקרי שימוש מסוימים הוא עדיין הכלי היחיד לביצוע העבודה.

קישורים לקוד

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

מקור: www.habr.com

[תרגום] דגם השרשור של השליח