როგორ ამზადებს AWS თავის ელასტიურ სერვისებს. ქსელის მასშტაბირება

Amazon Web Services ქსელის მასშტაბი არის 69 ზონა მთელს მსოფლიოში 22 რეგიონში: აშშ, ევროპა, აზია, აფრიკა და ავსტრალია. თითოეული ზონა შეიცავს 8-მდე მონაცემთა ცენტრს - მონაცემთა დამუშავების ცენტრებს. თითოეულ მონაცემთა ცენტრს აქვს ათასობით ან ასობით ათასი სერვერი. ქსელი ისეა დაპროექტებული, რომ გათიშვის ყველა ნაკლებად სავარაუდო სცენარი გათვალისწინებული იყოს. მაგალითად, ყველა რეგიონი ერთმანეთისგან იზოლირებულია და ხელმისაწვდომობის ზონები გამოყოფილია რამდენიმე კილომეტრის მანძილზე. კაბელის გაწყვეტის შემთხვევაშიც კი, სისტემა გადავა სარეზერვო არხებზე და ინფორმაციის დაკარგვა იქნება რამდენიმე მონაცემთა პაკეტი. ვასილი პანტიუხინი ისაუბრებს იმაზე, თუ რა სხვა პრინციპებზეა აგებული ქსელი და როგორ არის სტრუქტურირებული.

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

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

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

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

ქსელის მასშტაბირება

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

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

ვირტუალური პირადი ღრუბელი

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

რა არის პირველი, რაც გახსენდებათ, როდესაც ფიქრობთ ქსელის იზოლაციაზე? Რა თქმა უნდა VLAN и VRF - ვირტუალური მარშრუტიზაცია და გადამისამართება.

სამწუხაროდ, არ მუშაობდა. VLAN ID არის მხოლოდ 12 ბიტი, რაც გვაძლევს მხოლოდ 4096 იზოლირებულ სეგმენტს. ყველაზე დიდ გადამრთველებსაც კი შეუძლიათ გამოიყენონ მაქსიმუმ 1-2 ათასი VRF. VRF და VLAN ერთად გამოყენება გვაძლევს მხოლოდ რამდენიმე მილიონ ქვექსელს. ეს ნამდვილად არ არის საკმარისი ათობით მილიონი მოიჯარისთვის, რომელთაგან თითოეულს უნდა შეეძლოს მრავალი ქვექსელის გამოყენება.

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

არსებობს მხოლოდ ერთი დასკვნა - გააკეთე საკუთარი გამოსავალი.

2009 წელს გამოვაცხადეთ VPC - ვირტუალური პირადი ღრუბელი. სახელი გაიჭედა და ახლა მას მრავალი ღრუბლოვანი პროვაიდერი იყენებს.

VPC არის ვირტუალური ქსელი SDN (პროგრამული განსაზღვრული ქსელი). ჩვენ გადავწყვიტეთ არ გამოგვეგონა სპეციალური პროტოკოლები L2 და L3 დონეზე. ქსელი მუშაობს სტანდარტულ Ethernet-ზე და IP-ზე. ქსელში გადაცემისთვის, ვირტუალური მანქანების ტრაფიკი ჩაკეტილია ჩვენი პროტოკოლის შეფუთვაში. იგი მიუთითებს პირადობის მოწმობაზე, რომელიც ეკუთვნის მოიჯარის VPC-ს.

ჟღერს მარტივი. თუმცა, არსებობს რამდენიმე სერიოზული ტექნიკური გამოწვევა, რომელიც უნდა გადაილახოს. მაგალითად, სად და როგორ შეინახოთ მონაცემები ვირტუალური MAC/IP მისამართების რუკების, VPC ID და შესაბამისი ფიზიკური MAC/IP მონაცემების შესახებ. AWS მასშტაბით, ეს არის უზარმაზარი ცხრილი, რომელიც უნდა მუშაობდეს მინიმალური წვდომის შეფერხებით. ამაზე პასუხისმგებელი რუკების სერვისი, რომელიც თხელ ფენადაა გავრცელებული მთელ ქსელში.

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

მოდით გაერკვნენ, თუ როგორ მუშაობს იგი ზოგადად. დავიწყოთ L2 დონიდან. დავუშვათ, რომ გვაქვს ვირტუალური მანქანა IP 10.0.0.2 ფიზიკურ სერვერზე 192.168.0.3. ის აგზავნის მონაცემებს ვირტუალურ მანქანაზე 10.0.0.3, რომელიც ცხოვრობს 192.168.1.4-ზე. ARP მოთხოვნა გენერირდება და იგზავნება ქსელის Nitro ბარათზე. სიმარტივისთვის, ჩვენ ვვარაუდობთ, რომ ორივე ვირტუალური მანქანა ცხოვრობს იმავე "ლურჯ" VPC-ში.

რუკა ცვლის წყაროს მისამართს თავისით და გადასცემს ARP ჩარჩოს რუკების სერვისში.

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

Nitro ბარათი ARP პასუხში ცვლის MAC-ს ფიზიკურ ქსელში მისამართით VPC-ში.

მონაცემთა გადაცემისას ჩვენ ვახვევთ ლოგიკურ MAC-ს და IP-ს VPC გარსაცმში. ჩვენ ამ ყველაფერს გადავცემთ ფიზიკურ ქსელში შესაბამისი წყაროსა და დანიშნულების IP Nitro ბარათების გამოყენებით.

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

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

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

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

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

სილამაზე ის არის, რომ არ გჭირდებათ მთელი უზარმაზარი მაგიდის ქეშირება. ფიზიკური სერვერი მასპინძლობს ვირტუალურ მანქანებს VPC-ების შედარებით მცირე რაოდენობით. თქვენ მხოლოდ ამ VPC-ების შესახებ ინფორმაციის ქეში გჭირდებათ. მონაცემთა გადაცემა სხვა VPC-ებზე „ნაგულისხმევი“ კონფიგურაციით ჯერ კიდევ არ არის ლეგიტიმური. თუ გამოიყენება ისეთი ფუნქციები, როგორიცაა VPC-peering, მაშინ ინფორმაცია შესაბამისი VPC-ების შესახებ დამატებით იტვირთება ქეშში. 

ჩვენ დავახარისხეთ მონაცემთა გადაცემა VPC-ზე.

შავფეხა

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

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

VPN-ის გამოყენებისას მონაცემები დეკაფსულირებულია და ხელახლა იკვრება IPsec-ში.

Direct Connect-ის გამოყენებისას ტრაფიკი მონიშნულია და იგზავნება შესაბამის VLAN-ზე.

ჰიპერთვითმფრინავი

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

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

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

Hyperplane არის ასეთი EC2 მანქანების უზარმაზარი რაოდენობის განაწილებული სისტემა. თითოეულ ვირტუალურ მანქანას აქვს გამტარუნარიანობა 5 გბ/წმ. მთელ რეგიონალურ ქსელში, ეს უზრუნველყოფს გამტარუნარიანობის წარმოუდგენელ ტერაბიტს და დამუშავების საშუალებას იძლევა მილიონობით კავშირი წამში.

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

ხმაურიანი მეზობელი

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

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

დაბალი ალბათობა არ ნიშნავს შეუძლებელს.

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

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

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

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

8 კვანძისა და 3 მომხმარებლის შემთხვევაში ხმაურიანი მეზობლის ერთ-ერთ მომხმარებელთან გადაკვეთის ალბათობა 54%-ია. სწორედ ამ ალბათობით, ლურჯი მომხმარებელი გავლენას მოახდენს სხვა მოიჯარეებზე. ამავე დროს, მისი დატვირთვის მხოლოდ ნაწილი. ჩვენს მაგალითში, ეს გავლენა გარკვეულწილად შესამჩნევი იქნება არა ყველასთვის, არამედ ყველა მომხმარებლის მხოლოდ მესამედისთვის. ეს უკვე კარგი შედეგია.

მომხმარებელთა რაოდენობა, რომლებიც იკვეთება

ალბათობა პროცენტებში

0

18%

1

54%

2

26%

3

2%

მივაახლოოთ სიტუაცია რეალობას - ავიღოთ 100 კვანძი და 5 მომხმარებელი 5 კვანძზე. ამ შემთხვევაში არცერთი კვანძი არ იკვეთება 77%-ის ალბათობით. 

მომხმარებელთა რაოდენობა, რომლებიც იკვეთება

ალბათობა პროცენტებში

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

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

HyperPlane-ის ბაზაზე აგებულია მრავალი სერვისი: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

ქსელის მასშტაბი

ახლა მოდით ვისაუბროთ თავად ქსელის მასშტაბებზე. 2019 წლის ოქტომბრისთვის AWS გთავაზობთ თავის სერვისებს 22 რეგიონი, და კიდევ 9 იგეგმება.

• თითოეული რეგიონი შეიცავს რამდენიმე ხელმისაწვდომობის ზონას. მსოფლიოში 69 მათგანია.
• თითოეული AZ შედგება მონაცემთა დამუშავების ცენტრებისგან. სულ არ არის 8-ზე მეტი.
• მონაცემთა ცენტრში განთავსებულია სერვერების დიდი რაოდენობა, ზოგი 300-მდე.

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

არსებობს მრავალი ოპტიკური ბმული ხელმისაწვდომობის ზონებსა და მონაცემთა ცენტრს შორის. ჩვენს ერთ-ერთ უდიდეს რეგიონში 388 არხი დაიდო მხოლოდ AZ კომუნიკაციისთვის ერთმანეთთან და საკომუნიკაციო ცენტრებთან სხვა რეგიონებთან (ტრანზიტული ცენტრები). საერთო ჯამში ეს იძლევა გიჟებს 5000 ტბიტი.

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

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

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

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

მაინტერესებს როგორ შეიცვლება ინტერნეტი 10 წელიწადში თუ ეს ტენდენცია გაგრძელდება?

ფიზიკური არხები

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

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

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

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

ეს არის ვასილი პანტიუხინის ტრილოგიის ბოლო ნაწილი AWS მოწყობილობის შესახებ. IN პირველი ნაწილები აღწერს სერვერის ოპტიმიზაციას და მონაცემთა ბაზის სკალირებას და მეორე — სერვერის გარეშე ფუნქციები და Firecracker.

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

წყარო: www.habr.com