はじめに
こんにちは、合同会社DMM.com オンラインサロン事業部の谷川です。
DMMオンラインサロンのプロダクト開発を担当しています。
本記事では、DMMオンラインサロンのバックエンドの監視の取り組みを紹介します。
オンラインサロンのシステムについて
オンラインサロンとは、オンライン上で運営される会費制のクローズドなコミュニティのことを意味します。
オンラインサロン事業部は、このオンラインサロンのプラットフォームを開発・運営しています。
私が所属しているプロダクト開発チームでは、主にオンラインサロンの「入会ページ」、「オーナー管理画面」、「DMM管理画面」、オンラインサロンの活動を行う場である「コミュニティツール」を運用しています。
抱えていた監視関連の課題
当時、各プロダクトはそれぞれ以下のような環境・方式で監視運用を行なっていました。
*1 アプリケーションパフォーマンス監視のこと。アプリケーションの性能状況監視や、処理のトレース状況を見て障害解析に役立てることができる
*2 DMMのインフラを24/365で監視し、安定したサービスを提供できるようにトラブル発生時のさまざまなサポートを行うチーム
上記について、大きく分けると以下の課題がありました。
- 監視ツールや運用方法がバラバラで複雑
- オンプレミスのログは複数サーバーに分散しているため確認に時間がかかる
- アプリケーションのログ監視がほぼないため、致命的なエラーに気付けないときがある
- 監視ツールにAPM機能がないのでアプリケーションの詳細状態が分からない
監視運用改善のための取り組み
オンラインサロン事業部のプロダクト開発チーム、および社内SRE部と協力し、これらの課題を改善するための取り組みを行いました。
どのような流れで課題を改善していき、さらに監視運用をブラッシュアップしていったのかを、フェーズごとに分けてご紹介していきます。
導入フェーズ
監視ツールの見直し・選定
「入会ページ」、「オーナー管理画面」、「DMM管理画面」をオンプレミスからAWSにLift＆Shiftする案件をきっかけに、監視ツールの見直しを行いました。
今回新たに導入したのは、NewRelicというSaaS型監視ツールです。
NewRelicを選定した理由は、以下の通りです。
- 他の監視サービスと比べてAPMの情報量が多く、デバッグやトラブルシューティングがしやすい（2020年時点の対象機能が利用している言語とバージョンで比較）
- 他の監視サービスと比べて機能面やコスト面で気になる点がなかった
小さくスタート
まずは「入会ページ」、「オーナー管理画面」、「DMM管理画面」のAWS移行時に、それぞれの監視ツールをNewRelicに切り替えました。
AWS移行時の負荷テストでもAPMを利用することで、アプリケーションの性能やエラー状況、そのときのトレースなどを詳細に分析することができるようになり、テスト時や障害調査の際に大変役に立ちました。
あわせて、ログの確認もNewRelicから行えるようになったため、わざわざサーバーに入ることなく、NewRelic画面上で複数サーバーのログを横断的に検索できるようになりました。
監視ツールをNewRelicに統一
加えて「コミュニティツール」の監視ツールについても、Mackerel・CloudwatchからNewRelicに移行し、オンラインサロンのすべての監視ツールをNewRelicに統一しました。
監視の設定箇所、ログの確認先がNewRelicに統一され、アラート通知先もSlackに一本化できたため、監視運用が楽になりました。
改善フェーズ
新たな監視ツールの導入、システムごとの監視ツールの統一などいくつかの課題を改善することができました。
さらなる改善フェーズとして、以下の監視運用の改善を行いました。
ログ監視改善
アプリケーションログの監視設定ができていなかったためすぐにでも対応したかったのですが、当時以下の課題を抱えており、そのまま監視設定を進めても運用が回らないことが目に見えていました。
- さまざまな種別のログが混ざり合っている状態
- 軽微なエラーログが大量に出力されていてノイズになっている
そのため、まずは以下の対策を行いました。
- ログの種別毎に出力先を分ける
- 既存のエラーログをNewRelicのクエリー（NRQL）で一意に抽出し、優先度をつけて地道にエラーを潰す
ログの出力先の整理とエラーを一定数潰しきった後に、アプリケーション関連のログ監視を追加しました。
その結果、潜在的に眠っていて見過ごされていた不具合や、実装中のアプリケーションの不具合に、すぐ気付けるようになりました。
監視設定のIaC対応
NewRelic導入後、最初のうちは、監視内容をドキュメントで整理した後に、NewRelicの画面から手動で監視設定を行なっていました。
しかし監視ツールの活用が進むにつれて監視項目が増え、ドキュメントとNewRelicの監視設定の二重管理が大変になってきました。
さらにレビューや設定反映のコストも大きくなってきたため、設定をTerraformで管理してCircleCIでデプロイすることで、設定のコード管理、および設定反映の自動化を行いました。
IaC対応のおかげで監視設定のレビューや監視設定反映が行いやすくなりました。
Runbookの作成
上述のような取り組みのおかげで、致命的なアラートにすぐ気付けるようにはなりましたが、いざアラートが発生すると、どう対応していいのか迷うこともあり、初動対応や障害対応のスピードに課題を抱えていました。
そこで、アラート対応が複雑なケースでは、Runbookを作成してアラートの通知内容にRunbookのリンクを追加することにしました。
そうすることで、アラート発生時の速やかな初動対応や障害対応のスピードアップが実現できるようになりました。
またその結果、アラートが発生しても安心して作業ができるという、心理的安全性も高める結果につながりました。
活用フェーズ
導入フェーズ、そしてそこからの改善フェーズと、もともと抱えていた課題を解決していくことができました。
さらなる監視運用ブラッシュアップのため、NewRelicの機能も活用しながら、以下のような改善活動を行いました。
ダッシュボードの作成
アラートが発生してから各メトリクスを確認したり、NewRelic上で情報検索したりしていると、初動対応に時間がかかってしまいます。
そこで、リクエスト数、スループット、エラー発生件数、アプリケーションの性能状態、コスト等、よく確認する情報をダッシュボードにまとめ、素早く状況確認できるようにしました。
朝会でダッシュボードを観測することで数値の変化にも気付きやすくなりました。
デプロイメントを記録する
障害発生時等、アプリケーションがいつもと違う挙動をした際に、それがどのリリースに起因して引き起こされたのかを確認したいときがあります。
アプリケーションをデプロイした時間や、デプロイ関連の情報をNewRelicに送信・記録する機能があるため、それを活用し、NewRelic上にデプロイ情報を記録するようにしました。
これによりNewRelicのAPMのグラフ上にデプロイ情報がマッピングされ、俯瞰的に確認できるようになり、障害時や性能が悪化した際の原因調査に非常に役立ちました。
オンコール対応する
AWS移行したプロダクトが早朝に不安定になり、Slackに即時対応のアラートが発報されましたが、開発チームの全員が気付くことができず、復旧対応まで3時間かかったという問題が起こりました。
AWS移行前のオンプレ環境でアラートが発生したときは、サーバーを保守しているインフラ部や社内のMSPチームから開発担当者に架電する体制だったので、このようなことは起きていませんでした。
AWS移行対応時は、アラートをSlackで開発関係者全員にメンションを付けて通知すれば誰かが気付くと判断し、架電の仕組みまでは導入しなかったのです。
しかし、Slack通知だけではアラートに気付けないことが分かったので、オンラインサロンの全プロダクトに対して架電のオンコール体制を構築することにしました。
架電のオンコールシステムはPagerDutyなど、さまざまなサービスで実現できます。
私たちのチームの場合は、オンプレ環境で利用実績のある社内のMSPチームとの連携が一番早くコストも安かったので、MSPチームと連携することになりました。
MSPチームと連携するには、自動でインシデント起票・架電を行う内製ツールにアラート内容をメールで送信する必要がありました。
NewRelicには簡単に特定アラートだけ通知先を増やすことができるWorkflow機能があるので、監視をWorkflow版に切り替え、致命的なアラートだけMSP宛にメール送信するように設定しました。
この対応により、営業時間外に発生した致命的なアラートかつ、開発担当者全員が気付いていない場合は、当日の担当者（当番制）に架電されるようになりました。
まとめ
オンラインサロンの監視の課題と取り組み結果を紹介しました。
NewRelic導入とログ改善で監視の課題が解決し、アラート対応やパフォーマンスチューニング対応が行いやすくなりました。
監視は運用しながら設定の追加や調整が必要だったり、監視ツールのアップデートの追従作業があったりするので、最新のツールを導入しただけでは終わりません。
不具合やその予兆を検知して素早く対応できるように、引き続き改善活動を続けていきたいです。
DMMオンラインサロンでは開発チームのメンバーを募集しています。少しでもご興味を持たれた方、まずはカジュアル面談で気軽にお話ししてみませんか？
