For the complete documentation index, see llms.txt. This page is also available as Markdown.

서버 브라우저

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

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

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

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

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

✔️ 준비

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

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

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

기능 및 흐름

Server Browser: 흐름과 계층 구조

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

서버 브라우저 게임 클라이언트와 함께 다음을 수행합니다:

  • 적합한 서버 인스턴스를 검색하고 찾고, 슬롯을 확인하고, 사용 가능한 용량을 예약합니다.

  • 인스턴스 슬롯에 자리를 예약하고, 연결 세부 정보를 가져와 서버에 연결합니다.

  • 다음을 사용하여 배포에서 플레이어 연결을 인증합니다 연합 ID.

  • 인스턴스 슬롯의 사용 가능 용량 및/또는 메타데이터를 업데이트하여 검색 기준을 수정합니다.

서버 브라우저 (선택 사항) 다음을 사용하여 스케일링 정책과 함께:

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

  • 사전 워밍이나 just-in-time 스케일링으로 용량을 늘리기 위해 서버를 배포합니다.

  • 데모, 업데이트, 테스트, QA, 토너먼트 등 특수 정책으로 운영을 자동화합니다.

출시 후, 서버 브라우저는 24시간 365일 실행되어야 합니다 전 세계 플레이어가 서버에 참여할 수 있도록 보장하기 위해.

▶️ 브라우징 시작

효율적인 서버 사용을 보장하기 위해 서버/플레이어 수명 주기와 각자의 책임에 대해 알아보세요.

인증

모든 요청은 다음을 전송해야 합니다 Authorization HTTP 헤더에 비밀 인증 토큰:

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

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

    • 모든 API 메서드에 대한 액세스 권한을 부여하며, 테스트, DevOps 또는 사용자 지정 오케스트레이션에 유용합니다.

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

    • 토큰 회전을 더 쉽게 하기 위해 이 토큰을 서드파티 비밀 저장소에 보관하는 것을 권장합니다.

인스턴스 찾기

참조하세요 서버 브라우저 스케일링 정책에 대해 알아보고 배포를 자동으로 시작합니다.

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

  • 인스턴스를 초기화할 때 정의된 슬롯이 최소 하나,

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

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

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

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

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

  • 지연 시간 식별자 - 도시 및 지역 식별자와 할당된 핑 비컨 세부 정보;

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

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

위의 메타데이터 매개변수는 예시일 뿐이며, 필요에 따라 원하는 수의 매개변수를 정의할 수 있습니다.

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

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

참조하세요 지속성 지속적인 월드 상태를 관리하고 앱 및 버전 더 빠른 배포를 위해.

용량 할당

인스턴스 및 슬롯 용량은 두 가지 방식으로 할당할 수 있으며, 개별적으로 사용하거나 결합할 수 있습니다:

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

  • 서버 브라우저 플레이어가 필터를 정의하고 적합한 서버를 둘러보며 선택할 수 있도록 하기 위해.

자동 할당 예약

다음과 같은 기능을 구현하려면 이 기능을 사용하세요 서버를 자동으로 선택, 지역 용량을 기준으로.

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

이 예약에 적합한 인스턴스 슬롯이 없으면, 응답은:

  • 상태 코드는 정책이 확장 중인지 여부를 나타냅니다 그리고 더 많은 용량이 추가될 것입니다,

  • 헤더 Retry-After 재시도 전 대기 시간(초)을 나타냅니다, 재시도 가능하다면.

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

검색 및 둘러보기

다음과 같은 기능을 구현하려면 이 기능을 사용하세요 사용자에게 서버 목록을 보여주고 사용자 지정 예약을 허용합니다.

플레이어는 서버 인스턴스를 나열하고 결과를 페이지 단위로 탐색하여 참여하고 싶은 서버를 찾을 수 있습니다.

인스턴스와 슬롯은 기본 제공 매개변수 또는 인덱싱된 메타데이터:

속성
데이터 유형
인스턴스
슬롯

request_id

문자열

total_joinable_seats, total_available_seats

정수

이름

문자열

사용 가능한 좌석 수, 예약된 좌석 수

정수

생성 시각, 업데이트 시각

문자열

metadata.{index} (사용자 정의)

문자열, 정수, 실수, 불리언

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

매개변수
연산자
예시 필터(간단한 예시 기준)

문자열

eq 또는 ne 또는

lt 또는 le 또는

gt 또는 ge 또는 포함

정수, 실수

eq 또는 ne 또는

lt 또는 le 또는

gt 또는 ge

불리언

eq 또는 ne

커서 기반 서버 브라우저 를 학습하여 사용자가 더 많은 결과를 가져오게 하세요.

좌석 예약

서버에 참여하기 전에 인스턴스가 충분한 사용 가능 용량을 제공하는지 확인하기 위해 좌석 예약이 필요합니다. 예약에는 플레이어 그룹 또는 단일 개인이 포함될 수 있습니다.

연합 ID: 플레이어는 예약 시 고유한 서드파티 플레이어 ID를 제공해야 합니다. 일단 보내면 동일한 ID를 보내는 것은 서버 브라우저 서버가 신원을 확인할 수 있게 합니다.

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

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

서버는 모든 슬롯의 용량을 강제로 변경하고, 어떤 슬롯이든 추가, 삭제 또는 업데이트할 수 있습니다. 보류 중인 예약이 새 사용 가능한 슬롯 용량을 초과하면 해당 슬롯의 모든 예약이 제거됩니다.

서버에 연결

플레이어가 적합한 인스턴스를 찾으면, 필요한 연결 세부 정보를 가져옵니다 (URL 또는 IP, 외부 포트). 좌석 예약이 완료되는 즉시, 플레이어는 배포의 게임 서버에 연결을 진행하고 자신의 플레이어 ID를 전달할 수 있습니다.

다음으로 PIE(에디터)에서 연결하려면 개발 및 테스트 중에 틸드 키를 누르고 ~ 다음을 입력하세요 open {URL}:{port} 그리고 에디터가 맵을 로드할 때까지 기다리세요.

다음으로 Unity Editor를 연결하려면 또는 게임 클라이언트 를 클라우드 배포에 연결하려면 다음을 입력하세요:

  • 배포 URL 서버의 IP를 가리키며, 보통 NetworkManager 컴포넌트에 있습니다.

  • 외부 포트 다음에 매핑되는 서버의 내부 수신 포트, 보통 Transport 컴포넌트에 있습니다.

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

  • 수락된 플레이어 예약을 해당 선호 슬롯에 할당,

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

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

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

서버 포기

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

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

🚀 자동 확장

Server Browser는 여러 가지 다른 자동 스케일링 방법과 호환됩니다:

다음 가이드는 다음에 초점을 맞춥니다 스케일링 정책을 사용한 사전 워밍 을 주요 방법으로.

용량 모니터링

스케일링 정책은 서버 인스턴스(검색된 배포)의 목록을 지속적으로 새로고침하며, 매 monitoring_interval . 각 정책은 동일한 필터링 구문 을 사용한 필터가 필요합니다. 플레이어가 인스턴스를 검색할 때와 마찬가지로 지역, 용량 또는 기타 기준별로 적용됩니다.

구성된 minimum_active_instances 수량은 다음 중 하나로 취급할 수 있습니다:

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

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

고정 용량

다음을 가진 게임을 위해 고정된 수의 활성 서버를 유지합니다 지속성, 특히 이러한 게임이 플레이어에게 프로비저닝을 제공할 때 지속성.

이 유형의 정책 구성은 QA, 토너먼트, 비공개 알파, 퍼블리셔 데모 또는 기타 제한된 용량의 이벤트와 운영에도 때때로 사용됩니다.

스케일링 정책은 충돌한 서버를 즉시 자동으로 재시작하고 재활용하는 데 도움이 됩니다.

사전 워밍 대기

다음과 같은 경우 수요가 오기 전에 서버를 시작하세요:

  • 대형 출시를 앞두고 있으며 짧은 시간에 플레이어가 급격히 유입될 것으로 예상되는 경우,

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

  • 또는 게임이 계층적이거나 순환적인 네트워크 종속성을 요구하는 메싱 전략을 구현하는 경우.

서버 배포

모니터링된 서버 인스턴스 수가s 가 구성된 활성 인스턴스 최소값 아래로 떨어지면 새 배포가 자동으로 시작됩니다. 모든 배포는 즉시 요청되며 이후 매 모니터링 간격마다 무한히 재시도됩니다 deployment_registration_period 가 경과한 후.

정책은 배포를 다음으로 시작합니다 비공개 플릿 (Overflow to Cloud 사용) 또는 직접 Cloud로.

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

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

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

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

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

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

  • 웹훅 - 게임 백엔드(또는 매치메이커)에 배포 수명 주기 이벤트를 알림,

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

예시 정책

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

항상 테스트용 서버 하나를 배포해 두는 간단한 정책입니다.

수요를 예상하여 출시 전에 10배 배포를 시작합니다. 각 리전에 대해 복사하세요.

각 리전은 사용 가능한 용량이 임계값 아래로 떨어질 때 배포를 추가합니다.

서버 소유자당 하나의 정책으로, 서버 인증에 사용되는 사용자 지정 비밀번호를 전달합니다.

서버 그룹당 하나의 정책입니다. 게임 백엔드는 주 노드를 시작하고, 주 노드는 복제본을 생성합니다. 각 노드는 주입된 메시 그룹 ID를 읽고 네트워크를 형성할 다른 노드를 검색합니다.

⚙️ 구성

Server Browser API는 새 Server Browser를 만들거나 빠르게 재시작할 때 지정한 JSON 구성에서 생성됩니다. 서버 및 슬롯 만료, 그리고 사용자 지정 메타데이터를 지정할 수 있습니다:

최상의 성능을 위해, 필터링이나 정렬에 사용되지 않는 메타데이터에 대해서는 인덱스를 지정하지 않는 것이 좋습니다. 인덱스가 없는 매개변수도 서버 인스턴스 또는 슬롯 세부 정보 API 메서드로 계속 설정하고 읽을 수 있습니다. 참조하세요 📗 API.

☁️ 호스팅 클러스터

Server Browser는 Edgegap에서 연중무휴 24시간 편리하게 호스팅 및 관리됩니다.

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

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

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

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

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

프라이빗 클러스터 티어

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

요금제
취미용 요금제
스튜디오 요금제
엔터프라이즈 요금제

가장 적합한 대상

애호가, 개인 개발자

상업용 출시

대규모 트래픽 출시

리소스

1 vCPU + 2GB RAM

6 vCPU + 12GB RAM

18 vCPU + 48GB RAM

이중화

가상 노드 1개

가상 노드 3개

가상 노드 3개

요청 제한(req/s)

200

750

2,000

가격, 시간당

$0.0312

$0.146

$0.548

가격, 30일 (중단 없는 사용)

$22.464

$105.12

$394.56

공개 출시 게임을 위해 Edgegap 팀이 유지 관리하는 고가용성 호스팅과 연중무휴 실시간 지원의 혜택을 받으려면 한 번의 클릭으로 프라이빗 클러스터로 업그레이드하세요.

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

  • 플레이어 수 - 플레이어가 많을수록 API 요청이 더 많아집니다,

  • 플레이어당 요청 수 - 재시도가 빠를수록 서비스 부하가 증가하고 리소스를 소모합니다,

  • 서버 수 - 서버가 많을수록 저장되는 데이터와 API 요청이 더 많아집니다,

  • 클라이언트 재시도 폴백 로직 - 지터가 적용된 백오프로 재시도하면 트래픽 급증 피크를 분산하는 데 도움이 됩니다,

  • 평균 매치 시간 - 세션이 짧을수록 서버 브라우저와 더 자주 상호작용해야 합니다.

저희 클러스터는 2.4 - 3.2 GHz의 클럭 속도를 가진 AMD/Intel CPU를 탑재한 클라우드 머신을 사용합니다.

📗 API

시작하려면 다음에 대해 SDK 사용을 고려하세요 언리얼 엔진 또는 유니티 기성 예제로 빠르게 시작할 수 있습니다.

게임 클라이언트와 전용 서버는 수명 주기 전반에 걸쳐 Server Browser로 API 요청을 보냅니다.

Unity/Android - 고려하세요 원시 문자열 보간 사용 하드코딩된 JSON의 코드 제거를 방지하기 위해.

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

속도 제한

클러스터가 버스트 용량을 초과해 충돌하는 것을 방지하기 위해, 클라이언트의 공용 IP 주소당 초당 클라이언트 요청 수를 제한합니다.

제한은 다음에 의해 구성됩니다 서버 브라우저 매개변수 rate_limits.per_client_ip.

부하 테스트

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

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

현실적인 시나리오
비현실적인 트래픽 패턴

✅ 플레이어들이 몇 시간에 걸쳐 점진적으로 게임에 참여하여 req/s가 증가합니다.

❌ 모든 플레이어가 협력하여 정확히 같은 초에 API를 호출합니다.

✅ 플레이어들은 재시도 사이에 점점 더 긴 시간을 기다립니다(예: 1초-5초-10초-10초).

❌ 모든 플레이어가 429 요청이 너무 많음 응답을 받자마자 즉시 재시도합니다.

✅ 대부분의 플레이어는 짧은 시간(10~60초) 안에 배정을 받고 폴링을 중단합니다.

❌ 모든 플레이어가 배정을 받은 후에도 정해진 시간 동안 계속 폴링합니다.

✅ 대부분의 플레이어는 새 세션을 시작하기 전에(시간이 걸리며) 게임을 마칩니다.

❌ 모든 플레이어가 서버 배정을 받은 직후 즉시 새로 세션을 재시작합니다.

✅ 피크 트래픽은 하루 약 6시간 동안 유지되며, 이후 일부 시간대에서 트래픽이 줄어듭니다.

❌ 피크 트래픽이 하루 24시간 내내 유지되며, 모든 플레이어가 밤낮없이 플레이합니다.

부하 하 동작

클라이언트가 구성된 IP당 속도 제한에 도달하면 429 너무 많은 요청 응답을 받으며, 증가하는 백오프 기간과 함께 재시도해야 합니다.

스케일링 정책이 조직의 허용 req/s 한도보다 더 많은 배포를 유발하는 경우, 서버 브라우저는 계획된 배포 수를 기준으로 가중 라운드 로빈 전략을 사용하여 각 모니터링 간격마다 자동으로 재시도하며, 사용 가능한 배포 할당량을 모든 스케일링 정책에 균등하게 분배하려고 시도합니다.

페이지 매김

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

게임 서버 메타데이터를 위해 개발된 자체 데이터베이스 인덱싱 시스템과 결합하면, 커서 페이지 매김은 매우 동적인 데이터를 필터링할 때 빠르고 일관되며 유연한 사용자 경험을 제공합니다.

우리의 목표는 사용자가 첫 페이지에서 적합한 서버를 찾는 것입니다. 최상의 경험을 위해 이전 페이지의 캐시된 결과를 표시하고, 사용자가 검색을 클릭할 때만 결과를 새로 고치는 것을 권장합니다.

🔖 변경 로그

시맨틱 버전 관리

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

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

Server Browser의 최신 버전은 1.0.0 입니다. 다음을 주의해서 살펴보세요 업데이트 및 공지사항.

마지막 업데이트

도움이 되었나요?