Где хостил PostgreSQL?

Я хостил PostgreSQL в огромном количестве разных сред за свою карьеру, и выбор всегда зависел от конкретных требований проекта: баланса между контролем, стоимостью, сложностью администрирования и необходимостью масштабирования. Вот подробный разбор моих ключевых сценариев.

1. Самоуправляемые инстансы на виртуальных машинах (IaaS)

Это классика для проектов, где требуется полный контроль, тонкая настройка под нагрузку или специфичная конфигурация.

• Провайдеры: AWS EC2, Google Cloud Compute Engine, Яндекс.Облако, Bare-metal серверы (Hetzner, OVH).
• Почему выбирал:

    *   **Полный контроль над СУБД и ОС:** Возможность настроить `postgresql.conf` и `pg_hba.conf` под микроскопом, выбрать файловую систему (часто `XFS` или `ext4`), настроить `sysctl`-параметры для оптимальной работы с памятью и диском.
    *   **Гибкость репликации:** Настройка собственных каскадных реплик, использование инструментов вроде `pg_rewind` для recovery.
    *   **Выделенный диск:** Возможность подключить высокопроизводительные SSD или даже NVMe-диски отдельно от системного.

• Пример типовой установки и базовой настройки через Ansible:

# postgresql_deploy.yml
- hosts: db_servers
  become: yes
  vars:
    postgresql_version: "15"
    postgresql_listen_addresses: "'*'"
  tasks:
    - name: Add PostgreSQL APT repository
      apt_repository:
        repo: "deb https://apt.postgresql.org/pub/repos/apt {{ ansible_distribution_release }}-pgdg main"
        state: present
        update_cache: yes

    - name: Install PostgreSQL
      apt:
        name: "postgresql-{{ postgresql_version }}"
        state: present

    - name: Ensure PostgreSQL is started and enabled
      service:
        name: "postgresql@{{ postgresql_version }}-main"
        state: started
        enabled: yes

    - name: Configure listen addresses
      lineinfile:
        path: "/etc/postgresql/{{ postgresql_version }}/main/postgresql.conf"
        regexp: "^#?listen_addresses"
        line: "listen_addresses = {{ postgresql_listen_addresses }}"
        state: present
      notify: restart postgresql

• Сопровождение: Требовалось собственное резервное копирование (pg_dump, pg_basebackup + WAL-архивирование в S3), мониторинг (Prometheus + postgres_exporter), обеспечение отказоустойчивости (Patroni, repmgr).

2. Управляемые облачные сервисы (DBaaS)

Использовал для проектов, где нужно сосредоточиться на приложении, а не на администрировании БД, особенно в командах без выделенного DBA.

• Провайдеры: AWS RDS for PostgreSQL, Google Cloud SQL, Яндекс.Облако Managed Service for PostgreSQL, Azure Database for PostgreSQL.
• Почему выбирал:

    *   **Автоматическое администрирование:** Патчинг, обновления минорных версий, бэкапы, мониторинг базовых метрик.
    *   **Встроенный HA:** Легко включить Multi-AZ развёртывание с автоматическим failover.
    *   **Интеграция с экосистемой:** Простое подключение к CloudWatch/Stackdriver, IAM-аутентификация в AWS, управление через Terraform.
    *   **Мгновенное масштабирование:** Увеличение vCPU/RAM или переключение на более мощный инстанс часто в несколько кликов.

• Пример создания инстанса в AWS RDS через Terraform:

resource "aws_db_instance" "production" {
  identifier     = "myapp-prod-db"
  engine         = "postgres"
  engine_version = "15.3"
  instance_class = "db.t3.large"

  allocated_storage     = 100
  storage_type         = "gp3"
  storage_encrypted    = true

  db_name  = "myapp_production"
  username = var.db_master_username
  password = var.db_master_password

  multi_az               = true # Высокая доступность
  publicly_accessible    = false
  vpc_security_group_ids = [aws_security_group.db.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name

  backup_retention_period = 7
  backup_window           = "03:00-04:00"
  maintenance_window      = "sun:04:00-sun:05:00"

  performance_insights_enabled = true
}

3. Контейнеризация (Kubernetes)

Хостил в Kubernetes для микросервисных архитектур, где важна тесная связь сервиса с его данными, или для разработки/тестирования.

• Операторы: Использовал Crunchy Data PostgreSQL Operator (PGO) и CloudNativePG (ранее Zalando Postgres Operator).
• Почему выбирал:

    *   **Единая парадигма управления:** Объявление состояния БД через Custom Resource Definition (CRD) в YAML, как и всего остального в кластере.
    *   **Автоматическое жизне**цикличное управление: Развёртывание, репликация, резервное копирование, восстановление, обновление версий – всё декларативно.
    *   **Гибкость хранения данных:** Использование `PersistentVolumeClaims` с разными `StorageClass` (например, `ssd` или `network-ssd`).
    *   **Изоляция и переносимость:** Идеально для окружений разработки, staging, для stateful сервисов в микросервисах.

• Пример простого манифеста CloudNativePG:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: myapp-db-cluster
spec:
  instances: 3
  primaryUpdateStrategy: unsupervised
  storage:
    size: 50Gi
    storageClass: network-ssd
  bootstrap:
    initdb:
      database: myapp
      owner: app_user
  postgresql:
    parameters:
      shared_buffers: "256MB"
      work_mem: "8MB"

4. Специализированные платформы (и гибридные сценарии)

• Выделенные хостеры (Bare-metal): Для высоконагруженных OLTP-систем, где нужна максимальная и предсказуемая производительность дисков (вплоть до NVMe) и сетевых задержек.
• Локальные развёртывания (On-Premise): Для проектов со строгими требованиями к суверенитету данных или интеграцией в существующую корпоративную инфраструктуру.
• Гибридные схемы: Например, мастер на самоуправляемом инстансе в облаке (для контроля), а read-only реплика в виде облачного managed-сервиса для аналитики.

Критерии выбора, которыми я руководствуюсь:

1. Требования к доступности (SLA): Нужен ли автоматический failover? RPO/RTO?
2. Компетенции команды: Есть ли в команде опытный DBA или вся ответственность на инженерах?
3. Бюджет: Сравнение TCO (Total Cost of Ownership) – managed-сервис кажется дороже, но учитываются трудозатраты на администрирование.
4. Производительность и латентность: Требуется ли экстремальная скорость дискового ввода-вывода или минимальная сет