Основы облачных технологий

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

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

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

Сущность облачной модели вычислений

Переход от локальной инфраструктуры к модели предоставления ресурсов по запросу

Традиционная модель организации вычислительной инфраструктуры предполагает, что организация самостоятельно приобретает, размещает и обслуживает аппаратные ресурсы. Сервер, закупленный для конкретного проекта, физически устанавливается в серверном помещении или центре обработки данных (ЦОД), подключается к сети, настраивается, а затем эксплуатируется на протяжении нескольких лет до момента замены. Этот подход принято обозначать термином «on-premises» (локальное размещение). Его ключевая особенность состоит в том, что ответственность за все уровни инфраструктуры — от электропитания до прикладного программного обеспечения — лежит на самой организации.

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

Важно подчеркнуть, что переход к облаку не сводится к замене физического оборудования виртуальным. Облачная модель меняет саму логику взаимодействия с инфраструктурой. Если при локальном размещении решение о приобретении ресурсов принимается заблаговременно, с учётом прогнозируемой нагрузки, то в облачной среде ресурсы могут быть получены в момент возникновения потребности и возвращены сразу после её удовлетворения. Это различие имеет не только экономические, но и архитектурные следствия: приложения могут проектироваться с расчётом на динамическое изменение объёма доступных ресурсов, а не на фиксированную аппаратную конфигурацию.

Ключевые признаки облачной среды

Для формального определения облачных вычислений в мировой практике принято опираться на характеристики, сформулированные Национальным институтом стандартов и технологий США (National Institute of Standards and Technology, NIST) в специальной публикации NIST SP 800-145 «The NIST Definition of Cloud Computing» (2011) ¹. Документ занимает всего несколько страниц и определяет облачные вычисления как модель, обеспечивающую повсеместный и удобный сетевой доступ по требованию к общему пулу конфигурируемых вычислительных ресурсов (сетей, серверов, хранилищ, приложений, сервисов), которые могут быть быстро выделены и освобождены с минимальными усилиями по управлению и минимальным взаимодействием с поставщиком. Модель NIST состоит из трёх частей: пяти существенных признаков, трёх сервисных моделей и четырёх моделей развертывания. Согласно этому определению, облачная среда обладает пятью существенными признаками.

Первый признак — самообслуживание по требованию (on-demand self-service). Потребитель может самостоятельно выделять вычислительные ресурсы — серверные мощности, хранилища, сетевые компоненты — без необходимости обращения к представителю поставщика. Это означает, что процесс предоставления ресурсов автоматизирован и доступен через программный интерфейс или панель управления.

Второй признак — широкая сетевая доступность (broad network access). Облачные ресурсы доступны через сеть с использованием стандартных протоколов и механизмов доступа. Это позволяет потребителям работать с инфраструктурой из различных сред: рабочих станций, мобильных устройств, удалённых терминалов.

Третий признак — объединение ресурсов (resource pooling). Поставщик объединяет физические ресурсы в общий пул и динамически распределяет их между несколькими потребителями. Конкретный потребитель, как правило, не контролирует и не знает точного физического расположения предоставленных ему ресурсов, хотя может задать ограничения на уровне региона или зоны доступности (эти понятия разобраны ниже, в разделе о распределённости облака).

Четвёртый признак — быстрая эластичность (rapid elasticity). Ресурсы могут масштабироваться — увеличиваться или уменьшаться — в соответствии с текущими потребностями потребителя. С точки зрения пользователя доступные ресурсы кажутся практически неограниченными и могут быть получены в любом объёме в любой момент. Именно эту «иллюзию бесконечных ресурсов» вместе с отсутствием предварительных обязательств и оплатой за краткосрочное использование авторы известного обзора облачных вычислений из Беркли называют главной новизной облака по сравнению с прежними формами аренды ².

Пятый признак — измеряемость потребления (measured service). Облачная система автоматически контролирует и оптимизирует использование ресурсов, предоставляя механизмы мониторинга, отчётности и прозрачного учёта потребления. Это обеспечивает возможность оплаты строго за использованные ресурсы и позволяет обеим сторонам — поставщику и потребителю — контролировать объём предоставленных услуг.

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

Отличие облачных вычислений от традиционного хостинга и классической серверной инфраструктуры

Разграничение облачных вычислений и традиционного хостинга важно не только терминологически, но и практически. Услуги традиционного хостинга — аренда выделенного сервера, виртуального сервера с фиксированной конфигурацией, размещение оборудования в ЦОД — существуют на рынке давно и продолжают использоваться. Однако они, как правило, не обладают свойствами эластичности и автоматического самообслуживания. Арендованный сервер предоставляется в заранее согласованной конфигурации, его масштабирование требует ручного вмешательства или нового договора, а управление осуществляется через ограниченный набор инструментов.

Облачная модель отличается тем, что инфраструктура программно определяема (software-defined). Это означает, что создание, конфигурирование, масштабирование и уничтожение ресурсов осуществляется через программный интерфейс (API), а не посредством физических операций или переговоров с поставщиком. Программная определяемость делает инфраструктуру пригодной для автоматизации: ресурсы могут создаваться и удаляться скриптами, описываться в конфигурационных файлах и управляться как часть программного проекта.

Рассмотрим, как это выглядит на практике. Создание виртуальной машины в AWS сводится к одному вызову программного интерфейса; утилита командной строки AWS CLI формирует HTTPS-запрос RunInstances к конечной точке ec2.eu-central-1.amazonaws.com, подписывает его ключом учётной записи и печатает ответ сервиса ⁷:

aws ec2 run-instances \
  --region eu-central-1 \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --count 1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=demo-web}]'

{
    "ReservationId": "r-0123456789abcdef0",
    "OwnerId": "123456789012",
    "Instances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f67890",
            "InstanceType": "t3.micro",
            "ImageId": "ami-0abcdef1234567890",
            "LaunchTime": "2026-10-22T09:14:03+00:00",
            "Placement": {
                "AvailabilityZone": "eu-central-1b",
                "Tenancy": "default"
            },
            "State": {
                "Code": 0,
                "Name": "pending"
            },
            ...
        }
    ]
}

В этом ответе заметны сразу несколько свойств облачной модели. Ресурс получил идентификатор i-… за доли секунды, без участия человека со стороны поставщика — это самообслуживание по требованию. Состояние pending означает, что вызов асинхронный: API принял заявку и вернул управление, а сама машина будет запущена на одном из физических узлов позже, обычно в пределах минуты; её готовность нужно проверять отдельным запросом (aws ec2 describe-instances). Зону доступности eu-central-1b выбрал поставщик, поскольку запрос её не задавал, — это объединение ресурсов. Освобождение ресурса — такой же вызов:

aws ec2 terminate-instances --region eu-central-1 --instance-ids i-0a1b2c3d4e5f67890

{
    "TerminatingInstances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f67890",
            "CurrentState": { "Code": 32, "Name": "shutting-down" },
            "PreviousState": { "Code": 16, "Name": "running" }
        }
    ]
}

Идентификаторы в примере условные, но структура ответа соответствует документации. Посекундная тарификация начинается с перехода в состояние running и заканчивается после завершения машины, поэтому машина, прожившая десять минут, оплачивается как десять минут (у AWS для Linux-машин — с минимумом в одну минуту). Именно такие вызовы вместо заявок и договоров делают возможной инфраструктуру как код (тема 9), а подпись запроса и права учётной записи, от имени которой он выполнен, подробно рассматриваются в темах 10 и 11.

Ещё одно существенное отличие касается модели тарификации. Традиционный хостинг чаще всего предполагает фиксированную абонентскую плату за заранее определённый объём ресурсов, независимо от фактической загрузки. Облачная модель в типичном случае предполагает оплату по факту потребления (pay-as-you-go): потребитель платит за количество использованных процессорных часов, объём хранимых данных, объём переданного сетевого трафика. Это различие создаёт как преимущества, так и риски, которые подробнее рассматриваются в разделе об экономике облака.

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

Модели предоставления сервисов

Облачная модель вычислений не является однородной. В зависимости от того, какой именно уровень инфраструктуры предоставляется потребителю в виде управляемого сервиса, принято различать несколько моделей обслуживания. Каждая из них определяет границу ответственности между поставщиком облачных услуг и потребителем (эталонная архитектура NIST описывает эти роли подробно и добавляет к ним посредника, оператора связи и аудитора ⁹): чем выше уровень абстракции сервиса, тем меньше задач ложится на потребителя и тем больше контроля он передаёт поставщику.

Инфраструктура как услуга (Infrastructure as a Service, IaaS)

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

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

IaaS является наиболее близкой к традиционной серверной модели формой облачного сервиса. Потребитель работает с виртуальными машинами примерно так же, как с физическими серверами, но получает преимущества облачной модели: эластичность, автоматизируемость и оплату по факту потребления. Примерами IaaS-сервисов являются Amazon EC2, Google Compute Engine, Azure Virtual Machines, Yandex Compute Cloud.

Платформа как услуга (Platform as a Service, PaaS)

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

Практический смысл PaaS состоит в сокращении эксплуатационной нагрузки. Разработчик загружает код приложения, а платформа обеспечивает его исполнение, масштабирование, балансировку нагрузки и базовый мониторинг. Это позволяет существенно ускорить цикл разработки и развертывания, особенно для типовых веб-приложений и сервисов. Однако у этой модели есть и ограничения. PaaS накладывает требования на архитектуру приложения: поддерживаемые языки программирования, среды выполнения, способы хранения данных и механизмы масштабирования определяются поставщиком платформы. Если приложение не вписывается в предложенные рамки, его адаптация может оказаться трудоёмкой или невозможной.

Ещё одним следствием модели PaaS является более выраженная зависимость от поставщика (vendor lock-in). Приложение, спроектированное под конкретную платформу, может использовать специфические интерфейсы, механизмы хранения и способы конфигурации, которые не переносятся напрямую на другие платформы. Поэтому выбор PaaS требует осознанной оценки баланса между удобством и степенью привязки. Примерами PaaS-сервисов являются Google App Engine, Heroku, Azure App Service.

Программное обеспечение как услуга (Software as a Service, SaaS)

Модель SaaS представляет собой наивысший уровень абстракции в классификации облачных сервисов. Потребитель получает доступ к готовому приложению, работающему в облачной инфраструктуре поставщика. Вся ответственность за инфраструктуру, платформу, среду выполнения и само приложение лежит на поставщике. Потребитель использует приложение через веб-интерфейс или API, не занимаясь ни его установкой, ни обновлением, ни обеспечением доступности.

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

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

Производные модели: контейнеры и функции как услуга

Определение NIST ¹ знает только три сервисные модели, однако за прошедшие годы между IaaS и PaaS появились две модели, которые поставщики выделяют как самостоятельные. Обе они отличаются от трёх базовых не уровнем абстракции «вообще», а единицей, которую потребитель передаёт платформе, и единицей, за которую он платит.

Контейнеры как услуга (Containers as a Service, CaaS) — модель, в которой потребитель передаёт платформе образ контейнера и описание желаемого числа экземпляров, а платформа размещает контейнеры на своих узлах, перезапускает их при сбоях и балансирует трафик. Потребитель не администрирует операционную систему узлов, но сохраняет контроль над содержимым образа: языком, библиотеками, версией среды выполнения. Примеры — Amazon ECS с Fargate, Google Cloud Run, управляемые кластеры Kubernetes (Amazon EKS, Google GKE, Yandex Managed Service for Kubernetes). Устройство контейнера рассматривается в теме 3, оркестрация — в теме 7.

Функции как услуга (Function as a Service, FaaS), или бессерверные вычисления (serverless computing), — модель, в которой единицей развертывания является отдельная функция, вызываемая событием: HTTP-запросом, появлением объекта в хранилище, сообщением в очереди. Платформа запускает экземпляр функции при поступлении события и останавливает его после периода бездействия, поэтому при отсутствии запросов потребитель не платит за вычисления совсем ¹⁰. Цена этой модели — холодный старт (первый вызов после простоя ждёт создания экземпляра, от десятков миллисекунд до нескольких секунд), ограничение времени исполнения одного вызова (у AWS Lambda — 15 минут) и отсутствие локального состояния между вызовами: всё, что должно сохраниться, записывается во внешнее хранилище. Примеры — AWS Lambda, Google Cloud Functions, Yandex Cloud Functions.

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

Сравнение моделей

Три базовые модели образуют спектр, на одном конце которого находится максимальный контроль при высокой эксплуатационной нагрузке (IaaS), а на другом — минимальный контроль при минимальной нагрузке (SaaS). PaaS занимает промежуточную позицию.

Выбор модели определяется не абстрактными предпочтениями, а конкретными требованиями. Если организации необходимо полное управление операционной системой и сетевой конфигурацией, IaaS является единственным подходящим вариантом. Если задача сводится к быстрому развертыванию типового приложения, PaaS может оказаться более рациональным выбором. Если потребность состоит в использовании готового продукта без необходимости его сопровождения, SaaS удовлетворяет её наиболее полно.

Важно понимать, что границы между моделями не являются абсолютно жёсткими. Современные облачные платформы предлагают сервисы, которые сочетают признаки нескольких моделей. Например, управляемые базы данных предоставляют инфраструктурный ресурс (хранилище, вычисления), но освобождают потребителя от задач системного администрирования, что сближает их с PaaS. Управляемые сервисы оркестрации контейнеров (такие как Amazon EKS или Google GKE) располагаются на границе IaaS и PaaS. Поэтому классификация моделей полезна как концептуальная рамка, но не должна восприниматься как строгая таксономия с непроницаемыми границами.

Модели развертывания облачной инфраструктуры

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

Публичное облако (public cloud)

Публичное облако представляет собой инфраструктуру, которая принадлежит и управляется сторонним поставщиком облачных услуг и предоставляется широкому кругу потребителей. Физические ресурсы являются общими для множества арендаторов (multi-tenancy), хотя каждый потребитель работает в логически изолированной среде. Публичное облако обеспечивает наибольшую эластичность и наименьшие начальные затраты, поскольку потребителю не требуется приобретать оборудование и содержать инфраструктуру.

К основным преимуществам публичного облака относятся практически неограниченная масштабируемость, глобальная географическая доступность, широкий спектр предоставляемых сервисов и модель оплаты по факту потребления. Крупнейшими поставщиками публичных облачных услуг являются Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), а также региональные провайдеры, такие как Yandex Cloud.

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

Частное облако (private cloud)

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

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

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

Гибридное облако (hybrid cloud)

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

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

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

Общественное облако (community cloud)

Четвёртая модель развертывания в определении NIST — общественное облако (community cloud): инфраструктура, предназначенная для исключительного использования определённым сообществом организаций с общими задачами, требованиями безопасности или нормативными ограничениями ¹. Владеть и управлять ею может одна или несколько организаций сообщества, третья сторона или их сочетание, а размещаться она может как на площадке участников, так и вне её.

Общественное облако занимает промежуточное положение между частным и публичным. От частного его отличает то, что ресурсы разделяются между несколькими независимыми организациями, а от публичного — то, что круг арендаторов закрыт и все они подчиняются общему набору требований. Типичные примеры — государственные облака, доступные только ведомствам и проходящие единую сертификацию (AWS GovCloud, Azure Government), отраслевые облака для медицинских или финансовых организаций, научные вычислительные инфраструктуры, разделяемые университетами. Экономический смысл модели состоит в распределении стоимости соответствия требованиям: аттестацию, аудит и выделенный персонал оплачивает сообщество целиком, а не каждый участник отдельно.

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

Выбор модели развертывания

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

Распределённость облака: регионы, зоны доступности, SLA и теорема CAP

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

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

Регион (region) — географическая область, в которой поставщик размещает группу независимых площадок и в пределах которой ресурсы потребителя связаны между собой быстрой сетью: например, eu-central-1 (Франкфурт) у AWS или ru-central1 у Yandex Cloud. Регионы изолированы друг от друга: отказ одного региона не должен затрагивать другие, и по умолчанию данные из региона не выходят. Поэтому выбор региона определяется расстоянием до пользователей (задержкой), требованиями закона о месте хранения данных и ценой, которая у одного и того же ресурса в разных регионах различается.

Зона доступности (availability zone, AZ) — одна или несколько площадок внутри региона с независимым электропитанием, охлаждением и сетевыми подключениями. Зоны разнесены на километры, чтобы пожар, затопление или отключение подстанции не затронули две зоны сразу, но находятся достаточно близко (у AWS — в пределах 100 км) для того, чтобы задержка между ними составляла единицы миллисекунд ⁵. Такая задержка позволяет синхронно реплицировать данные между зонами, тогда как между регионами, удалёнными на сотни и тысячи километров, синхронная репликация уже заметно замедляет каждую запись.

Список зон региона можно получить тем же программным интерфейсом:

aws ec2 describe-availability-zones --region eu-central-1 \
  --query 'AvailabilityZones[].[ZoneName,ZoneId,State]' --output table

----------------------------------------------------
|             DescribeAvailabilityZones            |
+----------------+-------------+-------------------+
|  eu-central-1a |  euc1-az2   |  available        |
|  eu-central-1b |  euc1-az3   |  available        |
|  eu-central-1c |  euc1-az1   |  available        |
+----------------+-------------+-------------------+

Обратим внимание на два столбца с именами. ZoneName — имя зоны в пространстве учётной записи, ZoneId — идентификатор физической зоны; соответствие между ними может различаться у разных учётных записей ⁵. Это сделано для равномерного распределения нагрузки: если бы все клиенты по умолчанию выбирали физически одну и ту же «зону a», она переполнялась бы первой. Практическое следствие — при согласовании размещения между двумя учётными записями сравнивать нужно ZoneId, а не имена.

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

Соглашение об уровне обслуживания и расчёт допустимого простоя

Соглашение об уровне обслуживания (Service Level Agreement, SLA) — договорное обязательство поставщика обеспечить доступность сервиса не ниже заданной доли времени за расчётный период (обычно календарный месяц) и порядок компенсации при нарушении. Доступность задаётся «девятками», и интуиция плохо работает с ними: разница между 99,9 % и 99,99 % выглядит как десятая доля процента, но в минутах простоя это различие в десять раз.

Допустимое время простоя за период T при доступности A равно (1 - A) \cdot T. Для SLA 99,95 % и месяца из 30 дней (T = 30 \cdot 24 \cdot 60 = 43\,200 минут) допустимый простой в минутах составляет:

(1 - 0{,}9995) \cdot 43\,200 = 0{,}0005 \cdot 43\,200 = 21{,}6

Таким образом, сервис с SLA 99,95 % может быть недоступен около 22 минут в месяц или около 4,4 часа в год, и это не будет нарушением соглашения. Значения для распространённых уровней сведены в таблицу.

Приложение, как правило, зависит от нескольких сервисов сразу, и его доступность меньше доступности каждого из них. Если для обработки запроса необходимы и виртуальная машина с SLA 99,5 %, и управляемая база данных с SLA 99,95 %, а их отказы независимы, то доступность цепочки равна произведению, а простой в минутах за месяц — почти четырём часам:

0{,}995 \cdot 0{,}9995 \approx 0{,}99450, \qquad (1 - 0{,}99450) \cdot 43\,200 \approx 237{,}5

Если же запросы обслуживают две машины в разных зонах и для работы достаточно любой из них, вероятность одновременного отказа обеих равна (1 - 0{,}995)^2 = 0{,}000025, и доступность пары составляет 99,9975 %. Вместе с базой данных получается 0{,}999975 \cdot 0{,}9995 \approx 0{,}99948, то есть около 22,7 минуты простоя в месяц: теперь узким местом стала база данных, а не вычислительный уровень. На практике отказы зон не вполне независимы (общие ошибки обновления, сбои уровня региона), поэтому поставщики дают для размещения в нескольких зонах более скромные обязательства: у AWS для виртуальных машин на момент написания это 99,99 % на уровне региона и 99,5 % для отдельной машины ⁶.

Важно понимать, что именно обещает SLA. Во-первых, поставщик сам определяет, что считается недоступностью: например, отсутствие внешнего сетевого подключения у всех экземпляров в двух и более зонах, а не медленные ответы. Во-вторых, из расчёта исключаются плановые работы и сбои по вине клиента. В-третьих, компенсация выражается в кредитах на оплату — доле месячного счёта за пострадавший сервис, — а не в возмещении убытков потребителя. Поэтому SLA следует рассматривать как нижнюю границу ответственности поставщика, а не как гарантию доступности приложения. Собственные цели по доступности приложения (SLO) и бюджет ошибок рассматриваются в теме 12.

Теорема CAP как следствие распределённости

Чтобы пережить отказ зоны, данные хранятся в нескольких копиях (репликах) на разных площадках. Как только копий больше одной, возникает вопрос: что должна делать система, если связь между площадками пропала, а клиенты продолжают присылать запросы? Теорема CAP, сформулированная Э. Брюером в 2000 году как гипотеза и доказанная С. Гилбертом и Н. Линч в 2002 году ³, утверждает, что распределённая система хранения данных не может одновременно обеспечить три свойства:

• согласованность (consistency, C) — каждое чтение возвращает результат последней завершённой записи, как если бы копия данных была одна;
• доступность (availability, A) — каждый запрос к работающему узлу получает ответ (не ошибку и не бесконечное ожидание);
• устойчивость к разделению (partition tolerance, P) — система продолжает работу, когда сеть теряет сообщения между группами узлов.

Рассмотрим две реплики в зонах a и b и разрыв связи между ними, как показано на рисунке ниже. Клиент в зоне a записывает новое значение, клиент в зоне b его читает. Реплика a не может передать запись реплике b. У системы остаётся ровно два варианта поведения. Первый — отказать в записи или в чтении, пока связь не восстановится: данные остаются согласованными, но часть запросов получает ошибку (выбор CP). Второй — принять запись в a и ответить на чтение в b старым значением: все запросы получают ответ, но клиенты видят разные данные (выбор AP). Третьего варианта нет, поскольку реплика b физически не может узнать о записи, которую до неё не доставила сеть.

Отсюда следует правильное прочтение теоремы. Популярная формулировка «выберите любые два свойства из трёх» вводит в заблуждение: от разделения сети нельзя отказаться, оно происходит независимо от желания проектировщика, поэтому реальный выбор делается только между C и A и только на время разделения ⁴. Пока сеть исправна, система может быть и согласованной, и доступной. Зато и без разделений остаётся компромисс между согласованностью и задержкой: синхронная запись в реплику в другой зоне добавляет к каждой операции время обмена между зонами, а в другом регионе — десятки миллисекунд ⁸.

Облачные сервисы делают этот выбор по-разному, и знание выбора объясняет их поведение. Хранилище etcd, на котором держится состояние Kubernetes, выбирает согласованность: при потере большинства узлов оно перестаёт принимать записи (тема 7). Система DNS выбирает доступность: после изменения записи разные клиенты ещё некоторое время получают старый адрес из кэшей. Объектное хранилище Amazon S3 с 2020 года обеспечивает строгую согласованность чтения после записи внутри региона, а межрегиональная репликация объектов асинхронна (тема 10). Поэтому вопрос «согласована ли эта база» без уточнения «при каком отказе и в каком масштабе — зона, регион» не имеет смысла.

Типичные ошибки интерпретации распределённости

Первая ошибка — считать, что облако само по себе отказоустойчиво. Поставщик обеспечивает независимость зон, но приложение из одной машины в одной зоне так же уязвимо к отказу этой зоны, как сервер в собственной серверной. Отказоустойчивость возникает только тогда, когда сама архитектура использует несколько зон.

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

Третья ошибка — понимать теорему CAP как классификацию продуктов («эта база CP, та AP»). Многие системы позволяют выбирать уровень согласованности для каждого запроса, а одна и та же система ведёт себя по-разному внутри зоны, между зонами и между регионами. Теорема описывает не продукт, а неизбежный выбор в момент разделения сети.

Экономика и эксплуатационные эффекты облака

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

Капитальные и операционные затраты

В традиционной модели организация несёт капитальные затраты (Capital Expenditure, CapEx) на приобретение оборудования. Сервер приобретается единовременно, ставится на баланс и амортизируется в течение нескольких лет. Помимо стоимости самого оборудования, капитальные затраты включают расходы на проектирование серверного помещения, системы охлаждения, электроснабжения и физической безопасности. Эти расходы возникают до момента начала эксплуатации и не зависят от фактического уровня использования ресурсов.

Облачная модель трансформирует капитальные затраты в операционные (Operational Expenditure, OpEx). Потребитель не приобретает оборудование, а оплачивает использование ресурсов на регулярной основе. Это изменение имеет два важных следствия. Во-первых, снижается барьер входа: для запуска проекта не требуется крупных первоначальных инвестиций. Во-вторых, затраты становятся более пропорциональными реальному потреблению, что в теории позволяет избежать оплаты простаивающих ресурсов.

Однако замена CapEx на OpEx не является безусловным преимуществом. При устойчивых и предсказуемых нагрузках облачное размещение может оказаться дороже, чем эксплуатация собственного оборудования. Это связано с тем, что в стоимость облачных ресурсов включена маржа поставщика, затраты на обеспечение избыточности и расходы на программную инфраструктуру платформы. Поэтому экономическая оценка облачной модели должна учитывать не только прямые затраты на ресурсы, но и полную стоимость владения (Total Cost of Ownership, TCO), включающую расходы на персонал, лицензии, сетевой трафик, хранение данных и обеспечение безопасности.

Эластичное выделение ресурсов как инструмент оптимизации затрат

Одним из центральных экономических преимуществ облака является эластичность — возможность динамически изменять объём потребляемых ресурсов в зависимости от текущей нагрузки. В традиционной модели оборудование закупается с расчётом на пиковые нагрузки. Если пиковая нагрузка составляет условные 100 единиц, а средняя — 30, то 70% ёмкости большую часть времени простаивает. Организация платит за полный объём оборудования вне зависимости от того, сколько из него используется.

Эластичность облака позволяет приблизить фактическое потребление ресурсов к текущей потребности. В идеальном сценарии при нагрузке в 30 единиц потребитель оплачивает только 30 единиц, а при кратковременном росте до 100 единиц ресурсы масштабируются автоматически и возвращаются к прежнему уровню после снижения нагрузки. Это снижает избыточное резервирование и позволяет более рационально использовать бюджет.

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

Числовой пример: полная стоимость владения и эффект эластичности

Разберём, при каких условиях облако дешевле собственного оборудования, на условном примере. Веб-сервису в обычное время достаточно трёх экземпляров виртуальной машины, а в течение четырёх пиковых часов в сутки требуется десять. Цены условные (у. е.), но их соотношение типично: экземпляр в облаке стоит 0,20 у. е. в час; собственный сервер, вмещающий четыре таких экземпляра, стоит 6000 у. е. и амортизируется за 36 месяцев, а электропитание, место в стойке и доля работы администратора обходятся в 150 у. е. в месяц на сервер. Чтобы выдержать пик в десять экземпляров, своих серверов нужно три. Расчёт удобно записать короткой программой:

# Сравнение месячной стоимости трёх вариантов размещения (условные единицы, у. е.)
HOURS = 730                      # часов в среднем месяце
PRICE = 0.20                     # цена экземпляра ВМ в облаке, у. е./час
BASE, PEAK, PEAK_H = 3, 10, 4    # экземпляров в обычное время и в пик, пиковых часов в сутки

# Собственное оборудование: 3 сервера по 4 экземпляра (запас под пик 10)
servers, capex, months, opex = 3, 6000, 36, 150
onprem = servers * (capex / months + opex)

static = PEAK * HOURS * PRICE                                  # облако, 10 ВМ круглосуточно
peak_hours = (PEAK - BASE) * PEAK_H * HOURS / 24               # экземпляро-часы пика
elastic = (BASE * HOURS + peak_hours) * PRICE                  # облако с автомасштабированием

avg = (BASE * (24 - PEAK_H) + PEAK * PEAK_H) / 24
print(f"средняя нагрузка: {avg:.2f} экз., загрузка своего оборудования: {avg / (servers * 4):.0%}")
for name, cost in [("собственные серверы", onprem), ("облако, 10 ВМ постоянно", static),
                   ("облако, эластично", elastic)]:
    print(f"{name:26} {cost:8.0f} у. е./мес")

средняя нагрузка: 4.17 экз., загрузка своего оборудования: 35%
собственные серверы             950 у. е./мес
облако, 10 ВМ постоянно        1460 у. е./мес
облако, эластично               608 у. е./мес

Результат содержит главный вывод раздела. Облако, в котором ресурсы выделены «как в своей серверной» — под пик и круглосуточно, — оказалось в полтора раза дороже собственного оборудования, потому что цена облачного часа включает маржу поставщика и его резервы. Облако с автоматическим масштабированием оказалось дешевле обоих вариантов, потому что 65 % ёмкости собственных серверов простаивает, а в облаке простаивающая ёмкость не оплачивается. Если бы нагрузка была постоянной и равнялась десяти экземплярам, эластичности нечего было бы экономить, и выгоднее оказалось бы собственное оборудование. Таким образом, экономию даёт не облако как таковое, а отношение пиковой нагрузки к средней. Реальная оценка полной стоимости владения добавляет к этой модели исходящий трафик, хранение, лицензии, скидки за резервирование ёмкости на год или три и стоимость персонала с обеих сторон.

Риски облачной модели

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

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

Второй риск — зависимость от поставщика (vendor lock-in). Чем глубже организация интегрируется с конкретной облачной платформой, тем труднее перенести нагрузки на другую платформу или вернуть их в собственную инфраструктуру. Зависимость может проявляться на уровне специфических API, форматов данных, механизмов управления и ценовых моделей. Снижение зависимости возможно за счёт использования открытых стандартов, контейнеризации приложений и абстрагирования от платформенно-специфических сервисов, однако полное её устранение на практике достигается редко.

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

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

Итоги темы

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

Модели предоставления сервисов — IaaS, PaaS и SaaS, а также производные от них CaaS и FaaS — образуют спектр от максимального контроля при высокой эксплуатационной нагрузке до минимального контроля при минимальной нагрузке. Выбор модели определяется конкретными требованиями к гибкости, управляемости и степени делегирования ответственности поставщику. Границы между моделями подвижны, а современные облачные платформы предлагают сервисы, сочетающие признаки нескольких уровней.

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

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

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

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

Литература

1. Mell P., Grance T. The NIST Definition of Cloud Computing. — NIST SP 800-145, 2011. https://doi.org/10.6028/NIST.SP.800-145
2. Armbrust M., Fox A., Griffith R., Joseph A. D., Katz R., Konwinski A., Lee G., Patterson D., Rabkin A., Stoica I., Zaharia M. A View of Cloud Computing. — Communications of the ACM, 2010, Vol. 53, No. 4, С. 50–58, DOI: 10.1145/1721654.1721672.
3. Gilbert S., Lynch N. Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. — ACM SIGACT News, 2002, Vol. 33, No. 2, С. 51–59, DOI: 10.1145/564585.564601.
4. Brewer E. CAP Twelve Years Later: How the "Rules" Have Changed. — IEEE Computer, 2012, Vol. 45, No. 2, С. 23–29.
5. AWS Documentation. Regions and Zones (Amazon EC2 User Guide). — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html (дата обращения: 22.10.2026).
6. Amazon Web Services. Amazon Compute Service Level Agreement. — https://aws.amazon.com/compute/sla/ (дата обращения: 22.10.2026).
7. AWS CLI Command Reference. ec2 run-instances. — https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html (дата обращения: 22.10.2026).
8. Kleppmann M. Designing Data-Intensive Applications. — O'Reilly Media, 2017.
9. Liu F., Tong J., Mao J., Bohn R., Messina J., Badger L., Leaf D. NIST Cloud Computing Reference Architecture. — NIST SP 500-292, 2011. https://doi.org/10.6028/NIST.SP.500-292
10. Jonas E., Schleier-Smith J., Sreekanti V., Tsai C.-C., Khandelwal A., Pu Q., Shankar V., Carreira J., Krauth K., Yadwadkar N., Gonzalez J. E., Popa R. A., Stoica I., Patterson D. A. Cloud Programming Simplified: A Berkeley View on Serverless Computing. — arXiv:1902.03383, 2019. https://arxiv.org/abs/1902.03383

Дополнительные материалы

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

1. Какие пять существенных признаков облачной среды называет NIST SP 800-145 и чем совокупность этих признаков отличает облако от аренды виртуального сервера с фиксированной конфигурацией?
2. Что означает программная определяемость инфраструктуры и какие свойства облачной модели видны в ответе на вызов aws ec2 run-instances?
3. Почему вызов создания виртуальной машины возвращает состояние pending, а не running, и что из этого следует для скриптов автоматизации?
4. Как проходит граница ответственности между потребителем и поставщиком в моделях IaaS, PaaS и SaaS?
5. Чем модели CaaS и FaaS отличаются от базовых моделей NIST по единице развертывания и единице тарификации? Какие ограничения накладывает FaaS на код?
6. Чем общественное облако отличается от частного и от публичного? Приведите пример сообщества, для которого эта модель рациональна.
7. Почему одновременное использование частной и публичной инфраструктуры ещё не образует гибридное облако?
8. Чем регион отличается от зоны доступности? Почему зоны разносят на километры, но не дальше определённого расстояния?
9. Почему при согласовании размещения ресурсов между двумя учётными записями AWS следует сравнивать ZoneId, а не ZoneName?
10. Сколько минут простоя в месяц допускает SLA 99,95 %? Как изменится допустимый простой при переходе к 99,99 %?
11. Как рассчитать доступность цепочки из двух сервисов, необходимых для обработки запроса, и доступность пары резервирующих друг друга экземпляров? Почему реальная доступность пары ниже расчётной?
12. Что именно обещает SLA поставщика и почему его нельзя считать гарантией доступности приложения?
13. Сформулируйте теорему CAP. Почему формулировка «выберите любые два свойства из трёх» вводит в заблуждение?
14. В числовом примере темы облако без эластичности оказалось дороже собственных серверов, а облако с автомасштабированием — дешевле. Какой параметр нагрузки определяет этот результат?
15. Какие риски облачной модели связаны с простотой выделения ресурсов и с зависимостью от поставщика?

Глоссарий темы

Шпаргалка по инструментам

# Создать виртуальную машину (асинхронно: ответ придёт в состоянии pending)
aws ec2 run-instances --region eu-central-1 \
  --image-id ami-0abcdef1234567890 --instance-type t3.micro --count 1

# Узнать состояние машины и её зону доступности
aws ec2 describe-instances --region eu-central-1 \
  --instance-ids i-0a1b2c3d4e5f67890 \
  --query 'Reservations[].Instances[].[InstanceId,State.Name,Placement.AvailabilityZone]' \
  --output table

# Освободить ресурс (оплата прекращается после завершения машины)
aws ec2 terminate-instances --region eu-central-1 --instance-ids i-0a1b2c3d4e5f67890

# Перечислить зоны доступности региона: имя в учётной записи и физический идентификатор
aws ec2 describe-availability-zones --region eu-central-1 \
  --query 'AvailabilityZones[].[ZoneName,ZoneId,State]' --output table

# Допустимый простой в минутах за 30-дневный месяц для заданного SLA
python3 -c "a=0.9995; print(round((1-a)*30*24*60, 1), 'мин')"

# Доступность цепочки двух сервисов и пары резервирующих экземпляров
python3 -c "print(0.995*0.9995, 1-(1-0.995)**2)"

Что почитать и посмотреть

1. Mell P., Grance T. The NIST Definition of Cloud Computing (NIST SP 800-145) — https://doi.org/10.6028/NIST.SP.800-145. Первоисточник пяти признаков, трёх сервисных и четырёх моделей развертывания; занимает несколько страниц и читается за полчаса.
2. Armbrust M. et al. A View of Cloud Computing — https://doi.org/10.1145/1721654.1721672. Классический обзор Беркли 2010 года: экономика облака, «иллюзия бесконечных ресурсов» и десять препятствий к распространению облаков.
3. Jonas E. et al. Cloud Programming Simplified: A Berkeley View on Serverless Computing — https://arxiv.org/abs/1902.03383. Продолжение предыдущего обзора девять лет спустя: что такое бессерверные вычисления и каковы их ограничения.
4. AWS Documentation. Regions and Zones — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html. Официальное описание регионов, зон доступности, локальных зон и соответствия имён зон их идентификаторам.
5. AWS Well-Architected Framework, Reliability Pillar — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html. Практическое руководство по проектированию отказоустойчивости с расчётами доступности зависимых и резервированных компонентов.
6. Brewer E. CAP Twelve Years Later: How the "Rules" Have Changed — IEEE Computer, 2012. Автор теоремы объясняет, почему формула «два из трёх» вводит в заблуждение и как системы управляют разделениями.
7. Kleppmann M. Designing Data-Intensive Applications. — O'Reilly Media, 2017. Глава 9 подробно разбирает линеаризуемость, CAP и цену согласованности; лучшее введение в распределённые данные для инженера.
8. Kleppmann M. Please stop calling databases CP or AP — https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html. Короткая статья о том, почему теорема CAP не годится для классификации продуктов.
9. Википедия. Cloud computing — https://en.wikipedia.org/wiki/Cloud_computing. Обзор истории, моделей и поставщиков с большим списком ссылок для дальнейшего чтения.

Углубление (по желанию)

От разделения времени к Amazon Web Services

Идея вычислений как коммунальной услуги старше облаков на полвека. В 1961 году Дж. Маккарти предположил, что вычисления когда-нибудь будут продаваться так же, как электричество или вода. Системы разделения времени 1960-х годов (CTSS, затем Multics) позволяли многим пользователям работать на одной дорогой машине через терминалы, а коммерческие бюро разделения времени продавали машинное время по минутам. Персональные компьютеры и собственные серверы 1980–1990-х годов на время вернули вычисления «в здание» организации.

Возврат к модели услуги произошёл, когда интернет-компании построили огромные однотипные центры обработки данных для собственных нужд и обнаружили, что умеют эксплуатировать их дешевле других. В 2006 году Amazon открыл сервис хранения S3 и сервис виртуальных машин EC2 с почасовой оплатой и программным интерфейсом вместо договора. За ними последовали Google App Engine (2008, модель PaaS) и Microsoft Azure (2010). Технической основой стала виртуализация x86: первые машины EC2 работали под гипервизором Xen с паравиртуализацией, а аппаратная поддержка VT-x, появившаяся в процессорах за год до запуска EC2, стала массовой позже (тема 2).

PACELC: компромисс без разделения сети

Теорема CAP говорит только о поведении системы во время разделения сети. Д. Абади в 2012 году предложил расширение PACELC: если есть разделение (P), система выбирает между доступностью (A) и согласованностью (C); иначе (E, else) — между задержкой (L, latency) и согласованностью (C). Вторая половина формулы описывает повседневную работу: синхронная запись в реплику в другой зоне или регионе добавляет к каждой операции время обмена, и многие системы сознательно отвечают до подтверждения от всех реплик ради скорости. Такая классификация лучше объясняет поведение реальных баз данных, которые большую часть времени работают без разделений.

Лабораторная работа 1. Основы облачных технологий

• Раздел курса: тема 1 «Основы облачных технологий»

Введение

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

Работа опирается на материал темы 1: определение NIST, сервисные модели IaaS, PaaS, SaaS и производные от них CaaS и FaaS, модели развертывания, регионы и зоны доступности, расчёт допустимого простоя по SLA, теорему CAP и экономику облака. Она состоит из пяти частей. Части 1 и 2 — качественный анализ сценария. Часть 3 — количественная проверка интуиции: сначала предсказывается, какой вариант размещения дешевле и надёжнее, затем это проверяется расчётом. Часть 4 — поиск ошибок в готовом проектном решении. Часть 5 сводит результаты в схему целевой инфраструктуры. Части 1–3 и 5 составляют базовую часть работы, часть 4 рекомендуется, но выполняется по желанию.

Цель работы

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

После выполнения работы можно будет:

• выделять в описании сценария характеристики, определяющие выбор модели развертывания: профиль нагрузки, нормативные требования, бюджет, наличие персонала;
• сопоставлять модели IaaS, PaaS, SaaS, CaaS и FaaS применительно к компонентам конкретной системы, а не в общем виде;
• рассчитывать месячную стоимость собственного оборудования, облака с постоянными ресурсами и облака с эластичным масштабированием и объяснять, от чего зависит результат;
• рассчитывать доступность цепочки сервисов по их SLA и допустимое время простоя в минутах;
• находить в проектном решении типичные ошибки: ложную отказоустойчивость, завышенную доступность, «гибридное» облако без интеграции, неверное прочтение теоремы CAP;
• изображать схему инфраструктуры с границами ответственности, регионами и зонами доступности.

Теоретический минимум

Необходимый материал изложен в теме 1: разделы «Сущность облачной модели вычислений», «Модели предоставления сервисов», «Модели развертывания облачной инфраструктуры», «Распределённость облака: регионы, зоны доступности, SLA и теорема CAP», «Экономика и эксплуатационные эффекты облака». Ниже приведена сжатая справка.

Опорные значения доступности: 99 % — 432 минуты простоя в месяц, 99,9 % — 43,2 минуты, 99,95 % — 21,6 минуты, 99,99 % — 4,32 минуты.

Перечень оснащения

• Любая ОС с текстовым редактором для записей (Markdown или офисный редактор).
• Python 3.12 (или любая версия 3.8 и новее) для расчётов в части 3; проверка — python3 --version.
• Редактор схем: diagrams.net (draw.io, работает в браузере без регистрации), Mermaid или бумага и карандаш.
• По желанию — калькуляторы стоимости поставщиков (AWS Pricing Calculator, калькулятор Yandex Cloud) для сравнения условных цен работы с реальными; учётная запись в облаке не требуется.

Порядок выполнения работы

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

Сценарий и параметры расчёта выбираются по варианту. Номер варианта выбирается произвольно (например, по последней цифре года рождения, 0 соответствует варианту 10). Параметры нагрузки: число экземпляров ВМ в обычное время, в пик и длительность пика в часах в сутки; цена — цена одного экземпляра в облаке в у. е. в час; SLA — доступность звеньев цепочки «вычисления — база данных».

Сценарии:

Сценарий A. Стартап из пяти разработчиков запускает веб-приложение для бронирования спортивных площадок. Ожидаемая аудитория — до 10 000 пользователей в первый год. Бюджет на инфраструктуру ограничен, команда не располагает системным администратором. Нагрузка на приложение имеет выраженную суточную и сезонную неравномерность.

Сценарий B. Медицинская организация планирует развернуть систему хранения и обработки результатов лабораторных исследований. Данные содержат персональную медицинскую информацию и подпадают под требования законодательства о защите персональных данных. Объём данных растёт линейно и предсказуемо. Организация располагает собственной серверной инфраструктурой и штатом системных администраторов.

Сценарий C. Образовательное учреждение организует учебную среду для курса по разработке программного обеспечения. Каждому учащемуся необходима изолированная виртуальная машина с предустановленным набором инструментов. Среда используется в течение учебного периода, после чего ресурсы освобождаются. Нагрузка концентрируется в часы занятий и перед контрольными сроками.

Сценарий D. Производственное предприятие с несколькими филиалами внедряет систему мониторинга оборудования. Датчики передают телеметрию в центральное хранилище. Часть данных является коммерческой тайной, но аналитические отчёты должны быть доступны руководителям филиалов через веб-интерфейс. Нагрузка на систему сбора данных стабильна, но нагрузка на аналитический модуль возрастает в периоды подготовки отчётности.

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

Часть 1. Анализ прикладного сценария и выбор модели развертывания

Задание

1. Определите ключевые характеристики сценария: характер нагрузки, требования к безопасности и нормативному соответствию, бюджетные ограничения, наличие технического персонала, предсказуемость роста.
2. Выберите модель развертывания (публичное, частное, гибридное или общественное облако) и обоснуйте выбор. Укажите, какие факторы были решающими и какие альтернативы рассматривались.
3. Если выбрана гибридная модель, опишите, какие компоненты размещаются в публичном сегменте, какие — в частном, каким образом обеспечивается связность между ними и что делает эту конструкцию гибридным облаком, а не параллельным использованием двух сред (единый контур управления, перенос нагрузок, согласованные политики).
4. Укажите ограничения и риски выбранной модели применительно к данному сценарию.
5. Определите, в каком регионе (географически) должны размещаться данные и почему: близость к пользователям, требования закона о месте хранения, цена.

Что должно получиться

Текстовое обоснование объёмом одна–две страницы. В нём каждый вывод опирается на характеристику сценария, а не на общее свойство модели: не «публичное облако эластично», а «нагрузка сценария A в пиковые часы в 3–5 раз выше средней, поэтому эластичность публичного облака даёт прямую экономию». Для сценария B ожидается обсуждение требований к локализации персональных данных; для сценария D — разделение данных на коммерческую тайну и отчёты. Типичное отклонение — выбор гибридной модели «на всякий случай» без описания того, как связаны её сегменты; такой выбор следует пересмотреть.

Часть 2. Сопоставление моделей предоставления сервисов

Задание

1. Для того же сценария заполните сравнительную таблицу по следующим критериям:

2. Для каждого критерия дайте краткую оценку применительно к выбранному сценарию, а не абстрактную характеристику модели.
3. На основании таблицы выберите модель (или сочетание моделей), наиболее подходящую для рассматриваемого сценария. Обоснуйте выбор.
4. Укажите, какие компоненты системы могут использовать разные модели. Например, база данных может быть реализована как управляемый сервис (PaaS), прикладной сервер — как контейнер в CaaS, обработка загруженных файлов — как функция FaaS, а почта для уведомлений — как SaaS.

Что должно получиться

Заполненная таблица и обоснование на одну–две страницы. Хороший результат почти всегда оказывается сочетанием моделей по компонентам, а не одной моделью на всю систему. Для сценария A с командой без администратора ожидается смещение вправо по таблице (PaaS, CaaS, FaaS), для сценария C — IaaS для машин учащихся, поскольку им нужен доступ к ОС. Если для FaaS указана применимость к долгим вычислениям или к компоненту с локальным состоянием, следует сверить это с ограничениями модели из темы 1.

Часть 3. Стоимость и доступность: предсказание и расчёт

Задание

1. Прежде чем считать, запишите в журнал предсказание для своего варианта: какой из трёх вариантов размещения окажется дешевле в месяц — собственные серверы, облако с постоянно работающими экземплярами под пик, облако с эластичным масштабированием? Во сколько раз, по ощущению, отличаются самый дешёвый и самый дорогой?
2. Сохраните программу расчёта в файл cloud_calc.py. Допущения о собственном оборудовании те же, что в теме 1: сервер вмещает четыре экземпляра, стоит 6000 у. е., амортизируется за 36 месяцев и требует 150 у. е. в месяц на эксплуатацию.

# cloud_calc.py — стоимость размещения и доступность цепочки сервисов
import sys

base, peak, peak_h, price = int(sys.argv[1]), int(sys.argv[2]), float(sys.argv[3]), float(sys.argv[4])
HOURS = 730                                   # часов в месяце
SLOTS, CAPEX, MONTHS, OPEX = 4, 6000, 36, 150 # экземпляров на сервер, цена сервера, срок, расходы/мес

servers = -(-peak // SLOTS)                   # округление вверх
onprem = servers * (CAPEX / MONTHS + OPEX)
static = peak * HOURS * price
elastic = (base * HOURS + (peak - base) * peak_h * HOURS / 24) * price
avg = (base * (24 - peak_h) + peak * peak_h) / 24

print(f"серверов: {servers}, средняя загрузка своего оборудования: {avg / (servers * SLOTS):.0%}")
print(f"собственные серверы  {onprem:8.0f} у. е./мес")
print(f"облако постоянно     {static:8.0f} у. е./мес")
print(f"облако эластично     {elastic:8.0f} у. е./мес")

# доступность: остальные аргументы — SLA звеньев цепочки в процентах
a = 1.0
for p in map(float, sys.argv[5:]):
    a *= p / 100
if len(sys.argv) > 5:
    print(f"доступность цепочки: {a:.4%}, простой: {(1 - a) * 30 * 24 * 60:.1f} мин/мес")

3. Запустите расчёт с параметрами своего варианта: число экземпляров обычно, в пик, часы пика, цена, затем SLA звеньев. Для варианта 2:

python3 cloud_calc.py 2 12 6 0.20 99.5 99.9

4. Сравните результат с предсказанием. Объясните расхождение, опираясь на отношение пиковой нагрузки к средней и на загрузку собственного оборудования.
5. Измените один параметр так, чтобы победитель сменился (например, увеличьте число экземпляров в обычное время или длительность пика), и найдите приблизительное пороговое значение. Объясните, что оно означает для сценария.
6. Вычислите вручную доступность вычислительного уровня из двух экземпляров ВМ в разных зонах по формуле 1 - (1 - A)^2, затем доступность всей цепочки вместе с базой данных и допустимый простой в минутах. Какое звено стало узким местом? Что нужно изменить в архитектуре, чтобы цепочка достигла 99,95 %?
7. Для базы данных сценария укажите, что должно происходить при разрыве связи между зонами с её репликами: отказ части запросов (CP) или ответ устаревшими данными (AP). Обоснуйте выбор через последствия для пользователя сценария: что хуже — ошибка или устаревшие данные.

Что должно получиться

Для варианта 2 вывод программы выглядит так (значения получены запуском):

серверов: 3, средняя загрузка своего оборудования: 38%
собственные серверы       950 у. е./мес
облако постоянно         1752 у. е./мес
облако эластично          657 у. е./мес
доступность цепочки: 99.4005%, простой: 259.0 мин/мес

В большинстве вариантов эластичное облако оказывается дешевле всего, а облако с постоянными ресурсами — дороже собственного оборудования. В вариантах с малым отношением пика к обычной нагрузке (варианты 3, 5 и 8) выигрывает собственное оборудование; если предсказание было иным, это и есть главный результат части. Для двух экземпляров с SLA 99,5 % в разных зонах доступность вычислительного уровня составляет 99,9975 %, и узким местом становится база данных. Ответ о CP или AP должен быть разным для разных данных: для бронирования площадки (сценарий A) двойная продажа одного слота хуже кратковременной ошибки, а для отображения графиков телеметрии (сценарий D) устаревшие на несколько секунд данные допустимы.

Часть 4. Поиск ошибок в проектном решении

Эта часть выполняется по желанию. В ней предлагается «сломанное» проектное решение, в котором нужно найти ошибки и предложить исправления.

Задание

1. Прочитайте проектное решение, подготовленное для сценария A:

Приложение размещается в публичном облаке на одной виртуальной машине в зоне ru-central1-a; база данных PostgreSQL установлена на той же машине. Поскольку поставщик обещает SLA 99,95 % для виртуальных машин, приложение будет доступно 99,95 % времени, то есть не более 5 минут простоя в месяц. Резервная копия базы данных хранится на втором диске той же машины. Для отказоустойчивости дополнительно используется гибридное облако: у одного из разработчиков дома стоит сервер с копией кода, на который при сбое можно вручную перенести приложение. Для пользователей из другого региона база данных будет синхронно реплицироваться во второй регион, что обеспечит и строгую согласованность, и прежнюю скорость записи.

2. Найдите в тексте не менее пяти ошибок. Для каждой укажите, какое утверждение темы 1 нарушено.
3. Исправьте решение: опишите архитектуру, которая достигает заявленной цели или честно указывает достижимую доступность, и пересчитайте допустимый простой.

Что должно получиться

Список ошибок с объяснением и исправленное решение. Ожидаемые находки: 99,95 % — это около 22 минут простоя в месяц, а не 5; одна машина в одной зоне не переживает отказа зоны, а SLA поставщика на отдельную машину обычно ниже, чем на размещение в нескольких зонах; база данных на той же машине добавляет в цепочку ещё одно звено отказа; резервная копия на диске той же машины пропадёт вместе с машиной; сервер разработчика без интеграции и автоматического переноса — не гибридное облако; синхронная репликация в другой регион добавляет к каждой записи десятки миллисекунд, поэтому строгая согласованность и прежняя скорость записи несовместимы. Исправленное решение обычно включает два экземпляра в разных зонах за балансировщиком, управляемую базу данных с репликой в другой зоне и резервные копии в объектном хранилище.

Часть 5. Схема целевой инфраструктуры

Задание

1. Изобразите основные компоненты системы: прикладные сервисы, хранилища данных, сетевые границы, точки доступа пользователей.
2. Обозначьте, какая модель предоставления (IaaS, CaaS, PaaS, FaaS, SaaS) используется для каждого компонента.
3. Обозначьте границу ответственности потребителя и поставщика.
4. Покажите регион и зоны доступности, в которых размещаются компоненты, и какие компоненты дублируются между зонами.
5. Если используется гибридная модель, покажите разделение на публичный и частный сегменты и каналы связи между ними.
6. Подготовьте краткое пояснение к схеме (половина–одна страница), в котором опишите логику размещения компонентов и ожидаемые эксплуатационные свойства: масштабируемость, отказоустойчивость (с расчётом доступности из части 3), безопасность.

Что должно получиться

Схема с подписанными элементами и пояснение. Проверить схему можно вопросом: что произойдёт при отказе одной зоны доступности? Если ответ — «приложение недоступно», схема должна либо это честно отражать в расчёте доступности, либо быть доработана.

Журнал работы

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

Контрольные вопросы

1. Перечислите пять существенных признаков облачной среды согласно NIST SP 800-145. Какой из признаков наиболее сложно реализовать на практике и почему?
2. В чём состоит принципиальное отличие облачной модели вычислений от традиционного хостинга?
3. Объясните, как проходит граница ответственности между потребителем и поставщиком в моделях IaaS, CaaS, PaaS, FaaS и SaaS. Почему чем мельче единица развертывания, тем точнее оплата следует за нагрузкой?
4. Приведите пример ситуации, в которой частное облако является более обоснованным выбором, чем публичное, и пример, в котором уместно общественное облако.
5. Что такое зависимость от поставщика (vendor lock-in)? Какие меры позволяют снизить эту зависимость?
6. Объясните различие между капитальными (CapEx) и операционными (OpEx) затратами. Почему в расчёте части 3 облако с постоянными ресурсами оказалось дороже собственного оборудования?
7. Почему эластичность облачной среды является не только инфраструктурным свойством, но и архитектурным требованием к приложению?
8. Чем регион отличается от зоны доступности? Почему синхронная репликация между зонами практична, а между регионами — обычно нет?
9. Сервис с SLA 99,9 % зависит от двух других сервисов с SLA 99,95 %. Какова доступность цепочки и допустимый простой в месяц? Что изменится, если один из сервисов продублировать в двух зонах?
10. Почему формулировка теоремы CAP «выберите любые два свойства из трёх» вводит в заблуждение? Какой выбор на самом деле делает система и когда?
11. Что обещает SLA поставщика и чего он не обещает? Почему компенсация по SLA не защищает бизнес потребителя?