良書と言われる「OREILLY『入門 監視』」をまとめた

はじめに

2021年末から、プロジェクトで私が開発しているサービスが、
ベータ版としてエンドユーザーに利用され始めるようになった。

まだユーザー数も利用頻度もボチボチではあるが、このタイミングで、

「ユーザーのアプリ利用は正常に動作しているか？」あるいは、
「そもそも、ユーザーはどの頻度・時間でサービスを使っているのか？」

といったことを検知・検出するための運用監視が必要なフェーズになっている。

将来的にサービスがスケールする前に、
運用監視のファーストアクションとして、CloudWatchダッシュボードを利用したサービス利用状況の可視化・監視を行う。

運用監視を学習するためのファーストアプローチ

恥ずかしながら、「運用監視…ナニソレオイシイノ？」状態の私であった。。。
そのため、上司にまずはこの書籍を勉強することを勧められた。

www.oreilly.co.jp

かなり良書かつ、ややとっかかりにくいとのことなので、
以下２点に注力して、書籍をまとめる。

・運用監視をやる上で外せない必須部分
・プロジェクトで利用できる実用的な部分

「入門 監視」まとめ

読んでみた結論

• 監視にも定石があるので、それに沿ってやること。
  ・定石はツール利用による監視であり、簡便にツールで済ませるのがGood。
  　（※とはいっても開発が必要な場面はある）
• 見えたいものが見えるグラフ、知りたいことを通知してくれるアラートを正しく設定すること。
  ・閾値や統計の設定は、何をどの頻度でみたいかが重要。
  ・「ダッシュボード作りました！」
  　　⇒「で、何がわかるの？どう見たらいいの？」にならないことが重要。
• 監視対象のサービスに対して、ビジネス、フロントエンド、アプリケーション、サーバー、ネットワークのどの面から監視するか、多角的に設計すること。
  ・サービス全体を見ることで、総合的にサービスを監視できる。
  　⇒薄くみる。かつ、重要な点は厚くする。

主に読んだページ

• 各章の導入＆まとめ

「監視の原則（第Ⅰ部）」

1. 1. アンチパターン/デザインパターン

      監視をシステムに導入する上でまず重要なことは、”定石”、つまりアンチパターンとデザインパターンを知っていることである。
      （開発然り、定石通りにやらないことで、汎用性が失われて継承や共通化の障壁になる。）

      ■アンチパターン
      ・監視が運用における”杖”にならない
      ・ツール依存
      ■デザインパターン
      ・マイクロサービス的に組み合わせ可能
      ・目的由来に構成される（ユーザー視点や顧客視点など）
      ・継続的に改善できる（後から手が入れられる）
      
      

   2. アラート、オンコール、インシデント管理
      以下を見直しながら、運用監視はやっていく。
      ・通知方法は適切か？
      ・アラート検知した場合の手順は明確か？手順書化されているか？
      ・検出の方法、閾値の設定は適切か？
      ・オンコールの体制は適切か？（特定のメンバーに負荷は大きくないか）
      
      
   3. 統計
      アクセス頻度などに応じて、適切なインターバルでメトリクス表示する。
      （日単位での平均値や合計値で、本当にみたい現状は監視できるか？）

「監視戦略（第Ⅱ部）」

1. フロントエンド監視
   ・監視対象のトラッカーによって、２種類の監視方法がある。
   　①ホワイトボックス監視
   　②ブラックボックス監視
   ・特にロード時間を見る。
   　⇒読み込みに時間がかかると、顧客の満足度やアクセス数は大きく下がる。
   ・SaaSで監視するのがベスト。ググればOK。
   
   
2. アプリケーション監視
   ・３層アーキテクチャの中間
   （プレゼンテーション-アプリケーション-DB）
   ・StatusCodeでアプリの正常動作が行われているかを監視する。
   　（healthエンドポイントパターン）
   
   
3. その他、PJでは使わないが重要な監視
   1. ビジネスの監視
      ・顧客がやりたいことを実現するのが目的ならば、
      　顧客をターゲットにするのが筋。
      　Ex.)月次収益、コスト、顧客獲得単価、など
      ・ユーザー個別にフォーカスしてはいけない。
      　（ユーザー01がMax、みたいな明示的な情報を載せてはいけない。）
      　あくまでも、最大/最小や、上位帯/下位帯などで、傾向を見る。
      
      
   2. サーバーの監視
      ・CPU、メモリ、ディスクなどの使用率をトレースするのが定石。
   3. ネットワークの監視

終わりに　

サービスの現状を踏まえると、アプリケーション監視、プラスでビジネス監視が使えそうと感じた。

アプリケーション監視については、サービスを担っているのがAWSであることからCloudWatchダッシュボードでのデータ投入状況（投入はどのくらい行われているか、成功/失敗しているのか）をターゲットとする。
（後続の加工処理をどこまで監視するかは、工数を見ながらの相談になりそう。）

一方でビジネス監視は、より細かく投入データにフォーカスして、どのユーザーが投入しているかを解析することで、「誰が太客になり得るか」ということをサービス管理者に伝えることができて効果的になる。
⇒直接的な要望ではないけれど、

その他メモ書き

• 監視は役割ではなく、スキル
  ⇒システムの目的を知らずして監視はできない。つまり監視は、「動いているか」を知るための、開発に必要なスキルの一つである。
• 監視は、あるシステムやそのコンポーネントの振る舞いや出力を観察して、
  "継続して"チェックすること。
  ⇒１回アラートをキャッチできればOK、という訳ではない