Що таке Rate limiting?

Noisy tenants це одна з типових проблем в Multi-tenant системах, коли один шумний tenant(клієнт) починає споживати непропорційно багато ресурсів, наприклад CPU, памʼять, черги чи ліміти в API. Таким чином, це впливає на інших клієнтів: росте latency, зʼявляються timeouts, проблеми з сесіями чи поява downtime.

Як це виглядає на практиці

Наприклад, ви використовуєте брокер повідомлень(SQS, RabbitMQ…) і один tenant генерує велику кількість подій. Так як брокер і обробники подій спільні вони здебільшого обробляють повідомлення від noisy tenant, а інші клієнти страждають від збільшеного latency.

Ще один приклад, повʼязаний з сторонніми інтеграціями. Ви не встановили чітких Rate limits для клієнтів і noisy tenant викликає стороннє API настільки часто, що дуже швидко вибиває всі ліміти і інші клієнти не можуть повноцінно використовувати інтеграції.

Основні причини виникнення:

1. Спільна інфраструктура: брокери повідомлень, бази даних, сервери і тд.
2. Спільні ліміти зовнішніх сервісів або відсутність Rate limiting
3. Нерівномірний розподіл трафіку

Приклади вирішення проблеми

1. Ліміти і справедливе розподілення ресурсів
2. Запровадження квот на важкі та затратні операції
3. Виділення окремих ресурсів для “жирних” клієнтів

Throttling - це техніка в програмуванні, яка обмежує частоту виконання. Простими словами, ми вказуємо, що код може запускатись не частіше, ніж раз на N мілісекунд. Найкращий спосіб зрозуміти throttling це розібрати приклад.

Throttling в HTTP API

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

Типова проблема в таких системах це - Noisy Tenants. Уявимо, що клієнт обрав максимальний тарифний план, але частота запитів які він робить настільки велика, що він перебирає на себе значну частину ресурсів. Таким чином інші клієнти мають проблеми з затримкою у відповіді чи проблеми з повільним завантаженням даних.

В такому випадку, використовуючи throttling ви можете вказати, що максимальна частота запитів це 1000 в секунду. Це потенційно розвантажить ваші ресурси і дозволить всім клієнтам повноцінно використовувати систему.

Проблема N + 1 в GraphQL - це класичне запитання в контексті розмови про дизайн GraphQL API або порівнянні його з REST. Вона виникає, коли один GraphQL запит призводить до великої кількості дрібних запитів до бази даних.

Розберемо простий приклад з інтернет магазином. Ми робимо запит на отримання продуктів і хочемо отримати коментарі до них. Якщо б ми використовували REST API, то могли зробити JOIN на рівні ORM і витягнути всі дані одним запитом. Але в GraphQL ми витягнемо всі продукти одним запитом і після того почнемо викликати Resolvers окремо для кожного продукту.

Для кожного продукту буде запущений окремий SQL запит. Якщо в нас 100 продуктів, то буде запущено 100 додаткових запитів в базу даних, які витягнуть коментарі для кожного окремого продукту.

Як вирішити цю проблему?

Вирішується вона доволі просто, за допомогою DataLoader, основна задача якого - Batching. В нашому випадку DataLoader буде збирати всі product ids в один масив і викликати функцію, яка витягне коментарі більш оптимізовано. Наприклад, замість 100 запитів в базу даних ми можемо отримати все за один запит, використовуючи WHERE IN([…productIds]).