Объектное хранилище Ozon: где закончился S3 «из коробки»

https://www.youtube-nocookie.com/embed/YjPOklU4eX0

Автор: Максим Харитонов (Ozon) · CodeFest Russia

---

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

Максим Харитонов рассказывает об эволюции объектных хранилищ Ozon: от простоты MinIO до собственного S3-сервера поверх Ceph и ScyllaDB. Самое интересное здесь — не масштаб сам по себе, а выбор границы переделки. Команда столкнулась с ограничениями Ceph, но не отказалась от него: надёжное хранение данных её устраивало, а вот устройство S3-индекса стало мешать дальнейшему росту.

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

Из этого можно взять в работу: прежде чем заменять инфраструктурный компонент целиком, проверить, нельзя ли отделить проблемную часть от той, которая по-прежнему выполняет свою задачу.

---

В истории Ozon масштабирование не сводилось к добавлению дисков. Ceph помог распределять данные и нагрузку, но вместе с этим распределял между пользователями и последствия проблем отдельных бакетов. При интенсивном листинге и удалении бакеты примерно с 20 миллионами объектов уже становились тяжёлыми для их системы. Это наблюдение о конкретной инфраструктуре и нагрузке, а не универсальный предел размера бакета.

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

Выходом стал собственный S3-сервер Lusca: индекс вынесли в ScyllaDB, а Ceph оставили для хранения данных. Теперь команда могла отдельно управлять масштабированием индекса и развивать нужные возможности протокола, не ожидая изменений в штатной реализации.

Переделка повлияла и на стоимость хранения. Вместо четырёх реплик данных в прежней схеме стало возможно размещать по одной в трёх дата-центрах, сохраняя возможность пережить отключение одного из них. Добавилась дедупликация: для одного из бакетов докладчик приводит пример примерно 30% повторяющихся данных.

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