Comments 5
Ожидал прочитать про Kubernetes, autoscaling, какие параметры приложения являются ключевыми для определения, что нужна еще одна реплика.
Я правильно понял из написанного, что вы руками задаете количество серверов в соответствии с тем, что вам рассказал отдел маркетинга? Я вижу тут кучу места для оптимизации костов, ибо, ожидания и реальность не всегда совпадают. Ну и не понятно зачем нужны включенные сервера, если нагрузки еще/уже нет.
Также не совсем понятно, что значит "Здесь же запускаем на полную мощность дополнительные сервера." Сервер он либо работает, либо не работает. Это значит, что вы начинаете на него давать больше трафика? Сколько давать трафика и как распределять его между репликами тоже вручную решается?
ожидал прочитать про Azure Service Fabric.
Отвечаю на вопросы по пунктам:
0) Статья о комплексной подготовке к пику, а не только про сервера
1) Да, сейчас мы вручную расчитываем количество машин и их мощность под планируемую нагрузку, но разворачиваем их автоматически ансиблом.
1.1) Много костов тут не сооптимизируешь, так мы ищем баланс между стабильностью работы и ценой за сервера, то есть можно пару дней переплатить, но быть уверенным, что все работает стабильно.
1.2) Сервера у нас виртуальные, мы их можем держать маленькими и подавать туда проценты боевого траффика, таким образом быть уверенными, что они на 100% рабочие
2) Между репликами БД распределяет балансировщик, мы только следим за достаточностью ресурсов
Как масштабировать сервис в 20 раз и свернуть обратно за один день