Bitrix24: "ის, რაც სწრაფად ამაღლებულია, არ ითვლება დაცემულად"

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

”ჩვენ გავუშვით Bitrix24, როგორც SaaS 7 წლის წინ. მთავარი სირთულე ალბათ შემდეგი იყო: სანამ ის საჯაროდ გამოქვეყნდებოდა, როგორც SaaS, ეს პროდუქტი უბრალოდ არსებობდა ყუთში გადაწყვეტის ფორმატში. კლიენტებმა ის იყიდეს ჩვენგან, უმასპინძლეს მას საკუთარ სერვერებზე, შექმნეს კორპორატიული პორტალი - ზოგადი გადაწყვეტა თანამშრომელთა კომუნიკაციისთვის, ფაილების შესანახად, დავალების მენეჯმენტისთვის, CRM, ეს ყველაფერია. და 2012 წლისთვის, ჩვენ გადავწყვიტეთ, რომ გვინდოდა მისი გაშვება SaaS-ის სახით, მისი ადმინისტრირება თავად, შეცდომების ტოლერანტობისა და საიმედოობის უზრუნველყოფა. გამოცდილება მივიღეთ გზაში, რადგან მანამდე ის უბრალოდ არ გვქონდა - ჩვენ მხოლოდ პროგრამული უზრუნველყოფის მწარმოებლები ვიყავით და არა სერვისის პროვაიდერები.

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

Bitrix.24 როგორც SaaS

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

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

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

ჩვენ შევქმენით მხარდაჭერა პროდუქტის დონეზე სხვადასხვა ღრუბლოვანი ობიექტების შესანახად: google storage, amazon s3, პლუს ღია stack swift-ის მხარდაჭერა. ამიტომ, ეს მოსახერხებელი იყო როგორც ჩვენთვის, როგორც სერვისისთვის, ასევე დეველოპერებისთვის, რომლებიც მუშაობენ შეფუთული გადაწყვეტილებებით: თუ ისინი უბრალოდ იყენებენ ჩვენს API-ს სამუშაოდ, ისინი არ ფიქრობენ იმაზე, თუ სად შეინახება ფაილი საბოლოოდ, ადგილობრივ ფაილურ სისტემაში ან ობიექტის ფაილის შენახვაში.

შედეგად, ჩვენ მაშინვე გადავწყვიტეთ, რომ რეზერვი ვიქნებით მთელი მონაცემთა ცენტრის დონეზე. 2012 წელს ჩვენ მთლიანად გავუშვით Amazon AWS-ზე, რადგან უკვე გვქონდა გამოცდილება ამ პლატფორმაზე - ჩვენი ვებ-გვერდი იქ იყო განთავსებული. ჩვენ მოხიბლული ვიყავით იმით, რომ თითოეულ რეგიონში ამაზონს აქვს რამდენიმე ხელმისაწვდომობის ზონა - ფაქტობრივად, (მათი ტერმინოლოგიით) რამდენიმე მონაცემთა ცენტრი, რომლებიც მეტ-ნაკლებად დამოუკიდებელია ერთმანეთისგან და საშუალებას გვაძლევს დაჯავშნოთ მთელი მონაცემთა ცენტრის დონეზე: თუ ის მოულოდნელად ვერ მოხერხდა, მონაცემთა ბაზები განმეორდება master-master, ვებ აპლიკაციის სერვერების სარეზერვო ასლი და სტატიკური მონაცემები გადაინაცვლებს s3 ობიექტების საცავში. დატვირთვა დაბალანსებულია - იმ დროს Amazon elb-ით, მაგრამ ცოტა მოგვიანებით მივედით საკუთარ დატვირთვის ბალანსერებთან, რადგან უფრო რთული ლოგიკა გვჭირდებოდა.

რაც მათ სურდათ, მიიღეს...

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

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

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

როგორ მუშაობს ეს ყველაფერი? — ჩვენ გადავრთავთ ტრაფიკს სამუშაო მონაცემთა ცენტრში - თუ მონაცემთა ცენტრში მოხდა ავარია, მაშინ მთლიანად, თუ ეს არის ჩვენი დაგეგმილი მუშაობა ერთ მონაცემთა ბაზასთან, მაშინ გადავრთავთ ტრაფიკის ნაწილს, რომელიც ემსახურება ამ კლიენტებს მეორე მონაცემთა ცენტრში, აჩერებს ის რეპლიკაცია. თუ ახალი აპარატები საჭიროა ვებ აპლიკაციებისთვის, რადგან მეორე მონაცემთა ცენტრში დატვირთვა გაიზარდა, ისინი ავტომატურად დაიწყება. ჩვენ ვასრულებთ სამუშაოს, რეპლიკაცია აღდგება და მთელ დატვირთვას ვაბრუნებთ უკან. თუ ჩვენ გვჭირდება რაიმე სამუშაოს ასახვა მეორე DC-ში, მაგალითად, სისტემის განახლებების დაყენება ან პარამეტრების შეცვლა მეორე მონაცემთა ბაზაში, მაშინ, ზოგადად, ჩვენ ვიმეორებთ იგივეს, უბრალოდ სხვა მიმართულებით. და თუ ეს უბედური შემთხვევაა, მაშინ ჩვენ ყველაფერს ტრივიალურად ვაკეთებთ: მონიტორინგის სისტემაში ვიყენებთ მოვლენის დამმუშავებლის მექანიზმს. თუ რამდენიმე შემოწმება ხდება და სტატუსი გადადის კრიტიკულზე, მაშინ ჩვენ ვაწარმოებთ ამ დამმუშავებელს, დამმუშავებელს, რომელსაც შეუძლია ამა თუ იმ ლოგიკის შესრულება. თითოეული მონაცემთა ბაზისთვის ჩვენ განვსაზღვრავთ, რომელი სერვერია მისთვის დამარცხებული და სად არის საჭირო ტრაფიკის შეცვლა, თუ ის მიუწვდომელია. ისტორიულად, ჩვენ ვიყენებთ ნაგიოს ან მის ზოგიერთ ჩანგლს ამა თუ იმ ფორმით. პრინციპში, მსგავსი მექანიზმები არსებობს თითქმის ნებისმიერ მონიტორინგის სისტემაში, ჩვენ ჯერ არ ვიყენებთ უფრო რთულ რამეს, მაგრამ შესაძლოა ოდესმე გამოვიყენოთ. ახლა მონიტორინგი გამოწვეულია მიუწვდომლობის გამო და აქვს რაღაცის გადართვის შესაძლებლობა.

ყველაფერი დაჯავშნული გვაქვს?

გვყავს ბევრი კლიენტი ამერიკიდან, ბევრი კლიენტი ევროპიდან, ბევრი კლიენტი, რომლებიც უფრო ახლოს არიან აღმოსავლეთთან - იაპონია, სინგაპური და ა.შ. რა თქმა უნდა, კლიენტების დიდი წილი რუსეთშია. ანუ სამუშაო არ არის ერთ რეგიონში. მომხმარებლებს სურთ სწრაფი რეაგირება, არსებობს მოთხოვნები სხვადასხვა ადგილობრივი კანონების შესასრულებლად და თითოეულ რეგიონში ჩვენ ვიტოვებთ ორ მონაცემთა ცენტრს, პლუს არის რამდენიმე დამატებითი სერვისი, რომელიც, ისევ და ისევ, მოსახერხებელია განთავსება ერთ რეგიონში - კლიენტებისთვის, რომლებიც იმყოფებიან ეს რეგიონი მუშაობს. REST დამმუშავებლები, ავტორიზაციის სერვერები, ისინი ნაკლებად კრიტიკულნი არიან მთლიანად კლიენტის ფუნქციონირებისთვის, შეგიძლიათ გადახვიდეთ მათში მცირე მისაღები დაგვიანებით, მაგრამ არ გსურთ ხელახლა გამოიგონოთ საჭე, თუ როგორ უნდა დააკვირდეთ მათ და რა უნდა გააკეთოთ. მათთან ერთად. ამიტომ, ჩვენ ვცდილობთ მაქსიმალურად გამოვიყენოთ არსებული გადაწყვეტილებები და არა რაიმე სახის კომპეტენციის განვითარება დამატებით პროდუქტებში. და სადღაც ჩვენ ტრივიალურად ვიყენებთ გადართვას DNS დონეზე და ჩვენ განვსაზღვრავთ სერვისის სიცოცხლისუნარიანობას იგივე DNS-ით. ამაზონს აქვს Route 53 სერვისი, მაგრამ ეს არ არის მხოლოდ DNS, რომელშიც შეგიძლიათ ჩანაწერების გაკეთება და ეს არის ის - ის ბევრად უფრო მოქნილი და მოსახერხებელია. მისი მეშვეობით შეგიძლიათ შექმნათ გეოგანაწილებული სერვისები გეოლოკაციებით, როდესაც იყენებთ იმის დასადგენად, საიდან მოვიდა კლიენტი და მისცემ მას გარკვეული ჩანაწერები - მისი დახმარებით შეგიძლიათ ააწყოთ ფაილვერის არქიტექტურები. იგივე ჯანმრთელობის შემოწმებები კონფიგურირებულია თავად მარშრუტ 53-ში, თქვენ აყენებთ ბოლო წერტილებს, რომლებიც მონიტორინგს ატარებენ, ადგენთ მეტრიკას, ადგენთ რომელი პროტოკოლები განსაზღვრავს სერვისის „სიცოცხლისუნარიანობას“ - tcp, http, https; დააყენეთ შემოწმებების სიხშირე, რომელიც განსაზღვრავს სერვისი ცოცხალია თუ არა. და თავად DNS-ში აკონკრეტებთ რა იქნება პირველადი, რა იქნება მეორადი, სად უნდა გადართოთ, თუ ჯანმრთელობის შემოწმება ამოქმედდება მარშრუტში 53. ეს ყველაფერი შეიძლება გაკეთდეს სხვა ინსტრუმენტებით, მაგრამ რატომ არის მოსახერხებელი - ჩვენ დავაყენეთ ერთხელ და მერე საერთოდ არ იფიქრო იმაზე, თუ როგორ ვამოწმებთ, როგორ ვცვლით: ყველაფერი თავისთავად მუშაობს.

პირველი "მაგრამ": როგორ და რით უნდა დაჯავშნოთ მარშრუტი 53 თავად? ვინ იცის, რა მოხდება, თუ მას რამე დაემართება? საბედნიეროდ, ჩვენ არასდროს დაგვიდგამს ამ საკომისიოზე, მაგრამ კიდევ ერთხელ მექნება ისტორია, თუ რატომ გვეგონა, რომ ჯერ კიდევ გვჭირდებოდა დაჯავშნა. აქ ჩვენ წინასწარ დავყარეთ ჩალაკები. დღეში რამდენჯერმე ვაკეთებთ ყველა იმ ზონის სრულ განტვირთვას, რომელიც გვაქვს 53 მარშრუტზე. Amazon-ის API საშუალებას გაძლევთ მარტივად გაგზავნოთ ისინი JSON-ში და ჩვენ გვაქვს რამდენიმე სარეზერვო სერვერი, სადაც ვაკონვერტირებთ, ვტვირთავთ კონფიგურაციის სახით და გვაქვს, უხეშად რომ ვთქვათ, სარეზერვო კონფიგურაცია. თუ რამე მოხდება, ჩვენ შეგვიძლია სწრაფად განვათავსოთ ის ხელით DNS პარამეტრების მონაცემების დაკარგვის გარეშე.

მეორე "მაგრამ": რა ამ სურათზე ჯერ არ არის დაცული? თავად ბალანსერი! ჩვენი კლიენტების განაწილება რეგიონების მიხედვით ძალიან მარტივია. ჩვენ გვაქვს დომენები bitrix24.ru, bitrix24.com, .de - ახლა არის 13 განსხვავებული დომენები, რომლებიც მოქმედებენ სხვადასხვა ზონებში. ჩვენ მივედით შემდეგზე: თითოეულ რეგიონს ჰყავს თავისი დამაბალანსებლები. ეს უფრო მოსახერხებელს ხდის რეგიონებში განაწილებას, იმისდა მიხედვით, თუ სად არის პიკური დატვირთვა ქსელში. თუ ეს არის მარცხი ერთი ბალანსერის დონეზე, მაშინ ის უბრალოდ ამოღებულია სერვისიდან და ამოღებულია dns-დან. თუ რაიმე პრობლემაა ბალანსერების ჯგუფთან, მაშინ ხდება მათი სარეზერვო ასლი სხვა საიტებზე და მათ შორის გადართვა ხდება იმავე მარშრუტით53, რადგან მოკლე TTL-ის გამო გადართვა ხდება მაქსიმუმ 2, 3, 5 წუთში. .

მესამე "მაგრამ": რა ჯერ არ არის დაცული? S3, სწორია. როდესაც ჩვენ განვათავსეთ ფაილები, რომლებსაც ჩვენ ვინახავთ მომხმარებლებისთვის s3-ში, ჩვენ გულწრფელად გვჯეროდა, რომ ის იყო ჯავშანჟილეტიანი და არ იყო საჭირო იქ რაიმეს დაჯავშნა. მაგრამ ისტორია აჩვენებს, რომ ყველაფერი სხვაგვარად ხდება. ზოგადად, ამაზონი აღწერს S3-ს, როგორც ფუნდამენტურ სერვისს, რადგან თავად Amazon იყენებს S3-ს მანქანური სურათების, კონფიგურაციის, AMI სურათების, სნეპშოტების შესანახად... და თუ s3 ავარიულია, როგორც ეს მოხდა ერთხელ ამ 7 წლის განმავლობაში, რამდენადაც ჩვენ ვიყენებდით. bitrix24, ის მიჰყვება მას გულშემატკივართა მსგავსად. არსებობს უამრავი რამ, რაც ჩნდება - ვირტუალური მანქანების გაშვების შეუძლებლობა, api-ს უკმარისობა და ა.შ.

და S3 შეიძლება დაეცეს - ეს ერთხელ მოხდა. აქედან გამომდინარე, მივედით შემდეგ სქემამდე: რამდენიმე წლის წინ რუსეთში არ არსებობდა სერიოზული საზოგადოებრივი ობიექტების შესანახი ობიექტები და განვიხილეთ საკუთარი თავის გაკეთების ვარიანტი... საბედნიეროდ, ამის გაკეთება არ დაგვიწყია, რადგან გავაკეთებდით. ჩავუღრმავდით იმ ექსპერტიზას, რომელიც არ გვაქვს და, ალბათ, გაფუჭდება. ახლა Mail.ru-ს აქვს s3-თან თავსებადი საცავი, Yandex-ს აქვს და სხვა უამრავ პროვაიდერს აქვს. საბოლოოდ მივედით იმ აზრამდე, რომ გვინდოდა გვქონდეს, პირველ რიგში, სარეზერვო საშუალება და მეორეც, ადგილობრივ ასლებთან მუშაობის შესაძლებლობა. კონკრეტულად რუსეთის რეგიონისთვის, ჩვენ ვიყენებთ Mail.ru Hotbox სერვისს, რომელიც არის API თავსებადი s3-თან. ჩვენ არ დაგვჭირდა აპლიკაციის შიგნით კოდის მნიშვნელოვანი ცვლილებები და გავაკეთეთ შემდეგი მექანიზმი: s3-ში არის ტრიგერები, რომლებიც იწვევს ობიექტების შექმნას/წაშლას, Amazon-ს აქვს სერვისი სახელად Lambda - ეს არის კოდის სერვერის გარეშე გაშვება. რომელიც შესრულდება მხოლოდ მაშინ, როდესაც გარკვეული ტრიგერები ამოქმედდება.

ჩვენ ეს გავაკეთეთ ძალიან მარტივად: თუ ჩვენი გამომწვევი გააქტიურდება, ჩვენ ვასრულებთ კოდს, რომელიც დააკოპირებს ობიექტს Mail.ru საცავში. მონაცემთა ლოკალურ ასლებთან მუშაობის სრულად დასაწყებად, ჩვენ ასევე გვჭირდება საპირისპირო სინქრონიზაცია, რათა რუსულ სეგმენტში მყოფმა კლიენტებმა შეძლონ იმუშაონ მათთან უფრო ახლოს მდებარე საცავთან. ფოსტა აპირებს დაასრულოს ტრიგერები მის შენახვაში - შესაძლებელი იქნება საპირისპირო სინქრონიზაციის განხორციელება ინფრასტრუქტურის დონეზე, მაგრამ ახლა ჩვენ ამას ვაკეთებთ ჩვენივე კოდის დონეზე. თუ ჩვენ ვხედავთ, რომ კლიენტმა გამოაქვეყნა ფაილი, მაშინ კოდის დონეზე ვათავსებთ მოვლენას რიგში, ვამუშავებთ და ვაკეთებთ რევერსის რეპლიკაციას. რატომ არის ეს ცუდი: თუ ჩვენ რაიმე სახის სამუშაოს ვაკეთებთ ჩვენს ობიექტებთან ჩვენი პროდუქტის გარეთ, ანუ რაიმე გარე საშუალებებით, ჩვენ ამას არ გავითვალისწინებთ. ამიტომ, ჩვენ ველოდებით ბოლომდე, როდესაც ტრიგერები გამოჩნდება შენახვის დონეზე, ისე, რომ საიდანაც არ უნდა შევასრულოთ კოდი, ჩვენთან მოსულმა ობიექტმა დაკოპირდეს სხვა მიმართულებით.

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

და ამაზონი გაიქცა...

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

თუ კომპანია გლობალურია და რუსეთი მისთვის ძალიან მცირე სეგმენტია, 3-5% - კარგი, ასეა თუ ისე, შეგიძლიათ შესწიროთ ისინი.

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

რა მოხდება, თუ ეს არის კომპანია, რომელიც მუშაობს გლობალურად და ჰყავს დაახლოებით თანაბარი კლიენტების რაოდენობა რუსეთიდან და მსოფლიოს მასშტაბით? სეგმენტების დაკავშირება მნიშვნელოვანია და ისინი ასე თუ ისე უნდა მუშაობდნენ ერთმანეთთან.

2018 წლის მარტის ბოლოს Roskomnadzor-მა გაუგზავნა წერილი უმსხვილეს ოპერატორებს, სადაც ნათქვამია, რომ აპირებენ ამაზონის რამდენიმე მილიონი IP-ის დაბლოკვას, რათა დაებლოკათ... Zello მესენჯერი. მადლობა ამ იმავე პროვაიდერებს - მათ წარმატებით გაავრცელეს წერილი ყველასთვის და გაიგეს, რომ ამაზონთან კავშირი შეიძლება დაიშალა. პარასკევი იყო, პანიკურად მივვარდით ჩვენს კოლეგებს servers.ru-დან და ვუთხარით: ”მეგობრებო, ჩვენ გვჭირდება რამდენიმე სერვერი, რომელიც განთავსდება არა რუსეთში, არა ამაზონში, არამედ, მაგალითად, სადმე ამსტერდამში”. იმისათვის, რომ შევძლოთ მაინც როგორმე დავაყენოთ იქ ჩვენი საკუთარი VPN და პროქსი ზოგიერთი ბოლო წერტილებისთვის, რომლებზეც ჩვენ ვერანაირად ვერ ვიმოქმედებთ, მაგალითად, იგივე s3-ის ბოლო წერტილებზე - არ შეგვიძლია შევეცადოთ ახალი სერვისის აწევა და სხვა IP-ის მიღება, ჩვენ ჯერ კიდევ გჭირდებათ იქ მისვლა. სულ რამდენიმე დღეში დავაყენეთ ეს სერვერები, ავამუშავეთ და, ზოგადად, მოვემზადეთ ბლოკირების დაწყებისთვის. საინტერესოა, რომ RKN-მ აურზაურისა და პანიკის შემხედვარე თქვა: „არა, ჩვენ ახლა არაფერს დავბლოკავთ“. (მაგრამ ეს ზუსტად იმ მომენტამდე, როდესაც Telegram-ის დაბლოკვა დაიწყო.) შემოვლითი შესაძლებლობების დაყენების შემდეგ და მივხვდით, რომ დაბლოკვა არ იყო შემოღებული, ჩვენ, თუმცა, არ დავიწყეთ მთელი საკითხის დალაგება. დიახ, ყოველი შემთხვევისთვის.

2019 წელს კი კვლავ ბლოკირების პირობებში ვცხოვრობთ. წუხელ გადავხედე: დაახლოებით მილიონი IP აგრძელებს დაბლოკვას. მართალია, ამაზონი თითქმის მთლიანად განბლოკილი იყო, პიკში 20 მილიონ მისამართს მიაღწია... ზოგადად, რეალობა ისაა, რომ შეიძლება არ იყოს თანმიმდევრულობა, კარგი თანმიმდევრულობა. უცებ. შეიძლება ტექნიკური მიზეზების გამო არ არსებობდეს - ხანძარი, ექსკავატორები, ეს ყველაფერი. ან, როგორც ვნახეთ, არა მთლიანად ტექნიკური. მაშასადამე, ვინმე დიდსა და დიდს, საკუთარი AS-ებით, ალბათ შეუძლია ამის მართვა სხვა გზით - პირდაპირი დაკავშირება და სხვა რამ უკვე l2 დონეზეა. მაგრამ მარტივი ვერსიით, როგორც ჩვენი ან თუნდაც უფრო მცირე, შეგიძლიათ, ყოველი შემთხვევისთვის, გქონდეთ ზედმეტი სერვერების დონეზე, რომლებიც ამაღლებულია სხვაგან, წინასწარ არის კონფიგურირებული vpn, პროქსი, ამ სეგმენტებში მათზე კონფიგურაციის სწრაფად გადართვის შესაძლებლობით. რომლებიც გადამწყვეტია თქვენი კავშირისთვის. ეს ჩვენთვის არაერთხელ გამოდგა, როდესაც Amazon-ის დაბლოკვა დაიწყო; უარეს შემთხვევაში, ჩვენ მხოლოდ S3 ტრაფიკს დავუშვებდით მათ მეშვეობით, მაგრამ თანდათან ეს ყველაფერი მოგვარდა.

როგორ დაჯავშნოთ... მთელი პროვაიდერი?

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

ჰიპოთეტურად, Amazon-ისთვის განვიხილავთ სხვა პროვაიდერის დონეზე დაჯავშნის შესაძლებლობას; შესაძლოა Google, შესაძლოა ვინმე სხვა... მაგრამ აქამდე ჩვენ პრაქტიკაში დავაკვირდით, რომ მაშინ, როცა Amazon-ს აქვს ავარიები ერთი ხელმისაწვდომობის ზონის დონეზე, ავარიები მთელი რეგიონის დონეზე საკმაოდ იშვიათია. აქედან გამომდინარე, ჩვენ თეორიულად გვაქვს იდეა, რომ შეიძლება გავაკეთოთ დაჯავშნა „ამაზონი არ არის ამაზონი“, მაგრამ პრაქტიკაში ეს ჯერ ასე არ არის.

რამდენიმე სიტყვა ავტომატიზაციის შესახებ

ყოველთვის საჭიროა ავტომატიზაცია? აქ მიზანშეწონილია გავიხსენოთ დანინგ-კრუგერის ეფექტი. "x" ღერძზე არის ჩვენი ცოდნა და გამოცდილება, რომელსაც ვიღებთ, ხოლო "y" ღერძზე არის ნდობა ჩვენს ქმედებებში. თავიდან არაფერი ვიცით და საერთოდ არ ვართ დარწმუნებული. შემდეგ ჩვენ ცოტა ვიცით და ვხდებით მეგადარწმუნებულნი - ეს არის ეგრეთ წოდებული "სისულელის მწვერვალი", კარგად ასახული სურათით "დემენცია და გამბედაობა". მერე ცოტა ვისწავლეთ და მზად ვართ ბრძოლაში წასასვლელად. მერე რაღაც მეგა-სერიოზულ შეცდომებზე ვდგავართ და სასოწარკვეთილების ხეობაში აღმოვჩნდებით, როცა თითქოს რაღაც ვიცით, სინამდვილეში კი ბევრი რამ არ ვიცით. შემდეგ, როგორც გამოცდილებას ვიღებთ, უფრო თავდაჯერებულები ვხდებით.

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

დასკვნა

7 წლის განმავლობაში ჩვენ მივედით იქიდან, რომ როდესაც რაღაც დაეცა, იყო პანიკა-პანიკა, იმის გაგებამდე, რომ პრობლემები არ არსებობს, არის მხოლოდ ამოცანები, ისინი უნდა - და შეიძლება - გადაწყდეს. როდესაც თქვენ აშენებთ სერვისს, შეხედეთ მას ზემოდან, შეაფასეთ ყველა რისკი, რაც შეიძლება მოხდეს. თუ მათ დაუყოვნებლივ ხედავთ, მაშინ წინასწარ უზრუნველყოთ ჭარბი რაოდენობა და შეცდომის ტოლერანტული ინფრასტრუქტურის აშენების შესაძლებლობა, რადგან ნებისმიერი წერტილი, რომელიც შეიძლება ჩავარდეს და გამოიწვიოს სერვისის უმოქმედობა, აუცილებლად გააკეთებს ამას. და მაშინაც კი, თუ მოგეჩვენებათ, რომ ინფრასტრუქტურის ზოგიერთი ელემენტი ნამდვილად არ ჩავარდება - იგივე s3-ის მსგავსად, მაინც გაითვალისწინეთ, რომ მათ შეუძლიათ. და თეორიულად მაინც, გქონდეთ წარმოდგენა იმაზე, თუ რას გააკეთებთ მათთან, თუ რამე მოხდება. გქონდეთ რისკის მართვის გეგმა. როდესაც ფიქრობთ ყველაფრის ავტომატურად ან ხელით გაკეთებაზე, შეაფასეთ რისკები: რა მოხდება, თუ ავტომატიზაცია დაიწყებს ყველაფრის შეცვლას - განა ეს არ გამოიწვევს კიდევ უფრო უარეს მდგომარეობას ავარიასთან შედარებით? შესაძლოა, სადღაც აუცილებელია გონივრული კომპრომისის გამოყენება ავტომატიზაციის გამოყენებასა და მორიგე ინჟინრის რეაქციას შორის, რომელიც შეაფასებს რეალურ სურათს და გაიგებს, საჭიროა თუ არა რაღაცის გადართვა ადგილზე, თუ "დიახ, მაგრამ არა ახლა".

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

ეს ტექსტი არის ალექსანდრე დემიდოვის მოხსენების განახლებული და გაფართოებული ვერსია კონფერენციაზე მუშაობის დრო 4.

წყარო: www.habr.com