Who Let The Dogs Out 🐾

#S3 #aws #objectStore

AWS делают из S3 больше чем объектное хранилище, это теперь файловое хранилище. Но объектное. Но бакет теперь можно примаунтить как файловую систему. И там всякие UID/GID нарезать, как велено в POSIX. И всё это без s3fs и прочих суррогатов.

https://aws.amazon.com/blogs/aws/launching-s3-files-making-s3-buckets-accessible-as-file-systems/

AWS пытались объединить мир файлов и мир объектов что оказалось намного сложнее, чем можно было ожидать. Изначально команда надеялась буквально совместить EFS и S3 так, чтобы получить «лучшее из двух миров», но быстро выяснилось, что у файловой системы и объектного хранилища слишком разные базовые семантики. Файлы предполагают тонкие изменения внутри файла, быстрые переименования, богатые операции на уровне ОС, mmap, конкурентную работу и поведение, привычное для локальных или сетевых файловых систем. Объекты воплощают идею целостных immutable-единиц: объект обычно создаётся или перезаписывается целиком,

Launching S3 Files, making S3 buckets accessible as file systems | Amazon Web Services

Amazon S3 Files makes S3 buckets accessible as high-performance file systems on AWS compute resources, eliminating the tradeoff between object storage benefits and interactive file capabilities while enabling seamless data sharing with ~1ms latencies.

Amazon Web Services
Apr 13 at 2:09amWeb
Show threadWho Let The Dogs Out 🐾Apr 13

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

Поэтому в AWS решили не скрывать границу между файловым и объектным представлением данных, а сделать её явной частью дизайна. Так появилась модель stage and commit. Смысл в том, что файловый доступ рассматривается как слой представления поверх данных в S3. Пользователь монтирует bucket или prefix как файловую систему, а под капотом используется EFS, который отражает метаданные и даёт привычное файловое поведение. Изменения сначала накапливаются в файловом слое, а затем пакетно коммитятся обратно в S3. То есть это не магическое слияние двух несовместимых миров, а аккуратная синхронизация между ними с чётко обозначенной границей.

Show threadWho Let The Dogs Out 🐾Apr 13

Новый подход во-первых сохраняет правильные свойства обеих сторон. На файловой стороне остаются привычные операции и семантика NFS, а на стороне объектов — атомарные PUT, сильная консистентность и привычная модель S3.

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

Show threadWho Let The Dogs Out 🐾Apr 13

#aws #s3 #objectStore

Есть и компромиссы.
Один из них — консистентность и атомарность. Файловые системы позволяют, например, собрать изменения и сделать их видимыми через `atomic rename`, тогда как в S3 такой эквивалент отсутствует.
Другой — авторизация: IAM-политики S3 и права файловой системы устроены совершенно по-разному, и попытка одновременно наложить обе модели на каждый объект была бы слишком сложной.
В новом подходе права задаются на уровне mount и файлового слоя, а IAM остаётся защитным внешним контуром.

Ещё одна большая проблема — различия в пространстве имён: в S3 нет настоящих директорий, разделители путей условны, а некоторые объектные ключи вообще нельзя корректно представить как POSIX-имена.

Если имя нельзя безопасно перенести через границу, оно просто не переносится, а система сигнализирует об этом событием.

Show threadWho Let The Dogs Out 🐾Apr 13

#aws #s3 #objectStore

В практическом плане S3 Files работает так: bucket или его часть можно смонтировать в EC2, контейнере или Lambda как обычную файловую систему.

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

Это позволяет быстро начать работу даже с bucket, содержащим миллионы объектов. Изменения, сделанные через файловый интерфейс, агрегируются и примерно раз в 60 секунд коммитятся обратно в S3 единым PUT.
Синхронизация двусторонняя: если объект изменился напрямую в S3, файловое представление это тоже увидит.
При конфликте источником истины считается S3, а файловая версия уходит в `lost+found`.
Данные, к которым давно не обращались, вытесняются из файлового слоя, но не удаляются из самого S3.

Show threadWho Let The Dogs Out 🐾Apr 13

#aws #s3 #objectStore

Дизайн имеет ограничения: переименования дорогие, потому что в S3 нет нативного rename и приходится копировать и удалять объекты.
При очень больших mount’ах возникают отдельные издержки.
Не все ключи S3 можно показать как POSIX-файлы. Запусковая версия не даёт тонкого ручного контроля над моментом коммита. Но вместо того чтобы обещать невозможное, система явно показывает границу между двумя моделями и делает её управляемой.

Итого: проблема не в том, что у данных есть разные способы доступа, а в том, что раньше между этими способами приходилось строить неудобные мосты вручную.

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