Чому додатки e-commerce можуть «впасти» в цю чорну п’ятницю – ТОП-9 причин
Тільки уявіть, скільки ваших потенційних покупців вже передчувають один з головних розпродажів року. Після сплеску онлайн-активності, пов’язаної з карантином, коли онлайн-продажі стрімко росли, а разом з ними і навантаження на ваші сервіси, додатки e-commerce очікує ще одне випробування на міцність.
Напередодні Чорної п’ятниці більшість компаній тестують продуктивність своїх додатків. Багато хто вибирає імітацію навантаження попереднього року і відтворює в тестових середовищах клієнтську активність на рівні минулорічної Чорної п’ятниці. Хоча 75% вузьких місць можна виявити і усунути при тестуванні, на жаль, деякі з проблем виявляються тільки у виробничому середовищі. Це пов’язано з тим, що додатки є занадто складними, щоб їх можна було тестувати в реальних сценаріях. Наприклад, сьогодні більшість додатків e-commerce охоплюють понад 500 серверів, розподілених по безлічі мереж і постачальників послуг.
Які проблеми можуть виникнути і на які моменти варто звернути увагу, щоб не розчарувати клієнтів і не втратити прибуток і репутацію?
Ось 9 основних причин, через які e-commerce-додатки можуть «впасти» в цю Чорну п’ятницю:
1. Пул підключень до бази даних
Майже кожна транзакція при оформленні замовлення буде взаємодіяти з однією або декількома базами даних. Тому з’єднання з цим ресурсом надзвичайно важливі, і саме на цьому рівні часто виникають проблеми, коли кількість паралельних транзакцій зашкалює. Більшість серверів додатків поставляються зі встановленою за замовчуванням конфігурацією пулу з’єднань в межах від 10 до 20. Якщо врахувати, що пропускна здатність транзакцій для додатків e-commerce може легко перевищити 100 тис. транзакцій на хвилину, легко зрозуміти, що конфігурації пулу за замовчуванням не достатньо. Коли пул з’єднань з базою даних вичерпується, вхідні запити онлайн-замовлень просто зависають в очікуванні або відхиляються через тайм-аут, поки з’єднання знову не стане доступним.
Наприклад, як на цьому скріншоті:
2. Відсутні індекси баз даних
Ця першопричина проблем певною мірою пов’язана з вичерпаними пулами з’єднань. Оператори SQL, які виконуються дуже повільно, довше утримують з’єднання з базою даних, тому пули сполук не обробляються з потрібною швидкістю, оскільки запити займають більше часу. Причина номер 1 повільних операторів SQL – це відсутність індексів в таблицях бази даних, яка часто викликана нерозумінням між друкарськими SQL розробниками і адміністраторами баз даних, які налаштовують і підтримують схеми бази даних. Класичне виконання запиту «full table scan» означає, що транзакція і операція бази даних повинні читати всі дані в таблиці, перш ніж буде отримано результат. Ось приклад того, як це виглядає в AppDynamics:
3. Взаємне блокування коду
Високий рівень паралелізму транзакцій часто призводить до того, що потокам сервера додатків доводиться більше боротися за ресурси і об’єкти додатка. Більшість додатків e-commerce мають форму атомарності, вбудовану в їх транзакції, тому обсяги замовлень і запасів контролюються, поки тисячі користувачів «полюють» на спеціальні пропозиції і низькі ціни. Якщо доступ до ресурсу програми не управляється належним чином, деякі потоки можуть опинитися в глухому куті, а це часто може привести до зависання і тайм-ауту сервера додатків і всіх його користувальницьких транзакцій. Один із прикладів такого сценарію стався в минулому році, коли клієнт e-commerce використовував небезпечний кеш-потік. Три потоки намагалися виконати отримання, встановлення і видалення в одному і тому ж кеші одночасно. В підсумку виникло взаємне блокування коду, яке вплинуло на більш ніж 2,5 тис. транзакцій перевірки, як показано на скріншоті:
4. Винятки тайм-ауту сокета
Проблеми зі зв’язком із сервером є очевидною основною причиною «падінь». Якщо перевірити журнали сервера за допомогою Sumologic або Splunk, ймовірно, можна буде побачити сотні таких подій. Це мережеві проблеми або збої маршрутизації, коли транзакція оформлення замовлення намагається зв’язатися з одним або декількома серверами в інфраструктурі додатку. У більшості випадків служби, до яких ви підключаєтеся, не належать вам, наприклад: ресурси постачальника послуг доставки, обробника кредитних карт або засоби виявлення шахрайства. У дні з високою відвідуваністю, такі як Чорна п’ятниця, не тільки ваш сайт відчуває сплеск трафіку – часто цілі мережі переповнюються через високий попит. Через певний час (часто 30-45 секунд) транзакція оформлення замовлення просто завершиться за тайм-аутом і видасть користувачеві помилку. Немає підключення = немає доходу. Ось приклад того, як це виглядає:
5. Прибирання сміття
Кеш – це простий спосіб прискорити роботу додатків. Що ближче дані до логіки додатка (в пам’яті), то швидше він виконується.
Тому не дивно, що в міру того, як пам’ять стає дешевшою, більшість компаній впровадили ту чи іншу форму кешування в пам’яті, щоб виключити доступ до бази даних для часто використовуваних результатів. Настали дні 64- та 128-гігабайтних куп, а це означає, що вплив таких речей, як складання сміття, став більш «небезпечним» для кінцевих користувачів. Збереження кеш-даних та ефективне створення/збереження об’єктів в пам’яті набуває першочергового значення для усунення частих циклів складання сміття. Те, що у вас є гігабайти пам’яті, не означає, що ви можете легковажно ставитись до питань створення, збереження та знищення об’єктів. Ось кілька скріншотів, які показують, як складання сміття може «вбити» вашу програму e-commerce:
6. Транзакції з високим завантаженням ЦП
Не секрет, що неефективна логіка застосування вимагатиме більше циклів ЦП, ніж ефективна логіка. На жаль, у минулому найпопулярніше вирішення проблем зниження продуктивності полягало в тому, що постачальникам e-commerce доводилося купувати більше серверів. Більше серверів = більше потужності = більше пропускної спроможності транзакцій. Хоча цей розрахунок звучить добре, насправді в повному обсязі транзакції e-commerce пов’язані з процесором. Додавання додаткової потужності просто маскує неефективний код у короткостроковій перспективі і може спричинити зайві витрати значних сум у довгостроковій. Якщо певні транзакції в e-commerce-додатку перевантажують або спалюють процесор, ви можете подумати про їх налаштування, перш ніж підписувати черговий рахунок на покупку нового сервера. Наприклад:
7. Сторонні веб-служби
Якщо ваша програма e-commerce побудована на розподіленій архітектурі SOA, у вас буде декілька слабких місць. Особливо, якщо деякі послуги надаються третьою стороною, і у вас немає повної видимості в цих сервісах. Наприклад, більшість послуг з авторизації платежів та кредитних карток надаються сторонніми постачальниками, такими як PayPal. Якщо ця служба уповільнюється або виходить із ладу, транзакції оформлення замовлення не можуть бути завершені. Отже, вам необхідно суворо контролювати ці служби, щоб у разі виникнення проблем мати можливість швидко визначити, з чим пов’язана проблема: з вашим кодом, підключенням чи збою. Ось приклад того, як AppDynamics допоможе вам контролювати сторонні веб-служби:
8. Рекурсивний код
Цей пункт схожий на №6, причому така проблема спалює час, а не ресурси. Наприклад, багато транзакцій e-commerce будуть вимагати дані одночасно з кількох джерел (кешів, баз даних, веб-сервісів). Кожен із цих кіл може бути дорогим і може займати час. Бувало, що одна транзакція пошуку e-commerce викликала ту саму базу даних кілька разів замість виконання однієї операції з використанням процедури, що зберігається в базі даних. Рекурсивні віддалені виклики можуть займати всього по 10-50 мілісекунд кожен, але якщо вони викликаються кілька разів за транзакцію, вони можуть додати цілі секунди до досвіду кінцевого користувача. Наприклад, ось та пошукова транзакція, яка зайняла кілька секунд і зробила 13 тис. звернень до бази даних:
9. Зміна конфігурації
Хоч би як нам хотілося думати, що виробниче середовище «заблоковане» процесом управління змінами, це не так. Трапляються збої, люди роблять помилки, і виправлення іноді застосовуються поспіхом о 2 годині ночі?. Конфігурація сервера програм може бути чутливою, як і мережі або будь-які інші елементи інфраструктури. Можливість аудиту, складання звітів та порівняння змін конфігурації у вашому додатку дає вам миттєву інформацію про те, що конкретна зміна могла призвести до поломки вашої програми e-commerce. Наприклад, AppDynamics може записувати будь-яку зміну сервера додатків і показувати вам час та значення, які були оновлені, щоб допомогти співвіднести зміни із уповільненням та відключеннями, як, наприклад, на цьому скріншоті:
Крім того, AppDynamics також може відстежувати дохід та продуктивність ваших касових транзакцій з часом, що допомагає командам DevOps відстежувати та попереджати про стан бізнесу:
Співвідношення доходів та продуктивності
Ще одна хороша новина: AppDynamics Pro може виявити всі вищезгадані дефекти за лічені хвилини. Можна скористатися безкоштовною пробною версією та оцінити ефективність рішення.