ソーシャルゲームを開発したときに学んだこと

はじめに

けっこう前の話になるのだが、初めてソーシャルゲーム案件の開発をしたときの話です
ちょうどmixiアプリがリリースされたときの話でそれまではサービスがオープンしてから時間をかけて大きくなってゆきシステム的にボトルネックとなっている箇所を調査して修正する。という流れでした。

しかし、ソーシャルゲーム開発については全然話が違ってリリース直後にアクセスが集中するという経験したことがない様な負荷を体験したことを覚えています。今でこそネットにノウハウ的なものがたくさんあるのですが、、、

その後、さらにアクセスが多い案件もありましたがやはり一発目の案件は情報も少なくていろんな意味で特別だったなぁとおもいます

負荷対策として行ったこと

マスタDBを分割する

DBの負荷分散の対策としてMySQLレプリケーションを利用して参照系のクエリを分散させるというのは以前にも経験した事がありました。

しかしソーシャルゲームでは設計等にもよるのかもしれませんがデータの更新が多かったためスレーブDBは余裕があるにマスタDBがいっぱいいっぱいという自体に陥りました。

結論からいうとマスタDBを分割するという対応を取りました。

1コンテンツに複数DBを持たせるという発想が当初はなかったのですが、増え続けるデータに対してはユーザIDなどのユーザが一意に持つIDなどでDBを振り分けるという手法になります。

これをやるとRDBを使ってるにも関わらず安易にテーブル結合などが行えなくなるのでアプリケーション側の開発でも色々制約が生まれます

マスタデータなどの情報はmemcachedなどにもたせる

「マスタDBを分割する」と同様にDBの負荷対策となりますが、こちらはスレーブDBの負荷を少しでも下げるという対策になります。

ただコレに関してはマスタデータは全てのデータベースサーバに同じデータを持たせるという方法でも良かったと思います。

そうすればテーブル結合が一部使えるなどアプリケーション側の開発が少しは楽になる場面があると思ったからです

ログなどデータサイズが大きくなるテーブルは別DBとする

これも色々書いてありますが、MySQLのレコードサイズがメモリサイズを超えると遅くなるためです。

はじめにこの指摘を受けたときには負荷が高いテーブルをどうにかする必要があると思っていたのでなんのこっちゃと思っていたのですが、OSやらの仕組みとか知っている人からすると当然な話で根本的に間違っていました

更新系のクエリを減らす

これはアプリケーション開発側の工夫次第になります。

Webサイトの開発から入ると何でもかんでもDBに保存するということになりがちだったのですが、1度負荷を体感すると極力更新を減らせないかという発想になりました。

で、ちょっといちいちDBに保存しなくても必要なデータだけ保存しておいてあとはアプリケーション側で計算すれば充分だったとかありました。

おわりに

こう見てみるとアプリケーション側で注意することはいかにDBの負荷を気をつけるかということにつきるのかと思われます。

最近ソーシャルゲームの開発をしている人と話す機会があったのですが、今ではアプリケーション側で無理矢理対応するのではなくてマシンのスペック自体をあげてしまうこともあるそうです。

スケールアウト→スケールアップという流れになるのでしょうか、、、

ただ高負荷のサービスに関わるとそれまで考えなかった事を対応しなくてはならなくなるので色々勉強になったかと思います

以上です