데이터 IO및 암호화

오브젝트 크기는 IBM Cloud® Object Storage 성능에 상당한 영향을 줄 수 있습니다. 워크로드에 적합한 접근 방식을 선택하십시오.

다중 파트 전송

일반적인 조건에서 다중 파트 업로드 및 다운로드는 전송을 여러 병렬 트랜잭션으로 분할하는 매우 효율적인 방법입니다. 오브젝트 크기에 따라 100MB 의 파트 크기가 일반적으로 권장됩니다. 어떤 경우에도 COS로 들어오고 나가는 데이터를 최적화하기 위해 파트 크기를 4MiB 의 배수로 설정하는 것이 가장 효율적입니다.

AWS S3와 마찬가지로 다중 파트 전송을 사용하면 다음과 같은 이점이 있습니다.

  • 향상된 처리량-파트를 병렬로 업로드하여 처리량을 향상시킬 수 있습니다.
  • 네트워크 문제에서 빠른 복구-부품 크기가 작을수록 네트워크 오류로 인해 실패한 업로드를 다시 시작하는 영향이 최소화됩니다.
  • 오브젝트 업로드 일시정지 및 재개-시간 경과에 따라 오브젝트 파트를 업로드합니다. 다중 파트 업로드가 시작되면 다중 파트 업로드가 만료되지 않습니다. 명시적으로 완료하거나 다중 파트 업로드를 중단해야 합니다.
  • 최종 오브젝트 크기를 알기 전에 업로드를 시작하십시오. 오브젝트가 작성되는 대로 오브젝트를 업로드할 수 있습니다.

다중 파트 전송의 추가적인 복잡도로 인해 관리 다중 파트 전송에 대한 지원을 제공하는 적절한 S3 라이브러리, 도구 또는 SDK를 사용하는 것이 좋습니다.

다중 파트 다운로드를 위한 전용 API는 없지만, GET 요청에서 Range 헤더를 사용하여 오브젝트의 특정 파트만 읽을 수 있으며 파트를 업로드할 때와 마찬가지로 여러 범위의 읽기를 병렬로 실행할 수 있습니다. 모든 파트를 다운로드한 후에는 파트를 연결하고 전체 오브젝트의 무결성을 검사할 수 있습니다. 이전에 언급한 바와 같이, 이러한 전송을 수동으로 관리하는 복잡도를 방지하기 위해 SDK 또는 기타 도구를 사용하는 것이 좋습니다.

많은 수의 매우 작은 오브젝트를 저장해야 하는 워크플로우는 작은 파일을 더 큰 데이터 구조 (예: [Parquet]) 로 집계하여 더 나은 서비스를 제공할 수 있습니다.

크기가 200mb 보다 큰 오브젝트의 경우, 특히 안정적이지 않은 네트워크에서 또는 패킷 유실이 문제가 되는 매우 먼 거리에서는 Aspera High-Speed Transfer 이 우수한 성능을 제공할 수 있습니다.  Aspera 전송은 단일 요청 내에서 효율적으로 중첩된 디렉토리 구조를 업로드할 수도 있습니다.

일괄처리 삭제 조절

S3 API는 단일 일괄처리 삭제 요청으로 최대 1,000개의 오브젝트를 삭제하기 위한 메커니즘을 제공합니다. COS 시스템 내에서 성능 저하 가능성을 최소화하기 위해 이러한 요청을 클라이언트 측으로 조절하는 것이 좋습니다.  발행된 삭제 수가 시스템에 비해 너무 많은 경우 클라이언트는 "속도 저하" 를 표시하는 오류 메시지와 함께 HTTP 503오류를 수신합니다.

일관성 영향

IBM Cloud Object Storage System 은 오브젝트 쓰기, 겹쳐쓰기, 삭제, 다중 파트 조작 및 ACL 수정을 포함하여 모든 오브젝트 조작에 대한 즉각적인 일관성을 보장합니다. 버킷 작성도 즉시 일치합니다.  버킷 메타데이터 및 구성은 다른 오브젝트 스토리지 시스템의 경우와 마찬가지로 결과적으로 일관되며, 이는 고도로 분산된 시스템의 변경사항이 짧은 기간 동안 동기화되지 않을 수 있음을 의미합니다. 이는 상당한 성능 이점을 제공하고 서비스 거부 (DoS) 공격 가능성을 방지하는 메타데이터 캐싱 때문에 발생합니다.

일부 애플리케이션은 동일한 오브젝트를 겹쳐쓰거나 짧은 시간 동안 반복적으로 동일한 오브젝트를 삭제하고 다시 씁니다. 이로 인해 COS 시스템 내의 인덱스에서 경합이 발생할 수 있으므로 피해야 합니다.  매우 높은 빈도로 확장된 기간 동안 동일한 오브젝트 키 (이름) 로 데이터를 겹쳐쓰는 드문 경우에는 다른 스토리지 플랫폼 (파일, 블록, noSQL등) 을 선택하는 것이 더 좋습니다.

존재 확인

애플리케이션은 쓰기 전에 오브젝트가 존재하거나 수정되었는지 여부를 확인할 수 있습니다.  이로 인해 종종 HEAD 요청을 전송한 후 PUT 또는 GET 요청을 전송하는 비효율적인 애플리케이션 로직이 발생합니다.  이 안티 패턴으로 인해 네트워킹 및 서버 자원이 낭비되므로 사용하지 마십시오.

HEAD 요청을 일부 함수 내에서 존재 검사로 사용하는 대신 조건부 요청 헤더를 사용하십시오.  이러한 표준 HTTP 헤더는 MD5 해시 또는 시간소인을 비교하여 데이터 조작을 진행해야 하는지 여부를 판별합니다.  자세한 정보는 조건부 요청을 참조하십시오.

조건부 요청 사용

데이터 읽기 또는 쓰기를 요청할 때 불필요한 조작을 방지하기 위해 해당 요청에 대한 조건을 설정할 수 있습니다. 이는 If-Match, If-None-Match, If-Modified-Since 및 If-Unmodified-Since 와 같은 사전 조건부 HTTP 헤더를 사용하여 수행됩니다.

Last-Modified 값의 단위는 초 단위이며 일부 애플리케이션에서 경쟁 조건을 피하기에 충분하지 않을 수 있으므로 일반적으로 If-Match 를 사용하는 것이 좋습니다.

If-Match 사용

오브젝트 PUT, HEAD 또는 GET 요청에서 If-Match 헤더는 제공된 Etag (오브젝트 컨텐츠의MD5 해시) 가 제공된 Etag 값과 일치하는지 확인합니다. 이 값이 일치하면 조작이 진행됩니다. 일치에 실패하면 시스템은 412 Precondition Failed 오류를 리턴합니다.

If-Match를 상태 변경 메소드 (예: POST, PUT, DELETE) 와 함께 가장 자주 사용하여 여러 사용자 에이전트가 동일한 자원에서 병렬로 작동하는 경우 (즉, "업데이트 유실" 문제점을 방지하기 위해) 우발적인 겹쳐쓰기를 방지합니다.

If-None-Match 사용

오브젝트 PUT, HEAD 또는 GET 요청에서 If-None-Match 헤더는 제공된 Etag (오브젝트 컨텐츠의MD5 해시) 가 제공된 Etag 값과 일치하는지 확인합니다. 이 값이 일치하지 않으면 조작이 진행됩니다. 일치에 성공하면 시스템은 PUT 에서 412 Precondition Failed 오류를 리턴하고 GET 또는 HEAD 에서 304 Not Modified 를 리턴합니다.

If-None-Match는 최소한의 트랜잭션 오버헤드로 캐시된 정보를 효율적으로 업데이트할 수 있도록 조건부 GET 요청에서 주로 사용됩니다. 클라이언트가 엔티티-태그들을 갖는 하나 이상의 저장된 응답들을 업데이트하기를 원하는 경우, 클라이언트는 GET 요청을 할 때 이러한 엔티티-태그들의 리스트를 포함하는 If-None-Match 헤더 필드를 생성해야 한다.

If-Modified-Since 사용

오브젝트 HEAD 또는 GET 요청에서 If-Modified-Since 헤더는 오브젝트의 Last-Modified 값 (예: Sat, 14 March 2020 19:43:31 GMT) 이 제공된 값보다 최신인지 확인합니다. 오브젝트가 수정된 경우 조작이 진행됩니다. 오브젝트가 수정되지 않은 경우 시스템은 304 Not Modified 을 리턴합니다.

If-Modified-Since는 일반적으로 두 가지 다른 용도로 사용됩니다. Etag 가 없는 캐시된 표시의 효율적인 업데이트를 허용하고 최근에 변경된 자원으로 웹 순회의 범위를 제한하는 것입니다.

If-Unmodified-Since 사용

오브젝트 PUT, HEAD 또는 GET 요청에서 If-Unmodified-Since 헤더는 오브젝트의 Last-Modified 값 (예: Sat, 14 March 2020 19:43:31 GMT) 이 제공된 값과 같거나 이전인지 확인합니다. 오브젝트가 수정되지 않은 경우 조작이 진행됩니다. Last-Modified 값이 더 최근인 경우 시스템은 PUT 에서 412 Precondition Failed 오류를 리턴하고 GET 또는 HEAD 에서 304 Not Modified 를 리턴합니다.

If-Unmodified-대부분의 경우 상태 변경 메소드 (예: POST, PUT, DELETE) 와 함께 사용되어 여러 사용자 에이전트가 엔티티 태그를 해당 표시와 함께 제공하지 않는 자원에서 병렬로 작동할 수 있는 경우 (즉, "업데이트 유실" 문제점을 방지하기 위해) 우발적인 겹쳐쓰기를 방지합니다. 또한 선택된 표시가 이전 요청에서 이미 저장된 (또는 부분적으로 저장된) 표시와 일치하지 않는 경우 안전한 메소드와 함께 사용하여 요청을 중단할 수 있습니다.

재시도 전략

대부분의 라이브러리 및 SDK가 자동으로 재시도 논리를 처리하지만, 임시 오류를 적절히 처리하기 위해 API를 직접 사용하는 소프트웨어를 작성할 때 주의해야 합니다. 가장 중요한 것은 503오류를 수신할 때 지수 백오프를 구현하는 적절한 재시도 로직을 제공하는 것입니다.

암호 조정

IBM COS는 전송 중인 데이터를 암호화하기 위해 다양한 암호 설정을 지원합니다. 모든 암호 설정이 동일한 레벨의 성능을 제공하는 것은 아니며 일반적으로 TLS를 사용하면 성능이 약간 저하됩니다. 다음 암호 설정이 권장됩니다 (우선순위의 내림차순).

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA