Облачные вычисления
Регионы, зоны и доступность
Цели урока
- Понимать иерархию регионов, AZ и Edge Locations
- Выбирать регион с учётом compliance, latency и стоимости
- Проектировать Multi-AZ деплой для 99.99% uptime
- Объяснить, как CDN снижает latency с 150ms до 5ms
- Рассчитывать теоретический минимум latency по расстоянию
Предварительные знания
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, но и про закон.
| Регион AWS | EC2 t3.medium (USD/час) | S3 (USD/GB/мес) | Разница с us-east-1 |
|---|---|---|---|
| us-east-1 (Вирджиния) | 0.0416 | 0.023 | базовая цена |
| eu-west-1 (Ирландия) | 0.0456 | 0.024 | +10% |
| ap-southeast-1 (Сингапур) | 0.0520 | 0.025 | +25% |
| sa-east-1 (Сан-Паулу) | 0.0680 | 0.031 | +63% |
| af-south-1 (Кейптаун) | 0.0572 | 0.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 Uptime | Downtime/год | Стоимость |
|---|---|---|---|
| Single AZ | 99.9% | 8.7 часов | Базовая |
| Multi-AZ (2 AZ) | 99.99% | 52 минуты | +~30-50% |
| Multi-AZ (3 AZ) | 99.999% | 5 минут | +~50-80% |
| Multi-Region | 99.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 |
| Cloudflare | 310+ PoP в 120+ странах | DDoS-защита, Workers для serverless на Edge, бесплатный тариф |
| Akamai | 4100+ PoP | Крупнейшая CDN, обслуживает 30% мирового трафика |
| Fastly | 90+ PoP | Real-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 км | <1ms | 1-5ms | Мгновенно |
| Москва → Франкфурт | ~2 000 км | 20ms | 30-50ms | Незаметно |
| Москва → Вирджиния | ~8 000 км | 80ms | 120-160ms | Ощутимая задержка |
| Москва → Сидней | ~14 500 км | 145ms | 250-350ms | Заметно тормозит |
| Москва → Буэнос-Айрес | ~13 500 км | 135ms | 280-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