サービスの裏側
新しいサービスを学ぶとき
裏側のイメージを持てると、その理解もしやすくなるのではないでしょうか。
Dr. Wernerのブログ
今回のS3Filesの開発者による秘話がDr.ワーナーのブログに登場していました。
Linkedinでも結構バズっていました。
その内容を引用しながらS3filesの性質を見ていきたいと思います。
そもそもオブジェクトとファイルシステムって何がちがう？
ファイルへのアクセス方法が違います。
オブジェクト... apiコールなどでアクセスする。S3の場合だと、s3 get など。
ファイルシステム...EC2などにマウントして使う。ファイル書き込みによってファイルに追記したりするのも容易です。
他にも色々違う。
記事の中での説明では次のような箇所がありました。
We realized that it’s not necessary to converge file and object semantics to solve the data silo problem. What they needed was the same data in one place, with the right view for each access pattern. A file view that provides full NFS close-to-open consistency. An object view that provides full S3 atomic-PUT strong consistency. And a synchronization layer that keeps them connected.
geminiによる翻訳
私たちは、データサイロの問題を解決するために、ファイルセマンティクスとオブジェクトセマンティクスを無理に統合（コンバージ）させる必要はないということに気づきました。
本当に求められていたのは、「同じデータが一箇所にあり、かつそれぞれのアクセスパターンに対して最適なビューが提供されること」でした。
ファイルビュー： 完全なNFSの「close-to-open」一貫性を提供。
オブジェクトビュー： 完全なS3の「Atomic-PUT」による強い一貫性を提供。
同期レイヤー： これら2つのビューを常に連携させる。
ファイルとオブジェクトの明確な境界が設計上の最良の部分となった。
What I find most exciting about S3 Files is something I genuinely did not expect when we started: that the explicit boundary between file and object turned out to be the best part of the design. We spent months trying to make it disappear, and when we finally accepted it as a first-class element of the system, everything got better. Stage and commit gives us a surface that we can continue to evolve – more control over when and how data transits the boundary, richer integration with pipelines and workflows–and it sets us up to do that without compromising either side.
geminiによる翻訳
S3 Filesで私が最も興奮しているのは、開発開始当初は全く予想していなかったことです。それは、ファイルとオブジェクトの明確な境界が、設計上の最良の部分となったことです。私たちは何ヶ月もかけてその境界をなくそうと試みましたが、最終的にそれをシステムの第一級要素として受け入れた途端、すべてが好転しました。ステージングとコミットによって、私たちは継続的に進化できる基盤を得ることができました。つまり、データが境界を通過するタイミングと方法をより細かく制御でき、パイプラインやワークフローとの統合もより豊かになり、しかもどちらの側面も妥協することなく、それを実現できるようになったのです。
一連のS3の拡張の流れの1つである。
S3 tables
S3 vector
といった、S3の拡張の流れがあるようです。
So just like with the team’s work on structured data with S3 Tables, at the last re:Invent we launched S3 Vectors as a new S3-native data type for vector indices. S3 Vectors takes a very S3 spin on storing vectors in that its design anchors on a performance, cost and durability profile that is very similar to S3 objects. Probably most importantly though, S3 Vectors is designed to be fully elastic, meaning that you can quickly create an index with only a few hundred records in it, and scale over time to billions of records. S3 Vector’s biggest strength is really with the sheer simplicity of having an always-available API endpoint that can support similarity search indices. Just like objects and tables, it’s another data primitive that you can just reach for as part of application development.
geminiによる翻訳
S3 Tablesによる構造化データの取り組みと同様に、昨年のre:Inventにおいて、私たちはベクトルインデックスのための新しいS3ネイティブなデータタイプとしてS3 Vectorsをリリースしました。
S3 Vectorsは、S3オブジェクトと極めて近いパフォーマンス、コスト、耐久性のプロファイルに重点を置いた設計となっており、まさに「S3らしい」アプローチでベクトルを保存します。
おそらく最も重要な点は、S3 Vectorsが**完全な弾力性（フルエラスティック）**を備えていることです。これにより、わずか数百件のレコードからインデックスを素早く作成し、時間の経過とともに数十億件規模のレコードまでスケールさせることが可能です。
S3 Vectorsの最大の強みは、類似性検索インデックスをサポートする、常に利用可能なAPIエンドポイントという圧倒的なシンプルさにあります。オブジェクトやテーブルと同じように、アプリケーション開発の過程でいつでも手軽に利用できる新たな「データ・プリミティブ（データ基本要素）」です。
シンプルなことは難しい。
With S3 Files, you get a really simple thing. You can now mount any S3 bucket or prefix inside your EC2 VM, container, or Lambda function and access that data through your file system. If you make changes, your changes will be propagated back to S3. As a result, you can work with your objects as files, and your files as objects.
And this is where the story gets interesting, because as we often learn when we try to make things simple for customers, making something simple is often one of the more complicated things that you can set out to do.
S3 Filesを使えば、極めてシンプルなことが実現できます。S3のバケットやプレフィックス（フォルダパス）を、EC2 VMやコンテナ、Lambda関数の中にマウントし、ファイルシステム経由でそのデータにアクセスできるようになります。変更を加えれば、その変更はS3へと反映されます。その結果、オブジェクトをファイルとして、ファイルをオブジェクトとして扱うことができるようになるのです。
そして、ここからが面白いところです。お客様のために物事をシンプルにしようとすると、往々にして「シンプルにすること」こそが、取り組むべき最も複雑な課題の一つであると気づかされるからです。
「中間層」
この中間層の部分が実際にs3filesを使った時にどう影響が出るのだろうか？
The first decision was that we were going to treat first-class file access on S3 as a presentation layer for working with data. We would allow customers to define an S3 mount on a bucket or prefix, and that under the covers, that mount would attach an EFS namespace to mirror the metadata from S3. We would make the transit and consistency of data across the two layers an absolutely central part of our design. We started to describe this as “stage and commit,” a term that we borrowed from version control systems like git—changes would be able to accumulate in EFS, and then be pushed down collectively to S3—and that the specifics of how and when data transited the boundary would be published as part of the system, clear to customers, and something that we could actually continue to evolve and improve as a programmatic primitive over time. (I’m going to talk about this point a little more at the end, because there’s much more the team is excited to do on this surface).
geminiによる翻訳
最初の意思決定は、S3 における第一級のファイルアクセスを、データを扱うためのプレゼンテーション層として捉える、というものでした。顧客はバケットやプレフィックスに対して S3 のマウントを定義でき、その裏側では、そのマウントに EFS の名前空間を接続し、S3 のメタデータを反映させるようにします。さらに、この 2 つのレイヤー間でデータがどのように移動し、一貫性がどう保たれるかを、設計のまさに中心に据えることにしました。
私たちはこれを「stage and commit」と呼ぶようになりました。これは git のようなバージョン管理システムから借りた言葉です。変更はまず EFS 側に蓄積でき、その後まとめて S3 に反映できるようにする、という考え方です。そして、データがいつ・どのようにこの境界をまたいで移動するのか、その具体的な仕組みをシステムの一部として公開し、顧客にとって明確なものにしたいと考えました。さらにそれを、時間をかけて進化・改善していけるプログラム上の基本的な仕組みとして扱えるようにしようとしました。（この点については最後にもう少し詳しく触れます。というのも、この領域でチームがさらに実現したいことがたくさんあるからです。）
Consistency and atomicity
S3 readers often assume full object updates, notifications, and in many cases access to historical versions. File systems have fine-grained mutations, but they have important consistency and atomicity tricks as well. Many applications depend on the ability to do atomic file renames as a way of making a large change visible all at once. They do the same thing with directory moves. S3 conditionals help a bit with the first thing but aren’t an exact match, and there isn’t an S3 analog for the second. So as mentioned above, separating the layers allows these modalities to coexist in parallel systems with a single view of the same data. You can mutate and rename a file all you want, and at a later point, it will be written as a whole to S3.
geminiによる翻訳
S3の利用者は、オブジェクトが完全に更新されること、通知が行われること、そして多くの場合、過去のバージョンにアクセスできることを前提としています。一方で、ファイルシステムはきめ細かなデータ変更（ミューテーション）を行いますが、重要な一貫性と原子性（アトミック性）に関するテクニックも備えています。
多くのアプリケーションは、大規模な変更を一括で反映させる手段として、**「アトミックなファイル名の変更（rename）」**ができることに依存しています。ディレクトリの移動についても同様の手法が使われます。S3の条件付きリクエスト（conditionals）は前者のケースを多少補完しますが、完全に一致するものではありません。また、後者の「ディレクトリ移動」に相当する機能はS3には存在しません。
したがって、前述の通り、レイヤーを分離することによって、これらの異なる方式を並行するシステム内で共存させ、同じデータに対して単一のビューを提供することが可能になります。ファイルに対して何度でも変更や名前の変更を行うことができ、最終的な状態がひとつのまとまりとしてS3に書き込まれる、という仕組みです。
まとめ
確かに、体験として似たように見えるs3のファイルとEFSのファイルだが、バケットポリシーとEFSのアクセスポリシーとか全然違う、それらをstage commmit という層を作って、見通しをよくしたのだと理解できた。
冒頭の、実体験の話から始まり、楽しく読めた。
再度リンクを掲載しておきます。
以上