KR101865318B1

KR101865318B1 - 버스트 모드 제어

Info

Publication number: KR101865318B1
Application number: KR1020187003304A
Authority: KR
Inventors: 웨이 시아오; 비욘 패트릭 스위프트; 키란-쿠마르 무니스와미-레디; 미구엘 마스카레나스 필리페; 이준 루; 스튜어트 헨리 실리 마샬; 스테파노 스테파니; 제임스 알. 해밀턴
Original assignee: 아마존 테크놀로지스, 인크.
Priority date: 2013-06-25
Filing date: 2014-06-25
Publication date: 2018-06-08
Also published as: EP3014804B1; CN105409171B; EP3014804A1; SG10201709194PA; JP2018077852A; KR101948502B1; AU2017203274B2; KR101826969B1; EP3014804A4; JP6247388B2; AU2014302426A1; JP2016529597A; CN105409171A; SG11201510427QA; JP6530471B2; KR20180063371A; KR101903623B1; AU2014302426B2; CA2915996A1; AU2017203274A1

Abstract

초과한 공유-자원 스루풋 용량의 공평한 분배를 위한 방법들 및 장치가 개시된다. 제 1 및 제 2 작업 타겟은 수용된 작업 요청들을 구현하기 위해 공유된 자원을 액세스하도록 구성된다. 허가 제어는 각각의 토큰 버킷들을 사용하여 작업 타겟들에서 관리된다. 시간 간격 동안 작업 타겟들에서 작업 요청 도착률들을 표시한 제 1 메트릭 및 작업 타겟들의 프로비저닝된 용량들과 연관된 제 2 메트릭이 결정된다. 공유 자원의 스루풋 한계에 기초하여 결정된 토큰들의 수는 후속 시간 간격 동안 허가 제어를 위해 사용될 작업 타겟들 중에서 분배된다. 각각의 작업 타겟에 분배될 토큰들의 수는 제 1 메트릭 및/또는 제 2 메트릭에 기초한다.

Description

버스트 모드 제어 {BURST MODE CONTROL}

여러 개의 첨단 기술 조직들은 “서비스형 소프트웨어(software-as-a-service)”를 판매하는 빌딩 기술(building technology)들에 투자하고 있다.

이러한 서비스들은 공유된 저장 장치(예로서, 데이터베이스 시스템들) 및/또는 컴퓨팅 자원들에 대한 액세스를 클라이언트들 또는 가입자들에 제공한다. 다중-티어 전자-상거래 시스템들 내에서, 상이한 유형들의 자원들의 조합들이 전체 물리적 또는 가상 기계들, CPU들, 메모리, 네트워크 대역폭, 또는 I/O 용량과 같은, 가입자들 및/또는 그것들의 애플리케이션들에 할당될 수 있다.

클라이언트들에 서비스들을 제공하는 모든 시스템은 잠재적으로 시스템을 오버로딩할 수 있는 서비스 요청들의 압도적인 로드(load)로부터 스스로를 보호할 필요가 있다. 일반적으로, 웹 서비스 또는 원격 절차 호출(RPC) 서비스에 대하여, 시스템은 그것이 수신하는 클라이언트 요청들의 몇몇 부분에 대한 예상된 서비스 품질을 제공할 수 없다면 “오버로딩(overloaded)” 상태에 있는 것으로 고려된다. 오버로딩된 시스템들에 의해 적용된 공통 해법들은 시스템이 오버로딩 상태를 떠날 때까지 클라이언트들에 대한 서비스를 거절하거나 또는 특정한 수의 인입 요청들을 스로틀링하는 것을 포함한다.

몇몇 현재 시스템들은 요청 레이트를 고정된 또는 가변적인 전역 임계치와 비교하며 이러한 임계치가 교차되었다면 클라이언트들에 대한 서비스를 선택적으로 거절함으로써 오버로드 시나리오를 회피한다. 그러나, 이러한 접근법은 서비스 제공을 위한 서비스 요청들의 상이한 유형들 및/또는 인스턴스들을 수용하는 것에 응답하여 수행될 수 있는 작업의 양에서의 차이들을 고려하지 않는다. 또한, 가변적인, 예측 가능하지 않은 레이트들에서 상이한 유형들의 요청들을 수신하는 시스템에서 의미 있으며(수용 가능한 성능을 제공하는 것은 더욱 아닌), 요청들을 만족시키기 위해 요구되는 작업의 양이 또한 가변적이며 예측 가능하지 않은 단일 전역적 임계치를 정의하는 것은, 불가능하지 않다면, 어렵다. 많은 서비스들이 클라이언트 요청들이 시간에 걸쳐 균일하게 분배될 때 가장 잘 작동하도록 설계되어왔지만, 실제로 작업 분포에서의 이러한 시간적 균일성은 좀처럼 접해지지 않는다. 더욱이, 적어도 몇몇 환경들에서, 워크로드(workload)들은 시간에 대하여 균일하지 않을 수 있을 뿐만 아니라 또한 동작되는 데이터 세트에 대하여 균일하지 않을 수 있다 - 예로서, 데이터의 몇몇 부분들은 다른 것들보다 더 빈번하게 액세스되거나 또는 수정될 수 있다. 높은 레벨들의 고객 만족을 달성하며 유지하고 싶어하는 서비스 제공자들은 보다 정교한 방식으로 작업부하 변화들을 다루는 기술들을 구현할 필요가 있을 수 있다.

도 1a는 작업 요청 도착률 변화들의 예를 예시하며, 도 1b는 적어도 몇몇 실시예들에 따라, 토큰 버킷들이 이러한 변화들의 존재 시 허가 제어 결정들을 하기 위해 사용될 수 있는 시스템을 예시한다.
도 2는 적어도 몇몇 실시예들에 따라, 토큰 기반 허가 제어 메커니즘의 고-레벨 개요를 제공한다.
도 3은 적어도 몇몇 실시예들에 따라, 허가 제어를 위해 사용된 토큰 버킷의 예시적인 구성 속성들을 예시한다.
도 4는 적어도 몇몇 실시예들에 따라, 프로비저닝된-용량 버킷으로부터 버스트-모드 버킷으로 사용되지 않은 토큰들의 축적의 예를 예시한다.
도 5는 적어도 몇몇 실시예들에 따라, 판독들 및 기록들에 대한 허가 제어를 위해 각각의 토큰 버킷들의 사용을 예시한다.
도 6은 적어도 몇몇 실시예들에 따라, 하나 이상의 로컬-버스트-제한 버킷들, 하나 이상의 공유-자원 용량 버킷들, 및 하나 이상의 복제-관리 버킷들을 포함한 버스트-모드 토큰 버킷 세트를 예시한다.
도 7은 적어도 몇몇 실시예들에 따라, 허가 제어 목적들을 위해 카테고리들로의 작업 요청 버스트들의 분류의 예를 예시한다.
도 8은 적어도 몇몇 실시예들에 따라, 버스트-모드 허가 제어를 위해 피크-버스트 토큰 버킷 및 지속-버스트 토큰 버킷의 조합을 포함한 복합 토큰 버킷의 사용의 예를 예시한다.
도 9는 적어도 몇몇 실시예들에 따라, 작업 동작들의 각각의 카테고리들에 전용된 피크-버스트 및 지속-버스트 버킷들의 사용을 예시한다.
도 10은 적어도 몇몇 실시예들에 따라, 네트워크-액세스 가능한 서비스에서 작업 요청들에 대한 토큰-기반 허가 제어 메커니즘을 구현하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 11은 적어도 몇몇 실시예들에 따라, 네트워크-액세스 가능한 서비스에서 복수의 버스트-모드 토큰 버킷들을 사용하여 버스트-모드 동작들을 핸들링하기 위한 토큰-기반 허가 제어 메커니즘을 구현하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 12는 적어도 몇몇 실시예들에 따라, 허가 제어를 위해 수행될 수 있는 토큰 소비, 리필 및 전달 동작들의 양상들을 예시한 흐름도이다.
도 13은 적어도 몇몇 실시예들에 따라, 허가된 작업 요청에 대응하는 작업 동작들이 완료된 후 하나 이상의 토큰 버킷들에서 토큰 카운트들을 조정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 14는 적어도 몇몇 실시예들에 따라, 관리 이벤트들에 응답하여 버스트-모드 허가 제어 파라미터들을 수정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 15는 적어도 몇몇 실시예들에 따라, 토큰-기반 버스트-모드 허가 제어를 위해 사용된 파라미터들을 조정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 16은 적어도 몇몇 실시예들에 따라, 작업 요청 도착률들의 비-균일성과 조합하여, 서비스에 의해 관리된 데이터의 상이한 서브세트들에 대하여 작업 요청들의 비-균일한 분배의 예를 예시한다.
도 17은 적어도 몇몇 실시예들에 따라, 데이터 액세스의 공간 비-균일성의 결과들을 완화시키기 위해 구현될 수 있는 토큰-공유 프로토콜의 예시적인 반복들을 예시한다.
도 18은 적어도 몇몇 실시예들에 따라, 데이터 파티션들이 복제되는 환경에서 수립될 수 있는 토큰 공유 피어 그룹들의 예들을 예시한다.
도 19는 적어도 몇몇 실시예들에 따라, 2차 인덱스들에 대한 작업부하 관리를 지원하기 위해 데이터베이스 서비스에서 토큰 공유의 사용의 예를 예시한다.
도 20a 내지 도 20d는 적어도 몇몇 실시예들에 따라, 토큰-공유 프로토콜에서의 참여자들 사이에서 메시지 시퀀스 흐름들의 예들을 예시한다.
도 21은 적어도 몇몇 실시예들에 따라, 버스트-모드 동작들에 대한 토큰 공유를 지원하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 22는 적어도 몇몇 실시예들에 따라, 자원을 공유하는 작업 타겟들의 조합된 프로비저닝된 용량들보다 큰 스루풋 한계를 가진 공유된 자원의 예를 예시한다.
도 23은 적어도 몇몇 실시예들에 따라, 서비스의 저장 노드에서 작업 타겟들에 의해 공유될 수 있는 자원들의 예들을 예시한다.
도 24는 적어도 몇몇 실시예들에 따라, 자원을 공유한 작업 타겟들 중에서 분배될 초과 토큰들의 수를 계산하기 위해 수행된 동작들의 예를 예시한다.
도 25는 적어도 몇몇 실시예들에 따라, 자원을 공유한 작업 타겟들 중에서 초과 토큰들의 공평한 분배를 구현하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 26은 적어도 몇몇 실시예들에 따라, 버스트-모드 동작들을 위해 구현될 수 있는 가격 책정 관리기의 예시적인 구성요소들을 예시한다.
도 27은 적어도 몇몇 실시예들에 따라, 토큰-기반 가격 책정 정책의 예시적인 요소들을 예시한다.
도 28은 적어도 몇몇 실시예들에 따라, 버스트-모드 동작들에 대한 과금 양들을 결정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 29는 적어도 몇몇 실시예들에 따라, 조건부 버스트-모드 가격 책정과 연관된 동작들의 양상들을 예시한 흐름도이다.
도 30은 적어도 몇몇 실시예들에 따라, 가격 책정 정책(pricing policy)들의 클라이언트 선택을 가능하게 하기 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 31은 적어도 몇몇 실시예들에 따라, 버스트-모드 토큰들에 대한 시장을 가능하게 하기 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 32는 적어도 몇몇 실시예들에 따라, 작업 타겟의 상이한 파티션들 사이에서의 토큰들의 가격 책정 전달들을 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 33은 적어도 몇몇 실시예들에 따라, 토큰 버킷 구성 설정들에 대한 가격 책정 변화들을 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다.
도 34는 적어도 몇몇 실시예들에서 사용될 수 있는 예시적인 컴퓨팅 디바이스를 예시한 블록도이다.
실시예들이 여기에서 예로서 여러 개의 실시예들 및 예시적인 도면들에 대해 설명되지만, 이 기술분야의 숙련자들은 실시예들이 설명된 실시예들 또는 도면들에 제한되지 않는다는 것을 인식할 것이다. 도면들 및 그것에 대한 상세한 설명은 개시된 특정한 형태로 실시예들을 제한하도록 의도되지 않지만, 그와는 반대로, 의도는 첨부된 청구항들에 의해 정의된 바와 같이 사상 및 범위 내에 속하는 모든 수정들, 등가물들 및 대안들을 커버하는 것임이 이해되어야 한다. 여기에 사용된 주제들은 단지 조직 목적들을 위한 것이며 설명 또는 청구항들의 범위를 제한하기 위해 사용되도록 의도되지 않는다. 본 출원 전체에 걸쳐 사용된 바와 같이, 단어(“일 수 있다”)는 의무적 의미(즉, 해야 한다는 의미하는)보다는 허용적 의미(즉, ~하기 위한 가능성을 가짐을 의미하는)에서 사용된다. 유사하게, 단어들(“포함하다”, “포함하는”, 및 “포함하다”)은 이에 제한되지 않지만, 포함하는 것을 의미한다.

토큰 버킷들 및 연관된 가격 책정 정책들을 사용하여 버스트-모드 허가 제어를 구현하기 위한 방법들 및 장치의 다양한 실시예들이 설명된다. 용어(“허가 제어(admission control)”)는 수신된 작업 요청들(저장 서비스로 향해진 판독 또는 기록 요청들과 같은)이 구현을 위해 수용되는지를 결정하기 위해 수행된 동작들을 표현하기 위해 여기에서 사용될 수 있으며 허가 제어를 수행할 때 수반된 소프트웨어 및/또는 하드웨어 엔티티들의 세트는 총괄하여 “허가 제어기들(admission controller)”로서 불리울 수 있다. 토큰 버킷들을 사용한 허가 제어는 예를 들면, 네트워크-액세스 가능한 서비스(다중-임차자 저장 또는 데이터베이스 서비스)가 프로비저닝된 워크로드 모델을 지원하는 다양한 환경들에서 이용될 수 있다. 프로비저닝된 워크로드 모델에서, 작업 요청들이 향해질 수 있는 주어진 오브젝트는 그것이 보통 작업 요청들에 대한 수용 가능한 응답 시간들을 갖고 작업 요청들의 특정 레이트(“프로비저닝된 스루풋 용량(provisioned throughput capacity)”)까지 지원할 수 있도록 하는 방식으로 설정되거나 또는 구성될 수 있다. 용어(“스루풋 용량(throughput capacity)”)는 여기에서 주어진 레이트에서 작업 요청들을 완료하기 위해 자원(예로서, 저장 오브젝트, 데이터베이스 테이블(base table), 또는 저장 오브젝트 또는 데이터베이스 테이블의 파티션)의 능력을 표현하기 위해 사용된다. 스루풋 용량은 예를 들면, 저장 자원들의 경우에서 초당 논리적 또는 물리적 판독들 또는 기록들과 같은, 초당 작업 동작들과 같은 단위들로 표현될 수 있다. 용어(“작업 타겟(work target)”)는 여기에서 작업 요청들이 향해질 수 있는, 네트워크-액세스 가능한 서비스에 의해 구현되고 및/또는 관리된 자원 또는 오브젝트를 위해 사용될 수 있다. 적어도 몇몇 실시예들에서, 주어진 허가 제어기는 복수의 작업 타겟들에 대한 허가 결정들을 할 책임이 있을 수 있다.

일 실시예에서, 예를 들면, 네트워크-액세스 가능한 다중-임차자 데이터베이스 서비스는 초당 X개의 판독 또는 기록 동작들까지 핸들링하기 위해 구성된 데이터베이스 테이블(작업 타겟)을 설정할 수 있다(즉, 테이블의 프로비저닝된 스루풋 용량은 초당 X개의 동작들로서 설정될 수 있다). 용어들(“프로비저닝된 스루풋 용량” 및 “프로비저닝된 용량(provisioned capacity)”)은 여기에서 상호 교환 가능하게 사용될 수 있다. 적어도 몇몇 실시예들에서, 대응하는 클라이언트가 테이블의 수립 및 사용에 대해 지불하는 것에 대해 동의해야 하는 양은 프로비저닝된 용량에 기초할 수 있고; 예로서 클라이언트와의 작업 오브젝트에 대한 서비스 레벨 협약의 결과로서, 클라이언트는 서비스가 프로비저닝된 용량까지 작업 요청 도착률들을 쫓아갈 수 있어야 한다는 것을 예상할 수 있다(적어도, 재해적 이벤트들과 같은 기이한 상황들의 부재 시). 프로비저닝된 용량을 지원할 수 있도록, 데이터베이스 서비스는 테이블의 콘텐트들을 저장하며 원하는 스루풋 레벨들 및 응답 시간들을 지원하기 위해 적절한 저장 용량 및 수행 능력들을 갖고 저장 디바이스들을 식별하며 이용하는 것, 작업부하 밸런싱 목적들을 위해 다수의 이러한 디바이스들 중에서 테이블의 콘텐트들의 부분들을 분배하는 것 등과 같은 다양한 단계들을 취할 수 있다. 이러한 예시적인 시나리오에서, 프로비저닝된 스루풋 용량이 결정되거나 또는 테이블에 대해 설정된 후(예로서, 특정된 스루풋 능력들을 가진 테이블을 생성하기 위한 클라이언트의 요청이 수용되었거나, 또는 대응하는 서비스 레벨 협약이 관련 당사자들에 의해 승인되었다면), 테이블로 향해진 판독 또는 기록 요청들이 초당 X개의 요청들 이하의 레이트로 도착하는 한, 데이터베이스 서비스는 일반적으로 적정한 응답 시간들을 갖고 요청들을 수용하며 실행할 책임이 있을 수 있다. 오브젝트로 향해진 작업 요청들이 프로비저닝된 용량보다 높은 레이트로 도착한다면, 그러나, 오브젝트는 동작의 “버스트 모드(burst mode)”에서 동작하는 것으로 간주될 수 있으며, 서비스가 이러한 버스트-모드 작업 요청들을 수용하며 실행하려고 비보장형(best-effort) 시도를 할 수 있는 동안, 몇몇 버스트-모드 작업 요청들은 지연되거나 또는 거절될 수 있다. 몇몇 실시예들에서, 프로비저닝된 용량이 다양한 하위-레벨 자원들(저장 디바이스들 또는 서버들과 같은)에 작업 타겟 및 그것의 작업부하의 매핑으로서 이러한 파라미터들을 결정하기 위해 내부적으로 사용될 수 있을지라도, 주어진 작업 타겟의 프로비저닝된 용량은 관리 목적들을 위해 네트워크-액세스 가능한 서비스에 의해 내부적으로 사용될 수 있다 - 예로서, 서비스는 반드시 클라이언트에 프로비저닝된 용량을 드러내는 것이 아닐 수 있다.

프로비저닝된 워크로드 모델이 이용되는 몇몇 실시예들에서, 논리 컨테이너들 또는 “버킷들(buckets)”에 배열된 작업 토큰들은 자원의 이용 가능한 스루풋 용량을 표현하기 위해 사용될 수 있으며, 이러한 버킷들은 따라서 주어진 작업 요청이 실행을 위해 수용되어야 하는지를 결정하기 위해 사용될 수 있다. 용어(“이용 가능한 스루풋 용량”)는 여기에서 그것의 현재 워크로드를 고려해볼 때, 자원가 얼마나 많은 부가적인 스루풋을 제공할 수 있는지에 대한 추정치 또는 측정치를 표현하기 위해 사용될 수 있다. 예를 들면, 주어진 저장 디바이스는 초당 100개의 작업 동작들(예로서, 판독들 또는 기록들)의 프로비저닝된 용량을 갖고 구성될 수 있으며, 주어진 초 동안, 초당 60개의 동작들의 워크로드를 지원할 수 있다. 이 예에서, 그것의 이용 가능한 스루풋 용량은 초당 (100-60), 또는 40개의 동작들일 수 있다. 버킷은 일 구현에서, 프로비저닝된 용량을 표현하기 위해 매초 100개의 토큰들로 이루어질(또는 “리필될(refilled)”) 수 있다. 작업 요청이 도달함에 따라, 토큰들은, 프로비저닝된-용량 버킷으로 칭하여질 수 있는 버킷으로부터 소비될 수 있으며 - 예로서, 토큰들 중 60개가 60개의 작업 요청들이 수신되는 초에서 소비될 수 있으며, 이용 가능한 스루풋 용량을 나타내는 40개의 토큰들을 남긴다. 작업 요청 레이트가 프로비저닝된 용량보다 높지 않은 채로 있는 한, 저장 디바이스는 정상적으로, 또는 정상 모드에서 동작하는 것으로 고려될 수 있으며, 정상 동작들에 적용 가능한 파라미터들의 세트는 허가 제어를 위해 사용될 수 있다. 추가로 상세히 이하에서 설명된 바와 같이, 작업 요청 도착률이 프로비저닝된 스루풋 용량(예로서, 이 예에서 초당 100개의 작업 동작들)을 초과한다면, 저장 디바이스는 정상 모드와 대조적으로 버스트 모드에서 동작하는 것으로 간주될 수 있으며, 상이한 세트의 허가 제어 파라미터들이 사용될 수 있다. 프로비저닝된 용량 버킷의 토큰 집단이 소진될 수 있으며, 하나 이상의 부가적인 버킷들(버스트-모드 버킷들로 칭하여지는)은 버스트 모드 동안 허가 제어를 핸들링하기 위해 사용될 수 있다. 다수의 상이한 접근법들이 상이한 실시예들에서 버스트-모드 버킷(들)에서의 토큰들을 실장(populate)하고 소비하기 위해, 예를 들면, 서비스가 특정한 제약들 내에서 버스트-모드 동작들에 대한 비보장형(best-effort) 지원을 제공할 수 있게 하기 위해 취해질 수 있다. 주어진 자원의 이용 가능한 스루풋 용량(및 그러므로 버스트 모드 동작들에 대응하는 작업부하 레벨)은 기본 하드웨어 또는 소프트웨어의 능력들, 및/또는 자원에서 스루풋을 제어하거나 또는 제한하기 위해 구현되는 정책들(로드 밸런싱 고려사항들, 공정성 고려사항들, 비즈니스/가격 책정 고려사항들 또는 하드웨어/소프트웨어의 본래 능력들이 아닌 인자들의 몇몇 조합)과 같은, 상이한 실시예들에서 다양한 상이한 인자들의 임의의 조합에 의존적일 수 있다는 것이 주의된다.

일 실시예에 따르면, 작업 타겟은 그것으로 향해진 작업 요청들의 레이트가 특정된 레벨(예로서, 작업 타겟의 프로비저닝된 능력) 이하인 한 정상 모드에서 동작하는 것으로 간주될 수 있으며 작업 요청들의 레이트가 특정 레벨을 초과한다면 버스트 모드에서 동작하는 것으로 간주될 수 있다. 임의의 주어진 작업 요청이 수신될 때, 작업 타겟과 연관된 정상-모드 토큰 버킷의 토큰 모집단이 결정될 수 있다. 정상-모드 토큰 버킷의 토큰 모집단이 임계 기준을 충족시킨다면(예로서, 그것이 1 이상이거나, 또는 몇몇 임계 값 이상이면), 이것은 작업 타겟이 정상 모드에 있음을 허가 제어기에 표시할 수 있다. 따라서, 허가 제어기는 이러한 실시예들에서 동작의 모드를 결정하기 위해 직접 도착률들을 모니터링할 필요가 없을 수 있다 - 대신에, 정상-모드 토큰 버킷에서의 토큰 카운트들은 모드 결정을 위해 사용될 수 있어서, 도착률들이 허가 제어를 위해 모니터링되어야 하는 시나리오들에 대해 허가 제어기의 작업부하를 잠재적으로 감소시킨다. 요청은 정상 모드에서 실행을 위해 수용될 수 있으며, 하나 이상의 토큰들은 정상-모드 버킷으로부터 소비될 수 있다.

그러나, 정상-모드 버킷 모집단이 임계 기준을 충족시키지 않는다면, 작업 타겟은 버스트 모드에 있는 것으로 간주될 수 있거나, 또는 적어도 작업 요청이 실행을 위해 수용되었다면 작업 타겟이 버스트 모드에 들어갈 것이라는 결정이 이루어질 수 있다. 따라서, 허가 제어기는 버스트-모드 토큰 버킷들의 세트 중 적어도 하나의 버킷의 토큰 모집단을 결정할 수 있다. 버스트-모드 토큰 버킷 또는 버킷들의 토큰 집단이 제 2 임계 기준을 충족시킨다면(예로서, 버스트-모드 토큰 버킷이 적어도 하나의 토큰을 포함한다면), 작업 요청은 실행을 위해 수용될 수 있다. 버스트-모드 버킷 또는 버킷들의 모집단은 작업 요청이 수용되었다는 사실을 반영하기 위해 수정될 수 있다. 적어도 일 실시예에서, 허가 제어기는 예로서, 작업 요청을 완료하거나 또는 만족시키기 위해 수행될 작업의 양의 추정치에 기초하여, 및/또는 버스트-모드 동작들에 대해 적용 가능한 토큰 소비 정책에 기초하여, 버스트-모드 토큰 버킷(들)으로부터 특정한 수의 토큰들을 소비할 수 있다. 하나 이상의 작업 동작들(예로서, 저장 또는 데이터베이스 오브젝트들을 포함한 작업 타겟들의 경우에 판독들 또는 기록들)은 그것이 수용된 후 작업 요청에 따라 개시될 수 있다.

적어도 몇몇 실시예들에 따르면, 정상-모드 토큰 버킷의 토큰 모집단이 작업 타겟이 버스트-모드에 있음을 표시하지 않는다면, 정상-모드 토큰 버킷은 단독으로 허가 제어를 위해 사용될 수 있다(예로서, 몇몇 수의 토큰들은 상기 설명된 바와 같이 수용된 각각의 작업 요청에 대해 정상-모드 토큰 버킷으로부터 소비될 수 있다). 따라서, 버스트-모드 버킷(들)의 모집단은 적어도 몇몇 실시예들에서 정상 모드 허가 제어 동작들 동안 역할을 맡지 않을 수 있다. 몇몇 실시예들에서, 정상 모드 동작들 동안에도, 작업 요청이 수용될 때, 토큰들은 버스트-모드 및 정상-모드 버킷들의 각각의 토큰 소비 정책들에 따라 하나 이상의 정상-모드 토큰 버킷들로부터뿐만 아니라 하나 이상의 버스트-모드 버킷들로부터 소비될 수 있다. 적어도 몇몇 실시예들에서, 토큰들은 정상 모드 동안에도 적용 가능한 리필 정책들에 따라 버스트-모드 버킷들에 부가될 수 있다는 것이 주의된다. 작업 타겟이 버스트 모드에 있으며, 버스트-모드 버킷 또는 버킷들의 모집단이 제 2 임계 기준을 충족시키지 않는다면(예로서, 충분한 토큰들이 작업 요청을 수용하기 위해 버스트-모드 버킷들에서 발견되지 않았다면), 작업 요청은 몇몇 실시예들에서 거절되고, 지연되거나, 또는 재시도될 수 있다. 적어도 몇몇 실시예들에서, 충분한 토큰들이 주어진 작업 요청을 수용하기 위해 이용 가능하지 않을 때, 작업 요청은 요청을 제출하였음을 클라이언트에 통지하지 않고 1회 이상(예로서, 구성 가능한 재시도 카운트 한계까지) 재시도될 수 있다. 작업 요청이 궁극적으로 수용된다면, 작업 요청을 발행한 클라이언트는 요청에 대해 정상보다 높은 총 응답 시간을 경험할 수 있지만, 요청이 적어도 한 번 거절되었음을 알지 못한 채로 있을 수 있다.

추가로 상세히 이하에서 설명되는 바와 같이, 정상-모드 및 버스트-모드 토큰 버킷들은 다양한 시간 포인트들에서 각각의 리필 정책들에 따라 토큰들로 리필될 수 있다. 일 실시예에서, 정상-모드 토큰 버킷은 최대 토큰 집단 한계를 조건으로 하여, 작업 타겟의 프로비저닝된 용량과 같은 레이트로 리필될 수 있다. 이러한 정상-모드 토큰 버킷은 적어도 몇몇 실시예들에서 프로비저닝된-용량 토큰 버킷으로서 불리울 수 있다. 하나 이상의 버스트-모드 토큰 버킷들은 적어도 몇몇 실시예들에서 작업 타겟의 프로비저닝된 스루풋 용량에 비례하는 레이트로(반드시 같은 것은 아닌) 리필될 수 있다. 작업 타겟의 프로비저닝된 용량에 비례하는 버스트-모드 버킷들의 리필 레이트들을 유지하는 것은 상이한 작업 타겟들이 그것들의 각각의 프로비저닝된 용량에 비례하는 버스트-모드 워크로드들을 핸들링한다는 것을 보장할 수 있다. 예를 들면, 데이터베이스 서비스의 클라이언트(C1)는 프로비저닝된 용량(P1)을 가진 테이블(T1)에 대해 양(A1)을 지불하며, 클라이언트(C2)가 프로비저닝된 용량(P2)을 가진 테이블(T2)에 대해 A2를 지불한다면(여기에서 P1 > P2 및 A1 > A2), T1에 대한 버스트-모드 토큰 버킷(들)은 T2에 대한 버스트-모드 토큰 버킷(들)보다 더 높은 레이트로 리필될 것이며, 따라서 작업 요청들의 보다 높은 버스트 레이트들은, A1 > A2이므로 예상될 수 있는 바와 같이, T2에 대한 것보다 T1에 대해서보다는 T1에 대해 지원 가능하다.

몇몇 실시예들에서, 서비스는 상이한 유형들의 작업 요청 도착률 버스트들에 대한 상이한 허가 제어 파라미터들을 이용할 수 있다. 예를 들면, 초당 프로비저닝된 용량(P) 동작들을 가진 서비스(S)에 의해 구현된 작업 타겟(W)을 고려하자. 초당 P보다 큰 레이트에서 작업 요청 도착들은 버스트들로서 분류될 수 있다. 그러나, 모든 버스트들이 동일한 방식으로 서비스(S)에 영향을 미치는 것은 아니다. 클라이언트가 초당 100P의 레이트로 작업 요청들을 제출한다면, 예를 들면, 서비스(S)는 단지 다른 클라이언트들에 부정적으로 영향을 미치거나 또는 자원들을 다 쓰지 않고 매우 짧은 지속 기간 동안 요청들을 다룰 수 있을 것이다. 클라이언트가 초당 2P의 레이트로 작업 요청들을 제출한다면, 그러나 서비스는 보다 긴 기간 동안 요청들을 다룰 수 있을 것이다. 따라서, 일 실시예에서, 도착률들에서 급격한 단기 피크들을 다루기 위한 피크-버스트 버킷, 및 보다 낮은 최대 요청 레이트들을 갖고 보다 긴 버스트들을 다루기 위한 지속-버스트 버킷과 같은, 복수의 버스트-모드 토큰 버킷들이 설정될 수 있다. 피크-버스트 토큰 버킷 및 지속-버스트 토큰 버킷의 조합은 여기에서 “복합(compound)” 토큰 버킷(또는 복합 버킷(compound bucket))으로서 불리울 수 있다. 허가 제어기는 이러한 실시예에서, 작업 타겟으로 향해진 작업 요청들이 실행을 위해 수용되는 피크 버스트 레이트, 및 피크 버스트 레이트에서 작업 요청들이 수용되는 최대 지속 기간을 표시하는 피크 버스트 윈도우 크기를 결정할 수 있다. 또한, 허가 제어기는 피크 버스트 레이트보다 작은 지속 버스트 레이트, 및 피크 버스트 윈도우 크기보다 큰 지속 버스트 윈도우 크기를 결정할 수 있으며, 여기에서 지속 버스트 윈도우 크기는 지속 버스트 레이트에서 작업 타겟으로 향해진 작업 요청들이 수용되는 최대 지속 기간을 표시한다. 윈도우 크기들은 일반적으로 각각의 버스트 레이트들이 몇몇 실시예들에서 특정한 조건들 하에서(예로서, 버스트 동안 리필들이 없음을 가정하는) 지속될 수 있는 지속 기간들을 표시할 수 있지만, 실제로 달성된 지속 기간들은 (예로서, 리필 동작들이 사실상 버스트들 동안 수행될 수 있기 때문에) 윈도우 크기들에 정확하게 일치하지 않을 수 있다. 두 개의 버스트-모드 버킷들의 최대 토큰 모집단은 그것들 각각의 최대 버스트 레이트들에 기초하여 설정될 수 있다 - 예로서, 일 구현에서, 피크-버스트 버킷의 최대 토큰 모집단은 피크 버스트 레이트 및 피크 버스트 윈도우 크기의 곱으로 설정될 수 있지만, 지속-버스트 버킷의 최대 토큰 모집단은 지속 버스트 레이트 및 지속 버스트 윈도우 크기의 곱으로 설정될 수 있다. 양쪽 버킷들 모두는 버스트 모드 동작들 동안 허가 제어를 위해 사용될 수 있다 - 예로서 작업 타겟에서 향해진 작업 요청을 수신하는 것에 응답하여, 허가 제어기는 피크-버스트 토큰 버킷 및 지속-버스트 토큰 버킷의 각각의 토큰 모집단들에 적어도 부분적으로 기초하여 실행을 위한 작업 요청을 수용할 수 있다. 적어도 몇몇 실시예들에서, 상이한 소비 레이트들 및/또는 상이한 리필 레이트들은 피크-버스트 버킷 및 지속-버스트 버킷에 적용할 수 있다.

복합 버킷 기술을 사용함으로써, 허가 제어기는 이러한 실시예들에서 짧은 지속 기간들 동안 매우 높은 버스트 레이트들, 및 보다 긴 지속 기간들 동안 보다 낮은 버스트 레이트들을 지원할 수 있을 것이다. 작업 타겟의 프로비저닝된 용량(pr)은 100개의 동작들/초(100 ops/sec)이고, 피크-버스트 버킷(PBB : peak-burst bucket)과 연관된 피크 버스트 레이트(pbr)는 1000 ops/sec이고, 피크 버스트 윈도우 크기(pbw)는 6초들이고, 지속-버스트 윈도우 SBB(sustained-burst bucket)와 연관된 지속 버스트 레이트(sbr)는 200 ops/sec이며, 지속 버스트 윈도우 크기(sbw)는 60초들인 예시적인 시나리오를 고려하자. 피크-버스트 버킷의 최대 모집단(PBB-max)은 pbr 및 pbw의 곱(1000*6, 또는 6000 토큰들)으로 설정되며, 지속 버스트 버킷의 최대 모집단(SBB-max)은 sbr 및 sbw(200*60, 또는 12000 토큰들)의 곱으로 설정된다고 추가로 가정한다. 시간(T)에서 시작하는 작업 요청들(B)의 버스트를 고려하자(즉, 이러한 예시적인 시나리오에서, 허가 제어기는 정상-모드 버킷이 정상 모드 동작들 동안 시간(T)에서 불충분한 토큰들을 가지며, 따라서 버스트-모드 파라미터들이 적용된다). 설명의 용이함을 위해 PBB는 매초 200개의 토큰들로 리필되고(PBB-max 한계를 조건으로 하는) SBB는 매 초 100개의 토큰들로 리필되며(SBB-max 한계를 조건으로 하는) 작업 타겟은 이 예를 위해 버스트-모드에 남아있다고 가정하자. 각각의 작업 요청은 하나의 실제 작업 동작(예로서, 판독 또는 기록)을 야기한다고 가정되며, 하나의 토큰은 주어진 요청을 수용하기 위해 버스트-모드 버킷들, PBB(피크-버스트 버킷) 및 SBB(지속-버스트 버킷)의 각각으로부터 소비될 것이다. PBB 및 SBB 양쪽 모두는 시간(T)에서 가득한 것으로 가정된다: PBB는 6000개의 토큰들을 가지며, SBB는 12000개의 토큰들을 가진다.

첫 번째로, 버스트(B)는 1000 요청들/초에서의 도착들로 이루어지는 시나리오를 고려하자. 1초 후, 시간(T+1)에서, PBB의 모집단은, PBB가 6000개의 토큰들로 시작되고, 1000개의 토큰들이 도착들로 인해 소비되었으며 200이 PBB의 리필 정책에 따라 부가되었기 때문에 (6000 - 1000 + 200) = 5200일 것이다. 유사하게, 시간(T+1)에서, SBB의 모집단은 (12000 - 1000 + 100) = 11100일 것이다. 요청들이 1000 요청들/초에서 도착하는 동안 다음 수 초들 동안 매 초, PBB의 순 모집단은 800개의 토큰들만큼 떨어질 것인 반면, SBB의 것은 900만큼 떨어질 것이다. 따라서, PBB(pop(PBB)로 불리우는) 및 SBB(pop(SBB)로 불리우는)의 토큰 모집단들은 다음과 같이 감소할 것이다: 시간(T+2)에서: pop (PBB) = 4400, pop(SBB) = 10200; 시간(T+3): pop(PBB) = 3600, pop(SBB) = 9300; 시간(T+4): pop(PBB) = 2800, pop(SBB) = 8400; 시간(T+5): pop(PBB)=2000, pop(SBB) = 7500; 시간(T+6): pop(PBB) = 1200, pop (SBB) = 6600; 시간(T+7): pop(PBB) = 400, pop(SBB) = 5700.

T+7을 따르는 초 동안, 버스트 B는 초당 1000개의 요청들에서 계속되고, PBB는 이 예에서 토큰들을 다 써버릴 것이며, 적어도 몇몇 요청들은 거절될 것임(SBB가 여전히 충분한 토큰들을 가질지라도)을 가정하자. 따라서, 초당 1000개 요청들의 높은 도착률 버스트들은 단지 이 예에서 대략 7 내지 8초들 동안 지속 가능할 것이다.

반대로, 버스트 B가 초당 200개의 요청들을 포함하는 시나리오를 고려하자. 매 초, PBB는 순 토큰들을 잃을 것이고 - 200이 소비될 것이며, 200은 리필될 것이다. 매 초, SBB(12000 토큰들로 시작되는)는 100개의 토큰들을 잃을 것이다: 200은 소비될 것이고, 100은 리필될 것이다. 따라서, 그것은 SBB를 소진시키기 위해 대략 12000/100 = 120 초들을 취할 것이며, 따라서 200 요청들/초의 버스트는 가정된 파라미터 설정들을 갖고 대략 120 초들 동안 지속 가능할 것이다. 따라서, 200 요청들/초의 보다 작은 버스트 레이트는 이 예시적인 시나리오에서 1000 요청들/초의 선명한 버스트보다 훨씬 더 긴 시간 동안 수용될 것이다. 실제로, 다양한 실시예들에서, 연산은, 예로서 정상-모드 버킷들이 그것들이 리필됨에 따라 작동하기 시작할 수 있고, 버스트-모드 도착률들이 가정된 대로 평평한 채로 있지 않을 수 있으며, 다른 인자들(상이한 유형들의 요청들에 대한 상이한 수들의 토큰들을 요구하는 소비 정책들과 같은)이 고려되어야 할 수 있으므로, 더 복잡해질 수 있다.

몇몇 실시예들에서, 각각의 버스트-모드 버킷들은 작업 요청들의 상이한 카테고리들을 위해 사용될 수 있다 - 예로서, 저장 또는 데이터베이스 서비스 환경에서, 하나 이상의 버스트-모드 버킷들은 판독 동작 요청들을 위해 유지될 수 있으며, 하나 이상의 버스트-모드 버킷들은 기록 동작 요청들 동안 유지될 수 있다. 프로비저닝된-용량 버킷이 사용되는 일 실시예에서, 특정 시간 간격 후 프로비저닝된-용량 버킷의 몇몇 토큰들이 사용되지 않은 채로 있다면, 사용되지 않은 토큰들은 “뱅킹(banked)”되거나 또는 하나 이상의 버스트-모드 버킷들로 논리적으로 전달될 수 있으며, 따라서 적어도 원칙적으로 클라이언트는 버스트들 동안 사용되지 않은 프로비저닝된-용량 토큰들을 이용할 수 있을 것이다. 몇몇 실시예들에서, 버스트-모드 토큰 버킷들의 세트는 하나 이상의 공유 자원들의 스루풋 용량 한계들을 고려하기 위해 사용될 수 있다. 예를 들면, 데이터베이스 테이블 파티션이 다른 테이블들의 파티션들이 또한 위치되는 공유 저장 디바이스 상에 위치된다면, 상기 설명된 바와 같이 버스트-모드 버킷들을 사용하는 것 외에, 공유-자원 용량 버킷은 공유된 저장 디바이스의 이용 가능한 스루풋 용량을 표현하기 위해 사용될 수 있으며, 작업 요청을 수용하기 위해, 토큰들은 또한 공유-자원 용량 버킷으로부터 소비될 수 있다. 몇몇 실시예들에서, 주어진 작업 요청을 수용하기 위해 소비된 토큰들의 수는 요청을 위해 요구된 작업의 추정치에 기초할 수 있으며, 초기 추정치가 부정확한 것으로 발견된다면, 토큰들은 수행된 실제 작업 양이 알려질 때 다양한 버킷들에 대해 소비(또는 부가)될 수 있다. 버스트-모드 동작들에 대한 토큰-기반 허가 제어 정책들의 이들 및 다양한 다른 양상들에 관한 세부사항들이 이하에서 제공된다.

몇몇 유형들의 저장-관련 네트워크-액세스 가능한 서비스들의 경우에, 주어진 클라이언트의 데이터 세트는 허가 제어가 몇몇 실시예들에서 토큰 버킷들의 각각의 세트들을 사용하여 독립적으로 수행되는 다수의 작업 타겟들 사이에서 분배될 수 있다. 예를 들면, 데이터베이스 서비스는 N개의 파티션들의 세트로서 큰 테이블을 조직할 수 있으며, 주어진 파티션으로 향해진 작업 요청들이 수용되는지에 대한 토큰-기반 결정들은 다른 파티션들에 대하여 독립적으로 이루어진다. 이러한 실시예들에서, 클라이언트 워크로드들의 비-균일성의 문제는 시간적 비-균일성의 차원 외에, 부가된 공간 차원을 가질 수 있다. 즉, 모든 클라이언트의 데이터에 대한 조합된 워크로드가 고려될 때, 그것은 시간에 걸쳐 비-균일하게 분배된 작업 요청들일 뿐만 아니라(즉, 몇몇 시간 기간들 동안, 작업 요청은 다른 시간 기간들 동안보다 훨씬 더 높은 레이트들로 도착한다), 작업 요청들은 또한 데이터 공간에 걸쳐 비-균일하게 분배되는(즉, 클라이언트의 데이터의 몇몇 서브세트들은 다른 것들보다 더 빈번하게 액세스되고 및/또는 업데이트된다) 경우일 수 있다. 공간 비-균일성의 몇몇 예시적인 시나리오들에서, 그것은 적어도 몇몇 시간 기간들 동안, 주어진 클라이언트(C1)에 의해 소유된 하나의 데이터 파티션(P1)에서 이용 가능한 토큰들의 수가 동일한 클라이언트(C1)에 의해 소유된 다른 데이터 파티션(P2)에서보다 훨씬 더 높지만, 작업부하는 P1에서보다 P2에서 훨씬 더 높은 경우일 수 있다. 이것은, 모든 클라이언트의 파티션들이 전체로서 고려될 때, 거절들을 회피하기 위해 이용 가능한 충분한 토큰들이 있을 수 있을지라도, 아주 많이-액세스된 파티션에서 거절되는 작업 요청들을 야기할 수 있다. 따라서, 적어도 몇몇 실시예들에서, 작업 타겟들의 그룹 중에서 토큰 공유에 대한 메커니즘이 구현될 수 있다.

토큰 공유가 구현되는 일 실시예에서, 복수의 작업 타겟들은 허가 제어를 위해 각각의 토큰 버킷들을 갖고 구성될 수 있다. 토큰 공유 프로토콜의 반복은 토큰 고유 평가 기준이 특정한 작업 타겟(WT1)에서 충족되는 결정이 이루어질 때 시작될 수 있다. 즉, WT1은 하나 이상의 다른 작업 타겟들로부터 부가적인 토큰들을 획득하려고 시도하거나, 또는 토큰들을 하나 이상의 다른 타겟들로 전달하는 것이 가치 있는지를 평가하도록 구성될 수 있다. 이러한 평가들을 개시하기 위한 상이한 기준들은 상이한 실시예들에서 사용될 수 있다 - 예로서, 몇몇 실시예들에서, 각각의 작업 타겟은 디폴트로 X초들 또는 분들마다 한 번 토큰 공유를 평가하도록 구성될 수 있으며; 다른 실시예들에서, 주어진 작업 타겟은 그것의 토큰 버킷들의 몇몇 세트에서의 토큰 카운트가 임계치 아래로 떨어지거나 또는 상이한 임계치를 넘어선다면, 또는 작업 요청들에 대한 거부율들이 임계치를 넘어선다면, 토큰 공유를 평가하도록 구성될 수 있다.

평가 프로세스의 부분으로서, 몇몇 실시예들에서, 작업 타겟(WT1)은 토큰 버킷들의 몇몇 세트에 관한 토큰 모집단 정보가 교환될 제 2 작업 타겟(WT2)을 식별할 수 있다. 예를 들면, 버스트-모드 토큰 버킷의 토큰 모집단 카운트들은 일 구현에서 WT1 및 WT2 사이에서 교환될 수 있다. 토큰 카운트들의 비교에 적어도 부분적으로 기초하여, 두 개의 작업 타겟들은 몇몇 수의 토큰들이 공유되거나 또는 전달되어야 하는지를 결정할 수 있다 - 예로서, 보다 많은 토큰들을 가진 작업 타겟은 보다 적은 토큰들을 가진 작업 타겟에서 소스 버킷으로부터 목적지 버킷으로 몇몇 토큰들을 제공하는 것에 대해 동의할 수 있다. 토큰들을 송신하기 위한 결정이 이루어진다면, 목적지 버킷의 모집단은 몇몇 수의 토큰들(Nt)만큼 증가될 수 있으며, 소스 버킷의 모집단은 Nt만큼 증가될 수 있다. 토큰들이 전달된 후, 허가 제어 결정들은 양쪽 모두 참여하는 작업 타겟들에서 새롭게 수정된 토큰 모집단들을 사용하여 이루어질 수 있다. 토큰 공유 프로토콜에서의 참여자들은 “토큰 공유 피어들(token sharing peers)”로서 칭하여질 수 있으며, 프로토콜에 참여하는 작업 타겟들의 그룹은 여기에서 “토큰 공유 그룹(token sharing group)” 또는 “토큰 공유 피어 그룹(token sharing peer group)”으로서 칭하여질 수 있다. 토큰 공유 프로토콜 단계들(예로서, 프로토콜의 평가 단계들 및 토큰 공유 단계들)은 반복적으로, 예로서 충족되는 트리거링 조건들에 기초하여, 랜덤하게 선택된 시간들에서 또는 몇몇 구현들에서 결정적 스케줄에 따라 수행될 수 있다. 상이한 작업 타겟 쌍들은 적어도 몇몇 실시예들에서 상이한 반복들에 참여할 수 있다 - 즉, 토큰 공유 피어 그룹의 작업 타겟들 모두가 프로토콜의 주어진 반복에 수반되는 것은 아닐 수 있다. 몇몇 실시예들에서, 토큰 공유 프로토콜은 토큰 공유 그룹의 작업 타겟들의 허가 제어기들에 의해 총괄하여 구현될 수 있다.

토큰-공유 그룹에서의 멤버십은 상이한 실시예들에서, 여러 개의 인자들 중 임의의 것에 기초할 수 있다. 몇몇 실시예들에서, 예를 들면, 토큰들은 단지 단일 데이터베이스 테이블의 파티션들 중에서만 공유될 수 있다. 다른 실시예들에서, 토큰들은 동일한 클라이언트에 의해, 또는 협력 클라이언트들의 몇몇 세트에 의해 소유된 테이블들의 세트의 파티션들 모두 중에서 공유될 수 있다. 이하에서 추가로 상세히 설명되는 바와 같이, 비-관계형 데이터베이스 서비스가 도출된 테이블들을 사용하여 주어진 기준 테이블에 대한 2차 인덱스들을 구현하는 일 실시예에서, 토큰 공유는 기준 테이블의 파티션들 및 도출된 테이블(들)의 파티션들 중에서 구현될 수 있다. 몇몇 실시예들에서, 클라이언트들은 토큰 공유 그룹의 멤버 작업 타겟들을 명시적으로 특정하기 위해 가능해질 수 있는 반면, 다른 실시예들에서, 클라이언트들보다는 서비스가 토큰 공유 멤버십을 결정할 수 있다. 유사하게, 토큰 공유가 사용되는 특정 유형들의 토큰 버킷들은 상이한 실시예들에서 상이할 수 있다 - 예로서, 몇몇 실시예들에서, 토큰들은 버스트-모드 토큰 버킷들 단독 중에서 작업 타겟들에 의해 공유될 수 있지만, 다른 실시예들에서, 토큰들은 또한 또는 대신에 정상-모드 버킷들 중에서 공유될 수 있다.

상이한 작업 타겟들이 각각의 프로비저닝된 스루풋 용량들을 할당받는 몇몇 실시예들에서, 상이한 클라이언트들에 속하는 테이블 파티션들과 같은, 다수의 작업 타겟들은 저장 디바이스와 같은 단일 자원을 공유할 수 있다. 공유 자원 자체는 스루풋 한계(TL)를 가질 수 있으며, 이것은 통상적으로 자원을 공유하는 작업 타겟들의 세트의 조합된 프로비저닝된 용량들(PC들)보다 더 높을 수 있다. 공유 자원을 오버로딩하는 것을 회피하기 위해, 예를 들면, 작업 타겟들에서 구현되는 네트워크-액세스 가능한 서비스는 그것들의 조합된 프로비저닝된 용량들이 작업 타겟들이 클라이언트 작업 동작들을 완료하기 위해 의지하는 공유 자원의 스루풋 한계를 초과하지 않도록 하는 방식으로 작업 타겟들을 구성할 수 있다. 이러한 시나리오에서 작업 타겟들은 “자원 공유 그룹(resource sharing group)”의 멤버들로서 칭하여질 수 있다. 각각의 이러한 작업 타겟은 하나 이상의 정상-모드 토큰 버킷들 및 하나 이상의 버스트-모드 토큰 버킷들과 같은, 연관된 세트의 토큰 버킷들을 가질 수 있다.

공유 자원에 의해 지속 가능한 최대 스루풋에 대하여, 적어도 몇몇 구현들에서, 자원 공유 그룹의 조합된 프로비저닝된 용량들에 관한 초과 용량의 버퍼가 그에 따라 유지될 수 있다. 즉, 자원 공유 그룹의 작업 타겟들 모두가 그것들의 프로비저닝된 용량에서 작업 요청들을 수신할 때조차, 공유 자원는 부가적인 부하를 핸들링할 수 있을 것이다. 몇몇 경우들에서, 예로서 자원 공유 그룹의 작업 타겟들 중 하나 이상이 그것들이 핸들링할 수 없는 높은 작업 요청 도착들의 버스트들을 경험할 때, 자원 공유 작업 타겟들에 몇몇 수의 부가적인 토큰들을 분배하는 것은 유용할 수 있다(예로서, 그것들 각각의 버킷 리필 정책들에 기초하여 작업 타겟들에 대해 이미 생성된 토큰들의 수를 넘어). 부가적인 토큰들은 공유 자원의 초과 용량 버퍼의 적어도 일 부분을 표현하기 위해 고려될 수 있다. 이러한 “초과(excess)” 토큰들은 그것들을 분배하기 위한 결정이 이루어질 때의 시간 이전에 임의의 주어진 버킷과 반드시 연관되는 것은 아닐 수 있으며: 즉 새로운 토큰들이 적어도 몇몇 실시예들에서 분배를 위해 생성될 수 있다는 것이 주의된다. 다른 실시예들에서, 공유된 자원의 스루풋 용량을 명시적으로 표현한 초과 토큰들이 버킷에 존재할 수 있다. 이러한 초과 토큰들을 분배할 때, 네트워크-액세스 가능한 서비스의 제공자는 분배 시 몇몇 레벨의 공정성을 보장하기를 원하며, 따라서, 예를 들면, 주어진 클라이언트의 작업 타겟(WT1)은 초과 토큰들 모두를 축적하도록 허용됨으로써 특수 처리를 제공받지 않는 반면, 동일한 자원을 공유하는 다른 클라이언트의 작업 타겟(WT2)은 임의의 초과 토큰들을 제공받지 않는다. 상이한 공정성-관련 인자들의 수는 초과 토큰들을 분배할 때 고려되어야 할 수 있다. 예를 들면, 일 실시예에서, 초과 토큰들은 작업 타겟들의 각각의 프로비저닝된 용량들에 기초하여, 및/또는 작업 타겟들에서 최근의 작업 요청 도착률들에 기초하여 작업 타겟들 중에서 분배될 수 있다.

상기 표시된 바와 같이, 적어도 몇몇 실시예들에 따르면, 네트워크-액세스 가능한 서비스의 작업 타겟들의 수(데이터베이스 서비스의 데이터베이스 테이블 파티션들과 같은)는 수용된 작업 요청들에 응답하여 공유 자원(공유된 저장 디바이스와 같은)를 이용하도록 구성될 수 있다. 각각의 이러한 작업 타겟은 도착한 작업 요청들의 허가 제어를 위해 설정된 각각의 세트의 토큰 버킷들을 가질 수 있으며, 즉 주어진 작업 타겟에서의 실행을 위해 작업 요청을 수용할지 또는 거절할지에 대한 결정은 상기 작업 타겟의 하나 이상의 버킷들의 토큰 모집단에 기초할 수 있다. 공유 자원와 연관된 토큰 분배기와 같은, 서비스 관리 구성요소는 몇몇 실시예들에서 토큰 분배를 반복적으로 수행하도록 구성될 수 있으며, 각각의 사이클 또는 반복은 몇몇 스케줄에 따라, 또는 몇몇 트리거링 조건들의 검출에 기초하여 개시된다. 적어도 몇몇 실시예들에서, 토큰 분배기는, 토큰 분배 프로토콜의 반복에 대응하는 주어진 시간 기간 동안, 자원 공유 작업 타겟들의 버킷들 중에서 분배될 조합된 수의 초과 토큰들을 결정할 수 있다. 조합된 수는, 예를 들면, 공유 자원의 스루풋 한계, 및 작업 타겟들의 프로비저닝된 능력들의 합 사이에서의 차이의 함수일 수 있다.

토큰들은 상이한 실시예들에서 여러 개의 인자들의 조합에 기초하여 작업 타겟들 중에서 분배될 수 있다. 몇몇 실시예들에서, 상이한 작업 타겟들에 제공된 특정 수의 토큰들은 작업 타겟들의 상대적 도착률들 및 상대적 프로비저닝된 능력들에 적어도 부분적으로 기초하여, 다른 함수로서 계산될 수 있다. 자원 공유 그룹의 각각의 작업 타겟에서 작업 요청들의 도착률들은 모니터링될 수 있으며, 각각의 연속적인 5분 간격에 걸친 평균 도착률과 같은, 시간에 걸친 도착률들의 몇몇 통계적 메트릭이 계산될 수 있다. 주어진 토큰 분배 반복에 대해, 몇몇 수의 최근의 간격들에 대한 도착률들 메트릭들은 계산을 위해 사용될 수 있다 - 예로서, 주어진 5-분 토큰 분배 반복에 대해, 이전 5-분 기간에 대한 도착률 비들이 고려될 수 있거나, 또는 마지막 K 5-분 간격들의 도착률 비들이 고려될 수 있다. 조합된 수의 토큰들은 그 후 도착률 비들에 및 프로비저닝된 용량 비들에 기초하여 작업 타겟들 중 하나 이상에 분배될 수 있다(예로서, 그것들 각각의 버스트-모드 버킷들과 같은, 작업 타겟들의 하나 이상의 버킷들의 토큰 모집단을 증가시킴으로써). 분배로부터 기인한 조정된 토큰 버킷 모집단(들)은 작업 타겟들에서 허가 제어를 위해 사용될 수 있다.

적어도 몇몇 경우들에서, 주어진 반복에 대해, 분배기는 전혀 임의의 초과 토큰들을 분배하는 것으로 결정하지 않을 수 있다는 것이 주의된다 - 예로서, 작업 타겟들의 프로비저닝된 용량들의 합이 공유 자원에 의해 지원된 피크 스루풋에 가까운 것으로 발견된다면, 또는 도착률들이 매우 낮다면. 시간에 걸쳐, 토큰 분배 메커니즘에서 도착률 메트릭들 및/또는 프로비저닝된 용량 메트릭들에 할당된 상대적 가중치들이 조정될 수 있거나, 또는 토큰 분배를 통제하는 함수들이, 예로서 얼마나 성공적으로 분배 메커니즘이 상이한 작업 타겟들에서 작업 요청 거절들을 감소시키거나 또는 회피할 때 발견되는지에 기초하여, 조정될 수 있다. 몇몇 실시예들에서, 초과 토큰들은 단지 버스트-모드 버킷들에 부가될 수 있지만, 다른 실시예들에서, 토큰들은 또한 또는 대신에 정상 모드 버킷들에 부가될 수 있다. 작업 요청 도착률들 및 프로비저닝된 용량들 외의 다른 인자들의 조합들은 몇몇 실시예들에서 초과 공유 자원 용량의 공정한 분배를 위해 사용될 수 있다. 적어도 몇몇 구현들에서, 하나 이상의 공유된 자원의 스루풋 한계들은 얼마나 많은 토큰들이 분배될지 여부를 결정할 때 고려될 수 있다.

적어도 몇몇 실시예들에서, 토큰-기반 허가 제어가 사용되는 네트워크-액세스 가능한 서비스들을 이용한 클라이언트들은 그것들이 버스트 모드 동안 수행된 동작들을 위한, 또는 미래 버스티 워크로드들을 예상하고 수행될 수 있는 동작들(토크 공유 및 초과 토큰 분배들과 같은)을 위한 것보다는 정상-모드 동작들을 위한 과금된 상이한 양들일 수 있다. 각각의 가격 책정 정책들은 몇몇 이러한 실시예들에서 정상-모드 버킷들에서 및 버스트-모드 버킷들에서 토큰 소비 및/또는 전달들과 연관될 수 있다. 몇몇 실시예들에서, 서비스의 가격 책정 관리기 구성요소는 다양한 조건들 하에서 다양한 버킷들에서의 토큰 모집단 변화들과 연관된 가격 책정 정책들을 정의하며, 허가 제어기와 협력하여(또는 그것의 일부로서) 그것을 구현할 책임이 있을 수 있다. 일 실시예에서, 특정한 토큰 버킷에 적용될 토큰 가격 책정 정책이 결정될 수 있으며(예로서, 클라이언트에 의해 가격 책정 정책의 선택에 기초하여, 또는 서비스의 내부 구성 설정들에 기초하여), 여기에서 가격 책정 정책은 그것이 적용하는 토큰 모집단 변화들의 유형들, 하나 이상의 적용 가능성 기준들(예로서, 정책이 단지 특정한 시간 윈도우들 동안에만 적용할지, 또는 정책이 단지 몇몇 버킷 모집단들이 버스트-모드 동작들 동안 특정된 임계치 아래로 떨어질 때 적용할지), 및 토큰 모집단에 대한 특정한 변화를 위해 클라이언트에 청구될 가격 책정 양을 계산하기 위해 사용될 수 있는 공식 또는 함수를 정의한다. 클라이언트들에는몇몇 실시예들에서 토큰 모집단 변화들의 상이한 카테고리들에 대한 상이한 양들이 청구될 수 있으며 - 예로서, 하나의 경우에, 클라이언트에는 특정한 버스트-모드 버킷(B1)으로부터의 임의의 토큰의 소비에 대한 하나의 레이트, 및 버킷(B2)에서 버킷(B1)으로 토큰이 전달된다면 상이한 레이트가 청구될 수 있다. 적어도 일 실시예에서, 클라이언트들은 얼마나 많은(및 어떤 유형들의) 토큰 버킷들이 허가 제어를 위해 사용되는지에 기초하여 상이한 양들이청구될 수 있으며 - 예를 들면, 복합 토큰 버킷들을 사용하여 다수의 유형들의 버스트-모드 거동을 지원하기를 원하는 클라이언트는 보다 적은 버스트-모드 버킷들을 사용하는 보다 간단한 기술을 기꺼이 사용하는 클라이언트보다 더 많이 청구될 수 있다. 가격 책정 관리기는 시간에 걸쳐, 예를 들면 버스트 모드 동작들의 다양한 기간들 동안 다양한 토큰 버킷 모집단들에 대한 변화들을 기록할 수 있다. 클라이언트 청구 양들은 기록된 모집단 변화들에 기초하여 생성될 수 있다.

적어도 일 실시예에서, 네트워크-액세스 가능한 서비스는 예로서, 클라이언트들이 버스트 동작 모드들 및/또는 정상 모드들 동안 허가 제어를 위해 사용 가능한 토큰들을 사고, 팔거나 또는 교환하기 위해 사용할 수 있는 프로그램 인터페이스들(하나 이상의 웹 페이지들, 웹 사이트들, 그래픽 사용자 인터페이스들, 명령어-라인 툴들 및/또는 API들과 같은)을 구현함으로써, 토큰 시장을 구현할 수 있다. 몇몇 이러한 시장들에서, 예를 들면, 그것들의 토큰들의 일부가 주어진 미래 시간 기간 동안 사용되지 않을 수 있음을 알고 있는 클라이언트들은 경매 메커니즘을 사용하여 입찰하기 위한 토큰들의 이용 가능성을 광고할 수 있다. 그것들이 처음에 예상한(및 그러므로 그것들의 작업 타겟의 프로비저닝된 용량보다 더 높은 워크로드들) 것보다 더 높은 워크로드들을 지원할 필요가 있을 수 있는 다른 클라이언트들은 입찰할 수 있으며, (입찰이 성공적이라면) 판매자로부터 토큰들을 구매할 수 있다. 네트워크-액세스 가능한 서비스의 가격 책정 관리기 및/또는 다른 구성요소들은 이러한 경매들 및 다른 시장 거래들을 용이하게 하고, 토큰 전달들 및 가격들을 파악하고 있으며 적어도 몇몇 실시예들에서 클라이언트들에 대해 생성된 과금 양들에 시장 거래들을 적절하게 통합할 수 있다. 가격 책정 관리기 및 연관된 구성요소들의 기능의 다양한 양상들에 관한 부가적인 세부사항들이 또한 이하에 제공된다.

예시적인 시스템 환경

도 1a는 작업 요청 도착률 변화들의 예를 예시하며, 도 1b는 적어도 몇몇 실시예들에 따라, 토큰 버킷들이 이러한 변화들의 존재 시 허가 제어 결정들을 하기 위해 사용될 수 있는 시스템을 예시한다. 도 1a에서, X-축은 시간을 나타내는 반면, Y-축은 네트워크-액세스 가능한 서비스의 저장 오브젝트 또는 데이터베이스 테이블과 같은 작업 타겟으로 향해진 작업 요청들의 도착률(110)을 나타낸다. 주어진 작업 요청은, 요청하는 클라이언트가 작업 타겟과 연관된 특정된 논리적 또는 물리적 동작들의 세트를 수행하기를 원한다고 표시한다 - 예로서, 단일 작업 요청은 작업 타겟의 일 부분 상에서 하나 이상의 판독 동작들, 하나 이상의 수정 동작들, 작업 큐로부터 계산들, 삽입들 또는 제거들의 세트, 또는 이러한 동작들의 몇몇 조합으로 변환할 수 있다. 적어도 몇몇 실시예들에서, 클라이언트는 작업 요청 시 비교적 고-레벨 논리 동작을 표시할 수 있으며, 작업 타겟을 구현한 서비스는 작업 요청이 수용된다면 수행될 필요가 있을 몇몇 대응하는 세트의 하위-레벨 물리적 또는 논리적 동작들을 결정할 책임이 있을 것이다. 도 1a 및 도 1b는 작업 타겟에서 작업 요청들의 평균 또는 통상적인 카테고리에 대한 허가 제어 및 도착률들을 예시하며; 도착률들은 일반적으로 작업 요청들의 상이한 카테고리들에 대해 개별적으로 플로팅될 수 있으며, 각각의 허가 제어 파라미터들은 이하에서 추가로 상세히 설명되는 바와 같이, 상이한 작업 요청 카테고리들을 위해 사용될 수 있다. 작업 타겟의 프로비저닝된 용량(112)(균일한 또는 평균 작업 요청들을 가정할 때)은 “pr”에서 Y-축을 교차하는 수평 선에 의해 도 1a에서 표현된다. 도착률은 도 1a와 같은 시간 간격들의 시리즈 동안(예로서, 각각의 초 동안, 도착한 작업 요청들의 수가 측정될 수 있으며 요청들/초는 그래프 상에서 플로팅될 수 있다) 모니터링될 수 있다. 도시된 바와 같이, 작업 요청들의 도착률은 시간에 걸쳐 변화한다. 몇몇 시간 기간들 동안, 도착률은 프로비저닝된 용량(pr)보다 적으며, 작업 타겟은 정상 기간들(N1, N2 및 N3)과 같은, 이들 시간 기간들 동안 정상 모드에 있는 것으로 간주된다. 도착률이 pr을 초과할 때의 기간들 동안, 작업 타겟은 버스트 기간들(B1 및 B2) 동안과 같은, 버스트 동작 모드에 있는 것으로 간주될 수 있다.

네트워크-액세스 가능한 서비스는 몇몇 실시예들에서 pr까지의 작업 요청 레이트들을 지원하기 위해 강요받을 수 있다(예로서, 서비스 레벨 협약에 의해 계약상 강요될 수 있다). 도 1b에 도시된 바와 같이, 서비스의 허가 제어기(180)는 정상 모드 동안 허가 제어 결정들을 하기 위해 하나 이상의 버킷들을 포함한 정상-모드 토큰 버킷 세트(120)를 사용하도록 구성될 수 있다. 버스트 모드들 동안, 허가 제어기(180)는 정상-모드 버킷들에 적용된 것과 다른 세트의 파라미터들을 갖고, 허가 제어를 위해 하나 이상의 다른 토큰 버킷들을 포함한, 버스트-모드 토큰 버킷 세트(125)를 이용할 수 있다. 적어도 일 실시예에서, 작업 요청(170)이 수신될 때, 허가 제어기는 먼저 정상-모드 버킷의 토큰 모집단을 결정할 수 있다. 정상-모드 버킷 토큰 모집단이 임계치 이하이면(예로서, N보다 작은, 여기에서 N개의 토큰들은 작업 요청(170)을 수용하기 위해 소비될 것이다), 허가 제어기는 작업 타겟(102)이 버스트 모드에 있거나 또는 작업 타겟(102)이 작업 요청(170)이 실행을 위해 수용된다면 버스트 모드에 들어갈 것이라고 결론을 내릴 수 있다.

버스트-모드 파라미터들이 적용할 것이라고 결정할 때, 예로서 정상-모드 버킷 세트를 사용할 때, 허가 제어기(180)는 묘사된 실시예에서 버스트-모드 토큰 버킷 세트(125)의 적어도 하나의 버킷의 토큰 모집단들을 결정할 수 있다. 모집단이 특정한 기준을 충족시킨다면, 예로서 N개의 토큰들이 적어도 하나의 버스트-모드 토큰 버킷 내에서 이용 가능하다면, 작업 요청(170)은 실행을 위해 수용될 수 있으며, 수용된 작업 요청에 대응하는 하나 이상의 동작들(179)이 개시될 수 있다. 버스트-모드 버킷 세트(125)의 토큰 모집단이 특정한 기준을 충족시키지 않는다면, 189로 라벨링된 화살표에 의해 표시된 바와 같이, 작업 요청(170)은 거절될 수 있다. 다양한 실시예들에서, 파라미터들 및 정책들의 각각의 세트는 정상-모드 버킷 세트(120) 및 버스트-모드 버킷 세트(125)의 각각의 토큰 버킷에 적용할 수 있다 - 예를 들면, 상이한 버킷들이 상이한 토큰 소비 정책들(얼마나 많은 토큰들이 다양한 상황들 하에서 소비되는지를 표시한) 및 상이한 토큰 리필 정책들(토큰들이 부가되는 상황들 및 한 번에 부가될 수를 표시한)을 가질 수 있다. 일반적으로, 묘사된 실시예에서, 서비스 및 허가 제어기(180)는 정상 모드 동작들을 지원하도록 강요될 수 있으며, 버스트 모드 동작들 동안 클라이언트의 요청들을 수용하며 완료하기 위해 최선의 노력을 한다.

허가 제어를 위해 토큰 버킷들을 이용하는, 상기 설명된 것들과 같은 기술들은 작업 타겟들이 반드시 정의된 각각의 프로비저닝된 스루풋 용량들을 갖는 것은 아니며, 예로서 서비스 레벨 협약들이 몇몇 또는 모든 작업 타겟들에 대한 몇몇 명시적으로-특정된 스루풋 레벨을 지원하도록 서비스 제공자에 강요하지 않는 몇몇 실시예에서 사용될 수 있다는 것이 주의된다. 예를 들면, 일 실시예에서, 서비스 제공자는 작업 요청 도착률이 초당 R개의 동작들을 초과할 때마다 발생한 것으로서 버스트 모드를 간단히 정의할 수 있으며, 이러한 조건들 하에서 허가 제어를 위해 버스트-모드 토큰 버킷들을 사용할 수 있다. 따라서, 상이한 실시예들에서, 작업 타겟이 버스트 모드에 있는지 여부를 결정하기 위해 취해진 접근법은 상이할 수 있으며; 몇몇 경우들에서, 프로비저닝된 스루풋 용량은 정상 모드 및 버스트 모드 사이에서의 경계를 정의할 수 있는 반면, 다른 실시예들에서, 버스트 모드의 다른 정의들이 사용될 수 있다.

토큰-기반 허가 제어의 개요

도 2는 적어도 몇몇 실시예들에 따라, 토큰 기반 허가 제어 메커니즘의 고-레벨 개요를 제공한다. 토큰들의 단일 버킷(202)을 사용하는 메커니즘은 프리젠테이션의 단순성을 위해 예시되며; 상기 주지된 바와 같이, 정상-모드 허가 제어를 위한 하나 이상의 버킷들, 및 버스트-모드 허가 제어를 위한 하나 이상의 버킷들과 같은, 다수의 버킷들의 조합들이 몇몇 실시예들에서 사용될 수 있다. 메커니즘에 따르면, 데이터 오브젝트, 오브젝트 파티션, 또는 파티션 레플리카와 같은, 특정한 작업 타겟(102)과 연관된 허가 제어 목적들을 위해 설정된 버킷(202)(예로서, 적어도 몇몇 실시예들에서 소프트웨어 프로그램 내에서 데이터 구조로서 구현될 수 있는 논리 컨테이너)은 화살표(204A)를 통해 표시된 바와 같이, 버킷 초기화 동안 토큰들(208)의 초기 세트로 이루어질 수 있다. 초기 모집단은 예로서, 워크로드의 예상들, 서비스 레벨 협약들, 대응하는 데이터 오브젝트를 소유하거나 또는 관리하는 클라이언트에 의해 특정된 프로비저닝 예산, 또는 다양한 실시예들에서 이러한 인자들의 몇몇 조합에 기초하여 결정될 수 있다. 몇몇 유형들의 버킷들에 대해, 초기 모집단은 몇몇 실시예들에서 0으로 설정될 수 있다. 몇몇 구현들에서, 적어도 하나의 버킷의 초기 모집단은 버킷이 구성되는 최대 모집단으로 설정될 수 있다.

새로운 작업 요청(170)(저장 오브젝트 또는 데이터베이스 오브젝트의 경우에 판독 요청 또는 기록 요청과 같은)의 표시가 허가 제어기(180)에서 수신될 때, 허가 제어기는 몇몇 수 N의 토큰들(여기에서 N은 구현에 또는 구성 파라미터들에 의존하여, 1 이상일 수 있다)이 묘사된 실시예에서 버킷(202)에 존재하는지를 결정하려고 시도할 수 있다. 상기 수의 토큰들이 버킷에서 이용 가능하다면, 작업 요청(170)은 실행을 위해 수용되거나 또는 허가될 수 있으며, 토큰들은 소비되거나 또는 버킷(화살표(210))으로부터 제거될 수 있다. 그렇지 않다면, N개의 토큰들이 존재하지 않는다면, 작업 요청(170)이 거절될 수 있다. 예시된 예에서, 작업 요청(170A)이 수용되었고, 작업 요청(170B)이 거절되었으며, 작업 요청들(170C, 170D 및 170E)은 허가 제어기(180)에 의해 아직 고려되지 않고 있다.

204B로 라벨링된 화살표에 의해 도시된 바와 같이, 버킷(202)은 또한 도 3을 참조하여 이하에 설명되는 바와 같이, 예로서 버킷과 연관된 리필 레이트와 같은 구성 파라미터들에 기초하여, 시간에 걸쳐 리필되거나 또는 재실장될 수 있다. 몇몇 구현들에서, 토큰 리필 동작들은 소비 동작들을 동반하거나, 또는 시간적으로 근접하여 수행될 수 있고 - 예로서, 단일 소프트웨어 루틴 내에서, N개의 토큰들은 요청을 허가하기 위해 소비될 수 있으며, M개의 토큰들은 버킷이 마지막에 리필된 이래 리필 레이트 및 시간에 기초하여 부가될 수 있다. 몇몇 버킷들은, 또한 이하에 설명되는 바와 같이, 몇몇 시나리오들에 다른 버킷들에서 사용되지 않은 토큰들의 수에 기초하여 실장될 수 있다. 한계들은 예로서 구성 파라미터들을 사용하여, 몇몇 실시예들에서 버킷이 유지할 수 있는 최대 수의 토큰들에, 및/또는 최소 수의 토큰들에 두어질 수 있다. 구성 파라미터 설정들의 다양한 조합들을 사용하여, 매우 정교한 허가 제어 기법들이, 특히 다수의 버킷들이 주어진 오브젝트 또는 자원에 대한 허가들을 제어하기 위해 함께 사용될 때, 상이한 실시예들에서 구현될 수 있다.

하나의 간단한 예시적인 시나리오에서, 초당 100개의 작업 요청들의 불변 부하를 지원하기 위해, 도 2의 버킷(202)은 100개의 토큰들의 초기 모집단, 100개의 토큰들의 최대 허용 가능한 모집단 및 0개의 토큰들의 최소치를 갖고 구성될 수 있고; N은 1로 설정될 수 있고, 리필 레이트는 초당 100개의 토큰들로 설정될 수 있으며, 1개의 토큰은 10밀리초마다 한 번 리필 목적들을 위해 부가될 수 있다(최대 모집단 한계가 초과되지 않는다고 가정할 때). 작업 요청들(170)이 도착함에 따라, 하나의 토큰이 각각의 작업 요청을 위해 소비될 수 있다. 각각의 초 동안 균일하게 분배된, 초당 100개의 작업 요청들에서의 정상 상태 작업부하가 인가된다면, 리필 레이트 및 작업부하 도착률은 서로 균형을 이룰 수 있다. 이러한 정상-상태 워크로드는, 상기 열거된 버킷 파라미터들을 고려해볼 때, 몇몇 실시예들에서 무한정 지속될 수 있다.

상기 예를 연장하면, 도착률 및/또는 리필 레이트가 균일하지 않다면, 버킷(202)이 몇몇(통상적으로 작은) 시간 간격들 동안 비어있는 채로 있는(예로서, 거푸거푸 작업 요청들의 몇몇 세트가 리필 메커니즘이 교체할 수 있는 것보다 더 많은 토큰들을 소비할 수 있다면) 시나리오들이 발생할 수 있다. 이러한 경우에서, 단지 단일 버킷(202)만이 허가 제어를 위해 사용된다면, 도착한 작업 요청은 거절될 수 있다(또는 지연 후 재시도될 수 있다). 워크로드들의 시간적 비-균일성을 다루기 위해, 도 1b를 참조하여 설명된 바와 같이 부가적인 버스트-모드 토큰 버킷들의 사용과 같은, 다양한 기술들이 상이한 실시예들에서 이용될 수 있다.

도 3은 버킷(202)과 같은 토큰 버킷의 예시적인 구성 속성들(302)을 예시하며, 이것은 적어도 몇몇 실시예들에 따라, 다양한 유형들의 허가 제어 정책들을 구현하기 위해 사용될 수 있다. 몇몇 구현들에서, 토큰 버킷은 허가 제어기(180)의 메모리-내 데이터 구조로서 구현될 수 있으며, 필요에 따라 영구 저장 장치로 기록될 수 있다. 이러한 데이터 구조는 모집단이 마지막으로 수정될 때, 현재 토큰 모집단을 표현한 필드들, 및/또는 도 3에 표시된 다양한 파라미터들 및 정책들에 대한 값들을 포함할 수 있다.

토큰 소비 정책(310)은 토큰들이 어떻게 허가 제어를 위해 소비되는지를 표시할 수 있다. 몇몇 실시예들에서, 소비 정책(310)은 상이한 허가-전 정책들 및 허가-후 정책들을 포함할 수 있으며, 및/또는 작업 타겟의 동작의 모드 또는 다른 버킷들의 상태에 의존적일 수 있다. 예를 들면, 일 실시예에서, 두 개의 버킷들은 주어진 작업 타겟에 대한 허가 제어를 위해 사용될 수 있다: 프로비저닝된-용량 버킷(PB)(예로서, 정상-모드 버킷 세트(120)에서) 및 버스트-모드 버킷(BB)(예로서, 버스트-모드 버킷 세트(125)에서). 이 예에서 시행 중인 허가-전 정책에 따르면, 새로운 요청을 허가하기 위해, PB의 모집단은 적어도 하나의 토큰이 존재하는지를 결정하기 위해 확인될 수 있으며, 허가-후 정책에 따르면, 요청이 허가된다면, PB의 모집단은 1만큼 감소될 수 있다. PB가 토큰을 갖는다면, BB의 모집단은 요청을 허가하기 전에 확인될 필요가 없을 수 있다. 그러나, 몇몇 실시예들에서 시행 중인 허가-후 정책에 따르면, BB로부터의 하나의 토큰은 그럼에도 불구하고 요청이 수용된다면 소비될 수 있다. 반대로, 예를 계속하면, PB가 임의의 토큰들을 갖지 않는다면, 작업 타겟은 버스트 모드에 있는 것으로 간주될 수 있으며, BB의 모집단은 BB가 적어도 하나의 토큰을 갖는지를 결정하기 위해 확인될 수 있다. 버스트 모드에서, 요청은 BB가 이용 가능한 토큰을 갖는 경우에만 허가될 수 있으며, 요청이 허가된다면, 토큰은 BB로부터 소비될 수 있다. (몇몇 구현들에서, 버스트 모드에서, PB의 토큰 모집단은 또한 요청 허가 시 감소될 수 있어서, 잠재적으로 PB의 모집단을 마이너스로 만든다.) 몇몇 실시예들에서, 상이한 수들의 토큰들이 그것의 소비 정책에 기초하여 주어진 버킷으로부터 상이한 유형들의 동작들에 대해 소비될 수 있다. 몇몇 실시예들에서, 토큰 소비 정책은 또한 (어떤 레이트로) 토큰들이 대응하는 데이터 오브젝트가 잠시 동안 작업 요청들에 대해 타겟팅되지 않는다면 버킷으로부터 삭제될지를 표시한 유휴-동안-쇠퇴(decay-during-idle) 파라미터, 또는 토큰들이 그것들이 몇몇 시간 간격 동안 사용되지 않는다면 하나의 버킷에서 다른 것으로 전달되어야 하는지를 표시한 유휴 시 전달(transfer-upon-idle) 파라미터를 특정할 수 있다. 일 실시예에서, 시효경과 정책(staleness policy)이 특정된 시간 간격 동안 소비되지 않은 토큰들을 소비하기 위해 사용될 수 있다 - 예로서, 각각의 토큰은 토큰이 허가 제어 목적들을 위해 더 이상 유용하지 않은 유효성 수명과 연관될 수 있다. 버킷의 주어진 카테고리에 적용 가능한 토큰 정책들(및 이하에 설명된 것들과 같은 다양한 다른 정책들)은 여기에서 카테고리에 기초한 명칭에 의해 식별될 수 있다 - 예로서, 정상-모드 버킷에 적용 가능한 소비 정책은 정상-모드 소비 정책으로서 불리울 수 있는 반면, 버스트-모드 버킷에 적용 가능한 소비 정책은 버스트-모드 소비 정책으로서 불리울 수 있다.

속성들(302)은 묘사된 실시예에서 초기 토큰 모집단 파라미터(306)를 포함할 수 있으며, 이것은 개시 또는 초기화 시 얼마나 많은 토큰들이 버킷에 위치될지를 표시한다. 토큰 리필 정책 파라미터(314)는 예로서 버킷과 연관된 작업 타겟이 구성되는 작업의 레이트를 유지하도록 돕기 위해, 어떤 레이트로, 및/또는 어떤 상황들 하에서, 토큰들이 버킷에 부가되는지를 표시할 수 있다. 몇몇 실시예들에서, 버킷의 파라미터들 중 하나 이상은 시간에 걸쳐 변경될 수 있으며 - 예로서, 디폴트 리필 레이트는 버킷에 적용할 수 있지만, 특정한 조건들 하에서, 비-디폴트 레이트가 사용될 수 있다. 최대 모집단 파라미터(318)는 버킷의 최대 용량을 표시할 수 있는 반면, 최소 모집단 파라미터(322)는 버킷의 모집단에 대한 하한계를 표시할 수 있다. 몇몇 구현들에서, 버킷의 모집단은 몇몇 상황들 하에서 마이너스(negative)가 되는 것으로 간주될 수 있다(예로서, 최소 모집단은 0보다 작을 수 있다). 예를 들면, 작업 타겟이 판독들 및 기록들과 같은 I/O 동작들을 지원하는 일 실시예에서, 허가 제어기(180)는 단순성을 위해, 인입하는 클라이언트 요청들이 각각 대략 하나의 실제 I/O 동작을 야기할 것임을 가정하거나 또는 추정할 수 있다. 그러나, 동작 요청(R)이 수용된 후, 몇몇 경우들에서 R을 허가한 결과로서 요구된 실제 작업 양은 가정된 하나의 I/O보다 상당히 더 클 수 있으며: 예를 들면, 하나의 판독에 의해 이행될 것으로 예상된 판독 요청은 결국 1000개의 판독들을 요구하는 테이블의 스캔으로 끝날 수 있다. 이러한 시나리오들에서, 예상되지 않은 추가 작업의 영향은 후속 허가 제어 결정들에 반영된다는 것을 보장하기 위해, 추가 작업에 대응하는 토큰들의 수(예로서, 1000-1 = 999 토큰들)는 버킷으로부터 공제될 수 있으며, 이것은 적어도 일시적으로 토큰 카운트가 마이너스가 되게 할 수 있다. 토큰 카운트는 결국, 예로서 버킷의 리필 레이트들 및 인입하는 요청 레이트들에 기초하여, 양의 영토에 다시 들어갈 수 있다. 토큰 결손 정책 파라미터(324)는 어떤 토큰 결손들(또는 음의 모집단들)이 허용되는지, 얼마나 긴 결손들이 남아있도록 허용되는지, 어떤 동작들이 결손으로부터 회복하기 위해 취해져야 하는지 등의 조건들에 대한 규칙들을 특정할 수 있다. 몇몇 실시예들에서, 상이한 유형들의 동작들은 상이한 허가 제어 규칙들을 가질 수 있으며, 버킷이 사용될 동작들의 유형들은 적용 가능한 동작 유형들 파라미터(326)에서 특정될 수 있다. 적어도 몇몇 실시예들에서, 클라이언트가 버킷의 토큰들의 사용을 위해 청구될 양들을 결정하기 위해 사용될 수 있는 하나 이상의 가격 책정 정책들(328)은 버킷 속성들에서 표시될 수 있다. 가격 책정 정책들(328)이 포함할 수 있는 요소들의 종료들의 예들이 도 17에 예시되며 이하에서 추가로 상세히 설명된다. 상이한 실시예들에서, 단지 도 3에 도시된 예시적인 파라미터들의 서브세트만이 이용될 수 있는 반면, 다른 실시예들에서, 도 3에 도시된 것들을 넘어 부가적인 버킷 구성 파라미터들이 사용될 수 있다. 도 3에 도시된 다양한 속성들에 대한 값들 및/또는 설정들, 뿐만 아니라 버스트 모드 동작이 지원되는지와 같은 다른 허가 제어 설정들은 적어도 몇몇 실시예들에서 프로그램적으로 설정되거나 또는 수정될 수 있다(예로서, 웹 서비스 호출들을 사용하여).

사용되지 않은 토큰들을 뱅킹

몇몇 실시예들에서, 적용 가능한 리필 레이트에 따르면, 주어진 토큰 버킷은 주기적으로 또는 작업 요청에 응답하여 허가 제어 결정의 완료 또는 개시와 같은 트리거링 이벤트들에 응답하여 토큰들로 다시 채워질 수 있다(즉, 토큰들이 버킷에 부가될 수 있다). 이러한 실시예에서, 정상-모드 토큰 버킷이 예로서, 평균하여 이전 시간 간격 동안, 작업 요청들이 프로비저닝된 용량보다 적은 레이트로 도착하였기 때문에, 그것이 다시 채워지는 시간에서 몇몇 사용되지 않은 토큰들을 포함하는 것이 그 경우일 수 있다. 일 실시예에서, 하나 이상의 버킷들로부터 사용되지 않은 토큰들은 예로서, 버스트들 동안 나중에 잠재적인 사용을 위해, 하나 이상의 다른 토큰 버킷들에서 뱅킹되거나 또는 축적될 수 있다. 도 4는 적어도 몇몇 실시예들에 따라, 프로비저닝된 용량 버킷에서 버스트 버킷으로 사용되지 않은 토큰들의 축적의 예를 예시한다.

도 4에 묘사된 실시예에서, 정상-모드 버킷 세트(120)는 최대 토큰 모집단(M)을 갖고 구성된, 프로비저닝된-용량 버킷(420)을 포함하는 반면, 버스트-모드 토큰 버킷 세트(125)는, M 이상인 최대 토큰 모집단(B)을 갖고, 버스트-모드 버킷(422)을 포함한다. 화살표(452)에 의해 도시된 바와 같이, 프로비저닝된-용량 버킷(420)은 최대(M)을 조건으로 하는, 프로비저닝된 용량(pr)과 같은 레이트로 다시 채워진다. 따라서, 예를 들면, pr이 100 ops/sec이고, M=100이며, 리필 동작들이 초당 한 번 수행된다면, 최대 100개의 토큰들이 초마다 버킷(420)에 부가될 수 있다. 화살표(454)에 의해 표시된 바와 같이, 토큰들은 수신된 작업부하 요청들에 기초한 레이트로 버킷(420)으로부터 소비될 수 있다. 두 개의 시간 포인트들(T1 및 T2)을 고려하자, 여기에서 T2는 T1의 1초 후이다. T1에서, 버킷(420)은 100개의 토큰들을 포함하며, 다음 초 동안, 이들 토큰들 중 75개가 인입하는 작업 요청들(170)과 연관된 허가 제어 동작들을 위해 소비되었다고 가정하자. T2에서, 버킷(420)은 이러한 예시적인 시나리오에서 여전히 25개의 사용되지 않은 토큰들을 포함한다.

화살표(460)에 의해 표시된 바와 같이, 이러한 사용되지 않은 토큰들은 묘사된 실시예에서 버스트-모드 버킷(422)에 축적될 수 있다. 따라서, 예를 계속하면, 25개의 토큰들이 T2에서 버킷(422)에 부가될 수 있다. 또한, 묘사된 실시예에서, 토큰들은 그것의 리필 레이트(최대 모집단 한계(B)를 조건으로 하는)로 버킷(422)에 부가될 수 있으며, 이것은 또한 화살표(456)에 의해 표시된 바와 같이, 프로비저닝 레이트(pr)의 함수일 수 있다. 버스트 모드 동작들 동안, 토큰들은 작업 요청들의 도착률에 의존한 레이트로 버킷(422)으로부터 소비될 수 있다. 도 4의 화살표(458)에 의해 표시된 바와 같이, 적어도 몇몇 실시예들에서, 토큰들은 동작의 모드에 관계없이 작업 요청들의 도착률들에 기초하여 버킷(422)으로부터 소비될 수 있다 - 예로서, 작업 요청이 실행을 위해 수용될 때마다, 몇몇 수의 토큰들은 정상-모드 버킷(420)으로부터 소비될 수 있으며, 몇몇 수의 토큰들은 버스트-모드 버킷(422)으로부터 소비될 수 있다. 몇몇 실시예들에서, 도착률에 관계없이, 및 다른 허가 제어 설정들에 관계없이, 작업 요청들은 작업 타겟을 위해 사용된 컴퓨팅 디바이스들의 하드웨어 및/또는 소프트웨어 한계들에 기초할 수 있는 미리 결정된 최대-지속 가능한 레이트보다 높은 레이트에서 수용되지 않을 수 있다는 것이 주의된다. 이러한 최대 한계는 예를 들면, 디바이스들이 그것들의 능력들을 넘어 스트레스를 받는다면 컴퓨팅 디바이스들 상에서의 데이터가 변질되는 것으로부터 보호하기 위해 설정될 수 있다.

도 4에 묘사된 실시예에서, 버스트-모드 버킷(422)의 모집단은 점점 더 많은 토큰들이 버킷(420)에서 사용되지 않음에 따라 시간에 걸쳐 증가한다(최대 모집단 한계(B) 및 허가된 작업 요청들에 대한 버스트-모드 토큰들의 소비를 조건으로 하는). 이것은 허가 제어기(180)로 하여금 단지 버킷(422) 자신의 리필 레이트가 버킷(422)의 모집단에 기여한다면 가능할 수 있는 것보다 큰 버스트들을 다룰 수 있게 할 수 있다. 나중 사용을 위해 사용되지 않은 토큰들을 뱅킹하는 이러한 기술은, 클라이언트들이 버킷들 사이에서 사용되지 않은 토큰들을 논리적으로 전달함으로써 전체 비용들을 감소시킬 수 있을 것이므로, 클라이언트들이 프로비저닝된 용량에 대해서뿐만 아니라 버스트-모드 동작들에 대해 청구되는 실시예들에서 특히 도움이 될 수 있다. 몇몇 실시예들에서, 사용되지 않은 토큰들의 유사한 종류들의 전달들은 또한 다른 소스 및 목적지 버킷 쌍들 중에서 지원될 수 있다 - 예로서 별개의 토큰 버킷들이 작업 요청들의 각각의 카테고리들에 대해 유지될 수 있으며, 특정한 카테고리(C1)에 대한 버킷으로부터의 사용되지 않은 토큰들은 상이한 카테고리(C2)에 대한 버킷으로 전달될 수 있다.

특정 유형들의 동작들에 대한 토큰 버킷들

몇몇 실시예들에서, 주어진 작업 타겟은 동작들의 상이한 카테고리들에 대한 작업 요청들을 지원할 수 있다. 예를 들면, 데이터베이스 테이블은 일 실시예에서 판독 및 기록 동작들을 지원할 수 있다. 용어들(“기록 동작(write operation)” 또는 “기록”)은 예로서 생성들(새로운 또는 부가적인 데이터를 기록하는 것), 업데이트들(제자리 겹쳐쓰기를 수반할 수 있는 기존의 데이터에 대한 변화들, 또는 예로서 몇몇 한 번 기록 가능한 환경들에서, 새로운 버전의 데이터의 생성), 삭제들, 재명명들, 및/또는 이동들을 포함하여, 데이터베이스 테이블, 파일, 또는 볼륨과 같은 오브젝트들의 데이터 및/또는 메타데이터가 수정되는 동작들을 나타낼 수 있다. 용어들(“판독 동작들(read operations)” 또는 “판독들”)은 수정들을 수반하지 않는 동작들을 나타낼 수 있다. 기록 요청에 응답하기 위해 요구된 작업의 총 양은 판독 요청에 응답하기 위해 요구된 작업의 양과 상이할 수 있다: 예를 들면, 몇몇 실시예들에서, 주어진 데이터베이스 테이블 또는 테이블 파티션의 다수의 복제본들이 유지될 수 있으며, 기록은 완료된 것으로 고려될 기록 작업 요청에 대한 하나 이상의 복제본에서 완료되어야 할 수 있는 반면, 판독 요청은 단지 단일 복제본을 액세스하는 것을 요구할 수 있다. 몇몇 구현들에서, 기록 동작들은 로깅되어야 할 수 있거나, 또는 판독 동작들을 위해 요구되지 않을 수 있는, 인덱스 수정과 같은, 다른 부작용들을 가질 수 있다. 그 결과, 주어진 작업 타겟에서 판독들에 대한 스루풋 용량은 기록들을 위한 스루풋 용량과 상이할 수 있다. 결과적으로, 판독들 및 기록들은 허가 제어 결정들에 대하여 상이하게 처리될 수 있다. 도 5는 적어도 몇몇 실시예들에 따라, 판독들 및 기록들에 대한 허가 제어를 위해 각각의 토큰 버킷들의 사용을 예시한다.

도시된 바와 같이, 정상-모드 버킷 세트(120)는 묘사된 실시예에서 판독 프로비저닝된-용량 버킷(502) 및 별개의 기록 프로비저닝된-용량 버킷(504)을 포함한다. 버스트-모드 버킷 세트(125)는 판독 버스트 버킷(506) 및 기록 버스트 버킷(508)을 포함한다. 기록 요청이 도착할 때, 허가 제어기는 작업 요청이 판독 또는 기록을 위한 것인지를 결정할 수 있으며, (a) 작업 요청을 수용하는 것이 정상 모드 동작 또는 버스트 모드 동작을 야기할지 및 (b) 충분한 토큰들이 작업 요청을 수용하기 위해 적절한 버킷들에서의 소비를 위해 이용 가능한지를 결정하기 위해 대응하는 유형의 버킷의 토큰 모집단들을 사용할 수 있다. 판독 버킷들에서 토큰들의 소비 및/또는 리필은 묘사된 실시예에서 기록 버킷들에서의 토큰들의 소비 및/또는 리필에 독립적일 수 있으며, 도 3에 묘사된 속성들 및 정책들의 일부 또는 모두는 각각의 유형의 버킷에 대해 독립적으로 설정될 수 있다. 따라서, 그것은 주어진 시간 포인트에서, 작업 타겟은 판독들에 대하여 정상 모드에 있지만, 기록들에 대하여 버스트 모드에 있으며, 그 역 또한 마찬가지(즉, 기록들에 대하여 정상 모드에 있으며, 판독들에 대하여 버스트 모드에 있는)인 경우일 수 있다. 작업 타겟은 또한 판독들 및 기록들 양쪽 모두에 대하여 정상 모드에, 또는 판독들 및 기록들 양쪽 모두에 대하여 버스트 모드에 있을 수 있다. 몇몇 실시예들에서, 사용되지 않은 토큰들은 판독 버킷으로부터 기록 버킷으로, 또는 그 반대로 전달될 수 있는데 - 도 5에 묘사된 실시예에서, 예를 들면, 몇몇 토큰들이 시간 간격의 끝에서 기록 버스트 버킷(508)에서 사용되지 않은 채로 있다면, 대응하는 수의 토큰들은 판독 버스트 버킷의 모집단이 임계치 아래로 떨어진다면 판독 버스트 버킷(506)에 부가될 수 있다.

공유된 자원들 및 복제 관리

도 4 및 도 5에 예시된 종류들의 버스트-모드 토큰 버킷들의 각각의 세트들은 몇몇 실시예들에서 각각의 작업 타겟에 대해 수립될 수 있다. 적어도 몇몇 실시예들에서, 데이터베이스 테이블 또는 테이블 파티션과 같은 주어진 작업 타겟은 다른 작업 타겟들에 의해 공유되는 적어도 몇몇 자원들을 이용할 수 있다 - 예를 들면, 테이블의 일 부분(테이블 1)은 테이블의 일 부분(테이블 2)과 동일한 저장 디바이스 상에 위치될 수 있다. 허가 제어 결정들을 할 때, 작업 타겟을 구현한 네트워크-액세스 가능한 서비스는 또한 공유된 자원의 능력들을 고려해야 할 수 있다. 예를 들면, 일 구현에서, 주어진 저장 디바이스는 초당 단지 N개의 판독 동작들을 지원할 수 있을 것이며, 상기 저장 디바이스가 두 개의 상이한 작업 타겟들(WT1 및 WT2)을 위해 사용된다면, 하나의 타겟(WT1)의 이용 가능한 판독 스루풋 용량은 다른 타겟(WT2)에서 판독 워크로드에 의해 영향을 받을 수 있다. 몇몇 실시예들에서, 그 토큰 모집단이 다수의 작업 타겟들 중에서 공유된 자원의 이용 가능한 스루풋 용량을 표현하는 공유-자원 버킷은 작업 타겟들의 각각에서 버스트-모드 허가 제어 결정들을 위해 사용될 수 있다. 이하에 설명된 바와 같이, 작업 타겟들의 다수의 복제들이 유지되는 실시예들에서 특정한 유형들의 작업 요청들(기록 동작들을 야기하는 요청들과 같은)에 대해, 복제 관리와 연관된 하나 이상의 버킷들이 또한 사용될 수 있다. 복제 관리 버킷들은 몇몇 실시예들에서 몇몇 유형들의 작업 요청들의 허가 제어를 위해서만 사용될 수 있다 - 예로서, 이러한 실시예들에서, 그것들은 기록들을 위해 사용될 수 있지만, 판독들을 위해서는 사용될 수 없다. 도 6은 적어도 몇몇 실시예들에 따라, 하나 이상의 로컬-버스트-제한 버킷들(604), 하나 이상의 공유-자원 용량 버킷들(606), 및 하나 이상의 복제-관리 버킷들(608)을 포함한 버스트-모드 토큰 버킷 세트를 예시한다.

도 6에 도시된 3개의 유형들의 버스트-모드 토큰 버킷들은 예로서, 각각의 유형의 버킷이 이용 가능한 토큰들에 대해 순차적으로 확인되는, 허가 제어, 및 모든 관련 있는 버킷들이 그것들 각각의 토큰 소비 정책들에 따라 충분한 토큰들을 포함하는 경우에만 수용되는 작업 요청들(170)을 위해 총괄하여 사용될 수 있다. 상이한 토큰 버킷들이 허가 제어를 위해 확인되는 순서는 상이한 실시예들에서 달라질 수 있다. 로컬-버스트-제한 버킷들(604)은 분리 시 고려되는 작업 타겟의 이용 가능한 스루풋 용량을 표현한, 예로서 공유 자원들의 스루풋 한계들을 무시하며, 복제를 무시한, 토큰들을 포함할 수 있다. 일 실시예에서, 로컬-버스트-제한 버킷(들)(604)의 모집단은 먼저 작업 요청이 수신될 때 확인될 수 있다. 로컬-버스트-제한 버킷들이 충분한 토큰들을 포함한다면, 공유-자원 용량 버킷들(606)이 다음에 확인될 수 있다. 충분한 토큰들이 공유-자원 용량 버킷들에서 발견된다면 및 작업 요청에 대응하는 것이 데이터 복제를 요구한다며, 복제-관리 버킷들(608)은 다음에 확인될 수 있다. 묘사된 실시예에서, 확인된 버킷들 모두가 충분한 토큰들을 포함한다면, 작업 요청이 수용될 수 있다. 확인된 버킷들 중 임의의 것이 충분한 토큰들을 포함하지 않는다면, 작업 요청은 거절되고, 지연되거나, 또는 재시도될 수 있다.

로컬-버스트-제한 버킷들(604)이 불충분한 토큰들을 포함하며 예시된 다른 유형들의 버킷들 이전에 확인되는 시나리오에서, 작업 요청은 공유-자원 용량 버킷들(606) 및/또는 복제-관리 버킷들(608)이 그것들 각각의 소비 정책들에 기초하여 요청을 수용하기에 충분한 토큰들을 포함할지라도 거절될 수 있다. 몇몇 실시예들에서, 각각의 로컬-버스트-제한 버킷(604)은 판독 요청들 및 기록 요청들을 위해 유지될 수 있으며, 및/또는 각각의 공유-자원 버킷(606)은 판독 요청들 및 기록 요청들을 위해 유지될 수 있다.

몇몇 실시예들에서, 여러 개의 상이한 유형들의 공유 자원들은 허가 제어 동안, 예로서 공유-자원 버킷들의 각각의 인스턴스들을 사용하여 고려될 수 있다. 예를 들면, 일 실시예에서, 판독 동작들을 수행하기 위해 요구된 제한된 수의 메모리 버퍼들은 작업 타겟이 구현되는 서버에서 이용 가능할 수 있으며, 공유-자원 용량 버킷(606)은 이용 가능한 메모리 버퍼들을 표현하기 위해 수립될 수 있다. 유사하게, 다른 실시예에서, 데이터 구조의 유형(그것의 제한된 수가 작업 타겟을 위한 사용 시 주어진 운영 시스템 인스턴스에서 이용 가능할 수 있는, 파일 디스크립터와 같은)은 각각의 작업 동작을 위해 사용될 수 있으며, 상이한 공유-자원 용량 버킷(606)은 이용 가능한 파일 디스크립터들을 표현하기 위해 수립될 수 있다. 몇몇 실시예들에서, 하나 이상의 공유 자원들의 과잉 스루풋 용량을 표현한 토큰들(자원들을 공유한 작업 타겟들의 프로비저닝된 용량들의 합에 대하여)은, 이하에서 추가로 상세히 설명되는 바와 같이, 반복적 접근법을 사용하여 공평한 방식으로 작업 타겟들 중에서 분배될 수 있다.

일 실시예에 따르면, 작업 타겟의 콘텐트들(데이터베이스 테이블, 파일 또는 저장 볼륨과 같은)은 서비스에 의해 하나 이상의 논리 파티션들 중에서 분배될 수 있다. 예를 들면, 데이터베이스 서비스의 클라이언트는 테이블이 대략 X 테라바이트들(TB)의 데이터를 유지하기 위한 것이며 초당 Y개의 판독 또는 기록 동작들의 작업부하를 지원하는 것으로 예상된다는 것을 특정할 수 있으며, 데이터베이스 서비스는 P개의 논리 파티션들을 가진 테이블을 셋 업하기록 결정할 수 있으며, 충분한 자원들은 처음에 X/P TB를 저장하며 각각 Y/P 동작들의 프로비저닝된 용량 한계를 지원하기 위해 논리 파티션들의 각각에 대해 지정된다. (파티션들에 걸쳐 프로비저닝된 스루풋 용량의 비-균일 분배들이 몇몇 실시예들에서 사용될 수 있다 - 예로서, 몇몇 파티션들이 알려져 있거나 또는 “더 뜨거운(hotter)” 것으로 예상되거나, 또는 다른 것들보다, 더 높은 평균 요청 레이트들을 갖는다면.) 허가 제어 결정들은 적어도 몇몇 이러한 실시예들에서 논리 파티션 레벨에서 이루어질 수 있다. 각각의 논리 파티션에 대응하여, 파티션의 데이터의 마스터 복제본 및 하나 이상의 슬레이브 복제본들은 데이터 오브젝트에 대한 데이터 내구성 정책 또는 데이터 복제 정책에 따라 셋 업될 수 있다. 내구성/복제 정책은 데이터 기록들이 충분한 수의 별개의 물리적 위치들로 복제됨을 보장하기 위해 설계될 수 있으며, 따라서 장비 고장들, 전력 손실, 및/또는 자연 재해들과 같은 인자들로 인한 데이터 손실의 확률은 임계치 아래로 유지된다. 몇몇 실시예들에서, 기록 요청들을 위한 허가 제어 결정들은 마스터 복제에서 이루어질 수 있는 반면, 판독들을 위한 허가 제어 결정들은 마스터 복제에서 또는 (특히 클라이언트가 데이터의 잠재적으로 약간 오래된 버전으로부터의 판독들을 기꺼이 수용한다면) 슬레이브 복제에서 이루어질 수 있다. 복제 정책에 따르면, 클라이언트부터의 기록 요청이 수용될 때, 수정된 데이터는 몇몇 실시예들에서, 예로서 기록이 성공했다는 확인 응답이 클라이언트에 제공되기 전에, N개의 복제본들(마스터 복제본 및 N-1 슬레이브 복제본들)에서 성공적으로 복제되어야 할 것이다. 따라서, 기록의 성공적인 완료가 슬레이브 자원들의 사용을 요구하기 때문에, 슬레이브(들)(뿐만 아니라 마스터)에서 이용 가능한 스루풋 용량은 기록들을 위한 허가 제어 동안 고려되어야 할 것이다. 일 실시예에서, 셋 업되는 슬레이브 복제본들의 수는 복제 정책을 위해 요구된 최소 수를 초과할 수 있다. 복제 정책은 기록의 Q개의 사본들의 정족수가 기록이 성공적이라고 간주되기 전에 영구적으로 이루어짐을 요구할 수 있으며, 따라서 (Q-1) 슬레이브 복제본들의 최소치가 요구될 수 있다. 그러나, 판독 로드 밸런싱, 높은 이용 가능성 등과 같은 다양한 이유들로, 유지된 슬레이브 복제본들의 수는 이러한 실시예들에서 Q-1을 초과할 수 있다. 슬레이브 또는 마스터로서 특정한 복제본의 지정은 다양한 실시예들에서 시간에 걸쳐 변할 수 있으며; 예를 들면, 주어진 논리 파티션에 대한 마스터가 인스턴스화되는 디바이스가 고장나거나 또는 도달 가능하지 않게 된다면, 이전에 슬레이브로 지정된 상이한 복제본이 마스터로서 선택될 수 있다는 것이 주의된다. 몇몇 실시예들에서, 슬레이브 복제본들의 수는 예로서, 데이터 오브젝트를 소유한 클라이언트로부터의 요청에 응답하여, 데이터 오브젝트의 수명에 걸쳐 변경될 수 있다. 허가 제어를 위한 토큰-기반 기술들은 몇몇 실시예들에서 또한 피어-투-피어 환경들에서 적용될 수 있으며, 여기에서 복제본들은 반드시 마스터들 또는 슬레이브들로서 지정되는 것은 아니며; 이러한 실시예에서, 인입하는 기록 요청을 위한 허가 제어 결정이 이루어지는 복제본은 여기에 설명된 바와 같이 마스터 복제본에 대응할 수 있다(수행된 동작들의 유형들에 대하여). 따라서, 복제본들이 대부분의 부분에 대해서 책임들에 있어서 서로 같은 피어-투-피어 복제를 이용한 몇몇 실시예들에서, 기록 요청이 주어진 피어(P1)에서 수신된다면, 적어도 하나의 다른 피어(P2)의 이용 가능한 스루풋 용량에 관한 정보는 기록 요청이 실행을 위해 수용될지를 결정하기 위해 사용될 수 있다.

상기 표시된 바와 같이, 기록들이 복제될 적어도 몇몇 실시예들에서, 하나 이상의 복제본(예로서, 마스터 및 적어도 하나의 슬레이브)에서 이용 가능한 스루풋 용량은 기록들을 위한 허가 제어 동안 고려되어야 할 수 있으며, 하나 이상의 복제-관리 버킷들(308)이 그에 따라 사용될 수 있다. 예를 들면, 로컬-버스트-제한 버킷들(604)은 분리 시 고려된 마스터 복제본에서 이용 가능한 스루풋을 나타낼 수 있지만, 복제-관리 버킷들(308)은 하나 이상의 슬레이브들에서 이용 가능한 스루풋 용량의 마스터의 뷰를 나타낼 수 있다.

슬레이브 용량 업데이트 프로토콜은 적어도 몇몇 실시예들에서, 복제-관리 버킷(들)(608)에서 슬레이브 상태(들)에 대한 정보를 리프레싱하기 위해 사용될 수 있다(예로서, 마스터에서 복제-관리 버킷(들)(608)의 토큰 모집단은 슬레이브로부터 수신된 정보에 기초하여 업데이트될 수 있다). 몇몇 실시예들에서, 토큰 버킷들은 또한, 버킷들이 마스터에서 사용되는 방식과 유사한(동일하지 않지만) 방식으로, 스루풋 관리를 위해 슬레이브들에서 사용될 수 있다. 슬레이브 용량 업데이트 프로토콜에 따르면, 하나의 이러한 실시예에서, 슬레이브는 슬레이브의 로컬 토큰 버킷들(프로비저닝된-용량 버킷들 및/또는 버스트-모드 버킷들을 포함할 수 있는) 중 하나 이상의 모집단 스냅샷들(즉, 시간 포인트 표현들)을 마스터에 제공할 수 있다. 예를 들면, 하나의 특정한 슬레이브-측 토큰 버킷은, 마스터에서 공유된 자원 용량 버킷(606)과 유사한, 슬레이브의 데이터의 적어도 일 부분이 저장되는 공유된 저장 디바이스에서의 이용 가능한 용량을 나타낼 수 있으며, 이러한 버킷의 모집단의 스냅샷들은 마스터에 제공될 수 있다. 여러 개의 상이한 접근법들 중 임의의 것은 상이한 실시예들에서 슬레이브로부터 스냅샷들을 제공하기 위해 사용될 수 있으며; 예를 들면, 스냅샷들은 기록 복제가 마스터에 의해 요청될 때 슬레이브에서 마스터로 전송된 기록 확인 응답들을 갖고 피기백(piggyback)되거나 또는 그것에 부착될 수 있거나, 또는 슬레이브는 슬레이브가 작동 중임을 마스터에 알리기 위해 마스터에 전송하도록 요구되는 하트비트(heartbeat) 메시지에 스냅샷을 부착할 수 있다.

복합 토큰 버킷들

이전에 설명된 바와 같이, 상이한 유형들의 작업 요청 도착 버스트들은 네트워크-액세스 가능한 서비스에 대한 그것들의 영향에서 달라질 수 있다. 서비스는 짧은 시간 기간 동안 매우 높은 버스트 레이트를 핸들링할 수 있을 것이지만, 보다 긴 동안 보다 낮은 버스트 레이트들을 견딜 수 있을 것이다. 몇몇 실시예들에서, 허가 제어기(180)는 서비스에 대한 그것들의 영향에 기초하여 상이한 유형들의 버스트들의 지속 기간들을 제한하도록 구성될 수 있으며, 버스티 작업 요청 도착 거동은 허가 제어를 돕기 위해 복수의 카테고리들로 분류될 수 있다. 도 7은 적어도 몇몇 실시예들에 따라, 허가 제어 목적들을 위해 카테고리들로의 작업 요청 버스트들의 분류의 예를 예시한다.

도 7에서, (도 1a에서처럼)에서, X-축은 시간을 나타내며, Y-축은 주어진 작업 타겟(102)에서 작업 요청 도착률들(110)을 나타낸다. 도 7과 같은 그래프는 예를 들면, 매 초(또는 N초들마다) 수신된 작업 요청들의 수를 모니터링하고, 초당 요청들의 카운트를 계산하며, 각각의 시간 간격 동안 초당 요청 값들을 표현한 포인트들을 연결함으로써 플로팅될 수 있다. 작업 타겟에 대한 프로비저닝된 용량(112)은 pr에서 Y-축을 교차하는 수평 라인에 의해 표현된다. 작업 타겟은 도착률이 pr에 있거나 그 아래에 있을 때마다 동작의 정상 모드에, 및 도착률이 pr 위에 있을 때마다 버스트 모드에 있다고 가정된다. T0 내지 T7의 시간 동안, 작업 타겟은 T0 및 T1 사이에서의 기간, T2 및 T3 사이에서의 기간, T4 및 T5 사이에서의 기간, 및 T6 및 T7 사이에서의 기간과 같은, 여러 개의 기간들 동안 정상 모드에 있다. 그러나, 3개의 기간들(T1 내지 T2, T3 내지 T4, 및 T5 내지 T6) 동안, 작업 타겟은 버스트 모드에 있다. 그래프에 표현된 바와 같이 버스트들의 형태들(B-내로우-1(간격(T1-T2) 동안) 및 B-내로우-2(간격(T5-T6) 동안)은 유사하며, 양쪽 형태들 모두는 버스트의 형태(B-와이드-1)와 상이하다. 버스트 피크 레이트들(702A)(B-내로우-1 동안 최대 작업 요청 도착률) 및 702C(B-내로우-2 동안 최대 작업 요청 도착률))은 버스트 피크 레이트(702B)(B-와이드-1 동안 최대 작업 요청 도착률)보다 상당히 더 높다.

허가 제어기(180)는 묘사된 실시예에서 두 개의 기본 토큰 버킷들을 포함한, 복합 버스트-모드 토큰 버킷을 유지하도록 구성될 수 있다. 이하에 설명되는 바와 같이, 기본 토큰 버킷들 중 하나는 프로비저닝된 용량(pr)(B-내로우-1 또는 B-내로우-2와 같은)에 대하여 매우 높은 도착률들을 가진 짧은 버스트들을 허용하기 위해 그러나 이러한 높은 도착률들을 가진 버스트들이 매우 길게 지속되는 것을 방지하기 위해 사용될 수 있다. 복합 토큰 버킷의 다른 기본 토큰 버킷은 B-와이드-1과 같은, 보다 낮은 피크 레이트들을 가진 보다 긴 버스트들을 허용하기 위해 사용될 수 있다. 적용 가능한 파라미터들 및/또는 정책들(예로서, 리필 레이트들)은 기본 버킷들에 대해 상이할 수 있다. 적어도 몇몇 실시예들에서, 토큰들은 버스트 모드 동안 실행을 위한 작업 요청을 허가하기 위해 기본 버킷들 양쪽 모두로부터 소비될 수 있다.

도 8은 적어도 몇몇 실시예들에 따라, 버스트-모드 허가 제어를 위해 피크-버스트 버킷(PBB)(802) 및 지속-버스트 버킷(SBB)(804)을 포함한 복합 토큰 버킷(801)의 사용의 예를 예시한다. 도시된 바와 같이, 복합 토큰 버킷(801)은 묘사된 실시예에서 작업 타겟(102)에 대한 버스트-모드 토큰 버킷 세트(125)의 부분을 형성한다. 버킷들(802 및 804)의 각각은 각각의 버스트 레이트(버킷이 모델링하도록 의도되는 최대 도착률을 표현한) 및 각각의 버스트 시간 윈도우(모델링된 버스트의 지속 기간을 표시하는)에 의해 특성화된다. 피크 버스트 레이트(pbr) 파라미터는 PBB를 사용하여 지원될 최대 도착률을 나타내며 피크 버스트 윈도우 크기(pbw) 파라미터는 이러한 도착률이 작업 타겟에 의해 지속 가능해야 하는 지속 기간을 표시한다(어떤 리필 동작들도 없는 것과 같은 특정한 조건들을 가정할 때). 지속 버스트 레이트(sbr) 파라미터는 보다 긴, 지속 버스트 시간 윈도우(sbw)를 위해 이상적으로 지원되어야 하는 버스트 도착률(pbr보다 낮은)을 표현한다. 각각의 시간 윈도우들이 일반적으로 버스트들이 다양한 실시예들에서 각각의 버킷들에 의해 지원되는 지속 기간들의 상대적 길이들을 표시할 수 있지만, 각각의 레이트들에서 버스트들이 실제로 지원되는 실제 지속 기간들은 시간 윈도우들과 정확하게 일치하지 않을 수 있다는 것이 주의된다. 따라서, 적어도 몇몇 실시예들에서, 시간 윈도우들은 타겟팅된 버스트 지속 기간들을 표시하는 것으로 말하여질 수 있지만, 반드시 동일한 실제 버스트 지속 기간들인 것은 아닐 수 있다. PBB(802) 및 SBB(804)의 최대 토큰 모집단들은 각각의 경우에서 버스트 레이트 및 시간 윈도우의 곱을 계산함으로써 획득되며: 예로서, PBB의 최대 모집단은 (pbr*pbw)이며, SBB의 최대 모집단은 (sbr*sbw)이다. 856 및 858로 라벨링된 화살표들에 의해 도시된 바와 같이, 토큰들이 실제로 복합 버킷(801)의 버킷들의 각각으로부터 소비되는 레이트는 작업 요청들의 도착률에 의존적일 수 있다(적어도 버스트 모드 동안, 및 몇몇 실시예들에서, 작업 타겟이 버스트 모드에 있는지 정상 모드에 있는지에 관계 없이). 적어도 몇몇 실시예들에서, 토큰들은 작업 요청이 수용될 때 PBB(802) 및 SBB(804) 양쪽 모두로부터 소비될 수 있으며 - 즉, 토큰들이 PBB 및 SBB로부터 소비되는 레이트들은 동일할 수 있다.

매우 높은 도착률들의 버스트들이 너무 길게 지속되도록 허용되지 않음을 보장하기 위해, 토큰들은 묘사된 실시예에서 실행을 위한 주어진 작업 요청을 수용하기 위해 버킷들의 각각으로부터 소비될 수 있다. 이전에 제공된 예를 반복하기 위해: 프로비저닝된 용량(pr)은 100 동작들/초(100 ops/sec)이고, 피크 버스트 레이트(pbr)는 1000 ops/sec이고, 피크 버스트 윈도우 크기(pbw)는 6초들이고, 지속 버스트 레이트(sbr)는 200 ops/sec이며, 지속 버스트 윈도우 크기(sbw)는 60초들인 시나리오를 고려하자. PBB의 최대 모집단은 따라서 1000*6, 또는 6000 토큰들이며, SBB의 최대 모집단은 또한 200*60, 또는 12000 토큰들의 곱으로 설정된다. 수용될 주어진 요청에 대해, 하나의 토큰 각각은 예시적인 시나리오에서 PBB 및 SBB로부터 요구된다. PBB 및 SBB 양쪽 모두가 가득한(PBB는 6000개의 토큰들을 갖고, SBB는 12000개를 갖는다) 시간(T)에서 시작하는 작업 요청들(B)의 버스트를 고려하며, PBB는 매초 200개의 토큰들로 다시 채워지는 반면, SBB는 매초 100개의 토큰들로 다시 채워진다고 가정하자. 버스트(B)가 1000 요청들/초에서 도착들로 이루어진다면, B의 요청들은, PBB의 모집단은 초당 대략 800개의 토큰들(1000개가 소비되고, 200개가 리필되는)의 레이트로 감소할 반면, SBB의 모집단은 초당 대략 900개의 토큰들(1000개가 소비되고, 100개가 리필되는)로 감소할 것이므로, 7 및 8초들 사이에서 동안 수용될 것이다. 그 이후, 복합 버킷은 1000 요청들/초를 유지할 수 없을 것이다. 그러나, 버스트(B)가 초당 200개의 요청에서의 도착들로 이루어진다면, PBB는 초당 어떤 순 토큰들(200개가 소비되고, 200개가 리필되는)도 잃지 않을 것인 반면, SBB는 초당 100개의 토큰들(200개가 소비되고, 100개가 리필되는)을 잃을 것이다. 따라서, 보다 작은 버스트 레이트(200 요청들/초)는 이러한 예시적인 시나리오에서 선명한 버스트(1000 요청들/초의 버스트에 대해 7 내지 8초들)보다 더 긴 시간(120초들) 동안 수용될 것이다.

실제로, 이전에 주지된 바와 같이, 다양한 실시예들에서, 복합 토큰 버킷(801)의 이러한 예시적인 사용의 연산은 도착률들에서의 변동들, 작업 타겟 재-진입 정상 모드, 및/또는 상이한 유형들의 요청들에 대해 상이한 수들의 토큰들을 요구하는 소비 정책들과 같은, 다양한 이자들로 인해 더 복잡해질 수 있다.

묘사된 실시예에서, 예를 들면, PBB에 대한 리필 레이트는 프로비저닝된 용량의 함수(pr (f1(pr))), 및 작업 타겟에 대한 프로비저닝된-용량 버킷에서의 수 “u”의 사용되지 않은 토큰들의 함수(f2(u))이다. 유사하게, SBB에 대한 리필 레이트는 프로비저닝된 용량의 함수(f3(pr)) 및 u의 함수(f4(u))이다. 일 구현에서, 프로비저닝된-용량 버킷에서 절대 수의 사용되지 않은 토큰들에 기초하는 대신에, PBB, SBB 또는 양쪽 모두의 리필 레이트는 사용되지 않은 토큰들이 프로비저닝된-용량 버킷에서 축적하는 레이트에 기초할 수 있다. 몇몇 실시예들에서, 상기 예에서처럼, PBB의 리필 레이트는 SBB의 리필 레이트보다 더 높게 설정될 수 있는 반면, PBB의 최대 모집단은 SBB의 최대 모집단보다 작게 설정될 수 있다. 상이한 실시예들은 다양한 종류들의 함수들(f1, f2, f3 및 f4)의 임의의 원하는 조합을 이용할 수 있다.

다양한 실시예들에서, 파라미터들(pbr, pbw, sbr 및 sbw과 같은) 및 함수들(f1, f2, f3 및 f4)의 정의들은 동조 가능하거나 또는 구성 가능할 수 있으며; 예로서 허가 제어기(180)는 구성 파일로부터 또는 네트워크-액세스 가능한 서비스의 관리자로부터의 입력을 통해 함수들의 정의들 및 파라미터들의 값들을 결정하도록 구성될 수 있다. 허가 제어기는 파라미터 값들 및 함수들을 결정하고, 최대 모집단들을 계산하거나 또는 구성하고, 파라미터들에 따라 버킷들(802 및 804)을 실장하며 인입하는 작업 요청들을 대기할 수 있다. 작업 요청이 버스트 모드 동안 수신될 때, 그것은 PBB 및 SBB 중 하나 또는 양쪽 모두의 토큰 모집단들에 적어도 부분적으로 기초하여 실행을 위해 수용(또는 거절)될 수 있다. 수용된다면, 하나 이상의 토큰들은 두 개의 버킷들에 대한 각각의 소비 정책들에 기초하여, PBB, SBB, 또는 양쪽 모두로부터 소비될 수 있다. PBB 및 SBB는 도 12에 대하여 이하에서 추가로 상세히 설명되는 바와 같이, 다양한 시간 포인트들에서 그것들 각각의 리필 레이트들에 기초하여 다시 채워질 수 있다. 적어도 몇몇 실시예들에서, 함수들(f1, f2, f3 및 f4) 중 일부는 아이덴티티 함수들일 수 있으며 - 예로서, 그것은 f1(pr) = pr인 경우일 수 있다. 함수들(f1, f2, f3 및 f4) 중 일부는 일 실시예에서 다른 함수들 중 일부와 동일할 수 있으며, 예로서 4개의 함수들이 상이한 어떤 요건도 없을 수 있다. 몇몇 실시예들에서, 프로비저닝된 용량 버킷(“u”)에서 사용되지 않은 토큰들의 수는 리필 레이트에 기여하지 않을 수 있으며, 예로서 그것은 리필 레이트들이 사용되지 않은 토큰들의 축적에 독립적인 경우일 수 있다. 적어도 몇몇 실시예들에서, PBB 및/또는 SBB는 동작들의 정상 모드들 동안 그것들의 리필 정책들에 따라(및 그것들의 최대 토큰 모집단 한계들을 조건으로 하는) 다시 채워질 수 있으며, 따라서 토큰들은 작업 요청 도착들의 레이트가 버스트-모드 동안 임계치 아래인 동안에도 PBB 및/또는 SBB에서 축적된다. 정상 모드 동안 버스트-모드 버킷들의 이러한 리필은 예를 들면, 미래 버스트들을 핸들링하도록 시스템을 준비하는 것을 도울 수 있다.

몇몇 실시예들에서, 작업 타겟을 구현한 서비스는 작업 요청들의 상이한 카테고리들에 대한 파라미터들의 각각의 세트들을 사용하여 피크 및 지속 버스트-모드 허가들을 제어하기를 원할 수 있다. 예를 들면, 상이한 피크 버스트 레이트(또는 지속 버스트 지속 기간)는 기록들을 위한 것보다 판독들에 적절할 수 있거나, 또는 상이한 피크 버스트 레이트(또는 지속 버스트 지속 기간)는 작업 요청들의 여러 개의 우선순위-기반 카테고리들의 각각에 대해 적절할 수 있다. 작업 요청들의 몇몇 매우 시간-민감한 카테고리에 대해, 예를 들면, 서비스는 작업 요청들의 다른, 덜 시간-민감한 카테고리들에 대한 것보다 더 높은 피크 버스트들을 지원하기를 원할 수 있다. 허가 제어기(180)는 몇몇 실시예들에서 이러한 사용 경우들을 핸들링하기 위해 복수의 복합 버킷들을 구현할 수 있다. 도 9는 적어도 몇몇 실시예들에 따라, 작업 동작들의 각각의 카테고리들에 전용된 피크-버스트 및 지속-버스트 버킷들의 사용을 예시한다.

도시된 바와 같이, 묘사된 실시예에서, 버스트-모드 버킷 세트(125)는 각각이 작업 요청들의 하나 이상의 카테고리들에 전용되는, 801A, 801B 및 801C를 포함하여, 복수의 복합 버킷들(801)을, 로컬-버스트-제한 버킷들(604)의 그것의 모음 내에 포함할 수 있다. 예를 들면, 복합 버킷(801A)은 카테고리(C1)의 요청들에 대한 허가 제어를 위해 사용될 수 있고, 복합 버킷(801B)은 카테고리(C2)의 요청들에 대한 허가 제어를 위해 사용될 수 있으며, 복합 버킷(801C)은 카테고리(C3) 및 카테고리(C4)의 요청들에 대한 허가 제어를 위해 사용될 수 있다. 카테고리들의 정의들은 상이한 실시예들에서 서비스-의존적일 수 있다 - 예로서, 하나의 서비스는 수행된 동작들의 유형들에 기초하여 카테고리들을 정의할 수 있고(예로서, 판독들 및 기록들은 별개의 카테고리들일 수 있다), 다른 서비스는 평균적으로 소비된 자원들의 양들에 기초하여 카테고리들을 정의할 수 있고(예로서, 짧은 대 긴 동작들), 다른 서비스는 클라이언트-특정 우선순위들 또는 서비스-할당 우선순위들 등에 기초하여 카테고리들을 정의할 수 있다.

복합 버킷들(801)의 각각은 pbr, pbw, sbr 및 sbw에 대한 파라미터 설정들의 각각의(및 잠재적으로 별개의) 세트들을 갖고, 적어도 하나의 PBB(802) 및 적어도 하나의 SBB(804)를 포함할 수 있다. 예를 들면, 복합 버킷(801A)은 PBB(802A) 및 SBB(804A)를 포함하고, 복합 버킷(801B)은 PBB(802B) 및 SBB(804B)를 포함하는 반면, 복합 버킷(804C)은 PBB들(802C 및 802D) 및 단일 SBB(804C)를 포함한다. 복합 버킷(801C)의 경우에, 카테고리(C3) 요청들의 버스트-모드 관리 제어는 PBB(802C) 및 SBB(804C)를 사용하여 관리되는 반면, 카테고리(C4) 요청들에 대한 버스트-모드 관리 제어는 PBB(802D) 및 공유 SBB(804C)를 사용하여 핸들링된다. 따라서, 이러한 예시적인 시나리오에서, 카테고리(C3)의 버스트-모드 작업 요청이 수신될 때, PBB(802C) 및 SBB(804C)의 모집단들이 확인되며, 카테고리(C4)의 버스트-모드 작업 요청이 수신될 때, PBB(802D) 및 SBB(804C)의 모집단들이 확인된다. 작업 요청들의 상이한 카테고리들(또는 작업 요청들의 카테고리들의 조합들)에 대한 별개의 복합 버킷들을 구현함으로써, 서비스는 단일 복합 버킷이 사용된다면 실현 가능할 수 있는 것 보다 미세한 단위(granularity)에서 버스트-모드 거동을 제어할 수 있을 것이다. 도 9의 버스트-모드 버킷 세트(125)는 또한 하나 이상의 공유-자원 용량 버킷들(606)(예로서, 버스트-모드 허가 제어 동안 공유 자원들의 용량 한계들이 고려됨을 보장하기 위해) 및 하나 이상의 복제-관리 버킷들(608)(예로서, 복제되어야 하는 기록들과 같은 동작들에 대한 허가 제어 결정들이 하나 이상의 복제본에서 이용 가능한 스루풋 용량에 적어도 부분적으로 기초하여 이루어짐을 보장하기 위해)을 포함할 수 있다.

버스트-모드 허가 제어를 위한 방법들

도 10은 적어도 몇몇 실시예들에 따라, 네트워크-액세스 가능한 서비스에서 작업 요청들에 대한 토큰-기반 허가 제어 메커니즘을 구현하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(1001)에서 도시된 바와 같이, 작업 타겟에 적용 가능한 정상-모드 스루풋 용량 한계가, 예로서 클라이언트로부터의 프로비저닝 요청에 응답하여, 결정될 수 있다. 예를 들면, 데이터베이스 서비스의 클라이언트는 초당 N개의 판독 또는 기록 동작들을 지원할 수 있는 테이블이 생성됨을 요청할 수 있으며, 테이블에 대한 정상-모드 스루풋 용량 한계는 그에 따라 N으로 설정될 수 있다. 서비스의 허가 제어기(180)는 예를 들면, 디폴트 설정들에 기초하여 또는 클라이언트에 의해 요청되거나 또는 그것과 협상된 규격들에 기초하여, 정상-모드 버킷 세트 및 버스트-모드 버킷 세트를 위해 사용될 다양한 다른 파라미터들(버킷들의 수, 초기 토큰 모집단들, 리필 레이트들 등과 같은)을 결정할 수 있다. 정상-모드 버킷 세트(120) 및 버스트-모드 버킷 세트(125)의 버킷들은 그 후 초기화, 예로서 인스턴스화 및 실장될 수 있다(요소 1006).

다음의 작업 요청은 허가 제어기에서 수신될 수 있다(요소 1010). 적어도 하나의 정상-모드 버킷의 토큰 모집단이 확인될 수 있다. 정상-모드 토큰 모집단이 임계 기준(T1)을 충족시킨다면(요소(1014)에서 검출된 바와 같이), 하나 이상의 토큰들이 정상-모드 토큰 버킷(들)으로부터 소비될 수 있으며(즉, 토큰 모집단이 변경될 수 있다) 작업 요청이 실행을 위해 수용될 수 있다(요소 1016). 하나의 간단한 구현에서, 예를 들면, 정상-모드 토큰 버킷은 임계 기준(T)을 충족시키기 위해 적어도 하나의 토큰을 갖도록 요구될 수 있으며, 하나의 토큰은 허가된 작업 요청에 따라 소비될 수 있다. 몇몇 실시예들에서, 토큰들은 작업 요청이 정상 동작 모드 동안 수용될 때 하나 이상의 버스트-모드 버킷들로부터(하나 이상의 정상-모드 버킷들로부터 뿐만 아니라) 소비될 수 있다. 일반적으로, 소비된 토큰들의 수는 버킷(들)에 대해 시행 중인 토큰 소비 정책을 포함하여, 다양한 실시예들에서 인자들의 조합에, 및/또는 작업 요청에 응답하도록 요구될 수 있는 작업의 양의 추정치에 의존할 수 있다. 허가 제어기(180)는 예를 들면, 클라이언트에 의해 작업 요청에서 특정된 세부사항, 사실상 과거에 요구된 작업 유사 요청들의 양의 누적된 이력 또는 통계들 등에 기초하여, 적어도 몇몇 실시예들에서 이러한 추정치를 생성하도록 구성될 수 있다. 몇몇 실시예들에서, 시행 중인 리필 정책들에 의존하여, 다양한 토큰 버킷들(예로서, 정상-모드 버킷들, 버스트-모드 버킷들, 또는 양쪽 모두)은 선택적으로 허가 제어 결정이 이루어지는 시간에 리필될 수 있다(즉, 토큰들은 그것들의 리필 정책들 및 최대 모집단 한계들에 따라 그것들에 부가될 수 있다). 도 12에 대하여 이하에 설명되는 바와 같이, 토큰 버킷 리필들을 야기하는 특정 시간들 또는 이벤트들은 상이한 실시예들에서 상이할 수 있다. 정상-모드 토큰 모집단이 임계 기준(T1)(또한 요소(1014)에서 검출된 바와 같이)을 충족시키지 않는다면, 허가 제어기(180)는 작업 요청의 수용이 작업 타겟의 버스트-모드 동작을 야기할 것이며, 하나 이상의 버스트-모드 토큰 버킷들의 토큰 모집단들이 그에 따라 결정되어야 한다고 결론을 내릴 수 있다.

허가 제어기(180)는 묘사된 실시예에서 적어도 하나의 버스트-모드 토큰 버킷의 토큰 모집단을 결정할 수 있다. 버스트-모드 토큰 모집단이 임계 기준(T2)(요소(1018)에서 결정된 바와 같이)을 충족한다면, 하나 이상의 토큰들은 버스트-모드 버킷(들)으로부터 소비될 수 있으며 작업 요청은 버스트 모드에서 실행을 위해 수용될 수 있다(요소 1020). 하나의 단순한 구현에서, 예를 들면, 버스트-모드 토큰 버킷은 임계 기준(T2)을 충족시키기 위해 적어도 하나의 토큰을 갖도록 요구될 수 있으며; 따라서, 그것은 적어도 몇몇 구현들에서, 정상-모드 및 버스트-모드 버킷들 양쪽 모두에 대한 임계 토큰 모집단들이 동일한 경우일 수 있다. 일반적으로, 버스트-모드 토큰 버킷들로부터 소비된 토큰들의 수는 또한 버스트-모드 버킷(들)에 대한 시행 중인 토큰 소비 정책을 포함하여, 다양한 실시예들에서 인자들의 조합에, 및/또는 작업 요청에 응답하도록 요구될 수 있는 작업의 양의 추정치에 의존할 수 있다. 작업 요청의 정상-모드 수용에 대응하는 동작들의 경우에서처럼, 하나 이상의 버킷들은 버스트-모드 수용 결정이 이루어질 때, 그것들의 리필 정책들에 기초하여 및 그것들의 최대 토큰 모집단 한계들을 조건으로 하여, 선택적으로 리필될 수 있다.

작업 요청이 수용된다면, 정상 모드에서(요소 1016) 또는 버스트 모드에서(요소 1020), 작업 요청에 대응하는 하나 이상의 동작들이 개시될 수 있다(요소 1022). 몇몇 실시예들에서, 동작들이 완료될 때, 허가 제어기(180)는 얼마나 많은 토큰들을 소비할지를 결정하기 위해 사용된 작업의 추정치에 수행된 실제 작업 양을 비동기식으로 비교할 수 있다(요소 1024). 원래 작업 추정이 부정확하다면, 대응하는 작업 요청을 위한 허가 제어를 위해 사용된 하나 이상의 버킷들에서의 토큰들의 수가 그에 따라 조정될 수 있다. 추정치가 수행된 실제 작업보다 낮다면, 부가적인 토큰들의 수는 허가 제어를 위해 사용된 버킷들로부터 제거될 수 있고; 소비된 이러한 부가적인 토큰들의 수는 몇몇 실시예들에서 실제 작업 및 작업의 추정 사이에서의 차이에 기초하여 계산될 수 있다. 추정이 너무 높다면, 몇몇 수의 토큰들은 허가 제어를 위해 사용된 버킷들로부터 제거될 수 있다.

묘사된 실시예에서, 정상-모드 토큰 버킷 세트 모집단이 기준(T1)을 충족시키지 않으며, 버스트-모드 버킷 세트 토큰 모집단이 기준(T2)을 충족시키지 않는다면, 작업 요청은 거절되고, 지연되거나 또는 재시도될 수 있다(요소 1080). 몇몇 실시예들에서, 시행 중인 리필 정책들에 의존하여, 하나 이상의 토큰들은 작업 요청을 수용하지 않는다는 결정이 이루어질 때, 정상-모드 버킷(들), 버스트-모드 버킷(들), 또는 양쪽 모두에 선택적으로 부가될 수 있다. 허가 제어 결정이 이루어진 후(예로서, 작업 요청이 수용되거나 또는 거절되는), 허가 제어기는 다음의 작업 요청을 대기할 수 있으며 요소들(1010)에 대응하는 동작들이 앞으로 반복될 수 있다.

도 11은 적어도 몇몇 실시예들에 따라, 네트워크-액세스 가능한 서비스에서, 복합 버킷을 포함하여, 복수의 버스트-모드 토큰 버킷들을 사용하여 버스트-모드 동작들을 핸들링하기 위한 토큰-기반 허가 제어 메커니즘을 구현하도록 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(1101)에 도시된 바와 같이, 허가 제어기(180)는 주어진 작업 타겟에서 높은 도착률들에서 짧은-지속 버스트들 및 보다 낮은 도착률들에서 보다 긴-지속 기간 버스트들에 대한 버스트-모드 허가 제어를 위해 사용될 다수의 파라미터들을 결정할 수 있다. 결정된 파라미터는 예를 들면, 지원될 피크 버스트 레이트(pbr), 피크 버스트 레이트가 지원되는 지속 기간을 표시한 피크 버스트 윈도우 크기(pbw), 지속 버스트 레이트(sbr)(반드시가 아닌 통상적으로 pbr보다 낮은), 및 지속 버스트 윈도우 크기(sbw)(반드시가 아닌 통상적으로 pbw보다 큰)를 포함할 수 있다. 예를 들면, 공유-자원 용량 버킷들 및/또는 복제-관리 버킷들을 포함한 다른 버킷들이 설정될 것인지 여부, 다양한 버킷들에 대한 초기 모집단 설정들 등과 같은, 다른 파라미터들이 또한 적어도 몇몇 실시예들에서 결정될 수 있다. 파라미터들의 적어도 일부는 예로서, 관리자 입력 또는 서비스에 의한 자동-동조에 응답하여, 구성 가능할 수 있으며, 하나 이상의 파라미터들은 몇몇 구현들에서 구성 파일들을 통해 판독될 수 있다.

요소(1106)에 도시된 바와 같이, 적어도 하나의 피크-버스트 버킷(PBB) 및 하나의 지속-버스트 버킷(SBB)을 포함한 복합 버킷이, 예를 들면, 버킷들의 각각의 초기 모집단들(306)과 같은 파라미터 설정들에 기초하여 버킷들을 인스턴스화하며 실장함으로써, 초기화될 수 있다. 묘사된 실시예에서, PBB의 최대 토큰 모집단은 pbr 및 pbw의 곱으로 설정될 수 있으며, SBB의 최대 토큰 모집단은 sbr 및 sbw의 곱으로 설정될 수 있다. PBB 및/또는 SBB에 대한 리필 레이트들은 작업 타겟의 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초하여 설정될 수 있다. 몇몇 실시예들에서, PBB 및/또는 SBB에 대한 리필 레이트는 또한 사용되지 않은 토큰들이 프로비저닝된-용량 버킷 또는 다른 정상-모드 버킷에 축적되는 레이트 및/또는 이러한 버킷들에서의 사용되지 않은 토큰들의 수에 기초할 수 있다.

다음 버스트-모드 작업 요청은 버스트 모드 동안 허가 제어기에서 수신될 수 있다(요소 1110)(즉, 작업 요청이 수신될 수 있으며 허가 제어기는, 프로비저닝된-용량 버킷과 같은 정상-모드 버킷의 토큰 모집단을 사용하여, 또는 작업 타겟의 동작의 모드의 몇몇 다른 표시자를 사용하여, 작업 타겟이 버스트 모드에 있음을 결정할 수 있다). 허가 제어기는 소비 정책들에 및/또는 작업 요청과 연관된 작업의 양의 추정에 기초하여, PBB 및/또는 SBB의 토큰 모집단들을 결정할 수 있으며, 충분한 토큰들이 작업 요청을 수용하기 위해 이용 가능한지를 확인할 수 있다. 충분한 토큰들이 PBB 및/또는 SBB에 존재한다면(요소(1114)에서 검출된 바와 같이), 묘사된 실시예에서, 허가 제어기는 버스트-모드 토큰 버킷 세트가 그 모집단들이 또한 고려되는 작업 요청을 위해 확인되어야 하는 다른 버킷들을 포함하는지를 결정할 수 있다. 예를 들면, 몇몇 실시예들에서, 버스트-모드 토큰 버킷 세트는 하나 이상의 공유-자원 용량 버킷들(606) 및/또는 하나 이상의 복제-관리 버킷들(608)을 포함할 수 있다. 부가적인 버스트-모드 토큰 버킷들이 구현되며, 충분한 토큰들이 작업 요청에 관련 있는 남아 있는 버스트-모드 토큰 버킷들의 각각에서 발견된다면(요소(1118)에서 검출된 바와 같이), 적절한 수의 토큰들이 각각의 관련 버킷으로부터 소비될 수 있으며(예로서, 적용 가능한 소비 정책들에 따라) 요청이 실행을 위해 수용될 수 있다(요소 1120). 적어도 몇몇 실시예들에서, 부가적인 버스트-모드 토큰 버킷들 중 일부는 단지 요청들의 특정한 카테고리들에 관련 있을 수 있으며 - 예를 들면, 복제-관리 토큰 버킷(608)의 모집단은 일 실시예에서 기록 요청 허가 제어를 위해서만 확인될 수 있으며, 이러한 실시예에서 판독 요청을 수용할지를 결정할 때 확인되지 않을 수 있다는 것이 주의된다. 따라서, 단지 버스트-모드 토큰 버킷의 존재만이 몇몇 실시예들에서 상기 버킷이 수신된 모든 작업 요청들에 대한 허가 제어를 위해 사용되어야 함을 내포하지 않을 수 있다.

충분한 토큰들이 복합 토큰 버킷 쌍(즉, PBB 및/또는 SBB)(요소(1114)에서 검출된 바와 같이) 또는 관련 부가적인 버스트-모드 토큰 버킷들(요소(1118)에서 검출된 바와 같이)에서의 소비를 위해 이용 가능하지 않다면, 작업 요청은 묘사된 실시예에서 거절되고, 지연되거나 또는 재시도될 수 있다(요소 1138). 몇몇 실시예들에서, 작업 요청이 수용되었는지 또는 거절되었는지에 관계없이, 허가 제어를 위해 사용된 버킷들 중 하나 이상(예를 들면, 정상-모드 토큰 버킷 세트(120)의 버킷들 및/또는 버스트-모드 버킷 세트(125)의 버킷들)은 허가 제어 결정이 이루어진 후 대응하는 리필 정책들에 따라 리필될 수 있다(요소 1140). 주어진 작업 요청에 대응하는 그것의 동작들을 완료한 후, 허가 제어기(180)는 도착할 다음 작업 요청을 대기할 수 있으며, 요소들(1110)에 대응하는 동작들이 앞으로 버스트 모드에서 수신된 다음 작업 요청을 위해 반복될 수 있다.

상이한 실시예들에서, 토큰 리필 동작들(즉, 토큰들이 주어진 토큰 버킷에 부가되는 동작들)은 상이한 이벤트들에 응답하여, 또는 상이한 스케줄들에 기초하여 수행될 수 있다. 도 12는 적어도 몇몇 실시예들에 따라, 허가 제어를 위해 수행될 수 있는 토큰 소비, 리필 및 전달 동작들의 양상들을 예시한 흐름도이다. 요소(1201)에 도시된 바와 같이, 허가 제어기는 버킷 모집단 변화들을 야기할 수 있는 트리거링 이벤트들의 유형들을 결정할 수 있다(예로서, 구성 파라미터들을 검사함으로써). 몇몇 실시예들에서, 새로운 작업 요청의 도착 및/또는 대응하는 허가 제어 결정의 완료가 토큰 모집단 변화들을 트리거할 수 있다. 일 실시예에서, 마지막 모집단이 버킷에서 변화한 이래 시간 간격(예로서, N1 밀리초들 또는 N2 초들)의 만료는 토큰 모집단들을 트리거할 수 있다. 다른 실시예들에서, 시간 간격 만료들, 작업 요청 도착들 및/또는 작업 요청 허가 제어 완료들의 조합들은 토큰 모집단 변화들을 트리거할 수 있다. 다음 트리거링 이벤트의 발생이 검출될 수 있다(요소 1206). 다양한 토큰 버킷들의 현재 모집단들은, 예로서, 정상 모드 버킷들 및 버스트-모드 버킷들을 포함하여 결정될 수 있다(요소 1210). 몇몇 실시예들에서, 다양한 토큰 버킷들로 향해진 판독들 및 기록들은 모두 단일 원자 동작(데이터베이스 거래와 유사한) 내에서 수행될 수 있으며, 이러한 실시예들에서, 원자 동작은 현재 토큰 모집단들의 판독으로 시작할 수 있다.

트리거링 이벤트가 토큰들의 소비 또는 폐기를 수반한다면(요소(1214)에서 검출된 바와 같이), 소비되거나 또는 폐기될 토큰들의 수는 각각의 버킷에 대해 결정될 수 있으며(요소 1217), 버킷 모집단(들)은 묘사된 실시예에서 그에 따라 조정될 수 있다. 몇몇 수의 토큰들은 다양한 실시예들에서 수용된 각각의 작업 요청에 대해, 상기 설명된 바와 같이, 소비될 수 있다. 몇몇 실시예들에서, 토큰들은 최대 수명을 가질 수 있으며, 그것들의 최대 수명 동안 사용되지 않은 채로 있는 토큰들은 토큰 시효경과 정책에 따라 폐기될 수 있다.

적어도 몇몇 실시예들에서, 하나의 버킷에서 사용되지 않은 채로 있는 토큰들은 다른 버킷으로 “전달(transferred)”될 수 있으며 - 예로서, 프로비저닝된-용량 버킷에서의 사용되지 않은 토큰들은 버스트-모드 버킷 또는 버킷들에서 축적되거나 또는 뱅킹될 수 있다. 다양한 실시예들에서, 토큰들의 “전달(transfer)”은 예를 들면, N개의 토큰들이 특정한 시간 포인트에서 프로비저닝된 용량 버킷에서 사용되지 않은 것으로 발견된다면, N개의 토큰들은 버스트-모드 버킷에 부가되며 프로비저닝된 용량 버킷의 토큰 모집단은 N만큼 감소되는 논리 동작을 포함한다는 것이 주의된다. 즉, 이러한 실시예들에서, 소스 및 목적지 버킷들의 토큰 모집단들은 조정될 수 있으며, 토큰들은 사실상 이와 같이 송신되거나 또는 전달되지 않을 수 있다. 몇몇 실시예들에서, N개의 사용되지 않은 토큰들이 소스 버킷에서 발견된다면, N개의 토큰들은 복수의 목적지 버킷들의 각각에 부가될 수 있다(예로서, 단일 사용되지 않은 프로비저닝된-용량 버킷 토큰의 검출은 복합 토큰 버킷(801)의 PBB 및 SBB 양쪽 모두의 모집단들에 대한 증가를 야기할 수 있다). 이러한 전달이 수행된다면(요소(1220)에서 검출된 바와 같이), 전달의 소스 버킷(들)의 모집단은 감소될 수 있으며 목적지 버킷(들)의 모집단은 증가될 수 있다(요소 1223).

토큰들은 그것들 각각의 리필 정책들에 따라, 필요에 따라 다양한 버킷들에 부가될 수 있으며(요소 1227), 원자 동작 또는 거래가 요소(1210)에 대응하는 동작들에서 시작된다면, 원자 동작은 종료될 수 있다(요소 1230). 이러한 리필 동작들은 토큰들이 소비되고, 폐기되거나 또는 전달되는지에 관계 없이, 몇몇 실시예들에서 수행될 수 있다(즉, 요소들(1214 및 1220)에서 이루어진 결정들의 긍정 및 부정 결과들 양쪽 모두는 이러한 실시예들에서 리필 동작들로 이어질 수 있다). 단일 원자 동작 내에서 설명된 다양한 토큰 모집단 조정들을 수행함으로써, 허가 제어기는 이러한 실시예들에서 다수의 버킷 조합들에 걸쳐 원하는 레벨의 일관성을 보장할 수 있다. 허가 제어기는 그 후 다음 트리거링 이벤트를 기다릴 수 있으며, 앞으로 요소들(1206)에 대응하는 동작들은 다음 트리거링 이벤트가 검출될 때 반복될 수 있다.

이전에 주지된 바와 같이, 적어도 몇몇 실시예들에서, 허가 제어 결정의 결과, 및/또는 작업 요청의 수용과 함께 소비된 토큰들의 수는 작업 요청이 수용된다면 수행될 작업의 양의 추정에 적어도 부분적으로 기초할 수 있다. 추정은 몇몇 경우들에서, 부정확한 것으로 판명될 수 있으며, 허가 제어기(180)는 몇몇 실시예들에서, 예로서 수용된 요청에 대한 작업이 완료되며 불일치성(만약에 있다면)이 알려져 있을 때, 이러한 추정 에러들을 보상하도록 구성될 수 있다. 도 13은 적어도 몇몇 실시예들에 따라, 허가된 작업 요청에 대응하는 작업 동작들이 완료된 후 하나 이상의 토큰 버킷들에서 토큰 카운트들을 조정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(1301)에 도시된 바와 같이, 허가 제어기는 작업 요청에 대응하는 작업의 완료의 다음 표시를 수신할 수 있다. 이러한 표시는 예를 들면, 작업 타겟이 구현되는 서비스의 관리 구성요소에 의해 관리 제어기에 비동기식으로 제공될 수 있으며, 요청을 위해 행해진 실제 작업 양의 메트릭을 포함할 수 있다.

묘사된 실시예에서, 허가 제어기(180)는 원래 추정치가 행해진 실제 작업 양에 대하여 너무 높은지 또는 너무 낮은지를 결정할 수 있다. 추정된 것보다 많은 작업이 행해진다면(요소(1304)에서 결정된 바와 같이), 허가 제어기는 과소 추정의 보상으로 하나 이상의 토큰 버킷들로부터 공제될 토큰들의 수를 결정하며(요소 1308), 그에 따라 버킷 모집단들을 아래쪽으로 조정할 수 있다. 몇몇 경우들에서, 조정은 마이너스 토큰 모집단들을 야기할 수 있다. 결국, 리필 동작들은 토큰 모집단들을 양의 값들로 회복시킬 수 있으며, 주어진 버킷에서의 토큰 모집단이 마이너스인 채로 있지만, 허가 결정들이 주어진 버킷의 모집단에 기초하여 이루어지는 새로운 작업 요청들이 적어도 몇몇 실시예들에서 거절될 수 있다.

적어도 일 실시예에 따르면, 원래 작업 추정이 너무 높다면(요소(1312)에서 결정된 바와 같이), 허가 제어기(180)는 선택적으로 하나 이상의 버킷들로 부가될 토큰들의 수를 결정하며 그에 따라 버킷 모집단들을 설정할 수 있다(요소 1316). 묘사된 실시예에서, 허가 제어기는 작업 추정치들의 정확도의 기록들을 유지하도록 구성될 수 있으며, 예로서 시간 기간에 걸쳐 몇몇 또는 모든 수용된 작업 요청들에 대한 실제 작업 양 및 추정의 기록들은 데이터베이스 또는 로그에서 유지될 수 있다. 따라서, 추정이 정확한지 여부에 관계없이, 및 에러가 없는 이들 경우들에서 에러의 방향에 관계없이(예로서, 추정이 너무 높은지 또는 너무 낮은지에 관계없이), 허가 제어기는 작업 추정 에러들의 기록들을 업데이트할 수 있다(요소 1323). 이러한 기록 유지는, 예를 들면, 허가 제어기가 에러들에 기초하여 그것의 추정 절차들을 적응시킬 수 있으므로, 시간에 걸쳐 추정들의 정확도를 개선하도록 도울 수 있다. 몇몇 실시예들에서, 이러한 기록들은 작업 요청들의 서브세트(예로서, 랜덤 샘플)만을 위해 유지될 수 있거나, 또는 단지 에러의 크기가 임계치 이상인 이들 작업 요청들에 대해서만 유지될 수 있다. 기록들을 업데이트한 후, 허가 제어기는 묘사된 실시예에서 다음 완료에 대해 통지되길 기다릴 수 있으며, 앞으로 요소들(1301)에 대응하는 동작들이 반복될 수 있다. 몇몇 실시예들에서, 도 13에 도시된 이것들과 유사한 동작들은 정상-모드 버킷들에 대해서뿐만 아니라 버스트-모드 버킷들에 대해 수행될 수 있다. 적어도 일 실시예에서, 도 13에 예시된 종류들의 버킷 모집단들에 대한 소급적 조정들은 인입하는 클라이언트 작업 요청들에 대한 허가 제어 결정들에 대하여, 또는 배경 태스크들로서 낮은 우선순위에서 수행될 수 있다.

몇몇 실시예들에서, 주어진 작업 타겟의 이용 가능한 스루풋 용량은 인입하는 작업 요청들이 아닌 인자들에 의해 영향을 받을 수 있다. 예를 들면, 작업 타겟의 상태가 회복되는 실패로부터의 복구와 같은, 특정한 종류들의 관리 동작들, 또는 다양한 유형들의 유지 동작들은 클라이언트 요청들에 대해 이용 가능한 스루풋 용량을 감소시킬 수 있다. 도 14는 적어도 몇몇 실시예들에 따라, 관리 이벤트들에 응답하여 버스트-모드 허가 제어 파라미터들을 수정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(1401)에 도시된 바와 같이, 허가 제어기(180)는 하나 이상의 작업 타겟들의 이용 가능한 스루풋 용량에서의 감소를 야기할 수 있는, 복구 동작의 시작과 같은, 배경 또는 관리 이벤트(즉, 클라이언트 작업 요청으로부터 직접 기인하지 않는 이벤트)의 표시를 수신할 수 있다. 관리 제어기는 그 후 이벤트를 고려하여, 버스팅(예로서, 프로비저닝된 스루풋 용량보다 높은 레이트로)이 일시적으로 불능되는지를 결정할 수 있다. 버스팅이 불능된다면(요소(1404)에서 결정된 바와 같이), 단지 정상-모드 허가들이 이벤트가 완료될 때까지 지원될 수 있다(요소 1408).

버스팅이 전체적으로 불능되지 않는다면(또는 요소(1404)에서 결정된 바와 같이), 허가 제어기는 몇몇 실시예들에서, 예로서 하나 이상의 버킷들로부터 몇몇 토큰들을 제거함으로써, 또는 일시적으로 아래쪽으로 리필 레이트들을 조정함으로써, 허가된 버스팅의 양을 스로틀링하도록 구성될 수 있다. 이러한 실시예들에서, 허가 제어기는 공제될 토큰들의 수 및/또는 리필 레이트들이 낮아지는 정도를 결정할 수 있다(요소 1412). 하나 이상의 버킷들의 모집단들이 그에 따라 조정될 수 있으며, 및/또는 리필 레이트들이 결정된 대로 수정될 수 있다. 몇몇 경우들에서, 주어진 버킷의 모집단은 적어도 일 실시예에서 조정들의 결과로서 0 아래로 떨어질 수 있다. 허가 제어기는 그 후 관리 또는 배경 이벤트가 완료되었다는 통지를 대기할 수 있다(요소 1415). 이벤트가 완료된 후, 허가 제어기는, 적어도 몇몇 실시예들에서, 이벤트로 인해 이루어진 변화들 중 일부 또는 모두를 선택적으로 무효로만들 수 있다(요소 1418) - 예로서, 몇몇 버킷들의 모집단들이 증가될 수 있으며 및/또는 리필 레이트들은 그것들의 원래 값들로 회복될 수 있다. 이벤트 통지가 수신되기 전에 사용 중인 원래 파라미터들을 가진 버스트-모드 허가 제어가 몇몇 실시예들에서 재개될 수 있다. 적어도 몇몇 실시예들에서, 정상-모드(버스트-모드와 대조적으로) 허가 제어는 배경 또는 관리 이벤트들이 발생하는 동안 계속해서 영향을 미치지 않을 수 있다는 것이 주의된다. 적어도 몇몇 실시예들에서, 관리 이벤트 동안, 토큰들은 (가능하게는 수정된) 리필 레이트들에 따라 버스트-모드 버킷들에 계속해서 부가될 수 있다.

시간에 걸쳐, 주어진 작업 타겟에 대한 버스트-모드 관리 제어를 통제하는 파라미터들(리필 레이트들, 최대 버킷 모집단들 등) 중 적어도 일부는 수정될 필요가 있을 수 있다. 도 15는 적어도 몇몇 실시예들에 따라, 토큰-기반 버스트-모드 허가 제어를 위해 사용된 파라미터들을 조정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도들이다. 요소(1501)에서 도시된 바와 같이, 하나 이상의 작업 타겟들에 대한 작업 요청 도착률, 수용률 및/또는 거부율이 묘사된 실시예에서 모니터링될 수 있다(예로서, 허가 제어기에 의해, 또는 작업 타겟(들)을 구현한 서비스와 제휴된 최적화 엔진에 의해). 허가들, 거절들 및 도착률들에 관한 수집된 데이터는 예로서, 작업 타겟들로부터 수집되거나 또는 그것과 연관된 자원 사용 메트릭들과 함께, 분석될 수 있다. 분석이 버스트-모드 허가 제어를 통제하는 파라미터들이 변경되어야 함을 제안한다면(요소(1504)에서 결정된 바와 같이), 허가 제어기 또는 서비스의 다른 구성요소는 파라미터 변화들을 구현하는 비용들의 추정을 결정할 수 있다(요소 1508). 분석이 어떤 파라미터 변화들도 요구되지 않음을 제안한다면, 요소(1501)의 모니터링 동작들이 재개될 수 있다.

몇몇 경우들에서, 비용들(또는 클라이언트들에 청구될 수 있는 비용들의 적어도 일 부분)은 무시해도 될 정도이거나 또는 0일 수 있다. 이러한 시나리오에서, 파라미터 변화들은 그것들을 대신해서 작업 타겟이 설정되는 클라이언트와의 추가 상호 작용들 없이 이루어질 수 있다. 다른 경우들에서, 클라이언트 또는 클라이언트들은 제안된 파라미터 변화들의 잠재적 비용들 및 잠재적 이득들에 관해 통지될 수 있다(요소 1510). 클라이언트가 하나 이상의 버스트-모드 파라미터들에 대한 파라미터 변화 요청으로 응답한다면(요소 1512), 파라미터 변화들이 구현될 수 있다(요소 1516). 허가 제어기는 도착률들, 수용률들 및 거부율들을 모니터링하는 것을 재개할 수 있다(요소 1501). 몇몇 실시예들에서, 도 15에 표시된 것들과 유사한 허가 제어 파라미터 변화들은 요소들(1501 및 1504)에 표시된 모니터링된 메트릭들의 분석에 직접 관련되지 않은 이유들로 도입될 수 있다는 것이 주의된다. 예를 들면, 몇몇 실시예들에서, 클라이언트는 주어진 작업 타겟에 대한 프로비저닝된 스루풋에서의 변화를 요청할 수 있으며, 허가 제어 파라미터들(그것의 적어도 일부는 프로비저닝된 스루풋의 함수들일 수 있다)은 작업 타겟의 프로비저닝된 스루풋 변화 요청이 수용될 때 자동으로 변경될 수 있다. 다른 실시예들에서, 작업 타겟을 구현한 서비스의 관리자들은 유지 윈도우들, 업그레이드들, 장비 변화들 등과 같은, 다양한 다른 이유들로, 적어도 일시적으로, 허가 제어 파라미터들 중 적어도 일부를 변경할 수 있다. 단지 파라미터들의 서브세트만이 적어도 몇몇 실시예들에서 클라이언트들에 액세스 가능할 것이며, 따라서 파라미터 변화들에 대한 실질적인 관리 제어를 허용한다.

작업 타겟들에 걸친 토큰 공유

이전에 언급된 바와 같이, 적어도 몇몇 실시예들에서, 작업 요청들은 시간에 대해서뿐만 아니라, 또한 타겟팅된 특정 데이터 서브세트들에 대해서도 균일하지 않게 분배될 수 있다. 도 16은 적어도 몇몇 실시예들에 따라, 작업 요청 도착률들의 비-균일성과 조합하여, 서비스에 의해 관리된 데이터의 상이한 서브세트들에 대하여 작업 요청들의 비-균일한 분배의 예를 예시한다. 데이터 오브젝트(2010A)(예를 들면, 데이터베이스 테이블을 포함할 수 있다)는 묘사된 실시예에서, O1-P1, O1-P2 및 O1-P3으로 라벨링된 3개의 파티션들을 포함하는 반면, 다른 데이터 오브젝트(2010B)는 파티션(O2-P1)을 포함한다. 각각의 파티션은 PC1로 라벨링된 오브젝트들에 의해 표시된, 각각의 프로비저닝된 용량(예로서, 판독들/초, 기록들/초 등과 같은 초당 작업 요청들로 표현된)을 가진 별개의 작업 타겟으로 고려될 수 있다(파티션들(O1-P1, O1-P2, O1-P3 및 O1-P4)의 프로비저닝된 용량은 각각 PC1, PC2, PC3 및 PC4이다). 인입하는 작업 요청들을 수용할지 또는 거절할지에 관한 허가 제어 결정들은 파티션들의 각각에 대한 토큰 버킷들의 각각의 세트를 사용하여, 묘사된 실시예에서 파티션들의 각각에서 별도로 이루어진다. 몇몇 실시예들에서, 각각의 파티션은 예를 들면 정상-모드 및 버스트-모드 토큰 버킷들의 각각의 세트를 가질 수 있다. 데이터 오브젝트들(2010A 및 2010B)은 단일 클라이언트 엔티티에 의해 소유되거나 또는 그것에 할당될 수 있으며, 몇몇 세트의 클라이언트 애플리케이션들과 같은 공통 목적을 위해 사용될 수 있다; 따라서, 데이터 오브젝트의 소유자의 관점으로부터, 4개의 파티션들이 모두 동일한 데이터 세트의 부분으로 고려될 수 있다. 일반적으로 말해서, 4개의 파티션들은 크기에서(즉, 각각의 파티션에 포함된 데이터의 양에서) 및/또는 프로비저닝된 용량에서 서로 상이할 수 있다.

작업 요청들이 시간 윈도우(T0 내지 T1) 동안 파티션들 또는 작업 타겟들의 각각에 도착하는 레이트(W)는 도 16에 포함된 그래프들에서 도시된다. 화살표들(2051, 2052, 2053 및 2054)에 의해 표시된 바와 같이, 파티션들(O1-P1, O1-P2, O1-P3 및 O2-P1)에서 작업 요청 도착률은 각각 곡선들(W1, W2, W3 및 W4)에 의해 표현된다. 파티션들의 각각에 대한 프로비저닝된 용량이 또한 도시된다. O1-P1의 경우에, 작업 요청 도착률(W1)는 묘사된 시간 윈도우 동안 지속적으로 프로비저닝된 용량(PC1) 아래에 있다. O1-P2에 대해, 도착률(W2)는 많은 시간 기간(T0 내지 T1)에 대한 프로비저닝된 용량(PC2)을 초과하며; 따라서, O1-P2는 예시된 시간 기간의 대부분에 대해 버스트-모드에 남아있을 수 있다. O1-P3에 대해, 도착률은 일반적으로 프로비저닝된 용량(PC3)에 가까우며, O2-P1에 대한 도착률(W4)는 단지 간단히 프로비저닝된 용량(PC4)을 초과한다. O1-P2에서 작업 요청 거부율(R2)에 의해 표시된 바와 같이, 몇몇 수의 작업 요청들은, 예로서 허가 제어를 위한 버스트-모드 버킷들의 사용에도 불구하고, O1-P2에서 거절될 수 있다.

도시된 바와 같이, 상이한 파티션들로 타겟팅된 작업 요청들이 도착하는 레이트들은, 동일한 시간 간격 동안에도, 상당히 다를 수 있다. 몇몇 파티션들(예로서, O1-P1)은 심지어 그것들의 정상-모드 토큰들 모두까지 사용하지 않을 수 있지만, 동일한 오브젝트의(또는 동일한 소유자를 가진 상이한 오브젝트의) 다른 파티션들은 작업 요청들이 하나 이상의 버스트 모드 버킷들의 구현에도 불구하고 거절되어야 한다는 이러한 높은 작업부하를 가질 수 있다. 따라서, 묘사된 실시예에서, 4개의 파티션들은 토큰-공유 그룹(2002)의 멤버들로 간주될 수 있으며, 반복적 토큰-공유 프로토콜은 예시된 공간 비-균일성의 영향을 감소시키려고 노력하기 위해 그룹(2002) 내에서 구현될 수 있다.

토큰 공유 프로토콜은 토큰-공유 반복의 평가가 시도되어야 하는지를 결정하기 위해 트리거링되는(예로서, 규칙적 간격들로 또는 랜덤 양들의 시간 후) 파티션들 또는 작업 타겟들의 몇몇 수 또는 모두(예로서, 파티션들의 각각의 허가 제어기)를 야기할 수 있다. 즉, O1-P2와 같은 주어진 작업 타겟은, 토큰들이 교환될 수 있는 하나 이상의 파트너 작업 타겟들을 찾으려고 노력하기 위해, 그것의 현재 버킷 모집단들 및 최근의 워크로드를 고려해볼 때, 그것이 가치 있는지를, 다양한 기준들 중 임의의 것에 기초하여 결정할 수 있다. 결정이 토큰 고유를 평가하기 위해 이루어진다면, 작업 타겟은 프로토콜의 현재 반복을 위한 토큰-공유 개시자의 역할을 맡을 수 있으며, 하나 이상의 버킷 유형들에 대한 토큰 모집단 정보를 교환하는 하나 이상의 파트너 작업 타겟들(동일한 토큰-공유 그룹의 멤버들)을 식별할 수 있다. 개시자 및 파트너 피어의 토큰 모집단들의 분석 후, 몇몇 수의 토큰들이 개시자 및 수반된 제 2 피어 사이에서 하나의 방향 또는 다른 것으로 전달되어야 하는지에 대한, 제 2 결정이 이루어질 수 있다. 따라서, 예를 들면, 도 16에서, O1-P2는 개시자일 수 있으며, O1-P1과 버스트-모드 토큰 버킷에 관한 토큰 모집단 정보를 교환할 수 있다. O1-P2의 버스트-모드 버킷이 O1-P1의 대응하는 버스트-모드 버킷보다 훨씬 더 낮은 토큰 카운트를 가진다면, O1-P1 및 O1-P2는 O1-P1이 몇몇 수 N의 토큰들을 O1-P2로 전달해야 한다고 상호 결론을 내릴 수 있다. 따라서, N개의 토큰들은 O1-P2의 버킷에 부가될 수 있는 반면, N개의 토큰들은 O1-P1의 버킷으로부터 삭제될 수 있다. 토큰들의 부가는 도 16에 예시된 보다 높은 워크로드들을 유지하도록 O1-P2를 도울 수 있지만, O1-P1에서 토큰들의 감소는 O1-P1에서 보다 낮은 레이트의 요청들을 고려해볼 때 임의의 부정적 효과들을 갖지 않을 수 있다. 나중에, 토큰 공유 프로토콜의 후속 반복들에서, 필요하다면, 몇몇 다른 피어 작업 타겟은 어떤 작업 타겟이 심하게 로딩되게 되든 토큰들을 전달할 수 있으며; 예를 들면, O1-P2 자체는 나중에 다른 파티션들 중 임의의 것에 토큰들을 전달하기 위한 위치에 있을 수 있는 반면, O1-P1은 그것들을 다른 파티션들에 제공하는 대신에 결국 토큰들을 요청하게 될 수 있다. 논리적으로 전달될 토큰들의 정확한 수는 몇몇 실시예들에서, 예로서 토큰 모집단들에서의 차이에 기초하여, 및/또는 작업 타겟들 중 하나에 의해 요청된 토큰들의 양 등에 기초하여, 주어진 전달에 수반된 작업 타겟들 중에서 상호 동의에 의해 결정될 수 있다.

적어도 몇몇 실시예들에서, “가십 프로토콜(gossip protocol)”은 이러한 토큰 전달들을 위해 사용될 수 있다. 이러한 실시예에서, 각각의 작업 타겟은 랜덤 양의 시간 후 개시자로서 동작하며, 모집단 교환을 위한 상이한 작업 타겟을 식별하기 위해 랜덤 선택을 사용하도록 구성될 수 있다. 토큰 전달에(또는 심지어 토큰 모집단 교환에) 참여할지 여부에 대한 결정들은 몇몇 실시예들에서 각각의 작업 타겟에 의해 자율적으로 이루어질 수 있다. 토큰-공유 그룹에서의 멤버십은 상이한 실시예들에서 다양한 인자들에 기초하여 결정될 수 있다. 예를 들면, 몇몇 실시예들에서, 주어진 클라이언트(C1)는 그것의 데이터 오브젝트들(O1, O2, 및 O3)이 하나의 토큰-공유 그룹(G1)의 멤버들이라고 고려되고, 데이터 오브젝트들(O4 및 O5)이 다른 토큰-공유 그룹(G2)의 멤버들이라고 고려되는 반면, 데이터 오브젝트(O6)의 토큰들은 공유되지 않음을 표시할 수 있다. 몇몇 실시예들에서, 네트워크-액세스 가능한 서비스는 적어도 몇몇 토큰-공유 그룹 멤버십 결정들을 할 수 있는 반면, 다른 실시예들에서, 토큰-공유는 단지 클라이언트들로부터의 명시적 요청들에 응답하여 주어진 세트의 작업 타겟들에 대해 구현될 수 있다. 몇몇 실시예들에서, 여러 개의 상이한 클라이언트들이 그것들의 데이터 오브젝트들 중에서 필요에 따라 토큰들을 공유하기로 결정할 수 있으며 - 즉, 토큰 공유 그룹의 멤버들 모두가 동일한 클라이언트 엔티티(비즈니스 조직 또는 네트워크-액세스 서비스의 개개의 사용자와 같은)에 의해 소유되어야 하는 것은 아니다.

예시적인 토큰-공유 프로토콜 반복들

도 17은 적어도 몇몇 실시예들에 따라, 데이터 액세스의 공간 비-균일성의 결과들을 완화시키기 위해 구현될 수 있는 토큰-공유 프로토콜의 예시적인 반복들을 예시한다. 3개의 피어 작업 타겟들(예로서, 테이블 파티션들)(피어 A, 피어 B, 및 피어 C)은 예시된 예에서 동일한 토큰-공유 그룹의 멤버들이며, 각각은 토큰 공유에 수반된 단일 토큰 버킷(예로서, 버스트-모드 버킷, 또는 정상-모드 버킷)을 가진다. 3개의 피어들의 버킷들의 토큰 모집단은 프로토콜의 연속적인 반복들이 발생함에 따라 시간에 걸쳐 도시되며, 시간은 도면의 상부로부터 하부로 증가한다. 예를 간소화하기 위해, 앞으로 프로토콜의 반복(1)으로부터 시작하여, 리필 레이트들, 작업 요청들의 허가들, 또는 다른 인자들에 기인한 토큰 모집단 변화들이 무시되며, 단지 토큰-공유 프로토콜을 구현하는 것에 기인한 이들 토큰 모집단 변화들만이 포함된다.

도 17에 예시된 시간 기간의 처음에, 각각의 피어는 그것의 버킷에 1000개의 토큰들을 가진다. 화살표(2150)에 의해 표시된 인입하는 작업 요청들로 인해, 프로토콜의 제 1 반복이 시작하는 때에, 피어 A는 단지 50개의 토큰들을 갖는 반면, 피어 B 및 피어 C는 여전히 1000개의 토큰들을 가진다. 각각의 반복에서, 피어들 중 하나는 예시된 예에서 하나의 다른 피어와의 토큰 모집단 정보의 교환을 개시한다(다수의 피어 쌍들이 몇몇 실시예들에서 주어진 반복에 수반될 수 있으며; 단지 프로토콜의 작업의 간소화된 예만이 도 17에 제공된다). 수반된 두 개의 피어들은 그것들의 토큰 모집단들(P1 및 P2)을 비교하며, (잠깐 동안 P1 > P2임을 가정하면), 보다 많은 토큰들을 가진 피어로부터 보다 적은 토큰들을 가진 피어로 (P1-P2)/2 토큰들(정수로 반올림된)을 전달하기로 결정한다. 다양한 구현들에서, 전달된 토큰들의 수는 다양한 상이한 인자들에 기초하여 결정될 수 있으며, 예로서 (P1-P2)/2가 아닌 다른 공식 또는 함수가 사용될 수 있다.

따라서, 예시된 예에서 반복 1 동안, 피어 C(1000개의 토큰들을 가진)는 피어 A(50개 토큰들)와의 모집단 교환을 개시하며, 토큰 전달 크기는 (1000-50)/2 = 475로서 결정된다. 475개 토큰들은 따라서 피어 A의 버킷에 부가되지만, 475개 토큰들은 피어 C로부터 피어 A로 화살표에 의해 표시된 바와 같이, 피어 C의 버킷으로부터 제거된다. 전달 후, 피어 A 및 피어 C 양쪽 모두는 525개 토큰들을 가진다.

반복 2에서, 토큰 모집단 정보는 개시자로서 동작하는 피어 B(1000개 토큰들), 및 피어 A(525개 토큰들) 사이에서 교환되어, 피어 B로부터 피어 A로 (1000-525)/2 또는 대략 237개 토큰들의 전달을 야기한다. 그 결과, 피어 A는 이제 총 763개 토큰들을 가지며 피어 B는 762를 가진다. (피어 A 및 B에서 토큰들의 수는 부분 토큰들이 묘사된 실시예에서 지원되지 않기 때문에 반복 2의 끝에서 1만큼 상이하다. 다른 실시예들에서, 부분 토큰 카운트들이 지원될 수 있으며, 이 경우에 피어 A 및 피어 B 양쪽 모두는 결국 762.5 토큰들이 될 수 있다.)

반복 3에서, 피어 A(763개 토큰들) 및 피어 C(525개 토큰들)는 다시 토큰 모집단들을 교환하며, 피어 A는 피어 C에 (763-525)/2 또는 119개 토큰들을 전달한다. 반복 4에서, 피어 B(762개 토큰들)는 59개 토큰들을 피어 C(644 토큰들)에 전달하며, 반복 5에서, 피어 B(703 토큰들)는 피어 A(644 토큰들)에 29개 토큰들을 전달한다. 부가적인 반복들(도시되지 않음)은 보다 많은 토큰들을 가진 피어들로부터 보다 적은 토큰들을 가진 피어들로 토큰들의 추가 전달들을 야기할 수 있다. 도 17에 예시된 예시적인 반복들은 보다 일반적으로 또는 다른 실시예들에 반드시 적용 가능한 프로토콜 규칙들을 커버하기 위해서가 아닌, 묘사된 실시예에서 사용 중인 특정한 토큰 공유 프로토콜의 고-레벨 특성들을 예시하도록 의도된다는 것이 주의된다.

정확하게 언제 및 어떤 상황들 하에서 주어진 작업 타겟이 토큰 모집단 교환을 개시하는지, 어떤 다른 작업 타겟들과 모집단 교환이 행해져야 하는지, 및 얼마나 많은 토큰들(만약에 있다면)이 전달되어야 하는지를 결정하기 위해 어떤 기준들이 사용되어야 하는지에 관한 결정들은 모두 상이한 실시예들에서 상이한 세트들의 기준들에 기초하여 이루어질 수 있다. 몇몇 실시예들에서, 예를 들면, 허가 제어기 또는 주어진 작업 타겟에서의 다른 서비스 관리 구성요소가 상기 작업 타겟에서의 거부율이 임계치 이상임을 발견한다면, 토큰-공유 프로토콜의 새로운 반복이 개시될 수 있다. 다른 실시예들에서, 몇몇 세트의 버킷들(예로서, 버스트-모드 버킷에서)에서의 토큰 카운트가 임계치 아래로 떨어진다면, 토큰-공유 프로토콜의 새로운 반복이 개시될 수 있다. 몇몇 구현들에서, 상기 언급된 바와 같이, 프로토콜의 반복들은 랜덤하게-선택된 작업 타겟들로부터 랜덤한 시간들에서 개시될 수 있으며, 모집단 정보가 교환되는 작업 타겟은 또한 랜덤하게 선택될 수 있다. 적어도 일 실시예에서, 연속적인 토큰-공유 프로토콜 반복들을 너무 빈번하게 구현함으로써 야기된 잠재적 오버헤드를 감소시키기 위해, 토큰 공유를 위한 스로틀링 정책이 시행될 수 있으며, 따라서 예를 들면 주어진 작업 타겟이 X 초들 또는 분들 내에서 임의의 다른 작업 타겟으로 전달하고, 및/또는 그로부터 수신할 수 잇는 최대 수의 토큰들은 몇몇 수(Tmax)에 제한된다. 다른 스로틀링 정책들은 동일한 쌍의 작업 타겟들 사이에서의 앞뒤 토큰 전달들을 몇몇 최대 레이트에 제한하는 것과 같은, 다른 구현들에서 이용될 수 있으며 - 예로서, 작업 타겟들(WT1 및 WT2)은 매 15분들마다 최대 K개의 토큰 전달들에 참여하도록 허용될 수 있다. 몇몇 경우들에서, 시간(Tk)에서 새로운 토큰 전달은 상이한 토큰 전달이 Tk 전 특정 시간 윈도우 내에서 발생하였다면 한 쌍의 작업 타겟들(WT1 및 WT2) 사이에서 허용되지 않을 수 있다.

도 17에 도시된 예에서, 전달된 토큰들의 수는 간단히 보다 높은 토큰 모집단을 가진 피어 및 보다 낮은 토큰 모집단을 가진 피어 사이에서의 차이의 절반으로서 계산된다. 다른 실시예들에서, 전달 크기들은 다른 인자들에 기초하여 결정될 수 있으며 - 예로서, 각각의 작업 타겟은 토큰 전달들에 대하여 최소 토큰 모집단을 가질 수 있거나(따라서 최소 레벨이 도달된다면, 다른 작업 타겟이 보다 낮은 토큰 카운트를 가질지라도 어떤 토큰들도 전달될 수 없다), 또는 전달된 토큰들의 수는 작업 타겟에서 최근의 워크로드 레벨에, 또는 작업 타겟에서 프로비저닝된 용량에 적어도 부분적으로 기초할 수 있다. 다른 작업 타겟들로의 토큰들의 증여는 적어도 몇몇 실시예들에서 자발적일 수 있고 - 예로서, 주어진 작업 타겟(WT1)이 그것의 피어들(WT2) 중 하나보다 훨씬 더 많은 토큰들을 가질지라도, WT1은 WT2로 임의의 토큰들을 전달하도록 강요되지 않을 수 있다(예를 들면, 작업 요청들의 많은 버스트가 WT1에서 가까운 미래에 예상될 수 있으며, 따라서 다른 작업 타겟들에 토큰들을 전달하는 것은 적절하지 않을 수 있다).

데이터 복제 역할들을 지원하는 환경들에서의 토큰-공유

몇몇 실시예들에서, 이전에 언급된 바와 같이, 데이터베이스 서비스 또는 저장 서비스는 클라이언트의 데이터의 다수의 복제본들을 저장할 수 있으며, 상이한 복제본들은 작업 요청들의 허가 제어에 대하여 상이한 역할들을 가질 수 있고 - 예로서, 작업 요청들이 판독들 및 기록들을 포함할 수 있는 환경들에서, 몇몇 복제본들은 판독들뿐만 아니라 기록들에 대한 허가 제어에 책임이 있을 수 있는 반면, 다른 복제본들은 단지 판독들을 다룰 수 있다. 이러한 실시예들에서, 토큰-공유 프로토콜들이 구현되는 피어 작업 타겟들의 그룹은 복제 역할들에 의해 적어도 부분적으로 결정될 수 있다. 도 18은 적어도 몇몇 실시예들에 따라, 데이터 파티션들이 복제되는 환경에서 수립될 수 있는 토큰 공유 피어 그룹들의 예들을 예시한다.

오브젝트들(2201A, 2201B, 2201C 및 2201D)과 같은, 데이터 오브젝트들(2201)(예로서, 데이터베이스 테이블들 또는 저장 볼륨들)은 각각 하나 이상의 논리 파티션들을 포함할 수 있으며, 논리 파티션들의 각각에 대응하여, 둘 이상의 물리적 복제본들이 서비스의 데이터 내구성 요건에 따라 저장될 수 있다. 물리적 복제본들 중 하나는 묘사된 실시예에서 “마스터”복제본(또는 간단히 마스터)으로 칭하여질 수 있으며, 나머지 복제본들은 “슬레이브”복제본들(또는 간단히 슬레이브들)로 칭하여질 수 있다. 마스터 복제본은 기록들을 포함하는 작업 요청들에 대한 허가 제어를 책임질 수 있지만, 판독 요청들은 묘사된 실시예에서 복제본들 중 임의의 것(슬레이브 복제본(들)뿐만 아니라 마스터)에서의 실행을 위해 수용될 수 있다. 따라서, 주어진 논리 파티션으로 향해진 기록 요청은 마스터 복제본으로 향해질 수 있으며, 여기에서 기록을 수용할지 또는 거절할지에 대한 결정이 이루어질 수 있다. 기록이 수용된다면, 대응하는 데이터 수정들이 먼저 마스터에서 수행될 수 있으며, 그 후 슬레이브들로 전파된다. 판독 요청들은 도 18에 도시된 실시예에서 복제본들 중 임의의 것으로 향해질 수 있다 (및 그 결과, 슬레이브에서 판독된 데이터 중 일부는 가장 최근의 기록 요청들에 대하여 약간 오래되었을 수 있으며, 그것의 변화들은 슬레이브에서 복제되지 않을 수 있다). 각각의 물리적 복제본은 허가 제어를 위해 연관된 세트의 토큰 버킷들을 가질 수 있다 -예로서, 마스터 복제본들에 대한 마스터 버킷 세트 및 각각의 슬레이브 복제본에 대한 슬레이브 버킷 세트. 주어진 물리적 복제본에 할당된 “마스터” 및 “슬레이브” 역할들은 시간에 걸쳐 변할 수 있다 - 예로서, 마스터에 대한 연결성의 실패 또는 손실로 인해, 슬레이브는 마스터 역할에 대해 촉진될 수 있다. 다른 실시예들에서, 마스터 및 슬레이브 역할들과 연관된 책임들은 다를 수 있다 - 예로서, 몇몇 실시예들에서, 판독들에 대한 허가 제어가 또한 마스터에서 수행될 수 있다.

도 18에 도시된 실시예에서, 데이터 오브젝트(2201A)는 논리 파티션들(O1-P1, O1-P2, 및 O1-P3)을 가진다. 주어진 논리 파티션(Ox-Py)에 대한 마스터 복제본들은 Ox-Py-M로 라벨링되는 반면, 제 k 슬레이브 복제본은 Ox-Py-Sk로 라벨링된다. O1-P1-M으로 라벨링된, O1-P1에 대한 마스터 복제본은 서비스의 저장 노드(2210A)에 부착된 저장 디바이스(2202A) 상에 위치된다. O1-P1-S1로 라벨링된, O1-P1에 대한 슬레이브 복제본은 저장 노드(2210B)에서의 저장 디바이스(2202B)에 위치된다. 데이터 오브젝트(2201B)는 논리 파티션들(O2-P1 및 O2-P2)을 갖고, 데이터 오브젝트(2201C)는 논리 파티션들(O3-P1 및 O3-P2)을 갖는 반면, 데이터 오브젝트(2201D)는 n개의 논리 파티션들(O4-P1…O4-Pn)을 가진다. 일반적으로, 데이터 내구성에 대해, 동일한 논리 파티션들의 다수의 복제본들은 묘사된 실시예에서 동일한 저장 디바이스 또는 동일한 저장 노드 상에 저장되지 않을 수 있다. 이러한 내구성-도출 제약들을 제외하고, 복제본들은 일반적으로 묘사된 실시예에서 이용 가능한 충분한 공간을 가진 임의의(예로서, 랜덤하게 선택된) 저장 디바이스 또는 저장 노드 상에 저장될 수 있다. 예를 들면, 저장 디바이스(2202A)는 또한 데이터 오브젝트(2201B)의 논리 파티션(O2-P1)의 슬레이브 복제본(O2-P1-S1) 및 데이터 오브젝트(2201C)의 논리 파티션(O3-P1)의 슬레이브 복제본(O3-P1-S2)을 포함하는 반면, 저장 디바이스(2202B)는 슬레이브 복제본(O4-P2-S2) 및 마스터 복제본(O2-P1-M)을 포함하며, 저장 디바이스(2202C)는 또한 저장 노드(2210B)에서, 마스터 복제본(O1-P3-M) 및 슬레이브 복제본들(O2-P1-S1 및 O4-P1-S1)을 포함한다. (공간 한계들로 인해, 데이터 오브젝트들(2201A-2201D)의 파티션들 중 일부의 복제본들 중 단지 일부만이 도 18에 있다.

각각의 물리적 복제본은, 슬레이브인지 또는 마스터인지에 관계없이, 복제본으로 향해진 작업 요청들의 허가 제어를 위해 각각의 세트의 토큰 버킷들을 가진다. 예를 들면, 마스터 복제본들(O1-P1-M, O2-P1-M 및 O1-P3-M)은 각각의 마스터 버킷 세트들(2252A, 2252B 및 2252C)을 가진다. 저장 디바이스(2202A)에서 슬레이브들(O2-P1-S1 및 O3-P1-S2)은 슬레이브 버킷 세트들(2272A 및 2272B)을 갖는 반면, 슬레이브들(O1-P1-S1 및 O4-P2-S2)은 슬레이브 버킷 세트들(2272C및 2272D)을 가지며, 슬레이브들(O2-P2-S1 및 O4-P1-S1)은 슬레이브 버킷 세트들(2272E 및 2272F)을 가진다. 각각의 버킷 세트는 예를 들면 하나 이상의 정상-모드 토큰 버킷들 및/또는 버스트-모드 토큰 버킷들을 포함하여(몇몇 경우들에서, 복합 버스트-모드 토큰 버킷들을 포함하여), 이전에 설명된 것들과 유사한 하나 이상의 토큰 버킷들을 포함할 수 있다. 별개의 토큰 버킷들이 판독들 및 기록들을 위해 구성되는 몇몇 실시예들에서(예로서, 도 5에 예시된 바와 같이) 슬레이브들은 기록들을 위해 허가 제어에 참여하지 않고, 슬레이브 버킷 세트들(2272)은 단지 판독 토큰 버킷들만을 포함할 수 있는 반면, 마스터 버킷 세트들(2252)은 판독 및 기록 버킷들 양쪽 모두를 포함할 수 있다.

마스터 및 슬레이브 역할들은 상이한 허가 제어 책임들에 대응할 수 있으므로, 묘사된 실시예에서, 주어진 마스터 복제본은 단지 다른 마스터들과의 토큰-공유 프로토콜에 참여하도록 허용될 수 있으며, 유사하게, 슬레이브 복제본은 단지 다른 슬레이브들과 토큰들을 공유할 수 있다. 따라서, 도 18에 예시된 복제본들은 두 개의 토큰-공유 피어 그룹들(2242A 및 2242B)로 분할될 수 있다. 토큰-공유 피어 그룹(2242A)은 마스터들(O1-P1-M, O2-P1-M 및 O1-P3-M)과 같은, 몇몇 세트의 데이터 오브젝트들의 마스터 복제본들을 포함할 수 있다. 도 18에 도시되지 않은, 오브젝트들(2201A 내지 2201D)의 다른 마스터 복제본들이 또한 그룹(2242A)에 포함될 수 있다. 토큰-공유 피어 그룹(2242B)은 슬레이브들(O2-P1-S1, O3-P1-S2, O1-P1-S1, O4-P2-S2, O2-P2-S1 및 O4-P1-S1)(도 18에 도시되지 않은 다른 슬레이브 복제본들뿐만 아니라)을 포함할 수 있다. 따라서, 묘사된 실시예에서, 마스터 복제본들은 다른 마스터들과 토큰 모집단 정보를 교환하고, 그것으로/그로부터 토큰들을 전달할 수 있으며, 슬레이브 복제본들은 다른 슬레이브들과 토큰 모집단들 및/또는 토큰들을 교환할 수 있다. 이러한 제한들은 슬레이브에서 토큰의 값에 대한 마스터에서의 토큰의 값에 대한 가정, 예를 들면, - 예로서, 마스터들이 슬레이브들보다 더 많은 허가 제어 책임들을 갖기 때문에, 마스터에서 토큰을 잃거나 또는 얻는 것은 슬레이브에서 토큰을 잃거나 또는 얻는 것과 상이한 영향을 가질 수 있다는 가정을 반영할 수 있다. 몇몇 실시예들에서, 이러한 역할-기반 제한들은 강요되지 않을 수 있으며, 따라서 마스터들은 또한 또는 대신에 토큰들을 슬레이브들로 전달할 수 있으며 그 역 또한 마찬가지이다.

2차 인덱스들에 대한 토큰-공유

몇몇 실시예들에서, 토큰-기반 허가 제어는 최근에 인기를 얻은 다양한 유형들의 “NoSQL” 서비스들 중 임의의 것과 같은, 비-관계형 데이터베이스 서비스들에 대해 구현될 수 있다. 많은 이러한 데이터베이스 서비스들에서, 주어진 테이블의 상이한 로우들은 일반적으로 상이한 세트들의 컬럼들을 가질 수 있다. 따라서, 적어도 몇몇 경우들에서, 각각의 로우는 (기본-키(primary-key), 값) 쌍으로 고려될 수 있으며, 여기에서 기본-키 구성요소는 기본 인덱스를 위해 사용되는 반면, 값 구성요소는 각각의 컬럼들에 대응하는 값들의 몇몇 임의의 모음을 포함할 수 있다. 많은 경우들에서, 클라이언트들은 그것들의 비-관계형 데이터에 대한 2차 인덱스들, 즉 기본 키가 아닌 컬럼들 상에서의 인덱스들을 이용하고 싶어할 수 있다. 이러한 2차 인덱스들은 몇몇 실시예들에서 도출된 테이블들을 사용하여 구현될 수 있으며 - 예로서 주어진 테이블(베이스 테이블로서 불리울 수 있는)에 대응하는 데이터의 적어도 몇몇 서브세트가 또한 2차 인덱스를 통한 고속 액세스를 지원하기 위해 도출된 테이블로서 조직될 수 있다. 몇몇 경우들에서, 베이스 테이블의 컬럼들 모두가 도출된 테이블에서 복제될 수 있는 것은 아니다. 하나 이상의 2차 인덱스들을 위해 사용된 베이스 테이블 및 도출된 테이블들은 각각 몇몇 실시예들에서 허가 제어를 위해 각각의 토큰 버킷들을 가진 하나 이상의 논리적 및/또는 물리적 파티션들을 포함할 수 있다. 몇몇 실시예들에서, 베이스 테이블의 파티션들 및 도출된 테이블들의 파티션들은 상기 설명된 프로토콜들과 유사한 토큰-공유 프로토콜에 피어들로서 참여할 수 있다. 몇몇 구현들에서, 별개의 2차 인덱스들(및 별개의 도출된 테이블들)은 베이스 테이블의 각각의 서브세트들(예로서, 각각의 파티션들)에 대해 설정될 수 있다. 다른 구현들에서, 단일 도출 테이블은 베이스 테이블의 파티션들 모두에 대응하는 데이터를 포함한, 주어진 2차 인덱스에 대해 설정될 수 있으며; 나중 시나리오에서, 2차 인덱스는, 전체 베이스 테이블(베이스 테이블의 서브세트라기보다는)에 대응하는 데이터가 액세스될 수 있으므로, “전역적 2차 인덱스(global secondary index)” 또는 GSI로서 칭하여질 수 있다.

도 19는 적어도 몇몇 실시예들에 따라, 2차 인덱스들에 대한 작업부하 관리를 지원하기 위해 데이터베이스 서비스에서 토큰 공유의 사용의 예를 예시한다. 묘사된 실시예에서, 베이스 테이블(2310)은 N개의 파티션들(BT-P1, BT-P2, …, BT-PN)을 포함한다. 도출된 테이블(2320)은 베이스 테이블 상에서 GSI를 지원하기 위해 설정되었으며, 도출된 테이블은 파티션들(GSIT-P1, GSIT-P2, …,GSIT-PQ)을 포함한다. 몇몇 구현들에서, 베이스 테이블(base table)(2310) 및/또는 도출된 테이블(2320)의 파티션들은, 복제본들이 도 19에 도시되지 않을지라도, 데이터 내구성을 위해 복제될 수 있다. 일반적으로, 상이한 도출된 테이블은 주어진 베이스 테이블에 대해 설정된 각각의 GSI를 위해 생성될 수 있다. 베이스 테이블의 각각의 파티션, 및 도출된 테이블의 각각의 파티션은, 베이스 테이블 파티션들에 대해 BTPC1, BTPC2,…로 라벨링된 요소들 및 도출된 테이블에 대해 SIPC1, SIPC2,…로 라벨링된 요소들에 의해 표시된 바와 같이, 각각의 프로비저닝된 용량을 가진다. 허가 제어 결정들은 묘사된 실시예에서 어느 하나의 테이블의 파티션들의 각각에 대해 독립적으로 이루어질 수 있으며, 각각의 파티션은 토큰 버킷들의 세트(하나 이상의 정상-모드 및/또는 버스트-모드 토큰 버킷들과 같은)를 가질 수 있다. 몇몇 경우들에서, 상이한 유형들의 버킷들은 도출된 테이블에 대한 것보다 베이스 테이블에 대해 구현될 수 있지만 - 예로서 베이스 테이블은 복합 버스트-모드 버킷을 사용할 수 있지만, 도출된 테이블은 간단한(비-복합) 버스트-모드 버킷을 사용할 수 있다.

적어도 몇몇 실시예들에서, 클라이언트 기록 요청들에 대응하는 업데이트들은 먼저 베이스 테이블에서 이루어질 수 있으며, 그 후 도출된 테이블로 전파된다. 예를 들면, 업데이트 발송 버퍼(send buffer)들은 파티션(BT-P1)에 대한 업데이트 발송 버퍼(2325A), 파티션(BT-P2)에 대한 업데이트 발송 버퍼(2325B), 파티션(BT-P3)에 대한 업데이트 발송 버퍼(2325C), 및 파티션(BT-PN)에 대한 업데이트 발송 버퍼(2325N)와 같은, 베이스 테이블 파티션들의 각각에 대해 수립될 수 있다. 베이스 테이블 파티션들에 대해 이루어진 업데이트들은 대응하는 발송 버퍼들에서 전파(화살표(2350)에 의해 표시된 바와 같이)를 위해 큐잉되며, 결국 도출된 테이블의 데이터에 적용되기 전에 도출된 테이블 파티션들에서 대응하는 업데이트 수신 버퍼들(2330)(예로서, 수신 버퍼들(2330A, 2330B, 2330C 및 2330Q))에서 수신될 수 있다. 일반적으로, 베이스 테이블 및 도출된 테이블의 파티션들 사이에서의 1-대-1 매핑이 없을 수 있지만 - 예로서, 파티션(BT-P1)에서 주어진 업데이트가 도출된 테이블 파티션(GSIT-P3)에서 수정될 데이터를 요구할 수 있지만, 파티션(BT-P1)에서 상이한 업데이트가 GSIT-P1에 대한 수정을 야기할 수 있다. 먼저 베이스 테이블에 및 그 후 도출된 테이블에 적용되는 기록들과 대조적으로, 판독들은 판독 요청의 특징에 의존하여, 베이스 테이블을 참조하지 않고 도출된 테이블로부터 만족될 수 있지만 - 예로서, GSI의 키들에 대하여 프레이밍되는 판독 질의는 도출된 테이블을 사용하는 것에 응답될 수 있지만, 다른 키들에 기초한 판독 질의는 베이스 테이블 또는 도출된 테이블을 사용하는 것에 응답될 수 있다.

프로비저닝된 용량들은 적어도 몇몇 실시예들에서 서로에 독립적으로 베이스 테이블 및 도출된 테이블에 할당될 수 있다. 따라서, 일 실시예에서, 클라이언트가 테이블 생성을 요청할 때, 클라이언트는 베이스 테이블에 대한 프로비저닝된 용량을 특정할 수 있으며 다음과 유사한 문장의 논리적 등가물을 사용하여, 수립될 GSI(들)의 표시를 제공한다:

해시-키(k1), 초당-판독들=12, 초당-기록들=8을 가진 테이블(T1) 생성,

해시-키(k2)를 가진 전역적 인덱스(G1);

이 예에서, 베이스 테이블(T1)은 초당 12개의 판독들 및 초당 8개의 기록들의 프로비저닝된 스루풋을 갖고, 기본 키(이 경우에, 해시-키)(k1)를 갖고 생성된다. 클라이언트는 또한 전역적 2차 인덱스(G1)가 상이한 해시-키(k2)를 갖고 생성되지만, GSI에 대한 프로비저닝된 스루풋을 특정하지 않음을 표시한다. 이러한 시나리오에서, 데이터베이스 서비스는 클라이언트에 의해 특정된 베이스 테이블에 대한 총 프로비저닝된 스루풋에 기초하여 베이스 테이블 파티션들에 프로비저닝된 스루풋을 할당할 수 있으며, 추가 클라이언트 상호 작용 없이 도출된 테이블의 파티션들(GSI를 위해 사용된)에 대한 프로비저닝된 스루풋을 할당해야 할 수 있다. 데이터베이스 서비스는 다양한 실시예들에서 도출된 테이블 파티션의 프로비저닝된 용량을 결정하기 위해 다수의 상이한 접근법들 중 임의의 것을 사용할 수 있다.

이 예의 목적들을 위해, 두 개의 파티션들(BT-P1 및 BT-P2)이 베이스 테이블을 위해 설정되며, 두 개의 파티션들(GSIT-P1 및 GSIT-P2)이 인덱스(G1)를 지원하기 위해 도출된 테이블에 대해 설정된다고 가정하자. 일 접근법에서, 클라이언트에 의해 표시된 총 프로비저닝된 용량은 함께 취해진 도출된 테이블뿐만 아니라 베이스 테이블 양쪽 모두에 대해 핸들링될 판독들 및 기록들의 수를 표현하기 위해 가정될 수 있다. 이 경우에, 12 판독들/초는 BT-P1, BTR-P2, GSIT-P1, 및 GSIT-P2의 각각에서 3 판독들/초로 분할될 수 있으며, 8 기록들/초는 유사하게 4개의 파티션들의 각각에서 2 기록들/초로 분할될 수 있다. 다른 접근법에서, 데이터베이스 서비스는 클라이언트의 요청된 프로비저닝된 용량이 단지 베이스 테이블에만 적용하며, 부가적인 판독들 및 기록들은 도출된 테이블의 파티션들에 대해 프로비저닝된다고 가정할 수 있다. 이러한 제 2 접근법에서, BT-P1 및 BT-P2는 각각 6 판독들/초 및 4 기록들/초의 프로비저닝된 용량들을 할당받을 수 있는 반면, GSIT-P1 및 GSIT-P2는 각각 “v” 판독들/초 및 “w” 기록들/초의 프로비저닝된 용량들을 할당받을 수 있고, 여기에서 v 및 w는 몇몇 휴리스틱스에 기초하여 또는 유사한 GSI들을 가진 이전 경험에 기초하여 추정될 수 있다.

몇몇 실시예들에서, 클라이언트들은 GSI들에 대해 명시적으로 프로비저닝된 용량들을 특정(및 지불)하기 위해 인에이블될 수 있으며, 예로서 클라이언트는 테이블이 생성되는 것을 요청할 때 다음의 논리적 등가물을 특정할 수 있다:

해시-키(k1), 초당-판독들=12, 초당-기록들=8을 가진 테이블(T2)을 생성,

해시-키(k), 초딩-판독들=6, 초당-기록들=6을 가진 전역적 인덱스(G2);

이 예에서, 클라이언트는 베이스 테이블에 대한 프로비저닝된 판독 및 기록 레이트들로부터 별도로 GSI에 대한 원하는 프로비저닝된 판독 및 기록 레이트들을 표시하며, 데이터베이스 서비스는 베이스 테이블 및 도출된 테이블의 파티션들에 프로비저닝된 용량들을 그에 따라 할당할 수 있다. 몇몇 구현들에서, 해시 키들(예로서, 범위 키들)이 아닌 다른 인덱스 키들이 또한 또는 대신에 특정될 수 있다는 것이 주의된다. 적어도 일 실시예에서, GSI들은 기존의 테이블들에 대해 생성될 수 있으며, 예로서 클라이언트들은 베이스 테이블이 생성될 때 그것들이 요구하는 GSI들의 세트에 대해 결정할 필요가 없을 수 있다.

시간에 걸쳐, 베이스 테이블의 파티션들 및 도출된 테이블들의 파티션들에 대한 워크로드는 상당히 달라질 수 있으며, 주어진 시간 간격 동안, 판독 및/또는 기록 요청들은 양쪽 유형들 모두의 테이블들의 파티션들에 걸쳐 균일하지 않게 분배될 수 있다. 공간 비-균일성의 부정적 영향들(작업 요청 거절들과 같은)을 감소시키기 위해, 베이스 테이블(2310) 및 도출된 테이블(2320)의 파티션들 모두는 단일 토큰-공유 피어 그룹(2342)의 멤버들로 만들어졌다. 파티션들(BT-Px 및 GSIT-Py)의 각각은 따라서 그것들 각각의 토큰 버킷들에 대한 토큰 모집단들의 교환에, 및 상호 합의에 기초하여, 이전 설명된 바와 같이 토큰 전달들에 참여할 수 있다.

예시적인 토큰-공유 메시지 시퀀스들

도 20a 내지 도 20d는 적어도 몇몇 실시예들에 따라, 토큰-공유 프로토콜에서의 참여자들 사이에서 메시지 시퀀스 흐름들의 예들을 예시한다. 이전 설명된 바와 같이, 토큰 공유 프로토콜은 하나의 작업 타겟(예로서, 테이블 파티션)이 제 2 작업 타겟과의 토큰 모집단 정보의 교환을 개시하는 것, 이어서 잠재적으로 상호 합의 후 토큰들의 논리적 전달(즉, 전달되는 임의의 토큰 오브젝트들 없이 양쪽 작업 타겟들 모두에서 토큰 모집단들에서의 변화들)을 수반할 수 있다. 모집단 정보 교환을 개시하는 작업 타겟은 “토큰-공유 개시자 피어(token-sharing initiator peer)” 또는 TSIP로 칭하여질 수 있는 반면, 모집단 정보의 수신인은 여기에서 “토큰-공유 파트너 피어(token-sharing partner peer)” 또는 TSPP로 칭하여질 수 있다. 도 20a 내지 도 20d에 도시된 실시예에서, 적어도 3개의 유형들의 메시지들이 TSIP(2402) 및 TSPP(2405) 사이에서 흐를 수 있다: 토큰 공유 요청 메시지(TSReq), 토큰 공유 수용 메시지(TSAcc), 및 토큰 공유 거절 메시지(TSRej).

도 20a에 묘사된 상호 작용에서, TSIP(2402)는 TSReq 메시지(2410)를 선택된 TSPP(2405)에 전송한다. TSReq 메시지(2410)는 TSIP(2402)에서 특정한 버킷(예로서, 버스트-모드 버킷)의 토큰 모집단의 표시를 포함할 수 있다. 몇몇 구현들에서, TSReq 메시지는 또한 TSIP가 획득하고 싶어하는 부가적인 수의 토큰들의 표시, 또는 몇몇 경우들에서, TSIP가 기꺼이 TSPP(2405)에 제공하는 토큰들의 수의 표시를 포함할 수 있다. 이에 응답하여, TSPP(2405)는 수용 메시지(TSAcc)(2420)를 전송한다. TSAcc 메시지(2420)는 예를 들면, TSPP에서 토큰 모집단, 및/또는 TSPP(2405)가 기꺼이 TSIP(2402)에 제공하는 토큰들의 수(또는 TSPP가 기꺼이 TSIP로부터 수용하는 토큰들의 수)를 표시할 수 있다. TSReq 및 TSacc가 교환된 후, TSIP 및 TSPP 양쪽 모두는 묘사된 실시예에서 전달 시-상호-합의에 따라 그것들의 토큰 모집단들을 수정할 수 있다.

도 20b에 묘사된 상호 작용에서, TSIP(2402)는 유사한 TSReq 메시지(420)를 전송하지만, 이 경우에, TSPP(2405)는, 제안된 토큰 전달이 TSPP에 의해 수용 가능하지 않음을 표시하는 거절 메시지(TSRej)(2430)를 TSIP로 다시 전송한다. 따라서, TSIP(2402)의 요구들에 의존하여, TSIP는 몇몇 다른 파트너 피어와의 토큰 교환을 개시하려고 노력할 수 있거나, 또는 토큰 공유 프로토콜의 다른 반복을 개시하기 전에 얼마 동안 대기할 수 있다. 몇몇 구현들에서, 특정한 시간 윈도우 내에서 TSPP로부터 TSReq 메시지로의 응답의 부재는 거절의 등가로 간주될 수 있다. 일 구현에서, TSIP(2402)는 TSPP(2405)가 요청된 토큰 전달을 위해 이용 가능하지 않음을 가정하기 전에 몇 회 TSReq 메시지를 재전송할 수 있다.

도 20c에서, TSPP(2402)는 동일한 유형의 정보(예로서, TSPP의 토큰 모집단, 및 선택적으로 요청된 토큰 전달의 특징 또는 크기의 표시)를 포함한 그것의 TSReq(2410A)를 TSPP(2405)에 전송한다. TSPP(2405)는 요청을 수신하며, 반대-제안, 즉 TSReq(2410A)에 표시된 것과 상이한 전달에 대한 요청을 하는 것으로 결정한다. 따라서, TSPP(2405)는 TSPP의 토큰 모집단을 표시하는 상이한 TSReq(2410B), 및 TSPP가 전달되기를 원하는 토큰들의 방향 및 양의 표시를 되돌려 보낸다. TSIP(2402)는 TSReq(2410A)를 수신하며, 수정된 전달을 수용하기 위해 TSAcc 메시지(2420)를 전송하고, 두 개의 측면들은 그에 따라 그것들의 토큰 모집단들을 조정할 수 있다.

도 20d에서, TSPP(2402)는 그것의 TSReq(2410A)를 전송하며, TSPP는 도 20c에 도시된 것과 유사한 방식으로 그 자신의 TSReq(2410B)를 되돌려 보낸다. 이 경우에, TSIP(2402)는 TSReq(2410B)를 거절하며, 거절을 TSPP(2405)에 알리기 위해 거절 메시지(TSRej)(2430)를 전송한다.

상이한 실시예들에서, 도 20a 내지 도 20d에 도시된 상호 작용들의 유형들의 변형들 및 강화들이 구현될 수 있다는 것이 주의된다. 예를 들면, 몇몇 실시예들에서, 수용의 부가적인 확인은 TSAcc 메시지가 전송된 후 되돌려 보내어질 수 있다. 일 구현에서, TSRej 거절 메시지를 전송할 때, 전송자는 다른 작업 타겟들이 거절된 토큰 전달을 위한 양호한 후보일 수 있는 것에 관한 힌트들을 수신자에 전송할 수 있다(예로서, 다른 작업 타겟들과의 최근 통신들에 기초하여). 다른 구현에서, TSIP는 그것의 TSReq 메시지에, 전달될 원하는 수의 토큰들 또는 전달의 선호된 방향을 표시하지 않을 수 있으며; 대신에 단지 TSIP에서 토큰 모집단의 표시만이 제공될 수 있으며, 그것은 어느 하나의 방향에서의 전달이 적절한지를 결정하기 위해 TSPP에 남겨질 수 있다. 이러한 시나리오에서, TSPP가 어떤 전달도 적절하지 않다고 결정한다면, 그것은 간단히 거절 메시지를 전송하거나 또는 TSReq를 전체적으로 무시할 수 있으며; TSPP가 토큰 전달이 적절하다고 결정하면, 그것은 도 20c 또는 도 20d에서처럼 그 자신의 TSReq를 TSIP로 다시 전송할 수 있다. 몇몇 실시예들에서, TSIP는 그것이 그 자신의 토큰들 중 일부를 아낄 수 있는 경우가 아닌, 그것이 부가적인 토큰들을 요구하는 경우에만 TSReq 메시지를 전송하도록 구성될 수 있다. 다른 실시예들에서, TSIP는 그것이 보다 많은 토큰들을 요구하는지 또는 기꺼이 토큰들을 다른 것들에 전달하는지에 관계없이 TSReq 메시지를 전송할 수 있다.

토큰 공유를 위한 방법들

도 21은 적어도 몇몇 실시예들에 따라, 버스트-모드 동작들에 대한 토큰 공유를 지원하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(2501)에 도시된 바와 같이, 정상-모드 및 버스트-모드 버킷들을 포함한, 토큰 버킷들은 토큰 공유 그룹의 멤버들로서 지정되는 다수의 작업 타겟들(테이블 파티션들과 같은)의 각각에서 허가 제어를 위해 구성될 수 있다. 토큰 공유 그룹 내에서의 멤버십은 몇몇 실시예들에서, 예로서 디폴트로 내포될 수 있고, 주어진 테이블의 파티션들 모두는 토큰 공유 그룹의 멤버들로 고려될 수 있다. 멤버십은 몇몇 실시예들에서 저장 오브젝트들의 소유권에 기초할 수 있으며 - 예로서 특정한 클라이언트에 의해 소유된 테이블들(뿐만 아니라 2차 인덱스들을 위해 사용된 임의의 도출된 테이블들) 모두의 파티션들 모두는 토큰-공유 그룹의 멤버들로서 간주될 수 있다. 다른 실시예들에서, 클라이언트들은 그것들이 주어진 토큰 공유 그룹에 어떤 특정 작업 타겟들을 포함하기를 원하는지를 표시할 수 있을 것이다. 여러 개의 상이한 협력 클라이언트 엔티티들은 몇몇 실시예들에서 토큰 공유 그룹에서의 그것들 각각의 작업 타겟들을 포함할 것을 결정할 수 있다. 도 18의 설명과 함께 상기 설명된 바와 같이, 데이터 오브젝트들이 복제되며 상이한 복제본들이 허가 제어에 대하여 상이한 역할들(마스터 및 슬레이브 역할들과 같은)을 할당받은 몇몇 실시예들에서, 주어진 토큰 공유 그룹은 하나의 역할에 대응하며 다른 것에 대응하지 않는 복제본들을 포함할 수 있다. 토큰 공유는 몇몇 실시예들에서 특정한 유형의 토큰 버킷들에 대해서만 허용될 수 있다 - 예로서, 단지 버스트-모드 버킷들만이 토큰 공유에 참여할 수 있거나, 또는 단지 판독 토큰 버킷들만이 몇몇 구현들에서 토큰 공유에 참여할 수 있다.

토큰 공유 프로토콜은 도 17에 도시된 것과 유사한 방식으로, 몇몇 실시예들에서, 반복들에서 구현될 수 있다. 주어진 작업 타겟(W1)은 인입하는 작업 요청들에 대한 허가 제어 결정들을 하는 것 및 수용된 작업 요청들에 대응하는 작업을 실행하는 것과 같이, 잠시 동안 그것의 통상적인 동작들(토큰 공유에 관련되지 않은)을 수행할 수 있다. 토큰 공유 프로토콜의 반복은 이전 반복 이래 경과한 몇몇 시간의 양, W1에서 하나 이상의 버킷들에서 토큰들의 수가 임계 레벨에 도달하였다는 결정, 및/또는 W1에서 작업 요청들에 대한 거부율이 임계 레벨에 도달하였다는 결정과 같은, 충족되는 하나 이상의 기준들의 결과로서 W1에서 트리거링될 수 있다(요소 2504).

묘사된 실시예에서 프로토콜의 반복 동안, W1은 가능한 토큰 전달들을 위해 하나 이상의 파트너 피어 작업 타겟들을 성공적으로 식별하며, 한 번에 하나의 파트너에 하나 이상의 토큰 공유 메시지들을 송신할 수 있다(예로서, 도 20에 도시된 것과 유사한 방식으로). W1의 하나 이상의 버킷들(예로서, 버스트-모드 버킷)의 토큰 모집단들 및 파트너가 비교될 수 있으며, 몇몇 수의 토큰들이 W1 및 파트너 사이에서 전달되는지에 대한 결정이 두 개의 작업 타겟들의 상호 동의에 의해 도달될 수 있다. 따라서, 요소(2507)에서 도시된 바와 같이, W1은 가능한 토큰 전달을 위해 접촉될 다음 파트너(W2)로서 토큰 공유 그룹의 멤버인 몇몇 작업 타겟을 선택할 수 있다. 상이한 기술들이 다양한 실시예들에서 어떤 특정 작업 타겟이 선택되어야 하는지를 식별하기 위해 사용될 수 있다. 예를 들면, 몇몇 실시예들에서, 가십 프로토콜이 사용될 수 있으며 파트너들은 랜덤하게 선택될 수 있다. 다른 실시예들에서, 토큰 공유 그룹의 작업 타겟들 중에서 가장 긴 시간 동안 W1에 의해 접촉되지 않은(“가장 덜-최근-접촉된(least-recently-contacted)”으로 칭하여질 수 있는) 특정한 작업 타겟을 선택하는 것과 같은, 보다 결정적 선택 기술이 사용될 수 있거나, 또는 라운드-로빈 접근법이 사용될 수 있다. 일 구현에서, 주어진 작업 타겟은 단지 개시자 및 주어진 작업 타겟사이에서 어떤 토큰 전달들도 특정 시간 윈도우 동안 발생하지 않은 경우에만 파트너로서 선택 가능할 수 있다.

하나 이상의 메시지들은 토큰 전달에 의해 잠재적으로 영향을 받을 수 있는 버킷(들)의 토큰 모집단들을 비교하기 위해 파트너 피어와 교환될 수 있다(요소 2510). 몇몇 실시예들에서, 토큰 모집단 정보 대신에 또는 그 외에, 메시지(들)는 토큰들의 요청된 수, 또는 전달을 위해 수용 가능할 토큰들의 수의 범위, 뿐만 아니라 토큰 전달의 원하는 방향을 표시할 수 있다. 적어도 일 실시예에서, 토큰 모집단들의 비교는 요구되지 않을 수 있고; 대신에, 예를 들면, 파트너 피어에 몇몇 수의 토큰들을 제공할지, 또는 파트너 피어로부터 몇몇 수의 토큰들을 요청할지에 대한 결정이 개시자 피어(W1)에서의 토큰들의 수에 기초하여, 또는 다른 기준들 또는 임계치들에 기초하여 이루어질 수 있다. 유사하게, 이러한 실시예에서, 파트너 피어로부터의 응답은 또한 토큰 카운트들의 비교 없이 생성될 수 있다. 하나 이상의 기준들이 토큰 전달이 동의되어야 하는지, 그렇다면 얼마나 많은 토큰들이 전달되어야 하는지(즉, 전달 크기), 및 어떤 방향일지(전달 방향)를 결정하기 위해, 개시자 피어(W1) 또는 파트너 피어(W2)에서 사용될 수 있다. 예를 들면, 몇몇 실시예들에서, W2와 같은 주어진 작업 타겟은, W2가 W1보다 많은 토큰들을 가질지라도, W2의 토큰 버킷 모집단이 몇몇 임계치 이하이면 기꺼이 토큰들을 주지 않을 수 있거나; 또는 W2가 지난 동향들에 기초하여 가까운 미래에 작업 요청들의 버스트를 예상한다면 W2는 W1에 토큰들을 기꺼이 기증하지 않을 수 있다. 몇몇 실시예들에서, 작업 타겟들은 전적으로 토큰 모집단들에서의 차이에 기초하여 토큰들을 공유하도록 구성될 수 있으며 - 예로서 W2가 W1보다 많은 토큰들을 가진다면, W2는 W1과 토큰들의 일부(예로서, 도 17에 도시된 바와 같이 토큰 모집단들 사이에서의 차이의 절반 전달)를 공유하도록 강요될 수 있다. 적어도 일 실시예에서, “스래싱(thrashing)” 거동(예로서, 주어진 쌍의 작업 타겟들 사이에서 앞 뒤로 빠른 전달들)을 회피하기 위해, 주어진 쌍의 작업 타겟들 사이에서의 전달들의 수(또는 전달된 토큰들의 수)는 특정 레이트를 넘어 허용되지 않을 수 있다. 전달 크기는 개시 피어 및 파트너 피어 사이에서 상호 동의에 의해 결정될 수 있다. 몇몇 실시예들에서, 토큰 전달들은 단지 피어들 중 하나가 기꺼이 적어도 T개의 토큰들을 내어준다면 구현될 수 있으며, 여기에서 T는 프로토콜의 구성 가능한 파라미터일 수 있고; 따라서 매우 작은 수의 토큰들을 전달하는 것은 가치 있는 것으로 고려되지 않을 수 있다.

토큰 전달 기준들이 충족된다면(요소(2514)에서 결정된 바와 같이), 결정된 전달 크기와 같은 토큰들의 수는 작업 타겟들 중 하나에서(예로서, 개시자 또는 파트너) 하나 이상의 버킷들에 부가될 수 있으며, 동일한 수의 토큰들은 다른 작업 타겟에서 하나 이상의 버킷들의 대응하는 세트로부터 제거될 수 있다(요소 2518). 대부분의 경우들에서, 토큰들은, 다른 방향에서의 전달들이 또한 적어도 몇몇 실시예들에서 허용될지라도(예를 들면, W1이 W2보다 적은 토큰들을 갖지만, W2가 예상된 큰 버스트를 예상하고 토큰들을 요청한다면, W1은 일 예시적인 시나리오에서 W2에 토큰들을 전달할 수 있다), 보다 큰 토큰 모집단을 가진 피어로부터 보다 작은 토큰 모집단을 가진 피어로 전달될 수 있다.

토큰 전달이 동의되었는지에 관계없이, 묘사된 실시예에서, 다른 파트너 작업 타겟들이 접촉되는지에 대한 결정이 이루어질 수 있다. 예를 들면, 몇몇 실시예들에서, W1은 N개의 토큰들을 획득하고 싶어할 수 있지만 단지 M개의 토큰들(여기에서 M < N)만이 W2로부터 이용할 수 있으며, 따라서 W1은 다른 파트너들로부터 부가적인 토큰들을 획득하려고 시도하기를 원할 수 있다. 몇몇 실시예들에서, 한계는 주어진 시간 기간에서 W1과 같은 주어진 개시자에 의해 접촉될 수 있는 상이한 파트너들의 수에 대해 시행될 수 있다. 부가적인 피어들이 접촉된다면(요소(2522)에서 결정된 바와 같이), 다음 파트너는 예를 들면, 요소(2507)에 대하여 상기 설명된 바와 같이 유사한 접근법을 사용하여 식별될 수 있으며, 요소들(2510, 2514, 및 2518)에 대응하는 동작들은 다음 파트너를 갖고 수행될 수 있다.

어떤 부가적인 파트너들도 접촉되지 않는다면(또한 요소(2522)에서 결정된 바와 같이), 예로서 개시자가 원하는 수의 토큰들을 획득(또는 기증)할 수 있다면, 토큰-공유 프로토콜의 반복은 완료된 것으로 간주될 수 있다(요소 2526). 개시자는 다음 반복이 트리거될 때까지 그것의 보통 동작들을 재개할 수 있으며(요소 2504), 그 포인트에서 요소들(2507)에 대응하는 동작들이 앞으로 묘사된 실시예에서 반복될 수 있다.

공유된 자원들의 초과 용량을 표현하는 토큰들의 분배

이전에 설명된 바와 같이, 몇몇 실시예들에서, 데이터베이스 서비스에 의해 관리된 여러 개의 데이터베이스 테이블 파티션들과 같은, 주어진 네트워크-액세스 가능한 서비스의 여러 개의 작업 타겟들은 클라이언트 요청들에 응답하여 수행된 작업을 성취하기 위해 하나 이상의 공유된 자원들(예로서, 디스크 드라이브 또는 다른 저장 디바이스)을 사용하도록 구성될 수 있다. 일반적으로, 공유된 자원에 작업 타겟들을 할당할 때, 서비스는 공유된 자원들 중 임의의 것에 의해 지속 가능한 스루풋 한계가 작업 타겟들의 프로비저닝된 용량들의 합계를 초과함을 보장할 수 있다. 토큰 버킷 모집단들이 스루풋 용량들을 나타내는 몇몇 실시예들에서, 이것은 공유된 자원가 부가적인 작업 요청들을 핸들링할 수 있을지라도, 작업 타겟들 중 하나 이상이 인입하는 작업 요청들을 수용할 수 없는(예로서, 버스트-모드 버킷들의 사용에도 불구하고) 시나리오를 야기할 수 있다. 따라서, 적어도 몇몇 실시예들에서, 공유된 자원(들)의 초과한 스루풋 용량을 표현한 토큰들은 이하에 설명되는 공평한 방식으로 작업 타겟들 중에서 분배될 수 있다. 도 22는 적어도 몇몇 실시예들에 따라, 자원을 공유하는 작업 타겟들의 조합된 프로비저닝된 용량들보다 큰 스루풋 한계를 가진 공유된 자원의 예를 예시한다.

도 22에 묘사된 실시예에서, 자원(3044)는 적어도 4개의 작업 타겟들(3001A, 3001B, 3001C 및 3001D)에 의해 공유된다. 작업 타겟들은 자원(3044)에 대하여 자원 공유 그룹(3070)의 멤버들로 칭하여질 수 있다. 공유된 자원(3044)는 작업 타겟들의 프로비저닝된 용량들의 합, (PC1+PC2+PC3+PC4)을 초과하는, 스루풋 한계(SRTL)(3020)를 가진다. 도 22의 하부 부분에서의 그래프들은 화살표들(3051, 3052, 3053 및 3054)에 의해 표시된 바와 같이, 시간 간격(T0 내지 T1) 동안 4개의 작업 타겟들에서 각각의 작업 요청 도착률들을 예시한다. 도시된 바와 같이, 작업 타겟(3001A)에서 작업 요청 도착률(W1)는 간격(T0 내지 T1) 동안 프로비저닝된 용량(PC1)보다 낮다. 작업 타겟(3001B)에서의 작업 요청 도착률(W2)는 간격의 많은 부분에 대해 프로비저닝 스루풋(PC2)을 초과하며, 그 결과, 거부율 (R2)에 표시된 바와 같이, 작업 요청들의 몇몇 수가 거절된다. 이러한 거절들은 상기 설명된 종류들의 버스트-모드 토큰 버킷들이 작업 타겟들의 각각에서 사용될지라도 발생할 수 있다. 작업 타겟(3001C)은 0 도착률(W3)에 의해 표시된 바와 같이, 어떤 작업 요청들도 수신하지 않게 된다. 작업 타겟(W4)에서, 도착률(W4)은 시간 간격(T0 내지 T1)의 몇몇 부분들에 대한 프로비저닝된 용량을 초과하지만, 어떤 거절들도 없다(예로서, 버스트-모드 토큰 버킷들을 사용한 결과로서).

토큰 분배기(3080)는 공유된 자원(3044)의 사용되지 않은 스루풋 용량을 표현한 임의의 부가적인 토큰들(즉, 버킷 리필 레이트들에 기초하여 이미 생성된 수를 넘는 토큰들)이 몇몇 실시예들에서 주어진 시간 기간 동안 자원 공유 그룹의 작업 타겟들(3001) 중에서 분배되어야 하는지를 결정하도록 구성될 수 있다. 또한, 토큰 분배기(3080)는 얼마나 많은 이러한 토큰들이 예시된 실시예에서 작업 타겟들의 각각에 제공되어야 하는지를 결정할 책임이 있을 수 있다. “초과(excess)” 토큰들은 몇몇 실시예들에서 필요에 따라 생성될 수 있지만, 다른 실시예들에서 공유된 자원와 연관된 버킷은 공유된 오브젝트의 스루풋 용량을 표현한 토큰들을 포함하도록 구성될 수 있으며, 초과 토큰들은 이러한 버킷으로부터 분배될 수 있다.

토큰 분배기(3080)는 작업 타겟들의 각각의 프로비저닝된 용량들, 뿐만 아니라 작업 타겟들(3001)에서 최근의 활동의 몇몇 메트릭들(즉, 작업 요청 도착률들)로서 이러한 인자들을 고려한 공평한 분배 정책을 구현할 수 있다. 각각의 프로비저닝된 용량들은 적어도 몇몇 실시예들에서, 주어진 클라이언트가 특정한 작업 타겟으로의 액세스를 위해 청구되는 양이 상기 작업 타겟의 프로비저닝된 용량의 함수이기 때문에, 분배 알고리즘에 인자들로서 포함될 수 있다. 따라서, 적어도 어느 정도로, 작업 타겟들이 관리되는 서비스는 자원 공유 그룹(3070)의 멤버들의 프로비저닝된 용량들에 비례하여, 공유된 자원의 사용되지 않은 용량과 연관된 초과 토큰들과 같은, 자산들 또는 이득들을 분배하려고 시도할 수 있다. 동시에, 토큰 분배기(3080)는, 이러한 약간 로딩된 작업 타겟들이 임의의 부가적인 토큰들로부터 이득을 얻을 수 없으므로, 그것이 최근에 임의의 작업 요청들을 전혀 수신하지 않은 3001C와 같은 작업 타겟으로, 또는 최근 과거에 낮은 워크로드를 가졌던 작업 타겟(3001A)으로 토큰들을 분배하기에 특히 유용하지 않을 수 있기 때문에, 최근의 워크로드 레벨들을 고려할 수 있다. 다른 인자들, 몇몇 실시예들에서 다양한 작업 요청들에서 최근 시간 기간들에 걸친 거부율들, 예상된 미래 작업 요청 도착률들 등이 또한 고려될 수 있다.

적어도 몇몇 실시예들에서, 토큰 분배기(3080)는 몇몇 간격에 걸쳐 자원 공유 그룹의 다양한 멤버들에서 도착률들에 대한 메트릭들을 수집하며, 그 후 다음 시간 기간 동안 어떻게 토큰들을 분배할지 여부를 결정할 수 있다. 따라서, 토큰 분배기는 시간 기간(Tm)(예로서, T0 내지 T1) 동안 작업 타겟들에 대한 도착률 비들, 뿐만 아니라 프로비저닝된 스루풋 비들을 결정할 수 있다. 적어도 몇몇 실시예들에서, 비들은 반드시 도착률들 또는 프로비저닝된 스루풋들에 대해 계산될 필요는 없으며, 도착률들 및 프로비저닝된 스루풋들을 표시하거나 또는 그것과 연관된 다른 메트릭들이 대신에 사용될 수 있다. 시간 기간(Tn) 동안 허가 제어를 위해 작업 타겟들 중에서 분배될 토큰들의 조합된 수는 그 후 공유 자원(3044)의 스루풋 한계에 적어도 부분적으로 기초하여 결정될 수 있다. 예를 들면, 일 실시예에서, 조합된 수는 공유된 자원(도 22에서 SRTL(3020))의 스루풋 한계로부터 작업 타겟들의 프로비저닝된 용량들의 합(예로서, 도 22의 예에서 PC1+PC2+PC3+PC4)을 감함으로써 계산될 수 있다. 조합된 수의 토큰들은 적어도 (a) 각각의 작업 요청 도착률 비들 또는 메트릭들 및 (b) 작업 타겟의 프로비저닝된 용량들의 함수로서 작업 타겟들 중에서 분배될 수 있다. 부가적인 토큰들은 그 후 작업 타겟들에서의 버킷 리필 레이트들에 기초하여 생성될 수 있는 토큰들과 함께, 시간 기간(Tn) 동안(및/또는 다른 나중 시간 기간들에서) 수신 작업 타겟들에서의 허가 제어를 위해 사용될 수 있다. 적어도 몇몇 실시예들에서, 초과 토큰들은, 추가 토큰들이 주로 버스트-모드 동작들을 핸들링하도록 작업 타겟들을 돕도록 의도될 수 있으므로, 작업 타겟들에서 단지 버스트-모드 토큰 버킷들로만 분배될 수 있다. 다른 실시예들에서, 토큰들은 또한 또는 버스트-모드 토큰 버킷들로 대신에 정상-모드 토큰 버킷들에 분배될 수 있다. 몇몇 실시예들에서, 토큰들은 판독 토큰 버킷들과 같은, 특정한 유형들의 작업 요청들에 대한 토큰 버킷들에 분배될 수 있다.

작업 요청 도착률들 외에, 토큰 분배기가 그것의 결정들에서 고려해야 하는, 프로비저닝된 용량들을 포함한, 다른 인자들이 하나의 시간 간격으로부터 다른 것으로 변할 수 있다는 것이 주의된다. 예를 들면, 몇몇 실시예들에서, 임의의 주어진 시간 포인트에서, 클라이언트(또는 서비스)는 주어진 작업 타겟의 프로비저닝된 용량을 변경하기로 결정할 수 있다. 또한, 주어진 자원에 대한 액세스를 공유하는 작업 타겟들의 수가 또한 변할 수 있다 - 예를 들면, 테이블 파티션이 몇몇 실시예들에서 임의의 주어진 시간에서 공유된 저장 디바이스에 부가될 수 있거나, 또는 기존의 파티션이 삭제될 수 있다. 따라서, 토큰 분배기는 이러한 실시예들에서 작업 요청 도착률들의 메트릭들을 획득하는 것 외에, 다양한 유형들의 구성 변화들을 추적해야 할 것이다.

몇몇 실시예들에서, 여러 개의 상이한 공유 자원들의 스루풋 한계들은 얼마나 많은 토큰들이 공유기들 중에서 분배되어야 하는지를 결정할 때 고려될 수 있다. 도 23은 적어도 몇몇 실시예들에 따라, 서비스(데이터베이스 서비스 또는 보다 일반적인 저장 서비스)의 저장 노드에서 작업 타겟들에 의해 공유될 수 있는 상이한 유형들의 자원들의 예들을 예시한다. 도시된 바와 같이, 저장 노드(3110)는 각각의 프로비저닝된 용량들(PC1, PC2 및 PC3 )을 가진 적어도 3개의 데이터 오브젝트 파티션들(즉, 작업 타겟들)(O1-P1, O2-P3 및 O3-P2)이 저장되는 공유 저장 디바이스(3102)를 포함할 수 있다. 공유 저장 디바이스(3102)는 묘사된 실시예에서 스루풋 한계(SRTL)(3120A)를 가질 수 있다.

저장 디바이스 외에, 파티션들(O1-P1, O2-P3 또는 O3-P2)에서 향해진 작업 요청들은 저장 노드(3310), 또는 저장 노드의 외부에 위치된 다른 공유 자원들의 사용을 요구할 수 있다. 예를 들면, 운영 시스템 버퍼들, 소켓들, i노드들, 또는 애플리케이션-레벨 오브젝트들(예로서, 다양한 유형들의 록들 중 임의의 것)과 같은, 공유 데이터 구조들(3115)은 작업 동작들을 프로세싱하기 위해 요구될 수 있으며, 이러한 공유 데이터 구조들은 각각 그 자신의 스루풋 한계들(SRTL)(3120B)을 가질 수 있다. 공유 휘발성 메모리(3116)(예로서, 저장 노드의 메인 메모리)의 몇몇 양은 작업 동작들을 위해 요구될 수 있으며, 메모리는 묘사된 실시예에서 그 자신의 스루풋 한계(3120C)를 가질 수 있다. 공유 프로세싱 요소들(3118)(예로서, CPU들 또는 코어들)은 작업 요청들에 대응하는 작업 동작들을 프로세싱하기 위해 이용될 수 있으며, 프로세싱 요소들은 그 자신의 스루풋 한계(3120D)를 가질 수 있다. 작업 요청들 및 대응하는 응답들은 스루풋 한계(SRTL)(3120E)를 가진, 네트워크 인터페이스 카드와 같은 공유 네트워크 디바이스(3122)의 사용을 요구할 수 있다. 스루풋 한계(3120F)를 가진 공유 네트워크 링크들(3132)은 작업 요청들을 위해 요구될 수 있다. 몇몇 경우들에서, 스루풋 한계(3120G)를 가진 구성 데이터베이스와 같은, 외부 자원(3136)로의 액세스는 또한 적어도 몇몇 작업 동작들을 위해 요구될 수 있다.

초과 토큰들이 이들 유형들의 자원들 중 일부 또는 모두를 공유한 작업 타겟들 중에서 분배되는지를 결정할 때, 토큰 분배기는 묘사된 실시예에서 모든 적용 가능한 고유 자원들의 각각의스루풋 한계들의 함수를 계산하도록 구성될 수 있다. 몇몇 경우들에서, 계산은 예를 들면, 다양한 SRTL들 중에서 최소 SRTL를 결정하는 단계, 및 공유된 자원들의 조합과 연관된 유효 스루풋 한계로서 상기 최소 값을 사용하는 것을 수반할 수 있다. 도 23에 예시된 상이한 유형들의 공유 자원들 모두가 임의의 주어진 구현에서 사용되는 것은 아닐 수 있다. 몇몇 실시예들에서, 도 23에 도시되지 않은, 다른 유형들의 공유된 자원들이 사용될 수 있다.

도 24는 적어도 몇몇 실시예들에 따라, 자원을 공유한 작업 타겟들 중에서 분배될 초과 토큰들의 수를 계산하기 위해 수행된 동작들의 예를 예시한다. 도시된 바와 같이, 토큰 분배기(3080)는 하나 이상의 공유 자원들의 각각의 SRTL들(3220)(예로서, 3220A, 3220B, …3220N)의 함수(f1)로서 유효 공유 자원 스루풋 한계(3230)를 계산할 수 있다. 몇몇 구현들에서, 최소 SRTL은 예를 들면, 유효 SRTL로서 선택될 수 있는 반면, 다른 구현들에서, 몇몇 다른 함수가 사용될 수 있다. 도착률 모니터(들)(3277)는 묘사된 실시예에서 자원 공유 그룹의 다양한 작업 타겟들(3201)(예로서, 3201A, 3201B 및 3201C)에서 상대적 작업 요청 도착률들을 표시한 메트릭들(3240)을 결정할 책임이 있을 수 있다. 일 구현에서, 예를 들면, 초과 토큰 분배에 관한 결정은 매 4분들마다 한 번 이루어질 수 있으며, 메트릭들(3240)은 그에 따라 N-분 시간 윈도우들 동안 결정될 수 있다. 몇몇 실시예들에서, 도착률 모니터들(3277)은 작업 타겟들의 각각의 허가 제어기들(180) 내에 통합될 수 있다.

도 24에 묘사된 실시예에서, 토큰 분배기(3080)는 자원 공유 그룹의 작업 타겟들의 프로비저닝된 용량들 및 유효 SRTL(3230)의 함수(f2)로서, 공유 자원들에서 초과 스루풋 용량을 표현한 초과 토큰들(3240)의 수를 결정할 수 있다. 따라서, 예를 들면, 주어진 시간 윈도우(Tm) 동안 유효 SRTL(3240)이 초당 X개의 동작들이었으며, 작업 타겟들의 프로비저닝된 용량들의 합(예로서, (도 24에서 PC1+PC2+PC3))이 시간 윈도우(Tm) 동안 초당 Y개의 동작들이었다면, 제 (m+1) 시간 윈도우(T(m+1)) 동안 분배될 초과 토큰들은 일 구현에서 X-Y로서 계산될 수 있다. 보다 복잡한 함수들(f2)이 다른 구현들에서 사용될 수 있다. 적어도 몇몇 시나리오들에서, 공유 자원들의 SRTL들(및 그러므로 유효 SRTL(3230))은 시간에 걸쳐 변할 수 있다는 것이 주의된다. 유사하게, 작업 타겟들의 프로비저닝된 용량들은 예로서, 클라이언트 요청들로 인해, 시간에 걸쳐 또한 변할 수 있다. 그 결과, 초과 토큰들(3240)의 수는 또한 적어도 몇몇 실시예들에서 달라질 수 있다. 몇몇 실시예들에서 적어도 몇몇 시간 윈도우들에 대해, 주어진 시간 윈도우 동안 분배될 초과 토큰들의 수는 0일 수 있고 - 예로서 적어도 일시적으로 공유된 자원들에서 이용 가능한 초과 용량이 없을 수 있다는 것이 주의된다.

분배될 초과 토큰들(3240)의 수를 결정하면, 토큰 분배기(3080)는 다음에 얼마나 많은 토큰들(만약에 있다면)이 각각의 작업 타겟에 제공될지를 결정할 수 있다. 주어진 작업 타겟에 대한 분배된 초과 토큰들(DET)(3242)(예로서, 작업 타겟(3201A)에 대한 DET(3242A), 작업 타겟(3201B)에 대한 DET(3242B), 및 작업 타겟(3201C)에 대한 DET(3242C))은 작업 타겟의 도착률 메트릭(3240), 및 작업 타겟의 프로비저닝된 용량의 함수(f3)로서 계산될 수 있다. 시간 윈도우(Tm) 동안 3개의 작업 타겟들(3201A, 3201B 및 3201C)에 대한 각각의 도착률 메트릭 값들이 A1, A2, 및 A3인 예시적인 시나리오를 고려하자. 각각의 작업 타겟(k)에 대해, 도착률 비는 일 구현에서 A_율_k = (Ak/(A1+A2+A3))로서 결정될 수 있으며, 프로비저닝된 용량 비는 P_율_k = (PCk/(PC1+PC2+PC3))로서 결정될 수 있다. 제 (m+1) 시간 윈도우에 대해 분배될 초과 토큰들의 조합된 수는 E임을 추가로 가정하자. 작업 타겟(k)에 분배될 초과 토큰들(DETk)은 다음과 같이 계산될 수 있다: DETk = E*((알파*A_율_k)+((1-알파)*P_율_k))), 여기에서 알파는 상수이다. 이 예에서, 알파는 고려되는 두 개의 상이한 인자들에 제공된 상대적 가중을 나타낸다: 도착률들, 및 프로비저닝된 용량들. 토큰 분배기(3080)는 몇몇 실시예들에서, 예로서 도착률들 및 대응하는 거부율들에서의 관찰된 동향들에 응답하여, 시간에 걸쳐 알파를 조정할 수 있다. 적어도 몇몇 실시예들에서, 초과 토큰들(3240)은 제 m 시간 윈도우 동안 조합된 도착률들이 임계치를 초과한다면 단지 제 (m+1) 시간 윈도우 동안 분배될 수 있다 - 예로서, 도착률들의 각각이 작업 타겟의 프로비저닝된 용량보다 낮다면, 초과 토큰들은 제 (m+1) 시간 윈도우 동안 분배되지 않을 수 있다. 일 실시예에서, 보다 긴 시간 기간에 걸친 도착률들은 초과 토큰들을 분배할 때 고려될 수 있으며 - 예로서 얼마나 많은 토큰들이 5-분 시간 윈도우 동안 주어진 작업 타겟에 분배되어야 하는지를 결정할 때, 토큰 분배기(3080)는 이전 60분들 동안 상기 작업 타겟에 대해 획득된 도착률 메트릭들을 고려할 수 있다. 몇몇 실시예들에서, 주어진 작업 타겟에서의 도착률이 주어진 시간 간격 동안 0이면(예로서, 도 2의 작업 타겟(3001C)은 시간 기간(T0 내지 T1) 동안 유휴 상태이다), 어떤 토큰들도 그것의 프로비저닝된 용량에 관계없이, 다음 시간 간격 동안 상기 작업 타겟에 분배될 수 있다.

공유 자원들에서 초과 용량을 표현하는 토큰들을 분배하기 위한 방법들

도 25는 적어도 몇몇 실시예들에 따라, 자원을 공유한 작업 타겟들 중에서 초과 토큰들의 공평한 분배를 구현하기 위해 수행될 수 있는 동작의 양상들을 예시한 흐름도이다. 요소(3301)에서 도시된 바와 같이, 작업 타겟들의 세트는 클라이언트 작업 요청들에 대응하는 동작들을 수행할 때 하나 이상의 공유 자원들을 이용하도록 구성될 수 있다. 이러한 작업 타겟들은 자원 공유 그룹으로 칭하여질 수 있다. 각각의 공유 자원는 각각의 스루풋 한계(SRTL)를 가질 수 있다. 토큰 버킷들의 각각의 세트는 예로서, 이전에 설명된 것과 유사한 하나 이상의 정상-모드 버킷들 및/또는 하나 이상의 버스트-모드 버킷들을 포함하여, 자원 공유 그룹의 작업 타겟들의 각각에서 허가 제어를 위해 구성될 수 있다(요소 3304). 리필 레이트들, 최대 토큰 모집단 등과 같은, 토큰 버킷들의 다양한 파라미터들은 적어도 몇몇 실시예들에서 작업 타겟들과 연관된 각각의 스루풋 용량들에 적어도 부분적으로 기초할 수 있다.

작업 요청 도착률 메트릭들, 거부율 메트릭들, 프로비저닝된 용량들에 대한 변화들, 및/또는 공유된 자원의 스루풋 한계들에 대한 변화들과 같은, 다수의 메트릭들이 공유 자원(들) 및 자원 공유 그룹의 멤버들에 대해 수집될 수 있다. 몇몇 실시예들에서, 시간-윈도우 기반 토큰 분배 프로토클이 구현될 수 있으며, 여기에서 주어진 세트의 하나 이상의 시간 윈도우들에서 획득된 메트릭들은 몇몇 세트의 후속 시간 윈도우들 동안 토큰 분배를 위해 사용된다. 묘사된 실시예에서, 메트릭들은 시간 윈도우(t_j ₊₁) 동안 토큰 분배들을 결정하기 위해 시간 윈도우(t_j) 동안 수집될 수 있다(요소 3307). 시간 윈도우(t_j ₊₁) 동안 분배될 초과 토큰들의 조합된 수(DET-총)는 작업 타겟들의 프로비저닝된 용량들 및 공유 자원 스루풋 한계들(SRTL들)의 함수로서 결정될 수 있다(요소 3310). 예를 들면, 일 구현에서, 유효 SRTL이 계산될 수 있으며(예로서, 하나 이상의 공유 자원가 고려된다면 개개의 SRTL들의 최소치), DET-총은 유효 SRTL로부터 작업 타겟들의 프로비저닝된 용량들의 합을 감함으로써 계산될 수 있다.

적어도 몇몇 구현들에서, 그것은 DET-총은 특정한 시간 윈도우 동안 0이며, 즉 분배될 초과 토큰들이 없을 수 있는 경우일 수 있다. DET-총이 0을 초과한다면(요소(3313)에서 결정된 바와 같이), 각각의 작업 타겟(k)에 제공될 토큰들의 수(DET-k)이 그 후, 예로서 작업 타겟들의 각각의 도착률들 및/또는 각각의 스루풋 용량들과 연관된 메트릭들의 함수로서 계산될 수 있다(요소 3316). 예를 들면, 도 24의 설명과 함께 상기 논의된 바와 같이, 상이한 작업 타겟들의 도착률 메트릭들 및 프로비저닝된 용량 메트릭들에 상대적 가중 알파를 할당하는 함수는 DET-k를 획득하기 위해 몇몇 실시예들에서 사용될 수 있다. 작업 타겟들과 연관된 하나 이상의 버킷들에서의 토큰 모집단들은 그 후 결정된 DET-k에 기초하여 조정될 수 있다(요소 3319). 토큰들이 부가된 후, 허가 제어 결정들은 이전처럼, 그러나 적어도 몇몇 초과 토큰들에서 수신된 이들 작업 타겟들에서의 보다 높은 워크로드들을 견디기 위한 강화된 능력을 갖고 이루어질 수 있다. 몇몇 실시예들에서, 초과 토큰들은 단지 버스트-모드 토큰 버킷들에 부가될 수 있는 반면, 다른 실시예들에서, 초과 토큰들은 버스트-모드 버킷들 대신에 또는 그 외에 정상-모드 토큰 버킷들에 부가될 수 있다. 적어도 몇몇 실시예들에서, 별개의 토큰 버킷들은 판독들 대 기록들과 같은, 상이한 유형들의 작업 요청들에 대해 유지될 수 있다. 이러한 경우들에서, 초과 토큰들은 몇몇 실시예들에서 단지 몇몇 유형들의 버킷들에(예로서, 단지 판독 버킷들에, 또는 단지 기록 버킷들에), 및 다른 실시예들에서 모든 유형들의 버킷들에 분배될 수 있다.

도 24에 도시된 함수들(f1, f2, 및 f3)과 같은, 상기 설명된 분배 토큰 카운트들(DET들)을 결정하기 위해 사용된 다양한 함수들 및 공식들은 적어도 몇몇 실시예들에서, 예로서 토큰 분배기(3080) 또는 관리자에 의해, 시간에 걸쳐 동조될 수 있다. 예를 들면, 토큰 분배 기술의 성공은 높은 도착률들의 기간들 동안 다양한 작업 타겟들에서의 거부율들, 다양한 공유 자원들의 이용 레벨들 등과 같은 다수의 메트릭들을 모니터링함으로써 게이징될 수 있으며 도착률 메트릭들 대 프로비저닝된 용량 메트릭들에 할당된 가중 알파는 그에 따라 조정될 수 있거나 또는 시간 윈도우들의 크기들이 조정될 수 있다.

적어도 몇몇 실시예들에서, 간단한 또는 복합 토큰 버킷들의 사용, 작업 타겟들 중에서의 토큰 공유, 및 공유 자원들의 초과 용량의 공평한 분배를 포함하여, 상기 설명된 것들과 같은 허가 제어와 연관된 다양한 기술들이 제공자 네트워크에 의해 제공된 복수의 서비스들에서 사용될 수 있다. 기술들 중 일부 또는 모두의 조합들이 주어진 실시예에서 사용될 수 있으며, 예로서 복합 버스트-모드 토큰 버킷들의 사용은 작업 타겟들에 걸친 토큰 공유 및 초과 토큰들의 분배와 조합될 수 있다. 인터넷 및/또는 다른 네트워크들을 통해 액세스 가능한 하나 이상의 이러한 서비스들(다양한 유형들의 클라우드-기반 저장, 계산 또는 데이터베이스 서비스들과 같은)을 분배된 세트의 클라이언트들에 제공하기 위해 회사 또는 공공 섹터 조직과 같은 엔티티에 의해 설정된 네트워크들은 제공자 네트워크들로 칭하여질 수 있다. 주어진 제공자 네트워크는 제공자에 의해 제공된 기반 시설 및 서비스들을 구현하고, 구성하며 분배하기 위해 요구된, 물리적 및/또는 가상화 컴퓨터 서버들의 모음들, 각각 하나 이상의 저장 디바이스들을 가진 저장 서버들, 네트워크 장비 등과 같은 다양한 자원 풀들을 호스팅하는 다수의 데이터 센터들(상이한 지리적 영역들에 걸쳐 분배될 수 있는)을 포함할 수 있다. 그 일부가 상이한 데이터 센터들에서 또는 상이한 지리적 영역들에서 인스턴스화되거나 또는 실행될 수 있는, 다수의 상이한 하드웨어 및/또는 소프트웨어 구성요소들은 총괄하여 다양한 실시예들에서 허가 제어 기술들을 구현하기 위해 사용될 수 있다.

버스트-모드 동작들에 대한 토큰-기반 가격 책정

몇몇 실시예들에서, 클라이언트들은 정상 모드 동작들을 위해 사용될 수 있는 것과 상이한 가격 책정 방법론을 사용하여 버스트 모드들을 지원하는 대신에 수행된 작업에 대해 청구될 수 있다. 상기 설명된 바와 같이, 작업 타겟들에 걸친 토큰 공유 및 공유 자원 용량을 표현한 초과 토큰들의 분배는 또한 버스트-모드 워크로드들을 지원하기 위해 구현될 수 있으며 토큰 공유 및/또는 초과 토큰 분배에 대한 과금은 또한 몇몇 실시예들에서 정상-모드 동작들에 대한 과금과 상이할 수 있다. 도 26은 적어도 몇몇 실시예들에 따라, 버스트-모드 동작들에 대해 구현될 수 있는 가격 책정 관리기(4080)의 예시적인 구성요소들을 예시한다. 도시된 바와 같이, 정상-모드 토큰 버킷 세트(120) 및 버스트-모드 토큰 버킷 세트(125)는 작업 타겟에 대해 인스턴스화된다. 허가 제어기(180)는, 예로서, 다양한 실시예들에 대해 상기 설명된 것들과 유사한 기술들의 조합 또는 기술을 사용하여, 정상-모드 토큰 버킷 세트의 하나 이상의 프로비저닝된 용량 버킷들(420)의 토큰 모집단 및/또는 버스트-모드 토큰 버킷 세트(125)의 하나 이상의 버스트-모드 버킷들(422)의 토큰 모집단에 기초하여 인입하는 작업 요청을 수용할지를 결정할 책임이 있을 수 있다.

도 16에 예시된 실시예에서, 가격 책정 관리기(4080)는 버스트-모드 토큰 버킷 세트(125) 및/또는 정상-모드 토큰 버킷 세트(120)로부터 토큰들의 사용과 연관된 하나 이상의 가격 책정 정책들을 구현하도록 구성될 수 있다. 하나 이상의 버스트-모드 가격 책정 정책들(4005B) 및 하나 이상의 정상-모드 가격 책정 정책들(4005A)은 동작의 모드에 의존하여, 하나 이상의 버킷들로부터 토큰들의 소비 및/또는 전달에 대해 클라이언트에 얼마나 많이 청구할지를 결정하기 위해 사용될 수 있다. 정상-모드 동작들에 대해, 예를 들면, 정적 또는 고정 가격이 정상-모드 가격 책정 정책(4005A)에 따라 프로비저닝된 스루풋 용량까지의 레이트에서 토큰들의 사용을 위해 사용될 수 있지만, 버스트-모드 가격 책정 정책들(4005B)은 이하에 설명된 바와 같이 적어도 몇몇 실시예들에서 더 동적일 수 있다. 가격 책정 관리기(4080)는 토큰 모집단 변화들에 관한 정보를 허가 제어기(180)로부터 수집하기 위해, 및/또는 허가 제어 결정들을 할 때 고려될 제약들에 관해 허가 제어기에 알리기 위해 구성될 수 있다(예로서, 가격 책정 관리기(4080)는 특정한 버스트-모드 가격 책정 정책에 따라, 클라이언트의 예산 제약들이 허가 제어기의 결정들에 영향을 미칠 수 있는 특정한 버스트-모드 버킷(422)으로부터의 버스트 모드 동안 토큰들의 소비에 적용함을 허가 제어기에 통지할 수 있다.).

가격 책정 관리기(4080)는 몇몇 실시예들에서 여러 개의 상이한 서브구성요소들을 포함할 수 있다. 예를 들면, 인터페이스 관리기(4020)는 클라이언트 입력에 기초한 가격 책정 정책 선택과 같은, 클라이언트들과의 다양한 가격 책정-관련 상호 작용들을 위해, 또는 이하에 설명된 종류들의 시장 거래들의 다양한 양상들을 수행하기 위해 사용될 수 있는 하나 이상의 웹 페이지들, API들, GUI들(그래픽 사용자 인터페이스들), 명령어-라인 툴들 등과 같은, 일 실시예에서 프로그램 인터페이스들의 세트를 구현할 책임이 있을 수 있다. 인터페이스 관리기(4020)는 또한 몇몇 구현들에서 가격 책정 관리기(4080) 및 허가 제어기(180) 사이에서의 통신들과 같은, 네트워크-액세스 가능한 서비스 내에서 몇몇 유형들의 내부 상호 작용들에 책임이 있을 수 있다. 몇몇 실시예들에서, 토큰 시장들이 수립될 수 있어서, 몇몇 클라이언트들이 가격에 대해 다른 클라이언트들에 의해 획득될 수 있는 초과 토큰들의 이용 가능성을 알릴 수 있게 한다. 토큰 가격들은 적어도 몇몇 이러한 실시예들에서 몇몇 유형들의 시장 거래들에 대해 정적이거나 또는 고정될 수 있는 반면, 다른 거래들에 대해, 가격들이 동적으로 결정될 수 있다(예로서, 경매들과 유사한 기술들을 사용하여, 또는 시간 윈도우들에 기초하여). 가격 책정 관리기(4080)의 시장 관리기 구성요소(4040)는 묘사된 실시예에서 시장 거래들을 지원할 책임이 있을 수 있다.

하나 이상의 계량 컴포넌트(metering component)들(4030)은 묘사된 실시예에서 허가 제어기(180)로부터 토큰 사용/소비 메트릭들을 수집하도록 구성될 수 있다. 적어도 일 실시예에서, 허가 제어기들(180)의 다수의 인스턴스들이 구현될 수 있으며(예로서, 각각의 작업 타겟에 대한 하나의 허가 제어기 인스턴스, 또는 N개의 작업 타겟들에 대한 하나의 인스턴스), 계량 컴포넌트들은 이러한 실시예들에서 다수의 허가 제어기 인스턴스들(180)로부터 토큰 사용 데이터를 총합할 수 있다. 몇몇 실시예들에서, 토큰들을 소비하거나 또는 전달하기 위한 가격은 작업 요청들을 이행하기 위해 사용된 다양한 자원들의 자원 이용 레벨들(예로서, 프로세서 이용 레벨들, 저장 디바이스 이용 레벨들, 또는 네트워크 이용 레벨들)에 기초하여 달라질 수 있다. 토큰 가격 책정이 자원 이용 레벨들의 함수인 이러한 실시예들에서, 계량 컴포넌트들(4030)은 또한 네트워크-액세스 가능한 서비스에 대해 설정된 기반 시설의 다양한 부분들로부터 이용 정보를 수집할 수 있다. 과금 발생기(4050)는 시행 중인 가격 책정 정책 또는 정책들에 기초하여, 허가 제어기(들)로부터 수집된 다양한 토큰-관련 메트릭들을 분석하며 클라이언트들에 청구될 과금 양들을 생성하도록 구성될 수 있다. 몇몇 실시예들에서, 가격 책정 관리기(4080)는 예를 들면, 가격 책정 정책 세부사항들 및/또는 과금 이력 정보가 저장될 수 있는 가격 책정 데이터베이스(4060)를 포함할 수 있다. 가격 책정 데이터베이스(4060)는 또한 몇몇 실시예들에서 동향 분석을 위해, 예로서 이전 가격 책정 변화들에 기초하여 및/또는 과금 이력으로부터 도출 가능한 사용 패턴들에 기초하여 동작 가격 책정의 구성요소들을 결정하기 위해 사용될 수 있다. 적어도 일 실시예에 따르면, 가격 책정 관리기(4080)의 서브구성요소들 중 하나 이상이 허가 제어기(180) 내에 통합될 수 있다. 몇몇 실시예들에서, 가격 책정 관리기(4080)는 하나 이상의 컴퓨팅 디바이스들 중에서 분배될 수 있는 복수의 소프트웨어 및/또는 하드웨어 구성요소들을 포함할 수 있다.

토큰-기반 가격 책정 정책 요소들

도 27은 적어도 몇몇 실시예들에 따라, 토큰-기반 가격 책정 정책(4005)의 예시적인 요소들을 예시한다. 몇몇 실시예들에서, 각각의 가격 책정 정책들은 허가 제어를 위해 사용된 상이한 버킷들에 적용될 수 있다 - 즉, 클라이언트들에 청구되는 가격들은 정상-모드 토큰 버킷 세트(120)에서의 상이한 버킷들에 대해, 및/또는 버스트-모드 토큰 버킷 세트(125)에서의 상이한 버킷들에 대해 상이할 수 있다. 버킷 세트에서 하나 이상의 버킷들과 연관된 주어진 가격 책정 정책(4005)에 대해, 가격 책정 정책이 버킷에서 하나 이상의 토큰 모집단 변화 동작들에 대한 클라이언트 과금 양들을 결정하기 위해 사용되는 조건들을 표시한, 하나 이상의 적용 가능성 기준들(4105)이 묘사된 실시예에서 특정될 수 있다. 하나의 간단한 구현에서, 예를 들면, 특정한 가격 책정 정책(4005)이 버스트-모드 버킷(422)으로부터 소비된 모든 토큰에 적용될 수 있으며; 이러한 시나리오에서, 적용 가능성 기준(4105)은 간단히 “소비된 각각의 토큰에 대한 이러한 가격 책정 정책을 적용한다”의 논리적 등가를 표시할 수 있다. 몇몇 실시예들에서, 몇몇 다른 버킷 또는 버킷들의 토큰 모집단에 기초하고(예로서, “버킷(B2)의 토큰 모집단이 범위(B2low-B2high) 내에 있는 경우에만 버킷(B1) 토큰 소비들에 이러한 가격 책정 정책을 적용한다”의 논리적 등가), 클라이언트 예산들에 기초하고(예로서, “버스트-모드 토큰들에 대한 C1의 나머지 예산이 양(A)을 초과하는 경우에만 클라이언트 C1의 버킷(B1)에 이러한 가격 책정 정책을 적용한다”의 논리적 등가), 타이밍 윈도우들(예로서, “주중 시간 기간들(01:00 AM 내지 06:00 AM) 동안 버킷(B1)으로부터 소비된 토큰들에 이러한 가격 책정 정책을 적용한다”) 등에 기초한 기준들과 같은, 보다 복잡한 적용 가능성 기준들(4105)이 특정될 수 있다. 몇몇 경우들에서 적용 가능성 기준들이 사용되는 버킷들의 수 및 유형에 의존할 수 있으며, 예로서 몇몇 가격 책정 정책들은 복합 토큰 버킷이 또한 버스트-모드 허가 제어를 위해 사용되는 경우에만 주어진 공유-자원 용량 버스트-모드 버킷(B1)에 적용할 수 있다.

일반적으로 말해서, 토큰 모집단 변화들(예로서, 토큰 소비 또는 전달)과 연관된 가격 책정은 정적 가격 책정 구성요소들(4108)(예로서, 특정된 시간 기간 동안 특정된 요금으로 특정된 수의 버스트-모드 토큰들까지 소비하기 위한 선불 수수료들) 및 동적 가격 책정 구성요소들(4111)(예로서, 평일의 상이한 시간 윈도우들 동안 달라질 수 있는 요금들, 또는 공급 및 수요에 기초하여 달라질 수 있는 요금들)을 포함할 수 있다. 몇몇 가격 책정 정책들은 묘사된 실시예에서 정적 및 동적 가격 책정 구성요소들 양쪽 모두를 포함할 수 있지만, 다른 정책들은 단지 정적 구성요소들 또는 단지 동적 구성요소들만을 포함할 수 있다. 특저한 유형들의 토큰 전달들 또는 판매들에 대해, 동적 가격 책정은 적어도 몇몇 실시예들에서 경매들을 사용하여 구현될 수 있다. 적어도 일 실시예에서, 적어도 몇몇 토큰 버킷들에 대한 가격 책정은 공급 및 수요에 기초하여 변할 수 있으며, 예로서 버스트-모드 토큰들에 대한 “스폿(spot)” 가격 책정 정책이 구현될 수 있으며, 그에 따라 특정한 클라이언트가 클라이언트의 입찰이 입찰 시 현재 스폿 가격과 같거나 또는 이를 초과하는 경우에만 토큰을 제공받을 수 있다.

몇몇 실시예들에서, 하나 이상의 클라이언트가 주어진 토큰 거래에 수반될 수 있다. 예를 들면, 가격 책정 관리기(4080)가 토큰 시장을 구현하는 실시예들에서, 클라이언트(C1)는 C1이 소유한 몇몇 수의 토큰들(예로서, 버스트-모드 동작들을 위해 사용될 수 있는 토큰들)이 다른 클라이언트들에 판매를 위해 이용 가능함을 표시하기를 원할 수 있다. 가격 책정 관리기(4080)는 토큰들의 이용 가능성을 알릴 수 있으며(또는 토큰들을 구매하기 위해 잠재적인 후보들일 수 있음을 특정 클라이언트들에 통지할 수 있으며), 상이한 클라이언트(C2)는 C1로부터 토큰들을 구매할 수 있다. 이러한 시나리오에서, 클라이언트들 사이에서의 지불 전달들은 묘사된 실시예에서 예로서, 클라이언트-간 지불 전달 정책(4117)(특정한 유형의 토큰 버킷에 대해, 클라이언트 A의 가격 책정 정책에, 클라이언트 C2의 가격 책정 정책에, 또는 양쪽 클라이언트들의 정책들 모두에 포함될 수 있는)에 따라, 가격 책정 관리기(4080)에 의해 용이해질 수 있다. 클라이언트-간 지불 전달 정책(4117)은 예를 들면, 구매자 또는 판매자가 판매를 위해 초래할 수 있는 서비스 요금들, 및/또는 클라이언트-간 지불들이 프로세싱되는 스케줄(예로서, 축적된 지불들은 하나의 스케줄에 따라 한 주에 한 번 해결되거나 또는 전달될 수 있다)을 표시할 수 있다. 몇몇 실시예들에서, 토큰들은 가격 책정 목적들을 위해 통화들의 논리적 등가로서 사용될 수 있고(적어도 일시적으로) - 예를 들면, 클라이언트(C1)는 N개의 토큰들 덕분에 서비스를 할 수 있으며(또는 상이한 클라이언트를 빚지고 있을 수 있다), 빚은 실제 통화들을 사용하여 또는 대체 토큰들을 사용하여 만회될 수 있다(예를 들면, N개의 토큰들의 빚(debt)은 N+k 토큰들을 전달함으로써 만회될 수 있으며, 여기에서 k개의 토큰들은 빚에 대한 “관심(interest)”을 나타내고, k는 채무자가 빚을 갚기 위해 얼마나 오래 걸리는지에 기초하여 계산된다). 토큰들이 상이한 클라이언트들에 의해 소유된 작업 타겟들을 포함하여, 다수의 작업 타겟들 중에서 공유되는 몇몇 실시예들에서, 클라이언트-간 지불 전달 정책들은 또한 도 17에 예시된 예시적인 토큰 공유 프로토콜과 같은, 이전에 설명된 것들과 유사한 토큰 공유 기술들을 위해 적용 가능할 수 있다.

적어도 몇몇 실시예에서, 적어도 몇몇 유형들의 토큰 버킷들에 대해, 허가 제어기(180)는 미래 허가 제어 결정들에 관한 임의의 확실장 보장들을 제공할 수 없을 수 있으며 - 예로서, 이전에 설명된 바와 같이, 버스트-모드 허가 제어에 대해, “비보장형(best-effort)” 접근법이 사용될 수 있으며, 일반적으로 작업 요청들이 정상 모드 동안보다 버스트 모드 동안 거절되는 보다 높은 확률이 있을 수 있다. 가격 책정 정책(4005)은 몇몇 실시예들에서 가격 책정 정책에 따라 획득되거나 또는 소비된 토큰들에 적용할 수 있는 하나 이상의 비보장형 제약들(4120)의 표시를 포함할 수 있다. 예를 들면, 제약들(4120)은 허가 제어기의 최선의 노력에도 불구하고, 및 몇몇 수의 버스트-모드 토큰들을 획득하기 위해 클라이언트에 의해 발생된 요금에도 불구하고, 작업 요청들이 예를 들면, 작업 타겟이 버스트 모드 동안 공유된 물리적 또는 논리적 자원의 스루풋 용량 한계들을 겪는다면 거절되거나 또는 재시도될 필요가 있음을 클라이언트에 알릴 수 있다. 비보장형 제약들(4120)은 따라서 몇몇(통상적으로 드문) 상황들 하에서, 토큰들에 대한 그것들의 구매가 모든 그것들의 작업 요청들에 대한 응답들의 높은 수용률 또는 높은 품질을 보장하기에 충분하지 않을 수 있는 클라이언트들에 대한 나머지들로서 작용할 수 있다. 몇몇 실시예들에서, 적어도 몇몇 클라이언트들은 가격 책정 정책(4005)에 표시된 디스카운트 정책(discount policy)들(4124)에 따라 디스카운트들을 제공받을 수 있으며 - 예로서, 클라이언트가 다양한 제약들 중 임의의 것으로 인해 그것들의 구매된 버스트-모드 토큰들 중 X% 이상을 이용할 수 없거나 또는 클라이언트의 책임이 아님을 야기한다면, 클라이언트는 구매된 버스트-모드 토큰들 중 일부 또는 모두에 대해 상환될 수 있다. 일 실시예에서, 볼륨 디스카운트들(예로서, 구매된 토큰들의 총 수에 기초한 리베이트들)이 지원될 수 있으며, 디스카운트 정책(4124)은 이러한 디스카운트들의 용어들을 표시할 수 있다. 다양한 실시예들에서, 도 27에 도시된 요소들의 종류들 중 일부는 주어진 가격 책정 정책(4005)에 포함되지 않을 수 있으며, 및/또는 도 27에 도시되지 않은 다른 요소들이 포함될 수 있다.

토큰 가격 책정을 위한 방법들

도 28은 적어도 몇몇 실시예들에 따라, 버스트-모드 동작들에 대한 과금 양들을 결정하기 위해 수행될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(4201)에 도시된 바와 같이, 묘사된 실시예에서, 몇몇 수의 토큰 버킷들은 이전에 설명된 종류들의 하나 이상의 모드들(정상 모드 및 버스트 모드와 같은)에서 동작하도록 구성된 하나 이상의 작업 타겟들에서 워크로드 관리를 위해 인스턴스화될 수 있다. 작업 타겟에서 실행을 위해 작업 요청을 수용할지에 대한 결정들이 버킷들 중 하나 이상의 토큰 모집단에 기초하여 이루어질 수 있으며, 작업 요청을 수행하기 위한 결정이 예를 들면, 하나 이상의 버킷들로부터 몇몇 수의 토큰들의 소비에 의해 동반될 수 있다. 요소(4204)에 도시된 바와 같이, 버킷들 중 일부 또는 모두에서 토큰 모집단 변화들을 야기하는 동작들에 적용될 하나 이상의 가격 책정 정책들이, 예로서, 클라이언트들로부터의 정책 선택 요청들에 응답하여 또는 네트워크-액세스 가능한 서비스의 내부 구성 파라미터들에 기초하여 가격 책정 관리기(4080)에 의해 결정될 수 있다. 예를 들면, 가격 책정 정책은 버스트-모드 동안 버킷(B1)에서의 토큰의 소비를 위해, 하나의 버킷(B1)에서 다른 버킷(B2)으로의 전달을 위해, 버킷 리필 레이트들 및/또는 최대 토큰 모집단 한계들에 대한 단기 또는 장기 변화들에 대해, 또는 이들 종류들의 변화들의 몇몇 조합에 대해 클라이언트에 청구될 양을 표시할 수 있다. 몇몇 가격 책정 정책들은 단지 버스트 모드 동안에만 적용될 수 있지만, 다른 가격 책정 정책들은 정상 모드 동안 적용될 수 있거나, 또는 미래 버스트 모드들에 대한 준비들에 적용될 수 있다(정상-모드 버킷으로부터 버스트-모드 버킷으로의 사용되지 않은 토큰들의 전달들, 작업 타겟들에 걸친 토큰들의 공유, 또는 이전에 설명된 바와 같이 초과 토큰들의 분배와 같은). 적어도 일 실시예에서, 정상-모드 가격 책정 정책은 작업 요청들의 프로비저닝된 스루풋 용량까지 수용하기 위해 소비될 수 있는, 프로비저닝된 용량 버킷(420)에서 토큰들을 위한 고정 요금을 포함할 수 있으며; 이러한 요금은 프로비저닝된 용량 버킷으로부터 사용된 토큰들의 실제 수에 관계없이 변하지 않을 수 있다. 몇몇 가격 책정 정책들은 토큰 시장을 사용하여 행해진 거래들에 적용 가능할 수 있으며, 이것은 예를 들면 몇몇 실시예들에서 가격 책정 관리기(4080)에서 또는 그것에 의해 구현된 프로그램 인터페이스들을 사용하여 지원될 수 있다.

각각의 가격 책정 정책은, 예를 들면, 정책을 위한 하나 이상의 적용 가능성 기준들(그 동안 정책이 적용될, 버스트 모드와 같은 동작의 모드(들), 뿐만 아니라 적용될 정책에 대해 충족되어야 하는 임의의 다른 특정 조건들을 특정할 수 있는), 및 토큰 모집단 변화들을 야기하는 동작들과 연관된 하나 이상의 정적 또는 동적 가격 책정 구성요소들 또는 양들을 포함할 수 있다. 몇몇 구현들에서, 가격 책정 공식들은 가격 책정 정책에서, 예로서 절대 가격 책정 양들 대신에, 인자들의 조합의 함수들의 형태로 특정될 수 있다. 몇몇 실시예들에서, 가격 책정 정책은, 클라이언트-간 지불 전달 정책들, 디스카운트들 등과 같은, 도 27에 예시된 것들과 유사한 하나 이상의 부가적인 요소들을 포함할 수 있다. 가격 책정 관리기(4080)는 다양한 시간 기간들에 걸쳐, 가격 책정 정책들과 연관된 다양한 버킷들에서 토큰 모집단들에서의 변화들, 뿐만 아니라 어떤 가격 책정 정책들이 토큰 모집단에서의 변화들의 어떤 세트들에 적용 가능한지에 대한 표시들을 수집하고, 총합하거나, 또는 기록하도록 구성될 수 있다(요소 4208). 다양한 총합 기술들 중 임의의 것이 상이한 실시예들에서 토큰 모집단 변화들에 관한 데이터의 수집을 위해 사용될 수 있으며 - 예로서, 몇몇 실시예들에서, 주어진 버킷에서 토큰 모집단에 대한 각각 및 모든 변화가 기록될 수 있는 반면, 다른 실시예들에서, 토큰 카운트들은 주기적으로 샘플링되거나 또는 스케줄링된 간격들에서 수집될 수 있다. 몇몇 구현들에서, 클라이언트에 전혀 청구되지 않은 몇몇 유형들의 토큰 모집단 변화들이 있을 수 있으며 - 예로서, 몇몇 토큰 동작들이 적어도 몇몇 클라이언트들에 대해 무료일 수 있다는 것이 주의된다.

몇몇 실시예들에서, 몇몇 시간 간격 동안 토큰 모집단에 대한 어떤 변화들도 없다면, 클라이언트는 버킷에서의 토큰들에 대해 청구되지 않을 수 있는 반면, 다른 실시예들에서 클라이언트들은 그것들이 사용되지 않은 채로 있을지라도(예로서, 주어진 버킷의 토큰 모집단이 주어진 시간 간격 동안 청구하지 않는다면) 적어도 몇몇 유형들의 토큰들에 대해 청구될 수 있다. 일 실시예에서, 청구된 양들은 토큰들의 상이한 카테고리들에 대해 달라질 수 있으며 - 예로서, 정상 모드 동안, 버스트 모드 동안, 또는 정상 및 버스트 모드들 양쪽 모두 동안, 기록들은 판독들보다 더 비쌀 수 있으며, 그 역 또한 마찬가지이다. 하나 이상의 버킷들에서 토큰 모집단 변화들의 기록들에 적어도 부분적으로, 및 가격 책정 정책 또는 정책들에 적어도 부분적으로 기초하여, 과금 양이 묘사된 실시예에서 클라이언트에 대해 생성될 수 있다(요소 4212). 다양한 실시예들에서, 가격 책정 정책들은 예를 들면, 버스트들의 다수의 카테고리들을 지원하기 위해 복합 토큰 버킷들의 사용에 적용된 정책들, 토큰 버킷들의 우선순위-기반 카테고리들에 적용된 정책들 등을 포함하여, 이전 설명된 토큰-기반 허가 제어의 상이한 양상들 중 일부 또는 모두에 대해 선택될 수 있다는 것이 주의된다.

도 29는 적어도 몇몇 실시예들에 따라, 조건부 버스트-모드 가격 책정과 연관된 동작들의 양상들을 예시한 흐름도이다. 묘사된 실시예에서, 버스트-모드 버킷 세트(125)는 로컬-버스트-제한 버킷(604) 및 하나 이상의 공유-자원 용량 버킷들(606)을 포함한, 복수의 버킷들을 포함할 수 있으며 상이한 가격 책정 정책들은 다른 버스트-모드 버킷에서의 모집단에 기초하여, 버스트-모드 버킷들 중 하나에서의 토큰 모집단에 적용 가능할 수 있다. 작업 타겟으로 향해진 다음 작업 요청이 수신될 수 있다(요소 4301). 작업 타겟이, 예로서 하나 이상의 정상-모드 토큰 버킷들에서의 토큰 모집단에 기초하여, 버스트 모드에 있지 않다면(요소(4304)에서 검출된 바와 같이), 정상-모드 가격 책정 정책은 작업 요청을 위해 사용될 가격 책정을 결정하기 위해 사용될 수 있다(요소 4308). 예를 들면, 상기 설명된 바와 같이, 작업 타겟의 프로비저닝된 스루풋 용량에 비례하는 고정 선불 요금이 작업 요청들의 프로비저닝된 스루풋 용량보다 크지 않은 레이트로 도착하는 한 소비된 토큰들의 실제 수에 독립적으로, 몇몇 실시예들에서 클라이언트에 청구될 수 있다.

작업 타겟이 버스트 모드에 있다면, 요소(4304)에서 또한 검출된 바와 같이, 묘사된 실시예에서 적어도 하나의 공유-자원 용량 버킷(606)에서의 토큰 모집단이 결정될 수 있다. 공유-자원 용량 버킷 또는 버킷들이 시행 중인 소비 정책들에 기초하여 충분한 수의 토큰들을 포함한다면(요소 4312), 작업 타겟에 적용 가능한 로컬-버스트-제한 버킷(604)의 토큰 모집단이 다음으로 확인될 수 있다. 로컬-버스트-제한 버킷(604)의 모집단은, 예를 들면, 묘사된 실시예에서 분리 시(공유된 자원들을 고려하지 않고) 고려될 때 작업 타겟에 할당된 스루풋 한계에 기초하여 이용 가능한 스루풋 용량을 표시한다. 실행을 위해 작업 요청을 수용하기 위한 가격 책정은 묘사된 실시예에서 공유-자원 용량 버킷(들) 및 로컬-버스트-제한 버킷 양쪽 모두에서의 모집단에 의존할 수 있다. 공유-자원 용량 버킷(들) 및 로컬-버스트-제한 버킷 양쪽 모두가 그것들의 각각의 소비 정책들에 기초하여 충분한 토큰들을 포함한다면(요소들(4312 및 4316)에서 결정된 바와 같이), 작업 요청이 수용될 수 있고, 하나 이상의 토큰들이 양쪽 유형들의 버킷들 모두로부터 소비될 수 있으며, 제 1 버스트-모드 가격 책정 정책이 적용될 수 있다(요소 4320). 묘사된 실시예에서, 공유-자원 용량 버킷 또는 버킷들이 충분한 토큰들을 포함하지만, 로컬-버스터-제한 버킷들이 그렇지 않다면, 작업 요청은 여전히 실행을 위해 수용될 수 있다. 하나 이상의 토큰들이 공유-자원 용량 버킷(들)으로부터 소비될 수 있으며, 제 2 버스트-모드 가격 책정 정책이 적용될 수 있다(요소 4324). 공유-자원 용량 버킷(들)도 로컬-버스트-제한 버킷도 충분한 토큰들을 포함하지 않는다면, 작업 요청은 거절되고, 재시도되거나, 또는 지연될 수 있다(요소 4328). 수용(요소들(4320 또는 4324)) 또는 거절(요소 4328)을 야기하는, 허가 제어 결정이 이루어진 후, 수신된 다음 작업 요청은 예로서, 앞으로 요소(4301)에 대응하는 동작들을 구현함으로써 처리될 수 있다. 도 29에 예시된 조건부 버스트-모드 가격 책정 접근법은 예를 들면 로컬-버스트-제한 버킷 최대 모집단들이 보수적으로 설정되는 환경들에서 사용될 수 있는 반면, 이용 가능한 스루풋 용량이 공유-자원 용량 버킷(들)에서 표현되는 공유 자원들은 적어도 몇몇 시간 기간들 동안 로컬-버스트-제한 버킷들 단독으로 사용하여 지원 가능할 것보다 더 높은 작업 요청 도착률들을 지원할 수 있을 수 있다. 공유 자원들을 이용한 작업 타겟들 중 일부에서의 워크로드들이 시간에 걸쳐 상당히 달라진다면, 로컬-버스트-제한 버킷들이 비어 있을지라도, 충분한 용량이 단기 버스트들을 지원하기 위해 공유 자원들에서 이용 가능해지는 기간들이 있을 수 있으며, 제 2 가격 책정 정책이 적어도 이러한 시나리오들에서 유용할 수 있다. 도 29에 예시된 것들과 유사한 가격 책정 기술들은 또한 이전에 설명된 공유 자원들에서 초과 용량을 표현한 토큰들의 공평한 분배를 위한 기술들과 함께 사용될 수 있다.

도 30은 적어도 몇몇 실시예들에 따라, 가격 책정 정책들의 클라이언트 선택을 가능하게 하기 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(4401)에 도시된 바와 같이, 웹 페이지들, 웹 사이트들 또는 API들과 같은 하나 이상의 프로그램 인터페이스들은 클라이언트들이 복수의 지원된 가격 책정 정책들 중에서 선택하도록 허용하기 위해 구현될 수 있다. 가격 책정 관리기(4080)의 인터페이스 관리기 서브구성요소는 적어도 몇몇 실시예들에서 구현을 책임질 수 있다. 몇몇 실시예들에서, 다수의 가격 책정 정책들은 버스트-모드 동작들을 위해 이용 가능할 수 있지만, 다른 실시예들에서 다수의 정책들은 정상-모드 및 버스트-모드 동작들 양쪽 모두에 대해 지원될 수 있다. 적어도 몇몇 실시예들에서, 구체적으로 특정한 유형들의 파라미터 변화들(리필 레이트들 또는 최대 토큰 모집단 한계들에 대한 단기 또는 장기 변화들)에 적용하는 가격 책정 정책들은 인터페이스들을 통해 선택 가능할 것이다. 이용 가능한 가격 책정 정책들의, 또는 채워지거나 또는 파라미터화될 수 있는 정책 템플릿들의 표시들이 클라이언트들에 제공될 수 있다(요소 4404). 예를 들면, 상이한 가격 책정 정책들의 다양한 요소들(도 27에 예시된 요소들과 같은)에 관한 세부사항들은 일 구현에서 웹 사이트를 통해 제공될 수 있다.

작업부하 요구들 및/또는 예산들에 기초하여, 주어진 클라이언트는 예로서 구현된 인터페이스들 중 하나를 사용하여 제출된 가격 책정 정책 요청을 통해, 사용될 선택된 정책 및/또는 파라미터들을 표시할 수 있다(요소 4408). 이러한 요청에 응답하여, 가격 책정 관리기(4080)는 클라이언트를 위해 선택된 가격 책정 정책 및/또는 파라미터들의 구현을 개시할 수 있다(요소 4412). 적어도 몇몇 구현들에서, 예를 들면, 가격 책정 관리기(4080)는 가격 책정 정책의 사용을 개시하기 위해 허가 제어기(180)와 통신할 수 있다.

도 31은 적어도 몇몇 실시예들에 따라, 버스트-모드 토큰들에 대한 시장을 가능하게 하기 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(4501)에서 도시된 바와 같이, 웹 페이지들 및/또는 API들과 같은 하나 이상의 프로그램 인터페이스들이 묘사된 실시예에서 버스트-모드 허가 제어 및/또는 정상-모드 허가 제어를 위해 사용 가능한 토큰들의 광고, 판매, 구매, 공유 또는 전달을 수반한 다양한 유형들의 거래들을 지원하기 위해 구현될 수 있다(예로서, 인터페이스 관리기(4020)에 의해). 시장 관리기(4040)(예로서, 가격 책정 관리기의 서브구성요소)는 구현된 인터페이스들을 통해 하나 이상의 클라이언트들로부터, 토큰들을 팔고, 경매하거나 또는 사기 위한 제안들과 같은, 토큰 거래 제안들의 표시들을 수신할 수 있으며(요소 4504), 제안들을 다른 클라이언트들에 알리거나 또는 광고할 수 있다. 적어도 몇몇 실시예들에서 가격 책정 관리기 및/또는 허가 제어기는 토큰들을 요구하는 클라이언트들(예로서, 작업 요청들이 최근 시간 간격 동안 거절들의 정상 레이트들보다 높게 경험한 클라이언트들)을 알 수 있을 것이며, 이러한 후보 토큰 소비자들과 토큰 제안들을 매칭시킬 수 있을 것이다.

시장 관리기(4040)는 인터페이스들 중 하나 이상을 통해 고정 가격 또는 성공적인 경매 입찰(요소 4508)에 기초하여, 토큰들의 몇몇 세트의 판매 또는 전달을 위한 거래와 같은, 완료된 거래의 표시를 수신할 수 있다. 따라서, 묘사된 실시예에서 시장 관리기(4040)는 예로서, 하나 이상의 소스 버킷들에서 토큰들의 수를 감소시키고 및/또는 하나 이상의 다른 버킷들에서 토큰 카운트를 증가시킴으로써, 영향을 받은 버킷(들)의 토큰 모집단들을 변경할 수 있다(요소 4512). 클라이언트들에 청구될 과금 양들(예를 들면, 주어진 시장 거래에서 구매 클라이언트 및 판매 클라이언트 양쪽 모두에 대한 서비스 요금들을 포함할 수 있는)은 거래 및 적용 가능한 가격 책정 정책 또는 정책들(4005)의 세부사항들에 따라 생성될 수 있다(요소 4516).

적어도 몇몇 실시예들에서, 이전에 설명된 바와 같이, 데이터베이스 테이블과 같은 작업 타겟은 복수의 논리 파티션들로 분할될 수 있으며, 허가 제어는 논리 파티션 레벨에서 수행될 수 있고, 허가 제어 파라미터들 및 토큰 버킷들의 각각의 세트는 각각의 파티션을 위해 사용된다. 예를 들면, 테라바이트의 데이터를 포함한 큰 데이터베이스 테이블은 허가 제어를 위한 각각의 세트들의 토큰 버킷들을 갖고, 각각 250 메가바이트들의 4개의 논리 파티션들로서 구성될 수 있다. 몇몇 구현들에서, 또한 이전에 설명된 바와 같이, 각각의 논리 파티션의 다수의 물리적 복제본들은, 예로서 데이터 내구성을 위해 및/또는 높은 이용 가능성을 위해 유지될 수 있다. 몇몇 시나리오들에서, 클라이언트 워크로드가 항상 파티션들에 걸쳐 균일하게 분배되는 것은 아닐 수 있다. 그 결과, 주어진 시간 포인트에서, 하나의 심하게 사용된 파티션에서 토큰 버킷(버스트-모드 버킷(422))에서의 이용 가능한 토큰들의 수는 다른, 덜-사용된 파티션들에서 대응하는 토큰 버킷들에서 이용 가능한 토큰들의 수보다 훨씬 낮을 수 있다. 따라서, 그 외 많은 비대칭 작업부하로 인해 발생할 수 잇는 작업 요청 거절들의 수를 감소시키기 위해, 상이한 파티션들에 대한 허가 제어기(들)(180)는 몇몇 실시예들에서 도 16 내지 도 21을 참조하여 설명된 것들과 같은 토큰-공유 프로토콜들을 이용할 수 있으며, 파티션들을 소유하거나 또는 사용하는 클라이언트는 파티션-간 토큰 공유를 위한 가격 책정 정책에 따라 토큰 공유에 대해 청구될 수 있다. 도 32는 적어도 몇몇 실시예들에 따라, 작업 타겟의 상이한 파티션들 사이에서의 토큰들의 가격 책정 전달들을 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다.

도 32의 요소(4601)에서 도시된 바와 같이, 작업 타겟(데이터베이스 테이블 또는 논리적 볼륨)은 각각의 정상-모드 버킷 세트 및 각각의 버스트-모드 버킷 세트와 같은, 각각이 허가 제어에 대한 각각의 토큰 버킷들을 갖는, 파티션들의 모음으로서 구성될 수 있다. 각각의 파티션은 따라서 묘사된 실시예에서 독립적으로 구성 가능한 허가 제어 파라미터들을 가진 별개의 작업으로 고려될 수 있다. 가격 책정 관리기(4080)는 상이한 파티션들의 버킷들 사이에서의 토큰 전달들에 적용될 가격 책정 정책을 결정하도록 구성될 수 있다(요소 4604). 예를 들면, 파티션(P1)에서 버스트 모드 토큰 버킷(BB1)으로부터 파티션(P2)에서 버스트-모드 토큰 버킷(BB2)으로 N개의 토큰들을 전달하기 위한 가격 책정 정책은 클라이언트의 입력에 기초하여, 또는 구성 가능한 파라미터들에 기초하여 결정될 수 있다. 이러한 토큰 전달들은 토큰 모집단이 임계치 아래로 떨어졌다는 검출, 파티션들 사이에서의 토큰 전달을 위한 요구가 조사된 마지막 시간 이래 특정한 시간 양이 경과하였다는 검출, 작업 요청들에 대한 임계 거부율의 검출 등과 같은, 상이한 실시예들에서 다양한 유형들의 트리거링 이벤트들의 발생에 기초하여 구현될 수 있다. 요소(4608)에서 도시된 바와 같이, 파티션-간 토큰 전달이 시도되어야 하는지를 확인하기 위한 트리거링 이벤트가 검출될 수 있다.

파티션들의 서브세트 또는 모두에서의 토큰 모집단들은, 임의의 파티션의 토큰 카운트가 임계치(T1) 아래인지를 알기 위해 검사될 수 있다. 이러한 파티션(“p”)이 발견되며(요소(4612)에서 결정된 바와 같이), 상이한 파티션(“q”)에서의 토큰 모집단이 임계치(T2) 이상인 것으로 발견된다면(요소(4616)에서 결정된 바와 같이), 몇몇 수의 토큰들이 묘사된 실시예에서 파티션(“q”)으로부터 파티션(“p”)으로 전달될 수 있다(요소 4620). 몇몇 경우들에서 임계치(T1) 아래의 토큰 카운트들을 가진 다수의 파티션들이 발견될 수 있고, 및/또는 T2 이상의 토큰 모집단들을 가진 다수의 파티션들이 발견될 수 있으며, 그 경우에 토큰 전달들은 다수의 소스 및 수신인 버킷 쌍들 사이에서 개시될 수 있다. 예를 들면, 파티션들(p, q, r 및 s)에서 현재 토큰 모집단들의 주어진 검사 동안, 파티션들(p 및 r)이 임계치(T1) 아래에 있는 토큰 모집단들을 갖는 것으로 발견되는 반면, 파티션(q)이 T2+N개의 토큰들을 갖는 것으로 발견되며, 파티션(s)이 전달하기에 충분한 토큰들을 갖지 않는다면, 임의의 N/2 토큰들이 파티션들(p 및 r)에 부가될 수 있으며 q의 모집단은 일 구현에서 N만큼 감소될 수 있다. 전달 또는 전달들의 기록이 유지될 수 있으며, 결국 전달을 위해 클라이언트에 청구될 과금 양은 기록(들) 및 가격 책정 정책에 기초하여 생성될 수 있다(요소 4624). 파티션들 사이에서의 토큰들을 전달하기 위한 결정(긍정 또는 부정)이 이루어진 후, 앞으로 요소들(4608)에 대응하는 동작들은 다음 트리거링 이벤트에 대해 및/또는 상이한 소스 및 목적지 파티션 쌍들에 대해 반복될 수 있다.

이전에 설명된 바와 같이, 적어도 몇몇 실시예들에서, 허가 제어를 위해 사용된 토큰 버킷들은 각각 리필 레이트들, 최대 토큰 모집단들 등과 같은, 구성 가능한 파라미터들의 세트를 가질 수 있다. 몇몇 실시예들에서, 클라이언트들은 단시간 동안 또는 긴 기간들 동안, 주어진 토큰 버킷과 연관된 하나 이상의 파라미터들을 변경하고 싶어할 수 있다. 예를 들면, 클라이언트는 다음 날 또는 다음 주 동안 랜덤한 시간들에서 작업 요청들의 매우 높은 버스트들이 발생할 수 있음을 예상할 수 있을 것이며, 기꺼이 이러한 버스트들을 수용하기 위해 별도로 지불할 수 있다. 따라서, 몇몇 실시예들에서, 가격 책정 정책들은 토큰 버킷 리필 레이트들 및/또는 다른 구성 설정 변화들을 변경하기 위해 지원될 수 있다. 도 33은 적어도 몇몇 실시예들에 따라, 토큰 버킷 구성 설정들에 대한 가격 책정 변화들을 위해 구현될 수 있는 동작들의 양상들을 예시한 흐름도이다. 요소(4701)에서 도시된 바와 같이, 초기 정책들 및 파라미터들은 예로서, 작업 타겟이 초기화될 때, 정상-모드 및 버스트-모드 버킷들을 포함한 하나 이상의 토큰 버킷들에 대해 구성될 수 있다. 버킷(들)에 대한 파라미터 변화들을 위한 가격 책정 정책이 결정될 수 있으며(요소 4704), 클라이언트들은 파라미터들을 변경하는 것과 연관된 비용들을 통지받을 수 있다. 특정된 버킷 또는 버킷들에 대한 하나 이상의 파라미터들을 변경하기 위한 요청이, 예를 들면, 특정 시간 윈도우 동안 리필 레이트 또는 최대 토큰 모집단을 변경하기 위해 수신될 수 있다(요소 4708). 파라미터들은 요청에 기초하여 변경될 수 있으며(요소 4712)(예로서, 파라미터들에 대한 새로운 값들은 그 끝에서 초기 값들이 재-적용될 수 있는, 시간 윈도우의 지속 기간 동안 사용될 수 있다), 과금 양들은 결국 구현된 파라미터 변화들 및 가격 책정 정책에 기초하여 생성될 수 있다(요소 4716).

다양한 실시예들에서, 도 10 내지 도 15, 도 21, 도 25, 및 도 28 내지 도 33에의 흐름도들에 예시된 동작들은 도시되고, 및/또는 병렬로 수행된 것과 상이한 순서로 수행될 수 있다. 몇몇 실시예들에서, 여기에 예시된 동작들 중 하나 이상은 생략될 수 있으며, 및/또는 도면들에 도시되지 않은 다른 동작들이 수행될 수 있다.

사용 경우들

버스트 모드 동작들에 대한 토큰-기반 허가 제어 및 가격 책정의, 상기 설명된 기술들은 다양한 상이한 시나리오들에서 유용할 수 있다. 예를 들면, 몇몇 데이터베이스 환경들에서, 클라이언트들은 매우 큰(테라바이트들 또는 페타바이트들) 테이블들 또는 테이블 세트들을 가질 수 있으며, 매우 높은 I/O 레이트들이 테이블들에서 몇몇 시간 기간들(그러나 다른 기간들이 아닌) 동안 지시될 수 있다. 유사하게, 다른 네트워크-액세스 가능한 서비스들(범용 저장 서비스들, 계산-집중 서비스들 등)이 또한 임시 기간들의 높은 워크로드들을 경험할 수 있다. 일반적으로, 시간에 걸쳐 데이터베이스 테이블과 같은 주어진 작업 타겟으로 향해진 워크로드들에서의 변화를 예상하는 것은 매우 어려울 수 있다. 클라이언트들은 단지 가끔 또는 드물게 발생하는 높은 워크로드 레벨들을 지불하기를 원하지 않을 수 있다. 동시에, 서비스의 제공자가 긴 기간들에 걸쳐 매우 높은 레벨들의 작업 요청들을 핸들링하기 위해 충분한 자원들을 따로 떼어두길 원하지 않을 수 있지만, 제공자는 다수의 요청들을 거절하거나 또는 고객 요청들의 응답 시간들을 상당히 증가시키지 않고, 가능한 정도로, 도착률들에서의 임시 버스트들을 지원하기를 원할 수 있다. 여기에 설명된 토큰-기반 허가 제어 접근법들의 종류들을 사용하여, 제공자는 자원들을 낭비하지 않고 요청 도착률들에서 대다수(전부가 아니지만)의 버스트들을 수용할 수 있을 것이다. 토큰-공유 기술들의 사용 및 공유 자원들의 초과 용량의 공평한 분배는 또한 균일하지 않게 분배된 작업 요청 도착률들을 핸들링하도록 클라이언트들을 도울 수 있다.

버스트-모드 및/또는 정상-모드 동작들에 대한 유연한(예로서, 클라이언트-선택된) 가격 책정 정책들에 대한 지원은 그것들의 예산 우선순위들이 다양한 종류들의 비-균일한 워크로드들을 지원하면서 충족될 수 있다는 클라이언트의 신뢰를 증가시킬 수 있다. 토큰 시장에서 토큰들을 사고 팔기 위한 능력은 클라이언트들이 가끔 부정확한 워크로드 예측들을 할지라도, 이러한 부정확성들에 대한 페널티들이 최소화될 수 있는 가능성을 증가시킬 수 있다.

예시적 컴퓨터 시스템

적어도 몇몇 실시예들에서, 토큰-기반 허가 제어기들, 토큰 분배기들, 가격 책정 관리기들, 및/또는 다양한 종류들의 작업 타겟들을 구현하기 위한 기술들을 포함하여, 여기에 설명된 기술들 중 하나 이상의 일 부분 또는 모두를 구현하는 서버는 하나 이상의 컴퓨터-액세스 가능한 미디어를 포함하거나 또는 그것을 액세스하도록 구성되는 범용 컴퓨터 시스템을 포함할 수 있다. 도 34는 이러한 범용 컴퓨팅 디바이스(8000)를 예시한다. 예시된 실시예에서, 컴퓨팅 디바이스(8000)는 입력/출력(I/O) 인터페이스(8030)를 통해 시스템 메모리(8020)에 결합된 하나 이상의 프로세서들(8010)을 포함한다. 컴퓨팅 디바이스(8000)는 I/O 인터페이스(8030)에 결합된 네트워크 인터페이스(8040)를 더 포함한다.

다양한 실시예들에서, 컴퓨팅 디바이스(8000)는 하나의 프로세서(8010), 또는 여러 개의 프로세서들(8010)(예로서, 2, 4, 8, 또는 다른 적절한 수)을 포함한 다중프로세서 시스템을 포함한 유니프로세서 시스템일 수 있다. 프로세서들(8010)은 지시들을 실행할 수 있는 임의의 적절한 프로세서일 수 있다. 예를 들면, 다양한 실시예들에서, 프로세서들(8010)은 x86, PowerPC, SPARC, 또는 MIPS ISA들, 또는 임의의 다른 적절한 ISA와 같은, 다양한 지시 세트 아키텍처들(ISA들) 중 임의의 것을 구현한 범용 또는 내장 프로세서들일 수 있다. 다중프로세서 시스템들에서, 프로세서들(8010)의 각각은, 일반적으로, 반드시는 아니지만, 동일한 ISA를 구현할 수 있다.

시스템 메모리(8020)는 프로세서(들)(8010)에 의해 액세스 가능한 지시들 및 데이터를 저장하도록 구성될 수 있다. 다양한 실시예들에서, 시스템 메모리(8020)는 정적 랜덤 액세스 메모리(SRAM), 동기식 동적 RAM(SDRAM), 비휘발성/플래시-형 메모리, 또는 임의의 다른 유형의 메모리와 같은, 임의의 적절한 메모리 기술을 사용하여 구현될 수 있다. 예시된 실시예에서, 상기 설명된 이들 방법들, 기술들 및 데이터와 같은, 하나 이상의 원하는 기능들을 구현한 프로그램 지시들 및 데이터는 코드(8025) 및 데이터(8026)로서 시스템 메모리(8020) 내에 저장되어 도시된다.

일 실시예에서, I/O 인터페이스(8030)는 데이터 오브젝트 파티션들의 물리적 복제본들을 저장하기 위해 사용된 다양한 유형들의 영구 및/또는 휘발성 저장 디바이스들과 같은 네트워크 인터페이스(8040) 또는 다른 주변 인터페이스들을 포함하여, 디바이스에서 프로세서(8010), 시스템 메모리(8020), 및 임의의 주변 디바이스들 사이에서 I/O 트래픽을 조정하도록 구성될 수 있다. 몇몇 실시예들에서, I/O 인터페이스(8030)는 하나의 구성요소(예로서, 시스템 메모리(8020))에서 다른 구성요소(예로서, 프로세서(8010))에 의한 사용에 적합한 포맷으로 데이터 신호들을 변환하기 위해 임의의 필요한 프로토콜, 타이밍 또는 다른 데이터 변환들을 수행할 수 있다. 몇몇 실시예들에서, I/O 인터페이스(8030)는 예를 들면, 주변 구성요소 상호 연결(PCI) 버스 표준 또는 범용 직렬 버스(USB) 표준의 변형과 같은, 다양한 유형들의 주변 버스들을 통해 접속된 디바이스들에 대한 지원을 포함할 수 있다. 몇몇 실시예들에서, I/O 인터페이스(8030)의 기능은 예를 들면, 노스 브리지 및 사우스 브리지와 같은, 둘 이상의 별개의 구성요소들로 분리될 수 있다. 또한, 몇몇 실시예들에서, 시스템 메모리(8020)로의 인터페이스와 같은, I/O 인터페이스(8030)의 기능 중 일부 또는 모두는 프로세서(8010)로 직접 통합될 수 있다.

네트워크 인터페이스(8040)는 예를 들면, 도 1a 내지 도 33에 예시된 바와 같이 다른 컴퓨터 시스템들 또는 디바이스들과 같은, 네트워크 또는 네트워크들(8050)에 접속된 컴퓨팅 디바이스(8000) 및 다른 디바이스들(8060) 사이에서 컴퓨터-액세스 가능한 매체의 구성될 수 있다. 다양한 실시예들에서, 네트워크 인터페이스(8040)는 예를 들면, 이더넷 네트워크의 유형들과 같은, 임의의 적절한 유선 또는 무선 일반 데이터 네트워크들을 통해 통신을 지원할 수 있다. 부가적으로, 네트워크 인터페이스(8040)는 파이버 채널 SAN들과 같은 저장 영역 네트워크들을 통해, 또는 임의의 다른 적절한 유형의 네트워크 및/또는 프로토콜을 통해, 아날로그 음성 네트워크들 또는 디지털 파이버 통신들 네트워크들과 같은 전기통신들/전화 네트워크들을 통해 통신을 지원할 수 있다.

몇몇 실시예들에서, 시스템 메모리(8020)는 대응하는 방법들 및 장치의 실시예들을 구현하기 위해 도 1a 내지 도 33에 대해 상기 설명된 바와 같이 프로그램 지시들 및 데이터를 저장하도록 구성된 컴퓨터-액세스 가능한 매체의 일 실시예일 수 있다. 그러나, 다른 실시예들에서, 프로그램 지시들 및/또는 데이터는 상이한 유형들의 컴퓨터-액세스 가능한 미디어 상에서 수신되고, 전송되거나 또는 저장될 수 있다. 일반적으로 말해서, 컴퓨터-액세스 가능한 매체는 자기 또는 광 미디어, 예로서, I/O 인터페이스(8030)를 통해 컴퓨팅 디바이스(8000)에 결합된 디스크 또는 DVD/CD와 같은 비-일시적 저장 미디어 또는 메모리 미디어를 포함할 수 있다. 비-일시적 컴퓨터-액세스 가능한 저장 매체는 또한 시스템 메모리(8020) 또는 다른 유형의 메모리로서 컴퓨팅 디바이스(8000)의 몇몇 실시예들에 포함될 수 있는, RAM(예로서, SDRAM, DDR SDRAM, RDRAM, SRAM 등), ROM 등과 같은 임의의 휘발성 또는 비-휘발성 미디어를 포함할 수 있다. 뿐만 아니라, 컴퓨터-액세스 가능한 매체는 네트워크 인터페이스(8040)를 통해 구현될 수 있는 바와 같이, 네트워크 및/또는 무선 링크와 같은 통신 매체를 통해 전달된, 전기, 전자기 또는 디지털 신호들과 같은 송신 미디어 또는 신호들을 포함할 수 있다. 도 34에 예시된 것과 같은 다수의 컴퓨팅 디바이스들 중 일부들 또는 모두는 다양한 실시예들에서 설명된 기능을 구현하기 위해 사용될 수 있으며; 예를 들면, 다양한 상이한 디바이스들 및 서버들 상에서 실행하는 소프트웨어 구성요소들은 기능을 제공하기 위해 협력할 수 있다. 몇몇 실시예들에서, 설명된 기능의 부분들은 범용 컴퓨터 시스템들을 사용하여 구현하는 것 외에 또는 그 대신에, 저장 디바이스들, 네트워크 디바이스들, 또는 특수 목적 컴퓨터 시스템들을 사용하여 구현될 수 있다. 여기에서 사용된 바와 같이, 용어(“컴퓨팅 디바이스(computing device)”)는 적어도 모든 이들 유형들의 디바이스들을 나타내며, 이들 유형들의 디바이스들에 제한되지 않는다.

앞서 말한 것은 또한 다음의 항목들을 고려하여 이해될 수 있다:

1. 시스템에 있어서,

하나 이상의 컴퓨팅 디바이스들로서:

실행을 위해 수용된 작업 요청들에 응답하여 공유된 자원을 이용하도록 제 1 작업 타겟 및 제 2 작업 타겟을 구성하는 것으로서, 상기 제 1 작업 타겟은 제 1 프로비저닝된 스루풋 레이트를 갖고, 상기 제 2 작업 타겟은 제 2 프로비저닝된 스루풋 레이트를 가지며, 상기 공유된 자원는 스루풋 한계를 갖는, 상기 실행을 위해 제 1 작업 타겟 및 제 2 작업 타겟 구성하기;

작업 요청들의 허가 제어를 위해 각각의 토큰 버킷 세트들을 갖고 상기 제 1 작업 타겟 및 상기 제 2 작업 타겟을 구성하는 것으로서, 각각의 토큰 버킷 세트는 그 토큰 모집단이 실행을 위해 작업 요청을 수용할지를 결정하기 위해 사용되는 하나 이상의 버킷들을 포함하는, 상기 허가 제어를 위해 제 1 작업 타겟 및 상기 제 2 작업 타겟을 구성하고;

(a) 작업 요청들이 제 1 시간 간격 동안 상기 제 1 및 제 2 작업 타겟들에서 수신되는 상대적 레이트들을 표시한 도착률 비, (b) 상기 제 1 및 제 2 프로비저닝된 스루풋 레이트들에 적어도 부분적으로 기초한 프로비저닝된 스루풋 비, 및 (c) 제 2 시간 간격 동안 허가 제어를 위해 상기 제 1 및 제 2 작업 타겟들의 버킷 세트들 중에서 분배될 조합된 수의 토큰들을 결정하는 것으로서, 상기 조합된 수는 상기 공유된 자원의 상기 스루풋 한계에 적어도 부분적으로 기초하는, 상기 결정하기;

상기 도착률 비율 및 상기 프로비저닝된 스루풋 비율에 적어도 부분적으로 기초하여 상기 제 1 작업 타겟의 특정한 버킷에, 상기 조합된 수보다 크지 않은, 특정한 수의 토큰들을 부가하며; 및

상기 제 1 작업 타겟의 상기 특정한 버킷의 상기 토큰 모집단에 적어도 부분적으로 기초하여 상기 제 2 시간 간격 동안 실행을 위해 상기 제 1 작업 타겟으로 향해진 특정한 작업 요청을 수용하도록 구성된, 상기 하나 이상의 컴퓨팅 디바이스들을 포함하는, 시스템.

2. 항목 1에 있어서, 상기 조합된 수의 토큰들은, 상기 공유된 자원의 상기 스루풋 한계로부터, 상기 제 1 및 제 2 프로비저닝된 스루풋 레이트들의 합을 감함으로써 적어도 부분적으로 결정되는, 시스템.

3. 항목 1에 있어서, 상기 제 1 작업 타겟의 버킷 세트는 토큰 모집단이 상기 작업 요청 도착률이 임계치보다 낮은 정상 동작 모드 동안 허가 제어를 위해 검사되는 정상-모드 버킷, 및 토큰 모집단이 상기 작업 요청 도착률이 상기 임계치보다 작지 않은 버스트 동작 모드 동안 허가 제어를 위해 검사되는 버스트-모드 버킷을 포함하며, 특정한 버킷은 상기 버스트-모드 버킷을 포함하는, 시스템.

4. 항목 1에 있어서, 상기 제 1 작업 타겟은 네트워크-액세스 가능한 서비스에 의해 관리된 제 1 저장 오브젝트의 적어도 일 부분을 포함하고, 상기 제 2 작업 타겟은 상기 네트워크-액세스 가능한 서비스에 의해 관리된 제 2 저장 오브젝트의 적어도 일 부분을 포함하며, 상기 공유된 자원는 상기 제 1 작업 타겟 및 상기 제 2 작업 타겟이 저장되는 저장 디바이스를 포함하는, 시스템.

5. 항목 1에 있어서, 상기 특정한 작업 요청은: (a) 판독 동작, 또는 (b) 기록 동작 중 하나 이상을 포함하는, 시스템.

6. 방법에 있어서,

하나 이상의 컴퓨팅 디바이스들에 의해:

실행을 위해 수용된 작업 요청들에 응답하여 공유 자원을 이용하도록 제 1 작업 타겟 및 제 2 작업 타겟을 구성하는 것으로서, 상기 제 1 작업 타겟은 제 1 프로비저닝된 스루풋 레이트를 가지며, 상기 제 2 작업 타겟은 제 2 프로비저닝된 스루풋 레이트를 갖는, 상기 실행을 위해 제 1 작업 타겟 및 제 2 작업 타겟을 구성하는 단계;

작업 요청들의 허가 제어를 위해 각각의 토큰 버킷 세트들을 갖고 상기 제 1 작업 타겟 및 상기 제 2 작업 타겟을 구성하는 것으로서, 각각의 토큰 버킷 세트는 그 토큰 모집단이 실행을 위해 작업 요청을 수용할지를 결정하기 위해 사용되는 하나 이상의 버킷들을 포함하는, 상기 허가 제어를 위해 제 1 작업 타겟 및 상기 제 2 작업 타겟을 구성하는 단계;

(a) 제 1 시간 간격 동안 상기 제 1 및 제 2 작업 타겟들에서 작업 요청 도착률들을 표시한 제 1 메트릭, 및 (b) 상기 제 1 및 제 2 프로비저닝된 스루풋 레이트들과 연관된 제 2 메트릭을 결정하는 단계;

상기 제 1 메트릭, 상기 제 2 메트릭, 및 상기 공유 자원의 스루풋 한계에 적어도 부분적으로 기초하여 상기 제 1 작업 타겟의 특정한 버킷에 특정한 수의 토큰들을 부가하는 단계; 및

상기 제 1 작업 타겟의 상기 특정한 버킷의 상기 토큰 모집단에 적어도 부분적으로 기초하여 제 2 시간 간격 동안 실행을 위해 상기 제 1 작업 타겟으로 향해진 특정한 작업 요청을 수용하는 단계를 수행하는 단계를 포함하는, 방법.

7. 항목 6에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

상기 공유된 자원의 스루풋 한계에 적어도 부분적으로 기초하여 상기 제 1 및 제 2 작업 타겟들의 버킷 세트들 중에서 분배될 조합된 수의 토큰들을 결정하는 것을 수행하는 단계를 더 포함하며, 상기 특정한 수의 토큰들은 상기 조합된 수보다 크지 않은, 방법.

8. 항목 7에 있어서, 상기 조합된 수의 토큰들은 상기 공유된 자원의 상기 스루풋 한계로부터, 상기 제 1 및 제 2 프로비저닝된 스루풋 레이트들의 합을 감함으로써 적어도 부분적으로 결정되는, 방법.

9. 항목 6에 있어서, 상기 제 1 작업 타겟의 상기 버킷 세트는 토큰 모집단이 상기 작업 요청 도착률이 임계치보다 작은 정상 동작 모드 동안 허가 제어를 위해 검사되는 정상-모드 버킷, 및 토큰 모집단이 상기 작업 요청 도착률이 상기 임계치보다 작지 않은 버스트 동작 모드 동안 허가 제어를 위해 검사되는 버스트-모드 버킷을 포함하며, 상기 특정한 버킷은 상기 버스트-모드 버킷을 포함하는, 방법.

10. 항목 6에 있어서, 상기 제 1 작업 타겟은 네트워크-액세스 가능한 서비스에 의해 관리된 제 1 저장 오브젝트의 적어도 일 부분을 포함하고, 상기 제 2 작업 타겟은 상기 네트워크-액세스 가능한 서비스에 의해 관리된 제 2 저장 오브젝트의 적어도 일 부분을 포함하며, 상기 공유 자원는 상기 제 1 작업 타겟 및 상기 제 2 작업 타겟이 저장되는 저장 디바이스를 포함하는, 방법.

11. 항목 6에 있어서, 상기 제 1 작업 타겟은 네트워크-액세스 가능한 다중-임차자 데이터베이스 서비스에 의해 관리된 제 1 테이블 파티션의 적어도 일 부분을 포함하며, 상기 제 2 작업 타겟은 상기 네트워크-액세스 가능한 다중-임차자 데이터베이스 서비스에 의해 관리된 제 2 테이블의 적어도 일 부분을 포함하는, 방법.

12. 항목 6에 있어서, 상기 공유된 자원는 소프트웨어 모듈의 데이터 구조를 포함하는, 방법.

13. 항목 6에 있어서, 상기 특정한 작업 요청은: (a) 판독 동작, 또는 (b) 기록 동작 중 하나 이상을 포함하는, 방법.

14. 항목 6에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

상기 제 1 메트릭, 상기 제 2 메트릭, 및 상기 스루풋 한계의 특정한 함수에 적어도 부분적으로 기초하여 상기 특정한 수의 토큰들을 결정하는 단계;

상기 제 1 및 제 2 작업 타겟들과 연관된 하나 이상의 부가적인 메트릭들을 모니터링하는 단계; 및

상기 하나 이상의 부가적인 메트릭들에 적어도 부분적으로 기초하여 상기 특정한 함수를 수정하는 단계를 수행하는 단계를 더 포함하는, 방법.

15. 하나 이상의 프로세서들 상에서 실행될 때, 프로그램 지시들을 저장한 비-일시적 컴퓨터-액세스 가능한 저장 매체에 있어서, 상기 프로그램 지시들은,

실행을 위해 수용된 작업 요청들에 응답하여 공유된 자원을 이용하도록 제 1 작업 타겟 및 제 2 작업 타겟을 구성하는 것으로서, 상기 제 1 작업 타겟은 제 1 프로비저닝된 스루풋 레이트를 가지며, 상기 제 2 작업 타겟은 제 2 프로비저닝된 스루풋 레이트를 갖는, 상기 실행을 위해 제 1 작업 타겟 및 제 2 작업 타겟을 구성하고;

(a) 제 1 시간 간격 동안 상기 제 1 및 제 2 작업 타겟들에서 작업 요청 도착률들을 표시한 제 1 메트릭, 및 (b) 상기 제 1 및 제 2 프로비저닝된 스루풋 레이트들과 연관된 제 2 메트릭을 결정하고;

상기 제 1 메트릭, 상기 제 2 메트릭, 및 상기 공유된 자원의 스루풋 한계에 적어도 부분적으로 기초하여 상기 제 1 작업 타겟의 특정한 버킷에 특정한 수의 토큰들을 부가하며; 및

상기 제 1 작업 타겟의 상기 특정한 버킷의 토큰 모집단에 적어도 부분적으로 기초하여 제 2 시간 간격 동안 실행을 위해 상기 제 1 작업 타겟으로 향해진 특정한 작업 요청을 수용하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

16. 항목 15에 있어서, 상기 지시들은, 상기 하나 이상의 프로세서들 상에서 실행될 때:

상기 공유된 자원의 상기 스루풋 한계에 적어도 부분적으로 기초하여 상기 제 1 및 제 2 작업 타겟들의 상기 버킷 세트들 중에서 분배될 조합된 수의 토큰들을 결정하며, 상기 트겅한 수의 토큰들은 상기 조합된 수보다 크지 않은, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

17. 항목 15에 있어서, 상기 제 1 작업 타겟의 상기 버킷 세트는 모집단이 상기 작업 요청 도착률이 임계치보다 작은 정상 동작 모드 동안 허가 제어를 위해 검사되는 정상-모드 버킷, 및 토큰 모집단이 상기 작업 요청 도착률이 상기 임계치보다 작지 않은 버스트 동작 모드 동안 허가 제어를 위해 검사되는 버스트-모드 버킷을 포함하며, 상기 특정한 버킷은 상기 버스트-모드 버킷을 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

18. 항목 15에 있어서, 상기 제 1 작업 타겟은 네트워크-액세스 가능한 서비스에 의해 관리된 제 1 저장 오브젝트의 적어도 일 부분을 포함하고, 상기 제 2 작업 타겟은 상기 네트워크-액세스 가능한 서비스에 의해 관리된 제 2 저장 오브젝트의 적어도 일 부분을 포함하며, 상기 공유 자원는 상기 제 1 작업 타겟 및 상기 제 2 작업 타겟이 저장되는 저장 디바이스를 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

19. 항목 15에 있어서, 상기 공유 자원는 운영 시스템에서 구현된 논리적 자원을 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

20. 항목 15에 있어서, 상기 특정한 작업 요청은: (a) 판독 동작, 또는 (b) 기록 동작 중 하나 이상을 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

1. 시스템에 있어서,

하나 이상의 컴퓨팅 디바이스들로서:

작업 타겟에서 워크로드 관리와 연관된 하나 이상의 토큰 버킷들을 인스턴스화하는 것으로서, 상기 작업 타겟은 실행을 위해 작업 요청들을 수용하기 위한 각각의 세트들의 허가 제어 파라미터들을 가진 동작의 복수의 모드들에서 동작하도록 구성되며, 작업 요청을 수용하기 위한 결정은 상기 하나 이상의 토큰 버킷들 중 적어도 하나의 버킷의 토큰 모집단에 적어도 부분적으로 기초하여 이루어지는, 상기 인스턴스화하기;

상기 하나 이상의 토큰 버킷들의 특정한 토큰 버킷에 적용될 토큰 가격 책정 정책을 결정하는 것으로서, 상기 토큰 가격 책정 정책은 (a) 상기 토큰 가격 책정 정책이 적용되는 상기 동작의 복수의 모드들 중 적어도 버스트 동작 모드의 식별을 포함한, 상기 토큰 가격 책정 정책에 대한 하나 이상의 적용 가능성 기준들, 및 (b) 상기 특정한 토큰 버킷의 토큰 모집단에 대한 변화를 위해, 클라이언트에 청구될 가격 책정 양을 표시하는, 상기 결정하기;

시간 기간에 걸쳐, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 하나 이상의 변화들을 기록하는 것으로서, 상기 하나 이상의 변화들은 상기 하나 이상의 적용 가능성 기준들이 충족되는 상기 작업 타겟의 버스트 동작 모드 동안 발생하는, 상기 기록하기; 및

상기 시간 기간에 걸쳐 기록된 상기 하나 이상의 변화들에 적어도 부분적으로 기초하여 상기 클라이언트에 청구될 과금 양을 생성하는, 시스템.

2. 항목 1에 있어서, 상기 하나 이상의 토큰 버킷들은 토큰 모집단이 상기 작업 타겟의 동작의 모드를 결정하기 위해 사용되는 정상-모드 버킷, 및 토큰 모집단이 동작의 상기 버스트 모드 동안 작업 요청을 수용할지를 결정하기 위해 사용되는 하나 이상의 버스트-모드 버킷들을 포함하고, 특정한 토큰 버킷은 상기 하나 이상의 버스트-모드 버킷들의 버스트-모드 버킷을 포함하는, 시스템.

3. 항목 2에 있어서, 상기 하나 이상의 버스트-모드 버킷들은 토큰 모집단이 상기 작업 타겟에서 상기 이용 가능한 스루풋 용량을 표시하는 로컬-버스트-제한 버킷, 및 토큰 모집단이 복수의 작업 타겟들에 의해 공유된 자원에서 이용 가능한 스루풋 용량을 표시하는 공유-자원 용량 버킷을 포함하며, 상기 특정한 버킷은 상기 공유-용량 버킷을 포함하며, 상기 하나 이상의 적용 가능성 기준들의 특정한 적용 가능성 기준은 상기 가격 책정 정책이 상기 로컬-버스트-제한 버킷의 상기 토큰 모집단이 특정된 임계치보다 크지 않다는 결정에 응답하여 적용할 것을 표시하는, 시스템.

4. 항목 1에 있어서, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 변화는 실행을 위해 수신된 작업 요청을 수용하기 위해 소비되는 하나 이상의 토큰들의 결과로서 상기 토큰 모집단에서의 감소를 포함하는, 시스템.

5. 항목 1에 있어서, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 변화는 토큰 시장을 사용하여 구현된 토큰 판매 동작에 응답하여 상이한 버킷으로 전달되는 하나 이상의 토큰들의 결과로서 상기 토큰 모집단에서의 감소를 포함하는, 시스템.

6. 방법에 있어서,

하나 이상의 컴퓨팅 디바이스들에 의해,

작업 타겟에서 워크로드 관리와 연관된 하나 이상의 토큰 버킷들을 인스턴스화하는 것으로서, 상기 작업 타겟으로 향해진 작업 요청을 수용하기 위한 결정은 상기 하나 이상의 토큰 버킷들 중 적어도 하나의 버킷의 토큰 모집단에 적어도 부분적으로 기초하여 이루어지는, 상기 인스턴스화하기;

상기 작업 타겟의 버스트 동작 모드 동안 상기 하나 이상의 토큰 버킷들의 특정한 토큰 버킷에 적용된 토큰 가격 책정 정책을 결정하는 것으로서, 상기 토큰 가격 책정 정책은 상기 특정한 토큰 버킷의 토큰 모집단에 대한 변화에 대해 클라이언트에 청구될 가격 책정 양을 표시하는, 상기 결정하기;

시간 기간에 걸쳐, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 하나 이상의 변화들을 기록하는 것으로서, 상기 하나 이상의 변화들은 상기 버스트 동작 모드 동안 구현되는, 상기 기록하기; 및

상기 시간 기간에 걸쳐 기록된 상기 하나 이상의 변화들에 적어도 부분적으로 기초하여 상기 클라이언트에 청구될 과금 양을 생성하는 것을 수행하는 단계를 포함하는, 방법.

7. 항목 6에 있어서, 상기 하나 이상의 토큰 버킷들은 토큰 모집단이 상기 작업 타겟의 동작의 모드를 결정하기 위해 사용되는 정상-모드 버킷, 및 토큰 모집단이 상기 버스트 동작 모드 동안 작업 요청을 수용할지를 결정하기 위해 사용되는 하나 이상의 버스트-모드 버킷들을 포함하며, 특정한 토큰 버킷은 상기 하나 이상의 버스트-모드 버킷들의 버스트-모드 버킷을 포함하는, 방법.

8. 항목 7에 있어서, 상기 하나 이상의 버스트-모드 버킷들은 토큰 모집단이 상기 작업 타겟에서 상기 스루풋 용량을 표시하는 로컬-버스트-제한 버킷, 및 토큰 모집단이 복수의 작업 타겟들에 의해 공유된 자원에서 이용 가능한 스루풋 용량을 표시하는 공유-자원 용량 버킷을 포함하며, 상기 특정한 버킷은 상기 공유-용량 버킷을 포함하고, 상기 가격 책정 정책에 따라, 상기 방법은 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

상기 로컬-버스트-제한 버킷의 상기 토큰 모집단이 임계 기준을 충족시킨다고 결정하는 것에 응답하여, 상기 공유-자원 용량 버킷의 토큰 모집단의 특정한 변화에 상기 가격 책정 정책을 적용하는 것을 수행하는 단계를 더 포함하는, 방법.

9. 항목 6에 있어서, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 상기 변화는 실행을 위해 수신된 작업 요청을 수용하기 위해 소비되는 하나 이상의 토큰들의 결과로서 상기 토큰 모집단에서의 감소를 포함하는, 방법.

10. 항목 6에 있어서, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 변화는 토큰 시장을 사용하여 구현된 토큰 판매 동작에 응답하여 상이한 버킷으로 전달되는 하나 이상의 토큰들의 결과로서 상기 토큰 모집단에서의 감소를 포함하는, 방법.

11. 항목 10에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

특정한 클라이언트가, 상기 토큰 시장을 통해, 상기 특정한 토큰 버킷의 토큰들이 다른 토큰 버킷으로의 전달을 위해 이용 가능함을 표시할 수 있게 하는 하나 이상의 프로그램 인터페이스들을 구현하는 것을 수행하는 단계를 더 포함하는, 방법.

12. 항목 11에 있어서, 상기 토큰 가격 책정 정책은 상기 특정한 버킷으로부터 상이한 버킷으로의 토큰의 전달에 대해 청구될 양이 상기 전달에 대해 수신된 하나 이상의 경매 입찰들에 적어도 부분적으로 기초하여 결정되는, 방법.

13. 항목 6에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

클라이언트가 복수의 토큰 가격 책정 정책들 중에서 토큰 가격 책정 정책을 선택할 수 있게 하는 하나 이상의 프로그램 인터페이스들을 구현하는 것을 수행하는 단계를 더 포함하는, 방법.

14. 항목 6에 있어서, 상기 가격 책정 정책은 클라이언트-특정 예산 한계를 표시하며, 상기 클라이언트-특정 예산 한계는, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

상기 클라이언트-특정 예산 한계에 적어도 부분적으로 기초하여 상기 특정한 토큰 버킷의 상기 모집단에 대한 변화를 구현하도록 결정하는 것을 수행하는 단계를 더 포함하는, 방법.

15. 항목 6에 있어서, 상기 작업 타겟은 저장 오브젝트의 제 1 파티션을 포함하며, 상기 저장 오브젝트는 적어도 상기 제 1 파티션 및 제 2 파티션을 포함하고, 상기 특정한 버킷의 상기 토큰 모집단에 대한 상기 하나 이상의 변화들의 특정한 변화는 상기 특정한 버킷으로부터 상기 제 2 파티션의 워크로드 관리를 위해 사용된 상이한 버킷으로의 토큰의 전달의 결과인, 방법.

16. 하나 이상의 프로세서들 상에서 실행될 때, 프로그램 지시들을 저장한 비-일시적 컴퓨터-액세스 가능한 저장 매체에 있어서, 상기 프로그램 지시들은,

작업 타겟에서 허가 제어 결정들을 위해 사용된 하나 이상의 토큰 버킷들의 특정한 토큰 버킷에 적용될 토큰 가격 책정 정책을 결정하는 것으로서, 상기 토큰 가격 책정 정책은 상기 작업 타겟의 버스트 동작 모드 동안 적용되며, 상기 토큰 가격 책정 정책은 상기 특정한 토큰 버킷의 토큰 모집단에 대한 변화에 대해 클라이언트에 청구될 가격 책정 양을 표시하는, 상기 결정하기;

시간 기간에 걸쳐 동작의 상기 버스트 모드 동안 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 하나 이상의 변화들을 기록하며; 및

상기 시간 기간에 걸쳐 기록된 상기 하나 이상의 변화들에 적어도 부분적으로 기초하여 상기 클라이언트에 청구될 과금 양을 생성하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

17. 항목 16에 있어서, 상기 하나 이상의 토큰 버킷들은 토큰 모집단이 상기 작업 타겟의 정상 동작 모드 동안 작업 요청을 수용할지를 결정하기 위해 사용되는 정상-모드 버킷, 및 토큰 모집단이 동작의 상기 버스트 모드 동안 작업 요청을 수용할지를 결정하기 위해 사용되는 하나 이상의 버스트-모드 버킷들을 포함하며, 상기 특정한 토큰 버킷은 상기 하나 이상의 버스트-모드 버킷들의 버스트-모드 버킷을 포함하고, 상기 지시들은 상기 하나 이상의 프로세서들 상에서 실행될 때:

상기 정상-모드 버킷의 토큰 모집단 변화들에 적용될 상이한 토큰 가격 책정 정책을 결정하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

18. 항목 17에 있어서, 상기 하나 이상의 버스트-모드 버킷들은 토큰 모집단이 상기 작업 타겟에서 이용 가능한 스루풋 용량을 표시하는 로컬-버스트-제한 버킷, 및 토큰 모집단이 복수의 작업 타겟들에 의해 공유된 자원에서 이용 가능한 스루풋 용량을 표시하는 공유-자원 용량 버킷을 포함하며, 상기 특정한 버킷은 상기 공유-용량 버킷을 포함하고, 상기 가격 책정 정책에 따라, 상기 지시들은 상기 하나 이상의 프로세서들 상에서 실행될 때:

상기 로컬-버스트-제한 버킷의 상기 토큰 모집단이 임계 기준을 충족시킨다는 결정에 응답하여, 상기 공유-자원 용량 버킷의 토큰 모집단의 특정한 변화에 상기 가격 책정 정책을 적용하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

19. 항목 16에 있어서, 상기 특정한 토큰 버킷의 상기 토큰 모집단에 대한 상기 변화는 토큰 시장을 사용하여 구현된 토큰 판매 동작에 응답하여 상이한 버킷으로 전달되는 하나 이상의 토큰들의 결과로서 상기 토큰 모집단에서의 감소를 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

20. 항목 16에 있어서, 상기 특정한 버킷은 토큰 리필 레이트 및 최대 토큰 모집단 한계를 갖고 구성되며, 상기 가격 책정 정책은: (a) 상기 토큰 리필 레이트, 또는 (b) 상기 최대 토큰 모집단 한계 중 적어도 하나에 대한 변화에 대해 상기 클라이언트에 청구될 상이한 양의 표시를 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

1. 시스템에 있어서,

하나 이상의 컴퓨팅 디바이스들로서:

작업 타겟으로 향해진 작업 요청을 수신하고;

상기 작업 타겟과 연관된 정상-모드 토큰 버킷의 토큰 모집단이 제 1 임계 기준을 충족시킨다는 결정에 응답하여, 정상-모드 토큰 소비 정책에 따라 상기 정상-모드 토큰 버킷으로부터 하나 이상의 토큰들을 소비하며, 실행을 위해 상기 작업 요청을 수용하고; 및

상기 정상-모드 토큰 버킷의 상기 토큰 모집단이 상기 제 1 임계 기준을 충족시키지 않는다는 결정에 응답하여,

버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 토큰 모집단이 제 2 임계 기준을 충족시키는지를 결정하고;

상기 버스트-모드 토큰 버킷 세트의 상기 적어도 하나의 버킷의 상기 토큰 모집단이 상기 제 2 임계 기준을 충족시킨다는 결정에 응답하여, 버스트-모드 토큰 소비 정책에 적어도 부분적으로 기초하여 상기 버스트-모드 토큰 버킷 세트의 상기 적어도 하나의 버킷으로부터 하나 이상의 토큰들을 소비하고, 실행을 위해 상기 작업 요청을 수용하며, 및

상기 버스트-모드 토큰 버킷 세트의 상기 적어도 하나의 버킷의 상기 토큰 모집단이 상기 제 2 임계 기준을 충족시키지 않는다는 결정에 응답하여, 상기 작업 요청을 거절하도록 구성된, 상기 하나 이상의 컴퓨팅 디바이스들을 포함하는, 시스템.

2. 항목 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들은 또한:

정상 동작 모드 동안 상기 작업 타겟에서 수행될 작업 동작의 최대 레이트를 표시한, 프로비저닝된 스루풋 용량을 상기 작업 타겟에 할당하고;

상기 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초한 레이트에서 상기 정상-모드 토큰 버킷을 리필하며;

상기 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초한 다른 레이트에서 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷을 리필하도록 구성되는, 시스템.

3. 항목 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들은 또한:

작업 요청들이 수신된 평균 레이트가 상기 작업 타겟에 대해 지정된 프로비저닝된 레이트보다 작은 특정한 시간 기간의 끝에서, 하나 이상의 작업 토큰들이 상기 정상-모드 토큰 버킷에 남아있다는 결정에 응답하여, 상기 정상-모드 토큰 버킷에 남아있는 작업 토큰들의 수에 적어도 부분적으로 기초한 양만큼 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 상기 토큰 모집단을 증가시키도록 구성되는, 시스템.

4. 항목 1에 있어서, 상기 버스트-모드 버킷 세트는 최대 토큰 모집단이 상기 작업 타겟에서 작업 동작들을 위해 지원된 최대 버스트 레이트를 표시하는 로컬-버스트-제한 토큰 버킷, 및 토큰 모집단이 복수의 작업 오브젝트들에 의해 공유된 자원의 이용 가능한 스루풋 용량을 표시하는 공유-자원 토큰 버킷을 포함하며, 상기 정상-모드 토큰 버킷의 상기 토큰 모집단이 상기 제 1 임계 기준을 충족시키지 않는다는 상기 결정에 응답하여, 상기 하나 이상의 컴퓨팅 디바이스들은 또한:

상기 로컬-버스트-제한 토큰 버킷의 상기 토큰 모집단이 0을 초과하며 상기 공유-자원 토큰 버킷의 상기 토큰 모집단이 0을 초과한다고 결정하는 것에 응답하여 실행을 위해 상기 작업 요청을 수용하도록 구성되는, 시스템.

5. 항목 1에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들은 또한:

실행을 위해 상기 작업 요청의 상기 수용 이전에, 상기 작업 요청에 응답하여 수행될 작업의 양의 추정치를 생성하고;

상기 작업 요청의 상기 수용 다음에, 상기 작업 요청에 대응하는 수행된 작업의 양을 결정하며;

상기 수행된 작업의 양 및 추정치 사이에서의 차이의 결정에 응답하여, 상기 차이에 적어도 부분적으로 기초하여, (a) 상기 버스트-모드 토큰 버킷 세트 또는 (b) 상기 버스트-모드 토큰 버킷 세트 중 하나 이상의 적어도 하나의 버킷의 상기 토큰 모집단을 수정하는 것을 수행하는 단계를 더 포함하는, 시스템.

6. 방법에 있어서,

하나 이상의 컴퓨팅 디바이스들에 의해:

작업 타겟으로 향해진 작업 요청을 수신하는 단계;

상기 작업 타겟과 연관된 정상-모드 토큰 버킷의 토큰 모집단을 결정하는 단계; 및

상기 정상-모드 토큰 버킷의 상기 토큰 모집단이 제 1 임계 기준을 충족시킨다고 결정하는 것에 응답하여,

상기 작업 타겟과 연관된 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 상기 토큰 모집단이 제 2 임계 기준을 충족시킨다고 결정하는 단계,

실행을 위해 상기 작업 요청을 수용하는 단계; 및

버스트-모드 토큰 소비 정책에 적어도 부분적으로 기초하여 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 상기 토큰 모집단을 수정하는 것을 수행하는 단계를 포함하는, 방법.

정상 동작 모드 동안 상기 작업 타겟에서 수행될 작업 동작들의 최대 레이트를 표시한 프로비저닝된 스루풋 용량을 상기 작업 타겟에 할당하는 단계;

상기 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초한 레이트에서 상기 정상-모드 토큰 버킷을 리필하는 단계; 및

상기 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초한 상이한 레이트에서 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷을 리필하는 단계를 수행하는 단계를 더 포함하는, 방법.

8. 항목 6에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

상기 작업 타겟이 정상 모드에서 동작한 특정한 시간 기간의 끝에서, 하나 이상의 작업 토큰들이 상기 정상-모드 토큰 버킷에 남아있다고 결정하는 것에 응답하여, 상기 정상-모드 토큰 버킷에 남아있는 작업 토큰들의 수에 적어도 부분적으로 기초한 양만큼 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 상기 토큰 모집단을 증가시키는 단계를 수행하는 단계를 더 포함하는, 방법.

9. 항목 6에 있어서, 상기 버스트 모드 버킷 세트는 최대 토큰 모집단이 상기 작업 타겟에서 작업 동작들에 대해 지원된 최대 버스트 레이트를 표시하는 로컬-버스트-제한 토큰, 및 토큰 모집단이 복수의 작업 오브젝트들에 의해 공유된 자원의 이용 가능한 스루풋 용량을 표시하는 공유-자원 토큰 버킷을 포함하고, 상기 정상-모드 토큰 버킷의 상기 토큰 모집단이 제 1 임계 기준을 충족시킨다고 상기 결정하는 것에 응답하여, 상기 방법은 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

상기 로컬-버스트-제한 토큰 버킷의 상기 토큰 모집단이 0을 초과하며 상기 공유-자원 토큰 버킷의 상기 토큰 모집단이 0을 초과한다고 결정하는 것에 응답하여 실행을 위해 상기 작업 요청을 수용하는 단계를 수행하는 단계를 더 포함하는, 방법.

10. 항목 6에 있어서, 상기 하나 이상의 컴퓨팅 디바이스들에 의해:

실행을 위해 상기 작업 요청을 수용하는 것 이전에, 상기 작업 요청에 응답하여 수행될 작업의 양의 추정치를 생성하는 것;

상기 개시 후, 상기 작업 요청에 대응하는 수행된 작업의 양을 결정하는 단계; 및

상기 작업의 양 및 상기 추정치 사이에서의 차이를 결정하는 것에 응답하여, 상기 차이에 적어도 부분적으로 기초하여, (a) 상기 버스트-모드 토큰 버킷 세트 또는 (b) 상기 버스트-모드 토큰 버킷 세트 중 하나 이상의 적어도 하나의 버킷의 상기 토큰 모집단을 수정하는 것을 수행하는 단계를 더 포함하는, 방법.

11. 항목 6에 있어서, 상기 작업 타겟은 저장 오브젝트의 적어도 일 부분을 포함하며, 상기 작업 요청은 (a) 판독 동작 또는 (b) 기록 동작 중 적어도 하나를 포함하는, 방법.

12. 항목 6에 있어서, 상기 버스트-모드 버킷 세트는 판독 동작들을 포함한 작업 요청들에 대한 허가 제어를 위해 사용된 판독-버스트 토큰 버킷, 및 기록 동작들을 포함한 기록 요청들에 대한 허가 제어를 위해 사용된 기록-버스트 토큰 버킷을 포함하는, 방법.

시간 기간에 걸쳐 작업 요청 도착률을 모니터링하는 것; 및

상기 작업 요청 도착률을 모니터링한 결과에 적어도 부분적으로 기초하여 상기 버스트-모드토큰 버킷 세트의 적어도 하나의 버킷의 최대 토큰 모집단 한계를 수정하는 것을 수행하는 단계를 더 포함하는, 방법.

상기 작업 타겟에서 버스트-모드 동작들과 연관된 가격 책정 정책의 표시를 클라이언트에 제공하는 것; 및

상기 가격 책정 정책에 따라 클라이언트로부터 수신된 버스트-모드 용량 증가 요청에 적어도 부분적으로 기초하여 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 최대 토큰 모집단 한계를 수정하는 것을 수행하는 단계를 더 포함하는, 방법.

작업 타겟으로 향해진 작업 요청을 수신하며;

제 1 임계 기준에 적어도 부분적으로 기초하여, 상기 작업 타겟이 버스트 동작 모드에 있다는 결정에 응답하여,

상기 작업 타겟과 연관된 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 상기 토큰 모집단이 제 2 임계 기준을 충족시킨다고 결정하며; 및

실행을 위해 상기 작업 요청을 수용하는, 상기 하나 이상의 메모리들을 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

16. 항목 15에 있어서, 하나 이상의 프로세서들 상에서 실행될 때 상기 프로그램 지시들은:

상기 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초한 레이트에서 상기 작업 요청과 연관된 정상-모드 토큰 버킷을 리필하는 것으로서, 상기 제 1 임계 기준은 상기 정상-모드 토큰 버킷의 토큰 모집단에 적어도 부분적으로 기초하는, 상기 정상-모드 토큰 버킷 리필하기; 및

상기 프로비저닝된 스루풋 용량에 적어도 부분적으로 기초한 다른 레이트에서 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷을 리필하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

17. 항목 15에 있어서, 상기 하나 이상의 프로세서들 상에서 실행될 때 상기 지시들은:

특정한 시간 기간의 끝에서, 하나 이상의 작업 토큰들이 상기 작업 타겟과 연관된 정상-모드 토큰 버킷에 남아있다는 결정에 응답하여, 상기 정상-모드 토큰 버킷에 남아있는 작업 토큰들의 수에 적어도 부분적으로 기초한 양만큼 상기 버스트-모드 토큰 버킷 세트의 적어도 하나의 버킷의 상기 토큰 모집단을 증가시키는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

18. 항목 15에 있어서, 상기 버스트 모드 버킷 세트는 최대 토큰 모집단이 상기 작업 타겟에서 작업 동작들에 대해 지원된 최대 버스트 레이트를 표시하는 로컬-버스트-제한 토큰 버킷, 및 토큰 모집단이 복수의 작업 오브젝트들에 의해 공유된 자원의 이용 가능한 스루풋 용량을 표시하는 공유-자원 토큰 버킷을 포함하며, 상기 제 1 임계 기준이 충족되었다는 결정에 응답하여, 상기 하나 이상의 프로세서들 상에서 실행될 때 상기 지시들은:

상기 로컬-버스트-제한 토큰 버킷의 상기 토큰 모집단이 0을 초과하며 상기 공유-자원 토큰 버킷의 상기 토큰 모집단이 0을 초과한다고 결정하는 것에 응답하여 실행을 위해 상기 작업 요청을 수용하도록 구성되는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

19. 항목 15에 있어서, 상기 하나 이상의 프로세서들 상에서 실행될 때 상기 지시들은:

상기 버스트-모드 토큰 버킷 세트의 상기 적어도 하나의 버킷의 상기 토큰 모집단이 상기 제 2 임계 기준을 충족시킨다는 상기 결정에 응답하여, 토큰 소비 정책에 따라 상기 적어도 하나의 버킷으로부터 적어도 하나의 토큰을 소비하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

20. 항목 15에 있어서, 상기 작업 타겟은 데이터베이스 테이블의 파티션의 적어도 일 부분을 포함하며, 상기 작업 요청은 (a) 판독 동작 또는 (b) 기록 동작 중 적어도 하나를 포함하는, 비-일시적 컴퓨터-액세스 가능한 저장 매체.

결론

다양한 실시예들은 컴퓨터-액세스 가능한 매체에 대한 앞서 말한 설명에 따라 구현된 지시들 및/또는 데이터를 수신하는 것, 전송하는 것, 또는 저장하는 것을 더 포함할 수 있다. 일반적으로 말해서, 컴퓨터-액세스 가능한 매체는 예로서, 디스크 또는 DVD/CD-ROM과 같은 자기 또는 광 미디어, RAM(예로서, SDRAM, DDR, RDRAM, SRAM 등), ROM 등과 같은 휘발성 또는 비-휘발성 미디어와 같은 저장 미디어 또는 메모리 미디어, 뿐만 아니라 네트워크 및/또는 무선 링크와 같은 통신 매체를 통해 전달된 전기, 전자기, 또는 디지털 신호들과 같은 송신 미디어 또는 신호들을 포함할 수 있다.

도면들에 예시되며 여기에서 설명된 바와 같은 다양한 방법들이 방법들의 대표적인 실시예들을 표현한다. 방법들은 소프트웨어, 하드웨어 또는 그것의 조합으로 구현될 수 있다. 방법의 순서는 변경될 수 있으며, 다양한 요소들이 부가되고, 재순서화되고, 조합되고, 생략되고, 수정될 수 있다.

다양한 수정들 및 변화들은 본 개시의 이득을 가진 이 기술분야의 숙련자에게 명백할 바와 같이 이루어질 수 있다. 제한적 의미보다는 예시적으로 간주될 모든 이러한 수정들 및 변화들, 및 그에 따라 상기 설명을 포괄하도록 의도된다.

Claims

시스템에 있어서,
하나 이상의 컴퓨팅 디바이스로서:
작업 요청들의 허가 제어를 위한 토큰 버킷들의 각각의 세트로 복수의 작업 타겟(work target)을 구성하고 - 상기 복수의 작업 타겟은 토큰 버킷들의 제1 세트로 구성된 제1 작업 타겟을 포함하고, 상기 제1 작업 타겟에서의 실행에 대한 작업 요청을 수용하기 위한 결정은 상기 제1 세트의 하나 이상의 토큰 버킷의 토큰 모집단(token population)에 적어도 부분적으로 기초함 -;
상기 제1 작업 타겟에서 토큰 공유 평가 기준이 충족되었다는 결정에 응답하여,
상기 제1 작업 타겟으로부터 토큰 모집단 정보가 교환될 제2 작업 타겟을 상기 복수의 작업 타겟 중에서 식별하고 - 상기 제2 작업 타겟은 토큰 버킷들의 제2 세트로 구성됨 -;
상기 제1 세트의 제1 버킷 및 상기 제2 세트의 제2 버킷의 각각의 토큰 모집단의 분석에 적어도 부분적으로 기초하여, 상기 제1 및 제2 버킷 간의 토큰 전달을 개시할지 여부를 결정하고;
토큰 전달을 개시한다는 결정에 응답하여,
상기 토큰 전달에 대해 식별된 전달 방향에 따라, 상기 제1 및 제2 버킷 중 하나의 버킷의 상기 토큰 모집단을 특정한 수의 토큰만큼 증가시키고, 상기 제1 및 제2 버킷 중 다른 버킷의 상기 토큰 모집단을 상기 특정한 수의 토큰만큼 감소시키고;
상기 제1 작업 타겟으로 향하는 작업 요청을 수신하는 것에 응답하여, 상기 제1 버킷의 변화된 토큰 모집단에 적어도 부분적으로 기초하여 실행을 위한 상기 작업 요청을 수용하도록 구성된,
상기 하나 이상의 컴퓨팅 디바이스를 포함하는 시스템.
제1항에 있어서,
상기 복수의 작업 타겟은 제1 클라이언트를 위한 네트워크-액세스 가능한 저장 서비스에서 생성되는 하나 이상의 저장 오브젝트의 제1 모음(collection), 및 제2 클라이언트를 위한 네트워크-액세스 가능한 저장 서비스에서 생성되는 하나 이상의 저장 오브젝트의 제2 모음을 포함하고, 상기 제1 작업 타겟은 상기 제1 모음의 저장 오브젝트의 적어도 일부를 포함하고, 상기 하나 이상의 컴퓨팅 디바이스는 상기 제2 작업 타겟을 식별하기 위하여 상기 제1 모음으로부터 상기 제2 작업 타겟을 선택하도록 구성되는, 시스템.
제1항에 있어서,
상기 제1 작업 타겟은 네트워크-액세스 가능한 데이터베이스 서비스의 특정한 클라이언트를 위해 인스턴스화되는 베이스(base) 데이터베이스 테이블의 적어도 일부를 포함하고, 상기 제2 작업 타겟은 상기 베이스 데이터베이스 테이블에 대한 2차 인덱스를 구현하기 위하여 상기 네트워크-액세스 가능한 데이터베이스 서비스에서 인스턴스화되는 도출된(derived) 데이터베이스 테이블의 적어도 일부를 포함하는, 시스템.
제1항에 있어서,
상기 토큰 버킷들의 제1 세트는 상기 제1 작업 타겟의 동작의 정상 모드 동안 허가 제어에 사용되는 정상-모드 버킷, 및 상기 제1 작업 타겟에서의 버스트 모드 동작 동안 허가 제어에 사용되는 하나 이상의 버스트-모드 토큰 버킷을 포함하고, 상기 하나 이상의 버스트-모드 토큰 버킷은 상기 제1 버킷을 포함하는, 시스템.
하나 이상의 컴퓨팅 디바이스에 의해:
작업 요청들의 허가 제어를 위한 토큰 버킷 세트들 각각으로 복수의 작업 타겟을 구성하는 단계 - 상기 복수의 작업 타겟은 제1 토큰 버킷 세트로 구성된 제1 작업 타겟을 포함하고, 상기 제1 작업 타겟에서의 실행에 대한 작업 요청을 수용하기 위한 결정은 상기 제1 토큰 버킷 세트의 하나 이상의 토큰 버킷의 토큰 모집단에 적어도 부분적으로 기초함 -; 및
상기 제1 작업 타겟에서 토큰 공유 평가 기준이 충족되었다는 결정에 응답하여,
상기 제1 토큰 버킷 세트의 제1 버킷 및 상기 복수의 작업 타겟 중 제2 작업 타겟과 연관된 제2 토큰 버킷 세트의 제2 버킷 사이에서 특정한 방향으로 토큰 전달을 개시하고,
상기 제1 작업 타겟으로 향하는 작업 요청을 수신하는 것에 응답하여, 상기 토큰 전달 이후에 상기 제1 버킷의 상기 토큰 모집단에 적어도 부분적으로 기초하여 실행을 위한 상기 작업 요청을 수용하는 단계
를 수행하는 것을 포함하는 방법.
제5항에 있어서,
상기 복수의 작업 타겟은 제1 클라이언트를 위한 네트워크-액세스 가능한 저장 서비스에서 생성되는 하나 이상의 저장 오브젝트의 제1 모음, 및 제2 클라이언트를 위한 네트워크-액세스 가능한 저장 서비스에서 생성되는 하나 이상의 저장 오브젝트의 제2 모음을 포함하고, 상기 제1 작업 타겟은 상기 제1 모음의 저장 오브젝트의 적어도 일부를 포함하고,
상기 방법은,
상기 하나 이상의 컴퓨팅 디바이스에 의해:
상기 제1 모음으로부터 상기 제2 작업 타겟을 선택하는 단계를 수행하는 것을 더 포함하는 방법.
제5항에 있어서,
상기 제1 작업 타겟은 네트워크-액세스 가능한 데이터베이스 서비스의 특정한 클라이언트를 위해 인스턴스화되는 베이스 데이터베이스 테이블의 적어도 일부를 포함하고, 상기 제2 작업 타겟은 상기 베이스 데이터베이스 테이블에 대한 2차 인덱스를 구현하기 위하여 상기 네트워크-액세스 가능한 데이터베이스 서비스에서 인스턴스화되는 도출된 데이터베이스 테이블의 적어도 일부를 포함하는, 방법.
제5항에 있어서,
상기 제1 토큰 버킷 세트는 상기 제1 작업 타겟의 동작의 정상 모드 동안 허가 제어에 사용되는 정상-모드 버킷, 및 상기 제1 작업 타겟의 동작의 버스트 모드 동안 허가 제어에 사용되는 하나 이상의 버스트-모드 토큰 버킷을 포함하고, 상기 하나 이상의 버스트-모드 토큰 버킷은 상기 제1 버킷을 포함하는, 방법.
제5항에 있어서,
상기 하나 이상의 컴퓨팅 디바이스에 의해:
랜덤 선택 정책을 사용하여 상기 제2 작업 타겟을 선택하는 단계를 수행하는 것을 더 포함하는 방법.
제5항에 있어서,
상기 하나 이상의 컴퓨팅 디바이스에 의해:
가십 프로토콜(gossip protocol)에 따라 상기 제2 작업 타겟을 선택하는 단계를 수행하는 것을 더 포함하는 방법.
제5항에 있어서,
상기 하나 이상의 컴퓨팅 디바이스에 의해:
(a) 상기 제1 작업 타겟에서 이전 평가가 개시된 후로부터의 시간의 양, (b) 상기 제1 토큰 버킷의 상기 토큰 모집단이 제1 임계 값 아래로 떨어졌다는 표시, (c) 상기 제1 토큰 버킷의 상기 토큰 모집단이 제2 임계 값 위로 넘어섰다는 표시, 또는 (d) 상기 제1 작업 타겟에서의 작업 요청들에 대한 거부율이 특정한 임계 값을 넘어선다는 표시 중 하나 이상에 부분적으로 기초하여 상기 토큰 공유 평가 기준이 충족되었는지 여부를 결정하는 단계를 수행하는 것을 더 포함하는 방법.
제5항에 있어서,
상기 제1 작업 타겟은 저장 오브젝트의 제1 논리 파티션의 복수의 복제본(replica) 중 제1 복제본을 포함하고, 상기 복수의 복제본 중 각각의 복제본에, (a) 마스터 역할 및 (b) 슬레이브 역할 중 하나를 포함하는 역할이 할당되고, 상기 제1 논리 파티션으로 향해진 기록 동작을 포함하는 작업 요청에 대한 허가 제어는 상기 마스터 역할이 할당된 복제본에서 수행되고, 상기 제1 복제본에 상기 제1 논리 파티션에 대한 제1 역할이 할당되고,
상기 방법은,
상기 하나 이상의 컴퓨팅 디바이스에 의해:
상기 저장 오브젝트의 제2 논리 파티션의 특정한 복제본을 상기 제2 작업 타겟으로서 선택하는 단계 - 상기 제2 논리 파티션에 대하여, 상기 제1 논리 파티션에 대한 상기 제1 복제본의 상기 역할과 동일한 역할이 상기 특정한 복제본에 할당됨 -
를 수행하는 것을 더 포함하는 방법.
제5항에 있어서,
상기 제1 버킷과 상기 제2 버킷 사이에서 상기 특정한 방향으로 상기 토큰 전달을 개시하는 것은, 특정 시간 윈도우 내에서 상기 제1 작업 타겟 및 상기 제2 작업 타겟 사이에서 다른 토큰 전달이 구현되지 않았다는 결정에 적어도 부분적으로 기초하는 것인, 방법.
제5항에 있어서,
상기 특정한 방향은 상기 제1 및 제2 버킷 중 더 큰 토큰 모집단을 갖는 토큰 버킷으로부터 상기 제1 및 제2 버킷 중 더 작은 토큰 모집단을 갖는 토큰 버킷을 향하며,
상기 방법은,
상기 하나 이상의 컴퓨팅 디바이스에 의해:
상기 더 큰 토큰 모집단과 상기 더 작은 토큰 모집단 간의 차이의 함수로서 전달되는 토큰의 수를 결정하는 단계를 수행하는 것을 포함하는 방법.
프로그램 명령어들을 저장하는 비일시적 컴퓨터-액세스 가능한 저장 매체로서,
상기 프로그램 명령어들은 하나 이상의 프로세서에 의해 실행될 때:
제1 토큰 버킷 세트의 제1 버킷과 제2 토큰 버킷 세트의 제2 버킷 사이에서 전달되는 토큰의 개수를 결정하고 - 상기 제1 토큰 버킷 세트는 복수의 작업 타겟 중 제1 작업 타겟으로 향하는 작업 요청들의 허가 제어에 사용되고, 상기 제2 토큰 버킷 세트는 상기 복수의 작업 타겟 중 제2 작업 타겟에서의 허가 제어에 사용됨 -;
상기 제1 버킷 및 상기 제2 버킷 사이에서 특정한 방향으로 상기 개수의 토큰의 전달을 개시하고;
상기 제1 작업 타겟으로 향하는 작업 요청을 수신하는 것에 응답하여, 상기 전달 이후에 상기 제1 버킷의 토큰 모집단에 적어도 부분적으로 기초하여 실행을 위한 상기 작업 요청을 수용하는, 비일시적 컴퓨터-액세스 가능한 저장 매체.