Posted by はじめに
この記事はGRIPHONE Advent Calendar 2020 5日目の記事です。
こんにちは。クライアントの鈴木です。今回はリアルタイムチャットを導入するため、Photon Chatについて調べてみることにしました。本記事はそのまとめになります。Photon Chatのドキュメントには記述されていないことや、問い合わせで直接聞いた最新の情報などもまとめているので、これからPhoton Chatを使用しようとしている方はぜひ参考にしていただければと思います。
Photon Chatを使用する上での注意点
Photon ChatとはExit Gamesがグローバルに展開しているサービスで、リアルタイムチャットの基本的な機能を提供してくれます。5000CCU(CCUは同時接続数)以上のプロダクトでの採用もされており、実績のあるサービスです。
プロダクトへの導入も簡単で、チャットサーバー側の実装をあまり意識することなくチャットの実装ができます。
さらに、下記のように様々な機能を提供してくれています。
- パブリック/プライベートチャンネルでのチャット機能
- プライベートチャンネルの暗号化
- チャンネルごとのメッセージ履歴取得
- Webhook
- メッセージフィルタリング
- チャンネル人数制限/人数取得
- フレンド機能/オンラインステータス更新
- 様々なプラットフォームで対応
しかし、Photon Chatではできないこともあり、いくつか注意しなければならない点もあります。
チャンネルごとのメッセージ履歴取得
Photon Chatではチャンネルごとにメッセージ履歴を取得することができます。ただし、履歴は揮発性であり、以下に気を付ける必要があります。
チャンネルに所属しているユーザーが0人になるとチャンネルに投稿されたこれまでのメッセージ履歴が数秒後に消える
この対策についてPhoton側はWebhookを使用することによる解決方法を提案しています。
Webhookについて
Webhookを使用してチャンネルの作成やチャット投稿の情報をPhoton Chatサービスから他サーバーに送ることができます。例えばチャット投稿の情報をPhoton Chatサービスから自社サーバーに送り、自社サーバーからPhoton Chatサービスへのレスポンスでメッセージを書き換えることができます。もちろん、その場合は該当チャンネルに所属しているユーザーに書き換えられたメッセージが届きます。
この機能を使用して自社のDBに過去ログを保存しておくことができます。ただし、以下の点に気を付けなければなりません。
チャットの投稿でWebhookを使用する場合、サーバーのレスポンスを待ってからチャンネルに所属しているユーザーに投稿されたメッセージが反映される
つまり、Webhookを使用する場合、構成によってはサーバーのレスポンスが遅いと、端末にメッセージが届けられるのが遅くなってしまいます。
人数制限をしないことによる利用料金の増加
Photon Chatではチャンネルごとの人数制限はありません。しかし、このことが利用料金に影響する可能性があります。
Photon Premium Cloudの料金プランでは1CCUあたりの転送量上限が決まっています。その上限を突破する場合は追加の課金が必要になります。この転送量というのはチャンネルに投稿する送信量/投稿されたメッセージを配信する受信量両方が含まれます。
チャンネルを購読しているユーザーにメッセージを配信している図
当然ですが、ここで以下に注意する必要があります。
チャンネルに所属しているユーザー数が多いほど投稿されたメッセージを配信する転送量も多くなる
チャンネルに人数制限を設けないと、転送量が想定以上に多くなり、追加の課金が必要になる可能性があります。個人的にはチャンネルごとの人数制限を行うことをおすすめします。人数制限の設け方は次の項目で説明します。
チャンネル人数制限/接続人数取得
Photon Chatの機能でチャンネルの人数制限やそのチャンネルに現在接続している人数の取得をすることができます。そのチャンネルに接続している人数を取得する場合はPublishSubscribersをオンにする必要があります。
https://doc.photonengine.com/ja-JP/chat/current/reference/userids-and-friends
ただし、この機能を使用した場合以下の点に気を付ける必要があります。
接続人数を取得する場合は、チャンネル毎の最大接続数に設定出来る値の上限がChatClient.DefaultMaxSubscribers(定数)になる
購読していないチャンネルの人数は取得できない
接続人数を取得できる機能を使用しなければチャンネルの人数制限は何人でも可能ですが、何人が接続しているか知りたい場合には1チャンネルにつきChatClient.DefaultMaxSubscribersよりも多くの人数制限を設定することができません。接続人数を取得する場合は最大接続数に設定できる値に定数で制限がかかることに気をつける必要があります。
また、Photon Chatでは購読していないチャンネルの人数は取得できません。このことは以下のリンクでも話されています。
https://forum.photonengine.com/discussion/14978/get-of-subscribers-in-room-without-joining-the-room
例えば全チャンネルの入室人数が一覧で見れるようなUIを作りたい場合は、全チャンネルを購読して入室人数を取得しようとしてしまうかもしれません。しかし、全チャンネルを購読すると転送量が大きくなってしまう可能性があるため、注意する必要があると考えています。実際にプロダクトに導入する場合は、一瞬購読してすぐに購読をやめることで更新タイミングを制御することで解決しようと考えています。
ちなみに、(現時点では)Photon Chatのドキュメントでチャンネルごとの人数制限やチャンネルに所属しているユーザー数の取得機能がまだ使用できないと記述されていますが、問い合わせしたところ、現ドキュメントが古く、実際にはすでに使用可能とのことです。
様々なプラットフォームに対応
Photon Chatは様々なプラットフォームで使用ができ、IOS/Androidだけでなく、WebGLにも対応しています。ただし、Appleの審査では気を付ける必要がありそうです。
UDP通信によるAppleStore審査リジェクト
Photonでは一部でUDP通信を使用しています。これによりAppleStoreの審査をリジェクトされた事例があります。
https://forum.photonengine.com/discussion/7702/ipv6-for-unity-ios-exports/p5
PhotonのサービスのPUN2ではこの対策として、NameServerへの接続が失敗したときに他のプロトコルへのフォールバックを可能にしています。しかし、この機能はPhoton Chatサービスには実装されていないため、同じように対策するには自分で実装する必要があります。
自社サーバー(PHP)からAPIをたたきたい場合
Photon ChatではPHPのSDKを提供していません。なのでPHPから直接APIをたたくことはできません。PHPが自社サーバーの場合、APIをたたいてチャンネルを作成したり、システムメッセージを投稿したりすることは基本的には難しくなります。
しかし、企画からは下記のようなシステムメッセージの投稿をできるようにして欲しいという要望がありました。
「XXさんが〇〇を獲得しました」などのユーザー行動に紐づくシステムメッセージは同じタイミングで配信したい
全チャンネル向けのシステムメッセージはリアルタイムでなくてもよいが、チャットに表示したい
これに対して、下記のような方針を考えました。
全チャンネル向けのシステムメッセージはPhoton Chatを介さず、自社サーバーとクライアント間の通信で投稿欄にメッセージを挿入する
ユーザー行動に紐づくシステムメッセージは行動元のクライアントがPhoton Chatにシステムメッセージを投稿する
全チャンネル向けのシステムメッセージに関しては投稿欄にメッセージを挿入するだけで、チャンネルのほかのユーザーには表示されません。しかし、ユーザー行動に紐づくシステムメッセージは行動元のクライアントが自分で投稿することで、ほかのユーザーにも投稿と同じタイミングで配信することができます。
ユーザー行動に紐づくシステムメッセージ
以上のような方針をとることで、工夫して要件を満たすことができました。
テスト環境を作りたい場合
Photon Chatでは1アカウントで25個までアプリを登録することができます。そしてPhoton Chatアプリごとに課金設定を行います。テスト環境を用意する際、本番と同じ環境を使用したくない場合は、テスト環境と本番環境で別々のPhoton Chatアプリに接続することになると思います。そこで、テスト環境が26個以上ある場合にどうすればよいか問い合わせたところ、アカウントを複数作成することをおすすめされました。
ちなみに、複数のフリープランのPhoton Chatアプリを1つのアプリケーションに使用する方法はPhoton側で禁止されているようです。
おわりに
外部のサービスを使う場合はサービス側の仕様に従う必要があります。そのため、要件を満たせない場合は別のサービスを使用するか、もしくは工夫して要件を満たすか、そもそも要件定義を再定義しなおすかする必要があります。コストや効果を天秤にかけて、プロダクトに一番最適なものは何かを考えるときに、この記事が検証期間の短縮に役立つことができれば幸いです。
