FGRL(Fine Grained Rate Limiting)
이 문서에서는 Xbox 서비스 FGRL(Fine-grained Rate Limiting)에 대한 개요를 제공합니다. 이 문서는 속도 제한이 무엇인지 요약되어 있을 뿐 아니라 사용자가 자신이 제한을 받고 있는지, 제한을 받고 있다면 어떤 도구와 리소스를 원하는 대로 사용할 수 있는지 확인하는 데 도움을 드리기 위한 것입니다.
Fine-Grained Rate Limiting은 여러 타이틀 간에 공유 Xbox 리소스의 공정한 사용을 촉진하기 위해 의뢰되었습니다. 이 솔루션은 대부분의 기존 제한 시스템과 같이 엔터티가 일정 기간 동안 실행한 요청의 수를 유지하는 서비스가 있습니다.
서비스별 제한에 도달하는 엔터티는 엔터티의 모든 수신 요청을 돌려보내는 거부 상태로 바뀝니다. 엔터티는 지정된 기간이 만료되어 엔터티에 연결된 개수가 다시 설정될 때만 이 상태에서 벗어날 수 있습니다.
FGRL(Fine Grained Rate Limiting)에서는 위에서 언급한 것과 동일한 핵심 역학을 사용하지만 엔터티 하나를 추적하는 대신 사용자와 타이틀의 조합을 추적하고 하나를 추적할 때와 대조적으로 관련된 개수를 두 가지 다른 제한과 비교합니다. FGRL 이중 제한은 각 서비스에 적용되는데, 이는 GameClips에 대한 요청 수가 프레즌스에 대한 요청 수에 영향을 주지 않음을 뜻합니다.
다음 섹션에서는 사용자와 타이틀 페어링, 이중 제한, HTTP 429 제한 응답 개체에 대해 더 자세히 살펴보겠습니다.
FGRL(Fine Grained Rate Limiting) 관련 용어
| 용어 | 정의 |
|---|---|
| FGRL | FGRL(Fine Grained Rate Limiting) |
| XSAPI | Xbox 서비스 애플리케이션 인터페이스 |
| CU | 콘텐츠 업데이트 |
| 버스트 | 짧은 기간 동안 수신한 요청의 볼륨을 나타냅니다. |
| 지속 | 일정 기간 동안 지속적으로 수신한 상당히 많은 볼륨의 호출을 나타냅니다. |
| 사용자 + 타이틀 | 사용자와 타이틀을 하나의 엔터티로 페어링한 것을 나타냅니다. |
| XSTA | Xbox 서비스 추적 분석기 도구, 타이틀 속도 제한 여부를 확인하는 데 사용 |
공정한 사용
Xbox는 사용자가 어떤 게임(또는 앱)을 플레이하든 상관없이 각 사용자가 동일한 고품질 경험을 가져야 한다고 믿습니다. FGRL(Fine Grained Rate Limiting)은 다음과 같은 경우 해결책이 됩니다.
개발자 A는 모든 Xbox 서비스 모범 사례를 준수하여 서비스 사용을 최적화하는 타이틀을 릴리스하였고, 이와 동시에 개발자 B 역시 타이틀을 릴리스했으나 이 타이틀에는 알 수 없는 버그가 있습니다. 이 버그로 인해 타이틀과 각 사용자는 프레즌스를 대량으로 요청하게 되고 이 때문에 서비스에 큰 부하가 걸리게 됩니다. 이 버그가 문제를 일으킨 개발자 B의 것이었음에도 불구하고 개발자 A의 서비스가 느려지고 사용자 환경이 점차 저하됩니다.
FGRL이 구현된 경우 서비스는 잘못 작동하는 타이틀에서 요청받기를 중단할 수 있으며 리소스 파이에서 개발자 A의 타이틀이 공평한 조각을 가져갈 수 있게 합니다.
타이틀 및 사용자 세분화
타이틀과 사용자가 Xbox 리소스를 공평하게 사용할 수 있도록 키로 선택되었습니다.
사용자를 추적하는 것만으로도 사용자의 환경이 각 타이틀의 통합에 따라 좌우되는 시나리오가 생성됩니다. 예를 들어 대부분의 타이틀에서는 이미 피플 서비스를 사용하고 있으므로 이 예에서는 피플 서비스에 FGRL(Fine-Grained Rate Limiting)이 설정되어 5분간 최대 100개의 요청을 허용한다고 가정하겠습니다.
사용자가 1분간 100개의 요청을 실행한 게임을 한다고 가정하면 제한을 초과하게 되고 사용자는 피플 서비스에 더 많은 요청을 하지 못하게 될 것입니다. 이어서 같은 시간 동안 사용자가 홈 화면으로 돌아가 자신의 친구 목록을 클릭한다고 상상해 보면 홈 화면이 사용자를 제한된 상태에 두어야 할 책임이 없었다 할지라도 사용자가 이미 제한을 초과했기 때문에 해당 친구의 목록 호출은 5분 간격이 경과할 때까지는 실패할 것입니다.
또는 타이틀에만 기반을 둔 제한으로 인해 똑같이 불공정한 결과를 얻게 될 것입니다. 타이틀마다 제한을 설정하면 타이틀의 인기가 무시되고, 요청은 제한에 도달할 때까지는 선착순으로 처리됩니다.
사용자와 타이틀을 페어링하면 활성 사용자 수 감안 시 적절한 수준 이상의 리소스를 타이틀이 사용하지 못하게 함과 동시에 각 사용자에게 일관된 리소스 분량을 제공하도록 보장합니다.
위 다이어그램에서는 요청이 처리되는 방식을 높은 수준에서 보여줍니다. 먼저 원하는 서비스에서 요청을 생성하고 나서 수신합니다. 요청을 받으면 시스템은 사용자와 타이틀이 서비스에 함께 액세스한 횟수를 확인합니다.
- 요청이 제한보다 적은 경우 평소 대로 처리됩니다.
- 요청이 제한에 도달하거나 초과한 것이 감지되면 서비스는 요청을 드롭하고 429 응답을 반환합니다.
이 응답에서는 기간이 롤오버되고 사용자와 타이틀 요청이 처리되기까지 시간이 얼마나 남았는지 표시합니다.
버스트 및 지속 제한
일반적으로 속도 제한은 일정 기간 동안 추적되는 엔드포인트당 한 개의 제한으로 구성됩니다. 이 기간은 엔터티 요청 수를 추적하는 시간을 나타냅니다. 기간 종료 시점에 엔터티 수가 0으로 재설정되면서 추적이 다시 시작됩니다.
이 방식은 대부분의 API에 유효하지만 Xbox 서비스를 호출하는 게임 및 앱에 대해서는 복원성이 떨어졌습니다. 위 해결 방법에서는 사람들이 일관성 있고 꾸준하며 예측 가능한 방식으로 호출하고 있다고 가정합니다. Xbox 서비스의 경우 서비스 및 요청 타이틀에 따라 호출 패턴이 크게 다릅니다.
이 경우 제한을 하나만 선택하면 호출 패턴 스펙트럼 양쪽 끝의 성능 저하가 수반됩니다. Xbox 서비스 솔루션은 두 가지 기간과 제한을 사용합니다. 더 짧은 기간을 버스트 기간이라고 하며 더 긴 기간은 지속 기간이라고 합니다.
FGRL에 대한 버스트 기간은 항상 15초인 반면, 지속 기간은 항상 300초(5분)입니다. 따라서 5분의 유지 기간 동안 20회의 버스트 기간이 있습니다.
버스트 및 지속 제한은 동시에 추적하며, 이에 따라 요청을 동시에 계수합니다. 버스트 및 지속 제한 모두 서비스에 설정되는데, 이는 각 서비스에 자체 버스트 및 지속 횟수가 있음을 뜻합니다.
이 두 가지 제한이 함께 작동하는 방식을 이해하는 데 도움이 되도록 아래 표에서는 FGRL을 구현한 서비스를 다수 요청 중인 타이틀을 플레이하는 사용자를 보여줍니다. 이 경우 버스트 제한은 15초간 30개의 요청이며, 지속 제한은 5분간 100개의 요청입니다.
| 기간(두 번째) | 버스트 기간당 요청 수 | 지속 기간당 요청 수 | 15초 간격 이내에 스로틀된 요청의 # | 어떤 제한인가요? (버스트, 지속 또는 둘 다) |
|---|---|---|---|---|
| 0-15 | 35 | 35 | 5 | 버스트 |
| 15-30 | 28 | 63 | 0 | 해당 없음 |
| 30-45 | 21 | 84 | 0 | 해당 없음 |
| 45-60 | 36 | 120 | 20 | 둘 다 |
| 60-75 | 24 | 144 | 24 | 지속 |
| … | … | … | … | |
| 285-300 | 4 | 148 | 지속 |
이 표를 보면 최초 15초 이내에 사용자가 35건의 요청을 실행하여 버스트 제한을 트립하고 있음을 알 수 있습니다. 이 5건의 추가 요청은 삭제되고 5건의 429 응답이 전송됩니다.
이 5건의 요청은 스로틀되었다 하더라도 계속 지속 제한으로 집계됩니다. 두 제한 중 어느 한쪽이 트립되면 어떤 요청도 통과가 허용되지 않습니다. 이는 두 제한이 45초 표시에서 트립하고 다시 285초 표시에서 4건의 요청만이 실행될 때 알 수 있습니다.
HTTP 429 응답 개체
연결된 사용자 및 타이틀 수가 버스트 또는 지속 제한과 같거나 그보다 더 높은 수준이면 서비스는 요청을 처리하지 않고 그 대신에 HTTP 429 응답을 반환합니다. XSAPI를 사용하는 경우 이는 0x801901AD HRESULT와 동일합니다. HTTP 429 코드는 "요청이 너무 많음"을 뜻하며 "X초 이후 재시도" 값을 포함하는 헤더와 함께 제공됩니다.
FGRL 429 응답 개체에는 호출 엔터티가 재시도하기 전에 기다려야 하는 시간을 지정하는 "다음 시간 후 다시 시도" 헤더가 포함되어 있습니다. XSAPI를 사용하는 개발자는 XSAPI가 다음 시간 후 다시 시도 헤더를 존중하고 처리하므로 걱정하지 않아도 됩니다.
실제 응답에는 다음 필드가 포함되어 있습니다.
| 필드 이름 | 값 유형 | 예 | 정의 |
|---|---|---|---|
| 버전 | 정수 | "version":1 |
|
| currentRequests | 정수 | "currentRequests":13 |
전송된 총 요청 수 |
| maxRequests | 정수 | "maxRequests":10 |
허용된 총 요청 수 |
| periodInSeconds | 정수 | "periodInSeconds":15 |
기간 |
| 유형 | 문자열 | "type":"burst" |
제한 한도 유형 |
구현된 한도
다음 서비스에서는 2016년 5월 이후 이러한 제한이 적용됨에 따라 FGRL 제한을 구현해왔습니다. 이 제한은 모든 샌드박스 및 타이틀에 동일하게 적용됩니다.
Xbox 개발자 플랫폼 또는 파트너 센터를 통해 퍼블리싱되고 2016년 5월 이전에 배송된 모든 타이틀은 레거시로 간주되므로 제외됩니다.
| 이름 | 버스트 제한(타이틀별 사용자 1인당 15초) | 지속 제한(타이틀별 사용자 1인당 300초) | 인증 제한(타이틀별 사용자 1인당 10배 지속, 300초) |
|---|---|---|---|
| 통계 읽기 | 100 | 300 | 3000 |
| 프로필 | 10 | 30 | 300 |
| MPSD | 30 | 300 | 3000 |
| 검색 핸들(MPSD) | 읽기 1, 쓰기 1 | 읽기 20, 쓰기 20 | 읽기 20, 쓰기 20 |
| MPA 최근 플레이어 | 3 | 50 | 50 |
| MPA 초대 | 7 | 50 | 50 |
| MPA 활동 | 만들기/삭제 10, 읽기/쿼리 20 | 만들기/삭제 100, 읽기/쿼리 200 | 만들기/삭제 100, 읽기/쿼리 200 |
| 현재 상태 | 읽기 10, 쓰기 3 | 읽기 100, 쓰기 30 | 읽기 1000, 쓰기 300 |
| 소셜 | 10 | 30 | 300 |
| 순위표 | 30 | 100 | 1000 |
| 도전 과제 | 100 | 300 | 3000 |
| Smart Match | 10 | 100 | 1000 |
| 사용자 게시물 | 100 | 300 | 3000 |
| 통계 쓰기 | 100 | 300 | 3000 |
| 개인 정보 보호 | 10 | 30 | 300 |
| 클럽 | 10 | 30 | 300 |
| 인증(S2S만 해당) | 15 | 50 | 500 |
위 표는 FGRL에 대해 선택된 현재 서비스 목록입니다. 새 서비스와 기존 서비스를 추가할 수 있으므로 최종 목록은 아닙니다. 서비스를 추가될 예정인 경우 이 표가 업데이트되고 알림이 실행됩니다.
표의 제한은 변경될 수 있습니다. 제한은 서비스의 변화 및 발전에 따라 함께 변화, 발전합니다. 그러나 이와 관련해 알림을 받고 필수 레거시 제외가 실행됩니다.
서비스 매핑과 속도 제한의 타이틀 효과
| 이름 | 서비스 끝점 | FGRL의 예상 게임 영향 |
|---|---|---|
| 통계 읽기 | userstats.xboxlive.com | 도전 과제 또는 순위표 항목이 업데이트되거나 검색되지 않습니다. |
| 프로필 | profile.xboxlive.com | 플레이어 데이터가 정확하게 업데이트되거나 표시되지 않습니다. |
| MPSD | sessiondirectory.xboxlive.com | 참가/초대가 제대로 완료되지 않을 수 있으며, 세션을 제대로 생성하거나 업데이트하지 않아 타이틀 오류가 발생할 수 있습니다. |
| MPA | multiplayeractivity.xboxlive.com | 참가/초대가 올바르게 완료되지 않으며, 최근 플레이어 정보가 제대로 작동하지 않습니다. |
| 현재 상태 | presence.xboxlive.com | 게임 내 플레이어의 상태가 정확하지 않습니다. |
| 소셜 | social.xboxlive.com | 모든 친구 쓰기(예: 친구 추가, 누군가를 즐겨찾기에 추가 등)에 영향을 주고 친구 읽기(예: 내 친구 목록 가져오기)에도 영향을 줄 수 있습니다. 개발자는 social.xboxlive.com보다는 읽기에 대한 peoplehub를 호출하는 것이 좋습니다. |
| 순위표 | leaderboards.xboxlive.com | 순위표에 대한 게임 내 UX는 입력/업데이트되지 않습니다. |
| 도전 과제 | achievements.xboxlive.com | 잠금 해제된 도전 과제에 대한 게임 내 UX는 업데이트되지 않습니다. |
| Smart Match | momatch.xboxlive.com | 일치 항목이 제대로 설정되지 않을 수 있습니다. |
| 사용자 게시물 | userposts.xboxlive.com | 사용자 게시물은 표시되지 않습니다. |
| 통계 쓰기 | statswrite.xboxlive.com | 도전 과제 또는 순위표 항목이 업데이트되지 않습니다. |
| 개인 정보 보호 | privacy.xboxlive.com | 개인 정보 보호 관련 장애로 인해 모든 호출자에 대한 액세스가 차단될 수 있습니다. |
| 클럽 | Clubhub.xboxlive.com | 플레이어에게 인게임 클럽이 표시되지 않을 수도 있습니다. |
| 인증(S2S만 해당) | title.mgt.xboxlive.com | 서비스 간 호출 인증이 실패합니다. |
참고: 최신 API 매핑은 정기적으로 업데이트되며, Live Trace Analyzer API 매핑에서 확인할 수 있습니다.
FAQ
스로틀 발생 여부와 취해야 하는 조치를 어떻게 확인할 수 있나요?
Xbox 서비스 호출 모범 사례를 참조하세요. 이 문서에는 XSAPI 어설션과 XSAPI 소셜 및 Multiplayer Manager를 사용해 제한 문제에 관해 알림을 받고 이러한 제한 문제를 완화할 수 있는 방법에 대한 설명뿐 아니라 호출 패턴을 개선할 수 있는 조치가 포함되어 있습니다.
또 다른 옵션은 Xbox 서비스 호출의 추적을 기록한 다음 Xbox 서비스 추적 분석 도구를 사용하여 해당 추적을 분석하는 것입니다. 추적을 기록하려면 Fiddler를 사용해 .SAZ 파일을 기록하거나 XSAPI의 기본 제공 추적 로깅을 사용할 수 있습니다.
XSAPI에서 추적을 켜거나 사용하려면 서비스 호출 검토용 Trace Analyzer를 참조하세요. 추적이 있으면 Xbox 서비스 추적 분석기 도구가 제한된 호출을 감지하면 경고를 표시합니다.
제한을 변경할 수 있나요?
원래 의도는 시간이 지나도 퍼블리싱된 제한이 변경되지 않는 것입니다. 그러나 부득이 변경해야 하는 경우에는 일부 제한을 더 엄격하게 변경하는 것이 가능합니다. 이 경우 이미 RETAIL에 릴리스된 타이틀은 업데이트된 제한이 면제됩니다.
더 많은 서비스에 대해 제한을 적용할 계획인가요?
예, 더 많은 서비스와 신규 서비스에서 제한을 생성할 수 있고 또 생성할 것입니다. 그러나 이 첫 번째 FGRL 릴리스와 마찬가지로 이에 대해 알림을 받고 적절한 조치가 취해질 것입니다.
이러한 변경 사항은 언제 적용되나요?
2016년 5월 이후 속도 제한이 적용되어 왔습니다. 2018년 4월부터 지정된 지속 제한을 10배 이상 초과하는 타이틀은 Xbox 인증 프로세스를 통과하지 못합니다.
제한을 따를 수 없는 경우 어떻게 하나요?
Xbox 서비스 호출 모범 사례를 참조하고 다음 단계를 따르고 있는지 확인하세요. 또한 소셜 서비스의 속도 제한을 받고 있다면 소셜 관리자 사용을 고려해 보세요.
이 단계를 수행했는데도 여전히 제한을 초과한다면, 개발자 계정 관리자에게 문의하세요.
참고: 지정된 제한 또는 그 이상의 타이틀은 2018년 4월 이후 인증을 통과할 수 없습니다. 예를 들어 위 표에 지정된 것처럼 지속 제한이 300초 이내 300건 호출로 설정되어 있으면 300초 이내 호출이 3000건 이상인 타이틀은 인증에 실패하게 됩니다. 테스트 사례를 비롯한 자세한 내용은 XR-132 서비스 액세스 제한을 참조하세요.
내 기존 타이틀은 어떻게 되나요?
2018년 4월 이전의 RETAIL 내 모든 타이틀은 레거시로 간주되어 제외됩니다.
콘텐츠 업데이트는 어떻게 되나요?
레거시 또는 제외된 타이틀의 경우 콘텐츠 업데이트 역시 제외되지만 도구와 자산을 활용하여 게임의 서비스 통합 측면을 최적화하는 것이 좋습니다.
콘텐츠를 업데이트할 때까지 내 게임에 대해 면제를 받을 수 있나요?
개발자 계정 관리자에게 문의하세요.