Lifecycle policies: чому сховище зростає без контролю
Активний шар об'єктного сховища зростає не ривками, а рівним потоком: логи, дампи, проміжні артефакти збірки, прев'ю, щоденні копії. Кожне джерело додає невеликий префікс, і поки для нього не задані lifecycle policies та строк зберігання даних, не видаляється нічого.
За кілька місяців сховище впирається не у фізичний обсяг, а в квоту та швидкість операцій: лістинг префікса перестає вкладатися в розумний час, а фонові завдання, що перебирають ключі, конкурують за ліміти запитів.
Окрема лінія проблеми — версіонування. Увімкнене одного разу «про всяк випадок», воно зберігає кожен перезапис як неактивну версію, а без правила на її видалення старі копії лежать вічно.
Туди ж ідуть незавершені багатопотокові завантаження: їхні частини не видні у звичайному лістингу, але займають місце й враховуються в квоті. У S3-сумісних сховищах це виглядає як розбіжність: у консолі об'єкт один, за фактом їх десять.
Ціна такого стану — не лише місце. Сканування префікса за маскою на мільйонах ключів займає хвилини, через що сповільнюються вивантаження, аналітика та відновлення.
Ліміти на частоту операцій спільні для бакета, тому один забутий префікс із логами обвалює передбачуваність сусідніх сервісів.
Розбираємо, як це закривається: які правила задати одразу — що переводити в холодний клас, що видаляти за віком, як поводитися з неактивними версіями та обірваними завантаженнями, щоб переповнення сховища не поверталося після кожного ручного чищення.
Що змінюється після впровадження правил зберігання
Правила життєвого циклу переводять зберігання з ручного режиму в декларативний: політика описує, через скільки днів об'єкт виходить з активного шару, коли переходить у холодний клас і коли видаляється безповоротно.
Обсяг активного шару скорочується кратно — резервні копії та журнали, які роками лежали поруч із робочими даними, переїжджають в архів за розкладом. Перебір об'єктів у контейнері прискорюється, бо операції читання більше не спотикаються об мільйони неактуальних файлів.
Архівація об'єктів прибирає головну причину нічних чергувань — переповнення тому, після якого відмовляють записи й завантаження файлів.
MinIO та інші об'єктні сховища віддають події життєвого циклу й метрики за класами зберігання, тому частка відмов через заповнення диска падає до нуля: клас відмов знімається на рівні правила, а не реакцією чергового.
Час реакції на інцидент скорочується, бо оповіщення приходить за прогнозом заповнення, а не за фактом падіння сервісу. Інженер бачить, який префікс або тег порушив політику, і або править правило, або розбирає конкретне джерело даних.
Відкат при цьому залишається можливим: версіонування разом із правилом на останні N версій дозволяє повернути об'єкт, поки він не переступив межу видалення.
Варіанти політик: видалення, архівація, перекладання
Правило життєвого циклу — це набір дій, прив'язаних до префікса, тегу або віку об'єкта, а не одна галочка в налаштуваннях сховища.
Застосовуються вони відкладено, зазвичай раз на добу, тому між потраплянням об'єкта під умову та фактичним видаленням або переведенням у холодний шар минає час.
Режими не взаємовиключні: робоча конфігурація комбінує два-три, а вибір диктує те, за якою ознакою дані втрачають цінність.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Видалення за розкладом | Логи, вивантаження, тимчасові артефакти збірок із передбачуваним строком життя | Рахується вік, а не звернення: затребуваний файл піде раніше, ніж його перестануть читати |
| Переведення в холодний шар | Резервні копії, аудиторські вивантаження, дані з рідкісним доступом | Мінімальний строк зберігання в шарі: повернення раніше строку знецінює переведення, а відновлення займає години |
| Перекладання за тегами | Об'єкти, чия цінність змінюється за подіями — закриття проєкту, зміна статусу клієнта | Об'єкт без тега правило не побачить, а масова простановка тегів — окреме завдання |
| Робота з версіонуванням | Сховище з увімкненим версіонуванням, де важливий захист від перезапису | Видалення без урахування версій залишає маркери й не звільняє місце, потрібні окремі правила для неактивних версій |
| Перекладання за зверненням | Великі набори з непередбачуваним попитом | Вбудовані правила працюють за віком і тегами, а не за частотою читання — потрібен збір метрик і зовнішній планувальник |
Окремо перевіряємо накладення правил: якщо об'єкт підпадає одразу під кілька умов, спрацьовує найконкретніше, і результат рідко читається за описом політики.
Тому набори правил проганяємо на копії даних і звіряємо за журналом звернень — так видно, скільки об'єктів пішло в холодний шар, а скільки видалено, і чи не зачеплені активні шляхи.
Порядок налаштування lifecycle policies: етапи роботи
Lifecycle-політика застосовується до бакета цілком і спрацьовує без підтвердження: правило з невірним префіксом або строком видаляє об'єкти мовчки, а відкат можливий лише з резервної копії.
Тому ми не вмикаємо правила одразу в робочому контурі — спочатку фіксуємо фактичний стан сховища, збираємо схему, перевіряємо її на копії даних і лише потім переносимо в прод.
- Аудит сховища. Збираємо список бакетів і префіксів, дивимося обсяг, вік об'єктів, частку холодних даних і вже чинні правила — отримуємо карту, де політик немає зовсім, а де вони конфліктують.
- Інвентаризація об'єктів. Розмічаємо дані за строком і цінністю: що видаляти, що переводити в архівний клас, що не чіпати. Окремо позначаємо версії та об'єкти з обов'язковим строком зберігання.
- Схема правил. Описуємо політику таблицею: префікс, строк життя, перехід між класами, доля незавершених завантажень і старих версій. Перевіряємо, що правила не перекривають одне одного.
- Налаштування політик. Переносимо схему в правила бакета, фіксуючи конфігурацію як код — її можна відтворити на іншому контурі та відкотити однією правкою.
- Перевірка на тестовій копії даних. Копіюємо вибірку робочого бакета, проганяємо правила з укороченими строками й дивимося, що видалилося, що пішло в архів і чи не зачеплені потрібні об'єкти.
- Передача команді. Віддаємо карту бакетів, опис правил і журнал змін, показуємо, як перевірити спрацьовування політики й як скасувати правило без втрати даних.
Комплект документації, схем і регламентів
Комплект — не звіт про виконану роботу, а файли, які інженер відкриває в перший же день експлуатації. Кожен артефакт прив'язаний до конкретного рішення: правила автовидалення, політики архівування або ролі доступу, тому при зміні вимог видно, що саме правити, а не перепитувати. Усе складається у вашу систему контролю версій разом з історією правок.
- Файли конфігурації lifecycle-правил — з коментарем, до якого класу даних належить кожне правило і який строк воно задає.
- Схема сховища: які об'єкти залишаються в гарячому шарі, що вирушає в архів і за якою ознакою спрацьовує перехід.
- Регламент зберігання — строки за типами об'єктів, винятки для резервних копій і юридично значущих документів, порядок погодження змін.
- Матриця доступу: хто з ролей читає, записує та змінює правила, де проходить межа між прикладною командою та платформенною.
- Порядок відкату: як повернути об'єкт з архіву, скільки це займає, хто ініціює і що перевіряється до та після відновлення.
- Звіт верифікації: скільки об'єктів пройшло перехід і видалення на тестовому контурі, які розбіжності знайдені та як закриті.
- Інструкція з розширення — як додати новий бакет або правило, не зачепивши вже працюючі.
Кейс: як реєстр файлів перестав зростати
Вихідний стан
Реєстр накопичував усе: кожен реліз тягнув за собою всі шари образу, чорнові збірки жили в тих самих просторах імен, що й релізні, а перервані завантаження залишалися висіти невидимими фрагментами.
Обсяг додавав близько 9–10% на місяць, і чистили його руками раз на квартал: інженер звіряв список тегів з останніми збірками та видаляв решту на свій розсуд. Помилка в цьому списку коштувала відкату — одного разу стерли образ, з якого ще не переїхали на новий реліз.
Сховище зростало швидше за навантаження: інвентаризація займала години, вікно резервного копіювання розтягувалося, вартість утримання реєстру переставала бути передбачуваною.
Що налаштували
Правила життєвого циклу винесли в декларацію: останні 10 образів на релізний тег залишаються, чорнові теги видаляються через 14 днів, перервані завантаження — через добу, журнали переходять у холодний клас через 30 днів і стираються через рік.
Платформа об'єктного сховища MinIO сама оцінює вік об'єкта при зверненні, тому розклад завдань і ручні запуски більше не потрібні, а право на видалення залишилося лише в сервісного облікового запису.
Ключове: lifecycle-правила не чіпають теги, позначені як релізні, — відкат на попередню збірку залишився доступним.
Метрики до та після
Приріст обсягу впав з 9–10% на місяць до менш ніж 1%, активний простір скоротився втричі. Інвентаризація — з чотирьох годин до кількох хвилин, вікно резервного копіювання коротше приблизно на третину, бо копіюються лише потрібні об'єкти.
Час відкату на попередній реліз не зріс, але тепер це гарантована операція, а не удача при ручному чищенні.
Чим правило життєвого циклу відрізняється від версіонування?
Це механізми різних рівнів, і плутати їх дорого. Версіонування зберігає історію об'єкта: кожен перезапис створює нову версію, а видалення залишає маркер видалення — минулі версії продовжують займати місце.
Правило життєвого циклу керує їхньою долею в часі: переводить у холодний клас, видаляє неактуальні версії, чистить незавершені складені завантаження.
Типова помилка — увімкнути версіонування «для надійності» й не завести правило. Обсяг зростає лінійно від кількості перезаписів, а потрібну версію дедалі важче знайти.
Зворотна помилка — правило без версіонування: місце звільняється, але перезапис незворотний і відкотити реліз нічим.
Третій шар — захист від видалення: строк зберігання блокує видалення версії до заданої дати, безстрокове блокування не знімається взагалі. Правило життєвого циклу таку версію не зачепить — вона не потрапляє в кандидати, поки діє блокування.
| Механізм | Завдання | Від чого захищає | Вплив на обсяг |
|---|---|---|---|
| Версіонування | зберігає всі версії та маркери видалення | від втрати даних при перезаписі | зростає з кожним перезаписом |
| Правило життєвого циклу | переводить у холодний клас, видаляє за віком | від безконтрольного зростання | знижує та стабілізує |
| Захист від видалення | блокує видалення до строку | від випадкового та зловмисного видалення | задає мінімум |
В одному сховищі вони працюють разом: версіонування увімкнене, правило тримає задану кількість останніх версій і прибирає решту, частина префіксів іде в холодний клас, а нормативно значущі — під блокування. Відкат на попередню збірку залишається можливим, а обсяг перестає зростати безконтрольно.
Технічні питання про політики зберігання
Lifecycle-правило застосовується ретроактивно: планувальник обходить бакет і оцінює за фільтром не лише нові завантаження, а й об'єкти, що лежать там з минулого проходу.
Тому правило з фільтром за префіксом або тегом спочатку проганяють у режимі звіту — видно, скільки об'єктів і якого віку потрапить під архівацію або видалення, — і лише потім вмикають перехід у холодний клас або очищення.
Оборотність залежить від версіонування бакета. Без нього видалення остаточне, і повернути об'єкт можна лише із зовнішньої копії.
З версіонуванням об'єкт перетворюється в delete marker: відновлення — це зняття маркера або копіювання попередньої версії як поточної, тому правило чищення логічніше націлювати на старі версії, а не на актуальні.
Чи зачепить правило об'єкти, завантажені до його увімкнення?
Так. Вік рахується від дати завантаження, а не від дати створення правила, тому планувальник підхопить і накопичений масив. Щоб не знести зайве, задайте поріг за віком явно вище за строк зберігання свіжих даних.
Як повернути помилково видалений об'єкт?
За версіонування — зняти delete marker або скопіювати попередню версію як поточну. Без нього залишається відновлення з резервної копії або з репліки в іншому регіоні.
Як перевірити правило, не втративши дані?
Прогнати на тестовому префіксі або копії бакета: звіт покаже, що саме потрапить під видалення або архів. Вузький префікс і журналювання дають зрозумілий слід — видно, що і коли змінило стан об'єкта.
Чи можна змінити строк зберігання після запуску правила?
Так, правило редагується, і новий строк застосовується при наступному проході планувальника. Уже перенесені в холодний клас об'єкти там і залишаться — зворотний перехід у гарячий клас описують окремим правилом заздалегідь.
Обговоримо задачу: аудит сховища та план впровадження
Щоб повернутися з оцінкою обсягу робіт і планом налаштування правил, а не із загальними міркуваннями, нам потрібен зріз поточного стану сховища. Чим точніші вихідні дані, тим менше припущень в оцінці й тим швидше перший варіант політик іде в тестовий контур на копії даних.
Що підготувати до розмови:
- Перелік сховищ і префіксів: призначення кожного, які сервіси та команди в них пишуть і читають.
- Обсяги: кількість об'єктів і сумарний розмір, розподіл за віком — частка даних старших за місяць, квартал, рік.
- Профіль звернень: за логами видно, що реально читається, а що лежить мертвим вантажем і лише займає місце.
- Вимоги до строків: де є нормативні строки зберігання, де дані потрібні безстроково, де видалення допустиме без повернення.
- Класи зберігання: які вже підключені та які переходи між ними дозволені у вашого провайдера.
- Обмеження: версіонування, блокування об'єктів, реплікація в інший регіон, залежності від кешувальних шарів.
- Схема відкату: як відновити об'єкт, якщо правило видалить зайве, і хто підтверджує зміни в правилах.
- Точки контролю: хто з боку замовника погоджує політики й за якими метриками ми підтверджуємо, що вони працюють.
Опишіть задачу у вільній формі — що зберігається, що турбує, які строки горять. Повернемося з оцінкою обсягу робіт, планом впровадження та списком ризиків за кожним сховищем.
