はじめに
運用監視サービスを選ぶにあたって
- グラフの種類や使い方ってちゃんと考えて整理すると色々あるけど、理解して使ってますか？
- なんのアラートを通知するべきか、整理できてますか？
先にまとめ
-
あらゆる仕事に共通する話ではありますが、運用監視においても「目的や方針」を定めることは重要
-
方向性がぶれると、不必要なメトリクスやアラートを作りすぎて、必要な情報がすぐに探せなかったり、次第に見なくなったりするかも知れない
-
そのため、さまざまなデータの切り口や、どのサービスを使えば自分たちにとってベストプラクティスか？メトリクスの種類やグラフの種類、アラートの定義などをルール化して整理するのは大事
1. 優れたデータを収集する
不要なアラートを抑えつつ、迅速な調査を可能にするために
優れたデータを収集するのがとても大切
- 優れたメトリクスデータは迅速な調査を可能にして、潜在的な問題やパフォーマンスの問題の原因を特定しやすい
ビジネスメトリクス
- アプリ内でのユーザーの購入履歴
- 広告動画の視聴時間
- コンバージョン率
- サブスクリプション数
- ...etc
↓
事業の方向性を決めるのに役立つメトリクスだが
自分たちにとって何がビジネスメトリクスなんだろうか
システムメトリクス
- CPU
- メモリ
- リクエスト速度
- 待ち時間
- クエリ速度
- エラー率
- ...etc
↓
このタイプのメトリクスは、アプリの機構が実際にどの程度良好に機能しているかに関する情報を提供する
ワンポイント
監視のためのより良いデータについて
-
1.簡単に理解できる
素早く判断できる必要がある -
2.粒度を合わせる
メトリクス収集頻度が低すぎたり高すぎると、有意なデータが得られなくなる場合がある -
3.長期間の保持
あまりにも早い段階でデータを破棄すると、過去に何が起こったのかを示す重要な情報が失われる
2. 本当に重要な問題についてアラートを発行する
何でもかんでもアラートにして通知してしまうと、本当に大切な情報を見失ってしまうことになる
そのため、アラートの緊急度を定義して
（例）アラートの緊急レベル
記録するアラート（重大度が低い場合）
- 介入しなくても解決されることが多い
将来的に参照または調査する時に利用できる
通知するアラート（重大度が中程度の場合）
- 介入が必要だが、すぐに対応する必要はない
メールを送信するか、チャットで通知するのが良い
緊急メッセージを送信するアラート（重大度が高い場合）
- 発生した時間に関わらず、即時対応が必要となる
アラートマッピング例
3. 根本原因を効率的に見つける
問題が発生している可能性があることがアラートで通知されたら、体系的な調査を迅速に実施できるよう
関連するグラフをダッシュボードに集約して、相関性を分析できるようにする
例えば、SQSの遅延アラートが発生した場合
- データ量
- エラー率
- 処理速度
など、関連するサービスで必要な情報をあらかじめ設定しておくことで素早い調査が行える
4.監視するための最適なツール
監視する必要があるものを認識できると
ビジネスメトリクスやシステムメトリクスのデータが可視化できるツールが必要となってくる
何を選ぶべきなんだろうか？
GoogleAnalytics
GoogleAnalyticsを利用したビジネスメトリクスの監視しやすい
Firebaseを利用したシステムメトリクスの監視
ワンポイント
- 多くのサービスを利用して画面を切り替えて情報を監視するのは運用や情報追加が大変
- 1つのダッシュボードに情報を集約して一目で最も重要な情報を確認できるようにしておきたい
まとめ
-
そういう意味だとGrafanaはさまざまなリソースと連携できるので情報が集約できるGrafanaの選ぶのは割と理にかなってはいそう（ビジネスメトリクスやシステムメトリクスなど様々なサービス連携が可能）
-
AWSを利用しているならAmazon Managed Service for Grafanaも利用できる