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