В каких случаях стоит выбирать IaaS

Когда выбирать IaaS для Data Engineering

Делюсь опытом из 10+ лет работы с разными облачными моделями. IaaS (Infrastructure as a Service) — это не всегда правильный выбор, но есть конкретные случаи, где это идеально.

1. Непредсказуемые пики нагрузки

Сценарий: Данные приходят волнами

# Пример: обработка логов от мобильного приложения
# В рабочее время (9-18) пользователи активны → 1M events/hour
# Ночью (23-8) → 50K events/hour
# Выходные → 200K events/hour

# IaaS решение: AWS EC2 с Auto Scaling
from boto3 import client
auto_scaling = client('autoscaling')
# При пике: 10 инстансов
# В ночи: 1 инстанс
# Платишь только за используемое

PaaS альтернатива: Serverless (Lambda, Cloud Functions) — ещё лучше, но это уже не IaaS.

2. Требуется полный контроль над инфраструктурой

# IaaS: ты полностью контролируешь
# - Версия OS (Linux kernel, SELinux)
# - Сетевая конфигурация (VPC, firewall rules)
# - Хранилище (EBS, местное SSD, RAID конфиги)
# - Тюнинг параметров БД (shared_buffers, work_mem и т.д.)

# Пример: ClickHouse требует специфичный конфиг
sudo vim /etc/clickhouse-server/config.d/custom.xml
<yandex>
  <max_memory_usage>34359738368</max_memory_usage>  <!-- 32 GB -->
  <tmp_path>/ssd/clickhouse-temp/</tmp_path>
</yandex>

# В PaaS этого часто нельзя делать

Когда это критично:

• Высоконагруженные базы (PostgreSQL, MySQL в OLTP режиме)
• Специальные СУБД (ClickHouse, Elasticsearch)
• Требуется кастомная сетевая топология (частные IP, VPN)

3. Большие объёмы данных с высокой пропускной способностью

# Сценарий: обработка 100 TB данных в месяц
# Затраты на сетевой трафик критичны

# IaaS (EC2 в том же Data Center):
# - Трафик между инстансом и S3 → 0.01$ за GB (или бесплатно внутри сети)
# - Твой контроль над bandwidth utilization

# PaaS (Athena, BigQuery):
# - Плата за scanned data: $6-7 за TB
# - 100 TB = $600-700 в месяц ТОЛЬКО на queries

# IaaS экономит деньги
print(f"100 TB × $6.25 = ${100 * 6.25} на Athena")
print(f"EC2 + S3 = ~$50 в месяц на хранение + $100 на compute")

4. Миграция legacy систем (лифт-энд-шифт)

# У компании есть старая система на физических серверах:
# - Oracle Database (лицензия дорогущая)
# - Custom C++ приложение с low-level системными вызовами
# - Старая OS: RHEL 6

# IaaS решение (AWS EC2, Azure VM):
# 1. Виртуализируешь сервер (V2V migration)
# 2. Запускаешь на EC2
# 3. Платишь по часам, не по лицензиям (если Linux)

# PaaS/SaaS не подходит:
# - Oracle Database — дорого в облаке
# - Custom C++ — нельзя запустить в serverless
# - Требуется root access

5. Требуется собственный инженерный контроль

# Сценарий: компания хочет полное владение данными
# - GDPR/compliance требуют мониторить каждый байт
# - Нужно знать, кто к чему получает доступ
# - Требуется собственное резервное копирование

# IaaS позволяет:
from subprocess import run

# Собственный скрипт резервного копирования
run([
    'pg_dump', 
    '-h', 'my-postgres-rds.aws.com',
    '-U', 'postgres',
    'mydb'
], stdout=open('/encrypted-storage/backup.sql', 'w'))

# Собственный мониторинг
import prometheus_client
metrics = prometheus_client.CollectorRegistry()
metrics.register(custom_data_quality_metric)

# В PaaS часто нельзя

6. Стоимость вычислений меньше, чем в PaaS

Сравнение затрат:

# Калькулятор
data_size_tb = 100
queries_per_day = 10
data_per_query_tb = 50  # средняя выборка

# IaaS (EC2 + S3)
iaas_cost = 200 + (3000 * 0.023)  # EC2 на месяц + S3

# PaaS (Athena)
paas_cost = queries_per_day * 30 * data_per_query_tb * 6.25 / 1024

print(f"IaaS: ${iaas_cost}")
print(f"PaaS: ${paas_cost}")

7. Требуется собственное расписание масштабирования

# IaaS (AWS EC2 со своим скриптом масштабирования)
while true; do
  load=$(aws cloudwatch get-metric-statistics \
    --namespace AWS/EC2 \
    --metric-name CPUUtilization \
    --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
    --start-time 2024-03-23T00:00:00Z \
    --end-time 2024-03-23T01:00:00Z)
  
  if [ $load > 80 ]; then
    # Запустить новые инстансы
    aws ec2 run-instances --image-id ami-12345 --instance-type t3.xlarge
  fi
  
  sleep 300
done

Сравнение подходов:

Мой рекомендуемый выбор

Выбирай IaaS, если:

1. Объём данных > 50 TB/месяц
2. Требуется full control над инфраструктурой
3. Legacy система требует миграции
4. Budget < PaaS альтернативы в 2+ раза
5. Требуется собственное расписание масштабирования
6. Специальная СУБД (ClickHouse, Elasticsearch)

Выбирай PaaS, если:

1. Startup — нужна скорость, не затраты
2. Непредсказуемые пики нагрузки
3. < 10 TB данных
4. Хочешь меньше операционной нагрузки

Выбирай Serverless, если:

1. Sporadic workloads (раз в неделю запуск)
2. Need to scale from 0
3. Простая обработка (ETL, webhooks)

В моей последней компании мы выбрали IaaS (AWS EC2 + S3) для Data Lake на 200 TB, потому что экономили $2M/год по сравнению с Snowflake, и нам нужен был full control для compliance требований.