S3 Files のベストプラクティス

ワークロードを並列化する – S3 Files は、高度な並列ワークロードをサポートするように設計されています。複数のファイルと複数のコンピューティングインスタンスに読み取りを分散することで、集約スループットを最大化できます。また、(バケット全体に 1 つのファイルシステムを作成するのではなく) 同じバケット内に、異なる特定のプレフィックスを対象とする複数のファイルシステムを作成して、水平方向にスケールし、集計スループットを向上させることもできます。

名前変更の影響を最小限に抑えるためにワークロードが必要とする最小限のプレフィックスにファイルシステムをスコープする – S3 にはディレクトリというネイティブな概念がありません。ディレクトリの名前を変更したり移動したりすると、S3 Files はそのディレクトリ内のすべてのファイルについて、更新されたキーを持つ新しいオブジェクトにデータを書き込み、元のオブジェクトを削除する必要があります。数千万個のファイルを含むディレクトリの名前を変更すると、S3 のリクエストコストと同期時間が大幅に増加する可能性があります。ファイルシステムをアクティブなデータセットに限定するか、名前変更を予定しているディレクトリに含まれるファイル数を減らすようにデータを構造化します。詳細については、「名前変更および移動オペレーションの影響を理解する」を参照してください。

大きな IO サイズを使用する – S3 Files は、各読み取りおよび書き込みオペレーションを最低 32 KB で計測します。より大きな IO サイズ (1 MB 以上) を使用すると、オペレーションごとのオーバーヘッドが償却され、小さな読み取りまたは書き込みを多数行うよりもコスト効率が向上します。マウントヘルパーを使用する場合、最適なパフォーマンスを得るために、デフォルトの NFS 読み取りおよび書き込みバッファサイズは 1 MB に設定されます。

インポート設定の sizeLessThan 値をファイルサイズに合わせて調整する – デフォルトでは、S3 Files はディレクトリに初めてアクセスするときに 128 KB 未満のファイルのデータをキャッシュします。このしきい値より大きいファイルは S3 から直接読み取られます。ワークロードで、大きなファイルに対してレイテンシーの影響を受けやすい小さな読み取りを実行する場合は、ファイルシステムの高性能ストレージで必要なファイルサイズに合わせて、sizeLessThan しきい値を増やして、低レイテンシーアクセスを実現します。詳細については、「S3 Files の同期のカスタマイズ」を参照してください。

ワークロードのライフサイクルに合わせて有効期限ウィンドウを設定する – 有効期限ウィンドウ内に読み取られなかったデータは、ファイルシステムから自動的に削除されます。バッチジョブやトレーニング実行などの有効期間の短いワークロードでは、ストレージコストを最小限に抑えるために有効期限を短くします (1～7 日)。数週間にわたって同じデータに繰り返しアクセスするワークロードでは、低レイテンシーのメリットを引き続き享受するために、有効期限を長めに設定します (30～90 日)。詳細については、「S3 Files の同期のカスタマイズ」を参照してください。

混合ワークロードにプレフィックススコープのルールを使用する – 頻繁にアクセスされるデータとアクセス頻度の低いデータの両方がバケットに含まれている場合は、プレフィックスごとに個別のインポートルールを作成します。これにより、ホットプレフィックスについては積極的にデータをインポートしながら、コールドプレフィックスについてはメタデータのみを保持することができます。詳細については、「S3 Files の同期のカスタマイズ」を参照してください。

各アベイラビリティーゾーンにマウントターゲットを作成する – クロス AZ データ転送コストを削減し、パフォーマンスを向上させるために、運用する各アベイラビリティーゾーンに 1 つのマウントターゲットを作成することをお勧めします。これにより、コンピューティングリソースが常にファイルシステムへのローカルネットワークパスを確保できるため、可用性とレイテンシーの両方が向上します。AWS マネジメントコンソールを使用してファイルシステムを作成すると、S3 Files は選択した VPC 内の各アベイラビリティーゾーンに 1 つのマウントターゲットを自動的に作成します。

S3 Files の整合性モデルを理解する – ファイルシステム内のファイルが S3 バケット内の対応するオブジェクトと同時に変更されると、S3 Files は S3 バケットを信頼できるソースとして扱い、ファイルを lost and found ディレクトリに移動します。競合を回避するには、1 つのパス (ファイルシステムまたは S3) をプライマリライターとして指定します。

同期状態のモニタリング – CloudWatch メトリクスを使用して、ファイルシステムと S3 バケット間の同期ステータスを追跡します。PendingExports の増加は、ワークロードが同期レートよりも速く変更を生成していることを示しており、同期が完了するまでに時間がかかることを意味します。CloudWatch の ExportFailures メトリクスがゼロ以外の場合、エクスポートできなかったファイルがあり、アクションが必要であることを示します。詳細については、「S3 Files のトラブルシューティング」を参照してください。

最小特権の原則に従う – 各 IAM ロールとファイルシステムポリシーに必要な最小限のアクセス許可のみを付与します。例えば、コンピューティングリソースがファイルシステムからデータを読み取るだけで済む場合は、AmazonS3FilesClientFullAccess ではなく AmazonS3FilesClientReadOnlyAccess マネージドポリシーをアタッチします。さらに、クライアントがそのプレフィックス内のデータにのみアクセスできるように、バケット全体ではなく特定のプレフィックスに限定されたファイルシステムを作成することを検討してください。

S3 Files IAM ロールを変更しない – S3 バケットと同期するために S3 Files が引き受ける IAM ロールを変更または削除しないでください。このロールを変更または削除すると、ファイルシステムと S3 バケット間の同期が壊れる可能性があります。

S3 Files EventBridge ルールを変更しないでください – S3 Files は、S3 バケットの変更を検出するための EventBridge ルール (DO-NOT-DELETE-S3-Files というプレフィックス付き) を作成します。このルールを無効化、変更、または削除しないでください。これを削除すると、S3 Files がバケット内の新規または変更されたオブジェクトを検出できなくなり、ファイルシステムが古くなります。

efs-utils によって書き込まれたログへのアクセスを制限することを検討してください – efs-utils は、S3 オブジェクトキー名を /var/log/amazon/efs ディレクトリに保存されているログに直接書き込みます。S3 キー名に機密情報が含まれている場合は、POSIX アクセス許可を使用してこのディレクトリへのアクセスを制限する必要があります。例えば、sudo chmod 700 /var/log/amazon/efs コマンド を使用してアクセスを制限できます。

同期失敗時にアラームを設定する – ファイルの同期に失敗した場合に通知を受け取るために、ImportFailures と ExportFailures に関する CloudWatch アラームを作成します。エクスポートに失敗した場合は、アクセス許可の問題、暗号化キーの問題、またはパスの長さの制限を示している可能性があります。詳細については、「S3 Files のトラブルシューティング」を参照してください。