Web HighLoad - כיצד אנו מנהלים תעבורה עבור עשרות אלפי דומיינים

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

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

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

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

מדוע יש הרבה צמתים אמינים גדולים ברחבי העולם?

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

• תעבורת התקיפה חייבת להיות מקומית - מפעילי תחבורה יכולים להתדרדר במהלך התקפות, שנפחן עולה לרוב על 1Tbps. העברת תעבורת תקיפה דרך קישורים טרנס-אטלנטיים או טרנס-אסייתיים אינה רעיון טוב. היו לנו מקרים אמיתיים כאשר מפעילי Tier-1 אמרו: "היקף ההתקפות שאתה מקבל מסוכן עבורנו." זו הסיבה שאנו מקבלים זרמים נכנסים קרובים ככל האפשר למקורותיהם.

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

איך לנהל את כל זה?

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

בעת טעינת תצורת nginx, התמונה הבאה די נורמלית:

על שימוש בזיכרון:

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

מדוע זו לא הייתה בעיה כאשר nginx רק התחילה? לא היו HTTP/2, לא WebSocket, לא היו חיבורי שמירה ארוכים מאסיביים. 70% מתעבורת האינטרנט שלנו היא HTTP/2, כלומר חיבורים ארוכים מאוד.

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

יש לנו איזון שרת קדמי משלנו, שעליהם הפנימיות אדבר במאמרים הבאים. הדבר העיקרי שהוא יכול לעשות הוא להחיל אלפי שינויי תצורה בשנייה תוך כדי תנועה, ללא הפעלה מחדש, טעינה מחדש, עלייה פתאומית בצריכת הזיכרון וכל זה. זה דומה מאוד ל-Hot Code Reload, למשל ב-Erlang. הנתונים מאוחסנים במסד נתונים גיאוגרפי של ערכי מפתח ונקראים מיד על ידי המפעילים הקדמיים. הָהֵן. אתה מעלה את אישור ה-SSL דרך ממשק האינטרנט או ה-API במוסקבה, ותוך מספר שניות הוא מוכן ללכת למרכז הניקיון שלנו בלוס אנג'לס. אם תתרחש פתאום מלחמת עולם והאינטרנט ייעלם בכל העולם, הצמתים שלנו ימשיכו לעבוד באופן אוטונומי ולתקן את המוח המפוצל ברגע אחד מהערוצים הייעודיים לוס אנג'לס-אמסטרדם-מוסקבה, מוסקבה-אמסטרדם-הונג קונג- Los-Los הופך זמין. אנג'לס או לפחות אחת משכבות הגיבוי של GRE.

אותו מנגנון מאפשר לנו להנפיק ולחדש באופן מיידי תעודות Let's Encrypt. פשוט מאוד זה עובד ככה:

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

   

2. אם המשתמש לא אסר על הנפקת Let's Encrypt, רשות האישורים מייצרת CSR, מקבלת אסימון אישור מ-LE ושולחת אותו לכל החזיתות בערוץ מוצפן. כעת כל צומת יכול לאשר בקשת אימות מ-LE.

   

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

   

4. 7 ימים לפני תאריך התפוגה מתחיל הליך קבלת האישור מחדש

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

מה תרצה לדעת קודם?

• 14,3%אלגוריתמים לאשכול וניתוח איכות תעבורת האינטרנט<3

• 33,3%פנימיות של מאזני DDoS-Guard7

• 9,5%הגנה על תעבורת מעבר L3/L4

• 0,0%הגנה על אתרי אינטרנט על תעבורת תחבורה ציבורית0

• 14,3%חומת אש של אפליקציות אינטרנט3

• 28,6%הגנה מפני ניתוח ולחיצה6

21 משתמשים הצביעו. 6 משתמשים נמנעו.

מקור: www.habr.com