Облака: устройство и модели

Проект ЦИТадель

Слово «облако» затёрто маркетингом до полной прозрачности: им называют всё — от аренды виртуалки до почты в браузере. Эта статья — теоретическая: что такое облако технически, из чего оно собрано, что означают модели IaaS/PaaS/SaaS и границы ответственности, какие свойства облака действительно меняют архитектуру систем, а какие — только счёт. Парная статья «Облака на практике» посвящена выбору, миграции и экономике. Здесь нас интересуют устройство и принципы, переживающие смену поколений провайдеров; конкретные вендоры упоминаются только как иллюстрации.

В определении NIST у облака пять существенных характеристик: самообслуживание по требованию, доступ по сети, общий пул ресурсов, быстрая эластичность и измеряемый сервис. API — обычный способ реализовать самообслуживание и программируемость, но само определение им не ограничивается. Каждое слово несёт вес: ресурсы объединены и динамически распределяются между потребителями; их можно получить без переговоров с сотрудником провайдера; объём можно быстро менять; потребление измеряется. Тезис статьи, из которого выводится остальное: облако — это инфраструктура, ставшая программируемой. Не просто «чужие серверы», а ресурсы, доступные как сервис.

1. Из чего собрано облако

Под API-фасадом — три программных слоя поверх обычных дата-центров:

• Виртуализация вычислений. Гипервизор — KVM, Hyper-V или собственная технология провайдера — разделяет физические серверы между ВМ; часть сервисов работает и на выделенном физическом оборудовании. Читатели статьи о контейнерах узнают спектр изоляции: у ВМ своё ядро, а границей служит гипервизор. Это важно в многоарендной среде, где на одном сервере могут работать нагрузки разных клиентов. Лёгкие микро-ВМ, например Firecracker, применяются в некоторых serverless- и контейнерных платформах, но не являются обязательной основой serverless.
• Программно-определяемые сети. Виртуальная частная сеть в облаке (VPC) — логическая сеть поверх общей физической инфраструктуры. Инкапсуляция и распределённые правила обеспечивают изоляцию арендаторов, собственные адресные планы, программируемые маршруты и сетевые экраны; детали реализации зависят от провайдера.
• Распределённые хранилища. Три жанра с разной физикой: блочное (виртуальные диски ВМ и локальные диски узла), файловое (сетевые файловые системы) и один из основных облачных примитивов — объектное (пространство «ключ → объект» с доступом по HTTP, вошедшее в отраслевой язык как S3-совместимое). Сетевые диски обычно реплицируются, а локальные могут исчезнуть вместе с узлом; точные гарантии нужно читать в описании конкретного сервиса. Объектные хранилища хорошо масштабируются, но не дают всей семантики файловой системы. Их модели согласованности различаются: например, Amazon S3 гарантирует строгую согласованность операций с объектами и листинга, а другие реализации задают собственные гарантии. Совместимость с S3 API сама по себе ничего не говорит о согласованности реализации.

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

2. География: регионы и зоны

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

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

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

3. Модели обслуживания: лестница ответственности

Классическая триада — это не «три продукта», а уровни разделения труда между вами и провайдером:

• IaaS — вам дают виртуальные машины, сети, диски; ОС и всё выше — ваше. Максимум контроля, максимум эксплуатации: обновления, резервное копирование, отказоустойчивость — на вас.
• PaaS / managed-сервисы — вам дают работающие компоненты: базу данных, Kubernetes с обслуживаемым управляющим слоем, брокер, кэш. Репликация, резервные копии и обновления зависят от сервиса и настроек: их по-прежнему нужно выбрать и проверить. Ваши задачи — код, данные, доступы и конфигурация. По сути это «операторы за деньги»: часть действий, которые оператор PostgreSQL из статьи о Kubernetes выполняет программно, здесь берёт на себя провайдер; выбор «managed или самим» остаётся выбором «покупать или эксплуатировать».
• SaaS — готовое приложение (почта, CRM, трекер). Провайдер эксплуатирует его, а клиент по-прежнему управляет пользователями, доступом, своими данными, настройками и допустимыми способами использования.
• Serverless, частным случаем которого служит FaaS, заслуживает отдельной строки, потому что меняет модель программирования, а не только эксплуатации: вы отдаёте функции или контейнеры, платформа запускает их по событиям и масштабирует в пределах квот и возможностей сервиса. Реализация может использовать процессы, контейнеры или микро-ВМ. Плата за удобство: холодный старт, ограничения времени и ресурсов, привязка к событийной модели платформы и тарификация, требующая внимательного расчёта. Модель уместна для событийной, всплесковой и связующей логики; для постоянно нагруженного сервиса её нужно сравнивать с другими вариантами по стоимости и ограничениям.

Полезный критерий выбора уровня — вопрос из статьи о Kubernetes, работающий и здесь: что вы готовы эксплуатировать сами и зачем? Каждая ступень вниз по лестнице (SaaS → PaaS → IaaS) покупает контроль ценой эксплуатационной нагрузки; движение без ответа на «зачем» — в обе стороны ошибка.

4. Разделённая ответственность

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

5. Экономика: за что на самом деле платят

Без разговора о деньгах теория неполна. Классический аргумент «CAPEX → OPEX» — не покупать оборудование, а платить за сервис — верен, но главный экономический смысл облака тоньше: эластичность позволяет оплачивать пик только во время пика. При неровной нагрузке собственное оборудование, купленное под максимум, часть времени простаивает, а облачные ресурсы можно выделять по кривой нагрузки. При стабильной круглосуточной загрузке своё оборудование или колокация иногда дешевле, но сравнивать нужно полную стоимость: оборудование, помещения, электроэнергию, сеть, персонал, резервирование и риск нехватки мощности. Между полюсами — скидки за обязательство по сроку или объёму и спот-мощности, которые провайдер может отозвать и потому годятся только для прерываемой работы. При переезде часто недооценивают исходящий и межзонный трафик, запросы к сервисам и надбавку за managed-возможности; правила бесплатного входящего трафика и тарификации выхода зависят от провайдера и маршрута. Управление этими затратами выросло в отдельную практику FinOps, которую разбирает практическая статья.

6. Что облако меняет в архитектуре

Если бы облако было только арендой серверов, статья бы здесь закончилась. Но программируемость инфраструктуры меняет способ строить системы:

• Заменяемость экземпляров. Если экземпляр создаётся через API из образа и декларации, его можно восстанавливать заменой, а не ручным ремонтом уникальной машины. Для этого постоянное состояние хранят отдельно — например, в базе данных, сетевом диске или объектном хранилище, — проверяют готовность нового экземпляра и автоматизируют его включение в работу. На этом же свойстве строится автомасштабирование, когда оно действительно нужно нагрузке.
• Инфраструктура как код. Программируемое конфигурируется текстом: описание инфраструктуры — сетей, машин, баз и прав — хранится в репозитории и применяется инструментом с ревью, историей и воспроизводимым процессом. Идея декларативного желаемого состояния из Kubernetes поднимается на уровень всей инфраструктуры; подробности — в статье «Инфраструктура как код».
• Компоненты со свойствами по каталогу. Очередь приносит с собой определённую семантику доставки, объектное хранилище — свою модель согласованности, managed-БД — режимы переключения при отказе. Архитектор собирает систему из компонентов с задокументированными распределёнными свойствами, и словарь нашего курса — модели согласованности, семантики доставки, поведение при отказе зоны — превращается в язык чтения облачной документации.

7. Когда облако — и когда нет

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

8. Мини-практикум: облачный примитив на своей машине

Объектное хранилище можно исследовать локально на SeaweedFS — распределённом хранилище с S3-совместимым API. Команда ниже запускает его упрощённый однодисковый режим mini: все службы и данные находятся в одном контейнере, поэтому этот опыт не даёт отказоустойчивости. Сначала установите AWS CLI, затем выполните:

$ docker volume create citadel-seaweed-data
$ docker run -d --name citadel-seaweed \
    -p 127.0.0.1:8333:8333 \
    -e AWS_ACCESS_KEY_ID=citadel-lab \
    -e AWS_SECRET_ACCESS_KEY=citadel-lab-password \
    -e S3_BUCKET=demo \
    -v citadel-seaweed-data:/data \
    chrislusf/seaweedfs:4.41
$ export AWS_ACCESS_KEY_ID=citadel-lab
$ export AWS_SECRET_ACCESS_KEY=citadel-lab-password
$ export AWS_DEFAULT_REGION=us-east-1
$ printf 'hello\n' | aws --endpoint-url http://127.0.0.1:8333 \
    s3 cp - s3://demo/greeting.txt
$ aws --endpoint-url http://127.0.0.1:8333 s3 ls s3://demo/
$ aws --endpoint-url http://127.0.0.1:8333 \
    s3 cp s3://demo/greeting.txt -

Учётные данные в примере предназначены только для локального опыта. В следующих командах сохраняйте перед подкомандой s3 или s3api параметр --endpoint-url http://127.0.0.1:8333.

1. Ключи и версии. Включите версии командой aws --endpoint-url http://127.0.0.1:8333 s3api put-bucket-versioning --bucket demo --versioning-configuration Status=Enabled. Создайте объект folder/greeting.txt и «переименуйте» его командой s3 mv. Команда s3api list-object-versions должна показать версию нового ключа и маркер удаления старого: привычное переименование здесь составлено из копирования и удаления. Дважды перезапишите новый объект, выберите прежний идентификатор версии и восстановите содержимое командой s3api get-object --bucket demo --key folder/renamed.txt --version-id VERSION_ID previous.txt.
2. Согласованность. Сто раз запишите объект под одним ключом; после каждой записи немедленно прочитайте его и выполните листинг по этому ключу. Разделите вывод на две части: что вы наблюдали и что обещает документация реализации. Успешный опыт не превращается в гарантию. Сформулируйте результат терминами главы 4 нашего курса.
3. Временный доступ. Получите ссылку командой aws --endpoint-url http://127.0.0.1:8333 s3 presign s3://demo/greeting.txt --expires-in 300, откройте её без учётных данных, а через пять минут проверьте отказ. Объясните, почему предподписанная ссылка является временным правом доступа к конкретной операции, а не просто адресом объекта.
4. Отказ процесса (дополнительное задание). Остановите единственный контейнер и зафиксируйте полную недоступность: распределённая программа без реплик ещё не образует отказоустойчивую систему. Затем по описанию репликации SeaweedFS спроектируйте конфигурацию с отдельными master-, filer/S3- и двумя volume-серверами, выбрав для данных схему 001. Запишите гипотезу до опыта: после потери одного volume-сервера ранее записанный объект доступен через оставшуюся копию, но новая запись, требующая двух копий, завершиться не должна. Проверьте чтение и запись, а после возврата сервера — состояние репликации: SeaweedFS не восстанавливает недостающие копии автоматически. Несколько контейнеров на одном компьютере позволяют исследовать отказ процесса, но не отказ физического узла или зоны.

Итоги

• Облако сочетает самообслуживание по требованию, сетевой доступ, общий пул ресурсов, эластичность и измеряемое потребление; его инфраструктура программируема.
• Устройство: виртуализация, программные сети, три жанра хранилищ и слой оркестрации; облачная платформа опирается и на программные, и на аппаратные решения.
• Зона и регион — домены отказа разного масштаба, но их гарантии зависят от провайдера и сервиса; доступность и восстановление требуют явной архитектуры, а не только выбора размещения.
• IaaS/PaaS/SaaS/FaaS — лестница разделения труда; критерий уровня — «что готовы эксплуатировать сами и зачем»; managed-сервис = оператор за деньги.
• Ответственность разделена: провайдер отвечает за нижние слои сервиса, клиент — за своё использование; решения о данных, доступах и требуемой отказоустойчивости нужно принимать и проверять явно.
• Экономика: эластичность позволяет оплачивать пик во время пика; ровную нагрузку сравнивают по полной стоимости владения; трафик и managed-надбавки часто недооценивают.
• Архитектурно облако приносит заменяемость экземпляров, инфраструктуру как код и компоненты с задокументированными распределёнными свойствами — словарь нашего курса становится языком чтения облачной документации.

Литература

1. NIST SP 800-145, "The NIST Definition of Cloud Computing," 2011 — определение пяти существенных характеристик и моделей обслуживания.
2. L. A. Barroso, U. Hölzle, P. Ranganathan, "The Datacenter as a Computer," 3rd ed., Morgan & Claypool, 2018 — как устроены гиперскейлеры изнутри; свободно доступна.
3. Архитектурные своды провайдеров (Well-Architected и аналоги) — вендорские, но концептуальные разделы (надёжность, стоимость) полезны безотносительно вендора.
4. Материалы нашего раздела: «Контейнеры: устройство и экосистема», «Kubernetes: идея и устройство», курс «Распределённые системы» — гл. 1 (домены отказов) и гл. 4–5 (согласованность и репликация).