監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring

1
Copyright © 2020 BeeX Inc. All Rights Reserved.
2020年3月19日
Takashi Nasu
監視やモニタリングについて
もうちょっとだけ考えてみよう
Ops JAWS Meetup#18 モニタリング

View Slide

2
那須です
那須隆（なすたかし）
株式会社BeeX（びーえっくす）
Japan APN Ambassador 2019（APN: AWS Partner Network）
Twitter: @nasrinjp1
https://nasrinjp1.hatenablog.com/
経歴
• 6年半：ネットワークエンジニア
• 7年半：SAPコンサルタント(システム運用)
• 4年：AWSメインのインフラエンジニア
今興味ある：API Gateway、セキュリティ周り

View Slide

3
BeeXです
何やってる会社？
• SAPをはじめとした基幹システムのクラウド移行
• クラウドネイティブ開発
• クラウド環境やSAPシステムの運用保守
お客様事例の一部です。
クラウドネイティブ開発でやっていることや、
SAPシステムのスピード移行の内容を
見ることができます。
詳しくは↓Webサイトでどうぞ！
https://www.beex-inc.com/

View Slide

4
今日皆様と考えたい内容
• 監視/モニタリングの目的って何ですか？
• 何を監視/モニタリングしますか？
• アラートの出し方について考えていますか？
• アラート受信した後はすぐに動けますか？

View Slide

5
このセッションのターゲット
• AWS（に限らずクラウドの）運用および保守している人
• AWS（に限らずクラウドの）運用設計している人
• 監視の設計で困ってる人
• 担当システムの障害対応フローを改善したい人

View Slide

6
注意事項
今日お話する内容は、あくまで私が考えた内容になります。
参加されている皆さまの所属組織や提供されているサービ
スごとに詳細は異なると思いますので、話を聞きながら自
分はこう思うなーと考えていただけると嬉しいです。

View Slide

7
監視/モニタリングの目的？（Why）

View Slide

8
ちょっとだけゴールデンサークルの話
Why
What
How
Why
What
How
サイモン・シネックさんが提唱した理論

View Slide

9
というわけで
WhyからHow/Whatについて考えて
みたい

View Slide

10
なぜ監視するのか？
監視した結果の通知がほしいわけじゃない（手段？）
• 正常ではないと判断した状態から1秒でも早く復旧したいだけ
• そのために復旧作業を自動化したい
• 自動化できなくても通知からすぐに復旧作業に取りかかれるよ
うにしたい

View Slide

11
目的（例）
1秒でも早く障害状態から正常状態もしくは
縮退運転状態にしてサービスに影響がない
状態にすること

View Slide

12
こっちが目的？
その結果得られるであろう「運用負荷を下げる」
が目的かも？

View Slide

13
他の目的の例
• EC2インスタンスで稼働するお客様向けサービスの無停止提供
• EC2の問題？アプリの問題？ネットワークの問題？
• CloudWatchやSaaSを使う
• セキュリティ事故を0件にする
• 悪意ある第三者からの攻撃をいち早く知る
• セキュリティ基準が遵守されているかどうかを見る
• GuardDutyやInspector等のセキュリティサービスや、セキュリティ
チェックができるSaaSを使う

View Slide

14
何を監視/モニタリングするの？

View Slide

15
監視/モニタリングってなってるけど…
監視とモニタリングって日本語では2つとも見かける
けど、意味は同じなのか異なるのか？

View Slide

16
そもそも監視とモニタリングって何が違うの？
監視
警戒して見張ること。また、その人。「監視の目が光る」「火山活動を監
視する」
不都合な事の起こらぬように警戒して人の動きなどを見張ること
モニタリング
状態を監視すること。
状態を把握するために，観測や測定を行うこと。製品・サービスについて
の感想や評価を調べること
三省堂大辞林第三版から引用

View Slide

17
そもそも監視とモニタリングって何が違うの？
モニタリング
監視
こんなイメージ？

View Slide

18
目的を思い出す

View Slide

19
URL等のエンドユーザがアクセスするポイント
そもそもサービスが使える状態にあるのかどうかを監視する
異常検知したら必ず通知する
通知を受信したら1秒でも早く復旧させるように自動化するか、人が動く
※ウェブサイトの死活監視はされている方も多いと思います

View Slide

20
パフォーマンス
使えるけどなんか遅いって状態を見逃さないよう監視する
何が原因でパフォーマンス低下しているのかを調査する。
最初に調査のために実行するコマンド等が決まっているのであれば、パ
フォーマンス異常検知と同時に自動で実行させてチャット等に通知する
パフォーマンス異常通知のコンテンツにCWダッシュボード等へのリンクがあ
ると嬉しい

View Slide

21
[参考]Synthetics Monitoring
まだプレビューですが簡単にSynthetics Monitoringを試せます。
ウェブサイトやAPIの可用性とレイテンシをチェックします

View Slide

22
[参考]あるようであまりない複数トリガーでのアラート
https://aws.amazon.com/jp/about-aws/whats-new/2020/03/amazon-cloudwatch-now-allows-you-to-combine-multiple-alarms/

View Slide

23
（他の目的のための監視/モニタリング例）
リソースモニタリング例
ユーザへの提供サービスは問題ないがCPUが100%になっている等
すぐに知るべき情報かどうかは提供サービスにもよるが、ほとんどの場合は
ダッシュボード等でいつでも見れるようにするもの
• 平常時の状況確認等につかうために記録する
• 近い未来に障害となり得る傾向を見つけるために記録する
• Amazon Forecastを使えば傾向が見えるようになるかもしれない

View Slide

24
（他の目的のための監視/モニタリング例）
セキュリティ標準の監視例
組織やサービスごとにセキュリティ標準は異なるが、違反に対しては修復
しないといけない
• Security HubでCIS Benchmarkの標準チェックから始める
• 設定等でセキュリティ違反を検知したらAWS Configで自動修復
• セキュリティ標準を守れば完璧！ではないので、GuardDutyでセキュ
リティリスクの発生に気づくようにする

View Slide

25
雑にアラート出してませんか？

View Slide

26
監視システムから送られてくる内容（昔はこうだった
いつ、○○で××が発生しました。
しきい値：100
検知した値：200

View Slide

27
何度も目的を思い出す

View Slide

28
…目的達成できますか？
さっきのアラートが自分のところに飛んできたとして、
1秒でも早く対応しないといけない。そんな状況で
このアラートだけが飛んできたら…
目的達成できますか？
もっと事前にできることないでしょうか？いつ、○○で××が発生しました。
しきい値：100
検知した値：200

View Slide

29
今ではアラート内容のカスタマイズができるのは当たり前
昔のアラートは状況を知らせるだけのものが多かった
今ではアラートの内容は自由にカスタマイズできるものがほとんど

View Slide

30
アラートの内容例
前職でDatadogを触っていたので、
思い出しながら雑にアラート発生させて
Slackに通知してみた例

View Slide

31
アラート内容として書く情報の例
発生日時や対象、障害内容以外にもこんな情報を付け加えてみては
どうでしょうか？
障害対応手順
運用ドキュメントへのリンク
復旧目標時間

View Slide

32
なぜ対応手順をアラートの中に書くのか？（1/2）
アラートの中に対応手順が書かれていれば、対応に必要なドキュメントを
探す時間も０にできる。
対応手順がものすごく長いなら、対応手順が書かれたドキュメントへのリ
ンクをアラートに書くだけでも手順実施までの時間が短くなる。
注意：ドキュメント更新等で場所が変わったら、アラートに書いているリン
クも更新する。

View Slide

33
なぜ対応手順をアラートの中に書くのか？（2/2）
対応手順をアラートの中に書くようにすれば、監視の設計をしている時に
それぞれの監視項目での一次対応を決めることになる。
もし一次対応が書けないなら、そもそもそれを監視する意味ってある
の？って考えるきっかけにもなる。
運用の負荷を下げるためにも、不要なアラートを飛ばすのはやめよう。

View Slide

34
なぜ目標復旧時間をアラートの中に書くのか？（1/2）
運用や保守の契約で目標復旧時間がある場合は、それを守る努力を
する必要がある。
障害発生からいつまでに復旧させる必要があるのかを書く。
目標復旧時間が書かれていれば、状況や保守担当のスキル等を基に
障害発生してから○分経過しても状況が変わってなければエスカレーショ
ンする、などのフローが作りやすくなる。

View Slide

35
なぜ目標復旧時間をアラートの中に書くのか？（2/2）
同時に複数のアラートが発生している時、急いで対応しないといけないも
のはどれか等、優先度を決めて対応の順序を決められる。
• サービスの継続提供
• 契約

View Slide

36
以上のような工夫をすることで、場合によっては復旧までの時間が大幅に
短縮されることもある。
アラートはただの通知ではない。
次に進むためのガイドにもなり得ると思う。

View Slide

37
アラート受信したらすぐ対応できますか？

View Slide

38
一次対応を実施するのは誰か？
アラートで一次対応手順を書けたので、障害検知後すぐに対応開始す
ることができる。
それは、絶対に人間がやらないといけないのか？
もし自動化できる余地があるなら自動化に挑戦しよう。

View Slide

39
自動化の例（1/2）
障害検知時のアクションの自動化はこんな感じ。
• 監視サービスからWebhook
• EventBridgeで特定のステータスを受信したらアクション実行
• Lambdaで復旧処理実行
• SSM Automationで復旧処理実行
• MonitみたいなツールでOSでの処理実行

View Slide

40
自動化の例（2/2）
セキュリティインシデント検知時は、Security Hub、Eventbridge、
Lambdaを組み合わせての自動修復の仕組みを作る。

View Slide

41
https://aws.amazon.com/jp/blogs/news/automated-response-and-remediation-with-aws-security-hub/

View Slide

42
自動実行した結果をアラートに続けて通知する

View Slide

43
自動化は二次障害を防ぐためでもある
調査や復旧作業を自動化すれば、かなり時間短縮になる。
人間のオペレーションによるオペミスの発生確率も下げることもできる。
オペミスによる二次障害を起こさないためにも自動化に取り組む。

View Slide

44
どこまで自動化したものを信用するか？
でも自動化したものが必ず想定した動きをするとは限りらない。
アラートにはどんな場合でも人間が実施できるように対応手順は書くよう
にすべき。

View Slide

45
目的を達成するために監視について考えたい

View Slide

46
今まで話した内容で正解かどうかはわからない
過去のネットワークの運用・保守や、SAPシステムの運用設計の経験を
踏まえて考えた結果が今日お話した内容です。
環境やシステムが変われば、全然違う目的や手段になると思います。
皆さん自身で一度考えてみてもらえると嬉しいです。

View Slide

47

View Slide

監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring

監視やモニタリングについてもうちょっとだけ考えてみよう / Think about monitoring

Takashi Nasu

More Decks by Takashi Nasu

Other Decks in Technology

Featured

Transcript