SRE: ניתוח ביצועים. שיטת תצורה באמצעות שרת אינטרנט פשוט ב-Go

ניתוח וכוונון ביצועים הוא כלי רב עוצמה לאימות תאימות לביצועים עבור לקוחות.

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

Go טוב במיוחד כאן כי יש לו כלי פרופיל pprof בספרייה הרגילה.

אסטרטגיה

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

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

ארכיטקטורת שרת HTTP פשוטה

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

היישום המנותח הוא שרת HTTP שמסקר את Postgresql עבור כל בקשה. בנוסף, יש Prometheus, node_exporter ו-Grafana לאיסוף והצגת מדדי יישומים ומערכת.

כדי לפשט, אנו רואים כי עבור קנה מידה אופקי (ופישוט חישובים) כל שירות ומסד נתונים נפרסים יחד:

הגדרת מטרות

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

В ספר Google SRE שיטות בחירה ומידול נדונות בפירוט. בואו נעשה את אותו הדבר ונבנה דגמים:

• אחזור: 99% מהבקשות אמורות להסתיים תוך פחות מ-60 אלפיות השנייה;
• עלות: השירות צריך לצרוך את כמות הכסף המינימלית שלדעתנו אפשרית באופן סביר. לשם כך, אנו ממקסמים את התפוקה;
• תכנון קיבולת: דורש הבנה ותיעוד של כמה מופעים של היישום יהיה צורך להפעיל, כולל פונקציונליות קנה מידה כולל, וכמה מופעים יידרשו כדי לעמוד בדרישות הטעינה וההקצאה הראשונית יתירות n+1.

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

הקמת סביבת בדיקה

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

עומס עסקה

סביבה זו משתמשת לִחיוֹת חַיִים רֵיקִים כדי ליצור קצב בקשת HTTP מותאם אישית עד לעצירה:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

תצפית

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

יצירת פרופילים

פרופיל הוא סוג של מדידה המאפשרת לך לראות לאן עובר זמן המעבד כאשר אפליקציה פועלת. זה מאפשר לך לקבוע בדיוק היכן וכמה זמן המעבד מושקע:

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

ביצוע, תצפית, ניתוח.

בואו נעשה ניסוי. נבצע, נצפה וננתח עד שנהיה מרוצים מהביצוע. הבה נבחר ערך עומס נמוך באופן שרירותי כדי ליישם אותו כדי לקבל את תוצאות התצפיות הראשונות. בכל שלב עוקב נגדיל את העומס עם גורם קנה מידה מסוים, שנבחר עם וריאציה מסוימת. כל ריצת בדיקת עומס מתבצעת עם התאמה של מספר הבקשות: make load-test LOAD_TEST_RATE=X.

50 בקשות בשנייה

שימו לב לשני הגרפים העליונים. בפינה השמאלית העליונה ניתן לראות שהאפליקציה שלנו מעבדת 50 בקשות בשנייה (נראה לה) ובפינה השמאלית העליונה מוצגת משך הזמן של כל בקשה. שני הפרמטרים עוזרים לנו להסתכל ולנתח אם אנחנו בגבולות הביצועים שלנו או לא. קו אדום על הגרף חביון בקשת HTTP מציג SLO ב-60ms. השורה מראה שאנחנו הרבה מתחת לזמן התגובה המקסימלי שלנו.

בואו נסתכל על צד העלות:

10000 בקשות לשנייה / 50 בקשות לשרת = 200 שרתים + 1

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

500 בקשות בשנייה

דברים מעניינים יותר מתחילים לקרות כשהעומס מגיע ל-500 בקשות בשנייה:

שוב, בגרף השמאלי העליון ניתן לראות שהאפליקציה רושמת עומס רגיל. אם זה לא המקרה, יש בעיה בשרת שבו האפליקציה פועלת. גרף זמן השהיית התגובה ממוקם בפינה השמאלית העליונה, ומראה ש-500 בקשות בשנייה הביאו לעיכוב תגובה של 25-40ms. האחוזון ה-99 עדיין מתאים היטב ל-60ms SLO שנבחר לעיל.

מבחינת עלות:

10000 בקשות לשנייה / 500 בקשות לשרת = 20 שרתים + 1

הכל עדיין ניתן לשיפור.

1000 בקשות בשנייה

השקה מעולה! האפליקציה מראה שהיא עיבדה 1000 בקשות בשנייה, אך מגבלת ההשהיה הופרה על ידי ה-SLO. ניתן לראות זאת בשורה p99 בגרף הימני העליון. למרות העובדה שקו p100 גבוה בהרבה, העיכובים בפועל גבוהים מהמקסימום של 60ms. בואו נצלול לתוך פרופילים כדי לגלות מה האפליקציה עושה בפועל.

יצירת פרופילים

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

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ניתן להציג את התוצאות כך:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

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

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

ניתוח – השערה

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

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

אם תרחף עם הסמן מעל שם פונקציה בגרף, הזמן הכולל שהיא הייתה על הערימה במהלך איתור באגים יוצג. הפונקציה HTTPServe הייתה שם 65% מהזמן, פונקציות אחרות בזמן ריצה runtime.mcall, mstart и gc, לקח את שאר הזמן. עובדה מהנה: 5% מהזמן הכולל מושקע בשאילתות DNS:

הכתובות שהתוכנית מחפשת שייכות ל-Postgresql. לחץ על FindByAge:

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

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

הגדרת האפליקציה - ניסוי

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

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

ביצוע, תצפית, ניתוח

לאחר הפעלה מחדש של הבדיקה עם 1000 בקשות לשנייה, ברור שרמות ההשהיה של p99 חזרו לנורמליות עם SLO של 60ms!

מה העלות?

10000 בקשות לשנייה / 1000 בקשות לשרת = 10 שרתים + 1

בואו נעשה את זה אפילו יותר טוב!

2000 בקשות בשנייה

הכפלת העומס מראה את אותו הדבר, הגרף השמאלי העליון מראה שהאפליקציה מצליחה לעבד 2000 בקשות בשנייה, p100 נמוך מ-60ms, p99 עומד ב-SLO.

מבחינת עלות:

10000 בקשות לשנייה / 2000 בקשות לשרת = 5 שרתים + 1

3000 בקשות בשנייה

כאן האפליקציה יכולה לעבד 3000 בקשות עם חביון p99 של פחות מ-60ms. ה-SLO אינו מופר, והעלות מתקבלת כדלקמן:

10000 בקשות לשנייה / לכל 3000 בקשות לשרת = 4 שרתים + 1 (הסופר ריכז למעלה, משוער. מְתוּרגְמָן)

בואו ננסה סבב ניתוח נוסף.

ניתוח – השערה

אנו אוספים ומציגים את התוצאות של איתור באגים באפליקציה ב-3000 בקשות לשנייה:

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

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

הגדרת האפליקציה - ניסוי

מנסה להתקין MaxIdleConns שווה לגודל הבריכה (מתואר גם כאן):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

ביצוע, תצפית, ניתוח

3000 בקשות בשנייה

p99 הוא פחות מ-60ms עם פחות p100 משמעותית!

בדיקת גרף הלהבה מראה שהחיבור כבר לא מורגש! בואו נבדוק ביתר פירוט pg(*conn).query - אנחנו גם לא שמים לב לחיבור שנוצר כאן.

מסקנה

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

מקור: www.habr.com