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

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

חיפשתי הרבה זמן אחר כלי שיעזור להתמודד עם בעיות כאלה (כתבתי על זה ב-Habré: 1, 2), אבל בסופו של דבר הכנתי פתרון קוד פתוח משלי. במאמר זה אני מדבר על היתרונות של גישת ה-service mesh ומשתף כלי חדש ליישום שלה.

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

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

גישת רשת שירות

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

פתרונות

יש כבר כמה יישומים של גישה זו: Istio и linkerd2. הם מספקים הרבה תכונות מחוץ לקופסה. אבל במקביל, יש תקורה גדולה על משאבים. יתרה מכך, ככל שהאשכול בו פועלת מערכת כזו גדול יותר, כך יידרשו יותר משאבים לתחזוקת התשתית החדשה. ב-Avito, אנו מפעילים אשכולות kubernetes המכילים אלפי מופעי שירות (ומספרם ממשיך לגדול במהירות). ביישום הנוכחי שלה, Istio צורך ~300Mb של זיכרון RAM לכל מופע שירות. בשל ריבוי האפשרויות, איזון שקוף משפיע גם על זמן התגובה הכולל של השירותים (עד 10ms).

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

כתוצאה מכך, הגענו להחלטתנו:  נטרמש.

נטרמש

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

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

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

פרודוקטיביות

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

בוא נראה אילו תוצאות קיבלנו.

RAM

Netramesh צורכת ~10Mb ללא תעבורה ומקסימום 50Mb עם עומס של עד 10000 RPS לכל מופע.

Proxy של Istio צורך תמיד ~300Mb באשכולות שלנו עם אלפי מופעים. זה לא מאפשר להתאים אותו לכל האשכול.

עם Netramesh קיבלנו הפחתה של ~10x בצריכת הזיכרון.

CPU

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

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

אנו משתמשים ב-HTTP/1 לתקשורת בין שירותים. הגידול בזמן התגובה עבור Istio בעת ביצוע פרוקסי דרך שליח היה עד 5-10ms, וזה די הרבה עבור שירותים שמוכנים להגיב תוך אלפית שנייה. עם Netramesh הזמן הזה ירד ל-0.5-2ms.

מדרגיות

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

גילוי שירות

Netramesh לא מוסיפה מנגנונים נוספים לגילוי שירות. כל התעבורה מועברת בשקיפות דרך ה-netra sidecar.

Netramesh תומך בפרוטוקול יישומי HTTP/1. כדי להגדיר אותו, נעשה שימוש ברשימה הניתנת להגדרה של יציאות. בדרך כלל, למערכת יש מספר יציאות דרכן מתרחשת תקשורת HTTP. לדוגמה, אנו משתמשים ב-80, 8890, 8080 לאינטראקציה בין שירותים ובקשות חיצוניות. במקרה זה, ניתן להגדיר אותם באמצעות משתנה סביבה NETRA_HTTP_PORTS.

אם אתה משתמש ב-Kubernetes כמתזמר ובמנגנון ישות השירות שלו לתקשורת תוך-אשכולית בין שירותים, אזי המנגנון יישאר בדיוק זהה. ראשית, המיקרו-שירות משיג כתובת IP של שירות באמצעות kube-dns ופותח אליו חיבור חדש. חיבור זה נוצר לראשונה עם ה-netra-sidecar המקומי וכל מנות ה-TCP מגיעות בתחילה ל-netra. לאחר מכן, netra-sidecar יוצר קשר עם היעד המקורי. NAT על Pod IP על הצומת נשאר בדיוק כמו ללא Netra.

מעקב מבוזר והעברת הקשר

Netramesh מספקת את הפונקציונליות הדרושה לשליחת טווחי מעקב על אינטראקציות HTTP. Netra-sidecar מנתח את פרוטוקול ה-HTTP, מודד עיכובים בבקשות ומחלץ את המידע הדרוש מכותרות HTTP. בסופו של דבר, אנחנו מקבלים את כל העקבות במערכת ייגר אחת. עבור תצורה עדינה, אתה יכול גם להשתמש במשתני הסביבה שסופקו על ידי הספרייה הרשמית ספריית jaeger go.

אבל יש בעיה. עד שהשירותים ייצרו וישלחו כותרת uber מיוחדת, לא נראה טווחי מעקב מחוברים במערכת. וזה מה שאנחנו צריכים כדי למצוא במהירות את הגורם לבעיות. גם כאן ל-Netramesh יש פתרון. פרוקסי קוראים כותרות HTTP, ואם הם אינם מכילים את מזהה המעקב של Uber, יוצרים אחת. Netramesh גם מאחסנת מידע על בקשות נכנסות ויוצאות ב-sidecar ומתאימה אותן על ידי העשרתן בכותרות הבקשות היוצאות הנחוצות. כל מה שאתה צריך לעשות בשירותים הוא לשלוח כותרת אחת בלבד X-Request-Id, שניתן להגדיר באמצעות משתנה סביבה NETRA_HTTP_REQUEST_ID_HEADER_NAME. כדי לשלוט בגודל ההקשר ב-Netramesh, אתה יכול להגדיר את משתני הסביבה הבאים: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (הזמן שעבורו יישמר ההקשר) ו NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (תדירות ניקוי ההקשר).

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

קביעת מקור הבקשה

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

זה מאפשר להפיץ את הכותרת השימושית הזו באופן אחיד ברחבי הרשת. לאחר מכן תוכל להשתמש בו בשירותים ולהוסיף אותו ליומנים ומדדים.

ניתוב תנועה ופנימי Netramesh

Netramesh מורכב משני מרכיבים עיקריים. הראשון, netra-init, מגדיר כללי רשת ליירט תעבורה. הוא משתמש כללי ניתוב מחדש של iptables ליירט את התנועה כולה או חלקה על קרון הצד, שהוא המרכיב העיקרי השני של Netramesh. אתה יכול להגדיר אילו יציאות יש ליירט עבור הפעלות TCP נכנסות ויוצאות: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

לכלי יש גם תכונה מעניינת - ניתוב הסתברותי. אם אתה משתמש ב-Netramesh באופן בלעדי לאיסוף טווחי מעקב, אז בסביבת ייצור תוכל לחסוך משאבים ולאפשר ניתוב הסתברותי באמצעות משתנים NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (מ-0 עד 1). ערך ברירת המחדל הוא 1 (כל התעבורה יורטה).

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

בניית גרף תלות

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

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

כיצד להשתמש ב-Netramesh

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

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

העתיד של נטרמש

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

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

השתמש ב-Netramesh אם אתה נתקל בבעיות דומות וכתוב לנו עם שאלות והצעות.

מקור: www.habr.com