こんにちは、AWSチームの大澤です。
今回は、5/29 (月)に行われた、JAWS-UG SRE支部 #6 に参加してきましたので、
そちらのレポートをしたいと思います。
イベント概要
日時: 2023/05/29(月) 19:00 〜 21:00
場所: AWS Japan 目黒オフィス 目黒セントラルスクエア 21F 東京都品川区上大崎3-1-1
テーマ
CloudWatchでどこまでいけるか選手権！
SREの仕事は監視だけではなく、障害対応、インフラ構築、 CI/CDパイプライン作成、E2Eテスト実行基盤など様々だと思います。 普段の仕事にどこまでCloudWatchを活かせるか、 最新のCloudWatchのサービス拡充をキャッチアップしつつ一風変わった使い方を考えましょう！
関連するサービスの例
CloudWatch Metrics Logs XXX Insights Alarm Dashboard Internet Monitor Synthetics RUM
JAWS-UG SRE支部 #6 | commpass より引用
Speaker
- SRE支部 みのるん さん
- SRE支部 ふるや さん
- アマゾンウェブサービスジャパン合同会社 津郷 光明 さん
- アライとウマカツ さん
- SREホールディングス 釜田 康平 さん
- クラウドセントリック 角中 源太郎 さん
- k.goto さん
- 株式会社キャンサースキャン 保坂 将平 さん
Youtube
Youtube上でアーカイブ動画としてご覧いただけます。
レポート
アイスブレイクLT SRE支部 ふるや @saramune
- 登壇・LTやっていますか？
- 感謝・感想していますか？
- twitterなどで発信しよう
- なぜ感謝を伝えるべきか
- 話す側は褒められると嬉しい
- アンケートでコメントお願いします！
「エンジニアリングで運用を改善する」ためのAmazon CloudWatch活用 アマゾンウェブサービスジャパン合同会社 津郷 光明
津郷 光明さん 自己紹介
- 製造業のお客様を中心にサポートされている
- 運用&devops系サービスの推進
- Observability / IaC
SREとは
- Site Reliability Engineering
- (ソフトウェア) エンジニアリングでサービスを改善する
- 可用性・レイテンシ・パフォーマンス e.t.c
- サービスの信頼性・品質に責任を持つ
- Site Reliability Engineering
なぜモニタリング・おフザーバビリティが必要か
- 状態を把握でき、共通理解を得られる・判断につながる
- 障害の検知、対応の効率化につながる
- 特定の状態をパターン化することができ、自動化につながる
サービス状態や実際の利用状況をモニタリングする
- 従来のインフラの範囲のみのモニタリングではカバーできない
- インフラに限定せずにアプリケーションまで含めて、サービスを ”総合的に" 評価する必要がある
Amazon Cloudwatchでサービスを総合的にモニタリング
- コンソール上からで19種類ある！
- モニタリング・オブザーバビリティの機能を網羅的に提供
サービスの品質・信頼性に向けてモニタリングすべき対象
- 絶対の解はない
モニタリングの例
- スコープを切ってモニタリングし、品質・信頼性を積み上げる
- 提供サービスの正常性確認
- サービス状態を提供側の環境から継続的にテストし、提供するサービスの品質・信頼性をモニタリングする
- CloudWatch Synthetics
- Canaryを使用し。、24/365、ユーザ体験を模擬した継続的な監視
- 6種類のblueprintがあり、基本的な用途であればコーディング不要
- マイクロサービスにおける確認
- 障害原因の特定やパフォーマンスボトルネック特定は難しい一方で、サービス全体の性能・品質に影響を与える可能性がある
- CloudWatch ServiceLens
- X-Raxと連動し、サービス間の依存関係や、レイテンシ、レスポンス状態について視覚的に把握することが可能
- 通信経路がユーザに与える影響
- インターネットが与える影響
- インターネットの影響をモニタリングし、ユーザのエクスペリエンスを向上させる
- CloudWatch Internet Monitor
- インターネットの問題が、パフォーマンスや可用性にどのように影響しているかを可視化
- 2023/02/28に一般提供開始
- インターネットが与える影響
- ユーザビリティーの確認
- ユーザ視点でのレイテンシー、エラー
- 実際のユーザの利用状況・データをモニタリングし、環境差異による影響は想定していない、問題の早期発見、改善検討につなげる
- CloudWatch RUM
- アプリのパフォーマンスに関するクライアントサイドのデータをリアルタイムで取得
- webバイタルデータを始め、ブラウザー統計やユーザ挙動の可視化・分析のためのダッシュボードを提供
- ユーザ視点でのレイテンシー、エラー
- 一歩踏み込んだ、品質・信頼性の確認、分析
- 外形監視やリアルタイムユーザモニタリングでは把握できない粒度で、詳細なユーザ影響の分析が重要
- CloudWatch Contributor Insights
- ログを解析し、誰あるいは何が、システムやアプリケーションのパフォーマンスに影響を及ぼしているのか確認可能
- Metric Math
- METRICS関数、基本的な算術関数を始めとした関数をサポート
- CloudWatch Contributor Insights * Metric Math
- リクエストエラーとなったクライアントの割合を算出する
- CloudWatch Logs メトリクスフィルタ
- CWLogsをフィルタしてメトリクスにパブリッシュ
まとめ
- SREはサービスの信頼性、品質に責任を持つ
- 品質をモニタリングし、定量的にサービスの状態を表すことが重要
- CWはシステムを総合的にモニタリングする機能を有する
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 アライとウマカツ
- 虎の巻？
- AWSとSREの観点から眺めるCloudWatchの重要性
- AWS
- 220以上のサービスを提供
- 自分たちの課題解決に必要なサービスを組み合わせ
- システム拡張に伴い、複雑性が増していく
- SRE
- IT運用におけるSWEのアプローチ
- 信頼性を維持しつつ、運用を改善していく手法
- AWS
- AWSとSREの観点から眺めるCloudWatchの重要性
どうやって両立させるか？
- オブザーバビリティ
- いつでも・どこでもシステムの状態を把握できる能力・状態のこと
- 本日はCloudWatchが主役
- オブザーバビリティ
CloudWatchメトリクス運用の虎の巻
- AWS上の多様なワークロードにおける測定可能なデータポイントの集合
- CWメトリクス
- AWS名前空間
- カスタム名前空間
- ディメンション
- メトリクスを特定するための識別子
- データポイントの保持期間
- 時間経過について、メトリクス値は間引きされていく
- CWメトリクス
- 注意
- 設計: 15ヶ月以上、保持する場合はMetic Streamsで保存が可能
- 料金が肥大化しがちなので、適切にフィルタすることが重要
- メトリクスの削除出来ない
- 15ヶ月立つと勝手に消える
- CW Metics Insights
- 直近3時間までのデータ
- あくまでもリアルタイム
- 設計: 15ヶ月以上、保持する場合はMetic Streamsで保存が可能
- AWS上の多様なワークロードにおける測定可能なデータポイントの集合
Logsの虎の巻
- AWSでワークロードを運用する際に、ログの保存が可能なサービス
- 概要
- ロググループ
- 識別するための枠組み
- ログストリーム
- ログイベントを束ねたもの
- ログイベント
- ログの中身。レコード単位で記録 - 注意点
- サブスクリプションフィルターの制約
- 1ロググループ当たり2つまで
- クォータ変更はできない
- 正規表現が利用できない
- 独自構文で記述が必要
- 1ロググループ当たり2つまで
- ロググループの分離について
- 分離の制度は開発者次第
- アプリの種別
- 保存ライフサイクルの違い
- アラームの単位
- 分離の制度は開発者次第
- ログの取り込みと保存の考慮
- 取り込み自体にもコストが発生
- 保存期間を見直しが必要
- LamdaやCodeBuildのログはデフォルトで無期限保存
- ロググループ
CloudWatch Container Insightsの虎の巻
- コンテナサービスのパフォーマンス可視化ができるサービス
- パフォーマンスログ(json)
- 注意点
- コンピューティング構成による有効化の違い
- コントロールプレーン・データプレーンによって手順が異なる
- ECs on EKS なのか EC2 or Fargate
- コントロールプレーン・データプレーンによって手順が異なる
- カスタムメトリクス自動作成に伴う追加コスト
- 1つあたり0.30USDが発生する
- 環境ごとに必要性を考慮
- ADOTを利用することで、カスタムメトリクスの送出を制限
- コンピューティング構成による有効化の違い
- コンテナサービスのパフォーマンス可視化ができるサービス
X-rayの虎の巻
- アプリケーションが処理するリクエストに対して、アプリの一連のトレースデータを収集するサービス
- 注意点
- コンテナ利用時において、サイドカー構成ロール付与・ネットワーク構成
- アプリ設定のみならずシステムの全体を抑えながら設定する
- サポート言語による実装労力
- javaはコード変更なく可能
- 料金とパフォーマンスを考慮したサンプリング数の実装
- 1秒ごとに最初のリクエストを記録、以降は5%ずつ記録
- リザーバサイズと固定レートを調整して、自分たちのシステム特性に合わせてサンプリング数を設定
- コンテナ利用時において、サイドカー構成ロール付与・ネットワーク構成
Amazon CloudWatch Syntheticsで始める外形監視 SREホールディングス 釜田 康平
- とあるシステムの話
- よくある2層構造のアーキテクチャー
- 機能追加によるメンテ作業実施後
- ALBのHealthyHtCountの数も正常、監視アラートなしであったが、利用ユーザからサービスページを確認できない状態になった
- 切り戻しの際に設定する優先度を間違えてしまったために、社外からのアクセスがメンテナンスページにリダイレクトされる状態のままになっていた
- 作業後の確認が甘いこともあったが、ユーザ目線での監視、合成監視ができていなかった
- なぜか
- チェックボックス監視になっていた
- PoCレベルのシステムのため、できればThrid Partyツールを利用せずにAWS内で合成監視を実現したかった
- CW Synthetics
- サービスにアクセスしてパフォーマンスやサービスを把握する
- Canary(Lambda)を作成して合成監視を実現する
- 自前でスクリプトを用意して、ログイン後ページの表示まで定期的な合成監視を実施できるようにした
- 期待しない画面が表示されない場合はアラート
- CW RUM
- 実際のユーザアクセスの情報を取得・計測する
- まとめ
- チェックボックス監視にならないようにする
CloudWatchでバレる「君、仕事中にyo〇tube観てたよね？」 クラウドセントリック 角中 源太郎
- AWS Summit Tokyoで始まった勘違い
- CW Internet Monitorに関するセッションで、ファイバーの切断によってパケットロスに関することを聞いて、物理の断線も検知できるのではと思った
- 業務PCにCW Agentを入れれば様々なログなどを検知できるのでは？
- PCにCloudWatch Agentを入れてみた
- Chromeのブラウザ履歴
- SQLite形式をサポートしていない
- CloudWatch Agent on PC は業務端末なら選択肢の1つ
- Chromeのブラウザ履歴
- PCにCloudWatch Agentを入れてみた
- CW RUM
- 1ユーザだけユーザ体験がおかしいことをRUMでわかり、Agentで詳細原因がわかる
CloudWatch複合アラームでELBの5XXをいい感じに検知しようとしたらうまくいかなかった話 k.goto
- いい感じ？
- ALBのエラー通知をしたい
- ステータス通知したい
- 重複通知を排除したい
- CW複合アラームを使ってみた
- CW複合アラーム
- 複数条件を組み合わせてアラームを設定できる
- 500,2,3,4,でない5xxのときに通知するはず
- 1件の503エラーに対して、複合アラームも503アラームも両方通知されてしまった
- よく見てみた
- 5xxが先に発火し、その後503が発火した
- 5xxが先に発火して、500,2,3,4などのアラームになるのか？
- そうではなさそう
- 発火＝評価タイミングはアラームを作成した時刻によって違う？
- そうでもなさそう
- 評価タイミングは毎分同じ時間
- アラーム評価タイミングの前後どちらかでエラーが発生するか次第で順番が変わる
- 困る...
- サプレッサーアラームをつかった
- 選択したアラーム状態になると複合アラームのアクション無効になる
- 結果、503だけアラームが来た！
- うまくいった
- ALBのエラー通知をしたい
CloudWatchを個人情報保護の盲点にしないために 株式会社キャンサースキャン 保坂 将平
CW Logsに機密情報はないと言い切れますか？
- CWを含めたデータのライフサイクルの整理
- 必要なログは残しつつ、機密情報は排除するためのマスキングや加工
キャンサースキャン社のご紹介
- 健康データを利用し、予防行動を促す事業を展開
- 健康保険の診療補修データを分析して、受診すすめるなどをしている
- 要件: 自由に分析しつつ、適切に機密情報を管理する
- 監査証跡など、必要なログは残す
まずやること: データのライフサイクルの把握
- どこに、何が、いつ、保存・蓄積・活用されているかを見る
- いつ、どうやって削除するべきか
ログ毎にライフサイクルは違う
- 契約終了後に個人情報は削除が必要
- 監査ログは契約終了後にも保存が必要
次にやること: 各ライフサイクルについて
- 用途、コスト・アクセス性を考慮
Sagemaker等のをログで個人情報の保護
- Sagemakerなどはアプリをそのまま監査目的で保存しておきたい
- 案1: data protectionは日本語非対応
- 案2: subscription filterでマスクしたデータをs3に転送して保存
- ログの特定パターンを弾くのであれば有効
- 案3: s3に転送後にすきに加工
削除方法の検討: 暗号化消去を検討する
- NIST-SP-800-88 「媒体のデータ抹消に関するガイドライン」
まとめ
- データのライフサイクルを正確に把握する
- これをやっておけば大丈夫という対策はない
まとめ
JAWS-UG SRE支部は、今回で第6回目の開催となりました。 比較的最近に設立された支部ではありますが、SREにフォーカスしながらAWSを利用した活用方法・ベストプラクティスについて、キャッチアップできるコンテンツが毎回盛りだくさんとなっていて、インプットとして最高な勉強会の1つだと感じました。
