Автомасштабування та канареечний випуск в Azure Container Apps з KEDA і Dapr

Чому Azure Container Apps втрачає запити під час піку

Azure Container Apps масштабує контейнери за подіями та метриками, але на різкому піку трафіку застосунок все одно починає віддавати 5xx. Справа не в нестачі ресурсів, а в затримці керуючого контуру: рішення про додавання реплік приймається повільніше, ніж зростає навантаження.

Правило автоскейлінгу спирається на усереднену метрику за вікно спостереження — лічильнику потрібно набрати статистику, перш ніж він спрацює.

Поки вікно заповнюється, кількість одночасних запитів на кожну репліку вже подвоїлася, вхідна черга зростає, а нові екземпляри ще не створені. Масштабування контейнерів іде ступенями, а трафік приходить фронтом.

Далі вступає холодний старт: репліці потрібно отримати образ, підняти рантайм, прогрітися та пройти перевірку готовності. Перші секунди вона або не приймає трафік, або приймає його непрогрітою — час відповіді на цій ділянці вищий, ніж у вже працюючих екземплярів. Якщо перевірки готовності налаштовані формально, потік іде на процес, який ще не тримає з'єднання.

Так відмови під час піку складаються з двох хвиль: спочатку вхідний потік перевищує поточну ємність до спрацювання автоскейлінгу, потім частина запитів потрапляє на неготові репліки.

У метриках це 503 на вході, зростання 95-го та 99-го процентиля часу відповіді та обриви з'єднань у частини клієнтів.

Розбираємо, як це закривається: попереджувальні правила автоскейлінгу під пікове навантаження, прогрів і поступова видача трафіку, щоб масштабування встигало раніше, ніж черга запитів перетвориться на відмови.

Що дає автоскейлінг і канареечний випуск

Канареечний випуск тримає дві ревізії одночасно: на нову йде 5-10% трафіку, решту обслуговує попередня. Частку помилок і час відповіді нової ревізії порівнюють з базовою в реальному часі — при виході за поріг трафік повертається на перевірену ревізію за секунди. Простою сервісу при цьому немає: користувач не бачить ні перезапуску, ні обривів з'єднань.

Масштабування за подіями змінює профіль реакції на навантаження. Репліки додаються не за завантаженням процесора, а за довжиною черги та кількістю незакритих повідомлень, тому нічний сплеск розбирається на десятки секунд раніше, ніж встиг би спрацювати поріг за метриками заліза.

У Azure Container Apps правила масштабування та розбиття трафіку між ревізіями описані декларативно, тож поведінка під навантаженням відтворюється на будь-якому стенді, а не налаштовується заново.

Звідси — класи інцидентів, які перестають доходити до користувача:

• деградація після релізу: відкат секундами, без ручного втручання чергового;
• відмова однієї зони: репліки піднімаються в тих, що залишилися, час відновлення — одиниці секунд;
• нічна черга: ємність зростає разом з нею і так само йде вниз, коли потік спав.

Підсумок вимірний: час відновлення скорочується з хвилин до секунд, частка відмов обмежена розміром канареечної частки трафіку, а ємність слідує за навантаженням без переплати за простій.

Режими масштабування та стратегії випуску версій

В Azure Container Apps масштабування та випуск версій спираються на один механізм — незмінні ревізії застосунку. Кожна ревізія отримує свою частку трафіку, тому розкатка нового складання та відкат виконуються перемиканням ваг, без перезбирання та простою.

Потужність задається правилами: за завантаженням процесора та пам'яті, за довжиною черги, за розкладом — аж до масштабування до нуля.

Загальне обмеження: сумісність даних

Загальне обмеження у всіх стратегій — стан. Поки трафік ділиться між версіями, зміни схеми зобов'язані бути зворотно сумісними: спочатку додаємо поля і читаємо обидва формати, старі прибираємо тільки після повного перемикання. Інакше відкат поверне код, який вже не розуміє дані.

Як ми впроваджуємо автоскейлінг: етапи робіт

Порядок робіт будується від виміряного навантаження до правил, а не навпаки: спочатку знімаємо профіль попиту в Azure Container Apps, потім фіксуємо схему масштабування і тільки потім вмикаємо зміни в робочому контурі. Розбіжність між тестовою та робочою поведінкою сервісу — звичайне джерело хибних спрацювань.

1. Обстеження навантаження. Знімаємо метрики за кілька тижнів: інтенсивність запитів, тривалість обробки, глибину черг, споживання ресурсів на піках. За ними вибираємо тригер, що відображає реальний попит, а не побічну ознаку.
2. Схема масштабування. Розводимо фронт, API та фонові обробники на незалежно масштабовані групи, задаємо мінімум і максимум реплік і розділяємо оточення, щоб розробка не конкурувала з продом за ємність.
3. Налаштування правил. Описуємо тригери KEDA — черга, потік подій, розклад — і підбираємо вікна охолодження з кроком нарощування, щоб репліки не смикалися на коротких сплесках. Правила зберігаємо як код і проводимо через рев'ю.
4. Canary-деплой. Виводимо версію на частку трафіку, порівнюємо частку помилок і час відповіді з базовою, відкат налаштовуємо автоматичним за порогом.
5. Приймальні перевірки. Прогоняємо профіль навантаження з першого кроку зі ступінчастими піками та відмовою зовнішньої залежності: заміряємо час виходу на пік, стелю реплік і час повернення.
6. Передача в експлуатацію. Віддаємо конфігурацію в репозиторії, дашборди за репліками та тригерами, алерти на упор у стелю та на відмови, регламент чергування з типовими сценаріями.

Конфігурації, схеми та регламенти після впровадження

Після виведення сервісу в продуктив у команди залишається не тільки працюючий контур, а й набір артефактів, за якими його можна змінювати без нас.

Все лежить у репозиторії замовника разом з історією правок: зміна конфігурації проходить рев'ю і потрапляє в середовище тим самим шляхом, що й код, тому в Azure Container Apps не з'являється налаштувань «руками через консоль». Нижче — що саме передаємо.

• Конфігурація масштабування — правила та діапазон реплік за кожним сервісом, пороги спрацювання за метриками, поведінка при простої та час прогріву перед прийомом навантаження.
• Схема сервісів — зв'язки між компонентами, точки входу, черги та зовнішні залежності, з явною межею відповідальності застосунку та платформи.
• Правила доступу — ролі, посвідчення сервісів, мережеві обмеження та порядок видачі прав новому компоненту або підряднику.
• Регламент випуску — порядок канареечного випуску: частка трафіку на нову ревізію, метрики-критерії просування та умови автоматичного повернення.
• Інструкція з відкату — покрокове повернення на попередню ревізію, включаючи сумісність зі схемою даних та перевірки після відкату.
• Карта спостережуваності — які метрики, журнали та оповіщення заведені, на які пороги налаштовані та хто отримує повідомлення при спрацюванні.
• Пам'ятка по оточеннях — чим відрізняються середовища, де зберігаються секрети та змінні, як додати нове середовище без правки шаблонів.

Кейс: пікове навантаження без ручного втручання

Сервіс оформлення заявок для корпоративних клієнтів тримав пік в кінці робочого дня та на початку звітного періоду: за годину приходило стільки ж запитів, скільки за решту доби.

Масштабування було прив'язане до завантаження процесора, а воно зростало вже після того, як черга на обробку переповнювалася.

На піку частка неуспішних запитів сягала 8 %, відгук на 95-му процентилі розтягувався до кількох секунд, а черговий інженер піднімав репліки вручну три-чотири рази за добу.

Застосунок перенесли в Azure Container Apps і перевели масштабування на зовнішні метрики — довжину черги та кількість одночасних запитів замість завантаження процесора.

Поріг підйому задали із запасом, а гасіння реплік — із затримкою, щоб коротка просадка не знімала вже прогріті екземпляри.

Перед включенням у роботу прогнали навантажувальні випробування за зліпком реального піку: тримали граничний профіль і дивилися, за скільки виходить потрібна кількість реплік і як поводиться черга при різкому скиданні.

За результатами підняли мінімальну кількість реплік і налаштували прогрів, щоб перша хвиля запитів не потрапляла в холодний старт.

Після переведення чергування стали плановими — раз на тиждень замість трьох-чотирьох викликів на добу. Частка неуспішних запитів знизилася з 8 % до 0,4 %, відгук на 95-му процентилі скоротився втричі, пік обслуговується без участі інженера. Викат на частку трафіку залишили включеним: відкат на попередню версію займає хвилини.

Чим автоскейлінг в Azure відрізняється від ручного

Ручне масштабування тримає задану кількість реплік: платформа не дивиться на навантаження, поки інженер не змінить значення сам.

На рівномірному потоці це передбачувано, але сплеск — зростання черги, затримки, відмови — закриває тільки черговий, а в години затишшя ви платите за простій ресурсів.

Масштабування за розкладом знімає частину ручної роботи: правило задає, скільки реплік тримати в робочі години і скільки вночі. Це працює при повторюваному профілі навантаження і ламається на разових акціях.

Подієве масштабування спирається на метрику: довжину черги, кількість одночасних запитів, завантаження процесора.

Поріг масштабування та вікно стабілізації вирішують, при якому значенні додається репліка і як довго вона живе після спаду — вузьке вікно дає «дрижання», широке залишає зайву потужність.

Комбінована схема в Azure Container Apps закриває обидва сценарії: розклад виводить базовий рівень до ранкового піку, подієвий тригер добирає репліки під фактичне навантаження.

Ми спочатку знімаємо профіль навантаження, потім підбираємо пороги і підтверджуємо їх навантажувальним тестом — інакше правило виглядає робочим, але не спрацьовує там, де потрібно.

Технічні питання, які задають перед стартом

Перед стартом питання в інженерної команди зазвичай одні й ті самі: що станеться з активними з'єднаннями в момент випуску, чи доведеться переписувати застосунок, де верхня межа масштабування і як система поводиться, коли джерело подій недоступне.

Нижче — короткі відповіді без маркетингу, рівно в тому вигляді, в якому ми обговорюємо їх на технічній сесії.

Чи потрібно переписувати застосунок?

У більшості випадків ні. Застосунок збирається в той самий контейнер, що й раніше, а зверху додаються декларативні правила: за якою подією масштабуватися, скільки ревізій тримати, як розподіляти трафік.

Точкові доопрацювання потрібні, тільки якщо сервіс сам керує з'єднаннями з джерелом подій або тримає стан у пам'яті процесу.

Де верхня межа масштабування?

Задається явно: мінімальна та максимальна кількість реплік плюс правило за метрикою. Це захист від лавини — при сплеску навантаження зростає передбачувано до виставленої стелі, а не до вичерпання квоти.

Ми підбираємо межі за профілем навантаження: скільки подій приходить на піку, як швидко обробляється одна, який запас потрібен на розігрів.

Що робити, якщо джерело подій недоступне?

Розділяємо два випадки — недоступність джерела та відставання черги. Пороги вішаємо на довжину черги, а не тільки на самі події, щоб масштабування реагувало на накопичення.

Поведінка реплік при нульовому навантаженні теж налаштовується: ухід у нуль або утримання мінімуму, якщо сервісу потрібен прогрів.

Обговоримо задачу автоскейлінгу та випуску версій

Щоб повернутися з оцінкою та планом, а не із загальними міркуваннями, нам потрібен мінімум вхідних даних від замовника.

Нижче — те, що запитуємо на першій розмові; зазвичай вистачає півгодини обговорення та доступу до репозиторію з маніфестами та конфігурацією платформи, включаючи Azure Container Apps.

• Профіль навантаження: добовий і тижневий графік, пікові вікна, частка фонових і періодичних задач, розподіл запитів за операціями.
• Схема сервісів: які компоненти не зберігають стан, які тримають його самі, хто спілкується синхронно, а хто через черги та події.
• Поточні правила масштабування та вузькі місця: як поводиться система при сплеску, скільки триває запуск нового екземпляра, що впирається в ліміти платформи.
• Вимоги до випуску версій: частка трафіку на канареечний варіант, умови автоматичного відкату, допустиме вікно часткової деградації.
• Доступи та обмеження: середовища, приватні мережі, ролі, політики безпеки та регламент змін у проді.
• Приймання результату: які метрики вважаємо цільовими і на яких сценаріях перевіряємо — різкий сплеск, відмова екземпляра, відкат на попередній реліз.

Опишіть задачу у вільній формі — повернемося з оцінкою, планом робіт і розбивкою на етапи. На созвоні покажемо, як рішення лягає на вашу схему сервісів, і заздалегідь узгодимо порядок приймання результату.