Чому черга Azure Service Bus втрачає повідомлення на піках
На піку навантаження черга Azure Service Bus поводиться інакше, ніж на тестовому контурі: глибина зростає швидше, ніж споживачі розбирають повідомлення, і втрата повідомлень проявляється не одразу.
Спочатку це затримка обробки, потім зростання кількості спроб доставки, потім черга недоставлених. Причина майже ніколи не в самому брокері — складаються ліміти підписки, відсутність обмеження паралелізму у споживача і занадто короткий час життя повідомлення.
Далі вмикається каскад: повідомлення не підтверджується вчасно, блокування спливає, брокер віддає його повторно, і обробник запускає ту саму операцію вдруге. Повторна доставка перетворюється на дублі списань, поки черговий розбирає інцидент вручну.
Частина повідомлень при цьому йде в чергу недоставлених, частина спливає за часом життя — відновити їх вже нема чим.
Ціна збою — не лише простій обміну. Кожен інцидент розбирається вручну: підняти метрики, зіставити ідентифікатори, знайти крок, на якому загубилося повідомлення, доставити його повторно і при цьому не задвоїти операцію. Якщо права на чергу видані широко, додається ризик: будь-який сервіс може читати й видаляти чуже.
Тому починаємо не з налаштувань, а з розбору потоку: де повідомлення може загубитися, які повтори безпечні, чим обмежений споживач на піку і за якою ознакою черговий розуміє, що час втручатися. Нижче — як це закривається.
Що дає керована шина: стійкість і спостережуваність
Керована шина Azure Service Bus знімає цілий клас відмов інтеграції завдяки підтвердженням доставки та повторним спробам із наростаючою паузою. Повідомлення залишає чергу лише після успішної обробки, а при вичерпанні спроб переходить у чергу недоставлених із кодом причини.
Дублі відсікаються ключем ідемпотентності на боці споживача — повторний запуск після збою не породжує других замовлень і списань.
Спостережуваність будується на метриках самої шини: довжина черги, вік найстарішого повідомлення, кількість повторних спроб, частка спрацювань запобіжника.
Наскрізний ідентифікатор пов'язує запис у шині з обробкою в сервісі, тому інцидент розбирається за журналом, а не за розрізненими логами застосунків. Сповіщення ставимо на зростання черги недоставлених — черговий дізнається про проблему раніше, ніж її помічає бізнес.
Доступ розводиться за ролями: відправники тільки пишуть, споживачі тільки читають, розбір недоставлених — окрема роль для чергового. Ключі живуть у сховищі секретів і ротуються, прямі рядки підключення в конфігурації сервісів не залишаються.
Навантажувальний профіль проганяємо до продакшену: пікова подача, відмова одного споживача, тривала затримка обробки.
Після такого прогону час відновлення після збою вимірюється хвилинами, частка втрачених повідомлень за підтвердженими надсиланнями — нульова, а обсяг ручних розборів падає до одиниць на тиждень.
Режими доставки та топології черг
Топологія черги визначає не лише маршрут повідомлення, а й те, як система поводитиметься при збої. Неправильно вибраний режим доставки проявляється тільки під навантаженням: дублі замовлень, загублена подія, застрягла черга розвантаження. Нижче — варіанти, між якими реально обирають під час проєктування обміну.
Варіанти обміну та їх обмеження
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Черга «точка-точка» | один виробник — один споживач: команди, завдання на обробку | конкуруючі споживачі не зберігають порядок за бізнес-ключем |
| Топік із кількома підписками | подія має незалежно піти кільком системам | кожна підписка зберігає свою копію, обсяг зростає лінійно за кількістю споживачів |
| Сесії | суворий порядок у межах ключа: одне замовлення, один рахунок | сесію обробляє один споживач — паралелізм нижчий |
| Дедуплікація | джерело повторює надсилання при своєму збої | вікно зберігання ключа обмежене, а ключ потрібно задавати явно |
| Автопересилання | розвантаження вхідної черги і маршрутизація за ознакою | ланцюжок приховує шлях повідомлення, ускладнює розбір інцидентів |
Режими комбінуються: сесії поверх підписок дають порядок за ключем і незалежних споживачів, а дедуплікація разом з автопересиланням закриває повторну доставку на стику сервісів.
Важливо, що кожне поєднання змінює і профіль навантаження — кількість одночасних обробників, час життя повідомлення, поріг переходу в чергу недоставлених.
Ми фіксуємо вибрану топологію в схемі обміну і в налаштуваннях, щоб поведінка при збої була передбачуваною. На платформі Azure Service Bus ці режими задаються декларативно, тому схема залишається відтворюваною між середовищами.
Впровадження: від аудиту до передачі в експлуатацію
До правок у робочому контурі ми фіксуємо поточний стан обміну повідомленнями: хто публікує, хто читає, де повідомлення губляться або обробляються двічі.
Аудит інтеграції дає карту потоків і перелік вузьких місць, тому кожен наступний етап спирається на перевірені дані, а не на припущення.
- Аудит інтеграції. Розбираємо видавців і підписників, топіки та черги Azure Service Bus, клієнтські повтори й ділянки без захисту від дублів. На виході — схема потоків із часом обробки та обсягом повідомлень, що пішли у відкладені.
- Проєктування схеми. Розкладаємо навантаження за чергами й підписками, задаємо правила повторної доставки, час життя повідомлення і відсікання дублів.
- Налаштування черг і доступів. Створюємо сутності, налаштовуємо розділення прав між сервісами й людьми: кожен отримує рівно ті операції, які йому потрібні.
- Навантажувальна перевірка. Проганяємо піковий потік і сценарії відмови: недоступний підписник, повільна обробка, зростання черги. Дивимося, чи відновлюється система сама і за який час.
- Регламент експлуатації. Описуємо пороги спрацювання, дії чергового, порядок виведення повідомлень із відкладених і правила зміни налаштувань.
- Передача в підтримку. Проводимо розбір схеми з вашою командою, віддаємо документацію і залишаємося на зв'язку на період перших змін.
Політики доступу, ролі та регламенти: що передаємо
На виході замовник отримує не «налаштовану чергу», а комплект, за яким сервіс можна експлуатувати, передати іншій команді та пройти перевірку безпеки.
Для Azure Service Bus це особливо важливо: доступ тут видається на рівні простору імен і окремих сутностей, і без явного регламенту права розповзаються за пару місяців. Нижче — мінімальний набір артефактів, який передаємо разом із працюючою шиною.
- Політики доступу — окрема політика на надсилання, приймання та керування для кожного сервісу замість одного спільного ключа на все середовище.
- Ролі та ключі — прив'язка сервісів через керовані ідентичності, де це підтримується; там, де немає — ключ із зазначенням власника, строку ротації та порядку відкликання.
- Розмежування прав — матриця «сервіс → черга або топік → дозволені операції», за якою видно, хто і куди може писати або читати.
- Схема потоків повідомлень — відправники, підписники, правила фільтрації, обробка повторів і черга недоставлених повідомлень.
- Опис сутностей — черги, топіки, підписки, час життя повідомлень, захист від дублів, режим сесій: усе з обґрунтуванням вибраних значень.
- Документація — топологія, правила найменування, перелік власників сервісів та інструкція з підключення нового споживача.
- Регламент обслуговування — періодичність ротації ключів, порядок виведення сервісу з доступу, розбір накопичених недоставлених повідомлень і пороги сповіщень.
Такий пакет знімає головну проблему експлуатації — коли шина працює, але ніхто не знає, які права кому видані і що робити при відмові. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Кейс: потік замовлень під піковим навантаженням
До змін весь потік замовлень ішов через одну чергу Azure Service Bus: підписників було двоє, а рядок підключення з правами і на надсилання, і на читання видавали в спільний конфіг.
У пік один із підписників падав, повідомлення поверталися в чергу й оброблялися повторно — покупці отримували по два однакових замовлення, а черговий інженер розбирав дублі вручну.
Відновлення після такого збою займало до 40 хвилин, і зрозуміти причину було нічим: метрики черг ніхто не знімав.
Що саме змінили
- Розвели потоки: пріоритетні замовлення, фонова аналітика й сповіщення поїхали в окремі черги зі своїми підписниками та лімітами.
- Увімкнули дедуплікацію за ідентифікатором замовлення й обмежену кількість повторних спроб із переведенням у чергу недоставлених повідомлень.
- Замінили рядок підключення на видачу прав за ролями: у кожного сервісу тільки ті операції, які йому потрібні.
- Налаштували сповіщення на довжину черги, вік найстарішого повідомлення й частку записів у черзі недоставлених.
Що показали метрики
Частка дублів впала з 1,4% до 0,02% — повторна обробка перестала бути штатним сценарієм. Час відновлення після падіння підписника скоротився з 40 хвилин до 4: повідомлення залишаються в черзі, поки сервіс не повернеться.
У пік черга розбирається за лічені хвилини, вік найстарішого повідомлення не виходить за поріг сповіщення, а замовлення, що потребують ручного втручання, вимірюються одиницями на добу замість сотень.
Чим Service Bus відрізняється від саморобної черги?
Саморобна черга — це зазвичай таблиця в базі та фонове опитування за розкладом. Поки споживач один і потік невеликий, схема тримається, але на другому обробнику з'являються гонки за рядок, подвійна обробка і «залиплі» записи, які ніхто не повертає в роботу.
Керована шина, наприклад Azure Service Bus, закриває доставку сама: підтвердження обробки, автоматичний повтор при збої, окрема черга нерозібраних повідомлень, порядок і захист від дублів. За вами залишається ідемпотентність самого обробника — її не замінить жоден брокер.
Експлуатаційне навантаження розподіляється інакше: саморобну чергу ви обслуговуєте повністю — чищення накопиченого, міграції схеми, резервування, чергування.
У шини це на боці постачальника, а глибина черги, кількість повторів і недоставлені повідомлення видно в метриках, доступ до топіків роздається ролями через каталог.
Обмеження теж є: розділюваний сервіс задає стелі на розмір повідомлення, кількість підписок і регіон розміщення. Вибір зведено в таблицю.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Черга у своїй базі | один споживач, низький потік, усе в одному контурі | немає гарантій доставки, повтор вручну, гонки за рядок |
| Брокер на своїх серверах | вимоги до розміщення даних, нестандартні правила | відмовостійкість і чергування повністю на вас |
| Керована шина | кілька споживачів, потрібні повтори, порядок, розбір недоставлених | ліміти розділюваного сервісу, залежність від платформи |
Технічні сумніви перед стартом робіт
Перед стартом робіт із чергами Azure Service Bus замовники та їхні інженери порушують приблизно однаковий набір питань: як перейти без зупинки сервісів, що робити з вже написаними споживачами й виробниками, хто отримає доступ і що побачить черговий у момент збою. Нижче — короткі відповіді, щоб до оцінки залишилося менше невідомих.
Чи можна перевести черги без зупинки сервісів?
Так, міграція черг іде паралельним контуром: піднімаємо новий простір імен поруч із робочим, вмикаємо пересилання повідомлень зі старого в новий, перемикаємо споживачів по одному і тримаємо попередній контур на відкаті узгоджений строк.
Застосунок не зупиняється — необроблені повідомлення чекають на перемикання в черзі, повторна доставка гаситься налаштуванням кількості спроб і вікна блокування.
Чи доведеться переписувати код під іншу бібліотеку?
Сумісність визначається протоколом обміну повідомленнями, а не версією бібліотеки в застосунку. На практиці змінюються рядок підключення, налаштування повторних спроб і ознака завершення сесії — логіка обробки залишається попередньою. Повне переписування плануємо тільки там, де зараз використовуються саморобні обгортки поверх черг.
Як видаються доступи і де зберігаються ключі?
Доступи видаємо через модель ролей із розділенням прав на надсилання, читання та керування, окремо на простір імен і на конкретну чергу. Права отримують сервісні облікові записи, а не люди: співробітник іде — доступ до черг не змінюється.
Секрети живуть у сховищі секретів і підставляються в середовище виконання, у репозиторії та конфігураціях їх немає.
Що бачить черговий і коли спрацьовує сповіщення?
Моніторинг будується на чотирьох сигналах: довжина черги, вік найстарішого повідомлення, частка повідомлень у черзі необроблених і зростання кількості повторних доставок. За кожним задаємо поріг і час утримання, щоб чергування не піднімали через короткий сплеск.
До сповіщень додаємо інструкцію з розбору: де дивитися, що перезапустити, у якому разі телефонувати розробнику.
Обговоримо задачу за вашими чергами
Оцінка за чергами майже ніколи не зводиться до «підніміть нам Azure Service Bus»: обсяг робіт визначається профілем навантаження та вимогами до доставки.
Чим точніші вхідні дані на старті, тим менше припущень у плані — і тим менше переробок після перших прогонів під реальним трафіком.
Нижче — те, що варто додати до опису задачі. Частина даних вже є в моніторингу, частину достатньо оцінити порядком величин:
- схема потоків: хто публікує повідомлення, хто їх читає, скільки потрібно черг і підписок, що йде у відкладену обробку;
- профіль навантаження: середня та пікова інтенсивність, добовий і тижневий ритм, допустима затримка доставки в години пік;
- вимоги до доставки: чи допустимі повтори, чи потрібен суворий порядок обробки, через скільки невдалих спроб повідомлення йде в чергу необроблених;
- модель доступу: хто із сервісів і команд до яких сутностей звертається, чи потрібні окремі права на надсилання та читання;
- режим реагування: куди йдуть сповіщення, хто дивиться на них у неробочий час, які пороги вважати аварійними;
- поточний стан і рамки: чи є вже розгорнуті черги, скільки повідомлень накопичено, чи планується перенесення з іншого брокера, як викочуються конфігурації.
Далі ми звіряємо вхідні дані з обмеженнями платформи й повертаємося з оцінкою робіт, складом етапів і строками. Якщо якихось даних немає — так і напишіть: підкажемо, як їх зняти або чим замінити, щоб не гальмувати старт.
