PrepBro
← Назад к вопросам

Проектирование инфраструктуры для высоконагруженного сервиса

3.0 Senior🔥 191 комментариев
#Облачные технологии

Условие

Спроектируйте инфраструктуру для сервиса бронирования (типа Booking.com):

Требования

  • 1 млн активных пользователей в день
  • 99.9% availability (downtime < 8.76 часов в год)
  • Время ответа API < 200ms для 95 перцентиля
  • Хранение данных за 5 лет

Опишите

  1. Вычислительные ресурсы: Kubernetes кластер, размер нод, autoscaling
  2. База данных: Выбор БД, репликация, шардирование
  3. Кэширование: Redis/Memcached, стратегия инвалидации
  4. CDN и балансировка: Глобальное распределение, failover
  5. CI/CD: Pipeline, стратегия деплоя, rollback
  6. Мониторинг: Метрики, алерты, on-call
  7. Безопасность: WAF, секреты, audit logs

Дополнительно

  • Как обеспечить DR (Disaster Recovery)?
  • Оцените стоимость инфраструктуры в месяц

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Решение: Инфраструктура для высоконагруженного сервиса бронирования

Архитектурный обзор

Для сервиса с 1 млн активных пользователей в день и требованием 99.9% доступности необходимо спроектировать многоуровневую, отказоустойчивую инфраструктуру с распределением нагрузки и автоматизацией.

1. Вычислительные ресурсы

Kubernetes кластер

Размер кластера:

  • Мастер-ноды: 3 ноды в разных зонах доступности (HA setup)
  • Рабочие ноды: минимум 6-8 нод t3.2xlarge на AWS
  • Распределение: по 2-3 нодам в каждой zone доступности

Конфигурация нод:

  • CPU: 8-16 cores
  • Memory: 32-64 GB
  • Network: 10Gbps
  • Storage: 100GB+ SSD

Autoscaling:

  • Используем Kubernetes Cluster Autoscaler
  • Metric-based scaling через HPA (Horizontal Pod Autoscaler)
  • Скейлируем по CPU (70% target) и custom metrics

2. База данных

Выбор БД и архитектура

Primary база: PostgreSQL 15+

  • Для реляционных данных: пользователи, бронирования, платежи
  • ACID гарантии, мощный query engine
  • Требует горизонтального масштабирования через шардирование

Secondary cache: Redis Cluster

  • 6+ узлов с репликацией
  • Для быстрых lookups и сессий

Репликация

Primary PostgreSQL (Write) с 3 Standby репликами в разных Zone

  • RPO: менее 10 секунд
  • RTO: менее 30 секунд
  • Используем patroni для автоматического failover

Шардирование

Для 1млн пользователей шардируем по user_id:

  • Shards: 16 (позволяет масштабировать до 8-10млн пользователей)
  • Sharding Key: user_id modulo number_of_shards
  • Каждый shard имеет Primary + 2 Standby в разных zones
  • Хранение данных: 5 лет = примерно 1.8 PB на основных данных

3. Кэширование

Redis Cluster для высокой доступности

Топология:

  • Cluster Nodes: 9 (3 primary + 6 replicas)
  • Replication Factor: 2
  • maxmemory: 256GB total
  • maxmemory-policy: allkeys-lru
  • appendonly: yes (AOF persistence)

Стратегия инвалидации кэша:

  1. TTL-based: Кэш популярных поисков (отели, города) - TTL 1-4 часа
  2. Event-based: При обновлении цены/доступности отеля инвалидируем соответствующие ключи
  3. Lazy deletion: Проверяем актуальность при доступе

При обновлении доступности отеля инвалидируем все даты этого отеля в кэше.

4. CDN и глобальная балансировка

Multi-region deployment

  • US East (N. Virginia) - Primary
  • EU West (Ireland)
  • APAC (Singapore)
  • APAC (Tokyo)

Используем CloudFront или Akamai с geographic routing.

Load Balancing:

  • Внешний LB: AWS Route53 с health checks
  • В пределах кластера: NGINX Ingress Controller с session affinity
  • Pod-level: Kubernetes Service с RoundRobin распределением

Failover механизм:

  • Active-Active между регионами
  • Route53 health checks (30 сек интервал)
  • 3 failed checks = failover
  • DNS TTL 60 сек = переключение в течение минуты

5. CI/CD Pipeline

Stages:

  1. Build - Docker build и push в registry
  2. Test - unit tests, coverage > 90%
  3. Security - trivy scan, sonarqube
  4. Deploy-staging - rolling update в staging
  5. Deploy-prod - manual trigger для production

Стратегия деплоя:

  • Rolling update: Заменяем по 25% подов одновременно
  • Blue-Green: Держим две полные версии приложения
  • Canary deployment: 5% трафика на новую версию, затем 100%

Rollback:

  • Хранится история revisions
  • Можно откатиться на любую предыдущую версию за менее 1 минуты

6. Мониторинг и алерты

Stack: Prometheus + Grafana + ELK

Ключевые метрики:

Application:

  • Request latency (p50, p95, p99) менее 200ms для p95
  • Error rate (5xx errors) менее 0.1%
  • RPS (requests per second)
  • Cache hit ratio более 85%

Infrastructure:

  • CPU utilization менее 80%
  • Memory utilization менее 85%
  • Disk usage менее 90%
  • Pod restart count
  • Node availability

Database:

  • Query latency (p95) менее 100ms
  • Replication lag менее 5s
  • Connection pool usage менее 80%
  • Backup success/failure

Business:

  • Bookings per minute
  • Conversion rate
  • Payment success rate

Алерты (on-call schedule):

Critical (Page immediately):

  • Error rate более 5%
  • p95 latency более 1000ms
  • API availability менее 99%
  • Database down
  • Cache cluster down

Warning (Slack notification):

  • Error rate более 1%
  • CPU более 85%
  • Memory более 90%
  • Replication lag более 30s

7. Безопасность

WAF (Web Application Firewall):

  • AWS WAF или ModSecurity
  • OWASP Top 10 правила
  • Rate limiting: 100 requests/10s per IP
  • DDoS protection через AWS Shield

Управление секретами:

  • Используем HashiCorp Vault или AWS Secrets Manager
  • Никогда не коммитим пароли в git

Сертификаты и HTTPS:

  • Let's Encrypt с автоматическим обновлением
  • TLS 1.3 обязателен
  • HSTS заголовки

Audit logs:

  • Все попытки доступа к админ-панели
  • Все изменения в БД
  • API запросы с sensitive данными
  • Доступ к backups

Encryption:

  • Data at rest: AES-256 для БД
  • Data in transit: TLS 1.3
  • Sensitive fields зашифрованы отдельно

8. Disaster Recovery

RTO (Recovery Time Objective): 30 минут RPO (Recovery Point Objective): 10 минут

Backup стратегия:

  1. Continuous replication (основной механизм)

    • Streaming replication в другой zone
    • Failover за менее 30 секунд

  2. Daily snapshots

    • EBS snapshots в другой регион
    • Хранение: 30 дней
    • Проверка восстановления еженедельно

  3. Cross-region backup

    • Копирование БД в другой AWS регион каждые 4 часа
    • RTO: 4 часа, RPO: 4 часа

DR тестирование:

  • Ежемесячно: failover test
  • Ежемесячно: backup recovery test
  • Ежеквартально: full DR drill в другом регионе

Оценка стоимости инфраструктуры (в месяц)

Эвристика: 1млн активных пользователей в день ≈ 20-50K USD/month

Подробный расчёт:

Compute (Kubernetes на AWS):

  • 8 нод t3.2xlarge: 1920 USD/month
  • NAT Gateways (3): 135 USD/month
  • Load Balancer: 20 USD/month
  • Subtotal: 2,075 USD

Database (PostgreSQL RDS):

  • Primary db.r6g.4xlarge: 2,700 USD/month
  • 2x Standby replicas: 5,400 USD/month
  • Storage (1.5TB): 300 USD/month
  • Backup storage: 150 USD/month
  • Subtotal: 8,550 USD

Caching (Redis):

  • 9 cache.r6g.xlarge nodes: 2,250 USD/month
  • Data transfer: 200 USD/month
  • Subtotal: 2,450 USD

CDN & Networking:

  • CloudFront (1PB traffic): 5,000 USD/month
  • Data transfer out: 2,000 USD/month
  • Cross-AZ traffic: 1,000 USD/month
  • Subtotal: 8,000 USD

Monitoring & Logging:

  • Datadog / New Relic: 1,500 USD/month
  • S3 storage для logs (30 дней): 500 USD/month
  • Subtotal: 2,000 USD

Backup & DR:

  • Cross-region replication: 800 USD/month
  • EBS snapshots: 200 USD/month
  • Subtotal: 1,000 USD

Miscellaneous:

  • DNS (Route53): 50 USD/month
  • KMS encryption: 100 USD/month
  • Subtotal: 150 USD

ИТОГО: 24,225 USD в месяц (~290K USD в год)

Цены варьируются в зависимости от региона, облачного провайдера (AWS, GCP, Azure) и пиковой нагрузки. При оптимизации можно снизить на 20-30% через Reserved Instances и Spot Instances для non-critical workloads.