ქსელის დატვირთვის ბალანსერის არქიტექტურა Yandex.Cloud-ში

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

პირველ რიგში, შემოგთავაზებთ რამდენიმე ტერმინს:

• VIP (ვირტუალური IP) - ბალანსერის IP მისამართი
• სერვერი, ბექენდი, მაგალითი - ვირტუალური მანქანა, რომელიც მუშაობს აპლიკაციაში
• RIP (რეალური IP) - სერვერის IP მისამართი
• Healthcheck - სერვერის მზადყოფნის შემოწმება
• ხელმისაწვდომობის ზონა, AZ - იზოლირებული ინფრასტრუქტურა მონაცემთა ცენტრში
• რეგიონი - სხვადასხვა AZ-ების გაერთიანება

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

დატვირთვის ბალანსერი ხშირად კლასიფიცირდება პროტოკოლის ფენით OSI მოდელიდან, რომელზეც ის მუშაობს. Cloud Balancer მუშაობს TCP დონეზე, რომელიც შეესაბამება მეოთხე ფენას, L4.

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

მონაცემთა თვითმფრინავი

ტრაფიკი მთავრდება ძვირადღირებულ მოწყობილობებზე, სახელწოდებით სასაზღვრო მარშრუტიზატორები. შეცდომების ტოლერანტობის გაზრდის მიზნით, რამდენიმე ასეთი მოწყობილობა ერთდროულად მუშაობს ერთ მონაცემთა ცენტრში. შემდეგი, ტრაფიკი მიდის ბალანსერებზე, რომლებიც აცხადებენ ნებისმიერ IP მისამართებს ყველა AZ-ს BGP-ის საშუალებით კლიენტებისთვის. 

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

კონფიგურაციის თვითმფრინავი

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

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

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

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

ჯანმრთელობის შემოწმების კონტროლერი

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

მოდით ვისაუბროთ უფრო მეტი ჯანმრთელობის შემოწმების შესახებ. ისინი შეიძლება დაიყოს რამდენიმე კლასად. აუდიტს წარმატების სხვადასხვა კრიტერიუმი აქვს. TCP შემოწმებას სჭირდება კავშირის წარმატებით დამყარება ფიქსირებულ დროში. HTTP შემოწმება მოითხოვს როგორც წარმატებულ კავშირს, ასევე პასუხს 200 სტატუსის კოდით.

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

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

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

განსხვავება ისაა, რომ კლიენტები მოთხოვნებს უყენებენ VIP-ს, ხოლო ჯანმრთელობის შემოწმება თითოეულ ინდივიდუალურ RIP-ს. აქ ჩნდება საინტერესო პრობლემა: ჩვენ მომხმარებლებს ვაძლევთ შესაძლებლობას შექმნან რესურსები რუხი IP ქსელებში. წარმოვიდგინოთ, რომ არსებობს ორი განსხვავებული ღრუბლის მფლობელი, რომლებმაც თავიანთი სერვისები დამალეს ბალანსერების მიღმა. თითოეულ მათგანს აქვს რესურსები 10.0.0.1/24 ქვექსელში, იგივე მისამართებით. თქვენ უნდა შეძლოთ როგორმე განასხვავოთ ისინი და აქ თქვენ უნდა ჩაყვინთოთ Yandex.Cloud ვირტუალური ქსელის სტრუქტურაში. ჯობია მეტი დეტალები გაიგოთ ვიდეო შესახებ:Cloud ღონისძიება, ჩვენთვის ახლა მნიშვნელოვანია, რომ ქსელი მრავალშრიანია და აქვს გვირაბები, რომლებიც შეიძლება გამოირჩეოდეს ქვექსელის ID-ით.

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

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

VPP - მონაცემთა სიბრტყის გული

ბალანსერი დანერგილია Vector Packet Processing (VPP) ტექნოლოგიის გამოყენებით, Cisco-ს ჩარჩო ქსელის ტრაფიკის ჯგუფური დამუშავებისთვის. ჩვენს შემთხვევაში, ჩარჩო მუშაობს მომხმარებლის სივრცის ქსელის მოწყობილობის მართვის ბიბლიოთეკის თავზე - Data Plane Development Kit (DPDK). ეს უზრუნველყოფს პაკეტის დამუშავების მაღალ შესრულებას: გაცილებით ნაკლები შეფერხებები ხდება ბირთვში და არ არის კონტექსტური გადამრთველები ბირთვის სივრცესა და მომხმარებლის სივრცეს შორის. 

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

მაგალითად, IP პაკეტების დამუშავება VPP-ში ხდება შემდეგი თანმიმდევრობით: ჯერ პაკეტების სათაურები ნაწილდება ანალიზურ კვანძში, შემდეგ კი იგზავნება კვანძში, რომელიც შემდგომში გადასცემს პაკეტებს მარშრუტიზაციის ცხრილების მიხედვით.

ცოტა ჰარდკორი. VPP-ის ავტორები არ მოითმენენ კომპრომისებს პროცესორის ქეშის გამოყენებაში, ამიტომ პაკეტების ვექტორის დამუშავების ტიპიური კოდი შეიცავს ხელით ვექტორიზაციას: არის დამუშავების მარყუჟი, რომელშიც მუშავდება სიტუაცია, როგორიცაა "ჩვენ გვაქვს ოთხი პაკეტი რიგში". შემდეგ იგივე ორი, შემდეგ - ერთი. წინასწარი შეყვანის ინსტრუქციები ხშირად გამოიყენება მონაცემების ქეშებში ჩასატვირთად, რათა დააჩქაროს მათზე წვდომა შემდგომ გამეორებებში.

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

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

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

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

5 ორმაგი ჰეში გვეხმარება ნაკლები გამოთვლების შესრულებაში შემდგომ თანმიმდევრულ ჰეშინგ კვანძში, ასევე უკეთ გავუმკლავდეთ რესურსების სიის ცვლილებებს ბალანსერის უკან. როდესაც პაკეტი, რომლისთვისაც არ არის სესია, მიდის ბალანსერთან, ის იგზავნება თანმიმდევრული ჰეშირების კვანძში. სწორედ აქ ხდება დაბალანსება თანმიმდევრული ჰეშირების გამოყენებით: ჩვენ ვირჩევთ რესურსს ხელმისაწვდომი „ცოცხალი“ რესურსების სიიდან. შემდეგი, პაკეტები იგზავნება NAT კვანძში, რომელიც ფაქტობრივად ცვლის დანიშნულების მისამართს და ხელახლა გამოთვლის საკონტროლო ჯამებს. როგორც ხედავთ, ჩვენ ვიცავთ VPP-ის წესებს - მოსწონს მოწონება, მსგავსი გამოთვლების დაჯგუფება პროცესორის ქეშის ეფექტურობის გასაზრდელად.

თანმიმდევრული ჰეშინგი

რატომ ავირჩიეთ და რა არის ეს? პირველ რიგში, განვიხილოთ წინა დავალება - რესურსის შერჩევა სიიდან. 

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

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

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

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

Loadbalancer-კვანძი და აწყობილი კომპონენტები

ბალანსერებისა და რესურსების შემადგენლობა VPP-ში იუწყება ადგილობრივი სერვისი - loadbalancer-node. იგი იწერს მოვლენების ნაკადს დატვირთვის ბალანსის კონტროლერიდან და შეუძლია გამოსახოს განსხვავება მიმდინარე VPP მდგომარეობასა და კონტროლერისგან მიღებულ სამიზნე მდგომარეობას შორის. ჩვენ ვიღებთ დახურულ სისტემას: API-დან მოვლენები მოდის ბალანსის კონტროლერთან, რომელიც დავალებებს ანიჭებს ჯანმრთელობის შემოწმების კონტროლერს რესურსების „სიცოცხლის“ შესამოწმებლად. ეს, თავის მხრივ, ანიჭებს დავალებებს ჯანმრთელობის შემოწმების კვანძს და აგროვებს შედეგებს, რის შემდეგაც ის უგზავნის მათ ბალანსის კონტროლერს. Loadbalancer-node იწერს მოვლენებს კონტროლერიდან და ცვლის VPP-ის მდგომარეობას. ასეთ სისტემაში თითოეულმა სერვისმა იცის მხოლოდ ის, რაც საჭიროა მეზობელი სერვისების შესახებ. კავშირების რაოდენობა შეზღუდულია და გვაქვს შესაძლებლობა სხვადასხვა სეგმენტების დამოუკიდებლად მუშაობა და მასშტაბირება.

რა საკითხები იქნა აცილებული?

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

პრობლემები და გადაწყვეტილებები

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

ასევე, Go შეიძლება არ იყოს საუკეთესო არჩევანი ფუნქციური ტესტებისთვის. ისინი საკმაოდ მრავლისმეტყველები არიან და სტანდარტული მიდგომა „ყველაფერი CI-ში პარტიაში გაშვება“ მათთვის არც თუ ისე შესაფერისია. ფაქტია, რომ ფუნქციონალური ტესტები უფრო რესურსების მომთხოვნია და რეალურ დროში შეფერხებას იწვევს. ამის გამო, ტესტები შეიძლება ჩავარდეს, რადგან CPU დაკავებულია ერთეულის ტესტებით. დასკვნა: თუ შესაძლებელია, შეასრულეთ "მძიმე" ტესტები ცალკეული ტესტებისგან. 

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

ჩვენი გეგმები

ჩვენ გამოვამუშავებთ შიდა ბალანსერს, IPv6 ბალანსერს, დავამატებთ Kubernetes სკრიპტების მხარდაჭერას, გავაგრძელებთ ჩვენი სერვისების დაშლას (ამჟამად მხოლოდ healthcheck-node და healthcheck-ctrl არის გახეხილი), დავამატებთ ჯანმრთელობის ახალ შემოწმებებს და ასევე განვახორციელებთ შემოწმებების ჭკვიანურ აგრეგაციას. ჩვენ განვიხილავთ შესაძლებლობას გავხადოთ ჩვენი სერვისები კიდევ უფრო დამოუკიდებელი - ისე, რომ მათ დაუკავშირდნენ არა უშუალოდ ერთმანეთთან, არამედ შეტყობინებების რიგის გამოყენებით. ახლახან ღრუბელში გამოჩნდა SQS-თან თავსებადი სერვისი Yandex შეტყობინებების რიგი.

ახლახან მოხდა Yandex Load Balancer-ის საჯარო გამოშვება. Გამოკვლევა დოკუმენტაცია სერვისს, მართეთ ბალანსერები თქვენთვის მოსახერხებელი გზით და გაზარდეთ თქვენი პროექტების შეცდომის ტოლერანტობა!

წყარო: www.habr.com