Облачная инфраструктура провайдеров

Иерархия физической инфраструктуры

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

Дата-центр (data center) — специализированное здание или помещение, предназначенное для размещения серверного и сетевого оборудования, обеспечивающего хранение, обработку и передачу данных. Дата-центр включает системы электропитания, охлаждения, физической безопасности и резервирования, необходимые для бесперебойной работы IT-инфраструктуры.

Надёжность дата-центров сертифицируется согласно классификации Uptime Institute по уровням Tier I–IV: Tier I обеспечивает минимальную отказоустойчивость без резервирования, а Tier IV — максимальную, с полным резервированием всех систем и расчётным уровнем доступности до 99,995%. Сертификация помогает клиентам оценивать надёжность конкретной площадки при выборе провайдера или проектировании собственной инфраструктуры.

Зона доступности (Availability Zone, AZ) — изолированная часть внутри региона, состоящая из одного или нескольких дата-центров с независимыми источниками питания, охлаждения и сетевыми подключениями. Зоны доступности физически разнесены (обычно на десятки километров) настолько, чтобы авария в одной зоне (отключение электричества, пожар, наводнение) не затронула другие, но при этом достаточно близко, чтобы обеспечивать низкую задержку сети между зонами.

Связь между зонами доступности позволяет строить высокодоступные и отказоустойчивые системы: если одна зона выходит из строя, сервисы могут автоматически переключаться в другую зону того же региона. Именно поэтому в продакшн-архитектурах ресурсы (например, инстансы EC2 или реплики базы данных) размещают минимум в двух зонах доступности — это базовый паттерн отказоустойчивости, к которому мы будем возвращаться в лабораторных работах по Auto Scaling и RDS.

Регион (Region) — согласованно работающая географическая область, объединяющая несколько зон доступности. Каждый регион работает независимо и физически изолирован от других регионов, что обеспечивает локальную обработку данных, соответствие требованиям законодательства и низкие задержки при передаче информации внутри региона.

Набор доступных сервисов может отличаться от региона к региону: новые или специализированные сервисы часто разворачиваются сначала в ограниченном числе регионов (обычно us-east-1 у AWS), а затем постепенно распространяются на остальные. Стоимость одних и тех же услуг также может различаться между регионами из-за разницы в стоимости электроэнергии, земли и локального спроса.

Регион обозначается идентификатором вида us-east-1, ap-southeast-2 или eu-central-1 (первая часть — географическая область, вторая — порядковый номер региона в этой области). Зона доступности обозначается буквой после идентификатора региона: us-east-1a, ap-southeast-2c, eu-central-1b. Поскольку дата-центры внутри одной зоны связаны высокоскоростной сетью, пользователю нет необходимости указывать конкретный дата-центр — минимальная единица выбора для него — зона доступности.

Партишен (partition) — логический сегмент верхнего уровня, объединяющий группу регионов и определяющий границы, внутри которых ресурсы, аккаунты и идентификаторы совместимы друг с другом. У AWS выделяется три партишена:

  • aws — основной партишен, включающий большинство общедоступных регионов по всему миру.
  • aws-cn — партишен для Китая (включает регионы в Пекине и Нинся), требующий отдельной регистрации и соглашения в соответствии с местным законодательством.
  • aws-us-gov — специализированный партишен для государственных организаций США с повышенными требованиями безопасности и ограниченным доступом.

Ключевая особенность партишенов: аккаунты и ресурсы нельзя перенести между партишенами напрямую. Если компания использует AWS в глобальных регионах, а затем решает развернуть сервисы в Китае, ей потребуется создать отдельный аккаунт в китайском партишене — политики IAM и идентификаторы ресурсов (ARN) одного партишена неприменимы в другом.

Edge-инфраструктура: точки присутствия

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

Точка присутствия (Point of Presence, PoP), также называемая edge location, — небольшой узел сети провайдера, размещённый в крупном городе или узле интернет-магистрали, кэширующий часто запрашиваемый контент и обрабатывающий запросы, требующие минимальной задержки. В отличие от регионов, edge-локаций у провайдера на порядок больше (у AWS — сотни edge-локаций против нескольких десятков регионов), поскольку их задача — физическая близость к пользователю, а не размещение полноценных вычислительных мощностей.

Edge-инфраструктура лежит в основе сервисов доставки контента (Content Delivery Network, CDN) — Amazon CloudFront, Google Cloud CDN — которые мы рассмотрим в лабораторной работе по CloudFront: статические файлы (изображения, видео, скрипты) кэшируются в ближайшей к пользователю edge-локации, что снижает задержку загрузки и нагрузку на исходный сервер.

Соответствие терминов между провайдерами

Разные провайдеры используют разную терминологию для описания похожих концепций физической инфраструктуры. Ниже — таблица соответствий, к которой мы будем возвращаться в лекции 3 при сравнении сервисов AWS и GCP.

Концепция AWS Google Cloud Azure
Изолированная географическая область Region Region Region
Отказоустойчивая зона внутри области Availability Zone Zone Availability Zone
Граница биллинга и изоляции ресурсов Account Project Subscription
Логическая группа регионов Partition — (единое глобальное пространство) Cloud (Azure Public/China/Government)
Edge-узел для доставки контента Edge Location (CloudFront) Edge Node (Cloud CDN) Edge Site (Azure CDN)

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

Критерии выбора региона

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

  1. Близость к пользователям (задержка) — регион стоит выбирать географически ближе к основной аудитории сервиса, чтобы минимизировать сетевую задержку; для распределённой аудитории применяется CDN поверх edge-инфраструктуры, а не выбор единственного региона.
  2. Требования резидентности данных (data residency) — законодательство ряда стран требует хранить и обрабатывать определённые категории данных (например, персональные данные) на территории конкретной юрисдикции; это может напрямую диктовать выбор региона независимо от задержки или стоимости.
  3. Доступность необходимых сервисов — не все сервисы провайдера присутствуют во всех регионах, особенно новые или узкоспециализированные (например, отдельные ML-сервисы); перед выбором региона стоит свериться со списком доступных в нём сервисов.
  4. Стоимость — цены на одинаковые ресурсы могут отличаться между регионами на 10–30% и более из-за разницы в локальных издержках провайдера.
  5. Отказоустойчивость и соответствие внутренним требованиям организации — для критичных сервисов часто требуется architecture с несколькими регионами (multi-region) для защиты от отказа целого региона, что усложняет архитектуру, но повышает доступность.

Эти критерии будут напрямую применимы в лабораторных работах: при создании VPC, запуске EC2 и настройке CloudFront вам нужно будет осознанно выбирать регион, а не полагаться на значение по умолчанию.