# Объяснение облачных вычислений: 11 архитектурных концепций, которые вы должны знать (4K-мастер-класс).

Published: 2026-09-15

Большинство инженеров-программистов пытаются изучать облачную архитектуру, запоминая сотни аббревиатур продуктов поставщиков из AWS, GCP и Azure. Но реальная облачная инженерия строится на одиннадцати фундаментальных архитектурных примитивах. В этом 4K-ремастер-мастер-классе Нико разбирает полный корпоративный проект: от вертикального и горизонтального масштабирования и балансировки нагрузки уровня 7 до динамического автомасштабирования, бессерверного выполнения микро-ВМ, асинхронного событийно-ориентированного разъединения, оркестрации контейнеров, четырехуровневой иерархии хранения, критической разницы между высокой доступностью и 11 девятками долговечности, декларативной инфраструктуры как кода и сети виртуального частного облака. Освоите эти одиннадцать концепций, и вы сможете спроектировать любой бэкенд в продакшене. Вердикт: SHIP IT.

Canonical: https://thedailydiff.dev/ru/video/2026-09-14-cloud-computing-explained-4k/

## Что освещается в этом видео

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

## Главы

- 0:00 - Архитектурная стена и основной проект
- 0:57 - 01. Вертикальное против горизонтального масштабирования
- 2:17 - 02. Архитектура балансировки нагрузки (L4 против L7 и проверки работоспособности)
- 3:45 - 03. Автомасштабирование и эластичность
- 4:50 - 04. Бессерверный (FaaS и Firecracker MicroVMs)
- 6:05 - 05. Событийно-ориентированная архитектура (EDA и разъединение)
- 7:13 - 06. Оркестрация контейнеров (Docker и Kubernetes)
- 8:16 - 07. 4 Столпа облачного хранения (S3, EBS, DBs и Redis)
- 9:44 - 08. Высокая доступность и «девятки» (Multi-AZ Failover)
- 10:53 - 09. Долговечность против доступности (почему 11 девяток — это не аптайм)
- 12:14 - 10. Инфраструктура как код (Terraform против Console Drift)
- 13:20 - 11. Облачные сети (VPC, подсети, NAT и группы безопасности)
- 14:26 - 12. Полный корпоративный проект и вердикт

## Переведенная стенограмма

Переведено с оригинального английского повествования. Доступные аудио и субтитры контролируются 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 объектов. Важно отметить, что балансировщики нагрузки выполняют активные проверки работоспособности. Каждые несколько секунд балансировщик отправляет запрос к конечной точке работоспособности на каждом экземпляре. Если экземпляр выдает три последовательные ошибки 500 или не отвечает, он автоматически удаляется из пула с нулевыми потерями запросов.

### - 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. Высокая доступность и «девятки» (Multi-AZ Failover)

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, и в производстве это абсолютная катастрофа. Ручные изменения консоли не имеют аудиторского следа, механизма отката и неизбежно вызывают расхождение конфигураций между промежуточными и производственными средами. С помощью инструментов "Инфраструктура

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

### - 11. Облачные сети (VPC, подсети, NAT и группы безопасности)

13:20 Когда вы развертываете серверы в облаке, они не находятся в открытом доступе в чистом публичном интернете. Они живут внутри программно-определенной изолированной границы под названием VPC. Внутри вашего VPC вы выделяете частное адресное пространство IP, например, десять-точка-ноль-точка-ноль-точка-ноль слэш шестнадцать, и делите его на публичные и частные подсети. Публичная подсеть имеет прямой маршрут к Интернет-шлюзу. Она содержит общедоступные ресурсы, такие как балансировщики нагрузки приложений и NAT-шлюзы.

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

### - 12. Полный корпоративный проект и вердикт

14:28 5432 строго от группы безопасности ваших серверов приложений, делая внешнее проникновение математически невозможным. Если посмотреть шире, эти одиннадцать примитивов объединяются в одну целостную систему. Ваш DNS маршрутизируется к балансировщику нагрузки в публичной подсети, группы автомасштабирования обрабатывают всплески трафика в нескольких зонах доступности, шины событий развязывают бэкенд-воркеров, а весь ваш стек развертывается из Git с использованием Infrastructure as Code. Вердикт мастер-класса на сегодня: SHIP IT. Перестаньте запоминать сотни маркетинговых аббревиатур облачных технологий.

15:02 Освойте эти одиннадцать архитектурных шаблонов, отделите свое состояние и создайте системы, которые не могут отказать. Расскажите мне в комментариях, какая облачная концепция доставила вам наибольшую головную боль, когда вы только начинали строить. И чтобы получить полный чит-лист по архитектуре, подпишитесь на рассылку на daily diff dot dev, ссылка ниже. И это все на сегодня. Я Нико из Axrisi.

15:28 Слияние ответственно. Я Нико из Axrisi. Слияние ответственно.

## Источники

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io