目次

はじめに

本書の目的
対象読者
本書で得られること
サンプルコード
免責事項

第1章 監視の設計

1.1 なぜ監視をするのか
1.2 監視設計の考え方
1.3 監視に必要な処理

第2章 SLI/SLO

2.1 SLI/SLOとは
2.2 なぜSLOを定めるのか
2.3 SLI/SLOの決め方

第3章 AWSにおける監視設計

3.1 AWSにおける監視設計の方針
3.2 CloudWatchの進化
3.3 AWSにおけるメトリクスの収集
3.4 CloudWatchの機能
3.5 インスタンス・コンテナ監視
3.6 アプリケーションパフォーマンス監視
3.7 ログ監視
3.8 外形監視

第4章 監視対象の多様化

4.1 CI/CDの監視
4.2 IoTデバイス向けサービスの監視(Not “AWS IoT”)

第5章 ダッシュボード

5.1 ダッシュボードの設計
5.2 ダッシュボードツール

第6章 AWS上のサーバーレスアプリケーションの監視

6.1 サンプルアプリケーションについて
6.2 サンプルアプリケーションの構成
6.3 SLI/SLOの定義
6.4 メトリクスの収集

付録A CloudWatch Syntheticsを使ったFrontendの監視

A.1 サンプルアプリケーション
A.2 Canary Script
A.3 Canary Scriptを使用して監視する項目
A.4 Canary Scriptの生成
A.5 Canaryの作成
A.6 Syntheticsが計測したメトリクスの取得

はじめに

本書の目的

 この本を手に取っていただき、ありがとうございます。本書では「モニタリング(監視)」というテーマのもと、主に監視の設計手法を紹介します。

 2020年になり、2010年代が終わりました。2010年代はクラウドやコンテナの発展とともに、「モニタリング(監視)」の形も大きく変わったと思います。この本では、どのように監視を設計していくかを、CloudWatchを中心にAWSの各サービスを見ながら、著者の経験をもとに説明していきます。

 私自身、ここ数年で開発メンバー、リーダー、テックリードと、いくつかの立場を経験しました。どの立場にいても、システム開発に携わる以上、監視というのは重要な要素になってきます。特にここ数年はSLI/SLOを導入するなど、監視について考える機会が多くありました。そこで、この経験をアウトプットしてみたいと思い、この本を執筆しました。

 「監視設計」という部分は、システム開発の最初から携わっていれば経験します。ですが、運用から参加するような場合は既にできあがっていて、既存の仕組みをあまり考えずに使うことが多いです。そのため、いざ設計するタイミングになると、どこから手を付けていいかわからない、という状態に陥ります。そんなときに、この本が役に立てば幸いです。

対象読者

 ・監視設計の経験がない人

 ・AWSの監視サービスをひととおり知りたい人

 ・他のエンジニアがどのように監視を考えているか、興味がある人

 ・もう一度監視について考えるきっかけが欲しい人

本書で得られること

 ・監視設計のノウハウとやり方

 ・AWSの監視サービスの知識

 ・SLI/SLOの考え方

サンプルコード

 本書で使用しているサンプルコードは以下で公開しています

 https://github.com/tenbo07/monitoring-design-book-samples

免責事項

 本書の内容は個人の見解であり、所属する会社・組織の見解ではありません。また、本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

第1章 監視の設計

 まず初めに、監視設計の考え方から全体の流れ、そして各フェーズでのポイントを紹介します。

1.1 なぜ監視をするのか

 監視をする理由を問われることはあまりないと思います。なんとなく必要なものとして、そこにあるからやっている人も多いのではないでしょうか。私も新卒でSIerに入社し、初めの頃は何の意味もわからず、アラートメールが流れるのを眺めていました。監視について真面目に考えるようになったのは、夜間に叩き起こされるようになってからです。

 アラートを設定するのは簡単で、監視ツールの使い方さえ知っていれば、1分もかからず設定できます。しかし、そのアラートによって安眠が妨げられる以上、迂闊なアラート設定は命取りになります。もう、監視なぞしなければいいのでは?と何度も思いました。監視をしなければ夜間に起きる必要もなく、日中も自分が本当にしたい作業に集中できます。ここで、監視を行わない運用を考えてみます。開発が終わり、サービスをリリースします。リリースしたら、そのサービスがどれだけ使われたか気になります。しかし、監視は行っていないので、我々は何もわかりません。いきなりつまずきます。ここで私は、監視をする理由は「サービスの価値を確認するため」だと考えました。

 サービスの価値は、実際に使われることで発生します。そして、使われているかどうかは観測することでしかわかりません。この観測する行為こそ、普段我々が「監視」と呼んでいる業務になります。監視をする理由を問われた場合、私は「作り上げたサービスの価値がわからないから」と答えます。決して不安だから監視をするのではなく、エンジニアとしての成果を確認し、必要に応じて品質を高めるために監視を行います。監視を行うのは当たり前のことになっていて、その意味を考えることはあまりありません。しかし、意味を考えることで、本当に必要な監視は何なのか、軸を持つことができます。

試し読みはここまでです。
この続きは、製品版でお楽しみください。