Облачные вычисления

Регионы, зоны и доступность

Цели урока

  • Понимать иерархию регионов, AZ и Edge Locations
  • Выбирать регион с учётом compliance, latency и стоимости
  • Проектировать Multi-AZ деплой для 99.99% uptime
  • Объяснить, как CDN снижает latency с 150ms до 5ms
  • Рассчитывать теоретический минимум latency по расстоянию

Предварительные знания

  • Virtualization and Containers

YouTube открывается за миллисекунды. Ближайший дата-центр Google - в Финляндии, в 2 000 км. Как YouTube обманывает скорость света? 600+ Edge-серверов, 35+ регионов, архитектура вокруг физических законов Вселенной. Latency - единственная проблема в IT, которую нельзя решить лучшим алгоритмом.

  • **Amazon** подсчитал: +100ms задержки = -1% конверсии. При обороте 500 млрд долларов - это 5 млрд упущенной прибыли в год
  • **Fortnite** (Epic Games) держит серверы в 20+ регионах - ping свыше 80ms делает шутер неиграбельным
  • **GDPR** штрафует до 4% оборота за хранение данных в неправильном регионе - 746 млн долларов штраф Amazon в 2021

Как AWS строил глобальную инфраструктуру

В 2006 году Amazon Web Services запустились с одним регионом - us-east-1 в Вирджинии. К 2010 году появился второй регион в Европе. К 2026 году AWS работает в 30+ регионах и 90+ Availability Zones по всему миру. Каждый новый регион стоит от 1 млрд долларов инвестиций. Решение о размещении принимается исходя из трёх факторов: proximity to customers, compliance requirements, energy availability.

Регионы: география облака

**Region** - географически обособленная область, где облачный провайдер развернул кластер дата-центров. Каждый регион полностью независим: своё электропитание, своя сеть, свои серверы. Падение одного региона не затрагивает другие. В 2021 году аварии в us-east-1 не повлияли на eu-west-1 - именно потому что регионы изолированы.

Регион AWSРасположениеКол-во AZОсобенности
us-east-1Вирджиния, США6Самый старый и дешёвый. Большинство новых сервисов появляются здесь первыми
eu-west-1Ирландия3Популярен для европейских GDPR-compliant приложений
eu-central-1Франкфурт3Немецкий data residency, финансовый сектор
ap-northeast-1Токио4Крупнейший в Азии, низкая латентность для JP/KR
me-south-1Бахрейн3Ближний Восток, compliance для банков региона

**Data residency** - юридическое требование хранить данные граждан в определённой стране. GDPR (Европа) требует, чтобы персональные данные европейцев не покидали ЕС. В 2021 году Amazon получил штраф 746 млн долларов за нарушение GDPR. Выбор региона - не только про latency, но и про закон.

Регион AWSEC2 t3.medium (USD/час)S3 (USD/GB/мес)Разница с us-east-1
us-east-1 (Вирджиния)0.04160.023базовая цена
eu-west-1 (Ирландия)0.04560.024+10%
ap-southeast-1 (Сингапур)0.05200.025+25%
sa-east-1 (Сан-Паулу)0.06800.031+63%
af-south-1 (Кейптаун)0.05720.028+37%

Цены различаются значительно! Один и тот же инстанс в Сан-Паулу стоит на 63% дороже, чем в Вирджинии. Причины: стоимость электричества, налоги, инфраструктура. Если compliance позволяет - выбирать дешёвый регион.

Правило выбора региона: 1. Compliance - куда законы разрешают хранить данные 2. Латентность - ближе к пользователям 3. Доступность сервисов - не все сервисы есть во всех регионах 4. Цена - при прочих равных.

Availability Zones: отказоустойчивость внутри региона

**Availability Zone (AZ)** - один или несколько физических дата-центров внутри региона. AZ изолированы: раздельное электропитание, охлаждение, сетевое подключение. Связаны высокоскоростной сетью с латентностью менее 1ms. В 2017 году падение us-east-1a вывело из строя часть AWS S3. Сайты в одной AZ упали. Multi-AZ сервисы работали без перебоев.

**Multi-AZ** - ключевой паттерн отказоустойчивости. Копии приложения размещаются в нескольких AZ. Если одна AZ выходит из строя - трафик автоматически переключается на оставшиеся. Разница между 99.9% (8.7 часов downtime в год) и 99.99% (52 минуты) - именно Multi-AZ.

КонфигурацияSLA UptimeDowntime/годСтоимость
Single AZ99.9%8.7 часовБазовая
Multi-AZ (2 AZ)99.99%52 минуты+~30-50%
Multi-AZ (3 AZ)99.999%5 минут+~50-80%
Multi-Region99.9999%31 секунда+100-300%

RDS Multi-AZ: AWS автоматически реплицирует базу данных в другую AZ. При сбое основной AZ - failover за 60-120 секунд. Для приложения переключение прозрачно - DNS-имя RDS-инстанса не меняется.

Реальный инцидент (2017): падение us-east-1a на 4 часа вывело из строя часть AWS S3. Сайты, развёрнутые только в одной AZ, были недоступны. Multi-AZ сервисы (Netflix, Airbnb) продолжили работу без перебоев.

Приложение развёрнуто в одной AZ (eu-central-1a). В дата-центре произошёл сбой электропитания. Что произойдёт?

Edge Locations и CDN

**Edge Location** - мини-дата-центр, расположенный максимально близко к конечным пользователям. Задача одна: кешировать контент, чтобы пользователю не ждать ответа от далёкого origin-сервера. Именно так YouTube отдаёт видео за миллисекунды, хотя серверы могут быть за тысячи километров.

**CDN (Content Delivery Network)** - сеть Edge Locations по всему миру. Когда пользователь из Токио запрашивает изображение, CDN отдаёт его с ближайшего Edge Location в Токио, а не с origin-сервера в Вирджинии.

CDN-провайдерКол-во Edge PoPОсобенности
CloudFront (AWS)600+ PoP в 90+ городахГлубокая интеграция с AWS, Lambda@Edge для логики на Edge
Cloudflare310+ PoP в 120+ странахDDoS-защита, Workers для serverless на Edge, бесплатный тариф
Akamai4100+ PoPКрупнейшая CDN, обслуживает 30% мирового трафика
Fastly90+ PoPReal-time кеш-инвалидация за 150ms, VCL для кастомной логики

Lambda@Edge / CloudFlare Workers - позволяют выполнять код прямо на Edge Location. A/B тестирование, персонализация контента, редиректы, авторизация - без запроса к origin. Задержка: 1-5ms вместо 100-300ms.

Что кешировать на CDN: статические файлы (изображения, CSS, JS, шрифты), API-ответы с низкой изменчивостью (список стран, каталог товаров). Что не кешировать: персональные данные, авторизованные запросы, real-time данные.

Cache invalidation - одна из двух самых сложных проблем в CS (Phil Karlton). Обновлено изображение на origin, но CDN отдаёт старую версию? Использовать versioning в URL: `/img/logo-v2.png` или `?v=abc123` - надёжнее, чем ждать TTL.

Сайт с аудиторией в 50 странах хранит изображения в S3 (us-east-1). Пользователи из Азии жалуются на медленную загрузку. Решение?

Латентность: физика vs архитектура

**Латентность** - время, за которое данные проходят от клиента к серверу и обратно (Round-Trip Time, RTT). Нижняя граница - скорость света: ~200 000 км/с в оптоволокне (2/3 скорости в вакууме). Amazon посчитал: каждые 100ms задержки = -1% конверсии. При обороте 500 млрд долларов это 5 млрд потерь в год. Физику не обмануть алгоритмом.

МаршрутРасстояниеТеор. RTTРеальный pingВлияние на UX
Москва → Москва (Edge)~10 км<1ms1-5msМгновенно
Москва → Франкфурт~2 000 км20ms30-50msНезаметно
Москва → Вирджиния~8 000 км80ms120-160msОщутимая задержка
Москва → Сидней~14 500 км145ms250-350msЗаметно тормозит
Москва → Буэнос-Айрес~13 500 км135ms280-400msПлохой UX

Кумулятивный эффект: одна страница грузит 20 ресурсов. Если каждый - отдельный запрос с RTT 150ms, загрузка займёт 3 секунды только на ожидание сети. Amazon: каждые 100ms задержки = -1% конверсии. Google: +500ms загрузки = -20% трафика.

Multi-Region архитектура - единственный способ обеспечить низкую латентность для глобальной аудитории. Netflix, Spotify, Google держат инфраструктуру в 3+ регионах. Route 53 (DNS) направляет пользователя к ближайшему.

Стратегии снижения латентности: 1. CDN для статики 2. Multi-Region для API 3. Database read replicas в каждом регионе 4. HTTP/2 multiplexing - несколько запросов в одном соединении 5. Prefetching - загружать данные до того, как пользователь их запросит.

Одного региона достаточно для глобального приложения - интернет и так быстрый

Скорость света - физический лимит. Для пользователей на другой стороне планеты латентность 200-400ms делает приложение неотзывчивым. Global-приложениям нужен multi-region

Amazon доказал: +100ms латентности = -1% продаж. При обороте 500 млрд долларов это 5 млрд потерь. Netflix, Google, Spotify - все используют multi-region поэтому. Физику не обмануть - нужно приближать серверы к пользователям.

Приложение с серверами в us-east-1 получает жалобы от пользователей в Японии (ping 200ms). Какое решение даст максимальный эффект?

Ключевые идеи

  • Region - независимый кластер дата-центров. Выбор определяется compliance, латентностью и ценой
  • Availability Zone - изолированный дата-центр внутри региона. Multi-AZ = 99.99% uptime
  • Edge Location - кеш контента рядом с пользователем. CDN снижает латентность с 150ms до 5ms
  • Латентность ограничена скоростью света - единственное решение для global apps: multi-region
  • YouTube грузится мгновенно благодаря CDN, multi-region и архитектуре, которая уважает физику

Связанные темы

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

  • Виртуализация и контейнеры — VM и контейнеры работают внутри AZ - предыдущий урок
  • Введение в облачные вычисления — IaaS/PaaS/SaaS модели - фундамент курса

Вопросы для размышления

  • Где находятся основные пользователи текущего проекта? В каком регионе стоят серверы? Оптимальна ли эта конфигурация?
  • Для обеспечения 99.99% uptime банковского приложения - сколько AZ и регионов нужно использовать?
  • Какие данные в проекте подлежат data residency требованиям (GDPR) и как это влияет на выбор региона?

Связанные уроки

  • cloud-01 — IaaS/PaaS/SaaS модели - фундамент курса
  • cloud-02 — VM и контейнеры работают внутри AZ
  • cloud-04 — Сети VPC строятся внутри регионов и AZ
  • devops-03 — DNS-балансировка и CDN - сетевые механизмы на глобальном уровне
  • ds-02 — Multi-region - это AP в CAP-теореме: доступность vs консистентность
  • sec-01 — Data residency и GDPR - compliance-требования к выбору региона
  • net-50-cloud-networking
Регионы, зоны и доступность

0

1

Войти

Финтех-стартап из Берлина обрабатывает данные европейских клиентов. Какой регион выбрать для production?