> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PlayFab 소비 모범 사례

> Events, Profile, CloudScript, Multiplayer에 대한 PlayFab 소비 미터를 최적화하여 개발 모드에서 라이브로 타이틀을 이동하기 전에 비용을 절감하세요.

# PlayFab 소비: 모범 사례

PlayFab의 소비 기반 가격 모델을 사용하면 타이틀의 실제 서비스 사용량에 대해서만 비용을 지불합니다. 하지만 이는 명백한 질문을 제기합니다: 필요한 모든 기능을 구현하면서 비용을 절약하기 위해 이러한 타이틀을 어떻게 최적화하는 것이 가장 좋을까요? 이 문서에서는 이러한 세부 사항을 살펴보고 미리 계획하는 데 도움이 되는 모범 사례에 대해 이야기합니다.

타이틀을 개발 모드에서 라이브로 이동하기 전에 Game Manager의 Billing Summary 탭에서 미터 정보를 검토할 수 있습니다.

여섯 가지 소비 미터가 있습니다: Events, Profile, Content and Configuration, CloudScript, Insights, Multiplayer Services. 타이틀을 최적화하는 가장 좋은 방법은 사용하는 각 미터를 살펴보고 시간이 지남에 따라 어떻게 누적되는지 확인하는 것입니다. 이렇게 하면 몇 가지 명백한 개선점을 빠르게 도출할 수 있습니다. 미터에 대한 자세한 내용은 [가격 미터](/services/playfab/pricing/meters/meters)를 참조하세요.

## Events

PlayFab에는 두 가지 유형의 이벤트가 있습니다: PlayStream과 Telemetry.

PlayFab은 PlayStream 이벤트를 처리하여 정의한 PlayStream Actions를 트리거하는지 확인하고 User Segmentation을 업데이트합니다. 일부 PlayStream 이벤트는 인증 및 통계 업데이트와 같은 서비스 기능 호출의 결과로 자동으로 생성됩니다. 타이틀은 이 기능을 확장하기 위해 자체 커스텀 이벤트를 생성할 수 있습니다.

Telemetry 이벤트는 PlayStream에 의해 처리되지 않습니다. 이러한 이벤트는 분석에 사용되며 데이터 웨어하우스로 바로 이동합니다. Telemetry 이벤트는 PlayFab에서 자동으로 생성되지 않습니다. 타이틀이 생성하는 커스텀 이벤트입니다.

두 이벤트 유형 모두, 더 큰 데이터 페이로드는 총 미터 사용량을 증가시킵니다. 필요한 데이터만 전송하도록 하여 전반적인 사용량을 줄일 수 있습니다. 대략적인 가이드로는 특정 이벤트가 이벤트 본문의 데이터 1KB당 해당 미터를 1씩 증가시킵니다.

사용에 가장 적합한 이벤트 경로를 선택하려면 생성하는 각 커스텀 이벤트를 어떻게 사용할 것인지에 대한 명확한 계획이 있어야 합니다. 타이틀의 오프라인 평가에만 필요한 이벤트는 Telemetry 경로로 이동해야 합니다. 이는 Telemetry 이벤트의 초과 요금이 PlayStream의 절반 이하이므로 비용을 상당히 줄이는 데 도움이 될 수 있습니다.

미리 만들어진 SDK 중 하나를 사용하는 경우, [PlayStream Event Model 참조](/services/playfab/api-references/events)에 설명된 대로 사용자 행동에 대한 일부 분석 데이터가 자동으로 생성됩니다. 선택 사항 이벤트를 끄려면 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 호출에 대한 자세한 내용은 [가격 미터](/services/playfab/pricing/meters/meters)를 참조하세요.

User Data와 Statistics는 사용 패턴이 유사하므로 이들부터 시작하고, 그런 다음 플레이어 인벤토리 관리에 대해 이야기하겠습니다.

### 데이터 및 통계

User Data 사용을 평가할 때는 이벤트와 동일한 근사 논리가 적용됩니다. 각 1KB는 미터 카운트를 1씩 증가시킵니다. 다만 호출의 각 "요소"는 이 계산의 목적상 별개로 고려되어야 함을 명심하세요. User Data를 업데이트하는 호출의 각 키 값 쌍은 별도로 계산됩니다. 읽기의 경우, 이 1KB 계산은 키 값 쌍 수와 관계없이 반환된 총 데이터에 적용됩니다. 즉, 각각 100바이트의 10개 키를 쓰는 것은 프로필 쓰기 미터의 10 "틱"인데, 각 키 값 쌍 쓰기는 최소 1KB이기 때문입니다. 반면, 해당 10개 키의 읽기는 총 1KB이므로 1 "틱"입니다. 사용에 대한 구체적인 세부 사항은 [가격 미터](/services/playfab/pricing/meters/meters)를 참조하세요.

Statistics는 프로필을 업데이트하고 리더보드에도 영향을 미칠 수 있어 약간 더 복잡합니다. 일반적으로, 업데이트된 각 통계는 전체 프로필 업데이트로 생각할 수 있으며 읽기는 각 호출에서 읽은 데이터의 총 크기를 기반으로 합니다. 그리고 저장소는 기가바이트(GB)당 가격이 책정되고 통계는 일반적으로 각 몇 바이트만 소비하므로 읽기와 쓰기에 초점을 맞추겠습니다.

총 데이터 크기가 중요하므로 이를 최적화하는 것이 첫 번째 단계입니다. 다행히도 이를 위한 다양한 잘 알려진 기술이 있습니다. 항목에 대해 철자가 있는 텍스트 대신 열거형이나 ID를 사용하거나, 큰 데이터를 바이너리로 패킹하거나, 심지어 비트필드를 사용하여 더 작은 공간에 데이터를 패킹하는 것 등입니다. 이 작업이 완료되면 다음 단계는 이러한 읽기 및 쓰기 호출을 언제 수행해야 하는지 신중하게 평가하는 것입니다.

PC 또는 콘솔 개발, 특히 싱글 플레이어 게임에서 온 경우, 이는 새로운 패턴일 수 있습니다. 하지만 그러한 환경에서는 리소스 히트와 가비지 컬렉션이 중요한 시점에 성능 저하를 일으킬 수 있기 때문에 클라이언트 장치의 리소스 히트와 가비지 컬렉션에 주의해야 합니다. 타이틀이 클라우드에 있는 리소스를 사용할 때는 각 리소스 히트가 성능 비용 외에도 실제 비용을 가진다는 것을 고려하도록 그 논리를 확장할 필요가 있습니다.

읽기 및 쓰기의 최적 빈도를 어떻게 결정할까요? 데이터 및 통계를 더 자주 업데이트하려는 개발자의 가장 일반적인 두 가지 관심사는 부정 행위 방지, 그리고 플레이어 간 상호 작용을 위해 서버 측에 적시에 저장된 정보를 갖거나 게임이 예기치 않게 종료될 경우 데이터 손실을 방지하는 것입니다.

### 부정 행위 방지

필수 보안을 보장하기 위해 백엔드 데이터를 지속적으로 업데이트해야 하는 것처럼 보일 수 있지만, 게임이 세션의 완전한 서버 권한 제어를 요구하지 않는 한 빈번한 업데이트는 거의 필요하지 않습니다. 시작하려면 기본적인 질문은 실제로 얼마나 많은 보안이 필요한가입니다.

일부 게임의 경우, 특히 주로 게임 내 광고를 통해 수익을 창출하고 리더보드가 없는 게임의 경우, 부정 행위는 큰 관심사가 아닙니다. 이 경우 데이터의 보안이 실제로 관심사가 아니기 때문에, 클라이언트가 보낸 데이터를 신뢰하는 것이 종종 실행 가능한 접근 방식입니다. 부정 행위 동작을 식별하고 처리하는 방법을 결정하려면, 플레이어의 이벤트, 데이터 및 통계를 검토하는 프로세스를 구현하는 것을 권장합니다.

경쟁의 무결성을 지원하거나 전반적인 플레이어 경험을 보호해야 하는 다른 게임의 경우, 더 강력한 보안이 더 중요합니다. 특정 요구 사항에 따라, 특정 접근 방식은 이러한 상황에서 데이터 읽기 및 쓰기 빈도를 줄일 수 있습니다.

게임이 실시간이 아닌 경우, 우리가 권장하는 한 가지 접근 방식은 일정 기간 동안(종종 몇 분이 걸리는 게임의 "라운드") 플레이어 게임에 대한 정보를 집계한 다음, 유효한지 확인하는 스크립트로 해당 데이터를 보내는 것입니다. 평가할 주요 요소는 게임에 따라 다를 수 있지만, 고려할 몇 가지 일반적인 개념의 예는 다음과 같습니다:

* 마지막 세션 보고서 이후 얼마나 지났으며, 클라이언트는 최근 세션에서 얼마나 오래 재생되었다고 말합니까?
* 플레이어는 어떤 점수를 등록했으며, 해당 플레이어의 레벨, 장비 등을 감안할 때 합리적입니까?

서버 권한 플레이어 상태를 자주 업데이트해야 하는 등 더 실시간 요구 사항이 있는 게임의 경우, PlayFab 저장 데이터에 대한 빈번한 업데이트보다 더 나은 솔루션은 호스팅된 게임 서버를 사용하는 것입니다. 해당 모델에서는 세션 시작 시 서버에 플레이어를 연결합니다. 서버는 플레이어에 대해 서비스에서 필요한 모든 데이터를 읽은 다음, 시간이 지남에 따라 해당 플레이어의 시뮬레이션 상태를 호스팅하며, 필요한 속도로 서버와 데이터를 교환합니다. 그런 다음 서버는 세션 종료 시 또는 세션이 특히 긴 경우 몇 분마다 플레이어에 대한 최신 데이터로 PlayFab의 "장기 저장소"를 업데이트합니다.

이는 실시간 멀티플레이어 게임에서 사용되는 모델입니다. 서버 권한 확인이 필요한 싱글 플레이어 타이틀에도 유효한 기술이지만, 해당 빈도가 플레이어당 분당 몇 번에 불과하다면 Azure Functions CloudScript가 더 나은 옵션일 수 있습니다. 총 CloudScript 비용은 계산하기 쉽습니다. 실행당 최소 128MB 및 100ms로 소비되는 총 기가바이트-초와 스크립트가 사용하는 다른 서비스 API 호출에 대한 일반 계산입니다. 예를 들어, 스크립트 코드와 스크립트의 변수 사용 간에 총 메모리 사용 공간이 250MB인 경우, 1GB/s에 도달하기 위해 해당 스크립트를 4초 동안(대부분 여러 사용자에 걸쳐) 실행해야 합니다. 그리고 해당 스크립트 코드 내에서 Entity Objects, Title Data, User Data 등을 읽거나 쓰면 각 호출이 프로필 미터에 가지는 회전을 계산해야 합니다. 호스팅된 게임 서버 비용은 실행 중인 서버 수에 따라 달라지며, 이는 서버에서 한 번에 호스팅될 수 있는 플레이어 수에 따라 달라지므로, 둘 사이의 손익 분기점을 결정하는 것은 반드시 사소하지 않습니다. 하지만 스크립트를 높은 빈도로 호출해야 하고, 매번 서비스에서 데이터를 읽고 써야 한다는 것을 알게 된다면, 게임 서버 솔루션이 더 나은 방법일 가능성이 매우 높습니다.

### 데이터 적시성

프로필 쓰기 속도가 높은 개발자들 사이에서 우리가 들은 한 가지 공통된 주제는 플레이어가 진행 상황을 잃는 것에 대한 우려입니다. 플레이어가 게임을 저장할 수 있기 전에 게임을 종료하고 로컬 상태를 다음 번 게임을 플레이할 때 사용할 수 없거나, 해당 상태가 장치 간에 이동해야 하는 경우, 플레이어에 대한 PlayFab 저장 상태 정보가 최대한 최신 상태이길 원할 것입니다.

많은 게임의 경우, 서비스에 대한 정기적이고 드문 업데이트 하트비트(예: 15분마다)를 가짐으로써 이 문제를 해결할 수 있습니다. 하지만 해당 빈도를 늘리거나 줄이는 추가 로직을 포함하는 것도 도움이 될 수 있습니다. 예:

* 플레이어가 적극적으로 중요한 작업을 수행하는 경우 즉시 쓰기를 유발하고 타이머를 재설정하는 "important update" 재정의를 포함하여 손실되지 않도록 합니다.
* 게임이 플레이어 입력 없이 계속 진행되는 경우, 오랫동안 입력이 없었다면 하트비트 기간을 늘리는 것을 고려해 보세요. 이는 플레이어가 자주 밤새 실행하는 유휴 게임에 특히 중요합니다.
* 사용자 메뉴의 버튼 등 플레이어가 직접 업데이트를 강제로 실행할 수 있는 방법을 제공하세요. 이 경우, 플레이어가 해당 버튼을 계속해서 눌러도 매번 호출이 생성되지 않도록 클라이언트 장치에서 PlayFab으로 실제 호출되는 속도를 제한해야 합니다.

클라이언트가 다음번에 게임을 플레이할 때 상태 정보를 가지고 있다면, 로컬 타임스탬프와 서비스 데이터의 타임스탬프를 비교하여 어느 것을 사용할지 결정하거나, 심지어 플레이어에게 선택할 수 있는 옵션을 제공할 수도 있습니다.

플레이어의 프로필 정보는 자신뿐만 아니라 다른 사람에게도 관련이 있을 수 있습니다. 일부 게임에서는 경쟁을 자극하거나 비동기 친구 상호 작용, 챌린지 등을 통해 플레이어 경험에 직접적으로 영향을 미치기 위해 플레이어 간 쿼리를 해야 할 수도 있습니다.

경쟁의 경우, [Leaderboards](/services/playfab/community/leaderboards)는 서비스에 대한 단일 호출을 통해 다른 플레이어(종종 현재 플레이어의 점수에 가까운 플레이어)에 대한 정보의 하위 집합을 공유하여 그러한 긴장을 조성하는 이상적인 방법입니다. [Profile View Constraints](/services/playfab/community/leaderboards/tournaments-leaderboards/using-the-profile-for-advanced-leaderboards)를 사용하여 통계 및 태그와 같은 다른 프로필 요소를 반환할 수 있으므로, 이러한 다른 플레이어에 대한 풍부한 정보 세트를 제시할 수 있습니다. 그러나 리더보드의 모든 플레이어 목록을 반복하여 각 플레이어에서 추가 정보를 읽으려고 하지 않는 것이 중요합니다. 이는 총 프로필 읽기 수를 빠르게 곱하여 비용을 증가시킬 수 있기 때문입니다.

세션에서 플레이어 간 데이터를 직접 사용하는 게임의 경우, 가장 일반적인 최적화는 로컬 플레이어가 상호 작용하는 소수의 특정 플레이어에 대한 정보만 읽는 것입니다. 실시간 액션 게임의 경우, 이는 일반적으로 세션을 호스팅하는 서버에서 수행됩니다. 다른 게임(플레이어가 서로의 기지를 공격할 수 있는 게임 등)의 경우, 가장 일반적인 접근 방식은 해당 모든 데이터를 로컬 장치로 읽거나 로컬 플레이어에게 로컬 플레이어가 알아야 하는 다른 플레이어 데이터의 하위 집합만 보내는 것입니다. 전자를 수행하는 게임은 서버 측 로직을 사용하여 클라이언트가 보낸 최종 결과를 평가합니다. 후자를 수행하는 게임은 로컬 플레이어가 액세스해야 할 때 세션 과정에서 반복적으로 더 많은 데이터로 데이터를 업데이트합니다. 그러나 그때도 그들은 서버 측 로직을 사용하여 최종 결과를 평가합니다. 다시 말하지만, 이것이 스크립트를 통해 수행되어야 하는지 또는 호스팅된 서버에서 수행되어야 하는지 결정하는 티핑 포인트는 빈도에 있습니다. 분당 몇 번 이상이면 해당 데이터가 필요한 세션 부분에 대해 호스팅된 서버를 사용하는 것이 좋습니다.

## Economy 및 인벤토리

인벤토리, 그리고 일반적으로 경제는 다른 접근 방식이 필요합니다. 플레이어가 실제(돈) 또는 인지된(가상 통화 또는 소모품 컨테이너) 가치가 있는 것을 포기하는 경우, 거래가 존중될 것이라는 암묵적인 기대를 가지는 것은 피할 수 없습니다. 인앱 구매가 있는 게임의 경우, 플레이어가 실제 통화로 구매한 프로필 미터에 대한 증가는 사소한 비용입니다. 많은 유형의 게임에서 인벤토리 업데이트는 전체 사용량을 크게 증가시키는 것에 대한 우려가 거의 없을 만큼 드물게 발생합니다. 하지만 더 빈번한 인벤토리 업데이트가 있는 게임의 경우(게임 내 수익 창출이 없더라도) 비용을 줄이는 데 도움이 되는 최적화 요령이 있습니다.

모범 사례는 인벤토리를 문자 그대로의 의미로만, 즉 합리적으로 유한한 인벤토리로 생각하는 것입니다. 예를 들어, 증분("유휴") 게임에서, 플레이어가 획득하는 각 리소스를 항목으로 생각하고 플레이어가 다른 것을 구매할 때마다 총 개수를 늘리는 것이 매력적일 수 있습니다. 하지만 그 모델은 플레이어가 그러한 행동을 취하는 빈도를 계산할 때 빠르게 무너집니다. 즉시, 각 플레이어가 한 세션에서 미터를 수백 번 또는 수천 번 히트하는 것을 처리해야 할 것입니다. 이와 같은 상황에서는 이러한 요소를 User Data로 생각하고 위의 Profile 섹션의 권장 사항을 사용하여 서비스에 업데이트하는 것이 좋습니다.

인벤토리 업데이트 속도가 더 높은 게임의 경우, 데이터 적시성 질문으로 돌아갑니다. 예를 들어, 액션 게임은 플레이어가 가지고 있는 총알의 수를 추적할 수 있지만, 특히 게임 상태가 호스팅된 서버에서 관리되는 경우 그 "스택"의 총알에 대한 백엔드 데이터가 방아쇠를 당길 때마다 업데이트될 필요는 없습니다. Stackables는 항목의 여러 가상 인스턴스를 카운트가 있는 단일 실제 인스턴스로 표현할 수 있으므로 성능 및 비용 이점을 제공합니다. 시간이 지남에 따라 항목 스택에 대한 변경 사항을 집계하고 세션 끝이나 세션 전체에 주기적으로 업데이트할 수 있는 경우가 많습니다. 스택을 업데이트할 때는 [Player Item Management - Modify Item Uses](xref:titleid.playfabapi.com.server.playeritemmanagement.modifyitemuses)를 호출하여 각각 스택에 추가되고 정리되어야 하는 항목의 N 인스턴스를 추가하는 대신 스택의 카운트만 변경할 수 있는지 확인하는 것이 좋습니다.

수집형 카드 게임과 같은 특정 게임 장르는 본질적으로 플레이어 인벤토리를 다소 높은 속도로 업데이트해야 합니다. 하지만 여기에서도 여전히 인벤토리 변경 사항을 집계하고 프로필 미터의 총 사용량을 줄일 기회가 있습니다. 예를 들어, [drop tables](/services/playfab/economy-monetization/economy/tutorials/drop-tables)을 사용하는 게임에서, 디자인은 자주 여러 다른 drop table 각각에서 하나 이상의 "pull"이 있는 컨테이너를 사용합니다. 일반적으로, 이러한 pull이 가끔 하는 액션이라면 증분 비용이 우려를 일으키기에는 너무 작습니다. 하지만 플레이어가 이러한 컨테이너를 많이 수집하고 짧은 시간 내에 여러 개를 열 수 있다면, "N개 열기" 또는 심지어 "모두 열기" 옵션을 제공할 수 있습니다. 이 경우 [Azure Functions를 사용하는 PlayFab CloudScript](/services/playfab/live-service-management/service-gateway/automation/cloudscript-af) 또는 커스텀 게임 서버를 사용하여 drop table 세트에 대해 [Player Item Management - Get Random Result Tables](xref:titleid.playfabapi.com.server.playeritemmanagement.getrandomresulttables)를 쿼리하거나 인벤토리 항목을 생성하지 않고 [Player Item Management - Evaluate Random Result Table](xref:titleid.playfabapi.com.server.playeritemmanagement.evaluaterandomresulttable)을 호출할 수 있습니다. 그러면 필요한 곳에만 인스턴스를 추가하고 나머지 항목 스택의 카운트를 업데이트하여 플레이어 인벤토리를 훨씬 더 효율적으로 업데이트할 수 있습니다.

## Content 및 configuration

Profile이 주로 플레이어에 관한 것이라면, Content and Configuration은 주로 타이틀에 관한 것입니다. Push Notifications, 이메일 서비스, Title News 등 여러 타이틀 수준 구성 요소가 이 미터에 포함됩니다. 또한 이는 Entity File 사용량을 추적하는 데 사용되는 미터이기도 합니다. 마찬가지로, CDN 파일 업로드 및 다운로드용 URL 요청은 이 미터에서 추적되지만, CDN 비용은 별도이며 [Content Delivery Network (CDN)](/services/playfab/data-analytics/legacy/content-delivery-network)에 설명된 대로 다운로드된 총 기가바이트를 기반으로 청구된다는 점을 명확히 하는 것이 중요합니다. Content and Configuration 읽기 및 저장소 미터의 계산은 데이터 크기를 기반으로 한다는 점에서 Profile 미터와 유사하지만, 단위가 1KB보다 훨씬 크다는 것은 분명합니다. Content and Configuration 쓰기 미터의 경우 총 쓰기 작업 수를 기반으로 하며, 각 작업이 미터를 1씩 증가시킵니다.

참고로, Entity File 시스템은 타이틀, 그룹 또는 개별 플레이어와 관련이 있는지 여부에 관계없이 큰 데이터에 권장되는 서비스입니다. 플레이어당 큰 데이터 저장이 있는 게임의 경우, Entity File 시스템은 일반적으로 더 비용 효율적입니다. 다만 해당 업데이트 빈도가 추적되는 사용량에 영향을 미친다는 점을 명심하세요. 필요한 파일 수와 업데이트되어야 하는 빈도를 최적화하는 것이 가장 좋습니다.

Content and Configuration 미터의 비용을 최적화하는 관점에서, 추적해야 할 가장 중요한 것은 타이틀이 자주 변경되지 않는 자체 구성 데이터를 요청해야 하는 빈도입니다. 주로 이는 게임 밸런스/튜닝 데이터, 성취 정의, 지역화 데이터 등과 같이 모든 사용자에게 동일한 게임의 측면을 관리하는 데 일반적으로 사용되는 Title Data입니다.

CloudScript를 사용하는 게임의 경우, 스크립트에 대한 각 호출에 대해 이 타이틀 수준 데이터에 대한 종속성이 있다는 것을 알게 된다면, 해당 데이터를 스크립트에 직접 "굽는" 것을 고려할 수 있습니다. 스크립트 자체에 하드 코딩된 데이터로 정의하거나, 캐싱의 한 수단으로 정적 변수를 사용하여 가상 머신(VM) 인스턴스당 한 번씩 서비스에서 정보를 읽음으로써 이를 수행할 수 있습니다. 이렇게 하면 타이틀 수준 데이터가 특정 VM이 스크립트를 처음 실행할 때 로드되고 후속 실행에서 해당 VM에 의해 재사용됩니다. 여기서 명심해야 할 세 가지가 있습니다: 첫째, 스크립트는 많은 다른 사용자가 사용하므로 실행 사이의 개별 사용자에게 아무것도 일관된 것으로 간주해서는 안 됩니다. 둘째, 단일 플레이어가 각 호출에 대해 서로 다른 머신에 도달할 수 있으므로 데이터 처리는 상태 비저장으로 간주되어야 합니다. 마지막으로, 해당 데이터의 유효 기간을 추적하고 주기적으로 다시 로드하여 최신 버전을 가지고 있는지 확인해야 합니다.

## CloudScript

이는 클라이언트 장치나 서버에서 서버 권한 로직을 실행할 수 있게 하거나 심지어 PlayStream Rules를 통해 트리거할 수 있게 하는(예: 플레이어가 세그먼트에 진입할 때) PlayFab 서비스의 주요 "확장 조인트" 중 하나입니다. 커스텀 게임 서버 호스팅과 달리, 실행당 최소 128MB 및 100ms로 스크립트가 실행되는 기가바이트 초(GB/s)에 대해서만 지불합니다. 따라서 스크립트가 총 250MB의 공간을 사용하는 경우(스크립트 코드와 데이터 사이), 1 GB/s에 도달하기 위해 총 4초 동안(대부분 여러 실행에 걸쳐) 실행해야 합니다.

CloudScript의 사용 사례는 일반적으로 플레이어를 대신하여 조치를 취하는 것을 중심으로 하므로, 프로필 및 콘텐츠/구성 미터에 대한 지난 두 섹션에서 최적화에 대해 생각해야 할 대부분을 다루었습니다. 그러나 타이틀의 총 실행 수는 CloudScript 사용을 미터링하는 일부로도 추적되므로, 플레이어당 CloudScript에 대한 호출을 얼마나 자주 해야 하는지 검토할 가치가 있습니다. 일부 게임의 경우 활성 플레이어를 위한 "핫" 데이터 저장소를 갖기 위해 호스팅된 게임 서버를 사용하는 것이 CloudScript에 반복적인 호출로 데이터 저장소를 관리하려고 하는 것보다 상당히 더 비용 효율적일 수 있습니다.

## Insights

이 미터는 이벤트 수집 및 내보내기부터 Event History 검색 및 Data Explorer 쿼리에 이르기까지 PlayFab 서비스의 모든 분석 기능과 연결됩니다. 여기의 사용량은 이벤트를 얼마나 빠르게 처리해야 하는지, 얼마나 많은 이벤트 데이터를 "핫"(Game Manager의 쿼리용)으로 호스팅하려는지, 그리고 Data Explorer 쿼리 또는 데이터에 직접 연결하는 시각화 소프트웨어를 통해 서비스를 사용하여 데이터를 얼마나 평가하는지에 영향을 받습니다. 이 미터는 게임 내 활동(이벤트)과 게임 외 활동(분석) 모두에 의해 영향을 받습니다.

궁극적으로, 이는 Insights의 비용이 플레이어로부터 얼마나 많은 이벤트 데이터를 받고 해당 데이터에 대해 얼마나 많은 분석 처리를 하는지에 따라 결정됨을 의미합니다. 모범 사례 측면에서, 위의 이벤트에 대한 조언이 전자에 적용되며, 후자의 경우 두 가지 방법으로 비용을 제어할 수 있습니다. 첫째, 가장 간단한 것은 타이틀의 Game Manager에 있는 Insights Management 탭에서 총 저장소를 설정하여 PlayFab에 보관하는 총 이벤트 데이터 양을 제어할 수 있다는 것입니다. 다음으로, 같은 탭에서 타이틀에 대한 성능 수준을 설정할 수 있습니다. 이는 타이틀에 할당되는 총 CPU 리소스 양과 이벤트 히스토리의 쿼리를 위해 얼마나 많은 데이터가 "핫"으로 저장되는지를 결정합니다. 각각 얼마나 필요한지는 데이터 분석 팀 구성원의 요구 사항에 따라 다르므로, 설정이 무엇이어야 하는지 이해하기 위해 그들과 함께 이를 검토하는 것이 가장 좋습니다.

Insights에 대한 정보와 사용 방법은 [What is PlayFab Insights](/services/playfab/data-analytics/legacy/insights/overview)를 참조하세요.

Insights 모범 사례에 대한 정보는 [Best Practices & FAQ](/services/playfab/data-analytics/legacy/insights/best-practices)를 참조하세요.

## Multiplayer 서비스

이는 가격이 완전히 변경되지 않았기 때문에 모든 것 중 가장 간단합니다. 간단히 말해서, 호스팅된 [Multiplayer Servers](/services/playfab/multiplayer/servers)와 [Party 서비스](/services/playfab/multiplayer/networking)는 항상 사용량 기반으로 청구되어 왔습니다.

호스팅된 게임 서버의 경우, 특히 어떤 순간이든 실행되어야 하는 서버 코어 수를 최적화하여 가능한 한 많은 플레이어를 지원함으로써 비용을 최소화할 수 있습니다.

낮은 핑 시간이 해당 서버에 중요하다면, 서버를 실행할 지역을 선택할 수 있습니다. 대부분의 게임의 경우 플레이어의 가장 큰 집중지는 특정 주요 지역으로 제한되지만, 특히 게임의 롱테일에 있는 경우 널리 분산된 플레이어 인구가 있다면, 플레이어 근처의 모든 지역에서 서버를 실행하는 비용 대비 소수의 플레이어가 있는 지역에서 더 긴 핑 시간의 영향을 저울질해야 합니다. 이에 도움이 될 수 있는 한 가지 방법은 [QOS 서비스](/services/playfab/multiplayer/servers/using-qos-beacons-to-measure-player-latency-to-azure)를 사용하여 플레이어를 배치할 지역을 선택하고, 어느 지역이 실행 가능하기 위해 재생되어야 하는 최소 플레이어 수의 컷오프가 무엇인지 결정하는 것입니다.

## 라이브 게임 관리

이것으로 미터의 기본 사항을 다뤘지만, 타이틀이 라이브가 되면 무엇을 고려해야 할까요? 플레이어 커뮤니티 관리는 주로 분석(위 섹션의 [Insights](#insights))과 Content and Configuration 업데이트를 포함합니다. 또한 대부분의 게임은 게임 자체와의 일반적인 상호 작용 외에도 플레이어와 상호 작용해야 합니다. 재참여 캠페인(플레이어가 다시 오도록 유도)에서, 메타 게임 활동에 대한 커뮤니티 보상에 이르기까지, 심지어 게임 외부에서 자신의 커뮤니티 작업에 대해 플레이어에게 감사를 표하는 것까지, 요즘의 일반적인 관행은 [LiveOps](https://playfab.com/liveops/) 기술을 사용하여 플레이어를 매우 참여하게 하는 것입니다.

이에 대한 한 가지 핵심은 세분화를 잘 정의된 그룹으로 효과적으로 대상 지정하여 비용을 낮게 유지할 뿐만 아니라 로직이 빠르게 처리되도록 하는 것입니다. 예를 들어, 플레이어 재참여(어느 정도 기간 동안 게임을 그만둔 후 플레이어가 돌아오도록 하는 것)를 예로 들어 보겠습니다. 이에 접근하는 좋은 방법은 3일, 7일, 21일 동안 플레이하지 않은 플레이어와 같이 여러 lapsed user 기간을 정의하는 것입니다. 각각에 대해 간단한 "we miss you" 메시지로 시작하여 "here's some free gold/energy/etc." 메시지로 끝나는(물론 플레이어 계정에 자동으로 추가되는 것과 결합됨) 재참여에 대한 다른 접근 방식을 취할 수 있습니다. 각각에 대해 권장되는 접근 방식은 플레이어가 마지막으로 게임에 로그인한 시간을 기반으로 1시간 창을 정의하는 것입니다. 그렇게 하면 마지막으로 플레이한 시간을 대상으로 할 뿐만 아니라, 세그먼트의 플레이어 세트를 최소화하여 작업을 가능한 한 효율적으로 수행할 수 있습니다. 각 해당 세그먼트에 대해 매시간 한 번씩 실행되는 Scheduled Task를 사용하여 메시지를 보내고 플레이어 인벤토리에 항목이나 가상 통화(VC)를 추가합니다.

## 요약

궁극적으로, 게임에 필요한 기능이 PlayFab과 같은 백엔드 서비스의 사용량을 결정합니다. 사실, 모든 것은 하나의 포괄적인 질문으로 요약됩니다: 그 기능에 대해 어떤 요구 사항이 있습니까? 보안, 데이터의 적시성, 플레이어 상호 작용/경쟁 수준 또는 완전히 다른 것에 우선순위를 두든, 백엔드 데이터와의 더 높은 수준의 상호 작용으로 밀어붙일 수 있는 여러 요인이 있습니다. 그러한 요구 사항을 비판적인 시각으로 보고 어떤 것이 절대적인 요구 사항이고 어떤 것이 아닌지 식별할 수 있는 것은 게임의 다른 코드의 최적화와 매우 유사합니다. 이는 리소스 활용도가 높은 곳을 주의 깊게 살펴보고 실제로 그럴 필요가 있는지 또는 사용을 줄이기 위해 해당 로직을 재설계할 수 있는 방법이 있는지 결정하는 문제입니다.

상호 작용이 실시간, 플레이어 간이라면 그 상호 작용의 복잡성에 달려 있습니다. 이 유형의 대부분의 게임의 경우, 시뮬레이션 상태를 관리하고 세션 종료 시(또는 세션이 긴 경우 몇 분마다)에만 백엔드 데이터를 업데이트하는 호스팅된 서버가 일반적으로 최상의 솔루션입니다. 하지만 협동 게임이나 친구와만(또는 친구에 대해서만) 플레이되는 게임과 같이 상호 작용이 완전히 신뢰되는 많은 경우가 있어, 부정 행위의 인센티브가 최소화됩니다. 여전히 다른 게임들은 세션의 데이터가 어떻게 확인되어야 하는지에 대해 최소한의 요구 사항만 있어, 서버 측 검사가 두 개를 비교할 수 있도록 각 세션 후에 두 플레이어가 단순히 자신의 보고서를 제출하도록 허용합니다.

실시간 요구 사항이 없는 모든 게임의 경우, 플레이어가 실제로 초 단위 정확도를 필요로 하는지 고려해 보세요. 강력한 커뮤니티 상호 작용이 있는 매우 경쟁적인 게임에서는 그럴 수 있습니다. 하지만 많은 게임의 경우, 몇 분 지난 정보가 플레이어 경험에 영향을 미치지 않습니다.


## Related topics

- [Insights 모범 사례](/ko/services/playfab/data-analytics/legacy/insights/best-practices.md)
- [모범 사례](/ko/services/xbox-services/develop/best-practices/index.md)
- [PlayFab Identity 문서](/ko/services/playfab/identity/index.md)
- [PlayFab Multiplayer 문서](/ko/services/playfab/multiplayer/index.md)
- [PlayFab 데이터 및 분석 문서](/ko/services/playfab/data-analytics/index.md)