Recommended
More Related Content
What's hot
What's hot (20)
Similar to モンスターストライクにおける監視システムのあれこれ
Similar to モンスターストライクにおける監視システムのあれこれ (14)
モンスターストライクにおける監視システムのあれこれ
- 2. ⾃⼰紹介
- 3. ⾃⼰紹介 - ⽒名 - 白川裕介 - 経歴 - 2012年に新卒でミクシィに入社。 - SNS「mixi」でアドネットワークを担当したのちXFLAGのアドテクスタジオへ異動 - その後、モンストの開発に携わりマネージャーを経験 - 現在では開発室の室長として、モンストに関わるエンジニア組織を統括
- 4. モンスターストライク
- 7. アーキテクチャ構成
- 10. App • ロードバランサー • A10を利用し配下に約200台のAppサーバーを配置 • Appサーバー • マルチクラウドで計算リソースの確保 • AWS / GCP / IBM を利用 • オンプレサーバーも利用 • ハイブリット構成にしている理由 • 単一点障害の回避 • 在庫の確保の柔軟性
- 12. DB • 全てオンプレサーバーで構成 • 約300台稼働中 • 複数拠点・複数系統でサーバー故障に備える • DBサーバーへのアプローチ • 水平分割 / 垂直分割 • Indexやクエリの最適化 • 高性能なマシンを投入 (高いIO性能を出せるもの) • IOMemory / NVMeを利用
- 13. DBサーバー障害への対策 • データが完全に消失しないように何重にも防衛 • DCレベルでの冗⻑化 • DBサーバーは2拠点での冗長化 • DC毎に複数系統に冗長化 • master - backup構成 • 定期的にDBのSnapshotをとりクラウド上に保存 • 数週間分のbinlogのBackupを保持
- 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を仕込む • グラフの変化を捉える • バージョンアップ、改善施策のリリース、イベント時など • 必ずグラフ上から変化読み取る • 想定通りなのか、想定外なのかを判断
- 32. メトリクス監視 • グラフから読み取る⼒を養う • 各サーバーによって監視項⽬は異なる • 各グラフを⾒ることでサービスの全体構成を把握
- 33. メトリクス監視 • グラフから読み取る⼒を養う • 各サーバーによって監視項⽬は異なる • 各グラフを⾒ることでサービスの全体構成を把握
- 34. 死活監視 • On-Call • Nagios / CloudWatch / Zabbix などの監視からPagerDutyへ通知 • 同時にslackのalert部屋にも投稿 • アラートがなったら15分以内に対応開始 • 基本的な1次対応はドキュメント化されている • 1次対応に少しでも迷った場合はエスカレーションを奨励
- 35. 障害対応時のルール • 深夜対応の⼼得 • 必ず安全な道を選ぶ • 1次対応を迅速に実施 • サービスが正常に回っている状態まで復旧 • 2次対応(サーバの復旧や新サーバの作成)は翌営業日の作業 • 作業分担 • デプロイする内容は必ずもう一人の確認するなど • 情報を共有 • 必ずslack内で作業内容を共有 • ログなど共有すべき内容は必ず共有 • サービスにエラーや遅延など影響がある場合は企画とcsに共有