全AWSエンジニアに捧ぐ、CloudWatch 設計・運用虎の巻 / CloudWatch design and operation bible

by iselegant

Slide 1

Slide 1 text

2023-05-29 新井雅也、馬勝淳史全AWSエンジニアに捧ぐ、 CloudWatch 設計・運用虎の巻

Slide 2

Slide 2 text

新井雅也 M a s a y a A R A I msy78 ・某大手SI企業に所属・金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当・好きな技術・サービスはECS, Fargate, App Runner, Kubernetes, Golang, Rust, Pulumi テックリード /アーキテクト馬勝淳史 Atsushi UMAKATSU HorseVictory PdM / フロントエンジニア・某大手SI企業に所属・金融セグメントの顧客への設計、開発、ビジネス提案、 UI/UX検討などにも従事・好きな技術・サービスはCDK, ECS, Fargate, TypeScript

Slide 3

Slide 3 text

⚠ おことわり ⚠ u本発表は登壇者らの著書「CloudWatch[本格]入門」の内容をもとに、追加・修正した内容となっています。 u2023年5月29日時点の内容に基づき作成しています。 u可能な限り正確な内容を記載するように努めていますが、内容に関して保証するものではありません。

Slide 4

Slide 4 text

2023-05-29 新井雅也、馬勝淳史全AWSエンジニアに捧ぐ、 CloudWatch 設計・運用虎の巻

Slide 5

Slide 5 text

2023-05-29 新井雅也、馬勝淳史全AWSエンジニアに捧ぐ、 CloudWatch 設計・運用虎の巻？

Slide 6

Slide 6 text

虎の巻とは？

Slide 7

Slide 7 text

虎の巻とは？虎の巻（とらのまき）は、門外不出の秘伝が書かれている書。転じて、教科書などに対する解説書のことも指す。一部引用：https://ja.wikipedia.org/wiki/%E8%99%8E%E3%81%AE%E5%B7%BB

Slide 8

Slide 8 text

虎の巻とは？虎の巻（とらのまき）は、門外不出の秘伝が書かれている書。転じて、教科書などに対する解説書のことも指す。一部引用：https://ja.wikipedia.org/wiki/%E8%99%8E%E3%81%AE%E5%B7%BB CloudWatchに関するオンラインドキュメント（=教科書）の内容に対し、本発表（=解説書）を通して設計・運用観点における理解を深めていただく

Slide 9

Slide 9 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E

Slide 10

Slide 10 text

AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ（「Building Block」と呼ばれる思想）

Slide 11

Slide 11 text

AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ（「Building Block」と呼ばれる思想）自律的に開発しやすい環境が提供される中、チームの裁量やビジネス成長によるシステム拡張が進むとどうなるか？

Slide 12

Slide 12 text

システム拡張に伴い、当然ながら運用の複雑性は増していく

Slide 13

Slide 13 text

サービス追加

Slide 14

Slide 14 text

サービス追加

Slide 15

Slide 15 text

クライアント側でリクエストエラーどこで何が発生しているか？システム拡張に伴い、当然ながら運用の複雑性は増していくエラーの影響範囲は？

Slide 16

Slide 16 text

Slide 17

Slide 17 text

AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ（「Building Block」と呼ばれる思想）自律的に開発しやすい環境が提供される中、チームの裁量やビジネス成長によるシステム拡張が進むとどうなるか？・サービス(=ブロック)の数が肥大化する・サービス間の接続が増し、システム内の相互関係が複雑化する・故に、障害原因や影響範囲の特定が困難になりやすい

Slide 18

Slide 18 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴うシステムの複雑化・分散化

Slide 19

Slide 19 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E uIT運用におけるSWEのアプローチ uシステムの信頼性を維持しつつも、運用を改善するために必要なタスクを行う e.g. モニタリング、変更管理、インシデント対応、キャパシティ計画

Slide 20

Slide 20 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴うシステムの複雑化・分散化信頼性維持と運用改善

Slide 21

Slide 21 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴うシステムの複雑化・分散化信頼性維持と運用改善どうやって両立する?

Slide 22

Slide 22 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴うシステムの複雑化・分散化信頼性維持と運用改善オブザーバビリティの重要性どうやって両立する?

Slide 23

Slide 23 text

オブザーバビリティ(Observability)

Slide 24

Slide 24 text

オブザーバビリティ(Observability) いつ、どこで、なにが起こっているのか、システムの状態を把握できる能⼒・状態のこと日本語では「可観測性」と訳される。また、observabilityの最初の「o」と最後の「y」以外の単語数で短縮して「o11y」と表現されることもある。

Slide 25

Slide 25 text

΋ͱ΋ͱ͸ɺ੍ޚ޻ֶͷ෼໺ʹ͓͍ͯɺ ʮ֎෦ग़ྗͷ৘ใΛجʹγεςϜ಺෦ঢ়ଶΛਪఆ͢ΔͨΊͷࢦඪʯͱͯ͠ར༻͞Ε͍ͯͨɻ 引用. https://www.sciencedirect.com/science/article/pii/S1474667017700948

Slide 26

Slide 26 text

Ref. https://www.dynatrace.com/ja/gartner-magic-quadrant-for- application-performance-monitoring-observability/ オブザーバビリティ実現を支える主要なサービス

Slide 27

Slide 27 text

Ref. https://www.dynatrace.com/ja/gartner-magic-quadrant-for- application-performance-monitoring-observability/ オブザーバビリティ実現を支える主要なサービス

Slide 28

Slide 28 text

Slide 29

Slide 29 text

AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴うシステムの複雑化・分散化信頼性維持と運用改善オブザーバビリティの重要性

Slide 30

Slide 30 text

CloudWatchのサービススイート

Slide 31

Slide 31 text

CloudWatchのサービススイート

Slide 32

Slide 32 text

CloudWatchにおける各サービスの責務

Slide 33

Slide 33 text

CloudWatchにおける各サービスの責務

Slide 34

Slide 34 text

CloudWatchにおける各サービスの責務

Slide 35

Slide 35 text

CloudWatchにおける各サービスの責務

Slide 36

Slide 36 text

CloudWatchにおける各サービスの責務

Slide 37

Slide 37 text

CloudWatchにおける各サービスの責務

Slide 38

Slide 38 text

CloudWatchにおける各サービスの責務

Slide 39

Slide 39 text

CloudWatchにおける各サービスの責務

Slide 40

Slide 40 text

CloudWatchにおける各サービスの責務今回の発表で取り上げるサービス今回の発表で取り上げるサービス

Slide 41

Slide 41 text

CloudWatch メトリクスの設計・運用虎の巻

Slide 42

Slide 42 text

CloudWatchにおける各サービスの責務再掲

Slide 43

Slide 43 text

CloudWatchメトリクス AWS 上の多様なワークロードにおける測定可能なデータポイントの集合 u時系列のデータとして集計され、時刻と値を保持 uメトリクス情報を保存可能なAWSサービスは多岐に渡る u「名前空間」、「ディメンション」、「メトリクス」の3要素で構成

Slide 44

Slide 44 text

CloudWatchメトリクスの概要

Slide 45

Slide 45 text

CloudWatchメトリクスの概要メトリクスにおける論理的なグループ生成されたメトリクスは必ずいずれかの名前空間に分類される

Slide 46

Slide 46 text

CloudWatchメトリクスにおける名前空間

Slide 47

Slide 47 text

CloudWatchメトリクスの概要

Slide 48

Slide 48 text

CloudWatchメトリクスの概要メトリクスを特定するための識別子。分析する際の切り口・粒度。

Slide 49

Slide 49 text

CloudWatchメトリクスの概要

Slide 50

Slide 50 text

CloudWatchメトリクスのディメンション

Slide 51

Slide 51 text

CloudWatchメトリクスの概要

Slide 52

Slide 52 text

CloudWatchメトリクスの概要

Slide 53

Slide 53 text

CloudWatchメトリクスにおけるデータポイントの保持期間時間経過について、メトリクス値は間引きされていく

Slide 54

Slide 54 text

CloudWatchメトリクス設計・運用上の注意点 p 15ヶ月以上メトリクスを保持する場合はMetric Streamsで保存が可能 p 利用者によるメトリクスの削除がサポートされていない p CloudWatch Metrics Insightsでクエリ可能なデータは直近3時間まで設計運用運用

Slide 55

Slide 55 text

設計修正する CloudWatchメトリクス設計・運用上の注意点 15ヶ月以上メトリクスを保持する場合はMetric Streamsで保存が可能 u 別途、料金が発生するため要注意 u データポイント間隔が短いメトリクスは料金が肥大化しがちなので、適切にフィルタする

Slide 56

Slide 56 text

u 15ヶ月保持された後に勝手に削除されていく動き u 検証用途でゴミリソースを大量に作成すると、環境が汚れることがあるため注意 u メトリクスの保存料金は発生しない運用 CloudWatchメトリクス設計・運用上の注意点利用者によるメトリクスの削除がサポートされていない

Slide 57

Slide 57 text

運用 CloudWatchメトリクス設計・運用上の注意点 CloudWatch Metrics Insightsでクエリ可能なデータは直近3時間まで u SQLライクな構文でメトリクスをグラフ化できる機能 u ユースケースとしては、リアルタイム分析・検索用途

Slide 58

Slide 58 text

CloudWatch Logsの設計・運用虎の巻

Slide 59

Slide 59 text

CloudWatchにおける各サービスの責務再掲

Slide 60

Slide 60 text

CloudWatch Logs AWS上でワークロードを運用する際に発生するログの保存が可能なサービス u各種フィルタにより、ログの加工・保存・モニタリングに応用可能 u「アプリケーションログ」と「AWSサービスログ」 u「ログイベント」、「ログストリーム」、「ロググループ」の3要素で構成

Slide 61

Slide 61 text

CloudWatch Logsの概要

Slide 62

Slide 62 text

CloudWatch Logsの概要

Slide 63

Slide 63 text

CloudWatch Logsの概要アプリケーションやAWSサービスから出力されたログ内容。レコード単位で記録される。複数のログストリームをまとめたもの。多くのケースではアプリケーションや各AWSサービスの定義単位でグルーピングされる。同じソース上から出力された複数のログイベントを束ねたもの。

Slide 64

Slide 64 text

CloudWatch Logsの概要ロググループとログストリームの関係は 1:N ログストリームとログイベントの関係は 1:N

Slide 65

Slide 65 text

CloudWatch Logsの概要

Slide 66

Slide 66 text

CloudWatch Logs 設計・運用上の注意点 p サブスクリプションフィルターの制約 p ロググループの分離に関する判断 p ログ取り込みと保存に関する考慮設計設計運用

Slide 67

Slide 67 text

CloudWatch Logs 設計・運用上の注意点サブスクリプションフィルターの制約設計 u クォータ制約として、1ロググループあたり2つまで u クォータ変更はできない u 条件の集約など、ログ出力内容も要考慮 u 文字列フィルタリングに正規表現が利用できない u 独自構文で記述が必要 u 「正規表現でやれることは実現できる」と勘違いしない

Slide 68

Slide 68 text

CloudWatch Logs 設計・運用上の注意点ロググループの分離に関する判断設計 u 分離の粒度は開発者次第であるが、以下のような検討軸で判断すると良さげ u アプリケーションの種別 u 保存ライフサイクルの違い u アラーム単位（サブスクリプションフィルタ数の制約を考慮） u 暗号化要件の有無

Slide 69

Slide 69 text

CloudWatch Logs 設計・運用上の注意点ログ取り込みと保存に関する考慮運用 u CloudWatch Logsは取り込み自体にもコストが発生する u デバッグログの吐き出しなどは要注意 u W-A観点から、保存要件とコストを考慮して保存期間を見直す方が良い u 保存コスト観点では、S3(標準ストレージクラス)と比較すると1.3倍ほど高額 u AWSサービスによっては、ロググループが自動生成されるものもある u App Runnerなどは、ランダムなインスタンスIDでロググループが作成 u その他、LambdaやCodeBuildなどのログはデフォルトで無期限保存

Slide 70

Slide 70 text

CloudWatch Container Insightsの設計・運用虎の巻

Slide 71

Slide 71 text

CloudWatchにおける各サービスの責務再掲

Slide 72

Slide 72 text

CloudWatch Container Insights ECS やEKS といったコンテナワークロードのパフォーマンス情報を統合的に分析できるサービス uコンテナの詳細な情報まで取得可能

Slide 73

Slide 73 text

CloudWatch Container Insightsのメカニズム

Slide 74

Slide 74 text

CloudWatch Container Insightsのメカニズム

Slide 75

Slide 75 text

CloudWatch Container Insightsのメカニズム { "Version": "0", "Type": "Task", "TaskId": "7ac4dfba69214411b4783a3b8189c9ba", "TaskDefinitionFamily": "sleep360", : "CpuUtilized": 0.0, "CpuReserved": 10.0, "MemoryUtilized": 0, "MemoryReserved": 10, "CloudWatchMetrics": [{ "Namespace": "ECS/ContainerInsights", "Metrics": [ { "Name": "CpuUtilized", "Unit": "None” }, { "Name": "CpuReserved", "Unit": "None” }, : ], "Dimensions": [ [ "ClusterName” ], [ "ClusterName", "TaskDefinitionFamily” ] ] }] } ECSタスクに関する内容 JSON形式で記述

Slide 76

Slide 76 text

CloudWatch Container Insightsのメカニズム

Slide 77

Slide 77 text

CloudWatch Container Insights 設計・運用上の注意点 p コンピューティング構成によるContainer Insights有効化方法の違い p カスタムメトリクス自動作成に伴う追加コストの考慮設計運用

Slide 78

Slide 78 text

CloudWatch Container Insights 設計・運用上の注意点コンピューティング構成によるContainer Insight有効化の違い設計 u コントロールプレーン(ECS or EKS)、データプレーン(EC2 or Fargate)の違いで手順が異なる u データプレーンがEC2の場合、追加設定が必要なイメージ ECS on EC2 構成 EKS on EC2 構成 ECS on Fargate 構成 EKS on Fargate 構成

Slide 79

Slide 79 text

CloudWatch Container Insights 設計・運用上の注意点カスタムメトリクス自動作成に伴う追加コストの考慮 u 内部的に作成されるカスタムメトリクスは一つあたり 0.30 USD(*1) が発生運用 (*1) アジアパシフィック(東京)における、最初の 10000メトリクスのコスト (*2) AWSドキュメント(https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-reference-performance-logs-ECS.html)記載のパフォーマンスログサンプルのメトリクス数は8つだが、2022年11月18日にサポートされたストレージ利用モニタリングにより、エフェメラルストレージ領域のメトリクスが取得できるようになった u コスト発生を極力抑えるためのTipsとして… u 開発環境では無効化、プロダクション環境では有効化など環境ごとに必要性を考慮 u ADOTを利用することで、カスタムメトリクスの送出を制限単位コンポーネント名カスタムメトリクス数 ECSクラスター 3 ECSサービス 5 ECSタスクファミリー 10 (*2) e.g. ECS on Fargate 構成のカスタムメトリクス数

Slide 80

Slide 80 text

X-Rayの設計・運用虎の巻

Slide 81

Slide 81 text

CloudWatchにおける各サービスの責務再掲

Slide 82

Slide 82 text

X-Ray アプリケーションが処理するリクエストに関して、サービスコンポーネントに跨ぐ一連のトレースデータを収集するサービス uアプリケーション内部に組み込んで動作させる u「セグメント」、「トレース」で構成

Slide 83

Slide 83 text

X-Rayの概要

Slide 84

Slide 84 text

X-Rayの概要 X-Ray

Slide 85

Slide 85 text

X-Rayの概要 X-Ray

Slide 86

Slide 86 text

X-Rayの概要 X-Ray

Slide 87

Slide 87 text

X-Rayの概要 X-Ray メトリクスやLogsも含めて全体を可視化

Slide 88

Slide 88 text

X-Rayの概要 X-Ray メトリクスやLogsも含めて全体を可視化

Slide 89

Slide 89 text

X-Ray 設計・運用上の注意点 p コンテナ利用時におけるサイドカー構成・ロール付与・ネットワーク設定 p サポート言語による実装労力の差異 p 料金とパフォーマンス影響を考慮したサンプリング数の実装設計設計運用

Slide 90

Slide 90 text

X-Ray 設計・運用上の注意点コンテナ利用時におけるサイドカー構成・ロール付与・ネットワーク構成設計 u X-Rayはアプリケーションの設定のみならず、周辺系の設定が割と面倒でハマることも多い u 全体感を押さえながら設定していくとベター

Slide 91

Slide 91 text

X-Ray 設計・運用上の注意点サポート言語による実装労力の差異設計 u アプリケーションのプログラミング言語によってX-Ray実装の手間が異なる u JavaはAuto-instrumentation agentによりコード変更なく組み込みが可能 u GolangやJavaScript、TypeScript等はテレメトリデータを取得する箇所ごとにコーディングが必要

Slide 92

Slide 92 text

X-Ray 設計・運用上の注意点料金とパフォーマンス影響を考慮したサンプリング数の実装運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録

Slide 93

Slide 93 text

Slide 94

Slide 94 text

X-Ray 設計・運用上の注意点料金とパフォーマンス影響を考慮したサンプリング数の実装運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録 1秒 1秒 1秒 1秒 e.g. 毎秒200件リクエストが発生するケース・・・最初のリクエスト(=1件) それ以降のリクエスト(=199件)の5%を取得 →199 ×0.05 = 9.95件 u リザーバサイズと固定レートを調整して自分たちのシステム特性に併せたサンプリング数を設定する ⇨リザーバサイズで調整可能 ⇨固定レートで調整可能

Slide 95

Slide 95 text

Slide 96

Slide 96 text

まとめ

Slide 97

Slide 97 text

まとめ S R E ビジネス拡大に伴うシステムの複雑化・分散化信頼性維持と運用改善オブザーバビリティの重要性

Slide 98

Slide 98 text

まとめ

Slide 99

Slide 99 text

まとめ・15ヶ月以上メトリクスを保持はMetric Streams ・利用者によるメトリクスの削除がサポート外・CloudWatch Metrics Insightsは直近3時間のデータ・構成によるContainer Insights有効化方法の違い・カスタムメトリクスに伴う追加コストの考慮設計運用運用設計運用・コンテナ利用時に求められるアーキテクチャ・サポート言語による実装労力の差異・サンプリング数の考慮設計設計運用・サブスクリプションフィルターの制約・ロググループの分離に関する判断・ログ取り込みと保存に関する考慮設計設計運用

Slide 100

Slide 100 text

その他のサービスはCloudWatch[本格]入門で解説しています！ https://booth.pm/ja/items/4130172

Slide 101

Slide 101 text

Thank you!