edgegap.comCommunity DiscordDashboard

배포

배포와 그 라이프사이클에 대해 알아보세요 - 더 깊은 이해를 위한 개념과 모범 사례.

🗺️ 오케스트레이션

클라우드 네이티브 엣지 컴퓨팅 접근 방식으로 수초 안에 새 서버를 시작하여 용량 수요를 충족하세요. 우리는 서버를 반려동물보다 가축처럼 취급합니다 - 각 개체를 수동으로 보살피는 대신, 결함 있는 인스턴스를 완전히 교체합니다.

오케스트레이션 선택은 DevOps 비용, 서버 비용, 그리고 확장성에 영향을 미칩니다.

대부분의 게임은 완벽히 한 상자에 들어맞지 않습니다. Discord로 문의하세요 하이브리드 오케스트레이션 옵션을 알아보려면.

장단점을 완전히 이해하려면 다양한 오케스트레이션 방법을 비교해 봅시다.

매치-바운드

현대 스튜디오를 위한 황금 표준으로, 최고의 비용 효율과 가장 쉬운 통합을 제공합니다.

👍 장점

  • 최고의 비용 효율 - 분 단위로 플레이어 수요에 맞춰 실시간으로 스케일링합니다.

  • 리전 없는 호스팅으로 DevOps 비용이 최저, Edgegap이 작업의 99%를 자동화합니다.

  • Edgegap의 퍼블릭 클라우드 인프라에 615개+ 사이트가 있어 핑이 가장 낮습니다.

  • 예상치 못한 트래픽 급증 시 가장 빠른 스케일 업(버스트 능력).

  • 최고 수준의 보안과 플레이어 치팅 방지(서버 권한).

  • 예상치 못한 서버 크래시가 플레이어에게 미치는 영향이 최소화되어, 단일 매치에만 영향을 줍니다.

👎 단점

  • 새로운 오케스트레이션 사고 방식을 도입하려면 초기 러닝 노력이 필요합니다.

  • 24시간 이상 실행되는 서버는 자동으로 종료됩니다.

🧩 적합한 사례

  • 지연 시간에 민감한 게임 - 넷코드 최적화로 높은 핑을 극복할 수 없을 때:

    • FPS, 대전 격투, VR & XR(가상 및 확장 현실), …

  • 설계상 매치 지속 시간의 상한이 있는 게임,

    • 배틀 로얄, PvPvE, 협동 슈터, MOBA, 스포츠 게임, ARPG & 던전 크롤러, …

🔎 발견 가능성

Edgegap은 각 지역의 플레이어 활동을 바탕으로 615개+ 서버 위치를 자동으로 상하향 스케일합니다. 성공을 준비하세요 - 원활하게 60분 안에 동시 사용자 1,400만 명까지 스케일.

지역 대기(Regional Standby)

전통적인 모델 - UGC가 있는 지속 세계와 소셜 MMO 게임을 위해.

👍 장점

  • 전통적인 방식으로, 베테랑에게 친숙하고 이해하기 쉽습니다.

  • 최고 수준의 보안과 플레이어 치팅 방지(서버 권한).

  • 월 단위 약정을 바탕으로 비용을 쉽게 예측 가능.

👎 단점

  • 더 높은 호스팅 비용 - 각 지역에 유휴 대기 서버(버스트 용량)가 하나 이상 필요합니다.

  • 더 높은 DevOps 비용 - 스케일링, 운영, 유지보수가 지역마다 중복됩니다.

  • 플레이어 기반이 작은 지역은 먼 서버에 접속하게 되어 핑이 높습니다.

🧩 적합한 사례

  • 플레이어가 오프라인이어도 서버에 사용자 생성 콘텐츠가 저장되는 지속 세계.

    • MMO, 기지 건설/오브젝트 배치형 샌드박스, 익스트랙션 슈터, ...

  • 지연 허용 게임 - 서버 권한의 실시간 물리가 필요하지 않을 때:

    • 모바일 게임, 협동 게임, TCG/CCG, 턴제 전략, …

  • 비동기 멀티플레이 - 서버 크래시가 플레이어 경험에 미치는 영향이 미미할 때:

    • 고스트와 레이스, 적 기지 약탈, 타이머 기반 건설/농사 게임, …

  • 초기화가 무거운 애플리케이션 - 서버 준비에 몇 분이 걸릴 때.

🔎 발견 가능성

참고 관리형 클러스터 대상: 마이크로서비스와 백엔드 서비스를 셀프 호스팅하기 Edgegap에서.

피어 투 피어

개발 노력을 전용 서버 에서 경쟁적이지 않은 게임을 위한 릴레이 넷코드로 전환.

관련 주제: 리슨 서버, 플레이어 호스트 권한, NAT 펀치스루.

👍 장점

  • 최저 호스팅 비용, NAT 펀치스루 해결을 위해 릴레이 서버만 필요.

  • 최저 DevOps 비용 - 클라이언트 빌드와 배포 채널에 대해서만 유지보수 필요.

  • 예상치 못한 서버 크래시가 플레이어에게 미치는 영향이 최소화되어, 단일 매치에만 영향을 줍니다.

  • 백엔드 개발 없이도 구현이 쉽고 프로토타입까지 빠름.

👎 단점

  • 동시성 프로그래밍 역량이 필요한 P2P 넷코드 개발 노력이 증가.

  • 최악의 핑 시간과 불리한 네트워크 조건(예: 모바일 인터넷)에 가장 민감.

  • 가장 약한 보안, 중간자 공격 및 세션 하이재킹에 취약.

  • 커스텀 호스트 마이그레이션을 구현하지 않으면 호스트 이탈 시 세션 끊김 위험.

🧩 적합한 사례

  • 협동 & 캐주얼 게임 - 치팅이 재미를 크게 해치거나 게임을 망치지 않을 때,

    • 키즈 게임, 탐험 게임, 어드벤처, …

🔎 발견 가능성

자세한 내용은 분산 릴레이 를 참조하세요. 최상급 지연 시간과 보안으로 P2P를 가능하게 합니다.

📍 서버 배치

어떤 오케스트레이션 방식을 선택하든, 플레이어 그룹에 적합한 서버 위치를 고르는 것은 최적의 핑과 플레이어 경험을 보장하는 데 중요합니다. 서버 배치 전략과 그것이 플레이어에게 미치는 영향을 알아보세요.

서버 배치 전략은 플레이어의 경험, 유지율, 그리고 게임 리뷰에 영향을 줍니다.

Edgegap은 가능한 최적의 위치 와 가용 용량에서빠르고 저지연의 매치를 제공합니다.

참고 배포 에서 서버 배치를 실시간으로 분석하고대규모로 수행합니다.

서버 점수

서버 점수 전략은 Edgegap의 특허받은 방법론을 사용하며, 각 매치마다 서버 배치를 개별적으로 최적화합니다비침투적 텔레메트리로 각 플레이어의 네트워크 근접성을 추정하고 최적을 제공하는 서버를 선택합니다:

  • 반응성 - 모든 플레이어에게 평균적으로 가장 낮은 핑 제공,

  • 공정성 - 모든 플레이어에게 균형 잡히고 공정한 핑 제공.

우리의 매치메이커 는 최상의 경험을 보장하기 위해 기본적으로 서버 점수 전략을 사용합니다. 이 전략을 Deploy API와 함께 사용하려면, 배포 요청에 플레이어의 퍼블릭 IP 또는 지리 좌표를 입력하세요.

반응성이 낮은 배치 - 서버가 멀어 모든 플레이어의 핑이 높음:

불공정한 배치 - 핑이 고르지 않아 특정 플레이어가 불리함:

좋은 배치 예시 - 모든 플레이어에게 반응성과 공정성이 좋음:

이 전략은 서로 멀리 떨어진 플레이어 그룹을 호스팅할 때 특히 효과적입니다 (북미 vs 유럽, 또는 서해안 vs 동해안), 프리메이드 로비에서 자주 발생합니다.

지오로케이션

또는, 플레이어의 위도/경도 좌표 또는 선호 서버 위치의 좌표를 제공 하여 자동 텔레메트리 대신 사용할 수 있습니다. 이 접근 방식은 클라이언트 측 지오 조회 구현이 추가로 필요하며, 전적으로 게임 개발자의 솔루션에 의존합니다.

지오로케이션 전략은 배포 오케스트레이션에는 권장되지 않으며, 다만 지역 간 데이터 전송에 엄격한 규제가 있는 애플리케이션이나 플레이어 IP를 사용할 수 없는 경우에는 예외입니다.

이 전략을 Deploy API와 함께 사용하려면, 배포 요청에 플레이어의 퍼블릭 IP 또는 지리 좌표를 나열하세요.

리전 락

서버는 대략화된 리전 파라미터로 배치될 수 있으며, 방법은 다음과 같습니다:

  • 플레이어의 메타데이터(플레이어 계정 DB)에 기반해 자동 선택하거나,

  • 매치메이킹 중 플레이어가 선택하여 높은 클라이언트-서버 지연이 있는 배치를 허용.

이 전략만 단독으로 사용하는 것은 네트워크 성능 저하로 이어질 수 있어 권장되지 않습니다.

다른 전략과 사전 필터로서의 리전 선택을 결합해 사용하는 것 이 더 나은 대안입니다.

🟢 연결 품질

일부 게임(및 일부 플레이어)은 다른 이들보다 지연이나 렉에 더 민감합니다. 대규모 사건이나 회귀 버그의 지표로 플레이어 리포트는 훌륭하지만, 플레이어는 네트워킹 개념에 대한 깊은 이해가 부족할 수 있으며 스튜디오, 넷코드, 서버에 빠르게 책임을 돌리기 쉽습니다.

일부 문제의 근본 원인은 플레이어에게 보이지 않을 수 있으므로, 스튜디오와 호스팅 제공자의 협력이 중요할 수 있습니다. Edgegap의 최우선 순위는 언제나 가능한 최상의 서비스를 제공하는 것입니다.

플레이어 리포트를 다수 받고 있거나, 광범위한 장애 또는 반복되는 문제가 발생한다면, 즉시 당사 플랫폼의 지원 티켓을 통해 연락해 주세요.

도움이 필요하시면, Discord로 문의해 주세요. 라이브 게임 지원은 저희의 티켓 발급 시스템을 참조하세요.

저지연

플레이어 지연 시간은 다음 간 데이터 전송에서 발생하는 지연의 조합입니다:

  • 물리적 디바이스 - 물리 신호가 인터넷 네트워킹 토폴로지,

  • 호스트 간 을 가로지르는 데서 발생하며, 프로토콜, 전송, 보안 조치의 결과입니다,

  • 프로세스 간 - 클라이언트/서버에서 데이터 (언)박싱과 처리에서 비롯됩니다.

Edgegap은 서버를 플레이어에게 더 가깝게 배치해 물리적 지연을 줄여 응답을 더 빠르게 하고 네트워크 홉 수를 줄입니다. 17개의 클라우드 및 베어메탈 제공업체 전역 위치로, 전 세계 어디서나 플레이어에게 최상급 핑을 제공합니다.

서버와 인터넷 커버리지는(Edgegap만이 아니라) 다음과 같은 요인으로 전 세계적으로 제한됩니다:

  • 인프라 가용성 - 특정 지역의 인터넷 연결 품질이 충분치 않을 수 있음,

  • 자연적 요인 - 매우 복잡한 서버랙은 대체로 안정적인 환경을 필요로 함.

고가용성

전 세계 다양한 위치의 서버 가용성은 시간에 따라 변하며 하루에도 여러 번 바뀝니다. Edgegap은 자동으로 스케일 업/다운하여 위치를 온디맨드로조정하며, 다음을 고려합니다:

  • 버스트 트래픽 - 15분 내에 이루어진 배포,

  • vCPU 요구사항 - 배포당 vCPU가 많을수록 특정 위치에 대한 총 수요 증가,

  • 제공자 옵션 - 일부 원격 위치는 제공자 선택지가 적음,

  • 머신 가용성 - 일부 위치는 4 vCPU 또는 8 vCPU 머신만 제공,

  • 스튜디오 요청 - 테스트, QA, 얼리 액세스, 클로즈드 베타 또는 토너먼트 용도.

모든 애플리케이션의 배포 요청을 합산해 위치 수요를 평가합니다. 모든 조직은 기본적으로 동일한 할당 우선순위를 가지며, 특정 하드웨어나 위치가 필요한 엔터프라이즈 고객을 위한 프라이빗 서버 풀 추가가 가능합니다.

문의하여 출시 계획을 함께 세우세요또는 위치 가용성 관련 요청이 있다면 알려주세요.

플레이어 이슈 해결

플레이어 이슈는 서버 버그나 제공자 사건에서 비롯될 수 있지만, 로컬 ISP, 게임 서비스, 저수준 라이브러리의 버그, 인프라 제공자 등 제3자로부터 발생할 수도 있습니다.

플레이어 리포트나 사건을 트러블슈팅할 때 고려할 요소:

  • 매치메이킹 품질 - 배포 에서 최상의 결과를 얻으려면 플레이어는 서로(동일 지역) 가까워야 합니다:

    • 다음을 참조 } else { 그리고 핑 비콘 하여 당사 권장사항을 확인,

    • 다음을 참조 심층 분석 플레이어 리포트에 관련된 서버 로그를 찾는 방법을 학습,

  • 지역 문제:

    • 현지 인터넷 서비스 제공업체(ISP)가 일시적으로 사건을 해결 중일 수 있음,

    • 일부 지역(예: 중국, 러시아)은 지역 제재로 제한될 수 있음,

  • 캐싱 수준 - Edgegap은 캐시된 위치에서 빠른 배포를 우선시합니다:

  • 최대 배포 시간 - 초기화가 느리고 무거워 배포가 실패할 수 있음:

    • 다음을 참조 앱 및 버전 타임아웃 기간을 늘리려면,

    • 필요할 때까지 초기화 단계를 지연,

  • 서버 이미지 또는 통합 문제.

클라이언트 매치 기록 UI에 배포 ID 표시 하여 트러블슈팅 시 플레이어 리포트를 추적하세요.

광범위한 버그, 일시적 이슈, 장애에 대해 사용자에게 알리고 부정적 정서를 완화하세요.

🔄 배포 라이프사이클

Edgegap 배포는 배포 상태로 표시되는 여러 라이프사이클 단계를 거칩니다.

1. 배포 시작

다음과 같은 테스트 목적 의 배포는 다음으로 시작할 수 있습니다:

  • 언리얼 엔진 - Unreal Engine 프로젝트용 Docker 확장 또는 플러그인,

  • 유니티 - Unity 프로젝트용 플러그인,

  • 대시보드 웹 UI - 서버 통합 테스트를 위한 사용하기 쉬운 웹 인터페이스.

다음과 같은 라이브 프로덕션 환경 은 다음으로 시작해야 합니다:

저장 request_id (배포 ID) 및 배포에 태그 지정 하여 나중에 식별 및 문제 해결.

다음을 사용해 테스트할 때 Deploy API기본 Dockerfile CMD 를 커스텀 명령으로 오버라이드할 수 있습니다.

2. 배포 중

배포가 시작되면, 시스템은 빠르게 다음 단계를 수행합니다:

  • 텔레메트리 - 사용 가능한 데이터 센터에서 각 플레이어까지 네트워크 반응성을 측정,

  • 배포 - 용량을 예약하고 서버 컨테이너 시작 준비,

  • 컨테이너 부팅 - 컨테이너 시작, 종속성 설치 및 초기화,

  • 후처리 - 로그 스토리지, 모니터링 추가 및 배포 최종화.

활성화 앱 버전에서 활성 캐싱 서버를 몇 초 내에 배포하려면.

Too Many Requests 429 - 안정성을 보장하고 예기치 않은 청구서를 방지하기 위해, 조직의 요청을 다음으로 레이트 제한합니다 40 req/s. 문의하기 출시 계획 수립, 런칭 트래픽 추정, 성공 준비를 위해.

3. 배포 준비 완료

컨테이너가 완전히 초기화되었고 서버가 지금 시작 중입니다. 몇 초에서 1분 동안은 게임 엔진(또는 커스텀 런타임)이 플레이어 연결을 받을 준비가 될 때까지 서버가 여전히 초기화 중일 수 있습니다.

배포가 Ready 상태가 되면, 성공할 때까지 플레이어 연결을 재시도하거나, 클라이언트의 사전 정의 타임아웃까지 기다리세요.

예기치 않은 서버 충돌이 발생하면 서버가 자동으로 재시작됩니다. 서버 상태가 손실될 수 있습니다.

4. 배포 오류

배포는 예기치 않은 이유로 언제든 Error 상태가 될 수 있습니다. 이는 통합 테스트 중이거나 새 서버 빌드를 테스트할 때 더 발생하기 쉽습니다.

Error 상태의 배포는 24시간 후 자동으로 중지되며 비용이 청구되지 않습니다.

트러블슈팅 단계:

  • 다음을 통해 Edgegap 서비스 상태 확인 가용성 모니터링 페이지.

  • Docker Desktop으로 로컬에서 서버 컨테이너를 테스트하여 Edgegap 이슈를 배제해 보세요.

도움이 필요하시면, Discord로 문의해 주세요. 라이브 게임 지원은 저희의 티켓 발급 시스템을 참조하세요.

도움을 요청할 때는, 배포 ID와 유용한 세부 정보를 포함 하여 신속히 조사할 수 있도록 해주세요!

5. 배포 중지됨

우리는 귀하의 지시 없이 서버를 절대 중지하지 않습니다플레이어 경험에 부정적 영향을 주지 않기 위해서입니다. 배포가 중지될 수 있는 이유:

  • 자체 중지(Self-Stop) - DELETE_URL - 플레이어가 떠나고 매치가 종료된 후 배포가 스스로 중지,

  • 백엔드에서 중지 - 귀하의 백엔드가 다음을 사용해 이 배포를 중지함 Deployments API,

  • 게임 최대 지속 시간 - 귀하의 앱 및 버전 에서 할당된 시간이 만료됨,

  • 프라이빗 플릿 배포를 실행 중인 호스트가 예약된 작업으로 삭제됨.

배포가 중지되면, 우리는 정상 종료를 트리거합니다 다음을 보내 SIGTERM 신호를 메인 프로세스에 전달하여 짧은 종료 기간을 허용합니다. 만료되면 SIGKILL 신호를 보내 배포를 중지합니다.

👀 가시성(Observability)

게임 서버가 서드파티와 상호운용하고 운영 인사이트를 얻을 수 있게 합니다.

발견 가능성

Ready 상태가 되면 배포에는 URL(fqdn)과 각 내부 포트에 대한 외부 포트가 할당됩니다.

사용 방법: 배포 태그를 사용해 배포를 쉽게 마킹 그리고 배포.

게임 서버에서 클라이언트나 백엔드로의 아웃바운드 트래픽은 절대 차단되거나 필터링되지 않습니다.

웹소켓(WS) 및 보안 웹소켓(WSS)

Edgegap에서 웹소켓 기반 넷코드를 사용하려면 두 가지 옵션이 있습니다:

  • 관리형 인증서코드 작성 없이 1분 만에 설정:

    • 다음을 구성하고 앱 및 버전 에서 웹소켓(WS)을 사용하고 TLS 업그레이드 활성화,

    • 클라이언트 연결에 Edgegap URL 사용(예: https://5fa53fa00a57.pr.edgegap.net/)

  • 자가 관리 인증서커스텀 도메인을 사용하려는 경우:

    • 다음을 구성하고 앱 및 버전 에서 보안 웹소켓(WSS) 사용,

    • 커스텀 DNS 레코드로 자체 TLS 인증서 플로우 구성(예: Cloudflare).

캐치되지 않은 서버 예외는 배포 컨테이너의 재시작을 유발하며 TLS 보안을 무효화합니다. 이 경우, 서버를 중지하고 그리고 플레이어를 새 배포로 재매칭. 서버 상태가 손실될 수 있습니다.

주입된 변수

게임 서버는 종종 서버 IP, 내부 포트 값 등의 추가 정보가 필요합니다. 읽기 전용 환경 변수를 주입하는 것은 파라미터를 전달하는 신뢰할 수 있는 클라우드 불가지론적 방법입니다.

변수 값을 얻는 방법: C#의 GetEnvironmentVariable 또는 C++의 GetEnvironmentVariable.

참고 앱 버전 변수 그리고 매치메이커 변수 아래의 배포 변수와 함께 사용됩니다.

커스텀 변수

배포마다 최대 20개의 커스텀 변수를 정의할 수 있으며, 각 변수는 최대 4KB의 문자열 데이터를 담을 수 있습니다.

예약된 이름(아래)을 사용하지 마세요. 그렇지 않으면 커스텀 변수가 덮어씌워집니다!

Edgegap이 서버에 주입한 변수를 읽어 중요한 정보에 접근하세요:

식별자

  • ARBITRIUM_REQUEST_ID - 예: f68e011bfb01 .

    • 고유한 배포 ID로, 요청 ID라고도 합니다. 더 많은 정보를 가져오는 데 사용됩니다.

    • 배포 URL의 형식은 항상 다음과 같습니다 {ARBITRIUM_REQUEST_ID}.pr.edgegap.net.

  • ARBITRIUM_HOST_ID - 예: alpha-north-america-70364ef8 .

    • 배포를 호스팅하는 머신의 고유 식별자이며, 다른 배포와 공유됩니다.

  • ARBITRIUM_PUBLIC_IP - 예: 162.254.141.66 .

    • 이 호스트의 퍼블릭 IP 주소로, URL 대신 연결에 사용할 수 있습니다.

  • ARBITRIUM_DEPLOYMENT_TAGS - 예: tag1,tag2 .

리소스 사양

  • ARBITRIUM_HOST_BASE_CLOCK_FREQUENCY - 예: 2000 프로세서 주파수(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 - 예: 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 (기본값)으로 가정합니다. 각 포트는 정제된 앱 및 버전 변수 세트를 추가로 제공합니다: @Super Port! ⇒ ARBITRIUM_PORT_SUPER_PORT_INTERNAL .

  • ARBITRIUM_BEACON_ENABLED - 예: true프라이빗 플릿에서 배포 중이면, 핑 비콘.

  • ARBITRIUM_HOST_BEACON_PUBLIC_IP - 예: 139.177.198.69 가장 가까운 비콘의 퍼블릭 IP.

  • ARBITRIUM_HOST_BEACON_PORT_UDP_EXTERNAL - 예: 30199UDP를 통한 핑 측정용.

  • ARBITRIUM_HOST_BEACON_PORT_TCP_EXTERNAL - 예: 30456TCP를 통한 핑 측정용.

구조화된 정보(JSON 문자열)

환경 변수는 문자열화된 JSON으로 저장되며SDK 또는 커스텀 방법으로 파싱하세요.

ARBITRIUM_DEPLOYMENT_LOCATION: - 배포 위치에 대한 상세 정보.
ARBITRIUM_PORTS_MAPPING: - 내부 및 외부 포트에 대한 상세 정보.

대시보드 모니터링

우리의 대시보드 서버 확장성을 모니터링하고 운영을 지원하는 유틸리티를 제공합니다.

분석

찾기 사이드바 메뉴에서 분석 대시보드를 찾으세요 카테고리 '서버 호스팅 및 오케스트레이션' 아래에 있습니다.

🌟 종량제(Pay as You Go) 등급으로 업그레이드 상세한 서버 성능 지표와 인사이트를 잠금 해제하려면:

  • 일반 인사이트: 버전별 실시간 서버 수와 리소스 사용 개요로 릴리스를 모니터링하세요,

  • CPU 인사이트: 프로세서 집약적 작업으로 인한 서버 지연 문제를 해결하세요,

  • 메모리 인사이트: 할당된 메모리를 초과하여 서버가 재시작되는 문제를 완화하세요,

  • 네트워킹 인사이트: 비효율적인 네트워킹 패턴을 감지하고 넷코드를 최적화하세요.

배포 지도

배포 지도는 다음에서 찾을 수 있습니다 대시보드의 배포 세부 정보 페이지에서.

지도에서 배포 위치, 사용 가능한 위치 및 예상 플레이어 위치를 미리 보기:

배포 균형 지점

배포 균형 지점 히트맵은 다음에서 찾을 수 있습니다 대시보드의 애플리케이션 세부 정보 페이지에서.

배포 균형 지점 히트맵을 미리 보고 다음으로 필터링하세요 앱 및 버전. 균형 지점은 주어진 배포에서 각 플레이어와 네트워크상으로 동등한 근접성을 갖는 대략적인 위치입니다:

그린란드와 같은 이상한 위치의 균형 지점 핫스팟은 서로 멀리 떨어진 플레이어들의 매치메이킹을 나타냅니다. 최적화 방법에 대해 알아보세요 배포 그리고 핑 비콘 매치메이킹을 최적화하기 위해.

배포 로그

배포 로그는 다음에서 찾을 수 있습니다 대시보드의 배포 세부 정보 페이지에서.

배포 로그는 다음에 대한 정보를 표시합니다 배포:

컨테이너 로그

컨테이너 로그는 다음에서 찾을 수 있습니다 대시보드의 배포 세부 정보 페이지에서.

문제 발생 시 또는 디버깅할 때 게임 서버의 로그를 검사하세요:

배포가 중지되면 컨테이너 로그는 삭제됩니다. 설정하기 타사 S3 로그 스토리지 로그를 저장하려면.

컨테이너 메트릭

컨테이너 메트릭은 다음에서 찾을 수 있습니다 대시보드의 배포 세부 정보 페이지에서.

컨테이너 메트릭(프로세서, 메모리, 네트워킹)을 검토하여:

  • 연결 문제의 일반적 원인을 식별하세요 when 배포,

  • 리소스 사용 급증을 일으키는 비효율적인 구현 패턴을 감지하세요,

  • 특정 시나리오에서 비효율적인 리소스 사용을 정확히 찾아내세요,

  • 최적화 중 서버의 리소스 사용 변화 여부를 확인하세요,

  • 서버 초기화의 리소스 소비와 소요 시간을 벤치마크하세요.

히스토리 메트릭은 1분 기간의 값 평균을 표시하며, 무료 등급에서 제공됩니다.

🌟 종량제(Pay as You Go) 등급으로 업그레이드 1초 간격의 정밀한 메트릭을 잠금 해제하려면.

문의하기 대규모 릴리스를 위해 라이브 호스팅 지원을 요청하려면 릴리스 이전에.

컨텍스트 및 상태

추가 배포 정보는 JSON 형식으로 가져올 수 있습니다:

컨텍스트 API(배포 내부에서는)에는 Context API 토큰이 필요하고, 상태 API는 Edgegap 토큰을 사용합니다.

Too Many Requests 429 - 당사는 조직에 대해 다음으로 속도 제한을 적용합니다 초당 10 요청 컨텍스트 및 상태 API 엔드포인트에 대해. 확장 가능한 솔루션에는 주입된 변수 그리고 웹후크 를 사용하세요.

배포 필터링

모든 배포 중에서 빠르게 검색하려면, 당신은 대시보드를 사용하세요:

또는 플레이어가 지속적(항상 온라인)인 서버를 선택하게 하세요 목록에서 서버 브라우저.

API로 배포 나열 백엔드 통합과 함께 필터를 적용하세요:

배포 속성
연산자
예시 값

상태

eq 또는 neq

"ready" 또는 "error"

request_id

eq

"7e709a0d8efd"

을 또는 nin

[ "7e709a0d8efd", "4ba353100b4b" ]

태그

eq 또는 neq

"tagA"

을 또는 nin

[ "tagA", "tagB" ]

생성일

eq 또는 lte 또는 gte

2025-05-12T20:03:20Z

애플리케이션

eq 또는 neq

"my-app"

을 또는 nin

[ "my-app", "my-other-app" ]

버전

eq 또는 neq

"1.0.0"

을 또는 nin

[ "1.0.0", "prod" ]

is_joinable_by_session

eq

true 또는 false

available_session_sockets

eq 또는 neq 또는

lt 또는 lte 또는

gt 또는 gte

5

각 속성은 단일 요청에서 최대 1개의 필터 연산자를 가질 수 있습니다. 자세한 내용은 API 참조 을 참조하세요.

요청에 나타나는 순서대로 여러 필드로 결과를 정렬하세요:

배포 속성
정렬 순서

생성일

asc 또는 desc

available_session_sockets

asc 또는 desc

예시 필터 쿼리:

목록 오류가 있는 배포 문제 해결 및 제거를 위해.

인코딩된 URL:

형식화된 JSON 쿼리:

목록 앱 버전이 오래된 배포 릴리스가 완료되었는지 확인하려면.

인코딩된 URL:

형식화된 JSON 쿼리:

목록 사용 가능한 세션 소켓 용량이 있는 배포 참여하려면.

인코딩된 URL:

형식화된 JSON 쿼리:

요청에 Edgegap API 토큰이 포함된 Authorization 헤더를 추가하는 것을 잊지 마세요.

웹후크 및 포스트백

배포가 Ready 또는 Error 상태일 때 간단한 HTTP 알림을 받아야 하는 경우, 웹후크 URL 을 지정할 수 있습니다 배포 API 요청에.

웹후크는 재시도되지 않습니다따라서 백엔드가 속도 제한이나 오류로 인해 요청을 처리하지 못하면 웹후크가 손실될 수 있습니다. 웹후크는 비중요 사용 사례 또는 디버깅 목적에만 사용하세요.

신뢰할 수 있는 배포 옵저버를 위해서는 지터드 지수적 재시도 또는 폴링을 구현하세요 배포 상태 API.

🚨 문제 해결

배포 문제를 해결할 때:

  1. 다음에서 오류가 없는지 확인하세요 배포 그리고 배포,

  2. 통합 버그를 배제하기 위해 로컬에서 서버를 실행하세요,

  3. 이 페이지의 문제 해결 단계를 검토하세요,

  4. 커뮤니티 디스코드에서 저희에게 문의하세요 커뮤니티 디스코드 그리고 배포 ID를 포함하세요.

참고 배포 플레이어 커뮤니티 피드백을 처리하는 권장 사항은 다음을 참조하세요.

클라이언트가 서버에 연결할 수 없음 - 요청 시간이 초과되었습니다., 요청 시간 초과 , 연결 실패 , 또는 포트 확인 실패.
서버 프로세스가 예외로 인해 충돌한 경우, 시스템이 자동으로 서버를 재시작하려 시도합니다. 근본 원인을 찾기 위해 로컬에서 서버를 테스트하는 것을 고려하세요.

  • 로그는 배포 기간 동안만 보관되므로, 배포 중지 후 로그를 검사하려면

  • 타사 로그 스토리지를 통합하세요 중단 원인을 모두 발견하기 위해..

  • 참고 배포 내 배포가 X분 후 자동으로 중지되었습니다.

무료 등급 배포에는 60분 시간 제한이 있으니 계정 업그레이드를 고려하세요.
내 배포는 Ready 상태인데도 그 후 몇 분 동안 연결할 수 없습니다.

  • 배포가 Ready가 되면 게임 엔진 초기화가 시작됩니다. 이 과정은 수초에서 수분이 걸릴 수 있으며, 이 기간 동안 서버는 플레이어 연결을 수락하지 않습니다.

  • 이 시간을 줄이기 위해 서버 초기화를 최적화하는 것을 고려하세요.

  • 게임 클라이언트는 제한된 시간 동안(초기화 기간에 따라) 1초 간격으로 연결을 재시도한 후 매치메이킹으로 돌아가야 합니다.

  • 로딩 씬을 추가하여 서버가 초기화(언리얼 엔진의 경우 이동 포함)를 클라이언트와 동시에 수행하면서 양측의 상태를 동기화하도록 고려하세요.

내 Meta Quest 기기에서 다음 오류가 발생합니다 HTTP 0: 대상 호스트를 확인할 수 없습니다 .

  • 안드로이드 대상용으로 Unity 앱을 빌드할 때 인터넷 액세스 권한이 출력 APK 클라이언트 빌드 산출물에서 자동으로 제거될 수 있습니다.

  • 권한을 다시 추가하세요(그 후 클라이언트 재빌드 필요):

    • 프로젝트 설정 / OpenXR / ⚙️ Meta Quest 지원 / 인터넷 권한 강제 제거(체크 해제).

    • 플레이어 설정 / 인터넷 액세스(필수로 설정).

플레이어가 내 배포를 떠나면 어떤 일이 발생하나요?

  • 기본적으로 서버는 플레이어 연결을 거부하지 않습니다. 인증은 다양한 방법과 제공자가 있으므로 개발자가 처리해야 합니다.

  • 게임 클라이언트는 예기치 않은 클라이언트 충돌 시 재접속을 시도하기 위해 연결 정보를 로컬에 저장할 수 있습니다.

  • 진행 중인 게임에 플레이어가 합류하도록 허용하려면, 다음을 고려하세요 심층 분석 또는 세션.

내 서버가 Ready 상태가 된 후 CPU 사용률이 100%로 표시됩니다.

  • 게임 엔진은 서버 초기화 동안 CPU 집약적 작업을 수행하는 경향이 있으므로 이것이 문제이 아닐 수 있습니다. 배포 시작 후 2-3분 이내에 CPU 사용률이 떨어지지 않으면 서버를 최적화하거나 앱 버전 리소스를 늘려야 할 수 있습니다.

  • 틱 속도를 줄이면 서버가 메시징 작업을 덜 수행하므로 CPU 사용량에 영향을 줄 수 있습니다.

  • 로그에서 검사하세요. Mirror 넷코드를 사용 중이라면 "자동 서버 시작(Auto Start Server)" 을 선택해야 합니다 NetworkManager

  • , 재빌드하고 푸시한 다음 서버를 다시 배포하세요. FishNet 넷코드를 사용 중이라면 을 지정할 수 있습니다 “헤드리스에서 시작(Start on Headless)”을 활성화해야 합니다NetworkManager

  • 무료 등급에서는 1.5 vCPU 및 3GB 메모리(RAM)로 제한됩니다.

  • 새 앱 버전을 생성할 때 할당된 리소스를 늘릴 수 있습니다. 대시보드에서 앱 버전을 복제하고 재빌드 없이 필요한 값을 조정하세요.

내 배포가 반복적으로 재시작되며 `OOM kill` 오류를 표시합니다.

  • 이 동작은 할당된 메모리 양을 초과했기 때문에 발생합니다. 객체 풀링, 압축 또는 불필요한 씬 객체 제거로 메모리 사용을 최적화하세요.

  • 프로젝트가 기본 씬이 포함된 을 선택해야 합니다 을(를) 로드하고 해당 씬이 Unity의 빌드 설정에 포함되어 있는지 확인하세요.

  • 무료 등급에서는 1.5 vCPU 및 3GB 메모리(RAM)로 제한됩니다.

  • 새 앱 버전을 생성할 때 할당된 리소스를 늘릴 수 있습니다. 대시보드에서 앱 버전을 복제하고 재빌드 없이 필요한 값을 조정하세요.

가끔 서버의 메모리(RAM) 사용량이 급증하는데, 문제가 되나요?

  • 앱 버전에 할당된 메모리 양 내에 있는 한 이는 문제가 되지 않습니다.

  • 할당된 앱 버전 메모리 양을 초과하면 `OOM kill`이 발생합니다(위 참조).

동일한 머신에서 실행 중인 다른 서버들로 인해 내 서버 성능에 영향이 있나요?

  • 아니요, 당사 플랫폼은 할당된 리소스가 다른 스튜디오나 공유 인프라의 다른 서버에 의해 사용되지 않도록 보장합니다. Edgegap과 함께라면 소음 이웃(noisy neighbors)이 없습니다.

Previous앱 및 버전Next지속성

Last updated

Was this helpful?