妙に需要がありそうなので、AWS Summit 2016のFate/Grand Order関連の部分だけ、手元のメモからわかる範囲で再現。なお、興味ある箇所を中心に記録しているので、かなり抜けてますのでご注意ください。
冒頭にごく短い紹介映像。マップ、サーバントの会話、戦闘の攻撃部分、宝具演出などのラッシュ。
開発時にはMicrosoft Azureを使っていた。UnityでC#開発(Visual Studio 2013)なので、自然に使える。構成はIIS + MySQL + Redis。ただし、インフラエンジニアがいない。
通信削減には気をつかっている。ログイン時にユーザ情報を同期して、後はフレンド情報以外は差分だけ送信している。フレンドはトリガになるイベントがないので定期的に同期。
ゲーム公開後、DBがボトルネックになることが判明。ゲームの特徴として、非常にデータベースへの書き込みが多い。通常のアクセスが盛況なのもあるが、異様に速いAPI叩きをするボットや、海外からのDoSアクセスなどが多数。結果、MySQLへのCommit時に0.5秒前後のスロークエリが出て、DBのmaster→slaveの同期反映に1,000秒かかり、獲得アイテムが消えて見えたこともあった。[1]
当時のAzureの最高スペックのVMでもメモリを喰らいつくして、30秒ごとにスロークエリが出ていた。おまけにインフラエンジニアがいないので冗長化していない。Azureは事前予告なしのサーバダウンがある。それで、Redisが2回、DBが1回落ちた。(AWSは予告してくれる)
色々聞いているとAWSが良さそうだったので乗り換えることにした。DBのメモリも当時はAWSの方が高かったし、RDSがマネージドサービスなのも、インフラエンジニアがいないので助かる。
ピアレス(?)が運用とインフラの改善を担当。BeansTalkでデプロイして、ゲームサーバを30台ほど起動している。当時の負荷はだいたい、20,000 Read Query/sec。C4.2xlargeでIISを起動。他、ElastiCache(Redis, memcached)、RDSという構成。
サーバ運用はスカイアーチネットワークス(?)に外注。深夜のメンテにもおつきあいいただいている。Azure Cacheを利用していた部分は、切り替えスイッチをつけてmemcachedに対応させた。コードの分離がされていたので、書き換えは楽だった(他もう1つ小さな変更があったがメモになし)。ログは、fluentdとnxlogで処理。
移行に際し、公開済みのバイナリが使えるかどうかをプロキシサーバを利用してテストしたが、無事動いた。また、移行用にAzure→AWSでMySQLのレプシケーションをしていたのを、逆にして、いつでも切り戻せるようにした。11月(?)に移行して、年末年始は安心してすごすことができた。
海外からの不正通信は継続して来ている。最近は、国内に踏み台を設けてやってくるので、対応が大変。
MySQLのinnoDBのチューニングをしているが、indexとデータの合計が500GBを越えて、メモリに載らない。仕方なく、indexだけでもオンメモリになるようにしている。細々とメンテナンスのたびに手を入れている。チューニングは計測してからしましょう。それから仮説を立てて、検証する。
現在は、DBをユーザ情報、サーバント情報など4つに垂直分割している。水平分割でないのは、クエリの複雑化を嫌ってのこと。
現在は、Sentry(アプリログ収集), New Relic(モニタリング), Jenkins(寿司), Bitbucketl(Git)などを利用。
(追記)メモから漏れてましたが、あまりにもDB slaveへの反映が遅かったので、仕方なく最終手段として、一部情報は直接masterを参照するようにした。という話もありました。当然、masterの負荷はさらに上昇しました。
関連記事:
- DBを知っていると背筋が冷える、実にホラーな出来事です。 [↩]