S3 REST API 구현을 위한 권장 사항
변경 제안
PDF
StorageGRID 와 함께 사용할 S3 REST API를 구현할 때 다음 권장 사항을 따라야 합니다.
존재하지 않는 객체에 대한 HEAD 권장 사항
응용 프로그램이 실제로 존재하지 않을 것으로 예상되는 경로에 객체가 있는지 정기적으로 확인하는 경우 "사용 가능"을 사용해야 합니다."일관성" . 예를 들어, 애플리케이션이 PUT하기 전에 위치를 HEAD하는 경우 "사용 가능" 일관성을 사용해야 합니다.
그렇지 않은 경우 HEAD 작업에서 객체를 찾지 못하면 동일한 사이트에서 두 개 이상의 스토리지 노드를 사용할 수 없거나 원격 사이트에 접근할 수 없는 경우 500 내부 서버 오류가 많이 발생할 수 있습니다.
다음을 사용하여 각 버킷의 "사용 가능" 일관성을 설정할 수 있습니다."PUT 버킷 일관성" 요청하거나 개별 API 작업에 대한 요청 헤더에서 일관성을 지정할 수 있습니다.
객체 키에 대한 권장 사항
버킷이 처음 생성된 시점을 기준으로 개체 키 이름에 대한 다음 권장 사항을 따르세요.
-
객체 키의 처음 네 글자로 임의의 값을 사용하지 마세요. 이는 키 접두사에 대한 이전 AWS 권장 사항과 대조됩니다. 대신, 다음과 같은 무작위적이지 않고 고유하지 않은 접두사를 사용하세요.
image. -
키 접두사에 임의의 고유한 문자를 사용하라는 이전 AWS 권장 사항을 따르는 경우 개체 키에 디렉토리 이름을 접두사로 붙입니다. 즉, 다음 형식을 사용하세요.
mybucket/mydir/f8e3-image3132.jpg이 형식 대신:
mybucket/f8e3-image3132.jpg
성능 모범 사례를 충족하기 위해 객체 키 이름을 제한할 필요는 없습니다. 대부분의 경우 객체 키 이름의 처음 네 글자에 임의의 값을 사용할 수 있습니다.
|
이에 대한 예외는 짧은 시간 후에 모든 객체를 지속적으로 제거하는 S3 워크로드입니다. 이 사용 사례에서 성능 영향을 최소화하려면 수천 개의 객체마다 키 이름의 앞부분을 날짜 등으로 변경합니다. 예를 들어, S3 클라이언트가 일반적으로 초당 2,000개의 객체를 쓰고 ILM 또는 버킷 수명 주기 정책이 3일 후에 모든 객체를 제거한다고 가정해 보겠습니다. 성능에 미치는 영향을 최소화하려면 다음과 같은 패턴을 사용하여 키 이름을 지정할 수 있습니다. /mybucket/mydir/yyyymmddhhmmss-random_UUID.jpg
|
"범위 읽기"에 대한 권장 사항
만약"저장된 객체를 압축하는 글로벌 옵션" 이 활성화된 경우 S3 클라이언트 애플리케이션은 반환할 바이트 범위를 지정하는 GetObject 작업을 수행하지 않아야 합니다. 이러한 "범위 읽기" 작업은 StorageGRID 요청된 바이트에 액세스하기 위해 객체를 효과적으로 압축 해제해야 하기 때문에 비효율적입니다. 매우 큰 객체에서 작은 범위의 바이트를 요청하는 GetObject 작업은 특히 비효율적입니다. 예를 들어, 50GB 압축 객체에서 10MB 범위를 읽는 것은 비효율적입니다.
압축된 객체에서 범위를 읽는 경우 클라이언트 요청이 시간 초과될 수 있습니다.
|
객체를 압축해야 하고 클라이언트 애플리케이션에서 범위 읽기를 사용해야 하는 경우 애플리케이션의 읽기 시간 제한을 늘리세요. |