- 게임 세션이 끝나면(예: 매치가 끝나거나 마지막으로 연결된 플레이어가 나갈 때) 게임 서버 프로세스가 종료되도록 하세요. 게임에서 플레이어의 재연결을 허용하는 경우 먼저 짧은 유예 기간 동안 기다리세요. MPS는 게임 세션을 대신 종료하지 않습니다. 서버는 프로세스가 종료될 때까지 Active 상태로 유지됩니다. MPS는 빌드가 축소될 때 Active 서버를 제거하지 않으므로, 종료되지 않는 서버는 비용을 지불하는 용량을 계속 사용합니다. 프로세스가 종료되면 MPS는 이를 새 서버로 교체합니다. 자세한 내용은 멀티플레이어 서버의 수명 주기를 참조하세요.
-
서버가 Active 상태가 되면(예: Game Server SDK(GSDK)의
ReadyForPlayers메서드가true를 반환할 때) 타이머를 시작하세요. 몇 분 안에 연결하는 플레이어가 없으면 프로세스를 종료하세요. 이렇게 하면 어떤 이유로든 아무도 참가하지 않는 서버가 무기한 Active 상태로 유지되지 않습니다. 시간 제한은 플레이어가 일반적으로 연결하는 데 걸리는 시간을 기준으로 설정하세요. - 서버에 필요한 정리 작업을 수행한 다음 프로세스를 종료하는 GSDK 종료 콜백을 등록하세요. GSDK는 프로세스를 대신 종료하지 않습니다. MPS는 ShutdownMultiplayerServer API를 호출할 때 콜백을 호출합니다. 이 API는 응급 상황(예: 멈춘 게임 서버를 종료하는 경우)에만 호출하세요. 일반적인 상황에서 게임 세션을 끝내는 데 사용하지 마세요. 게임 서버는 이 섹션의 앞부분에서 설명한 것처럼 스스로 종료되어야 합니다. 종료 요청 후 15분이 지나도 프로세스가 계속 실행 중이면 MPS가 프로세스를 강제로 종료합니다. 자세한 내용은 게임 서버를 정상적으로 종료하기를 참조하세요.
개발
- 로컬 워크스테이션에서 반복 테스트를 위해 LocalMultiplayerAgent(LMA)를 사용하세요. 이는 시간과 비용을 절약할 뿐만 아니라 모든 아티팩트가 로컬에서 실행되기 때문에 디버깅도 간단해집니다. 이 도구는 오픈 소스이며 기여/개선 사항은 언제나 환영합니다. 자세한 내용은 로컬에서 게임 서버 디버깅 및 PlayFab과의 통합을 참조하세요.
- standingBy 서버 비용을 절약하기 위해 구체적인 일정을 설정하려면 일정을 사용하세요. 예를 들어 모든 테스트 및 유효성 검사가 업무 시간에 수행되는 경우, 업무 시간에만 standingby 서버가 있도록 일정을 설정할 수 있습니다. 일정을 설정하는 데 추가 비용이 들지 않습니다.
- VM 메트릭 또는 자체 프로파일러를 사용하여 선택한 크기의 VM 하나에서 실행할 게임 서버 수를 결정하세요. VM의 모든 서버가 Active 상태이고 플레이어로 가득 찬 상태에서 부하 테스트를 수행하세요. 같은 VM의 서버들이 거의 동시에 할당되고 게임 세션을 시작할 수 있으므로 이러한 경우도 테스트에 포함하세요. CPU 여유 공간을 남겨 두세요. CPU가 포화된 VM에서는 할당이 느려지거나 실패할 수 있습니다.
- 심층 분석을 위해 서버 로그 및 크래시 덤프를 사용하세요.
출시 준비
- 빌드 별칭에 맞게 할당 요청을 조정하세요. 서버 업데이트의 일환으로 게임 클라이언트를 새로운 게임 서버로 원활하게 마이그레이션하는 데 도움이 되며 할당량 문제(나중에 논의)를 관리하는 데도 도움이 됩니다.
- 게임 클라이언트에 가장 가까운 지역을 추적하고 이를 할당에 사용하려면 QoS 비콘을 사용하세요. 이러한 정보는 PlayFab Matchmaking과 결합하여 유사한 지연 시간을 가진 클라이언트를 그룹화하고 가장 가까운 서버를 할당할 수 있습니다.
- 게임 서버가 항상 플레이어와 가까이 위치하도록 하려면 PlayFab MPS의 전체 지리적 커버리지를 활용하세요. 지역 장애 시 더 높은 가용성을 위해 지리적 영역 내에서 여러 지역을 사용하는 것을 고려해 보세요. 예를 들어, NorthEurope와 WestEurope에 서버를 배치하고 할당 요청에 두 지역을 (우선 순위대로) 지정하면, 한 지역에서 실패한 할당이 목록의 다음 지역에서 성공할 수 있습니다.
-
빌드 별칭에 대해 할당할 때, 플레이어에게 허용 가능한 환경을 제공하는 모든 지역을 선호하는 순서대로
PreferredRegions에 나열하세요. MPS는 해당 순서대로 지역을 시도하며, 빌드 가중치는 지역 내에서 어떤 빌드가 요청을 처리할지만 결정합니다. 가중치가 0인 빌드는 대체용으로도 사용되지 않습니다. 자세한 내용은 다른 빌드 및 지역으로의 대체를 참조하세요. -
RequestMultiplayerServer가
MultiplayerServerTooManyRequests오류로 실패하면, 요청된 지역 중 어디에도 StandingBy 서버가 있는 빌드가 없었다는 의미입니다. 이름과 달리 이 오류는 요청이 스로틀링되었다는 의미가 아닙니다. 이 오류를 방지하려면 다음을 수행하세요.PreferredRegions에 인근 지역을 여러 개 나열합니다.- 예상 최대 사용량에 맞게 대기 서버를 설정합니다.
- 각 빌드 지역의 최대 서버 수를 예상 최대 사용량보다 여유 있게 설정합니다. MPS는 대기 서버가 소진되더라도 해당 최대값을 초과하여 서버를 만들지 않습니다.
- 출시 전에 충분한 시간을 두고 빌드에서 사용하는 모든 VM 제품군과 지역에 대해 할당량을 요청하세요. 새 빌드를 롤아웃할 때는 이전 빌드의 서버가 모두 비워질 때까지 이전 빌드와 새 빌드가 동시에 코어를 사용하므로, 두 빌드에 충분한 할당량을 요청하세요. 용량을 분산하려면 서로 다른 VM 제품군을 사용하는 빌드를 같은 별칭 뒤에 두어 할당이 같은 지역의 다른 VM 제품군으로 대체될 수 있도록 하는 것을 고려하세요.
- 게임 서버용 가상 머신 SKU가 게임이 출시될 모든 지역에서 사용 가능하지 않은 경우가 있을 수 있습니다. 이러한 경우, 별칭을 사용하여 SKU 및 지역별로 빌드를 분할하거나 단일 빌드 내에서 지역 재정의를 사용하여 해당 지역에만 다른 가상 머신 SKU를 선택합니다.
- 수요에 따라 게임 서버를 확장하려면 동적 대기(Dynamic StandingBy)를 사용하세요. 이를 기본 정적 standingBy 구성과 결합하면 출시 중 높은 수요를 처리하는 비용 효율적인 방법을 제공할 수 있습니다.
- 출시 전에 게임 서버에 대한 모니터링을 설정하세요. VM 메트릭을 켜면 Game Manager에서 VM의 CPU, 메모리, 디스크 및 네트워크 메트릭을 확인할 수 있습니다. 고급 모니터링을 위해서는 VmStartupScript를 사용하여 VM에 자체 모니터링 도구를 설치하세요. VmStartupScriptGallery 리포지토리에는 VM 메트릭과 게임 서버 로그를 Azure Monitor, Application Insights, Azure Data Explorer 같은 서비스로 보내는 샘플이 있습니다.
출시일
- PlayFab Game Manager의 대시보드와 이벤트 스트림으로 게임의 성공적인 출시를 추적하세요. 시간을 내어 축하하세요. 충분히 그럴 자격이 있습니다!
출시 후
- 게임은 다시 일정으로 구성할 수 있는 수요 리듬에 빠지는 경향이 있습니다. 비용 효율적인 출시 후 게임 확장을 위해 동적 대기(Dynamic StandingBy)와 함께 일정을 사용하세요.
- 게임 서버 업데이트를 위해 빌드 별칭을 사용하고 새로운 게임 환경으로 트래픽을 점차적으로 전환하세요.
-
별칭을 새 빌드로 이동할 때는 MPS가 유휴 VM을 해제할 수 있도록 이전 빌드의 대기 서버를 0으로 설정하세요. 이전 빌드는 Active 서버가 모두 비워진 후에만 삭제하세요. 또한 클라이언트가 요청하는 지역을 별칭의 빌드가 배포된 지역과 동기화된 상태로 유지하세요. 별칭의 빌드 중 어느 것도 요청된 지역에 배포되어 있지 않으면 요청은
MultiplayerServerNotFound오류로 실패합니다.