Ваш застосунок на ШІ потрапив у топ. Чи витримає він напливу трафіку?
Хтось поділився вашим застосунком — і тисяча людей прийшла одночасно. Ось як допомогти створеному на ШІ застосунку пережити сплеск трафіку, не переписуючи його за ніч до того, як це справді важитиме.
Уявіть гарну версію поганого дня. Ви опублікували свій застосунок на ШІ у спільноті, до якої належите, або хтось із великою аудиторією спробував його та поділився ним, або він потрапив на головну сторінку форуму, куди ви навіть нічого не надсилали. Раптом звична цівочка відвідувачів перетворюється на повінь. Тисяча людей одночасно клікають по всьому застосунку в одну й ту саму годину.
Це момент, заради якого ви все це будували. І це водночас момент, коли багато застосунків на ШІ тихо падають — повільні сторінки, нескінченні завантаження, форма реєстрації, яка не надсилається. Люди, які нарешті прийшли, впираються у стіну й ідуть, і більшість із них так і не повертається спробувати ще раз.
Хороша новина: пережити сплеск трафіку — це здебільшого кілька нудних рішень, які можна ухвалити до того, як сплеск станеться. Вам не потрібно бути інженером. Вам потрібно знати, на яких кутах не можна зрізати.
Що насправді ламається, коли трафік підстрибує
Коли вашим застосунком одночасно користується у сто разів більше людей, ніж зазвичай, речі ламаються не випадково. Вони ламаються в передбачуваному порядку, і це майже завжди ті самі три місця.
База даних не справляється. Щоразу, коли хтось завантажує сторінку, ваш застосунок зазвичай ставить базі даних запитання: «які дані в цього користувача?» Одна людина із запитом — це дрібниця. Тисяча людей із тим самим запитом за ту саму хвилину можуть накопичитися швидше, ніж база встигає відповідати, і сторінка в усіх сповзає до повзання.
Щось поза вашим застосунком стає повільним. Більшість застосунків на ШІ спираються на інші сервіси — надсилання e-mail, обробку платежів, виклик моделі ШІ. Ці сервіси часто обмежують, як швидко ви можете до них звертатися. За звичайного трафіку ви ніколи не помічаєте цього обмеження. Під час сплеску ваш застосунок упирається в нього, і раптом будь-яка дія, що торкається того сервісу, зависає.
Застосунок раз за разом виконує ту саму витратну роботу. Якщо ваша головна сторінка щоразу, коли хтось заходить, запускає важке обчислення — підтягує список, сортує його, форматує, — це нормально для десяти відвідувачів і нищівно для тисячі. Ця робота завжди була марнотратною. Низький трафік просто це приховував.
Зверніть увагу на закономірність: жодна з цих проблем — не нова помилка. Сплеск нічого не зламав. Він виявив слабкі місця, що вже були там, тихо чекаючи під низьким трафіком.
Найдешевше виправлення: кешуйте те, що не змінюється
Кешування звучить технічно, але ідея проста: якщо відповідь на запитання однакова для всіх і рідко змінюється, обчисліть її один раз і використовуйте повторно замість того, щоб переробляти роботу для кожного відвідувача.
Ваша головна сторінка, ймовірно, виглядає однаково для всіх 1000 людей, що на неї заходять. То навіщо просити базу даних перебудовувати її 1000 разів? Зберіть її один раз, збережіть результат на кілька хвилин і віддавайте цю збережену копію всім. Ви щойно перетворили тисячу витратних звернень до бази на одне.
Скажіть своєму конструктору на ШІ саме це: «Кешуй головну сторінку та публічний список товарів на п’ять хвилин, щоб ми не зверталися до бази даних при кожному відвідуванні». Усе, що однакове для всіх і не потребує посекундної актуальності — сторінка з цінами, публічний каталог, індекс блогу, — кандидат на кешування. Персоналізовані речі (чийсь власний дашборд, налаштування акаунта) кешувати так само не вийде, але це зазвичай невелика частка трафіку під час сплеску. Більшість людей дивляться на ті самі кілька публічних сторінок.
Не змушуйте людей чекати на те, що може статися пізніше
Ось помилка, яку легко зробити й легко виправити. Скажімо, хтось реєструється, і ваш застосунок надсилає йому вітальний лист. Якщо застосунок змушує його чекати на сторінці реєстрації, доки лист повністю не надішлеться, то повільний поштовий сервіс робить вашу реєстрацію повільною — саме в той момент, коли реєструється найбільше людей.
Виправлення — дозволити повільним речам відбуватися у фоні. Людина миттєво бачить «Готово!», а лист іде за кілька секунд, і ніхто на нього не чекає. Той самий результат, але відвідувач не витріщається на спінер, поки поштовий сервер за три компанії звідси робить свою справу.
Попросіть конструктор: «Надсилай вітальний лист у фоні, щоб реєстрація на нього не чекала». Та сама логіка стосується всього, що не мусить завершитися, перш ніж людина зможе йти далі — генерація звіту, синхронізація з іншим інструментом, надсилання сповіщення. Якщо результат потрібен користувачу не просто зараз, не змушуйте його на нього чекати.
Майте план «забагато людей»
Іноді сплеск більший за все, до чого ви готувалися, і чесний хід — деградувати плавно, а не обвалюватися. Повільний застосунок, який усе ще працює, кращий за зламаний.
Кілька простих варіантів цього:
- Дружнє повідомлення про очікування. Якщо щось справді перевантажене, показати «Зараз у нас дуже багато відвідувачів — зачекайте трохи» куди краще за порожній екран чи сиру помилку. Люди прощають зайнятому застосунку. Зламаному — ні.
- Тимчасово вимкніть найважчу функцію. Якщо одна функція — найвитратніша (скажімо, ШІ-генерація, що коштує реальних грошей і часу за клік), її можна сховати під час напливу та зберегти решту застосунку швидкою. Більшість відвідувачів під час сплеску так чи інак переглядають, а не користуються вашою найвибагливішою функцією.
- Знайте, звідки береться ваш рахунок. Якщо ваш застосунок викликає платну модель ШІ при кожному відвідуванні, тисяча відвідувачів може означати несподіваний рахунок, а не просто повільну сторінку. Знання того, які дії коштують грошей, дає змогу заздалегідь вирішити, що обмежити.
Тридцятихвилинна генеральна репетиція
Вам не потрібні хитромудрі інструменти, щоб знайти свої слабкі місця. Вам потрібно кілька друзів і пів години.
Попросіть п’ятьох-шістьох людей відкрити ваш застосунок одночасно й кілька хвилин активно по ньому клікати — зареєструватися, скористатися головною функцією, завантажити завантажені сторінки. Це грубо, але швидко виявляє очевидне. Якщо застосунок уже відчувається млявим, коли по ньому гамселять шестеро, тисяча його розчавить. Якщо він залишається жвавим, ви принаймні взяли низьку планку.
Поки вони клікають, дивіться, яка сторінка відчувається найповільнішою. Саме ця повільна сторінка постраждає найбільше від справжнього сплеску трафіку, і саме її варто кешувати чи спрощувати першою. Ви не намагаєтеся зімітувати тисячу користувачів. Ви намагаєтеся знайти ту одну сторінку, що вже не дає ради на шести.
Справжня мета
Ви не зробите свій застосунок нескінченно куленепробивним, та цього й не потрібно. Мета не в тому, щоб бездоганно обслужити десять тисяч людей під час свого першого вірусного моменту. Вона в тому, щоб не осоромитися перед тими кількома сотнями, які нарешті прийшли, — переконатися, що люди, яких ви так старанно привертали, отримають робочий застосунок, а не крутне колесо.
Кешуйте сторінки, що не змінюються. Перенесіть повільні речі у фон. Майте план на «забагато людей». Зробіть генеральну репетицію з п’ятьма друзями, перш ніж вона знадобиться. Нічого з цього не вимагає писати код самому — лише знати, про що правильно попросити свій конструктор на ШІ.
Тоді, коли настане ваш момент, ви зможете ним насолодитися, а не гарячково його дебажити. Тож ось запитання, з яким варто посидіти цього тижня: якби завтра прийшла тисяча людей, яка сторінка зламалася б першою — і чи ви вже це знаєте?