Чем отличается горизонтальное масштабирование от вертикального?

Горизонтальное и вертикальное масштабирование — это две принципиально разные стратегии увеличения вычислительной мощности системы, и выбор между ними критически влияет на архитектуру и DevOps-практики.

Вертикальное масштабирование (Scale Up/Down):

• Суть: Увеличение или уменьшение ресурсов (CPU, RAM, диск) уже существующего сервера (виртуальной машины, инстанса, контейнера).
• Аналогия: Замена двигателя в грузовике на более мощный.
• Примеры в DevOps:
  • В AWS: изменение типа инстанса EC2 с t3.medium (2 vCPU, 4 GiB) на t3.xlarge (4 vCPU, 16 GiB).
  • В базе данных: увеличение памяти для кэша или выделение больше CPU для инстанса PostgreSQL.
• Плюсы:
  • Простота — не требует изменений в архитектуре приложения.
  • Подходит для монолитных приложений, которые сложно распараллелить, и для СУБД, где важен один мощный узел.
• Минусы:
  • Единая точка отказа (SPOF).
  • Существует физический или финансовый предел мощности одного сервера.
  • Часто требует перезагрузки сервиса.

Горизонтальное масштабирование (Scale Out/In):

• Суть: Добавление или удаление новых серверов/нод в пул для распределения нагрузки.
• Аналогия: Добавление большего количества грузовиков в автопарк.
• Примеры в DevOps:
  • Увеличение количества реплик (replicas) Deployment в Kubernetes.
  • Добавление новых веб-серверов Nginx за балансировщиком нагрузки (AWS ALB, Nginx LB).
  • Использование распределенных NoSQL БД (Cassandra, DynamoDB).
• Плюсы:
  • Высокая доступность и отказоустойчивость (нет SPOF).
  • Теоретически неограниченный масштаб.
  • Позволяет использовать более дешевое, стандартизированное железо.
• Минусы:
  • Требует архитектуры, поддерживающей распределенность (stateless-сервисы, shared-nothing).
  • Усложняет систему (необходимость в балансировке, service discovery, синхронизации данных).

DevOps-практика: Современные облачные приложения стремятся к горизонтальному масштабированию как к более гибкой и отказоустойчивой модели. Инфраструктура как код (Terraform) и оркестраторы (Kubernetes) делают этот процесс автоматизированным и декларативным.

Пример горизонтального масштабирования в Kubernetes (HPA на основе CPU):

# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 3  # Стартовое количество подов
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
      - name: api
        image: my-api:latest
        resources:
          requests:
            cpu: 100m
          limits:
            cpu: 200m
---
# HorizontalPodAutoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # Система будет добавлять/удалять поды, чтобы средняя загрузка CPU была ~70%