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

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

300 חברות תרמו קוד לפרויקט OpenTelemetry ויש לו 2,000 תורמים פעילים (צילום: Dreamstime)

מאת נדב יחזקאל, סמנכ”ל פיתוח בחברת SeaLights

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

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

ארכיטקטורת Microservices למערכת הסעות

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

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

Observability נחלץ להצלה

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

בעבר, ארגונים כמו Uber פיתחו כלים כגון Merckx ו-Zipkin כדי לקבל Observability למערכות שלהם, אולם לאורך השנים התווספו כלים רבים, בהם Datadog ,Newrelic ,Cloudwatch ועוד. מאחורי הקלעים כלים אלו עובדים על ידי שליחת מדדים, עיבוד לוגים של המערכת או מעקב אחר התקשורת בין השירותים השונים על מנת להפיק תובנות. מדדים ותובנות אלו עוזרים לצוותי הפיתוח לבנות מערכות ניטור ולהתריע על אירועים חריגים כגון CPU גבוה וצריכת זיכרון גבוהה. בנוסף, ניתן להיעזר במדדים ותובנות אלו על מנת לזהות בקלות חלקים בקוד שמועדים לפורענות, כמו כאלה שנוטים להיכשל בעומס גבוה, קריאות מרובות בין שירותים ועוד מגוון של בעיות חבויות. כל זאת כדי שנוכל להזמין הסעה מכל מקום בגלובוס, בכל שעה וללא תקלות.

הילד החדש בשכונה: OpenTelemetry

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

OpenTelemetry הוא פרויקט המובל על ידי CNCFי(Cloud Native Computing Foundation) והוא נולד כתוצאה מאיחוד של שני פרויקטים אחרים – Open Tracing ו-OpenCenus. המטרה שלו היא לאפשר Observability בקלות על ידי יצירת תקן עולמי שאינו תלוי יצרן, לאינסטרומנטציה של קוד כדי לאפשר שליחה של המידע לכל שרת התומך בתקן.

בפרויקט ניתן למצוא את הרכיבים הבאים:

  • תקן שמטרתו לדאוג לאחידות בין המימושים השונים.
  • APIs המגדירים את ה-Interfaces ומימושים של התקן. באמצעותם יצרני ספריות יכולים להטמיע את זה כחלק מהספרייה.
  • SDKs המממשים את התקן וה-APIs במגוון שפות כגון Java ,Go ,Python ,.NET ועוד.
  • Exporters שמטרתם לאפשר שליחה של המידע לכל Backend שתומך בתקן.
  • Collectors המאפשרים מימוש אגנוסטי לספק לטובת עיבוד ויצוא של הנתונים.

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

שימוש ב-OpenTelemetry כחלק ממערכת מבוזרת

כאשר מתחילים להשתמש ב-OpenTelemetry, כדאי להכיר ולהבין את מונחי היסוד הבאים:

  • Trace – תיעוד של בקשה במערכת מבוזרת. ניתן להסתכל על זה כ-(Directed Acyclic Graph (DAG של Spans. בהמשך לדוגמה שלנו, Trace יתחיל בהזמנה של הסעה מתוך ממשק המשתמש, ימשיך לשירות שאחראי על הזמנות, משם לשירות שאחראי על מציאת נהג וכן הלאה.
  • Span – מייצג פעולה אחת מתוך Trace המכילה שם, זמן התחלה וזמן סיום. Trace הוא למעשה עץ של Span-ים, כאשר לכל אחד יהיה Root Span שיכול להכיל ילד אחד או יותר. דוגמה ל-Span היא קריאה מתוך שירות ההזמנות ל-DB בשביל להוסיף רשומה של הזמנה חדשה.
  • Metrics – מייצג ערך אחד אשר נמדד ב-Runtime. כחלק מהפרוטוקול, ישנם שלושה סוגים של מדדים: Counter ,Measure ו-Observer.
  • Context – כחלק מכל Span, ישלח גם Context המהווה Metadata אודות ה-Span. ניתן למצוא שם נתונים כגון SpanId ,TraceId וערכים שהושמו על ידי המשתמש. לדוגמה, אפשר להוסיף נתונים כגון Machine Name ,Service Version ,Data Region וכו’, כאשר הרציונל הוא להיות מסוגלים לעקוב טוב יותר אחר ה-Trace-ים, לסנן את המידע או לבצע עליו Aggregation. בדרך כלל ה-Context ישלח בצורה אוטומטית בין שירותים באמצעות Http Headers.
  • (OpenTelemetry Protocol (OTLP – סט של מוסכמות להעברת Telemetry Data. זה פרוטוקול מסוג Request/Response והוא יודע להעביר הודעות מצד אחד לשני שמתארות את הסיגנלים השונים (Logs ,Metrics ו-Tracing) גם באמצעות gRPC וגם באמצעות HTTP.

    משמאל: Trace המכיל מספר Span-ים. מימין: ה-Root Span מופיע בכתום ותחתיו Span-ים אחרים

אז איך משתמשים ב-OpenTelemetry?

בראש ובראשונה, הקהילה יצרה ספריות נפוצות שמשתמשות ב-APIs של OpenTelemetry ויודעות לייצר מדדים, Span-ים ו-Trace-ים ולדווח אותם ב-OTLP. לדוגמה, ב-Java יש יותר מ-70 אינטגרציות שונות, מקליינטים של בסיסי נתונים ועד Queues ו-Http Clients. המשמעות היא שמי שמשתמש בספריות התומכות ב-OpenTelemetry יאסוף את הנתונים האלה מבלי לשנות את הקוד הקיים שלו. אם יהיה צורך במידע נוסף, כמו תמיכה בטכנולוגיות שלא נתמכות בצורה אוטומטית, ניתן להשתמש ב-SDK-ים השונים על מנת לדווח את המדדים המעניינים.

שנית, יש מספר כלים ויצרנים גדולים שמסוגלים לעבד מידע של OpenTelemetry. הרשימה כוללת, בין היתר, את Jaeger ,Zipkin ,Prometheus ,New Relic ,Splunk ו-DataDog.

חלק מהכלים יודעים להציג מדדים, חלק יודעים להציג Distributed Traces וחלק יודעים להציג את כולו. אבל הצגה זה לא הכל:

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

עם 300 חברות שתרמו קוד לפרויקט ו-2,000 Contributors פעילים רק בשנה החולפת, אין ספק שעבור OpenTelemetry זו רק ההתחלה. אז בפעם הבאה שאתם יושבים בסלון וצופים באחת מסדרות הטלוויזיה האהובות עליכם או מזמינים הסעה, תזכרו את החבר’ה שיושבים ומנתחים מידע מכלי ה-Observability שלהם כדי שאתם תוכלו ליהנות משירות חלק ומתקדם.

הכתבה בחסות SeaLights

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

לעמוד הקריירה לחץ כאן.

כתב אורח

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

הגב

6 תגובות על "כל מה שצריך לדעת על הטכנולוגיה שעושה סדר בפרודקשן שלכם"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
יוכי
Guest

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

נילס
Guest

גם מגיב לא ממומן צריך להיות סגור על מה שהוא כותב

יוכי
Guest

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

נדב
Guest

אהלן יוכי!
ראשית, תודה רבה שלקחת את הזמן לקרוא את המאמר ולהגיב – זה לא מובן מאליו!
אכן יכולתי להרחיב יותר על יתרונות וחסרונות על Microservices, אבל זו לא הייתה מטרת המאמר ולמעשה ניסיתי במשפט לסכם 20 שנה של הנדסת תוכנה כרקע לנושא המאמר – Open Telemetry.

שנית, אשמח להמשיך את הדיון הזה במייל או אפילו בשיחת זום. אם אתה מעוניין בוא נתחבר ב-Linkedin ונמשיך משם :)

שיהיה אחלה יום,
נדב
https://www.linkedin.com/in/nadav-yeheskel-90068620/

רב-שרברב
Guest

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

איתי
Guest

למי שמעוניין ללמוד יותר, יש כאן סדרה של 6 סרטונים שמכסים את OpenTelemetry מהבסיס עד לקונספטים יותר מורכבים. מאוד hands-on ומעמיק. חינם וללא קשר ל vendor
https://www.aspecto.io/opentelemetry-bootcamp/

wpDiscuz

תגיות לכתבה: