Upgrade to Pro — share decks privately, control downloads, hide ads and more …

JAWS-UG 情シス支部 第31回 クラウド女子会×札幌支部コラボ会 チョークトーク Clo...

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

Avatar for Naomi Yamasaki

Naomi Yamasaki

May 24, 2025
Tweet

More Decks by Naomi Yamasaki

Other Decks in Technology

Transcript

  1. チョークトークの進め方 • チョークトークとは対話型のセッションで学校の授業やゼミに近いものです • 途中、投票型の質問と発言型の質問があります ◦ 投票型 ▪ スライドに投影された選択肢の中から選択していただきます ▪

    ご自身の考えに最も近いものに手を挙げてください ◦ 発言型 ▪ 質問について発言したい方は手を挙げてください • チョークトークはクイズではないので正解も不正解もありません • 積極的に発言と議論をして、みんなで知見の共有をしましょう!
  2. 申込時アンケート結果 CloudWatchやモニタリングについての困りごとや悩み事はありますか? • Platform Engineeringとしてどうやってセルフサービスを提供できるか悩んでいる • よくわかっていないのが悩み事 • マネコンが見づらい •

    Datadogに任してるので特にない... • モニタリング対象の選定基準が分からない。他サービスとの連携例が思い浮かばない。 • 良く聞く単語ですが、アプリケーションエンジニアですので(言い訳)、いまいちはっきりと概念や ユースケースを理解できておらず・・・。 • CloudWatchLogsで集積したあとのワードによるアラーム設定の難解さ • CloudWatchの仲間が増え過ぎて追い切れてない • alert通知たくさんで埋もれる • 適切なしきい値を知りたい • 費用がそこそこかかる • モニタリングに割く時間がなかなか取れない ^^; • どこまでログって処理しているの?
  3. 申込時アンケート結果 CloudWatchについてどのようなことを知りたいですか? • 各機能の使い分けなど • 直近のアップデートをキャッチアップできていないのでどのような機能が増えているのか • よくわかってないので改めて勉強したいです • ログ収集の目的にしか使用しておらず、本来できる事の多くはできていない(機能を全然使い切れて

    いない)ので、色々なTipsなどを知るきっかけになれば • CloudWatch Logs の効率的な運用方法 • Datadogとの比較とか、Datadog使わなくてもCloudWatchだけでもいけるよー的な? • CloudWatchで集めたログ(監査ログ)等を加工して通知する様な仕組みを使うような事例 • 基本的なことを知ることができればと思います。 • どこまでCloudWatchで対応しているか(3rdPartyツールとの使い分けの境界) • 自動復旧等、洗練された使い方 • みなさんがどのように使っているのかを知りたいです • ログの見方
  4. 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テストや段階的なロールアウトを管理
  5. 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 セキュリティ関連の監視を統合
  6. 想定企業とシステムについて • 企業名:SharkCart株式会社(SharkCart, Inc.) • 企業理念:「速く、力強く、絶え間ない進化」(Fast, Powerful, Ever-evolving) • 事業内容:ECサイト運営(アパレル、雑貨、食品等)

    • 売上規模:年商300億円 • ユーザー数:月間アクティブユーザー100万人 • 本社所在地:JR池袋駅徒歩10分(サメが輝く水族館の近く) 企業の特徴 • 社名の由来:大きな口を開けて獲物を捕らえるサメのように、 幅広い商品をワンストップで提供する • マスコットキャラクター:「フィンちゃん」 • 企業カラー:シャークブルー(#1B4B65)
  7. SharkCartのシステム構成 • フロントエンド:CloudFront + React • バックエンド:ECS on EC2(マイクロサービス構成) •

    データベース:Aurora MySQL • キャッシュ:ElastiCache for Redis • 画像/動画ストレージ:S3 • 検索エンジン:OpenSearch Service • その他:SQS(非同期処理)、EventBridge(バッチ処理)
  8. SharkCartのセール体系 冬のセール Great White Friday(年1回) • 時期:11月最終金曜日(従来のブラックフライデーに相当) • 特徴:年間最大の割引率、最大の商品数 •

    規模:年間最大のトラフィック、売上 定例セール Shark Sunday(毎月開催) • 時期:毎月第2日曜日 • 特徴:カテゴリー別の特別割引 • 規模:通常の2-3倍のトラフィック
  9. 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倍
  10. ベストプラクティス • 多層的な監視設定 ◦ インフラ指標とアプリケーション指標の組み合わせ ◦ 複合アラームによる誤検知防止 ◦ 段階的なアラート閾値(警告→重要→緊急) •

    スケーリングポリシー ◦ ターゲット追跡スケーリングの活用 ◦ スケールアウトの閾値は余裕を持って設定 ◦ クールダウン期間の適切な設定
  11. ベストプラクティス • プロアクティブな対応 ◦ 予測可能なイベント前の事前スケーリング ◦ 段階的なキャパシティ増強 ◦ 自動スケーリングの補助的な活用 •

    自動化のアプローチ ◦ EventBridgeによるスケジュール実行 ◦ Systems Managerの自動化 ◦ Step Functionsによる複雑なワークフロー制御
  12. ベストプラクティス • バッチ監視の基本設定 ◦ 実行開始・終了のログ記録 ◦ 処理件数のメトリクス化 ◦ 実行時間の監視と閾値設定 •

    異常検知の仕組み ◦ 前回実行との差分チェック ◦ 業務的な妥当性確認 ◦ データ整合性の自動検証
  13. ベストプラクティス • ログ設計のポイント ◦ 構造化ログの採用 ◦ エラー重要度の明確な分類 ◦ トレーサビリティの確保 •

    自動リカバリー ◦ エラー時の再実行条件定義 ◦ デッドレターキューの活用 ◦ 手動介入ポイントの明確化
  14. ベストプラクティス • 自動対応の実装 ◦ WAFルールの動的更新 ◦ セキュリティグループの自動制御 ◦ インシデント情報の自動集約 •

    インシデント管理 ◦ Security Hubでの一元管理 ◦ ChatOpsによる即時共有 ◦ インシデント対応の文書化と改善
  15. ベストプラクティス • ログ管理の最適化 ◦ ログレベルの適切な設定(INFO/WARN/ERROR) ◦ ログ保持期間のポリシー策定 ◦ サンプリングルールの導入 •

    メトリクス収集の効率化 ◦ 必要最小限のメトリクス定義 ◦ 収集間隔の最適化 ◦ 集約メトリクスの活用
  16. ベストプラクティス • コスト可視化 ◦ リソースタグによる費用分析 ◦ チーム別コストダッシュボード ◦ 予算アラートの設定 •

    運用プロセス ◦ 定期的な使用状況レビュー ◦ 不要リソースの特定と削除 ◦ コスト効率の定期評価
  17. 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倍
  18. Deep Blue Sale - SharkCartの夏季限定の大規模セール システム負荷要因 1. タイムセール開始時の瞬間的なアクセス集中 2. レベル変更時の商品価格一斉更新

    3. 在庫数リアルタイム同期 4. SharkFin Members認証の集中 監視ポイント 1. フロントエンド ◦ SharkCart GOアプリの応答性 ◦ 商品検索機能のレスポンス 2. バックエンド ◦ 価格更新バッチの処理状況 ◦ 在庫同期の整合性 3. インフラ ◦ オートスケーリングの効果 ◦ キャッシュヒット率
  19. ベストプラクティス • 分散トレーシング ◦ サービス間の依存関係の可視化 ◦ パフォーマンスボトルネックの特定 ◦ エラー伝播の追跡 •

    統合モニタリング ◦ メトリクス・ログ・トレースの相関 ◦ エンドツーエンドの可視性確保 ◦ ユーザー体験の定量化
  20. 質問(投票です!) サービス依存関係が複雑化しているDeep Blue Saleでの トラブルシューティングを効率化するために、最も重要な観点は? 1. Shark Pod(商品管理チーム) から Hammerhead

    Squad(決済システムチーム)まで の依存関係の可視化 2. SharkFin Members認証からカート決済までのエラー伝播追跡 3. Great White Friday対策で改善したボトルネックの特定 4. SharkCart GOアプリユーザーへの影響範囲の定量化
  21. ベストプラクティス • トラブルシューティング ◦ 共通のコンテキスト情報付与 ◦ サービスマップの自動生成 ◦ 影響範囲の即時把握 •

    パフォーマンス分析 ◦ レイテンシーの詳細分析 ◦ ボトルネックの自動検出 ◦ リソース使用率の相関分析
  22. ベストプラクティス • データ相関 ◦ トレースIDによる紐付け ◦ タイムスタンプの正規化 ◦ メタデータの標準化 •

    可視化戦略 ◦ 目的別ダッシュボード ◦ リアルタイムモニタリング ◦ トレンド分析の自動化
  23. 質問(投票です!) SharkMart(ECサイト)のSLIとして最も重要な指標は? SLI = Service Level Indicator : サービス品質を定量的に測定するための指標 1.

    商品検索APIのレイテンシー 2. 決済処理の成功率 3. モバイルアプリのページロード時間 4. カート機能の可用性
  24. ベストプラクティス • SLI選定基準 ◦ ユーザー体験との直接的な関連性 ◦ 測定の容易さと正確性 ◦ ビジネスインパクトの大きさ •

    測定方法 ◦ エンドポイントごとの詳細測定 ◦ ユーザーセグメント別の分析 ◦ 地域・デバイス別の傾向把握
  25. 質問(投票です!) Shark Quality Score(SLO)の設定方法として適切なアプローチは? SLO = Service Level Objective :

    サービスの品質に関する目標値 1. 過去3ヶ月のGreat White Friday実績値をベースに設定 2. ユーザーフィードバックに基づく設定 3. 競合他社のベンチマークに基づく設定 4. カートから決済までの離脱率に基づく設定
  26. ベストプラクティス • 目標設定プロセス ◦ データに基づく現実的な目標 ◦ 段階的な改善目標の設定 ◦ 定期的な見直しサイクル •

    エラーバジェット ◦ サービス重要度による配分 ◦ 季節変動の考慮 ◦ インシデント影響の評価
  27. ベストプラクティス • モニタリング実装 ◦ リアルタイムSLO達成状況 ◦ トレンド分析と予測 ◦ チーム別のスコアカード •

    レポーティング ◦ 経営層向けサマリー ◦ チーム向け詳細分析 ◦ 改善施策の効果測定