वेब हाईलोड - हामी कसरी हजारौं डोमेनहरूको लागि ट्राफिक व्यवस्थापन गर्छौं

DDoS-Guard नेटवर्कमा वैध ट्राफिक भर्खरै प्रति सेकेन्ड एक सय गिगाबिट्स नाघेको छ। हाल, हाम्रो सबै ट्राफिकको 50% ग्राहक वेब सेवाहरू द्वारा उत्पन्न हुन्छ। यी धेरै हजारौं डोमेनहरू हुन्, धेरै फरक र धेरै जसो केसहरूमा व्यक्तिगत दृष्टिकोण चाहिन्छ।

कट तल हामी कसरी फ्रन्ट नोडहरू व्यवस्थापन गर्छौं र सयौं हजारौं साइटहरूको लागि SSL प्रमाणपत्रहरू जारी गर्छौं।

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

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

संसारभरि किन धेरै ठूला भरपर्दो नोडहरू छन्?

• ग्राहक ट्राफिकको लागि सेवाको गुणस्तर - संयुक्त राज्य अमेरिकाबाट अनुरोधहरू संयुक्त राज्य अमेरिकामा प्रशोधन गर्न आवश्यक छ (आक्रमण, पार्सिङ र अन्य विसंगतिहरू सहित), र मस्को वा युरोपमा तानिएको छैन, अप्रत्याशित रूपमा प्रशोधन ढिलाइ बढाउँदै।

• आक्रमण ट्राफिक स्थानीयकृत हुनुपर्दछ - ट्रान्जिट अपरेटरहरूले आक्रमणको समयमा घटाउन सक्छन्, जसको मात्रा प्रायः 1Tbps भन्दा बढी हुन्छ। ट्रान्सएट्लान्टिक वा ट्रान्ससियन लिंकहरूमा आक्रमण ट्राफिक ढुवानी गर्नु राम्रो विचार होइन। हामीसँग वास्तविक केसहरू थिए जब टियर-१ अपरेटरहरूले भने: "तपाईंले प्राप्त गर्नुभएको आक्रमणको मात्रा हाम्रो लागि खतरनाक छ।" यसैले हामी आगमन स्ट्रिमहरूलाई उनीहरूको स्रोतको नजिकको रूपमा स्वीकार गर्छौं।

• सेवाको निरन्तरताका लागि कडा आवश्यकताहरू - सफाई केन्द्रहरू एकअर्कामा वा हाम्रो द्रुत रूपमा परिवर्तन भएको संसारमा स्थानीय घटनाहरूमा निर्भर हुनु हुँदैन। के तपाईंले एक हप्ताको लागि MMTS-11 को सबै 9 तलाको बिजुली काट्नु भयो? - समस्या छैन। यस विशेष स्थानमा भौतिक जडान नभएको एकल ग्राहकले पीडित हुने छैन, र वेब सेवाहरू कुनै पनि परिस्थितिमा पीडित हुनेछैनन्।

यो सबै कसरी व्यवस्थापन गर्ने?

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

nginx कन्फिगरेसन पुन: लोड गर्दा, निम्न चित्र एकदम सामान्य छ:

मेमोरी उपयोगमा:

पुराना कामदारहरूले मेमोरी खान्छ, मेमोरी सहित जुन रैखिक रूपमा जडानहरूको संख्यामा निर्भर हुँदैन - यो सामान्य हो। जब क्लाइन्ट जडानहरू बन्द हुन्छन्, यो मेमोरी खाली हुनेछ।

किन यो एउटा मुद्दा थिएन जब nginx भर्खरै सुरु हुँदै थियो? त्यहाँ कुनै HTTP/2 थिएन, कुनै WebSocket थिएन, कुनै ठूलो लामो जीवित जडानहरू थिएन। हाम्रो वेब ट्राफिकको 70% HTTP/2 हो, जसको अर्थ धेरै लामो जडानहरू छन्।

समाधान सरल छ - nginx प्रयोग नगर्नुहोस्, पाठ फाइलहरूमा आधारित फ्रन्टहरू व्यवस्थापन नगर्नुहोस्, र निश्चित रूपमा ट्रान्सप्यासिफिक च्यानलहरूमा जिप गरिएको पाठ कन्फिगरेसनहरू नपठाउनुहोस्। च्यानलहरू, निस्सन्देह, ग्यारेन्टी र आरक्षित छन्, तर यसले तिनीहरूलाई कुनै पनि कम ट्रान्सकन्टिनेन्टल बनाउँदैन।

हामीसँग हाम्रो आफ्नै फ्रन्ट सर्भर-ब्यालेन्सर छ, जसको भित्री म निम्न लेखहरूमा कुरा गर्नेछु। यसले गर्न सक्ने मुख्य कुरा भनेको उडानमा प्रति सेकेन्ड हजारौं कन्फिगरेसन परिवर्तनहरू लागू गर्नु हो, पुन: सुरु नगरी, पुन: लोड, मेमोरी खपतमा अचानक वृद्धि, र ती सबै। यो हट कोड रिलोडसँग धेरै मिल्दोजुल्दो छ, उदाहरणका लागि Erlang मा। डाटा भू-वितरित कुञ्जी-मान डाटाबेसमा भण्डार गरिएको छ र अगाडि एक्चुएटरहरू द्वारा तुरुन्तै पढिन्छ। ती। तपाईंले मस्कोमा वेब इन्टरफेस वा API मार्फत SSL प्रमाणपत्र अपलोड गर्नुहुन्छ, र केही सेकेन्डमा यो लस एन्जलसको हाम्रो सफाई केन्द्रमा जानको लागि तयार छ। यदि अचानक विश्वयुद्ध भयो र इन्टरनेट संसारभरि गायब भयो भने, हाम्रा नोडहरूले स्वायत्त रूपमा काम गर्न जारी राख्नेछ र एक समर्पित च्यानल लस एन्जलस-एम्स्टर्डम-मस्को, मस्को-एम्स्टर्डम-ह Hongक Kong- को रूपमा चाँडै विभाजित मस्तिष्क मर्मत गर्नेछ। लस-लस उपलब्ध हुन्छ। एन्जलस वा कम्तिमा एउटा GRE ब्याकअप ओभरले।

यही मेकानिजमले हामीलाई तुरुन्तै प्रमाण पत्रहरू इन्क्रिप्ट गर्न र नवीकरण गर्न अनुमति दिन्छ। धेरै सरल रूपमा यो काम गर्दछ:

1. हामीले हाम्रो क्लाइन्टको डोमेनको लागि प्रमाणपत्र बिना (वा म्याद सकिएको प्रमाणपत्र सहित) कम्तिमा एउटा HTTPS अनुरोध देख्ने बित्तिकै, अनुरोध स्वीकार गर्ने बाह्य नोडले आन्तरिक प्रमाणीकरण प्राधिकरणलाई यो रिपोर्ट गर्छ।

   

2. यदि प्रयोगकर्ताले Let's Encrypt जारी गर्न निषेध गरेको छैन भने, प्रमाणीकरण प्राधिकरणले CSR उत्पन्न गर्दछ, LE बाट पुष्टिकरण टोकन प्राप्त गर्दछ र यसलाई एन्क्रिप्टेड च्यानलमा सबै मोर्चाहरूमा पठाउँदछ। अब कुनै पनि नोडले LE बाट प्रमाणीकरण अनुरोध पुष्टि गर्न सक्छ।

   

3. केही क्षणमा, हामी सही प्रमाणपत्र र निजी कुञ्जी प्राप्त गर्नेछौं र त्यसै गरी मोर्चाहरूमा पठाउनेछौं। फेरि, डेमनहरू पुन: सुरु नगरी

   

4. म्याद सकिने मिति भन्दा 7 दिन अघि, प्रमाणपत्र पुन: प्राप्त गर्ने प्रक्रिया सुरु हुन्छ

अहिले हामी वास्तविक समयमा 350k प्रमाणपत्रहरू घुमाउँदै छौं, प्रयोगकर्ताहरूलाई पूर्ण रूपमा पारदर्शी।

शृङ्खलाका निम्न लेखहरूमा, म ठूलो वेब ट्राफिकको वास्तविक-समय प्रशोधनका अन्य सुविधाहरूको बारेमा कुरा गर्नेछु - उदाहरणका लागि, ट्रान्जिट ग्राहकहरूको लागि सेवाको गुणस्तर सुधार गर्न र सामान्यतया ट्रान्जिट ट्राफिकको सुरक्षाको लागि अपूर्ण डाटा प्रयोग गरेर 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