## Summary for Tweet #SRE論文紹介[Young+,SIGMOD2016]:DBの性能診断を半自動化するために、DBの大量の統計指標を用いて、1）異常と思われる時間領域をユーザーが選択あるいは自動検知し、異常の診断的な説明を依頼し、2）述語（"latency>100ms^network_recv<10KB"など）や述語から構成される因果モデルによって、生じる可能性のある原因という形で異常を説明し、3）同じ原因を共有する複数の因果モデルを統合することで、因果モデルの信頼性を高める手法DBSherlockを提案している。 アルゴリズムだけでなく、提案範囲は性能問題の分析のためのUIまでおよび、アルゴリズムの各パラメータをDBAが調整しながら対話的に問題を診断していくツールとして設計されている。実装はDBSeerプロジェクトに統合されている https://dbseer.org/ 。 [Young+, SIGMOD2016]: DBSherlock: A Performance Diagnostic Tool for Transactional Databases paper: https://web.eecs.umich.edu/~mozafari/php/data/uploads/sigmod_2016.pdf ## Memo - ミシガン大学の著者らによる会議論文。[[DBSeer]]プロジェクトの成果のひとつ。DBSherlockの実装はDBSeerのモジュールとして組み込まれている。 - DBの性能診断は、同時に実行され競合する多数のトランザクションが複合的に相互作用し、分離が困難な非線形効果をもたらすため、困難である。膨大な量の詳細な統計情報やログファイル（MySQLなら260以上、商用DBMSなら何千単位の統計指標）があり、これらのデータから性能問題を分析するツールがまだなく、DBAが手動で検査する必要がある。 - DBSherlockは、1）異常と思われる領域を選択し、異常の診断的な説明を依頼し、2）述語や因果モデルによって生じる可能性のある原因という形で異常を説明し、3）同じ原因を共有する複数の因果モデルを統合することで、因果モデルの信頼性を高める。 - ![[Pasted image 20230504165008.png|400]] - 述語成：異常領域$A$、正常領域$N$、入力データ$T$が与えられたとき、$A$の入力タプルを$N$のタプルからよく分離するように、各述語$Pred$が以下のような形式をとる述語の接続を生成する（カテゴリカルな包含も含む）。SP（分離力）は式（１）のように定義され、述語を満たす異常領域のタプルの比率を、述語を満たす正常領域のタプルの比率で差し引いている。分離力の高い個々の属性を抽出することが目的。 - ![[Pasted image 20230504170035.png|400]] - 述語の例：network_send < 10KB ∧ network_recv < 10KB ∧ client_wait_times > 100ms ∧ cpu_usage < 5 - 述語の抽出アルゴリズム：1）パーティション空間と呼ばれる各属性の離散化され た領域を作成し、2）各パーティショ ンに3つのラベルのうちの1つをマークし、3）NormalパーティションとAbnormalパーティションのラベルをEmptyパーティションに置き換えることで、いくつかのパーティショ ンをフィルタリングし、4）Emptyパーティションで区切られたAbnormalパーティション とNormalパーティションが連続するブロックが大きくなるため、EmptyパーティションをNormalかAbnormalにラベル付けし、ギャップを埋め、5）異常の実際の原因と関連する属性を抽出するために、属性の値を[[正規化]]し、閾値$\theta$を基に選択し、連続するAbnormalパーティションのブロックが1つしかない場合にのみ、属性$Attr i$の述語候補$Pred$を抽出する。 - ![[Pasted image 20230504170240.png|400]] - パーティション幅は$(Max(Attr_{i})- Min(Attr_{i}))/R$（R:パーティション数） で決定され、数値属性に対する述語の閾値は、パーティションの上限下限から（おそらく）決定される。 - 属性のセマンティクスに関するドメイン知識の取り込み：根本原因の二次的な症状を刈り込むことが目的。例えば、DBMS CPU使用率はOS CPU使用率に影響を与えるが、 その逆はないなどのルールを取り込む。「DBMS C PU使用率」→「OS CPU使用率」については、スレッド数などがOS CPU利用率に影響を与える可能性があるため、属性間の独立性を[[相互情報量]]に基づき検定する。2つの属性が独立性検定にパスした場合、Attr i → Attr j という規則は適用されない。 - 因果モデル：生の述語を超えて、より人間が読める記述的な説明を提供する。エンドユーザがラベル付けした二値の外生変数を「原因変数」(Log Rotation)と「結果述語」（3つ）から構成される。ユーザーから原因変数をフィードバックされ、下図のように述語とリンクさせる。将来の診断問い合わせごとに、因果モデルの信頼度を計算し、信頼度が閾値$\lambda$より高ければ、この原因変数が報告される。 - ![[Pasted image 20230504172545.png|200]] - 因果モデルの信頼度：分割空間におけるその結果述語の平均分離力と定義される。モデルの原因変数が真であれば、その結果述語もそのパーティション空間において高い分離力を示す可能性が高いという仮定を置いている。 - ![[Pasted image 20230504173236.png|300]] - 因果モデルの統合により、不要で関連性の低い効果述語を排除し、同じ原因によって引き起こされる異なる異常インスタンスに関連する効果述語を適用する。統合プロセスは、1）両モデルに共通する属性に 該当する結果述語のみを残す、2）同じ属性に関する2つの述語を、両者の境界を含む1つの述語に統合する。 - 異常検知：前処理と[[DBSCAN]]クラスタリングにより、異常の視覚領域を明確にする。前処理は、各属性を正規化後に、時系列に急激な変化を伴う部分配列をもつ属性を選択する。選択方法は、時系列中のサイズτの部分配列としてスライディングウィンドウ$w$から、式（４）ポテンシャルパワー（PP）に対する閾値判定である。PPは中央値フィルタを用いて、各ウィンドウ内の全体の中央値と値の中央値との差の絶対値の最大値を意味する。選択された属性に対してクラスタリングするために、DBSCANの$epsilon$をk-dist関数によりk番目の最近傍の距離のリストLkを構築し、$max(L_k )/4$として設定するのが経験的に最良であった。データ項目の総数の20%未満のサイズを持 つすべてのクラスタのポイントを返す。 - ![[Pasted image 20230504174339.png|400]] - 実験設定：MySQL 5.6.20に対して[[TPC-C]]ベンチマークをかけながら、stress-ngによりCPU、I/O、ネ ットワーク異常を注入する。2分間の通常活動と1つ以上の異常で、異常の長さは30秒から80秒まで、5秒刻みで変化する。 - 実験結果：Table RecoveryとFlush Log/Tableによる異常は、因果関係モデルの中で最も低い信頼度である。DBMSがあまりにも多くのディスクI/Oを実行したという共通の特徴をもつ。 因果モデルの統合により、平均して元のモデルより30%精度が高くなり、θの値が小さいほど各因果モデルの述語が多いほど最大となる。また、データセットが増えるほど精度は高くなる（図８c）。ドメイン知識を組み込むと、85%前後から94%前後まで精度が向上する。 - ![[Pasted image 20230504175613.png|300]] - ![[Pasted image 20230504172311.png|600]] - 今後の課題は、高い信頼度で原因を診断したときに、自動的に修正アクションを実行する。DBAが取ったアクションを文書化し、同じ異常の将来の発生を示唆するものとして使用する - 感想 - 数値やカテゴリデータの探索空間を狭めるために、説明述語を生成する方式は、出力の説明性を高める意味で、とても興味深い。UIまで含めてシステムが設計されているため、アルゴリズムの入力と出力がどのようにユーザーから提供されあるいはツールがユーザーに提供するか、各内部パラメータをユーザーがどのように調整するかが明瞭であることはすばらしい。UIまで含めていることは、[[2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platfor|GRANO]]と類似する。実験ではUser Studyまで行っておりUIの信頼性もある程度は評価されている。 - DBSCANによるクラスタリングになんの意味があるかがわかりにくいが、おそらくユーザーが似たような異常領域をもつ属性リストを確認するためであろうと推測する。 - 実験で、異常時間を変化させているのは他文献ではあまりみられないが、ちゃんとしている印象がある。 - ユーザーが原因変数をDBSherlockにフィードバックするときに、原因変数の言語揺れなどはどの扱うのだろうか。 - 今後の課題のDBAがとるアクションの文章化は、[[notes/data-science/LLM]]で実現できる可能性がある。 - [[Interactive AIOps]]に組み込みたい。 ## Abstract オンライントランザクション処理（OLTP）システムの運用は、データベース管理者（DBA）に求められる最も困難なタスクの1つです。企業は、ミッションクリティカルでリアルタイムなアプリケーションをサポートするためにOLTPデータベースに依存しているため、データベースのパフォーマンス低下は収益とユーザーエクスペリエンスに大きな影響を及ぼします。そのため、DBA は常に監視し、診断し、性能の低下を修正します。 残念ながら、OLTP パフォーマンス問題のデバッグと診断を手作業で行うことは、非常に面倒であり、自明ではありません。OLTPデータベースのパフォーマンス問題は、単一の遅いクエリに起因するのではなく、多くの場合、同時実行および競合する多数のトランザクションが複合的に作用し、分離が困難な非線形の効果をもたらすことに起因しています。リクエスト量、トランザクションパターン、ネットワークトラフィック、データ分布の急激な変化により、これまで豊富にあったリソースが不足し、性能が急降下することがあります。 この論文では、DBAがOLTPデータベースのパフォーマンス問題を迅速かつ確実に診断するのを支援する実用的なツールを紹介します。システムのライフタイムを通じて収集された何百もの統計情報と設定を分析することにより、我々のアルゴリズムは、潜在的な原因の小さなセットを迅速に特定し、DBAに提示します。DBAによって確立された根本原因は、今後の診断を改善するために、新しい因果関係モデルとして我々のアルゴリズムに再導入される。実験によると、本アルゴリズムは最新のアルゴリズムと比較して、正しい説明を見つける精度が大幅に向上している。 [[2016__SIGMOD__DBSherlock―A Performance Diagnostic Tool for Transactional Databases__translations]]