入門 監視 ―モダンなモニタリングのためのデザインパターン
- オライリージャパン (2019年1月17日発売)
本棚登録 : 714人
感想 : 51件
- Amazon.co.jp ・本 (228ページ)
- / ISBN・EAN: 9784873118642
作品紹介・あらすじ
今求められる「モダンなモニタリング」を解説 !
なぜモニタリングをする必要があるのか、どこから、どのように始めたらよいのかを起点に各テーマに沿って書かれているため、モニタリングについての深い知識を身につけることができます。
感想・レビュー・書評
-
長らく積読してしまっていたが、同僚の勧めを受けて読了。
監視に対する基本的な考え方から始まり、
典型的なサービスで必要となる各レイヤーの監視を解説したのち、
フィクションのサービスに対する監視アセスメントを実行するという流れで、
とても頭に入ってきやすかった。
基本的にwebサービスを対象に書かれているが、
考え方は組み込みにも応用していけそう。
以下、読書メモ。
https://github.com/takeoverjp/booklog/blob/main/practical_monitoring.md
1
詳細をみるコメント0件をすべて表示 -
１章 監視のアンチパターン
1.ツール依存
2.役割としての監視
会社が成長するにつれて、チームメンバーは特定の役割を受け持つのが普通になってきます。私は各人が専門化した役割を持っている巨大企業で働いたことがありますが、そこではログ収集の専門家、Solarisサーバ管理の専門家、さらには他の人のために監視の仕組みを作って管理する人すらいました。3人のうちの1人が私です。
一見するとこの仕組みは効率が良さそうです。皆が万能選手になって、まあまあのレベルであらゆることをやるよりも、専門化したロールを作ることでメンバーが役割に完璧に集中できるのですから。しかし、監視となると問題があります。理解もできないものを監視する仕組みなんて作れるでしょうか?それは難しいでしょう。
つまり、このやり方はアンチパターンです。監視とは役割ではなくスキルであり、「チーム内の全員がある程度のレベルに至っておくべきです。構成管理ツール、あるいはデータベースサーバの管理方法に詳しいのは1人だけという状況にはしないのに、監視となると1人でもよいと思ってしまうのはなぜでしょうか。監視は他の仕組みから孤立した仕組みではなく、サービスのパフォーマンスのために重要なのです。監視の旅へ進むに当たって、皆が監視について責任を持つことを主張して下さい。
3.チェックボックス監視
「これを監視してます」というための監視システムのこと。
このアンチパターンに陥ってしまっているかどうかを知るにはどうしたらよいで しょうか。以下のような兆候が考えられます。
●システム負荷、CPU使用率、メモリ使用率などのメトリクスは記録しているが、システムがダウンしたことの理由はわからない。
● 誤検知が多すぎるのでアラートを常に無視する。
● 各メトリクスを5分あるいはそれより長い間隔で監視している。
●メトリクスの履歴を保存していない (Nagios、お前のことだ)。
4.監視を支えにする
5.手動設定
・クラウド環境と従来型環境の監視
クラウドベースのアーキテクチャを監視するのは、従来型(静的ともいいます)のアーキテクチャを監視するのと比べて、ある大きな点で違います。それは、個別のなにかを監視するのではなく、何かの集合全体を監視することです。1つや2つのシステムを監視するのではなく、複数のシステムのまとまりを監視します。したがって、クラウドネイティブなアーキテクチャの監視をうまくやるには、自動化が必須になります。
■まとめ
この章では、監視でよくある5つのアンチパターンについて学びました。
●ツールに依存しても、監視の仕組みはよくなりません。
●監視は全員がやるべき仕事であり、チームや部署内での役割ではありません。
●素晴らしい監視とは、チェックボックスに「これは監視してます」とチェックを入れるだけで済むものではありません。
●監視するだけでは壊れたものは直せません。
●自動化が足りていないということは、何か重要なことを見落としている可能 性を知るよい方法です。
これで注意すべき監視のアンチパターンとその修正方法が分かったので、よい監視の習慣を付けられるでしょう。この5つの問題を解決しただけでも、よい状態になったはずです。もちろん完璧を目指す人は、この程度で満足しません。そのためにはアンチパターンの逆、デザインパターンについて見ていきましょう。
２章 監視のデザインパターン
■監視サービスのコンポーネント
・データ収集
・データストレージ
・可視化
・分析とレポート
・アラート
■まとめ
この章では、4つの主なデザインパターンを取り上げました。
●組み合わせ可能な監視の仕組みは、モノリシックな仕組みよりも効果的です。
●ユーザ視点優先での監視によって、より効果的な可視化ができます。
●監視の仕組みは、可能な限り自分で作るのではなく買うことを選びましょう。
●常に改善し続けましょう。
これは完璧なリストではありませんが、この4つを適用すれば、ほとんどの会社の仕組みより素晴らしい監視プラットフォームを作れるでしょう。
ここまででこれらのパターンが使えるようになりました。次は、失敗しやすく、理解が難しく、監視についての辛さの大半を占めるであろうアラートのデザインについて取り上げましょう。
３章 アラート、オンコール、インシデント管理
この章では、アラート、オンコール、インシデント管理に関するさまざまな情報を扱ってきました。
●アラートは難しいけれど、いくつかのヒントを活用することで正しい方向に進めます。
●アラートをメールで送らないようにしよう。
●手順書を書こう。
●すべてのアラートがシンプルな閾値で決められるわけではない。
●常にアラートを見直そう。
●メンテナンス期間を使おう。
●誰かにアラートを送る前に自動復旧を試そう。
●いくつかの方法を使えばオンコールの仕組みを改善するのは難しくありません。
●自社にあったシンプルで使い道のあるインシデント管理プロセスを作るのを優先しよう。
これでアラートとオンコールをやっつけました。それでは次は、好きではない授業の第1位、統計の話に移りましょう。
４章 統計入門
この章では、統計の世界のほんの表面をなぞったに過ぎませんが、運用とエンジニアリングに対して最も一般的でインパクトの大きいアプローチに焦点を当てて説明したつもりです。まとめると以下のようになります。
●平均は、多くの種類のデータセットに広く適用できることから、最も広く使われ便利な関数です。中央値もデータセットによってはかなり便利です。
●周期性は、時系列のデータのパターンについて表現するうまい方法です。トラフィックのログを見れば、周期性を見つけられるはずです。
●パーセンタイルはデータの大部分がどうなっているかを理解するのに便利です。ただし、本来この方法は極端なデータを無視するものであることに注意して下さい。
●標準偏差は便利なツールですが、この先、扱うであろうデータには適用できないことが多いでしょう。
データについて考える時に考慮すべきいくつかの質問を挙げておきます。
●どちらか一方に大きな偏りがあるデータだろうか? つまり、データポイン トの集まりはグラフのどちらかの端にあるだろうか?
●極端な外れ値はよく発生するだろうか?
●データポイントには上限あるいは下限があるだろうか? 例えば、レイテンシの計測値は理論上正の方向には無限に値を取り得る。しかし、CPU使用 率のパーセンテージは上限も下限もある (0%と100%)。
データに関してこれらの質問をすることで、どんな統計的手法がうまく適用でき、 どれが適用できないか理解するきっかけになります。
これでこの本の第I部の終わりにたどり着きました。第II部では、「何を監視すべ きか、どのように監視すべきか」の核心に入っていきます。
５章 ビジネスを監視する
■まとめ
ここまで、多くの人はなかなか直面しないであろう会社のビジネス面の重要性について学びました。これらの情報は、ビジネスを運営し成長するため、そして私たちが仕事をしていくために非常に重要です。まとめると以下のようになります。
●ビジネスKPIは、非常に重要なメトリクスであり、アプリケーションやイン・フラの調子やパフォーマンスを示す先行指標です。
●会社の中でこれらのメトリクスを特定し、追跡する方法を学びました。
●ビジネスメトリクスを技術指標に結び付ける方法を学びました。
次の章では、進化し続けるフロントエンドパフォーマンス監視について学んでいきます。
６章 フロントエンド監視
Aberdeen Research の2010年の研究(http://bit.ly/2y66G1p)によると、ページロード時間が1秒遅くなると、平均でページビューが11%、コンバージョンが7%、顧客満足度が16%下がると言われています。Aberdeenは、最適なページロード時間は2秒以下で、5.1秒を超えるとビジネスに影響が出始めるとしています。ShopzillaとAmazonも同じような発見をしています。Shopzillaのページロード時が6秒から1.2秒に短くなった(https://www.youtube.com/watch?v=Y5n2WtCXz48)間とで、売上げが12%増え、ページビューも25%増えたとしています。またAmazonは、ロード時間が100ms改善するごとに売上げが1%増えることを突き止めました(http://bit.ly/2y494hq)。
より最近の例では、Pinterestが2017年3月にフロントエンドパフォーマンスに関するプロジェクト(http://bit.ly/2iyxUio)を始め、体感の待ち時間を40%短縮したことでSEOトラフィックが15%増え、新規登録も15%増えたという驚くべき結果を出しています。「トラフィックとコンバージョン率が倍々に増えていくことから、これはWebとアプリケーションの新規登録の点で私たちにとって大きな成功でした」とブログ記事の筆者は書いています。これは、フロントエンドにおけるパフォーマンスチューニングのインパクトに対する、なかなかの推薦の言葉と言えます。
■ページロード時間はどのくらいであるべきか
4秒以下を目指しましょう。到達するのはきつい数字ですが、間違いな<実現可能です。無理ですって?Amazon.comは、2017年のAmazon Prime Day 期間中のロード時間をおよそ2.4秒に保った(http://bit.ly/2i3u7Wn)そうです。これは私たちの誰も経験したことのないであろうトラフィックですが、それでも彼らはやり遂げたのです。
■まとめ
ここまで学んだように、フロントエンドの監視は見落とされることが多い一方で、単に監視ができるというだけでなく、その実現も比較的簡単です。あらゆる監視と同じように、永遠に続くかのような興味深い分野ですが、その基礎はシンプルです。
●実際のユーザが見ているページのロード時間を監視しましょう。
●JavaScriptの例外を監視しましょう。
●ページのロード時間をCIシステムから計測し続け、ロード時間が許容時間内に収まるようにしましょう。
アプリケーションのフロントエンドは、バックエンドと密接に関係しています。バックエンドのパフォーマンスは、フロントエンドの問題として現れます(例えば、ボタンをクリックした時の遅い反応など)。これを解決するために、次はアプリケーションのバックエンド(つまりコードのこと)の計測に話を移しましょう。
７章 アプリケーション監視
アプリケーション監視についてこの章で学んだことをまとめてみましょう。
●メトリクスとログでアプリケーションを計測するのは、アプリケーションのパフォーマンスを把握し、トラブルシューティングする能力を高めるためにできる最も重要なことです。
●アプリケーションやインフラのリリースやパフォーマンスに関係することを追跡しましょう。
●役立つアーキテクチャが限られているとは言え、/healthエンドポイントバターンはなかなかよい方法です。
●相当大規模にデプロイしているのでない限り、サーバレスあるいはマイクロサービスの監視は、他のアプリケーションと大きく違いはありません。分散トレーシングを始めるには、時間と労力をかけなければならないでしょう。
アプリケーションのコードは当然ながらどこかのサーバ上で動作し、それらサーバのパフォーマンスはアプリケーションのパフォーマンスに大きな影響を与えます。次はサーバインフラを監視する理由を見ていきましょう。
８章 サーバ監視
■まとめ
なんという章でしょう。本章では以下のトピックをすべて扱いました。
●標準的なOSメトリクスはアラートを送るのには適さないことがある理由と、それらの効果的な使い方。
●Webサーバ、データベースサーバ、ロードバランサなどといった、よく使うサービスの監視方法。
●サーバの観点からのロギング。
サーバは、依存するネットワーク以上の信頼性を持つことはできません。次は、変わり者のSNMPとネットワーク監視の世界へ飛び込んでいきましょう。
９章 ネットワーク監視
■まとめ
ネットワークの監視ははるかに複雑で、多くの人が考えているよりさらに複雑に絡み合った仕組みであり、大規模では特にその傾向があります。この章で学んだことを振り返ってみましょう。
●SNMPは古めかしい悩みの種ですが、使えるのはこれだけです。ベンダを呼ぴつけて、もっとましな監視と管理のインタフェイスがないのかと不満を表明しておきましょう。
●設定変更を追跡することで、たくさんの情報が得られ、作業時間も頭痛の種も減らせます。
●インタフェイス、ルーティングプロトコル、スイッチ、シャーシのコンボーネントを監視する難しさを学びました。
●音声や映像ストリーミングのパフォーマンス監視、QoS、IPSLAについて学びました。
●NetFlow.、J-Flow、sFlow、IPFIXを使ってフロー全体を監視することで、ネットワーク内で何が起きているかに対する深い理解が得られます。
●ネットワークエンジニアリングにおけるキャパシティプランニングの基礎を学びました。
これで技術的なスタックの最後に到達したので、次の章ではスタック全体のセキュリティ監視について議論するという俯瞰的な内容に戻りましょう。
10章 セキュリティ監視
セキュリティ監視の広い範囲に全部触れたとはとても言えませんが、アプリケーションやインフラのセキュリティ監視を手早く始められることを教えられたという自信はあります。まとめると以下のようになります。
●コンプライアンス目的の監視の要求事項は、見た目よりも単純なことも多くあります。ただし、常に簡単という意味ではありません。
●auditdを使ったユーザ、コマンド、ファイルシステムの監査は、始めるのは簡単ですが、役立つ状態にもって行くまでの調整が非常に大変です。
●ルートキットやその他のホストレベルの侵入を検知するのは難しい場合がありますが、rkhunterから始めるのがよいでしょう。
●ネットワークセキュリティにはファイアウォールは十分ではありません。ネットワークタップを注意深く配置し、NIDSを使うことで、たくさんの情報を取得できます。
この章で、あなたの環境のあちこちを監視する詳しい方法を探る旅は終わりになります。最後のまとめとして、私の大好きなサイトTater.lyの監視アセスメントを実施してみましょう。
1
-
入門とあるが、ソフトウェアを運用していくにあたって一度は読んでおくことを推奨する内容だった。特に昔ながらの監視をしているチームはメンバー全員が理解した方がいい。
0
-
昔、図書館で借りて読み、あらためて手元に持っておこうとオライリーのサイトで電子版を購入。
なぜ監視するのか、どのようなレイヤーがあるのか、監視できるようにしておくためには等々、ときどき開いて読み直したい一冊。
0
-
読む前はわからないことだらけだったけど、さすが入門、少しは理解できた気がする。
ここも開発同様、銀の弾丸はないということ。
コラム的なもので「SLAは願望や嘘」「ツールは作るより買う」「アラートにメールを使うな」など、へぇーと思いつつ。
111冊目読了。
0
-
装置やアプリケーション等様々なものを「監視」することに重きをおいた本。ありそうで意外と少ないジャンルと思う。インフラエンジニアやサーバーエンジニアは数多いるので、この本が活躍する場面は多いと思われる。
原題は「Practical Monitoring - Effective Strategies for the Real World」だが、日本語タイトルに「入門」を冠したのはお見事と思う。
この本もオライリーにしては薄くて読みやすいが、"さわりの部分"が記述されているに過ぎないので、まさに入門書。
文体はいかにもアメリカナイズな感じを受けるが、上手く訳されているので、問題ないと感じた。あとは、どこまでこの本の内容と実務だったり読者が求めている部分がマッチするかだろう。
0
-
よくわからず取れるメトリクスを眺めている自分のようなアプリケーションエンジニアにとっては、よい指針となってくれそうな本だった。
ネットワーク監視や分散トレーシング、ログの粒度などの細かいノウハウは別の本が良さそう。
0
-
「監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。」（viiページ)
要するに、パフォーマンスのチェックや異常のチェックのこと。
２００ページほどの薄い本。
おそらく、監視業務に携わる人にとってはすばらしい有益な本なのだろうけど、私の理解不足のため正当に評価はできない（現時点での主観的な面白さという意味で星３つにしておく）。
またあとで機会があれば再読したい。
0
