האם וכמה service צריך לבדוק את הבריאות של השכנים?

[Rשף]

האם וכמה service צריך לבדוק את הבריאות של השכנים?

אחרי ויכוח חם בצוות, האם service שמסתמך על שירות מ services אחרים צריך לבדוק את הבריאות שלהם לפני שהוא נותן שירות?
התשובות נעו בין לא, ping לשרת, תשובה ל api בסיסי ועד ל ניסיון לבצע פעולה אמיתית.
ברור שהתשובה תלוייה בקונטקסט, לצורך הדיון מדובר במערכת לא life critical או פיננסית, ה sla המצופה הוא באחוזים הגבוהים של ה 90 אבל בהחלט לא 5x9, והרעיון עלה כי המערכת שלנו מהווה את שער הכניסה להרבה שירותים כך שאנחנו סופגים את האש עבור השירותים מאחורינו

 

[vinney]

מה יעזור לך לבדוק לפני מתן שירות?

כך או כך תחזיר שגיאה.
&nbsp
מה שכן הוא אתה צריך ניטור קבוע גם לשרת שלך וגם לשרתי downstream. איך עושים ניטור? תלוי בארכיטקטורה, אפשר פשוט לשים סקריפט שכל כמה זמן מבצע קריאה, או אם הפלטפורמה מאפשרת דברים קצת יותר מתוכחמים - להתחכם. הרעיון הוא לגלות שגיאה לפני שלקוחות שלך מגלים אותה, או לפחות בו בזמן.
&nbsp
מבחינת ניטור המערכת שלך יש לך יותר אפשרויות, כי אתה שולט על הקוד. אתה יכול לייצא כל מיני נתונים (error rate למשל, לפי סוג שגיאה/backend) ולהתחיל לשלוח סמסים או להרים טלפונים באופן אוטומטי כשהמספרים עוברים רף מסוים או עולים במשך פרק זמן מסוים.
&nbsp
כמובן צריך לזכור שהSLA שלך כנראה לא יהיה גבוה מהSLA הנמוך ביותר של התלויות שלך, כך שאם אתה מבטיח uptime של 99.9% אבל אתה מסתמך על שירות שבקושי מחזיק 99% - תהיה לך בעיה

 

[Rשף]

עוד פרטים

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

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

 

[h a j b i]

עדיין, מה יעזור לך לבדוק את השירותים לפני?

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

 

[zaske]

לא תמיד הדבר הנכון הוא להחזיר לסוף התור

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

 

[h a j b i]

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

במקרה שהוא תיאר לא ראיתי סיבה לא להכניס לסוף התור.
&nbsp
מה שאני בדר"כ עושה זה אכן תור נוסף לנכשלים שחוזרים לתור הראשי לפי קריטריונים כאלה ואחרים ובמידת הצורך תור נוסף להודעות שלא מבצעים להם retry (בגלל סיבת כישלון מסויימת או יותר מידי נסיונות שנכשלו).
&nbsp
כמובן שכשיש לך תורים נוספים אתה יכול לבצע ניטור יעיל יותר עליהם ולהימנע מ - false positive בגלל עומס זמני.
&nbsp
ובכל מקרה, אם ה - timeout קטן מידי אז אול שווה להגדיל אותו

 

[andthisistheme]

מסכים כמעט עם הכל פרט ל...

״צריך לזכור שהSLA שלך כנראה לא יהיה גבוה מהSLA הנמוך ביותר של התלויות שלך״.

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

 

[vinney]

זה לא תמיד אפשרי...

אתה מניח שיש לך שליטה על הdownstream, אבל מההודעה של Rשף משתמע שאין לו שליטה כזאת, וזה מקור הבעיה עבורו.

 

[Rשף]

לרוב ה services יש מנגנון גיבוי פנימי

Fallback לשרת אחר או משהו אחר, המימוש שקוף לנו

 

[nocgod]

השאלות האמיתית הן...

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

א. למה שזה יהיה מתפקידו של ServiceA לבדוק אם DepServiceB ו DepServiceC בחיים? זה טיפה נוגד את Single Responsibility
ב. נניח ו ServiceA מגלה שאחת התלויות שלו לא זמינה כרגע - מה הדפ"א שלך? להודיע על שגיאה ללקוח ולזנוח את הבקשה כולה? תשמור את הבקשה באיזה באפר ותנסה שוב בהתאם ל retry policy כלשהו? מה המטרה של הבדיקה הזאת בעצם? הרי אם מדובר בשירות שהגישה אליו הדרך איזה REST API אז בדיקת "בריאות" תגרום לייצור של 2 בקשות במקום אחת (אם הבקשה נכשלה, אתה יכול להניח שיש איזה חוסר בריאות בשירות)
ג. למה לא לדאוג שלכל הServices יהיה איזה דרך לבדוק Health דרך service צד שלישי? לדוגמא HealthService שמקבל דיווחים כל כמה זמן מכל הServices במערכת על Health שלו (ואולי פרמטרים מעניינים אחרים שיכולים להצביע על בעיה ב Health). לאותו שירות HealthService יהיה גם API תחקור שאפשר לשאול אותו "מה המצב של DepServiceB" והוא יענה "נגיש" או "לא נגיש" (פשטני מאוד). יש כלים מוכנים שאפשר באמצעותם לעשות את זה!
ד. אם אין צורך לדווח ללקוח response מלא ישר אחרי הבקשה שלו אפשר להחזיר לו handle ולהשתמש בampq לדוגמא כדי להעביר בקשות לDepServices ואז מקסימום הסרוויסים לא עובדים, הבקשות שמורות עד שיעלה אחד תקין ויוכל לעשות ACK על ההודעות בצורה תקינה.

חפירה זו היא דעתי הלא כל כך מיומנת...

 

[Rשף]

דווקא כיוונת לדעתם של גדולים

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

 

[zaske]

לגבי ד

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

 

[nocgod]

ברור שיש הרבה פתרונות לשכבת ה transport בפיתרון

servicebus עלה לי כי לדעתי יותר קל לממש בו retry policy ו recovery policy.
בנוסף מאוד קל לעשות באמצעות לעשות באמצעותו scale-out, לא צריך קומפוננטה ייעודית כדי לבצע load balancing.
יש גם כלים נוחים (לפחות ל .net) לביצוע טרנזאקציות מעל תשתית מבוזרת שעובדת מעל service bus (לדוגמא Automatonymous)

 

[choo]

במקום רק לבצע ניטור - מה עם לפתור את הבעיה?

&nbsp
אם יש לך שרות לא מאוד אמין - יש דרכים שונות לטפל בזה.
&nbsp
השאלה היא מהיכן נובעות בפועל בעיות האמון של ה-services השונים. האם מדובר בשרתים שנופלים? בקוי תקשורת בנופלים? במעבדים חנוקים? במחסור בזכרון שמוביל ל-swap? בבאגים לוגיים באפליקציה (ואם כן - האם בפועל האפליקציה נופלת, או נתקעת, או רק מגיבה לאט כשהבאגים הללו מתרחשים?)
&nbsp
על פניו נשמע, בגלל בעית האמון בין הצוותים, שבכל צוות צריך לבצע ניטור לשרות שלו כדי להוכיח שהשרות שלו היה נגיש בזמן X. עומק הניטור תלוי בצורת המימוש של כל שרות, כמו גם בסוגי הבעיות שבהן נתקלים בפועל מול אותו שרות. אם התהליך נוטה ליפול - מספיק ping. אם הוא נוטה להיתקע - מספיקה בדיקת API של "areYouAlive". אם בסיס הנתונים שממנו הוא מביא נתונים הוא זה שנתקע, צריך שבדיקת ה-areYouAlive" אכן תבצע בדיקה קצה לקצה. אם השרות מרובה נימים (או תהליכים) ובכל פעם חלק נתקעים - ניטור לא בהרכח יעזור, אם בקשת הניטור תגיע לתור של חוט/תהליך שמצבו תקין אבל בקשת השירות תגיע לתור של חוט/תהליך שכבר תקוע (או שהמשאב שהוא זקוק לו כדי לשרת את הבקשה נעול בצורה שתגרום לו להיתקע לאחר משיכת הבקשה מהתור).

 

[vinney]

ניטור צריך להיות לא רק ״קופסא שחורה״ או ״חי-מת״.

זה חשוב שיהיה ניטור כלשהו מהסוגים שתיארת, אבל מה שדורש ניתור זה גם הפעילות השוטפת.
&nbsp
כמה בקשות נכשלו? כמה בקשות התעקבו? כמה בקשות הצטרכו retry? כל אלה מספרים שהשרת צריך לאסוף ולאפשר לשלוף בצורה שוטפת. ניתור שרת צריך להיות גם על פי הנתונים האלה. אם פתאום יש לך קפיצה בזמן שירות, אפילו שאם כל הבקשות מטופלות - לא תרצה לדעת את זה? לא חשוב לך שבמקום 10 מילישניות הלקוח שלך מחכה 10 שניות? כנ״ל אם פתאום אתה צריך לעשות retry חמש פעמים על כל בקשה - בסוף היא מטופלת, אבל זה מראה שיש בעיית תשתית שדורשת טיפול - לא תרצה לדעת את זה?
&nbsp
ניטור מהסוג areYouAlive זה ניטור הכי גס. כשהדבר הזה שולח התראה - אתה כבר עמוק בבוץ. בדרך כלל, הרבה (במונחי זמן מחשב) לפני שהפינגים מתחילים להכשל אתה כבר תראה עליה בlatency, עליה בretryים, ועליה בכמות השגיאות.

 

[choo]

לגבי "התארכות זמן שירות" - זה חזאי לחלק מסוגי התקלות

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

 

[vinney]

כן ולא

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

 

[Rשף]

אין סתירה

החברה בהחלט משקיעה משאבים לשפר את הזמינות של השירותים אבל זה תהליך איטי

 

[choo]

תהליך זיהוי סוגי התקלות שמתרחשות אמור להיות מהיר יחסית

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

 

[ipv6]

הכל תלוי כמה חשוב לך performance

כמה יקר לך לבדוק את הבריאות של ה-service-ים האחרים וכמה כואב לך "ליפול" (לפנות ל-service שלא זמין). בשביל לענות על זה צריך להכיר את המערכת שלך.

האם ה-service שלך (זה שמהווה את הכניסה) עמוס רב הזמן? אם לא, הוא יכול להחזיק מעין DB שיכיל את מצב ה-service-ים האחרים. ולאפשר לצרכנים שלו לתשאל את ה-DB הזה.

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

זה קצת באוויר כי אני לא מכיר את המערכת שלך ולא יודע כמה "כואב" לך לטעות..

גם איזו בדיקה לעשות, זה תלוי לגמרי במה שה-service-ים האלה עושים. אם אתה מבקש מ-node מרוחק לבצע חישוב מורכב שתלוי באינפורמציה מ-Node-ים אחרים, זה שעשית אליו Ping לא אומר הרבה.