Edited at

[勉強会メモ] 白猫プロジェクトの裏側 〜リアルタイム通信と、コロプラのサーバサイドの全貌〜

More than 3 years have passed since last update.

コロプラ × Photon 共催!中の人が語る「リアルタイム通信」の実装

https://atnd.org/events/72402

レポートとは言ってますが、写経ではなく私の中で一旦整理してから書きなおしてます。

ご注意ください。


サーバシステム構成


  • AWS(Amazon Web Services)

  • CACHEサーバ:redis

  • WEBサーバ:Apche&Zend Framework

  • WebSocket:Node.js&Nginx

  • EC2上にMySQL構築。RDSは使わない(ベンダーロックインが怖い)


リアルタイム通信


  • WebSocketでユーザ間通信を実現

  • ユーザ間の表示情報は重要な要素のみ同期する(ボスはしっかり、雑魚は適当)


データ管理


  • ホストユーザ:データ管理する

  • ゲストユーザ:ホストユーザから貰う


ロジック部分


  • Node.js部分は簡単には変更する事が出来ないため、ロジックは実装していない

  • 改修や不具合が発生した場合に対応が難しい

  • Node.jsはDBに命令を積むだけで、実行はバッチが定期的に行う


通信保証


  • ホストからゲストへ重要なデータ送信時には通信保証を行う

  • ゲストは正常にデータ受信した場合はホストに受け取り済みを送信する

  • ホストは受け取り済みを受信するまでデータ送信する

  • ホストは定期的にゲストにPINGして死活検査する


ノーメンテナンス運用


マスタデータ


  • サーバ側とクライアント側の同期が難しい

  • クライアントはサーバに更新が無いか定期的に確認し必要なら更新を行う


不具合


  • 新機能を実装する場合はサーバ側でON,OFFを切り替えれるようにしておく

  • 問題があった場合は機能をクローズする(部分メンテナンス)


サーバ負荷


  • スケールアウト

  • 使用スタミナを減らすと負荷が上がるので注意

  • 重要な局面(CM前など)では徹底的な負荷予測をする

  • 機能ごとに垂直分割し全体が重くなるのを防ぐ


オンラインマスタDB切り替え

マスタの構成を大幅に変更する時や、負荷が重いALTERを実行する場合は、

オンライン状態でマスタDB切り替えて対応する。

詳しい方法は下記サイトが参考になります。

MySQL Casual な生活

http://www.slideshare.net/idhatak/mysql-casual


DBテーブル変更

ALTER TABLEを実行すると共有ロックがかかってしまうため、

更新クエリを実行しても即座に終了せずにタイムアウトになってしまう。

そのため、サービスを停止する必要がある。

下記ツールを使用することで、サービスを停止することなく、

スキーマを変更することが出来る。

Percona Toolkit pt-online-schema-change

https://www.percona.com/doc/percona-toolkit

詳しい方法は下記サイトが参考になります。

Percona Toolkit pt-online-schema-change でサービス無停止スキーマ変更

http://blog.father.gedow.net/2012/10/04/percona-toolkit-pt-online-schema-change/


クライアントバージョンアップ


  • 古いクライアントと新しいクライアントが混在する

  • サーバ側はクライアントバージョンで挙動を切り替える

  • クライアントバージョンが違うクライアント同士はマッチングさせない

  • 知らない機能は無視する(未対応のスキルは無しにしておくなど)

  • アップデートで機能が開放されることは明示しておく