5W1Hを使って監視設計をスムースに行う
こんにちは。
株式会社ココナラでインフラ・SREを担当しているクララです。
本記事では、インフラリソースのメトリクス監視を一例に、5W1Hを使って監視設計をスムースに行う方法をお話しします。
はじめに
一口に監視(モニタリング)と言っても、用途や立場、システム規模などの変数でベストプラクティスは異なります。
本記事では5W1Hという考え方を使って、変数を一つずつ固定することで必要な監視システムの姿を明確にします。
大きく以下2点をお話しします。
- Why, Who, Whenから要件を導く
- 要件からWhere, What, Howを考える
そもそも5W1Hってなに？
何かを考えたり分析したりする際に使用するフレームワークの一種です。
英語の疑問詞 Who, What, When, Where, Why, How に回答しながら問題を分析します。
そのため、それぞれの頭文字を取って5W1Hです。
今回はゴールとなる監視システムの要件と実装・運用方法を明確化するために使用します。
Why, Who, Whenから要件を導く
本記事では、私が担当したインフラリソースのメトリクス監視改善を一例に考えます。
Why, Who, Whenは、監視設計ではそれぞれ以下の通り対応します。
- 監視システムの目的 (Why)
- 対象者 (Who)
- ユースケース (When)
監視システムの目的(Why)、対象者(Who)、ユースケース(When)が定まっていると、監視設計が楽になります。
私は最初、前提を定めずに突っ走り、「便利そうなメトリクスは沢山あるけど、何を監視対象にすれば良いのか分からない...」と途方に暮れました。
監視システムの目的を決める(Why)
監視システムの目的は事前に決まっていることが多いと思います。
今回は中長期的な監視戦略策定の中で、「インフラリソースのメトリクス監視改善」が施策に挙がった理由が、監視システムの目的です。
簡単に説明します。
ココナラでは「最速で最大の価値を提供する」を目標に、新規開発を行っています。
そして、これに伴ってシステムは日々成長しています。
一方で、インフラリソースの追加時の監視設定が標準化されておらず、アラートの抜け漏れに時々悩まされるようになっていました。
そのため、アラートの抜け漏れがない状態を達成し、継続することが、今回の目的です。
また目的から、アラートの網羅性が担保できることと監視システムの拡張性が高いことが要件です。
対象者を決める(Who)
ココナラのインフラ・SREチームが主な対象です。
チームメンバー全員が監視運用に参加できるよう習得が容易なことが要件です。
ユースケースを決める(When)
- アラート
- アラートは事象発生から可能な限り短時間で担当者へ伝わるのがベストです。
- 事象発生時に即時性を持って通知されることが要件です。
- アラートは事象発生から可能な限り短時間で担当者へ伝わるのがベストです。
- ダッシュボード
- インシデントの予兆検知・原因特定、パフォーマンスチューニングなど、SRE活動で多岐に利用することを想定します。
- ユースケースに合わせたカスタマイズが容易であることが要件です。
- インシデントの予兆検知・原因特定、パフォーマンスチューニングなど、SRE活動で多岐に利用することを想定します。
要件からWhere, What, How(監視システムの姿)を明らかにする
ここまで5W1Hのうち、Why, Who, Whenの3つからいくつかの要件を導き出しました。
残るWhere, How, Whatを要件をもとに考えます。
それぞれ以下の通り対応します。
- 使用する監視システム (Where)
- 監視対象メトリクス (What)
- 実装と運用の方法 (How)
使用する監視システム(Where)
要件を高いレベルで満たすことから、datadogを採用しました。
- 拡張を容易にする機能(テンプレート変数など)の提供
- AWS環境のメトリクスを即時性高く連携できる機能(CloudWatch Metric Streams)への対応
- UIが優れていて、習得とカスタマイズが容易
監視対象メトリクス(What)
監視システムの対象者がインフラ・SREチームであることから、サービスの信頼性の担保と向上に役立つメトリクスが対象です。
ココナラでは既にREDメソッド、USEメソッドに基づくメトリクス監視を実践しています。
しかしながら先述の通り、システム成長に伴う監視のムラが見えてきました。
なので、引き続きREDメソッド、USEメソッドに基づきながら、監視のムラを無くすためにクラウドサービス毎に監視メトリクスを標準化しました。
以下は、RDS(Aurora)の監視対象メトリクスの一部です。
実装と運用の方法(How)
監視システムの継続的な改善、アラートの網羅性の担保を満たすべく、TerraformでMonitor(アラート)の実装コードを管理する方針を取ります。
またインフラリソースの追加時に必要なコードの修正・適用方法はドキュメントに残します。
これらの実践から標準化された監視対象メトリクスとTerraform moduleで、新規開発時の対応コスト削減を狙います。
まとめ
設計したメトリクス監視のシステム全体像
ここまでの5W1Hに沿った監視設計で、以下の監視システムの姿が明確になりました。
- AWSリソースのメトリクスはCloudWatch Metric Streamsでdatadogへ転送する
- 詳細なメトリクスが欲しいリソース、AWS以外のインフラリソースのメトリクスはエージェントでdatadogへ転送する
- datadog上のMonitorは、Terraformで管理する
今回は5W1Hというフレームワークに則って、前提を整理して要件を定義し、要件を満たす監視システムを設計しました。
5W1Hの枠組みに沿って進むことで、要件を満たした上でシンプルな構成のメトリクス監視システムを実現できます。
最後に
本記事では、インフラリソースのメトリクス監視を一例に、5W1Hを使って監視設計をスムースにする方法を紹介しました。
振り返ってみると当たり前な方法に思えますが、当たり前であるがゆえに「考え方」の情報は少なく、初めて監視設計をする方は悩むポイントだと思います。
フレームワークはコンサルタント業界などで利用されるイメージがありますが、エンジニアにとっても特に要件定義・設計段階では強い味方になります。
本記事が同じように監視設計に悩んでいる方の目に触れ、ご参考になれば幸いです。
ココナラでは、一緒に事業のグロースを推進していただける様々な領域のエンジニアを募集しています。
インフラ・SRE領域だけでなく、フロントエンド領域・バックエンド領域などでも積極的にエンジニア採用を行っています。
少しでも興味を持たれた方がいましたら、エンジニア採用ページをご覧ください。
特にテックブログをご覧いただいて、ぜひ話をしてみたい！と思われた方はカジュアル面談応募フォームからご応募をお願いします。
Discussion