Posted by こんにちは。SREの川野です。
今回は、「Monitoring Modern Infrastructure」を読んで個人的に大事そうなポイントや思ったことなどをまとめてみました。
「Monitoring Modern Infrastructure」とは
Datadogが無料で公開しているEBOOKで、以下URLからダウンロードすることができます。約70ページほどの資料なので比較的読みやすいのではないかと思います。
https://www.datadoghq.com/ja/ebook/monitoring-modern-infrastructure/
こちらの本では、以下の内容について書かれています。
本書では、複雑で動的なインフラストラクチャとアプリケーションを監視するための効果的なフレームワークについて概説します。
主な内容
– 現在の監視に求められるフレームワークについて
– 監視における重要な要素デアメトリクスのグラフ化と視覚化について
– Amazon ELBとDockerの2つのインフラストラクチャテクノロジにどのように適用されるかについて
第1章 絶えざる変化
・現在〜今後のインフラストラクチャに関して、コンピュートインスタンスからコンテナ環境へ移行すればより動的でエフェメラルという傾向を強める
・ホスト個別のデータポイントではなく、サービスの全体的なヘルスとパフォーマンスに注目する
・監視する理由は、パフォーマンスの問題がエンドユーザーに対する問題を引き起こす前に、その問題を検出して解決すること
・急速に拡大する環境では更新と調整が常に必要
・高度な監視システム例
・相対的変化についてのアラート
・外れ値と異常値の自動検出
・インシデント対応の担当者がグラフ、ダッシュボード、イベント、およびコメントを簡単に共有できる
感想
インフラストラクチャの傾向に合わせてソフトウェア開発の運用も変化し、DevOpsの概念が導入され、それらを踏まえた監視のアプローチが必要なんだということが分かりました。弊社では定期的にリリースをまとめて行っているのですが、今後若し、よりDevOpsな運用に変化すると小規模なコードを頻繁にリリースすることになるので、そうなった場合はより詳細な監視が必要だということを認識しておかなければなりません。
第2章 優れたデータを収集せよ
監視するためのデータの形式は以下に分類されます。
・メトリクス
・ワークメトリクス
・リソースメトリクス
・その他のメトリクス
・イベント
ワークメトリクス・・・実質的な問題、多くの場合はユーザーが直面する問題を洗い出すうえで非常に有用。例）スループット、成功/エラーメトリクス、パフォーマンスメトリクス(レイテンシ）
リソースメトリクス・・・ソフトウェアインフラストラクチャのほとんどのコンポーネントは、他のシステムのリソースとして機能。例）使用率、サチュレーション（飽和）、エラー、可用性（リソースが要求に応答した時間の割合）
その他のメトリクス・・・ワークでもリソースでもないメトリクス。例）キャッシュヒット率、データベースロック数
イベント・・・デプロイやバッチ実行など
感想
各メトリクスについて具体例を多く挙げていたのでイメージがつきやすかったです。ユーザー影響があるかどうかを判断するのはワークメトリクスであり、ユーザー影響はないが内部的に問題があることに対してリソースメトリクスやその他のメトリクスを活用するということですね。弊社では、ダッシュボードや監視設定について特に上記のデータ形式で分類していないので、こちらを意識するだけでも良い改善が行えそうです。イベントに関してはバッチ実行が可視化できておらず、デプロイはSlackに通知しているだけなので、こちらもうまくダッシュボードで可視化できると問題の調査をするときに直ぐにあたりをつけることができるかもしれないです。
第3章 本当に重要な問題についてアラートを発行する
・アラートの緊急レベル
・記録するアラート（重大度：低）・・・人が介入する必要がない
・通知するアラート（重大度：中）・・・人が介入する必要があるが、すぐに対応する必要はない
・緊急メッセージを送信するアラート（重大度：高）・・・速やかな介入が求められるアラート
・アラート緊急度の設定方法
・これは本当に問題か？
・この問題に対する注意は必要か？
・この問題は緊急か？
感想
アラートについて緊急レベルに応じた分類を3段階で行っています。アラートは大量に送ってしまうと見なくなってしまいますし、重要なアラートを見過ごしてしまう可能性が出てきます。ゆえに、アラートを出す必要があるかどうか上記のアラート緊急度の設定方法に書いてある疑問を投げかけ精査していく必要があります。特に重大度が高いアラートに関してはワークメトリクス起因のものを設定すると良さそうです（レスポンスタイムやHTTPステータスなど）。弊社では、CPU使用率やスロークエリのアラートを通知しており、問題の早期発見・警戒するためのアラートと認識した上での設定であれば良いのですが、怪しいので考え直す必要がありそうです。また、インスタンスごとにアラートが発行されるので閾値を超えたときに沢山の通知がきてしまっていることも問題なので要改善ですね・・・。
第4章 パフォーマンス問題の調査
具体的な調査手順
・ワークメトリクスから最初に取り掛かる
・リソースの詳細な調査
・何かを変更したか？（イベント）
・修正する
・問題の原因を特定後、修正して症状がなくなれば完了
・今後、同様の問題を回避するためにシステムを変更する方法について検討
感想
分類したデータ形式に基づいて調査をしていくので、データ形式についてチームで認識合わせが取れていればスムーズな調査ができそうな感じです。また、調査を進めやすくするためにダッシュボードの構築にもポイントがあって、
システム自体のメトリクスと、そのシステムが依存するサブシステムの主要なメトリクスを表示できるようにする
ということです。例えばリクエストのドロップの原因がバックエンドのCPU負荷によるものなのかもしれないので、ロードバランサとインスタンスは同じダッシュボードに設定する必要があります。また、ダッシュボードは1つではなく複数作って段階的に抽象度を掘り下げて調査できるようにするとよさそうです。
第5章 時系列グラフによるメトリクスの可視化
時系列グラフ
・折れ線グラフ（デフォルトで多く使用される）
・積み上げ面グラフ
・棒グラフ
・ヒートマップ
空間を横断する集計 ・・・ 例）Web要求についてホストレベルではなく、アベイラビリティゾーン別に集計するなど
感想
具体的なメトリクスを示し、どのグラフ形式にして表示するのが最適なのかということがまとめられていました。タグ付けやアベイラビリティゾーンなどでインフラストラクチャを多次元的に分析できるようにしておくと良さそうです。CPU使用率でヒートマップを勧められていましたが、折れ線グラフの方が見やすいよなあといったこともあるので、あくまでも参考にしてどれがみやすいかを意識して考えるとより良いダッシュボードが作れるんじゃないかなと思います。
第6章 サマリーグラフによるメトリクスの視覚化
サマリーグラフ・・・特定の期間を平坦化して視覚化し、インフラストラクチャの概要を確認できるようにしたもの
時間を横断する集計
・時間を横断 ≒ 時間を圧縮
・過去60分間でのホスト別の最大Redisレイテンシなど
空間を横断する集計
・各内部サービスのピークレイテンシーの表示など
・任意の1台のホストによって報告された最大値のみなど。
感想
サマリーグラフは、抽象度としては一番高いと思うので、最初にみるダッシュボードや簡易版として利用するダッシュボードに設定するのが良いのかなあと思いました。
第7章〜9章
感想
ELBやDockerコンテナの監視について何を考えれば良いのかが書かれていました。コンテナ監視では特にインフラレイヤーを意識して監視のギャップをなくすようにしないといけないみたいです。また、インスタンスよりもよりエフェメラルになる＆数も多いのでタグ付けによってコンテナ群としての監視が必須になってきます。どういったタグをつければ良いのかしっかり考えないといけないです。AMI（マシンイメージ）のタグなどあると良さそうだなと思いました。
最後に
今回は各章ごとに個人的に特に大事そうなところ・気になったところをまとめてみました。「Monitoring Modern Infrastructure」は監視の考え方・フレームワークについて書かれておりDatadogのダッシュボードを使った実践的な内容でした。Datadogを普段使っていなくても監視について理解したい方は是非1度読んでみることをお勧めします。
