10.3 Облака: сервисы, модели, привязка к вендору

Зачем это аналитику

«Уедем в облако» — решение с большими последствиями для стоимости, безопасности, зависимости от поставщика и компетенций команды. Архитектор должен понимать модели облачных услуг, типовые управляемые сервисы и уметь взвесить managed против self-hosted.

Готовность к модулю

Модуль опирается на темы ниже. Если какая-то из них незнакома или её вопросы для самопроверки даются с трудом, начните с неё.

Что понять

Модели: IaaS, PaaS, SaaS, serverless (FaaS) — зона ответственности провайдера и ваша.
Регионы и зоны доступности: что защищает зона, что — регион.
Типовые сервисы: вычисления, объектное хранилище, управляемые базы, очереди, Kubernetes, балансировщики, IAM, KMS.
Управляемый сервис против своего: стоимость владения, компетенции, гибкость, ограничения.
Привязка к вендору: где она оправдана, как снижать (открытые стандарты, абстракции, Kubernetes), и почему полная независимость дорога.
Well-Architected Framework как чек-лист: надёжность, безопасность, стоимость, производительность, операционное совершенство, устойчивое развитие (sustainability).
Serverless: когда уместен, холодный старт, лимиты, стоимость при росте нагрузки.
Российский контекст: локальные облака (Yandex Cloud, VK Cloud, Cloud.ru — бывший SberCloud), требования к хранению персональных данных.

Урок

Облако как экономическое и организационное решение

Переезд в облако часто обсуждают как техническую задачу: перенести виртуальные машины, настроить сеть. На деле это смена модели владения. Вместо покупки серверов раз в несколько лет компания платит за потребление каждый месяц; вместо собственной экспертизы по эксплуатации базы данных — полагается на провайдера; вместо свободы выбора любой версии любого ПО — принимает ограничения платформы. Каждое из этих изменений может быть выгодным или разорительным в зависимости от профиля нагрузки, зрелости команды и регуляторики.

Задача архитектора — не агитировать за облако и не против него, а разложить решение на составляющие: какая модель услуги, какие сервисы брать управляемыми, какой ценой обойдётся независимость от вендора, какие требования к размещению данных действуют.

Модели услуг и разделённая ответственность

Облачные модели различаются тем, где проходит граница ответственности между провайдером и клиентом. Эту идею называют моделью разделённой ответственности (shared responsibility model).

Слой	Своя площадка	IaaS	PaaS	Serverless (FaaS)	SaaS
Физика, сеть ЦОД, питание	Вы	Провайдер	Провайдер	Провайдер	Провайдер
Виртуализация	Вы	Провайдер	Провайдер	Провайдер	Провайдер
ОС, патчи	Вы	Вы	Провайдер	Провайдер	Провайдер
Среда выполнения, СУБД, масштабирование	Вы	Вы	Провайдер	Провайдер	Провайдер
Код приложения	Вы	Вы	Вы	Вы	Провайдер
Данные, доступы, настройки безопасности	Вы	Вы	Вы	Вы	Вы

IaaS (инфраструктура как услуга) — виртуальные машины, диски, сети. Вы получаете «железо по запросу» и сами отвечаете за всё, что выше гипервизора: ОС, обновления, установку СУБД, резервное копирование, мониторинг. Гибкость максимальная, экономия на эксплуатации минимальная.

PaaS (платформа как услуга) — управляемые базы, очереди, платформы для запуска контейнеров или приложений. Провайдер отвечает за ОС, установку, обновления, резервные копии, часто — за отказоустойчивость. Вы отвечаете за схему данных, запросы, параметры, права доступа.

Serverless / FaaS (функции как услуга) — вы загружаете функцию, провайдер запускает её на событие (HTTP-запрос, сообщение в очереди, файл в хранилище) и масштабирует от нуля. Нет серверов, которые нужно держать, оплата обычно за вызовы и время выполнения. Под serverless также понимают шире — любые сервисы без управления мощностями и с оплатой за фактическое использование, например бессерверные базы или очереди.

SaaS (программное обеспечение как услуга) — готовое приложение: почта, CRM, трекер задач. Вы только пользуетесь и настраиваете.

Важно, что нижняя строка таблицы всегда ваша. Даже в SaaS провайдер не отвечает за то, что вы выдали права администратора всем сотрудникам или сделали публичным бакет с выгрузками клиентов. Большинство громких утечек из облаков — ошибки конфигурации на стороне клиента, а не взлом провайдера.

Регионы и зоны доступности

Регион (region) — географическое расположение, в котором провайдер держит несколько дата-центров. Зона доступности (availability zone, AZ) — один или несколько дата-центров внутри региона с независимым питанием, охлаждением и сетью, соединённые с другими зонами региона каналами с низкой задержкой. Зоны разнесены физически, чтобы локальная авария (пожар, отключение питания, повреждение кабеля) не затронула соседнюю зону.

От чего защищает размещение в нескольких зонах:

отказ отдельного сервера, стойки, дата-центра;
локальные сбои питания и сети;
плановые работы провайдера в одной зоне.

От чего не защищает:

Региональные сбои. Ошибка в управляющем слое (control plane) региона, неудачное обновление сервиса провайдера, проблема с региональной сетью затрагивают все зоны сразу.
Логические ошибки. Если приложение или оператор удалил данные, синхронная репликация между зонами аккуратно удалит их везде. От этого защищают резервные копии и восстановление на момент времени, а не зоны.
Ошибки конфигурации. Неверная политика доступа или правило сети применяется ко всем зонам.
Отказ провайдера целиком — редкий, но возможный сценарий, включая юридические и коммерческие причины.

Мультизонное размещение — разумный стандарт для продовых систем: синхронная репликация между зонами возможна благодаря малой задержке, стоимость умеренная. Мультирегион дороже и сложнее из-за задержки между регионами и вопросов согласованности; он рассматривается в модуле 10.4.

Типовые сервисы

Названия у провайдеров разные, но набор базовых строительных блоков похож.

Вычисления. Виртуальные машины, группы автомасштабирования, прерываемые (spot, preemptible) инстансы со скидкой и риском внезапной остановки — подходят для пакетных расчётов вроде ночного пересчёта прогноза.
Объектное хранилище. S3-совместимое хранилище для файлов, выгрузок, резервных копий, данных для аналитики. Почти неограниченный объём, классы хранения с разной ценой и скоростью доступа, политики жизненного цикла. S3-совместимый API фактически стал отраслевым стандартом.
Управляемые базы данных. PostgreSQL, MySQL, Redis, ClickHouse, MongoDB-совместимые и другие. Провайдер берёт на себя установку, обновления минорных версий, резервное копирование, реплики, переключение при отказе.
Очереди и шины. Управляемые очереди сообщений и Kafka-совместимые сервисы.
Управляемый Kubernetes. Провайдер управляет control plane, вы — рабочими узлами и приложениями.
Балансировщики нагрузки. Сетевые (L4) и прикладные (L7), с проверками здоровья и терминацией TLS.
IAM (управление идентификацией и доступом). Пользователи, сервисные аккаунты, роли, политики. Фундамент безопасности в облаке: принцип минимальных привилегий, отдельные сервисные аккаунты для каждого приложения, отсутствие долгоживущих ключей там, где можно без них.
KMS (сервис управления ключами). Хранение ключей шифрования и операции с ними. Позволяет шифровать данные в базах и хранилище ключами, доступ к которым контролируете вы, и журналировать использование ключей.

Управляемый сервис или свой

Классический выбор — управляемый PostgreSQL провайдера или свой кластер на виртуальных машинах (или на своём железе). Сравнивать только счёт за ресурсы бессмысленно; нужно сравнивать полную стоимость владения (total cost of ownership, TCO).

Упрощённая формула для месяца:

TCO_managed = плата за сервис + трафик + хранение копий
TCO_self    = плата за ВМ и диски + трафик + хранение копий
            + часы инженеров на эксплуатацию * ставка
            + доля времени на дежурства и инциденты
            + стоимость риска (вероятность потери данных * ущерб)

Управляемый сервис обычно дороже по строке «ресурсы» — провайдер берёт наценку за эксплуатацию. Но свой кластер требует людей, которые умеют настроить репликацию, автоматическое переключение, резервное копирование с восстановлением на момент времени, мониторинг, обновления. Если в команде нет такого специалиста или он один, риск высок: отпуск или увольнение этого человека становится угрозой данным.

Аргументы за управляемый сервис:

в команде нет глубокой экспертизы по эксплуатации этой технологии;
нагрузка типовая, особые настройки не нужны;
важна скорость запуска, а не тонкая оптимизация;
требуется отказоустойчивость, которую сложно и долго строить самим.

Аргументы за свой:

нужны расширения, версии или параметры, которые провайдер не поддерживает (управляемые сервисы часто ограничивают доступ к суперпользователю, набор расширений, некоторые параметры конфигурации);
большой стабильный объём, при котором наценка провайдера превышает стоимость своей команды;
требования к размещению, которые провайдер не закрывает;
экспертиза уже есть и эксплуатация отлажена.

Разобранный пример: база для сервиса прогноза спроса

Розничная сеть переносит сервис прогноза спроса и автопополнения. Ночью идёт пересчёт прогноза по всем товарам и магазинам, днём — лёгкие запросы от заказов поставщикам. База PostgreSQL среднего размера, используются расширения для секционирования и статистики запросов.

Вопросы, которые задаёт архитектор:

Поддерживает ли управляемый сервис нужные расширения и версию? Если нет — это решающий аргумент.
Какой RPO и RTO требуется? Управляемый сервис обычно даёт восстановление на момент времени в пределах окна хранения и автоматическое переключение на реплику в другой зоне. Своё — нужно строить и регулярно проверять.
Сколько человеко-часов в месяц уйдёт на эксплуатацию своего кластера и есть ли на это люди?
Можно ли разделить нагрузку: ночной пересчёт вынести на прерываемые ВМ, читающие из реплики, а базу держать умеренного размера?

Для такой команды разумный ответ обычно — управляемая база плюс прерываемые вычисления для пакетных расчётов. Свой кластер оправдан, если у компании уже есть DBA-команда, обслуживающая десятки баз.

Привязка к вендору

Привязка к вендору (vendor lock-in) — зависимость, при которой переход к другому провайдеру требует значительных затрат. Она возникает на нескольких уровнях:

API сервисов. Код, написанный под конкретную очередь, функции или базу с проприетарным протоколом.
Данные. Большие объёмы дорого и долго выгружать; плата за исходящий трафик делает выгрузку заметной статьёй затрат.
IAM и сеть. Модель прав и сетевая топология у каждого провайдера своя.
Компетенции. Команда знает инструменты одного облака.
Договор. Скидки за обязательства по объёму потребления на годы вперёд.

Как снижать привязку:

Открытые стандарты и протоколы. PostgreSQL вместо проприетарной базы, S3-совместимый API, Kafka-совместимый протокол, OpenTelemetry для наблюдаемости.
Kubernetes как слой абстракции над вычислениями. Приложение, упакованное в контейнеры и описанное манифестами, переносится проще, чем набор проприетарных функций. Но управляемый Kubernetes всё равно цепляется за балансировщики, хранилище и IAM конкретного облака.
Инфраструктура как код. Terraform работает с разными провайдерами, хотя сами описания ресурсов у каждого провайдера свои — переписывать всё равно придётся, но быстрее, чем кликать заново.
Изоляция зависимостей в коде. Порт и адаптер для хранилища и очереди: бизнес-логика не знает, чей именно сервис под ней.

Почему полная независимость дорога. Чтобы быть по-настоящему переносимым, нужно использовать только общий знаменатель всех провайдеров, отказаться от управляемых сервисов с уникальными возможностями, держать абстракции и тестировать систему на нескольких платформах. Это кратно увеличивает затраты и лишает главного преимущества облака — готовых сервисов. Разумная позиция — осознанная привязка: принимать её там, где сервис даёт большую ценность и заменяется в обозримые сроки, и избегать там, где стоимость выхода непропорционально высока (например, данные и ключевая бизнес-логика). Полезно заранее оценить стоимость выхода (exit cost) и записать её в архитектурное решение.

Well-Architected Framework как чек-лист

Крупные провайдеры публикуют свои своды рекомендаций. Наиболее известный — AWS Well-Architected Framework, у Azure и Google есть аналоги. Независимо от провайдера его удобно использовать как чек-лист из шести столпов:

Столп	Ключевые вопросы
Операционное совершенство (operational excellence)	Как выкатываем изменения, как узнаём о проблемах, есть ли runbook и разбор инцидентов
Безопасность (security)	Минимальные привилегии, шифрование, журналирование доступа, управление секретами
Надёжность (reliability)	Отказ зоны, резервные копии и проверка восстановления, лимиты и квоты, повторные попытки
Эффективность производительности (performance efficiency)	Правильные типы ресурсов, кэширование, масштабирование под нагрузку
Оптимизация стоимости (cost optimization)	Кто владелец затрат, теги, неиспользуемые ресурсы, резервирование мощностей
Устойчивое развитие (sustainability)	Эффективность использования ресурсов, отсутствие простаивающих мощностей

Сила фреймворка не в ответах, а в вопросах: за полчаса он вытаскивает слабые места, о которых команда не думала. Типичные находки — все сервисные аккаунты с правами администратора, резервные копии, восстановление из которых ни разу не проверялось, отсутствие тегов владельца на ресурсах и, как следствие, невозможность понять, кто тратит бюджет.

Serverless: когда уместен

Функции как услуга хорошо подходят для:

нерегулярной или пиковой нагрузки: обработка загруженных файлов, вебхуки, редкие интеграции;
событийной обработки: сообщение в очереди, файл в хранилище, событие по расписанию;
прототипов и внутренних утилит, где важна скорость запуска и нулевая стоимость в простое.

Ограничения, которые нужно учесть:

Холодный старт (cold start). Если функция давно не вызывалась, провайдеру нужно поднять среду выполнения, загрузить код и инициализировать зависимости. Первый запрос получает дополнительную задержку. Она зависит от языка, размера пакета и инициализации; для чувствительных к задержке API это проблема. Некоторые провайдеры позволяют держать заранее подготовленные экземпляры, но за это платят постоянно, что частично убивает экономику.
Лимиты. Максимальное время выполнения одного вызова, объём памяти, размер запроса и ответа, число одновременных экземпляров. Значения зависят от провайдера и меняются, проверять их нужно в документации. Долгий расчёт в функцию не помещается.
Отсутствие состояния. Всё состояние хранится во внешних сервисах. Каждый вызов может открывать соединение с базой, и при масштабировании до сотен экземпляров база получает сотни соединений — нужен пул соединений или прокси.
Наблюдаемость и отладка. Трассировка через цепочку функций сложнее, чем в одном сервисе.

Стоимость при росте нагрузки. Оплата за вызовы и время выполнения выгодна, пока нагрузка низкая или неравномерная: в простое вы не платите ничего. При стабильно высокой нагрузке цена за единицу вычислений у функций выше, чем у постоянно работающего контейнера или ВМ. Есть точка безубыточности: если постоянный сервис загружен большую часть времени, он дешевле. Грубая оценка:

стоимость_FaaS  ≈ число_вызовов * (цена_вызова + длительность * память * цена_единицы)
стоимость_ВМ    ≈ число_ВМ * цена_ВМ_в_месяц (не зависит от числа вызовов до предела мощности)

Сравнивая две функции от нагрузки, находят точку, после которой постоянные мощности выгоднее. Типичный путь — начать на функциях, а стабильно нагруженные части перенести в контейнеры.

Российский контекст

Для российских компаний выбор облака во многом определяется доступностью и регуляторикой. Крупнейшие локальные провайдеры — Yandex Cloud, VK Cloud, Cloud.ru (бывший SberCloud); есть и другие. Набор услуг у них покрывает базовые строительные блоки: виртуальные машины, объектное хранилище с S3-совместимым API, управляемые PostgreSQL и другие базы, Kubernetes, очереди, IAM, KMS. Зрелость и ассортимент отдельных сервисов различаются, их нужно проверять под конкретную задачу, а не переносить ожидания от глобальных облаков.

Ключевое требование — локализация персональных данных (ч. 5 ст. 18 закона 152-ФЗ): при сборе персональных данных граждан РФ их запись, систематизация, накопление, хранение, уточнение и извлечение должны выполняться с использованием баз данных, находящихся на территории России. Последующая трансграничная передача регулируется отдельно и возможна не всегда. Кроме того, существуют требования к защите персональных данных и к информационным системам в отдельных отраслях (финансы, государственный сектор). Детали — какие уровни защищённости нужны, какие сервисы провайдера сертифицированы и для каких классов систем — зависят от конкретной системы и меняются со временем. Правильный путь для аналитика — зафиксировать в требованиях категории обрабатываемых данных, поручить юристам и службе безопасности определить применимые требования и проверить у провайдера документы о соответствии именно для тех сервисов, которые планируется использовать.

Для компаний, работающих на разные юрисдикции, возникает дополнительная развилка: часть данных должна жить в российском облаке, часть — за рубежом, а интеграция между ними должна учитывать ограничения на передачу персональных данных. Это прямо влияет на архитектуру: разделение данных по юрисдикциям, псевдонимизация при передаче, выбор, где выполняется обработка.

Типичные ошибки

Сравнение облака и своей площадки только по цене ресурсов, без стоимости эксплуатации, людей и рисков.
«Перенесли как есть» (lift and shift) все ВМ без пересмотра архитектуры и потом удивляются счёту за постоянно работающие мощности.
Уверенность, что мультизонное размещение защищает от удаления данных или от ошибки конфигурации.
Попытка полной независимости от вендора через самописные абстракции над всем, что в итоге дороже самой привязки.
Serverless для стабильно нагруженного API с жёсткими требованиями к задержке.
Отсутствие владельца затрат и тегов на ресурсах: никто не знает, откуда рост счёта.
Вопросы размещения персональных данных решаются после выбора провайдера, а не до.

Как говорить об этом на собеседовании

На уровне senior от вас ждут не перечисления сервисов, а умения взвешивать. Хороший ответ на «стоит ли уходить в облако» начинается с вопросов: какой профиль нагрузки (стабильный или пиковый), какие компетенции в команде, какие требования к размещению данных, какова стоимость выхода. Упомяните полную стоимость владения, модель разделённой ответственности и то, что облако не снимает ответственности за конфигурацию и доступы.

Про привязку к вендору зрелая позиция — «осознанная привязка с оценённой стоимостью выхода», а не «Kubernetes решает всё». Если есть пример из опыта — как выбирали управляемую базу против своей, какие ограничения всплыли (расширения, параметры, лимиты соединений), как учитывали требования к локализации данных, — это лучше любой теории.

Коротко

Модели IaaS, PaaS, FaaS, SaaS различаются границей ответственности; данные и доступы всегда на вас.
Зоны защищают от локальных аварий, но не от региональных сбоев, логических ошибок и ошибок конфигурации.
Управляемый сервис против своего решается через полную стоимость владения, экспертизу и ограничения, а не через цену ресурсов.
Привязку к вендору снижают открытые стандарты, контейнеры, IaC и изоляция зависимостей; полная независимость обычно не окупается.
Well-Architected Framework полезен как быстрый чек-лист вопросов по шести столпам.
Serverless выгоден при неравномерной нагрузке и дорог при стабильно высокой; холодный старт и лимиты нужно учитывать заранее.
В российском контексте требования к локализации и защите персональных данных определяют выбор провайдера и архитектуру до технических деталей.

Читать дальше

AWS Well-Architected Framework (docs.aws.amazon.com/wellarchitected).
Документация Yandex Cloud — обзор сервисов и архитектурные рекомендации.

На system-design.space:

Практика

Пройти по Well-Architected Framework (сокращённо) для обезличенной системы и найти три слабых места.
Для обезличенной задачи сравнить управляемый PostgreSQL в облаке и свой кластер: стоимость в месяц, трудозатраты, риски.
Сформулировать критерии, по которым вы бы предложили или отговорили заказчика от миграции в облако.

Вопросы для самопроверки

Чем IaaS, PaaS и serverless отличаются по зоне ответственности?
От чего защищает размещение в нескольких зонах доступности, а от чего нет?
Когда стоит брать управляемый сервис, а когда разворачивать своё?
Как снизить привязку к облачному провайдеру и стоит ли это делать?
Когда serverless выгоден, а когда становится дорогим?