2章　監視のデザインパターン

作成日: 2024/6/5

最終更新日: 2024/6/11

2.1 デザインパターン1: 組み合わせ可能な監視

専門化されたツールを複数使い、それらを疎に結合させて、監視「プラットフォーム」を作ること

モノリシックなツール (e.g. Nagios) とは対象的

Unix哲学を実践的にした考え方とも言える

「1つのことを行い、またそれをうまくやるプログラムを書け。協調して動くプログラムを書け

→ なるほど、コードを書くときと同じだな。疎結合。ドメインモデル、ドメインオブジェクトとも同じ感じ。

あるツールがやり方に合わなくなった時、監視プラットフォーム全体を置き換えるのではなく、そのツールだけを削除して、他のもので置き換えればよい

柔軟性

アーキテクチャは複雑になるが、そこから得られる利益のほうがコストを上回る

2.1.1 監視サービスのコンポーネント

監視サービスの5つの要素

データ収集

データストレージ

可視化

分析とレポート

アラート

データ収集方法

主な方法は「プッシュ」」と「プル」。都合がよい方を使えばよい。

プル型

サービスがリモートノードに対して、ノードの情報を送りつけてくるよう要求を出す

SNMP、Nagios

→ AWS ALB がターゲットに対して行うヘルスチェックはこれ？

→ Mackerelの死活監視は、自前で作ったヘルスチェック用エンドポイントに定期的にMackerelからリクエストするようにしてる、それもこれ？

メトリクスに関しては、プル型のメカニズムには面倒な欠点がある

プル型は中央システムがすべてのクライアントを把握してスケジュールし、応答をパースしなくてはならないので、スケールしにくい

プッシュ型

クライアント (サーバーやアプリケーションなど) がデータを他の場所に、一定間隔あるいはイベントが発生したタイミングでプッシュする

ポーリングを行う中央サーバーは存在しないので、クラウド環境のように分散アーキテクチャではスケールしやすくなる

ポーリングを行うサーバーが複数いる場合ポーリングスケジュール調整は難しく、全ノードのマスタリストを管理する必要がある

データをプッシュするノードは、送り先さえ知っておけば、データの受け側がどう実装されているかは気にする必要がない

データの種類

メトリクス

カウンタ (Counter)

増加していくメトリクス

e.g. Web サイトに訪れる累計人数

ゲージ (Gauge)

ある時点の値

時系列データベース (TSDB) に保存することで、後から過去のデータを取り出したり、グラフにプロットしたりできる

これから扱うものの多くはゲージのデータ

ログ

基本的には連続した文字列

いつイベントが発生したのかを示すタイムスタンプが関連づけられたもの

「構造化ログ」と「非構造化ログ」の2つのタイプがある

非構造化ログ:

各フィールドに対して明確な意味のマッピングがない

順序が意味を持つ場合がよくある

NGINXやWebサーバーに慣れていない人は、NGINXのドキュメントを見ずに各フィールドの意味を理解するのが難しい

ログエントリはキーと値のペアの集合

キーの意味が明確なので、各フィールドの意味を理解するのが簡単

コンピューターが情報を簡単に抽出できるようになる

JSONが人気

→ 今さらだけど、構造化ログの良さみ、腹落ちした。たしかにたしかに。キーがなくてもなんとなく雰囲気で読み取れてたけど、たしかにキーがあった方が人間も読みやすいし、コンピューターに何かやらせるのもやりやすい。今まで「何かと便利なんだよー良いんだよー」と言われるからそうなんだろなーと深く考えてなかったけど。あと慣れると JSON だと逆に見にくかったりしたもんで。

ログ転送

リモートのロギングサービスにログを転送しておけば、ログをチェックするために各Webサーバーにログインする代わりに1箇所でログを分析でき、Webサーバーが何をしているかより全体像を掴みやすくなる

→ CloudWatch とか Datadog とか

アプリケーションからログに情報を出力すべき

データストレージ

データを収集したらどこかにそれを保存する必要がある

メトリクスは時系列データベース (Time Series Database) へ

TSDB とは、タイムスタンプと値というキーと値のペアから構成される時系列データを保存するためにデザインされた、専用のデータベース

キーと値のペアを「データポイント」という

TSDB の多くでは、一定期間後にデータの「間引き」(roll up) や「有効期限切れ」が発生する

データが古くなったら、複数のデータポイントが1つのデータポイントにまとめられる

平均化

データポイントの合計、など

→ CloudWatch の Metric とかそうだった覚え > 「間引き」(roll up) や「有効期限切れ」

そういえば、DB dump も間引き... DB Dump もゲージ的なものだな

先週のCPU使用率を60秒ごとの粒度で気にするなんてない

運用上のデータについては、直近のイベントの方を注視していて、古いトレンドは大まかな動きがわかればよい

ログのストレージには2つの方法

通常のファイル

検索エンジン (e.g. Elasticsearch)

より高度な方法

多くのロギングプラットフォームは、検索を透過的に行えるストレージコンポーネントを備えている

メトリクスのストレージは比較的安い

ログの保存は高くつく

データ量が多い

圧縮したり保存期間を設定する

→ CloudWatch に転送して、3ヶ月とか半年とか1年とか経ったらS3 → S3 Glacier へ... みたいなやつだな

可視化

ダッシュボードは、自分自身やチームの求めるものに沿った形でデータを理解できるものであると良き

「優れた監視の背景にある原則は、あなたの環境で最適に動く仕組みを作るべきだということです。」

時系列データの最も一般的な可視化の方法は、折れ線グラフ

お願いだから円グラフは使わないで

ある時点での状態の可視化

あまり変化しない値を表現するのに向いている

データと全体の関連を表現する

それでも棒グラフの方が良い可視化の方法である場合が多いです

→ 他のところでも聞いたような

価値あるダッシュボードには、異なる視点とスコープがある

ある場面でもった疑問に回答をくれる

→ Datadog とかそういうみがある気がするが、情報量が多く機能も多いので.....使いこなせてない

最高のダッシュボードは、1つのサービスあるいは1つのプロダクトのステータスを表示することに焦点を絞るもの

ダッシュボードが最も効果的なのは、そのサービスを最もよく理解している人たちによって作られ、運用されている時

→ サービスイン前だとばっちりこれだ！というのがはっきりしない場合もありそうな気がする。やはり育てていくものなのかもな。

分析とレポート

ユースケースとして、アプリケーションとサービスのサービスレベルアグリーメント (SLA) を決定し、レポートする場合など

SLAとは、サービス提供者と顧客 (外部の課金顧客か、社内のチームなのかは問わない) との間で取り交わされる、アプリケーションやサービスに期待される可用性についての契約。

通常、月ごとに決められる

ペナルティの有無に関係なく、可用性を有効に報告できるよう、監視データが完全で正確であることが重要

SLAとは、(ほとんどの場合) 願望や嘘である)

可用性は、9の数で表す

99%はツーナイン、99.99%はフォーナイン

「サンプリングエラーに気づいていますか」

全体の可用性を計算してしまう

あるサービスの可用性は、そのサービスの下のレイヤーにあるコンポーネントの可用性を超えることはできない

アラート

「監視は、質問を投げかけるためにある。」

何か問題が起きた時にアラートを出すことが、監視システムの目的ではない

監視とはアラートを出すために存在しているのではない

→ そうですねえ。最初に監視設定したときははそんな気持ちだった。

収集しているメトリクスやグラフそれぞれは、アラートと1対1対応している必要はない

→ それはそうだな

2.2 デザインパターン2: ユーザ視点での監視

できるだけユーザーに近いところから監視を始める

ユーザーが我々のアプリケーションとやり取りするところ

ユーザーが気にするのは、アプリケーションが動いているかどうか

ユーザー視点を優先した可視化が必要

HTTPレスポンスコード (特に HTTP 5xx 番台)

その次に、リクエスト時間 (レイテンシ)

どちらも何が問題なのかは教えてくれないが、何かが問題で、それがユーザーに影響を与えていることは分かる

データベースサーバーのCPU使用率が急上昇しても、ユーザーが影響を受けていないなら、それは本当に問題か？

→ レスポンス遅延のアラートとDB CPUのアラートが同時に出ると、関連性(がありそう？なこと) がわかるところはいいな

必要なだけ深く広く対象を増やしつつも、「このメトリクスはユーザーへの影響をどう教えてくれるだろうか」と常に自問自答して下さい。

2.3 デザインパターン3: 作るのではなく買う

「ツール依存」アンチパターンへのアンサー

5年間は悩む必要はなく SaaS を監視に使うべき

ツールがニーズに合わなくなり、システムがツールを超えて成長したら、自社の監視プラットフォーム構築に進む

2.3.1 安いから

構築メンバーのコスト、逸失利益、機会損失、ドキュメント作成、社内ツールのための教育、運用コストを考えると、買った方が安い

多くの会社では素晴らしいSaaSの監視ソリューションを使うのに、年＄6,000〜$9,000 かけている

→ 1ドル150円換算だと、900,000円〜1,350,000円。月額だと、75,000円〜112,500円。

2.3.2 あなたは (おそらく) 監視ツールを設計する専門家ではないから

SaaSソリューションを使うと、特定の問題領域に特化した専門知識を、自分でやるよりもずっと安く手にいれることができる

2.3.3 SaaS を使うとプロダクトにフォーカルできるから

SaaS を使えば数分で動く仕組みが手に入り、始めたタイミングからドキュメントなども手に入る

2.3.4 実際のところ SaaS のほうがよいから

ログに何を入れて送るかを文書化し、SaaS サービスに機密情報を送らないようにする

SaaS を使えているうちは、まだ SaaS でこと足りている可能性が高い

2.4 デザインパターン4: 継続的改善

「世界レベルの仕組みは1週間でできるものではなく、数ヶ月あるいは数年間にわたる継続した注意深さと改善から生まれるものです。あなたはこの長い道のりの途中にいるのです。」

2.5 まとめ

常に改善し続けましょう

→ アジャイルだ！