## Memo - [[博士論文参考文献]] - [[参考博士論文集]] - [[研究室内研究会発表 202301 アウトライン]] - [[2022年度IPSJ研究会推薦 博士論文速報]] - [[2021年度IPSJ研究会推薦 博士論文速報]] - [[予備審査修正点]] - [[博士論文 謝辞]] ## Title - A Study on Loads of Instrumentation, Storage, and Mining in Observation Systems for Cloud Applications - クラウド型アプリケーションの観測システムにおける計測・保存・解析の負荷に関する研究 - A Study on Instrumentation, Storage, and, Mining Loads in Cloud Applications Monitoring - クラウドアプリケーション監視における計測、保存、マイニングの負荷に関する研究 - A Study on Load Reduction of Instrumentation, Storage, and, Mining in Cloud Applications Monitoring - A Study on Scaling Monitoring Systems for Massive Telemetry Workloads in Cloud Applications. - A Study on Monitoring Mechanisms Scaled for Large Scale Telemetry Workloads in Cloud Applications. - クラウドアプリケーションにおける大規模なテレメトリワークロードをスケーリングするモニタリング機構に関する研究。 - A Study on Monitoring Mechanisms for Scaling Large Telemetry Workloads in Cloud Applications - クラウドアプリケーションにおける大規模なテレメトリワークロードのスケーリングのための監視メカニズムに関する研究 - A Study on Scaling Large Telemetry Workloads in Cloud Applications - クラウドアプリケーションにおける大規模なテレメトリワークロードのスケーリングに関する研究 - A Study on Scaling Large Telemetry Workloads for Cloud Applications Operation - A Study on Techniques for Scaling Large Telemetry Workloads for Cloud Applications - "Techniques for Scaling Large-Scale Telemetry Workloads in Cloud Applications with Low Operational Complexity" - Scaling Large-Scale Workloads of Telemetry for Managing Cloud Applications - Scaling Large-Scale Telemetry Workloads for Efficient Management of Cloud Applications - Scaling Telemetry Systems for Cloud Applications: Efficient Methods for Instrumentation, Storage, and Mining - Effectively Scaling Telemetry Workloads in Cloud Applications: Techniques for Instrumentation, Storage, and Mining - クラウドアプリケーションにおけるテレメトリーワークロードの効率的なスケーリング：計測・保存・マイニングのための技術 ## Abstract クラウドアプリケーションは高い信頼性が要求される一方で、変更に対する拡張性を確保するためにソフトウェアがモジュール化されているため、複雑な分散システムとして構成される。 ソフトウェアエンジニアは、稼働中の複雑なシステムを認知するために、一般的に、システムが生成するテレメトリーデータを計測、保存、マイニングするためのデータ処理システムを構築する。 より高精細の認知のために、テレメトリデータは増加の一途をたどっているため、テレメトリデータ処理の各ステージ（計測、ストレージ、マイニング）にてコンピューティング資源消費が増加している。 結果として、観測対象システムへ与える余分なオーバーヘッド、テレメトリーデータ処理システムに余剰のコスト、マイニングの効率と正確性が悪化する。 本論文では、我々はテレメトリデータ処理の各ステージに対して、大規模なテレメトリワークロードをスケールさせるための技術を提示する。 収集される多くのテレメトリデータのうち必要なデータは限られることに着目し、ユースケースを考慮したうえで、計測ステージでは冗長なデータの集約、マイニングステージでは不要なデータを削減することを目指す。 ストレージでは、様々なアプリケーションやマイニングのユースケースに適応する必要があるため、取り込むデータ量を低減するのではなく、処理効率性を向上させる。 第一に、計測ステージでは、トポロジー指向のテレメトリデータをOSカーネル層でネットワーク通信をフックする形で計装する際に、TCP接続やUDPパケットレートが高い環境では、計測負荷が大幅に増加する課題がある。その課題に対して、OSカーネル内で通信フローを集束させるように計装し、カーネルからユーザー空間へテレメトリデータをコピーするコストを低減させる。 第二に、ストレージステージでは、時間指向のテレメトリデータの系列数が増大するときに、データベース管理システムのインデックス構造が木構造のときに、探索が低速になる課題がある。そこで、探索計算量が小さいハッシュ表に向いたメモリベースDBと、長期保存に向いたディスクベースDBとを階層化するアーキテクチャを提案する。 最後にマイニングステージでは、障害の故障箇所特定について、障害に無関係なテレメトリデータが推論時間や特定時間を悪化させている課題がある。そこで、我々は、前処理で障害に無関係な時系列を自動削減する。 実験による評価の結果、各提案法がベースラインに対して処理効率や正確性を向上させていることを確認した。 本研究の貢献は、まず、クラウドアプリケーションにおけるテレメトリデータのワークロードに関する計測、保存、マイニングの基本概念とワークロード増大に対する課題を体系的に整理していることにある。もうひとつの貢献は、未解決の各課題について、within the framework of widespread technologies and echosystems to maintain low additional burdens on engineers、技術的に解決していることである。 これらの貢献は、テレメトリデータのワークロード増大に対して、計算機資源の過剰消費の低減、より迅速な障害復旧を可能とし、結果として経済的損失の削減やエンドユーザーからみる信頼性の向上に寄与する。 各提案方式については、データ計測時のCPU処理、データ保存時の書き込み、データマイニングのCPU処理が増加する。 - Background - Current information systems are generally provided through cloud computing via the Internet. - An engineering approach is needed to improve both change frequency and reliability for complex systems. - Reliability of onlne services depends on manual operations with software engineers. - Engineers usually instrument, store, and mine operational data of cloud applications (monitoring) - Problem - Large volume of operational data increases the loads in the following phases. - Instrumentation loads - システム内部の深く、より細粒度のデータを計測できるようになった結果、データ数が増大する - - Storage loads - - Mining loads - - This doctorial dissertation addresss the outstanding issues of instrumentation, storage, and mining loads for systems observation when operational data grows. - 3つのうち、Instrumentation loadsとStorage loadsの問題は産業界において広く知られているが、Mining loadsについては学術・産業界ともにほとんど知られていない。 - Proposal 1. A method to reduce CPU load when instrumenting spatial data 2. An architecture that both reduces the metric insertion load and lengthens the retention period 3. A framework for fast reduction of problem space for increasing number of operational multivariate time series data - Contributions - より多くの運用データを収集可能となる -> エンジニアが精緻にシステム状態を認識できる ## Terminology - Cloud Application - Site Reliability Engineering - Monitoring Loads - Instrumentation loads - Storage loads - Mining loads ## 1. Introduction 0. クラウドが普及していること。 1. クラウド上の分散アプリケーションが、耐障害性と多様な機能やワークロードを実現するために、要素数、異種性と依存関係の観点で複雑化していること。 2. エラーや遅延の悪化が分散システムのネットワークごしに伝搬するため、故障が大規模な障害につながりやすいこと。 3. クラウドの障害の損失が大きいこと。 4. ビジネスやセキュリティの要求からアプリケーションとその基盤となる下位システムには頻繁な変更が求められること。 5. ハードウェア故障起因よりも、変更やオペレーションミスなどの人的要因の障害が増えていること。 6. 高い信頼性と変更速度の両立が求められている。そのためには、障害が発生することを前提として、障害を効率的に検知、診断、緩和されることが重要である。 7. 専門家であるエンジニアでさえ自動化された複雑なシステムの振る舞いを認知することが難しいことは障害管理のハードルとして知られている。 8. 複雑なシステムを理解するために、テレメトリデータが重要であること。 ### 1.1 Motivations **クラウドコンピューティングの普及とそのアプリケーション構成：** クラウド・コンピューティングは、ソーシャル・ネットワーキング、電子商取引、メディア・ストリーミング、決済、IoTなどのオンライン・サービスを支えるアプリケーションを展開するための一般的なプラットフォームとなっている。 幅広い計算機資源へのオンデマンド・アクセスを提供することで、クラウドプラットフォームは、複数のマシンやデータセンターにまたがる分散アプリケーションの構築と実行を可能にし、従来よりも優れたスケーラビリティと性能を実現した。 分散クラウドアプリケーションには、複雑なタスクを実行するために、ネットワーク上で相互に通信する、モジュール化された複数のコンポーネントが含まれている。 直近の10年で、大規模なエンタープライズ組織が管理するアプリケーションでは、細粒度の組織単位が独立して開発、デプロイ、スケーリングが可能となるようなより細かく特化したサービスに分解されるマイクロサービス・アーキテクチャが採用されている。 **クラウドアプリケーションの障害：** これらの複雑なクラウドアプリケーションは、コンポーネントが相互にネットワーク接続されているため、あるマイナーな故障の影響によるエラー発生や遅延増加が、ネットワークを通じてシステム内部を伝搬し、その結果として障害を引き起こしやすい。[[Fault - Failrue - Error サイクル]] 大規模な障害は、顧客のサービス利用不全と大きな経済的損失を発生させる。 [[クラウドの信頼性低下による損失が書かれた参考文献]] したがって、クラウドアプリケーションは、24時間365日中断のないサービスを高い信頼性で保証する必要がある。 Reliability refers "The ability of a system or component to perform its required functions under stated conditions for a specific period of time". [[Software Reliability]]より。 そこで、高信頼性をもつクラウドアプリケーションを設計するために、長年の分散システムの研究の努力から確立されているソフトウェアレベルのフォールトトレランス技術が採用されている。[[1985__SRDS__Why Do Computers Stop and What Can Be Done About It?|Gray+, SRDS1985]] > These applications typically serve massive user bases, where even minor software glitches can result in significant losses due to service outages or degraded service quality. Therefore, cloud applications need to ensure uninterrupted 24/7 service, with high reliability. **変更とそれに基づく障害の増加、障害管理の必要性（人的要因）：** 現代では、ビジネスやセキュリティの要求からクラウドアプリケーションには頻繁な変更や更新が求められていることから、コードや設定などの変更起因の障害が支配的である。[[2023__ISSRE__How to Manage Change-Induced Incidents? Lessons from the Study of Incident Life Cycle|Zhao+, ISSRE2023]], [[2023__ICSE__An Empirical Study on Change-induced Incidents of Online Service Systems|Wu+, ICSE2023]] [[State of DevOps Report]] そのため、現代の分散アプリケーションには、高信頼性と高頻度の変更を両立することが要求されている。 それらの両立のためのアプローチの一つが、障害が発生することを前提として、オペレーターが障害を効率的に検知、診断、緩和するための障害管理方法を確立することである [[2003__USENIX Symposium__Why do Internet services fail, and what can be done about it?]]。 1985年時点ですでに、高度に自動化された制御システムに対して、人間のオペレーターの貢献が重要であることがよく知られている。 [[Ironies of Automation]] しかし、クラウドアプリケーションの多機能性と異種性から来る複雑なシステムの動作を人間が認知することは困難である。 - 40年前からハードウェアの故障よりもソフトウェアの不具合と運用ミスが障害の主要因であった。 [[1985__SRDS__Why Do Computers Stop and What Can Be Done About It?]] **テレメトリーシステム：** そこで、エンジニアがクラウドアプリケーションの複雑なシステムを観測可能とするために、テレメトリーデータを収集し、収集したデータを手動あるいは自動で解析することが一般的である。 エンジニアはこれらの一連の処理を担うテレメトリーシステムをアプリケーションとは別に構築する。 テレメトリーシステムでは、まずアプリケーションやその基盤となる下位層のハードウェアとソフトウェアに事前に計装され、送信され続けるテレメトリデータはストレージに追記され続ける。 次に、インシデントなどのイベントが発生する時点で、ダッシュボードツールや障害診断ツールがストレージに問い合わせ、得られたデータを可視化あるいはminingする。 テレメトリーシステムにより、エンジニアはデータ駆動でシステムの問題点を調査できる。 - instrumemtation: - storage: - mining: - [[2024__Dissertation__Towards Effective Performance Diagnosis for Distributed Applications]] - [[2024__Dissertation__Towards Cloud-Scale Debugging]] **テレメトリーシステムのワークロードの増大**： 近年では、より精緻にシステムの振る舞いを理解するために、複数の異なるモーダルをもつ、より細粒度のテレメトリーデータが要求されている。[[2021__SIGMOD__Towards Observability Data Management at Scale]]、[[2022__Empirical Software Engineering__Enjoy your observability - An Industrial Survey of Microservice Tracing and Analysis]] そのため、テレメトリーシステムのワークロードが増大している。計装のステージでは、テレメトリデータを取り出すための負荷がアプリケーションの性能劣化や計算資源の枯渇を招く可能性がある。 ストレージでは、大量のテレメトリデータの取り込みと保持が発生する。ストレージのステージにおけるテレメトリーデータの規模は、[[テレメトリデータの規模事例]]にて示されている。 miningステージでは、大量のテレメトリデータを統計解析すると問題空間が拡大されるため、正確性または実行速度が低下しうる。\cite{2021_causal_eval} [[2021__ACSOS__Causal Inference Techniques for Microservice Performance Diagnosis - Evaluation and Guiding Recommendations|Wu+, ACSOS2021]] **テレメトリーワークロードの増大に対する既存のアプローチ：** 各ステージにおけるテレメトリーワークロードの増大の課題に対する既存の解決アプローチは次のようなものがある。 計装ステージでは、データをサンプリングまたは集約することにより、アプリケーションから取り出すデータ量を削減する。 [[Tracing Sampling Papers]] 保存ステージでは、取り込み効率を向上させる、圧縮、ワークロードの規模に対して水平スケーリングさせるテクニックがある。 miningステージでは、前処理段階で、ノイズ削減あるいは特徴量削減と呼ばれる手法を適用し、不要なデータを削除するテクニックが知られている[[2011__DSN-W__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs|Rao+, 20112011]]、[[2018__TNSM__Mining Causality of Network Events in Log Data|Kobayashi+, TNSM2018]], [[2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]。 - [[クラウドシステムの概要図]] - [[モニタリング関連システムの概要図]] - [[ネットワークログの因果解析による障害の原因究明支援技術に関する研究]] - [[2020__ESEC-FSE__Graph-Based Trace Analysis for Microservice Architecture Understanding and Problem Diagnosis]] > 負荷の観点では、データの生成元であるInstrumentation Layerでなるべくデータ片を集約することで、Storage LayerやMining Layerの負荷も同時に削減可能である。しかし、ドメインエキスパートであっても、どのデータが必要であるかは、事前にはわからない。そこで、Mining Layerの精度に影響しないInstrumentation Layerでの集約法や削減法が必要である。Mining Layerでそのときのコンテキストにあわせた即時の集約・削減法も有効である。 **Operability of managing telemetry systems itself** - 導入容易性：既存システムにその技術がどれだけ容易に適用できるか？ - standard technologies, techniques, protocols, implementations - maintainability - 習熟している - パラメータが少ない - サービス化されている - instrumentation: non-intrusive and eBPF - storage: - mining: unsupervisor learning and few hyper parameters ### 1.2 Research Objectives > なぜこれらの残余課題を選択したのか？ 本研究では、テレメトリーワークロードの増大の問題に対して、既存アプローチではカバーしきれていない次の残余課題にタックルする。 To clarify the remaining challenges, we categorize telemetry data into two types: time-oriented data and topology-oriented data. Time-oriented data is a numeric or string time series data and topology-oriented data is a set of data fragment that can constract the topology of function or network call. 1. [instrumentation]\: トポロジー指向データをアプリケーション非侵入型で計装するには、OSカーネル層に侵入してネットワークコールを傍受する。ナイーブな計装は、カーネル内で発生するTCP/UDPパケットの発着・受信などの細粒度のイベントごとに、カーネル空間からユーザー空間へデータ片をコピーする。その結果、アプリケーションが動作するホストのCPU利用が顕著に増大する。そこで、[[2020__SAC__Black-box inter-application traffic monitoring for adaptive container placement|Neves, SAC2021]]では同一のフローに属するパケットをカーネル内で集約することにより、コピー回数を低減させる。しかし、この集約法は、新規のTCP接続やUDPパケットレートが高くなるほど、カーネルからユーザー空間へコピー回数は増大する。一部のアプリケーションでは、特にDBMSに問い合わせる際に、一旦確立したTCP接続を再利用することが難しい。大量の新規送受信フローがある環境でも、低いオーバーヘッドでネットワーク・コールを発見できるカーネル・トレースのスケーリング技術とは？ 2. [storage]\: 数値的な時間指向データの大量の時系列をストレージに取り込むために、シェアードナッシングで水平にスケールアウト可能な既存のディスクベースDBMSが採用されている。ディスクベースDBMSのインデックス構造は、ディスクのアクセス効率のため、B-Treeなどのツリーベースの構造が採用される。しかし、系列数が大きいとインデックスが保持するキー数も増大するため、インデックス更新時のツリー探索の時間計算量が対数オーダーで増大する。定数時間でアクセス可能なハッシュ表のようなデータ構造のほうが適しているが、ハッシュ表が採用されるメモリベースDBMSは、大量のデータを保持するには、cost-per-bitの観点でディスクベースDBMSよりも不利である。どのようなアーキテクチャが、既存のDBMSの上で、数値時間指向データの取り込みパフォーマンスを最適化し、長期保存コスト効率を削減できるのか？ 3. [mining]\: 機械学習により数値的な時間指向データ駆動で自動化される故障箇所特定が、大量の時系列が入力されたときの精度や実行効率の低下を防ぐために、その前処理段階で異常のないまたは類似の系列を除去するテクニックが知られている。 ### 1.3 Contributions The main contributions of this dissertation are as follows. 1. The largest contribution in this thesis is the first study of focusing on various "loads" of instrumentation, storage and mining for cloud application monitoring. - クラウドアプリケーションのテレメトリー処理システムの計測・保存・解析の基本概念とスケーリングに関する課題を体系的に整理した。 2. We propose several techniques to scale telemetry workloads for three cases: (1) Call graphing, (2) TSDB , and (3) Mining for Fault localization. 3. We implement the proposed techniques and perform detailed experiments and show the usefulness of the proposed techniques. miningについて、故障箇所特定モデルは得意不得意があるため、様々なモデルに対して透過的であることが望ましい。 ### 1.4 Thesis Organization ## 2. Background 博士論文全体を通底するようなレベルでの関連研究を提示する。 - Failure Managementに関する関連研究 - Cloud - [[2024__Dissertation__AI-based Proactive Failure Management in Large-scale Cloud Environments]] - Cloud Application - [[2024__Dissertation__Towards Cloud-Scale Debugging]] - [[2024__Dissertation__Towards Effective Performance Diagnosis for Distributed Applications]] - Network - [[2024__Dissertation__A Data Mining Perspective on Explainable AIOps with Applications to Software Maintenance]] - [[ネットワークログの因果解析による障害の原因究明支援技術に関する研究]] ### 2.1 Cloud Application and its Reliability - Cloud ComputingにおけるCloud Applicationの位置づけ - Cloud Applicationの典型的なシステム構成 - [[2024__arXiv__The trade-offs between Monolithic vs. Distributed Architectures]] - [[2003__USENIX Symposium__Why do Internet services fail, and what can be done about it?]] - scaling - load balancing - one size fits all - redundancy - [[クラウドの耐障害性のためのオニオンモデル]] - [[SRE]] - オニオンモデルを総合的に高信頼化。 - [[The Morning Paper on Operability]] - [[2007__LISA__On designing and deploying internet-scale services]] - [[2002__IEEE Internet Computing__Architecture, operation, and dependability of large-scale Internet services - three case studies]] - [[2010__SoCC__Characterizing Cloud Computing Hardware Reliability]] クラウドアプリケーションのアーキテクチャは、2000年代初頭から現代に至るまで、いくつかの拡張はなされているものの、その基本構造は変化していない。 ### 2.2 Failure Management and its Monitoring - [[2024__JSS__Change impact analysis in microservice systems - A systematic literature review]] - オニオンモデルの最外殻層における[[Failure Management]] - Failure Detection - Failure Diagnosis - Fault Localization - Failure Mitigation - Failure Managementの基盤はモニタリング - 昨今では発展的に[[Observability]]と呼ばれる。 - Monitored Data Propeties - Time Series Data - Metrics, Logs - Network Graph Data - Tracing and Call Graph - [[コールグラフを使用するAIOps Fault Localization論文]] - [[2022__TPDS__An In-depth Study of Microservice Call Graph and Runtime Performance]] ### 2.3 Instrumentation Load - OS layer - time series - network - TCP short lived connection and UDP heavy workload - Application layer - time series - network ### 2.4 Storage Load - [[Time Series DataBase|TSDB]] - [[Tracing Sampling Papers]] ### 2.5 Mining Load - Time Series Data Mining - [[2022__VLDB__Anomaly Detection in Time Series - A Comprehensive Evaluation]] - Network Data Mining - [[2023__Physics Reports__Signal propagation in complex networks]] - Read Storage Loads - - [[2011__DSN-W__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]] - [[2018__TNSM__Mining Causality of Network Events in Log Data]] ### 2.6 Research Motivation - 負荷については、負荷削減に最適化されたアーキテクチャやデータ構造を設計・採用すれば、負荷の削減率は最大となる。しかし、特化型の解決策はエンジニアに追加の負担を課すことになる。そのため、 広く普及する技術の枠組みの中で課題を解決する。 - 収束法 - HeteroTSDBは汎用DBによるマネージドサービス前提 - MetricSifterは教師なし学習と少ないハイパーパラメータ - 非侵入あるいは非変更型の制約の範囲内で、アーキテクチャや手法を提案する。 - NetTracing: [[eBPF]]によるカーネル非変更、アプリケーション非侵入型 - HeteroTSDB: メトリクス用のストレージを新規に構築せず、既存のクラウドアプリケーションの構成要素として広く用いられているDBMSを変更せずに用いる。 - MetricSifter: 既存のFault Localization手法をそのまま使えるようにする。教師あり学習を用いない。 ## 3. Low Overhead TCP/UDP Socket-based Tracing for Discovering Network Services Dependencies ### 3.1 Introduction [[Call Metrics Data]]のようにアプリケーション層のトレースについては集約法が提案されているが、OSカーネル層においても同様の集約が必要である。 [[2022__ICPE__MiSeRTrace - Kernel-level Request Tracing for Microservice Visibility]] アプリケーション非侵入の方式としては例えばこれ。 ### 3.2 Proposed Tracing Method ### 3.3 Experimental Evaluation ### 3.4 Concludion ## 4. A High Performance Time Series Database for Automated Data Tiering in Heterogeneous Distributed KVSs - [[HeteroTSDB]] - [[20200610_HeteroTSDB論文の書き直し]] ### 4.1 Introduction 1. メトリクスのワークロード 2. ワークロードに対するスケーラビリティのためのボトルネック２つ - ingestion throughput - storage capacity - スケーラブルなストレージシステムを設計する上で、重要となるのがOperabilityである。 - [[2021__SIGMOD__Towards Observability Data Management at Scale|Karumuri+, SIGMOD2021]] 3. 既存手法 (Gorilla, Prometheus, InfluxDB, KairosDB) - 既存手法は、時系列データ特化型DBMS方式と、時系列データ指向アプリケーション構成方式に分けられる。時系列データ特化型DBMS方式は、時系列向けのストリーミング圧縮アルゴリズムを用いてデータ量を低減する。性能は高い。一方で、時系列データベースアプリケーション方式は、広く利用されている多目的DBMSであるディスクベースKVSの上に、時系列データの読み書きアプリケーションとして構成する。ディスクベースKVSの採用は、サービス化されたクラスタ自動管理の恩恵を得やすいため、時系列データベースアプリケーション方式のほうが運用複雑性が低い。 - (単一のDBMSで構成する方法と、異種のDBMSで構成する方法がある。) - [[2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database|Gorilla]]は、メモリDBと分散ファイルシステム。定期的にディスクへフラッシュする。 - [[2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems|ByteSeries]] - ByteSeriesはディスクベースの時系列データベースシステムの前に配置することで、ハイスループットなデータ管理を実現できるインメモリキャッシュである。 4. 既存手法の課題 - 運用性を考慮すると、時系列データ指向アプリケーション構成方式のほうが有利である。しかし、ディスクベースDBは新規の時系列を追加する際のインデックスアクセス効率の観点で取り込み効率が低い。ディスク上に配置されるインデックス構造として、シーケンシャルアクセス効率の高いBalanced Treeなどのデータ構造が採用される。1つのメトリックを1つのキーに対応させるのであれば、メトリクス数が増加するほど、キー数も増加する。メトリクス数の増大に対して、Balanced Treeの平均時間計算量は対数オーダーとなる。計算量が定数時間となるハッシュテーブルのほうがより効率的である。しかし、ハッシュテーブルへのアクセスはランダムであるため、ハッシュテーブルは通常メモリベースDBで採用される。メモリベースDBに長期間のデータを保持することはバイト単価の観点で高価である。 5. HeteroTSDB - そこで、我々は、DBMSクラスタの運用複雑性を低く抑えながらも、メトリクス数の増大に対してスケールするように設計された、異種のDBMSを階層化する時系列データ指向アプリケーションHeteroTSDBを提案する。 - HeteroTSDBはメモリベースKVS上に時系列データを取り込み、時間経過をトリガーとして古いデータをディスクベースKVSへ移動させる。 - メモリベースKVSに備えられたハッシュテーブル上に構築されるインデックスにより、メトリクス数が増大したとしても定数時間で新規のメトリクスを追加できる。 - KVS間でデータを粗粒度のバッチでマイグレーションすると瞬間的に移動負荷が過剰に増大するため、メトリクス単位でジッターを加えたTTL（Time to Live）に基づき、細粒度でマイグレーションする。 - 本研究の貢献 - The contributions of this research are summarized as follows. - 我々は、運用性とスケーラビリティを両立可能な、異種のDBMSを階層化する時系列データ指向アプリケーションのためのアーキテクチャを提案する。 - KVS間のTTLに基づく細粒度のマイグレーション方式を提案する。 - We implement a prototype of HeteroTSDB and conduct a detailed performance evaluation. ### 4.2 Proposed Data Tiering Architecture - メモリベースDB上ではハッシュテーブルを採用するが、TSDBには時間レンジスキャンが必要で、通常ハッシュインデックスで対応している。 ### 4.3 Experimental Evaluation - Redis moduleを用いればさらなる性能改善が可能である。 - Limitation - 頻繁にクエリされるデータがメモリ上に保持されているかどうか。 - 多次元インデックスについては未対応だが、拡張可能である。 - TSDBMSと比較した評価はできていない。 - KVS間のデータ一貫性レベルは結果整合性である。マイグレーション中にクライアントからみたときにデータが消失したようにみえる。 ### 4.4 Related Work - [[2023__VLDB__Lindorm TSDB - A Cloud-native Time-series Database for Large-scale Monitoring Systems]] - [[2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems]] ### 4.5 Concludion future work: - 読み出しのさらなる効率性。 - メタデータのインデックス管理や圧縮のためのコンポーネントを追加する拡張性 [[2020__SoCC__ByteSeries - An In-Memory Time Series Database for Large-Scale Monitoring Systems|ByteSeries]] 。ByteSeriesはGorillaの圧縮アルゴリズムを採用し、データ点を効率的に圧縮する。しかし、ByteDanceのプロダクションデータセットでは、メタデータのメモリフットプリントが非常に大きくなっている。したがって、メモリフットプリントを効果的に削減するために、クエリを高速化するためのインデックスを維持しながら、メタデータを効率的に圧縮するメカニズム全体を設計し、実装する。 ## 5. Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications ### 5.1 Introduction > いずれもエンドツーエンドで根本的な原因を直接導き出すことはできない。その代 わりに、因果グラフやトポロジーグラフの特徴表現を学習し、ランダムウォークなどのグラフ中心性計算アプローチと組み合わせることで、根本原因の局所化を2段階に分解し、実装の難易度を高める。 > Instead, they train the feature representations of a causal graph or topology graph and then combine them with graph centrality computation approaches such as random walk to break down the root cause localization into two stages, increasing the difficulty in implementation. [[2024__arXiv__Root Cause Localization for Microservice Systems in Cloud-edge Collaborative Environments]]より ### 5.2 Proposed Feature Reduction Framework ### 5.3 Experimental Evaluation ### 5.4 Concludion ## 6. General Conclusion ### 6.1 Summary - instrumentationにはruntimeのコンテキスト、miningにはユーザーのコンテキストがある。それらを踏まえてデータ量の削減を行う。 ### 6.2 Future Directions - 今後はシステムの各負荷を適応的に制御可能とする新たなフレームワークが必要である。 - 計測フェーズでサンプリングあるいは集約しすぎると、解析フェーズで必要なデータが少ない - [[Incident Response]]後に、必要なデータとそうでなかったデータのフィードバックを人間が行う。 ## Ackowledgements ## Bibliography ## Publications and Awards