Спроектируйте отказоустойчивую инфраструктуру веб-сервиса: балансировка, несколько зон доступности, база данных, деплой без даунтайма.
Короткий ответ
- Убрать единые точки отказа на каждом слое
- DNS → CDN/anycast → балансировщик → stateless-приложение
- Минимум две зоны доступности для всех компонентов
- Приложение без локального состояния: сессии в Redis, файлы в S3
- БД: primary с синхронной репликой и автоматическим failover
- Health checks выводят больные инстансы из балансировки
- Rolling или canary деплой с graceful shutdown
Высокая доступность — это избыточность в нескольких зонах, stateless-приложение и отработанный failover каждого слоя.
Как сказать вслух
пример ответаЯ иду по слоям и на каждом убираю единую точку отказа. Трафик входит через балансировщик, растянутый на несколько зон доступности, за ним — автоскейлящаяся группа stateless-инстансов приложения: сессии выношу в Redis, файлы — в объектное хранилище. База — primary с репликой в другой зоне и автоматическим failover, читающие запросы можно отправлять на реплики. Health checks убирают больные инстансы из балансировки, а деплой делаю rolling или канареечным, чтобы обновляться без даунтайма. И обязательно проверяю отказоустойчивость учениями, а не только на бумаге.
Подробный ответ
Основной ответ
Входной слой: DNS с health-чеками и failover, опционально CDN и anycast; управляемый балансировщик (L7) в нескольких AZ. Приложение: stateless-инстансы в autoscaling-группе или Deployment в Kubernetes, распределённые по зонам (topology spread); состояние вынесено — сессии в Redis, файлы в S3-совместимое хранилище, очереди в брокере. Данные: PostgreSQL primary + реплика в другой AZ, автоматический failover (Patroni или managed RDS Multi-AZ), чтение с реплик с учётом лага; Redis — в режиме sentinel/cluster. Деплой без даунтайма: rolling с readiness-пробами, connection draining на балансировщике, graceful shutdown по SIGTERM, обратная совместимость миграций. Дополнительно: ограничение по PodDisruptionBudget, ретраи с таймаутами и circuit breaker между сервисами, бэкапы с проверкой восстановления, регулярные game days. Multi-region — отдельный уровень со своими компромиссами (латентность, консистентность, цена).
Ключевые моменты
- Stateless-приложение. Вынос сессий и файлов из инстансов — предпосылка и для масштабирования, и для безболезненного деплоя.
- Зоны доступности. Каждый слой живёт минимум в двух AZ; падение зоны — штатное событие, а не катастрофа.
- База — самое сложное. Репликация и автоматический failover с пониманием лага и риска split-brain; БД нельзя просто «поставить за балансировщик».
- Graceful deploy. Readiness, connection draining и совместимые миграции дают ноль даунтайма при rolling-обновлении.
Практический контекст
Самый частый system-design на DevOps-собеседованиях; его дают и middle, и senior, различается глубина уточнений: лаг реплик, split-brain, поведение при падении зоны. На практике эта схема — основа почти любого продакшена в облаке. Интервьюер смотрит, рассуждает ли кандидат слоями, называет ли конкретные механизмы failover и честно ли признаёт компромиссы, например что синхронная репликация стоит латентности.
Частые ошибки
- Оставляют единственный экземпляр базы или балансировщика — SPOF в центре схемы
- Хранят сессии и файлы на локальных дисках инстансов приложения
- Заявляют zero-downtime деплой без graceful shutdown и совместимых миграций