Оптимизация хранилища: как мы сжали базу данных в 16 раз и перестали переплачивать AWS

CEO Europe компании Waites Илья Смолиенко более 15 лет работает в IT, из которых более десяти – в сфере индустриального интернета вещей (IIoT) и предиктивного технического обслуживания. В Waites он построил экосистему из 12 сервисов для мониторинга промышленного оборудования. Платформа компании собирает данные с более чем 500 тыс. сенсоров и ежедневно получает больше 10 млрд сигналов. Такая нагрузка начала влиять на производительность базы данных, которая выросла до 16 ТБ. Редакция ITC поговорила с Ильей о том, как удалось сжать базу в AWS до 1 ТБ и провести миграцию данных на новую базу без даунтайма.

Мы должны были действовать, как кардиохирург

Когда наша база данных MySQL в AWS выросла до 16 ТБ, она перестала быть просто «большой базой», а стала дорогой проблемой – её содержание обходилось всё дороже. Кроме того, её уже нужно было обновить в соответствии с актуальными требованиями безопасности.

Мы понимали, что базу нужно уменьшить. Но было одно существенное «но». В AWS объём хранилища можно легко увеличить, а чтобы уменьшить его, нужно создавать новую базу и переносить в неё данные. В стандартном сценарии это означает временную остановку работы продукта, и такой вариант нам не подходил.

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

Когда я обдумывал план действий, вспомнил анекдот о разнице между кардиохирургом и автомехаником: врачу нужно оперировать пациента «на ходу», не останавливая его «мотор». В отличие от механика, который может остановить машину, всё починить и снова её запустить. Нам нужно было действовать как кардиохирург.

Аудит и сжатие

Для нашего случая – провести миграцию без даунтайма – готового решения не было. Мы много консультировались с database-архитекторами и командой AWS, и они сразу предупредили: «Вы можете попробовать, но маловероятно, что получится провести миграцию без полной остановки работы».

Поэтому мы спроектировали собственный план миграции: разбили процесс на параллельные задачи, чтобы уложиться примерно в 20 минут активной фазы – момент переключения на новую базу. Речь шла не о сжатии всех 16 ТБ, а о переносе только тех данных, которые действительно нужны в работе, в базу объёмом 1 ТБ.

Мы начали с аудита. Отсортировали самые большие таблицы и разбирались, какие данные действительно используются, а какие накапливались годами без необходимости. Параллельно оптимизировали типы данных: пересматривали системные поля и проверяли, не используются ли слишком большие числовые типы там, где можно безопасно обойтись меньшими. В каждой таблице обычно есть 5–6 служебных колонок — created_at, updated_at, last_action, last_seen и тому подобные. Когда таких таблиц десятки, а строк в них миллиарды, даже уменьшение размера одного поля на несколько байт начинает существенно влиять на общий объём.

Часть таблиц мы подготовили ещё до основной миграции: сократили их объём и вынесли в другие базы. Нужно было сразу «уложиться» в 1 ТБ.

Симуляции и миграция

Поскольку мы не могли соединить старую и новую базы через нативную репликацию, мы использовали сервис AWS Database Migration Service, который работает как посредник между базами. Он одновременно подключается к обеим: считывает через бинарные логи изменения из источника – «старой» базы – и воспроизводит их в новой. Фактически сервис синхронизирует данные между ними почти в реальном времени.

Сам процесс миграции мы решили разбить на небольшие параллельные задачи и запускать их одновременно, например десять задач по переносу таблиц разного объёма. Это позволило снизить риски: если одна задача останавливалась, другие продолжали выполняться, и процесс миграции не падал полностью.

Мы создавали копию старой базы, настраивали синхронизацию изменений между старой и новой базами через сервис миграции и проверяли, не отстаёт ли новая база под нагрузкой. Нам нужно было убедиться, что миграция пройдёт без остановки системы.

В итоге мы создали полную копию продакшен-базы и после проверки настроили передачу изменений со старой базы напрямую в новую. После этого начали постепенно переводить на новую базу трафик со всей Европы. Первая попытка провалилась — мониторинг показал существенное отставание: пользователи в Европе видели более старые данные. Формально механизм передачи изменений работал, но задержка была критической. Мы сделали откат, проанализировали узкие места и скорректировали процесс. С третьей попытки миграция прошла успешно.

Результат

Полный цикл оптимизации и миграции занял около года. Это была полная перестройка подхода к хранению данных. Если подвести итоги, уменьшить базу удалось благодаря комплексу архитектурных решений:

• Оптимизация типов данных – уменьшение размера числовых и служебных полей там, где это было безопасно.
• Декомпозиция больших таблиц – разделение на более мелкие логические части.
• Сегментация быстро накапливающихся данных и переход на более компактные форматы хранения.
• Перенос логовых данных в отдельное time-series хранилище (Timescale) с настройкой автоматического удаления через TTL.
• Перемещение крупных текстовых объектов в DynamoDB или MongoDB.
• Внедрение TTL на один месяц для сессий в Redis.
• Введение чёткой политики хранения данных – 1, 3 или 5 лет в зависимости от требований клиента с последующим архивированием в файловое хранилище.

Сейчас наша база занимает 1,2 ТБ. В целом нам удалось снизить расходы на хранение данных в три раза. Раз в квартал мы проводим аудит: через статистику AWS сравниваем, как изменились таблицы за несколько месяцев, увеличилось ли количество клиентов или сенсоров. Если изменений нет, но данных почему-то стало больше, начинаем разбираться, почему.

Инсайты

Универсальных советов, как сжать базу данных, здесь не будет. Каждый должен принимать решения самостоятельно, исходя из собственных данных и задач компании. Но я подскажу, на что стоит обратить внимание, если уже пришло время оптимизировать базу:

• Анализируйте throughput (пропускную способность): смотрите на объёмы данных – сколько их проходит в секунду на запись и сколько на чтение.
• Оцените допустимость простоя: можете ли вы позволить себе остановить базу, например, на 2-4 часа? Если да – проблем нет: делайте снапшоты, поднимайте новую базу, а клиентов предупреждайте о профилактических работах. Задача решена.
• Оцените непрерывность процессов: если остановка невозможна, единственный выход – репликация любыми доступными способами.
• Следите за динамикой costs и квартальными отчётами, чтобы понимать, сколько вы тратите на архитектуру.
• Помните, что симуляция – это святое: тесты покажут, как будет вести себя база данных во время изменений в продакшене.

Если бы я мог дать себе совет перед началом сжатия базы и миграции, я бы порекомендовал начать этот процесс раньше – до того, как она выросла до 16 ТБ.

Чем больше база, тем сложнее и дольше будет этот процесс. Поэтому лучше начинать, пока её размер ещё находится в пределах 2-5 ТБ.

Над текстом работали: Анастасия Пономарева, Алена Лебедева, Анастасия Симонова