Межа міцності веб-сервісу, або як розігріти «холодний» кеш



Межа міцності — механічне напруження, вище якої відбувається руйнування матеріалу. Інакше кажучи, це порогова величина, перевищуючи яку механічне напруження зруйнує якесь тіло з конкретного матеріалу.
Межа пружності і межа міцності зазвичай проходять у шкільній програмі приблизно разом з загоном Гука (деформація зростає лінійно від прикладеної сили), підкреслюючи область застосування цього закону. При роботі з великими навантаженнями (сотні і тисячі запитів в секунду) модель міцності матеріалів фізичних дуже добре описує поведінку веб-сервісу під навантаженням і характер його відмови у разі перевищення навантаженням «межі пружності».

Далі я розповім, як можна використовувати цю модель, щоб впоратися з великим навантаженням і вирішити завдання «прогріву» холодного кешу для веб-сервісу (новинного порталу, інтернет-магазину або SaaS), яку нам іноді доводиться вирішувати у разі повного скидання кешу сайтів.

«Межа пружності» веб-сервісу
Знання «межі» оптимальної роботи веб-сервісу важливо при забезпеченні його стабільності. Зрозуміло, що в разі DDoS ця межа може бути перевищено в десятки, сотні або тисячі разів, але в разі щоденної відвідуваності сплески (вже достатньо велике навантаження) будуть тільки трьох-п'ятиразовими: тобто досить мати 5-кратний запас «міцності» по відвідуваності веб-сервісу, щоб гарантувати стабільну його роботу в 99,9% випадків. Тут і далі мова йде про денну відвідуваність 100 тисяч відвідувачів і вище.

Навіть якщо у вас немає п'ятикратного запасу міцності, то розуміння, де конкретно знаходиться «межа» стабільності, і як після проходження цієї межі сервіс буде себе вести, — корисно. Хто обізнаний, той озброєний.

Як знайти цю межу? Він буде характеризуватися двома особливостями:
  1. Час відповіді сервера після проходження межі буде рости швидше, ніж до нього («зламається» лінійність зростання часу відповіді сервера).
  2. З'являться мережеві або серверні помилки (сервер(и) не буде встигати обробляти всі запити).
Якщо у вас зараз відсутні помилки при роботі веб-сервісу, то, швидше за все, ви ще не дійшли до цього краю, і варто скористатися будь-яким генератором навантаження (Яндекс.Танк, JMeter, ab, http_load, LoadImpact або будь-яким іншим), щоб до цієї межі дійти. Наприклад, на графіку нижче «перегин» залежно часу відповіді від кількості одночасних запитів настає приблизно за 45 запитів у секунду. Якщо при цьому (або при трохи більшому навантаженні) починають виникати помилки (502, 504, connect timeout) — це і є шуканий межа.



Практичне використання «межі пружності»
У практичних цілях отримана величина навантаження (коли веб-сервіс ще працює нормально, але при невеликому — близько 10% — підвищення навантаження вже починають «завалюватися») може бути використана в наступних цілях:
  1. Розрахувати навантаження, при якій буде забезпечуватися KPI по часу відповіді сервера (наприклад, при 1000 запитів в секунду медіанне час буде не більше 200 мс).
  2. Розрахувати збільшення серверних потужностей, які будуть гарантувати KPI за часом відповіді (якщо зараз він не досягається) або потрібні при зростанні навантаження (наприклад, з 1000 до 1500 запитів в секунду).
  3. Попередити ситуації відмови веб-сервісу (якщо виявиться, що щоденні піки навантаження вже перевищують «межа пружності»): адже при незначному перевищенні навантаження може відбутися повний відмова в обслуговуванні.
  4. Отримати розрахункові значення навантаження для ситуації «прогрів кеша» (обговоримо трохи нижче).
Знаючи значення межі пружності» веб-сервісу в разі лінійного масштабування робить роботу з високим навантаженням повністю прозорою та передбачуваною, мінімізуємо ризики.

Корисно також знати реальний «межа міцності» веб-сервісу, але з досвіду він не перевищує +30% від «межі пружності» (сервери досить швидко відмовляють через лавиноподібного зростання навантаження, коли невеликі затримки призводять до збільшення черги запитів і перевищення часу очікування відповіді вже для більшості вхідних запитів).

«Прогрів кешу»
Можлива рідкісна, але дуже неприємна ситуація: коли в разі масового оновлення записів (сторінок) необхідно їх все максимально оперативно замінити на нові. Це може бути новий виклик коду, видалення вірусних вставок або виправлення технічної помилки. А кешування сайту дозволяє працювати у «зоні пружності» і гарантувати лінійний зростання часу відповіді при збільшенні навантаження.

Різке скидання кешу («прогрів») відразу виводить сайт в зону нестабільної роботи або навіть за межі «межі міцності», тому неприпустимий. Існують два принципово схожі) підходу для вирішення цього завдання.

Перший — це «прогрів» кешуючих серверів по черзі, припускаючи, що «прогрів» кожного з них не виводить сайт з «зони пружності». Характерний графік такого «прогріву» показаний нижче: число запитів різко зростає, швидко повертається до зниженого значенням, потім ситуація повторюється до тих пір, поки всі їх сервери не будуть більш-менш «прогріті». Для опису цього процесу я використовую термін «Каскадний скидання кешу».



Можлива оптимізація описаного процесу, наприклад, за рахунок синхронізації кешей між серверами, в теорії, можна добитися меншого зростання навантаження при прогріві» чергового сервера. Але на практиці або кеш серверів дещо відрізняються (перетин кешей не більше 20-30%), тому взаємне використання не дає короткочасного ефекту. Або частота запитів до «прогріти» даними досить висока, і «прогрів» нового сервера відбувається дуже швидко (як на графіку вище), тому синхронізація не потрібно.

Другий підхід — це фізичне обмеження числа запитів (якщо вони «прогрівають» кеш досить повільно), щоб при прогріві» веб-сервіс не виходив з «зони пружності». Зокрема, в Mail.ru використовують iptables, Irie.рф використовують IP Anycast. У будь-якому разі для більшості користувачів веб-сервіс виявляється на деякий час недоступним, і по мірі накопичення кешу з'являється для все більшого числа користувачів (інакше сервіс буде недоступний одночасно для всіх із-за перевищення «межі міцності»).

Які заходи використовуєте ви при роботі з високим навантаженням?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.