~スタートアップの人たちに捧ぐ~ 監視再入門 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
2. Shinichi Hama / track3jyo Startup Solutions Architect Amazon Web Service Japan --- work: - ⻄⽇本のスタートアップ⽀援 - コンテナ技術のあれこれ 過去のスライド: https://speakerdeck.com/track3jyo <最近好きな AWS サービス> AWS App Runner Amazon ECS Amazon DynamoDB
3. アジェンダ • 「監視」再⼊⾨ • ありがちな監視アンチパターン • AWS 上で⼩さく的確に監視を始める • まとめ & Next Step
4. 「監視」再⼊⾨
5. なぜサービスを監視するのか︖ • システムはある⽇突然壊れる • 定期的・継続的に観測してこの「突然壊れる」を検知・予知し、 対応する必要がある • 広い意味で「監視」とは、定期的・継続的に観測することで システムの価値を維持・向上させるためにおこなう⾏為全て
6. 監視の種類 • ビジネス監視（e.g. ⽉次売上、会員登録数） • フロントエンド監視（e.g. リアルユーザー監視、模擬モニタリング） • アプリケーション監視（e.g. API のレスポンスタイム、DB クエリ実⾏時間） • サーバー監視（e.g. CPU 使⽤率、メモリ使⽤率） • セキュリティ監視（e.g. ログイン試⾏ /fail 履歴、sudo 実⾏） • …more
7. 監視に重要な三つの軸 – メトリクス、ログ、トレース - Logging Metrics Tracing Monitoring l システム内で発⽣したイベント情報 l 各イベントが独⽴したレコードとして記録される l e.g. アクセスログ、 エラー情報、… l ある時点のなんらかのシステム状態 を表現する数値情報 l ⼀定間隔ごとの時系列データとして 記録される l e.g. CPU 使⽤率、エラー率、 ストレージ残容量、… l 1つのトランザクションを複数システム で構成するフロー情報 l トランザクションごとにユニークな識別 ⼦をもって記録される l e.g. ある HTTP リクエストの受け取りか らレスポンスまで
8. 監視システムのコンポーネント(CloudWatch を例に) CloudWatch Alarms （監視アラーム） 観測 CloudWatch Metrics, CloudWatch Logs CloudWatch Logs Insights （クエリエンジン） CloudWatch Dashboards （ダッシュボード） メトリクスやログな ど監視データを送信 メトリクスに応じた アクションの実⾏ ログの可視化 EC2 インスタンス CloudWatch エージェント （監視⽤エージェント） データ収集 データ利⽤ SNS Topic（通知） Mobile / SMS
9. ありがちな 監視アンチパターン
10. アンチパターン 1: 監視ツールを選ぶところから始める • ⼿段(ツール)を選ぶところから⼊ってしまい、そこで満⾜してしまう • 改善策︓ツール選定は監視計画と⼀緒に考える • モニタリングの⽬的は? • モニタリングの対象となるリソースは? • どのくらいの頻度でこれらのリソースをモニタリングするか? • 使⽤するモニタリングツールは? • 誰がモニタリングタスクを実⾏するか? • 問題が発⽣したときに誰が通知を受け取るか? https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring_best_practices.html
11. アンチパターン 2: メトリクスとログをとりあえず集めて満⾜ • メトリクスとログデータを収集して終わっている。 • 障害発⽣後初めてデータを⾒る。⾒⽅や調査⽅法がわからない。 • 改善策︓ • 監視データの分類と対応パターンを定義する • Daily, Weekly, Monthly で監視データの確認 • 調査対応時は、複数名であたりノウハウを共有する
12. アンチパターン 3: 無視していいアラートがいっぱいある • アラート疲れ、アラート燃え尽き症候群になっている • たくさんアラートメールが⾶んでくるが、基本対応の必要ない(対応していない) • e.g: CPU 使⽤率 80%、わからないけど⾒た感じ⼤丈夫そうなので放置しているエラー…more • ある⽇重要なアラートを⾒逃し⼤障害に…(狼少年) • 改善策︓ • 監視データの分類と対応パターンを定義する • 即時対応が必要な異常に対して強⼒な通知を⾏う • e.g. HTTP のレスポンスコードやリクエスト時間などユーザーから近いもの • オートリカバリーを組み込む（強い通知は不要） • 誤検出も含め、定期的にアラートをメンテナンスする
13. 監視データの分類と対応パターン パターン 観測・記録 異常性の判定 ⾏うべき通知 対応完了の管理 異常を検知して、即時対応したい する する 電話,チャット する 異常を検知して、翌営業⽇以降に対応したい する する チケット起票 など する 対応はしないけど、異常があったことは知り たい する する 通知なし しない 特にこれという観点はないけど、記録したい する しない しない しない Web エンジニアのための監視システム実装ガイド / 78p https://www.amazon.co.jp/dp/4839969817/
14. アンチパターン 4: 監視・トラブル対応が特定の⼈任せ • 監視・トラブル対応を特定の⼈に依存している • オンコール対応担当を決めていない • その特定の⼈が対応できない⽇、⼤障害に… • 改善策︓ • 監視はできる限り開発チーム全員で取り組む • “You build it, you run it” • オンコール担当はメインとサブで、ローテーションを組む
15. アンチパターン 5: 監視していません 監視しましょう。 監視はシステムの価値を継続的に維持・向上させるためのものです。 またセキュリティ Issue が放置されていた場合、顧客の信⽤を⼀気に失いかねません。
16. AWS 上で⼩さく・的確に 監視を始める
17. CloudWatch は最初の選択肢 • AWS サービスに対するビルトインの メトリクスやログが利⽤可能 • 特に準備不要で監視を始められる • e.g. EC2、RDS、Lambda、ECS、S3、 DynamoDB…more • AWS サービスとのインテグレーションが容易 • 監視データの S3 へのバックアップ • Alarm からのオートメーション処理 • …more • 1 プラットフォームで完結できる
18. CloudWatch は最初の選択肢 • メトリクス・ログ以外も監視システムとして さまざまな機能を提供 • CloudWatch Alarm: 監視アラート • CloudWatch dashboard: ダッシュボードによる可視化 • CloudWatch Synthetics:模擬モニタリング • CloudWatch Logs Insights: ログデータのクエリ分析 • CloudWatch Container Insights: コンテナレベルの監視 • CloudWatch ServiceLens: トレースデータの可視化 • CloudWatch RUM: リアルユーザーモニタリング • CloudWatch Evidently:フィーチャーフラグ、A/Bテスト • …more
19. CloudWatch は最初の選択肢 • チームとしてすでに使い慣れている監視 SaaS があるのであれば、 そこも選択肢になる • スタートアップにとって、⼀番のアンチパターンは ⾃⾝で監視システムを構築・運⽤すること • サービスのコストより、⼈のコストの⽅が⾼いし貴重です • 可能な限りマネージドなサービスを使いましょう
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
21. GuardDuty はとりあえず有効化する • セキュリティの観点から 脅威を検知するサービス • 機械学習、異常検出、脅威インテリジェンスを使⽤ • 数クリックで有効化可能 • 従量課⾦モデルで⼩さくスタート • 30⽇間の無料トライアルで料⾦試算が可能 • 例えば重要度が ⾼ の検出を トリガーに通知するなど 偵察 インスタンス の侵害 アカウントの 侵害 通常と異なる API アクティビティ 悪意のある既知の IP 通常と異な るポート ポートスキャン 通常と異なる トラフィック量 通常と異なるインスタンスまた はインフラストラクチャの起動 匿名化プロキシ 窃取された 認証情報の悪⽤ ビットコイン アクティビティ DNSを⽤いた不正通信 CloudTrail の無効化 RDP/SSH ブルートフォース Amazon GuardDuty
22. 困った時の RDS Performance Insights • 運⽤でよく起こりがちな RDB ワーク ロードのパフォーマンス最適化を お助け • 数クリックで RDS のパフォーマンス 情報を可視化 • ダッシュボードからドリルダウンして いき、原因となったクエリなどを特定 • 無料枠からスモールにスタートできる • 7 ⽇間分のパフォーマンスデータ履歴 • 1 か⽉あたり 100 万件のリクエスト
23. • 「監視」はシステムの価値を維持・向上させるために おこなうもの • 最初から監視システムを作り込まない • 意図のない監視は⼈を疲弊させる • AWS 上で稼働するサービスを監視する上で CloudWatch は最初の選択肢 さいごに – お伝えしたかったこと -
24. 次のステップ1: AWS Well-Architected フレームワーク （運⽤上の優秀性の柱） https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/ 設計原則 • 運⽤をコードとして実⾏する • ⼩規模かつ可逆的な変更を頻繁に⾏う • 運⽤⼿順を定期的に改善する • 障害を予想する • 運⽤上のすべての障害から学ぶ
25. 次のステップ2: One Observability Workshop https://catalog.workshops.aws/observability/ja-JP/
26. 個⼈的に参考になると思う書籍 • ⼊⾨ 監視 • https://www.amazon.co.jp/dp/4873118646/ • Web エンジニアのための監視システム実装ガイド • https://www.amazon.co.jp/dp/4839969817/
27. Thank you © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Shinichi Hama track3jyo