要約

  • PerconaとCorootは9月10日、Coroot Percona EditionをPerconaの顧客へ提供する提携を発表した。PMMのデータベース監視を補完する位置付けだ。
  • 原因の仮説、AIによる説明、サポートへの引き継ぎは別工程となる。製品ページでは、直接の問い合わせ起票がなお開発予定に含まれる。

最初に相談されたチームが直せるとは限らない

アプリの遅延について最初に連絡を受けるのがデータベース担当でも、原因となる部品を管理しているとは限らない。9月10日に発表されたPerconaとCorootの提携は、このチーム間の調査に関わる。Coroot Percona Editionは、アプリ、ネットワーク、基盤の状況を、Percona Monitoring and Management、略称PMMが示すクエリ、複製、エンジン内部の情報に加える構想だ。

PMMを廃止する発表ではなく、相互補完である。狙いは、ある担当が見つけた症状を、別の担当が使える証拠へつなぐ時間を短くすることにある。ただし、新版の価格や顧客の復旧時間がどれだけ改善したかという測定結果は示されていない。

発表は、データベースに関する発見をPercona Supportの案件へ渡す流れを説明している。一方、リンク先の製品ページは早期アクセスを募集し、診断資料を自動添付して直接起票する機能、データベースの深い原因分析、知識ベースを利用したAIを開発予定に置いている。実際の提供範囲を確認すべきであり、すべてを一般提供済みと読んではならない。ただし、早期利用者が一部機能も使えないと断定できる資料でもない。

原因候補を作る処理と、文章にする処理

Corootの原因分析の文書は工程を分けている。まず、影響を受けたサービスから依存関係をたどり、異常と観測データを比較する。ここでは大規模言語モデルを使わず、機械学習の手法で原因候補と裏付ける信号を得る。その後、言語モデルが結果を説明し、対応案を示す。

この記載された分析経路でモデルに送るのは、選別した発見事項であり、すべての生データではない。読みやすい説明は、その前段の診断に依存する。なお、Corootのほかの機能もすべて同じ言語モデルの使い方をするという意味ではない。

インシデントの文書も、出力を考えられる原因と位置付け、各仮説の根拠となるグラフを確認できるとしている。案件を引き継いだ技術者が、対象時間、依存関係の経路、別の説明を理解できるかが、具体的な検証項目になる。

例えば、遅延の疑わしい原因がデータベースエンジンではなく、共用基盤にある場合を考える。これは説明用の仮定で、顧客事故の報告ではない。観測範囲が広がれば担当チームを探しやすくなるが、データベースの支援担当に基盤変更の権限が自動的に与えられるわけではない。見えるソフトウェアすべてに支援契約が拡張されるわけでもない。

保存先とAIへの送信先を分けて確認する

Perconaは自社管理や完全隔離環境での導入を掲げる。一方、CorootのAI設定文書は、記載された外部モデルとの連携に各提供者の接続先への通信を求めている。観測データの保存先が社内でも、すべてのAI要求が社内で処理されるとは確認できない。

隔離環境では、モデルと通信経路を明示して合意する必要がある。生データ全量を送らなくても、選別された診断結果には運用情報が含まれ得る。これは導入条件の確認であり、情報漏えいの指摘ではない。

提携は、周辺層の証拠をデータベース専門家へ届ける機会を作る。商業的な成果は、適切な担当が案件を受け、変更が承認され、アプリの復旧が確認されて初めて測れる。今回の発表はその方向を示した段階だ。