🥇वेब-हाईलोड - हम हजारों डोमेन के ट्रैफ़िक का प्रबंधन कैसे करते हैं

DDoS-Guard नेटवर्क पर वैध ट्रैफ़िक हाल ही में प्रति सेकंड एक सौ गीगाबिट से अधिक हो गया है। वर्तमान में, हमारे सभी ट्रैफ़िक का 50% क्लाइंट वेब सेवाओं द्वारा उत्पन्न होता है। ये कई दसियों हज़ार डोमेन हैं, बहुत भिन्न और अधिकांश मामलों में व्यक्तिगत दृष्टिकोण की आवश्यकता होती है।

कट के नीचे बताया गया है कि हम फ्रंट नोड्स को कैसे प्रबंधित करते हैं और सैकड़ों हजारों साइटों के लिए एसएसएल प्रमाणपत्र जारी करते हैं।

किसी एक साइट के लिए फ्रंट सेट करना, यहां तक कि बहुत बड़ी साइट के लिए भी, आसान है। हम nginx या haproxy याlighttpd लेते हैं, इसे गाइड के अनुसार कॉन्फ़िगर करते हैं और इसके बारे में भूल जाते हैं। यदि हमें कुछ बदलने की आवश्यकता होती है, तो हम पुनः लोड करते हैं और फिर से भूल जाते हैं।

जब आप तुरंत बड़ी मात्रा में ट्रैफ़िक संसाधित करते हैं, अनुरोधों की वैधता का मूल्यांकन करते हैं, उपयोगकर्ता सामग्री को संपीड़ित और कैश करते हैं, और साथ ही प्रति सेकंड कई बार पैरामीटर बदलते हैं तो सब कुछ बदल जाता है। उपयोगकर्ता अपने व्यक्तिगत खाते में सेटिंग्स बदलने के तुरंत बाद सभी बाहरी नोड्स पर परिणाम देखना चाहता है। एक उपयोगकर्ता एपीआई के माध्यम से व्यक्तिगत ट्रैफ़िक प्रोसेसिंग मापदंडों के साथ कई हजार (और कभी-कभी हजारों) डोमेन भी डाउनलोड कर सकता है। यह सब अमेरिका, यूरोप और एशिया में भी तुरंत काम करना चाहिए - यह कार्य सबसे मामूली नहीं है, यह देखते हुए कि अकेले मॉस्को में कई शारीरिक रूप से अलग किए गए निस्पंदन नोड हैं।

दुनिया भर में इतने सारे बड़े विश्वसनीय नोड क्यों हैं?

ग्राहक यातायात के लिए सेवा की गुणवत्ता - संयुक्त राज्य अमेरिका से अनुरोधों को संयुक्त राज्य अमेरिका में संसाधित करने की आवश्यकता है (हमलों, पार्सिंग और अन्य विसंगतियों सहित), और मॉस्को या यूरोप में नहीं खींचा जाना चाहिए, जिससे प्रसंस्करण में अप्रत्याशित रूप से देरी हो रही है।
हमले के ट्रैफ़िक को स्थानीयकृत किया जाना चाहिए - ट्रांज़िट ऑपरेटर हमलों के दौरान ख़राब हो सकते हैं, जिसकी मात्रा अक्सर 1Tbps से अधिक हो जाती है। ट्रान्साटलांटिक या ट्रांसएशियाई लिंक पर आक्रमण यातायात का परिवहन एक अच्छा विचार नहीं है। हमारे पास वास्तविक मामले थे जब टियर-1 ऑपरेटरों ने कहा: "आपको मिलने वाले हमलों की मात्रा हमारे लिए खतरनाक है।" इसीलिए हम आने वाली धाराओं को यथासंभव उनके स्रोतों के करीब स्वीकार करते हैं।
सेवा की निरंतरता के लिए सख्त आवश्यकताएं - सफाई केंद्रों को हमारी तेजी से बदलती दुनिया में एक-दूसरे पर या स्थानीय घटनाओं पर निर्भर नहीं होना चाहिए। क्या आपने एमएमटीएस-11 की सभी 9 मंजिलों की बिजली एक सप्ताह के लिए काट दी? - कोई बात नहीं। एक भी ग्राहक जिसका इस विशेष स्थान में भौतिक संबंध नहीं है, पीड़ित नहीं होगा, और वेब सेवाएं किसी भी परिस्थिति में प्रभावित नहीं होंगी।

यह सब कैसे प्रबंधित करें?

सेवा कॉन्फ़िगरेशन को सभी फ्रंट नोड्स पर यथाशीघ्र (आदर्श रूप से तुरंत) वितरित किया जाना चाहिए। आप केवल टेक्स्ट कॉन्फ़िगरेशन नहीं ले सकते हैं और न ही उसका पुनर्निर्माण कर सकते हैं और न ही प्रत्येक परिवर्तन पर डेमॉन को रीबूट कर सकते हैं - वही nginx कुछ और मिनटों के लिए प्रक्रियाओं को बंद कर देता है (कार्यकर्ता बंद कर देता है) (या लंबे वेबसॉकेट सत्र होने पर शायद घंटों तक)।

Nginx कॉन्फ़िगरेशन को पुनः लोड करते समय, निम्न चित्र बिल्कुल सामान्य है:

स्मृति उपयोग पर:

पुराने कर्मचारी मेमोरी को खा जाते हैं, जिसमें वह मेमोरी भी शामिल है जो रैखिक रूप से कनेक्शन की संख्या पर निर्भर नहीं करती - यह सामान्य है। जब क्लाइंट कनेक्शन बंद हो जाएंगे, तो यह मेमोरी मुक्त हो जाएगी।

जब nginx अभी शुरू ही हुआ था तो यह कोई मुद्दा क्यों नहीं था? कोई HTTP/2 नहीं था, कोई WebSocket नहीं था, कोई बड़े पैमाने पर लंबे समय तक सक्रिय रहने वाला कनेक्शन नहीं था। हमारे वेब ट्रैफ़िक का 70% HTTP/2 है, जिसका अर्थ है बहुत लंबा कनेक्शन।

समाधान सरल है - nginx का उपयोग न करें, टेक्स्ट फ़ाइलों के आधार पर फ़्रंट प्रबंधित न करें, और निश्चित रूप से ट्रांसपेसिफिक चैनलों पर ज़िप्ड टेक्स्ट कॉन्फ़िगरेशन न भेजें। बेशक, चैनल गारंटीकृत और आरक्षित हैं, लेकिन यह उन्हें किसी भी कम अंतरमहाद्वीपीय नहीं बनाता है।

हमारे पास अपना स्वयं का फ्रंट सर्वर-बैलेंसर है, जिसके आंतरिक भाग के बारे में मैं निम्नलिखित लेखों में बात करूंगा। मुख्य बात जो यह कर सकता है वह है प्रति सेकंड हजारों कॉन्फ़िगरेशन परिवर्तन लागू करना, बिना पुनरारंभ किए, पुनः लोड किए, मेमोरी खपत में अचानक वृद्धि, और यह सब। यह हॉट कोड रीलोड के समान है, उदाहरण के लिए एर्लैंग में। डेटा को भू-वितरित कुंजी-मूल्य डेटाबेस में संग्रहीत किया जाता है और फ्रंट एक्चुएटर्स द्वारा तुरंत पढ़ा जाता है। वे। आप मॉस्को में वेब इंटरफ़ेस या एपीआई के माध्यम से एसएसएल प्रमाणपत्र अपलोड करते हैं, और कुछ ही सेकंड में यह लॉस एंजिल्स में हमारे सफाई केंद्र में जाने के लिए तैयार है। यदि अचानक विश्व युद्ध होता है और पूरी दुनिया में इंटरनेट गायब हो जाता है, तो हमारे नोड्स स्वायत्त रूप से काम करना जारी रखेंगे और समर्पित चैनलों में से एक लॉस एंजिल्स-एम्स्टर्डम-मॉस्को, मॉस्को-एम्स्टर्डम-हांगकांग- जैसे ही विभाजित मस्तिष्क की मरम्मत करेंगे। लॉस-लॉस उपलब्ध हो जाता है। एंजिल्स या कम से कम जीआरई बैकअप ओवरले में से एक।

यही तंत्र हमें लेट्स एनक्रिप्ट प्रमाणपत्रों को तुरंत जारी करने और नवीनीकृत करने की अनुमति देता है। बहुत सरलता से यह इस प्रकार काम करता है:

जैसे ही हम अपने क्लाइंट के डोमेन के लिए बिना प्रमाणपत्र (या समाप्त प्रमाणपत्र के साथ) के लिए कम से कम एक HTTPS अनुरोध देखते हैं, अनुरोध स्वीकार करने वाला बाहरी नोड आंतरिक प्रमाणीकरण प्राधिकरण को इसकी रिपोर्ट करता है।
यदि उपयोगकर्ता ने लेट्स एनक्रिप्ट जारी करने पर रोक नहीं लगाई है, तो प्रमाणन प्राधिकरण एक सीएसआर उत्पन्न करता है, एलई से एक पुष्टिकरण टोकन प्राप्त करता है और इसे एक एन्क्रिप्टेड चैनल पर सभी मोर्चों पर भेजता है। अब कोई भी नोड LE से मान्य अनुरोध की पुष्टि कर सकता है।
कुछ ही क्षणों में, हमें सही प्रमाणपत्र और निजी कुंजी प्राप्त हो जाएगी और इसे उसी तरह मोर्चों पर भेज दिया जाएगा। फिर से, डेमॉन को पुनः आरंभ किए बिना
समाप्ति तिथि से 7 दिन पहले प्रमाणपत्र पुनः प्राप्त करने की प्रक्रिया शुरू की जाती है

अभी हम वास्तविक समय में 350k प्रमाणपत्रों को घुमा रहे हैं, जो उपयोगकर्ताओं के लिए पूरी तरह से पारदर्शी हैं।

श्रृंखला के निम्नलिखित लेखों में, मैं बड़े वेब ट्रैफ़िक के वास्तविक समय प्रसंस्करण की अन्य विशेषताओं के बारे में बात करूंगा - उदाहरण के लिए, ट्रांज़िट ग्राहकों के लिए सेवा की गुणवत्ता में सुधार के लिए अपूर्ण डेटा का उपयोग करके आरटीटी का विश्लेषण करने के बारे में और सामान्य तौर पर ट्रांज़िट ट्रैफ़िक की सुरक्षा के बारे में टेराबिट हमले, ट्रैफ़िक जानकारी के वितरण और एकत्रीकरण के बारे में, WAF के बारे में, लगभग असीमित CDN और सामग्री वितरण को अनुकूलित करने के लिए कई तंत्र।

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

आप पहले क्या जानना चाहेंगे?

14,3% तक वेब ट्रैफ़िक की गुणवत्ता को क्लस्टर करने और उसका विश्लेषण करने के लिए एल्गोरिदम<3
33,3% तक DDoS-Guard7 बैलेंसर्स के आंतरिक भाग
9,5% तक पारगमन L3/L4 यातायात की सुरक्षा2
0,0% तक ट्रांज़िट ट्रैफ़िक पर वेबसाइटों की सुरक्षा करना0
14,3% तक वेब एप्लिकेशन फ़ायरवॉल3
28,6% तक पार्सिंग और क्लिक करने से सुरक्षा6

21 उपयोगकर्ताओं ने मतदान किया। 6 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com

वेब हाईलोड - हम हजारों डोमेन के लिए ट्रैफ़िक कैसे प्रबंधित करते हैं

दुनिया भर में इतने सारे बड़े विश्वसनीय नोड क्यों हैं?

यह सब कैसे प्रबंधित करें?

आप पहले क्या जानना चाहेंगे?

एक टिप्पणी जोड़ें उत्तर रद्द