DMM.comの、一番深くておもしろいトコロ。

ポイントグループの運用監視カイゼンの取り組み

ポイントグループの運用監視カイゼンの取り組み

  • このエントリーをはてなブックマークに追加

はじめまして。ペイメントサービス部 ポイントグループの谷内(やち)です。
現チームにジョインしてから初めて業務でサーバーサイドを経験し、かれこれ3年近くDMMポイントに関するシステム(以下、ポイントシステム)の開発・保守をしています。

ところで皆さん、管理しているシステムで異常が発生した時、どのように検知していますか。
ポイントシステムの以前までの運用監視はひどいもので、システムの異常を検知しても実際に復旧に向けて動き出すまでに30分かかったこともありました。
しかし、ここ1年間で運用監視を大きくカイゼンし、今では障害発生から5分以内にはチームメンバー数人が事態を把握し、復旧に向けて行動できるようになりました。
今回の記事では、私たちが行ったポイントシステムの監視カイゼンの取り組みについて紹介します。

カイゼン前の運用監視

カイゼン前は以下のような運用監視をしていました。

f:id:dmminside:20201109113837p:plain

この運用監視でもシステムの異常を検知することはできるのですが、実際には以下のような問題がありました。

  • 障害担当者が見つかるまでに時間がかかる
  • 復旧にかかる時間が担当者のスキルに依存

Bad1:障害担当者が見つかるまでに時間がかかる

システム異常のアラートを検知するとメールやSlackに通知され、それを見た監視チームから障害担当者へ架電されるようになっていました。
障害担当者は複数人いたのですが、架電された一人目が出先だったり、就寝中ですぐに気付かなかったりすると二人目に架電、というように障害担当者を見つけるまでに時間がかかっていました。
また、Slack通知でもシステムの異常を検知できますが、他のメッセージの通知に埋もれてすぐに気付かないこともありました。

Bad2:復旧にかかる時間が担当者のスキルに依存

オンプレサーバメトリクスはZabbix、アプリケーションログはKibana、クラウドメトリクスはAmazon CloudWatch、というように運用監視に必要な情報が様々なサービスに分散していました。
このアラートを検知したらこうするといった復旧手順はなく、障害担当者がその場で各サービスを駆使し、必要なデータを集めて復旧対応していました。
このように復旧にかかる時間が担当者のスキルに依存しており、担当者によっては復旧に時間がかかってしまうことがありました。

監視サービスをDatadogへ移行したことをきっかけに運用監視を大カイゼン

CTOの松本がDMMにジョインしたことによって、監視サービスがDatadogに統一されていく働きかけをきっかけに、ポイントシステムでもDatadogを導入しました。
監視サービスを変更するという大きな変化があったことで、長年現状維持していたポイントグループの運用監視も見直すきっかけとなりました。
そして、私たちはこれまでの運用監視をただ移行するのではなく、どうしたら監視する人の負担にならないかを考え、以下のようなカイゼンをしました。

  • 運用監視に必要なデータをDatadogに集約
  • 一覧性の高いダッシュボードを作成
  • アラート内容に復旧手順を記載
  • PagerDutyの導入
  • Slackコマンドで復旧できるように

カイゼン1:運用監視に必要な情報をDatadogに集約

Datadog導入によって簡単に情報を収集できるようになったこと(例えば、サーバメトリクス取得設定は3分あればできる)も幸いして、運用監視に必要な情報をDatadogに集約しました。

f:id:dmminside:20201109113948p:plain

これによって運用監視がDatadogのみで完結し、一覧性の高いダッシュボードの作成や、アラート管理のコスト削減などが可能となりました。

カイゼン2:一覧性の高いダッシュボードを作成

ヘルスチェック用ダッシュボードと障害調査用ダッシュボードの2つのダッシュボードを作成しました。

ヘルスチェック用ダッシュボードでは、各サービスの正常性を横断的に確認できます。
主にどのサービスで障害が発生しているか、また、障害復旧後の解散の判断材料として利用しています。

f:id:dmminside:20201109114010p:plain

障害調査用ダッシュボードでは、各サービスの詳細な情報を確認できます。
これによって、何が原因で障害が発生しているかを、すぐに調査できるようになりました。

f:id:dmminside:20201109114036p:plain

カイゼン3:アラート内容に復旧手順を記載

各アラートの内容にそれぞれの復旧手順を記載しました。

f:id:dmminside:20201109114101p:plain

これによって、障害時に復旧方法を一から考える必要がなくなり、誰でも、すぐに復旧できるようになりました。

カイゼン4:PagerDutyの導入

緊急度が高いアラート検知時に、PagerDuty(機械音声で電話してくれるサービス)による架電 + Slack + LINEでメッセージ送信するようにしました。
PagerDuty導入によって、運用監視チームを介さないことで運用コストを削減しただけでなく、担当者全員に同時に架電されることで対応可能な担当者がすぐに見つかるようになりました。
また人からの架電の場合は、仮にSlackのメッセージ等で先に障害を検知していても「すでに障害を検知している」ということを伝えるためにも電話に出る必要がありましたが、PagerDutyになったことでたとえ電話に出なくともすぐに復旧対応を開始できるようになりました。

f:id:dmminside:20201109114121p:plain

カイゼン5:アプリケーションの復旧をSlackのスラッシュコマンドで

Slackの特定のチャンネルでスラッシュコマンドを打つことでアプリケーションのロールバックや起動、停止を行えるようにしました。
これまでアプリケーションの復旧は、VPNに接続 → Jenkinsにログイン → Jenkinsジョブを実行、といった手順だったものが、スマホでSlack上にスラッシュコマンドを打つだけでも良くなりました。

f:id:dmminside:20201109114143p:plain

カイゼン後の運用監視

様々なカイゼンによって以下の運用監視になりました。

f:id:dmminside:20201109114208p:plain

復旧までのだいたいの流れは以下のような感じです。

  1. Datadogで閾値を超えたアラートが発報される
  2. 緊急度が高いアラートの場合、PagerDutyから担当者全員に対して同時に架電される(緊急度が低いものはSlack、LINE通知のみ)
  3. 架電に気付いた人が電話の内容を聴いたり、Slack、LINEに通知されるアラートを見たりして障害の内容を把握
  4. アラート内の復旧手順に従って障害を復旧(Datadog上のダッシュボードやログで何が異常なのかを詳細に確認したり、Slackのスラッシュコマンドでアプリケーションを再起動やロールバックしたりする)

上のカイゼン後の図を見ても分かるようにカイゼン前と比べてだいぶシンプルになりました。
カイゼン前はそもそも障害を検知してから対応できる人が見つかるまで時間がかかったり、検知しても復旧手順を考えるのに時間がかかったりしていましたが、今では障害が起きてから10分以内に復旧を完了させて解散することもあります。
何より個人的に一番良かったのは「いつ障害が来ても大丈夫」と思えるようになり、心理的ストレスから解放されたことでした。

さいごに

今回はポイントシステムの運用監視カイゼンについてお話しましたが、ポイントグループでは他にも自分たち積極的に楽をするためのカイゼンを継続的に行なっています。
ポイントグループでは一緒に働いてくれる仲間を募集していますので、ご興味のある方は是非ぜひ募集ページをご確認ください。
dmm-corp.com