როგორ ამზადებს AWS თავის ელასტიურ სერვისებს. სერვერებისა და მონაცემთა ბაზის სკალირება

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

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

მომხსენებლის შესახებ: ვასილი პანტიუხინი (ქათამი) დაიწყო Unix-ის ადმინისტრატორად .ru კომპანიებში, მუშაობდა Sun Microsystem-ის დიდ აპარატურაზე 6 წლის განმავლობაში და 11 წლის განმავლობაში ქადაგებდა მონაცემებზე ორიენტირებულ სამყაროს EMC-ში. ის ბუნებრივად გადაიქცა კერძო ღრუბლებში და 2017 წელს გადავიდა საჯარო ღრუბლებში. ახლა ის იძლევა ტექნიკურ რჩევებს, რათა დაეხმაროს ცხოვრებას და განვითარებას AWS ღრუბელში.

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

რატომ ვსაუბრობ ამაზონის მოწყობილობაზე?

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

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

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

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

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

Რაზე ვისაუბროთ

მე ავირჩიე დივერსიფიცირებული მიდგომა – შევარჩიე 4 საინტერესო სერვისი, რომლებზეც ღირს საუბარი.

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

სერვერის გარეშე ფუნქციები (ლამბდა) ალბათ ყველაზე მასშტაბური სერვისია ღრუბელში.

მონაცემთა ბაზის მასშტაბირება. მე გეტყვით იმაზე, თუ როგორ ვაშენებთ საკუთარ მასშტაბურ მონაცემთა ბაზებს.

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

Შენიშვნა. ამ სტატიაში განხილული იქნება სერვერის ოპტიმიზაცია და მონაცემთა ბაზის მასშტაბირება. ქსელის მასშტაბირებას განვიხილავთ შემდეგ სტატიაში. სად არის სერვერის გარეშე ფუნქციები? მათ შესახებ გამოქვეყნდა ცალკე ჩანაწერი“პატარა, მაგრამ ჭკვიანი. Unboxing Firecracker მიკროვირტუალი" იგი საუბრობს სკალირების რამდენიმე სხვადასხვა მეთოდზე და დეტალურად განიხილავს Firecracker გადაწყვეტას - ვირტუალური მანქანისა და კონტეინერების საუკეთესო თვისებების სიმბიოზს.

სერვერები

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

2012 წელს ამ არქიტექტურამ საკმაოდ კარგად გაართვა თავი თავის ამოცანებს. Xen არის შესანიშნავი ჰიპერვიზორი, მაგრამ მას აქვს ერთი მნიშვნელოვანი ნაკლი. მას საკმარისი აქვს მაღალი ზედნადები მოწყობილობის ემულაციისთვის. როგორც ახალი, უფრო სწრაფი ქსელის ბარათები ან SSD დისკები ხელმისაწვდომი გახდება, ეს ზედმეტად მაღალი ხდება. როგორ გავუმკლავდეთ ამ პრობლემას? გადავწყვიტეთ ერთდროულად ორ ფრონტზე გვემუშავა - როგორც ტექნიკის, ასევე ჰიპერვიზორის ოპტიმიზაცია. ამოცანა ძალიან სერიოზულია.

აპარატურის და ჰიპერვიზორის ოპტიმიზაცია

ყველაფრის ერთდროულად კეთება და კარგად გაკეთება არ გამოდგება. რა იყო „კარგი“, ასევე თავდაპირველად გაურკვეველი იყო.

ჩვენ გადავწყვიტეთ ევოლუციური მიდგომა გამოგვეყენებინა - არქიტექტურის ერთ მნიშვნელოვან ელემენტს ვცვლით და წარმოებაში ვყრით.

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

ტრანსფორმაცია 2013 წელს დაიწყო ყველაზე რთული ნივთით - ქსელით. IN С3 მაგალითად, სტანდარტული ქსელის ბარათს დაემატა სპეციალური Network Accelerator ბარათი. იგი პირდაპირ კავშირში იყო წინა პანელზე მოკლე მარყუჟის კაბელით. ეს არ არის ლამაზი, მაგრამ ის არ ჩანს ღრუბელში. მაგრამ აპარატურასთან უშუალო ურთიერთქმედებამ ფუნდამენტურად გააუმჯობესა ჯიტერი და ქსელის გამტარუნარიანობა.

შემდეგ ჩვენ გადავწყვიტეთ გავაუმჯობესოთ წვდომა მონაცემთა ბლოკირებისთვის EBS - Elastic Block Storage. ეს არის ქსელისა და შენახვის ერთობლიობა. სირთულე იმაში მდგომარეობს, რომ სანამ ქსელის ამაჩქარებლის ბარათები არსებობდა ბაზარზე, უბრალოდ არ არსებობდა Storage Accelerator ტექნიკის ყიდვის საშუალება. ასე რომ, ჩვენ მივმართეთ სტარტაპს ანაპურნას ლაბორატორიები, რომელმაც ჩვენთვის სპეციალური ASIC ჩიპები შეიმუშავა. მათ დაუშვეს დისტანციური EBS ტომების დამონტაჟება NVMe მოწყობილობებად.

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

2017 წლის ნოემბრისთვის ჩვენ მივხვდით, რომ დრო იყო თავად ჰიპერვიზორის შეცვლა.

ახალი ჰიპერვიზორი შეიქმნა KVM ბირთვის მოდიფიცირებული მოდულების საფუძველზე.

ამან შესაძლებელი გახადა მოწყობილობის ემულაციის ზედნადების ძირეულად შემცირება და უშუალოდ ახალ ASIC-ებთან მუშაობა. შემთხვევები С5 იყო პირველი ვირტუალური მანქანები ახალი ჰიპერვიზორით, რომელიც მუშაობდა ქუდის ქვეშ. ჩვენ ის დავასახელეთ Nitro.

შემთხვევების ევოლუცია ვადებში.

ყველა ახალი ტიპის ვირტუალური მანქანა, რომელიც გამოჩნდა 2017 წლის ნოემბრის შემდეგ, მუშაობს ამ ჰიპერვიზორზე. Bare Metal-ის ინსტანციებს არ აქვთ ჰიპერვიზორი, მაგრამ მათ ასევე უწოდებენ Nitro, რადგან ისინი იყენებენ სპეციალიზებულ Nitro ბარათებს.

მომდევნო ორი წლის განმავლობაში, ნიტრო ინსტანციების ტიპების რაოდენობამ გადააჭარბა რამდენიმე ათეულს: A1, C5, M5, T3 და სხვა.

ინსტანციის ტიპები.

როგორ მუშაობს თანამედროვე ნიტრო მანქანები

მათ აქვთ სამი ძირითადი კომპონენტი: Nitro hypervisor (ზემოთ განხილული), უსაფრთხოების ჩიპი და Nitro ბარათები.

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

ნიტრო ბარათები - მათი ოთხი ტიპი არსებობს. ყველა მათგანი შემუშავებულია Annapurna Labs-ის მიერ და დაფუძნებულია საერთო ASIC-ებზე. მათი ზოგიერთი firmware ასევე გავრცელებულია.

ოთხი ტიპის Nitro ბარათები.

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

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

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

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

Inferentia Machine Learning Processor ჩიპი.

მასშტაბირებადი მონაცემთა ბაზა

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

• SQL — კლიენტი და მოთხოვნის დისპეტჩერები მუშაობენ მასზე.
• დებულებები გარიგებები - აქ ყველაფერი გასაგებია, ACID და ეს ყველაფერი.
• ქეშირება, რომელიც უზრუნველყოფილია ბუფერული აუზებით.
• ხე-ტყე — უზრუნველყოფს მუშაობას ხელახალი ჟურნალებით. MySQL-ში მათ Bin Logs-ს უწოდებენ, PosgreSQL-ში - Write Ahead Logs (WAL).
• შენახვის - პირდაპირი ჩაწერა დისკზე.

ფენიანი მონაცემთა ბაზის სტრუქტურა.

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

თუმცა, ყველა ეს მეთოდი ინარჩუნებს მონაცემთა ბაზის იგივე მონოლითურ სტრუქტურას. ეს მნიშვნელოვნად ზღუდავს სკალირებას. ამ პრობლემის გადასაჭრელად ჩვენ შევიმუშავეთ ჩვენი საკუთარი მონაცემთა ბაზა − ამაზონის ავრორა. ის თავსებადია MySQL-თან და PostgreSQL-თან.

ამაზონის ავრორა

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

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

შესვლისა და შენახვის დონეები ცალკეა მონაცემთა ბაზისგან.

ტრადიციული DBMS წერს მონაცემებს შენახვის სისტემაში ბლოკების სახით. Amazon Aurora-ში შევქმენით ჭკვიანი საცავი, რომელსაც შეუძლია ენაზე საუბარი ხელახალი ჟურნალები. შიგნით, საცავი აქცევს ჟურნალებს მონაცემთა ბლოკებად, აკონტროლებს მათ მთლიანობას და ავტომატურად ქმნის სარეზერვო ასლებს.

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

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

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

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

საცავი მოვაწესრიგეთ.

როგორ გავაფართოვოთ DBMS იარუსები

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

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

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

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

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

როგორ გავაუმჯობესოთ სიტუაცია? დააყენეთ პროქსი აპლიკაციასა და მთავარ კვანძს შორის.

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

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

საბოლოო გადაწყვეტა Amazon Aurora სერვერის გარეშე

როგორ მოვაგვარეთ ეს პრობლემები?

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

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

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

განაწილებული მარიონეტები, თბილი ინსტანციები და მონიტორინგი.

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

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

მონაცემთა ბაზის რეზიუმეებთან მუშაობა.

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

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

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

წლის მაღალი დატვირთვა ++ ვასილი პანტიუხინი მოხსენებას წარადგენს ”Ჰიუსტონ პრობლემა გვაქვს. მარცხისთვის სისტემების დიზაინი, ამაზონის შიდა ღრუბლოვანი სერვისების განვითარების შაბლონები" რა დიზაინის შაბლონებს იყენებენ განაწილებული სისტემებისთვის ამაზონის დეველოპერები, რა არის მომსახურების წარუმატებლობის მიზეზები, რა არის Cell-based არქიტექტურა, Constant Work, Shuffle Sharding - საინტერესო იქნება. კონფერენციამდე თვეზე ნაკლები დარჩა - დაჯავშნეთ თქვენი ბილეთები. 24 ოქტომბერს ფასის საბოლოო ზრდა.

წყარო: www.habr.com