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

Transcript

1. 2023-05-29 新井 雅也、馬勝 淳史 全AWSエンジニアに捧ぐ、 CloudWatch 設計・運用 虎の巻
2. 新井 雅也 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
3. ⚠ おことわり ⚠ u本発表は登壇者らの著書「CloudWatch[本格]入門 」の内容をもとに、 追加・修正した内容となっています。 u2023年5月29日時点の内容に基づき作成しています。 u可能な限り正確な内容を記載するように努めていますが、 内容に関して保証するものではありません。
4. 2023-05-29 新井 雅也、馬勝 淳史 全AWSエンジニアに捧ぐ、 CloudWatch 設計・運用 虎の巻
5. 2023-05-29 新井 雅也、馬勝 淳史 全AWSエンジニアに捧ぐ、 CloudWatch 設計・運用 虎の巻？
6. 虎の巻とは？
7. 虎の巻とは？ 虎の巻（とらのまき）は、門外不出の秘伝が書かれている書。 転じて、教科書などに対する解説書のことも指す。 一部引用：https://ja.wikipedia.org/wiki/%E8%99%8E%E3%81%AE%E5%B7%BB
8. 虎の巻とは？ 虎の巻（とらのまき）は、門外不出の秘伝が書かれている書。 転じて、教科書などに対する解説書のことも指す。 一部引用：https://ja.wikipedia.org/wiki/%E8%99%8E%E3%81%AE%E5%B7%BB CloudWatchに関するオンラインドキュメント（=教科書）の内容に対し、 本発表（=解説書）を通して設計・運用観点における理解を深めていただく
9. AWSとSREの観点から眺めるCloudWatchの重要性 S R E
10. AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ （「Building Block」と呼ばれる思想）
11. AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ （「Building Block」と呼ばれる思想） 自律的に開発しやすい環境が提供される中、 チームの裁量やビジネス成長によるシステム拡張が進むとどうなるか？
12. システム拡張に伴い、当然ながら運用の複雑性は増していく
13. サービス追加
14. サービス追加
15. クライアント側で リクエストエラー どこで何が発生しているか？ システム拡張に伴い、当然ながら運用の複雑性は増していく エラーの影響範囲は？
16. AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ （「Building Block」と呼ばれる思想） 自律的に開発しやすい環境が提供される中、 チームの裁量やビジネス成長によるシステム拡張が進むとどうなるか？
17. AWSとSREの観点から眺めるCloudWatchの重要性 u220以上のサービスを提供 u自分たちの課題解決に必要なサービスの組み合わせ （「Building Block」と呼ばれる思想） 自律的に開発しやすい環境が提供される中、 チームの裁量やビジネス成長によるシステム拡張が進むとどうなるか？ ・サービス(=ブロック)の数が肥大化する ・サービス間の接続が増し、システム内の相互関係が複雑化する ・故に、障害原因や影響範囲の特定が困難になりやすい
18. AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴う システムの複雑化・分散化
19. AWSとSREの観点から眺めるCloudWatchの重要性 S R E uIT運用におけるSWEのアプローチ uシステムの信頼性を維持しつつも、 運用を改善するために必要なタスクを行う e.g. モニタリング、変更管理、 インシデント対応、キャパシティ計画
20. AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴う システムの複雑化・分散化 信頼性維持と運用改善
21. AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴う システムの複雑化・分散化 信頼性維持と運用改善 どうやって両立する?
22. AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴う システムの複雑化・分散化 信頼性維持と運用改善 オブザーバビリティの 重要性 どうやって両立する?
23. オブザーバビリティ(Observability)
24. オブザーバビリティ(Observability) いつ、どこで、なにが起こっているのか、 システムの状態を把握できる能⼒・状態のこと 日本語では「可観測性」と訳される。 また、observabilityの最初の「o」と最後の「y」以外の単語数で短縮して「o11y」と表現されることもある。
25. ΋ͱ΋ͱ͸ɺ੍ޚ޻ֶͷ෼໺ʹ͓͍ͯɺ ʮ֎෦ग़ྗͷ৘ใΛجʹγεςϜ಺෦ঢ়ଶΛਪఆ͢ΔͨΊͷࢦඪʯͱͯ͠ར༻͞Ε͍ͯͨɻ 引用. https://www.sciencedirect.com/science/article/pii/S1474667017700948
26. Ref. https://www.dynatrace.com/ja/gartner-magic-quadrant-for- application-performance-monitoring-observability/ オブザーバビリティ実現を支える主要なサービス
27. Ref. https://www.dynatrace.com/ja/gartner-magic-quadrant-for- application-performance-monitoring-observability/ オブザーバビリティ実現を支える主要なサービス
28. AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴う システムの複雑化・分散化 信頼性維持と運用改善 オブザーバビリティの 重要性 どうやって両立する?
29. AWSとSREの観点から眺めるCloudWatchの重要性 S R E ビジネス拡大に伴う システムの複雑化・分散化 信頼性維持と運用改善 オブザーバビリティの 重要性
30. CloudWatchのサービススイート
31. CloudWatchのサービススイート
32. CloudWatchにおける各サービスの責務
33. CloudWatchにおける各サービスの責務
34. CloudWatchにおける各サービスの責務
35. CloudWatchにおける各サービスの責務
36. CloudWatchにおける各サービスの責務
37. CloudWatchにおける各サービスの責務
38. CloudWatchにおける各サービスの責務
39. CloudWatchにおける各サービスの責務
40. CloudWatchにおける各サービスの責務 今回の発表で 取り上げるサービス 今回の発表で 取り上げるサービス
41. CloudWatch メトリクスの設計・運用 虎の巻
42. CloudWatchにおける各サービスの責務 再掲
43. CloudWatchメトリクス AWS 上の多様なワークロードにおける測定可能なデータポイントの集合 u時系列のデータとして集計され、時刻と値を保持 uメトリクス情報を保存可能なAWSサービスは多岐に渡る u「名前空間」、「ディメンション」、「メトリクス」の3要素で構成
44. CloudWatchメトリクスの概要
45. CloudWatchメトリクスの概要 メトリクスにおける 論理的なグループ 生成されたメトリクスは 必ずいずれかの名前空間に分類される
46. CloudWatchメトリクスにおける名前空間
47. CloudWatchメトリクスの概要
48. CloudWatchメトリクスの概要 メトリクスを特定するための識別子。 分析する際の切り口・粒度。
49. CloudWatchメトリクスの概要
50. CloudWatchメトリクスのディメンション
51. CloudWatchメトリクスの概要
52. CloudWatchメトリクスの概要
53. CloudWatchメトリクスにおけるデータポイントの保持期間 時間経過について、メトリクス値は間引きされていく
54. CloudWatchメトリクス 設計・運用上の注意点 p 15ヶ月以上メトリクスを保持する場合はMetric Streamsで保存が可能 p 利用者によるメトリクスの削除がサポートされていない p CloudWatch Metrics Insightsでクエリ可能なデータは直近3時間まで 設計 運用 運用
55. 設計 修正する CloudWatchメトリクス 設計・運用上の注意点 15ヶ月以上メトリクスを保持する場合はMetric Streamsで保存が可能 u 別途、料金が発生するため要注意 u データポイント間隔が短いメトリクスは料金が肥大化しがちなので、適切にフィルタする
56. u 15ヶ月保持された後に勝手に削除されていく動き u 検証用途でゴミリソースを大量に作成すると、環境が汚れることがあるため注意 u メトリクスの保存料金は発生しない 運用 CloudWatchメトリクス 設計・運用上の注意点 利用者によるメトリクスの削除がサポートされていない
57. 運用 CloudWatchメトリクス 設計・運用上の注意点 CloudWatch Metrics Insightsでクエリ可能なデータは直近3時間まで u SQLライクな構文でメトリクスをグラフ化できる機能 u ユースケースとしては、リアルタイム分析・検索用途
58. CloudWatch Logsの設計・運用 虎の巻
59. CloudWatchにおける各サービスの責務 再掲
60. CloudWatch Logs AWS上でワークロードを運用する際に発生するログの保存が可能なサービス u各種フィルタにより、ログの加工・保存・モニタリングに応用可能 u「アプリケーションログ」と「AWSサービスログ」 u「ログイベント」、「ログストリーム」、「ロググループ」の3要素で構成
61. CloudWatch Logsの概要
62. CloudWatch Logsの概要
63. CloudWatch Logsの概要 アプリケーションやAWSサービスから 出力されたログ内容。 レコード単位で記録される。 複数のログストリームをまとめたもの。 多くのケースではアプリケーションや 各AWSサービスの定義単位でグルーピングされる。 同じソース上から出力された複数の ログイベントを束ねたもの。
64. CloudWatch Logsの概要 ロググループとログストリームの関係は 1:N ログストリームとログイベントの関係は 1:N
65. CloudWatch Logsの概要
66. CloudWatch Logs 設計・運用上の注意点 p サブスクリプションフィルターの制約 p ロググループの分離に関する判断 p ログ取り込みと保存に関する考慮 設計 設計 運用
67. CloudWatch Logs 設計・運用上の注意点 サブスクリプションフィルターの制約 設計 u クォータ制約として、1ロググループあたり2つまで u クォータ変更はできない u 条件の集約など、ログ出力内容も要考慮 u 文字列フィルタリングに正規表現が利用できない u 独自構文で記述が必要 u 「正規表現でやれることは実現できる」と勘違いしない
68. CloudWatch Logs 設計・運用上の注意点 ロググループの分離に関する判断 設計 u 分離の粒度は開発者次第であるが、以下のような検討軸で判断すると良さげ u アプリケーションの種別 u 保存ライフサイクルの違い u アラーム単位（サブスクリプションフィルタ数の制約を考慮） u 暗号化要件の有無
69. CloudWatch Logs 設計・運用上の注意点 ログ取り込みと保存に関する考慮 運用 u CloudWatch Logsは取り込み自体にもコストが発生する u デバッグログの吐き出しなどは要注意 u W-A観点から、保存要件とコストを考慮して保存期間を見直す方が良い u 保存コスト観点では、S3(標準ストレージクラス)と比較すると1.3倍ほど高額 u AWSサービスによっては、ロググループが自動生成されるものもある u App Runnerなどは、ランダムなインスタンスIDでロググループが作成 u その他、LambdaやCodeBuildなどのログはデフォルトで無期限保存
70. CloudWatch Container Insightsの設計・運用 虎の巻
71. CloudWatchにおける各サービスの責務 再掲
72. CloudWatch Container Insights ECS やEKS といったコンテナワークロードの パフォーマンス情報を統合的に分析できるサービス uコンテナの詳細な情報まで取得可能
73. CloudWatch Container Insightsのメカニズム
74. CloudWatch Container Insightsのメカニズム
75. 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形式で記述
76. CloudWatch Container Insightsのメカニズム
77. CloudWatch Container Insights 設計・運用上の注意点 p コンピューティング構成によるContainer Insights有効化方法の違い p カスタムメトリクス自動作成に伴う追加コストの考慮 設計 運用
78. 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 構成
79. 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 構成のカスタムメトリクス数
80. X-Rayの設計・運用 虎の巻
81. CloudWatchにおける各サービスの責務 再掲
82. X-Ray アプリケーションが処理するリクエストに関して、 サービスコンポーネントに跨ぐ一連のトレースデータを収集するサービス uアプリケーション内部に組み込んで動作させる u「セグメント」、「トレース」で構成
83. X-Rayの概要
84. X-Rayの概要 X-Ray
85. X-Rayの概要 X-Ray
86. X-Rayの概要 X-Ray
87. X-Rayの概要 X-Ray メトリクスやLogsも含めて 全体を可視化
88. X-Rayの概要 X-Ray メトリクスやLogsも含めて 全体を可視化
89. X-Ray 設計・運用上の注意点 p コンテナ利用時におけるサイドカー構成・ロール付与・ネットワーク設定 p サポート言語による実装労力の差異 p 料金とパフォーマンス影響を考慮したサンプリング数の実装 設計 設計 運用
90. X-Ray 設計・運用上の注意点 コンテナ利用時におけるサイドカー構成・ロール付与・ネットワーク構成 設計 u X-Rayはアプリケーションの設定のみならず、周辺系の設定が割と面倒でハマることも多い u 全体感を押さえながら設定していくとベター
91. X-Ray 設計・運用上の注意点 サポート言語による実装労力の差異 設計 u アプリケーションのプログラミング言語によってX-Ray実装の手間が異なる u JavaはAuto-instrumentation agentによりコード変更なく組み込みが可能 u GolangやJavaScript、TypeScript等はテレメトリデータを取得する箇所ごとにコーディングが必要
92. X-Ray 設計・運用上の注意点 料金とパフォーマンス影響を考慮したサンプリング数の実装 運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録
93. X-Ray 設計・運用上の注意点 料金とパフォーマンス影響を考慮したサンプリング数の実装 運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録 1秒 1秒 1秒 1秒 e.g. 毎秒200件リクエストが発生するケース ・・・ 最初のリクエスト(=1件) それ以降のリクエスト(=199件)の5%を取得 →199 ×0.05 = 9.95件
94. X-Ray 設計・運用上の注意点 料金とパフォーマンス影響を考慮したサンプリング数の実装 運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録 1秒 1秒 1秒 1秒 e.g. 毎秒200件リクエストが発生するケース ・・・ 最初のリクエスト(=1件) それ以降のリクエスト(=199件)の5%を取得 →199 ×0.05 = 9.95件 u リザーバサイズと固定レートを調整して自分たちのシステム特性に併せたサンプリング数を設定する ⇨リザーバサイズで調整可能 ⇨固定レートで調整可能
95. X-Ray 設計・運用上の注意点 料金とパフォーマンス影響を考慮したサンプリング数の実装 運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録 1秒 1秒 1秒 1秒 e.g. 毎秒200件リクエストが発生するケース ・・・ 最初のリクエスト(=1件) それ以降のリクエスト(=199件)の5%を取得 →199 ×0.05 = 9.95件 u リザーバサイズと固定レートを調整して自分たちのシステム特性に併せたサンプリング数を設定する ⇨リザーバサイズで調整可能 ⇨固定レートで調整可能 e.g. 1秒ごとに最初のリクエストを2件記録し、それ以降は記録したくない 1秒 1秒 1秒 1秒 ・・・ リザーバサイズ=2に設定 → 2件取得 固定レート=0%に設定 → 0件取得
96. まとめ
97. まとめ S R E ビジネス拡大に伴う システムの複雑化・分散化 信頼性維持と運用改善 オブザーバビリティの 重要性
98. まとめ
99. まとめ ・15ヶ月以上メトリクスを保持はMetric Streams ・利用者によるメトリクスの削除がサポート外 ・CloudWatch Metrics Insightsは直近3時間のデータ ・構成によるContainer Insights有効化方法の違い ・カスタムメトリクスに伴う追加コストの考慮 設計 運用 運用 設計 運用 ・コンテナ利用時に求められるアーキテクチャ ・サポート言語による実装労力の差異 ・サンプリング数の考慮 設計 設計 運用 ・サブスクリプションフィルターの制約 ・ロググループの分離に関する判断 ・ログ取り込みと保存に関する考慮 設計 設計 運用
100. その他のサービスはCloudWatch[本格]入門で解説しています！ https://booth.pm/ja/items/4130172
101. Thank you!