Кто принимал решение о количестве инстансов сервиса?
Что проверяют
Вопрос про ваш прошлый проект: участвовали ли вы в решениях об эксплуатации или только писали код, который кто-то потом запускал. Следом обычно спрашивают, от чего отталкивались при расчёте и как сервис вёл себя при росте нагрузки.
Как отвечать
Сначала честно назовите, кто решал: команда сервиса, SRE или DevOps, техлид. Затем покажите, что понимаете, на чём такое решение строится:
- замер ёмкости: нагрузочный тест (Locust, k6) показывает, сколько запросов в секунду держит один инстанс при приемлемой задержке по p95 или p99;
- запас и отказоустойчивость: минимум две-три реплики, чтобы падение одной или выкладка не роняли сервис, разнесение по узлам и зонам,
PodDisruptionBudgetв Kubernetes; - автомасштабирование:
HorizontalPodAutoscalerсminReplicasиmaxReplicasпо CPU или по своим метрикам, а воркеры очередей масштабируют по длине очереди, например через KEDA; - стоимость: лишние реплики стоят денег, а их нехватка стоит пользователей.
Для Python добавьте то, что отличает его от других стеков. Из-за GIL один процесс интерпретатора выполняет Python-код на одном ядре, поэтому решение двухуровневое: сколько подов и сколько воркеров внутри каждого. Для синхронного gunicorn документация предлагает начинать с 2 × ядра + 1 воркеров, у uvicorn их обычно ставят по числу ядер. Много маленьких подов с одним воркером и несколько крупных с пачкой воркеров по-разному ведут себя и по памяти, и по балансировке.
Если решали не вы, так и скажите, но покажите, что знаете цифры своего сервиса: сколько было реплик, какая нагрузка, срабатывал ли автоскейлинг.
Где спотыкаются
Отвечают «это решали девопсы, я не в курсе». Разработчик должен хотя бы знать, сколько экземпляров его сервиса работает и почему.
Приводят «99,9% доступности» как результат своего решения, не понимая, как это считалось. Лучше назвать реальные замеры.
Масштабируют по CPU сервис, который упирается в базу или во внешний API. Новые реплики только открывают больше соединений и ухудшают ситуацию.