ღრუბლოვანი გამოთვლები ახსნილი: არქიტექტურის 11 კონცეფცია, რომელიც უნდა იცოდეთ (4K მასტერკლასი).

რას მოიცავს ეს ვიდეო

• - არქიტექტურის კედელი და სამაგისტრო გეგმა
• - 01. ვერტიკალური vs. ჰორიზონტალური სკალირება
• - 02. დატვირთვის დაბალანსების არქიტექტურა (L4 vs. L7 & ჯანმრთელობის შემოწმებები)
• - 03. ავტომატური სკალირება და ელასტიურობა
• - 04. Serverless (FaaS & Firecracker MicroVMs)

ნათარგმნი ტრანსკრიპტი

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

- არქიტექტურის კედელი და სამაგისტრო გეგმა

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

0:34 ამ მასტერკლასში, ჩვენ განვიხილავთ მთელ საწარმოს გეგმას: სკალირებიდან და დატვირთვის დაბალანსებიდან სერვერების გარეშე, მოვლენებზე ორიენტირებულ განცალკევებამდე, საცავის იერარქიებამდე და ღრუბლოვან ქსელებამდე. დაეუფლეთ ამ თერთმეტ კონცეფციას და შეგიძლიათ შექმნათ ნებისმიერი ბექენდი AWS-ზე, GCP-ზე ან Azure-ზე. ეს არის The Daily Diff, შიდა მხარე.

- 01. ვერტიკალური vs. ჰორიზონტალური სკალირება

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

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

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

- 02. დატვირთვის დაბალანსების არქიტექტურა (L4 vs. L7 & ჯანმრთელობის შემოწმებები)

2:17 მეორე კონცეფცია: დატვირთვის დაბალანსება. ჰორიზონტალური სკალირება ქაღალდზე შესანიშნავად ჟღერს, მაგრამ ის დაუყოვნებლივ პრობლემას ქმნის: როდესაც ათი ათასი მომხმარებელი თქვენს დომენის სახელს ეწვევა, რომელი კონკრეტული სერვერი იღებს მათ ტრაფიკს? დატვირთვის ბალანსერი მოქმედებს როგორც უკუ პროქსი, რომელიც დგას საჯარო ინტერნეტსა და თქვენს კერძო ბექენდ კლასტერს შორის. ის იღებს შემომავალ TCP ან HTTP კავშირებს და ანაწილებს მოთხოვნებს თქვენს ჯანმრთელ ინსტანციებზე.

2:47 დატვირთვის ბალანსერები მუშაობენ ორ ძირითად ქსელურ ფენაზე. ფენა 4 ქსელური დატვირთვის ბალანსერები მუშაობენ სატრანსპორტო ფენაზე, ახდენენ ნედლი TCP და UDP პაკეტების მარშრუტიზაციას IP მისამართისა და პორტის მიხედვით მიკროწამიერი დაყოვნებით და მილიონობით მოთხოვნით წამში. ფენა 7 აპლიკაციის დატვირთვის ბალანსერები ამოწმებენ HTTP პროტოკოლს თავად: კითხულობენ URL ბილიკებს, მოთხოვნის სათაურებს, ქუქიებს და HTTP მეთოდებს. ეს საშუალებას აძლევს ბილიკზე დაფუძნებულ მარშრუტიზაციას: slash-api მოთხოვნების გაგზავნას თქვენს ბექენდ კლასტერში და slash-static მოთხოვნების

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

- 03. ავტომატური სკალირება და ელასტიურობა

3:45 მესამე კონცეფცია: ავტომატური სკალირება. თუ თქვენს ვებ აპლიკაციას სჭირდება ორი სერვერი დილის სამ საათზე, მაგრამ ოცი სერვერი შუადღის გაშვების დროს, ღრუბლოვანი კონსოლში ღილაკების ხელით დაჭერა გარანტირებული გზაა შეფერხებისა და გაკოტრებისკენ. ავტომატური სკალირება დინამიურ ელასტიურობას ანიჭებს ჰორიზონტალურ სერვერულ პულებს. ავტომატური სკალირების ჯგუფი აკონტროლებს შესრულების მეტრიკებს, როგორიცაა საშუალო CPU გამოყენება, ქსელის I-O, ან რიგის ჩამორჩენის სიღრმე. როდესაც საშუალო CPU გადაკვეთს განსაზღვრულ ზღურბლს — ვთქვათ,

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

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 წლების განმავლობაში მარკეტინგული გუნდები სერვერების გარეშე კოდს ცაში გაშვებულ ჯადოსნურ კოდს უწოდებდნენ. სინამდვილეში, სერვერების გარეშე მაინც იყენებს სერვერებს — მაგრამ თქვენ არ ფლობთ, არ არემონტებთ და არ იხდით მათთვის, როდესაც კოდი არ მუშაობს. Function-as-a-Service-ის საშუალებით, როგორიცაა AWS Lambda ან Google Cloud Functions, თქვენ წერთ დამოუკიდებელ handler ფუნქციას. როდესაც HTTP მოთხოვნა, S3 ფაილის ატვირთვა, ან მონაცემთა ბაზის ცვლილება ხდება, ღრუბლოვანი runtime იწყებს ეფემერულ

5:23 მიკრო-ვირტუალურ-მანქანას, როგორიცაა Firecracker, ხუთ მილიწამზე ნაკლებ დროში. თქვენი კოდი სრულდება, აბრუნებს პასუხს და ითიშება. თუ არავინ ეწვევა თქვენს ვებსაიტს სამი თვის განმავლობაში, თქვენი გამოთვლის გადასახადი ზუსტად ნულ დოლარს და ნულ ცენტს შეადგენს. თუ მილიონი მომხმარებელი ერთდროულად ეწვევა მას, პროვაიდერი იწყებს მილიონ თანმიმდევრულ microVM-ს. საინჟინრო კომპრომისები რეალურია: ცივი დაწყების დაყოვნება ახალი runtimes-ის გაშვებისას, მკაცრი თხუთმეტწუთიანი შესრულების ლიმიტი Lambda-ზე და მკაცრი უსახელმწიფოება.

5:55 Serverless შეუდარებელია მოვლენების მილსადენებისთვის და სპორადული API-ებისთვის, მაგრამ ცუდია მუდმივი WebSockets-ისთვის ან მრავალსაათიანი ტრენინგის გაშვებისთვის.

- 05. მოვლენებზე ორიენტირებული არქიტექტურა (EDA & განცალკევება)

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

6:37 როდესაც მომხმარებელი დააწკაპუნებს ყიდვაზე, checkout სერვისი არ იძახებს ქვემო დინების სერვისებს. ის უბრალოდ აქვეყნებს მოვლენას სახელწოდებით OrderPlaced ცენტრალურ Event Bus-ზე, როგორიცაა Amazon EventBridge ან SNS თემა. შეკვეთა სრულდება ორმოცდაათ მილიწამში. ქვემო დინების მუშაკები გადახდის, ინვენტარის შემცირების და ელფოსტის ქვითრებისთვის ცალკე იღებენ შეტყობინებებს საკუთარი გამოყოფილი SQS რიგებიდან. თუ ელფოსტის სერვისი ერთი საათით გაითიშება, შეტყობინებები უსაფრთხოდ ელოდება ბუფერირებულად რიგში არცერთი შეკვეთის დაკარგვის გარეშე.

- 06. კონტეინერების ორკესტრირება (Docker & Kubernetes)

7:13 მეექვსე კონცეფცია: კონტეინერების ორკესტრირება. Docker-მა გადაჭრა შეფუთვის პრობლემა: ის ახვევს თქვენს აპლიკაციის კოდს, სისტემის ბიბლიოთეკებს, კონფიგურაციას და runtime-ს უცვლელ იმიჯში, რომელიც იდენტურად მუშაობს თქვენს MacBook-ზე და ღრუბელში. მაგრამ კონტეინერის შეფუთვა ადვილია. ხუთასი კონტეინერის გაშვება ორმოცდაათ ფიზიკურ ვირტუალურ მანქანაზე არის ის, სადაც ინჟინერია იშლება. ამიტომ არსებობს კონტეინერების ორკესტრატორები, როგორიცაა Kubernetes და AWS ECS.

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

- 07. ღრუბლოვანი შენახვის 4 სვეტი (S3, EBS, DBs & Redis)

8:16 ჯანმრთელ კვანძებზე. მეშვიდე კონცეფცია: ღრუბლოვანი შენახვის იერარქია. დამწყებთათვის ხშირად ღრუბლოვან საცავს განიხილავენ, როგორც ერთ ვედროს, სადაც ფაილებს ყრიან. საწარმოს არქიტექტურაში, საცავი დაყოფილია ოთხ განსხვავებულ სვეტად წვდომის ნიმუშებისა და დაყოვნების საფუძველზე. პირველი არის ობიექტების საცავი, როგორიცაა Amazon S3 ან Google Cloud Storage. ფაილებზე წვდომა ხდება HTTP REST API-ების საშუალებით მარტივი PUT და GET ზარებით. ის გთავაზობთ უსაზღვრო ჰორიზონტალურ სიმძლავრეს ორ ცენტად გიგაბაიტზე თვეში,

8:49 რაც მას იდეალურს ხდის ვიდეოებისთვის, მომხმარებლის ატვირთვებისთვის, ჟურნალებისთვის და სარეზერვო ასლებისთვის. მეორე არის ბლოკური საცავი, როგორიცაა Amazon EBS. ეს არის ვირტუალური მყარი დისკები, რომლებიც პირდაპირ კონკრეტულ ვირტუალურ მანქანასთან არის დაკავშირებული მაღალსიჩქარიანი ურთიერთკავშირებით. ისინი ფორმატირდება სტანდარტულ ფაილურ სისტემებში, როგორიცაა ext4, მონაცემთა ბაზის ძრავებისთვის საჭირო სწრაფი შემთხვევითი წაკითხვისა და ჩაწერის წვდომის მხარდაჭერით. მესამე არის მართული მონაცემთა ბაზები: რელაციური ძრავები, როგორიცაა PostgreSQL RDS-ზე, რომელიც უზრუნველყოფს ACID ტრანზაქციებს და კომპლექსურ შეერთებებს,

9:21 და NoSQL ძრავები, როგორიცაა DynamoDB, რომელიც უზრუნველყოფს ერთნიშნა მილიწამიერ დაყოვნებას მასიურ მასშტაბზე. და მეოთხე არის In-Memory Caches, როგორიცაა Redis. RAM-დან მონაცემების წაკითხვას მიკროწამები სჭირდება და არა მილიწამები. ქეშები თქვენი მონაცემთა ბაზის წინ ზის, იცავს მას განმეორებითი წაკითხვის ტრაფიკისგან და მართავს არასტაბილურ მომხმარებლის სესიის ტოკენებს.

- 08. მაღალი ხელმისაწვდომობა და ცხრიანები (Multi-AZ Failover)

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

10:15 წელიწადში. მაღალი ხელმისაწვდომობის მისაღწევად, თქვენ უნდა აღმოფხვრათ უკმარისობის ერთი წერტილები ხარვეზის დომენებში. ღრუბელში, ეს ნიშნავს განთავსებას მრავალ Availability Zone-ზე. Availability Zone არ არის ერთი კარადა: ეს არის ერთი ან მეტი განსხვავებული ფიზიკური მონაცემთა ცენტრი მილებით დაშორებული დამოუკიდებელი ენერგიითა და გაგრილებით. Zone A-სა და Zone B-ში აქტიური ინსტანციების სინქრონული მონაცემთა ბაზის რეპლიკაციით გაშვებით, ელვისებური დარტყმა ან ბოჭკოვანი ხაზის გაწყვეტა, რომელიც მთელ ფიზიკურ ობიექტს აჩერებს, იწვევს ავტომატურ failover-ს

10:50 ოცდაათ წამში, ადამიანის ჩარევის გარეშე.

- 09. გამძლეობა vs. ხელმისაწვდომობა (რატომ არ არის 11 ცხრიანი გამართული მუშაობის დრო)

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

11:24 ნახეთ Amazon S3 Standard. მისი მომსახურების დონის შეთანხმება გვთავაზობს 99.9% ხელმისაწვდომობას, რაც საშუალებას იძლევა დაახლოებით ორმოცდასამი წუთი მუშაობის შეფერხება ყოველთვიურად, როდესაც API მოთხოვნამ შესაძლოა დააბრუნოს ხუთასიანი შეცდომა. მაგრამ S3 გვპირდება 11 ცხრიანს გამძლეობას: 99 წერტილი ცხრა ცხრა ცხრა ცხრა ცხრა ცხრა ცხრა ცხრა ცხრა პროცენტი. თუ S3-ში ათ მილიონ ფაილს ინახავთ, სტატისტიკურად შეგიძლიათ ელოდოთ, რომ დაკარგავთ ერთ

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

- 10. Infrastructure as Code (Terraform vs. Console Drift)

12:14 მეათე კონცეფცია: ინფრასტრუქტურა კოდის სახით, ანუ IaC. ღრუბლოვანი გამოთვლების ადრეულ დღეებში, ინჟინრები შედიოდნენ AWS-ის ვებ მართვის კონსოლში და ხელით აწკაპუნებდნენ ვირტუალური მანქანების შესაქმნელად, ქვექსელების კონფიგურაციისთვის და უსაფრთხოების ჯგუფების დასამატებლად. ინდუსტრია ამას ClickOps-ს უწოდებს, და წარმოებაში, ეს აბსოლუტური კატასტროფაა. კონსოლის ხელით ცვლილებებს არ გააჩნიათ აუდიტის კვალი, არ გააჩნიათ უკან დახევის მექანიზმი და გარდაუვლად იწვევს კონფიგურაციის დრიფტს staging-სა და production გარემოებს შორის. ინფრასტრუქტურის

12:48 როგორც კოდის ხელსაწყოებით, როგორიცაა Terraform, OpenTofu, Pulumi, ან AWS CDK, თქვენ განსაზღვრავთ თქვენს მთელ ღრუბლოვან არქიტექტურას დეკლარაციულ კონფიგურაციის ფაილებში, რომლებიც Git-ში ინახება. ყველა ცვლილება ღია პორტში ან მონაცემთა ბაზის რეპლიკაში გადის pull request-სა და თანატოლთა განხილვას. terraform plan-ის გაშვება წინასწარ აჩვენებს ზუსტ API diff-ს სანამ რამეს შეეხებით, და თქვენი production-ის იდენტური რეპლიკის გაშვებას ოთხი წუთი სჭირდება ოთხი კვირის ნაცვლად.

- 11. ღრუბლოვანი ქსელი (VPC, Subnets, NAT & უსაფრთხოების ჯგუფები)

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

13:51 მასში ინახება საჯარო აქტივები, როგორიცაა თქვენი Application Load Balancers და NAT Gateways. ეს არის თქვენი ქსელის ერთადერთი ნაწილი, რომელსაც აქვს საჯარო IP მისამართები. თქვენი აპლიკაციის სერვერები და production მონაცემთა ბაზები მკაცრად კერძო ქვექსელებში ცხოვრობენ საჯარო IP-ების გარეშე და ნულოვანი შემომავალი მარშრუტებით ინტერნეტიდან. როდესაც თქვენს ბექენდ სერვერებს უსაფრთხოების განახლებების გადმოწერა სჭირდებათ, მათი გამავალი ტრაფიკი საჯარო ქვექსელში არსებული NAT Gateway-ის გავლით გადის. ყოველი ინსტანციის გარშემო არის უსაფრთხოების ჯგუფები: მდგომარეობრივი ვირტუალური firewall-ები, რომლებიც უზრუნველყოფენ მინიმალური პრივილეგიის პრინციპს.

- 12. სრული საწარმოს გეგმა და ვერდიქტი

14:28 თქვენი მონაცემთა ბაზის უსაფრთხოების ჯგუფი იღებს კავშირებს პორტზე 5432 მხოლოდ თქვენი აპლიკაციის სერვერების უსაფრთხოების ჯგუფიდან, რის გამოც გარე შეღწევა მათემატიკურად შეუძლებელია. როდესაც მასშტაბს ამცირებთ, ეს თერთმეტი პრიმიტივი ერთ კოჰეზიურ სისტემად ერთიანდება. თქვენი DNS მარშრუტდება Load Balancer-ზე საჯარო ქვექსელში, ავტომასშტაბირების ჯგუფები ამუშავებენ ტრაფიკის ზრდას მრავალ Availability Zone-ში, მოვლენათა ავტობუსები აცალკევებენ ბექენდ მუშაკებს, და თქვენი მთელი სტეკი Git-იდან განლაგდება ინფრასტრუქტურა როგორც კოდის გამოყენებით.

15:02 დღევანდელი მასტერკლასის ვერდიქტი: SHIP IT. შეწყვიტეთ ასობით ღრუბლოვანი მარკეტინგული აბრევიატურის დამახსოვრება. დაეუფლეთ ამ თერთმეტ არქიტექტურულ შაბლონს, გააცალკევეთ თქვენი მდგომარეობა, და ააშენეთ სისტემები, რომლებსაც არ შეუძლიათ მარცხი. მითხარით, რომელმა ღრუბლოვანმა კონცეფციამ შეგიქმნათ ყველაზე დიდი თავის ტკივილი, როდესაც პირველად დაიწყეთ მშენებლობა კომენტარებში. და სრული არქიტექტურის "მოტყუების ფურცლის" ასაღებად, გამოიწერეთ ბიულეტენი the daily diff dot dev-ზე,

15:28 ბმული ქვემოთ. და ეს არის დღევანდელი diff. მე ვარ ნიკო Axrisi-დან. პასუხისმგებლობით გააერთიანეთ.

წყაროები

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io