はじめに
こんにちは、Stackdriver担当者です。年明けに「入門 監視」を恵贈頂いたのですが、書評を公開するのが遅くなってしまいました。すでに多くの方が書評を公開していらっしゃいますが、そちらは気にせず自分の書評をメモ代わりに書いておこうと思います。
TL;DR
- 本書を読んでも即座に監視に関する問題が解決するわけではないが、システム監視について何から始めれば良いかわからない人はまず手にとるべき本であると思う。
- 本書とSRE bookを読むことで同じ内容を異なる角度から捉える事ができ、非常に有益。
感想
全体として
- 1章 監視のアンチパターン
- 2章 監視のデザインパターン
- 3章 アラート、オンコール、インシデント管理
- 4章 統計入門
- 5章 ビジネスを監視する
- 6章 フロントエンド監視
- 7章 アプリケーション監視
- 8章 サーバ監視
- 9章 ネットワーク監視
- 10章 セキュリティ監視
- 11章 監視アセスメントの実行
- 付録A 手順書の例：Demo.App
- 付録B 可用性表
- 付録C 実践.監視SaaS
本書の目次を見て分かるとおり、前半で監視の設計手法や取り組み方に関してから始まり、後半でシステム内の各構成部品に対する監視の概要を見ていくという内容でした。よって、本書一冊ですべてが解決するという辞書のような使い方ではなく、本書で大まかに監視全体を把握するのに向いていると思いました。
特に今2019年現在において「監視」というのがどのような取り組み・行為なのかを解説した本として充実していました。現代での「監視」のスナップショットの確認として、さらっと一度流し読みするだけでも価値があると感じます。
システムアーキテクチャ・開発手法の変化による監視手法の変化
本書で最も特徴的であり、自分が大きく賛同した部分は、本書が「システムアーキテクチャや開発手法が変化したことにより、監視手法も変化してきている」という点を様々な角度から論じていた点です。
各章で語られていたことを簡単に抜粋してみます。
1.2 アンチパターン 2: 役割としての監視
監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきです。（中略）監視の旅へ進むに当たって、皆が監視について責任を持つことを主張してください。
2.1 デザインパターン 2: ユーザ視点での監視
まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをするところです。
3.2.3 上手にオンコールローテーションを組む
ソフトウェアエンジニアもオンコールのローテーションに入れることを強くおすすめします。
5.4自分のアプリケーションにそんなメトリクスはないという時は
必要な計測データをアプリケーションが出してくれないなら、自分でアプリケーションを変更してしまいましょう。
6 フロントエンド監視
そして、時と共にパフォーマンスが悪くなってしまわないように、既存のツールにフロントエンド監視をどのように組み込んでいくのかを考え、この章の仕上げとします。
7 アプリケーション監視
アプリケーションのメトリクスはいろいろなことにとても便利に使えるので、なぜすぐ始めなかったのか不思議に思うくらいでしょう。
7.6 マイクロサービスアーキテクチャを監視する
マイクロサービスがあらゆるものを飲み込みつつあるこの世界では、優れた監視の仕組みを持つことは絶対条件になっています。
ざっくりと抜粋しているので、上記の引用だけでは読み取りづらい部分があると思いますが、私はこれらはすべてDevOps、さらにはSRE的なアプローチによって、アプリケーションとインフラを区別して捉えるのではなく、システム全体として期待されるとおりに稼働しているかを捉えることが重視されるようになったことが影響していると考えています。
またクラウド上でシステムを動作させることが増え、アプリケーションのモジュール化も進み、それに関わるインスタンスの台数も需要に応じて柔軟に増減するようになってきていることで、インスタンス自体のメトリクスよりも、アプリケーションに係るメトリクスが与える影響が大きくなっていることも関係があります。
これらによって、監視そのものが「インフラチームがアプリケーションランタイムの安定性を見る」という性質から「システム全体として期待した動作を行っているかの確認をする」という性質に大きく変化しています。当然その変化の中で、アプリケーションエンジニアが監視や運用に参加することの必要性も高まってきています。
そうした運用手法としてDevOpsを推し進めたものの一つがSite Reliablity Engineering (SRE) だと思いますし、そのような監視をどのように行うかというのを一貫して紹介したのが本書だと感じました。
また使用するランタイムの性能が向上していることもこれらを支える一助となっているでしょう。「1.1.1 監視とは複雑な問題をひとくくりにしたもの」の節のコラム「観察者効果は気にしない」には次のようにあります。
観察者効果とは（中略）技術分野では、監視ツールがシステムに負荷を加えてしまうことを指すことが多いですが、これは大した問題ではありません。今は2017年で、1999年ではありません。
Application Performance Management (APM) においては、トレース情報やプロファイル情報をサンプリングして取得する手法が主になっています。これらが許容されるようになったのはサンプリングを行ってもアプリケーションに与える影響が問題ないくらいマシンのCPUやメモリ、あるいはネットワークなどの性能が高まったからでしょう。
乱暴に言えば、クラウドではアプリケーションランタイムとしてのインスタンスは即座に上位性能のものに入れ替えられる一方でアプリケーション自体は、その開発フェーズが進めば進むほど、即座の置き換えが難しくなります。そうしたこともAPMなどといったアプリケーション側の監視の比重が高まってきている要因でしょう。
本書では「6章 フロントエンド監視」「7章 アプリケーション監視」と2章を割いて、アプリケーション側の監視の考え方を紹介していて、そういったものを導入しようとしている人向けに良い入門になっていると感じました。
SRE bookと重なる部分
上のような理由から、同じオライリーで発刊されている「SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム」（SRE book）の内容と重なる部分や、SRE bookでより詳細に説明されている内容なども見受けられました。いくつか抜粋します。
2.1.1 監視サービスのコンポーネント
ペナルティ事項の存在しないSLAは、むしろ「目指すべき目標」と一般的には捉えられます。
この用語を区別するためにSREではSLI、SLO、SLAとサービスにおける指標、目標、契約を呼び分けています。
1.5 アンチパターン 5: 手動設定
もし手順書が単なるやることの羅列なら、さらなる自動化が必要です。
3.1.6 まずは自動復旧を試そう
アラートに対する代表的なアクションが、既知でかつ用意されたドキュメントの手順に沿って対応するだけなら、コンピュータにその手順をやらせない理由はありません。
これはまさにトイルの撲滅そのものです。
3.4 振り返り
振り返りには良くない習慣があることに私は気づきました。それは誰かを非難するという文化です。
これに関してはSRE bookにある「非難のないポストモーテム (Blameless Postmortem)」にも詳細に書かれています。
監視とは、システムを見守るという行為なので、システムの信頼性を担保する役割であるところのSREチームには大きく関係するところであり、こうした内容が重なるのは当然でしょう。
しかしとはいえSRE bookはかなりの重量級（B5版 590ページ）です。ましてこれからそうしたことに取り組もうと思っている方は、読もうと思っても、その重量に圧倒されかねません。その点入門監視はA5版 200ページとあっさり読める内容です。深堀りはしていなくても、監視の全様を大まかに把握するにはうってつけです。本書を読んでから、あらためてSRE bookを読んでみるというのも手だと感じました。
付録C 実践 監視SaaS
私が本書が翻訳版として価値があると感じたのは、もちろん「付録 C 実践 監視SaaS」です。こちらは監視SaaSであるMackerelの @Songmu さんが書き下ろしとあって、監視SaaSの利点、信頼性、選定ポイント、利用方法について、本文でぼかされていた部分を一歩踏み込んで解説し、即座に実践に活かせる内容となっています。
私も冒頭で述べているようにGoogle Cloud Platformの Stackdriver という監視SaaSの担当をしているのでうなずくことばかりです。
Stackdriverにはロギング、分散トレース、プロファイラ、モニタリングダッシュボード、エラーレポート、デバッガといった製品群があります。
本書で触れられていた内容に関しては一通りカバーしている製品群で、特に特徴としてはまさに本書のような現代的な監視手法を導入しやすくしている点（例: ログベースメトリクスの作成、OpenCensus を利用したアプリケーションメトリクスの取得、分散トレース、フレームグラフが見えるプロファイラなど）です。
これも主にGCP上でシステムを動かす開発者・運用者が、即座にSRE的な監視を行える機能を提供するという目的があって開発されているためです。（たとえばGoogle App Engine Standardでは分散トレースやログベースメトリクスなどはインストゥルメンテーション無しで即座に行えるようになっています）
クラウドプラットフォーム事業者が監視SaaSを提供する利点は、一番下のレイヤーまでできるだけ多くの情報を提供でき、他のサービスとの連携も図りやすい点にあります。（先程のGAEの例をはじめ、GKEでもアプリケーション側のインストゥルメンテーションのみでロギングや分散トレースやプロファイラとの連携可能です）
この付録Cを通じて、監視SaaSを導入する企業が増え、Stackdriverにもより多くのフィードバックが来ることを期待しています。GCPUG Slack の #stackdriver チャンネルにいますので、利用してみて疑問に感じたことがあればぜひ来てください！
gcpug.jp
参照
