Хмарні обчислення: 11 архітектурних концепцій, які ви повинні знати (4K майстер-клас).

Що охоплює це відео

• - Стіна архітектури та Майстер-план
• - 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, заголовки запитів, файли cookie та методи HTTP. Це дозволяє маршрутизацію на основі шляху: надсилання запитів за шляхом /api до вашого бекенд-кластера та запитів за шляхом /static до

3:25 об'єктного сховища. Важливо, що балансувальники навантаження виконують активні перевірки стану. Кожні кілька секунд балансувальник пінгє кінцеву точку здоров'я на кожному екземплярі. Якщо екземпляр видає три послідовні помилки п'ятсот або не відповідає, він автоматично видаляється з пулу без втрати жодного запиту.

- 03. Автомасштабування та еластичність

3:45 Концепція номер три: Автомасштабування. Якщо вашій веб-програмі потрібно два сервери о третій ранку, але двадцять серверів під час запуску опівдні, ручне натискання кнопок у хмарній консолі — це гарантований шлях до простоїв та банкрутства. Автомасштабування забезпечує динамічну еластичність пулів горизонтальних серверів. Група автомасштабування відстежує показники продуктивності, такі як середнє використання процесора, мережевий ввід/вивід або глибина черги очікування. Коли середнє використання процесора перевищує визначений поріг — скажімо,

4:19 сімдесят відсотків протягом трьох послідовних хвилин — автомасштабувальник автоматично запускає нові віртуальні машини, реєструє їх у вашому балансувальнику навантаження та починає маршрутизувати трафік. Не менш важливим є масштабування всередину: коли хвиля трафіку спадає, автомасштабувальник припиняє роботу надлишкових екземплярів, щоб ви припинили платити за прості обчислення. Щоб запобігти «флапінгу» — коли сервери швидко створюються та знищуються в нескінченному циклі метання — хмарні архітектори налаштовують періоди охолодження. Концепція номер чотири: Безсерверні технології.

- 04. Безсерверні технології (FaaS та Firecracker MicroVMs)

4:53 Протягом багатьох років маркетингові команди рекламували безсерверні технології як магічний код, що працює в хмарі. Насправді, безсерверні технології все ще використовують сервери, але ви їх не володієте, не виправляєте та не платите за них, коли код не виконується. З Function-as-a-Service, такими як 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. 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. Читання даних з оперативної пам'яті займає мікросекунди, а не мілісекунди. Кеші знаходяться перед вашою базою даних, захищаючи її від повторного трафіку читання та керуючи тимчасовими токенами сесій користувачів.

- 08. Висока доступність та дев'ятки (відмовостійкість між кількома зонами доступності)

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

10:15 рік. Щоб досягти високої доступності, ви повинні усунути єдині точки відмови у різних доменах відмови. У хмарі це означає розгортання в кількох зонах доступності. Зона доступності — це не єдина стійка: це один або кілька окремих фізичних центрів обробки даних, розташованих за милі один від одного, з незалежним живленням та охолодженням. Запускаючи активні екземпляри в зоні A та зоні B із синхронною реплікацією бази даних, удар блискавки або переріз волокна, що виводить з ладу весь фізичний об'єкт, призводить до автоматичного перемикання на резерв.

10:50 за тридцять секунд без жодного втручання людини.

- 09. Довговічність проти доступності (чому 11 дев'яток – це не час безвідмовної роботи)

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

11:24 Подивіться на Amazon S3 Standard. Його Угода про рівень обслуговування пропонує дев'яносто дев'ять цілих дев'ять десятих відсотка доступності, що дозволяє приблизно сорок три хвилини простою щомісяця, коли запит API може повертати п'ятисоту помилку. Але S3 обіцяє одинадцять дев'яток довговічності: дев'яносто дев'ять цілих дев'ять дев'ять дев'ять дев'ять дев'ять дев'ять дев'ять дев'ять дев'ять дев'ять відсотків. Якщо ви зберігаєте десять мільйонів файлів в S3, ви можете статистично очікувати втрати в середньому одного

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

- 10. Інфраструктура як код (Terraform проти Console Drift)

12:14 Концепція номер десять: Інфраструктура як код, або IaC. На початку хмарних обчислень інженери входили в консоль веб-управління AWS і вручну клацали, щоб створити віртуальні машини, налаштувати підмережі та приєднати групи безпеки. машини, налаштовували підмережі та приєднували групи безпеки. Галузь називає це ClickOps, і у виробництві це абсолютна катастрофа. Ручні зміни в консолі не мають аудиторського сліду, механізму відкату і неминуче викликають розбіжності в конфігурації між проміжною та виробничою середовищами. За допомогою інструментів Infrastructure as Code, таких як Terraform,

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

- 11. Хмарні мережі (VPC, підмережі, NAT та групи безпеки)

13:20 Концепція номер одинадцять: Хмарні мережі та Віртуальні Приватні Хмари. Коли ви розгортаєте сервери в хмарі, вони не знаходяться у відкритому доступі в сирому публічному інтернеті. Вони живуть всередині програмно-визначеної ізольованої межі, званої VPC. Всередині вашого VPC ви виділяєте приватний адресний простір IP, наприклад десять-крапка-нуль-крапка-нуль-крапка-нуль слеш шістнадцять, і ділите його на публічні та приватні підмережі. Публічна підмережа має прямий маршрут до Інтернет-шлюзу.

13:51 Вона містить публічні активи, такі як ваші балансувальники навантаження додатків та NAT Шлюзи. Це єдина частина вашої мережі, яка володіє публічними IP-адресами. Ваші сервери додатків та виробничі бази даних живуть суворо в приватних підмережах без публічних IP-адрес та нульових вхідних маршрутів з інтернету. Коли вашим серверам бекенда потрібно завантажити оновлення безпеки, їхній вихідний трафік маршрутизується через NAT-шлюз у публічній підмережі. Навколо кожного інстансу розташовані групи безпеки: віртуальні брандмауери зі збереженням стану, віртуальні брандмауери, які забезпечують принцип найменших привілеїв.

- 12. Повний корпоративний план та висновок

14:28 Ваша група безпеки бази даних приймає з'єднання на порту 5432 суворо від групи безпеки ваших серверів додатків, що робить зовнішнє проникнення математично неможливим. Якщо подивитися ширше, ці одинадцять примітивів об'єднуються в одну цілісну систему. Ваш DNS маршрутизується до балансувальника навантаження в публічній підмережі, групи автомасштабування обробляють сплески трафіку в декількох зонах доступності, шини подій розв'язують працівників бекенда, і весь ваш стек розгортається з Git за допомогою Infrastructure as Code.

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