StorageGRID로 S3 REST API 구현 권장 사항
변경 제안
PDF
StorageGRID와 함께 사용하기 위해 S3 REST API를 구현할 때 다음 권장 사항을 따라야 합니다.
존재하지 않는 객체에 대한 HEAD 권장 사항
애플리케이션에서 객체가 실제로 존재하지 않을 것으로 예상되는 경로에 객체가 있는지 정기적으로 확인하는 경우 "Available" "일관성"을 사용해야 합니다. 예를 들어, 애플리케이션에서 PUT 작업을 수행하기 전에 해당 위치에 HEAD 요청을 보내는 경우 "Available" 일관성을 사용해야 합니다.
그렇지 않으면 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 범위를 읽는 것은 비효율적입니다.
압축된 객체에서 범위를 읽어오는 경우 클라이언트 요청 시간이 초과될 수 있습니다.
|
객체를 압축해야 하고 클라이언트 애플리케이션에서 범위 읽기를 사용해야 하는 경우 애플리케이션의 읽기 시간 제한을 늘리십시오. |