監視データの保持設計 — メトリクスとログをいつ間引き、いつ消すかの判断

監視データの保持設計で判断を誤ると、障害発生から数週間後の遡及調査で手も足も出なくなる。原因は単純で、「何を・どの粒度で・どの期間・どこに」置くかを意図して決めていないからだ。保持期間を一律に揃えればストレージが膨れ、短く切りすぎれば調査の手がかりが消える。この記事では、データ種別ごとの保持期間の設計根拠から、ダウンサンプリング方式の選定、階層ストレージへの移行タイミング、自動削除の設計、コンプライアンス要件との分離、そしてよくある落とし穴まで、構築担当者が実際に線引きするための判断軸を整理する。

監視データの種類ごとに保持期間が変わる理由

メトリクス・ログ・トレースの性質の違い

監視データは大きく「メトリクス」「ログ」「トレース」の3種に分かれ、参照パターンが根本的に異なる。メトリクスは時系列の数値データで、直近の状態把握には秒単位の粒度が必要だが、数ヶ月後には傾向を見る目的に変わるため粒度を落としても実用に耐える。ログはイベントの記録であり、特定の日時に何が起きたかを記述するため、後から粒度を変えることができない。トレースは1リクエストの処理経路を追う情報で、主にインシデント直後の短期調査に使われ、長期保存の費用対効果は低い。この性質の違いを無視して同一の保持期間を設定すると、必要なデータが消えるか不要なデータが残り続けるかのどちらかになる。

参照頻度と調査深度の非対称性

現場では監視データの9割以上が直近1週間以内に参照されるという傾向がある。一方、障害調査が長引いたとき「3ヶ月前のトレンドと比較したい」「先月のデプロイ直後の状態を確認したい」という需要が生まれる。この非対称性が設計を難しくしている要因だ。毎日アクセスされるわけではないが、いざという場面に参照できないと調査が立ち止まる。設計の核心は「いつまで調査できるか」と「その時点でどの粒度が残っているか」の2軸を意図的に決めることにある。

保持期間設計の出発点となる3つの問い

保持期間を設計する際、最初に答えるべき問いは3つある。第一に「最長でどこまで遡及する必要があるか」、第二に「その時点で必要な粒度は何か」、第三に「法令・社内規程が定める最低保持期間はあるか」だ。この3つが揃うと、保持設計の輪郭が見えてくる。多くの環境では、オペレーション用途で3〜6ヶ月、コンプライアンス用途で1〜3年という二層の構造に落ち着くことが多く、これを出発点として各データ種別に当てはめていく作業が設計の実態だ。

高頻度メトリクスのダウンサンプリング方式比較

ダウンサンプリングが必要になる背景

CPUやネットワークのメトリクスを10秒間隔で収集すると、1台あたり1日に約8,640ポイントのデータが積み上がる。100台構成であれば1日あたり86万ポイント超だ。これを1年間保持すれば単純計算で3億ポイント以上となり、クエリ速度とストレージコストの両方に影響を与える。長期保持の現実解は「古いデータほど粒度を落とす」設計で、この処理をダウンサンプリングと呼ぶ。粒度をいつ・どの方式で落とすかが、後の調査能力を左右する設計判断になる。

集約方式の比較と用途ごとの選定

ダウンサンプリングには主に複数の集約方式があり、用途によって適切な選択が変わる。平均値集約はノイズを滑らかにするが、スパイクが埋もれる欠点がある。最大値集約はピーク値を保持するため異常検知には有利だが、通常状態のトレンド把握には向かない。パーセンタイル保持（p95・p99）はレイテンシ分析で使われ、外れ値の影響を受けにくい特性を持つ。設計で迷った場合は、アラートの根拠に使うメトリクスには最大値かパーセンタイルを、容量計画に使うメトリクスには平均値を選ぶという切り分けが実践的な判断基準となる。

集約方式	スパイク保持	主な用途	向かないケース
平均値	×（埋もれる）	容量計画・トレンド把握	アラート閾値判定
最大値	○	アラート根拠・ピーク把握	通常状態の傾向分析
最小値	△	SLO下限の追跡	ほとんどの一般用途
p95 / p99	○（外れ値除く）	レイテンシ分析・SLI	カウンター系メトリクス

集約タイミングの設計方針

ダウンサンプリングをいつ実行するかも重要な判断だ。「書き込み時にリアルタイムで集約する」方式はストレージ消費を即座に抑えられる反面、集約後に元粒度が必要になっても取り戻せない。「一定期間は原粒度を保持し、期間経過後にバッチで集約する」方式は柔軟性が高いが、移行処理の設計とテストが必要になる。現場では後者が多く採用され、直近7日は10秒粒度、30日以降は1分粒度、90日以降は5分粒度という段階的な移行が典型的なパターンだ。手を動かす際の具体的な実装はツールやDBの公式ドキュメントで確認するとして、設計段階で決めるべきは「どの粒度を・いつ・何に集約するか」の3点だ。

長期保持と短期保持のストレージ階層設計

ホット・ウォーム・コールドの3層モデル

監視データのストレージ設計では、アクセス頻度に応じてデータを3層に分けることが有効だ。ホット層は直近のデータを高速に検索できるSSD系ストレージや専用時系列DBに置き、ダッシュボードへのレスポンスを数秒以内に収める。ウォーム層は数週間〜数ヶ月のデータを保持し、クエリ速度よりも保持コストを優先した構成にする。コールド層は長期保存用のオブジェクトストレージやアーカイブストレージに置き、頻繁には参照しないが法令対応や深刻な障害調査の際に参照できる状態を維持する。この3層を明示的に設計することで、コストと速度のトレードオフを意図的に制御できる。

層間移行のタイミングと移行条件の設計

3層構造を機能させるには、各層へのデータ移行条件を明示的に定義しておく必要がある。移行条件が「日付経過」だけでは不十分で、「データの圧縮・集約が完了しているか」「直近インシデントに関連するデータではないか」という確認ステップが欠けると、調査中にデータが移行されて参照が遅くなる問題が起きる。実装上は移行ジョブがインシデントフラグ付きのデータをスキップする仕組みを組み込むか、インシデント対応中は移行を一時停止する制御を設けるかで対応する。移行条件の設計は後から追加すると既存パイプラインへの影響が大きいため、構築時点で組み込む必要がある。

ログとメトリクスで異なる階層設計の判断

メトリクスはダウンサンプリングを経た後にウォーム層へ移行できるが、ログは原文を保持する必要があるためサイズが大きくなりやすい。50台規模の環境でアプリケーションログを1年保持する場合、非圧縮で数十TBに達するケースも珍しくない。コールド層への移行前に圧縮（gzipやzstd）を挟むことで、ストレージ消費を1/5〜1/10程度に抑えられる。ただしコールド層に移行したログをクエリするには解凍処理が必要で、調査時の応答速度に影響する。その制約を事前に利用部門へ共有しておくことで、「調査できると思っていたが時間がかかる」という認識齟齬を防ぐ。

ストレージコストと遡及調査の深さをどうトレードオフするか

コストの主な発生源を把握する

監視データのコストは「保存コスト」と「クエリコスト」の2種に分解できる。ホット層は両コストが高く、コールド層は保存コストは低いがクエリ時に取り出しコストが加算される。設計で見落とされがちなのは後者で、アーカイブストレージに置いたデータを大量に取り出す場面で予想外の費用が発生することがある。保持期間を長く取るほど保存コストが上がり、頻繁に参照するほどクエリコストが上がる構造を理解した上で、「何のために・どの頻度で参照するか」を基準に保持先を決める判断が設計の軸となる。

調査深度の実績に基づく判断軸

保持期間を決める際、「念のため長く残したい」という心理が働きやすい。それ自体は悪くないが、実際の遡及調査でどの期間のデータが参照されているかを計測すると判断精度が上がる。構築を任されたある担当者は、半年分のアクセスログを分析した結果、障害調査で参照したデータの95%が発生から30日以内のものだったと証言している。この結果を受けて90日以降のメトリクスをコールド層に移行した結果、ホット層のストレージ使用量が約40%削減された。実績が取れない段階では、まず3〜6ヶ月で運用を始め、後から延ばす方向で調整するのが現実的だ。

段階的な保持期間の見直し設計

保持設計は一度決めたら固定ではなく、定期的に見直す仕組みを組み込むことが重要だ。半年に一度、「どの期間のデータが実際に参照されたか」「保持コストに対して参照回数は見合っているか」をレビューする運用ルールを定めておくと、コストと調査深度のバランスを継続的に最適化できる。保持期間を短縮する方向の変更は影響が大きいため、変更前に利用部門へ周知し、必要なら移行前にエクスポートを取っておく手順を含めるとトラブルを防げる。設計ドキュメントには「いつ・誰が・何を根拠に決めたか」を記録しておくと、次回の見直し時の判断材料として活用できる。

保持期限を超えたデータの削除を自動化する設計

手動削除が抱える構造的な問題

保持期間を設定しても削除が手動運用のままでは、担当者の交代や業務繁忙期に見直しが滞り、ストレージが際限なく増え続ける。現場でよく聞く話として、「設定は1年だが実際には2〜3年分残っている」という状況がある。これは費用上の問題にとどまらず、古いデータが残ることでクエリの対象範囲が広がり、検索速度の低下を招く原因にもなる。自動削除は「余ったら消す」ではなく「設計通りに消す」仕組みとして、最初から組み込む必要がある。

自動削除の設計パターンと注意点

自動削除の設計では、削除対象の選定基準・削除実行のタイミング・削除前の確認ステップの3つを定義する。選定基準は「タイムスタンプが保持期限を超えたデータ」が基本だが、インシデントフラグや法令保持タグが付いたデータは除外する条件を入れる。削除実行は深夜バッチで小分けにして行うことでI/Oのスパイクを抑えられる。削除前の確認ステップとして、削除対象のサイズと件数をログに残し、異常な大量削除を検知したら一時停止するガード処理を加えると安全性が高まる。削除ジョブ自体の監視も忘れずに設定する必要がある。

自動削除設計のチェックリスト

• 保持期限はデータ種別（メトリクス・ログ・トレース）ごとに個別に設定されているか
• インシデントフラグや法令保持タグが付いたデータを削除対象から除外する条件が存在するか
• 削除実行前にサイズと件数をログに記録し、異常大量削除の検知・停止処理があるか
• 削除ジョブ自体の監視（失敗時のアラート・ジョブ実行履歴の保存）が設定されているか
• 削除済みデータの復元手順と対応可能期間が明確に定義されているか
• 保持期間変更時の周知・エクスポート手順が文書化されているか

コンプライアンス要件とオペレーション要件の保持期間の分け方

要件の種類と保持期間の考え方

監視データの保持要件は「オペレーション要件」と「コンプライアンス要件」の2種に分けて考えると設計しやすい。オペレーション要件は「障害調査に必要な期間」で、一般的には3ヶ月〜1年程度が目安だ。コンプライアンス要件は法令・業界規制・契約に基づく保持義務で、金融系では数年、医療系では数十年に及ぶケースもある。両者を同じ設計で扱おうとすると、コンプライアンス要件に引きずられてオペレーション用のデータも過剰に長期保持するか、逆に短期設計に統一して法的義務を果たせないかのどちらかに陥りやすい。

分離保管とラベリングの設計

コンプライアンス要件を満たすデータとオペレーション用データは、保管先・削除ポリシー・アクセス制御の3点で分離する設計が有効だ。コンプライアンス対象データには取り込み時点でラベルを付与し、自動削除の対象外とするフラグを持たせる。アクセス制御については、長期保持データへのアクセスを限定的なロールに絞ることで、誤削除や意図しない参照を防ぐ。ラベリングの設計を後から追加するのは難しいため、取り込みパイプラインの設計段階で組み込む必要がある。改ざん防止（WORM）要件がある場合は、対応するストレージサービスの選定も設計段階で確定させる。

要件定義の段階で確認すべき事項

保持設計の前に、法務・コンプライアンス部門と合意しておくべき事項がある。「対象となる法令・規制の名称と条文の確認」「保持対象のデータ種別の定義（ログ全体か特定のログか）」「保持期間の起算点（データ生成日か特定イベント日か）」「改ざん防止要件の有無」「監査時の証跡提出フォーマット」の5点を明確にすることで、設計段階での手戻りを防げる。これらを曖昧なまま構築を進めると、後から要件追加で既存設計を大幅に作り直す事態になることがある。

落とし穴 — 保持設計を怠ったことで障害調査が行き詰まるパターン

データが消えていて原因を特定できないパターン

保持期間を短く設定しすぎた結果、障害調査の時点でデータが存在しないケースは現場で頻繁に起きている。特に問題になるのは、障害の症状が「じわじわ進行するタイプ」の場合だ。パフォーマンス劣化や断続的なエラー増加は、数週間前から兆候がある場合が多い。7日保持の設定で1ヶ月前から始まっていた異常の証跡を取り戻すことはできない。保持期間の設計は「平常時に必要なもの」ではなく「最悪のインシデント時に必要なもの」を想定して決める必要があり、この発想の転換が設計精度に直結する。

粒度が荒すぎてスパイクを見逃すパターン

ダウンサンプリングの集約タイミングを早めに設定した結果、数分単位のスパイクが平均値に飲み込まれて見えなくなるケースがある。例えば1分間に1回しか発生しないタイムアウトエラーは、5分集約の平均値では発生率0.2%未満となり、閾値アラートに引っかからない。粒度の粗いデータしか残っていない状態で「アラートが鳴らなかったのにサービス影響が出ていた」という事態が起きる。ダウンサンプリングの設計では、集約後も異常検知に使えるメトリクス（最大値・エラーカウント）は原粒度か最大値集約で保持する判断が必要で、「全メトリクスを同じ設定で集約する」という運用が落とし穴になる。

ストレージが予期せず枯渇するパターン

保持設計を「期間だけ」で行い、データ量の見積もりをしなかった結果、6ヶ月で枯渇する予定のストレージが3ヶ月で満杯になるケースがある。原因は監視対象の台数増加・ログの冗長化・新しいメトリクスの追加など複数あり、設計時点の見積もりが陳腐化しやすい。また、ストレージが枯渇した際に古いデータが自動削除されるのか、新しいデータの書き込みが止まるのかによって影響が大きく変わる。いずれの動作を選ぶかを意図的に決め、枯渇前に警告するアラートを設定しておくことが設計として必要だ。ストレージ使用量が設計上限の80%に達した時点でアラートを発報する設定が、一般的な目安として現場で参照されることが多い。