はじめに
この記事はDMMグループ Advent Calendar 2025の2日目の記事です。
データ基盤開発部・検索基盤チームで検索システムの開発・運用をしている小山です。
今回はチームのオブザーバビリティ課題の改善の中で取り組んだ、ダッシュボード改善について簡単にお話したいと思います。
背景
まず、なぜダッシュボードを改善したかを記載します。
多すぎるモニターと機能しないダッシュボード
我々はシステム構築の初期段階で、エラーログベースのモニターや、CPU使用率・メモリ使用率のモニターなど多くのモニターを作成していました。
よくある過ちではありますが、この結果としてアラートの発報頻度が多く、かつほとんどが「静観」されることとなりました。
これにより、本当に対応が必要なアラートの緊急性が薄れ、「オオカミ少年」状態に陥っていました。
これらのモニターについてはSLOを整備し、真にユーザ体験に影響を与える事象のみを検知するように改善を進めてきました。
SLO自体が今のままで良いかというと、まだまだ改善の余地はあるものの、不要なアラートを極力減らすことで、アラート対応に疲弊する機会はかなり減ったと思います。
そして、モニターの改善が進む中で次に問題となったのがダッシュボードの使いにくさでした。
ダッシュボードはコンポーネントごとに多数のメトリクスを網羅的に表示していました。
しかし、インシデント発生時にどこから原因を切り分けたら良いのか分からず、判断が遅れることもありました。
そこで、この課題を解決するために「目的駆動型」の3階層ダッシュボードを設計しました。
目的別ダッシュボードの設計
今回我々が新しく設計したダッシュボードは目的ごとに以下の3つに分かれています。
- インシデント初動調査用ダッシュボード
- ドリルダウン調査用ダッシュボード
- 振り返り用ダッシュボード
これらを1つずつ説明していきます。
第1階層：インシデント初動調査用ダッシュボード
初動調査ダッシュボードの目的は、アラート発生時にサービス全体の健全性を迅速に評価し、問題の発生源を特定することです。
そのために大きく3つのことを考えました。
問題発生の即時確認とサービス健全性の判断
まず、ダッシュボードの最上位には、問題が現在発生しているか、そしてその影響度がどの程度かを瞬時に判断できるメトリクスを配置します。
具体的には、ユーザ体験にもっとも近い指標であるALBのレスポンスタイムやエラー率のメトリクスをダッシュボードの先頭に配置します。
これにより、仮にアプリケーションがクラッシュしてもALBがエラーを確実に検知できるので、サービスの可用性低下を瞬時に切り分けられます。
ただし、ALBのメトリクスはAWSのIntegration経由で取得しているため、Datadogへの反映に数分のラグが発生するという課題も認識しています。
このラグを考慮して、ALBの「最新の値」とアプリケーション側で取得している直近のメトリクスを組み合わせて、状況を複合的に判断する運用を取っています。
相関関係によるボトルネックの切り分け
問題の発生が確認できたら、次にどこで問題が発生しているかを特定するため、サービスごとに依存先コンポーネントのメトリクスを時系列で横並びに配置します。
実際に並べたものが以下の画像です(サービスは都合上隠しています)。
- 検索リクエスト数:
- 特定サービスのトラフィック量を確認し、負荷の急増がないかを確認する
- 検索稼働率:
- 特定サービスのリクエストに正常なレスポンスを返しているかを確認する
- 検索API処理時間:
- アプリケーション内部の純粋な処理時間
- Elastic Cloud処理時間:
- 依存先であるElastic Cloudでクエリ処理にかかった時間(検索時のレスポンスのtookを利用)
- 通信レイテンシ:
- 検索APIとElastic Cloud間のネットワーク遅延
これらの時系列グラフを比較することで、レイテンシが増加している区間がどこかを視覚的に切り分けます。
ドリルダウンへの誘導とコンポーネントの主要メトリクス確認
ここまでの流れでおおよその問題発生箇所が特定できるので、そこから詳細調査への円滑な導線を提供します。
まず、コンポーネントの主要なメトリクスをダッシュボードの最下部に配置します。
これは特定した問題発生箇所が正しいかを確認するための最後のチェックポイントです。
以下のような障害の直接的な兆候を示すメトリクスを配置しました。
Elastic Cloudの例:
- CPU使用率
- ヒープメモリ使用率
- 検索のRejectedスレッドプール
また、コンポーネントごとのグルーピングをして、それぞれのグループに「ドリルダウン調査用ダッシュボード」へのリンクを設置します。
これにより、調査の継続性が途切れることなく、次の階層にシームレスに移行できるようにしました。
第2階層：ドリルダウン調査用ダッシュボード
このダッシュボードでは初動調査で、「このコンポーネントが怪しい」とアタリをつけた後、なぜそれが起きたのか根本原因を掘り下げることを目的としています。
ここまで読んだ方の中には、元々運用していたコンポーネント別ダッシュボードと同じではないか？と疑問を持った方もいるかもしれません。
形式上はコンポーネントごとに分割されていますが、以下のような設計思想の下、再設計をしています。
- 健全性の再確認
- ノード・Podなど細かい単位での分解
- イベントとメトリクスの相関分析
一つずつ細かく見ていきます。
健全性の再確認
ダッシュボードの最上位に、あらためてコンポーネントの健全性を示す重要なメトリクスを配置しています。
初動調査用のダッシュボードには載せていない、コンポーネント特有のメトリクスも合わせることで、初動調査の判断が正しかったかを再確認します。
以下の画像はそれぞれElastic Cloudの健全性確認用のメトリクスと検索APIの健全性確認用のメトリクスのスクリーンショットです。
Elastic Cloudの方ではクラスタやIndexのステータスなども表示しています。
以下の画像は上がElastic Cloudのダッシュボードで、下は検索APIのダッシュボードです。
ノード・Podなど細かい単位での分解
問題が起きているのが一部のリソースだけで、リソース全体で見たら均されてしまうということもあるので、できる限りメトリクスを分解して表示するようにしました。
また、インフラリソースやアプリケーションリソースなどグルーピング単位も見直しました。
以下の画像はそれぞれElastic Cloudと検索APIのメトリクスの例です。
イベントとメトリクスの相関分析
重要なメトリクスには、その異常の原因となり得るログイベントやKubernetesイベント(OOM Killなど)をグラフ上にマーカーとして重ねて表示しています。
また、最下部には詳細なログストリームやイベントストリームを配置し、メトリクスの異常時間帯とログの内容を照合できるようにしました。
第3階層：振り返り用ダッシュボード
最後に振り返り用ダッシュボードの説明です。
このダッシュボードは毎週の定例振り返りを支援するためのダッシュボードです。
初動調査用やドリルダウン調査用とは異なり、議論時間を長引かせないために情報量は最低限のものにしています。
SLOバジェットによる目標達成度の確認
毎週の振り返りサイクルに合わせて、先週と今週のSLOバジェット消費を数値として表示します。
これにより、完了した期間の評価と進行中の期間のリスクを同時に管理しています。
また、直近30日間のバジェットの残量も数値として配置することで、長期的な傾向も確認し、慢性的な劣化がないかをチェックしています。
アラート件数と主要メトリクスの制限
振り返りの時間を不必要に長くしないよう、メトリクスは議論に不可欠な指標のみに制限しています。
まず、一週間で鳴ったアラートの総件数を可視化します。
これによって、アラート対応頻度が適切であったかや、不要なアラートが残っていないかを確認できるようにしています。
SLOは問題ないが、アラート件数が多い場合などは不要なアラートが残っている可能性が高いのでモニター設定の見直しを議論できるようになります。
また、サービスごとのリクエスト数やレイテンシ、Elastic CloudのCPU使用率などから一週間の傾向を確認します。
その他、Elastic Cloudのドキュメント数やストレージサイズなども表示することで長期的なリソース枯渇の兆候なども把握できるようにしています。
最後に
本記事では、我々のチームの課題であったダッシュボードの改善について解説しました。
ただのデータ収集としてしか機能していなかったダッシュボードを「意思決定の支援ツール」として役割を持たせることで、緊急時の対応速度を改善できたと思っています。
もし、この記事を読んだ方の中に、ダッシュボードに課題を持っている方がいたら、ぜひ一度「このダッシュボードの目的は何か」を問い直してみてください。
