Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.
Навигация по тексту
Объект — логическая единица хранения. У него три части: ключ — уникальный идентификатор объекта в бакете; метаданные — размер, контрольная сумма и другие свойства; и сами данные — любая последовательность байт: текст, изображение, JSON, Protobuf, что угодно.
Ну почему нельзя взять и просто положить на диск?
Положить данные на диск можно. Но как только их становится много и к ним обращается не одно приложение, всплывает целый класс задач: надежность хранения, контроль целостности, атомарность операций, управление нагрузкой и доступом, работа в отказоустойчивых системах.
Большую часть из них S3 закрывает из коробки. Он выносит данные из приложения — а stateless-сервисом управлять проще. Отдает контент тем механизмом, который для этого и сделан. Дает встроенный контроль доступа и retention. И при этом обходится дешевле обычных дисков в облаке. Но это всё в теории. Ниже — где объектное хранилище реально крутится у нас в продакшене.
Статика для сайта
Классический сценарий: вынести статику сайта — изображения, CSS, шрифты — в отдельное хранилище. Клиент по-прежнему ходит в веб-приложение за динамикой, а за картинками и стилями отправляется напрямую в S3. Само приложение этот трафик уже не трогает.
Что это дает? Сайт проще масштабировать: запросы к статике уходят в отдельный сервис и не нагружают приложение. В Kubernetes такой вариант разворачивается едва ли не легче всего. На статику можно навесить отдельную аутентификацию, а через retention — автоматически вычищать устаревшие объекты.
Но у этого есть своя цена. Приложение должно уметь работать с S3 — поддержку придется заложить на его стороне. И в инфраструктуре появляется ещё один сервис, а значит, чуть больше экспертизы у команды.
Отдельный случай — когда сайт сам по себе и есть статика. Так устроены документация и сайты на статических генераторах, зеркала репозиториев пакетов (yum/dnf/apt) и видеоплощадки, раздающие видео в HLS-формате.
Хранение логов, спанов и метрик
Для логов используем Loki с бэкендом на S3. Логи хорошо ложатся в объектное хранилище: объем растет постоянно, а читают их обычно по временным диапазонам — паттерн, под который S3 и заточен. Так же устроено хранение трейсов в Tempo и долгосрочных метрик в Mimir. Быстрые метрики пишем в VictoriaMetrics, а ее бэкапы тоже складываем в S3.
Вы спросите: почему не взять time-series базу для метрик и просто диски для логов? Отвечу так: объектное хранилище эластично и по нагрузке, и по месту. А еще позволяет раскладывать свежие и старые данные по разным tier’ам — в зависимости от того, как часто к ним обращаются.
А что с бэкапами?
Инструментов под бэкапы баз хватает: WAL-G и barman-cloud для PostgreSQL, xbcloud для MySQL. У нас — barman-cloud, встроенный в CNPG (CloudNativePG). Бэкапы PostgreSQL-кластеров уходят напрямую в S3: надёжно, масштабируемо, без дополнительных дисков и с поддержкой PITR. Подробнее про наш DBaaS — в отдельной статье [ссылка].
Бэкапы виртуальных машин клиентов (BaaS)
Бэкапы клиентских ВМ работают через restic с S3 в качестве бэкенда. Выбор очевидный: объем данных непредсказуем, а хранить их в S3 дешевле, чем на блочных устройствах.
Почему не сервер с кучей дисков? S3 эластичен — растет по месту без физического перетряхивания железа. Для долгого хранения применяет дешёвые, но не менее надежные механизмы вроде erasure coding. И сохраняет данные, даже если из строя выходит сразу несколько хостов. Про архитектуру BaaS у нас тоже есть отдельная статья.
Репозитории пакетов и локальные зеркала
Наши серверы на Debian и RHEL берут пакеты из локальных зеркал, которые лежат в S3. Миллионы мелких объектов, редкие обновления, много параллельных читателей — классический сценарий для объектного хранилища.
Артефакты CI/CD
Артефакты сборок складываем в S3. Объем растет с каждым релизом, а доступ нужен из разных мест пайплайна одновременно. Единый сервер с диском тут и плохо масштабируется по размеру, и превращается в точку отказа.
Почему S3, а не scp по ssh или ansible? У S3 есть история и версионирование — либо на уровне самого хранилища, либо просто за счет разных имен артефактов. Он доступен всем участникам процесса, а операции воспроизводимы благодаря уникальным именам. Плюс бинарные данные — скомпилированные приложения, образы — удобнее держать не в Git.
Складывается классический CI/CD-пайплайн: CI собирает артефакт, кладет в S3, CD забирает его и выкатывает на целевую систему. В Kubernetes место S3 в этой цепочке занимает container registry.
Репозиторий образов контейнеров
Container registry хранит образы в S3. Образы — бинарные данные, которые никогда не меняются и часто читаются параллельно, и под такой паттерн объектное хранилище подходит хорошо. Бонус: registry по умолчанию умеет отдавать presigned URL, чтобы клиент скачивал образ напрямую из S3, не гоняя данные через сам registry. Хороший пример архитектуры, спроектированной под возможности хранилища.
Диск не ушел совсем, но потеснился
Для нас S3 закрывает целый класс задач, где данных много, они растут и их читают параллельно. И часто часть потребителей не получает прямого доступа к хранилищу — им выдают presigned URL, который дает авторизованный доступ к конкретному объекту без передачи реквизитов. Это логи, бэкапы, образы, артефакты.
Где-то по-прежнему выгоднее обычный диск — с низкой латентностью и прямым доступом к данным, и это нормально. Граница между сценариями не всегда очевидна — в этом и есть суть выбора. Надеюсь, наши примеры помогут с ней разобраться.
ссылка на оригинал статьи https://habr.com/ru/articles/1054318/