Что такое облако и зачем оно нужно

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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