PlayFab 소비: 모범 사례
PlayFab의 소비 기반 가격 모델을 사용하면 타이틀의 실제 서비스 사용량에 대해서만 비용을 지불합니다. 하지만 이는 명백한 질문을 제기합니다: 필요한 모든 기능을 구현하면서 비용을 절약하기 위해 이러한 타이틀을 어떻게 최적화하는 것이 가장 좋을까요? 이 문서에서는 이러한 세부 사항을 살펴보고 미리 계획하는 데 도움이 되는 모범 사례에 대해 이야기합니다. 타이틀을 개발 모드에서 라이브로 이동하기 전에 Game Manager의 Billing Summary 탭에서 미터 정보를 검토할 수 있습니다. 여섯 가지 소비 미터가 있습니다: Events, Profile, Content and Configuration, CloudScript, Insights, Multiplayer Services. 타이틀을 최적화하는 가장 좋은 방법은 사용하는 각 미터를 살펴보고 시간이 지남에 따라 어떻게 누적되는지 확인하는 것입니다. 이렇게 하면 몇 가지 명백한 개선점을 빠르게 도출할 수 있습니다. 미터에 대한 자세한 내용은 가격 미터를 참조하세요.Events
PlayFab에는 두 가지 유형의 이벤트가 있습니다: PlayStream과 Telemetry. PlayFab은 PlayStream 이벤트를 처리하여 정의한 PlayStream Actions를 트리거하는지 확인하고 User Segmentation을 업데이트합니다. 일부 PlayStream 이벤트는 인증 및 통계 업데이트와 같은 서비스 기능 호출의 결과로 자동으로 생성됩니다. 타이틀은 이 기능을 확장하기 위해 자체 커스텀 이벤트를 생성할 수 있습니다. Telemetry 이벤트는 PlayStream에 의해 처리되지 않습니다. 이러한 이벤트는 분석에 사용되며 데이터 웨어하우스로 바로 이동합니다. Telemetry 이벤트는 PlayFab에서 자동으로 생성되지 않습니다. 타이틀이 생성하는 커스텀 이벤트입니다. 두 이벤트 유형 모두, 더 큰 데이터 페이로드는 총 미터 사용량을 증가시킵니다. 필요한 데이터만 전송하도록 하여 전반적인 사용량을 줄일 수 있습니다. 대략적인 가이드로는 특정 이벤트가 이벤트 본문의 데이터 1KB당 해당 미터를 1씩 증가시킵니다. 사용에 가장 적합한 이벤트 경로를 선택하려면 생성하는 각 커스텀 이벤트를 어떻게 사용할 것인지에 대한 명확한 계획이 있어야 합니다. 타이틀의 오프라인 평가에만 필요한 이벤트는 Telemetry 경로로 이동해야 합니다. 이는 Telemetry 이벤트의 초과 요금이 PlayStream의 절반 이하이므로 비용을 상당히 줄이는 데 도움이 될 수 있습니다. 미리 만들어진 SDK 중 하나를 사용하는 경우, PlayStream Event Model 참조에 설명된 대로 사용자 행동에 대한 일부 분석 데이터가 자동으로 생성됩니다. 선택 사항 이벤트를 끄려면 PlayFab Game Manager의 게임에 있는 Settings/Data Collection 탭에서 분석 설정을 변경합니다. 마찬가지로, 디버깅 중에는 CloudScript 실행에 대한 “generate PlayStream event” 옵션을 켜 두는 것이 좋지만, 라이브로 전환하기 전에 이를 비활성화해야 합니다. PlayStream Action 트리거 CloudScripts의 경우, 나중에 실제 환경에서 일부 동작을 디버깅해야 할 필요가 있을 때 언제든지 다시 켤 수 있습니다.Profile
프로필은 사실상 “플레이어에 관한 모든 것”으로, 인벤토리, 저장된 데이터 및 통계와 같은 일반적인 요소를 포함합니다. 또한 위에서 언급한 User Segmentation과 같이 PlayStream의 LiveOps 기능을 통해 고유한 경험을 유도하는 데 사용하는 메타 정보도 포함됩니다. 또한 Title Data, Catalogs, Stores와 같은 일부 타이틀 수준의 레거시 기능은 데이터 구현이 사실상 User Data와 동일하므로 이 미터에 포함됩니다. 이 미터 세트는 모든 플레이어 액션과 플레이어에 대한 액션에 의해 구동되므로, 대부분 최적화 계획이 가장 필요한 미터입니다. 가격 미터에 캡처된 사용량에 주요 기여 요인은 읽고, 저장하고, 쓰는 데이터의 양과 데이터를 생성하는 API 호출 빈도입니다. 이러한 미터에 “회전”을 일으키는 특정 API 호출에 대한 자세한 내용은 가격 미터를 참조하세요. User Data와 Statistics는 사용 패턴이 유사하므로 이들부터 시작하고, 그런 다음 플레이어 인벤토리 관리에 대해 이야기하겠습니다.데이터 및 통계
User Data 사용을 평가할 때는 이벤트와 동일한 근사 논리가 적용됩니다. 각 1KB는 미터 카운트를 1씩 증가시킵니다. 다만 호출의 각 “요소”는 이 계산의 목적상 별개로 고려되어야 함을 명심하세요. User Data를 업데이트하는 호출의 각 키 값 쌍은 별도로 계산됩니다. 읽기의 경우, 이 1KB 계산은 키 값 쌍 수와 관계없이 반환된 총 데이터에 적용됩니다. 즉, 각각 100바이트의 10개 키를 쓰는 것은 프로필 쓰기 미터의 10 “틱”인데, 각 키 값 쌍 쓰기는 최소 1KB이기 때문입니다. 반면, 해당 10개 키의 읽기는 총 1KB이므로 1 “틱”입니다. 사용에 대한 구체적인 세부 사항은 가격 미터를 참조하세요. Statistics는 프로필을 업데이트하고 리더보드에도 영향을 미칠 수 있어 약간 더 복잡합니다. 일반적으로, 업데이트된 각 통계는 전체 프로필 업데이트로 생각할 수 있으며 읽기는 각 호출에서 읽은 데이터의 총 크기를 기반으로 합니다. 그리고 저장소는 기가바이트(GB)당 가격이 책정되고 통계는 일반적으로 각 몇 바이트만 소비하므로 읽기와 쓰기에 초점을 맞추겠습니다. 총 데이터 크기가 중요하므로 이를 최적화하는 것이 첫 번째 단계입니다. 다행히도 이를 위한 다양한 잘 알려진 기술이 있습니다. 항목에 대해 철자가 있는 텍스트 대신 열거형이나 ID를 사용하거나, 큰 데이터를 바이너리로 패킹하거나, 심지어 비트필드를 사용하여 더 작은 공간에 데이터를 패킹하는 것 등입니다. 이 작업이 완료되면 다음 단계는 이러한 읽기 및 쓰기 호출을 언제 수행해야 하는지 신중하게 평가하는 것입니다. PC 또는 콘솔 개발, 특히 싱글 플레이어 게임에서 온 경우, 이는 새로운 패턴일 수 있습니다. 하지만 그러한 환경에서는 리소스 히트와 가비지 컬렉션이 중요한 시점에 성능 저하를 일으킬 수 있기 때문에 클라이언트 장치의 리소스 히트와 가비지 컬렉션에 주의해야 합니다. 타이틀이 클라우드에 있는 리소스를 사용할 때는 각 리소스 히트가 성능 비용 외에도 실제 비용을 가진다는 것을 고려하도록 그 논리를 확장할 필요가 있습니다. 읽기 및 쓰기의 최적 빈도를 어떻게 결정할까요? 데이터 및 통계를 더 자주 업데이트하려는 개발자의 가장 일반적인 두 가지 관심사는 부정 행위 방지, 그리고 플레이어 간 상호 작용을 위해 서버 측에 적시에 저장된 정보를 갖거나 게임이 예기치 않게 종료될 경우 데이터 손실을 방지하는 것입니다.부정 행위 방지
필수 보안을 보장하기 위해 백엔드 데이터를 지속적으로 업데이트해야 하는 것처럼 보일 수 있지만, 게임이 세션의 완전한 서버 권한 제어를 요구하지 않는 한 빈번한 업데이트는 거의 필요하지 않습니다. 시작하려면 기본적인 질문은 실제로 얼마나 많은 보안이 필요한가입니다. 일부 게임의 경우, 특히 주로 게임 내 광고를 통해 수익을 창출하고 리더보드가 없는 게임의 경우, 부정 행위는 큰 관심사가 아닙니다. 이 경우 데이터의 보안이 실제로 관심사가 아니기 때문에, 클라이언트가 보낸 데이터를 신뢰하는 것이 종종 실행 가능한 접근 방식입니다. 부정 행위 동작을 식별하고 처리하는 방법을 결정하려면, 플레이어의 이벤트, 데이터 및 통계를 검토하는 프로세스를 구현하는 것을 권장합니다. 경쟁의 무결성을 지원하거나 전반적인 플레이어 경험을 보호해야 하는 다른 게임의 경우, 더 강력한 보안이 더 중요합니다. 특정 요구 사항에 따라, 특정 접근 방식은 이러한 상황에서 데이터 읽기 및 쓰기 빈도를 줄일 수 있습니다. 게임이 실시간이 아닌 경우, 우리가 권장하는 한 가지 접근 방식은 일정 기간 동안(종종 몇 분이 걸리는 게임의 “라운드”) 플레이어 게임에 대한 정보를 집계한 다음, 유효한지 확인하는 스크립트로 해당 데이터를 보내는 것입니다. 평가할 주요 요소는 게임에 따라 다를 수 있지만, 고려할 몇 가지 일반적인 개념의 예는 다음과 같습니다:- 마지막 세션 보고서 이후 얼마나 지났으며, 클라이언트는 최근 세션에서 얼마나 오래 재생되었다고 말합니까?
- 플레이어는 어떤 점수를 등록했으며, 해당 플레이어의 레벨, 장비 등을 감안할 때 합리적입니까?
데이터 적시성
프로필 쓰기 속도가 높은 개발자들 사이에서 우리가 들은 한 가지 공통된 주제는 플레이어가 진행 상황을 잃는 것에 대한 우려입니다. 플레이어가 게임을 저장할 수 있기 전에 게임을 종료하고 로컬 상태를 다음 번 게임을 플레이할 때 사용할 수 없거나, 해당 상태가 장치 간에 이동해야 하는 경우, 플레이어에 대한 PlayFab 저장 상태 정보가 최대한 최신 상태이길 원할 것입니다. 많은 게임의 경우, 서비스에 대한 정기적이고 드문 업데이트 하트비트(예: 15분마다)를 가짐으로써 이 문제를 해결할 수 있습니다. 하지만 해당 빈도를 늘리거나 줄이는 추가 로직을 포함하는 것도 도움이 될 수 있습니다. 예:- 플레이어가 적극적으로 중요한 작업을 수행하는 경우 즉시 쓰기를 유발하고 타이머를 재설정하는 “important update” 재정의를 포함하여 손실되지 않도록 합니다.
- 게임이 플레이어 입력 없이 계속 진행되는 경우, 오랫동안 입력이 없었다면 하트비트 기간을 늘리는 것을 고려해 보세요. 이는 플레이어가 자주 밤새 실행하는 유휴 게임에 특히 중요합니다.
- 사용자 메뉴의 버튼 등 플레이어가 직접 업데이트를 강제로 실행할 수 있는 방법을 제공하세요. 이 경우, 플레이어가 해당 버튼을 계속해서 눌러도 매번 호출이 생성되지 않도록 클라이언트 장치에서 PlayFab으로 실제 호출되는 속도를 제한해야 합니다.