> [!abstract] 概要(abstract の日本語訳) > オブザーバビリティは今日の大規模ソフトウェアシステムとサービスにおける重要な能力として注目されている。Slack での産業経験を動機とし、データベース研究への問いかけとして、本論文はこの新興ワークロードを大規模に扱うオブザーバビリティデータ管理システム(ODMS)の設計・構築に関わる課題と機会を概観する。 ## 論文情報 - **タイトル**: Towards Observability Data Management at Scale - **著者**: Suman Karumuri(Slack Technologies)、Franco Solleza・Stan Zdonik(Brown University)、Nesime Tatbul(Intel Labs and MIT) - **媒体**: SIGMOD Record, December 2020 (Vol. 49, No. 4) / DOI: 10.1145/3456859.3456863 - **発行年**: 2021（DOI 収録年） - **論文種別**: ビジョン/経験論文（産業事例を題材とした研究課題提起） ## 概要 Slack の 2020 年 5 月 12 日の完全サービス停止インシデントを起点に、オブザーバビリティをデータ管理問題として定式化する。Metrics・Events・Logs・Traces(MELT)という 4 種の異種時系列データが独立したツール群で管理されてきた現状を分析し、大規模 ODMS 構築の設計原則と新アーキテクチャのブループリントを提示するビジョン論文。 ## 問題設定 - **入力**: クラウドネイティブシステムが実行時に生成する MELT データ（不変・追記型・大量・バースト性） - **出力**: 近リアルタイムの洞察（time to insight の最小化） - **前提**: DevOps チームが人間参加型でシステムの「何が・なぜ起きているか」を理解する必要がある - **問題**: 既存 ODMS は MELT の各型に特化したツールの寄せ集め(パッチワーク)で、統一したデータライフサイクル管理・クエリインタフェースを持たない ## MELT データ分類(§2) 論文の中核的貢献の一つ。4 データ型の特性を Table 1 で整理している。 | 型 | データ | クエリ | ストレージ | Slack 規模 | 保持期間 | |---|---|---|---|---|---| | Metrics | 数値(カウンタ/ゲージ/ヒストグラム) + tags | 集計・メタデータフィルタ | 圧縮時系列 + ハイブリッドカラム | 4B 系列/日・12M samples/秒・12TB/日(圧縮) | 30 日 | | Events | 高度構造化文字列またはバイナリ | 正確な文字列一致フィルタ | カラムストア | 250TB/日(生)、70PB 超を蓄積 | 3〜24 ヶ月 | | Logs | 半構造化〜非構造化文字列 | 近似文字列検索 | 転置インデックス | 90TB/日(生) | 7 日 | | Traces | DAG（実行経路） | 分離グラフ検索 | カラム/転置インデックス | 2TB/日(生) | 14 日 | - Metrics はカウンタ(単調増加)・ゲージ(増減可)・ヒストグラム(観測値の分布)の 3 型を含む - Events は従来 Logs のサブカテゴリとして扱われてきたが、データモデル・クエリ・アクセスパターンが Logs と本質的に異なるため独立した類型として扱う - Traces は DAG 表現で Lamport の happens-before 順序を用い、OpenTelemetry が業界標準として整備中 ### MELT の共通特性 - **データ特性**: 全型とも不変・追記型。動的分散環境のバースト性により取り込み量が一時的に 10 倍に跳ね上がる - **鮮度バイアス**: Table 2 より、クエリの 97% 超が直近 24 時間以内のデータを対象とする（Logs 92.5%→99.8%@<24h、Metrics 94.7%→99.8%、Traces 85.2%→97.3%） - **ライフサイクル管理**: 鮮度バイアスがある一方、少数クエリは長期トレンド・法的目的で古いデータを要求する。世代別ストレージ戦略が必要 ## Slack の現行 ODMS(§3) ### インフラ構成 Prometheus(メトリクス)・Apache Kafka → S3 → Presto(ELT 歴史クエリ)・Elasticsearch(ログ・トレース)・Logstash・内製トレースストアで構成される 20 以上のソフトウェアコンポーネント。各コンポーネントは独自アーキテクチャを持ち、クラスタ管理・セキュリティ・容量計画がそれぞれ異なる。 - Prometheus はシングルノードで高可用性のため独立コピーを 100 プールほど運用 - ELT は Presto でデュプリケートして処理——可用性とのトレードオフでコストが増大 ### 3 課題 1. **高い運用複雑性**: 20 超コンポーネント、異種アーキテクチャ。インシデント時に取り込み量が 4 倍に跳ね上がる場面での複雑なスケールアップ操作が必要 2. **低クエリレイテンシの維持困難**: 97% の鮮度バイアスの下、ダッシュボード・アラートはサブ秒レイテンシを要求。インシデント時には通常の 2 倍のユーザー数で過去 8 時間分を参照する 3. **高いインフラコスト**: ピーク時に 2 倍プロビジョニング、ELT の二重処理。新しいピーク負荷が旧ピークの 2 倍になりプロビジョニング戦略そのものがコストを積み増す ## ODMS 設計原則(§4) **原則 1: リアルタイムと履歴データ管理の分離** - MELT ワークロードは HTAP(OLTP + OLAP)とは異なる。バースト性の大量不変書き込みと 97% 超の鮮度バイアスを前提とし、リアルタイム取り込みと歴史アクセスを独立して管理する - 利点: 高取り込み率・低クエリレイテンシ・歴史データの低コスト保持の三者を分離して最適化できる **原則 2: MELT ライフサイクル統合** - 時間軸がすべての MELT データを共通フレームワークで束ねる。データ年齢に基づくライフサイクル管理で、リアルタイムから歴史ストレージへの移動を抽象化する **原則 3: MELT 単一クエリインタフェース** - オブザーバビリティクエリは複数の MELT 型にまたがる（例: 特定の異常がメトリクス・ログ・トレースのどれで現れるか）。単一インタフェースで横断クエリを可能にし、ストレージ最適化の機会を提供する **原則 4: クラウドネイティブ分散配置** - 読み書きのバースト性に対応するため、各層はデフォルトで分散・弾力的に設計する。コストとパフォーマンスのトレードオフを柔軟に調整できるクラウドネイティブ配置 ## 提案アーキテクチャ(§4) Lambda アーキテクチャでなく**ポリストアアーキテクチャ**に影響を受ける統合設計。 ``` 計装アプリ → Replicated Log Service(Kafka 等) ↓ Real-Time Indexing(型別ストレージエンジン) ↓ (定期移行) Persistent Storage(S3 等) ↕ Hot Data Cache(歴史データの高速アクセス層) ↑ Query Engine + Metadata Store + Cluster Manager ``` - **Cluster Manager**: Real-Time Indexing の負荷を監視し、書き込みバースト時には Indexing を、歴史データの重いクエリ時には Hot Data Cache をスケールアップ - **Query Engine**: Real-Time Indexing・Persistent Storage・Hot Data Cache を透明に横断。時間範囲フィルタでデータ配置を決定し、アドホッククエリが反復される場合は Hot Data Cache へコピーしてレイテンシを低減 - **Hot Data Cache**: アクセスパターンベースの弾力的な層。ピーク読み込み時に独立スケール可能 この設計により Slack の May 12 相当のインシデント時でも、単一クエリインタフェースと統一 MELT ビューを維持できる。プロトタイプ実装を Slack の本番データで検証中（論文時点）。 ## 新規性 - 2021 年時点でオブザーバビリティを「データ管理問題」として最初に体系的に定式化したビジョン論文 - MELT の 4 型分類を Slack の定量データ（表 1・表 2）で裏付けた産業論文 - Events を Logs のサブカテゴリとして扱う従来の慣行に疑問を呈し、独立した型として分離する主張 - 既存のポリストア研究（BigDAWG 等）をオブザーバビリティドメインに適用する方向性を示した ## 強み・弱点・課題 ### 強み - Slack の実測データ(表 1・表 2)に基づく具体的な定量化 - MELT の各型の特性を丁寧に整理し、なぜ統一が困難かを説明している - ビジョン論文として研究コミュニティへの問題提起が明確 ### 弱点・課題 - プロトタイプ実装はあるが本番評価なし（ビジョン論文の性質上） - 実装の具体的な技術的詳細（圧縮方式、クエリオプティマイザ等）は論文スコープ外 - MELT の 4 分類は Slack 視点であり、ネットワークテレメトリ(フロー等)は含まない - 2021 年以降、LLM エージェントが ODMS に接続する際の意味的ギャップ（[[UModel]] が定義した「死んだトークン」問題）は未考慮 ## 関連 - ソース: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]](本ビジョンを 2026 年に大規模実証) - 概念: [[テレメトリ]] / [[オブザーバビリティデータモデル]] / [[時系列データベース]] / [[分散トレーシング]] - エンティティ: [[Suman Karumuri]] / [[Franco Solleza]] / [[Stan Zdonik]] / [[Nesime Tatbul]] / [[Slack Technologies]] / [[Brown University]] / [[OpenTelemetry]] / [[Prometheus]] ## 出典 - PDF 本文: `.raw/papers/1-3456859.3456863.pdf` (Table 1, Table 2, §2–§4 全節) - DOI: 10.1145/3456859.3456863