CEO Europe компанії Waites Ілля Смолієнко понад 15 років працює в ІТ, з яких понад десять – у сфері індустріального інтернету речей (IIoT) та прогнозного технічного обслуговування. У Waites він побудував екосистему з 12 сервісів для моніторингу промислового обладнання. Платформа компанії збирає дані з понад 500 тис. сенсорів і щодня отримує понад 10 млрд сигналів. Таке навантаження почало впливати на продуктивність бази даних, яка виросла до 16 ТБ. Редакція ITC поговорила з Іллею про те, як вдалося стиснути базу в AWS до 1 ТБ – і провести міграцію даних на нову базу без даунтайму.
Зміст
Коли наша база даних MySQL в AWS виросла до 16 ТБ, вона перестала бути просто «великою базою», а стала дорогою проблемою, бо утримання коштувало дедалі більше. Крім цього, її вже потрібно було оновити відповідно до актуальних вимог безпеки.
Ми розуміли, що базу потрібно зменшити. Але було суттєве «але». В AWS обсяг сховища можна легко збільшити, а для зменшення потрібно створювати нову базу й переносити в неї дані. У стандартному сценарії це означає тимчасову зупинку роботи продукту, і такий варіант нам не підходив.
Річ у тім, що ми працюємо з системою моніторингу промислового обладнання, яка безперервно обробляє дані про його роботу для виявлення несправностей. Навіть під час п’ятихвилинної паузи для міграції даних можна пропустити збій, що дорого обійдеться клієнту.
Коли я обмірковував план дій, згадав той анекдот про різницю між кардіохірургом та СТОшником: лікарю потрібно оперувати пацієнта «на ходу», не зупиняючи його «мотори». На відміну від СТОшника, який може зупинити машину, все полагодити й знову запустити. Ми мали діяти, як кардіохірург.
Для нашого випадку – провести міграцію без даунтайму – не було готового рішення. Ми багато консультувалися з Database архітекторами та командою AWS й вони одразу нас попередили: «Ви можете спробувати, але малоймовірно, що вдасться провести міграцію без повної зупинки роботи».
Крім цього виникла проблема сумісності версій. AWS не гарантував нативну реплікацію між старою та новою базами. Тобто ми не мали підтвердження, що стандартний механізм реплікації AWS відбудеться коректно.
Тому ми спроєктували власний план міграції: розбили процес на паралельні задачі, щоб вкластися приблизно у 20 хвилин активної фази – моменту перемикання на нову базу. Йшлося не про стиснення всіх 16 ТБ, а про перенесення лише тих даних, які реально потрібні в роботі, у базу обсягом 1 ТБ.
Ми почали з аудиту. Відсортували найбільші таблиці й розбиралися, які дані реально використовуються, а які накопичувалися роками без потреби. Паралельно оптимізували типи даних: переглядали системні поля й перевіряли, чи не використовуються завеликі числові типи там, де можна безпечно обійтися меншими. У кожній таблиці зазвичай є 5-6 службових колонок – created_at, updated_at, last_action, last_seen тощо. Коли таких таблиць десятки, а рядків у них мільярди, навіть зменшення розміру одного поля на кілька байтів починає суттєво впливати на загальний обсяг.
Частину таблиць ми підготували ще до основної міграції: скоротили, винесли в інші бази. Адже треба було одразу «втиснутися» в 1 ТБ.
Оскільки ми не могли з’єднати стару і нову базу через нативну реплікацію, ми використали для цього сервіс AWS Database Migration Service, який працює, як посередник між базами. Він одночасно підключається до обох: зчитує через бінарні логи зміни з джерела – «старої» бази – й відтворює їх у новій. Фактично сервіс синхронізує дані між ними майже в реальному часі.
Сам процес міграції ми вирішили розбити на невеликі паралельні задачі й запускати їх одночасно, наприклад, десять задач на перенесення таблиць різного об’єму. Це дозволило зменшити ризики: якщо одна задача зупинялася, інші продовжували виконання, і процес міграції не падав повністю.
Перш ніж виходити в продакшен, ми провели три симуляції на тестових базах без трафіку.
Створювали копію старої бази, налаштовували синхронізацію змін між старою та новою базами через сервіс для міграції й перевіряли, чи не відстає нова база під навантаженням. Нам потрібно було впевнитися, що міграція пройде без зупинки системи.
Зрештою ми створили повну копію продакшн-бази й після перевірки налаштували передачу змін зі старої бази безпосередньо в нову. Після цього почали поступово переводити на нову базу трафік з усієї Європи. Першу спробу провалили – моніторинг показав суттєве відставання: користувачі в Європі бачили старіші дані. Формально механізм передачі змін працював, але затримка була критичною. Ми зробили відкат, проаналізували вузькі місця й скоригували процес. З третьої спроби міграція пройшла успішно.
Повний цикл оптимізації та міграції зайняв близько року. Це була повна перебудова підходу до зберігання даних. Якщо підбивати підсумки, то зменшити базу вдалося завдяки комплексу архітектурних рішень, це:
Зараз наша база займає 1,2 ТБ. Загалом, нам вдалося знизити витрати на зберігання даних в три рази. Раз на квартал проводимо аудит: через статистику AWS порівнюємо, як змінилися таблиці за кілька місяців, збільшилася кількість клієнтів або сенсорів. Якщо змін немає, але даних чомусь стало більше, починаємо розбиратись, чому.
Універсальних порад, як стиснути базу даних, тут не буде. Кожен повинен приймати рішення самостійно, базуючись на власних даних та задачах компанії. Але я підкажу, на що варто звернути увагу, якщо час стискати базу уже прийшов:
Якби я міг дати собі пораду перед початком стиснення бази та міграції, я б порадив собі почати цей процес раніше, до того, як вона виросла до 16 ТБ.
Чим більша база, тим складнішим і довшим буде цей процес. Тож краще починайте його, поки ви ще в межах 2-5 ТБ.
Над текстом працювали: Анастасія Пономарьова, Альона Лебедєва, Анастасія Сімонова
Контент сайту призначений для осіб віком від 21 року. Переглядаючи матеріали, ви підтверджуєте свою відповідність віковим обмеженням.
Cуб'єкт у сфері онлайн-медіа; ідентифікатор медіа - R40-06029.