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

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

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

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

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

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

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

8 Copyright © 2020 BeeX Inc. All Rights Reserved. ちょっとだけゴールデンサークルの話
Why What How Why What How サイモン・シネックさんが提唱した理論

9 Copyright © 2020 BeeX Inc. All Rights Reserved. というわけで
WhyからHow/Whatについて考えてみたい

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

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

12 Copyright © 2020 BeeX Inc. All Rights Reserved. こっちが目的？
その結果得られるであろう「運用負荷を下げる」が目的かも？

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

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

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

17 Copyright © 2020 BeeX Inc. All Rights Reserved. そもそも監視とモニタリングって何が違うの？
モニタリング監視こんなイメージ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Decks by Takashi Nasu

Other Decks in Technology

Featured

Transcript