배포
배포와 그 수명 주기에 대해 알아보세요 - 더 깊은 이해를 위한 개념과 모범 사례입니다.
🗺️ 오케스트레이션
클라우드 네이티브 엣지 컴퓨팅 접근 방식을 통해 용량 수요를 충족하기 위해 몇 초 안에 새 서버를 시작하세요. 저희는 서버를 애완동물이 아니라 가축으로 취급합니다 - 고장 난 인스턴스를 각각 수동으로 돌보기보다 전체를 교체합니다.
오케스트레이션 선택은 DevOps 비용, 서버 비용, 그리고 확장성에 영향을 미칩니다.
Discord로 문의하여 하이브리드 오케스트레이션 옵션과 호스팅 비용 최적화에 대해 알아보세요.
모든 장단점을 완전히 이해하려면 다양한 오케스트레이션 방식을 비교해봅시다.
매치 바운드
다음을 제공하는 현대 스튜디오를 위한 최고의 비용 효율성과 가장 쉬운 통합을 제공하는 골든 스탠다드.
👍 장점
최고의 비용 효율성 - 플레이어 수요에 맞춰 분 단위로 실시간 확장합니다.
리전이 없는 호스팅으로 DevOps 비용이 가장 낮으며, Edgegap이 작업의 99%를 자동화합니다.
Edgegap의 퍼블릭 클라우드 인프라에 있는 615개 이상의 사이트 덕분에 가장 낮은 핑을 제공합니다.
예상치 못한 트래픽 급증 시 가장 빠른 확장(버스트 대응력)을 제공합니다.
최고 수준의 보안과 플레이어 치트 방지(서버 권한)를 제공합니다.
예상치 못한 서버 장애가 플레이어에게 미치는 영향이 최소화되며, 단일 매치에만 영향을 줍니다.
👎 단점
새로운 오케스트레이션 사고방식을 도입하려면 초기에 어느 정도 적응 노력이 필요합니다.
24시간 이상 실행되는 서버는 자동으로 종료됩니다.
🧩 가장 적합한 경우
지연 시간에 민감한 게임 - 넷코드 최적화로도 높은 핑을 극복할 수 없을 때:
FPS, 대전 격투 게임, VR 및 XR(가상 및 확장 현실), …
게임 설계상 매치 지속 시간의 상한이 있는 게임,
배틀 로얄, PvPvE, 협동 슈터, MOBA, 스포츠 게임, ARPG 및 던전 크롤러, …
🔎 발견 가능성
충분한 플레이어가 참가하면 새 게임을 시작 매치메이킹.
다음에 플레이어 추가 백필로 기존 매치에서 나간 플레이어를 대체.
플레이어가 서버를 탐색하고 목록에서 선택하도록 허용 서버 브라우저.
Edgegap은 각 리전의 플레이어 활동에 따라 615개 이상의 모든 서버 위치를 자동으로 확장/축소합니다. 성공에 대비하세요 - 매끄럽게 60분 안에 동시 사용자 1,400만 명까지 확장.
리전 대기
다음을 위한 전통적인 모델 사용자 생성 콘텐츠와 소셜 MMO 게임이 있는 지속형 월드.
👍 장점
익숙하고 이해하기 쉬운, 실전 경험이 많은 베테랑들을 위한 올드스쿨 접근 방식입니다.
최고 수준의 보안과 플레이어 치트 방지(서버 권한)를 제공합니다.
월별 약정을 기준으로 비용을 쉽게 예측할 수 있습니다.
👎 단점
호스팅 비용이 더 높음 - 각 리전마다 하나 이상의 유휴 대기 서버(버스트 용량)가 필요합니다.
DevOps 비용이 더 높음 - 확장, 운영 및 유지 관리가 리전별로 중복됩니다.
플레이어 기반이 작은 리전은 멀리 있는 서버에 접속하게 되어 높은 핑을 경험합니다.
🧩 가장 적합한 경우
플레이어가 오프라인이더라도 서버에 사용자 생성 콘텐츠가 저장되는 지속형 월드.
MMO, 기지 건설 또는 오브젝트 배치가 있는 샌드박스, 익스트랙션 슈터, ...
지연 허용형 게임 - 서버 권한 기반 실시간 물리가 필요하지 않을 때:
모바일 게임, 협동 게임, TCG/CCG, 턴제 전략 게임, …
비동기 멀티플레이어, 서버 장애가 플레이어 경험에 미치는 영향이 최소인 경우:
고스트와 레이스, 적 기지 약탈, 타이머 기반 건설/농장 게임, …
초기화 과정이 무거운 애플리케이션 - 서버 준비에 몇 분이 걸릴 때.
🔎 발견 가능성
플레이어가 서버를 탐색하고 목록에서 선택하도록 허용 서버 브라우저.
보기 관리형 클러스터 용 마이크로서비스와 백엔드 서비스를 자체 호스팅하기 Edgegap에서.
P2P
개발 노력을 전용 서버 에서 비경쟁 게임을 위한 릴레이 넷코드로 전환.
관련 주제: 리슨 서버, 플레이어 호스트 권한, NAT 펀치스루.
👍 장점
가장 낮은 호스팅 비용 - NAT 펀치스루 해결을 위해 릴레이 서버만 필요합니다.
가장 낮은 DevOps 비용 - 클라이언트 빌드와 배포 채널만 유지 관리하면 됩니다.
예상치 못한 서버 장애가 플레이어에게 미치는 영향이 최소화되며, 단일 매치에만 영향을 줍니다.
백엔드 개발 없이도 구현이 쉽고 프로토타입 제작까지 빠릅니다.
👎 단점
동시성 프로그래밍 기술이 필요한 P2P 넷코드 개발 노력이 증가합니다.
가장 나쁜 핑 시간과 불리한 네트워크 상태(예: 모바일 인터넷)에 가장 민감합니다.
보안이 가장 취약하며, 중간자 공격과 세션 하이재킹에 취약합니다.
커스텀 호스트 마이그레이션을 구현하지 않으면 호스트가 나갈 때 세션이 끊길 위험이 있습니다.
🧩 가장 적합한 경우
협동 및 캐주얼 게임 - 치팅이 재미를 해치거나 게임을 망치지 않을 때,
어린이 게임, 탐험 게임, 어드벤처, …
🔎 발견 가능성
저희의 분산 릴레이 서비스를 확인해 보세요. 동급 최고 수준의 지연 시간과 보안으로 P2P를 가능하게 합니다.
📍 서버 배치
어떤 오케스트레이션 방식을 선택하든, 플레이어 그룹에 맞는 올바른 서버 위치를 선택하는 것은 최상의 핑과 최적의 플레이어 경험을 보장하는 데 매우 중요합니다. 서버 배치를 위한 다양한 전략과 그것이 플레이어에게 미치는 영향을 알아보세요.
서버 배치 전략은 플레이어 경험, 유지율, 그리고 게임 리뷰에 영향을 미칩니다.
Edgegap은 가능한 최적의 위치에 가용 용량과 함께배포하여 빠르고 지연 시간이 낮은 매치를 제공합니다.
보기 배포 에서 실시간으로 서버 배치를 분석합니다, 대규모로.
서버 점수
서버 점수 전략은 Edgegap의 특허받은 방법론을 사용하며, 이는 각 매치별로 서버 배치를 개별적으로 최적화합니다. 비침습적 텔레메트리를 수행하여 각 플레이어의 네트워크 근접도를 서버 위치와 비교 추정하고 다음을 가장 잘 제공하는 서버를 선택합니다:
응답성 - 모든 플레이어에게 평균적으로 가장 낮은 핑을 제공합니다,
공정성 - 모든 플레이어에게 균형 잡히고 공정한 핑을 제공합니다.
응답성이 낮은 배치 - 서버가 멀리 있어 모든 플레이어의 핑이 높음:
불공정한 배치 - 핑이 고르지 않아 한 플레이어가 불리함:
좋은 배치 예시 - 모든 플레이어에게 응답성이 좋고 공정한 핑:
이 전략은 서로 멀리 떨어져 있는 플레이어 그룹을 호스팅할 때 특히 효과적입니다 (북미 대 유럽, 또는 서해안 대 동해안), 이는 사전 구성 로비에서 자주 발생합니다.
지오로케이션
대안으로, 자동화된 텔레메트리를 활용하는 대신 플레이어의 위도 및 경도 좌표 또는 선호 서버 위치의 좌표를 제공하세요 이 접근 방식은 추가적인 클라이언트 측 지오 룩업 구현이 필요하며, 전적으로 게임 개발자의 솔루션에 의존합니다.
지오로케이션 전략은 다음에는 권장되지 않습니다 배포 오케스트레이션에는, 지역 간 데이터 전송에 대한 엄격한 규제 요구 사항이 있거나 플레이어 IP를 사용할 수 없는 애플리케이션을 제외하고.
이 전략을 배포 API와와 함께 사용하려면 배포 요청에 플레이어의 공인 IP 또는 지리 좌표를 나열하세요.
리전 잠금
서버는 대략적으로 일반화된 리전 매개변수를 사용해 배치될 수 있으며, 방법은 다음 중 하나입니다:
플레이어의 메타데이터(플레이어 계정 데이터베이스)를 기반으로 자동 선택되거나,
매치메이킹 중 플레이어가 직접 선택하여 높은 클라이언트-서버 지연이 발생할 수 있습니다.
이 전략만 단독으로 사용하는 것은 네트워크 성능 저하를 초래할 수 있으므로 권장되지 않습니다.
사용 다른 전략과 함께 사전 필터로서의 리전 선택 이 더 나은 대안입니다.
🟢 연결 품질
일부 게임(및 일부 플레이어)은 다른 게임보다 지연 시간이나 랙에 더 민감합니다. 플레이어 보고는 대규모 사고나 회귀 버그를 나타내는 훌륭한 지표이지만, 플레이어는 네트워킹 개념에 대한 깊은 이해가 부족할 수 있으며 빠르게 스튜디오, 넷코드 또는 서버를 탓하곤 합니다.
일부 문제의 근본 원인은 플레이어에게 보이지 않을 수 있으므로, 스튜디오와 호스팅 제공업체의 협력이 중요할 수 있습니다. Edgegap의 우선순위는 항상 가능한 최고의 서비스를 제공하는 것입니다.
플레이어 보고가 다수 접수되거나, 광범위한 장애를 겪고 있거나, 반복적인 문제가 있다면 플랫폼의 지원 티켓을 통해 즉시 문의해 주세요.
낮은 지연 시간
플레이어 지연 시간은 다음 사이에서 데이터를 전송할 때 발생하는 지연 시간의 조합입니다:
물리적 장치 - 물리적 신호가 인터넷 네트워크 토폴로지,
호스트 대 호스트 를 가로질러 이동하며 발생 - 프로토콜, 전송 및 보안 조치로 인해 발생,
프로세스 대 프로세스 - 클라이언트/서버에서 데이터의 (언)박싱 및 처리로 인해 발생.
Edgegap은 서버를 플레이어에 더 가깝게 배치하여 응답 시간을 줄이고 네트워크 홉 수를 낮춤으로써 물리적 지연을 줄입니다. 17개 클라우드 및 베어메탈 제공업체 전반에 걸친 위치를 통해, 여러분은 전 세계 어디서나 플레이어를 위한 동급 최고 수준의 핑.
을 얻을 수 있습니다. 전 세계의 서버 및 인터넷 커버리지(Edgegap뿐만 아니라)는 다음과 같은 요인으로 인해 제한됩니다:
인프라 가용성 - 특정 지역의 인터넷 연결 품질이 충분하지 않을 수 있음,
자연적 요인 - 매우 복잡한 서버 랙은 대체로 안정적인 환경을 필요로 합니다.
고가용성
전 세계 여러 위치에서의 서버 가용성은 시간에 따라 달라지며, 하루 동안 여러 차례 변동합니다. Edgegap은 자동으로 확장/축소 위치를 수요에 따라하며, 다음을 고려합니다:
버스트 트래픽 - 15분 기간 내에 이루어진 배포,
vCPU 요구 사항 - 배포당 더 많은 vCPU는 특정 위치에 대한 전체 수요를 증가시킴,
제공업체 제공 범위 - 일부 원격 위치는 사용 가능한 제공업체 옵션이 더 적음,
머신 가용성 - 일부 위치는 4 vCPU 또는 8 vCPU 머신만 제공할 수 있음,
스튜디오 요청 - 테스트, 품질 보증, 얼리 액세스, 클로즈드 베타 또는 토너먼트를 위한 요청.
모든 애플리케이션의 배포 요청은 위치 수요를 평가하기 위해 함께 집계됩니다. 모든 조직은 기본적으로 동일한 할당 우선순위를 가지며, 특정 하드웨어나 위치가 필요한 엔터프라이즈 고객을 위해 프라이빗 서버 풀을 추가할 가능성.
이 있습니다. 부디 릴리스 계획을 위해 문의해 주세요, 또는 위치 가용성과 관련된 요청이 있다면 문의해 주세요.
플레이어 문제 해결
플레이어 문제는 서버 버그나 제공업체 사고에서 비롯될 수 있지만, 로컬 ISP, 게임 서비스, 저수준 라이브러리의 버그, 인프라 제공업체 또는 기타 원인과 같은 제3자로부터 발생할 수도 있습니다.
플레이어 보고나 사고를 문제 해결할 때는 다음 요소를 고려하세요:
지역 문제:
현지 인터넷 서비스 제공업체(ISP)가 일시적으로 사고를 해결 중일 수 있음,
일부 지역(예: 중국, 러시아)은 지역별 제재로 인해 제한될 수 있음,
캐싱 수준 - Edgegap은 캐시된 위치에서 빠른 배포를 우선시합니다:
최대 배포 시간 - 느리고 무거운 초기화 과정으로 인해 배포가 실패할 수 있음:
보기 앱 및 버전 타임아웃 기간을 늘리려면,
초기화 단계를 반드시 필요할 때까지 지연하세요,
서버 이미지 또는 통합 문제.
클라이언트 매치 기록 UI에 배포 ID 표시 하여 문제 해결 시 플레이어 보고를 추적하세요.
부정적인 반응을 완화하기 위해 광범위한 버그, 일시적 문제 및 장애를 사용자에게 알리세요.
🔄 배포 수명 주기
Edgegap 배포는 배포 상태로 표시되는 여러 수명 주기 단계를 거칩니다.
1. 배포 시작
다음을 위한 배포는 테스트 목적 으로 다음을 통해 시작할 수 있습니다:
Unreal Engine - Unreal Engine 프로젝트용 Docker Extension 또는 플러그인,
Unity - Unity 프로젝트용 플러그인,
대시보드 웹 UI - 서버 통합 테스트를 위한 사용하기 쉬운 웹 인터페이스.
다음을 위한 배포는 실제 프로덕션 환경 은 다음으로 시작해야 합니다:
배포 API - 서버 간 맞춤형 통합(커스텀 스케일링).
저장 request_id (배포 ID) 및 배포 태그 지정 나중에 문제를 식별하고 해결하기 위해.
다음으로 테스트할 때 배포 API, 기본 Dockerfile의 CMD 를 커스텀 명령으로 재정의할 수 있습니다.
2. 배포 중
배포가 시작되면, 저희 시스템은 빠른 연속으로 여러 단계를 수행합니다:
텔레메트리 - 사용 가능한 데이터 센터에서 각 플레이어까지의 네트워크 응답성을 측정합니다,
배포 - 용량을 예약하고 서버 컨테이너 시작을 준비합니다,
컨테이너 부팅 - 컨테이너를 시작하고, 종속성을 설치하고, 초기화합니다,
후처리 - 로그 저장소, 모니터링을 추가하고 배포를 마무리합니다.
요청 과다 429 - 안정성을 보장하고 예상치 못한 청구서를 방지하기 위해 조직당 초당 40요청. 으로 속도 제한합니다. 문의해 주세요 릴리스 계획, 출시 트래픽 추정, 성공적인 준비를 위해.
3. 배포 준비 완료
컨테이너가 완전히 초기화되었고 서버가 지금 시작 중입니다. 몇 초에서 1분 정도 동안 서버는 여전히 초기화 중일 수 있으며, 게임 엔진(또는 커스텀 런타임)이 플레이어 연결을 받을 준비가 완전히 되기 전까지는 플레이어 요청에 응답하지 않을 수 있습니다.
배포가 Ready 상태가 되면, 성공할 때까지 플레이어 연결을 재시도하세요, 또는 사전 정의된 클라이언트 타임아웃까지.
4. 배포 오류
배포는 예기치 않은 이유로 언제든지 Error 상태가 될 수 있습니다. 이는 통합을 테스트하거나 새로운 서버 빌드를 테스트하는 동안 더 자주 발생할 수 있습니다.
Error 상태의 배포에는 요금이 청구되지 않으며, 24시간 후 자동으로 중지됩니다.
문제 해결 단계:
다음으로 Edgegap 서비스 상태를 확인하세요 저희 업타임 모니터링 페이지.
Edgegap 문제를 배제하기 위해 Docker Desktop으로 서버 컨테이너를 로컬에서 테스트해 보세요.
도움을 요청할 때는, 배포 ID와 유용한 세부 정보를 포함해 주세요 그래야 저희가 신속히 조사할 수 있습니다!
5. 배포 중지됨
저희는 귀하의 지시 없이는 절대 서버를 중지하지 않습니다, 플레이어 경험에 부정적인 영향을 주지 않기 위해서입니다. 배포는 다음 이유로 중지될 수 있습니다:
다음을 통한 자체 중지 DELETE_URL - 플레이어가 떠나고 매치가 종료된 후 배포가 자체적으로 중지됨,
보기 Unreal Engine 및 Unity 배포를 올바르게 중지하기 위한 가이드,
백엔드에서 중지 - 백엔드가 배포 API를 사용해,
게임 최대 지속 시간 - 귀하의 앱 및 버전 에 할당된 시간이 만료됨,
프라이빗 플릿 배포를 실행 중이던 호스트가 예약된 작업을 통해 삭제되었습니다.
배포가 중지되면, 저희는 정상 종료를 트리거합니다 다음을 전송하여 SIGTERM 신호를 메인 프로세스에 보내 짧은 종료 시간을 허용합니다. 시간이 만료되면 SIGKILL 신호가 전송되어 배포를 중지합니다.
👀 관측 가능성
게임 서버가 제3자와 상호 운용되고 운영 인사이트를 얻을 수 있도록 하세요.
발견 가능성
Ready 상태가 되면 배포에는 URL (fqdn) 과 각 내부 포트에 대한 외부 포트가 할당됩니다.
사용 배포 태그를 사용해 배포를 쉽게 표시하세요 및 배포.
게임 서버에서 나가는 아웃바운드 트래픽(클라이언트 또는 백엔드로)은 절대 차단되지 않으며 필터링되지도 않습니다.
웹소켓(WS) 및 보안 웹소켓(WSS)
Edgegap에서 웹소켓 기반 넷코드를 사용하려면 두 가지 옵션이 있습니다:
관리형 인증서, 코드 작성 없이 1분 안에 설정 가능:
다음을 구성하세요 앱 및 버전 에서 Websocket(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이며 request 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- 예: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.배포에서 호출 가능, 배포가 정상적으로 중지됩니다.
고유한 1회용
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 (기본값)로 지정했다고 가정합니다. 각 포트는 추가적인 정제된 앱 및 버전 변수 @Super Port! ⇒ 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 문자열)
환경 변수는 문자열화된 JSON으로 저장됩니다, SDK 또는 커스텀 방식으로 파싱하세요.
대시보드 모니터링
저희 대시보드 는 서버 확장성을 모니터링하고 운영을 지원하는 유틸리티를 제공합니다.
분석
찾기 사이드바 메뉴에서 분석 대시보드를 서버 호스팅 및 오케스트레이션 카테고리 아래에서 찾으세요.
🌟 사용량에 따라 지불 요금제로 업그레이드하여 자세한 서버 성능 지표와 인사이트를 확인하세요:
일반 인사이트: 버전별 실시간 서버 수 + 리소스 사용량 개요로 릴리스를 모니터링,
CPU 인사이트: 처리량이 많은 작업으로 인해 지연되는 서버를 문제 해결,
메모리 인사이트: 할당된 메모리 초과로 인한 서버 재시작을 완화,
네트워킹 인사이트: 비효율적인 네트워크 패턴을 감지하고 넷코드를 최적화하세요.
배포 지도
배포 지도를 대시보드의 배포 상세 페이지에서 찾으세요.
지도에서 배포 위치, 사용 가능한 위치, 예상 플레이어 위치를 미리 볼 수 있습니다:
배포 균형 지점
배포 균형 지점 히트맵을 대시보드의 애플리케이션 상세 페이지에서 찾으세요.
배포 균형 지점 히트맵을 미리 보고 다음 항목별로 필터링하세요 앱 및 버전. 균형 지점은 주어진 배포에서 각 플레이어와 네트워크상 근접성이 동일한 대략적 위치입니다:
배포 로그
배포 로그를 대시보드의 배포 상세 페이지에서 찾으세요.
배포 로그에는 다음에 대한 정보가 표시됩니다 배포:
컨테이너 로그
컨테이너 로그를 대시보드의 배포 상세 페이지에서 찾으세요.
문제 발생 시 또는 디버깅할 때 게임 서버의 로그를 확인하세요:
배포가 중지되면 컨테이너 로그는 삭제됩니다. 설정하세요 타사 S3 로그 저장소를 로그를 저장하려면.
컨테이너 메트릭
컨테이너 메트릭을 대시보드의 배포 상세 페이지에서 찾으세요.
컨테이너 메트릭(프로세서, 메모리, 네트워킹)을 검토하여 다음을 수행하세요:
다음과 같은 일반적인 연결 문제를 식별 배포,
리소스 사용량 급증을 유발하는 비효율적인 구현 패턴을 감지,
특정 시나리오에서 비효율적인 리소스 사용을 정확히 파악,
최적화 중 서버의 리소스 사용량 변화를 검증,
서버 초기화 시 리소스 소비와 지속 시간을 벤치마크.
히스토리 메트릭은 Free 요금제에서 제공되며, 1분 간격의 평균 값을 표시합니다.
🌟 사용량에 따라 지불 요금제로 업그레이드하여 1초 간격의 정밀한 메트릭을 사용하려면 업그레이드하세요.
으로 속도 제한합니다. 문의해 주세요 대규모 릴리스를 위한 실시간 호스팅 지원을 요청하려면 릴리스 전에
컨텍스트 및 상태
추가 배포 정보는 JSON 형식으로 가져올 수 있습니다:
배포 내부(게임 서버)에서, 다음을 사용하여 배포 컨텍스트 API,
배포 외부(백엔드 / 타사)에서, 다음을 사용하여 배포 상태 API.
컨텍스트 API(배포 내부에서)는 컨텍스트 API 토큰이 필요하고, 상태 API는 Edgegap 토큰을 사용합니다.
배포 필터링
모든 배포 중에서 빠르게 검색하려면 대시보드를 사용할 수 있습니다:
API로 배포 목록을 조회하고 백엔드 통합을 통해 필터를 적용하세요:
이 또는 nin
[ "7e709a0d8efd", "4ba353100b4b" ]
이 또는 nin
[ "tagA", "tagB" ]
이 또는 nin
[ "my-app", "my-other-app" ]
이 또는 nin
[ "1.0.0", "prod" ]
각 속성은 단일 요청에서 최대 1개의 필터 연산자만 가질 수 있습니다. 자세한 내용은 API 참조 을 참조하세요.
요청에 나타나는 순서대로 여러 필드로 결과를 정렬하세요:
asc 또는 desc
asc 또는 desc
예시 필터 쿼리:
목록 오류 상태의 배포 를 문제 해결하고 제거하세요.
인코딩된 URL:
서식이 지정된 JSON 쿼리:
목록 오래된 앱 버전을 사용하는 배포 릴리스 완료를 확인하려면.
인코딩된 URL:
서식이 지정된 JSON 쿼리:
다음을 추가하는 것을 잊지 마세요 Authorization 요청에 Edgegap API 토큰이 포함된 헤더를.
웹훅 및 포스트백
다음의 변경 사항에 대한 간단한 HTTP 알림을 게임 백엔드에서 수신하세요 배포 웹훅 URL을 다음에 지정하여 배포 API 요청. 다음에서 사용 가능:
준비 완료 시: 배포 컨테이너 성공적으로 시작됨 (이후 서버 초기화가 시작됩니다),
오류 시: 배포를 시작할 수 없었고 배포 오류가 발생했습니다,
종료 시: 배포 그리고 게임 서버에 더 이상 연결할 수 없습니다.
Ready 및 Error 웹훅은 동일한 배포에 대해 결코 트리거되지 않습니다.
웹훅은 재시도되지않으므로, 백엔드가 속도 제한이나 오류로 인해 요청을 처리하지 못하면 웹훅이 손실될 수 있습니다. 웹훅은 다음과 같은 경우에만 사용하세요 비핵심 사용 사례 또는 디버깅 목적.
웹훅은 배포 수명 주기를 관찰하지만, 씬/레벨 초기화 상태는 인식하지 못합니다. 씬/레벨의 로딩 진행 상황을 관찰하려면 게임 서버에 사용자 지정 웹훅을 구현하세요.
🚨 문제 해결
배포 문제를 해결할 때:
통합 버그를 배제하기 위해 서버를 로컬에서 실행하세요,
이 페이지의 문제 해결 단계를 검토하세요,
다음에서 문의하세요 커뮤니티 디스코드 배포 ID를 포함하세요.
보기 배포 플레이어 커뮤니티 피드백을 다루는 방법에 대한 권장 사항은 다음을 참고하세요.
클라이언트를 서버에 연결할 수 없음 - 요청 시간 초과., 요청 시간 초과 , ConnectionFailed 또는 포트 검증 실패.
먼저 배포가 Ready 상태인지, 그리고 배포 로그에 런타임 예외나 오류가 없는지 확인하세요. 배포가 중지되었다면, 다음 위치의 로그를 확인하세요 대시보드.
Mirror 넷코드를 사용 중이라면 다음을 설정해야 합니다 "Auto Start Server” 다음에서 선택된 상태로
NetworkManager그런 다음 다시 빌드, 푸시, 재배포하세요.FishNet 넷코드를 사용 중이라면 다음을 활성화해야 합니다 “Start on Headless” 다음에서
ServerManager그런 다음 다시 빌드, 푸시, 재배포하세요.Photon Fusion 2 넷코드를 사용 중이라면, 서버가 배포의 공용 IP, 외부 포트 및 다음 값을 전달하는지 확인하세요
roomCode서버에서, 그리고 클라이언트에서도 같은 room code를 다음에서 사용하세요 “NeworkRunner.StartGame” 매개변수StartGameArgs. 배포 ID(예:b63e6003b19f)는 전역적으로 고유하고 클라이언트가 다음을 통해 쉽게 접근할 수 있으므로 좋은 선택입니다 매치메이커는 할당 및 심층 살펴보기.게임 클라이언트가 다음에 연결하고 있는지 확인하세요 외부 포트 배포 상세 페이지에 표시된 이 값은 보안상의 이유로 항상 무작위로 지정됩니다.
넷코드 통합에서 Secure Websocket(WSS) 프로토콜을 사용하는 경우, 앱 버전 WSS 포트의 포트 구성에서 TLS 업그레이드가 활성화되어 있는지 확인하세요.
중국에 있으며 다음을 사용하고 있나요 스마트 플릿? Great Firewall 때문에 연결이 차단될 수 있습니다. 플릿에 중국에 위치한 서버를 추가하거나, VPN을 사용하여 연결하는 것을 고려하세요.
내 배포가 중지/재시작되었고 더 이상 로그에 접근할 수 없습니다.
예외로 인해 서버 프로세스가 충돌하는 경우, 시스템은 서버를 자동으로 재시작하려 시도합니다. 근본 원인을 찾기 위해 서버를 로컬에서 테스트해 보세요.
로그는 배포 기간 동안만 보관되므로, 배포가 중지된 후 로그를 확인하려면 타사 로그 저장소를 통합하세요.
보기 배포 배포가 중지되는 모든 원인을 발견하세요.
내 배포는 준비 완료 상태이지만 그 후 몇 분 동안 연결할 수 없습니다.
배포가 Ready 상태가 되면 게임 엔진 초기화가 시작됩니다. 이 과정은 몇 초에서 몇 분까지 걸릴 수 있으며, 이 기간 동안 서버는 플레이어 연결을 수락하지 않습니다.
이 시간을 줄이기 위해 서버 초기화를 최적화하는 것을 고려하세요.
게임 클라이언트는 제한된 시간 동안 1초 간격으로 연결을 재시도해야 하며(초기화 시간에 따라 다름), 그 후 다시 매치메이킹으로 돌아갑니다.
로딩 씬을 추가하여 서버가 클라이언트와 동시에 초기화(언리얼 엔진의 경우 이동 포함)를 수행하면서 두 상태를 동기화할 수 있도록 고려하세요.
내 Meta Quest 기기에서 다음 오류가 발생합니다 HTTP 0: 대상 호스트를 해석할 수 없음 .
Android 대상으로 Unity 앱을 빌드할 때, 인터넷 액세스 권한이 출력 APK 클라이언트 빌드 아티팩트에서 자동으로 제거될 수 있습니다.
권한을 다시 추가하세요(이후 클라이언트를 다시 빌드해야 함):
프로젝트 설정 / OpenXR / ⚙️ Meta Quest 지원 / 인터넷 권한 강제 제거(체크 해제).
플레이어 설정 / 인터넷 액세스(필요로 설정).
내 서버는 준비 완료가 된 후 CPU 사용률이 100%로 표시됩니다.
게임 엔진은 서버 초기화 중에 CPU를 많이 사용하는 작업을 수행하는 경향이 있으므로, 이는 문제가 아닐 수 있습니다. 배포 시작 후 2~3분이 지나도 CPU 사용량이 감소하지 않으면 서버를 최적화하거나 앱 버전 리소스를 늘려야 할 수 있습니다.
틱 속도를 줄이면 서버가 수행하는 메시징 작업이 줄어들어 CPU 사용량에 영향을 줄 수 있습니다.
Mirror 넷코드를 사용 중이라면 다음을 설정해야 합니다 "Auto Start Server” 다음에서 선택된 상태로
NetworkManager그런 다음 다시 빌드, 푸시, 재배포하세요.FishNet 넷코드를 사용 중이라면 다음을 활성화해야 합니다 “Start on Headless” 다음에서
ServerManager그런 다음 다시 빌드, 푸시, 재배포하세요.Free Tier에서는 1.5 vCPU와 3GB 메모리(RAM)로 제한됩니다.
새 앱 버전을 만들 때 할당된 리소스를 늘릴 수 있습니다. 서버나 이미지를 다시 빌드하지 않고도 대시보드에서 앱 버전을 복제한 다음 필요에 따라 이 값을 조정할 수 있습니다.
내 배포가 반복적으로 재시작되며 오류 `OOM kill` 이 표시됩니다.
이 동작은 할당된 메모리 양을 초과했기 때문에 발생합니다. 오브젝트 풀링, 압축 또는 씬에서 필요 없는 객체 제거를 통해 메모리 사용을 최적화하는 것을 고려하세요.
프로젝트가 다음을 포함하는 기본 씬을 로드하고 있는지 확인하세요
NetworkManager그리고 씬이 Unity의 빌드 설정에 포함되어 있습니다.Free Tier에서는 1.5 vCPU와 3GB 메모리(RAM)로 제한됩니다.
새 앱 버전을 만들 때 할당된 리소스를 늘릴 수 있습니다. 서버나 이미지를 다시 빌드하지 않고도 대시보드에서 앱 버전을 복제한 다음 필요에 따라 이 값을 조정할 수 있습니다.
마지막 업데이트
도움이 되었나요?