【AWS新機能】S3をファイルシステムとしてマウントできる「S3 Files」がついに登場！

AWSから、S3バケットをファイルシステムとしてシームレスに利用可能にする新機能「S3 Files」が発表されました。これまでS3の操作にはAPIやCLIが必要でしたが、このアップデートにより、標準的なファイルシステムのようにS3を直接マウントして扱うことが可能になります。既存のアプリケーションを大幅に改修することなく、S3の圧倒的なスケーラビリティをファイルストレージとして活用できるのは、エンジニアにとって非常に大きなメリットです。詳細はこちらの公式ブログをチェックしてみてください。https://aws.amazon.com/blogs/aws/launching-s3-files-making-s3-buckets-accessible-as-file-systems/

100%確信があるわけじゃないけど、AWSはこれまでずっとS3をファイルシステムとして使うなと言い張ってた気がするんだよね。なんで今さら変えたんだろう？

これ要するに、アクティブなデータやランダムアクセスのためのキャッシュレイヤーとしてEFS（AWSのマネージドNFSサービス）を使ったS3FSだね。ただ残念ながら、EFSのあの目玉が飛び出るような料金体系も付いてくるってことだ。

— 書き込みは全部まずEFSキャッシュに行なわれるから、1GBあたり0.06ドルかかる。書き込みが多いアプリケーションだと、これは致命的かも。

— キャッシュにヒットした読み込みは1GBあたり0.03ドル。128kB以上の大きな読み込みは、背後のS3バケットから直接ストリーミングされるから無料だ。

— キャッシュの利用料は月額0.30ドル/GB。整合性のためにすべてがキャッシュに書き込まれるとはいえ、基本的には小さいファイル（128kB未満）の永続ストレージとしてしか使われないみたいだから、そこまでコストはかからないはず。

同期の仕組みがどうなってるのか気になってたんだ：https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html

例えば、ファイルシステム経由で /mnt/s3files/report.csv を編集したとする。S3 Filesがその変更をS3バケットに同期する前に、別のアプリケーションが新しいバージョンの report.csv を直接S3バケットにアップロードした場合。S3 Filesがこの競合を検知すると、手元の report.csv を lost and found ディレクトリに移動して、S3バケットにあるバージョンに置き換える。

lost and found ディレクトリは、ファイルシステムのルートディレクトリにある .s3files-lost+found-file-system-id という名前の場所にある。

ワーナー・ヴォゲルスは最高だよね。Dynamo DBについて学んだときに、彼の書いたものを初めて知ったんだ。

NFSのロッキングセマンティクスがおかしいと思ってたなら、そこにリモートのS3バックエンドが混ざったときにどうなるか、見てなよ！

これ、最初の公式リリースが近い https://fiberfs.io/ にすごく似てるね。
キャッシュ内蔵、CDN対応、JSONメタデータ、並行処理セーフで、あらゆるS3互換ストレージをターゲットにしてるやつ。

ローカルのNVMeストレージへのマネージドなブリッジを提供してくれたらいいのにな。AWSのNVMeはEBSに比べてめちゃくちゃ速いし、EBS（ブロックデバイスとしてのノード独占アクセス）はEFS（マルチノードアクセス）よりも速い。この上にさらにNVMe FSみたいなキャッシュを重ねれば速くなるんだろうけど、完全に垂直統合されたオプションがあるほうがずっといいよね。

「NFSはアプリケーションが期待するセマンティクスを提供する」って、今まで読んだ中で一番面白いジョークの一つだよ。

初歩的な質問：これでSQLiteのデータベースを保存したらどうなるかな？ 単に……動くのかな？
たぶんLitestreamがやってるみたいなバックアップじゃなくて、リードレプリカとしてしか使えない気がするけど、どうだろう？

Hugging Face Bucketsも最近、バケットをファイルシステムとしてマウントするサポートを追加したよね：https://huggingface.co/changelog/hf-mount