読書レビュー「入門 監視」
こんにちは！
今担当している案件で、監視SaaSとして「Datadog」を導入することが決まりました。
しかしながら、そもそも「監視」についてよく理解していないのが現状でした。。
そこで監視のTHE入門書とも言われている「入門 監視」を購入し、読了したので内容を整理したいと思います！
「入門 監視」とは
「入門 監視」とは、オライリージャパン社から出版されているシステム監視に関する入門書です。
概要は以下のとおり。
あなたのシステムはきちんと動いていると言えますか？
本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかについて解説する書籍です。
前半で監視のベストプラクティス、デザインパターン／アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。
監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。
本書のポイント
本書のポイントを章別でピックアップしていきたいと思います。
第１章 監視のアンチパターン
この章では、システム監視を行う上でよくありがちなアンチパターンについて紹介されています。
ツール依存であること
「何をやるか」よりもツールに焦点を当てすぎてしまい効果的な監視ができていないケースが多々あると述べています。
IT業界でありがちな「目的よりも手段にフォーカスしてしまう」やつですね。
効果的な監視を行うためのツールを選定するには「とにかく人と話すこと」が有効であると述べています。
アプリケーション開発メンバー、リーダー、プロダクトマネージャーなど様々な役割の人達と話していくことで
メンバーがどんな監視方法を求めているのかを見つけ、ツールを選定していくことが重要みたいですね。
また「カーゴツールなツールは避けよう」という記述も印象に残りましたね。
過去の成功や他社の成功体験をそのまま自分達に適用させてしまうということはよくあると思います。
他社の成功体験などをベースに自分達の状況を考慮して効果的に適用させることが必要でしょう。
役割としての監視
大きな組織の場合、監視専門のメンバーがアサインされていてその人達だけが監視について設定、管理しているということがあると思います。
それはアンチパターンであると筆者は述べています。
確かにアプリケーションやデータベースのことをよく理解していない人達だけで効果的な監視はできるとは考えにくいです。
「監視とは役割ではなく、スキルでありチーム内全員がある程度のレベルに至っておくべき」と述べられております。
ソフトウェアエンジニアは誰よりもアプリケーションに詳しいので素晴らしい監視の仕組みがデザインできるというわけですね。
チームとしてアプリケーションをリリースするだけなく、監視の仕組みを作るまでは本番環境とは言えないとも述べています。
そのためには監視というものを組織に浸透させるための教育や仕組み作りが必要ですね。今私がやっている案件ではこの点についてどうやって行うのがベストなのか悩んでいます。
チェックボックス監視
チェックボックス監視とはただただ形式的に監視をしているだけの状態になってしまっている状態のことを指します。
もう少し具体的にいうと
- CPUやメモリ、ディスクなどのメトリクスは記録しているが、システムがダウンしていることの理由はわからない
- 誤検知が多すぎるのでアラートを常に無視している
みたいな状況に陥っている状態ですね。先程の役割としての監視でもあった通り、システムの構造をよくわかっていない人が監視を設定するとこうなります。
チェックボックス監視状態を解決するためには以下３点の方法を実践しようと述べられています。
1.「動いている」かどうかを監視しよう
ユーザにとって最も関心があるのは、CPUやメモリの使用率が80%以上を超えているかどうかでもなく、ディスクがあと少し逼迫しそうかどうかでもありません。
「アプリケーションが問題なく動いているかどうか」です。
動いているかどうかの定義はサービスやアプリケーションのオーナーに聞くと良いみたいです。
具体的な監視方法としては、HTTPリクエストを行うことでリターンコードやレスポンス時間を判断材料に動いているかどうかをチェックします。
こうすることで何がおかしいかは特定できませんが、何かがおかしいということを検知することができるようになります。
2.OSのメトリクスについてアラート設定をしてもあまり意味が無い
これはどういうことかというと、たとえCPU使用率が80%を超過していてもアプリケーションが安定して動いていれば問題は無いということですね。
アラートは”アプリが問題なく動いているかという監視項目”に対して設定すべきだと述べられています。
3.メトリクスは高頻度で取得しよう
複雑なシステムほど短時間で様々なことが起きます。５分に1回のペースではそういったイベントを見逃してしまいます。
最低でも60秒に1回のペースで取得すべきだとされています。
監視を支えにしてしまう
どれだけ監視を仕組みを完璧にしたとしても、アプリケーションの問題を検知するだけであり、修復はしてくれないということに注意すべきであると述べられています。
監視の仕組みが完璧だからアプリケーションは安全だ！と満足せずに問題を解決する取組みも行いましょうということですね
手動設定
監視設定は100%自動化すべきだと述べられています。
昨今のマイクロサービスアーキテクチャはシステムの集合体なので手動は限界があるとのことです。なんとなくイメージつきます。
monitoring as codeしよう。ってことだと思いますが、コード化っていろいろと難しいんですよね・・・話逸れてしまうのでここでは述べませんが。
第２章 監視のデザインパターン
この章では監視の仕組みをより良くするためのデザインパターンが紹介されています。
組み合わせ可能な監視
良いツールを複数使い、それらを疎結合にして監視プラットフォームを作るべきだと述べられています。
そうすることであるツールが合わなくなってきたらプラットフォーム全体を置き換えるのではなく、そのツールだけを削除して置き換えるだけで済むというメリットがあげれています。
この意見については100%鵜呑みにはできないと考えています。というのも、各ツールの知識が必要になるという学習コストの面と自動化を含めてツールを組み合わせるのが大変という作業コストが
大きくかかるのではないかと思っているからです。Datadogのようなほぼオールインワンでやってくれるツールを使えば良いのではないかと思いますが、そこはバランスが重要ですね。
そして良い監視プラットフォームを構築するためには、プラットフォームの構成要素を理解する必要があると述べられています。
・データ収集
監視対象のデータを収集する方法として２つあります。
【プル型】
監視サービスが監視対象に対して、監視データを送りつけるようにリクエストするタイプです。
例としてはヘルスチェックによるデータ収集ですね。
プル型のデメリットとしては、監視サービスが全ての監視対象に対してリクエストするスケジュールすることに責任を持たなければならず
容易にスケールしにくい。ということが挙げられています。
【プッシュ型】
監視対象が監視対象に対して一定間隔で監視データをプッシュするタイプです。
例としてはsyslogの転送があげられますね。
プル型とは違って、データの送り先さえ知っておけばデータの受け側がどういう仕組みなのかを意識する必要はないので、スケールしやすいです。
それぞれの特徴を踏まえた上でどちらを選択するか決めた方が良いですね。
また、取得する監視対象のデータは大きく分けて２種類あります。
【メトリクス】
メトリクスとはシステム全体で監視および収集できるリソース使用量または動作の測定値のことを示します
さらにメトリクスは２種類に分かれます
・カウンタ
増加していくメトリクスのことみたいです。具体例はWebサイトに訪れる累計人数やリクエスト数などが挙げられます。
・ゲージ
ある時点の値を示すメトリクスのことみたいです。具体例はCPU使用率などが挙げれます。
ゲージの仕組みには欠点があり、値そのものに着目しても過去の傾向や未来の値を予測する情報が得られないと述べられています。
ただし、ゲージを時間刻みに取得していけばこの問題は解決できると述べられています。
【ログ】
ログは様々の情報が記載された文字列の集合体です。素のログだと情報量が多いので効率的に情報を得るには何らかのパースが必要です。
さらにログには２種類の分かれます
・非構造化ログ
パッと見でどんな情報が記載されているのかわからないログです。Apacheのログをイメージするとわかりやすいかもしれません。
・構造化ログ
キーと値の集合体です。JSON形式で書かれているようなログです。こっちのわかりやすいのでオススメされていました。
・データストレージ
データを収集したら当然保存するわけですが、大抵は時系列データとして保存されます。
ここで重要なポイントは過去のデータは「間引く」ことが大切である。という点ですかね。
例えば60秒に1回データを取得するとしてそれを１週間分保存したとすると、1日86400データ×7日間=604800データも保存することになります。
この場合、大量のデータを保存するためのディスク容量が必要であるということと、そのデータを元にグラフを描写するまでに多くの時間が必要であることが問題として挙げれています。
そのような問題を解決するために60秒に1回取得していたデータを3日程度経過したら5分単位のデータとしてまとめると良いと述べられています。このことを「間引く」と呼ぶようです。
確かにそのとおりで、過去の１週間のCPU使用率を60秒ごとの粒度で気にする必要なんてないですよね。直近のデータは細かく見たいですが、過去のデータは大まかな動きが分かれば充分です。
・可視化
データを保存したら、グラフなどを使って可視化するわけです。複数のグラフが集まったものをダッシュボードと呼びますが、価値のあるダッシュボードはどんな特徴があるのでしょうか？
ハイレベルな概要だけを示しているメインのダッシュボードがありつつ、各サービス別のダッシュボードで構成されていると良いみたいです（わかりにくい・・・）
無理に１つのダッシュボードに全ての情報を詰め込むのではなく、複数のダッシュボードを用意して見やすくすることが大事ですね
なお、ダッシュボードが最も効果的なのはそのサービスを最もよく理解している人たちによって作られ、運用されている時だと述べられています。
これはイメージつきやすいと思います。サービスを理解していない監視専門の人みたいな人が良いダッシュボードを作成できるとは思えませんね。
・アラート
「何か起きた時にアラートを出すことが監視システムの目的」という考え方は間違いであると述べられています。
「監視は質問を投げかけるためにある」のであり、必ずしも取得するメトリクスとアラートが１対１で対応している必要はないということみたいです。
ユーザ視点での監視
アンチパターンの「チェックボックス監視」でも述べられていましたが、
アプリケーションを利用するユーザにとって、サーバのCPU使用率やメモリ使用率はどうでもよくて、アプリケーションが問題なく動いているかどうかが重要です。
なので、監視項目を設定する時は、「このメトリクスはユーザへの影響をどう教えてくれるのか」ということを自問自答しながら設定していくことが大事だと述べられています。
作るのではなく買う
NetfilixやTwitterとかのサービスレベルでもない限り、自前で監視する仕組みを構築するのではなく、SaaSを使いましょうってことです。
自前で構築するコストと比べて安い、自分達のプロダクトに注力できるなどのメリットがあるからですね。
監視ツールに限らず、SaaSを利用した方が良い場面は多々ありますよね。
第３章 アラート、オンコール、インシデント管理
第３章では、監視の基本となるアラート、オンコール、インシデント管理に関する原則が書かれています。
アラート
まず良いアラートの仕組みを作るには６つの大事なポイントがあると述べれています。
1.アラートにメールを使うのはやめる
全てのアラートをメールで送ってしまうと受け取る人がアラート疲れをし、迅速なアクションが取れなくなるという問題が生じます。
そこで、以下のような手段を使ってアラートをパターン別に通知すると良いようです。
1.すぐに応答orアクションが必要なアラート
SMSやPagerDutyなどのページャに送る
2.注意は必要だが、すぐにアクションのいらないアラート
社内チャットツールに送る(SlackやTeams)
3.履歴や診断のために保存しておくアラート
ログサービスへ転送
”すぐに対応すべき”か”そうでないか”で通知手段が違ったら、確かに適切な動きが取れそうなのはイメージできますね。
2.手順書を書く
アラートがきた時にどんな対応を行えばいいかを示した手順書を用意しましょう。
手順書の中身は、対象システムの構成、エスカレーション手順、どんな監視項目が設定されているか、復旧手順などが記載されていると良いようです。
また、アラートの一部に手順書のパスを記載しておけば、そのままスムーズに対応に移れると述べられています。
3.固定の閾値を決めることだけが方法じゃない
前章にも出てましたが、「XX使用率が80%を超えた」みたいな監視はあまり意味がありません。
「一晩でディスク使用率が10%から60%にあがった」のような監視を行うことが、システムに問題が起きているかどうかを発見することができます。
昨今の監視ツールはそういった監視の方法ができるようなので是非とも取り入れていきたいですね。
4.アラートを削除し、チューニングする
定期的にアラートを見直して、アラート疲れを削減していこうということです。
見直す基準は、
・誰かがアクションする必要のあるアラートになっているか
・過去１ヶ月のアラート履歴を見て、どんなアクションをとったか、アラートの影響はどうだったか、削除できるアラートは無いかを振り返る
などを行い、減らしていくと良いみたいです。
5.メンテナンス期間を使おう
アプリケーションをリリース、サーバーのスペックを増強するためにサービスを一時停止するような場合はアラートもメンテナンス期間に設定してアラートを止めておきましょう。
確かにサービスが一時停止している事を知らないチームメンバーはアラートによってビックリしてしまいますからね。
大抵の監視ツールがメンテナンス期間にできる機能を備えていて、特定の期間だけアラートを発信しないことができるます。しかも事前に「このアラートは今からメンテナンス期間に入るよ」みたいなアラートを出してくれたりします。
6.まずは自動復旧を目指す
アラート検知したあとのアクションが、”特定のドキュメントの手順に沿って対応する”みたいな運用をしているならば、自動復旧を目指しましょうと述べられています。
それがアラート疲れを避ける良い方法です。
オンコール
オンコールとは、何か問題が起きた時にいつでも対応できるようにしている担当のことです。
自分の会社にそんな担当はいなくて、私が案件の環境構築・開発をしつつ、常にオンコール担当みたいなものなのでしんどいなぁと感じました（笑）
でもお金のある会社じゃ無い限り、ほとんどの会社がそんな感じですよね。
そんなオンコール担当ですが、誤報が多かったり、場当たり的な対応が多かったり、わかりにくいアラートが頻発すると数ヶ月後には怒りっぽくなる、心配性になる、睡眠不足になるなどの症状が発生するとのこと。
ここまでの症状は発症したことはないですが（笑）、通常の案件を遂行している最中にアラートを検知して、影響や原因などを調査していると集中力切れたり、パフォーマンスが落ちたりします。
そんな問題を解決するためには、以下３点の方法で解決しましょうと述べられています。
1.誤報を修正する
アラートをチューニングして、100%の正確性を目指していこうと述べられています。
そのためにはオンコール担当が日々、前日に送られたアラートの一覧を作って改善できるポイントや削除できるアラートを検討していくと良いようです。
これはプロジェクト遂行とオンコール担当を兼任してたらそんな余裕無いので厳しそうですね・・・
2.無用の場当たり的対応を減らす
監視自体はシステムに異常が発生したことを報告するだけであり、何も修復はしてくれません。場当たり的な対応を止めるにはその基礎にあるシステムを改善するのに時間を使うべきだと述べられています。
・オンコールシフト中に場当たり対応をしていない時間帯は、システムの改善する時間にあてる
・前週の監視情報を元に、次週のチーム会議でシステムの安定性や回復性について取り上げる
と良いと述べられています。
3.上手にオンコールローテーションを組む
うまくオンコールシフトを組んで、オンコール担当者が燃え尽きないようにしようということですね。
最低でも４人１チームを作り、１週間ごとにローテーションしていくと良いようです。
また、ソフトウェアエンジニアもオンコールのローテーションに加えるべきだと述べられています。
ソフトウェアエンジニアリングにおける「丸投げ」を避けるという意図があり、オンコール担当中に発生した問題にソフトウェアエンジニアが気づいた場合により良いソフトウェアを作ろうというインセブティブが生まれますし、
ソフトウエアエンジニアとインフラエンジニアを一緒にすることで、お互いの共感が高まるというメリットもあるようです。
インシデント管理
問題が発生したら、きちんとインシデント管理を行うことと述べられています。
以下のようなプロセスが行えたら良いようです。
- インシデントの認識（監視が問題を認識）
- インデントの記録（インシデントに対しての監視の仕組みが自動的にチケットを起票）
- インシデントの診断・分類・解決・クローズ
- 必要に応じてチーム内でコミュニケーション（会議など）
- インデント解決後、回復力を高めるための改善策を考える
この際、役割をしっかり決めて対応しましょう。
・現場監督官
この人は、システムの改善、顧客や社内とのコミュニケーション、調査には関わらず、インシデントに関する調査を監督するだけの役割だと述べられています。
つまり、上記のプロセスが最初から最後まで行えたかどうかをチェックし続ける人ですね。
・スクライブ
誰が何を行ったのか、どんな決断がされたのかを記録する書記役。この人も調査や改善は行いません。
・コミュニケーション調整役
社内外問わずステークホルダーに最新状況のコミュニケーションをとる人。
ステークホルダー（経営者など）がインシデント解決に取り組んでいる人達に余計な口出しをするなどの邪魔をしないようブロックをするのもこの人の役目だと記載されています（笑）
・SME（subject matter expart）
実際にインシデント対応する人です。
第４章 統計入門
この章は、統計学について記載されています。
監視において何故統計が重要かというと、監視データから今後のシステムの変化が推測できるからです。
例えば、閾値を超えたのがたまたまだったのか、今後も定常的に超えるのかなどが統計学によって予測出来たりします。
あとは具体的な統計学の内容だったので本記事では割愛します。
第５章 ビジネスを監視する
第２章でも記載されていた通り監視はインフラの部分から始めるのではなく、まずは外側（サービスが動いているか、ユーザに影響は無いかなど）から始めるのが重要です。
外側監視の項目はビジネス的な観点から生まれます。事業責任者が最も理解している領域ですね。
そんなビジネス観点の知識はエンジニアも身に付けるべきだと述べられています。
そうすれば非常に重要で大きくレバレッジの効いた、ビジネスに直結する問題に取り組めるからです。
では、ビジネス観点の知識とは何でしょうか？それはビジネスKPIです。
ビジネスKPI
KPI（key performance indicator）は、全体としてビジネスが良い状態であるために会社が重要だと認識している計画をどのように実行しているかを測るためのメトリクスです。
インフラのCPU使用率などのパフォーマンス指標のように、KPIはビジネスの調子が良いかどうかを教えてくれます。
経営者から事業責任者から受ける質問は以下のような質問が挙げれます
- 顧客はアプリケーションあるいはサービスが使えているか
- 儲かっているか
- 成長しているか、縮小しているか、停滞しているか
- どのくらい利益が出ているか、収益性は改善しているか、悪化しているか、停滞しているか
- 顧客は喜んでいるか
上記質問に答え流ために事業責任者がよく使うビジネスKPIのメトリクスが記載されています。
結構数が多いので全ては書きませんが、月次経常利益やアクティブユーザ数、顧客の解約数などが挙げれています。
ビジネスKPIを技術指標に結びつける
ビジネスKPIが決まったら、それを監視ツールでチェックするために技術指標に結びつけましょうと述べられています
例えば、コメント投稿をビジネスKPIにしているならばコメント投稿失敗やコメント投稿のレイテンシを技術指標として監視するなどですね。
会社のビジネスKPIを見つける
実際に自分の参画しているプロジェクトのビジネスKPIを見つけてみましょう。
どうやって見つけるのか？答えは、とにかく人と話すことだと述べられています。
まずは、プロダクトマネージャ。１番顧客との距離が近いですからね。次にプロジェクトマネージャ、ソフトウェアエンジニアリーダーの順番が好ましいようです。
また、ビジネスKPIを見つけるためによく行っている質問が紹介されていました。
- 会社に入りたての人がアプリケーションが動いていることをどうやって知ったら良いか？何をチェックしているか？
- アプリのKPIは何か？何故そのKPIを使っているのか？そのKPIはどのような事を教えてくれるのか？
第６章〜第１１章
第６章〜第１０章までは、フロントエンド、バックエンド、インフラ、ネットワーク、セキュリティのより具体的な監視について記載されています。
それらについて記載するときりがないので本記事では割愛します（笑）
第１１章は、架空のシステムを材料に今までの章のおさらいが記載されています。
まとめ
いかがだったでしょうか。そもそも監視って何だっけってところから記載してくれているのですごく良書だと思います！
監視の考え方が記載された１〜５章のはわかりやすかったですが、具体的な監視について記載された６〜１０章は正直わかりにくかったです。
これから監視の仕組みを構築していくときには、本書に記載されていた考え方を念頭に構築していきたいです。
以上です！それでは。