Облачные вычисления
EC2 и виртуальные машины
2006 год, 18 марта. Amazon запускает EC2 в beta. Первый instance type: m1.small - 1 vCPU, 1.7GB RAM, $0.10/час. До этого запуск собственного сервера стоил $2000-5000 и 2-8 недель ожидания поставки. Через 3 года Netflix начинает миграцию с собственных data centers. К 2016 Netflix полностью в AWS, управляя тысячами EC2 instances как программным кодом. Идея 'купи столько вычислений сколько нужно прямо сейчас' изменила индустрию.
- **Airbnb** в праздники масштабирует fleet с 200 до 2000+ instances за часы через Auto Scaling Groups - без EC2 потребовались бы месяцы procurement
- **Netflix** использует Spot instances для encoding видео - 70% savings, при interruption encoding job перезапускается с checkpoint
- **Stripe** держит baseline на Reserved Instances (3yr, all upfront) - экономия 72% на предсказуемой payment processing нагрузке
Andy Jassy и рождение AWS EC2
Идея EC2 возникла из внутренней боли Amazon: каждая команда тратила недели на provisioning серверов под новые проекты. Chris Pinkham (VP Infrastructure) и команда в Кейптауне разработали систему виртуализации на базе Xen гипервизора. Andy Jassy (тогда VP AWS) продвинул идею как внешний сервис. Beta-запуск в марте 2006, публичный в 2008. Первый крупный клиент - Smugmug (2007), сэкономил $500K в год. Netflix начал миграцию в 2008. К 2023 AWS EC2 генерирует $40+ млрд выручки в год и является крупнейшим провайдером облачных вычислений с долей рынка ~32%.
Instance Types
**EC2 (Elastic Compute Cloud)** - вычислительный сервис AWS, предоставляющий виртуальные машины по требованию. Виртуализация: AWS использует собственный гипервизор Nitro (с 2017), ранее Xen. Каждый instance type - фиксированная комбинация vCPU, RAM, сети и хранилища, оптимизированная под конкретные workloads.
| Семейство | Оптимизировано под | Примеры | Типичное применение |
|---|---|---|---|
| t3/t4g | Общего назначения, burstable | t3.micro (2vCPU, 1GB) | Dev/test, малый трафик, CI runners |
| m6i/m7i | Balanced CPU+RAM | m6i.xlarge (4vCPU, 16GB) | Application servers, microservices |
| c6i/c7g | Compute-optimized | c6i.2xlarge (8vCPU, 16GB) | Video encoding, ML inference, HFT |
| r6i/r7i | Memory-optimized | r6i.2xlarge (8vCPU, 64GB) | In-memory databases, Redis, SAP HANA |
| p4d/p5 | GPU | p4d.24xlarge (96vCPU, 8 A100 GPU) | ML training, rendering |
| i3/i4i | Storage-optimized (NVMe) | i3.4xlarge (16vCPU, 122GB, 2x1.9TB NVMe) | Cassandra, Elasticsearch, OLAP |
**Burstable instances (t3/t4g)**: накапливают CPU credits в периоды низкой нагрузки, расходуют при пиках. При исчерпании credits производительность падает до baseline (20-30% vCPU). Режим `unlimited` позволяет уходить в минус credits за доплату. Для production приложений с предсказуемой нагрузкой - лучше фиксированные m-series.
ML-команда обучает нейронные сети. Какое семейство EC2 instance types оптимально?
AMI - Amazon Machine Image
**AMI (Amazon Machine Image)** - шаблон для создания EC2 instance: root volume snapshot + launch permissions + block device mapping. Аналог Docker image, но для виртуальных машин. AMI привязана к региону (для мультирегиональных deployments - копировать).
| Тип AMI | Кто создаёт | Пример использования |
|---|---|---|
| AWS官方 (owned by amazon) | AWS | Amazon Linux, Ubuntu, Windows Server |
| Community (owned by public) | Сообщество | Специализированные конфигурации |
| AWS Marketplace | ISV вендоры | Fortinet NGFW, Bitnami стеки |
| Private (аккаунт) | Команда | Golden image с предустановленным ПО |
**Golden AMI паттерн**: создать базовый AMI с предустановленным агентами (CloudWatch, SSM, антивирус), application runtime и hardening (CIS Benchmark). Auto Scaling запускает instances из golden AMI - startup time 30-60 сек вместо 5+ минут при bootstrap скриптах.
AMI создана в us-east-1. Команда хочет запустить instance в eu-west-1. Что нужно сделать?
Spot Instances
**Spot Instances** - аукцион на неиспользуемые EC2 ресурсы AWS. Скидка 70-90% от On-Demand цены. Catch: AWS может прервать instance с предупреждением за 2 минуты (Spot interruption) когда ресурсы понадобятся On-Demand клиентам. Interruption rate зависит от instance type и региона - обычно 5-15% в месяц.
| Workload | Spot подходит? | Почему |
|---|---|---|
| ML training (checkpoint) | Да | Checkpoint каждые N батчей, resume при interruption |
| Batch video encoding | Да | Stateless задачи из SQS, retry при interruption |
| Stateful production API | Нет | Interruption = downtime для пользователей |
| CI/CD runners | Да | Failed build автоматически перезапускается |
| Database master | Нет | Потеря данных при interruption без persistent volume |
| Kubernetes worker nodes | Да | Karpenter автоматически replaces interrupted nodes |
ML pipeline обучает модель 8 часов на Spot instance. Instance прерван через 3 часа. Как минимизировать потери?
Reserved и Savings Plans
**Reserved Instances и Savings Plans** - механизм скидки за commitment: обязательство платить за вычислительные ресурсы 1 или 3 года в обмен на скидку 30-72% от On-Demand. Savings Plans (новее) - более гибкий вариант: commitment по сумме расходов в $/час, а не по конкретному instance type.
| Тип | Скидка | Гибкость | Когда выбирать |
|---|---|---|---|
| On-Demand | 0% | Полная | Непредсказуемая нагрузка, тестирование |
| Spot | 70-90% | Прерываемые | Batch, ML, stateless, fault-tolerant |
| Savings Plans (Compute) | 66% | Высокая (любой instance type/region) | Baseline stable нагрузка, flexibilty важна |
| Standard RI (1yr) | 40% | Средняя (фиксированный type) | Стабильная нагрузка, известный instance type |
| Standard RI (3yr, all upfront) | 72% | Низкая | Зрелая infrastructure, долгосрочный commitment |
**Unused RI/SP проблема**: commitment продолжает списываться даже если instance не запущен. Перед покупкой RI на 3 года - убедиться через Cost Explorer что утилизация baseline стабильна 6+ месяцев. Продажа неиспользуемых RI на AWS Marketplace возможна, но с дисконтом.
Reserved Instances нужно покупать сразу при запуске проекта для максимальной экономии
RI покупают после 3-6 месяцев работы, когда baseline нагрузка стабилизировалась. Ранняя покупка рискует зафиксировать неоптимальный instance type на 1-3 года
Архитектура и нагрузка меняются в первые месяцы. На старте - On-Demand + Spot. После стабилизации - анализ Cost Explorer, покупка RI/SP на реальный baseline. Это стандартная практика AWS Well-Architected Framework.
Startup запускает production: 4 instances m6i.large постоянно, плюс масштабирование до 12 в бизнес-часы. Оптимальная стратегия покупки?
Ключевые идеи
- **Instance types** - семейства оптимизированы под workload: t (burstable), m (balanced), c (compute), r (memory), p (GPU), i (storage NVMe)
- **AMI** - шаблон VM: региональный, content-addressable. Golden AMI паттерн для fast startup
- **Spot** - 70-90% скидка за прерываемость. Паттерн: checkpoint + retry, diversified fleet по нескольким типам
- **Buying strategy**: Savings Plans на baseline, On-Demand/Spot на пики. RI покупать после 3-6 мес стабилизации
Вопросы для размышления
- Стартап тратит $50K/мес на EC2 On-Demand: 20 m6i.xlarge постоянно запущены. AWS Cost Explorer показывает 95% утилизацию за последние 6 месяцев. Какую стратегию закупки предложить и какова потенциальная экономия?