Через усі негаразди

Спостерігається в даний час зростаюча інтенсивність роботи 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-сайтів росте з кожним вдень, їм навряд чи варто сподіватися на що-небудь інше найближчим часом. Але повернемося до приказки, з якої ми почали статтю, – немає лиха без добра. Зрештою менеджери вузлів ЕК, здатні успішно нарощувати їх продуктивність, користуються сьогодні великий попит.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*