האיץ את בקשות האינטרנט ושינה בשקט

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

דוגמה ברורה לגישת נטפליקס לפיתוח ותמיכה במערכות מורכבות הוצגה ב-DevOops 2019 סרגיי פדורוב - מנהל פיתוח בנטפליקס. בוגר הפקולטה למתמטיקה חישובית ומתמטיקה של אוניברסיטת ניז'ני נובגורוד. לובצ'בסקי, סרגיי אחד המהנדסים הראשונים ב-Open Connect - צוות CDN בנטפליקס. הוא בנה מערכות לניטור וניתוח נתוני וידאו, השיק שירות פופולרי להערכת מהירות החיבור לאינטרנט FAST.com, ובשנים האחרונות עמל על ייעול בקשות האינטרנט כך שאפליקציית נטפליקס תפעל במהירות האפשרית עבור המשתמשים.

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

בדו"ח שלו דיבר סרגיי בפירוט

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

תשובות לשאלות אלו נדרשות לא רק למי שעובד בתאגידים גדולים.

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

הבא הוא הקריינות מנקודת המבט של הדובר.

החשיבות של מהירות האינטרנט

מהירות הבקשות לאינטרנט קשורה ישירות לעסקים. קחו בחשבון את תעשיית הקניות: אמזון ב-2009 דיברשהשהייה של 100 אלפיות השנייה גורמת לאובדן של 1% מהמכירות.

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

מהירות החיבור חשובה גם במוסדות פיננסיים שבהם חביון הוא קריטי. בשנת 2015, Hibernia Networks גָמוּר כבל של 400 מיליון דולר בין ניו יורק ללונדון כדי להפחית את זמן האחזור בין הערים ב-6 אלפיות השנייה. תארו לעצמכם 66 מיליון דולר עבור הפחתת זמן אחזור של 1 אלפית השנייה!

על פי מחקר, מהירויות חיבור מעל 5 Mbit/s כבר לא משפיעות ישירות על מהירות הטעינה של אתר אינטרנט טיפוסי. עם זאת, יש קשר ליניארי בין זמן האחזור של החיבור ומהירות טעינת העמוד:

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

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

בתוך נטפליקס

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

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

קישור לסרטון עם הדגמה (6:04-6:23)

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

מרכיב חשוב נוסף בתשתית שלנו הוא Open Connect CDN, המספק תוכן סטטי למשתמש הקצה - סרטונים, תמונות, קוד לקוח וכו'. ה-CDN ממוקם בשרתים מותאמים אישית (OCA - Open Connect Appliance). בפנים יש מערכים של כונני SSD ו-HDD המריצים FreeBSD מותאם, עם NGINX ומערכת שירותים. אנו מתכננים ומייעלים את רכיבי החומרה והתוכנה כך ששרת CDN כזה יוכל לשלוח כמה שיותר נתונים למשתמשים.

ה"קיר" של שרתים אלה בנקודת חילופי תעבורת האינטרנט (Internet eXchange - IX) נראה כך:

Internet Exchange מספק את היכולת לספקי שירותי אינטרנט וספקי תוכן "להתחבר" זה לזה כדי להחליף נתונים באופן ישיר יותר באינטרנט. יש כ-70-80 נקודות חילופי אינטרנט ברחבי העולם בהן מותקנים השרתים שלנו, ואנו מתקינים ומתחזקים אותם באופן עצמאי:

בנוסף, אנו מספקים גם שרתים ישירות לספקי אינטרנט, אותם הם מתקינים ברשת שלהם, משפרים את הלוקליזציה של תעבורת נטפליקס ואיכות הסטרימינג למשתמשים:

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

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

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

לגבי האצת אינטרנט

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

בואו נעשה פרוקסי בשרת CDN ונתחיל לשלוח תנועה דרכו. האם זה יהיה מהיר יותר?

חומר

בואו נזכור איך פרוטוקולי רשת עובדים. כיום, רוב התעבורה באינטרנט משתמשת ב-HTTP, שתלוי בפרוטוקולי השכבה התחתונה TCP ו-TLS. כדי שלקוח יתחבר לשרת, הוא מבצע לחיצת יד, וכדי ליצור חיבור מאובטח, הלקוח צריך להחליף הודעות עם השרת שלוש פעמים ולפחות פעם נוספת כדי להעביר נתונים. עם חביון לכל נסיעה הלוך ושוב (RTT) של 100 אלפיות השנייה, ייקח לנו 400 שניות כדי לקבל את סיבית הנתונים הראשונה:

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

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

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

גם לפרוטוקולים ברמת האפליקציה (OSI Level 7) יש השפעה על זמן ההשהיה. פרוטוקולים חדשים כגון HTTP/2 מייעלים את הביצועים של בקשות מקבילות. עם זאת, יש לנו לקוחות Netflix עם מכשירים ישנים יותר שאינם תומכים בפרוטוקולים החדשים. לא ניתן לעדכן או להגדיר בצורה מיטבית את כל הלקוחות. יחד עם זאת, בין פרוקסי CDN לענן ישנה שליטה מלאה ויכולת שימוש בפרוטוקולים והגדרות חדשים ואופטימליים. החלק הלא יעיל עם פרוטוקולים ישנים יפעל רק בין הלקוח לשרת ה-CDN. יתרה מזאת, אנו יכולים לבצע בקשות מרובות בחיבור שכבר נוצר בין ה-CDN והענן, ולשפר את ניצול החיבור ברמת ה-TCP:

אנחנו מודדים

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

• מהירות: האם פרוקסי יהיה מהיר יותר?
• אמינות: האם זה ישבר לעתים קרובות יותר?
• קושי: איך להשתלב עם יישומים?
• עלות: כמה עולה לפרוס תשתית נוספת?

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

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

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

כיצד ניתן לשלב את היתרונות של שתי השיטות?

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

1. זמן קצר לאחר טעינת האפליקציה והשלמת הפעילות הראשונית, אנו מפעילים את הבדיקות שלנו.
2. הלקוח מגיש בקשה לשרת ומקבל "מתכון" לבדיקה. המתכון הוא רשימה של כתובות URL שאליהן יש לבצע בקשת HTTP(ים). בנוסף, המתכון מגדיר פרמטרים של בקשה: עיכובים בין בקשות, כמות הנתונים המבוקשים, כותרות HTTP(s) וכו'. במקביל, אנו יכולים לבדוק מספר מתכונים שונים במקביל - כאשר מבקשים תצורה, אנו קובעים באופן אקראי איזה מתכון להנפיק.
3. זמן השקת הבדיקה נבחר כדי לא להתנגש עם השימוש הפעיל במשאבי הרשת בלקוח. בעיקרו של דבר, הזמן נבחר כאשר הלקוח אינו פעיל.
4. לאחר קבלת המתכון, הלקוח מגיש בקשות לכל אחת מכתובות האתרים, במקביל. ניתן לחזור על הבקשה לכל אחת מהכתובות - מה שנקרא. "פולסים". בפעימה הראשונה, אנו מודדים כמה זמן לקח ליצור חיבור ולהוריד נתונים. בפעימה השנייה, אנו מודדים את הזמן שלוקח לטעון נתונים דרך חיבור שכבר נוצר. לפני השלישי, נוכל להגדיר השהיה ולמדוד את מהירות יצירת החיבור מחדש וכו'.

   במהלך הבדיקה אנו מודדים את כל הפרמטרים שהמכשיר יכול להשיג:

   • זמן בקשת DNS;
   • זמן הגדרת חיבור TCP;
   • זמן הגדרת חיבור TLS;
   • זמן קבלת הביט הראשון של נתונים;
   • זמן טעינה כולל;
   • קוד תוצאת מצב.
5. לאחר השלמת כל הפולסים, המדגם טוען את כל המדידות לניתוח.

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

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

תורת הבדיקה בפועל: אב טיפוס

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

• ליצור אב טיפוס של פרוטו;
• הצב את אב הטיפוס על CDN;
• לקבוע כיצד להפנות לקוחות ל-proxy בשרת CDN ספציפי;
• השווה ביצועים לבקשות ב-AWS ללא פרוקסי.

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

כדי לאזן בין אזורי AWS, השתמשנו במסד נתונים גיאוגרפי DNS, אותו אחד המשמש לאיזון לקוחות. כדי לבחור שרת CDN עבור הלקוח, אנו משתמשים ב-TCP Anycast עבור שרתים ב-Internet Exchange (IX). באפשרות זו, אנו משתמשים בכתובת IP אחת עבור כל שרתי ה-CDN, והלקוח יופנה לשרת ה-CDN עם ​​מספר ה-IP המינימלי ביותר. בשרתי CDN המותקנים על ידי ספקי אינטרנט (ISP), אין לנו שליטה על הנתב כדי להגדיר את TCP Anycast, ולכן אנו משתמשים אותו היגיון, המפנה לקוחות לספקי אינטרנט לצורך הזרמת וידאו.

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

כל אחד מהנתיבים הופך למטרה נפרדת, ואנחנו מסתכלים על הזמן שקיבלנו. לצורך ניתוח, אנו משלבים את תוצאות ה-proxy לקבוצה אחת (בוחרים את הזמן הטוב ביותר בין פרוקסי IX ל-ISP), ומשווים אותם לזמן הבקשות לענן ללא פרוקסי:

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

כתוצאה מכך, עשינו מספר דברים חשובים:

1. הערכנו את הביצועים הצפויים של בקשות מלקוחות לענן באמצעות פרוקסי CDN.
2. קיבלנו נתונים מלקוחות אמיתיים, מכל סוגי המכשירים.
3. הבנו שהתיאוריה לא אושרה ב-100% וההצעה הראשונית עם פרוקסי CDN לא תעבוד עבורנו.
4. לא לקחנו סיכונים - לא שינינו תצורות ייצור עבור לקוחות.
5. שום דבר לא נשבר.

אב טיפוס 2.0

אז, חזור ללוח השרטוט וחזור על התהליך שוב.

הרעיון הוא שבמקום להשתמש ב-100% פרוקסי, נקבע את הנתיב המהיר ביותר לכל לקוח, ונשלח לשם בקשות – כלומר, נעשה מה שנקרא היגוי לקוח.

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

התשובה היא להשתמש ב-DNS. במקרה שלנו, יש לנו תשתית DNS משלנו, ואנחנו יכולים להגדיר אזור תחום שעבורו השרתים שלנו יהיו אוטוריטריים. זה עובד ככה:

1. הלקוח מגיש בקשה לשרת ה-DNS באמצעות מארח, למשל api.netflix.xom.
2. הבקשה מגיעה לשרת ה-DNS שלנו
3. שרת ה-DNS יודע איזה נתיב הוא המהיר ביותר עבור לקוח זה ומנפיק את כתובת ה-IP המתאימה.

לפתרון מורכבות נוספת: ספקי DNS סמכותיים אינם רואים את כתובת ה-IP של הלקוח ויכולים לקרוא רק את כתובת ה-IP של הפותר הרקורסי בו משתמש הלקוח.

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

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

אנחנו מקבלים את המערכת הבאה:

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

שוב, השאלה היא באיזו יעילות גישה זו תעבוד? כדי לענות, אנו שוב משתמשים במערכת הבדיקה שלנו. לכן, אנו מגדירים את תצורת המציג, כאשר אחד היעדים עוקב אחר הכיוון מהיגוי DNS, השני עובר ישירות לענן (ייצור נוכחי).

כתוצאה מכך, אנו משווים את התוצאות ומקבלים הערכה של היעילות:

כתוצאה מכך, למדנו מספר דברים חשובים:

1. הערכנו את הביצועים הצפויים של בקשות מלקוחות לענן באמצעות DNS Steering.
2. קיבלנו נתונים מלקוחות אמיתיים, מכל סוגי המכשירים.
3. האפקטיביות של הרעיון המוצע הוכחה.
4. לא לקחנו סיכונים - לא שינינו תצורות ייצור עבור לקוחות.
5. שום דבר לא נשבר.

עכשיו לגבי החלק הקשה - אנחנו משיקים אותו בייצור

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

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

לכן נמשיך לדבר על שינה רגועה ובריאה.

איך להמשיך בפיתוח ולא לבזבז את כל זמנך בתמיכה? הגישה שלנו מבוססת על 3 עקרונות:

1. אנו מצמצמים את קנה המידה הפוטנציאלי של תקלות (רדיוס פיצוץ).
2. אנחנו מתכוננים להפתעות - אנחנו מצפים שמשהו ישבר, למרות בדיקות וניסיון אישי.
3. השפלה חיננית – אם משהו לא עובד נכון, יש לתקן אותו אוטומטית, גם אם לא בצורה היעילה ביותר.

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

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

1. בדיקה לדוגמה.
2. בדיקות A/B או קנריות.
3. השקה מתקדמת.

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

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

לאחר מכן אנו מתקינים את ה-build עם השינויים בשרת הקנרי. כדי להעריך את התוצאות, אנו מפעילים מערכת המשווה כ-100-150 מדדים עם מדגם של שרתי בקרה:

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

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

• מלקוחות - מספר פגישות ובקשות, שיעורי נפילה;
• פרוקסי - סטטיסטיקה על מספר ושעת הבקשות;
• DNS - מספר ותוצאות של בקשות;
• cloud edge - מספר וזמן לעיבוד בקשות בענן.

כל זה נאסף לצינור אחד, ובהתאם לצרכים, אנחנו מחליטים אילו מדדים לשלוח לניתוח בזמן אמת, ואילו ל-Elasticsearch או Big Data לאבחון מפורט יותר.

אנחנו עוקבים

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

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

כדי לזהות ולבחון בעיות אנו משתמשים במערכת קוד פתוח משלנו בזמן אמת אטלס и לום - להדמיה. הוא מאחסן מדדים מצטברים בזיכרון, הוא אמין ומשתלב עם מערכת ההתראה. עבור לוקליזציה ואבחון, יש לנו גישה ליומנים מ- Elasticsearch ומ-Kibana. לניתוח סטטיסטי ומידול, אנו משתמשים ב-Big Data והדמיה ב-Tableau.

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

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

• אחוז נפילה של לקוחות - הערכת התנהגות הלקוח;
• אחוז שגיאות בדיקה - נתוני יציבות של רכיבי רשת.

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

1. יש כשל של לקוח אם ה-proxy שלנו לא עובד.
2. ישנה מערכת היגוי אוטומטית המגיבה לבעיות.

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

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

דוגמאות:

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

לפיכך, ניתן לנסח את עקרונות התמיכה במערכת באופן הבא:

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

לקחים

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

בהתבסס על הניסיון שלנו, אנו יכולים להמליץ ​​על הדברים הבאים:

1. אל תסמוך על האינטואיציה שלך.

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

2. קבל נתונים מהפקה.

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

3. אל תפעל לפי עצות ותוצאות של אחרים - אסוף את הנתונים שלך.

   עקוב אחר העקרונות לאיסוף וניתוח נתונים, אך אל קבל באופן עיוור את התוצאות וההצהרות של אנשים אחרים. רק אתה יכול לדעת בדיוק מה עובד עבור המשתמשים שלך. המערכות שלך והלקוחות שלך עשויים להיות שונים באופן משמעותי מחברות אחרות. למרבה המזל, כלי ניתוח זמינים כעת וקלים לשימוש. ייתכן שהתוצאות שתקבלו אינן מה שטוענות Netflix, Facebook, Akamai וחברות אחרות. במקרה שלנו, הביצועים של TLS, HTTP2 או נתונים סטטיסטיים על בקשות DNS שונים מהתוצאות של Facebook, Uber, Akamai - מכיוון שיש לנו מכשירים, לקוחות ותזרימי נתונים שונים.

4. אל תעקבו אחר מגמות אופנה שלא לצורך והעריכו את האפקטיביות.

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

5. התכונן ליישומים חדשים.

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

   • כדי לאזן את התעבורה בין אזורי AWS ולהפחית עלויות;
   • לדגם יציבות CDN;
   • כדי להגדיר DNS;
   • כדי להגדיר TLS/TCP.

מסקנה

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

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

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

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

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

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

מקור: www.habr.com