Налаштування API Gateway для мобільного застосунку: де рветься трафік
Мобільний клієнт — найнестабільніше джерело трафіку з усіх, що бачить бекенд. Телефон заходить у метро, перемикається з Wi-Fi на LTE, застосунок іде у фон і повертається за годину — і кожна така подія рве встановлене з'єднання на півдорозі.
Сервер у цей момент уже виконав роботу, але відповісти нікому: клієнт пішов, а його наступний запит приходить як новий. Так починається налаштування API Gateway не з конфігурації, а з розбору того, де саме рветься трафік.
Далі вмикається ефект лавини. Клієнт не отримав відповідь — отже, повторює запит, часто з тим самим ключем операції.
Без дедуплікації на вході один платіж перетворюється на три, а сплеск повторів після масового перепідключення кладе вузьке місце — зазвичай базу — рівно в той момент, коли вона найпотрібніша.
Шлюз для мобільного застосунку зобов'язаний гасити це на вході: тримати ідемпотентність за ключем запиту, обмежувати частоту на клієнта, а не на IP, і не пропускати повтор далі, якщо перший ще в роботі.
Третє джерело збоїв — розсинхрон версій. Користувач оновився не одразу, старий збірник шле запити у форматі, який бекенд уже не розуміє, і замість зрозумілої помилки отримує обрив.
Тут допомагає версіонування маршрутів і явний контракт: шлюз сам вирішує, яку версію бекенду віддати під конкретний заголовок клієнта, і відсікає несумісні запити до того, як вони дійдуть до сервісів.
Обриви з'єднань, сплески повторів і розсинхрон версій — три різних класи відмов, але лікуються вони в одній точці. Нижче розбираємо, як це закривається на рівні конфігурації шлюзу: таймаути, ретраї, ідемпотентність і маршрутизація за версіями.
Що дає правильно налаштований шлюз мобільному продукту
Мобільний застосунок живе в умовах, яких немає у вебі: мережа рветься в ліфті та метро, пристрій засинає посеред запиту, а оновлення версії на боці клієнта розтягнуте на тижні — стара збірка продовжує стукати на бекенд, поки користувачі не оновляться.
Якщо кожен такий запит іде напряму в сервіси, будь-яка нестабільність каналу перетворюється на навантаження на бекенд: обірвані з'єднання, повторні спроби, дублі операцій.
Налаштування API Gateway виносить весь мобільний трафік в єдину точку входу, і далі ці проблеми вирішуються на одному рівні, а не в кожному сервісі окремо.
Стабільність сесій тримається на тому, що шлюз бере на себе перевірку та оновлення токенів, а не віддає це застосунку.
Клієнт продовжує доступ за refresh-токеном через шлюз, не перезбираючи запит до кожного сервісу; при обриві з'єднання повтор іде з тим самим ідентифікатором, і операція не дублюється. Для користувача це виглядає просто: застосунок не викидає на екран входу після зміни мережі.
Навантаження на бекенд стає передбачуваним, коли шлюз обмежує частоту запитів на користувача та пристрій, відсікає зайві повтори й тримає чергу на час сплеску. Обмеження задаються політикою на маршрут, а не кодом усередині сервісу, тому поріг змінюється без релізу.
Сплеск після розсилки або збою мережі більше не доходить до бази цілком — до неї дістається лише те, що пройшло перевірку.
Управління релізами спирається на ту саму точку: маршрутизацію за версією застосунку, поетапний вивід нової збірки на частку користувачів, миттєвий відкат перемиканням правила.
Старі версії продовжують працювати за своїми маршрутами, поки їхня частка не зійде нанівець, — і це знімає необхідність тримати сумісність у всіх сервісах одразу.
Єдина точка входу дає й спостережуваність: затримки, коди відповідей і частка помилок видно за кожним маршрутом і версією клієнта, а не розмазані по логах десятка сервісів.
Розбираємо, як це закривається: які маршрути й політики налаштовуються під ваш профіль трафіку, як переноситься поточна авторизація і що відбувається з уже випущеними версіями застосунку.
Варіанти шлюзу: вбудований балансувальник, Kong, Traefik, хмарний сервіс
Вибір точки входу для мобільного API — це не питання смаку, а наслідок того, де живе застосунок, хто керує сертифікатами і наскільки часто змінюються правила маршрутизації. Нижче — чотири реальні варіанти, між якими обирають на старті проєкту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудований балансувальник | Один кластер, прості правила, немає зовнішніх споживачів API | Немає тонкої маршрутизації за заголовками, ліміти та авторизація робляться в самому застосунку |
| Kong | Потрібні плагіни: ліміти, ключі, трансформація запитів, аналітика | Потребує окремого контуру та супроводу, декларативна конфігурація складніша для невеликих команд |
| Traefik | Динамічна маршрутизація, часті релізи, кілька середовищ | Менше готових плагінів, частина логіки авторизації пишеться самостійно |
| Хмарний шлюз | Немає власної інфраструктури, потрібні керовані сертифікати та автомасштабування | Прив'язка до провайдера, обмежений контроль над поведінкою на рівні мережі |
Вбудований балансувальник закриває базовий сценарій: застосунок за одним кластером, стабільний набір маршрутів, мінімум зовнішніх інтеграцій.
Як тільки з'являються версії API для старих збірок мобільного клієнта, ліміти за пристроями або різні правила для партнерів, він перестає справлятися — логіка розповзається по коду застосунку.
Kong і Traefik вирішують це на рівні шлюзу: маршрути, ліміти, перевірка токенів і канареечні релізи описуються конфігурацією, а не правками в сервісах. Хмарний шлюз знімає питання експлуатації, але прив'язує до провайдера.
На практиці вибір зводиться до того, чи готові ви тримати свій контур заради гнучкості — чи віддаєте перевагу керованому сервісу в обмін на менший контроль.
Етапи налаштування шлюзу під мобільний трафік
Налаштування API Gateway для мобільного застосунку починається не з конфігурації, а з інвентаризації: які ендпоінти реально викликає клієнт, які версії ОС і збірок ще в обігу, де трафік іде напряму в бекенд в обхід шлюзу.
Без цього етапу правила маршрутизації пишуться «на око» і ламаються на першому ж релізі. Нижче — послідовність, за якою ми ведемо роботи.
- Аудит ендпоінтів. Збираємо карту викликів з логів і трасувань: метод, частота, розмір відповіді, залежність від версії застосунку. Позначаємо застарілі маршрути, які тримаємо лише заради старих збірок, і точки, де мобільний клієнт ходить у сервіси напряму.
- Проєктування схеми маршрутизації. Розкладаємо маршрути за префіксами і версіями, визначаємо, що йде на шлюз, а що залишається внутрішнім. Фіксуємо правила переписування шляхів і заголовків, щоб бекенд не довелося правити під кожен реліз клієнта.
- Налаштування правил. Ліміти за частотою запитів на пристрій і на користувача, таймаути, повтори, кешування відповідей, які не змінюються між викликами. Окремо — правила автентифікації: перевірка токена на вході, щоб неавторизований запит не доходив до сервісів.
- Перевірка відмовостійкості. Прогоняємо сценарії деградації: недоступність одного сервісу, сплеск трафіку при масовому оновленні застосунку, обрив з'єднання на мобільній мережі. Дивимося, що шлюз віддає клієнту замість помилки і як швидко відновлюється після зняття навантаження.
- Спостережуваність. Налаштовуємо метрики за маршрутами, частку помилок і затримки за кожним ендпоінтом, трасування запиту від клієнта до сервісу. Без цього наступний інцидент шукається наосліп.
- Передача в експлуатацію. Конфігурація йде в репозиторій, зміни — через рев'ю і автоматичне викочування, а не руками на проді. Пишемо регламент: як додати маршрут, як відкотити правило, хто чергує.
Порядок важливий: правила, написані до аудиту, доводиться переписувати, а відмовостійкість, перевірена після релізу, обходиться дорожче. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Конфігурації, схеми та регламенти, які залишаються в команди
Робота над шлюзом закінчується не запуском, а передачею артефактів, за якими команда замовника зможе жити далі без нас. Нижче — що саме залишається в репозиторії та в документації.
- Конфігурація шлюзу у вигляді декларативних маніфестів: маршрути, апстріми, health-check'и, таймаути та ліміти — усе в системі контролю версій, а не у веб-інтерфейсі. Зміна проходить рев'ю та розкочується як звичайний реліз.
- Схема маршрутизації з картою сервісів: який шлях веде на який бекенд, де версіонування, де канаркові відгалуження, як розв'язуються конфлікти правил.
- Політики доступу: схеми автентифікації, випуск і ротація ключів, обмеження частоти запитів за клієнтами та ендпоінтами, правила блокування підозрілого трафіку.
- Конфігурація відмовостійкості: ретраї, розмикачі ланцюга, деградація при недоступності бекенду — із зазначенням, які сценарії деградують, а які віддають помилку.
- Набір перевірок працездатності: readiness/liveness для самого шлюзу та синтетичні запити за критичними маршрутами, які ловлять обрив раніше за користувачів.
- Регламент експлуатації: порядок викочування змін, відкат на попередню конфігурацію, реакція на інциденти, точки контролю метрик та алертів.
- Документація: опис архітектури, схема потоків запитів, інструкція з додавання нового сервісу та чек-ліст приймання змін.
Кожен артефакт ми розбираємо разом із командою замовника — не віддаємо архівом, а проходимо по ньому на реальній зміні: додати маршрут, випустити ключ, відкотити конфігурацію. Так регламент експлуатації стає робочим інструментом, а не папкою, яку ніхто не відкриває.
Кейс: як шлюз на Kong усунув обриви сесій у мобільному застосунку
Клієнт — сервіс доставки з мобільним застосунком на iOS та Android, близько 400 тисяч активних користувачів. Бекенд — набір сервісів за балансувальником, авторизація через JWT, сесії короткоживучі.
За пікових навантажень (вечірні години, акції) частка успішних запитів падала до 91%: частина запитів обривалася на етапі перевірки токена, клієнти отримували помилку й поверталися до повторного входу.
Підтримка фіксувала сплеск звернень «викидає із застосунку» — до 1 800 тікетів на тиждень, і це без урахування тих, хто просто видаляв застосунок.
Що змінили
Розгорнули Kong як єдину точку входу для мобільного трафіку.
Ключові налаштування: перевірку JWT винесено на рівень шлюзу, щоб не ганяти кожен запит через сервіс авторизації; ліміти запитів рахуються за користувачем, а не за IP — інакше клієнти за одним оператором зв'язку різали одне одного; health-check бекендів з автоматичним виведенням вузла, що впав, з ротації; повторні спроби на ідемпотентних методах з обмеженням за кількістю.
Окремо налаштували таймаути: раніше запит міг висіти, доки клієнт не обірве з'єднання сам. Тепер шлюз віддає зрозумілу помилку за фіксований час, а застосунок показує екран повтору замість «білого» зависання.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Частка успішних запитів | 91% | 99,6% |
| Час відновлення після збою вузла | 4-6 хвилин | 20-30 секунд |
| Звернення до підтримки щодо сесій | ~1 800/тиж | ~120/тиж |
| Навантаження на сервіс авторизації | пікове | знизилося в 3 рази |
Час відновлення скоротився завдяки автоматичному виведенню вузла з ротації: раніше черговий дізнавався про проблему з тікетів і перемикав трафік вручну, тепер шлюз робить це сам, а команда отримує повідомлення вже за фактом.
Через місяць після запуску звернення до підтримки щодо обривів сесій упали більш ніж у десять разів — це вивільнило першу лінію для завдань, які справді потребують людини.
Чим відрізняється шлюз для мобільного API від звичайного вебпроксі
Звичайний вебпроксі живе у припущенні, що клієнт — це браузер на стабільному каналі: з'єднання тримається довго, версія одна, відповідь можна віддати цілком. Мобільний API працює в протилежних умовах.
Пристрій заходить у метро, втрачає мережу на середині запиту, перемикається між мережами й повертається з тим самим ідентифікатором запиту.
Шлюз для мобільного API зобов'язаний переживати розрив з'єднання й не створювати дублі: ідемпотентність за ключем запиту, буферизація відповіді та повторна віддача без повторного виконання операції на бекенді.
Друга різниця — версії клієнта. У вебі ви викочуєте нову збірку і всі отримують її одразу, у мобільному застосунку на руках одночасно живуть кілька версій: частина користувачів не оновилася, частина сидить на старій збірці через політику магазину.
Шлюз маршрутизує запити за версією клієнта та заголовками сумісності, віддає різні схеми відповіді й уміє м'яко вимикати застарілі поля, не ламаючи старі збірки.
Це не «фіча на майбутнє», а умова, за якої реліз нової версії не перетворюється на масові помилки у тих, хто ще не оновився.
Третє — економія ресурсів клієнта. Мобільний пристрій обмежений за пам'яттю, зарядом і трафіком, тому шлюз займається стисненням відповідей, віддачею лише змінених полів і агрегацією кількох запитів екрана в один виклик.
Тут же вирішується авторизація: токен оновлюється на шлюзі, а не в кожному клієнті, і політика доступу змінюється централізовано, без випуску нової збірки.
Четверте — спостережуваність. За мобільним трафіком потрібно бачити не лише коди відповідей, а й частку запитів із поганою мережею, розподіл за версіями клієнта та час до першого байта на слабкому каналі.
Без цього неможливо зрозуміти, деградація — це проблема бекенду чи конкретної версії застосунку в частини користувачів.
Саме тому налаштування API Gateway для мобільного продукту — окреме інженерне завдання, а не перенесення конфігурації вебпроксі. Ми розбираємо профіль трафіку конкретного застосунку й збираємо політики маршрутизації, повторів і версіонування під нього.
Технічні сумніви перед стартом робіт
Сумніви зазвичай не про «чи працює шлюз», а про те, як він впишеться в поточний контур: що зламається під час міграції, хто тримає конфігурацію, що буде при відмові. Нижче — відповіді на питання, які найчастіше виникають на етапі оцінки.
Чи можна підключити шлюз до наявного бекенду без переписування сервісів?
Так. Шлюз ставиться перед поточними сервісами й маршрутизує трафік за правилами — самі сервіси не змінюються. Змінюються лише адреси, за якими до них звертається мобільний застосунок.
Якщо у сервісів уже є версіонування, маршрути описуються декларативно й переносяться без правок коду.
Як проходить міграція і чи є відкат?
Переводимо трафік поступово: спочатку частина користувачів, потім решта. Старий контур залишається робочим до підтвердження стабільності, тому повернення до попередньої схеми займає хвилини.
Конфігурація шлюзу зберігається в репозиторії — відкат робиться поверненням попереднього стану, а не ручною правкою.
Що із сумісністю старих версій застосунку?
Користувачі оновлюються не миттєво, тому маршрути тримаємо сумісними з попередніми версіями клієнта. Застарілі виклики позначаємо й виводимо з експлуатації за розкладом, коли їхня частка падає до знехтуваної. Так оновлення застосунку не перетворюється на обов'язкове для всіх одразу.
Хто відповідає за експлуатацію після запуску?
Конфігурація, правила маршрутизації та політики лімітів передаються вашій команді з документацією та розбором типових сценаріїв. Ми можемо залишитися на підтримці — тоді зміни маршрутів і розбір інцидентів ідуть через нас за узгодженим регламентом.
Що відбувається при відмові самого шлюзу?
Шлюз розгортається в кількох екземплярах, перевірка живості виводить вузол, що відмовив, з балансування автоматично. Ліміти й таймаути налаштовуються так, щоб повільний сервіс не забирав ресурси в решти. Це переводить відмову з класу «лежить весь застосунок» у клас «деградація одного маршруту».
Опишіть ваш контур — повернемося з оцінкою та планом робіт.
Обговоримо ваше завдання та повернемося з оцінкою і планом
Щоб повернутися з оцінкою і планом, а не із загальними словами, нам потрібен контекст щодо вашої інфраструктури.
Шлюз — це точка, через яку проходить весь трафік застосунку, тому рішення щодо маршрутизації, лімітів і авторизації залежать від того, як зараз влаштовані сервіси, де зберігаються ключі та які вимоги щодо навантаження. Чим точніші вхідні дані, тим менше припущень в оцінці.
Що корисно отримати від вас на старті:
- Схему поточних сервісів: які сервіси за шлюзом, як вони спілкуються між собою, чи вже є точка входу для мобільних клієнтів.
- Вимоги до навантаження: пікова кількість одночасних підключень, профіль трафіку, сезонні сплески.
- Модель авторизації: як видаються та перевіряються токени, чи потрібні зовнішні провайдери, ролі та права доступу.
- Обмеження щодо інфраструктури: де розгортається шлюз, які середовища (dev/stage/prod), вимоги щодо ізоляції та доступів.
- Поточні проблеми: що не влаштовує в наявному рішенні — затримки, ручне налаштування маршрутів, відсутність спостережуваності.
- Регламенти: вимоги щодо безпеки, логування, зберігання персональних даних, галузеві норми.
У відповідь ми готуємо план робіт з етапами, строками та зонами відповідальності, схему цільової архітектури шлюзу з обґрунтуванням вибору між Kong і Traefik під ваше завдання, а також перелік ризиків і способів відкату на кожному кроці. Оцінка спирається на реальний обсяг, а не на усереднений шаблон.
Опишіть завдання у зручному форматі — дзвінок, листування або короткий опис вхідних даних. Ми повернемося з оцінкою і планом, за яким можна стартувати.
