# 同期の仕組みを理解する
S3 Files は、ファイルシステムとリンクされた S3 バケットを自動的に同期させます。アクティブに使用されるデータはファイルシステムにコピーされるため、標準の Linux ファイルオペレーションを使用して、低レイテンシーでファイルの読み取りおよび書き込みができます。S3 Files では、リンクされた S3 バケットで S3 バージョニングを有効にする必要があります。ファイルシステム上のファイルを編集すると、S3 Files は変更を対応するオブジェクトの新しいバージョンとして S3 バケットにコピーし、古いバージョンが確実に保持されるようにします。他のアプリケーションが S3 バケット内のオブジェクトを追加、変更、または削除すると、S3 Files はそれらの変更をファイルシステムに自動的に反映します。ファイルシステムと S3 バケットの両方で同じデータへの同時変更が原因で競合が発生した場合、S3 Files は [S3 バケットを競合が発生したときの信頼できるソース](#s3-files-sync-source-of-truth)として扱います。
ストレージコストを最適化するために、S3 Files はファイルシステムから最近使用されていないデータを削除します。データはリンクされた S3 バケットに永続的に保存され、次回アクセスしたときにファイルシステムにフェッチされます。
## S3 バケットにはファイルシステム経由でアクセス可能
S3 ファイルシステムを作成したら、[S3 バケットをコンピューティングリソースにマウント](s3-files-attach-compute.md)し、S3 バケットのデータへのアクセスをすぐに開始できます。デフォルトでは、内容を一覧表示するか、ディレクトリ内のファイルを開くことでディレクトリに初めてアクセスすると、S3 Files は、そのディレクトリ内のすべてのファイルのメタデータと、インポートサイズのしきい値 (デフォルトは 128 KiB) より小さいファイルのデータを S3 バケットからインポートします。ディレクトリへの最初のアクセスのレイテンシーは高くなる可能性がありますが、それ以降の読み取りと書き込みは大幅に速くなります。S3 Files は、メタデータを事前にインポートすることで、低レイテンシーでディレクトリの内容を参照したり、ファイルサイズを表示したり、アクセス許可を確認したりできるようになります。
例えば、S3 バケットに `data/images/` というプレフィックスがあり、1,000 個のオブジェクトが含まれているとします。初めて `ls /mnt/s3files/data/images/` を実行すると、S3 Files は 1,000 個のファイルすべてのメタデータをインポートし、インポートサイズのしきい値を下回るファイルのデータをファイルシステムに非同期的にコピーします。この最初の一覧表示には数秒かかることがありますが、その後は、そのディレクトリ内の個々のファイルに対する `ls -la`、`stat`、`cat` などのコマンドは低レイテンシーで応答します。
インポートサイズのしきい値を超えるファイルの場合、S3 Files はメタデータのみをインポートし、データはファイルシステムにコピーされず、アクセス時に S3 バケットから直接読み取られます。このしきい値は、ワークロードに合わせて調整できます。例えば、同じファイルに繰り返しアクセスし、低レイテンシーの読み取りの恩恵を受けるワークロードの場合、この値を増やしてより多くのデータを事前にインポートすることができます。データを順番にストリーミングするワークロードの場合、しきい値を低くするほうがコスト効率が良くなることがあります。これは、データを事前にインポートすることによるレイテンシーのメリットが、小さなランダム読み取りではなく、大きなチャンクで順番に読み取る場合、あまり意味をなさないためです。詳細については、「[S3 Files の同期のカスタマイズ](s3-files-synchronization-customizing.md)」を参照してください。
## ファイルシステムの変更が S3 バケットに自動的に反映される
ファイルシステム内でファイルを作成、変更、または削除すると、S3 Files はそれらの変更を S3 バケットに自動的にコピーします。新しいファイルは新しい S3 オブジェクトになり、既存のファイルへの変更は新しいオブジェクトバージョンになり、削除されたファイルは S3 削除マーカーになります。
所有者 (UID)、グループ (GID)、アクセス許可ビットなど、ファイルシステムを介してファイルとディレクトリに設定する POSIX アクセス許可は、対応する S3 オブジェクトにユーザー定義の S3 オブジェクトメタデータとして保存されます。`chmod`、`chown`、または `chgrp` を使用してアクセス許可を変更すると、S3 Files はそれらの変更をデータ変更とともに S3 バケットにエクスポートします。S3 Files が S3 バケットからオブジェクトをインポートすると、このメタデータを読み取り、対応する POSIX アクセス許可をファイルシステムに適用します。POSIX アクセス許可メタデータを持たないオブジェクトには、デフォルトのアクセス許可が割り当てられます。
ファイルシステム内のファイルを変更すると、S3 Files が最大 60 秒間待機し、その時間内のファイルへの連続する変更を集約してから、S3 バケットにコピーします。つまり、同じファイルへの高速な連続書き込みは、個々の変更ごとに新しいオブジェクトバージョンを生成するのではなく、単一の S3 PUT リクエストにキャプチャされるため、S3 リクエストのコストとストレージコストを削減できます。S3 Files が変更内容を S3 バケットにコピーした後もファイルを変更し続けると、後続の変更が必要に応じてコピーされます。
例えば、アプリケーションがログファイルを開き、30 秒間に 50 回追記した場合、S3 Files は 50 回すべてを 1 つの S3 PUT リクエストに追加します。アプリケーションが最初の同期後も書き込みを継続すると、S3 Files は追加の変更を後続の同期にコピーします。
## S3 バケットの変更がファイルシステムに自動的に表示される
S3 Files は、S3 イベント通知を使用して S3 バケットの変更をモニタリングします。S3 API を使用する別のアプリケーションが S3 バケット内のオブジェクトを追加、変更、または削除すると、S3 Files は、現在データがファイルシステムの高性能ストレージに保存されているファイルについて、これらの変更をファイルシステムに自動的に反映します。ファイルシステムからデータの有効期限が切れたファイルは、次回アクセスするまで更新されません。その時点で、S3 Files は S3 バケットから最新バージョンを取得します。
## 名前変更および移動オペレーションの影響を理解する
Amazon S3 は、オブジェクトがキー名で識別されるフラットストレージ構造を使用します。S3 Files ではデータをディレクトリに整理できますが、S3 にはディレクトリというネイティブな概念がありません。ファイルシステムにディレクトリとして表示されるのは、S3 バケット内のオブジェクトのキーによって共有される共通のプレフィックスです。さらに、S3 オブジェクトは変更不可能であり、アトミックな名前変更をサポートしていません。その結果、ファイルの名前を変更したり移動したりすると、S3 Files は更新されたキーを使用して新しいオブジェクトにデータを書き込み、元のオブジェクトを削除する必要があります。ディレクトリの名前を変更したり移動したりすると、S3 Files は、そのプレフィックスを共有するすべてのオブジェクトに対してこのプロセスを繰り返す必要があります。したがって、数千万のファイルを含むディレクトリの名前を変更または移動すると、S3 へのリクエストコストと同期時間が大幅に増加します。
S3 Files は、名前変更に最大 4 時間かかるような多数のオブジェクト (最大約 1,200 万個のオブジェクト) が含まれるプレフィックスをスコープとするファイルシステムを作成しようとすると、エラーを返します。このエラーは、大規模な再帰的な名前変更または移動オペレーションが、各ファイルに対して S3 バケットへの個別の書き込みと削除リクエストが必要となるため、ファイルシステムのパフォーマンスに影響を与える可能性があることを警告するものです。それでも、そのプレフィックスにスコープされたファイルシステムを作成する場合は、`--AcceptBucketWarning` パラメータを追加できます。
S3 Files は S3 バケットでオブジェクトの名前を個別に変更するため、名前の変更が完全に完了するまで、両方のディレクトリが S3 バケットに表示されます。ディレクトリの名前変更後、かつ変更が完全に同期される前に書き込まれたオブジェクトは移動されません。データの再編成作業を簡素化するために、一致するディレクトリの名前を変更している間は、S3 バケットを介して新しいオブジェクトを作成しないことをお勧めします。
例えば、`mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta` を実行すると、名前変更はファイルシステムですぐに完了します。S3 バケットでは、S3 Files は各オブジェクトのコピーと削除を S3 バケット内の新しいキーに開始し (`projects/alpha/` プレフィックスを `projects/beta/` に置き換えます)、元のオブジェクトを削除します。このプロセス中、S3 バケットには一時的に `projects/alpha/` と `projects/beta/` の両方の下にあるオブジェクトが含まれます。すべてのオブジェクトを移動すると、`projects/beta/` のみが残ります。
## ストレージを最適化するために、未使用のデータがファイルシステムから期限切れになる
S3 Files は、ファイルシステムから最近読み取られていないファイルデータを自動的に削除することで、ストレージコストを最適化します。お客様のデータは S3 バケットに安全に保存されています。S3 Files は、ファイルシステムからコピーを削除するだけです。名前、サイズ、アクセス許可などのファイルメタデータはファイルシステムから削除されないため、ファイルシステムを低レイテンシーで引き続き参照できます。
ファイルシステム内のファイルが 30 日間 (設定可能) 読み取られておらず、その変更が S3 バケットに既に同期されている場合、S3 Files はファイルシステムからファイルデータを削除します。次回そのファイルを読み取ると、S3 Files は対応するオブジェクトの最新バージョンを S3 バケットから取得し、ファイルシステムにコピーし直します。
例えば、1 月に `/mnt/s3files/data/batch-jan.parquet` にあるデータセットを処理し、再度アクセスしないとします。S3 Files は、30 日後にファイルシステムからファイルデータを削除します。ファイルは、ディレクトリのリストに正しいサイズとアクセス許可で引き続き表示されますが、データはファイルシステムに存在しなくなっています。4 月にファイルを再度読み取ると、S3 Files はそれを S3 バケットから取得し、ファイルシステムにコピーします。最初の読み取りはレイテンシーが高くなる可能性がありますが、それ以降の読み取りは高速です。
## S3 バケットは競合が発生した場合の信頼できるソースとなる
競合は、同じファイルがファイルシステムを介して変更され、S3 Files がファイルシステムの変更を S3 バケットに同期する前に、対応する S3 オブジェクトも変更された場合に発生します。例えば、マウントしたファイルシステムを介してファイルを編集している間に、別のアプリケーションが対応するオブジェクトの新しいバージョンをアップロードしたり、リンクされた S3 バケットで直接それを削除したりすることがあります。
S3 Files は、ファイルシステムの変更を S3 バケットに同期しようとしたとき、またはオブジェクトが変更されたことを示す S3 イベント通知を受信したときに競合を検出します。S3 バケットはデータの長期保存場所として機能するため、S3 Files は競合が発生した場合に S3 バケットを信頼できるソースとみなします。これにより、予測可能な整合性が得られ、S3 バケットのバージョンが常に優先されることが保証されます。競合が発生した場合、S3 Files は競合するファイルをファイルシステムの現在の場所から lost and found ディレクトリに移動し、リンクされた S3 バケットからファイルシステムに最新バージョンをインポートします。
例えば、ファイルシステムを使用して `/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}}` という名前で存在します。ルートディレクトリを指定するアクセスポイントを介してファイルシステムをマウントする場合、lost and found ディレクトリはアクセスポイントのルートディレクトリよりも上位にあるため、そのマウントからは表示されません。lost and found ディレクトリにアクセスするには、アクセスポイントを使用せずにファイルシステムをマウントするか、ルートディレクトリの制限がないアクセスポイントを使用して、アクセスポイント経由でファイルシステムのスコープ全体にアクセスできるようにします。
S3 Files がファイルを lost and found ディレクトリに移動すると、時間の経過とともに移動される可能性がある同じファイルの複数のバージョンを区別するために、ファイル名の前に識別子を付加します。lost and found ディレクトリ内のファイルは、S3 バケットにコピーされません。このディレクトリからファイルを削除したりファイルをコピーしたりすることはできますが、ファイルを移動したり名前を変更したり、ディレクトリ自体を削除したりすることはできません。S3 バケットの最新バージョンではなくファイルシステムの変更を保持する場合は、lost and found ディレクトリから元のパスにファイルをコピーします。ファイルの元のパスは、lost and found ディレクトリにあるファイルの拡張属性から取得できます。その後、S3 Files はオブジェクトの新しいバージョンとして S3 バケットにコピーします。詳細については、「[S3 Files のトラブルシューティング](s3-files-troubleshooting.md)」を参照してください。
**注記**
S3 Files が lost and found ディレクトリに移動した競合ファイルは無期限に残り、ファイルシステムのストレージコストにカウントされます。不要になったファイルは、lost and found ディレクトリから削除してストレージを解放する必要があります。
デフォルトの同期設定は、ほとんどのワークロードで機能し、S3 データへのファイルベースの低レイテンシーアクセスを実現します。これらのパラメータの設定方法の詳細については、「[S3 Files の同期のカスタマイズ](s3-files-synchronization-customizing.md)」を参照してください。
**Topics**
+ [S3 バケットにはファイルシステム経由でアクセス可能](#s3-files-sync-bucket-accessible)
+ [ファイルシステムの変更が S3 バケットに自動的に反映される](#s3-files-sync-changes-to-bucket)
+ [S3 バケットの変更がファイルシステムに自動的に表示される](#s3-files-sync-changes-from-bucket)
+ [名前変更および移動オペレーションの影響を理解する](#s3-files-sync-rename-move)
+ [ストレージを最適化するために、未使用のデータがファイルシステムから期限切れになる](#s3-files-sync-expiration)
+ [S3 バケットは競合が発生した場合の信頼できるソースとなる](#s3-files-sync-source-of-truth)
+ [S3 Files の同期のカスタマイズ](s3-files-synchronization-customizing.md)