← назад к разделу

Сервису понадобился второй сервер — и оказалось, что ждать его три недели: согласовать закупку, дождаться поставки, поставить в стойку, настроить. А нагрузка пришла сегодня. Через полгода серверов стало пять, два из них простаивают, а за место в дата-центре, электричество и администратора платят одинаково — работают они или нет.

Облако решает ровно эту задачу. Мощности берут в аренду по запросу, на минуты и часы, через API: нажали — через полминуты есть машина; отпустили — платить перестали. В этой статье разберём, что именно вы арендуете, из каких элементов собран любой облачный провайдер и где проходит граница вашей ответственности. Остальные статьи раздела — про эти элементы по отдельности, а разделы про AWS, Azure и GCP — про то, как каждый провайдер их называет.

Аренда вместо покупки: что именно вы берёте

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

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

Третий уровень — когда сервера не видно вовсе. Вы отдаёте функцию или контейнер, а провайдер сам решает, где и на скольких машинах его запустить, и гасит их, когда обращений нет. Это называют serverless, «без сервера», хотя серверы, конечно, есть — просто не ваши.

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

Из чего собран любой провайдер

Название сервисов у AWS, Azure и GCP разные, а набор элементов один. Эти семь элементов — план всего раздела.

Учётные записи и права. Прежде чем что-то создать, облако должно знать, кто вы и что вам можно. Людям заводят пользователей, программам — сервисные аккаунты, а права выдают ролями: «читать этот бакет», «запускать машины в этом проекте». Ключ доступа в коде — самый частый источник утечек, поэтому программам на машинах провайдера права выдают без ключей вовсе.

Регионы и зоны доступности. Регион — географическая площадка, скажем, Франкфурт или Стокгольм. Внутри региона несколько зон: отдельные дата-центры со своим питанием и сетью. Ресурсы привязаны к региону, и авария одной зоны не должна задевать соседние — на этом строится вся отказоустойчивость.

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

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

Управляемые данные. База данных, кэш, очередь или брокер сообщений, объектное хранилище для файлов. Провайдер снимает с вас копии, реплики, обновления и замену сломанного узла; дизайн схемы, индексы и идемпотентность потребителей остаются вашими.

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

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

Кто за что отвечает

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

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

Как считают деньги

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

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

Глубже: как провайдер делает зоны независимымирасширенное

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

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

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

Глубже: что переносится между провайдерами, а что нетрасширенное

Один раз разобравшись в элементах, в новом облаке вы ищете не «что тут есть», а «как здесь называется то, что мне нужно». Соответствие для самых частых элементов такое:

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

Глубже: квоты: первая стена нового аккаунтарасширенное

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

Обычные пределы, в которые упираются первыми: ядра виртуальных машин на регион (единицы или десятки у нового аккаунта), публичные адреса (около пяти), частные сети на регион, одновременные выполнения функций, число управляемых баз, объём дисков. Пределы двух видов: мягкие, которые поднимают по заявке, и жёсткие, которые не поднимает никто. Заявка на повышение это форма в консоли (у AWS раздел Service Quotas, у GCP страница Quotas, у Azure Usage and quotas у подписки), и рассматривают её от минут до нескольких дней, поэтому просят заранее, а не в день запуска.

Два места, где квота бьёт не в момент создания, а позже. Автомасштабирование: копии не поднимаются, сервис деградирует под нагрузкой, а в событиях группы масштабирования строка про квоту, которую никто не читает. И аварийное восстановление: план «поднимаем всё во втором регионе» упирается в квоты второго региона, где никогда ничего не создавали, и они на уровне нового аккаунта. Квоты резервного региона поднимают в мирное время и проверяют учениями, о чём статья про отказоустойчивость.

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

Глубже: переезд в облако и обратно: что легко, что тяжело и во что обходится выходрасширенное

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

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

Что переносится легко: всё без состояния (сервисы в контейнерах, балансировщики, конфигурация), всё, что описано кодом инфраструктуры, всё, что говорит по открытым протоколам (PostgreSQL, Redis, Kafka, HTTP-хранилище с протоколом S3). Что тяжело: база данных, потому что данные надо перелить с минимальным простоем (снимок плюс догон изменений средствами репликации или сервисом миграции провайдера), и файлы, потому что терабайты по сети идут неделями и для них провайдеры возят диски физически. Что не переносится: собственные управляемые сервисы провайдера, документные базы с их моделью, функции с их триггерами, конвейеры на его сервисах. Каждая из них это переписывание, и это записывают в цену при выборе.

Во что обходится выход. Исходящий трафик платный: терабайты данных наружу по цене от нескольких центов за гигабайт дают тысячи долларов за сотню терабайт; крупные провайдеры с 2024 года отменяют эту плату при полном уходе, но по заявке и с условиями. Дороже трафика люди: переписывание того, что было привязано к провайдеру, и повторная сертификация безопасности. Поэтому запертость у поставщика это не «плохо» и не «хорошо», а число: сколько месяцев займёт уход. Держать его в разумных пределах помогают открытые протоколы, Kubernetes как слой запуска, PostgreSQL как база и код инфраструктуры, который хотя бы по структуре переносится; а полный отказ от управляемых сервисов «чтобы не привязываться» обычно дороже самой привязки.

Коротко

• Облако — аренда вычислительных мощностей и готовых сервисов по запросу, с оплатой по факту и управлением через API, а не через заявку админу.
• Любой провайдер собран из семи логических элементов: учётные записи и права, регионы и зоны, частная сеть, вычисления трёх уровней, управляемые данные, наблюдаемость с секретами, счёт.
• Граница ответственности описана явно: провайдер отвечает за железо и платформу, вы — за код, данные, права доступа и настройки.
• Чем выше уровень аренды (готовая база вместо своей на машине), тем меньше эксплуатации на вас и тем дороже единица ресурса.
• Платят за всё, что включено, даже когда оно не работает: у остановленной машины остаются платные диски, у забытого балансировщика — часы.
• Между провайдерами переносится модель, а не названия: выучив элементы один раз, в новом облаке вы ищете, как они называются здесь.
• У нового аккаунта малые квоты на ядра, адреса, сети и функции в каждом регионе; их поднимают заявкой заранее, ставят тревогу на 80 % и проверяют в резервном регионе до учений.
• Переезд: без состояния и по открытым протоколам переносится легко, база и файлы тяжело, собственные сервисы провайдера не переносятся; запертость измеряют месяцами ухода, а не избегают любой ценой.

Что почитать дальше

• AWS — те же элементы на языке самого распространённого провайдера, с примерами кода.
• Kubernetes — оркестратор контейнеров, который в облаке берут управляемым.
• Object storage (S3) — объектное хранилище: модель, которая одинакова у всех провайдеров.