Управление реактивным масштабированием в облачных сервисах

Реактивное масштабирование — это очень хорошее и мощное средство, но прочный канат ведь можно использовать не только для страховки, но и для того, чтобы, скажем, взять и повеситься. Реактивное масштабирование позволяет вам очень быстро реагировать на неожиданное возрастание потребностей в ресурсах. Но если вы не будете выполнять никакого планирования мощностей, а вместо этого целиком и полностью положитесь на реактивное масштабирование вашего Web- приложения, вы очень быстро обнаружите, что вместо ожидаемой пользы оно может нанести вам серьезный ущерб.

Самая грубая форма реактивного масштабирования — это реактивное масштабирование, основывающееся на фактическом потреблении. Иными словами, в тот момент, когда потребление ресурсов CPU, RAM или каких-либо других ресурсов достигает определенного уровня, вы просто добавляете дополнительные объемы нужных ресурсов в вашу среду. Это очень серьезно упрощает логику системы мониторинга, но в реальной жизни вам все-таки требуется некоторое время на размышления. Мы уже видели несколько примеров, когда такой подход терпит неудачу.

± Добавление сервера приложений, когда проблема вызвана снижением производительности операций дискового ввода/вывода на сервере базы данных. В результате нагрузка на сервер базы данных от этого еще более возрастет, и это только усугубит ситуацию.

± Атака, на преодоление которой вы начинаете наращивание ресурсов. В результате ваше потребление начинает расти, "раскручиваясь по спирали", в результате чего вы ничего не добьетесь, а только резко повысите ваши расходы на ресурсы.

± Неожиданный "всплеск" активности в Web, который начинает влиять на ваши затраты на инфраструктуру, но слабо влияет на работу конечных пользователей. Вы знаете, что эта активность скоро спадет, но ваша система мониторинга "тупо" наращивает мощности, просто потому, что имело место резкое возрастание нагрузки.

Хорошая система мониторинга должна предоставлять такие инструменты, которые позволяют сглаживать эти потенциальные проблемы, вызванные реактивным масштабированием. Однако я еще не видел такой системы, которая бы при таком сценарии действовала идеально. Для этого требуется логика, позволяющая выделить проблемную область и проанализировать активность с тем, чтобы определить ситуации, в которых имеет смысл запускать новые экземпляры, а в каких — нет. Здесь, к сожалению, никакой алгоритм пока не может сравниться с человеческой интуицией.

Тем не менее, ваша система мониторинга может определять правила для реактивного масштабирования, и вы всегда должны иметь в ней регулятор, который может взять управление на себя. Этот регулятор устанавливает пределы, ограничивающие количество ресурсов, которые может автоматически задействовать система мониторинга. За счет этого вы имеете некоторую возможность ограничить финансовые затраты, которые мониторинговая система может предпринять от вашего имени. Если на вашу инфраструктуру предпринята атака, то система мониторинга может со временем достигнуть предела, установленного вашим ограничителем, но от этого вы не перестанете тратить деньги на безумное количество экземпляров, запущенное в вашей облачной среде.

Наконец, есть еще один аспект, влияющий как на превентивное, так и на реактивное масштабирование (но в большей степени — на реактивное). Этой проблемой является подверженность ошибкам интерфейсов прикладного программирования Amazon S3 и AWS. Если вы рассчитываете на реактивное масштабирование в надежде на то, что у вас всегда будет достаточно ресурсов, то проблемы с Amazon S3 ослабляют ваши планы. Ваша система рано или поздно обманет ваши ожидания.

Рекомендуемый подход

Я не являюсь ярым сторонником реактивного масштабирования, но оно находит свои области применения. При управлении своей инфраструктурой я предпочитаю полагаться на превентивное масштабирование на основе прогнозируемой потребности, включая избыточные мощности, в два раза превышающие ожидаемую нагрузку и верхние пределы ожидаемых нагрузок (от трех до пяти среднеквадратичных отклонений от ожидаемого уровня). При такой настройке реактивное масштабирование обычно почти никогда и не требуется.

Неожиданный рост потребностей действительно существует. Вместо использования реактивного масштабирования в ответ на непредвиденное возрастание нагрузки я обычно даю время персоналу проанализировать ситуацию и отреагировать соответственно. Мои ограничители обычно установлены на значения от 150 до 200 % от базовой конфигурации. Иными словами, если моя базовая конфигурация состоит из двух серверов приложений, и мое приложение может масштабироваться до 200 % от базовой конфигурации за счет добавления двух дополнительных серверов приложений, я устанавливаю лимит масштабирования и конфигурирую мониторинговую систему таким образом, чтобы она заранее выдавала предупреждение при необходимости добавить хотя бы один.

В результате такого применения реактивного масштабирования я получаю возможность управляемого автоматического масштабирования моей инфраструктуры в ответ на неожиданный рост нагрузки, но только до определенного предела. Кроме того, я также должен иметь время на анализ аномальной активности с тем, чтобы определить, должен ли я поднять ограничения по масштабированию, изменить мою базовую конфигурацию или же просто проигнорировать происходящее. Поскольку моя инфраструктура не работает на пределе мощности, и я не полагаюсь на реактивное масштабирование, сбои Amazon S3 вряд ли окажут на мою инфраструктуру негативное влияние.

Хотя приведенные мною показатели могут не иметь никакого смысла для вашего Web-приложения, но общая политика должна быть вам понятна, и, как я надеюсь, она и вам будет служить так же хорошо, как и мне. Какими бы ни были абсолютные показатели для вашего приложения, вы в любом случае должны определить бюджет, который позволит вам работать на пределе мощности, по крайней мере, до тех пор, пока не будет согласовано и одобрено расширение бюджета. Если ваш бюджет одобрен для ожидаемых мощностей, а вы обнаруживаете, что начали работать не пределе, установленном вашими ограничителями, вряд ли это обрадует финансовый отдел вашей компании.

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100