새로운“S3 증가 된 요청 속도 성능”공지 란 무엇입니까


12

2018 년 7 월 17 일에 최대 성능을 달성하기 위해 모든 S3 객체 키의 첫 문자를 무작위화할 필요가 없다고 공식 AWS 발표가있었습니다 : https://aws.amazon.com/about-aws/whats-new / 2018 / 07 / amazon-s3-announces 증가 요청 속도 성능 /

Amazon S3, 요청 속도 성능 향상 발표

게시 된 날짜 : Jul 17, 2018

Amazon S3는 이제 데이터를 추가하기 위해 초당 3,500 개의 요청을, 데이터를 검색하기 위해 초당 5,500 개의 요청을 지원하는 향상된 성능을 제공하므로 추가 비용없이 상당한 처리 시간을 절약 할 수 있습니다. 각 S3 접두사는 이러한 요청 속도를 지원할 수 있으므로 성능을 크게 향상시킬 수 있습니다.

현재 Amazon S3에서 실행되는 애플리케이션은 변경없이이 성능 향상을 누릴 수 있으며 S3에서 새 애플리케이션을 구축하는 고객은이 성능을 달성하기 위해 애플리케이션을 사용자 정의 할 필요가 없습니다. 병렬 요청에 대한 Amazon S3의 지원은 애플리케이션을 사용자 정의하지 않고도 컴퓨팅 클러스터의 요소에 따라 S3 성능을 확장 할 수 있음을 의미합니다. 접두사 당 성능이 확장되므로 필요한 처리량을 달성하기 위해 필요한만큼의 접두사를 동시에 사용할 수 있습니다. 접두사 수에는 제한이 없습니다.

이 S3 요청 속도 성능 향상은 객체 접두사를 무작위 화하여 성능을 향상시키기위한 이전 지침을 제거합니다. 즉, 성능에 영향을주지 않고 S3 객체 명명에서 논리적 또는 순차적 명명 패턴을 사용할 수 있습니다. 이 개선 사항은 이제 모든 AWS 리전에서 사용할 수 있습니다. 자세한 내용은 Amazon S3 개발자 안내서를 참조하십시오.

대단하지만 혼란 스럽습니다. 그것은 말한다 각 S3의 접두사가 간단 성능이 크게 증가하고, 이러한 요청 속도를 지원할 수

그러나 접두사와 구분 기호는 GET Bucket (List Objects)버킷의 내용을 나열 할 때 API 에 대한 인수 일 뿐이 므로 "접두사 당"객체 검색 성능에 대해 이야기하는 것이 합리적 일 수 있습니다. 모든 호출 GET Bucket (List Objects)은 원하는 접두사와 구분자를 선택할 수 있으므로 접두사는 사전 정의 된 엔티티가 아닙니다.

예를 들어, 버킷에 다음과 같은 객체가있는 경우 :

a1/b-2
a1/c-3

그런 다음 버킷 내용을 나열 할 때마다 "/"또는 "-"를 구분 기호로 사용하도록 선택할 수 있으므로 접두사를

a1/ 

또는

a1/b-
a1/c-

그러나 GET ObjectAPI가 전체 키를 사용하기 때문에 특정 접두어 또는 구분 기호의 개념이 객체 검색에 존재하지 않습니다. 5,500 req / sec a1/또는 5,500 req / sec a1/b-및 5,500 on을 기대할 수 a1/c-있습니까?

그렇다면 누군가 "각 s3 접두사"에 대해 특정 수준의 성능 (예 : 데이터를 검색하기 위해 초당 5,500 개의 요청)을 제안 할 때 발표의 의미를 설명 할 수 있습니까?


나는 이것에 대한 설명이 있다고 생각하지만 확인을 찾을 수 있는지 찾고 있습니다. 인덱스 파티션 분할 알고리즘과 관련이 있다고 생각합니다.이 알고리즘은 자동이며 트래픽로드를 기반으로하고 해시 기반이 아닌 어휘를 기반으로합니다.
Michael-sqlbot

답변:


9

여기에서 실제로 접두사라고하는 것은 실제로 버킷 인덱스의 각 파티션을 나타내는 지나치게 단순화 된 것으로 보입니다. 인덱스는 어휘이므로 개체 키의 선행 문자를 기준으로 분할이 발생합니다. 따라서 접두사 라고 합니다 .

S3는 인덱스 파티션을 자동으로 투명하게 관리하므로 여기에서 "접두사"에 대한 정확한 정의는 실제로 다소 부정확합니다. "S3이 버킷의 작업 부하를 지원하기 위해 필요로하는 결정이 무엇이든"입니다. S3는 워크로드에 대한 응답으로 인덱스 파티션을 분할하므로, 오늘날 "접두사"가 동일한 두 개체가 내일마다 다른 접두사를 가질 수 있습니다.

현재 a1 / a -... 및 a1 / b -... 및 a1 / c -...는 모두 단일 접두사 일 수 있습니다. 그러나 버킷에서 충분한 트래픽을 처리하면 S3에서 파티션을 분할해야한다고 결정할 수 있으므로 내일 a1 / a- 및 a1 / b-는 하나의 접두사에 있고 a1 / c-는 자체 접두사에있을 수 있습니다. 즉, 키 <a1 / c-는 하나의 파티션에 있고 키> = a1 / c-는 이제 다른 파티션에 있습니다.

언제, 어디서 어떤 임계 값이 스플릿 동작을 트리거하는지는 문서화되지 않았지만, 오브젝트의 수나 크기가 아니라 요청 수에만 관련되는 것으로 보입니다. 이전에는 이러한 파티션이 초당 수백 건의 요청으로 제한되어 크게 증가했습니다.


1
매우 흥미롭고 믿을 수 있습니다. 그러나 접두사는로드를 기준으로 동적이기 때문에 특정 성능 측정 값을 "접두사 당"으로 할당하는 것은 의미가 없습니다. 버킷의 접두사가 동적으로 변경되면 신뢰할 수있는 성능 측정 값이 없습니다. 또는 S3 객체 당 5,500 req / sec를 기대할 수있을 때까지 이론적으로 접두사가 이론적으로 변경되어야한다고 추론 할 수 있습니까?
John Rees

1
버킷 스케일링은 한 방향으로 만 진행되는 경향이 있기 때문에 성능 측정은 여전히 ​​유용합니다. 파티션 당 단일 객체로의 확장에 대한 명백한 부조리는 객체 당 5k + req / s를 지불하는 경우 AWS가 얼마나 많은 돈을 벌고 있는지 알면 사라지는 것 같습니다.
Michael-sqlbot

1
예, 파티션 당 단일 객체로 약간 놀랍습니다. :-) 그러나 더 진지하게, 이것은 내가 10000 개의 객체 버킷에 10 개의 인기있는 객체가 포함되어 있으면 10 개 각각이 5k reqs / sec를 얻을 수있을 때까지 S3이 결국 다시 파티션 할 것이라고 기대할 수 있다고 생각합니다. 두 개의 큰 파티션에서. 그럴듯한?
John Rees

2
S3가 워크로드에 적응할 것이라고 확신합니다. CloudFront는 전적으로 배포되고 요청을 요청하는 뷰어와 가장 가까운 가장자리에 객체를 캐시하므로 요청 측의 트래픽이 많을 경우 공식적으로 S3와 함께 CloudFront를 사용하는 것이 좋습니다. 요금은 CloudFront를 S3에 추가해도 종종 전체 비용에 영향을 미치지 않습니다 (S3은 요청이 CloudFront에서 도착하여 캐시 미스를 처리 할 때 대역폭을 청구하지 않기 때문에).
Michael-sqlbot

고마워 마이클. 정말 좋은 신중한 답변은 대단히 감사합니다.
John Rees
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.