Објашњење рачунарства у облаку: 11 архитектонских концепата које морате знати (4К мастерклас).

Шта овај видео покрива

• - Архитектонски зид и главни нацрт
• - 01. Вертикално наспрам хоризонталног скалирања
• - 02. Архитектура балансирања оптерећења (L4 наспрам L7 и провере здравља)
• - 03. Аутоматско скалирање и еластичност
• - 04. Без сервера (FaaS и Firecracker MicroVMs)

Преведени транскрипт

Преведено са оригиналне енглеске нарације. Доступни аудио и титлови контролисани су од стране YouTube-а.

- Архитектонски зид и главни нацрт

0:00 Сваки софтверски инжењер се на крају суочи са зидом архитектуре облака. Изградите апликацију на свом лаптопу, гурнете је у производњу, и оног тренутка када стварни корисници стигну, сервери се руше, везе са базама података се испразне, а ваш AWS рачун изгледа као број телефона. Већина програмера покушава да реши инжењеринг облака памћењем три стотине различитих AWS скраћеница производа. Али право рачунарство у облаку није памћење каталога добављача: оно је изграђено на једанаест фундаменталних архитектонских примитива.

0:34 У овом мастеркласу, проћи ћемо кроз цео нацрт предузећа: од скалирања и балансирања оптерећења до без сервера, одвајања вођеног догађајима, хијерархија складиштења и умрежавања у облаку. Овладајте овим једанаест концепата и можете дизајнирати било који позадински систем на AWS-у, GCP-у или Azure-у. Ово је The Daily Diff, испод хаубе.

- 01. Вертикално наспрам хоризонталног скалирања

0:57 Концепт број један: Скалирање. Када ваша апликација доживи раст саобраћаја, имате два фундаментално различита начина да се носите са оптерећењем: вертикално скалирање или хоризонтално скалирање. Вертикално скалирање, или скалирање навише, значи узимање ваше постојеће машине и додавање више ресурса: надоградња са четири ЦПУ језгра на тридесет два, или замена тридесет два гигабајта РАМ-а за сто двадесет осам. Вертикално скалирање не захтева никакве архитектонске промене: ваш код

1:28 и база података остају потпуно исти. Али оно удара у брутални хардверски плафон. Ниједна машина на свету нема десет хиљада ЦПУ језгара, а врхунске инстанце носе експоненцијалну премију цене. Хоризонтално скалирање, или скалирање споља, значи задржавање ваших сервера малих и са стандардном ценом, али покретање више инстанци паралелно иза рутера. Ако се једна инстанца сруши, преостали чворови апсорбују саобраћај са нултим застојем. Златно правило хоризонталног скалирања је

2:01 безстатност: ваши сервери апликација не могу да чувају корисничке сесије, отпремљене датотеке или стање на својим локалним дисковима. Стање мора да живи у спољној бази података или кешу, омогућавајући било ком чвору да обради било који кориснички захтев.

- 02. Архитектура балансирања оптерећења (L4 наспрам L7 и провере здравља)

2:17 Концепт број два: Балансирање оптерећења. Хоризонтално скалирање звучи сјајно на папиру, али уводи тренутни проблем: када десет хиљада корисника погоди ваше име домена, који конкретан сервер прима њихов саобраћај? Балансер оптерећења делује као обрнути прокси који се налази између јавног интернета и вашег приватног позадинског кластера. Он прихвата долазне TCP или HTTP везе и дистрибуира захтеве преко ваших здравих инстанци.

2:47 Балансери оптерећења раде на два примарна мрежна слоја. Балансери оптерећења мреже Слоја 4 раде на транспортном слоју, рутирајући необрађене TCP и UDP пакете на основу IP адресе и порта са латенцијом од микросекунди и милионима захтева у секунди. Балансери оптерећења апликација Слоја 7 прегледају сам HTTP протокол: читајући URL путање, заглавља захтева, колачиће и HTTP методе. Ово омогућава рутирање на основу путање: слање захтева /api на ваш позадински кластер и захтева /static на складиште

3:25 објеката. Кључно, балансери оптерећења врше активне провере здравља. Сваких неколико секунди, балансер пингује здравствену тачку на свакој инстанци. Ако инстанца баци три узастопне грешке типа пет стотина или не успе да одговори, аутоматски се избацује из базе са нултим испуштеним захтевима.

- 03. Аутоматско скалирање и еластичност

3:45 Концепт број три: Аутоматско скалирање. Ако вашој веб апликацији требају два сервера у три ујутро, али двадесет сервера током подневне лансирне фазе, ручно кликтање на дугмиће у конзоли облака је гарантовани пут до застоја и банкрота. Аутоматско скалирање доноси динамичку еластичност хоризонталним групама сервера. Група за аутоматско скалирање прати метрике перформанси као што је просечна искоришћеност процесора, мрежни I/O или дубина заостатка у реду чекања. Када просечна искоришћеност процесора пређе дефинисани праг — рецимо,

4:19 седамдесет посто три узастопна минута — аутоматски скалер аутоматски покреће нове виртуалне машине, региструје их код вашег балансера оптерећења, и почиње да рутира саобраћај. Једнако важно је и скалирање: када талас саобраћаја опадне, аутоматски скалер терминима вишак инстанци тако да престанете да плаћате за неактивно рачунарство. Да би се спречило осцилирање — где се сервери брзо креирају и уништавају у бескрајној петљи — архитекти облака конфигуришу периоде хлађења. Концепт број четири: Без сервера.

- 04. Без сервера (FaaS и Firecracker MicroVMs)

4:53 Годинама су маркетиншки тимови представљали без сервера као магични код који ради на небу. У стварности, без сервера и даље користи сервере — али ви их не поседујете, не закрпљујете, нити плаћате када код не ради. Са функцијом као сервисом попут AWS Lambda или Google Cloud Functions, пишете самосталну функцију руковања. Када дође до HTTP захтева, S3 отпремања датотеке или промене у бази података, окружење облака покреће ефемерну

5:23 микро-виртуелну-машину попут Firecracker-а за мање од пет милисекунди. Ваш код се извршава, враћа одговор и гаси се. Ако нико не посети вашу веб страницу три месеца, ваш рачун за рачунарство је тачно нула долара и нула центи. Ако милион корисника приступи истовремено, провајдер покреће милион истовремених микроВМ-ова. Компромиси у инжењерингу су стварни: латенција хладног покретања при покретању свежих окружења, строго ограничење извршења од петнаест минута на Lambda-и и строга безстатност.

5:55 Без сервера је ненадмашиво за догађајне цевоводе и спорадичне API-је, али лоше за постојане WebSockets или вишесатно тренирање.

- 05. Архитектура вођена догађајима (EDA и одвајање)

6:05 Концепт број пет: Архитектура вођена догађајима, или EDA. У традиционалним архитектурама, услуге комуницирају синхроно. Ваша услуга плаћања позива плаћање, плаћање позива инвентар, инвентар позива превару, а превара позива е-пошту. Ово ствара синхрону каскаду пропасти. Ако провајдер е-поште треће стране доживи мрежни проблем и треба му десет секунди да одговори, цео захтев вашег корисника за плаћање истиче са грешком. У архитектури вођеној догађајима, услуге су потпуно одвојене.

6:37 Када купац кликне на „купи“, услуга плаћања не позива низводне услуге. Она једноставно објављује догађај под називом OrderPlaced на централном Аутобусу догађаја попут Amazon EventBridge или SNS теме. Плаћање се завршава за педесет милисекунди. Низводни радници за плаћање, смањење инвентара и е-пошту са рачунима независно повлаче поруке из својих наменских SQS редова. Ако услуга е-поште не ради сат времена, поруке сигурно чекају буфероване у реду без иједне испуштене поруџбине.

- 06. Оркестрација контејнера (Docker и Kubernetes)

7:13 Концепт број шест: Оркестрација контејнера. Docker је решио паковање: обмотава ваш код апликације, системске библиотеке, конфигурацију и извршно окружење у непроменљиву слику која идентично ради на вашем MacBook-у и у облаку. Али паковање контејнера је лако. Покретање пет стотина контејнера преко педесет физичких виртуелних машина је место где инжењеринг пуца. Зато постоје оркестратори контејнера као што су Kubernetes и AWS ECS.

7:41 Оркестратор обезбеђује контролну раван: API сервер, etcd складиште стања и интелигентни распоређивач. Ви декларишете жељено стање: желим десет реплика моје услуге аутентификације са по два гигабајта РАМ-а. Распоређивач прегледа кластер, поставља поде на чворове са слободном меморијом, конфигурише интерно умрежавање и непрекидно усклађује стварност. Ако чвор доживи квар хардвера, Kubernetes детектује губитак и одмах прераспоређује све измештене поде на

- 07. Четири стуба складиштења у облаку (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-а који испоручују једноцифрену латенцију у милисекундама у огромном обиму. И четврто су кешеви у меморији попут Redis-а. Читање података из РАМ-а траје микросекунде, а не милисекунде. Кешеви се налазе испред ваше базе података, штитећи је од поновљеног саобраћаја читања и управљајући променљивим токенима корисничких сесија.

- 08. Висока доступност и деветке (Failover са више АЗ)

9:44 Концепт број осам: Висока доступност, или HA. Доступност одговара на једно питање: колико процената времена је ваша апликација оперативна и доступна корисницима? У корпоративним уговорима, доступност се мери у деветкама. Две деветке, или деведесет девет посто доступности, омогућава преко три и по дана застоја сваке године. Четири деветке смањују дозвољено време застоја на педесет две минуте, а пет деветки дозвољава једва пет минута укупног застоја годишње.

10:15 Да бисте постигли високу доступност, морате елиминисати појединачне тачке отказа у доменима грешака. У облаку, то значи распоређивање преко више зона доступности. Зона доступности није један рацк: то је један или више различитих физичких центара података удаљених миљама са независним напајањем и хлађењем. Покретањем активних инстанци у Зони А и Зони Б са синхроном репликацијом базе података, удар грома или прекид влакна који доведе до прекида целог физичког објекта резултира аутоматским пребацивањем

10:50 за тридесет секунди са нултом људском интервенцијом.

- 09. Трајност наспрам доступности (Зашто 11 деветки није време рада)

10:53 Концепт број девет: Трајност наспрам Доступности. Ово је најчешћа концептуална замка у архитектури облака интервјуима. Инжењери често користе ове речи наизменично, али оне мере потпуно различите особине. Доступност мери време рада: могу ли да позовем АПИ да прочитам или пишем моје податке баш овог тренутка? Трајност мери очување: да ли ће моји подаци преживети без трајне битне трулежи, оштећења или уништења током десет година?

11:24 Погледајте Amazon S3 Standard. Његов Уговор о нивоу услуге нуди деведесет девет тачка девет процената доступности, што дозвољава отприлике четрдесет три минута застоја месечно где АПИ захтев може вратити грешку петсто. Али S3 обећава једанаест деветки трајности: деведесет девет тачка девет девет девет девет девет девет девет девет девет процената. Ако складиштите десет милиона датотека у S3, статистички можете очекивати да ћете изгубити

11:56 просечно једну датотеку сваких десет хиљада година. S3 то постиже кодирањем објеката за брисање и реплицирањем делова преко најмање три географски одвојена центра за податке. Током великог регионалног прекида мреже, S3 може привремено бити недоступан, али ваши подаци никада нису уништени.

- 10. Инфраструктура као код (Terraform наспрам Console Drift)

12:14 Концепт број десет: Инфраструктура као код, или IaC. У раним данима рачунарства у облаку, инжењери су се пријављивали на AWS конзолу за веб управљање и ручно кликали да би креирали виртуелне машине, конфигурисали подмреже и прикључивали безбедносне групе. Индустрија то назива ClickOps, а у продукцији је то апсолутна катастрофа. Ручне промене у конзоли немају евиденцију ревизије, нема механизам за враћање и неизбежно узрокују одступања у конфигурацији између развојног и продукционог окружења. Са алатима за инфраструктуру

12:48 као код попут Terraform, OpenTofu, Pulumi, или AWS CDK, ви дефинишете своју целокупну архитектуру облака у декларативним конфигурационим датотекама које су ускладиштене у Git-у. Свака промена отвореног порта или реплике базе података пролази кроз захтев за повлачење и рецензију колега. Покретање terraform plan-а приказује тачну АПИ разлику пре него што се било шта дотакне, а покретање идентичне реплике вашег продукционог стека траје четири минута уместо четири недеље.

- 11. Умрежавање у облаку (VPC, Подмреже, NAT и Сигурносне групе)

13:20 Концепт број једанаест: Мрежа у облаку и Виртуелне приватне облаке. Када распоређујете сервере у облак, они не седе изложени на чистој јавној мрежи. Они живе унутар софтверски дефинисане изоловане границе која се зове VPC. Унутар вашег VPC-а, алоцирате приватни ИП адресни простор попут десет-тачка-нула-тачка-нула-тачка-нула коса црта шеснаест, и делите га на јавне и приватне подмреже. Јавна подмрежа има директан пут до Интернет Гејтвеја.

13:51 Она садржи јавне ресурсе попут ваших балансера оптерећења апликација и NAT гејтвеја. То је једини део ваше мреже који поседује јавне ИП адресе. Ваши апликациони сервери и продукционе базе података стриктно живе у приватним подмрежама без јавних ИП адреса и нултих долазних рута са интернета. Када ваши бекенд сервери треба да преузму безбедносне исправке, њихов одлазни саобраћај иде кроз NAT Гејтвеј у јавној подмрежи. Сваку инстанцу окружују безбедносне групе: stateful виртуални заштитни зидови који спроводе принцип најмање привилегије.

- 12. Комплетан нацрт предузећа и пресуда

14:28 Ваша безбедносна група базе података прихвата везе само на порту 5432 стриктно од безбедносне групе ваших апликационих сервера, чинећи спољашњу пенетрацију математички немогућом. Када се погледа шире, ових једанаест примитива повезују се у један кохезиван систем. Ваш DNS рутира на балансер оптерећења у јавној подмрежи, групе за аутоматско скалирање рукују порастом саобраћаја преко више зона доступности, аутобуси догађаја одвајају позадинске раднике, а цео ваш стек је размештен из Git-а користећи Инфраструктуру као код.

15:02 Данашња пресуда мајсторске класе: SHIP IT. Престаните да памтите стотине акронима облачног маркетинга. Овладајте овим једанаест архитектонских образаца, одвојите своје стање, и градите системе који не могу отказати. Реците ми који концепт облака вам је задао највећу главобољу када сте први пут почели да градите у коментарима. И да узмете комплетан архитектонски водич, претплатите се на билтен на the daily diff dot dev,

15:28 линк испод. И то је разлика за данас. Ја сам Нико из 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