皆さんこんにちは。ソニー・ミュージックソリューションズでWebアプリケーション開発に携わっているじつげつです。今回は自分が担当したチャットシステムの技術選定について書いていきたいと思います。
チャットシステムについて
ここで言う「チャットシステム」とは、弊社で運用しているライブ配信サービスなどで提供されているユーザー向けのチャット機能になります。この機能自体は以前からあったのですが、利用コストが高かったり、運用負荷が高かったりといったいくつか問題点があったため、アーキテクトから見直し、新たに作り直すことになりました。
過去のチャットシステムの問題点
実は今回の改修の前にもチャットシステムの刷新を行ったことがあります。
最初に使っていたチャットシステムは外部のSaaSを利用したものだったのですが、費用や同時接続数の点で課題がありました。そこで、そうした課題を解決すべく自前でシステムを構築したのですが、納期の問題などからサービスインを優先したため、運用コストが高くなってしまっていました。準備の際に手動でAmazon EC2を必要台数起動する必要があるのですが、サーバーの管理を外部に委託していたため、そのつど作業費用が発生してしまっていたのです。
新しいチャットシステムの要件
そうした課題を受け、新しいチャットシステムでは以下のように要件を設定し、構成や利用する技術の選定を開始しました。
- 管理画面から配信で利用できるチャットの設定を行える
- 接続情報を管理画面から確認できる
- 配信規模を管理画面で設定することで、自動でサーバーをスケーリングできる
- 性能要件は先述の自前で構築したチャットシステムと同等とする
- 運営からの通知や、ユーザーBANなどの新たな機能を追加する
- 投稿されたコメントや接続数などを管理画面から確認できる
新しいチャットシステムで使っている技術
以下は新しいチャットシステムの機能と、システム構成図です。
- HTTPS通信とWebSocketのハイブリットでの実装
- ユーザーチャットの投稿・受信
- HTTPS通信によるREST APIへの投稿とポーリングでの取得
- アーティストが投稿するメッセージ
- 運営からの通知
- メッセージの削除やユーザーBAN
- AWS AppSyncを利用したWebSocketによる通信
使用している技術の決定まで
新しいチャットシステムの実装は以下のような流れで進めています。
PoCの実施
技術選定にあたり、選定したものが性能要件を満たすかを確認するためにプロトタイプを作成しPoCを実施しました。 この時点ではユーザーメッセージを含めたすべての通信を、AWS AppSyncを利用したWebSocketでの通信で実装していました。しかし、いざPoCを実施してみたところ、想定される規模の同時接続数があった場合にAWS AppSyncの利用料が膨大になってしまうことが判明し、技術選定からやり直すこととなりました。
なおこの際、事前に利用料の概算を出す工程を飛ばしてしまったために、実際に稼働させてからAWS Cost Explorerで確認して慌てて止めるという事態になってしまったのは大きな反省点でした（金額は書けないのですが、目玉が飛び出るくらいにはなりました……）。
選定のやり直し
技術選定をやり直し、AWSさんにも相談しつつ構成を再検討した結果、大量の同時接続と、メッセージの投稿・受信が発生するユーザーのチャットはHTTPS通信でREST APIをコールする方式、よりリアルタイム性が求められ、メッセージのやり取りが多くなりにくい、アーティストのチャットや運営からの通知、ユーザーBAN、メッセージ削除についてはAWS AppSyncを利用したWebSocket通信によって行うハイブリット方式に決定しました。
ハイブリッドにするメリットとして、メッセージ取得はAPIに対してポーリングによるリクエストにすることで、Amazon CloudFrontでキャッシュ時間をポーリング間隔に合わせることで高負荷に強くできること、AWA AppSyncによる経路も用意することで、ポーリングでは実現しにくい即時性のあるメッセージを送信できることなどが挙げられます。
実装～運用
使用する技術が決まった後、いよいよ設計・実装に入り、細かい機能要件・非機能要件定義を行っていきました。下表はそのうち非機能要件を一部抜粋してまとめたものです。
また同時接続数の見込みに応じてサーバーリソースを自動で調整する機能の調整と実装内容で想定した負荷に耐えられるかの負荷試験を実施しました。
流れとしては
- 同時接続数を段階に分けて負荷をかけサーバーリソースの適切な値を確認
- リソース調整のための計算式を決定
- 想定される最大規模の負荷をかけて負荷試験を実施
の流れで実施しました。
実装・テストが完了し、実際に運用を行ったところ、管理画面で操作が完結し、インフラの設定作業を自分たちで行えるようになったこと、サーバーリソースを効率的に増強・縮退ができるようになったことなどから、ランニングコストの低下が確認できました。
まとめ
今回の記事はライブ配信で利用するチャットシステムの刷新を技術選定から行ったという内容でしたが、当時は新型コロナ禍ということもあってライブ配信への需要が大きかったタイミングでもありました。ライブ配信の特性上、障害で止められないということが多いので最初から大規模配信を念頭に技術選定を行い、結果としてうまく動くものができたと思っています。
今回の取り組みを通して、やはり下調べや準備が重要だなと改めて実感させられました。また、当初予定していた方式が、コスト面で適さないという予想外の事態からハイブリットでの実現に切り替えたことからは、改めて実現方法は一択ではないのだなと思い知らされました（コスト面の試算はほんとに大事……）。
この記事が同じく、Webアプリケーションの開発に携わっている皆さんの何かの参考になれば幸いです。
