서버 브라우저

Server Browser를 빠르게 시작하고 다양한 장르의 예제 시나리오를 살펴보세요.

Server Browser는 다음을 위한 관리형 서비스입니다 배포 및 지속형 서버:

• 플레이어가 적합한 서버를 검색하고 참여하도록 돕습니다 용량, 지연 시간 또는 게임 매개변수를 기준으로;

• 새 서버를 미리 워밍합니다 전 세계 사용자에게 대규모로 서비스를 제공하고 답답한 대기열을 방지하기 위해;

• 서버 운영을 간소화합니다 업데이트, 재시작, 지속성, 메시싱 등을 포함합니다.

✔️ 준비

이 서비스를 테스트하는 것은 전적으로 무료이며 신용카드가 필요하지 않습니다.

무료 요금제는 각 재시작 후 공유 테스트 클러스터에서 최대 3시간의 런타임을 허용합니다.

이 튜토리얼은 다음을 이미 완료했다고 가정합니다:

• Edgegap의 배포 모델을 이해한,

• Edgegap에 서버 애플리케이션을 배포한(게시한)Unreal Engine, Unity),

• 게임 클라이언트에서 Edgegap의 서버에 성공적으로 연결한

함수 및 흐름

Server Browser는 두 가지 주요 기능을 제공합니다:

서버 브라우저 클라이언트 및 서버 통합을 통해:

• 클라이언트는 단일 메서드로 좌석을 예약하고 연결 정보를 받습니다.

• 클라이언트는 사용자 지정 필터(게임 내 UI)를 사용해 적합한 서버와 슬롯을 탐색할 수 있습니다.

• 서버는 다음을 사용해 서버에서 플레이어 연결을 인증합니다 연합 ID.

• 서버는 슬롯 용량과 메타데이터를 업데이트하여 표시 여부를 변경하거나 확장 트리거를 실행합니다.

서버 브라우저 (선택 기능) 스케일링 정책을 통해:

• 사용 가능한 서버 인스턴스, 슬롯, 용량을 지역별 또는 사용자 지정 기준별로 모니터링합니다.

• 미리 워밍하거나 적시 확장을 통해 용량을 늘리기 위해 새 서버를 배포합니다.

• 제한된 기간의 이벤트(QA 테스트, 토너먼트)를 위해 분리된 정책으로 작업을 자동화합니다.

▶️ 탐색 시작

효율적인 서버 사용을 위해 서버와 플레이어(클라이언트) 라이프사이클을 알아보세요.

인증

모든 요청에는 Authorization 비밀값이 포함된 HTTP 헤더를 보내야 합니다 인증 토큰:

Server Browser는 자동으로 두 가지 유형의 토큰을 생성합니다:

• 서버 토큰 - 다음에 필요: 서버 API 메서드에 사용할 수 있으며, 앱 버전 변수로 주입될 수 있습니다.

  • 모든 API 메서드에 대한 접근 권한을 부여하며, 테스트, DevOps 또는 사용자 지정 확장에 유용합니다.

• 클라이언트 토큰 - 다음에 필요: 모니터 API 및 좌석 예약 API 게임 클라이언트에서 사용됩니다.

인스턴스 검색

검색은 완전히 초기화된 서버가 Server Browser에 알리고 표시되기 시작하는 과정입니다 검색 또는 자동 할당된 예약을 통해.

필수 정보 각 서버 인스턴스에는 다음이 포함됩니다:

• 인스턴스를 초기화할 때 최소 하나의 슬롯이 정의되어 있어야 합니다,

• 서버 연결 정보 - URL, IP, 포트 정보 및 위치.

선택적 사용자 지정 메타데이터 매개변수 플레이어 필터링, 정렬 및 탐색용; 예를 들면:

• 슬롯 정보 - 팀 용량 및 팀별 메타데이터(예: 팀 이름),

• 이름 및 태그 - 사용자 지정 가능하고 고유하며 사람이 읽을 수 있고 검색 가능한 레이블;

• 호환성 데이터 - 서버 버전 또는 지원되는 클라이언트 버전;

• 지연 시간 식별자 - 도시 및 지역 식별자, 그리고 할당된 핑 비콘 세부 정보;

• 게임 매개변수 - 레벨/씬/맵, 게임 모드, 난이도, 사용된 모드;

• 플레이어가 필터링하여 적합한 서버를 찾는 데 도움이 되는 기타 사용자 지정 매개변수.

서버는 인스턴스 또는 슬롯 메타데이터를 언제든지 업데이트할 수 있습니다 검색 가능성 기준을 수정할 수 있습니다. 메타데이터를 업데이트할 때는 수정되지 않은 경우에도 모든 인덱싱된 키에 유효한 값이 제공되어야 합니다.

서버 인스턴스는 주기적으로 유지 신호 하트비트를 보내야 합니다 지속적인 가용성을 확인하고 플레이어가 충돌했거나 오프라인인 서버에 참여하는 것을 방지하기 위해서입니다. 설정된 만료 기간 동안 하트비트가 없으면 인스턴스와 보류 중인 모든 좌석 예약이 자동으로 삭제됩니다.

용량 할당

인스턴스와 슬롯의 용량은 다음 두 가지 방법으로 할당할 수 있으며, 개별적으로 또는 함께 사용할 수 있습니다:

• 서버 브라우저 특정 스케일링 정책으로 시작된 서버를 선택하려면,

• 서버 브라우저 플레이어가 필터를 설정하고 적합한 서버를 탐색해 직접 선택할 수 있습니다.

자동 할당 예약

플레이어는 플레이어 ID와 스케일링 정책 이름만 제공하여 자동 할당 예약을 만들 수 있습니다. Server Browser는 충분한 참여 가능 용량을 제공하는 인스턴스 슬롯을 자동으로 찾아 좌석을 예약하고, 즉시 인스턴스 연결 정보를 응답합니다.

이 예약에 적합한 인스턴스 슬롯이 없으면, 응답은 다음과 같습니다:

• 상태 코드는 정책 확장 상태를 나타냅니다 그리고 추가 용량이 더해지고 있다면,

• 확장 중인 경우, 헤더 Retry-After 재시도하기 전 대기 시간(초)을 나타냅니다.

예약이 완료되면 다음으로 건너뛸 수 있습니다 서버 브라우저.

검색 및 탐색

플레이어는 사용자 지정 필터와 정렬로 서버 인스턴스를 나열하고, 결과를 페이지로 나눌 수 있습니다 참여하고 싶은 서버를 찾기 위해서입니다. 각 인스턴스의 슬롯도 같은 방식으로 검색할 수 있습니다.

인스턴스와 슬롯은 내장 매개변수 또는 인덱싱된 메타데이터로 필터링하고 정렬할 수 있습니다:

사용 가능한 필터 연산자는 필터링된 속성의 데이터 유형에 따라 다릅니다:

좌석 예약

서버에 참여하기 전에 플레이어는 좌석을 예약해야 합니다 인스턴스가 충분한 사용 가능 용량을 제공하는지 보장하고 과밀을 방지하기 위해서입니다. 예약에는 플레이어 그룹이나 단일 개인이 포함될 수 있습니다.

연합 ID: 플레이어는 예약 시 고유한 제3자 플레이어 ID를 제공해야 합니다. 그들이 서버 브라우저서버 측 검증을 위해 동일한 ID를 보냅니다.

예약이 성공적으로 완료되면 플레이어는 즉시 연결을 시도해야 합니다. 보류 중인 예약은 서버에서 확인되지 않으면 30초(구성 가능) 후 만료됩니다 서버에 의해.

슬롯의 참여 가능 좌석 용량을 초과하는 예약은 거부됩니다 (409 충돌). 참여 가능 좌석은 아직 다른 플레이어가 예약하지 않은 사용 가능한 좌석입니다.

서버에 연결

좌석 예약이 이루어지는 즉시, 플레이어는 배포된 게임 서버에 연결을 진행하고 netcode RPC로 플레이어 ID를 전달해야 합니다.

새 연결을 인증하려면, 서버는 대량 예약 확인 요청을 모든 새 플레이어의 ID와 함께 보내야 하며, 응답으로 다음을 받습니다:

• 승인된 플레이어 예약을 선호하는 슬롯에 할당,

• 만료된 플레이어 예약을 선호하는 슬롯에 할당,

• 알 수 없는 플레이어 ID 목록.

귀하의 서버는 만료된 플레이어 그룹을 어떻게 처리할지 결정합니다 그리고 만료되었거나 거부된 사용자를 허용할지, 내보내거나 차단할지 여부를 결정합니다. 각 인스턴스 슬롯은 새 사용 가능 좌석 수로 즉시 업데이트해야 합니다 이후 예약이 슬롯 용량을 초과하지 않도록 하기 위해.

서버 포기

플레이어가 떠나면, 귀하의 서버는 할당된 슬롯의 사용 가능 좌석 수를 늘려야 합니다.

다음을 읽어보세요 영속성 답답한 지속형 서버 롤백을 방지하기 위해.

🚀 자동 확장

Server Browser는 여러 다른 자동 확장 방식과 호환됩니다:

• 프리워밍 방식 - Server Browser 스케일링 정책에 따라 엄격하게 서버를 시작합니다,

• 적시 방식 - 다음을 통해 시작: 매치메이킹 및 Server Browser로 채우기,

• 사용자 지정 자동 확장기 - 사용자 지정 게임 백엔드를 통해 시작하고 Server Browser로 채우기.

다음 가이드는 다음에 초점을 맞춥니다 스케일링 정책을 사용한 프리워밍.

용량 모니터링

Server Browser는 검색된 인스턴스 목록을 매번 새로고칩니다 monitoring_interval .

구성한 minimum_active_instances 수량은 다음 중 하나로 간주할 수 있습니다:

• 고정 용량 항상 실행 상태로 유지하고 싶은 배포의

• 프리워밍 대기 초기화 지연을 숨기기 위한 배포 버퍼.

고정 용량

고정 용량 정책은 좌석 관련 필터를 사용해서는 안 됩니다.

이 유형의 정책 구성은 주로 품질 보증, 토너먼트, 비공개 알파, 퍼블리셔 데모 또는 기타 제한 용량 이벤트에 사용됩니다.

또는, 다음을 사용하는 게임은 영속성 일반적으로 장시간 실행되는 서버를 유지하려고 하며, 특히 플레이어에게 프로비저닝을 제공할 때 영속성.

프리워밍 대기

프리워밍 정책은 참여 가능 좌석 필터를 사용해 용량 사용량을 모니터링해야 합니다.

다음과 같은 경우 대기 중인 유휴 서버를 시작하여 플레이어 수요에 앞서 대응하세요:

• 전 세계적으로 출시하고 짧은 시간 안에 플레이어가 빠르게 유입될 것으로 예상하는 경우,

• 또는 서버 초기화에 30초 이상이 걸리는 경우(배포 시간은 제외),

• 또는 서버가 더 복잡한 네트워크 토폴로지가 필요한 메시싱 전략을 사용하는 경우.

서버 배포

검색된 인스턴스 수가개 가 정책의 최소 활성 인스턴스 수보다 낮아지면, 배포는 이후 매 모니터링 간격마다 무한히 재시도됩니다 deployment_registration_period 가 경과한 후.

사용 가능한 매개변수에는 다음이 포함됩니다(전체 API 사양을 참조하세요):

• 애플리케이션 및 버전 - 빌드 버전, 리소스 및 기타 오케스트레이션 매개변수,

• 사용자 - 선호하는 위치에 대한 단일 지리 좌표 세트 서버 배치,

• 비공개 호스트 ID - 클라우드의 경우 비워 두거나, 원하는 지역의 호스트를 지정합니다,

• 태그 - 나중에 이 정책으로 시작된 배포를 찾을 수 있도록 정책 이름으로 태그를 지정합니다,

• 환경 변수 - 서버에 사용자 지정 매개변수와 비밀을 전달합니다,

• 웹훅 - 배포 라이프사이클 이벤트를 게임 백엔드(또는 매치메이커)에 알립니다,

• - 캐시된 위치가 필요합니다 - 캐시된 위치에서만 더 빠른 배포를 선호하는 경우.

예제 정책

필요에 따라 이 정책들을 테스트하고 수정하세요. 대부분의 게임은 여러 정책을 사용하게 됩니다.

⚙️ 구성

Server Browser 시작 시 JSON 구성으로 Server Browser API가 생성됩니다. 사용자 지정 만료/등록 시간 범위와 사용자 지정 메타데이터를 지정할 수 있습니다:

☁️ 호스팅 클러스터

Server Browser는 Edgegap이 편리하게 24시간 연중무휴로 호스팅 및 관리합니다.

목표에 가장 적합한 호스팅 옵션을 선택하세요:

• 무료 클러스터(공유) 모든 기능을 테스트하고 디자인과의 시너지를 탐색하려면,

  • 3시간 후 자동으로 종료되며 테스트를 계속하려면 재시작이 필요합니다.

• 프라이빗 클러스터 (전용) 프로덕션 요구에 맞는 안정적인 환경을 보장하려면,

  • 지역을 선택하고 24시간 연중무휴 라이브 게임 지원을 받아 안심하고 출시하세요.

프라이빗 클러스터 티어

현재 다음을 제공합니다 3개의 프라이빗 클러스터 요금제 모두의 필요에 맞추기 위해:

🌟 한 번의 클릭으로 무료 인스턴스를 프라이빗 클러스터로 업그레이드하고, 공개 출시된 게임을 위해 Edgegap 팀이 유지 관리하는 고가용성 호스팅과 24시간 라이브 지원을 받으세요.

인스턴스의 리소스 요구 사항은 다음 요인에 따라 달라집니다:

• 플레이어 수, 플레이어가 많을수록 ⇒ API 요청이 늘고 CPU 사용량이 증가합니다,

• 플레이어당 요청 수, 재시도 빈도가 높을수록 ⇒ CPU 자원 사용량이 증가합니다,

• 서버 수, 서버가 많을수록 ⇒ CPU 사용량과 메모리 사용량이 증가합니다,

• 클라이언트 재시도 폴백 로직 - 지터된 백오프 없이 재시도하면 ⇒ 썬더링 허드,

• 평균 매치 지속 시간 - 세션이 짧을수록 ⇒ 라이프사이클 이벤트 발생 빈도가 높아집니다.

📗 API

다음 용도로는 저희 SDK를 고려해 보세요 Unreal Engine 또는 Unity 미리 만들어진 예제로 시작하세요.

API 사양을 가져와 Scalar API 웹 클라이언트 또는 Swagger Editor 세부 정보를 확인하세요.

속도 제한

인스턴스가 버스트 용량을 초과하여 중단되는 것을 방지하기 위해, 각 클라이언트의 공용 IP 주소별로 초당 클라이언트 요청 수를 제한합니다.

이 제한은 다음으로 구성됩니다 서버 브라우저 매개변수 rate_limits.per_client_ip.

부하 테스트

실서비스와 유사한 환경에서의 부하 테스트에는 배포 호스팅 비용이 발생합니다. 각 등급과 관련된 리소스 및 가격은 요금제 페이지에서.

부하 테스트를 설계할 때, 현실적인 플레이어 패턴을 고려해 주세요:

부하 시 동작

클라이언트 요청 - 어떤 클라이언트가 구성된 IP당 req/s 속도 제한에 도달하면, 해당 클라이언트는 429 요청 과다 재시도 전에 물러나야(대기해야) 합니다.

배포 요청 - 스케일링 정책이 조직의 허용 req/s 제한보다 더 많은 배포를 트리거하면, 서버 브라우저는 모든 인스턴스 정책 간에 가중 라운드 로빈 전략을 사용하여 모니터링 간격마다 자동으로 재시도합니다.

정책 가중치는 각 라운드의 계획된 배포 수를 바탕으로 산출되며, 사용 가능한 배포 할당량을 모든 스케일링 정책에 고르게 분배합니다.

페이지 매김

Server Browser는 커서 기반 페이지 매김을 제공하여 필터링된 결과를 특정 순서대로 점진적으로 가져옵니다. 이 방식은 기존의 limit-offset 페이지 매김과 달리, 더 많은 결과를 가져올 때마다 커서(시작점)와 페이지 크기(응답 항목 수)를 전송해야 합니다.

가장 중요한 우선순위는 사용자가 첫 페이지에서 적합한 서버를 찾는 것입니다.

최상의 경험을 위해 이전 페이지의 캐시된 결과를 보여주고, 사용자가 검색을 클릭하거나 수동으로 새로 고침을 요청할 때만 결과를 갱신하는 것을 권장합니다.

🔖 변경 로그

시맨틱 버전 관리

당사의 개발자 도구와 관리형 서비스는 공식 시맨틱 버전 관리을 사용하며, 이는 어떤 업데이트가 ✅ 안전한지(마이너, 패치)와 어떤 업데이트에 ⚠️ 호환성을 깨는 변경이 포함될 수 있는지(메이저)를 나타냅니다.

버전이 출시되면, 절대 수정/변경되지 않습니다.