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

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

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

iselegant

May 29, 2023
Tweet

More Decks by iselegant

Other Decks in Technology

Transcript

  1. 新井 雅也 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
  2. CloudWatch Logs 設計・運用上の注意点 サブスクリプションフィルターの制約 設計 u クォータ制約として、1ロググループあたり2つまで u クォータ変更はできない u

    条件の集約など、ログ出力内容も要考慮 u 文字列フィルタリングに正規表現が利用できない u 独自構文で記述が必要 u 「正規表現でやれることは実現できる」と勘違いしない
  3. CloudWatch Logs 設計・運用上の注意点 ログ取り込みと保存に関する考慮 運用 u CloudWatch Logsは取り込み自体にもコストが発生する u デバッグログの吐き出しなどは要注意

    u W-A観点から、保存要件とコストを考慮して保存期間を見直す方が良い u 保存コスト観点では、S3(標準ストレージクラス)と比較すると1.3倍ほど高額 u AWSサービスによっては、ロググループが自動生成されるものもある u App Runnerなどは、ランダムなインスタンスIDでロググループが作成 u その他、LambdaやCodeBuildなどのログはデフォルトで無期限保存
  4. 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形式で記述
  5. 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 構成
  6. 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 構成のカスタムメトリクス数
  7. X-Ray 設計・運用上の注意点 料金とパフォーマンス影響を考慮したサンプリング数の実装 運用 u デフォルトでは、1 秒ごとに最初のリクエストを記録し、それ以降のリクエストは 5% ずつ記録 1秒

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

    1秒 1秒 1秒 e.g. 毎秒200件リクエストが発生するケース ・・・ 最初のリクエスト(=1件) それ以降のリクエスト(=199件)の5%を取得 →199 ×0.05 = 9.95件 u リザーバサイズと固定レートを調整して自分たちのシステム特性に併せたサンプリング数を設定する ⇨リザーバサイズで調整可能 ⇨固定レートで調整可能
  9. 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件取得
  10. まとめ ・15ヶ月以上メトリクスを保持はMetric Streams ・利用者によるメトリクスの削除がサポート外 ・CloudWatch Metrics Insightsは直近3時間のデータ ・構成によるContainer Insights有効化方法の違い ・カスタムメトリクスに伴う追加コストの考慮

    設計 運用 運用 設計 運用 ・コンテナ利用時に求められるアーキテクチャ ・サポート言語による実装労力の差異 ・サンプリング数の考慮 設計 設計 運用 ・サブスクリプションフィルターの制約 ・ロググループの分離に関する判断 ・ログ取り込みと保存に関する考慮 設計 設計 運用