세분화된 속도 제한 용어
공정한 사용
XBOX는 사용자가 어떤 게임(또는 앱)을 플레이하든 모든 사용자가 동일한 고품질 경험을 해야 한다고 믿습니다. 세분화된 속도 제한(FGRL)은 다음 시나리오를 해결합니다. 개발자 A는 모든 XBOX services 모범 사례를 따라 서비스의 최적 사용을 보장하는 타이틀을 방금 출시했으며, 개발자 B도 방금 타이틀을 출시했지만 이 타이틀에는 알려지지 않은 버그가 있습니다. 이 버그는 타이틀과 각 사용자가 presence를 스팸으로 보내게 하여 서비스가 과부하 상태에 이르게 합니다. 서비스는 느려지고 결국 중단되어 개발자 B의 버그로 인해 문제가 발생했음에도 불구하고 개발자 A의 사용자에 대한 경험을 손상시킵니다. FGRL이 구현되었다면, 서비스는 잘못 동작하는 타이틀로부터 요청을 받는 것을 중지할 수 있었을 것이며, 개발자 A의 타이틀에 리소스 파이의 공정한 부분을 제공할 수 있었을 것입니다.타이틀 및 사용자 세분성
XBOX 리소스의 공정한 사용을 보장하기 위해 타이틀과 사용자가 키로 선택되었습니다. 사용자만 추적하면 사용자 경험이 각 타이틀 통합에 좌우되는 시나리오가 만들어질 것입니다. 예를 들어, 대부분의 타이틀은 이미 people 서비스를 사용하므로 이 예제를 위해 세분화된 속도 제한이 people 서비스에 설정되어 5분에 100개 이하의 요청만 허용된다고 가정해 보겠습니다. 사용자가 1분 안에 100개의 요청을 하는 게임을 플레이한다면, 한도가 초과되고 사용자는 people 서비스에 더 이상 요청을 할 수 없게 됩니다. 같은 기간에 사용자가 홈 화면으로 돌아가 친구 목록을 클릭한다고 상상해 보세요: 사용자는 이미 한도를 초과했으므로, 홈 화면이 사용자를 제한된 상태로 만든 원인이 아니더라도 5분 간격이 지날 때까지 친구 목록 호출은 실패할 것입니다. 또는 타이틀에만 기반한 제한은 마찬가지로 불공정한 결과를 낳을 것입니다. 타이틀당 한도를 설정하면 타이틀의 인기를 무시하게 되고, 요청은 한도에 도달할 때까지 선착순으로 처리될 것입니다. 사용자와 타이틀의 페어링은 활성 사용자 수에 비추어 적절한 것보다 더 많은 리소스를 사용하는 타이틀이 없도록 하는 동시에 각 사용자에게 리소스 파이의 일관된 조각을 제공합니다. 위의 다이어그램은 요청이 어떻게 처리되는지에 대한 상위 수준 보기를 보여줍니다. 먼저 요청이 생성된 다음 원하는 서비스에서 수신됩니다. 요청을 받으면 시스템은 사용자와 타이틀이 함께 서비스에 액세스한 횟수를 확인합니다.- 요청이 한도 미만이면 정상적으로 처리됩니다.
- 요청이 한도 이상인 것으로 확인되면 서비스는 이를 삭제하고 대신 429 응답을 반환합니다.
버스트 및 지속 한도
전통적으로 속도 제한은 주어진 시간 동안 추적되는 엔드포인트당 하나의 한도로 구성됩니다. 이 기간은 엔터티의 요청 카운트가 추적되는 시간을 나타냅니다. 기간이 끝나면 엔터티의 카운트가 0으로 재설정되어 다시 추적이 시작됩니다. 이 접근 방식은 대부분의 API에 적용되지만, 이 접근 방식은 XBOX services를 호출하는 게임과 앱에 대해 충분히 견고하지 않았습니다. 위의 솔루션은 사람들이 일관되고 안정적이며 예측 가능한 방식으로 호출한다고 가정합니다. XBOX services의 경우, 서비스와 요청 타이틀에 따라 호출 패턴이 극적으로 다릅니다. 이 경우 하나의 한도만 선택하려면 호출 패턴 스펙트럼의 양쪽 끝에서 타협해야 합니다. XBOX services 솔루션은 두 가지 기간과 한도를 사용합니다. 더 작은 기간은 버스트 기간이라고 하고, 더 길고 큰 기간은 지속 기간이라고 합니다. FGRL의 버스트 기간은 항상 15초이며, 지속은 항상 300초(5분)입니다. 따라서 5분의 지속 기간 동안 20개의 버스트 기간이 있습니다. 버스트 및 지속 한도는 동시에 추적되며, 따라서 요청을 동시에 카운트합니다. 버스트 및 지속 한도는 모두 서비스에 설정되므로 각 서비스에는 고유한 버스트 및 지속 카운트가 있습니다. 이 두 한도가 함께 작동하는 방식을 이해하는 데 도움이 되도록, 아래 표는 FGRL을 구현한 서비스에 대해 여러 요청을 하는 타이틀을 플레이하는 사용자를 보여줍니다. 이 경우 버스트 한도는 15초에 30개의 요청이며 지속 한도는 5분에 100개의 요청입니다.
이 표는 처음 15초 동안 사용자가 35개의 요청을 하여 버스트 한도를 초과한 것을 보여줍니다.
그 5개의 추가 요청은 삭제되고 5개의 429 응답이 전송됩니다.
이 5개의 요청은 throttling되었지만 지속 한도에는 여전히 계산됩니다.
어느 한도라도 초과되면 요청이 통과되지 않습니다. 45초 지점에서 두 한도가 모두 초과될 때, 그리고 285초 지점에서 4개의 요청만 만들어질 때 이를 볼 수 있습니다.
HTTP 429 응답 개체
관련 사용자 및 타이틀 카운트가 버스트 또는 지속 한도 이상이면 서비스는 요청을 처리하지 않고 대신 HTTP 429 응답을 반환합니다. XSAPI를 사용할 때 이는 HRESULT 0x801901AD와 동일합니다. HTTP 429 코드는 “너무 많은 요청”을 의미하며 “retry after X seconds” 값이 포함된 헤더와 함께 제공됩니다. FGRL 429 응답 개체에는 호출 엔터티가 다시 시도하기 전에 기다려야 하는 시간을 지정하는 “retry after” 헤더가 포함되어 있습니다. XSAPI를 사용하는 개발자는 XSAPI가 Retry-After 헤더를 준수하고 처리하므로 걱정할 필요가 없습니다. 실제 응답에는 다음 필드가 포함됩니다.구현된 한도
다음 서비스는 FGRL 한도를 구현했으며, 이러한 한도의 시행은 2016년 5월부터 시행되었습니다. 이러한 한도는 모든 샌드박스와 타이틀에서 동일합니다. XBOX Developer Platform 또는 Partner Center를 통해 게시되어 2016년 5월 이전에 출시된 타이틀은 레거시로 간주되어 면제됩니다.
위 표는 FGRL로 선택된 현재 서비스 목록을 나타냅니다.
이 목록은 최종적인 것이 아니며, 새로운 서비스와 기존 서비스가 추가될 수 있습니다.
서비스가 추가될 예정이면 이 표가 업데이트되고 공지가 이루어집니다.
표의 한도는 변경될 수 있습니다.
서비스가 변화하고 발전함에 따라 한도도 그렇게 될 것입니다. 그러나 알림을 받고 필요한 레거시 면제가 이루어질 것입니다.
서비스 매핑 및 속도 제한의 타이틀 영향
참고: 최신 API 매핑은 정기적으로 업데이트되며 Live Trace Analyzer API Mapping에서 찾을 수 있습니다.