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

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

자동 확장

Cloud Storage는 멀티 테넌트 서비스이므로 사용자들이 동일한 기본 리소스 집합을 공유합니다. 이러한 공유된 리소스를 최대한 활용하기 위해 버킷은 초당 약 1000회의 객체 쓰기 요청(객체 업로드, 업데이트, 삭제 포함) 과 초당 약 5000회의 객체 읽기 요청을 처리하는 초기 IO 용량을 가지고 있습니다. 이를 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분 이상에 걸쳐 요청 비율을 두 배로 늘려야 합니다.

지연 시간이나 오류 발생률 증가와 같은 문제점이 발견되면 요청 비율 증가를 일시중지하거나 일시적으로 요청 비율을 줄여서 Cloud Storage에게 버킷을 확장할 수 있는 시간적 여유를 제공해야 합니다. Cloud Storage로부터 5xx 또는 429 응답 코드가 포함된 오류를 받으면 지수 백오프를 사용하여 요청을 다시 시도해야 합니다.

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

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

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

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

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
...

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

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

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

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

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.