This document is about: SERVER 4

SWITCH TO

SERVER 4 SERVER 5

Frequently Asked Questions

어떤 Photon 제품이 나에게 맞을까요?

이에 대한 답변은 주로 귀하의 프로젝트와 팀에 따라 달라집니다.
일반적으로, 저희는 가장 진보된 클라이언트 솔루션인 Fusion 또는 Quantum을 사용하는 것을 권장합니다.

빠른 개요를 위해 두 제품 시트 모두 제품 선택기 "Quadrant"를 포함합니다:

의문 사항이 있으시면 언제든지 연락주시길 바랍니다.

로드 밸런싱

Photon 룸이 지원하는 플레이어의 최대 수는 몇명인가요?

대부분의 Photon 멀티플레이어 게임은 2~16명의 플레이어를 수용하지만, 룸당 플레이어/피어의 이론적인 제한은 상당히 높을 수 있습니다.
32명 또는 64명의 플레이어가 참여하는 Photon 게임이 실시간으로 진행되고, 가상 회의 시나리오에서는 수백 명에 달할 수 있습니다.
그러나 초당 너무 많은 메시지(방당 메시지/초)를 보내면 데이터를 처리하는 클라이언트의 처리 능력에 따라 성능 문제가 발생할 수 있습니다.
턴제 게임과 같이 플레이어 수가 많은 것은 전혀 문제가 없지만, 빠르게 진행되는 액션 게임에서 플레이어가 32명이 넘으면 관심 관리를 구현해야 할 가능성이 높습니다.
이렇게 하면 모든 플레이어가 다른 플레이어로부터 모든 메시지를 받지 않게 됩니다.

게임 룸 내 데이터 트래픽을 증가시키는 주요 요인은 룸당 플레이어 수입니다.
따라서 객실당 메시지 수를 500개 이하로 유지하는 것이 좋습니다.
Photon은 이러한 제한을 강제하지 않지만, 공정 사용 정책을 따릅니다.
대역폭 사용량을 항상 살펴보는 것이 중요하며, 이를 통해 계획에 포함된 CCU당 3GB의 트래픽 범위를 벗어나지 않도록 할 수 있습니다.

Photon 문자열에는 제한이 있나요?

Photon은 룸 이름, 로비 이름, UserID, 별명, 사용자 지정 속성 키 등의 많은 목적으로 문자열을 사용합니다.

기술적으로, Photon 바이너리 프로토콜은 최대 32,767개의 1바이트 문자까지 문자열을 직렬화할 수 있지만 가능한 한 가장 짧은 문자열을 사용하는 것이 좋습니다.

이름과 사용자 ID의 경우 36자면 충분합니다(예: GUID는 36자입니다).
사용자 지정 속성 키의 경우 오버헤드를 최소화하기 위해 짧은 문자열을 사용해야 합니다.
특히 로비에 보이는 숙박 시설의 경우 이 사항이 중요한데, 이는 객실 목록의 일부로, 객실에 있는 몇몇 고객에게만 전송되는 것이 아니라 로비에 있는 모든 사람에게 전송되기 때문입니다.

사용자 지정 속성의 갯수에는 제한이 있나요?

네, 제한이 있습니다. 각 사용자는 13,000개의 키 값을 설정할 수 있으며, 룸의 총 크기는 500kB를 초과할 수 없습니다.
사용자 정의 속성이 많을수록 클라이언트가 모든 속성을 받게 되므로 클라이언트가 방에 참여하는 데 걸리는 시간이 길어집니다.

Photon을 사용하여 매우 큰 메시지를 보낼 수 있나요?

무엇을 해야 할지 잘 모르는 경우 Photon을 사용하여 대용량 데이터(예: 파일)를 전송하지 않는 것이 좋습니다.
여러분이 교환하는 데이터를 최적화하고, 정말로 큰 메시지를 보내야 하는 경우 저희에게 연락하는 것이 좋습니다.

Photon Cloud에는 클라이언트 버퍼에 대한 서버 측 제한이 있으며, 이는 500KB입니다.
따라서 맥락에 따라 메시지는 다음과 같이 고려될 수 있습니다.

Photon Cloud의 클라이언트당 버퍼 크기가 500KB를 초과하면 "너무 큽니다". 클라이언트가 짧은 시간 내에 이 한계에 도달하면 서버에서 연결이 끊어집니다.
UDP로 전송하기에는 "너무 커서" 100KB가 넘는 조각으로 인해 문제가 발생할 수 있습니다.
여러 개의 UDP 패킷으로 분할하지 않고는 전송하기에는 "너무 큽니다" > 1.2KB(프로토콜 오버헤드 포함).

매우 정기적으로(1초에 10회 이상) 전송되는 메시지의 경우 크기를 1KB 미만으로 유지하는 것이 좋습니다.

메시지가 거의 전송되지 않는 경우(예: 경기 시작 시 한 번 전송)에는 여러 KB 크기가 괜찮지만, 여전히 10KB 미만으로 유지하는 것이 좋습니다.

더 큰 메시지는 별도의 Enet 채널(UDP)로 전송할 수 있으며, 이렇게 하면 다른 채널(상태 동기화)에 미치는 영향이 줄어듭니다.

대용량 파일의 경우 별도의 백엔드를 사용하는 것을 고려하세요.

어떤 데이터가 신뢰성있게 전송되며 신뢰성 없게 전송되는 데이터는 어떤것입니까?

무엇보다도, 프로토콜이 UDP인 경우에만 신뢰성이 있다는 것을 알아야 합니다.
TCP에는 여기에서 다루지 않고 있는 TCP 자체의 "신뢰성" 메커니즘이 있습니다.

신뢰성 있게 전송한다는 것은 목표한 곳에 도착한다는 것을 확신한다는 것 입니다.
따라서 충분한 시간을 기다린 후에 잘 받았다고 회신을 받지 못한 경우에는 확인을 받거나 받을 때까지 다시 보냅니다.
또한 신뢰할 수 있는 이벤트를 반복하면 지연 시간이 길어지고 이후의 이벤트가 지연될 수 있습니다.

신뢰성을 사용하지 않은 예제:

실시간 게임에서 플레이어의 위치 변경
음성 또는 동영상 채팅

신뢰성을 사용한 예제:

턴 기반 게임의 턴 이벤트

게임에서 왜 자주 끊기나요?

연결해제는 다양한 원인에 의해서 발생될 수 있습니다.
이 문제에 관련된 사항에 대해 두 가지의 문서가 있으니 도움이 될 것 입니다:

"연결해제 분석"

초당 메시지 룸당 메시지는 어떻게 계산되나요?

Photon 서버는 초당 총 인바운드 및 아웃바운드 메시지 수를 세고 전체 룸 수(동일한 마스터 서버에 있음)로 나눕니다.

모든 오퍼레이션 요청, 오퍼레이션 응답 또는 이벤트는 메시지로 간주됩니다.
Photon 오퍼레이션은 선택적인 오퍼레이션 응답을 반환하고 0개 이상의 이벤트를 트리거 합니다.
캐시된 이벤트도 메시지로 계산됩니다.

룸 오퍼레이션에서의 메시지 비용:

오퍼레이션	성공: 최적	성공: 평균	성공: 최악
Create	2 (SuppressRoomEvents=true)	3 + Join 이벤트 (SuppressRoomEvents=false, default)	4 + ErroInfo 이벤트 (HasErrorInfo=true)
Join	2 + k (SuppressRoomEvents=true) + k * 캐시된 커스텀 이벤트	2 + n + k + n * Join 이벤트 (SuppressRoomEvents=false, default)	*2 + 2 n + k** + n * ErroInfo 이벤트 (HasErrorInfo=true)
Leave	2 (SuppressRoomEvents=true)	1 + n + (n - 1) * Leave 이벤트 (SuppressRoomEvents=false, default)	*2 + (n - 1) 2** + (n - 1) * ErroInfo 이벤트 (HasErrorInfo=true)
RaiseEvent	1 (오퍼레이션 응답 없음) (타겟: 구독자가 없는 관심 그룹)	1 + n + n * 사용자정의 이벤트 (타겟: 모두/브로드캐스트)	*2 + 2 n** + n * ErroInfo 이벤트 (HasErrorInfo=true) + Auth 이벤트 (토큰 리프레시)
SetProperties	2 Broadcast=false	2 + n + n * PropertiesChanged 이벤트 (Broadcast=true, 기본)	*2 + 2 n** + n * ErrorInfo 이벤트 (HasErrorInfo=true)

사용자가 사용한 트래픽을 어떻게 계산하나요?

이는 매우 복잡한 주제입니다.
먼저, 계산 값은 이론적으로 추정한 값일 뿐이며 실제와는 다를 수 있다는 것을 아셔야 합니다.
Proof-of-Concept를 구축하고, 이를 사용하여 실 데이터를 수집하는 것을 권장해드립니다.

여기서 언급한 것은 룸 안에서 한명의 사용자가 생성한 트래픽을 추정하는 방법입니다.

다음을 가정해보겠습니다:

룸안에는 N명의 플레이어가 있습니다.
한 명의 플레이어가 초당 F개의 메시지를 전송합니다 (메시지 전송률은 Hz)
평균 메시지 크기는 X 입니다(바이트 단위, 페이로드(payload, P) + 프로토콜 오버헤드(O))
평균적으로 플레이어는 한달동안 이 게임을 H시간 플레이합니다.

ACK, 연결 처리(설정, 활성 상태 유지 등)명령과 재전송을 고려하지 않았습니다.
그러면 게임은 평균적으로 다음과 같이 CCU는 게임의 C(바이트/월)를 사용합니다.

C = X * F * N * H * 60 (분) * 60 (초)

방 연결이 끊긴 후 빨리 다시 참여하려면 어떻게 해야 하나요?

방에 참가하는 동안 예상치 못한 연결 끊김으로 인해 복구하려면 클라이언트가 다시 연결을 시도하여 방에 다시 참가할 수 있습니다.
우리는 이것을 "빠른 재입장"이라고 부릅니다.
빠른 재입장은 다음과 같은 경우에만 성공합니다.

방이 여전히 같은 서버에 존재하거나 로드될 수 있음:
플레이어가 방을 나가더라도 다른 플레이어가 계속 참여해 있다면 그 플레이어는 Photon 서버에서 살아남을 수 있습니다.
플레이어가 마지막으로 나가고 방이 비어 있으면 EmptyRoomTTL은 플레이어가 참여하거나 다시 참여하기를 기다리면서 방이 살아 있는 시간입니다.
EmptyRoomTTL 이후에도 룸이 비어 있고 아무도 참여하지 않으면 해당 룸은 Photon 서버에서 제거됩니다.
지속성 조건이 충족되고 웹훅이 설정된 경우, 룸 상태를 구성된 웹 서비스에 저장하여 나중에 로드할 수 있습니다.
액터가 비활성으로 표시됨: 동일한 UserId를 가진 액터가 액터 목록 내에 있지만 현재 룸에 참여하지 않은 경우입니다.
이렇게 하려면 PlayerTTL이 0이 아니어야 합니다.
비활성 액터의 PlayerTTL이 만료되지 않았습니다. 액터가 돌아올 수 있는 옵션과 함께 방을 나갈 때 비활성화 타임스탬프를 저장합니다.
방이 활성화되어 있는 한, 비활성화 시간 후에 PlayerTTL 밀리초가 경과하면 해당 액터는 액터 목록에서 제거됩니다.
그렇지 않은 경우, 액터가 재참여를 시도할 때 재참여 시도 시간과 비활성화 시간 사이의 밀리초 차이가 PlayerTTL을 초과하면 액터는 액터 목록에서 제거되고 재참여는 실패합니다.
따라서 비활성적인 행위자는 비활성화 시간 후 PlayerTTL 밀리초 동안만 룸에 다시 참여할 수 있습니다.

A "빠른 재입장"은 두 단계로 구성됩니다.

Reconnect: 연결이 끊어지면 적절한 연결 방법을 호출하기만 하면 됩니다.
Rejoin: loadBalancingClient.OpRejoin(roomName)을 호출합니다.

자체 호스팅

리눅스에서 Photon Server를 실행할 수 있나요?

아니오.
Photon Server는 윈도우즈용입니다.
상세내용은 "요구사항" 을 읽어주십시오.

Amazon에서 Photon Server를 어떻게 호스팅하나요?

Amazon에서 Photon Server를 호스트하는 절차입니다:

새로운 윈도우즈 서버 EC2 인스턴스를 설정합니다

Amazon Web Services 계정을 생성합니다.
AWS 포털에 로그인 합니다.
"Service -> EC2"로 이동합니다.
"Create Instance" 섹션의 "Launch Instance"를 클릭합니다.
Photon Server에서 지원하는 Microsoft Windows Server edition을 "선택" 버튼에서 클릭합니다.
"Choose an Instance Type" 이후 "6. Configure Security Group"으로 이동합니다
new security group "Photon Server" 생성하여 이 페이지에 나와있듯이 수신 포트를 허용합니다.
"Review and Launch"를 클릭하고 검토 및 "실행"합니다.
키 페어를 기존 것을 선택하거나 생성합니다.
확인 토글을 선택하고 "Launch Instances"를 누릅니다.
"View Instances"를 클릭하고 인스턴스가 초기화를 마칠때까지 대기합니다.

새로운 인스턴스에 RDP 연결

EC2 인스턴스를 선택합니다.
"Connect" 클릭합니다.
"Get Password"를 클릭합니다.
개인키를 업로드하거나 내용을 복사하후 "Decrypt Password"를 합니다.
"Download Remote Desktop File" 을 클릭하여 RDP 바로가기를 얻습니다.
바로가기를 더블 클릭하여 원격 머신에 연결합니다.
자격증명을 입력하여 로그인합니다.

Photon Server SDK 설정

Photon 계정을 생성합니다.
Photon Server SDK를 다운로드합니다.
패키지를 풀고 원격 머신에 파일들을 복사합니다.
Photon Control을 시작합니다.
서비스로 Photon을 설치합니다
Photon 서비스를 시작합니다.

Windows 방화벽에서 필요한 포트 열기

플러그인 SDK와 서버 SDK의 차이점은 무엇인가요?

두 패키지 모두 동일한 바이너리("deploy" 폴더)와 라이브러리("lib" 폴더)를 제공하지만 다른 소스 코드 프로젝트("src-server")를 제공합니다.
Photon Server SDK는 Photon Server를 자체 호스팅하고 Photon Server 애플리케이션을 개발하는 데 사용할 수 있습니다. 내부 소스 코드는 서버 애플리케이션의 예입니다.
Photon Plugins SDK는 Photon Server를 자체 호스팅하고 사용자 정의 Photon Server 플러그인을 개발하는 데 사용할 수 있습니다. 내부 소스 코드는 플러그인 예제용입니다.

스레딩

단일 Photon server에서 쓰레드는 몇 개나 수행되나요?

쓰레드의 사용은 분리됩니다:

네이티브 - 9 개 쓰레드
매니지드 - .NET 기본 설정을 사용하는 .Net ThreadPool 에 의존함

이 설정은 상당히 집중적으로 테스트되었으며 다양한 부하 프로파일에 매우 적합합니다.

매니지드 쓰레드의 사용은 (.NET Windows Performance counters에서 보고된 것처럼) 다양합니다:

a) 전형적인 Photon cloud RealTime 부하에서 ~12
b) 클라이언트 클라우드가 플러그인 간 통신(잠금)을 통해 플러그인을 실행함으로써 (우리의 코드와 달리) 일부 더 높은 경합이 발생하는 곳에서 35 (및 그 이상)

노트: 필요에 따라, .Net ThreadPool 설정은 조정될 수 있습니다.
지금까지 기본값은 각 버전마다 다를 수 있지만 좋은 결과를 얻었습니다.

경쟁 조건 및 기타 멀티스레딩 문제를 방지하려면 어떻게 해야 하나요?

Photon에서는 가능한 한 모든 것을 단순화했습니다.

모든 스레드에서 PhotonPeer 메서드를 사용할 수 있습니다.
PhotonPeer의 모든 알림은 하나의 파이버에서 실행됩니다(아래 파이버에 대한 내용을 읽어보세요).
한 방의 모든 작업은 하나의 파이버에서 실행됩니다.
피어는 멀티스레딩 문제로부터 데이터를 보호하기 위해 룸의 파이버로 메시지를 보냅니다.

파이버는 FIFO 방식으로 순차적으로 하나씩 실행되는 작업 목록입니다.
이는 하나의 스레드에서 실행된다는 것을 의미하지 않습니다.
실제로 이러한 작업은 여러 스레드에서 하나씩 실행됩니다.
따라서 첫 번째 작업은 스레드 A에서 실행되고, 완료되면 두 번째 작업은 스레드 B에서 실행됩니다.
하지만 매 순간에 방 데이터에 접근하는 스레드는 단 하나뿐입니다.
여러 개의 파이버가 동일한 데이터에 접근하는 경우 잠금을 사용합니다.
예를 들어, 방의 캐시에 넣어두는 것과 같습니다.

다음과 같이 섬유를 사용할 수 있습니다.

// rooms contructor
someFiber = new PoolFiber(); // create new fiber
someFiber.Start();
someFiber.ScheduleForInterval(someRepetitiveRoutine, 0, 100); // start immediately and repeat every 100 ms, ie 10 times per second. this params may vary as you need
// at some other point, where you need to add more logic to the fiber
someFiber.Enqueue(newTask);
someFiber.Enqueue(()=>{ anotherTask(parameters);});
// from the tasks you can send messages to the room e.g. to notify the room of a result of a task
room.EnqueueMessage(new YourCustomMessage(somethingToSend));

동일한 코드나 동일한 데이터를 공유하는 여러 개의 사용자 정의 파이버를 사용하는 경우 서로 다른 파이버의 작업이 동시에 실행되므로 액세스를 동기화해야 합니다.

Logging

클라이언트가 연결하거나 연결을 끊을 때마다 로그는 어떻게 생성하나요?

어플리케이션의 "log4net.config"에 아래 내용을 추가합니다:

XML


<logger name="Photon.SocketServer.ApplicationBase">
    <level value="DEBUG"/>
</logger>

"{MyApplication}.log"의 출력내용:

Successful connect:

2013-05-02 11:19:02,506 [23] DEBUG Photon.SocketServer.ApplicationBase [(null)] - OnInit - ConnID=17, IP 127.0.0.1 on port 4530
2013-05-02 11:19:02,506 [23] DEBUG Photon.SocketServer.ApplicationBase [(null)] - OnInit - response sent to ConnId 17 with SendResult Ok

Disconnect:

2013-05-02 11:19:07,608 [24] DEBUG Photon.SocketServer.ApplicationBase [(null)] - OnDisconnect - ConnID=17

Photon이 클라이언트에 작업 응답을 보낼 때 어떻게 로그를 생성하나요?

어플리케이션의 "log4net.config"에 아래 내용을 추가합니다:

XML


<logger name="Photon.SocketServer.PeerBase">
    <level value="DEBUG"/>
</logger>

"{MyApplication}.log"을 출력내용:

2013-05-02 11:19:02,569 [21] DEBUG Photon.SocketServer.PeerBase [(null)] - SentOpResponse: ConnID=17, opCode=255, return=0, ChannelId=0 result=Ok size=14 bytes

How to write a log entry when Photon receives an operation request from a client?

This kind of logging is best done in your application's Peer class (which inherits from HivePeer).

XML


<logger name="Photon.Hive.HivePeer">
    <level value="DEBUG"/>
</logger>

Output from "{MyApplication}.log":

2013-05-02 11:19:02,553 [21] DEBUG Photon.Hive.HivePeer [(null)] - OnOperationRequest. Code=255

OnOperationRequest 메소드에서 로그 항목의 내용을 변경할 수 있습니다.

protected override void OnOperationRequest(OperationRequest operationRequest, SendParameters sendParameters)
{
    if (log.IsDebugEnabled)
    {
        log.DebugFormat("OnOperationRequest. Code={0}", operationRequest.OperationCode);
    }    
    // snip
}

클라이언트들이 왜 연결이 끊어질까요? 타임아웃은 어떻게 디버깅을 하나요?

클라이언트의 연결이 끊기는 이유를 확인하려면 피어에서 OnDisconnect가 호출될 때 디버그 로그 항목을 작성하도록 어플리케이션을 구성합니다.

XML


<logger name="Photon.Hive.HivePeer">
    <level value="DEBUG"/>
</logger>

Peer 클래스(HivePeer에서 상속됨)에서 , OnDisconnect() 메소드는 다음의 코드와 같아야합니다:

protected override void OnDisconnect(DisconnectReason reasonCode, string reasonDetail)
{
    if (log.IsDebugEnabled)
    {
        log.DebugFormat("OnDisconnect: conId={0}, reason={1}, reasonDetail={2}", this.ConnectionId, reasonCode, reasonDetail);
    }
    //     
}

"{MyApplication}.log"의 출력 내용:

2013-05-02 11:19:07,639 [12] DEBUG Photon.Hive.HivePeer [(null)] - OnDisconnect: conId=17, reason=ClientDisconnect, reasonDetail=

If you are using UDP: in case of "TimeoutDisconnect", the "reasonDetail" will contain the RoundTripTime history, like this:

index - sequence - rtt - variance - sentTime - recvTime - cmd_rtt

0 - 326 - 0 - 0 - 830717056 - 830728351 - 11295
1 - 325 - 89 - 19 - 830715918 - 830716042 - 124
2 - 324 - 85 - 14 - 830714826 - 830714904 - 78
3 - 323 - 86 - 17 - 830712751 - 830712813 - 62
4 - 322 - 89 - 14 - 830711659 - 830711737 - 78
5 - 321 - 90 - 16 - 830710551 - 830710645 - 94
6 - 320 - 90 - 19 - 830709428 - 830709537 - 109
7 - 319 - 88 - 19 - 830708320 - 830708414 - 94
8 - 318 - 88 - 23 - 830707197 - 830707306 - 109
9 - 317 - 86 - 24 - 830706105 - 830706183 - 78
10 - 316 - 87 - 29 - 830704701 - 830704763 - 62
... etc ...

각 라인은 다음들의 값으로 구성되어 있습니다:

인덱스 (0...49, 0이 가장 최신이고 49는 가장 오래된 것입니다. 최신의 50개 항목만 보여집니다.)
시퀀스 - 증가하는 일련번호
rtt (RoundTripTime - ms로 현재 RTT - ACK 또는 타임아웃이 발생 처리된 이후 사용가능)
variance (ms 로 현재 Variance)
sentTime (명령이 전송된 시간)
recvTime (ACK가 수신된 시간)
cmd_rtt (ms 단위로 명령이 전송되고 ACK가 수신된 시간 사이의 간격)

위의 예에서 클라이언트는 62ms에서 124ms 사이에 cmd_rtt를 가지고 있었습니다. 마지막 명령에 대해 11초 동안 ACK를 수신하지 않은 후 연결이 끊어졌습니다.

과금

학생, 취미자 또는 인디 개발자를 위한 특별 제안이 있나요?

저희의 모든 제품에는 프리티어와 일회 지불하는 가격 정책이 있습니다.
또한 우리는 Unity 에셋 스토어에서 판매를 하고 있으며 때로는 바우처를 제공해드립니다.

Photon 애플리케이션 하나에 대해 100 CCU 플랜을 하나 이상 결합할 수 있습니까?

아니오.
100 CCU 플랜은 겹쳐서 사용할 수 없으며 AppId당 딱 한 번만 적용할 수 있습니다.
여러개의 PUN+ 에셋 시트를 구입한 경우 AppId 별로 100 CCU에 대해 리딤해주어야 합니다.
단일 앱에 대해 더 많은 CCU가 필요한 경우, 다음으로 높은 요금제는 500 CCU입니다.
월간 또는 연간 플랜에 가입한 경우, 월간/연간 플랜의 CCU에 추가로 12개월 동안 100 CCU가 유지됩니다.

Photon 플랜에 얼마나 많은 트래픽이 포함되어 있나요? 앱에서 포함된 한도를 넘는 트래픽을 생성하면 어떻게 되나요?

Photon Public Cloud 및 Premium Cloud 플랜에는 CCU당 3GB가 포함됩니다.

예를 들어, 1,000개의 CCU를 갖춘 월간 요금제에는 월 3TB의 트래픽이 포함됩니다.

앱이 더 많은 트래픽을 생성하면 자동으로 이메일을 통해 알림을 보냅니다. 매월 말에 Photon 계정 이메일 주소로 자동 생성된 초과 청구서를 받게 됩니다. 청구서 금액은 다음 계산을 기반으로 합니다.

총 트래픽 - 포함 트래픽 = 초과 트래픽(GB)

트래픽은 사용된 Photon Cloud 지역에 따라 GB당 90원/180원으로 계산되고 추가 청구됩니다.

Photon Cloud 플랜의 구독한 CCU를 피크 CCU가 초과하면 어떻게 되나요?

500 CCU / 1,000 CCU / 2,000 CCU 플랜에 가입한 경우, 애플리케이션에 대해 "CCU 버스트"가 자동으로 활성화됩니다. Photon Cloud는 사용자에게 최상의 경험을 제공하기 위해 예약한 것보다 더 많은 CCU를 허용합니다.

버스트가 시작되면 합의된 조건에 따라 48시간 이내에 필요한 구독 등급으로 업그레이드해야 합니다.

업그레이드하지 않으면 Photon 계정 이메일 주소로 "초과 청구서"를 보내고 구독한 플랜을 초과하는 각 CCU에 대해 CCU당 1350원/1400원/1800원(사용된 SDK 기준)의 수수료를 청구합니다.

Photon은 "피크 CCU"는 해당 달에 합산된 지역별 피크 CCU의 합계입니다. 피크에 도달한 후 사용량이 감소하더라도 초과 요금을 피하기 위해 업그레이드해야 합니다.

로드 밸런싱
자체 호스팅

스레딩
Logging

과금