[Karumuri 21]: Suman Karumuri, Franco Solleza, Stan Zdonik, Nesime Tatbul, **Towards Observability Data Management at Scale,** ACM SIGMOD Record, Vol.49, No.4, pp.18-23, 2021**.** [https://dl.acm.org/doi/pdf/10.1145/3456859.3456863](https://dl.acm.org/doi/pdf/10.1145/3456859.3456863) [[2021__SIGMOD__Towards Observability Data Management at Scale]] SIGMOD Record 2021の"Towards Observability Data Management at Scale"の論文を読んだ．SlackのObservabilityの経験から，Observabilityデータの管理（Observability Data Management System（ODMS）と命名している）データベースの課題を共有し，データベース研究への呼びかけをしている．昨年のSlackのロードバランサの設定まわりの障害の話から始まり，Observabilityの定義とMELT（Metrics，Events，Logs，Traces）の説明，ODMSの設計原則が論述されている． （論文で定義や各データのボリューム感を書いてくれていると，引用により根拠を示しやすくて助かる．） ### Observabilityの定義 > Observability is emerging as a key capability for monitoring and maintaining cloud-native systems to ensure their quality of service to customers [25]. Borrowed from control theory, the notion of observability brings better visibility into understanding the complex behavior of software using telemetry collected from the system at run time [14]. Beyond simple black-box monitoring, observability provides deeper contextual insight about the correctness and performance of systems. Its goal is to minimize time to insight - a critical measure of understanding what is happening in the system, and why. As such, observability is inherently a data-intensive and time-sensitive process that involves humans in the loop... - 実行時にシステムから収集したテレメトリを用いて，ソフトウェアの複雑な動作を理解するための可視性を高める - Observabilityはシステムの正常性と性能に関するより深い文脈的洞察を提供する - その目的は，システムで何が起きているのか，なぜ起きているのかを理解するための重要な指標である「洞察までの時間」を最小化することにある - Observabilityは本質的にデータ指向で，かつ時間的制約があるプロセスであり，そのプロセスには人間が関与する． ### Observabilityデータ ⇒ MELT ![[2021%E5%B9%B4 %E5%95%93%E8%9F%84(%E5%BE%8C) Slack%E3%81%AEObservability%E8%AB%96%E6%96%87%EF%BC%8C%E3%83%88%E3%83%83%E3%83%95%E3%82%9A%E4%BC%9A%E8%AD%B0%E3%81%AE%E8%AB%96%E6%96%87%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9%E3%81%AA%E3%81%A8%E3%82%99/ScreenShot_2021-03-22_at_10.54.33.png]]%20Slack%E3%81%AEObservability%E8%AB%96%E6%96%87%EF%BC%8C%E3%83%88%E3%83%83%E3%83%95%E3%82%9A%E4%BC%9A%E8%AD%B0%E3%81%AE%E8%AB%96%E6%96%87%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9%E3%81%AA%E3%81%A8%E3%82%99%20bf56aea2dfbe4cc29436d824ef1e4344/ScreenShot_2021-03-22_at_10.54.33.png) - Metrics: ゲージやカウントのような数値データ - Slackでは12TB/day (compressed)， 保持期間が30 days - Events: システムイベントに関する高度に構造化されたデータ - 250TB/day(raw), 3-24 months - （HTTPのアクセスログのような，HTTPメソッドとステータスコードなど，有限のセットの組み合わせ） - イベントのデータモデル、クエリ、アクセスパターンは、ログのそれとは大きく異なるため、我々はこれらを別個に分類 - Logs: 構造化されていない文字列のログ - 90TB/day (raw) , 7 days - Traces: リクエストの実行経路のグラフ - 実行時間のDAG - 2TB/day (raw), 14 days MELTの共通特性 - Data: immutableでappend-only．バースト性がある． - Query: 97%以上が24時間以内のデータ． - LifeCycle Management: 長期的な傾向を調べる場合や、法的/ビジネス的な目的で過去のデータが必要．新しいデータと過去のデータを同時に扱う必要性がある． ### ODMSの設計原則 1. リアルタイムデータとヒストリカルデータの管理を切り離す 2. MELTデータのライフサイクル管理を統一する 3. MELTデータに対する単一の問い合わせインターフェースを提供する。 - Polystoreのようなプラガブルストレージアーキテクチャが適している 4. クラウドネイティブな分散型デプロイメントをサポート - 読み込みと書き込みの両方が非常にバースト的な性質を持つため、システムの様々な層が分散され、変化するワークロードに対応する必要がある ![[2021%E5%B9%B4 %E5%95%93%E8%9F%84(%E5%BE%8C) Slack%E3%81%AEObservability%E8%AB%96%E6%96%87%EF%BC%8C%E3%83%88%E3%83%83%E3%83%95%E3%82%9A%E4%BC%9A%E8%AD%B0%E3%81%AE%E8%AB%96%E6%96%87%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9%E3%81%AA%E3%81%A8%E3%82%99/ScreenShot_2021-03-22_at_11.14.12.png]]%20Slack%E3%81%AEObservability%E8%AB%96%E6%96%87%EF%BC%8C%E3%83%88%E3%83%83%E3%83%95%E3%82%9A%E4%BC%9A%E8%AD%B0%E3%81%AE%E8%AB%96%E6%96%87%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9%E3%81%AA%E3%81%A8%E3%82%99%20bf56aea2dfbe4cc29436d824ef1e4344/ScreenShot_2021-03-22_at_11.14.12.png) LambdaアーキテクチャよりもPolystoreアーキテクチャ． この設計の初期プロトタイプを構築し、Slackの本番データでテストを行っている．