S3 REST API 実装に関する推奨事項
変更を提案
PDF
StorageGRIDで使用するために S3 REST API を実装する場合は、次の推奨事項に従う必要があります。
存在しないオブジェクトへのHEADの推奨事項
アプリケーションが、実際には存在しないと思われるパスにオブジェクトが存在するかどうかを定期的に確認する場合は、「使用可能」を使用する必要があります。"一貫性" 。たとえば、アプリケーションが PUT を実行する前に場所を HEAD する場合は、「Available」一貫性を使用する必要があります。
そうでない場合、HEAD 操作でオブジェクトが見つからないと、同じサイトにある 2 つ以上のストレージ ノードが使用できないか、リモート サイトにアクセスできないときに、多数の 500 内部サーバー エラーが発生する可能性があります。
各バケットの「利用可能」一貫性を設定するには、"PUT バケットの一貫性"リクエストごとに一貫性を指定したり、個々の API 操作のリクエスト ヘッダーで一貫性を指定したりすることもできます。
オブジェクトキーに関する推奨事項
バケットが最初に作成された時期に基づいて、オブジェクト キー名に関する次の推奨事項に従ってください。
-
オブジェクト キーの最初の 4 文字としてランダムな値を使用しないでください。これは、キープレフィックスに関する以前の AWS 推奨事項とは対照的です。代わりに、ランダムではない、ユニークではない接頭辞を使用してください。
image。 -
キープレフィックスにランダムで一意の文字を使用するという以前の AWS 推奨事項に従う場合は、オブジェクトキーの前にディレクトリ名を付けます。つまり、次の形式を使用します。
mybucket/mydir/f8e3-image3132.jpgこの形式の代わりに:
mybucket/f8e3-image3132.jpg
パフォーマンスのベスト プラクティスを満たすためにオブジェクト キー名を制限する必要はありません。ほとんどの場合、オブジェクト キー名の最初の 4 文字にはランダムな値を使用できます。
|
例外は、短時間ですべてのオブジェクトを継続的に削除する S3 ワークロードです。このユースケースでのパフォーマンスへの影響を最小限に抑えるには、数千個のオブジェクトごとにキー名の先頭部分を日付などに変更します。たとえば、S3 クライアントが通常 1 秒あたり 2,000 個のオブジェクトを書き込み、ILM またはバケット ライフサイクル ポリシーによって 3 日後にすべてのオブジェクトが削除されるとします。パフォーマンスへの影響を最小限に抑えるには、次のようなパターンを使用してキーに名前を付けます。 /mybucket/mydir/yyyymmddhhmmss-random_UUID.jpg
|
「レンジリード」の推奨事項
もし"保存されたオブジェクトを圧縮するグローバルオプション"が有効になっている場合、S3 クライアント アプリケーションは、返されるバイトの範囲を指定する GetObject 操作の実行を避ける必要があります。これらの「範囲読み取り」操作は、 StorageGRID が要求されたバイトにアクセスするためにオブジェクトを効果的に解凍する必要があるため、非効率的です。非常に大きなオブジェクトから小さな範囲のバイトを要求する GetObject 操作は特に非効率的です。たとえば、50 GB の圧縮されたオブジェクトから 10 MB の範囲を読み取るのは非効率的です。
範囲が圧縮されたオブジェクトから読み取られる場合、クライアント要求がタイムアウトする可能性があります。
|
オブジェクトを圧縮する必要があり、クライアント アプリケーションで範囲読み取りを使用する必要がある場合は、アプリケーションの読み取りタイムアウトを増やします。 |