배포
배포와 그 생명주기에 대해 알아보세요 - 더 깊이 이해하기 위한 개념과 모범 사례.
🗺️ 오케스트레이션
클라우드 네이티브 엣지 컴퓨팅 접근 방식을 통해 용량 수요를 충족하기 위해 몇 초 만에 새 서버를 시작합니다. 우리는 서버를 애완동물보다 가축으로 - 각 인스턴스를 수동으로 돌보는 대신 결함이 있는 인스턴스를 완전히 교체합니다.
Discord에서 문의하세요 하이브리드 오케스트레이션 옵션과 호스팅 비용 최적화에 대해 알아보세요.
모든 장단점을 완전히 이해하기 위해 다양한 오케스트레이션 방식을 비교해 봅시다. 일부 게임은 게임 루프 설계에 따라 여러 오케스트레이션 방식을 사용할 것입니다.
매치 종속
수명이 짧은(시간 제한) 서버는 매치 종료 시 축소되어 최고의 비용 대비 성능 비율.
세션은 일반적으로 다음을 통해 자동화됩니다: 매치메이킹 엄격한 규칙을 사용해 필요한 시점에 서버를 배포하며, 선택적으로 진행 중인 서버를 채워 매치 충원율을 높입니다.
👍 장점
최고의 비용 효율 - 분 단위로 플레이어 수요에 맞춰 실시간으로 확장합니다.
지역 제한 없는 호스팅 덕분에 DevOps 비용이 가장 낮고, Edgegap이 작업의 99%를 자동화합니다.
Edgegap의 퍼블릭 클라우드 인프라에 있는 615개 이상의 사이트 덕분에 최저 핑을 제공합니다.
예기치 않은 트래픽 급증 시 가장 빠른 확장(버스트 대응)이 가능합니다.
가장 높은 수준의 보안과 플레이어 치팅 방지(서버 권한)를 제공합니다.
예기치 않은 서버 충돌이 플레이어에게 미치는 영향이 최소이며, 단일 매치에만 영향을 줍니다.
👎 단점
새로운 오케스트레이션 사고방식을 도입하려면 처음에 어느 정도 적응 노력이 필요합니다.
24시간보다 오래 실행되는 서버는 자동으로 종료됩니다.
🧩 가장 적합한 대상
지연 시간에 민감한 게임 - 넷코드 최적화로도 높은 핑을 극복할 수 없을 때:
1인칭 슈팅, 격투 게임, VR & XR(가상 및 확장 현실), …
다음과 같은 게임 설계상 매치 시간에 상한이 있는,
배틀 로얄, PvPvE, 협동 슈터, MOBA, 스포츠 게임, ARPG 및 던전 크롤러, …
지역 대기
지속형 월드 및 소셜 MMO 게임 서버 수명은 종종 개별 플레이어 세션보다 깁니다.
세션은 보통 다음을 통해 배정됩니다: 서버 브라우저 플레이어 선호에 따라(지역 또는 사용자 지정 검색으로 자동화), 지역 용량에 기반한 수평 배포 사전 확장과 함께.
👍 장점
익숙하고 이해하기 쉬운, 백전노장에게는 구식의 접근 방식입니다.
가장 높은 수준의 보안과 플레이어 치팅 방지(서버 권한)를 제공합니다.
월간 약정에 기반해 쉽게 예측 가능한 비용.
👎 단점
호스팅 비용이 더 높음 - 각 지역마다 하나 이상의 유휴 대기 서버(버스트 용량)가 필요합니다.
DevOps 비용이 더 높음 - 지역별로 확장, 운영, 유지보수가 중복됩니다.
플레이어 기반이 적은 지역은 멀리 있는 서버에 접속하게 되어 높은 핑을 경험합니다.
🧩 가장 적합한 대상
플레이어가 오프라인이어도 서버에 사용자 생성 콘텐츠가 저장되는 지속형 월드.
MMO, 기지 건설이나 오브젝트 배치가 있는 샌드박스, 익스트랙션 슈터, ...
지연 시간에 관대한 게임 - 서버 권한의 실시간 물리가 필요하지 않을 때:
모바일 게임, 협동 게임, TCG/CCG, 턴제 전략 게임, …
비동기 멀티플레이어, 서버 충돌이 플레이어 경험에 미치는 영향이 최소인 경우:
고스트와의 경주, 적 기지 약탈, 타이머 기반 건설/농사 게임, …
초기화 과정이 무거운 애플리케이션 - 서버 준비에 몇 분이 걸릴 때.
피어 투 피어
개발 노력을 다음에서 전환하세요 전용 서버 에서 비경쟁 게임용 릴레이 넷코드.
관련 주제: 리슨 서버, 플레이어 호스트 권한, NAT 펀치스루.
👍 장점
NAT 펀치스루 해결을 위해 릴레이 서버만 필요하므로 호스팅 비용이 가장 낮습니다.
DevOps 비용이 가장 낮음 - 클라이언트 빌드와 배포 채널에 대해서만 유지보수가 필요합니다.
예기치 않은 서버 충돌이 플레이어에게 미치는 영향이 최소이며, 단일 매치에만 영향을 줍니다.
구현이 쉽고 프로토타입 제작이 빠르며, 백엔드 개발이 전혀 필요하지 않습니다.
👎 단점
동시성 프로그래밍 기술이 필요한 피어 투 피어 넷코드 개발 노력이 증가합니다.
가장 나쁜 핑과 불리한 네트워크 환경(예: 모바일 인터넷)에 가장 민감합니다.
보안이 가장 취약하며, 중간자 공격과 세션 하이재킹에 취약합니다.
사용자 정의 호스트 이전을 구현하지 않으면 호스트가 떠날 때 세션이 끊길 위험이 있습니다.
🧩 가장 적합한 대상
협동 및 캐주얼 게임 - 치팅이 재미를 해치거나 게임을 망치지 않을 때,
어린이 게임, 탐험 게임, 어드벤처, …
다음을 참고하세요 분산 릴레이 최고 수준의 지연 시간과 보안으로 피어 투 피어를 가능하게 하는 서비스입니다.
📍 서버 배치
어떤 오케스트레이션 방식을 선택하든, 플레이어 그룹에 적합한 서버 위치를 선택하는 것은 가능한 최상의 핑과 최적의 플레이어 경험을 보장하는 데 매우 중요합니다. 서버 배치 전략의 다양한 방법과 그것이 플레이어에게 미치는 영향을 알아보세요.
Edgegap은 다음에서 배포합니다 가능한 최상의 위치 가용 용량이 있는, 빠르고 저지연 매치를 위해.

서버 점수
서버 점수 전략은 Edgegap의 특허 받은 방법론을 사용하며, 각 매치마다 개별적으로 서버 배치를 최적화합니다. 비침습적 텔레메트리를 수행해 각 플레이어의 서버 위치에 대한 네트워크 근접도를 추정하고, 다음 기준에서 가장 우수한 서버를 선택합니다:
응답성 - 평균적으로 모든 플레이어에게 가장 낮은 핑을 제공합니다,
공정성 - 모든 플레이어에게 균형 잡히고 공정한 핑을 제공합니다.
반응성이 낮은 배치 - 서버가 멀리 있어 모든 플레이어의 핑이 높습니다:

불공정한 배치 - 핑이 고르지 않아 한 플레이어가 더 높은 지연으로 불리합니다:

좋은 배치 예시 - 모든 플레이어에게 응답성이 좋고 공정한 핑:

지리 위치
대신, 원하는 서버 위치의 위도 및 경도 좌표를 제공하세요:
⭐ 권장: 가장 빠른 핑 비콘을 찾아 해당 좌표 또는 IP를 사용자 필드에 보내세요.
⚙️ 사용자 지정: 게임 백엔드에서 지역(좌표 포함)을 정의하고, 사용자 지정 API로 가져옵니다.
👉 테스트에 가장 간단한 방법: 지역(좌표 포함)을 게임 클라이언트 개발 빌드에 하드코딩하여 정의합니다.
이 전략은 권장되지 않습니다 배포 오케스트레이션은, 지역 간 데이터 전송에 대한 엄격한 규제 요건이 있는 애플리케이션의 경우나 플레이어 IP를 사용할 수 없는 경우를 제외하고는.
또는 플레이어가 지속적(항상 온라인) 서버를 선택하도록 목록에서 서버 브라우저.
지역 고정
일부 스튜디오는 안정적이고 예측 가능한 위치를 고정하는 것을 선호합니다(예: 다음과 같은 MMO 영속성). 고려해 보세요 서버 브라우저 과 지역별 확장 정책 및 자동 할당 예약.
이 전략은 권장되지 않습니다 배포 오케스트레이션은, 지역 간 데이터 전송에 대한 엄격한 규제 요건이 있는 애플리케이션의 경우나 플레이어 IP를 사용할 수 없는 경우를 제외하고는.
🟢 연결 품질
어떤 게임(및 플레이어)은 다른 게임보다 지연 시간이나 랙에 더 민감합니다. 플레이어 보고는 대규모에서 사건이나 회귀 버그의 훌륭한 지표이지만, 플레이어는 네트워킹 개념에 대한 깊은 이해가 부족할 수 있으며 스튜디오, 넷코드 또는 서버에 빠르게 책임을 돌릴 수 있습니다.
일부 문제의 근본 원인은 플레이어에게 보이지 않을 수 있으므로, 스튜디오와 호스팅 제공업체의 협력이 매우 중요할 수 있습니다. Edgegap의 최우선 과제는 항상 가능한 최상의 서비스를 제공하는 것입니다.
많은 플레이어 보고를 받고 있거나, 광범위한 장애를 겪고 있거나, 반복적인 문제가 발생한다면, 플랫폼의 지원 티켓을 통해 즉시 문의해 주세요.
저지연
플레이어 지연 시간은 다음 간 데이터 전송 시 발생하는 지연의 합입니다:
물리적 장치 - 를 가로질러 이동하는 물리적 신호 인터넷 네트워크 토폴로지.
호스트 간 - 프로토콜, 전송, 보안 조치로 인해 발생합니다.
프로세스 간 - 클라이언트/서버에서 데이터의 (언)박싱 및 처리로 인해 발생합니다.
Edgegap은 더 짧은 응답과 더 적은 네트워크 홉을 위해 서버를 플레이어에게 더 가까이 배치하여 물리적 지연을 줄입니다. 17개의 클라우드 및 베어메탈 제공업체에 걸친 위치를 통해, 여러분은 전 세계 어디서나 플레이어에게 최고 수준의 핑을 제공합니다.
전 세계 서버 및 인터넷 커버리지(Edgegap뿐만 아니라)는 다음과 같은 요인에 의해 제한됩니다:
인프라 가용성 - 특정 지역의 인터넷 연결 품질이 충분하지 않을 수 있습니다.
자연적 요인 - 서버에는 민감한 구성 요소가 포함되어 있어 안정성이 필요합니다(지진 없음).
고가용성
전 세계 여러 위치의 서버 가용성은 시간에 따라 달라지며, 하루에도 여러 번 변합니다. Edgegap은 자동으로 확장/축소합니다 위치 요청 시, 다음을 고려하여:
버스트 트래픽 - 15분 이내에 이루어진 배포는 확장 추세에 반영됩니다.
자원 요구 사항 - 각 위치의 총 vCPU 수요가 확장 속도를 결정합니다.
제공업체 대안 - 일부 원격 위치는 이용 가능한 제공업체 옵션이 더 적습니다.
제공업체 용량 - 일부 위치는 4 vCPU 또는 8 vCPU 머신만 제공할 수 있습니다.
서비스 품질 - 일부 제공업체는 같은 지역의 ISP 전반에서 더 나은 네트워크 품질을 제공합니다.
스튜디오 일정 - 테스트 및 QA, 비공개 베타 또는 토너먼트에 대한 특별 요청.
모든 애플리케이션의 배포 요청은 각 위치의 수요를 평가하기 위해 통합됩니다. 모든 조직은 기본적으로 동일한 할당 우선순위를 가집니다. 스튜디오는 사용자 지정을 추가할 수 있습니다 프라이빗 플릿.
부디 출시 계획을 위해 문의해 주세요또는 위치 가용성에 대한 요청이 있다면.
플레이어 문제 해결
플레이어 문제는 때때로 서버나 호스팅 버그로 인해 발생할 수 있지만, 종종 무관합니다 - 케이블/와이파이 연결, 인터넷 서비스 제공업체, 백엔드 서비스, 또는 클라이언트/서버 저수준 라이브러리의 버그도 고려하세요.
플레이어 보고나 사건을 문제 해결할 때는 다음 요소를 고려하세요:
지역별 네트워킹 및 ISP 문제:
지역 인터넷 서비스 제공업체(ISP)가 일시적으로 사건을 해결하고 있을 수 있으며,
일부 지역(예: 중국, 러시아)은 지역 제재로 인해 제한될 수 있습니다.
캐싱 수준 - 캐싱이 없으면 더 느린 배포로 인해 세션이 시간 초과될 수 있습니다:
배포 최대 시간 - 느리고 무거운 초기화 과정 때문에 배포가 실패할 수 있습니다:
다음을 보세요 앱 및 버전 타임아웃 시간을 늘리려면.
서버 이미지 또는 통합 문제 사용자 지정 빌드 파이프라인의 초기 반복에서.
클라이언트 매치 기록 UI에 배포 ID를 표시 문제 해결 시 플레이어 보고를 추적하기 위해.
🔄 배포 생명주기
Edgegap 배포는 배포 상태로 표시되는 여러 생명주기 단계를 거칩니다.
1. 배포 시작
다음에 대한 배포는 테스트 목적 다음으로 시작할 수 있습니다:
Unreal Engine - Unreal Engine 프로젝트용 Docker Extension 또는 EGIK 플러그인.
Unity - Unity 프로젝트용 호스팅 퀵스타트 플러그인.
Godot - Godot 프로젝트용 호스팅 퀵스타트 플러그인.
대시보드 웹 UI - 빠른 서버 테스트와 반복을 위한 쉬운 웹 인터페이스.
배포를 수동으로 시작하고 URL과 포트를 붙여넣는 것만으로는 라이브 게임에 충분하지 않습니다.
다음 중 하나를 사용해 세션 관리 및 필요에 따른 확장을 위한 인기 게임 흐름을 자동화하세요:
짧은 라운드
온디맨드 매치
실력 등급 및/또는 사용자 지정 규칙
지속형 또는 라운드
소셜 지역 허브
자동 할당 및/또는 사용자 지정 검색
사용자 지정 백엔드:
라이브 게임 마이그레이션
저장 request_id (배포 ID) 및 배포에 태그를 지정 나중에 문제를 식별하고 해결하기 위해.
2. 배포 중
배포가 시작되면 시스템은 여러 단계를 빠르게 순차적으로 수행합니다:
텔레메트리 - 사용 가능한 데이터 센터에서 각 플레이어까지의 네트워크 응답성을 측정합니다,
배포 - 용량을 예약하고 서버 컨테이너 시작을 준비합니다,
컨테이너 부팅 - 컨테이너를 시작하고, 종속성을 설치하며, 초기화합니다,
후처리 - 로그 저장, 모니터링을 추가하고 배포를 마무리합니다.
활성화 앱 버전에서 활성 캐싱 몇 초 안에 서버를 배포하려면.
요청이 너무 많음 429 - 안정성을 보장하고 예상치 못한 청구를 방지하기 위해, 귀 조직에 다음의 속도 제한을 적용합니다 40 req/s. 문의하기 출시를 계획하고, 런치 트래픽을 추정하며, 성공을 준비하세요.
3. 배포 준비 완료
배포가 Ready 상태가 되어도 엔진은 아직 할 일이 남아 있습니다. 엔진은 서브시스템과 프레임워크를 부트스트랩한 다음, 맵을 포함한 에셋을 메모리에 로드합니다. 이는 배포가 Ready가 된 후에 발생하며, 보통 최적화 수준에 따라 최대 1분이 걸립니다.
플레이어 연결을 몇 번 다시 시도하세요미리 정의된 타임아웃 기간이 끝날 때까지, 그 후 중단하고 새 세션을 시작합니다. 서버는 일반적으로 완전히 초기화되기 전까지 새 플레이어 연결을 स्वीकार하지 않습니다.
서버 충돌 처리는 사용자의 프로세스 재시작 정책. 서버 상태가 손실될 수 있습니다.
버전의 앱 및 버전 상태에 따라 다음을 받을 수 있습니다:
🟢 캐시 적중
캐싱이 활성화되어 있습니다. 이 머신에 미리 로드된 이미지를 재사용하여 배포가 더 빨랐습니다.
🟡 웜 스타트
캐싱이 비활성화되어 있습니다. 동일한 머신에서 이전 배포를 위해 다운로드한 이미지를 재사용하여 배포가 더 빨랐습니다. 전 세계에서 일관되게 빠른 배포를 위해 캐싱을 활성화하세요.
🔴 캐시 미스
캐싱이 활성화되어 있습니다. 캐시 전파가 완료되기 전에 갑작스러운 트래픽 급증이 발생하여 배포가 더 느렸습니다. 배포 요청에서 “require cached locations”를 활성화하면 이를 방지할 수 있지만, 예상치 못한 트래픽 급증 시 더 많은 Unprocessable 배포가 발생할 수 있습니다.
🔴 콜드 스타트
캐싱이 비활성화되어 있습니다. 배포가 더 느렸고, 이미지는 배포 시점에 다운로드되었습니다. 더 빠른 배포를 위해 캐싱을 활성화하세요.
4. 배포 오류
배포는 예상치 못한 이유로 언제든지 Unprocessable 상태가 될 수 있습니다. 이는 통합을 테스트하거나 새 서버 빌드를 테스트하는 동안 더 자주 발생합니다.
오류 배포에는 요금이 부과되지 않으며, 24시간 후 자동으로 중지됩니다.
문제 해결 단계:
다음으로 Edgegap 서비스 상태를 확인하세요 저희 업타임 모니터링 페이지.
Edgegap 문제를 배제하기 위해 Docker Desktop을 사용하여 서버 컨테이너를 로컬에서 테스트해 보세요.
도움을 요청할 때, 배포 ID와 유용한 세부 정보를 포함하세요 그래야 신속히 조사할 수 있습니다!
5. 배포 중지
클라우드 배포는 24시간 실행 후 종료됩니다 인프라 유지보수를 위한 서버 정리 정책을 따르며, 예기치 않은 버그로 인해 배포가 제대로 종료되지 않았을 때 예상치 못한 비용이 누적되는 것을 방지하기 위해서입니다.
24시간 이상 장시간 실행되는 서버의 경우 다음 사용을 고려하세요 프라이빗 플릿 과 영속성.
다음 방법으로 비용을 최적화하고 유휴 배포를 조기에 중지하세요:
앱 버전 재시작 정책 - 종료나 충돌 시 자동 재시작을 방지합니다.
게임 최대 지속 시간 - 다음에서 할당된 시간 앱 및 버전 만료되었습니다.
다음을 통한 자동 중지 DELETE_URL - 플레이어가 떠나고 매치가 종료된 후 배포가 스스로 중지되었습니다.
다음을 보세요 Unreal Engine 및 Unity SDK 유틸리티와 쉬운 통합을 위한 가이드 또는 API를 사용하세요.
사용자 지정 백엔드에서 중지 - 사용자 지정 세션 오케스트레이션은 다음을 사용할 수 있습니다 배포 API.
프라이빗 플릿 배포를 실행 중인 호스트가 예약된 작업을 통해 삭제되었습니다.
👀 관찰 가능성
게임 서버가 제3자와 상호 운용하고 운영 인사이트를 얻을 수 있게 합니다.
발견 가능성
Ready가 되면 배포에는 URL(fqdn)과 각 내부 포트에 대한 외부 포트가 할당됩니다.
사용하세요 배포 태그(최대 40자)를 사용해 배포를 쉽게 표시하고 나중에 찾을 수 있습니다.
웹소켓(WS) 및 보안 웹소켓(WSS)
Edgegap에서 웹소켓 기반 넷코드를 사용하려면 두 가지 옵션이 있습니다:
관리형 인증서, 코드를 작성하지 않고 1분 만에 설정 가능:
다음을 구성하세요 앱 및 버전 에서 Websocket(WS) 사용 및 TLS 업그레이드 활성화,
클라이언트를 연결하는 데 Edgegap URL을 사용합니다(예:
https://5fa53fa00a57.pr.edgegap.net/)
자체 관리 인증서, 사용자 지정 도메인을 사용하려면:
다음을 구성하세요 앱 및 버전 에서 보안 웹소켓(WSS) 사용,
사용자 지정 DNS 레코드(예: Cloudflare).
처리되지 않은 서버 예외가 발생하면 배포의 컨테이너가 재시작되고 TLS 보안이 무효화됩니다. 그런 경우, 서버를 중지하고 및 플레이어를 새 배포로 다시 매칭하세요. 서버 상태가 손실될 수 있습니다.
삽입된 변수
게임 서버는 종종 서버 IP, 내부 포트 값 등 추가 정보가 필요합니다. 읽기 전용 환경 변수를 삽입하는 것은 파라미터를 전달하는 안정적이고 클라우드에 구애받지 않는 방법입니다.
다음으로 변수 값을 가져오세요 Unity SDK, Unreal EGIK, 또는 런타임의 환경 변수 메서드를 사용합니다.
사용자 지정 변수
각 배포에 대해 최대 20개의 사용자 지정 변수를 정의할 수 있으며, 각 변수에는 최대 4KB의 문자열 데이터를 포함할 수 있습니다.
예약된 이름(아래)을 사용하지 마세요. 그렇지 않으면 사용자 지정 변수가 덮어쓰여집니다!
Edgegap이 서버에 삽입하는 변수를 읽어 중요한 정보에 액세스하세요:
식별자
ARBITRIUM_REQUEST_ID- 예:f68e011bfb01.고유한 배포 ID로, 요청 ID라고도 합니다. 더 많은 정보를 가져오는 데 사용됩니다.
배포 URL은 항상 다음 형식을 가집니다
{ARBITRIUM_REQUEST_ID}.pr.edgegap.net.
ARBITRIUM_PUBLIC_IP- 예:162.254.141.66.이 호스트의 공용 IP 주소로, URL 대신 연결에 사용할 수 있습니다.
ARBITRIUM_HOST_ID- 예:alpha-north-america-70364ef8.배포를 호스팅하는 머신의 고유 식별자이며, 다른 배포와 공유됩니다.
ARBITRIUM_DEPLOYMENT_TAGS- 예:tag1,tag2.쉼표로 구분된 사용자 정의 배포 태그, 간편한 검색 및 필터링에 유용합니다.
ARBITRIUM_PRIVATE_FLEET_ID- 예:PUBLIC_CLOUD, 또는 다음에서 호스팅되는 경우 플릿 ID 프라이빗 플릿.
리소스 사양
ARBITRIUM_HOST_IN_PRIVATE_FLEET- 예:false, 다음에서 호스팅되는지 여부를 나타냅니다 프라이빗 플릿.ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY- 예:2300, MHz 단위의 프로세서 주파수입니다.ARBITRIUM_DEPLOYMENT_VCPU_UNITS- 예:256, 할당된 vCPU 단위(1024 = 1 vCPU).ARBITRIUM_DEPLOYMENT_MEMORY_MB- 예:512, 할당된 RAM(MB 단위)(1024 = 1 GB).
수명 주기 관리
ARBITRIUM_DELETE_URL- 예:https://api.edgegap.com/v1/self/stop/9f511e17/660.배포에서 호출 가능, 배포가 정상적으로 중지됩니다.
고유한 일회용이 필요합니다
ARBITRIUM_DELETE_TOKEN에Authorization헤더.
ARBITRIUM_DELETE_TOKEN- 예:7df4cd933df87084b34ae80d8abde293.ARBITRIUM_CONTEXT_URL- 예:https://api.edgegap.com/v1/context/9170f5211e17/17.배포에서만 호출 가능하며, 더 많은 배포 세부 정보를 반환합니다.
고유한 값이 필요합니다
ARBITRIUM_CONTEXT_TOKEN에Authorization헤더.
ARBITRIUM_CONTEXT_TOKEN- 예:dfaf50b9333b9ee07b22ed247e4a17e6.
발견 가능성
ARBITRIUM_PORT_GAMEPORT_INTERNAL- 예:7777, 서버 리스너용 내부 포트입니다.ARBITRIUM_PORT_GAMEPORT_EXTERNAL- 예:31504, 클라이언트 연결용 외부 포트입니다.보안상 외부 포트 값은 각 배포마다 무작위로 지정됩니다.
ARBITRIUM_PORT_GAMEPORT_PROTOCOL- 예:UDP, 네트코드 전송의 프로토콜입니다.
예시에서는 포트 이름을 다음과 같이 지정했다고 가정합니다 gameport (기본값). 각 포트는 추가로 정리된 앱 및 버전 변수: @슈퍼 포트! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .
ARBITRIUM_HOST_BEACON_PUBLIC_IP- 예:139.177.198.69, 가장 가까운 비컨의 공용 IP입니다.ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL- 예:30199, UDP를 통한 핑 측정을 위한 것입니다.ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL- 예:30456, TCP를 통한 핑 측정을 위한 것입니다.
구조화된 정보(문자열 형태의 JSON)
대시보드 모니터링
우리의 대시보드 서버 확장성을 모니터링하고 운영을 지원하는 유틸리티를 제공합니다.
분석
찾기 사이드바 메뉴에서 분석 대시보드를 서버 호스팅 및 오케스트레이션 카테고리 아래에서.
🌟 Pay as You Go 요금제로 업그레이드 자세한 서버 성능 지표와 인사이트를 잠금 해제하세요:
일반 인사이트: 버전별 실시간 서버 수와 리소스 사용 개요로 릴리스를 모니터링하세요,
CPU 인사이트: 프로세서 집약적인 작업으로 인한 지연 서버를 문제 해결하세요,
메모리 인사이트: 할당된 메모리 초과로 인한 서버 재시작을 완화하세요,
네트워킹 인사이트: 비효율적인 네트워킹 패턴을 감지하고 네트코드를 최적화하세요.

배포 지도
다음에서 배포 지도를 찾으세요 대시보드의 배포 상세 페이지.
맵에서 배포 위치, 사용 가능한 위치, 추정 플레이어 위치를 미리 볼 수 있습니다:

배포 밸런스 포인트
다음에서 배포 밸런스 포인트 히트맵을 찾으세요 대시보드의 애플리케이션 상세 페이지.
배포 밸런스 포인트 히트맵을 미리 보고 다음으로 필터링하세요 앱 및 버전. 밸런스 포인트는 주어진 배포에서 각 플레이어까지의 네트워크 근접도가 동일한 대략적 위치입니다:

배포 로그
다음에서 배포 로그를 찾으세요 대시보드의 배포 상세 페이지.
배포 로그는 다음에 대한 정보를 표시합니다 배포:

컨테이너 로그
다음에서 컨테이너 로그를 찾으세요 대시보드의 배포 상세 페이지.
문제가 있거나 디버깅할 때 게임 서버의 로그를 살펴보세요:

배포가 중지되면 컨테이너 로그는 삭제됩니다. 설정 타사 S3 로그 저장소 를 사용해 로그를 저장하세요.
컨테이너 지표
다음에서 컨테이너 지표를 찾으세요 대시보드의 배포 상세 페이지.
컨테이너 지표(프로세서, 메모리, 네트워킹)를 검토하여 다음을 수행합니다:
다음과 같은 경우 일반적인 연결 문제를 식별합니다 배포,
리소스 사용량 급증을 유발하는 비효율적인 구현 패턴을 감지합니다,
특정 시나리오에서 비효율적인 리소스 사용을 정확히 찾아냅니다,
최적화 중 서버의 리소스 사용량 변화를 검증합니다,
서버 초기화 시 리소스 소비와 소요 시간을 벤치마킹합니다.
기록 지표는 1분 간격의 평균 값을 표시하며, Free 요금제에서 사용할 수 있습니다.
🌟 Pay as You Go 요금제로 업그레이드 1초 간격의 정밀 지표를 사용하려면 업그레이드하세요.

컨텍스트 및 상태
추가 배포 정보는 JSON 형식으로 가져올 수 있습니다:
배포 내부(게임 서버)에서 다음을 사용하여 배포 컨텍스트 API,
배포 외부(백엔드 / 타사)에서 다음을 사용하여 배포 상태 API.
요청이 너무 많음 429 - 컨텍스트 및 상태 API는 조직당 초당 20회 요청으로 제한됩니다. 이 API는 자동화된 세션 오케스트레이션이 아니라 특수 작업 중 사용하도록 설계되었습니다.
사용하세요 배포 속도 제한을 피하고 확장성을 보장하기 위해 사용자 지정 세션 오케스트레이션을 사용하세요.
배포 필터링
모든 배포를 빠르게 검색하려면 다음을 할 수 있습니다 대시보드를 사용하거나:

또는 플레이어가 지속적(항상 온라인) 서버를 선택하도록 목록에서 서버 브라우저.
API로 배포 목록 조회 백엔드 통합으로 필터를 적용하세요:
에 또는 nin
[ "7e709a0d8efd", "4ba353100b4b" ]
에 또는 nin
[ "tagA", "tagB" ]
에 또는 nin
[ "my-app", "my-other-app" ]
에 또는 nin
[ "1.0.0", "prod" ]
에 또는 nin
[ "fleet-eu", "fleet-us" ]
ilike
"%-eu%"
에 또는 nin
[ "alpha-north-america-95fab093" ]
ilike
"%north-america%"
요청에 나타나는 순서대로 여러 필드로 결과를 정렬합니다:
asc 또는 desc
available_session_sockets
asc 또는 desc
필터 쿼리 예시:
요청에 Authorization Edgegap API 토큰이 포함된 헤더를 추가하는 것을 잊지 마세요.
웹훅
다음의 변경 사항에 대해 게임 백엔드로 간단한 HTTP 알림을 받으세요 배포 다음에 웹훅 URL을 지정하여 배포 API 요청. 사용 가능 대상:
준비 완료 시: 배포 컨테이너 가 성공적으로 시작되었습니다 (그 후 서버 초기화가 시작됩니다).
오류 시: 배포를 시작할 수 없었고 배포 오류가 발생했습니다.
종료 시: 배포 그리고 게임 서버에 더 이상 연결할 수 없습니다.
Ready 및 Error 웹훅은 같은 배포에서 절대 트리거되지 않습니다.
웹훅은 사용자 지정 백엔드 배포 통합을 위한 기본 권장 방법입니다.
웹훅은 재시도되지 않으며속도 제한이나 오류로 인해 백엔드가 요청을 처리하지 못하면 손실될 수 있습니다. 예상 시간 내에 웹훅을 받지 못한 경우 Status API로 대체하세요.
🚨 문제 해결
배포 문제를 해결할 때:
통합 버그를 배제하기 위해 서버를 로컬에서 실행해 보세요,
이 페이지의 문제 해결 단계를 검토하세요,
다음 곳에서 문의해 주세요 커뮤니티 디스코드 그리고 배포 ID를 포함해 주세요.
마지막 업데이트
도움이 되었나요?

