Підготовка до (а) Чорної п’ятниці

Чорні п’ятниці є захоплюючими для будь-якої компанії з електронної комерції, і для Travelstart це був наш третій раз. Ми багато чого навчилися з останніх двох, тож цього року ми вирішили це правильно зробити. Ось що ми зробили

Кілька місяців до цього

Ми дізналися чимало уроків із попередньої Чорної п’ятниці та запланували кілька виправлень для вирішення цих питань:

  • Проблеми з нашою CMS - на щастя, вона була швидко вирішена, оскільки це була проблема конфігурації (саме тому періодичне тестування навантаження - хороша ідея). Однак це може збільшити масштаб лише певної кількості користувачів. Потім ми завантажили зображення на S3 та зробили їх доступними через CloudFront. Ця зміна також дозволила нам надати більше примірників - попередня архітектура додатків зберігала зображення у файловій системі. Ми додали шар кешування, який різко збільшив час відповідей та кількість одночасних запитів. Ми вносили додаткові зміни і тестуючи їх, роблячи тести навантаження, під час цього процесу ми також виявили вузькі місця на рівні ОС, які потрібно було налаштувати.
  • Бенкенд платформи видав у базу даних багато тих самих запитів щодо даних, які майже ніколи не змінюються - ми почали кешувати їх у розподіленому кеші, що також означає, що зміни відображатимуться у кластері у разі зміни. Нижче - приклад знімка екрана, що показує ефект. Ми майже заощаджуємо розподіл підключення до бази даних, мережевий перехід, (можливе) зчитування диска та деякий час процесора на коробці db. Що чудово підходить для масштабування.
  • Проблеми з базою даних, яка відслідковує всі запити / відповіді третіх осіб на попередньому BF. Незважаючи на те, що INSERT вже вбудовані, а потім асинхронно висунуті до бази даних, ми збиралися паралельно (кілька пакетів пакетів), і це означало, що db буде надіслано купу вкладених INSERT за з'єднання за бекенд. Що було дуже погано для масштабування - db був повністю перевантажений. Отже, ми подумали про те, як «перемістити» проблему з бази даних до самого резервного сервера (ми можемо забезпечити резервні копії за бажанням, але не базу даних легко): ми вставили в чергу кожен запис і надіслали його постачальнику (якого там зараз лише один, замість кількох). Це означає, що кількість підключень до db є відносно постійною і навантаження сидить на бекенді, а не на базі даних. Дивіться скріншот нижче; кількість підключень піднялося з 27 до 42 (1,6x) під великим навантаженням, але кількість запитів зросла на коефіцієнт 6 та (сильно стиснений) мережевий трафік в 4 рази. На попередньому BF у нас було 500 + підключення, що використовуються, що призвело до дуже поганої роботи.
  • Переглядаючи кількість "статичних" запитів, які веб-сайт робив до свого API - ми зрозуміли, що це 50% усіх запитів API! Ми ввели шар кешування перед API та зменшили кількість викликів на 50%!
  • Розгортання: перед тим, як ми підтримували список розгорнутих компонентів (мітки, API та ін.), Тобто список серверів висхідної течії був статичним і не динамічним, що призводило іноді до помилок розгортання: ми передбачили нові екземпляри сервера, але процес розгортання не знав про це —результат “дивного” поведінки (відображається старий код) - ми змінили всю конфігурацію на динамічну: всі списки “вузлів” генеруються в усі часи. Це корисно, коли вам потрібно швидко збільшити та уникнути витраченого часу на полювання на помилок.
  • Внесіть філософію змін, перегляду та застосування: внесіть зміни в невелику частину системи та стежте за змінами - якщо все добре - застосовуйте всюди. Мати належні інструменти моніторингу. Майте всю конфігурацію (включаючи інфраструктуру) в управлінні версіями - це полегшує відкат і бачити, хто що робив. Повернення повинно бути легким.
  • Оскільки ми сильно покладаємось на черги з повідомленнями, ми потрапили в пастку просто збільшувати кількість одночасних споживачів (до масштабу) і не помічаємо, що з моменту внесення змін змінився фактичний час обробки кожного повідомлення; якщо обробка повідомлення залежить від зовнішньої залежності (наприклад, бази даних чи зовнішньої служби), яка має певну SLA - будьте уважні! Відтоді ми переглянули та зменшили кількість одночасних споживачів для певних черг з 10 до 1 за кожний бекенд, і ми отримали цей приємний сюрприз:
Час обробки повідомлень скорочено більш ніж на 50%

Підготовка за тиждень до цього

Перше, що ми зробили, це зробити тест навантаження в нічний час, щоб побачити, чи зможе наша CMS (вміст для наших сторінок продажів) утримувати раптовий приплив трафіку, і на наш подив ми виявили, що ми досягли меж пропускної здатності на центр обробки даних! На щастя, тест був зроблений рано, тому ми могли його вчасно вирішити. Це також дуже допомагає, якщо тести навантаження можуть бути ініційовані з консолі для послідовного тестування.

Що стосується офісної мережі: оскільки ми будемо мати справу з набагато більшою кількістю дзвінків, ми збільшили пропускну здатність Інтернету як для голосу, так і для даних за тиждень, щоб вирішити додаткове навантаження.

Ми також створили панелі інформаційних панелей, специфічні для BF, які відображатимуться на екранах, особливо для третіх сторін (час відгуку, обсяг), оскільки ми залежаємо від них, наприклад, рейси, платежі - зазвичай під час великого продажу деякі послуги знижуються дуже швидко, і це часто простіше мати візуалізацію, яку кожен може побачити, щоб рано помітити проблеми. Це також хороша ідея поспілкуватися з вашими найбільш проблемними постачальниками послуг та домовитись про те, як спілкуватися, коли справи йдуть TITSUP (Повна неможливість підтримки звичайної продуктивності). Ми зібрали команду основних людей до "Війни кімнати" на день, а на екранах виставили інформаційні панелі.

Сповіщення - це те, що ми вже мали, але ми переглянули всі правила оповіщення, такі як час відгуку на певні ключові транзакції, наприклад BookFlight. Якщо ви залежите від багатьох третіх сторін для таких критичних служб, як Travelstart, також налаштуйте попередження для цих служб, щоб вони могли вирішувати операційні проблеми.

Потім надаємо додаткові ресурси («сервери», «екземпляри»): ми дивилися на нормальне завантаження (1x), завантаження останнього продажу (день народження, 5x) та завантаження останньої Чорної п’ятниці (25x). Тут потрібно добре знати архітектуру додатків - просто додавання більшої кількості серверів не обов'язково означає, що ваші додатки будуть масштабуватись із кількістю доданих серверів (платформа Travelstart - це потужна архітектура на основі SEDA). Оскільки ми використовуємо NewRelic, ми можемо отримати кілька корисних статистичних даних, щоб зрозуміти, скільки екземплярів кожного компонента розгортати (backends, API тощо). Ми ще не здійснили автоматичне масштабування, але те саме стосується: ваша архітектура повинна справлятися зі збільшенням кількості примірників.

Більш технічний фронт, ми розглянули наші зовнішні кеші - у цьому випадку наш кеш-польотів - який містить дуже часто пошук даних про польоти, які є досить складними, оскільки дати та наявність відіграють дуже особливу роль з точки зору ціноутворення на рейс - не ваш прямий стратегія кешування У Чорну п’ятницю пошук маршрутів (із супроводжуваними датами) буде дуже специфічним, і ми створили окремий екземпляр кешу та змінили Правила кеш-польоту на дуже короткий TTL (зазвичай у нас є динамічний TTL, який розраховується для кожного пошуку). Обґрунтуванням цього є те, що користувачі будуть шукати ті самі рейси (маршрут + дата) за дуже короткий час, і це зменшить раптовий тиск на нашу сторону, але також і на наших постачальників.

Огляд запланованих робочих місць - оскільки BF починається опівночі, нам довелося перепланувати деякі завдання, які виконуються в цей час. Те ж саме стосується і завдань з обслуговування Бази даних - ви не хочете додатково навантажувати базу даних, коли, мабуть, буде тихий час. Ми також розглядали завдання, які працюють дуже часто, і запитували, чи справді це потрібно, щоб він працював щохвилини? Ми виявили декілька з них і змінили її на запуск кожні 15 хвилин - це забрало зовсім небагато навантаження від загальної системи!

Зміна розкладу завдань призводила до того, що запит виконується рідше, що призводить до меншого навантаження на db

Ще одна важлива річ, яку ми перевірили - це конфігурація пулу підключень до бази даних - оскільки ми збільшуємо масштаб, кількість підключень до бази даних також збільшиться. Наприклад, у вас є 10 екземплярів, а кожен сервер має 10 підключень, тепер ви масштабуєте до 25 екземплярів, тоді раптом у вас може бути до 250 підключень замість 100. Або зменшіть кількість підключень на екземпляр бекенда (гарна ідея, бази даних не ' t масштабувати так само легко, як ваші копії) або дати вашій базі даних більш високу межу з'єднання. Ми зробили такий самий огляд щодо підключення до нашої черги повідомлень.

Часи очікування: налаштування налаштування тайм-ауту для зовнішніх служб. На веб-сайті загальний час відгуку на пошук такий же хороший, як і найповільніший зовнішній сервіс, який ми використовуємо для отримання доступності рейсів. Ми скоротили тайм-аути для деяких наших проблемних постачальників, щоб з нами постати «повільними».

Коротко:

  • Тест навантаження - до та після змін
  • Монітор - візуальний, але також попереджуваний через Slack, текстове повідомлення (SMS)
  • Забезпечення можливостей із резервними копіями статистики - знайте свою архітектуру додатків!
  • Перегляньте заплановані завдання
  • Перегляньте стратегії кешування
  • Огляд параметрів підключення до бази даних
  • Перегляньте кількість споживачів у черзі повідомлень
  • Майте філософію, яка нам потрібна, щоб змінити
  • Огляд конфігурації тайм-ауту: ви настільки ж швидкі, як і зовнішній постачальник послуг

Висновок

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