지속성
24/7 항상 온라인 배포로 지속적인 월드를 관리하는 방법을 알아보세요 프라이빗 플릿.
많은 장르(MMO, 샌드박스, 소셜 게임)는 플레이어가 다음을 할 수 있도록 지속적인 월드를 활용합니다:
새 친구들을 만나 교류하고 유기적인 플레이어 커뮤니티를 육성하며,
플레이어가 배치한 사용자 제작 콘텐츠로 가득한 살아 있는 오픈 월드를 탐험하고,
대규모 그룹이나 길드 전체와 함께 몇 시간 동안 이어지는 장대한 레이드 전투에 참여합니다.
전략을 탐색하여 최상의 플레이어 경험을 제공하고, 비용을 통제하며, 장애나 롤백으로 인한 플레이어의 불만을 해소하세요게임 개발자가 쉽게 사용할 수 있도록 패키징한 엣지 컴퓨팅의 장점을 도입해 기존 서버 모델을 향상시키세요.
또는, 다음을 참조하세요 배포 부분 vCPU 요금제를 활용하기 위한 오케스트레이션.
✔️ 준비
지속적이고 중단 없는 24/7 항상 온라인 배포를 활성화하려면:
우리 API로 새로운 앱 버전을 생성(또는 기존 것을 업데이트)하세요,
다음을 지정
"max_duration": -1하여 24시간 후 자동 종료를 방지합니다,
사용 방법: 프라이빗 플릿 배포 API 시작하기 위해 대기 서버 team_size 지속성.
가상 머신(Performance) 또는 베어메탈(Overdrive) 사양 중에서 선택하세요.
🔑 서버 소유권
엣지 컴퓨팅 관점을 더한 현대적/전통적 소유 모델의 장단점을 살펴보세요.
스튜디오 호스팅
서버 호스팅은 전통적으로 스튜디오가 관리하며, 게임 수익으로 호스팅 비용을 충당합니다.
👍 장점
투명한 제품 가격 책정 - 호스팅 비용은 플레이어의 라이선스/구독으로 충당,
클라이언트, 서비스, 스케일링의 느슨한 결합으로 강력한 클라이언트/서버 호환성,
서버가 폐쇄 소스이므로 치팅과 리버스 엔지니어링에 더 강함.
👎 단점
서버 무결성과 안정성을 보장하기 위해 커뮤니티 모딩 지원은 제한됩니다.
커뮤니티 서버
플레이어가 자체 서버를 호스팅하고 자금을 조달하도록 하여 제3자 임대 서비스의 필요성을 제거하세요. 최종 사용자 경험의 품질에 대한 통찰이 부족한 제3자 대신 스튜디오를 통해 수익을 유도하세요.
👍 장점
큐레이션된 모딩 목록을 통한 향상된 모딩 지원 앱 및 버전,
커뮤니티와의 긴밀한 협업으로 개선된 플레이어 피드백 루프,
플레이어가 호스팅 비용을 부담하므로 재정적 위험 감소.
👎 단점
스튜디오의 운영 증가 - 플레이어 요청 중재 및 결제 수납,
모딩 버전 수 증가로 클라이언트/서버 호환성 약화,
분산 코드베이스와 리버스 엔지니어링 가능성으로 치팅에 취약.
🥛 용량 및 스케일링
서버 가용성, 호스팅 비용, 서비스 품질을 최적화하는 고급 기법을 배우세요.
용량
배포는 활성 플레이어 연결을 추적하거나 관리하지 않습니다 당신이 한 뒤에 배포 어떤 설계든 구현할 수 있도록 절대적인 제어와 자유를 제공합니다.
다음이 보장되도록 용량 관리를 구현하세요:
비용 절감을 극대화 - 벤치마크 하고 서버 리소스를 효율적으로 활용,
원활한 게임플레이 제공 - 동시 플레이어 과다로 서버 과부하 방지,
크래시로 인한 악평 방지 - 예기치 않은 예외를 포착하고 처리.
효율적인 서버 용량 관리를 위해서는:
다음 경우 플레이어 슬롯을 해제하세요 게임 서버에 매칭된 플레이어가 몇 초 안에 연결하지 않으면,
클라이언트에서 서버로 최소한의 하트비트 메시지를 자주 보내 활동을 추적하고,
몇 초 동안 활동이 감지되지 않으면 클라이언트를 연결 해제하고 플레이어 슬롯을 해제하며,
용량이 가득 차 플레이어 슬롯이 없는 서버에 플레이어가 추가되지 않도록 하세요.
참고 서버 브라우저 관리형 서비스를 통한 자동 용량 처리를 위해 사용하세요.
예약된 배포 리소스의 양은 런타임 중에는 변경할 수 없습니다. 조정된 항목을 활용하여 새 서버 인스턴스로 수평 확장합니다 애플리케이션 버전 더 많은 CPU 또는 메모리 리소스를 요구합니다.
스케일 업
지속 서버 스케일링에는 "어림짐작"이 필요하지 않습니다 지역 트래픽이나 서버 비용에 대해. 예약 프라이빗 플릿 용량을 간조 하고, 예기치 않은 피크 시 자동으로 클라우드로 오버플로하세요.
활성화 앱 버전에서 활성 캐싱 서버를 몇 초 내에 배포하려면.
서버 스케일링 전략을 구현하여:
남용을 주의 깊게 방지하면서 대규모 호스팅을 가능하게 하고,
빈 대기 서버로 인한 낭비 비용을 최소화하며,
플레이어 수요 증가에 빠르게 대응하여 긴 대기열을 방지하세요.
통합 핵심 포인트
스케일링 권한자는 실행 중인 서버를 할당하거나 새 서버를 시작해 플레이어를 서비스합니다.
서버는 시작/중지 및 플레이어 연결 변경을 실시간으로 스케일링 권한자에게 알립니다.
스케일링 권한자는 응답하지 않는(크래시된) 서버의 오래된 레코드를 삭제(만료)합니다.
클라이언트는 서버에 직접 연결하여 게임 세션을 수립하고, 게임플레이로 진행합니다.
물리적 부하 대신 연결 수를 기준으로 스케일링할 것을 강력히 권장합니다 (CPU 및 RAM). 순간적인 물리 부하 변동은 예측 불가능한 가용성을 초래할 수 있기 때문입니다.
예약된 배포 리소스의 양은 런타임 중에는 변경할 수 없습니다. 조정된 항목을 활용하여 새 서버 인스턴스로 수평 확장합니다 애플리케이션 버전 더 많은 CPU 또는 메모리 리소스를 요구합니다.
스케일 다운
효율적인 스케일 다운 정책은 비용 최적화의 핵심이지만, 서버를 종료하는 것 을 신중히 하지 않으면 플레이어 경험에 부정적 영향을 줄 수 있습니다. 다음 요소를 고려하고 출시 전 변경 사항을 테스트하세요:
플레이어 활동/연결 해제 감지가 신뢰할 수 있나요?
입력 부재가 플레이어 비활동을 신뢰성 있게 나타내나요? 플레이어는 대기열을 피하기 위해 종종 봇, 매크로 등으로 활동을 가장합니다.
활성 플레이어가 자주 수행하지만 조작하기 어려운 행동이 있나요?
봇이나 매크로 사용이 해당 지속성 서버에서 문제인가요, 아니면 기능인가요?
서버 종료가 쉽게 빠르게 되돌릴 수 있나요(다시 스케일 업)?
로딩 씬, 미니게임, 로비 등으로 서버 로딩을 숨길 수 있나요?
플레이어는 특정 서버 인스턴스에 묶이나요, 아니면 쉽게 이동할 수 있나요?
다른 서버에 연결하면 플레이어의 계정, 구매 이력, 소셜 경험, 진행도, 인벤토리 및 기타 게임플레이 요소에 어떤 영향을 주나요?
다음을 검토하고 지속성 중요 데이터가 손실되지 않도록 하세요.
중요 데이터를 복원하기 위한 자동화된 방법 또는 플레이어 도구를 구현하세요.
사람이 직접 지원을 제공하고, 장애와 문제에 대해 커뮤니티와 소통하세요.
🔎 발견성
새 플레이어를 받는 활성 서버를 찾기 위해 하나 이상의 디스커버리 방법을 구현하세요:
충분한 플레이어가 모이면 새 게임 시작 } else {.
플레이어 추가로 백필로 기존 매치의 이탈자를 대체.
플레이어가 서버를 찾아보고 목록에서 선택할 수 있도록 서버 브라우저.
💭 구성 및 상태
초기 서버 요구사항을 정의하고 플레이어 및 서버 상태를 관리하기 위해 서비스를 통합하세요.
구성 관리
구성이란 배포 중 서버로 전달되는 초기 데이터를 의미합니다:
예: 클라이언트/서버 버전 호환성 데이터,
서드파티 통합 파라미터, 키, 시크릿.
상태 관리
상태란 이전의 일련의 플레이어 행동과 서버 이벤트의 결과를 설명하는 데이터를 의미합니다:
플레이어 연결, 플레이어가 제어하는 상태 변경(예: 폰(Pawn)),
데이터 손실을 방지하기 위해 잦은 상태 백업을 수행하세요 예기치 않은 클라이언트 또는 서버 문제 발생 시 대비:
서드파티 서비스를 사용해 실시간으로 비동기 백업, 예: Heroic Labs의 Nakama,,
클라이언트/서버 시작 또는 종료 시, 역직렬화된 상태 파일을 클라우드 오브젝트 스토리지에 저장..
게임 오브젝트는 보통 제어하는 소유자를 지정하며, 이는 서버일 수도 플레이어일 수도 있습니다.
서버 소유 오브젝트
서버 소유 오브젝트는 서버만 조작할 수 있습니다. 연결된 플레이어는 서버 소유 오브젝트에 제한적 읽기 접근만 가집니다. 서버 소유 오브젝트는 보통 다른 서버와 공유되지 않습니다.
서버 소유 오브젝트는 예기치 않은 서버 크래시 시 교체 서버가 로드할 수 있으며그렇습니다. 사용: 배포 ID 를 최초 실행 시 신규 저장 파일 식별 및 서버 소유 오브젝트 상태 저장에 사용하세요.
플레이어 소유 오브젝트
플레이어 소유 오브젝트는 플레이어와 서버 모두가 조작할 수 있습니다. 지속 오브젝트의 소유권을 플레이어에게 부여하면 이후 다른 서버로의 마이그레이션이 쉬워집니다.
플레이어 소유 오브젝트의 상태를 플레이어 기기 또는 게임 백엔드에 백업하세요 플레이 세션 사이에.
복구 목표
문제 발생 시 일부 데이터 범주는 데이터 손실에 더 민감할 수 있습니다. 예:
계정, 구독, 구매 및 마이크로트랜잭션 데이터 - 치명적,
진행도, 업적, 리더보드, 인벤토리 데이터 - 중요,
치트 탐지, 중재, 성능 및 오류 추적 데이터 - 중요,
플레이어 행동, 소셜, 채팅 데이터 - 중요도 낮음.
독립 거래 이력 소스를 통한 구매 복원을 구현하세요 최상의 경험을 위해.
팀 내에서 다음 내용을 적극적으로 논의하길 권장합니다:
게임 클라이언트와 서버에서 다루는 데이터 범주,
각 범주가 비즈니스와 플레이어에게 갖는 중요도와 민감도,
RPO(복구 지점 목표) - 중대한 피해가 발생하기 전 허용 가능한 데이터 손실량,
RTO(복구 시간 목표) - 중대한 피해가 발생하기 전 허용 가능한 다운타임.
예기치 않은 서버 충돌이 발생하면 서버가 자동으로 재시작됩니다. 서버 상태가 손실될 수 있습니다.
👀 가시성(Observability)
장시간 실행되는 지속 서버는 관측 가능성에 새로운 과제를 제기하며, 특히 모니터링, 로깅, 버그 추적에서 이상 탐지가 중요합니다.
우리는 서버 재시작 알림 구현을 강력히 권장합니다 문제에 대한 가시성을 높이기 위해.
우리의 엔드포인트 저장소 로그 통합은 로그를 전송합니다 이후에만 배포따라서, 부분 실패와 버그를 해결하기 위해 커스텀 로그와 버그 추적(예: Sentry)을 추가하세요.
예측 가능한 트래픽 패턴을 가진 게임의 경우 프라이빗 플릿 대기 용량을 예약하는 것을 고려하세요.
Last updated
Was this helpful?