Web HighLoad - როგორ ვმართავთ ტრაფიკს ათიათასობით დომენისთვის

DDoS-Guard ქსელში ლეგიტიმურმა ტრაფიკმა ცოტა ხნის წინ გადააჭარბა ას გიგაბიტს წამში. ამჟამად, მთელი ჩვენი ტრაფიკის 50% გენერირდება კლიენტის ვებ სერვისებით. ეს არის მრავალი ათიათასობით დომენი, ძალიან განსხვავებული და უმეტეს შემთხვევაში მოითხოვს ინდივიდუალურ მიდგომას.

ქვემოთ მოცემულია, თუ როგორ ვმართავთ წინა კვანძებს და გავცემთ SSL სერთიფიკატებს ასობით ათასი საიტისთვის.

ერთი საიტისთვის ფრონტის დაყენება, თუნდაც ძალიან დიდი, მარტივია. ვიღებთ nginx-ს ან haproxy-ს ან lighttpd-ს, ვაკონფიგურირებთ მას სახელმძღვანელოების მიხედვით და დავივიწყებთ მას. თუ რაიმეს შეცვლა გვჭირდება, ვაკეთებთ გადატვირთვას და ისევ ვივიწყებთ.

ყველაფერი იცვლება, როდესაც თქვენ ამუშავებთ დიდი მოცულობის ტრაფიკს, აფასებთ მოთხოვნების ლეგიტიმურობას, შეკუმშავთ და ქეშით მომხმარებლის კონტენტს და ამავდროულად ცვლით პარამეტრებს წამში რამდენჯერმე. მომხმარებელს სურს ნახოს შედეგი ყველა გარე კვანძზე, მას შემდეგ რაც შეცვალა პარამეტრები მის პირად ანგარიშში. მომხმარებელს ასევე შეუძლია ჩამოტვირთოთ რამდენიმე ათასი (და ზოგჯერ ათობით ათასი) დომენი ტრაფიკის დამუშავების ინდივიდუალური პარამეტრებით API-ის საშუალებით. ეს ყველაფერი ასევე დაუყოვნებლივ უნდა მუშაობდეს ამერიკაში, ევროპაში და აზიაში - ამოცანა არ არის ყველაზე ტრივიალური, იმის გათვალისწინებით, რომ მხოლოდ მოსკოვში არის რამდენიმე ფიზიკურად გამოყოფილი ფილტრაციის კვანძი.

რატომ არის ბევრი დიდი საიმედო კვანძი მთელს მსოფლიოში?

• სერვისის ხარისხი კლიენტთა ტრაფიკისთვის - აშშ-დან მოთხოვნები უნდა დამუშავდეს აშშ-ში (შეტევების, ანალიზისა და სხვა ანომალიების ჩათვლით) და არა მოსკოვში ან ევროპაში გაყვანა, რაც არაპროგნოზირებად გაზრდის დამუშავების შეფერხებას.

• თავდასხმის ტრაფიკი ლოკალიზებული უნდა იყოს - სატრანზიტო ოპერატორებს შეუძლიათ დეგრადაცია შეტევების დროს, რომელთა მოცულობა ხშირად აღემატება 1Tbps-ს. თავდასხმის ტრაფიკის ტრანსატლანტიკური ან ტრანსაზიური კავშირების ტრანსპორტირება არ არის კარგი იდეა. ჩვენ გვქონდა რეალური შემთხვევები, როდესაც Tier-1 ოპერატორებმა თქვეს: ”შეტევების მოცულობა, რომელსაც თქვენ იღებთ, საშიშია ჩვენთვის”. ამიტომ ჩვენ ვიღებთ შემომავალ ნაკადებს რაც შეიძლება ახლოს მათ წყაროებთან.

• მომსახურების უწყვეტობის მკაცრი მოთხოვნები - დასუფთავების ცენტრები არ უნდა იყოს დამოკიდებული არც ერთმანეთზე და არც ადგილობრივ მოვლენებზე ჩვენს სწრაფად ცვალებად სამყაროში. MMTS-11-ის 9-ვე სართულს ერთი კვირით გამორთეთ დენი? - არაა პრობლემა. არც ერთი კლიენტი, რომელსაც არ აქვს ფიზიკური კავშირი ამ კონკრეტულ ადგილას, არ დაზარალდება და ვებ სერვისები არავითარ შემთხვევაში არ დაზარალდება.

როგორ მართოთ ეს ყველაფერი?

სერვისის კონფიგურაციები უნდა გადანაწილდეს ყველა წინა კვანძზე რაც შეიძლება სწრაფად (იდეალურად მყისიერად). თქვენ არ შეგიძლიათ უბრალოდ აიღოთ და აღადგინოთ ტექსტის კონფიგურაციები და გადატვირთოთ დემონები ყოველი ცვლილებისას - იგივე nginx აგრძელებს პროცესების გათიშვას (მუშაის გამორთვა) კიდევ რამდენიმე წუთის განმავლობაში (ან შესაძლოა საათის განმავლობაში, თუ არის ხანგრძლივი ვებსოკეტის სესიები).

nginx კონფიგურაციის გადატვირთვისას, შემდეგი სურათი საკმაოდ ნორმალურია:

მეხსიერების გამოყენების შესახებ:

ძველი მუშები ჭამენ მეხსიერებას, მათ შორის მეხსიერებას, რომელიც ხაზოვანი არ არის დამოკიდებული კავშირების რაოდენობაზე - ეს ნორმალურია. როდესაც კლიენტის კავშირები დაიხურება, ეს მეხსიერება გათავისუფლდება.

რატომ არ იყო ეს პრობლემა, როდესაც nginx ახლახან იწყებოდა? არ იყო არც HTTP/2, არც WebSocket, არც მასიური ხანგრძლივი შენარჩუნების კავშირები. ჩვენი ვებ ტრაფიკის 70% არის HTTP/2, რაც ნიშნავს ძალიან ხანგრძლივ კავშირებს.

გამოსავალი მარტივია - არ გამოიყენოთ nginx, არ მართოთ ფრონტები ტექსტურ ფაილებზე დაყრდნობით და რა თქმა უნდა არ გაგზავნოთ zipped ტექსტის კონფიგურაციები ტრანსწყნარი ოკეანის არხებზე. არხები, რა თქმა უნდა, გარანტირებულია და დაცულია, მაგრამ ეს მათ ნაკლებად ტრანსკონტინენტურს არ ხდის.

ჩვენ გვაქვს საკუთარი წინა სერვერ-ბალანსერი, რომლის ინტერიერებზე შემდეგ სტატიებში ვისაუბრებ. მთავარი, რისი გაკეთებაც მას შეუძლია, არის ათასობით კონფიგურაციის ცვლილების გამოყენება წამში ფრენის დროს, გადატვირთვის, გადატვირთვის, მეხსიერების მოხმარების უეცარი ზრდის და სხვა ყველაფრის გარეშე. ეს ძალიან ჰგავს Hot Code Reload-ს, მაგალითად Erlang-ში. მონაცემები ინახება გეო-განაწილებულ საკვანძო-მნიშვნელობის მონაცემთა ბაზაში და დაუყოვნებლივ იკითხება წინა აქტივატორების მიერ. იმათ. თქვენ ატვირთავთ SSL სერთიფიკატს მოსკოვში ვებ ინტერფეისის ან API-ის საშუალებით და რამდენიმე წამში ის მზად არის წავიდეს ჩვენს დასუფთავების ცენტრში ლოს ანჯელესში. თუ მსოფლიო ომი მოულოდნელად მოხდა და ინტერნეტი მთელ მსოფლიოში გაქრება, ჩვენი კვანძები განაგრძობენ ავტონომიურ მუშაობას და ტვინში გაყოფის აღდგენას, როგორც კი ერთ-ერთი გამოყოფილი არხი ლოს-ანჯელესი-ამსტერდამი-მოსკოვი, მოსკოვი-ამსტერდამი-ჰონკონგი- Los-Los ხელმისაწვდომი ხდება. Angeles ან GRE-ის სარეზერვო გადაფარვის ერთ-ერთი მაინც.

ეს იგივე მექანიზმი საშუალებას გვაძლევს მყისიერად გავცეთ და განვაახლოთ Let's Encrypt სერთიფიკატები. ძალიან მარტივად მუშაობს ასე:

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 მოძრაობის2 დაცვა

• 0,0%ვებსაიტების დაცვა სატრანზიტო ტრაფიკზე0

• 14,3%ვებ აპლიკაციის Firewall3

• 28,6%დაცვა ანალიზისა და დაწკაპუნებისგან6

მისცა ხმა 21 მომხმარებელმა. 6 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com