JAWS-UG 情シス支部 第31回 クラウド女子会×札幌支部コラボ会 チョークトーク CloudWatchについて / JAWS-UG System Admins collaboration with Sapporo, Cloud Girls Chalk Talk about CloudWatch

JAWS-UG 情シス支部 第31回 クラウド女子会×札幌支部コラボ会で実施した、CloudWatchに関するチョークトークの資料です。
当日は実際には課題4までをしました。
#jawsug情シス #cloudgirl #jawsug_sapporo

Transcript

1. チョークトーク CloudWatchについて 2025/5/24 JAWS-UG 情シス支部 第31回 クラウド女子会×札幌支部コラボ会
2. チョークトークの進め方 • チョークトークとは対話型のセッションで学校の授業やゼミに近いものです • 途中、投票型の質問と発言型の質問があります ◦ 投票型 ▪ スライドに投影された選択肢の中から選択していただきます ▪ ご自身の考えに最も近いものに手を挙げてください ◦ 発言型 ▪ 質問について発言したい方は手を挙げてください • チョークトークはクイズではないので正解も不正解もありません • 積極的に発言と議論をして、みんなで知見の共有をしましょう！
3. 申込時アンケート結果 あなたのCloudWatchの経験は？（一番近いものを選択してください） 1. CloudWatchってなんぞや　6名（あなた絶対初心者じゃないじゃんって人が3名） 2. CloudWatch "完全に" 理解した　2名 3. CloudWatch 日常的に見たり設定したりしてるよ！　7名 4. ﾜﾀｼ ｸﾗｳﾄﾞｳｫｯﾁ ﾁｮﾄ ﾃﾞｷﾙ　4名
4. 申込時アンケート結果 CloudWatchやモニタリングについての困りごとや悩み事はありますか？ • Platform Engineeringとしてどうやってセルフサービスを提供できるか悩んでいる • よくわかっていないのが悩み事 • マネコンが見づらい • Datadogに任してるので特にない... • モニタリング対象の選定基準が分からない。他サービスとの連携例が思い浮かばない。 • 良く聞く単語ですが、アプリケーションエンジニアですので（言い訳）、いまいちはっきりと概念や ユースケースを理解できておらず・・・。 • CloudWatchLogsで集積したあとのワードによるアラーム設定の難解さ • CloudWatchの仲間が増え過ぎて追い切れてない • alert通知たくさんで埋もれる • 適切なしきい値を知りたい • 費用がそこそこかかる • モニタリングに割く時間がなかなか取れない ^^; • どこまでログって処理しているの？
5. 申込時アンケート結果 CloudWatchについてどのようなことを知りたいですか？ • 各機能の使い分けなど • 直近のアップデートをキャッチアップできていないのでどのような機能が増えているのか • よくわかってないので改めて勉強したいです • ログ収集の目的にしか使用しておらず、本来できる事の多くはできていない（機能を全然使い切れて いない）ので、色々なTipsなどを知るきっかけになれば • CloudWatch Logs の効率的な運用方法 • Datadogとの比較とか、Datadog使わなくてもCloudWatchだけでもいけるよー的な？ • CloudWatchで集めたログ（監査ログ）等を加工して通知する様な仕組みを使うような事例 • 基本的なことを知ることができればと思います。 • どこまでCloudWatchで対応しているか（3rdPartyツールとの使い分けの境界） • 自動復旧等、洗練された使い方 • みなさんがどのように使っているのかを知りたいです • ログの見方
6. CloudWatchの 各機能について
7. CloudWatchの主要機能説明 1. CloudWatch Metrics（メトリクス） システムの状態を数値化して時系列で保存するサービス 2. CloudWatch Logs（ログ）アプリケーションやシステムのログを収集・保存・分析するサービス 3. CloudWatch Alarms（アラーム） メトリクスの状態を監視し、閾値超過時にアクションを実行 4. CloudWatch Dashboard（ダッシュボード） メトリクスやログを可視化して表示 5. CloudWatch ServiceLens　トレース、メトリクス、ログを統合的に表示 6. CloudWatch Synthetics　アプリケーションのエンドポイントを定期的に監視 7. CloudWatch RUM（Real-User Monitoring）実際のユーザーセッションを監視 8. CloudWatch Evidently　新機能のA/Bテストや段階的なロールアウトを管理
8. CloudWatchの主要機能説明 9. CloudWatch Container Insights　コンテナ化されたアプリとマイクロサービスの監視・トラブルシューティング 10. CloudWatch Application Insights　アプリケーションのリソースを自動で監視 11. CloudWatch Internet Monitor　インターネット接続の可用性とパフォーマンスを監視 12. CloudWatch Contributor Insights　時系列データの分析によるトップコントリビューターの特定 13. CloudWatch Metric Streams　メトリクスデータをほぼリアルタイムで外部に送信 14. CloudWatch Cross-Account Observability　複数のAWSアカウントにまたがる監視の一元化 15. CloudWatch Unified Security Monitoring　セキュリティ関連の監視を統合
9. シチュエーションの説 明 みなさんもイメージしやすいようにモデルとする 架空の企業を作りました。 この企業のシステムで発生する課題に対して、 どのようなアプローチをとるかという観点で進め ます。
10. 想定企業とシステムについて • 企業名：SharkCart株式会社（SharkCart, Inc.） • 企業理念：「速く、力強く、絶え間ない進化」（Fast, Powerful, Ever-evolving） • 事業内容：ECサイト運営（アパレル、雑貨、食品等） • 売上規模：年商300億円 • ユーザー数：月間アクティブユーザー100万人 • 本社所在地：JR池袋駅徒歩10分（サメが輝く水族館の近く） 企業の特徴 • 社名の由来：大きな口を開けて獲物を捕らえるサメのように、 幅広い商品をワンストップで提供する • マスコットキャラクター：「フィンちゃん」 • 企業カラー：シャークブルー（#1B4B65）
11. SharkCartのブランド • ECサイト名：SharkMart（シャークマート） • モバイルアプリ：SharkCart GO • 会員プログラム：SharkFin Members
12. SharkCartのシステム構成 • フロントエンド：CloudFront + React • バックエンド：ECS on EC2（マイクロサービス構成） • データベース：Aurora MySQL • キャッシュ：ElastiCache for Redis • 画像/動画ストレージ：S3 • 検索エンジン：OpenSearch Service • その他：SQS（非同期処理）、EventBridge（バッチ処理）
13. SharkCartの開発チーム体制 • Shark Pod（商品管理チーム） • Hammerhead Squad（決済システムチーム） • Ray Team（UI/UXチーム） • Deep Sea Team（インフラチーム） • Blue Ocean Team（データ分析チーム）
14. SharkCartのセール体系 冬のセール Great White Friday（年1回） • 時期：11月最終金曜日（従来のブラックフライデーに相当） • 特徴：年間最大の割引率、最大の商品数 • 規模：年間最大のトラフィック、売上 定例セール Shark Sunday（毎月開催） • 時期：毎月第2日曜日 • 特徴：カテゴリー別の特別割引 • 規模：通常の2-3倍のトラフィック
15. SharkCartのセール体系 夏のセール Deep Blue Sale（7月） • 期間：2週間 • 時間帯別セール ◦ Dawn Sale（早朝6:00-8:00）：深海生物が浮上してくるイメージ ◦ Deep Night Sale（22:00-24:00）：深海に潜るイメージ • 特別企画 ◦ 深海レベル別割引：商品は時間経過で深層に移動（割引率アップ） ▪ Level 1 (表層): 10%OFF ▪ Level 2 (中層): 30%OFF ▪ Level 3 (深層): 50%OFF ▪ Level 4 (超深層): 70%OFF • SharkFin Members特典 ◦ プレセール参加権 ◦ 限定深海アイテム ◦ ポイント2倍
16. 課題シーン 1：パフォーマンス問題 状況 年に一度の最大セール『Great White Friday』と、毎月開催の『Shark Sunday』でアクセス 集中によりサイトのレスポンスが悪化。 特に目玉商品の検索・カート追加・決済処理での遅延が顕著。Deep Sea Team（インフラ チーム）は、売上機会の損失を防ぐため、早期検知と自動対応の仕組みを構築する必要が ある。
17. 質問（投票です！） レスポンス悪化の早期検知と自動対応の仕組みを構築する必要のある状況で 最も効果的な監視設定は？ 1. ECSサービスのCPU使用率80%超過でスケールアウト 2. Auroraのレプリカ遅延が30秒超過でアラート 3. APIレスポンスタイムp90が2秒超過で通知 4. ElastiCacheのメモリ使用率90%超過でスケールアップ
18. ベストプラクティス • 多層的な監視設定 ◦ インフラ指標とアプリケーション指標の組み合わせ ◦ 複合アラームによる誤検知防止 ◦ 段階的なアラート閾値（警告→重要→緊急） • スケーリングポリシー ◦ ターゲット追跡スケーリングの活用 ◦ スケールアウトの閾値は余裕を持って設定 ◦ クールダウン期間の適切な設定
19. 質問（手を挙げてご意見ください！） 毎月開催される「Shark Sunday」セール時の負荷対策として、 あなたならどのような自動化を実装しますか？
20. ベストプラクティス • プロアクティブな対応 ◦ 予測可能なイベント前の事前スケーリング ◦ 段階的なキャパシティ増強 ◦ 自動スケーリングの補助的な活用 • 自動化のアプローチ ◦ EventBridgeによるスケジュール実行 ◦ Systems Managerの自動化 ◦ Step Functionsによる複雑なワークフロー制御
21. 課題シーン 2：システム異常 状況 深夜の「Night Shark Batch」（在庫同期処理）が失敗。 朝になって発覚し、「SharkFin Members」向けの限定商品で在庫表示が実際の在庫数と 不整合が発生。 Shark Pod（商品管理チーム）とDeep Sea Team（インフラチーム）間で異常を早期に検知 する仕組みが必要。
22. 質問（投票です！） バッチ処理の監視として最適な組み合わせは？ 1. EventBridgeの実行結果 + ログパターンマッチング 2. カスタムメトリクス + 処理件数の閾値監視 3. Step Functionsの実行状態 + タスク所要時間 4. CloudWatch Syntheticsでの結果整合性チェック
23. ベストプラクティス • バッチ監視の基本設定 ◦ 実行開始・終了のログ記録 ◦ 処理件数のメトリクス化 ◦ 実行時間の監視と閾値設定 • 異常検知の仕組み ◦ 前回実行との差分チェック ◦ 業務的な妥当性確認 ◦ データ整合性の自動検証
24. 質問（手を挙げてご意見ください！） あなたがバッチ処理の異常検知で工夫している点はありますか？
25. ベストプラクティス • ログ設計のポイント ◦ 構造化ログの採用 ◦ エラー重要度の明確な分類 ◦ トレーサビリティの確保 • 自動リカバリー ◦ エラー時の再実行条件定義 ◦ デッドレターキューの活用 ◦ 手動介入ポイントの明確化
26. 課題シーン 3：セキュリティインシデント 状況 「SharkFin Members」アカウントへの不自然なログイン試行が多発。 また、商品API呼び出しの急増やデータベースへの大量クエリなど、通常とは異なるパター ンが観測されている。 SHARK（Swift Handling and Response Keeper）Team（緊急対応チーム）による即時対 応が必要。
27. 質問（投票です！） セキュリティ監視として優先すべき項目は？ 1. WAFのブロックルール + CloudTrailログ 2. VPCフローログ + GuardDuty 3. RDSのスロークエリ + 接続元IP 4. IAMの認証失敗 + API呼び出し頻度
28. ベストプラクティス • セキュリティ監視の階層化 ◦ ネットワークレベル：VPCフローログ、WAF ◦ アプリケーションレベル：認証ログ、APIアクセスログ ◦ データベースレベル：クエリログ、アクセスパターン • アラート設定 ◦ 重要度に基づく通知先の振り分け ◦ インシデントタイプごとの対応フロー定義 ◦ 誤検知を減らすための複合条件設定
29. 質問（手を挙げてご意見ください！） あなたが今までに実施したセキュリティインシデントの検知・対応で 効果的だった施策はありますか？
30. ベストプラクティス • 自動対応の実装 ◦ WAFルールの動的更新 ◦ セキュリティグループの自動制御 ◦ インシデント情報の自動集約 • インシデント管理 ◦ Security Hubでの一元管理 ◦ ChatOpsによる即時共有 ◦ インシデント対応の文書化と改善
31. 課題シーン 4：コスト最適化 状況 Blue Ocean Team（データ分析チーム）の分析により、AWSの利用料金が前月比20%増 加していることが判明。 特にCloudWatchのログ保存とメトリクス収集のコストが増大。 Deep Sea Team（インフラチーム）は監視品質を維持しながら、コストを最適化したい。
32. 質問（投票です！） コスト最適化として効果的な施策は？ 1. ログ保持期間の見直しと重要度による振り分け 2. メトリクス収集間隔の調整 3. カスタムメトリクスの統合・整理 4. 不要なダッシュボードの棚卸し
33. ベストプラクティス • ログ管理の最適化 ◦ ログレベルの適切な設定（INFO/WARN/ERROR） ◦ ログ保持期間のポリシー策定 ◦ サンプリングルールの導入 • メトリクス収集の効率化 ◦ 必要最小限のメトリクス定義 ◦ 収集間隔の最適化 ◦ 集約メトリクスの活用
34. 質問（手を挙げてご意見ください！） あなたがCloudWatchのコスト最適化で実施している工夫があれば教えてください。
35. ベストプラクティス • コスト可視化 ◦ リソースタグによる費用分析 ◦ チーム別コストダッシュボード ◦ 予算アラートの設定 • 運用プロセス ◦ 定期的な使用状況レビュー ◦ 不要リソースの特定と削除 ◦ コスト効率の定期評価
36. 課題シーン 5：オブザーバビリティの強化 状況 SharkMartのマイクロサービス化が進み、各Podやチーム間のサービス依存関係が複雑 化。 夏の期間限定セール「Deep Blue Sale」中の障害発生時、Ray Team（UI/UXチーム）から Hammerhead Squad（決済システムチーム）まで、問題の切り分けに時間がかかってい る。
37. Deep Blue Sale - SharkCartの夏季限定の大規模セール キャンペーンの特徴 1. 時間帯別セール ◦ Dawn Sale（早朝6:00-8:00）：深海生物が浮上してくるイメージ ◦ Deep Night Sale（22:00-24:00）：深海に潜るイメージ 2. 特別企画 ◦ 深海レベル別割引 ▪ Level 1 (表層): 10%OFF ▪ Level 2 (中層): 30%OFF ▪ Level 3 (深層): 50%OFF ▪ Level 4 (超深層): 70%OFF ◦ 商品は時間経過で深層に移動（割引率アップ） 3. SharkFin Members特典 ◦ プレセール参加権 ◦ 限定深海アイテム ◦ ポイント2倍
38. Deep Blue Sale - SharkCartの夏季限定の大規模セール システム負荷要因 1. タイムセール開始時の瞬間的なアクセス集中 2. レベル変更時の商品価格一斉更新 3. 在庫数リアルタイム同期 4. SharkFin Members認証の集中 監視ポイント 1. フロントエンド ◦ SharkCart GOアプリの応答性 ◦ 商品検索機能のレスポンス 2. バックエンド ◦ 価格更新バッチの処理状況 ◦ 在庫同期の整合性 3. インフラ ◦ オートスケーリングの効果 ◦ キャッシュヒット率
39. 質問（投票です！） SharkMartオブザーバビリティ実現のために、最初に取り組むべき施策は？ 1. X-Rayによる分散トレーシングの導入 2. ServiceLensでのSharkMart全体のメトリクス・ログ・トレースの統合 3. CloudWatch RUMによるモバイルアプリのユーザー体験モニタリング 4. Syntheticsによる商品検索・決済フローの定期的な外形監視
40. ベストプラクティス • 分散トレーシング ◦ サービス間の依存関係の可視化 ◦ パフォーマンスボトルネックの特定 ◦ エラー伝播の追跡 • 統合モニタリング ◦ メトリクス・ログ・トレースの相関 ◦ エンドツーエンドの可視性確保 ◦ ユーザー体験の定量化
41. 質問（投票です！） サービス依存関係が複雑化しているDeep Blue Saleでの トラブルシューティングを効率化するために、最も重要な観点は？ 1. Shark Pod（商品管理チーム） から Hammerhead Squad（決済システムチーム）まで の依存関係の可視化 2. SharkFin Members認証からカート決済までのエラー伝播追跡 3. Great White Friday対策で改善したボトルネックの特定 4. SharkCart GOアプリユーザーへの影響範囲の定量化
42. ベストプラクティス • トラブルシューティング ◦ 共通のコンテキスト情報付与 ◦ サービスマップの自動生成 ◦ 影響範囲の即時把握 • パフォーマンス分析 ◦ レイテンシーの詳細分析 ◦ ボトルネックの自動検出 ◦ リソース使用率の相関分析
43. 質問（手を挙げてご意見ください！） オブザーバビリティを実現する上で、あなたならどのような指標やログを 相関付けますか？
44. ベストプラクティス • データ相関 ◦ トレースIDによる紐付け ◦ タイムスタンプの正規化 ◦ メタデータの標準化 • 可視化戦略 ◦ 目的別ダッシュボード ◦ リアルタイムモニタリング ◦ トレンド分析の自動化
45. 課題シーン 6：SLO/SLIの設定 状況 経営陣からサービス品質の定量的な評価を求められている。 また、各マイクロサービスチームが独自に監視設定を行っており、品質基準がバラバラに なっている。
46. 質問（投票です！） SharkMart（ECサイト）のSLIとして最も重要な指標は？ SLI = Service Level Indicator : サービス品質を定量的に測定するための指標 1. 商品検索APIのレイテンシー 2. 決済処理の成功率 3. モバイルアプリのページロード時間 4. カート機能の可用性
47. ベストプラクティス • SLI選定基準 ◦ ユーザー体験との直接的な関連性 ◦ 測定の容易さと正確性 ◦ ビジネスインパクトの大きさ • 測定方法 ◦ エンドポイントごとの詳細測定 ◦ ユーザーセグメント別の分析 ◦ 地域・デバイス別の傾向把握
48. 質問（投票です！） Shark Quality Score（SLO）の設定方法として適切なアプローチは？ SLO = Service Level Objective : サービスの品質に関する目標値 1. 過去3ヶ月のGreat White Friday実績値をベースに設定 2. ユーザーフィードバックに基づく設定 3. 競合他社のベンチマークに基づく設定 4. カートから決済までの離脱率に基づく設定
49. ベストプラクティス • 目標設定プロセス ◦ データに基づく現実的な目標 ◦ 段階的な改善目標の設定 ◦ 定期的な見直しサイクル • エラーバジェット ◦ サービス重要度による配分 ◦ 季節変動の考慮 ◦ インシデント影響の評価
50. 質問（手を挙げてご意見ください！） 各チームの品質指標を統合したダッシュボードを作るとしたら あなたはどのような項目を重視しますか？ • Shark Pod（商品管理チーム） • Hammerhead Squad（決済システムチーム） • Ray Team（UI/UXチーム） • Deep Sea Team（インフラチーム） • Blue Ocean Team（データ分析チーム）
51. ベストプラクティス • モニタリング実装 ◦ リアルタイムSLO達成状況 ◦ トレンド分析と予測 ◦ チーム別のスコアカード • レポーティング ◦ 経営層向けサマリー ◦ チーム向け詳細分析 ◦ 改善施策の効果測定