Ценность ваших вычислительных мощностей в облачных сервисах

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

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

Web-приложения не настолько стандартны и шаблонны. Обычно Web-сайт поддерживает десятки или даже сотни сценариев использования, каждый из которых имеет собственную ценность для бизнеса. Ценность сайта, поддерживающего систему электронной коммерции, сильно отличается от ценности блога директора по маркетингу. Поэтому 100 % всплеск активности, относящийся к успешному запуску продукта, гораздо важнее, чем такой же всплеск активности, вызванный записью в блоге директора и ссылками на нее из Twitter.

Простой мысленный эксперимент

Рассмотрим простейший пример, объясняющий смысл обсуждаемых вопросов. Представьте себе, что у нас есть простое Web-приложение, работающее с корпоративным контентом, который служит основным инструментом продаж. Мы пользуемся модулем SalesForce.com Web2Lead1 для получения руководящих указаний с Web-сайта и переноса этой информации в SalesForce.com. Интранет-компонент, поддерживающий этот Web-сайт, позволяет коллективу отдела маркетинга планировать рекламные кампании, формировать целевые страницы (landing pages) и вести базовую отчетность.

Допустим, что на Web-сайте наблюдается внезапный и неожиданный всплеск активности. Поскольку уровень нагрузки приближается к предельному, поддерживаемому имеющимися вычислительными мощностями, нам необходимо решить, что следует делать дальше: наращивать мощность или просто переждать данный всплеск активности?

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

± Как нехватка мощностей повлияет на посетителей сайта?

± Является ли данный всплеск активности нормальной реакцией на повышение интереса пользователей к системе (т. е. является ли он результатом нормальной деятельности)? Нет ли еще более серьезной проблемы, о которой необходимо задуматься (не есть ли это признак производимой на сайт DoS-атаки)?

± Следует ли ожидать дальнейшего повышения активности? Приблизились ли мы к пиковой мощности?

± В какие суммы обойдется нам бездействие (т. е. что произойдет, если мы пустим ситуацию "на самотек"?). Что обойдется нам дороже: добавление дополнительных мощностей или тактика выжидания?

В рассматриваемом примере предположим, что все операции по масштабированию выполняются вручную. Теперь нам необходимо провести некоторые исследования. Представьте себе, что на поставленные вопросы мы дали следующие ответы:

± Как нехватка мощностей скажется на посетителях сайта? Поскольку мы приближаемся к предельной мощности, работа нашего Web-сайта замедлится, и будет замедляться до тех пор, пока система не прекратит обрабатывать вводимые пользователями регистрационные данные (входные имена и пароли). Если

1 Формы Web-to-Lead (Web2Lead) представляют собой основной компонент автоматизации деятельности отделов маркетинга и продаж. Их цель заключается в захвате данных, предоставленных посетителями Web-сайта (например, таких как контактная информация и сведения о заинтересованности в тех или иных продуктах) и сохранении их в виде записей (Lead) в базе данных продуктов CRM (в данном случае Salesforce.com). Подробнее см. http://www3.formassembly.com/blog/tutorial-how-to-create- a-salesforce-web-to-lead-form/. — Прим. перев.

система  слишком  перегружена,  скорость  работы  сайта  замедлится до  такой степени, что пользоваться им станет невозможно.

± Считаем ли мы этот всплеск нормальным и законным? Анализ трафика показывает, что запись в блоге директора по маркетингу содержит нечто, вызвавшее повышенный интерес пользователей и средств массовой информации. Блог находится под мощным "обстрелом", но весь остальной трафик сайта выглядит абсолютно нормальным.

± Стоит ли ожидать ухудшения ситуации? Это маловероятно, и трафик пошел на спад. Но, может быть, это просто временное "плато"?

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

± Ответ. Мы выбираем наращивание мощностей. Это не принесет нам большой выгоды, но и стоит совсем недорого.

Насколько различными могут оказаться исходы?

Наиболее важный урок, извлеченный из рассмотрения описанного примера, заключается в понимании того, насколько разными могли бы быть результаты тех или иных действий, если бы сайт не был развернут в облачной среде. Затраты на наращивание мощности могли бы оказаться огромными, а к моменту получения нового сервера необходимость в нем могла бы уже отпасть.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 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