Подробный дизайн инфраструктуры сервиса‑клон Dropbox

Условие

Компания планирует создать сервис, схожий по функционалу с DropBox, рассчитанный на пользователей по всему миру (Европа, США, Азия и др.). Приложение состоит из набора микросервисов, каждый из которых реализует отдельный бизнес‑процесс (например, сервис оплаты, сервис управления пользователями, сервис работы с файлами и т.п.). Для хранения данных используется PostgreSQL, файлы размещаются в объектном хранилище совместимом с S3, а обмен сообщениями между микросервисами организован через очередь.

Исходный репозиторий содержит:

• 10 каталогов, в каждом из которых находится код отдельного микросервиса и Dockerfile для его сборки;
• файл docker‑compose.yml в корне, позволяющий запустить локальное окружение со всеми микросервисами, PostgreSQL, очередью и S3‑совместимым хранилищем.

Нефункциональные требования бизнеса:

1. Высокая доступность – SLA не менее 99,99 %.
2. Устойчивость к нагрузке – система должна выдерживать как постоянную высокую нагрузку, так и кратковременные пиковые нагрузки.
3. Низкая задержка – требуется минимальная latency как внутри региона, так и для пользователей из разных регионов.
4. Безопасность и конфиденциальность – защита данных от несанкционированного доступа.
5. Экономия расходов – инфраструктура должна быть cost‑effective, без избыточных затрат.
6. Failover и DR – при отказе целого дата‑центра или региона сервис должен оставаться доступным и сохранять целостность данных.

Ваша роль – руководитель DevOps‑команды. Требуется подготовить:

1. Проект production‑окружения – предложить полную схему инфраструктуры, учитывающую все перечисленные требования. Явно указать используемые облачные сервисы, инструменты и подходы.
2. Проект staging‑окружения – разработать вариант, максимально приближённый к production, но существенно дешевле. Описать, какие компоненты будут упрощены или исключены и почему.
3. Управление инфраструктурой – выбрать методику и инструменты для автоматизации развертывания и поддержки инфраструктуры.
4. Обратная связь – определить набор средств и практик, позволяющих разработчикам и бизнесу наблюдать за работой системы в разных средах и принимать решения по её оптимизации.
5. Оценка производительности – описать подходы и метрики, которые помогут измерять эффективность использования серверных ресурсов, а также способы снижения задержек при работе с файлами.

Ответ

Разделите metadata, передачу файлов и фоновые операции; распределённость проектируйте под явно согласованные RPO/RTO, а не обещание доступности без ограничений.

Production. Возможный вариант AWS: EKS в нескольких AZ, RDS PostgreSQL Multi-AZ, S3 с versioning и межрегиональной репликацией, SQS, CloudFront и Route 53. Файлы загружаются напрямую по короткоживущим подписанным URL; API хранит права, версии и metadata. Для пользователей разных регионов задайте регион-владелец записи, избегая несогласованного multi-writer.

DR. Резервный регион, проверенные backups, управляемый failover и защита от двух writers. Асинхронная репликация имеет ненулевой RPO; более строгая согласованность повышает задержку и стоимость. 99,99% подтверждают измерениями и отказными испытаниями.

Staging. Те же версии и схемы доставки, но меньшие мощности и объём данных; межрегиональный DR проверяют отдельными периодическими прогонами.

Управление. Terraform, отдельные state и IAM-roles, GitOps, независимые сборки десяти сервисов, immutable images и совместимые миграции. Secrets — через менеджер секретов.

Обратная связь. SLO по latency/ошибкам, traces, backlog, replication lag, аудит доступа и стоимость на объём файлов. Для производительности измеряйте p95/p99, throughput загрузок, cache hit и насыщение ресурсов. Multipart upload, CDN и размещение ближе к пользователю уменьшают задержку; бюджеты и lifecycle хранения ограничивают расходы.