Налаштування Azure Cosmos DB: API, шардування та Terraform

Azure Cosmos DB: де налаштування за замовчуванням не витримує навантаження

Azure Cosmos DB прощає багато на стенді з одним розробником і майже одразу починає заважати в проді.

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

Найчастіше помилка ключа розділу походить з моделі даних, а не з конфігурації.

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

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

Окрема історія — ручні правки в консолі: індекси, рівні узгодженості, політики часу життя та профілі масштабування, виставлені «нашвидкуруч» під час інциденту.

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

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

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

Що дає вивірена конфігурація сховища

Вивірена конфігурація Azure Cosmos DB — це не разовий запуск, а набір параметрів, кожен з яких видно в метриках: ключ розділу, політика індексування, рівень узгодженості, запас пропускної здатності.

Їхнє поєднання визначає, скільки операцій проходить без повторних спроб і як швидко повертається відповідь.

Зниження частки відмов під час пікових сплесків

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

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

Передбачуваний відгук на читання та запис

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

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

Що фіксуємо у звіті за підсумками:

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

Режими узгодженості та моделі ємності

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

Узгодженість: що втрачаємо і що отримуємо

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

Виділена ємність проти еластичної

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

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

Як ми ведемо роботи в Azure: від аудиту до передачі

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

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

Що уточнюємо на вході

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

1. Аудит схеми розділів. Розбираємо ключі розділів, індекси та профіль запитів: де читання йде по всіх розділах, які з них упираються в стелю на піці. На виході — карта вузьких місць і вердикт щодо розкладки.
2. Проєкт розділення та режиму узгодженості. Добираємо ключ під реальні запити, перевіряємо зростання розділів і обираємо рівень узгодженості — він впливає на затримку та на допустимі розходження між репліками.
3. Інфраструктура як код. Контейнери, пропускну здатність, індекси та ролі доступу описуємо декларативно: конфігурація живе в репозиторії, проходить перевірку й розгортається в кількох середовищах однаково.
4. Налаштування Cosmos DB через Terraform і міграція без простою. Піднімаємо нову розкладку поруч із робочою, перемикаємо трафік поетапно та переносимо дані під контролем відставання. Вікно недоступності — нуль, відкат на попередню схему залишається напоготові.
5. Перевірка на навантажувальному профілі. Проганяємо піковий і затяжний сценарії, дивимося поведінку при зростанні розділів, налаштовуємо оповіщення та правила масштабування. Регламент резервного копіювання фіксуємо письмово й перевіряємо відновлення.
6. Передача та навчання команди. Віддаємо репозиторій, схему середовищ, політики доступу та порядок змін, проводимо розбір з інженерами — супровід іде без нас.

Що залишається у вас після впровадження: конфігурації та регламенти

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

Склад документації, що передається

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

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

Кейс: перезбирання схеми розділів під пікове навантаження

Орендний сервіс: замовлення, склад, звіти. Контейнери в Azure Cosmos DB зростали разом із кількістю клієнтів, і на сезонних піках запити починали відвалюватися. Розбирали не навантаження, а схему розділів: її колись спроєктували під рівний потік, а не під пік.

Що було до

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

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

Що стало після

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

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

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

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

Що робити, якщо база вже розгорнута і зростає навантаження?

Перебудувати схему розділів на живих даних можна — але не «на місці».

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

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

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

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

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

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

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

Спірні місця: узгодженість, індекси, доступ

Майже кожне рішення щодо Cosmos DB — компроміс між затримкою, доступністю та витратою одиниць запиту. На рев'ю перед запуском спливають ті самі сумніви — нижче короткі відповіді на ті, що найчастіше гальмують погодження.

Індексувати всі поля — це нормально?

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

Чи можна обійтися без мастер-ключа в застосунку?

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

Що дає резервне копіювання і як відновлюватися?

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

Хто з'їдає бюджет обробки запитів?

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

Обговоримо завдання і повернемося з планом робіт

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

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

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