Наблюдающаяся в настоящее время растущая интенсивность работы Web-узлов электронной коммерции (ЭК) неизбежно приводит к появлению в сетевой архитектуре большого числа потенциально узких мест, не справляющихся с нахлынувшей лавиной клиентских запросов. О методах обеспечения бесперебойной работы Web-узлов в условиях постоянно возрастающей нагрузки мы и попытаемся рассказать в этой статье.
Вы, наверное, помните известную старую поговорку о том, что нет худа без добра? Так вот, по отношению к Web-узлам она зачастую справедлива с точностью до наоборот. Успех, популярность, ассоциируемые с возрастанием трафика, могут в одночасье привести к полнейшей парализации Web-узла. Резкое снижение его производительности отвращает от него потенциальных покупателей, многие из которых уже никогда не вернутся назад. Действительно, согласно исследованиям, проведенным фирмой Jupiter Communications, 46% посетителей покинули свои излюбленные Web-узлы из-за неприемлемого (с их точки зрения) снижения скорости их работы. При этом только 24% от этого числа вернулись снова, и то только после общения с W eb-узлами конкурентов.
Но резкое увеличение трафика - не единственная проблема, с которой приходится сталкиваться разработчикам Web-узлов. Их сетевая инфраструктура становится все сложнее и сложнее, включая в себя Web-серверы, серверы приложений промежуточного уровня, серверные базы данных и широкий перечень других специализированных систем. Все это приводит к увеличению числа элементов, способных стать потенциальными источниками перегрузок сети.
Итак, что же нужно делать, чтобы успешно преодолеть тяжелые испытания, выпавшие на долю вашего узла ЭК? Да, в целом эта задача не из простых, но при грамотном управлении сетевыми и системными ресурсами, имеющими в своем составе СУБД, высокоскоростные процессоры, распределители нагрузки, каналы связи и устройства кэширования, ее все же можно решить. Хотя каждый Web-узел по-своему индивидуален, менеджеры наиболее популярных узлов имеют одну общую черту: они очень хорошо понимают, что значит высокая производительность узла для их бизнеса. "Если ваш Web-узел не отличается поистине уникальным и неповторимым содержимым, - а чаще всего так оно и есть, - производительность ниже определенной нормы просто погубит ваш бизнес, - говорит Серж Уилсон, главный исполнительный директор Web-узла freemerchant.com, на котором размещено более 36 000 интерактивных магазинов. - Люди всегда могут обратиться в другой подобный магазин и никогда больше не вернутся назад". Многие ветераны ЭК, так же как и Уилсон, отдают себе отчет в том, что стоять на месте - смерти подобно и нужно действовать, действовать и действовать.
"Сегодня, когда нагрузка на Web-узлы растет с фантастической скоростью, никакое интуитивное заблаговременное планирование пропускной способности сети не дает результатов, - продолжает Уилсон. - Вы радуетесь, что все держите под контролем, но гарантировать, что это так на самом деле, можно, лишь затратив четверть миллиона долларов на приобретение дополнительного оборудования".
Кроме того, менеджеры процветающих Web-узлов хорошо представляют себе характер проблем, способных повлиять на снижение скорости, с которой информационное наполнение узлов электронной коммерции доставляется клиентам, - от перегрузки каналов связи поставщиков услуг Интернет, обслуживающих конечных пользователей, до "заторможенных" серверных баз данных Web-узлов. "Вы должны тщательно проанализировать архитектуру своего узла и постараться понять, какие проблемы можно полностью устранить обычным усилением контроля и какие попытаться компенсировать", - отмечает Рич Секор, главный управляющий фирмы SmarterKids.
Не спускайте глаз с СУБД
Одна из причин, снижающих производительность узла ЭК по мере возрастания интенсивности трафика, - это неэффективное взаимодействие серверных приложений с базой данных. "Многие Web-узлы были построены с использованием СУБД с архитектурой клиент-сервер, - говорит Даниел Селцер, генеральный директор Alterity Partners LLC - компании, занимающейся консалтингом в области электронной коммерции. - И вся проблема в том, что клиент-серверные решения имеют слишком слабые возможности масштабирования, не позволяя тем самым обслуживать тысячи одновременно обратившихся к узлу пользователей".
Очень часто масштабирование систем, на которых размещены серверные базы данных, связано с техническими трудностями и большими финансовыми затратами. Так как для обеспечения эффективной работы приложений требуется держать всю необходимую информацию в одном месте, то под базу данных узла ЭК выделяется, как правило, всего одна машина. Когда же возникает необходимость повысить пропускную способность узла, его администраторам приходится заменять старый сервер БД на более мощный новый, а это, естественно, всегда связано со значительными денежными затратами. Другими словами, модернизировать узел ЭК в данном случае можно только за счет значительного скачкообразного увеличения капитальных затрат на соответствующее оборудование. И вдобавок ведущие производители СУБД лицензируют свои продукты, основываясь на мощности ЦПУ используемого сервера. Таким образом, приобретая новое оборудование, следует учитывать и затраты, обусловленные существенным увеличением лицензионных платежей.
Все это говорит о том, как важно из уже имеющейся платформы СУБД суметь выжать максимум производительности. В этом вам помогут такие методы, как использование хранимых процедур и тщательная настройка функций кэширования, позволяющие разгрузить ядро СУБД.
Другим, не менее эффективным методом оптимизации серверных баз данных является организация пула БД (database pooling), предусматривающая введение дополнительного иерархического уровня, который обеспечивает управление процедурами взаимодействия с базой данных. Этот уровень размещается между самой БД и ее многочисленными пользователями. Благодаря ему СУБД не приходится открывать одни и закрывать другие соединения всякий раз, когда посетители Web-узла запрашивают информацию из базы данных.
Сегодня некоторые администраторы узлов пытаются найти приемлемые способы распределения своих баз данных по нескольким относительно недорогим машинам. "Привязать 80 Web-серверов к одному многопроцессорному серверу базы данных - не самый эффективный с точки зрения повышения производительности путь, - говорит Секор (SmarterKids). - Мы собираемся разделить базу данных на отдельные части таким образом, чтобы серверное приложение могло находить разные данные, хранящиеся на разных машинах". Кроме того, использование нескольких недорогих систем позволит Секору наращивать производительность СУБД поэтапно - аналогично тому, как он делает это с Web-серверами, - а не связывать себя большими затратами на приобретение более дорогих мультипроцессорных систем.
Между СУБД и Web-серверами многих узлов ЭК реализуются приложения, обеспечивающие поиск товаров, совершение покупок и другие типы интерактивных функций. Именно на этом уровне менеджеры узлов обязаны уделить особое внимание мониторингу показателей загруженности системы, таких, как коэффициент использования процессора и размеры очередей задач. Но вот параметры достигли определенных пороговых значений - значит, пришла пора устанавливать более производительное аппаратное обеспечение для поддержки ПО, работающего на пределе возможного.
Но ограниченные возможности оборудования - это не единственное потенциально узкое место промежуточного прикладного уровня. Обусловливать недостаточные возможности масштабирования программного обеспечения может сама его архитектура. "Не следует допускать, чтобы отдельные компоненты или объектные модули приложений были слишком "раздутыми" и занимали чрезмерно много места в оперативной памяти, - предупреждает Патрик Фочер, директор по развитию бизнеса узла BuyItOnline. - Если такое случится, вам придется так или иначе наращивать системные ресурсы".
Сказанное выше объясняет, почему менеджеры успешно функционирующих узлов ЭК так тщательно отслеживают все прикладные процессы, используя для этого инструментальные средства, подобные Mercury Interactive фирмы Astra и MasterIT компании Computer Associates. Если какой-либо отдельный программный компонент начинает слишком медленно реагировать на запросы, это может означать, что его следует разукрупнить. "В таком случае возникающая в некий момент критическая нагрузка уже не будет концентрироваться на каком-либо одном программном модуле, а в той или иной степени распределится между несколькими модулями", - разъясняет Фочер.
Существуют также и очевидные приемы управления узлом ЭК, позволяющие уберечь серверы от чрезмерных перегрузок. Такие задачи, как размещение нового информационного наполнения узла или автоматическая отправка сообщений по электронной почте, не должны решаться в режиме реального времени. "Задачи, не связанные с обработкой запросов конечных пользователей, лучше всего выполнять в пакетном режиме, - полагает Уилсон (freemerchant.com). - Таким образом можно освободить серверы от решения подобных проблем и сэкономить ресурсы ЦПУ".
Тестирование новых прикладных модулей на небольшом числе серверов приложений до их окончательного развертывания в масштабах всего узла ЭК тоже неплохая идея. "Функционирование новой программы на автономной тестовой машине не соответствует в точности ее функционированию в реальной рабочей среде, - отмечает Уилсон. - Но уж если обнаружатся проблемы, то будет лучше, если они отразятся лишь на незначительной части ваших пользователей, чем сразу на всех".
Уровень серверов приложений узлов ЭК скрыт за фасадом, образуемым их Web-серверами, которые обрабатывают HTTP-запросы и статические Web-страницы. В отличие от баз данных такое информационное наполнение можно легко распределять по нескольким серверам, так что при необходимости сетевые менеджеры могут всегда установить дополнительные системы. Вся хитрость здесь кроется в том, чтобы наиболее эффективно распределить нагрузку между всеми имеющимися ресурсами. Вот тут-то и приходит черед распределителей нагрузки.
Сохраняйте равновесие
Последние несколько лет технология балансировки нагрузки, возникшая как результат целенаправленных попыток производителей помочь сетевым администраторам справиться с наиболее коварными проблемами производительности, развивалась достаточно быстрыми темпами.
Если первоначально средства балансировки всего лишь распределяли запросы по Web-серверам, опираясь на результаты простого мониторинга их относительной нагрузки, то теперь они выполняют и ряд других, более сложных функций - контролируют не только сами Web-серверы, но и серверы приложений, CGI-серверы и другие специализированные системы, спрятанные за их "спиной". Таким образом, распределитель нагрузки никогда не направляет пользовательский запрос на машину, ресурсы которой полностью исчерпаны, хотя она и не проявляет внешних признаков перегрузки.
Но, чтобы полностью воспользоваться всеми преимуществами средств балансировки нагрузки по устранению узких мест Web-узлов, настраивать их менеджеры должны очень тщательно. Только тогда они будут эффективно распределять задачи между многочисленными серверами.
С помощью распределителей нагрузки можно также устранить другую проблему, с которой приходится сталкиваться администраторам узлов ЭК и которая связана с серверами SSL. Дело в том, что эти серверы, управляющие процессами шифрования, необходимого для организации безопасного обмена данными, очень легко перегрузить. Интенсивные вычисления, связанные с генерацией ключей шифрования, так сильно загружают процессор, что сервер, способный поддерживать до 1000 обычных сеансов HTTP, осиливает лишь около десятка сеансов SSL. Это может серьезно повлиять на производительность интерактивного узла розничной торговли или любого другого узла, передающего большие объемы информации по протоколу SSL. Если узел устроен таким образом, что всякий раз, когда посетитель переходит от одного информационного раздела Web-сервера к другому, устанавливается новый защищенный сеанс связи, ситуация может еще более осложниться.
Еще одна проблема связана с тем, что многие пользователи получают доступ к Интернет через поставщика услуг, использующего серверы-посредники, которые могут изменять IP-адреса прямо в ходе сеанса связи. Если это происходит, сервер SSL генерирует новый ключ шифрования, а это значит, что вероятность его перегрузки резко возрастает.
Помимо того что администраторам узлов ЭК необходимо предпринимать все меры, чтобы не допустить перегрузки SSL-серверов, Web-серверов, прикладных серверов и серверов баз данных, а также программного обеспечения, установленного на них, они еще должны не упускать из виду связывающую их сетевую инфраструктуру. Ведь увеличение числа машин, подключаемых к каждому коммутатору, может привести к насыщению высокоскоростных каналов связи. Таким образом, базовые меры по мониторингу загрузки различных компонентов, планированию их производительности и установлению порогов для системных параметров играют весьма существенную роль в устранении слабых мест Web-узлов электронной коммерции.
Какая полоса пропускания вам нужна?
Конечно, самые большие проблемы, связанные с работой сети, с которыми администраторам узлов приходится сталкиваться на практике, имеют отношение не столько к внутренней инфраструктуре этих узлов, сколько к организации их взаимодействия с внешним миром. Не так давно администраторам узлов ЭК приходилось мучительно решать, какой ширины каналы связи с Интернет им следует покупать. При этом они нередко попадали впросак, если во время всплеска трафика работа их узлов резко замедлялась. В настоящее время большинство менеджеров крупных узлов ЭК прибегают к услугам разных поставщиков одновременно. Это позволяет заметно разгрузить каналы связи с Интернет. "Использование услуг нескольких Интернет-провайдеров - лучший из всех вариантов, которые вы можете использовать, ибо такое решение позволяет мгновенно увеличивать полосу пропускания, - говорит Уилсон (freemerchant.com). - Это единственный способ, полагаясь на который вы всегда сумеете справиться с любым сколь угодно резким возрастанием спроса на ваши товары, когда ваш узел ЭК вступит в пору настоящего расцвета".
Это, правда, не означает, что Интернет перестает "осчастливливать" менеджеров узлов ЭК проблемами, связанными с их производительностью. Перегрузка магистрали, неэффективный взаимный обмен сетевым трафиком (или пиринг - peering) и большие расстояния все еще могут быть причиной замедления доставки информации на ПК конечного пользователя. Хотя эти факторы и неподконтрольны администраторам узлов, все же имеется ряд способов, позволяющих нейтрализовать их негативное влияние.
Одно из таких решений - использование специальной услуги "интеллектуального пиринга", предоставляемой, в частности, узлом обмена трафиком InterNAP. Последний тщательно отслеживает состояние магистралей, связывающих поставщиков услуг Интернет с остальной Сетью, и на основании полученных результатов принимает решение по маршрутизации трафика конечных пользователей или групп пользователей, выбирая наименее загруженные маршруты. Возможность динамической смены используемых для передачи трафика маршрутов позволяет InterNAP направлять информацию узла в обход любого участка магистрали, испытывающего периодические перегрузки.
Другой способ, обеспечивающий более быструю доставку информации пользователям, предусматривает размещение ее как можно ближе (логически либо географически) к последним, применяя для этого услуги кэширования, предлагаемые некоторыми поставщиками, например Akam a i. "Akamai обеспечивает нам надлежащую пропускную способность магистралей Интернет, - отмечает Секор (SmarterKids). - Целесообразность использования ее службы кэширования очень легко обосновать экономически, поскольку затраты на нее с лихвой компенсируются снижением расходов на полосу пропускания, которую нам приходится покупать".
Конечно, как вам скажет любой менеджер по качеству, нельзя улучшить то, что нельзя измерить. Следовательно, увеличить до максимума производительность узла ЭК вам поможет хорошая система контроля текущего состояния пользовательских линий. Многие администраторы узлов делают это, что называется "с изнанки", отслеживая время, необходимое их системам для обработки запросов в периоды пиковой активности. Но при таком подходе вы можете так и не узнать, какие проблемы мучают пользователей, подключенных к разным поставщикам услуг Интернет, работающим на разных скоростях и использующих ПК самых разных конфигураций. Чтобы получить более полное представление о том, как все эти факторы влияют на производительность Web-узла, их администраторы обращаются к специальным службам мониторинга, например таким, как Keynote. Эти службы непрерывно отслеживают параметры доступа к заданным указателям ресурсов (Uniform Resource Locator - URL) из самых разных точек сети Интернет. Помимо того, что эти точки зондирования (sampling points) связаны с разными поставщиками услуг Интернет через коммутируемые и широкополосные каналы связи, в них могут размещаться персональные компьютеры с разными конфигурационными параметрами. Получаемая в результате зондирования статистика позволяет администраторам судить о том, насколько успешно их узлы ЭК преодолевают хронические проблемы производительности, а также о том, каким образом принимаемые ими меры реально уменьшают эти проблемы.
Фактор реальности
Принимая во внимание ряд рассмотренных в статье средств и методов преодоления узких мест архитектуры узлов ЭК, а именно комбинированный доступ к Интернет, комплексные службы кэширования, многофункциональные средства распределения нагрузки и растущую производительность процессоров, казалось бы, можно сделать вывод о том, что уж теперь-то их менеджеры могут справиться с любой проблемой, связанной с нехваткой производительности. К сожалению, дело обстоит совсем не так, и на то существуют две причины.
Первая, как всегда, связана с деньгами. Ведь никто на свете не располагает неограниченным бюджетом. Это заставляет администраторов узлов ЭК тщательно рассчитывать инвестиции в инфраструктуру. "В этом деле нужно, несомненно, использовать сбалансированный подход, - говорит Секор. - Иначе вы можете потратить все средства на устранение одного узкого места, оставив нетронутыми другие". Вторая причина - люди. Чтобы менеджеры узлов могли воспользоваться преимуществами большего числа серверов, разнообразных технологий и усовершенствованных архитектур, им нужен знающий, опытный технический персонал, позволяющий реализовать все их замыслы и организовать эффективную работу систем. К сожалению, найти таких людей - большая проблема.
Учитывая все вышеизложенное, можно сделать вывод, что работа сетевых администраторов, по-видимому, еще долгое время будет оставаться нервной и напряженной. И хотя число посетителей Web-узлов растет с каждым днем, им вряд ли стоит надеяться на что-либо иное в ближайшее время. Но вернемся к поговорке, с которой мы начали статью, - нет худа без добра. В конце концов менеджеры узлов ЭК, способные успешно наращивать их производительность, пользуются сегодня большим спросом.