다음을 통해 공유

멀티 플레이어 백엔드 참조 아키텍처

  • 아티클

이러한 참조 아키텍처는 게임에 적합한 클라우드 솔루션을 설계할 수 있게 해주는 다양한 멀티 플레이어 백엔드 사용 사례와 다양한 대안을 포함하는 구현을 설명합니다.

사용 사례

게임에 멀티 플레이어 백엔드를 설계할 때 고려할 수 있는 다양한 변수가 있습니다. 다음은 몇 가지 예입니다.

  1. 관리 수준 - 개발자가 직접 처리하는 수준에서 플랫폼이 모두 처리하는 수준까지
  2. 운영 체제 - Windows 또는 Linux
  3. 게임 세션 실행 위치 전용 서버 또는 P2P(피어-투-피어)
  4. 하드웨어 - 게임 세션을 실행하는 데 필요한 항목
  5. 처리 시간 - 실시간 또는 비실시간(NRT)
  6. 대기 시간 - 플레이어에게 지연이 있을 경우 불이익 여부
  7. 지속성 - 상호 작용하는 플레이어가 없는 경우에도 게임 세계가 계속 존재하고 내부적으로 발전 또는 각 세션에 시작과 끝이 있음
  8. 최대 동시 플레이어 수 - 작음, 보통 또는 많음
  9. 다시 연결 허용 - 연결이 끊긴 경우 플레이어가 게임으로 돌아갈 수 있는지 아니면 새 게임 세션을 시작해야 하는지 여부

다음은 몇 가지 멀티 플레이어 백엔드 사용 사례입니다.

팁

즉시 사용할 수 있는 확장 가능한 멀티 플레이어 서버 솔루션을 찾고 있는 경우 PlayFab은 멀티 플레이어 서버 지원이 포함된 클라우드 연결 게임을 빌드, 출시 및 확대하기 위한 완전한 백엔드 플랫폼입니다.

멀티 플레이어 디자인

관리 수준

컴퓨팅 서비스는 사용자가 전적으로 관리하는 수준에서 플랫폼에서 전적으로 관리하는 수준까지 제공되는 관리 수준에 따라 다양합니다.

  • Raw Virtual Machines - 모든 항목을 사용자가 관리하고, 사용자 지정 크기 조정 솔루션이 필요합니다.
  • ACI(Azure Container Instances) - 컨테이너 내부를 제외하고 모든 항목을 사용자가 관리하고, 사용자 지정 크기 조정 솔루션이 필요합니다.
  • Virtual Machine Scale Sets / Batch - 사용자가 정의한 규칙에 따라 가상 컴퓨터의 크기 조정을 사용자 대신 관리합니다.
  • Service Fabric / AKS(Azure Kubernetes Service) - 사용자를 대신하여 컨테이너의 오케스트레이션을 관리합니다.
  • PlayFab Multiplayer Servers - 사용자 대신 수행하는 상위 수준 게임 서버 오케스트레이션이며, Azure에서 실행됩니다. 자세한 내용은 PlayFab Multiplayer Servers를 참조하세요.

운영 체제

아래 표는 다양한 Azure 컴퓨팅 서비스에서 지원하는 운영 체제에 대한 개요입니다.

서비스 Windows 전용 Linux 전용
Raw Virtual Machines 예 예
ACI(Azure Container Instance) 예*(Windows 10 1607만 해당) 예
가상 컴퓨터 확장 집합 예 예
Batch 예 예
Service Fabric 예 예
AKS(Azure Kubernetes Service) AKS 엔진을 통해서만 예
Functions 예 예(전용 모드)

* 참고: 다중 컨테이너 그룹은 현재 Linux 컨테이너로 제한됩니다.

게임 세션은 어디에서 실행되나요?

전용 서버

게임을 플레이하기 위해 플레이어는 클라이언트 디바이스를 서버에 연결합니다.

전용 서버 사용을 고려할 때 유의할 사항은 다음과 같습니다.

  • 연결 및 안정성 이점을 제공합니다.
  • 구현이 상당히 간단하고 확장이 용이합니다.
  • 플레이어가 부정 행위를 하기가 더 어렵습니다.
  • 게임이 프레임 동기화되면 다른 플레이어의 인터넷에 영향을 줄 수 있습니다.
  • 게임 종류에 따라 전용 서버 가까이 거주하는 플레이어는 멀리 거주하는 플레이어에 비해 상당한 이점이 있습니다.

P2P(피어 투 피어)

P2P 모델을 고려할 때 유의할 사항은 다음과 같습니다.

  • 운영 비용은 전용 서버보다 저렴합니다.
  • 전용 서버 솔루션에 비해 진정으로 성공적인 구현이 더 어렵습니다.
  • 대부분의 위치에서 가정용 인터넷 서비스는 다수의 플레이어를 처리하기에 충분한 업로드 속도를 제공하지 않습니다.
  • 잘못된 연결이 있는 플레이어가 다른 플레이어의 게임에 영향을 줄 수 있습니다.
  • NAT 펀치스루 문제 때문에 클라이언트에서 연결할 수 없는 경우도 있습니다. 포트 전달이 필요할 수 있습니다.
  • 각 플레이어의 IP 주소를 다른 모든 플레이어에게 직접 전달하지 마세요. 플레이어가 게임 내 다른 플레이어의 DDoS 공격에 노출됩니다.
  • 중립 서버 형태의 중앙 인증을 사용하지 않으면 부정 행위를 방지하는 쉬운 방법은 없습니다.

로비

로비 시스템 은 플레이어가 동일한 초기 상태에서 시작해야 하는 경우 실제로 게임 세션을 시작하기 전에 플레이어를 모으는 데 매우 일반적입니다. 레이트 조인(Late Join) 지원을 구현하는 것은 기술적으로 가능하지만, 이로 인해 상당한 복잡성이 추가되기 때문에 일반적이지 않습니다. 로비 시스템에는 서버가 필요하며 일반적으로 다음과 같이 작동합니다.

  1. 플레이어가 로비를 시작하고 선택적으로 게임 매개 변수를 설정합니다.
  2. 다른 플레이어가 게임에서 제공하는 모든 쿼리 메커니즘을 통해 로비를 보거나 검색할 수 있습니다.
  3. 이러한 플레이어 중 한 명이 로비에 참여합니다.
  4. 플레이어가 충분한 경우(게임 및 제공되는 경우 로비 작성자가 설정한 규칙에 따름) 로비가 로비에서 대기 중인 각 플레이어의 세부 정보를 안전하게 배포하고 작업이 완료됩니다.
  5. 그러면 플레이어가 분산된 방식으로 패킷을 전송하기 시작합니다.

모니터링 및 경고

선호하는 원격 분석 솔루션 외에도 Azure Monitor를 활용하여 백엔드 솔루션에 사용된 Azure 서비스의 메트릭을 진단 및 활동 로그와 함께 제공할 수 있습니다. 또한 Azure Monitor는 게임에 영향을 주는 문제를 식별하는 데도 도움이 됩니다. 다음에 대한 경고를 고려합니다.

  • CPU 사용량 - 호스트의 CPU가 포화 상태에 근접하는 경우 알림을 받습니다.
  • 디스크 I/O - 게임에 예상보다 자주 디스크를 읽거나 쓰는 경우 경고를 설정합니다.
  • 메모리 사용률 - 메모리 페이징이 과다한 경우 경고를 표시해야 합니다.
  • 네트워크 트래픽 - 네트워크 트래픽이 포화 상태에 근접하거나 갑자기 급감하는 경우 경고 생성을 고려해야 합니다.

Azure Resource Manager를 사용하여 Azure Monitor 구성을 자동화할 수 있습니다. Azure Monitor에 대한 자세한 내용은 Azure Monitor를 사용하는 전체 스택 종단간 모니터링을 참조하세요.

하드웨어

게임 세션을 실행하는 데 필요한 처리 능력, 저장소, 메모리 및 네트워크 트래픽을 올바로 이해해야 합니다. 멀티 플레이어 백엔드에 필요한 가상 컴퓨터 유형과 직접적인 관련이 있기 때문입니다.

의사 결정 과정에 관련되고 게임 세션을 실행하는 데 필요한 CPU 용량을 넘어서는 몇 가지 데이터 요소가 있습니다.

  • 게임에 필요한 스레드 수는 몇 개입니까?
  • 한 게임 세션에 필요한 RAM은 얼마나 되나요?
  • 게임을 플레이하는 사용자에 게 필요한 대역폭은 얼마나 되나요?
  • 한 게임 세션에 참가하는 사용자는 몇 명인가요?
  • 게임에 하이퍼 스레딩이 필요합니까? 게임 서버가 하이퍼 스레딩에 의존하는 경우에는 하이퍼 스레드 코어를 사용해야 합니다.
  • 메모리 대 코어 비율은 무엇인가요?

이 정보를 수집하여 다음을 알아낼 수 있습니다.

  • 한 세션에 필요한 코어는 몇 개입니까?

    게임 서버가 한 스레드에서 실행되면 하나의 코어로 충분합니다. 게임 서버가 1.5개 스레드에서 실행되는 경우 두 개의 코어가 필요합니다.

    서버에서 5개 게임 세션을 호스트하고 각 게임 세션에 스레드가 필요한 경우 5개 이상의 코어가 필요합니다. 서버에서 5개 게임 세션을 호스트하고 각 게임 세션에 1.5개 스레드가 필요한 경우 8개 이상의 코어가 필요합니다.

    운영 체제 사용량을 고려합니다. 경험상, 가상 컴퓨터를 1~2개 코어 과다하게 프로비전하는 것이 좋습니다.

  • 송신은 얼마나 생성되나요?

    이는 경제적 영향과 관련된 숫자입니다. 또한 한 가상 컴퓨터에 너무 많은 플레이어가 있는 경우 네트워킹 제한이 적용될 수 있고, 특히 NIC 하나에 수천 명의 사용자를 시도하는 경우라면 병목 현상이 발생할 수 있습니다.

이 모든 것을 종합하면 원하는 가상 컴퓨터 유형 및 관련 비용을 결정할 수 있습니다. 가상 컴퓨터 유형에 따라 대역폭 처리량이 다릅니다. 네트워크 인터페이스가 요구를 처리할 수 있는지 확인해야 합니다. 가상 컴퓨터당 플레이어 수와 플레이어당 소비하는 대역폭을 곱해 계산합니다. 이 값은 각 VM 크기에 대해 설명하는 최대 NIC / 예상 네트워크 대역폭(Mbps) 보다 클 수 없습니다.

프리미엄 저장소를 사용하여 단일 인스턴스 가상 컴퓨터의 가용성을 높일 수 있다는 점을 고려할 가치가 있습니다. 프리미엄 저장소를 사용하는 가상 컴퓨터는 SLA가 99.9%입니다.

대기 시간 영향

일부 게임에서는 몇 분의 1초 수준의 반응이 필요하고, 플레이어의 반응 시간과 대기 시간을 더하면 게임 경험에 부정적이 영향을 미칠 수 있습니다.

대기 시간을 축소하거나 완화하려면 몇 가지 사항을 고려해야 합니다. 구현의 관점에서는 클라이언트 쪽 예측을 사용하여 플레이어가 수행할 동작을 "앞지르고" 간혹 플레이어가 화면에 표시되는 내용과 게임에서 실제로 발생하는 상황이 불일치하는 것을 감수하는 것이 매우 일반적인 방식입니다. 이러한 불일치를 완화하기 위해 보외 또는 보간과 같은 메커니즘을 사용하여 게임 개체를 표시할 위치를 결정하는 약간의 지연 보상을 적용할 수도 있습니다.

인프라의 관점에서는 플레이어가 게임 서버에서 멀리 있을수록 결국 대기 시간이 길어집니다. 플레이어를 가장 가까운 게임 서버에 연결하면 효과가 있습니다. Azure에는 다른 어떤 클라우드 공급자보다 많은 글로벌 지역이 있으므로 전 세계 플레이어를 더 가까이 모을 수 있는 규모를 제공합니다. 가속화된 네트워킹은 서버 쪽 대기 시간을 줄일 수 있지만, 4개 이상의 vCPU가 탑재된 가상 컴퓨터에서만 사용할 수 있다는 데 유의해야 합니다. 또한 Linux 가상 컴퓨터를 사용하려는 경우 동일한 가상 컴퓨터에 많은 수의 플레이어가 있을 때 대기 시간 및 처리량을 최적화하기 위해 DPDK를 고려하는 것이 좋습니다.

그룹을 지원하는 게임의 경우 그룹의 구성원들이 서로 떨어져 있는 경우를 해결할 필요가 있습니다. 게임에서 연결하려는 지역을 수동으로 선택하는 기능을 추가하거나 최소 대기 시간 공통 분모 알고리즘을 추가합니다.

완화 노력이 실패한 시나리오에서는 네트워크 대기 시간이 관리할 수 없는 수준에 도달할 수 있습니다. 이 경우 대기 시간이 가장 긴 플레이어의 연결을 해제하는 등 보다 극단적인 조치를 적용해야 합니다.

팁

가장 좋은 방법은 플레이어의 대기 시간을 측정하고 QA 팀 또는 베타 테스터를 위한 피드백 메커니즘과 함께 사용하여 언제 지연이 발생하는지(예: 키 조합, 게임 패드 버튼 조합 또는 화면에 표시되는 아이콘) 확인하는 것입니다. 이 두 가지 기능을 모두 사용하면 플레이어가 지연을 인식하게 되는 요인을 더 쉽게 찾을 수 있습니다.

프로토콜

실시간 통신이 필요한 게임의 경우에는 UDP(사용자 데이터그램 프로토콜) 를 통해 전송하는 것이 가장 좋습니다. 이 방법은 일반적으로 TCP(전송 제어 프로토콜)보다 구현하기 복잡하지만 성능 고려 사항이 훨씬 좋습니다.

비동기 또는 턴 기반 통신의 경우 HTTPS를 통한 JSON을 활용하면 충분합니다.

게임 세션당 동시 플레이어 수

플레이어가 두 명뿐인 틱택토(tic-tac-toe) 게임에서 100명이나 되는 배틀 로열 게임, 수천 명이 참여하는 몇몇 지속적인 월드 게임에 이르기까지 동일 게임 세션의 동시 플레이어 수는 활용할 아키텍처 및 서비스에 영향을 미칩니다. 이러한 사용 사례에서 고려된 세 가지 범위는 다음과 같습니다.

  • 소규모 - 10명 미만의 동시 플레이어
  • 중규모 - 11~50명의 동시 플레이어
  • 대규모 - 50명을 초과하는 동시 플레이어

모범 사례

용량 계획이 중요

다른 크기 조정 서비스와 마찬가지로, 충분한 시간을 들여 적절한 인스턴스 수를 계획하는 것은 중요한 단계입니다. 너무 적은 수의 인스턴스를 사용하면 성능이 저하됩니다. 너무 많은 경우에는 불필요한 비용을 초래합니다.

미리 테스트하고 충분히 숙고하세요. 게임을 릴리스하기 전에 먼저 개념 증명과 한 번 이상의 베타를 실행하여 플레이어가 가장 많이 사용하는 요일과 이를 지원하기 위한 최대 용량을 파악하세요.

소프트웨어가 크기 조정 가능한지 또한 로그인 및 매치 메이킹에서 게임 서버 자체에 이르기까지 플레이어가 게임을 즐길 수 있도록 준비가 완료되었는지 확인합니다. 다양한 수준에서 플레이어 동시성(100, 1,000, 10,000, 100,000 등)을 테스트합니다. 동시 플레이어 수가 10배 증가할 때마다 새로운 병목 현상이 발생하고 조정 작업을 수행해야 하는 경우가 많습니다.

배포 방법

Virtual Machine Scale Sets, Service Fabric 또는 Batch를 활용하는 경우 단일 클러스터, 여러 가상 컴퓨터 확장 집합을 사용하여 한 번에 1~4개 노드씩 점진적으로 크기를 조정합니다. 여러 개의 가상 컴퓨터 확장 집합을 활용하면 신속하게 크기 조정되지만 비용도 증가한다는 점을 유의해야 합니다.

초기 테스트에서 매일 워크로드를 캡처한 후에는 해당 정보를 사용하여 용량이 필요하기 1시간 전에 확장 작업을 미리 계획합니다.

인프라 변경 방지

Azure Logic Apps를 사용하고 인프라를 최대한 변경하지 않도록 최선을 다해야 합니다. 실행 인스턴스를 웜 풀로 유지하면 플레이어가 즉시 게임을 시작할 수 있지만 비용도 증가하게 됩니다.

유사 시 대기

가상 컴퓨터가 실패하는 경우 게임 세션은 어떻게 되나요? 게임 유형과 구현에 추가하려는 복잡성에 따라 몇 가지 대안이 있습니다.

세션이 몇 분 정도 지속되어 빠르게 시작하고 끝나는 게임의 경우 아무 작업도 수행하지 않고 플레이어를 로비로 돌려보내는 것이 좋습니다. 플레이어에 대한 영향이 미미하기 때문입니다. 지속적인 월드 게임에서는 가상 컴퓨터 실패가 보다 심각한 문제가 될 수 있으며, 플레이어 상태를 유지하면서 플레이어를 새 서버로 자동으로 이동하는 것과 같은 조치를 구현할 수 있습니다.

모니터 서비스를 사용하여 노드가 실패했는지 확인하고 경고를 설정합니다. 또한 실패한 가상 컴퓨터를 유지하며 포렌식을 통해 환경이 실패한 이유를 조사할지 단순히 해당 가상 컴퓨터를 삭제할지 여부도 고려할 수 있습니다.

추가 리소스 및 샘플