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

Transcript

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

   View Slide

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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 虎の巻とは？
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

13. サービス追加
    

    View Slide

14. サービス追加
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

30. CloudWatchのサービススイート
    

    View Slide

31. CloudWatchのサービススイート
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

44. CloudWatchメトリクスの概要
    

    View Slide

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

    View Slide

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

    View Slide

47. CloudWatchメトリクスの概要
    

    View Slide

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

    View Slide

49. CloudWatchメトリクスの概要
    

    View Slide

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

    View Slide

51. CloudWatchメトリクスの概要
    

    View Slide

52. CloudWatchメトリクスの概要
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

58. CloudWatch Logsの設計・運用 虎の巻
    

    View Slide

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

    View Slide

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

    View Slide

61. CloudWatch Logsの概要
    

    View Slide

62. CloudWatch Logsの概要
    

    View Slide

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

    View Slide

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

    View Slide

65. CloudWatch Logsの概要
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

73. CloudWatch Container Insightsのメカニズム
    

    View Slide

74. CloudWatch Container Insightsのメカニズム
    

    View Slide

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形式で記述
    

    View Slide

76. CloudWatch Container Insightsのメカニズム
    

    View Slide

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

    View Slide

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 構成
    

    View Slide

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 構成のカスタムメトリクス数
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

83. X-Rayの概要
    

    View Slide

84. X-Rayの概要
    X-Ray
    

    View Slide

85. X-Rayの概要
    X-Ray
    

    View Slide

86. X-Rayの概要
    X-Ray
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

93. X-Ray 設計・運用上の注意点
    料金とパフォーマンス影響を考慮したサンプリング数の実装
    運用
    u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録
    1秒 1秒 1秒 1秒
    e.g. 毎秒200件リクエストが発生するケース
    ・・・
    最初のリクエスト(=1件)
    それ以降のリクエスト(=199件)の5%を取得
    →199 ×0.05 = 9.95件
    

    View Slide

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

    View Slide

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件取得
    

    View Slide

96. まとめ
    

    View Slide

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

    View Slide

98. まとめ
    

    View Slide

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

    View Slide

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

     View Slide

101. Thank you!
     

     View Slide