Оскільки ми говоримо про Azure Front Door (AFD), варто згадати збій, що стався 29 жовтня.
Для тих, хто не знайомий з AFD: це глобальний балансувальник навантаження рівня 7 (Layer 7). Він має безліч точок присутності (PoPs) по всьому світу.
Як це працює:
-
Клієнт підключається до найближчої точки присутності.
-
Використовується Split TCP, який завершує TLS-сесію локально для швидшої відповіді.
-
AFD отримує контент із здорового бекенду.
-
Підтримує кешування та інтеграцію з Web Application Firewall (WAF).
Цей сервіс широко використовується як Microsoft-сервісами (наприклад, Office 365, Xbox, Entra), так і сторонніми постачальниками.
Причина збою та вирішення
Збій спричинила зміна конфігурації тенанта, яка випадково створила некоректний стан конфігурації, що зробило велику кількість вузлів “нездоровими”.
У результаті це зменшило пропускну здатність обробки запитів. Виправлення передбачало відкат до останньої коректної конфігурації, що зайняло кілька годин.
Microsoft уже виявила та усунула помилку в програмному забезпеченні, яка дозволила обійти захисні перевірки при розгортанні некоректної конфігурації.
Що можуть зробити клієнти
З архітектурної точки зору: як можна самостійно мінімізувати ризики?
-
Azure Front Door — це глобальний балансувальник навантаження, але як резервний варіант можна розглянути Azure Traffic Manager.
Однак слід врахувати:-
Traffic Manager базується на DNS;
-
Він не має можливостей WAF, кешування або Split TCP;
-
Не підтримує приватні ендпоїнти чи непублічні сервіси.
-
Отже, хоча це не повна альтернатива, Traffic Manager може бути “аварійним рішенням” у надзвичайних ситуаціях.
Microsoft серйозно інвестує у запобігання подібним інцидентам, адже вони впливають не лише на клієнтів, а й на сервіси самої компанії — M365, Minecraft тощо.