S3 REST API を実装する際の推奨事項
変更を提案
PDF
StorageGRID で使用するために S3 REST API を実装する場合は、次の推奨事項を考慮してください。
存在しないオブジェクトに対する HEAD の推奨事項
オブジェクトが実際に存在するとは思わないパスにオブジェクトが存在するかどうかをアプリケーションが定期的にチェックする場合は、「使用可能」整合性制御を使用する必要があります。たとえば ' アプリケーションがその場所に配置する前にその場所に注意する場合は ' 利用可能な整合性制御を使用する必要があります
そうしないと、使用できないストレージノードがある場合に HEAD 処理でオブジェクトが見つからないと、「 500 Internal Server Error 」が大量に返される可能性があります。
PUT Bucket consistency 要求を使用して各バケットに「 available 」整合性制御を設定するか、または個々の 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クライアントアプリケーションで返されるバイト数の範囲を指定するGET Object処理を実行しないようにする必要があります。StorageGRID は要求されたバイトにアクセスするためにオブジェクトを圧縮解除する必要があるため ' これらの “range read” 操作は非効率的です非常に大きなオブジェクトから小さい範囲のバイト数を要求する GET Object 処理は特に効率が悪く、たとえば、 50GB の圧縮オブジェクトから 10MB の範囲を読み取る処理は非効率的です。
圧縮オブジェクトから範囲を読み取ると、クライアント要求がタイムアウトする可能性があります。
|
オブジェクトを圧縮する必要があり、クライアントアプリケーションが範囲読み取りを使用する必要がある場合は、アプリケーションの読み取りタイムアウトを増やしてください。 |