Механизм автоматического масштабирования ресурсов в ответ на изменение нагрузки регулярно преподносится как надежная страховка от перегрузки системы в момент реального пикового спроса. Практический опыт множества компаний, полагавшихся на подобную страховку в момент по-настоящему серьезного, значимого для бизнеса всплеска реальной нагрузки, регулярно демонстрирует, что эта страховка способна подвести именно тогда, когда цена подобного отказа максимальна. Первая и, пожалуй, самая распространенная причина подобного разочарования — это недостаточная скорость реакции самого механизма масштабирования относительно реальной скорости роста нагрузки. Даже полностью корректно настроенный механизм неизбежно требует определенного, ненулевого времени на обнаружение факта роста нагрузки, на принятие решения о необходимом масштабе дополнительных ресурсов, и на фактическое развертывание и полную готовность этих дополнительных ресурсов к обслуживанию реального трафика. Для сценариев с достаточно плавным, постепенным ростом нагрузки подобная неизбежная задержка обычно остается практически незаметной, но для сценариев с по настоящему резким, взрывным всплеском спроса, характерным для многих значимых для бизнеса событий, эта неизбежная задержка способна создать весьма ощутимый и болезненный разрыв между реальной, уже наступившей потребностью в дополнительных ресурсах и фактической, все еще недостаточной мощностью уже развернутой инфраструктуры. Вторая причина связана с ограниченной доступностью запрашиваемого типа вычислительных ресурсов именно в момент пиковой нагрузки. Механизм масштабирования способен корректно и своевременно принять решение о необходимости дополнительных ресурсов, но столкнуться с тем, что запрашиваемый конкретный тип инстанса просто физически недоступен у облачного провайдера именно в данный конкретный момент времени, особенно если пиковая нагрузка вашего собственного бизнеса совпадает по времени с аналогичным пиковым спросом множества других клиентов того же самого облачного провайдера на тот же самый популярный тип ресурсов, что создает своего рода конкуренцию за ограниченно доступную мощность именно в тот самый момент, когда эта мощность нужнее всего. Третья причина связана с недостаточно продуманной конфигурацией верхнего предела масштабирования, о важности явного ограничения которого я упоминал в отдельной статье про предотвращение неконтролируемого роста расходов. Верхний предел, установленный из осторожных, консервативных соображений экономии бюджета в спокойные времена без реального пикового спроса, способен оказаться попросту недостаточным для по настоящему значимого события, и механизм масштабирования, честно уперевшись в этот заранее установленный предел, оказывается неспособен предоставить системе действительно необходимый объем дополнительных ресурсов, вне зависимости от того, насколько остро эти ресурсы реально требуются в данный конкретный момент. Четвертая причина связана с узким местом производительности, находящимся вовсе не в том компоненте системы, который реально масштабируется автоматически. Приложение способно успешно и своевременно масштабировать количество своих собственных экземпляров, но упереться в производительность какой то другой, недостаточно масштабируемой зависимости, вроде центральной базы данных, изначально спроектированной без учета необходимости подобного же динамического масштабирования, что делает автоматическое масштабирование самого приложения фактически бесполезным, потому что реальным узким местом производительности всей системы оказывается совершенно другой, не подвергшийся масштабированию компонент. Пятая причина связана с недостаточно продуманной готовностью только что развернутых, дополнительных экземпляров приложения к реальному обслуживанию трафика сразу после их фактического появления.