Posted by こんにちは。SREの川野です。
今回は、「入門 監視」を読んで個人的に大事そうなポイントや思ったことなどをまとめてみました。
「入門 監視」とは
オライリーが出版している本で2019年の1月に発売されています。
https://www.oreilly.co.jp/books/9784873118642/
こちらの本では、2部構成になっており第1部ではアンチパターンや監視についての新しい考え方について、第2部では監視戦略について書かれています。
第1部 監視の原則
1章 監視のアンチパターン
・オペレーションチームだけでなく全員が本番環境全体に責任を持つこと
・監視を設定する人がシステムの動作を完全に理解していない状態だと、チェックボックス監視になってしまう
・「動いている」とはどういう意味か。HTTP 200 OKが返ってきている、ページに特定の文字列があるかどうか、リクエストのレイテンシが小さいかどうか
・60秒に1回はメトリクスを取得する
・壊れたら監視を追加して対応することは何も役になっていない
・アラートに参照されている対応手順のみで対応できるものであれば自動化する
感想
チェックボックス監視はありそうだなあと思いました。各コンポーネントの依存関係やインフラレイヤーについてどういった監視をするべきか理解が必要です。また、「動いてる」とはどういう意味かについては、Monitoring Moderin Infrastructureに書いてあったワークメトリクスと通ずるものがありました。壊れたら監視を追加して解決ではなく、自動回復やアーキテクチャを変更するなどして改善を行い根本原因をなくすように動かないといけません。弊社で設定しているアラートメッセージには、何をどうすれば良いかという次のアクションについては大体設定はできています。ちょうど以前、スロークエリアラートのメッセージでCloudWatchLogsのここみてください、といった具合に書いていたのを自動で取得して表示するみたいなことを対応したのですが、こういった自動化を行えるものはどんどんしなきゃという気持ちです。
2章 監視のデザインパターン
・メトリクスの表現方法
・カウンタ（Counter）・・・増加していくメトリクス
・ゲージ（Gauge）・・・ある時点の値
・ログ
・構造化ログ・・・プログラムで処理しやすい
・非構造化ログ・・・人間が読むだけなら非構造化ログのままでもよい
・ユーザー視点での監視（HTTPレスポンスコード、レイテンシ）
3章 アラート、オンコール、インシデント管理
アラート・・・アラートを受け取った人に緊急性があり、すぐに対応する必要があることを認識させるためのもの
直ぐに応答かアクションが必要なアラート→SMSやPagerDutyなどのページャ
注意が必要だが直ぐにアクションは必要ないアラート→社内のチャットルーム
履歴や診断のために保存しておくアラート→ログファイル
手順書を書こう
・これは何のサービスで、何をするものか。
・誰が責任者か。
・どんな依存性を持っているか。
・インフラの構成はどのようなものか。
・どんなメトリクスやログを送っていて、それらはどういう意味なのか。
・どんなアラートが設定されていて、その理由は何なのか。
感想
弊社ではPagerDutyなどのページャは使用していないので、使っていかないといけない気持ちはあるですが、エスカレーションしたりオンコール対応のローテーションを組めるほどの組織規模ではないので個人的には必要ないのかなと考えています。ただページャを使用しないのであれば、インシデント管理について別のやり方を検討する必要がありそうです。手順書については、上記のような情報が乗っていると開発チームのエンジニアでも次のアクションをどうすれば良いのかがわかるのでDevOpsの観点でも非常に良いと思いました。
4章 統計入門
・移動平均（moving average）・・・時系列データにおける平均のよくある使い方の1つ。データポイントを一定の時間間隔の平均値としてグラフにプロットすることで平滑化され見やすくなる。しかし、代わりに正確さを犠牲にしているためバランスをとって平滑化しないといけない。
・中央値（50パーセンタイル）・・・平均値の正確さが欠ける場合（一方方向に大きな偏りのあるデータセット）に使用する。
・周期性・・・今のデータポイントと1週間、1時間前とを比較したり、将来の負荷について推測できる。
・分位数（quantile）・・・最もよく使われる分位数がパーセンタイル。パーセンタイルを使うことで、外れ値を無視して大部分のユーザに対するサービス品質がどうだったかについて有益な情報を得ることができる。ある程度のデータポイントを捨てているので、最大値も計算しユーザに対する最悪のシナリオについても確認をした方がよい。
・標準偏差（standard deviation）・・・平均からどの程度離れているか表現する方法。正規分布しているデータセットに対してしか適用できない。
第2部 監視戦略
5~10章
各章で以下のレイヤーについて具体例を交えながら監視の考え方が書かれていました。個人的な感想をまとめています。
・ビジネスKPI
ビジネスKPIはインフラの監視とは関係ないんじゃないかと思っていましたが、技術指標に結びつけたビジネスKPIの表があって、技術スタック以外の面でも監視は活用できるんだと考えの幅が広がりました。例えば、ビジネスKPIでユーザのログインだったら、技術指標としてはユーザのログイン失敗、ログインのレイテンシといったものが使われます。弊社ではビジネスKPIの分析に別のツールを使用しているため、Datadogとの相関性を持たせるようにダッシュボードを工夫できると良いのかなと思いました。
・フロントエンド
弊社では、既にサーバ側でレスポンスタイムを計測していましたが、フロントエンドを含めた全体のページのロード時間は計測していないので、Synthetic（外形監視）をして計測してみる観点も重要だということが分かりました。curlコマンドを使用したり、WebPageTest を使ってチェックすることもできます。試しに弊社のサービスの公式サイトを分析してみましたが、初回アクセスが8秒で2回目以降がアセットがキャッシュされても4秒という結果でした。これは現状のダッシュボードでは確認できていなかった数値でしたので改善が必要です。
・アプリケーション
APMは、運用しているサービスのアプリケーションやビジネスロジックについて把握していないので、使用については制限事項があるという切り口からStatsDというツールを使ってサービス独自のアプリケーションのメトリクスを追加していきましょうといった内容でした。弊社ではDatadogを使用しているのでStatsDを拡張したDogStatsDを用いてカスタムメトリクスを追加することができます。現状の監視設定で物足りないところはこの方法で補うことができそうです。
・サーバ
OSの標準的なメトリクスについて、各コンポーネントやキャッシュ、DNSなどについて書かれていました。メモリに関しては、OOMKillerの呼び出しを監視するアラートは良いなと思いました。ログにkilled processでgrepし、追うことができるようです。WebサーバについてはHTTPキーブアライブを使用してクライアントがコネクションを再利用することで効率化しており、また最近のブラウザでもデフォルトでパーシステントコネクションを使用しているのでコネクション数よりもリクエスト数に注視していくのが重要です。他にもスケジュールジョブの監視でデータが存在していないことを検知するデッドマン装置と呼ばれる仕組みをスクリプトで紹介されていました。
・ネットワーク
ネットワーク監視パッケージの多くにSNMPを使用する機能が含まれているらしく、コマンドラインからSNMPを使用する方法だったりインタフェイスのメトリクス（帯域幅、スループット、レイテンシ、エラー、ジッタ）、ルーティングプロトコルや、スパニングツリープロトコル、フロー監視などの説明がされていました。弊社ではスループットは設定していましたが、ネットワークレイヤーでのレイテンシと帯域幅は設定してなかったので改善が必要です。フローとは一定方向へのパケットのシーケンスのことで、フロー監視をすることで帯域幅を大きく使っているノードを突き止めたり、IPごと、プロトコルごと、サービスごとといった単位で帯域幅の使用率の分析ができるようです。
・セキュリティ
セキュリティは脅威とリスクを見積もり、不正アクセス時に決断を下すことという説明がありました。何でもかんでもセキュリティのレベルを高くしすぎることはコストパフォーマンスがよくないみたいです。監査ログについては、弊社ではAWSのCloudTrailを使用していますが、ユーザ認証の失敗などを監視できれば社内でいち早く問題に気付けるので良いのかなあと思いました。
最後に
今回は各章ごとに個人的に特に大事そうなところ・気になったところをまとめてみました。「入門 監視」は監視についての概念と戦略について書かれているといった印象でした。前回記事の「Monitroing Modern Infrastructure」と合わせて読んでおくと、言葉は違いますが同じようなことが書かれていたりしたので、そういったものは特に重要そうだなと思ったりしました。監視について詳細に理解したい方は是非1度読んでみることをお勧めします。
