Современные компании оперируют терабайтами или даже петабайтами данных. Но часто эти данные имеют разный формат, степень структурированности и не нужны в «горячем» доступе, поэтому зачастую хранить весь массив в традиционных БД не только невозможно, но и нерационально. Как результат, бизнес все чаще использует объектные S3-хранилища.

Меня зовут Андрей Капустин. Я менеджер продукта Tarantool в компании VK Tech. В этой статье я расскажу об объектном хранилище VK Cloud, его архитектуре и месте Tarantool в ней. 

Традиционные хранилища vs S3: немного контекста

Есть два классических типа хранилищ, с которыми работают компании:

• Блочные системы хранения (например, Storage Area Network). Обеспечивают высокую производительность и минимальные задержки, подходят для высоконагруженных систем и развертывания отказоустойчивых кластеров.

• Файловые системы хранения (например, Network Attached Storage). Подходят для сред с умеренной нагрузкой и невысокими требованиями к задержкам, обычно применяются для хранения общих документов и медиаконтента.

Но у этих хранилищ есть несколько слабых мест, которые возникают при работе с большими объемами данных.

• Высокая стоимость хранения. В классических хранилищах стоимость хранения каждого гигабайта довольно высокая. Например, для хранения 1 Гб данных в СУБД с учетом репликации нужно больше 2 Гб пространства на дорогом SSD-диске. Соответственно, рост объема данных может стать тяжелой нагрузкой для бюджета компании.

• Ограниченное масштабирование. Классические хранилища тяжело масштабируются. Например, блочные системы масштабируются только вертикально (добавление дисков в рамках одного массива). Поэтому, чтобы получить дополнительное пространство, надо либо менять систему хранения, либо заменять оборудование.

• Деградация производительности. В классических системах хранения данных (СХД) увеличение количества файлов нередко приводит к увеличению времени отклика и деградации производительности всей системы. Например, файловые протоколы плохо справляются с высоким числом одновременных запросов.

• Недостаточная универсальность. Файловые СХД работают со всеми типами данных, но не обеспечивают их семантическую обработку — только хранение и доступ через файлы. Блочные, в свою очередь, работают с любыми данными на уровне сырых блоков, но не различают их типы. 

• Ограниченное управление метаданными. В файловых системах метаданные ограничены, а блочные СХД их и вовсе не поддерживают. Это усложняет поиск нужных данных в общем массиве.

То есть у классических СХД есть потолок возможностей, с которым бизнес сталкивается при увеличении объема накопленных данных. Поэтому все больше компаний начинают работать с объектными S3-хранилищами, то есть СХД, использующими объектную модель для организации данных. Так, S3-хранилища:

• легко горизонтально масштабируются, могут хранить экзабайты данных;

• позволяют хранить холодные данные дешево;

• используют метатеги, упрощая управление данными через API;

• используют плоское адресное пространство;

• оптимизированы для параллельной обработки;

• подходят для хранения любых форматов данных независимо от степени их структурированности.

Отсутствие в объектных хранилищах барьеров и «узких горлышек», характерных для классических СХД, во многом обеспечивается свойствами и архитектурой S3-хранилищ.

Что именно скрывается под капотом объектных хранилищ, разберем на примере Object Storage от VK Tech.

Архитектура и особенности работы S3 от VK Tech

Архитектурно Object Storage разделен на три функциональных уровня:

1. Фронт серверов.

2. Метаданные.

3. Storage.

Каждый из уровней разворачивается на отдельных серверах.

• Fronts. Fronts — уровень серверов, на которых выполняются все вычисления. Они работают как Proxy в распределенном кластере S3 и выполняют вычисления в режиме Near Real-time. Также они отвечают за работу с файлами через S3 API, поддерживающий HTTP-запросы.

API нашего S3 полностью совместим со стандартом Amazon S3 API, поэтому через Fronts-уровень можно создавать бакеты и проверять их содержимое, скачивать и загружать файлы, настраивать правила доступа (ACL), управлять фоновыми процессами и выполнять любые доступные в S3 операции.

• Metadata. Метасерверы — уровень, на котором хранится метаинформация обо всех объектах. К метаинформации относятся данные о правилах загрузки, хранения, обработки и скачивания файлов. Фактически серверы Metadata выполняют задачи оперативной памяти и максимально быстро предоставляют информацию о том, где и какие файлы хранятся.

Уровень метаданных работает на базе Tarantool. Это позволяет обеспечивать стабильную скорость отклика при любых объемах хранимой информации. 

• Storage. Уровень Storage формулируют серверы, на которых хранятся все объекты. Object Storage использует файловую систему ext4, которая позволяет хранить файлы размером до 16 Тб. При этом благодаря механизму многоблочного распределения (Mballoc) и внутреннему распараллеливанию загрузки (Multipart Upload) хранилище поддерживает стабильную производительность даже при работе с крупными файлами.

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

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

• Если увеличивается объем хранимых данных, мы можем просто добавить Storage-серверы. При этом, как правило, вместе с увеличением количества объектов увеличивается и объем метаинформации, поэтому слои Metadata и Storage обычно масштабируются одновременно.

Отказоустойчивость S3-хранилища обеспечивается за счет того, что Object Storage развернут на нескольких ЦОДах и работает в распределенном режиме. То есть работа ведется сразу со всеми доступными ЦОДами и объектами, которые в них расположены.

Применение нескольких ЦОДов упрощает и реплицирование. Так, по умолчанию коэффициент репликаций равен 2, то есть каждый объект хранится в двух копиях. При этом каждая из этих двух копий абсолютно всегда хранится на отдельном сервере и на отдельном диске. Так мы гарантируем доступность данных в любых сценариях.

Примечание: Стандартная задержка между ЦОДами у нас около 7 миллисекунд (но допустимо и до 30 миллисекунд). Это нужно, поскольку у нас распределенная система с синхронной записью и важно получать подтверждение с каждого ЦОДа.

Как организован доступ к файлам в S3

Мы реализовали Access Control List (ACL) — соглашение о том, кто может получать доступ к файлу и какие именно операции разрешено выполнять.

Аккаунты пользователей (Accounts) организованы в тенанты для возможности работы с файлами проектов (Projects), которые хранятся в бакетах (Buckets) без ограничений на количество файлов (Objects).

Проект — «рабочая зона», в которой пользователи S3 могут выполнять операции со своими файлами. К одному Проекту могут иметь доступ до 25 пользователей.

При добавлении в Проект нового пользователя для него создается ключевая пара:

ACCESS_KEY (публичная часть) + SECRET_KEY (секрет)

Секрет нельзя терять: он используется для подписи файлов и авторизации запросов пользователя, а также для определения владельца файла и проверки его прав доступа.

У каждого пользователя по требованию ИБ есть две ключевые пары для возможности их ротации.

Все пользователи Проекта имеют доступ ко всем бакетам Проекта.

Настройки ACL определяют, могут ли разные Проекты хранить файлы в одном бакете и другие параметры организации структуры хранения в S3.

ACL во взаимодействии с IAM (Identification Access Management — сервис управления доступом) позволяет получить полноценную, гибкую, настраиваемую ролевую модель доступа к данным S3.

Роль Tarantool в архитектуре Object Storage

В архитектуре Object Storage одно из ключевых значений имеет Tarantool, который применяется в разных аспектах и для разных задач. Например, он нужен для хранения метаданных S3.

Метаданные распределены между S3 API и File Storage и определяют правила загрузки, хранения, обработки и скачивания файлов в S3.

Основные сущности те же, что придумал Amazon:

Projects. Проекты, к которым относятся файлы в S3, — их десятки тысяч.

Buckets. Проект содержит несколько бакетов. Это подключенные к S3 локальные диски пользователей — их сотни тысяч.

Objects. Бакеты содержат объекты (их миллиарды), в которых настраиваются ключевые параметры (бизнес-логика) обработки файлов в S3:

• Идентификаторы объекта — Key и производная от него шард-функция;

• Access Control List (ACL) — кто может получать доступ к файлу и какие именно операции разрешено выполнять;

• Life Cycle — набор статусов и правила обработки файла в S3: «Логика» при вставке файла и «Параметры устаревания/удаления».

Multipart. Соглашение о том, как отказоустойчиво загружать большие файлы по HTTP в несколько потоков, в том числе Политика ретраев (сколько раз, с какого места) и Логика партиционирования (резки) файлов.

• Большие файлы режет сам S3-клиент на куски файлов заданного размера (примерно по 5 Мб).

• Куски загружаем в S3 в произвольном порядке, потом их можно собирать в заданном порядке. 

• При этом куски физически хранятся в S3 как отдельные файлы и не склеиваются. 

• При запросе от клиента мы последовательно отдаем ему все куски в одном соединении.

Для прозрачности описания процесса работы с метаданными мы ввели внутренние «говорящие имена» для различных Тарантулов, получилось так: 

• Компонент Wires. Stateless-инстанс Tarantool — Proxy для работы с метаданными.

• Компонент Fringes. Еще несколько Stateless-инстансов Tarantool — серверный Sharding Proxy для работы с основным кластером хранения метаданных Matters.

• Компонент Hitbox. Отдельный инстанс Tarantool — Storage для сущностей Projects, Buckets.

• Компонент Matters. Распределенный кластер Tarantool — Storage для основной сущности метаданных Objects.

Конфигурация Matters = (1 мастер + 2 реплики) * 256 шардов

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

Если файл заливали кусками, то Matters хранит инфу о структуре файла:

• перечень кусков; 

• размер каждого куска;

• порядок для склейки: 

  • например, залили 7 кусков, а собрали из 1+2+3;

  • при этом куски 4, 5, 6, 7 храним «вечно».

Как Tarantool работает с метаданными S3

1. Запущен Event-Loop-процесс в операционной системе, который слушает Socket.

2. Приходящее событие запускает Fiber (Job) — код на LUA в Wires.

3. Wires идет в ETCD за конфигурацией, чтобы понять, какие Connections надо

открывать для Fringes.

4. Затем Wires идет в Hitbox для определения шарда Matters, на котором хранится нужный Object:

• Все запросы от S3 API содержат bucket_id + object_id, значит, мы можем посчитать:

  • шард-функцию от Bucket — получаем range шардов хранения;

  • шард-функцию от Object — получаем конкретный шард.

5. Затем Fringes вызывает конкретную функцию по работе с файлами (PUT, GET) на

выбранном шарде Matters.

Ниже мы подробно рассмотрим операцию PUT загрузки файла в S3: 

Синтаксис PUT 1Mb

Этап 1. Аутентификация и авторизация

1. Пользовательский HTTP-запрос на загрузку файла приходит в Hitrod из Nginx.

2. Hitrod идет в Wires для авторизации Проекта.

3. Wires запрашивает из Hitbox параметры project_id, bucket_id.

4. Hitbox уведомляет Wires о возможности загружать файл данного Проекта.

5. Wires возвращает параметры Проекта в Hitrod.

Этап 2. Размещение файла в S3

1. Hitrod открывает соединение.

2. Hitrod прокачивает трафик через Streamers — workers с capacity 110 Мбайт/с на CPU, который физически загружает файл в S3.

3. После загрузки Streamers возвращает в Hitrod хэш файла SHA1 HASH, по которому

в дальнейшем можно будет получить файл из S3, используя операцию GET <file>.

Этап 3. Обновление метаданных файла

function(PutObjectComplete)

parameters(project_id, bucket_id, object_id, sha1 hash)

1. Hitrod идет в Wires для выполнения операции PutObjectComplete.

2. Wires открывает соединение для Fringes и передает в него все параметры для

выполнения PutObjectComplete.

3. Дополнительно Wires считает и передает параметры, необходимые для S3:

• hash md5;

• sha256.

4. Внутри Fringes на LUA написана хэш-функция для определения конкретного

шарда Matters HASH function(bucket, object) -> X from range [0...255], в который Fringes проксирует операцию PutObjectComplete.

5. Matters загружает в себя метаданные файла (INSERT или UPDATE).

6. Matters возвращает OK во Fringes.

7. Fringes возвращает OK в Wires.

8. Wires возвращает OK в Hitrod.

9. Hitrod говорит OK пользователю и передает ему md5 + sha256.

10. Файл успешно загружен в S3.

Сервис биллинга мы также реализовали на Tarantool.

Помимо этого, Tarantool применен в основе системы рейт-лимитов, которая позволяет нам балансировать нагрузку на все участки хранилища и стабильно выдерживать нагрузку, которая приходит на S3.

Наряду с этим Tarantool также используется для хранения SSL-сертификатов. В нашей реализации это позволяет управлять сертификатами извне и обеспечивает крайне быструю отдачу.

Data Lakehouse на базе Object Storage

Отдельно необходимо отметить, что использование Object Storage в системах обработки информации и управления позволяет сократить затраты на хранение неструктурированных данных. 

В 2024 году мы вывели на рынок новый продукт VK Data Platform, а в 2025-м реализуем для наших заказчиков корпоративные хранилища данных (КХД) на базе архитектуры Data Lakehouse (DLH), ключевым компонентом которой является Object Storage, обеспечивающий гибкость, масштабируемость и экономическую эффективность хранения данных.

DLH — гибридная архитектура управления данными, сочетающая в себе удобство и удешевление инфраструктуры для хранения единицы объема сырых неструктурированных данных Data Lake и высокую производительность выполнения аналитических SQL-запросов с гарантией качества предоставляемых результатов, как в DWH.

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

Неструктурированные данные из источников различных форматов (tsv, csv, xml, syslog, json и т. д.) хранятся в недорогом облачном S3-хранилище. Это могут быть:

• видеозаписи с беспилотников и камер наружного наблюдения;

• телеметрия с датчиков и устройств;

• графические изображения;

• логи поведения пользователей с сайтов и информационных систем;

• прочие данные с разными форматами хранения (схемами представления).

В сыром виде они непригодны для ежедневной аналитики в BI-системах, но могут использоваться для быстрой отработки новых бизнес-гипотез с помощью алгоритмов ML/AI и других методов Data Science.

Для организации полноценного доступа аналитических сервисов к данным DLH необходимо:

1. Разметить и каталогизировать информацию об объектах в S3-хранилище в одном из общепринятых открытых форматов (например, Apache Parquet или Iceberg).

2. Подключить через предоставляемый ими API-интерфейс движок выполнения SQL-запросов на базе Trino или Apache Spark для сквозной потоковой Real-time-передачи событий. 

Мы получаем гибкость и удобство эксплуатации, так как Dataset можно положить в S3+Iceberg и обращаться к нему разными сервисами (ETL — Apache Spark, Ad-hoc — Trino, BI — ClickHouse).

Таким образом, DLH позволяет использовать инструменты бизнес-аналитики непосредственно в исходных данных, повышая их актуальность, а также уменьшая задержку и затраты, связанные с необходимостью выполнения ETL-операций, как в Data Lake или в классическом DWH.

О том, что мы получим после реализации всех планов, а также о наших проектах внедрения Data Lakehouse обязательно расскажем в одной из следующих статей. 

Что в итоге

Сегодня Object Storage VK Cloud доступен в разных вариантах поставки: 

• On-premise-инсталляция, развертываемая на оборудовании заказчика;

• хранилище в публичном облаке VK Cloud;

• преднастроенный программно-аппаратный комплекс.

При этом у VK Cloud одна из самых крупных инсталляций объектного хранилища в России:

• в 6 ЦОДах хранится более 350 Пб данных — около 95 млрд объектов, из них 35 млрд в горячем доступе;

• скорость чтения данных — более 350 Гб/сек;

• среднее время отклика (TTFB) — менее 20 мс;

• производительность обработки запросов — более 20 000 RPS.

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

Вместе с тем мы не останавливаемся на достигнутом и продолжаем развитие Object Storage. Так, в перспективе мы планируем реализовать функционал Object Versioning, репликацию master-master/master-slave, разделение данных по тирам (NVMe/HDD), антивирусную защиту и другие возможности.

---

Подписывайтесь на каналы VK Cloud | Новости сервисов, Вокруг Kubernetes в VK и Данные на стероидах. Обсуждайте новости и рабочие моменты в чате пользователей платформы.