Databricksが自ら実践！ データベース信頼性をスケールさせる裏側

要約：
Databricksのエンジニアたちは、自社製品を含むビッグデータ分析ツールを活用し、従来の「事後対応型モニタリング」から「プロアクティブなスコアリング方式」へと転換しました。これにより、顧客への影響が出る前に問題のあるクエリやスキーマ設計を特定・改善できるようになり、データベース利用の効率が大幅に向上しました。実際、あるデータベースではトラフィックが4倍に増加したにもかかわらず、CPU・メモリ・ディスク使用量を抑えたまま運用できています。

Databricksでは、複数のクラウド・リージョン・データベースエンジン上に数千のデータベースを運用し、ユーザーアカウントのメタデータ管理、ジョブスケジューリング、データガバナンスなど多様なユースケースを支えています。これらのデータベースは、ユーザー権限のアトミック更新などの信頼性の高いトランザクション処理や、Genieの会話履歴の高速検索などを支えています。しかし、このような大規模かつ多様な環境において、複数顧客が共有インフラ上でワークロードを動かすマルチテナント構成は、信頼性確保の大きな課題にもなります。非効率なクエリや最適化されていないスキーマは、遅延やロック競合を引き起こし、多くのユーザーに影響を与える可能性があるのです。

本ブログでは、Databricksのエンジニアリングチームが「データドリブンな思考」を軸に、データベースの信頼性をどのように高めていったかを詳しく紹介します。まずは、従来使っていたリアクティブなモニタリング手法とその限界を説明します。次に、クエリログをDelta Tableに取り込み、インシデント時のデータベース利用状況を柔軟に集計・分析できる「クライアントサイド・クエリトレーシング」を導入した経緯を紹介します。さらに、CIパイプラインに組み込まれた「プロアクティブなQuery Scorer」により、潜在的な問題を早期に検知できる仕組みを構築しました。CIで検出されたクエリパターンはJSONとして出力され、ノートブックで処理され、Sparkジョブによって数千のデータベース・数万のクエリ単位でメトリクスが計算されます。
最後に、これらの仕組みを統合した「Database Usage Scorecard」をAI/BIダッシュボード上で可視化し、チームがベストプラクティスに沿って改善を進められるようにしています。

全体を通してのテーマは、「問題発生後に火消し対応する姿勢」から「問題を未然に防ぐ仕組みづくり」への転換です。
この取り組みはDatabricksプラットフォームの信頼性向上にとどまらず、他のチームにとっても、自社の分析基盤を活用して同様の“スコアカード型パイプライン”を構築・最適化するためのモデルケースとなるでしょう。Databricksを選んだ理由は自社インフラとの統合性の高さにありますが、このアプローチは、堅牢な分析基盤を持つあらゆるプラットフォームに適用可能です。

元の反応型アプローチ - サーバーサイドメトリクス

初期のころ、我々のデータベース問題へのアプローチは大まかに言ってリアクティブなものでした。データベースのインシデントが発生したとき、私たちは主にPercona Monitoring and Managementとmysqld-exporterを使用しましたが、これらはどちらもMySQL Performance Schemaに基づいています。これらはデータベースサーバー内部の洞察を提供し、最も長い実行時間のクエリや、異なる操作によってスキャンされる行数、保持されているロック、CPU使用率などを見ることができました。

このサーバー中心の監視は非常に価値があったが、大きな制限がありました。クライアントのコンテキストが不足していました：データベースはどのクエリが問題であるかを教えてくれますが、それをトリガーした人や要因についてはあまり詳しくありませんでした。負荷の急増は、CPU使用率の高まりや特定のSQLステートメントの実行回数の増加として表れる場合があります。しかし、追加情報がなければ、我々は症状だけを知っていました（例："クエリQの負荷が20%増加している"） しかし、根本的な原因は不明でした（「どのテナントまたは機能が突然、より頻繁にクエリQを発行し始めたのか？」）。この調査は、多くの場合、様々なサービスのログをクロスチェックしてタイムスタンプを関連付け、問題のクエリの起源を見つける推測作業を伴っていました。これは、アクティブなインシデント中に時間がかかる可能性があります。

洗練されたリアクティブアプローチ - クライアントのクエリトレース

サーバーサイドの監視のブラインドスポットに対応するために、クライアントサイドのクエリトレーシングを導入しました。アイデアはシンプルだが強力です：当社のプラットフォームのアプリケーション（データベースクライアント）がデータベースにSQLクエリを送信するたびに、テナントID、サービスまたはAPI名、リクエストIDなどの追加的なコンテキストとともに、それをタグ付けしてログに記録します。これらのカスタム次元を各クエリと共に伝播させることで、データベースの視点とアプリケーションの視点を接続する包括的なビューを得ることができます。

これが実際にどのように役立つのでしょうか？データベースのメトリクスで「クエリZ」が急激に遅くなったり、多くのリソースを消費していることが観察されたと想像してみてください。クライアントトレーシングを使用すると、即座に次の質問ができます：クエリZの責任者はどのクライアントまたはテナントですか？ 私たちのアプリケーションが識別子を添付するので、たとえばテナントAのワークスペースがXロードでクエリZを発行している可能性があることがわかるかもしれません。これにより、「データベースが高負荷下にある」（あいまいな観察）を「テナントAが特定のAPIを介して負荷を発生させている」（行動可能な洞察）に変えることができます。この知識により、担当のエンジニアは迅速にトリアージを行うことができます—たとえば、そのテナントのリクエストのレートを制限するなど。

過去には全体のデータベースメトリクスにのみ依存し、根本原因について推測しなければならなかったいくつかの難問の火消しを、クライアントクエリトレーシングが救ってくれることが分かりました。今では、サーバーサイドとクライアントサイドのデータの組み合わせにより、クエリQPSが急上昇した原因はどのテナントや機能によるものかという重要な問いに、数分で答えることができます。一番データベースの時間を使っているのは誰ですか？特定のAPIコールが過剰な負荷やエラーの原因になっている可能性はありますか？これらのカスタム次元でメトリクスを集約することにより、単一の顧客がリソースを独占する、新しい機能が本質的に高価なクエリを発行するなどのパターンを検出できました。

この追加のコンテクストは、インシデントの際だけでなく、利用ダッシュボードやキャパシティプランニングにも役立ちます。データベースで最も活発なテナントやワークロードを追跡し、必要に応じてリソースを割り当てたり、分離したりすることができます（例えば、特に重たいユーザーをその専用のデータベースインスタンスに移行するなど）。要するに、アプリケーションレベルでの計装は、従来のデータベースメトリクスを補完する新しい観測可能性の次元を私たちに提供しました。

しかし、診断が早くなっても、問題が発生した後に反応することが多かった。この問題を最初から生産に送られることがないようにすることが、我々の旅の次の論理的なステップでした。

積極的なアプローチ: CIのQuery/Schemaスコアラ

スタティック分析ツールがマージ前のコードのバグやスタイル違反を補足するように、私たちはSQLクエリやスキーマパターンも積極的に分析できると気づきました。これにより、事前マージのCIパイプラインに統合されたクエリスコアラが開発されました。

SQLクエリのライフサイクルを開発する; スコアラーは開発サイクルの初期にアンチパターンを早期に特定します。これは修正が最も容易です。

開発者がSQLクエリやスキーマの更新を含むプルリクエストを開くたびに、クエリとスキーマのスコアリング機能が作動します。提案された変更をベストプラクティスのルールセットと既知のアンチパターンと照らして評価します。アンチパターンが検出された場合、CIシステムはテストに失敗し、修補のための実行可能な提案を提供します。

私たちはどのようなクエリやスキーマのアンチパターンを探しているのでしょうか？これまでの経験と一般的なSQLの知識に基づいて、アンチパターンのライブラリを構築してきました。いくつかの主要な例を挙げますと:

• 予測不能な実行プラン：データ配布やオプティマイザの気まぐれによって、異なるインデックスやプランを使用できるクエリ。これらはタイムボムですーー試験ではうまく動くかもしれませんが、特定の条件下では病的に振る舞う可能性があります。
• 効率の悪いクエリ：必要以上に多くのデータをスキャンするクエリ、例えば大規模なテーブル全体のスキャン、インデックスが存在しない、または非選択的なインデックスなど。また、深く入れ子になったサブクエリを含む過度に複雑なクエリは、最適化プログラムに負担をかける可能性があります。
• 制約のないDML: DELETE または UPDATE 操作がWHERE節がない場合や、全体テーブルをロックする可能性のあるもの。
• 不適切なスキーマ設計: 主キーが無いテーブル、過剰/重複したインデックスを持つテーブル、または過大なBLOB/TEXTコラムを使用したテーブルなどは、データの重複、書き込みの遅さ、またはパフォーマンスの低下を引き起こす可能性があります。

“タイムボム”Sqlクエリの例

DELETE FROM t 
WHERE t.B = ?AND t.C = ?;

CREATE TABLE t (
   A INT PRIMARY KEY,
   B INT,
   C INT,
   KEY idx_b (B),
   KEY idx_c (C)
);

このクエリのアンチパターンは「複数のインデックス候補」パターンと呼びます。これは、クエリのWHERE節が複数のインデックス（idx_bとidx_c）によって満たされる可能性がある場合に発生します。これにより、クエリ最適化プログラムには複数の有効な実行パスが提供されます。例えば、上記から、idx_bとidx_cの両方がWHERE節を満たすために使用できる可能性があります。MySQLはどのインデックスを使用しますか？これは、クエリ最適化者がどのパスが安いと見積もるかによります。この決定は、データの分布が変わる場合や、インデックス統計が古くなった場合に変わる可能性があります。

詐欺の危険性は、一つのインデックスパスが他のものよりもはるかに高価になる可能性がある一方で、最適化者が見積もりを誤って誤ったものを選ぶ可能性があることです。

実際に、最適化器がサブオプティマルなインデックスを選択した結果、1000万行以上の全表がデリート中にロックされるというインシデントが発生しました。

クエリスコアラでは、プランが安定していないクエリはブロックされます。クエリが複数のインデックスを使用でき、明確で一貫した計画がない場合、それは危険とフラグが立てられます。これらの場合、開発者には、明示的にFORCE INDEX 句を使用して安全と知られているインデックスを強制する、またはクエリを再構成してより決定的な動作にするよう依頼します。

これらのルールを開発サイクルの早い段階で適用することで、新たなデータベースの落とし穴の導入を大幅に減らしました。エンジニアは、データベースの健全性を損ねる可能性のあるクエリを導入した場合、そのプルリクエストで即座にフィードバックを受け取り、これらのベストプラクティスを時間とともに学び、内部化します。

統一されたデータベース利用スコアカード：ホリスティックなビュー

システムのアンチパターンを検出することは効果的ですが、データベースの信頼性は包括的な性質です。個々のクエリだけでなく、トラフィックパターン、データ量、スキーマの進化によっても影響を受けます。これを解決するために、より広範なベストプラクティスを定量化する統一されたデータベース使用スコアカードを開発しました。

データベース効率性のジャーを埋めるという私たちの哲学 - ロックは大きく重要なタスク、砂は小さく重要性の低いタスク、小石はその間のタスクです。

このスコアはどのように計算されますか？クエリのライフサイクルの全段階からのデータを統合します：

• CIステージ（マージ前）：私たちはすべてのクエリー/スキーマとそれらのアンチパターンをデルタテーブルに取り込む
• プロダクションステージ: クライアントサイドのクエリトレーシングとサーバーサイドのメトリクスを使用して、Delta Live Tables (DLT) パイプラインがクエリの遅延、スキャンされた行と返された行、成功/失敗率などのリアルタイム性能データを収集します。

この情報は全て、中央のlogfood内のAI/BIダッシュボードに集約されます。

一つのサービスのためのDB使用スコアカードの例。寄与する要素には、過剰な行の検査、SLA、タイムアウト、ユニットテストのカバレッジ、アンチパターン、読み書きの増幅が含まれます。

主要なポイント

DatabricksでのOLTP SQLデータベースの信頼性を高めるための取り組みは、高性能な製品をスケーリングするための貴重な教訓になりました：

• 反応型から予防型への転換: インシデント駆動の反応型から、データベース使用スコアカードを使用したデータベースベストプラクティスの改善を積極的に行うようになり、データベースベストプラクティスを計測可能で実行可能なものにしました。
• 開発周期の早い段階でベストプラクティスを適用する：クエリスコアラを早い開発サイクルに統合することで、フルテーブルスキャンや不安定なプランのようなアンチパターンの修正にかかるコストと労力を減らし、開発者が効率的に問題を解決できるようにしました。
• 分析を活用して洞察を得る：データベース使用スコアカードは、Delta Tables、DLT Pipelines、AI/BIダッシュボードなどのDatabricks製品を活用し、数千のデータベースインスタンスの最適化と開発者の適切なサポートを可能にします。Databricks製品はプロセスの加速を助け、その解決策は他のデータ駆動型プラットフォームにも適応可能です。

この記事は、私たちがSREcon25 Americas 2025で発表したトークから改訂されました（スライドと録音はここで利用可能になります）。私たちはコミュニティに私たちの経験を共有することを光栄に思い、ここではより広い視聴者にそれらの洞察をもたらすことに興奮しています。

データベースの信頼性問題の解決に情熱を注いでいる方は、Databricksでのキャリア機会を探してみてください（https://www.databricks.com/company/careers/open-positions）。