वेब हायलोड - आम्ही हजारो डोमेनसाठी रहदारी कशी व्यवस्थापित करतो

डीडीओएस-गार्ड नेटवर्कवरील कायदेशीर रहदारी अलीकडे प्रति सेकंद शंभर गिगाबिट्स ओलांडली आहे. सध्या, आमच्या सर्व रहदारीपैकी 50% क्लायंट वेब सेवांद्वारे व्युत्पन्न केली जाते. ही अनेक हजारो डोमेन्स आहेत, खूप वेगळी आणि बहुतेक प्रकरणांमध्ये वैयक्तिक दृष्टीकोन आवश्यक आहे.

आम्ही फ्रंट नोड्स कसे व्यवस्थापित करतो आणि शेकडो हजारो साइट्ससाठी SSL प्रमाणपत्रे कशी जारी करतो हे कट खाली दिले आहे.

एका साइटसाठी फ्रंट सेट करणे, अगदी मोठ्या साइटसाठी, सोपे आहे. आम्ही nginx किंवा haproxy किंवा lighttpd घेतो, ते मार्गदर्शकांनुसार कॉन्फिगर करतो आणि त्याबद्दल विसरतो. आम्हाला काहीतरी बदलण्याची आवश्यकता असल्यास, आम्ही रीलोड करतो आणि पुन्हा विसरतो.

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

जगभरात अनेक मोठ्या विश्वासार्ह नोड्स का आहेत?

• क्लायंट रहदारीसाठी सेवेची गुणवत्ता - यूएसए कडून आलेल्या विनंत्यांवर यूएसएमध्ये प्रक्रिया करणे आवश्यक आहे (हल्ला, पार्सिंग आणि इतर विसंगतींसह), आणि मॉस्को किंवा युरोपकडे खेचले जाणार नाही, प्रक्रिया विलंब अनपेक्षितपणे वाढतो.

• अटॅक ट्रॅफिकचे स्थानिकीकरण करणे आवश्यक आहे - ट्रान्झिट ऑपरेटर हल्ल्यांदरम्यान खराब होऊ शकतात, ज्याचा आवाज अनेकदा 1Tbps पेक्षा जास्त असतो. ट्रान्सअटलांटिक किंवा ट्रान्सेशियन लिंक्सवर अटॅक ट्रॅफिकची वाहतूक करणे ही चांगली कल्पना नाही. आमच्याकडे वास्तविक प्रकरणे होती जेव्हा टियर -1 ऑपरेटर म्हणाले: "तुम्हाला प्राप्त झालेल्या हल्ल्यांचे प्रमाण आमच्यासाठी धोकादायक आहे." म्हणूनच आम्ही येणारे प्रवाह त्यांच्या स्रोतांच्या शक्य तितक्या जवळ स्वीकारतो.

• सेवेच्या निरंतरतेसाठी कठोर आवश्यकता - आपल्या वेगाने बदलणाऱ्या जगात स्वच्छता केंद्रे एकमेकांवर किंवा स्थानिक घटनांवर अवलंबून नसावीत. तुम्ही एका आठवड्यासाठी MMTS-11 च्या सर्व 9 मजल्यांची वीज खंडित केली होती का? - काही हरकत नाही. या विशिष्ट ठिकाणी प्रत्यक्ष कनेक्शन नसलेल्या एकाही क्लायंटला त्रास होणार नाही आणि वेब सेवांना कोणत्याही परिस्थितीत त्रास होणार नाही.

हे सगळं कसं सांभाळायचं?

सेवा कॉन्फिगरेशन शक्य तितक्या लवकर सर्व फ्रंट नोड्सवर वितरित केले जावे (आदर्श तत्काळ). तुम्ही फक्त मजकूर कॉन्फिगरेशन घेऊ शकत नाही आणि पुनर्बांधणी करू शकत नाही आणि प्रत्येक बदलावेळी डिमन रीबूट करू शकत नाही - तेच nginx आणखी काही मिनिटांसाठी (किंवा लांब वेबसॉकेट सत्रे असल्यास काही तास) प्रक्रिया बंद ठेवते.

nginx कॉन्फिगरेशन रीलोड करताना, खालील चित्र अगदी सामान्य आहे:

मेमरी वापरावर:

जुने कामगार मेमरी खातात, मेमरीसह जी कनेक्शनच्या संख्येवर रेखीयपणे अवलंबून नसते - हे सामान्य आहे. क्लायंट कनेक्शन बंद झाल्यावर, ही मेमरी मुक्त केली जाईल.

nginx नुकतेच सुरू होत असताना ही समस्या का आली नाही? तेथे कोणतेही HTTP/2 नव्हते, कोणतेही वेबसॉकेट नव्हते, कोणतेही मोठे दीर्घकाळ जिवंत कनेक्शन नव्हते. आमच्या वेब ट्रॅफिकपैकी 70% HTTP/2 आहे, ज्याचा अर्थ खूप लांब कनेक्शन आहे.

उपाय सोपा आहे - nginx वापरू नका, मजकूर फाइल्सवर आधारित फ्रंट व्यवस्थापित करू नका आणि निश्चितपणे ट्रान्सपॅसिफिक चॅनेलवर झिप केलेले मजकूर कॉन्फिगरेशन पाठवू नका. चॅनेल अर्थातच गॅरंटीड आणि आरक्षित आहेत, परंतु ते त्यांना कमी ट्रान्सकॉन्टिनेंटल बनवत नाहीत.

आमच्याकडे आमचे स्वतःचे फ्रंट सर्व्हर-बॅलेंसर आहे, ज्याच्या अंतर्गत मी पुढील लेखांमध्ये बोलेन. ते करू शकत असलेली मुख्य गोष्ट म्हणजे फ्लायवर प्रति सेकंद हजारो कॉन्फिगरेशन बदल लागू करणे, रीस्टार्ट न करता, रीलोड होणे, मेमरी वापरामध्ये अचानक वाढ आणि हे सर्व. हे हॉट कोड रीलोड सारखेच आहे, उदाहरणार्थ एर्लांगमध्ये. डेटा भौगोलिक-वितरित की-व्हॅल्यू डेटाबेसमध्ये संग्रहित केला जातो आणि समोरच्या अॅक्ट्युएटर्सद्वारे लगेच वाचला जातो. त्या. तुम्ही मॉस्कोमधील वेब इंटरफेस किंवा API द्वारे SSL प्रमाणपत्र अपलोड कराल आणि काही सेकंदात ते लॉस एंजेलिसमधील आमच्या स्वच्छता केंद्रात जाण्यासाठी तयार आहे. जर अचानक महायुद्ध झाले आणि संपूर्ण जगातून इंटरनेट गायब झाले, तर आमचे नोड्स स्वायत्तपणे काम करत राहतील आणि लॉस एंजेलिस-अ‍ॅमस्टरडॅम-मॉस्को, मॉस्को-अ‍ॅमस्टरडॅम-हाँगकाँग- या समर्पित चॅनेलपैकी एक चॅनेल स्प्लिट-ब्रेन दुरुस्त करतील. लॉस-लॉस उपलब्ध होईल. एंजेलिस किंवा GRE बॅकअप आच्छादनांपैकी किमान एक.

हीच यंत्रणा आम्हांला Let's Encrypt प्रमाणपत्रे झटपट जारी आणि नूतनीकरण करण्यास अनुमती देते. अगदी सोप्या पद्धतीने हे असे कार्य करते:

1. आमच्या क्लायंटच्या डोमेनसाठी प्रमाणपत्राशिवाय (किंवा कालबाह्य प्रमाणपत्रासह) किमान एक HTTPS विनंती दिसताच, विनंती स्वीकारणारा बाह्य नोड अंतर्गत प्रमाणन प्राधिकरणाला याची तक्रार करतो.

   

2. जर वापरकर्त्याने Let's Encrypt जारी करण्यास मनाई केली नसेल, तर प्रमाणन प्राधिकरण एक CSR व्युत्पन्न करते, LE कडून पुष्टीकरण टोकन प्राप्त करते आणि ते सर्व आघाड्यांवर एनक्रिप्टेड चॅनेलवर पाठवते. आता कोणताही नोड LE कडून प्रमाणित विनंतीची पुष्टी करू शकतो.

   

3. काही क्षणात, आम्हाला योग्य प्रमाणपत्र आणि खाजगी की प्राप्त होईल आणि त्याच पद्धतीने मोर्चांना पाठवू. पुन्हा, डिमन रीस्टार्ट न करता

   

4. मुदत संपण्याच्या तारखेच्या 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