【要約】s3fsで痛い目を見たので S3 Filesを調べ倒した [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がs3fsなどのFUSE系ツールを用いてS3をマウントする際、オブジェクトストレージの構造的限界により、ファイルシステムとしての整合性を維持できない問題に直面する。筆者は過去に、s3fsでファイルロック（flock）が動作せず、バッチ処理の二重起動によるデータ破損を経験している。
- ・S3はオブジェクトストレージであり、ファイルシステム的なロック概念が存在しない。
- ・FUSE系ツールはS3 APIを直接変換するため、ロックやアトミックなrenameが実現できない。
- ・これにより、SQLiteやWordPress、Gitなど、POSIX機能を前提とするソフトウェアが正常に動作しない。
// Approach
Amazon S3 Filesは、S3を永続層としつつ、EFS技術を基盤としたHPSを介在させることで、POSIX互換性を実現するアプローチをとる。HPSがファイルシステム操作を完結させることで、アプリからは通常のファイルシステムとして振る舞う。
- ・EFS技術を用いたHPSにより、NFSプロトコル経由でファイルロックやパーミッションを提供。
- ・1 MiB以上の読み取りはS3から直接ストリーミングし、小ファイルはHPSで低レイテンシを実現。
- ・アクセス頻度の低いデータは、設定期間（デフォルト30日）後に自動的にS3へ退避する階層化構造を採用。
// Result
S3 Filesの導入により、開発者は既存のアプリケーションコードを一切変更することなく、S3の耐久性を備えたPOSIX環境を利用できる。これにより、ファイルロックやアトミックな操作によるデータ整合性の確保が可能となる。
- ・flockやrenameによる排他制御・整合性が保証され、データ破損リスクを低減。
- ・「ホットデータはHPS、コールドデータはS3」という自動階層化により、コストと性能を両立。
- ・Lambdaからのマウントも可能になり、サーバーレス環境でのファイル操作の選択肢が拡大。
Senior Engineer Insight
> S3 Filesは「S3の制約」と「POSIXの要件」の妥協点を見事に突いた設計だ。FUSE系のような「通訳」ではなく、HPSという「実体」を置くことで、アプリケーションの信頼性を担保している。ただし、S3との同期遅延（最大60秒）や、小ファイル大量処理時のコスト増といった、分散システム特有のトレードオフは存在する。設計者は、S3 APIとNFSの併用における整合性モデルを正しく理解すべきだ。