Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / API Gateway простими словами: маршрутизація, безпека та обмеження запитів для мікросервісів — чи потрібен він вам? (ШІ-дубляж)

Transcript

API Gateway простими словами: маршрутизація, безпека та обмеження запитів для мікросервісів — чи потрібен він вам? (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та зустрічі з тими, хто формує майбутні роботи.
• 0:07
  Цього січня M365Con повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас на живих сесіях, демонстраціях реальних кейсів та отримуйте практичні знання від MVP та експертів з усього світу.
• 0:18
  Жодних загальних слайдів чи нескінченних модних слів.
• 0:22
  Ми розглядаємо реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви і те фахівець, розробник або бізнес-лідер, для вас знайдуться відповідні сесії.
• 0:35
  Протягом 10 повних днів ви зможете дослідити різні технології та налагодити зв'язки з глобальною спільнотою.
• 0:40
  Дивіться наживо та впроваджуйте практичні ідеї у своїй організації.
• 0:44
  Січень 2027 року, 10 днів, єдина спільнота Microsoft. Реєстрація вже відкрита.
• 0:51
  Перейдіть на M365Con.net і забронюйте своє місце вже сьогодні.
• 0:56
  Це M365Con.net
• 0:59
  Долучайтеся зараз на M365Con.net і побачимося наживо в січні.
• 1:05
  Ви створили робочий додаток, потім додали ще один сервіс, потім ще один, і раптом керування трафіком між ними перетворилося на жах.
• 1:11
  Отже, що таке Арі Шлюз і чи дійсно він вам потрібен?
• 1:14
  До кінця цього епізоду ви зрозумієте, що робить Арі Шлюз, чому він вирішує хаос керування багатьма сервісами та як дізнатися, чи потрібен він вам.
• 1:22
  Почнімо з проблеми, потім розберемо складові та побачимо, як усе це працює разом.
• 1:27
  Проблема. Забагато дверей.
• 1:29
  Уявіть, що ви керуєте компанією, яка швидко зростає.
• 1:32
  У вас є відділ продажів на третьому поверсі, бухгалтерія в підвалі та і те відділ у задньому крилі.
• 1:37
  Тепер уявіть, що кожен із цих відділів має окремий вхід, свій номер телефону та власного охоронця, який не спілкується з іншими.
• 1:43
  Якщо ви відвідувач і хочете залишити посилку, успіхів вам.
• 1:46
  Ви повинні точно знати, якими дверима скористатися, з яким охоронцем говорити і що робити, коли цей охоронець на перерві.
• 1:51
  Саме це відбувається, коли ваш додаток має кілька серверних служб і кожен клієнт звертається до них напряму.
• 1:56
  Клієнт, чи то мобільний додаток, веб-сайт чи інший сервіс має знати, де знаходиться кожна служба, як проходити автентифікацію і що робити, коли щось ламається.
• 2:04
  Кожна окрема служба повинна самостійно забезпечувати свою безпеку, ліміти запитів та обробку помилок.
• 2:09
  Це дублювання роботи і легко допустити розбіжності.
• 2:12
  Візьмемо, наприклад, банк. У них є окремі сервіси для рахунків платежів, кредитів та виявлення шахрайства.
• 2:17
  За старим підходом кожен із них доступний напряму.
• 2:19
  Мобільний додаток має знати чотири різні URL-адреси, чотири різні методи автентифікації та чотири різні способи обробки помилок.
• 2:25
  Це вчетверо більша складність і вчетверо більша ймовірність збоїв, і саме цей хаос покликаний усунути Аріш-шлюз.
• 2:32
  Отже, яке рішення?
• 2:33
  Що таке Аріш-шлюз?
• 2:35
  Уявіть Аріш-шлюз як рецепцію готелю.
• 2:38
  Коли ви заходите, вам не потрібно знати, на якому поверсі покоївки, де кухня або як зв'язатися з технічною службою.
• 2:44
  Ви просто підходите до стійки реєстрації, кажете, що вам потрібно, і вони беруть усе на себе.
• 2:48
  Вони спрямовують ваш запит потрібній людині, перевіряють, чи є у вас доступ, і навіть самі вирішують прості питання.
• 2:54
  Аріш-шлюз робить те саме для вашого програмного забезпечення.
• 2:57
  Це єдина точка входу, яка стоїть між вашими клієнтами та бекенд-сервісами.
• 3:01
  Кожен запит спочатку проходить через шлюз. Він вирішує, куди його спрямувати, чи дозволити його, і що надіслати у відповідь.
• 3:08
  Це не нова ідея. Зворотні проксі-сервери існують десятиліттями, але Аріш-шлюз став незамінним з появою мікросервісів.
• 3:14
  Коли ви розбиваєте додаток на багато дрібних сервісів, у вас раптом з'являється багато дверей.
• 3:17
  Шлюз надає вам одні парадні двері.
• 3:19
  У світі Azure Azure Arie Management є повноцінною платформою, а шлюз – це основний компонент, що обробляє трафік.
• 3:24
  Але цей шаблон однаковий усюди. Одна точка входу – централізований контроль. Кожен запит надходить сюди.
• 3:30
  Шлюз перевіряє його, спрямовує і надсилає відповідь назад.
• 3:33
  Клієнт ніколи не спілкується з вашими бекенд-сервісами напряму. Він спілкується лише зі шлюзом.
• 3:37
  Давайте розберемо, що це означає насправді.
• 3:39
  Почнемо з найпростішого завдання – маршрутизації.
• 3:42
  Частина перша – маршрутизація трафіку.
• 3:44
  Найпростіша функція Арі Шлюзу – це маршрутизація спрямування кожного запиту до потрібного сервісу.
• 3:49
  Подумайте про те, як працює веб-сайт.
• 3:50
  Коли ви натискаєте на посилання, ваш браузер надсилає запит.
• 3:53
  Цей запит має шлях.
• 3:54
  Якщо шлях – юзаз, шлюз знає, що його треба спрямувати до сервісу користувачів.
• 3:57
  Якщо це – одаз, він йде до сервісу замовлень.
• 4:00
  Шлюз вчитує шлях, визначає, куди потрібно спрямувати запит і пересилає його.
• 4:03
  Без шлюзу ваші клієнти мають знати URL-адресу кожного окремого сервісу.
• 4:07
  Мобільному додатку потрібні адреси сервісу користувачів, сервісу замовлень, платіжного сервісу, сервісу каталогу.
• 4:12
  Це дуже багато адрес для керування.
• 4:13
  І якщо хоча б одна з цих адрес зміниться, вам доведеться оновлювати кожен клієнт.
• 4:17
  Зі шлюзом клієнти знають лише одну URL-адресу – адресу самого шлюзу.
• 4:20
  Їх не цікавить, де насправді розташовані сервіси.
• 4:23
  Вони просто надсилають запит на шлюз, а він обробляє все інше.
• 4:26
  Це один із найпоширеніших варіантів використання арі-шлюзу – маршрутизація на основі ресурсів.
• 4:30
  Дослідження Apache Apysics прямо вказує на це.
• 4:32
  Ви налаштовуєте маршрути за шляхом HTTP методом, заголовками чи навіть геолокацією клієнта.
• 4:37
  Якщо хтось у Європі надсилає запит, ви спрямуєте його до Європейського дата-центру.
• 4:41
  Якщо запит надходить зі США, він йде до Американського дата-центру.
• 4:44
  Клієнт навіть не знає, що все це відбувається.
• 4:46
  Він просто отримує швидку відповідь.
• 4:47
  Маршрутизація також допомагає з версіонуванням.
• 4:49
  Припустімо, у вас з'явилася нова версія сервісу користувачів.
• 4:52
  Старі клієнти все ще використовують V1 Users, а нові – V2 Users.
• 4:56
  Шлюз спрямовує їх на різні бекенди.
• 4:57
  Старі клієнти продовжують працювати, поки ви впроваджуєте нову версію.
• 5:01
  Ви можете змінювати бекенд, не створюючи проблем для клієнтів.
• 5:03
  Це критично важливо, коли ви керуєте активним додатком із реальними користувачами.
• 5:07
  Подумайте про платформу електронної комерції.
• 5:09
  У вас є окремі сервіси для каталогу, кошика, оформлення замовлення та облікових записів.
• 5:13
  Без шлюзу мобільний додаток повинен знати чотири різні URL-адреси.
• 5:17
  Зі шлюзом він знає лише одну.
• 5:19
  Шлюз зчитує шлях каталог, кошик, оплата, аккаунт і спрямовує запит до потрібного сервісу.
• 5:24
  Проста маршрутизація – це найлегша частина.
• 5:26
  Наступне завдання – це те, де стає справді корисно.
• 5:29
  Частина друга – безпека на вході.
• 5:31
  Кожен виклик АРІ має перевірятися, хто робить цей запит, чи має ця особа відповідні дозволи.
• 5:36
  Без шлюзу кожен сервіс має самостійно керувати автентифікацією.
• 5:39
  Це означає дублювання роботи, де легко припуститися помилки.
• 5:42
  Один сервіс може перевіряти токи неналежним чином, інший – пропустити крок, а третій – використати зовсім інший методичний.
• 5:48
  Ви отримуєте неузгоджену безпеку в усьому додатку.
• 5:51
  Шлюз змінює це.
• 5:52
  Він обробляє автентифікацію та авторизацію в одному центральному місці.
• 5:55
  Одне місце для перевірки, одне – для виконання правил, одне – для оновлення політик.
• 5:59
  Це одна з найкращих практик безпеки.
• 6:01
  Він підтверджує АРІ ключі JWT, OAT-токени або сертифікати для кожного запиту.
• 6:06
  Кожен запит проходить через одну і ту саму перевірку.
• 6:09
  Жодних винятків.
• 6:10
  Шлюз також може застосовувати правила.
• 6:12
  Ви можете задати, цей АРІ ключ може викликати лише ендпоінти читання.
• 6:15
  Або цей клієнт має доступ лише до сервісу каталогу, а не до сервісу оплати.
• 6:19
  Ви визначаєте детальні дозволи на рівні шлюзу, і вони застосовуються автоматично.
• 6:23
  Сервіси бекенду ніколи не переймаються авторизацією.
• 6:26
  Вони просто обробляють запит і повертають дані.
• 6:28
  Ось у чому річ.
• 6:29
  Шлюз – це єдине місце, де можна скасувати доступ, якщо щось пішло не так.
• 6:33
  Якщо ключ АРІ клієнта скомпрометовано, ви анулюєте його на шлюзі.
• 6:36
  Одна зміна – і все.
• 6:37
  Вам не потрібно оновлювати кожен сервіс чи щось перезапускати.
• 6:40
  Наступний запит із цим ключем буде негайно відхилено.
• 6:43
  Візьмемо реальний приклад.
• 6:44
  У банку є сервіс платежів і сервіс білінгу.
• 6:46
  Тільки сервіс платежів має право на запис у білінгову систему.
• 6:49
  Шлюз забезпечує це виконання.
• 6:51
  Якщо клієнт намагається записати дані в білінг через неправильну кінцеву точку, шлюз блокує це.
• 6:55
  Сервіс білінгу навіть не бачить такого запиту.
• 6:57
  Шлюз також може підтримувати взаємний TLS та інтеграцію з WAF для глибшого захисту.
• 7:02
  Але, по суті, це ваш перший рубіж оборони.
• 7:04
  Безпека – це одне, але що робити, коли надходить забагато запитів одночасно?
• 7:08
  Частина третя – керування трафіком.
• 7:10
  Що станеться, коли 10 тисяч користувачів одночасно звернуться до вашого додатку?
• 7:14
  Можливо, у вас флеш-розпродаж, вірусний запуск продукту або просто звичайний вівторок, коли всі вирішили увійти одночасно?
• 7:20
  Без шлюзу ваші бекенд-сервіси отримають прямий удар і можуть вийти з ладу.
• 7:24
  Не поступово, а відразу всі.
• 7:26
  Ось тут на допомогу приходить керування трафіком.
• 7:28
  Шлюз може обмежувати кількість запитів, які може зробити кожен клієнт.
• 7:32
  Обмеження частоти та регулювання швидкості – це стандартні функції.
• 7:34
  Ви встановлюєте правила на шлюзі, і він їх виконує.
• 7:37
  Ваші сервіси бекенду ніколи не відчують сплеску навантаження.
• 7:39
  Ви можете встановлювати квоти на користувача, на ARRI-ключ або на IP-адресу.
• 7:42
  Припустимо, у вас є безкоштовний рівень ARRI.
• 7:44
  Безкоштовні користувачі отримують 100 запитів на годину.
• 7:47
  Преміум користувачі – 10 тисяч.
• 7:49
  Шлюз відстежує кожен запит і застосовує ці обмеження на вході.
• 7:52
  Коли користувач безкоштовного рівня вичерпує ліміт,
• 7:54
  шлюз повертає ввічливе повідомлення «Спробуйте пізніше».
• 7:56
  Сервіси бекенду навіть не дізнаються, що був такий запит.
• 7:59
  Вони продовжують працювати, обслуговуючи платних клієнтів.
• 8:02
  Шлюз також забезпечує балансування навантаження.
• 8:04
  Якщо у вас працює кілька екземплярів одного сервісу,
• 8:07
  шлюз розподіляє запити між ними.
• 8:09
  Перший екземпляр отримує запит, другий – наступний, третій – ще наступний.
• 8:12
  Це відбувається автоматично.
• 8:14
  А якщо один екземпляр виходить з ладу, шлюз перенаправляє запити на інший.
• 8:16
  Клієнти навіть не знають про це.
• 8:18
  Вони просто отримують свою відповідь.
• 8:19
  Балансування навантаження з перевірками стану забезпечує безперебійну роботу.
• 8:22
  Шлюз пінгує кожен екземпляр, щоб переконатися, що він живий.
• 8:25
  Якщо ні, він припиняє надсилати туди трафік.
• 8:27
  Це особливо важливо для Арі з високим рівнем трафіку.
• 8:30
  Без шлюзу сплеск трафіку влучає прямо у ваші сервіси.
• 8:33
  Зі шлюзом сплеск спочатку влучає у шлюз, він поглинає його,
• 8:37
  розподіляє та захищає ваші сервіси від перевантаження.
• 8:40
  Гаразд, але що, якщо дані виглядають некоректно, коли вони надходять?
• 8:44
  Частина четверта – трансформація даних.
• 8:46
  Іноді дані, які надсилає клієнт, не відповідають тому, що очікує ваш бекенд.
• 8:50
  Можливо, клієнт надсилає JSON, а ваш бекенд розуміє лише XML.
• 8:53
  Можливо, назви полів не збігаються.
• 8:55
  Клієнт використовує FirstName, а ваш бекенд очікує FirstName з іншим форматом.
• 8:59
  Ціни відповідності призводять до помилок.
• 9:00
  За старого підходу вам довелося б виправляти кожного клієнта або переписувати бекенд.
• 9:04
  Не найкращий варіант.
• 9:05
  Шлюз може трансформувати дані до того, як вони досягнуть бекенду.
• 9:08
  Уявіть його як перекладача.
• 9:09
  Він стоїть посередині і може змінювати дані під час входу, виходу або в обох випадках.
• 9:20
  Вона працює добре.
• 9:22
  Але тепер ви створюєте новий мобільний додаток, а мобільні додатки говорять мовою JSON.
• 9:25
  Без шлюзу вам довелося б переписувати за старілу систему або змусити мобільний додаток надсилати XML.
• 9:29
  Зі шлюзом вам не потрібно робити ні того, ні іншого.
• 9:31
  Мобільний додаток надсилає JSON.
• 9:33
  Шлюз конвертує його в XML.
• 9:35
  Система отримує те, що очікує.
• 9:36
  Мобільний додаток отримує відповідь уже у форматі JSON.
• 9:38
  Нікому не довелося нічого переписувати.
• 9:40
  У цьому вся принадність.
• 9:41
  Шлюз також може додавати або видаляти заголовки, змінювати URL-адреси або маскувати конфіденційні дані.
• 9:46
  Уявіть, що відповідь містить номер кредитної картки.
• 9:48
  Ви не хочете, щоб це повернулося клієнту.
• 9:50
  Шлюз може видалити це перед відправленням відповіді або замінити на замасковану версію.
• 9:54
  Беккенду взагалі не потрібно змінюватися.
• 9:56
  Шлюз бере це на себе.
• 9:57
  Це особливо корисно при модернізації старих систем.
• 9:59
  Вам не потрібно переписувати беккен.
• 10:01
  Вам не потрібно змушувати клієнтів змінюватися.
• 10:03
  Ви просто змінюєте налаштування шлюзу.
• 10:05
  Це як перекладач на міжнародній конференції.
• 10:07
  Кожен говорить своєю мовою, але перекладач забезпечує взаєморозуміння.
• 10:10
  Шлюз – це такий самий перекладач для вашого програмного забезпечення.
• 10:12
  Отже, маршрути за ція безпека, обмеження швидкості, трансформація – це чимало.
• 10:15
  Але це не чотири окремі речі.
• 10:17
  Дозвольте показати, як вони пов'язані.
• 10:19
  Як це все працює разом.
• 10:20
  Ось у чому справа.
• 10:21
  Ці чотири завдання не є окремими.
• 10:23
  Вони працюють разом над кожним окремим запитом щоразу, коли він надходить.
• 10:26
  Шлюз перевіряє автентифікацію.
• 10:28
  Він перевіряє обмеження швидкості, рейт-ліміт.
• 10:29
  Він спрямовує запит до потрібного сервісу.
• 10:31
  Він перетворює дані, якщо це потрібно.
• 10:33
  Він отримує відповідь.
• 10:34
  Він також перетворює її, якщо необхідно.
• 10:36
  Потім він надсилає все назад клієнту.
• 10:38
  Один конвейер.
• 10:38
  Кожен крок відбувається автоматично, по черзі, без участі сервісів.
• 10:42
  Справжня сила не в якійсь одній функції, а в інтеграції.
• 10:46
  Ви можете додати нову політику безпеки, не змінюючи маршрутизацію.
• 10:49
  Бекенд-сервіс, не змінюючи клієнтську частину.
• 10:52
  Ви можете оновити ліміти запитів без повторного розгортання.
• 10:54
  Кожен елемент незалежний, але вони працюють в одному конвейері.
• 10:57
  І оскільки все проходить через одне місце, ви отримуєте повний огляд того, що відбувається.
• 11:02
  Логи, метрики, аналітика – все з однієї точки.
• 11:05
  Ви бачите кількість запитів, які з них не вдалися, які були повільними,
• 11:08
  які клієнти споживають найбільше ресурсів.
• 11:10
  Без шлюзу вам довелося б збирати ці дані з кожного сервісу окремо.
• 11:13
  Зі шлюзом все доступно відразу.
• 11:15
  У цьому головна ідея.
• 11:16
  Шлюз – це не просто маршрутизатор.
• 11:18
  Це центр керування всією вашою АРІ-платформою.
• 11:20
  Кожен запит, кожна відповідь, кожна помилка – все проходить крізь одне місце.
• 11:23
  Ви отримуєте єдину панель огляду для всього, що відбувається.
• 11:26
  Отже, як цим насправді користуватися?
• 11:28
  Давайте поговоримо про те, що ви можете зробити вже зараз.
• 11:30
  Практичні поради.
• 11:31
  Будьмо відвертими.
• 11:32
  Якщо у вас лише один або два сервіси,
• 11:34
  АРІ-шлюз вам, швидше за все, ще не потрібен.
• 11:35
  Ви можете налаштувати маршрутизацію самі,
• 11:37
  керуючи доступом у кожному сервісі.
• 11:39
  Це не елегантно, але працює.
• 11:40
  Але як тільки ви доходите до трьох сервісів
• 11:42
  або відкриваєте АРІ для зовнішніх клієнтів,
• 11:44
  складність швидко зростає.
• 11:45
  Шлюз швидко окупається.
• 11:47
  Тож, який ваш найкращий перший крок?
• 11:49
  Централізуйте автентифікацію на шлюзі.
• 11:50
  Зробіть це першочергово.
• 11:52
  Виберіть один сервіс, перенесіть перевірку доступу на шлюз.
• 11:54
  Ви відразу помітите, що код вашого сервісу став чистішим.
• 11:57
  Більше ніякої логіки перевірки токенів розкиданої всюди.
• 12:00
  Більше жодних сумнівів, чи однаково ви реалізували це в кожному сервісі.
• 12:03
  Шлюз обробляє це один раз, і кожен сервіс отримує вигоду.
• 12:06
  Наступний крок – обмеження запитів.
• 12:08
  Навіть просте обмеження захистить ваш бекенд від перевантаження.
• 12:11
  Почніть з чогось базового, наприклад, 100 запитів на хвилину для клієнта.
• 12:14
  Це зупинить неконтрольованого клієнта від виведення з ладу ваших сервісів.
• 12:16
  Ви можете говорити.