Тлумачэнне воблачных вылічэнняў: 11 канцэпцый архітэктуры, якія вы павінны ведаць (4K майстар-клас).

Што ахоплівае гэта відэа

• - Сцяна архітэктуры і генеральны план
• - 01. Вертыкальнае супраць гарызантальнага маштабавання
• - 02. Архітэктура балансіроўкі нагрузкі (L4 супраць L7 і праверкі спраўнасці)
• - 03. Аўтамаштабаванне і эластычнасць
• - 04. Бессерверны (FaaS і мікра-ВМ Firecracker)

Перакладзеная стэнаграма

Перакладзена з арыгінальнай англійскай агучкі. Даступнае аўдыя і субтытры кантралююцца YouTube.

- Сцяна архітэктуры і генеральны план

0:00 Кожны інжынер-праграміст рана ці позна сутыкаецца са сцяной воблачнай архітэктуры. Вы ствараеце праграму на сваім ноўтбуку, запускаеце яе ў вытворчасць, і ў той момант, калі прыходзяць рэальныя карыстальнікі, серверы выходзяць з ладу, злучэнні з базай дадзеных вычэрпваюцца, а ваш рахунак за AWS выглядае як нумар тэлефона. Большасць распрацоўшчыкаў спрабуюць вырашыць праблемы воблачнай інжынерыі, запамінаючы трыста розных акронімаў прадуктаў AWS. Але рэальныя воблачныя вылічэнні - гэта не запамінанне каталогаў пастаўшчыкоў: яны пабудаваны на адзінаццаці фундаментальных архітэктурных прымітывах.

0:34 У гэтым майстар-класе мы разгледзім увесь карпаратыўны план: ад маштабавання і балансіроўкі нагрузкі да бессерверных рашэнняў, падзеева-кіраванай дэкаплінгу, іерархій захоўвання дадзеных і воблачных сетак. Авалодайце гэтымі адзінаццаццю канцэпцыямі, і вы зможаце спраектаваць любы бэкэнд на AWS, GCP або Azure. Гэта The Daily Diff, знутры.

- 01. Вертыкальнае супраць гарызантальнага маштабавання

0:57 Канцэпцыя нумар адзін: Маштабаванне. Калі ваша праграма сутыкаецца з ростам трафіку, у вас ёсць два прынцыпова розныя спосабы апрацоўкі нагрузкі: вертыкальнае маштабаванне або гарызантальнае маштабаванне. Вертыкальнае маштабаванне, або "маштабаванне ўверх", азначае ўзяць вашу існуючую машыну і дадаць больш рэсурсаў: абнавіць чатыры ядра CPU да трыццаці двух, або замяніць трыццаць два гігабайты RAM на сто дваццаць восем. Вертыкальнае маштабаванне не патрабуе архітэктурных змяненняў: ваш код

1:28 і база дадзеных застаюцца абсалютна ранейшымі. Але яно сутыкаецца з жорсткай апаратнай мяжой. Ніводная машына ў свеце не мае дзесяці тысяч ядраў CPU, а самыя лепшыя экзэмпляры маюць экспанентна высокую цану. Гарызантальнае маштабаванне, або "маштабаванне вонкі", азначае захаванне вашых сервераў невялікімі і таварнымі па цане, але запуск некалькіх экзэмпляраў паралельна за маршрутызатарам. Калі адзін экзэмпляр выходзіць з ладу, астатнія вузлы паглынаюць трафік без прастою. Залатое правіла гарызантальнага маштабавання - гэта

2:01 бесстатачнасць: серверы вашага прыкладання не могуць захоўваць карыстальніцкія сесіі, загружаныя файлы або стан на сваіх лакальных дысках. Стан павінен знаходзіцца ў знешняй базе дадзеных або кэшы, дазваляючы любому вузлу апрацоўваць любы запыт карыстальніка.

- 02. Архітэктура балансіроўкі нагрузкі (L4 супраць L7 і праверкі спраўнасці)

2:17 Канцэпцыя нумар два: Балансіроўка нагрузкі. Гарызантальнае маштабаванне выглядае выдатна на паперы, але яно адразу стварае праблему: калі дзесяць тысяч карыстальнікаў звяртаюцца да вашага даменнага імя, які канкрэтны сервер атрымлівае іх трафік? Балансіроўшчык нагрузкі дзейнічае як зваротны проксі-сервер, які знаходзіцца паміж публічным інтэрнэтам і вашым прыватным бэкэнд-кластарам. Ён прымае ўваходныя TCP або HTTP-злучэнні і размяркоўвае запыты па вашых спраўных экзэмплярах.

2:47 Балансіроўшчыкі нагрузкі працуюць на двух асноўных сеткавых узроўнях. Балансіроўшчыкі сеткавай нагрузкі ўзроўню 4 працуюць на транспартным узроўні, маршрутызуючы сырыя TCP і UDP-пакеты на аснове IP-адраса і порта з мікрасекунднай затрымкай і мільёнамі запытаў у секунду. Балансіроўшчыкі нагрузкі прыкладанняў узроўню 7 правяраюць сам пратакол HTTP: чытаюць шляхі URL, загалоўкі запытаў, кукі і метады HTTP. Гэта дазваляе маршрутызацыю на аснове шляху: адпраўку запытаў /api на ваш бэкэнд-кластар, а запытаў /static - у сховішча

3:25 аб'ектаў. Важна адзначыць, што балансіроўшчыкі нагрузкі выконваюць актыўныя праверкі спраўнасці. Кожныя некалькі секунд балансіроўшчык пінгвае канчатковую кропку здароўя на кожным экзэмпляры. Калі экзэмпляр выдае тры паслядоўныя памылкі з кодам 500 або не адказвае, ён аўтаматычна выдаляецца з пула без страты запытаў.

- 03. Аўтамаштабаванне і эластычнасць

3:45 Канцэпцыя нумар тры: Аўтамаштабаванне. Калі вашаму вэб-прыкладанню патрэбны два серверы ў тры гадзіны раніцы, але дваццаць сервераў падчас запуску ў сярэдзіне дня, ручное націсканне кнопак у воблачнай кансолі - гэта гарантаваны шлях да прастояў і банкруцтва. Аўтамаштабаванне забяспечвае дынамічную эластычнасць пулаў гарызантальных сервераў. Група аўтамаштабавання кантралюе метрыкі прадукцыйнасці, такія як сярэдняе выкарыстанне CPU, сеткавае ўвод-вывад або глыбіня чаргі бэклога. Калі сярэдняе значэнне CPU перавышае вызначаны парог — скажам,

4:19 семдзесят працэнтаў на працягу трох хвілін — аўтамаштабавальнік аўтаматычна запускае новыя віртуальныя машыны, рэгіструе іх у вашым балансіроўшчыку нагрузкі і пачынае маршрутызаваць трафік. Не менш важнае маштабаванне ўнутр: калі хваля трафіку спадае, аўтамаштабавальнік спыняе лішнія экзэмпляры, каб вы перасталі плаціць за бяздзейныя вылічэнні. Каб прадухіліць пераключэнне — калі серверы хутка ствараюцца і знішчаюцца ў бясконцым цыкле – воблачныя архітэктары наладжваюць перыяды астуджэння. Канцэпцыя нумар чатыры: Бессерверны.

- 04. Бессерверны (FaaS і мікра-ВМ Firecracker)

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 і інтэлектуальны планавальнік. Вы аб'яўляеце свой жаданы стан: я хачу дзесяць копій майго сэрвісу аўтэнтыфікацыі з двума гігабайтамі RAM кожная. Планавальнік правярае кластар, размяшчае поды на вузлах з вольнай памяццю, наладжвае ўнутраныя сеткі і бесперапынна ўзгадняе рэальнасць. Калі вузел пацярпеў ад апаратнага збою, 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, якія забяспечваюць аднаначную мілісекундную затрымку ў вялікім маштабе. І чацвёртае - гэта кэшы ў памяці, такія як Redis. Чытанне дадзеных з RAM займае мікрасекунды, а не мілісекунды. Кэшы знаходзяцца перад вашай базай дадзеных, абараняючы яе ад паўторнага трафіку чытання і кіруючы зменлівымі токенамі карыстальніцкіх сесій.

- 08. Высокая даступнасць і "дзявяткі" (пераключэнне на некалькі AZ)

9:44 Канцэпцыя нумар восем: Высокая даступнасць, або HA. Даступнасць адказвае на адно пытанне: які працэнт часу ваша праграма працуе і даступная карыстальнікам? У карпаратыўных кантрактах даступнасць вымяраецца ў "дзявятках". Дзве "дзявяткі", або дзевяноста дзевяць працэнтаў даступнасці, дазваляюць больш за тры з паловай дні прастою ў год. Чатыры "дзявяткі" скарачаюць дапушчальны час прастою да пяцідзесяці дзвюх хвілін, а пяць "дзявятак" дазваляюць усяго пяць хвілін агульнага часу прастою ў

10:15 год. Каб дасягнуць высокай даступнасці, вы павінны выключыць адзінкавыя кропкі адмовы паміж даменамі адмоў. У воблаку гэта азначае разгортванне ў некалькіх зонах даступнасці. Зона даступнасці - гэта не адзіны стэлаж: гэта адзін ці некалькі розных фізічных цэнтраў апрацоўкі дадзеных на адлегласці міль з незалежным харчаваннем і астуджэннем. Запускаючы актыўныя экзэмпляры ў зоне A і зоне B з сінхроннай рэплікацыяй базы дадзеных, удар маланкі або перарэзка валакна, якія выклікаюць выход з ладу ўсяго фізічнага аб'екта, прыводзяць да аўтаматычнага пераключэння.

10:50 за трыццаць секунд без умяшання чалавека.

- 09. Даўгавечнасць супраць даступнасці (чаму 11 дзявятак - гэта не uptime)

10:53 Канцэпцыя нумар дзевяць: Даўгавечнасць супраць даступнасці. Гэта адзіная найбольш распаўсюджаная канцэптуальная пастка ў хмарнай архітэктуры інтэрв'ю. Інжынеры часта выкарыстоўваюць гэтыя словы ўзаемазаменна, але яны вымяраюць зусім розныя ўласцівасці. Даступнасць вымярае час працы: ці магу я зрабіць выклік API, каб прачытаць або запісаць свае даныя прама зараз? Даўгавечнасць вымярае захаванасць: ці выжывуць мае даныя без пастаяннага бітавага гніення, пашкоджання або знішчэння на працягу дзесяці гадоў?

11:24 Паглядзіце на Amazon S3 Standard. Яго Пагадненне аб узроўні абслугоўвання прапануе дзевяноста дзевяць і дзевяць дзясятых працэнта даступнасці, што дазваляе прыкладна сорак тры хвіліны прастою кожны месяц дзе запыт API можа вярнуць памылку пяцьсот. Але S3 абяцае адзінаццаць дзевятак даўгавечнасці: дзевяноста дзевяць кропка дзевяць дзевяць дзевяць дзевяць дзевяць дзевяць дзевяць дзевяць дзевяць дзевяць дзевяць працэнтаў. Калі вы захоўваеце дзесяць мільёнаў файлаў у S3, вы можаце статыстычна чакаць страты ў сярэднім аднаго файла кожныя дзесяць тысяч гадоў.

11:56 у сярэднім аднаго файла кожныя дзесяць тысяч гадоў. S3 дасягае гэтага шляхам кадзіравання аб'ектаў і рэплікацыі фрагментаў па меншай меры ў трох геаграфічна падзеленых цэнтрах апрацоўкі даных. па меншай меры ў трох геаграфічна падзеленых цэнтрах апрацоўкі даных. Падчас буйнога рэгіянальнага збою сеткі S3 можа быць часова недаступны, але вашы даныя ніколі не знішчаюцца.

- 10. Інфраструктура як код (Terraform супраць зруху кансолі)

12:14 Канцэпцыя нумар дзесяць: Інфраструктура як код, або IaC. На ранніх этапах хмарных вылічэнняў інжынеры ўваходзілі ў вэб-кансоль кіравання AWS і ўручную націскалі вакол, каб ствараць віртуальныя машыны, наладжваць падсеткі і далучаць групы бяспекі. Галіна называе гэта ClickOps, і ў вытворчасці гэта абсалютная катастрофа. Ручныя змены ў кансолі не маюць аўдытарскага следу, механізму адкату і непазбежна выклікаюць дрэйф канфігурацыі паміж асяроддзямі стэйджавання і вытворчасці. З інструментамі Інфраструктуры як Код, такімі як Terraform,

12:48 як Код, такімі як Terraform, OpenTofu, Pulumi або AWS CDK, вы вызначаеце сваю усю хмарную архітэктуру ў дэкларатыўных файлах канфігурацыі, якія захоўваюцца ў Git. Кожная змена адкрытага порта або рэплікі базы дадзеных праходзіць праз запыт на аб'яднанне і экспертную ацэнку. Запуск terraform plan праглядае дакладны дыф API, перш чым што-небудзь будзе закранута, а разгортванне ідэнтычнай рэплікі вашага вытворчага стэка займае чатыры хвіліны замест чатырох тыдняў.

- 11. Воблачныя сеткі (VPC, падсеткі, NAT і групы бяспекі)

13:20 Канцэпцыя нумар адзінаццаць: Хмарная сетка і віртуальныя прыватныя воблакі. Калі вы разгортваеце серверы ў воблаку, яны не знаходзяцца адкрытымі ў сырым публічным інтэрнэце. Яны жывуць у ізаляванай мяжы, вызначанай праграмным забеспячэннем, званай VPC. Унутры вашага VPC вы вылучаеце прыватную прастору IP-адрасоў, напрыклад, дзесяць-кропка-нуль-кропка-нуль-кропка-нуль слэш шаснаццаць, і дзеліце яе на публічныя і прыватныя падсеткі. Публічная падсетка мае прамы маршрут да інтэрнэт-шлюза.

13:51 Яна змяшчае публічныя актывы, такія як балансіроўшчыкі нагрузкі прыкладанняў і NAT Шлюзы. Гэта адзіная частка вашай сеткі, якая валодае публічнымі IP-адрасамі. Адрасы. Вашы серверы прыкладанняў і вытворчыя базы дадзеных жывуць строга ў прыватных падсетках без публічных IP-адрасоў і нуля ўваходных маршрутаў з інтэрнэту. Калі вашым бэкэнд-серверам трэба спампаваць абнаўленні бяспекі, іх зыходны трафік праходзіць праз шлюз NAT у публічнай падсетцы. Вакол кожнага экзэмпляра знаходзяцца групы бяспекі: віртуальныя віртуальныя фаерволы, якія забяспечваюць прынцып найменшых прывілеяў.

- 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