LESSON 30分

ストーリー

田
田中VPoE
データ収集パイプラインの設計ができた。次は「集めたデータをどこに、どう保存するか」だ
あなた
バックエンドにそのまま流せばいいのでは？
あ
田
田中VPoE
規模が小さいうちはそれで問題ない。だが月間5億リクエストの組織だと、メトリクスだけで1日数十億データポイント、ログは1日数TBになることもある。ストレージの選択と分析基盤の設計が、プラットフォームの性能とコストを大きく左右する
あなた
スケーラビリティとコストのバランスですね
あ
田
田中VPoE
まさにそうだ。そしてもう一つ重要なのが「分析の速度」だ。インシデント対応中に10秒待つクエリは致命的だ。必要な分析が即座にできるストレージ設計が求められる

テレメトリデータのストレージ選択

メトリクスストレージ

選択肢特徴適用
PrometheusPull型、ラベルベースのTSDB、PromQL単一クラスタ、短期保持
Mimir / Thanos / CortexPrometheusの長期保存・マルチテナント対応大規模組織、長期保持
InfluxDBPush型、高い書き込み性能IoT、高頻度データ
SaaS（Datadog, Grafana Cloud等）フルマネージド、運用不要運用工数を最小化したい組織

ログストレージ

選択肢特徴適用
Elasticsearch/OpenSearch全文検索、高い分析機能高度なログ分析、大量のカーディナリティ
Lokiラベルベースインデックス、低コストコスト重視、Grafana統合
S3 + Athenaサーバーレス分析、長期保管アーカイブ分析、コスト最小化
SaaS（Datadog Logs, Splunk Cloud等）フルマネージド、高度な分析機能運用工数を最小化したい組織

トレースストレージ

選択肢特徴適用
JaegerCNCF Graduated、Cassandra/Elasticsearch対応OSS中心の組織
Tempoオブジェクトストレージベース、低コストGrafana統合、コスト重視
SaaS（Datadog APM, Grafana Cloud等）フルマネージド、相関分析組み込み運用工数を最小化したい組織

ストレージアーキテクチャの設計パターン

パターン1: 統合SaaS型

OTel Collector → Datadog / Grafana Cloud / New Relic
                 (メトリクス + ログ + トレース 一括保存)
項目内容
メリット運用不要、3本柱の相関分析がビルトイン
デメリットコストが高い（大量データ時）、ベンダーロックイン
TCO（月間5億リクエスト規模）年間2,000-4,000万円

パターン2: OSSスタック型（Grafana LGTM）

OTel Collector → Loki (ログ)
               → Mimir (メトリクス)
               → Tempo (トレース)
               → Grafana (可視化・相関分析)
項目内容
メリットベンダー非依存、コスト最適化可能
デメリット運用スキルが必要、構築・運用工数
TCO（月間5億リクエスト規模）年間1,000-2,000万円（インフラ + 人件費）

パターン3: ハイブリッド型

OTel Collector → SaaS (メイン: 直近データ、リアルタイム分析)
               → OSS/S3 (長期保管: コスト最適化)
項目内容
メリットリアルタイム分析とコスト最適化の両立
デメリット複雑なアーキテクチャ、データの一貫性管理
TCO（月間5億リクエスト規模）年間1,500-2,500万円

分析基盤の設計

分析のユースケースと要件

ユースケースレイテンシ要件データ範囲分析手法
インシデント対応< 1秒直近24時間フィルタリング、ドリルダウン
根本原因分析< 5秒直近7日相関分析、比較分析
トレンド分析< 30秒30-90日集約、可視化
キャパシティプランニング< 1分3-12ヶ月統計分析、予測
コンプライアンス監査< 5分1-7年全文検索、集計

相関分析の実現

3本柱の相関分析を実現するための設計要件を定義します。

相関手法実現方法前提条件
Trace→LogトレースIDでログをフィルタログにtrace_idフィールドが必須
Trace→Metricsスパンからメトリクスを生成（Span Metrics Connector）OTel Collectorの設定
Metrics→Trace異常メトリクスの時間帯でExemplarトレースを取得Exemplar対応のメトリクスDB
Log→Traceログ内のtrace_idリンクからトレースにジャンプ可視化ツールの統合設定
相関分析の流れ（インシデント対応時）:

1. メトリクス: "payment-serviceのエラーレートが上昇"
   ↓ Exemplarリンク
2. トレース: "特定のトレースでDB呼び出しがタイムアウト"
   ↓ trace_idリンク
3. ログ: "Connection pool exhausted, max_connections=50 reached"
   ↓ 根本原因特定
4. 対応: "コネクションプールの設定値を調整"

スケーラビリティ設計

データ量の見積もり

データ種別推定量（月間5億リクエスト規模）年間ストレージ
メトリクス5億データポイント/日2TB（ダウンサンプリング後）
ログ2TB/日（構造化JSON）20TB（フィルタリング後）
トレース10億スパン/日5TB（サンプリング後）

スケーラビリティの考慮点

考慮点設計方針
書き込みスケーラビリティ水平スケーリング可能なストレージを選択
クエリスケーラビリティクエリキャッシュ、インデックス最適化
マルチテナントチーム別のデータ分離とクォータ管理
可用性3AZ以上のレプリケーション
バックアップ日次バックアップ、ポイントインタイムリカバリ

「ストレージ設計で最も重要なのは”3年後のデータ量”を見据えた設計だ。今日動くアーキテクチャではなく、3年後も動くアーキテクチャを選べ」 — 田中VPoE

まとめ

ポイント内容
ストレージ選択メトリクス/ログ/トレースそれぞれに最適なストレージを選定
アーキテクチャパターン統合SaaS型、OSSスタック型、ハイブリッド型から選択
分析基盤ユースケース別のレイテンシ要件、3本柱の相関分析設計
スケーラビリティデータ量見積もり、水平スケーリング、マルチテナント

チェックリスト

  • テレメトリデータ種別ごとのストレージ選択肢を理解した
  • 3つのアーキテクチャパターンの特徴とTCOを理解した
  • 相関分析の実現方法を理解した
  • スケーラビリティ設計の考慮点を理解した

次のステップへ

次は「可視化とダッシュボード設計」を学びます。保存・分析したデータをどのように効果的に可視化し、意思決定に活用するかの設計手法を身につけましょう。

推定読了時間: 30分