モンスターストライクにおける監視システムのあれこれ

モンスターストライクにおけるメトリクス監視、死活監視についての話です。
以下のイベントの登壇資料になります。

◆うちのDevOps事情〜大規模サービスのモニタリングあれこれ〜

DevOpsについての進捗共有をする「うちのDevOps事情」シリーズ。
今回のテーマは【大規模サービスのモニタリング】です。
どのような項目を監視/モニタリングするのか？
利用ツールを選択した理由とは？そのツール利用した結果どうだった？
運用しながら改善していく時の優先順位の付け方は？
など、DevOpsを推進していくときに参考にしていただきたい事例を4名からお伝えします！

https://techplay.jp/event/765163

Transcript

1. モンスターストライクにおける 監視システムのあれこれ 株式会社ミクシィ モンスト事業本部 開発室 室⻑ ⽩川裕介
2. ⾃⼰紹介
3. ⾃⼰紹介 - ⽒名 - 白川裕介 - 経歴 - 2012年に新卒でミクシィに入社。 - SNS「mixi」でアドネットワークを担当したのちXFLAGのアドテクスタジオへ異動 - その後、モンストの開発に携わりマネージャーを経験 - 現在では開発室の室長として、モンストに関わるエンジニア組織を統括
4. モンスターストライク
5. モンスターストライク ⾃分のモンスターを引っ張って弾き、敵のモンスターに当てて倒していくという、スマートフォンの特性を活⽤した、 誰でも簡単に楽しめるアクションRPGです。ゲームはターン制をとっており、 ⼀緒にいる友だちと最⼤4⼈まで同時に遊べる協⼒プレイ（マルチプレイ）が特⻑です。 2013年の10⽉の提供開始から現在※までの世界累計利⽤者数5,300万⼈を突破 ※ 2020年01⽉時点 「世界累計利用者数 5,300万人を突破したスマホアプリ」
6. アジェンダ モンストを⽀えるシステム アーキテクチャ構成 監視システム メトリクス監視 死活監視 監視のその先 ・ ・ ・ ・ ・ ・
7. アーキテクチャ構成
8. アーキテクチャ構成 LB App App App DB(master) DB(backup) Redis Memcached Batch Turn
9. アーキテクチャ構成 LB App App App
10. App • ロードバランサー • A10を利用し配下に約200台のAppサーバーを配置 • Appサーバー • マルチクラウドで計算リソースの確保 • AWS / GCP / IBM を利用 • オンプレサーバーも利用 • ハイブリット構成にしている理由 • 単一点障害の回避 • 在庫の確保の柔軟性
11. アーキテクチャ構成 DB(master) DB(backup)
12. DB • 全てオンプレサーバーで構成 • 約300台稼働中 • 複数拠点・複数系統でサーバー故障に備える • DBサーバーへのアプローチ • 水平分割 / 垂直分割 • Indexやクエリの最適化 • 高性能なマシンを投入 (高いIO性能を出せるもの) • IOMemory / NVMeを利用
13. DBサーバー障害への対策 • データが完全に消失しないように何重にも防衛 • DCレベルでの冗⻑化 • DBサーバーは2拠点での冗長化 • DC毎に複数系統に冗長化 • master - backup構成 • 定期的にDBのSnapshotをとりクラウド上に保存 • 数週間分のbinlogのBackupを保持
14. アーキテクチャ構成 Redis Memcached Batch
15. Redis / Batch / memcached • Redis / Batch • Resqueを利用した非同期処理 • ミッションの達成判定や報酬付与などを非同期処理で実施 • memcached • すべてオンプレサーバーで構成 • DBサーバーとの距離を重視 • DB性能限界へのアプローチとしてCacheを用いる • モンストではCacheの比重が大きい • app <=> memcached の往復が100回を超えるAPIもある • Cacheを利用することによりレスポンスの高速化を実現 • Replica Poolを用意しサーバー障害へ対策
16. アーキテクチャ構成まとめ その1 • 稼働中のサーバーはトータルで約1,000台 • DBサーバー: 約300台、Appサーバー: 約200台 • Turnサーバーを利⽤しマルチプレイを実現 • パケットのリレーを行う用途 • Cacheを多⽤することでレスポンスの⾼速化 • モンストではmemecachedを利用 • Resqueを利⽤した⾮同期処理 • バックエンドはRedis
17. アーキテクチャ構成まとめ その2 • ハイブリッド構成 • 自社DCのオンプレサーバーとクラウドサーバーの併用 • 単一点障害の回避や柔軟な在庫の確保 • サーバー障害に対して、何重もの対策を実施 • DCの冗長構成 • 2つDCを利用しDCレベルでの冗長化を実現 • memcachedのReplica Poolの用意
18. 監視システム
19. 監視システム(メトリクス監視) • CloudForecast • リソースのモニタリング • Kibana + elasticsearch • ログ可視化 • Grafana + InfluxDB • APIリクエストなどをモニタリング
20. CloudForecast • mixiで利⽤していた監視ツール • オープンソースで公開 • http://github.com/kazeburo/cloudforecast • Gearmanで監視処理を分散 • RRDtoolのラッパー • Perlで書かれている • Pluginを⾃作して各種項⽬を監視
21. Kibana + elasticsearch • Appサーバーのlogなどを蓄積 • ログの集計や検索などに利用 • 1/100でサンプリングして蓄積 • Fluentd • サンプリングやデータ加工 • Kibana + Elasticsearch • 可視化、検索
22. Grafana + InfluxDB • InfluxDB • 様々なデータを集計して蓄積 • Grafana • ダッシュボードを作成し可視化
23. • Nagios • サーバー監視 • PagerDuty • インシデント管理システム 監視システム(死活監視)
24. Nagios • サービスインしている全サーバーの死活監視を実施 • 監視項目はサーバーの利用用途により多岐にわたる • App/DB/memcached等 • 監視項目(check plugin)も独自に拡張 • SNMPのextend機能を利用 • Nagios自体の監視をするために各拠点ごとにNagiosを構築 • 相互に監視をし合う • 独自で運用ツールを構築 • 設定に用いるcfgファイルはyamlから自動生成 • 各拠点の設定を一括で更新
25. PagerDuty • 監視で異常を検知した際のインシデント通知を送る • 各種監視システムと簡単に連携可能 • エスカレーションルールを柔軟に設定可能 • On-Call当番制 • システム障害に備えて24時間365日待機 • 2人1組で1週間の当番制 • アラート発生時には15分以内に対応開始
26. 監視システム • オンプレ・クラウドで共通で利⽤可能 • モンストはハイブリット構成で運用 • 拠点間に監視やモニタリングは共通である必要 • SNS mixi時代からの資産を数多く利⽤ • 採用しているフレームワークやアーキテクチャは違えど基本的な構成は同じ • SNS時代に活用していたものを多く利用可能
27. 監視システムまとめ • モンストの監視システム • メトリクス監視 • CloudForecast • Kibana + elasticsearch • Grafana + InfluxDB • 死活監視 • Nagios • PagerDuty • SNS mixiで⽤いていた資産を最⼤限に活⽤ • 独⾃Pluginなどで監視項⽬を拡張
28. 監視のその先
29. メトリクス監視 • グラフを⾒る/ログを取る習慣をつける • 毎日見ているとグラフから小さな変化にも気づくことが可能 • イベントやピークタイミングのログやグラフから次回への対策を考察 • より詳細なログが取りたいときはサーバーにtcpdumpを仕込む • グラフの変化を捉える • バージョンアップ、改善施策のリリース、イベント時など • 必ずグラフ上から変化読み取る • 想定通りなのか、想定外なのかを判断
30. メトリクス監視 • リリース後の効果
31. メトリクス監視 • リリース後の効果
32. メトリクス監視 • グラフから読み取る⼒を養う • 各サーバーによって監視項⽬は異なる • 各グラフを⾒ることでサービスの全体構成を把握
33. メトリクス監視 • グラフから読み取る⼒を養う • 各サーバーによって監視項⽬は異なる • 各グラフを⾒ることでサービスの全体構成を把握
34. 死活監視 • On-Call • Nagios / CloudWatch / Zabbix などの監視からPagerDutyへ通知 • 同時にslackのalert部屋にも投稿 • アラートがなったら15分以内に対応開始 • 基本的な1次対応はドキュメント化されている • 1次対応に少しでも迷った場合はエスカレーションを奨励
35. 障害対応時のルール • 深夜対応の⼼得 • 必ず安全な道を選ぶ • 1次対応を迅速に実施 • サービスが正常に回っている状態まで復旧 • 2次対応(サーバの復旧や新サーバの作成)は翌営業日の作業 • 作業分担 • デプロイする内容は必ずもう一人の確認するなど • 情報を共有 • 必ずslack内で作業内容を共有 • ログなど共有すべき内容は必ず共有 • サービスにエラーや遅延など影響がある場合は企画とcsに共有
36. まとめ ⽇頃から監視ツールを確認する癖をつけましょう (未然に防げるものは防ぎましょう)