Балансировка для высоконагруженного API
Вопрос
Интервьюер: «API получает 50 тысяч запросов в секунду. Как устроите балансировку от DNS до приложения?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Уровни: DNS или anycast, L4-балансировщики, L7-прокси, приложения
Отказоустойчивость самих балансировщиков: несколько экземпляров, VRRP или облачный LB
Выбор алгоритма и health checks, быстрый вывод мёртвых узлов
TLS-терминация, keepalive к бэкендам, лимиты и защита от DDoS
Наблюдаемость: метрики балансировщика, логи с временем upstream
Масштабирование и тесты под нагрузкой
Что могут спросить следом
- Где вы будете завершать TLS и почему?
- Что будет, если один L7-узел начнёт отвечать медленно?
Разбор
Образцовый ответ: «Снаружи облачный сетевой балансировщик или пара L4 на своём железе с VRRP, на них DNS. За ними горизонтально масштабируемый слой L7: nginx или Envoy, каждый узел выдерживает, скажем, 10-15 тысяч RPS, так что 6-8 узлов с запасом на отказ зоны. TLS завершаю на L7, сертификаты автоматизированы, внутрь иду по keepalive. Алгоритм least_conn или two random choices, активные health checks у Envoy или пассивные у nginx плюс короткий connect timeout, чтобы быстро уходить с мёртвых узлов. На L7 лимиты по ключу клиента, отсечение тяжёлых запросов, от объёмного DDoS защищает провайдер. Метрики: RPS, коды, латентность upstream по каждому узлу, насыщение соединений. Медленный L7-узел ловится по метрикам и выводится health check L4. Всё проверяю нагрузочным тестом с отключением узла».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.