モンストがどうなっているか

お話は上巻と下巻でそれぞれインフラチームとSREチームの方が登壇されました。
モンスターストライクの監視ツール今昔物語集　上巻
 モンスターストライクの監視ツール今昔物語集　下巻

サーバー構成

使用言語:Ruby
アプリケーションサーバー:Unicorn
データ管理:Fluentd
メモリ分散:memcached
データベース:mariaDB
インメモリDB:Redis
非同期処理:resque worker

マルチクラウド構成

パブリッククラウドを使っている
データセンターが２つを拠点として、クラウドをその周囲にパブリッククラウドで接続。

監視システム構成

死活監視

Nagios

オンプレとクラウドで共通で使えるため。

メトリックス監視

Cloudforecast
kibnaa
Grafana

問題点

監視サーバーが自身を監視できない
物理サーバーが死んだか、クラウドとの接続が切れたかわからない
各拠点にNagiosを設置して、Nagios自体が各拠点のそれぞれを監視する

Nagiosのconfigが非常に複雑問題。

故に、ymlから生成されるツールを作成し、更新サーバーを用意して、一括でNagiosを更新する。

独自の監視項目をカスタマイズしたい問題。

SNMPのextend機能を利用する
Net-SNMPの拡張機能

任意のコマンド結果をSNMPで返す。
サーバーのuptimeをチェック
filesystemのreadonlyをチェック
するなどの自作プラグインを作成

複数サーバーの監視にはソフトウェアが非常に多いし、管理が煩雑になりがち問題

現在進行形で刷新中。
Nagiosからprometheusに移行
アンチパターンを結構踏んでいた・・・SNMPサーバーはよせby入門監視o'raily
監視サーバーがスケールしない
メトリクスの履歴が保存されていない
取得感覚が5分で長い
監視ソフトウエアの古く、また依存度が高い。
故に、ソフトウェア変えよう。

Saasサービスだと監視項目が少なかった

オンプレとクラウドを１つのソフトで監視したい

prometheusは、

google製
exporterが充実
pull型
アラートの重複を自動排除してくれる・・・らしい

Nagiosを滅ぼすには

監視構成の高可用性
拠点冗長する
設定統一
configの自動生成
自動のサービスディスカバリがない

メトリクス監視について

Cloudforecast
monitor pluginを作成

アプリから、fluentdから、kibana+elasticsearch

異常アラート検知
PagerDuty
各種監視システムと連携して通知ができる。
エスカレーションルールが柔軟に作れる

On-Call当番制

サーバ開発&SREでローテーション

FGOを支えるデータベースの話

FGOの運営をdisってる連中はこれ読んでほしいな。アプリの裏側ででどれだけすごいことやっているかを知ってほしい。
FGOデータベーススケールの苦難

webサービス概要

ASP.NET MVC4で構築されたAPIサーバー
UNITYで構築されたクライアント

で構成されているシンプルなサーバークライアントモデル。(ADO.NET　＋　Mysqlコネクタ)を呼び出す内製実装。

APIサーバーはwindows server Ⅱs

ロードバランサはClassic Load Balancer

データベースはmysql

特徴

クライアントがcontrollerの状態まで持つ。処理情報もクライアント側に送り込まれる。
弱点としては、ユーザーデータがキャッシュしにくい。
APIサーバでキャッシュするとスケールアウトが難しくなる。

APIga叩かれると、毎回データベースから際書き込みをしている
イベントシステムごとにAPIの叩かれ方が違うので、データベースを様々なところで耐久することを強いられる。

多ユーザーに影響をほとんど与えない

ロンチから垂直分割までの戦い

インストールは30万だと予想したら、倍の300万だった・・・
botアクセスも大量にきた・・・
スレーブ参照をしていたが、レプリケーションが遅れて、ガチャ結果が反映されない・・・
APIサーバーはスケールアウトで対応
ただし、スケールアップのみを想定していた
APIコールが増えてクエリ数が増加
データベースの処理を超え、コネクションプールが枯れた

イベントのミッション形式は非常にユーザー状態を監視するのが大変
加えて、シナリオ更新もあった。

staticパラメータを変更してインスタンスの再起動がいるので、臨時メンテをした

スケールアウト（DB分割）が最終決断

それでAWSのAuroraへ移行して考える時間稼ぎ

binlogのバグを踏み抜く。結局一旦切り戻しをして、垂直分割を敢行。

データベース分割後の分散トランザクション
アトミック性がなくなる

エラー発生に対して、DBクエリログを記録

インスタンス間のテーブル分配とコミット順を工夫
ユーザーのキャラデータと戦闘結果を守ることだけ考えた。

垂直分割から、水平分割へ

インスタンスを分割増加
ユーザーテーブルも分割

テーブルサイズの肥大化
スケールアップでインスタンスが最大化、次はない
レイテンシが悪化する

ユーザーIDでシャーディングする

垂直分割を水平分割にならべかえる

最終的にレイテンシが下がる

まとめ

イベントから身辺がごたごたしたせいで随分と遅くなってしまった。こういうのって即日投稿が命でしょうがヨォ、ちくしょう。
弊社でサーバー負荷テストなどなどやっていていずれその仕事にもがっつりアサインされていきたいと思っているので、サーバー構成とか使われているソフトウェアとか、保守・運営あるあるネタくらい知っておけよ、俺ということで行ってまいりました。
自分の好きなゲームのインフラアーキテクチャの話ならば親しみやすいかなと思ったのが参加の理由です。
今回の話、弊社インフラエンジニアのOさんや負荷テストを受け持っているKさんとサーバーの保守・運営について、弊社で使えそうなトピックをピックしてもらって話しながら飲みにいきたいな・・・

おまけの用語

高屋さんのお話は、私のような雑魚には難しかったですね。ついていくのに必死で聴き終わった後は、マラソン完走した並に脳が疲れてました。というわけで、話を聞いていたときに調べた用語、知ってても言語化ちゃんと脳内で再生できなかった用語まとめ、および参考文献です。

CDN

Content Delivery Network.の略。突発的にアクセス数が増えたときに、webサーバーのオリジンがダウンしたりする可能性があるので、配信拠点(PoP)を世界中に設置、そこに多数のwebサーバー（CDNサーバー）を設置しておき、CDNプラットフォームを構築しておき、これらのサーバー群は、オリジンのデータをキャッシュしてアクセスしてきたエンドユーザーに近いCDNサーバーがこれにレスポンスを返すというネットワークの仕組み。