概要
初めてサービスを公開するにあたって、障害対策のために監視を強化することになり、入門 監視を読むことで監視に関して知見をつけることにしました。この本の内容についてまとめます。対象として後半の「何を監視すべきか、なぜ監視すべきなのか、どうやっって監視するのかといった監視の戦略」についての内容をまとめます。
フロントエンド監視
監視ののゴール
フロントエンドのパフォーマンス監視のゴールは動き続けることではなく、素早くロードされること
フロントエンド監視には、 リアルユーザー監視(RUM)とシンセティック監視の２つの方法がある。
-
リアルユーザー監視： 監視のデータとして実際のおユーザトラフィックを使うもの
ex)下の Navigation Timing APIや Speed Indexでメトリクスを取得 -
シンセティック監視：Webサイトがうご行っているかどうかをリクエストしてstatus code 200のレスポンスが返ってくることで確かめる方法
ex) Datadog synthetics
フロントエンドパフォーマンスのメトリクス
Navigation Timing API
ブラウザは、W3Cによって推奨されいている Navigation Timing APIという仕様に基づいたAPIを通じて、ページパフォーマンスのメトリクスを公開している。
特に有益なメトリクス
| メトリクス項目 | 内容 |
|---|---|
| navigationStart | ブラウザによってページリクエストが開始されたタイミング |
| domLoading | DOMがコンパイルされロードが始まったタイミング |
| domInteractive | ページが使用可能になったと考えられるタイミング(ページのロードが終わっているとは限らない |
| domCoontentLoaded | 全てのスクリプトが実行されたタイミング |
| domComplete | ページが全て(HTML,CSS,JS)のロードを終えたがイミング |
他にも、 Speed Indexなどのフロントエンドパフォーマンステストツール。
Speed Indexは視覚的な点でページがいつロードされ終わったのかを判断する。
アプリケーション監視
メトリクスでアプリケーションを計測する
まずシンプルにはじめる。
ex)
- データベースのクエリの実行にかかった時間
- 外部ベンダのAPIが応答するのにかかった時間
- あるいは一日に発生したログインの数
ビルドとリリースのパイプラインの監視
デプロイイベントとAPIエラー率のそれぞれのグラフを重ねた表を作ることで、どこのデプロイから挙動おがおかしくなったのかを一目で分かるようにする。
healthエンドポイントによるレスポンスの確認
監視方法
healthエンドポイントに対してhealth()関数を呼び、レスポンスを返してそのステータスコードで成功しているかどうかを判断する
- sqlデータベースに接続してqueryが実行できるかどうか
- Redisに依存性がある場合はRedisに接続してデータを取得できるか否か。場合に応じて書き込みの確認も
マイクロサービスアーキテクチャを監視
監視方法
分散トレーシングにより、1つのリクエストに一意なリクエストIDを「タグ付け」することで、そのリクエストがどのサービスにアクセスしたか、各サービスでどのくらい時間を過ごしたかが分かる。ただ、分散トレーシングを始めるには時間と労力がかかる。
ex) Zipkin
サーバ監視
OSの標準的なメトリクス
OSの標準的なメトリクスは世の中の監視ツールではデフォルトで収集対象になっているため、どうやって取得するかよりも、その意味と使い方について説明。
CPU、メモリ、ネットワーク、ディスク、ロードアベレージなどについて説明されています。今回は省略。
Webサーバ
パフォーマンスとトラフィックのレベルを測る決定版のメトリクスは秒間リクエスト数。
基本的には秒間リクエスト数はスループットの指標。
パフォーマンスにはそこまで致命的ではないが全体の見通しで重要なのがHTTPステータスコードの監視。
もう1つ便利なメトリクスが、リクエスト時間。
DBサーバ
監視項目
- まず監視するのはコネクション数(MySQLではスレッドと表現している)
- どれくらい忙しいのかをみるのには秒間クエリ数をみる。
- スロークエリー(クエリの実行時間、実行回数、そのクエリ自体をあわせてログに出力される)
- レリプリケーションの遅延
- IOPS
参考資料： 実践ハイパフォーマンスMySQL Database Reliability Engineering
ロードバランサー
ロードバランサはヘルスチェックを通じてバックエンドサーバの状態を判断する。
監視項目
- フロントエンドとバックエンドの2つのメトリクスを両方とる必要がある
キャッシュ
主なメトリクス
- キャッシュから追い出されたアイテム数(evicted items)
- ヒット・ミス比率(hit/miss ratio、又はキャッシュヒット率[cache-hit ratio])
キャッシュから追い出されたアイテム数が多いということは、キャッシュ容量が足りないということ。
キャッシュの目的はよくあるリクエストの応答速度をあげることだが、キャッシュミスはその速度をさげてしまう。したがって、ヒット・ミス比率を監視するのはキャッシュパフォーマンスを確認するのに良い方法。
まとめ
フロントエンド、アプリケーション、サーバーのそれぞれのレイヤーについての監視の目的と監視する項目について本の内容から抜粋して書きました。この本でも書かれていることで、まず監視をはじめて、定期的に監視を振り返ってブラッシュアップしていくことが大事だとのことでした。