Создали базу, а в консоли её нет. Через полчаса выясняется: консоль открыта на Ирландию, а базу создали во Франкфурте, и это не сбой, а устройство облака. Вторая история из той же серии: машина, база и её реплика подняты в одном дата-центре ради минимальной задержки, и авария питания в нём кладёт всё разом, включая «резервную» реплику.
Обе истории про одно: у облака есть география, и её надо учитывать при каждом решении о том, где что создавать. В этой статье разберём, чем регион отличается от зоны, от чего защищает раскладка по зонам, а от чего нет, и по каким соображениям выбирают регион.
Регион это площадка с адресом и ценами, зоны внутри него это отдельные дата-центры с независимым питанием и сетью. Копии по разным зонам переживают отказ одного дата-центра; от отказа всего региона они не защищают.
Регион: площадка, к которой привязано всё
Регион — это город или область, где у провайдера стоят дата-центры: Франкфурт, Стокгольм, Северная Вирджиния, Токио. Почти каждый ресурс создаётся в конкретном регионе и живёт там: машина, диск, база, очередь. Консоль и API тоже работают в контексте региона, поэтому переключатель региона в шапке консоли — первое, что проверяют, когда «ресурс пропал».
Регионы независимы друг от друга намеренно. Данные не копируются между ними сами собой, сети не связаны, права выдаются на ресурсы каждого региона отдельно. Если нужна копия базы в другом регионе — это отдельная настройка и отдельная плата за трафик между регионами. Независимость — цена за то, что авария в одном регионе не тянет за собой другой.
Зона доступности: дата-центр внутри региона
Внутри региона провайдер держит несколько зон доступности. Зона — это физически отдельный дата-центр, а чаще группа зданий: своё электропитание, своё охлаждение, свои каналы связи. Зоны стоят в десятках километров друг от друга, чтобы пожар, авария электросети или порыв кабеля затронули только одну.
При этом зоны одного региона соединены быстрой сетью, и задержка между ними — единицы миллисекунд. Это и делает их удобным строительным блоком: копии сервиса в разных зонах можно поставить за один балансировщик, а реплику базы держать в соседней зоне и переключаться на неё за секунды, а не за часы.
Зоны называют буквами: eu-central-1a, eu-central-1b, eu-central-1c. Одна тонкость, на которой спотыкаются: у разных клиентов буква может означать разные физические здания — провайдер перемешивает их, чтобы все не выбирали «первую». Внутри одного аккаунта буквы стабильны, и этого достаточно.
Как раскладывать копии по зонам
Правило простое: всё, что должно пережить отказ дата-центра, живёт минимум в двух зонах. Копии приложения раскидывают по зонам за балансировщиком, который перестаёт слать трафик в упавшую зону. Управляемую базу берут в конфигурации с резервом в другой зоне: провайдер сам держит реплику и переключает на неё при отказе основного узла. Очереди и объектное хранилище у провайдера обычно устроены так изначально, и делать ничего не надо.
Чего это стоит: трафик между зонами часто платный, а реплика базы удваивает её цену. Поэтому тестовые стенды держат в одной зоне, а боевые сервисы раскладывают по зонам осознанно, по списку того, что должно пережить отказ.
Как выбирают регион
Первое соображение — пользователи. Каждая тысяча километров между ними и сервисом добавляет к задержке примерно десять миллисекунд в одну сторону, и для интерактивного сервиса регион выбирают ближе к аудитории.
Второе — закон. Персональные данные граждан ряда стран обязаны храниться на территории этих стран; европейский регламент ограничивает вывоз данных из ЕС. Это решение принимают до создания первого ресурса: перенести базу в другой регион потом можно, но это миграция с простоем, а не переключатель.
Третье — цена и набор сервисов. Одни и те же машины в разных регионах стоят по-разному, а новые сервисы появляются сначала в крупных регионах. Проверять это стоит заранее: нужный тип базы в выбранном регионе может отсутствовать.
Глубже: от чего зоны не защищаютрасширенное
Управляющий слой облака — тот, что принимает команды через API, ведёт учёт ресурсов и раздаёт права, — общий на весь регион. Часть сервисов работает поверх него. Поэтому раскладка по зонам защищает от отказа дата-центра, но не от отказа самого облака: региональные аварии редки, но случаются, и в этот момент не помогает ни одна зона.
От потери региона защищает только второй регион, и это уже другой класс решения. Данные реплицируются между регионами с задержкой и за деньги, у каждого региона свои адреса и свои права, а переключение пользователей на другой регион требует либо смены DNS, либо глобального балансировщика. Такую схему берут, когда простой стоит дороже удвоенной инфраструктуры: платёжные системы, сервисы с обязательствами по доступности перед клиентами. Для большинства продуктов достаточно двух-трёх зон одного региона и проверенных резервных копий.
Глубже: задержка и трафик между площадкамирасширенное
Внутри зоны запрос между двумя машинами занимает доли миллисекунды, между зонами одного региона — одну-две миллисекунды, между регионами — десятки и сотни. Это определяет, что куда можно разносить. Приложение и его база живут в одном регионе всегда: сотня миллисекунд на каждый запрос к базе убьёт любой сервис. Кэш держат в той же зоне, что и приложение, или мирятся с лишней миллисекундой ради переживаемости зоны.
Трафик считается по направлению: внутри зоны обычно бесплатно, между зонами — по копейкам за гигабайт, между регионами и наружу — заметно дороже. Сервис, который гоняет через границу зон терабайты в сутки, платит за это отдельной строкой, и это одна из причин, почему тяжёлые обмены данными стараются держать в одной зоне.
Глубже: где физически лежат данные: резидентность, 152-ФЗ и свои ключирасширенное
«Второе соображение это закон» из раздела про выбор региона для российского сервиса часто первое и единственное, и стоит разобрать, что именно требуется и как это ограничивает облако.
Резидентность. 152-ФЗ требует, чтобы персональные данные граждан России первично записывались и хранились в базах на территории страны; европейский регламент ограничивает вывоз данных из ЕС. Это не про регион, а про физическое место: регион иностранного провайдера в России отсутствует, поэтому база пользователей российского сервиса живёт у российского провайдера или на своём железе, а иностранное облако получает в лучшем случае обезличенное. Для государственных систем и данных повышенных категорий нужны аттестованные сегменты облака, у которых подтверждён набор мер по требованиям регуляторов, и их предлагают отдельными площадками по другой цене.
Данные уезжают не только базой. Резервные копии в другой регион, реплика для восстановления, логи в общий сервис наблюдаемости, поддержка провайдера с доступом к данным при разборе, кэш в сети доставки контента: каждое из этого может вывезти данные за границу региона, и каждое проверяют отдельно. У провайдеров есть настройки, запрещающие создавать ресурсы вне списка регионов (ограничения организации), и их включают первыми.
Ключи шифрования. По умолчанию данные в облаке шифруются ключами провайдера, и с точки зрения регулятора это шифрование «у него», а не «у вас». Свои ключи (CMK, ключ, которым управляете вы в хранилище ключей провайдера) дают три вещи: ротацию по вашему расписанию, журнал каждого использования и возможность отозвать ключ, после чего данные становятся нечитаемыми для всех, включая провайдера. Стоит это денег за ключ и за операции, и на этом ловятся все, кто включил свой ключ у хранилища с миллионами мелких объектов. Строже этого только ключ вне облака, во внешнем хранилище, к которому провайдер обращается по вашему разрешению; это нужно редко и дорого в эксплуатации.
Практическое правило: место хранения и схема ключей решаются до первого ресурса вместе с юристом, а не подгоняются после; и записываются в журнал данных, где какое поле хранится и кому передаётся, о чём статья про GDPR и 152-ФЗ в разделе безопасности.
Коротко
- Регион — географическая площадка провайдера (Франкфурт, Стокгольм, Вирджиния); ресурсы привязаны к региону, и данные между регионами сами не путешествуют.
- Зона доступности — отдельный дата-центр внутри региона со своим питанием, охлаждением и сетью; в регионе их обычно три и больше.
- Копии сервиса и базы раскладывают по зонам: отказ одного дата-центра тогда не останавливает сервис.
- Раскладка по зонам защищает от отказа дата-центра, но не от отказа облака в регионе: управляющий слой общий, региональные аварии случаются.
- Регион выбирают по трём соображениям: близость к пользователям, требования закона к месту хранения данных, цена и набор сервисов.
- Второй регион — отдельная площадка с отдельными деньгами и сложностью, а не флажок в настройках; его берут, когда потеря региона недопустима.
- Резидентность это физическое место, а не регион: данные граждан России первично хранят в стране, ЕС не вывозят; копии, логи, реплики и поддержка тоже вывозят данные; свои ключи шифрования дают ротацию, журнал и отзыв за деньги.
Что почитать дальше
- Отказоустойчивость и восстановление — как из зон, реплик и копий собирается сервис, который переживает аварии.
- Сеть в облаке — подсети привязаны к зонам, и это влияет на раскладку.
- Регионы и зоны в AWS — как та же модель называется у конкретного провайдера.