PostgreSQL RTO і RPO: налаштування відмовостійкості з Patroni

Зауважимо: коли сервіс лежить годину, а recovery триває добу — це катастрофа. Платіжний шлюз, що обробляє 10 000 транзакцій на хвилину, при простої в 30 хвилин втрачає не лише виручку, але й довіру клієнтів. Середня вартість години простою для e-commerce — понад 1 000 000 гривень. RTO (Recovery Time Objective) та RPO (Recovery Point Objective) — параметри, які визначають, як швидко ви встанете після збою і скільки даних втратите. Ми налаштовуємо інфраструктуру PostgreSQL так, щоб ці метрики відповідали бізнес-вимогам: від cold standby до multi-region active-active. Наші інженери мають понад 10 років досвіду в PostgreSQL та понад 50 успішних проєктів із впровадження відмовостійких кластерів.

Які проблеми вирішуємо

• Невизначені SLA. Без формальних RTO/RPO ви не можете гарантувати клієнтам час відновлення. Штрафи за договорами зростають, а репутація страждає.
• Ручне відновлення. При збої адміністратор вручну піднімає репліку — це години простою. Автоматичний failover скорочує RTO до секунд.
• Втрата даних. Рідкісні бекапи (раз на добу) означають RPO = 24 години. При збої ви втрачаєте денні транзакції. WAL-архівування кожні 5 хвилин знижує RPO до 5 хвилин.
• Надмірні витрати. Гонитва за нульовим RTO без аналізу бізнесу призводить до переплати. Ми допомагаємо знайти баланс вартість/надійність.

Як визначити RTO та RPO для вашого бізнесу?

Перший крок — оцінка вартості простою. Використовуємо простий калькулятор:

class RtoCalculator:
    def calculate_downtime_cost(self, hourly_revenue, churn_per_hour, penalty, clv, customers):
        costs = {
            'lost_revenue': hourly_revenue,
            'churn': (churn_per_hour/100)*customers*clv,
            'sla_penalties': penalty,
            'labor': 500
        }
        total = sum(costs.values())
        if total > 100000: return '< 5 min (active-active)'
        elif total > 10000: return '< 15 min (hot standby)'
        else: return '< 1 h (warm standby)'

Чому Patroni — найкращий вибір для PostgreSQL?

Patroni з etcd забезпечує failover за 30 секунд — у 10 разів швидше за ручне відновлення. Він керує конфігурацією, автоматично перемикає трафік і не втрачає дані при правильному налаштуванні синхронної реплікації. Це стандарт для High Availability в PostgreSQL.

Як ми це робимо

Кейс: Корпоративна CRM на PostgreSQL 15. Потрібні були RTO < 30 хвилин та RPO < 5 хвилин. Розгорнули Patroni на трьох нодах, pgBackRest для WAL-архівування в S3, HAProxy для маршрутизації. Після тестового збою (kill primary) failover тривав 18 секунд, втрата даних — 0 (синхронна реплікація). Документація з відновлення була передана команді.

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
checkpoint_timeout = 5min
max_wal_senders = 10
wal_keep_size = 1GB

# pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-bucket=myapp-wal-archive
repo1-retention-full=4
repo1-retention-diff=14

[main]
pg1-path=/var/lib/postgresql/data

Patroni: автоматичний failover (RTO < 30 сек)

# patroni.yml
scope: postgres-cluster
name: pg-node-1
restapi:
  listen: 0.0.0.0:8008
etcd3:
  hosts: etcd1:2379,etcd2:2379,etcd3:2379
bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    max_lag_on_failover: 1048576
postgresql:
  parameters:
    wal_level: replica
    hot_standby: on
    archive_command: 'pgbackrest --stanza=main archive-push %p'

HAProxy: маршрутизація з урахуванням ролі

frontend postgres_write
  bind *:5432
  default_backend postgres_primary
backend postgres_primary
  option httpchk GET /master
  server pg-node-1 check port 8008

frontend postgres_read
  bind *:5433
  default_backend postgres_replicas
backend postgres_replicas
  balance roundrobin
  option httpchk GET /replica
  server pg-node-1 check port 8008

Як моніторити RTO/RPO?

Моніторинг — ключ до дотримання SLA. У таблиці наведено метрики, які потрібно відстежувати:

Налаштовуємо Prometheus + alertmanager. При порушенні RPO чергова команда отримує сповіщення. Це дозволяє реагувати до того, як збій вплине на бізнес.

Що робити при порушенні RPO?

Типові помилки при проєктуванні відмовостійкості:

• Відсутність тестів failover. Ми проводимо хаос-інжиніринг: симулюємо відмову ноди, мережі, диска. Тільки так можна підтвердити реальні RTO/RPO.
• Ігнорування затримок реплікації. При синхронному режимі latency між дата-центрами не має перевищувати 10 мс.
• Неправильна ротація бекапів. pgBackRest з retention (full/diff) гарантує, що старі бекапи не перезаписуються. Відновлення на будь-яку точку в часі.

Ми складаємо чек-лист для чергових: дії при збої, порядок promotion, контакти вендора.

Процес роботи

1. Аудит — інвентаризація поточної інфраструктури, навантаження, бюджет.
2. Розрахунок — визначаємо цільові RTO/RPO разом із вами.
3. Проєктування — вибираємо архітектуру (Patroni + etcd, pgBackRest, HAProxy).
4. Реалізація — розгортання, конфігурація, тестування failover.
5. Тест — симулюємо збої, вимірюємо реальні RTO/RPO.
6. Документація та навчання — runbook з інцидентів, навчання чергових.

Що входить у налаштування під ключ

• Налаштування Patroni з etcd/Consul для автоматичного failover
• pgBackRest — full/differential backup, WAL-архівування в S3 або локальне сховище
• HAProxy — інтелектуальна маршрутизація (write/read split)
• Моніторинг — Prometheus експортер для lag, алерти при порушенні RPO
• Документація — план відновлення, конфіги, перевірочні листи
• Навчання — 2 години workshop для вашої команди

Строки та гарантії

Налаштування під ключ для типового кластера (3 ноди) займає 3–5 робочих днів. Результат — досягнення цільових RTO/RPO, підтверджене навантажувальним тестуванням. Ми сертифіковані інженери з більш ніж 10 роками досвіду в PostgreSQL. Гарантуємо SLA на час відновлення.

Економія від впровадження автоматичного failover може становити від 100 000 до 500 000 гривень на місяць за рахунок запобігання простоям. Зв'яжіться з нами для розрахунку вашого випадку. Замовте консультацію — ми підберемо оптимальну архітектуру під ваш бюджет та вимоги.

Ми регулярно стикаємося з ситуацією: «Сайт не відкривається» о 3 годині ночі — і виявляється, що disk full на VPS, тому що логи nginx не ротувалися півроку. Або сервер ліг під навантаженням у день запуску рекламної кампанії, тому що на shared хостингу стояв ліміт у 50 одночасних з'єднань. Налаштування хостингу та деплою — це не про «де дешевше», це про те, що відбувається в момент, коли щось іде не так. Наша команда допомагає уникнути таких інцидентів, проектуючи інфраструктуру з урахуванням реальних патернів навантаження.

Коли обирати Vercel та Netlify?

Vercel створений під Next.js — деплой в один push, preview deployments для кожного PR, автоматичний CDN, Edge Functions, ISR без конфігурації. Для фронтенд-проєктів та JAMstack це оптимальний вибір: немає операційного навантаження, time-to-deploy вимірюється хвилинами.

Обмеження реальні: Vercel Serverless Functions запускаються в us-east-1 за замовчуванням (latency для Європи +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/місяць на Pro. Для важкого backend — потрібні воркери або окремий сервер.

Netlify ближчий до статики та Edge Functions на базі Deno Deploy. Build minutes — основне обмеження на безкоштовному тарифі.

Чому Docker — основа передбачуваного деплою?

«Працює на моїй машині» — класика. Docker вирішує це через контейнеризацію середовища. Але поганий Dockerfile створює нові проблеми.

Типова помилка: копіювати все в образ без .dockerignore, отримувати 800MB образ замість 80MB. node_modules всередині образу важить стільки ж. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Підсумковий образ: 180MB замість 1.2GB. Час збірки CI скорочується через layer caching — якщо package.json не змінився, шар з npm ci береться з кешу.

Docker Compose для локальної розробки та простих продакшн-сценаріїв: застосунок + PostgreSQL + Redis в одній конфігурації. Для production на одному сервері — цілком робочий варіант, якщо немає вимог горизонтального масштабування.

Детальніше про контейнеризацію — Wikipedia: Docker.

Як налаштувати Nginx як reverse proxy?

Nginx перед застосунком — стандарт для VPS та виділених серверів. Основні функції: SSL termination, gzip, static files, rate limiting, upstream балансування.

Конфігурація, яку часто роблять неправильно: worker_processes auto — кількість процесів дорівнює числу CPU. worker_connections 1024 — це 1024 на кожний воркер-процес. При 4 CPU та 1024 connections = 4096 одночасних з'єднань. Для високонавантаженого сайту потрібно worker_connections 4096 та налаштування keepalive_timeout 65.

Для статичних ассетів з хешем в імені файлу:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable повідомляє браузеру: не перевіряй цей файл навіть при hard refresh. Правильно працює лише з content-hashed іменами файлів (що робить Vite/webpack за замовчуванням). Документація — Wikipedia: Nginx.

AWS: гнучкість та складність

EC2 + Auto Scaling Group — класика для горизонтального масштабування. AMI з попередньо встановленим застосунком, Launch Template, ASG з min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 хвилини — scale out, при CPU < 30% на 15 хвилин — scale in. Health check через ALB виключає нездорові інстанси з ротації.

ECS Fargate — контейнери без управління EC2. Деплой Docker-образу, задаєте CPU/пам'ять (512 CPU units = 0.5 vCPU, від 512MB пам'яті), Fargate запускає. Дорожче Lambda, але немає cold start та немає timeout-обмежень. Підходить для long-running процесів, WebSocket-серверів, важких воркерів.

RDS для PostgreSQL з Multi-AZ: автоматичний failover за 1–2 хвилини при падінні primary. Read Replicas для масштабування читання. RDS Proxy для connection pooling — Lambda-функції не вміють тримати довгострокові з'єднання, проксі буферизує це.

Kubernetes: коли це виправдано

K8s додає значну операційну складність. Виправданий, коли: кілька команд деплоять незалежні сервіси, потрібне тонке налаштування ресурсів на сервіс, canary deployments та blue/green без простою — вимога.

AWS EKS, GKE або managed k8s від Hetzner (дешевше). Helm charts для стандартних сервісів. Horizontal Pod Autoscaler по CPU та custom metrics (RPS через Prometheus).

Для більшості стартапів та середніх проєктів — Kubernetes надмірний. ECS або Fly.io дають 80% можливостей при 20% операційної складності.

Моніторинг та alerting

Сервер без моніторингу — це очікування інциденту. Мінімальний стек: Prometheus + Grafana (або Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 хвилин, error rate > 1%. Uptime через Better Uptime або Upptime (self-hosted).

Logs: Loki + Grafana або CloudWatch Logs Insights. Структуровані JSON-логи (winston, pino) — обов'язково, інакше пошук по логах перетворюється на біль.

Що входить у налаштування хостингу

• Аудит поточної інфраструктури та профілювання навантаження
• Вибір цільової архітектури (VPS, AWS, serverless, Kubernetes)
• Налаштування CI/CD pipeline (GitHub Actions, GitLab CI) з автоматичним деплоєм
• IaC через Terraform або Pulumi (інфраструктура як код)
• Конфігурація Nginx, SSL-сертифікати, HTTP/2, brotli
• Моніторинг та алертинг (Prometheus + Grafana, PagerDuty)
• Документація runbooks та навчання команди

Додатково: пишіть, якщо потрібна міграція з поточного хостингу або інтеграція із зовнішніми сервісами.

Процес роботи

1. Аудит поточної інфраструктури (2–5 днів)
2. Вибір цільової архітектури з обґрунтуванням за навантаженням та бюджетом (1–3 дні)
3. Налаштування CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 днів)
4. IaC через Terraform або Pulumi (3–10 днів)
5. Налаштування моніторингу та alerting (2–5 днів)
6. Документація runbooks та навчання команди (1–3 дні)

Наш досвід — 7 років на ринку, понад 50 проєктів, гарантія працездатності після деплою.

Терміни

• Базовий деплой на VPS з Docker + Nginx + CI/CD: 1–2 тижні.
• Налаштування AWS інфраструктури з Auto Scaling, RDS, CDN: 3–6 тижнів.
• Міграція на EKS з нуля: 6–12 тижнів.
• Налаштування Vercel/Netlify для JAMstack: 3–5 днів.

Вартість розраховується індивідуально залежно від складності та обсягу робіт. Отримайте консультацію — оцінимо вашу архітектуру за один день.