Через всі негаразди, через випробування …, Різне, Інтернет-технології, статті

Спостерігається в даний час зростаюча інтенсивність роботи 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>

*

*