요청 비율 및 액세스 분배 가이드라인

Cloud Storage는 자동 확장 기술을 사용하여 매우 높은 수준의 요청 비율을 달성하는 고도로 확장 가능한 서비스입니다. 이 페이지는 Cloud Storage가 제공하는 확장성과 성능을 최적화하기 위한 가이드라인을 제공합니다.

자동 확장

Cloud Storage는 멀티 테넌트 서비스이므로 사용자들이 동일한 기본 리소스 집합을 공유합니다. 이러한 공유된 리소스를 최대한 활용하기 위해 버킷은 다음과 같은 초기 IO 용량을 가지고 있습니다.

  • 객체 업로드, 업데이트, 삭제 등 초당 약 1,000개의 객체 쓰기 요청 Cloud Storage에는 동일한 객체 이름의 반복 쓰기에 대해 더 작은 한도도 적용됩니다.
  • 객체 나열, 객체 데이터 읽기, 객체 메타데이터 읽기 등 초당 약 5,000개의 객체 읽기 요청

이를 1MB 객체에 대입하면 한달간 평균 2.5PB 쓰기와 13PB 읽기에 해당합니다. 주어진 버킷에 대한 요청 비율이 증가함에 따라 Cloud Storage는 자동 확장하고 여러 서버에 요청 부하를 분산하여 해당 버킷에 대한 IO 용량을 자동으로 증가시킵니다.

부하 재분배 시간

버킷이 IO 용량 한계에 도달하면 Cloud Storage는 일반적으로 수 분 내에 감지하여 그에 따라 부하를 더 많은 서버에 다시 분배합니다. 결과적으로, 버킷에 대한 요청 비율이 Cloud Storage가 이러한 재분배를 수행할 수 있는 속도보다 빠르게 증가하면 일시적으로 한계에 도달하여 지연 시간과 오류 발생률이 증가할 수 있습니다. 아래의 설명에 따라 버킷에 대한 요청 비율을 점차적으로 높이면 이러한 지연 시간과 오류를 방지할 수 있습니다.

객체 키 색인 생성

Cloud Storage는 사용자가 Cloud Storage에서 데이터 처리 워크플로를 쉽게 실행할 수 있도록 일관된 객체 나열을 지원합니다. 일관된 객체 나열을 제공하기 위해 Cloud Storage는 각 버킷의 객체 키 색인을 관리합니다. 이 색인은 사전순으로 저장되며 버킷에서 객체가 작성되거나 삭제될 때마다 업데이트됩니다. 모든 키가 작은 범위의 색인에 존재하는 객체를 추가 및 삭제하면 자연스럽게 경합이 발생할 가능성이 증가합니다.

Cloud Storage는 부하 집중이라고도 하는 이러한 경합을 감지하고 영향을 받은 색인 범위의 부하를 여러 서버에 자동으로 다시 분배합니다. 버킷의 IO 용량을 확장하는 경우와 마찬가지로 새로운 프리픽스로 객체를 작성할 때와 같이 새로운 색인 범위에 액세스하는 경우에는 아래 설명에 따라 요청 비율을 점진적으로 증가시켜야 합니다. 이렇게 하지 않으면 일시적으로 지연 시간과 오류 발생률이 증가할 수 있습니다.

권장사항

다음 섹션은 요청 비율을 높이고, 객체 키를 선택하고, 버킷에 대한 일시적 한계를 방지하기 위해 요청을 분배하는 방법에 대한 권장사항을 설명합니다. 버킷당 고려사항 외에도 같은 위치 및 프로젝트에 있는 버킷에 적용되는 결합된 대역폭 한도도 있습니다.

점진적으로 요청 비율 높이기

Cloud Storage 자동 확장 기능이 항상 최상의 성능을 제공하도록 하려면 몇 일 동안 요청 비율이 높지 않았거나 새로운 범위의 객체 키를 가진 버킷에 대해 요청 비율을 점진적으로 높여야 합니다. 요청 비율이 초당 1000회 쓰기 요청 또는 초당 5000회 읽기 요청 미만인 경우, 요청 비율을 높일 필요가 없습니다. 요청 비율이 이러한 임곗값을 초과할 것으로 예상되면 임곗값 미만이나 근처의 요청 비율로 시작한 후, 20분 이상에 걸쳐 요청 비율을 2배를 넘지 않는 선에서 점진적으로 높여야 합니다.

지연 시간이나 오류 발생률 증가와 같은 문제점이 발견되면 요청 비율 증가를 일시중지하거나 일시적으로 요청 비율을 줄여서 Cloud Storage가 버킷을 확장할 수 있는 시간적 여유를 두어야 합니다. 다음과 같은 경우에는 지수 백오프로 요청을 다시 시도해야 합니다.

  • 응답 코드가 408 및 429인 오류가 발생합니다.
  • 응답 코드가 5xx인 오류가 발생합니다.

계층적 네임스페이스가 사용 설정된 버킷은 계층적 네임스페이스가 사용 설정되지 않은 버킷에 비해 객체 읽기 및 쓰기에 대한 초기 초당 쿼리 수 (QPS) 한도가 최대 8배 더 높습니다. 초기 QPS가 높을수록 데이터 집약적인 워크로드를 더 쉽게 확장하고 처리량을 개선할 수 있습니다. 버킷에서 계층적 네임스페이스를 사용 설정하는 방법에 관한 자세한 내용은 계층적 네임스페이스가 사용 설정된 버킷 만들기를 참고하세요.

전체 키 범위에 걸쳐 부하를 균일하게 분배하는 이름 지정 규칙 사용

일련의 숫자나 타임스탬프를 토대로 한 객체 키와 같이 순차 이름을 사용하면 색인 범위 자동 확장이 느려질 수 있습니다. 그 이유는 요청이 지속적으로 새로운 색인 범위로 이동하므로 부하 재분배가 더욱 어렵고 효과적이지 않기 때문입니다.

높은 요청 비율을 유지하려면 순차 이름을 사용하지 마세요. 완전한 임의 객체 이름을 사용하면 부하 분배가 최적으로 수행됩니다. 객체 이름의 일부로 일련의 숫자나 타임스탬프를 사용하려면 일련의 숫자나 타임스탬프 앞에 해시 값을 추가하여 객체 이름에 임의성을 도입합니다.

예를 들어, 다음과 같은 원래 객체 이름을 사용하려는 경우:

my-bucket/2016-05-10-12-00-00/file1
my-bucket/2016-05-10-12-00-00/file2
my-bucket/2016-05-10-12-00-01/file3
...

원래 객체 이름의 MD5 해시를 계산하고 객체 이름에 프리픽스로 해시의 첫 6자를 추가할 수 있습니다. 새로운 객체 이름은 다음과 같이 됩니다.

my-bucket/2fa764-2016-05-10-12-00-00/file1
my-bucket/5ca42c-2016-05-10-12-00-00/file2
my-bucket/6e9b84-2016-05-10-12-00-01/file3
...

긴 랜덤 프리픽스를 사용하면 읽기 및 쓰기 속도가 매우 높아질 때 자동 확장에 더욱 효과적입니다. 예를 들어 임의의 16진수 값을 사용하는 1문자 프리픽스는 초기의 초당 5000/1000 읽기/쓰기부터 최대 초당 약 80000/16000 읽기/쓰기까지 유효한 자동 확장을 제공하는데 이는 프리픽스에 16개의 잠재적 값이 있기 때문입니다. 사용 사례에서 이보다 더 높은 비율이 필요하지 않은 경우 1문자의 임의 프리픽스는 2자리 이상의 긴 임의 프리픽스만큼 요청 비율을 늘리는 데 효과적입니다.

공통 프리픽스 뒤의 임의성은 프리픽스에만 효과적임

임의 문자열이 반드시 객체 이름 맨 앞에 있어야 할 필요는 없습니다. 공통 프리픽스 뒤에 임의 문자열을 추가해도 자동 확장 기능이 적용되지만 효과는 해당 프리픽스로만 제한되고 버킷의 나머지 부분은 고려되지 않습니다.

예를 들면 다음과 같습니다.

my-bucket/images/animals/4ce4c6af-6d27-4fa3-8a91-5701a8552705/1.jpg
my-bucket/images/animals/9a495e72-1d85-4637-a243-cbf3e4a90ae7/2.jpg
...
my-bucket/images/landscape/585356ac-ce89-47a8-bdd2-78a86b58fee6/1.jpg
my-bucket/images/landscape/2550ae5b-395e-4243-a29b-bbf5aece60ef/2.jpg
...
my-bucket/images/clouds/1.jpg
my-bucket/images/clouds/2.jpg
...

위의 이름 지정 방식을 통해 images/animals 및 images/landscape,에서는 객체를 효율적으로 자동 확장할 수 있지만 images/clouds에서는 그렇지 않습니다.

순차 프리픽스 뒤의 임의성은 효과적이지 않음

위에서 언급한 바와 같이, 공통 프리픽스 뒤에서 임의 문자열을 사용하면 해당 프리픽스에 대해서만 자동 확장 기능이 적용됩니다. 요청이 새로운 프리픽스로 이동하면 이전 자동 확장 효과의 이점을 더 이상 누릴 수 없습니다. 프리픽스가 순차 패턴을 따르는 경우, 이것이 특히 문제가 됩니다.

예를 들어 새로운 타임스탬프 기반 프리픽스로 1시간마다 파일을 쓰는 경우는 다음과 같습니다.

my-bucket/2016-05-10-00/cf9a7b95-0d2e-4466-9596-840ff388ddbd
my-bucket/2016-05-10-00/f1e16a88-16b8-4c66-ba66-a225c87be80c
my-bucket/2016-05-10-00/646d8272-4a88-4dc2-b2d4-d537c778df41
...
my-bucket/2016-05-10-01/bdcba6de-ac25-4c27-8550-0d08f249e69d
my-bucket/2016-05-10-01/a32c867c-09a9-4d65-9668-ddd4ebe4138b
my-bucket/2016-05-10-01/d619485c-5243-4a4e-8ef3-0f7e1d26ce1d
...

자동 확장은 시간이 지남에 따라 프리픽스에서 쓰기 속도를 높이는 데 도움이 되지만 쓰기 속도는 매시 정각에 다시 설정됩니다. 이로 인해 쓰기 속도가 최적화되지 않고 지연 시간 및 오류율이 주기적으로 증가합니다. 시간이 지남에 따라 다른 프리픽스에 쓰기 작업을 수행해야 하는 경우 이 문제를 방지하려면 새 프리픽스가 전체 키 범위에 고르게 분포되도록 하세요.

대량 작업을 재정렬하여 주요 범위에 로드를 균등하게 분산

Cloud Storage에서 데이터 일괄 업로드 또는 삭제를 수행하려는 경우가 있습니다. 두 경우 모두 객체 이름은 제어할 수 없습니다. 하지만 개체가 업로드되거나 삭제되는 순서를 제어하여 최대 쓰기 또는 삭제 속도를 구현할 수 있습니다.

이렇게 하려면 업로드 또는 삭제를 여러 프리픽스에 분산시켜야 합니다. 예를 들어 업로드할 각 폴더 아래에 폴더와 파일이 여러 개 있는 경우 여러 폴더에서 동시에 업로드하고 업로드할 폴더와 파일을 임의로 선택하는 것이 좋습니다. 이렇게 하면 시스템이 전체 키 범위에 더 균등하게 부하를 분산시킬 수 있으므로, 초기 준비 시간 이후 높은 요청 비율을 달성할 수 있습니다.

다음 단계