モンストがどうなっているか
お話は上巻と下巻でそれぞれインフラチームとSREチームの方が登壇されました。
モンスターストライクの監視ツール今昔物語集 上巻
モンスターストライクの監視ツール今昔物語集 下巻
サーバー構成
使用言語:Ruby
アプリケーションサーバー:Unicorn
データ管理:Fluentd
メモリ分散:memcached
データベース:mariaDB
インメモリDB:Redis
非同期処理:resque worker
マルチクラウド構成
パブリッククラウドを使っている
データセンターが２つを拠点として、クラウドをその周囲にパブリッククラウドで接続。
監視システム構成
死活監視
オンプレとクラウドで共通で使えるため。
メトリックス監視
問題点
監視サーバーが自身を監視できない
物理サーバーが死んだか、クラウドとの接続が切れたかわからない
各拠点に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サーバーがこれにレスポンスを返すというネットワークの仕組み。
トラフィック
一定時間内に流れるデータ量。
端的に回線容量を表すこともある。（トーク内ではこっちの意味で使われていた）
awsのstaticパラメータ
クエリ大量発行
DB分割
- 垂直分割と水平分割(シャーディング)
Aurora
Amazon Auroraの先進性を誰も解説してくれないから解説する
KVS
分散データストアの総称。代表的なもので、前述したmemchacedなどがある
データベースのトランザクション
- トランザクション
- アトミック性
- 分散トランザクション
トランザクションに含まれる処理内容を、別々のサーバーに処理を実行させ、保存するDBも別のデータベースで持っている。
mutex
0=使用中と1=未使用の２つの状態でセマフォと同じような機能をもつが、デッドロック回避の機能などを機能として持っている
排他制御
他の利用者がいる場合、後続の利用者には利用制限がかかる仕組み。
セマフォ
共有資源に対するアクセス可能数値で制限をかける
デッドロック
アクセスしに行って使用状況に空きができるまでお互いが処理を終えるための片方の処理を抱えたまま待ち続けている状態。結果として、お互いが、求めている処理を待ちながら、お互いが相手の求める処理を確保してしまっているせいで、いつまでたっても処理が終わらないという状況のこと
spin lock
排他制御の１つ。短期間向き。ロック変数が手に入れられると、処理実行可能になるが、この変数が手に入れられるまで、取得行為をループさせる手法。
レイテンシ
データ転送の指標の１つ。リクエストしてから、レスポンスが返るまでの遅延時間を表す。
SPOF
Single Point of Failure. 単一障害点の意。システム内の一機能が停止すると、システム全ちあが止まる可能性を孕んだコンポーネント
ElasticsSearch
第６回 Elasticsearch 入門 基本コンセプトを理解する
レースコンディション
データ競合(data race)と競合状態(race condition)を混同しない
哲学者の食事問題
うわぁ・・・引くわ・・・多すぎ問題・・・