Введение в облачные вычисления

От собственной инфраструктуры к облаку

Исторически компании, которым требовались вычислительные мощности, приобретали и обслуживали собственное оборудование: серверы, сетевое оборудование, системы хранения данных, а также помещения для их размещения (on-premise-инфраструктура). Такой подход требовал значительных капитальных затрат (CapEx, Capital Expenditure) ещё до запуска проекта, а также постоянных расходов на обслуживание, электроэнергию, охлаждение и обновление оборудования.

Дополнительная сложность on-premise-подхода — планирование мощностей (capacity planning). Компании приходилось заранее закупать оборудование с запасом под пиковые нагрузки (например, распродажи у интернет-магазина), которое большую часть времени простаивало, либо рисковать нехваткой ресурсов в момент всплеска спроса.

Облачные вычисления (cloud computing) — модель предоставления вычислительных ресурсов (серверов, хранилищ, баз данных, сетей, программного обеспечения) по требованию, через интернет, с оплатой по факту использования, без необходимости владеть физической инфраструктурой.

Ключевой сдвиг, который совершает облако — перевод затрат из капитальных (CapEx) в операционные (OpEx, Operational Expenditure): вместо покупки сервера компания арендует вычислительную мощность и платит только за то время, пока ей пользуется.

Согласно определению NIST (National Institute of Standards and Technology), облачные вычисления характеризуются пятью признаками:

  • Самообслуживание по требованию (on-demand self-service) — пользователь может получить ресурсы (например, запустить сервер) самостоятельно, без обращения к сотруднику провайдера.
  • Широкий сетевой доступ (broad network access) — ресурсы доступны через сеть со стандартных устройств (ноутбук, смартфон) с помощью стандартных протоколов.
  • Объединение ресурсов (resource pooling) — провайдер обслуживает множество клиентов на общей физической инфраструктуре, динамически выделяя и освобождая ресурсы (модель multi-tenancy).
  • Быстрая эластичность (rapid elasticity) — ресурсы могут быть быстро выделены и освобождены, иногда автоматически, в соответствии с изменением нагрузки.
  • Измеримый сервис (measured service) — использование ресурсов отслеживается и измеряется провайдером, что позволяет реализовать оплату по факту потребления (pay-as-you-go).

Модели обслуживания

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

IaaS (Infrastructure as a Service, инфраструктура как услуга) — провайдер предоставляет базовые вычислительные ресурсы (виртуальные серверы, хранилище, сети), а операционную систему, среду выполнения и приложения пользователь настраивает и обслуживает самостоятельно. Пользователь получает максимальный контроль и максимальную ответственность за настройку.

Примеры: Amazon EC2, Google Compute Engine, Amazon VPC, Google Cloud Storage (как «сырой» ресурс хранения).

PaaS (Platform as a Service, платформа как услуга) — провайдер берёт на себя управление операционной системой, средой выполнения и масштабированием, а пользователь загружает только код приложения. Часть гибкости приносится в жертву удобству — не нужно администрировать сервер.

Примеры: AWS Elastic Beanstalk, Google App Engine, Amazon RDS (управляемая база данных, где провайдер отвечает за установку, патчи и резервное копирование СУБД).

SaaS (Software as a Service, программное обеспечение как услуга) — провайдер предоставляет полностью готовое к использованию приложение через браузер или API; пользователь не управляет ни инфраструктурой, ни платформой, а только использует функциональность и настраивает её под себя.

Примеры: Google Workspace (Gmail, Google Docs), Salesforce, Dropbox.

FaaS (Function as a Service, функция как услуга), также называемая serverless-вычислениями — модель, в которой пользователь загружает только код отдельной функции, а провайдер полностью берёт на себя выделение вычислительных ресурсов, масштабирование (включая масштабирование до нуля при отсутствии нагрузки) и оплату исключительно за время фактического выполнения кода.

Примеры: AWS Lambda, Google Cloud Functions.

Удобный способ представить эти модели — сравнить их с уровнями ответственности за «пирог» из инфраструктуры:

Уровень On-premise IaaS PaaS SaaS
Приложения и данные Вы Вы Вы Провайдер
Среда выполнения / runtime Вы Вы Провайдер Провайдер
Операционная система Вы Вы Провайдер Провайдер
Виртуализация Вы Провайдер Провайдер Провайдер
Серверы, хранилище, сеть Вы Провайдер Провайдер Провайдер
Дата-центр (здание, питание, охлаждение) Вы Провайдер Провайдер Провайдер

Чем выше уровень абстракции (от IaaS к SaaS), тем меньше пользователю нужно администрировать, но тем меньше у него и гибкости в настройке.

Модели развёртывания

Помимо модели обслуживания, облачные решения различаются по тому, кто владеет инфраструктурой и кто имеет к ней доступ.

Публичное облако (public cloud) — инфраструктура принадлежит стороннему провайдеру (AWS, GCP, Azure) и используется множеством независимых клиентов на общих физических ресурсах. Наиболее распространённая и экономически эффективная модель.

Приватное облако (private cloud) — инфраструктура выделена для использования одной организацией, может располагаться как на территории организации, так и в дата-центре провайдера. Выбирается компаниями с повышенными требованиями к безопасности, контролю или соответствию нормативным требованиям.

Гибридное облако (hybrid cloud) — сочетание частной и публичной инфраструктуры с возможностью переноса нагрузки между ними (например, критичные данные хранятся в приватном облаке, а пиковые нагрузки обрабатываются в публичном — паттерн cloud bursting).

Мультиоблако (multi-cloud) — одновременное использование сервисов нескольких публичных провайдеров (например, AWS для вычислений и GCP для аналитики данных), обычно для снижения зависимости от одного поставщика или использования лучших сервисов каждого провайдера.

Преимущества и риски облачной модели

Преимущества:

  • Эластичность и масштабируемость — ресурсы можно наращивать и сокращать по требованию, без задержек на закупку оборудования.
  • Оплата по факту использования — снижение начальных инвестиций, перевод расходов из CapEx в OpEx.
  • Глобальный охват — возможность разворачивать сервисы в разных регионах мира за минуты, приближая приложение к пользователям.
  • Скорость экспериментов — команды могут быстро тестировать гипотезы, не дожидаясь закупки инфраструктуры.
  • Управляемые сервисы — провайдер берёт на себя рутинные задачи (патчи, резервное копирование, масштабирование), высвобождая время инженеров для продуктовой работы.

Риски и ограничения:

  • Vendor lock-in (привязка к поставщику) — использование специфичных для провайдера сервисов усложняет и удорожает переход на другого провайдера.
  • Соответствие требованиям законодательства (compliance) — необходимость учитывать требования к месту хранения и обработки данных, например GDPR (Евросоюз) или 152-ФЗ «О персональных данных» (Россия), которые могут ограничивать выбор региона.
  • Контроль над затратами — эластичность облака означает, что при отсутствии контроля расходы могут неожиданно вырасти («cloud bill shock»); требует дисциплины мониторинга затрат (тема лекции 7).
  • Безопасность в модели разделённой ответственности — провайдер отвечает за безопасность облака (инфраструктуры), но клиент отвечает за безопасность в облаке (настройка доступа, шифрование, конфигурация сервисов) — подробнее в лекции 7.
  • Зависимость от сети — работа с облачными ресурсами требует стабильного интернет-соединения.

Роли инженеров в облачных проектах

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

Cloud Engineer / DevOps Engineer — отвечает за проектирование, развёртывание и эксплуатацию инфраструктуры: вычислительные ресурсы, сети, CI/CD, инфраструктура как код (Terraform), мониторинг и обеспечение отказоустойчивости приложений.

Data Engineer — строит инфраструктуру для сбора, хранения, преобразования и доставки данных: пайплайны ETL/ELT, потоковую обработку, хранилища данных (data warehouse) и озёра данных (data lake), обеспечивая данные для аналитики и моделей.

Data Scientist / ML Engineer — использует данные, подготовленные Data Engineer-ами, для построения, обучения и развёртывания моделей машинного обучения, применяя облачные ML-платформы (SageMaker, Vertex AI) для масштабирования вычислений и вывода моделей в продакшн.

На практике эти роли пересекаются и работают в одной облачной экосистеме: то, что для DevOps-инженера — виртуальная машина для запуска сервиса, для Data Engineer-а может быть узлом Spark-кластера для обработки данных, а для Data Scientist-а — средой для обучения модели. Понимание общей инфраструктуры (регионы, сети, хранилище, IAM), которое даёт этот курс, — общий фундамент для всех трёх ролей.