~スタートアップの人たちに捧ぐ~ 監視再入門 in AWS

https://aws-startup-community.connpass.com/event/241721/
2022/05/10(火) 19:30 〜 21:30
「スタートアップ事例祭り 〜監視・モニタリング・セキュリティ編〜」

Transcript

1. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   Shinichi Hama / track3jyo
   Startup Solutions Architect, West Japan
   Amazon Web Services Japan G.K.
   ~スタートアップの⼈たちに捧ぐ~
   監視再⼊⾨ in AWS
   

   View Slide

2. Shinichi Hama / track3jyo
   Startup Solutions Architect
   Amazon Web Service Japan
   ---
   work:
   - ⻄⽇本のスタートアップ⽀援
   - コンテナ技術のあれこれ
   過去のスライド: https://speakerdeck.com/track3jyo
   <最近好きな AWS サービス>
   AWS App Runner Amazon ECS Amazon DynamoDB
   

   View Slide

3. アジェンダ
   • 「監視」再⼊⾨
   • ありがちな監視アンチパターン
   • AWS 上で⼩さく的確に監視を始める
   • まとめ & Next Step
   

   View Slide

4. 「監視」再⼊⾨
   

   View Slide

5. なぜサービスを監視するのか︖
   • システムはある⽇突然壊れる
   • 定期的・継続的に観測してこの「突然壊れる」を検知・予知し、
   対応する必要がある
   • 広い意味で「監視」とは、定期的・継続的に観測することで
   システムの価値を維持・向上させるためにおこなう⾏為全て
   

   View Slide

6. 監視の種類
   • ビジネス監視（e.g. ⽉次売上、会員登録数）
   • フロントエンド監視（e.g. リアルユーザー監視、模擬モニタリング）
   • アプリケーション監視（e.g. API のレスポンスタイム、DB クエリ実⾏時間）
   • サーバー監視（e.g. CPU 使⽤率、メモリ使⽤率）
   • セキュリティ監視（e.g. ログイン試⾏ /fail 履歴、sudo 実⾏）
   • …more
   

   View Slide

7. 監視に重要な三つの軸 – メトリクス、ログ、トレース -
   Logging
   Metrics Tracing
   Monitoring
   l
   システム内で発⽣したイベント情報
   l
   各イベントが独⽴したレコードとして記録される
   l
   e.g. アクセスログ、 エラー情報、…
   l
   ある時点のなんらかのシステム状態
   を表現する数値情報
   l
   ⼀定間隔ごとの時系列データとして
   記録される
   l
   e.g. CPU 使⽤率、エラー率、
   ストレージ残容量、…
   l
   1つのトランザクションを複数システム
   で構成するフロー情報
   l
   トランザクションごとにユニークな識別
   ⼦をもって記録される
   l
   e.g. ある HTTP リクエストの受け取りか
   らレスポンスまで
   

   View Slide

8. 監視システムのコンポーネント(CloudWatch を例に)
   CloudWatch Alarms
   （監視アラーム）
   観測
   CloudWatch Metrics,
   CloudWatch Logs
   CloudWatch Logs Insights
   （クエリエンジン）
   CloudWatch Dashboards
   （ダッシュボード）
   メトリクスやログな
   ど監視データを送信
   メトリクスに応じた
   アクションの実⾏
   ログの可視化
   EC2 インスタンス
   CloudWatch エージェント
   （監視⽤エージェント）
   データ収集 データ利⽤
   SNS Topic（通知） Mobile /
   SMS
   

   View Slide

9. ありがちな
   監視アンチパターン
   

   View Slide

10. アンチパターン 1: 監視ツールを選ぶところから始める
    • ⼿段(ツール)を選ぶところから⼊ってしまい、そこで満⾜してしまう
    • 改善策︓ツール選定は監視計画と⼀緒に考える
    • モニタリングの⽬的は?
    • モニタリングの対象となるリソースは?
    • どのくらいの頻度でこれらのリソースをモニタリングするか?
    • 使⽤するモニタリングツールは?
    • 誰がモニタリングタスクを実⾏するか?
    • 問題が発⽣したときに誰が通知を受け取るか?
    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring_best_practices.html
    

    View Slide

11. アンチパターン 2: メトリクスとログをとりあえず集めて満⾜
    • メトリクスとログデータを収集して終わっている。
    • 障害発⽣後初めてデータを⾒る。⾒⽅や調査⽅法がわからない。
    • 改善策︓
    • 監視データの分類と対応パターンを定義する
    • Daily, Weekly, Monthly で監視データの確認
    • 調査対応時は、複数名であたりノウハウを共有する
    

    View Slide

12. アンチパターン 3: 無視していいアラートがいっぱいある
    • アラート疲れ、アラート燃え尽き症候群になっている
    • たくさんアラートメールが⾶んでくるが、基本対応の必要ない(対応していない)
    • e.g: CPU 使⽤率 80%、わからないけど⾒た感じ⼤丈夫そうなので放置しているエラー…more
    • ある⽇重要なアラートを⾒逃し⼤障害に…(狼少年)
    • 改善策︓
    • 監視データの分類と対応パターンを定義する
    • 即時対応が必要な異常に対して強⼒な通知を⾏う
    • e.g. HTTP のレスポンスコードやリクエスト時間などユーザーから近いもの
    • オートリカバリーを組み込む（強い通知は不要）
    • 誤検出も含め、定期的にアラートをメンテナンスする
    

    View Slide

13. 監視データの分類と対応パターン
    パターン 観測・記録 異常性の判定 ⾏うべき通知 対応完了の管理
    異常を検知して、即時対応したい する する 電話,チャット する
    異常を検知して、翌営業⽇以降に対応したい する する チケット起票
    など
    する
    対応はしないけど、異常があったことは知り
    たい
    する する 通知なし しない
    特にこれという観点はないけど、記録したい する しない しない しない
    Web エンジニアのための監視システム実装ガイド / 78p
    https://www.amazon.co.jp/dp/4839969817/
    

    View Slide

14. アンチパターン 4: 監視・トラブル対応が特定の⼈任せ
    • 監視・トラブル対応を特定の⼈に依存している
    • オンコール対応担当を決めていない
    • その特定の⼈が対応できない⽇、⼤障害に…
    • 改善策︓
    • 監視はできる限り開発チーム全員で取り組む
    • “You build it, you run it”
    • オンコール担当はメインとサブで、ローテーションを組む
    

    View Slide

15. アンチパターン 5: 監視していません
    監視しましょう。
    監視はシステムの価値を継続的に維持・向上させるためのものです。
    またセキュリティ Issue が放置されていた場合、顧客の信⽤を⼀気に失いかねません。
    

    View Slide

16. AWS 上で⼩さく・的確に
    監視を始める
    

    View Slide

17. CloudWatch は最初の選択肢
    • AWS サービスに対するビルトインの
    メトリクスやログが利⽤可能
    • 特に準備不要で監視を始められる
    • e.g. EC2、RDS、Lambda、ECS、S3、
    DynamoDB…more
    • AWS サービスとのインテグレーションが容易
    • 監視データの S3 へのバックアップ
    • Alarm からのオートメーション処理
    • …more
    • 1 プラットフォームで完結できる
    

    View Slide

18. CloudWatch は最初の選択肢
    • メトリクス・ログ以外も監視システムとして
    さまざまな機能を提供
    • CloudWatch Alarm: 監視アラート
    • CloudWatch dashboard: ダッシュボードによる可視化
    • CloudWatch Synthetics:模擬モニタリング
    • CloudWatch Logs Insights: ログデータのクエリ分析
    • CloudWatch Container Insights: コンテナレベルの監視
    • CloudWatch ServiceLens: トレースデータの可視化
    • CloudWatch RUM: リアルユーザーモニタリング
    • CloudWatch Evidently:フィーチャーフラグ、A/Bテスト
    • …more
    

    View Slide

19. CloudWatch は最初の選択肢
    • チームとしてすでに使い慣れている監視 SaaS があるのであれば、
    そこも選択肢になる
    • スタートアップにとって、⼀番のアンチパターンは
    ⾃⾝で監視システムを構築・運⽤すること
    • サービスのコストより、⼈のコストの⽅が⾼いし貴重です
    • 可能な限りマネージドなサービスを使いましょう
    

    View Slide

20. CloudWatch を活⽤したモニタリング構成例
    EC2 Instance
    CloudWatch Logs
    EC2 Instance
    CloudWatch Metrics
    VPC Flow Logs
    AWS Config
    AWS CloudTrail
    On-Premises
    AWS Storage
    Gateway
    AWS Backup Amazon
    CloudWatch
    AWS Budgets
    SNS Topic
    Amazon CloudWatch
    AWS Services
    Amazon RDS Amazon S3 Amazon
    DynamoDB
    CloudWatch
    Event
    CloudWatch
    Alarm
    CloudWatch
    Rule
    AWS
    Lambda
    HTTP
    Notification
    Email
    Notification
    Mobile / SMS
    Personal
    Health
    Dashboard
    AWS Events
    Amazon S3 Amazon
    GuardDuty
    AWS Trusted
    Advisor
    AWS Systems
    Manager
    AWS Chatbot
    Amazon Chime
    Server
    

    View Slide

21. GuardDuty はとりあえず有効化する
    • セキュリティの観点から
    脅威を検知するサービス
    • 機械学習、異常検出、脅威インテリジェンスを使⽤
    • 数クリックで有効化可能
    • 従量課⾦モデルで⼩さくスタート
    • 30⽇間の無料トライアルで料⾦試算が可能
    • 例えば重要度が ⾼ の検出を
    トリガーに通知するなど
    偵察
    インスタンス
    の侵害
    アカウントの
    侵害
    通常と異なる API
    アクティビティ
    悪意のある既知の IP
    通常と異な
    るポート
    ポートスキャン
    通常と異なる
    トラフィック量
    通常と異なるインスタンスまた
    はインフラストラクチャの起動
    匿名化プロキシ
    窃取された
    認証情報の悪⽤
    ビットコイン
    アクティビティ
    DNSを⽤いた不正通信
    CloudTrail の無効化
    RDP/SSH
    ブルートフォース
    Amazon GuardDuty
    

    View Slide

22. 困った時の RDS Performance Insights
    • 運⽤でよく起こりがちな RDB ワーク
    ロードのパフォーマンス最適化を
    お助け
    • 数クリックで RDS のパフォーマンス
    情報を可視化
    • ダッシュボードからドリルダウンして
    いき、原因となったクエリなどを特定
    • 無料枠からスモールにスタートできる
    • 7 ⽇間分のパフォーマンスデータ履歴
    • 1 か⽉あたり 100 万件のリクエスト
    

    View Slide

23. • 「監視」はシステムの価値を維持・向上させるために
    おこなうもの
    • 最初から監視システムを作り込まない
    • 意図のない監視は⼈を疲弊させる
    • AWS 上で稼働するサービスを監視する上で
    CloudWatch は最初の選択肢
    さいごに – お伝えしたかったこと -
    

    View Slide

24. 次のステップ1: AWS Well-Architected フレームワーク
    （運⽤上の優秀性の柱）
    https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/
    設計原則
    • 運⽤をコードとして実⾏する
    • ⼩規模かつ可逆的な変更を頻繁に⾏う
    • 運⽤⼿順を定期的に改善する
    • 障害を予想する
    • 運⽤上のすべての障害から学ぶ
    

    View Slide

25. 次のステップ2: One Observability Workshop
    https://catalog.workshops.aws/observability/ja-JP/
    

    View Slide

26. 個⼈的に参考になると思う書籍
    • ⼊⾨ 監視
    • https://www.amazon.co.jp/dp/4873118646/
    • Web エンジニアのための監視システム実装ガイド
    • https://www.amazon.co.jp/dp/4839969817/
    

    View Slide

27. Thank you
    © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    Shinichi Hama
    track3jyo
    

    View Slide