← AWSサービスの内部原理 コース
67. 古い数値は粗くなる — 1分→5分→1時間へロールアップしながら15ヶ月残す
メトリクスが「新しいうちは細かく、古くなると粗く」変わっていく仕組みを、解像度と保持期間の階段を図で追っていきます。
① メトリクスには「解像度」が2種類ある
メトリクス1点時刻つきの数値
時系列に並ぶデータポイント標準解像度1分粒度
AWSサービスのメトリクスは既定でこれ高解像度1秒粒度
カスタムメトリクスでのみ選択可- 公式の言い回し: "Standard resolution, with data having a one-minute granularity" / "High resolution, with data at a granularity of one second"。
- "Metrics produced by AWS services are standard resolution by default."
- 高解像度は PutMetricData でカスタムメトリクスを発行するときにのみ選べる（StorageResolution=1。有効値は1と60、省略時は60=標準解像度。公式: "Currently, high resolution is available only for custom metrics."）。
- 高解像度メトリクスは1秒粒度で保存され、1・5・10・30秒または60の倍数のperiodで読める。
メトリクスはまず「どれくらい細かく刻むか」で決まる。AWSサービスが出すメトリクスは既定で1分粒度、より細かい1秒粒度は自分で発行するカスタムメトリクスだけが選べる。
② 保持期間は「粒度ごとの階段」になっている
発行された生データ
粗くなるほど長く
60秒未満保持3時間
高解像度。以後は秒粒度では取得不可さらに粗く
1分粒度保持15日
さらに粗く
5分粒度保持63日
1時間粒度保持455日(=15ヶ月)
- "Data points with a period of less than 60 seconds are available for 3 hours. These data points are high-resolution custom metrics."
- "Data points with a period of 60 seconds (1 minute) are available for 15 days"
- "Data points with a period of 300 seconds (5 minutes) are available for 63 days"
- "Data points with a period of 3600 seconds (1 hour) are available for 455 days (15 months)"
- メトリクス自体は削除できず、新しいデータが来なくなると15ヶ月で自動失効する。
粒度が細かいほど保持は短く、粗いほど長い。3時間・15日・63日・455日という4段の階段が、そのまま「古いデータほど粗い解像度でしか残らない」を意味する。
③ 期限が来たデータは「消える」のではなく「粗く集約されて生き残る」
1分粒度で発行0〜15日: 1分解像度のまま取得できる
63日経過 — さらに集約
5分解像度で取得1分の細部は失われる
点は生きている455日(15ヶ月)経過
1時間解像度で取得
失効
- "Data points that are initially published with a shorter period are aggregated together for long-term storage."
- "if you collect data using a period of 1 minute, the data remains available for 15 days with 1-minute resolution. After 15 days this data is still available, but is aggregated and is retrievable only with a resolution of 5 minutes. After 63 days, the data is further aggregated and is available with a resolution of 1 hour."
これがダウンサンプリング（ロールアップ）そのもの。1分データは15日で「消える」のではなく、5分粒度に丸められて生き延びる。細部を捨てて要約だけを残すから、15ヶ月という長期保存が現実的なコストで成立する。
④ なぜ「新しいデータは細かく・古いデータは粗く」なのか
用途は時間で変わる
古いほど 価値↓・保存量↑
直近: 障害デバッグ1分・1秒の細部が要る
過去: 傾向分析秒単位の揺れは不要。大きな流れで十分
設計判断
コスト vs 価値細部を保つコストと得られる価値の天秤
粗くして長く残す古いデータは解像度を削って保持
- S3編のライフサイクル（古いオブジェクトを安いストレージ層へ移す）と同じ「データの価値は時間で減衰する」という原理のメトリクス版。S3は"置き場所"を変え、CloudWatchは"解像度"を削ることでコストを下げる。
- ロールアップで捨てているのは生値そのもの。丸めて要約（統計）を残すこの発想は、次レッスンの統計（生値でなく集計を保持する）への伏線。
「古いデータは粗く長く」は妥協ではなく設計。直近はデバッグに細部が要り、古い区間は傾向さえ分かればいい——価値の減衰とストレージコストの両方に、階段状の解像度がちょうど噛み合う。
⑤ 取得時のperiod（集計期間）と、sub-minuteが意味を持つ条件
period(秒)を指定取得時に何秒ぶんを1点に束ねるか
どちらのperiodか
1/5/10/30または60の倍数
選び方の原則
1〜30秒のperiod高解像度カスタムメトリクスでのみ意味を持つ
標準解像度は1分未満の刻みを持たない60の倍数標準/高解像度どちらでも使える
保存粒度に合わせるperiodはデータの保存粒度に揃えて選ぶ
- "valid values for period are 1, 5, 10, 30, or any multiple of 60."
- "Only custom metrics that you define with a storage resolution of 1 second support sub-minute periods." / "you should select a period that aligns to how the metric is stored."
- periodの既定値は60秒。60を超える場合は60の倍数でなければならない。
periodは「何秒ぶんを1点に束ねて取り出すか」。細かい秒単位のperiodは、そもそも秒単位で保存されている高解像度メトリクスにしか意味がない。保存粒度を超える細かさは取り出せない。
⑥ 集計値は「periodの開始時刻」がスタンプされ、進行中は動き続ける
19:00〜20:001時間period
この区間の全サンプルを集約period進行中の見え方
スタンプ=19:00periodの開始時刻が付く
サンプルが増えるたび更新
19:00時点最初の数点だけの暫定値
全サンプル反映
19:30時点値が変化していく
20:00時点で確定
- "When statistics are aggregated over a period of time, they are stamped with the time corresponding to the beginning of the period. For example, data aggregated from 7:00pm to 8:00pm is stamped as 7:00pm."
- "data aggregated between 7:00pm and 8:00pm begins to be visible at 7:00pm, then the values of that aggregated data may change as CloudWatch collects more samples during the period."
- 高解像度メトリクスへのアラームは10秒/30秒周期を選べる（追加料金あり）。それ以外は60の倍数。
集計値には「区間の始まり」の時刻が付く。だからperiod進行中に見えている値は暫定で、サンプルが集まるにつれ動く。直近のperiodの数字が後からズレて見えるのは、この確定前の状態を見ているため。