Post Mortem ב- Quay.io חוסר זמינות

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

ב-19 במאי, מוקדם בבוקר (שעון הקיץ המזרחי, EDT), שירות quay.io התרסק. התאונה השפיעה הן על צרכני quay.io והן על פרויקטי קוד פתוח באמצעות quay.io כפלטפורמה לבנייה והפצה של תוכנה. Red Hat מעריך את האמון של שניהם.

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

«מה השתנה?"- זו השאלה הראשונה שנשאלת בדרך כלל במקרים כאלה. שמנו לב שזמן קצר לפני הבעיה, האשכול הייעודי של OpenShift (המריץ את quay.io) החל להתעדכן לגרסה 4.3.19. מכיוון ש-quay.io פועל על Red Hat OpenShift Dedicated (OSD), עדכונים קבועים היו שגרתיים ומעולם לא גרמו לבעיות. יתרה מכך, במהלך ששת החודשים הקודמים, שדרגנו אשכולות Quay מספר פעמים ללא כל הפרעה בשירות.

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

ניתוח סיבת השורש

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

ניסינו גם לזהות דפוס בתעבורת מסד הנתונים שעלול לגרום למפולת השלגים הזו. עם זאת, לא הצלחנו למצוא שום דפוס ביומנים. בזמן שהמתינו שהאשכול החדש עם OSD 4.3.18 יהיה מוכן, המשכנו לנסות להשיק quay.io pods. בכל פעם שהאשכול הגיע לקיבולת מלאה, מסד הנתונים היה קופא. המשמעות היא שהיה צורך להפעיל מחדש את מופע ה-RDS בנוסף לכל הפודים של quay.io.

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

Quay.io עבד ביציבות על אשכול ה-OSD החדש, אז חזרנו ליומני מסד הנתונים, אך לא מצאנו מתאם שיסביר את החסימות. מהנדסי OpenShift עבדו איתנו כדי להבין אם שינויים ב-Red Hat OpenShift 4.3.19 עלולים לגרום לבעיות עם Quay. עם זאת, דבר לא נמצא, ו לא ניתן היה לשחזר את הבעיה בתנאי מעבדה.

כישלון שני

ב-28 במאי, מעט לפני הצהריים EDT, quay.io קרס שוב עם אותו סימפטום: מסד הנתונים נחסם. ושוב השקענו את כל מאמצינו בחקירה. קודם כל, היה צורך לשחזר את השירות. למרות זאת הפעם אתחול RDS והפעלה מחדש של quay.io pods לא עשו כלום: מפולת נוספת של קשרים הכריעה את הבסיס. אבל למה?

Quay כתוב ב-Python וכל תרמיל פועל כמיכל מונוליטי יחיד. זמן הריצה של מיכל מריץ משימות מקבילות רבות בו זמנית. אנחנו משתמשים בספרייה gevent תחת gunicorn לעיבוד בקשות אינטרנט. כשמגיעה בקשה ל-Quay (דרך ה-API שלנו, או דרך ה-API של Docker), מוקצה לה עובד. בדרך כלל עובד זה צריך ליצור קשר עם מסד הנתונים. לאחר הכישלון הראשון, גילינו שעובדי gevent מתחברים למסד הנתונים באמצעות הגדרות ברירת המחדל.

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

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

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

לאחר שהצליח לעקוף את הבעיה שהובילה לחסימה, לא גילינו את הסיבות האמיתיות שלו. אושר שזה לא קשור לשינויים כלשהם ב-OpenShift 4.3.19, שכן אותו דבר קרה בגרסה 4.3.18, שעבדה בעבר עם Quay ללא בעיות.

ברור שמשהו אחר אורב באשכול.

מחקר מפורט

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

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

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

רגע לפני הזינוק בחיבורים, הוגשו מספר רב של בקשות ל-App Registry API. רישום האפליקציות הוא תכונה לא ידועה של quay.io. זה מאפשר לך לאחסן דברים כמו תרשימי Helm ומכולות עם מטא נתונים עשירים. רוב משתמשי quay.io אינם עובדים עם תכונה זו, אך Red Hat OpenShift משתמש בה באופן פעיל. OperatorHub כחלק מ-OpenShift מאחסן את כל המפעילים ב-App Registry. מפעילים אלו מהווים את הבסיס למערכת האקולוגית של עומס העבודה של OpenShift ולמודל ההפעלה ממוקד השותפים (פעולות יום 2).

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

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

ביטול סיבות

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

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

מה למדנו?

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

1. נתונים לגבי מי משתמש בשירות שלך וכיצד לעולם אינם מיותרים. מכיוון ש-Quay "פשוט עבד", מעולם לא היינו צריכים להשקיע זמן באופטימיזציה של תנועה וניהול עומס. כל זה יצר תחושת ביטחון מזויפת שהשירות יכול להגדיל ללא הגבלת זמן.
2. כשהשירות יורד, החזרתו לפעולה היא בראש סדר העדיפויות.. מכיוון ש-Quay המשיכה לסבול ממסד נתונים נעול במהלך ההפסקה הראשונה, הנהלים הסטנדרטיים שלנו לא הביאו את האפקט המיועד ולא הצלחנו לשחזר את השירות באמצעותם. זה הוביל למצב שבו היה צריך להשקיע זמן בניתוח ואיסוף נתונים בתקווה למצוא את הסיבה השורשית - במקום למקד את כל המאמצים בשיקום הפונקציונליות.
3. הערך את ההשפעה של כל תכונת שירות. לקוחות ממעטים להשתמש ב-App Registry, כך שזה לא היה בראש סדר העדיפויות של הצוות שלנו. כאשר חלק מתכונות המוצר בקושי נמצאות בשימוש, הבאגים שלהם מופיעים רק לעתים נדירות, ומפתחים מפסיקים לעקוב אחר הקוד. קל ליפול טרף לתפיסה השגויה שכך זה צריך להיות - עד שפתאום הפונקציה הזו מוצאת את עצמה במרכז אירוע גדול.

מה הלאה?

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

1. פרוס העתקים של מסד נתונים לקריאה בלבד כדי לעזור לשירות לטפל בתעבורה מתאימה במקרה של בעיות עם מופע ה-RDS הראשי.
2. עדכון מופע RDS. הגרסה הנוכחית עצמה אינה הבעיה. במקום זאת, אנו פשוט רוצים להסיר את השביל הכוזב (שאחריו עקבנו במהלך הכישלון); שמירה על עדכנית התוכנה תבטל גורם נוסף במקרה של הפסקות עתידיות.
3. שמירה נוספת במטמון על פני כל האשכול. אנו ממשיכים לחפש אזורים שבהם אחסון במטמון יכול להפחית את העומס על מסד הנתונים.
4. הוספת חומת אש של יישום אינטרנט (WAF) כדי לראות מי מתחבר ל-quay.io ומדוע.
5. החל מהמהדורה הבאה, אשכולות Red Hat OpenShift ינטשו את רישום האפליקציות לטובת קטלוגי מפעילים המבוססים על תמונות מיכל הזמינות ב-quay.io.
6. תחליף לטווח ארוך ל-App Registry יכול להיות תמיכה במפרטי חפץ של Open Container Initiative (OCI). הוא מיושם כעת כפונקציונליות Quay מקורית ותהיה זמין למשתמשים כאשר המפרט עצמו יושלם.

כל האמור לעיל הם חלק מההשקעה המתמשכת של Red Hat ב-quay.io כאשר אנו עוברים מצוות "סטייל סטארט-אפ" קטן לפלטפורמה בוגרת מונעת SRE. אנו יודעים שרבים מהלקוחות שלנו מסתמכים על quay.io בעבודתם היומיומית (כולל Red Hat!) ואנו מנסים להיות שקופים ככל האפשר לגבי ההפסקות האחרונות והמאמצים המתמשכים לשיפור.

נ.ב מהמתרגם

קרא גם בבלוג שלנו:

• «קוד רישום של Red Hat במקור פתוח עבור תמונות מיכל CoreOS - Quay";
• «סיפורים מעשיים מחיי היומיום שלנו ב-SRE. חלק 2";
• «כיצד סדרי עדיפויות של תרמילים ב-Kubernetes גרמו להשבתה במעבדות Grafana".

מקור: www.habr.com