Температура данных: как выбрать идеальный баланс между скоростью и стоимостью хранения

Температурный режим данных: суть концепции

В мире современных IT-инфраструктур объем информации постоянно растет. Чтобы не разориться на хранении и при этом обеспечить пользователям необходимую скорость и нагрузку в индустрии используют концепцию «температуры» данных. Если вкратце, то вся информация делится на категории в зависимости от того, как часто к ней обращаются и с какой скоростью.

Такой подход помогает найти баланс между стоимостью хранения и производительностью. Экономически нецелесообразно хранить архивные данные на самых быстрых накопителях, если к ним обращаются несколько раз в год. И наоборот, экономия на данных, которые постоянно читаются и записываются, может обойтись дороже из-за потери производительности. Понимание «температуры» позволяет распределить файлы таким образом, чтобы платить за скорость только там, где она действительно нужна, а уже тяжелые архивы складировать на максимально дешевых накопителях.

Сравнение температурных режимов

Для каждого температурного класса рынок диктует разные технические требования и финансовую модель. Рассмотрим их подробнее.

Горячие данные

Это данные, с которыми ваше приложение, сервисы или пользователи работают прямо сейчас в режиме реального времени. Для такого класса критичны минимальная задержка, высокая пропускная способность и максимальная доступность, а также большое количество запросов в секунду (RPS). 

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

Несколько примеров: 

• горячий слой хранения в Data Platform;
• AI/ML-датасеты, активно используемые для обучения моделей;
• транзакции (финансовые операции, процессинг оплат), которые требуют мгновенного отклика.

Стандартные данные 

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

Примеры:

• медиафайлы стриминговых сервисов, которые сейчас находятся в тренде (сериалы, вирусные видео);
• CRM-системы, карточки клиентов и история взаимодействий, с которыми менеджеры работают в ежедневном режиме;
• рабочие файлы (документы, презентации);
• раздача прошивок для обновления ПО.

Холодные данные

Холодные данные — это своего рода архив, к которому могут не обращаться неделями. Такая информация лежит «до востребования» и как правило в гигантских объемах, поэтому стоимость хранения здесь минимальна, но за извлечение данных приходится платить ощутимо больше. 

Среди примеров:

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

Ледяные данные

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

Примеры:

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

Какой класс хранилища выбрать

Описанная выше концепция разделения данных по температурам идеально ложится на технологию объектного хранения S3. В современных объектных хранилищах логическое разделение на «горячее», «стандартное», «холодное» и «ледяное» материализуется уже в виде конкретных классов хранения.

Выбор класса хранения — это всегда важное бизнес-решение. Ошибочный выбор гарантированно ведет к неоправданным финансовым потерям. Например, если разместить редко используемые архивные файлы в горячем хранилище, компания получит огромные счета за хранение. И наоборот: если отправить в «холодный» класс данные, к которым системы обращаются постоянно, бизнес столкнется с колоссальными затратами из-за высоких тарифов за API-запросы.

Для удобства и быстрого выбора правильного класса хранения вы можете ориентироваться на следующую матрицу параметров:

Параметр	Горячее	Стандартное	Холодное	Ледяное
Скорость	🦖🦖🦖🦖	🦖🦖🦖	🦖🦖	🦖
RPS (Количество запросов)	🦖🦖🦖🦖	🦖🦖🦖	🦖🦖	🦖
Стоимость хранения	🦖🦖🦖🦖	🦖🦖🦖	🦖🦖	🦖
Стоимость запросов	🦖	🦖🦖	🦖🦖🦖	🦖🦖🦖🦖

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

Выделенное S3-хранилище — это полноценное объектное хранилище с S3 API AWS, которое разворачивается в инфраструктуре Selectel специально под задачи одного клиента. Для такого проекта выделяются отдельные стойки, серверы и сетевое оборудование, поэтому все ресурсы работают только под вашу нагрузку.

Ранее в отдельной статье мы уже рассказывали, как мы строим наше S3. Из данной статьи важно подметить, что класс хранения — это результат проектирования инфраструктуры. 

Производительность, стоимость хранения и стоимость операций зависят от сочетания нескольких факторов: типа накопителей (HDD SATA, SSD SATA или NVMe SSD), политики защиты данных в Ceph, конфигурации и количества серверов, а также сетевой топологии и количества зон доступности (Single-AZ — данные хранятся в одном дата-центре или Multi-AZ — данные хранятся в нескольких дата-центрах). Именно комбинация этих параметров позволяет подобрать оптимальную архитектуру под конкретный профиль нагрузки, поэтому проектирование выделенного S3 начинается с обсуждения требований к системе. Вместе с заказчиком фиксируются ответы на ключевые вопросы.

• Для каких именно целей планируется использовать S3?
• Какое количество запросов в секунду (RPS) ожидается на пиках?
• Какие показатели RTO/RPO необходимы для бизнес-задачи?
• Какой совокупный объем хранения требуется?
• В какой локации необходима инсталляция?
• Есть ли необходимость в геораспределении (Multi-AZ)?

На основе этих требований проектируется архитектура хранилища. Такой подход оправдан прежде всего для крупных инсталляций — как правило, при объемах данных от 1 ПБ, когда индивидуальная конфигурация позволяет оптимизировать как производительность, так и стоимость эксплуатации. Проектирование, поставка оборудования и развертывание занимают некоторое время, поэтому для задач, где инфраструктура нужна сразу или объемы хранения существенно меньше, обычно рациональнее использовать публичное S3, о котором мы еще поговорим чуть позже.

Ниже рассмотрим примеры того, как могут выглядеть инфраструктуры для разных классов хранения. Это не универсальные шаблоны, а возможные варианты архитектуры, которые показывают общий подход к проектированию.

Инфраструктура для горячих данных

Архитектура строится вокруг максимизации RPS и минимизации любых «бутылочных горлышек».

• Дисковая подсистема для Ceph — NVMe SSD.
• Серверы (ноды) — платформы с мощными многоядерными процессорами и большим объемом ОЗУ. Небольшое количество дисков на сервер хранения (например, 10-12 NVMe), чтобы шина PCIe и CPU не стали узким местом.
• Сеть — от 200 GbE (Гбит/с) до 1,5 TbE (Тбит/с) и более.
• Защита данных в Ceph — тройная репликация. Это дает максимальную скорость чтения/записи, так как не тратится время CPU на вычисление контрольных сумм и четности.

Инфраструктура для стандартных данных

Здесь ориентируемся на баланс между скоростью, плотностью хранения и стоимостью сервера.

• Дисковая подсистема для Ceph — SATA SSD, но можно рассмотреть и HDD.
• Серверы (ноды) — серверы хранения средней плотности, например, 24 диска на узел, со сбалансированным CPU.
• Сеть — от 100 GbE до 200GbE.
• Защита данных — тройная репликация.

Инфраструктура для холодных данных

В случае работы с холодными данными фокус смещается на плотность хранения и удешевление каждого терабайта. RPS уходит на второй план.

• Дисковая подсистема для Ceph — вместительные SATA HDD объемом 18, 20, 22 ТБ.
• Серверы (ноды) — серверы с высокой плотностью дисков, вмещающие 36 или более жестких дисков в одном шасси. Требования к CPU и RAM минимальны.
• Сеть — от 40 до 100 GbE. Высокая пропускная способность для последовательного чтения больших файлов важнее, чем задержка.
• Защита данных в Ceph — Erasure Coding. Это экономит место по сравнению с репликацией, обеспечивая при этом приемлемую скорость сборки данных при чтении.

Инфраструктура для ледяных данных

В случае с ледяными данными мы ориентируемся на экстремальное снижение затрат на хранение.

• Дисковая подсистема для Ceph — диски HDD максимального объема.
• Серверы (ноды) — серверы хранения высокой плотности от 60 дисков.
• Сеть — от 10 до 40 GbE.
• Защита данных — Erasure Coding.

Публичное S3-хранилище

Выделенное S3 оправдано для крупных проектов, где требования к производительности, стоимости хранения или отказоустойчивости невозможно закрыть типовой конфигурацией. Во всех остальных случаях, когда ресурсы нужны «здесь и сейчас», быстрее и проще начать работу с публичным S3, которое не требует проектирования и доступно сразу после создания бакета.

Публичное S3 Selectel поддерживает API Amazon S3 и предлагает готовые классы хранения — стандартный, холодный и ледяной. Благодаря этому можно подобрать оптимальный вариант хранения без самостоятельного проектирования инфраструктуры.

Рассмотрим ключевые преимущества публичного S3 Selectel.

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

Отсутствие штрафов за раннее удаление в ледяном классе. В нашем S3 нет обязательного минимального срока хранения (например, 90 или 180 дней) для ледяных данных.

Отказоустойчивость уровня Multi-AZ. Доступны конфигурации регионов с синхронным распределением и хранением данных сразу в трех независимых дата-центрах, что защищает систему от полной остановки даже при масштабных авариях на уровне одного ЦОД.

Публичное S3 Selectel подходит для хранения медиаконтента, резервных копий, логов, аналитических данных и ML-датасетов. Благодаря совместимости с API Amazon S3 его можно интегрировать практически в любое приложение без изменения привычных инструментов и библиотек.

Заключение

Выбор «температурного» режима — это всегда взвешенное бизнес-решение. Грамотное распределение файлов позволяет превратить разрозненные терабайты информации в строго упорядоченную систему, где инфраструктурный бюджет расходуется максимально эффективно, а бизнес получает необходимую скорость доступа без переплат.

Итог один: анализируйте свои данные перед их загрузкой в S3. Четкое понимание того, как часто ваши пользователи или внутренние системы будут читать конкретный объект, позволяет выбрать правильный класс S3-хранилища с самого первого дня.