1日10兆サンプル：Databricksにおける従来のモニタリングインフラを超えたスケーリング

Databricks の監視インフラストラクチャは、昨年1年間で3倍以上に拡大し、現在では50億のアクティブな時系列データをリアルタイムで追跡し、1日あたり10兆を超えるサンプルを取り込んでいます。この大規模な環境では、市販のソリューションは非効率的であるか、要件に合わせて調整するのが難しいことがわかりました。この記事では、代わりに構築したもの、つまりオープンソースの監視エコシステムの利点を最大限に活用し、独自のニーズに合わせてカスタマイズを組み込んだスケーラブルなプラットフォームを紹介します。

Databricks のエンジニアは、問題を迅速に通知し、スケーリングとロールバックを自動化し、インテリジェントなトラブルシューティングを可能にする監視システムに依存しています。これらのシステムは、潜在的なインシデント中に監視が不十分になることがないように、高い信頼性が必要です。しかし、Databricks の規模でこのインフラストラクチャを開発するのは簡単なことではありませんでした。

• スケーラビリティ、信頼性、効率性の要件に加えて、私たちは約70のクラウドリージョン、3つの主要クラウドすべてでグローバルにシステムを運用しています。クラウド、さらには個々のリージョンごとの違いにもかかわらず、同等のパフォーマンスをサポートする必要があります。
• この広範さと多様性に直面すると、大規模なインフラストラクチャの運用はすぐに持続不可能になる可能性があります。システムは、オンコール担当者が各リージョンのスタックを直接管理するのではなく、自己修復および自己スケーリングするように、可能な限り「ハンズオフ」である必要があります。それでも、ユーザーにとってシンプルなインターフェイスを提供する必要があります。
• Databricks でサーバーレスおよび AI ワークロードが増加するにつれて、インフラストラクチャ全体のチャーンが急増し、メトリクスのカーディナリティが急速に増加しました。これまでのように高カーディナリティの監視データを処理および保存することはできなくなりましたが、エンジニアが依存するデバッグワークフローを維持することを目指していました。

これらの課題に直面し、Databricks の古い監視スタックは信頼性の問題に悩まされていました。私たちは、エンジニアの期待に応える、新しく信頼性の高いプラットフォームを開発することに着手しました。以来、3つの主要な問題に取り組んできました。

1. 信頼性が高く効率的な時系列データベース（TSDB）のアーキテクチャ
2. TSDB をカーディナリティから保護するためのメトリクス集計の導入
3. Databricks レイクハウスによる高次元トラブルシューティングの有効化

Thanos 時系列データベース

TSDB とは？

TSDB は、従来の監視システムアーキテクチャのコアコンポーネントです。これらの特殊なデータベースは、大量の時系列メトリクスデータを取得し、高QPS、低遅延、リアルタイムの読み取りを提供するように設計されています。特に、同じクエリセットを繰り返し発行し、最新のデータに基づいて非常に高速な結果を取得する必要がある、アラートやダッシュボードの更新などの監視クエリパターンに最適です。

Databricks の古い TSDB は、1桁小さい規模で構築されており、近年、私たちにとって主要なボトルネックとなっていました。実際、監視インフラストラクチャ全体の信頼性問題の第1位は、TSDB のスケールアップの困難さでした。これは他の多くの企業にとってはまれな操作ですが、Databricks の指数関数的な成長を考えると、ほぼ毎日行う必要がありました。

そこで、オープンソースの CNCF Thanos プロジェクトをフォークした、Pantheon というコードネームの新しい TSDB を開発しました。3つのクラウドプロバイダーのすべてのリージョンにわたる Thanos インスタンスを160以上にスケールアップすることに成功し、合計約50億のインメモリアクティブ時系列と、1日あたり10兆を超えるサンプルを取り込んでいます。最大のインスタンスは約3億のインメモリ時系列をホストし、毎秒約1,000件の PromQL クエリをサポートしています。また、小規模な3ノードデプロイメントや、その間のあらゆる規模のものも実行しています。デプロイメントの広範さ、規模、多様性のため、Thanos のエッジケースやパフォーマンス最適化を発見し、オープンソースコミュニティに貢献することがよくあります。

Pantheon への移行により、年間数百万ドルのクラウドコストを節約できると同時に、監視インフラストラクチャのダウンタイムを約5倍削減し、多くの手作業による負担を排除することができました。 Pantheon のアーキテクチャを以下に示します。次のセクションでは、これらの成果を可能にしたいくつかの重要な設計上の決定について説明します。

ストレージアーキテクチャ

Thanos の重要な要素は、階層型ストレージアーキテクチャです。最新の時系列はメモリに保持され、過去24時間の時系列はディスクに保持され、それより古いデータはすべてオブジェクトストレージに保持されます。これは、アラートやその他のリアルタイムクエリが、通常は最新のデータに依存するため、厳格なパフォーマンス要件を満たすことができることを意味します。同時に、オブジェクトストレージを活用することで、システムはコンピューティングとストレージを本質的に分離できます。クラスターは、履歴データをすべてデータベースノードに再分散する必要なくスケールアップできます。

このアーキテクチャは、私たちの主要なボトルネック（スケールアップ）を解決し、Pantheon のコスト削減の基盤を築きました。さらにいくつかの最適化を適用しました。

• メモリ保持ポリシー: 2つの Receive グループを、異なるメモリ保持ポリシーでデプロイしています。1つは永続サービスからの長寿命時系列に最適化されており、メモリ内に2時間のサンプルを保持します。もう1つは Databricks の一時的なワークロードからの短寿命時系列に最適化されており、メモリ内に30分分のサンプルのみを保持します。この分割は、Databricks におけるサーバーレスワークロードの寿命として観測されたものと一致しており、メモリフットプリントとクラウドコストを大幅に削減しながら、正確性を維持します。
• Receive グループ構造: 各グループは、単一の大きなハッシュリングの代わりに、3つのレプリカに対応する3つの分離された Kubernetes StatefulSet として意図的に実装されています。この設計は、クォーラム書き込みで3方向レプリケーションを維持し、運用上およびデータ上の分離を強化します。このセットアップにより、クォーラム違反や書き込み可用性への影響を発生させることなく、リリース中やノードローテーション中に StatefulSet 全体を並列でロールアウトまたは再起動でき、日常的な運用が大幅に簡素化されます。
• マルチテナンシー: Pantheon は Thanos のマルチテナンシーを使用して、Receive グループ全体にわたって分離されたテナントセットをホストします。ルーター層では、メトリクス名と選択されたラベルを検査することにより、各データサンプルのテナントを推測するルールベースのテナント属性を適用します。これにより、アップストリームクライアントの変更を必要とせずに、同じ書き込みバッチ内のサンプルを異なるテナント（したがって異なる Receive グループ）にルーティングできます。
• 少なくとも1回のアップロード: コストをさらに最適化し、正確性を維持するために、3つの StatefulSet のうち2つだけがオブジェクトストレージにブロックをアップロードします。これにより、冗長なアップロードトラフィックとクラウドストレージコストが削減されますが、レプリケーションとクォーラムセマンティクスを通じてデータの耐久性と一貫性保証が維持されます。

Pantheon コントロールプレーン

グローバルな規模では、手動操作、ベストエフォートの Kubernetes 自動化、または標準の Thanos の動作では不十分です。すべてのリリース、スケールイベント、またはホスト障害は、安全かつ自動的に、最小限の人間の介入で処理され、クォーラムとデータ可用性を維持する必要があります。これを達成するために、Pantheon は Thanos コンポーネントのライフサイクルと容量決定をオーケストレーションする、専用のコントロールプレーンを導入しています。これは3つの主要なコントローラーで構成されています。

• Rollout Operator: 3つの分離された Receive StatefulSet 全体でリリースとスケーリングを調整し、読み取りと書き込みの両方のクォーラムを保証します。これにより、一度に最大1つのレプリカしか利用できなくなるようにすることで、並列 StatefulSet 更新による高速なリリースが可能になります。
• Hashring Controller: ルーターから見える Receive エンドポイントを管理します。正常で完全に準備ができたポッドのみがハッシュリングに追加され、スケールダウンまたはメンテナンス中に削除がステージングされます。これにより、トラフィック管理とポッドライフサイクルが分離され、動的なクラスター変更中の偶発的なクォーラム違反や部分的なルーティングが防止されます。
• Autoscaling and Self-Healing Controller: 一般的な Kubernetes シグナルではなく、Pantheon 固有の取り込みとリソースプレッシャーに基づいてクラスターをスケーリングします。組み込みのヒーラーシステムは、ホスト障害、過負荷のポッド、破損した WAL など、一般的な障害モードを継続的に検出し、修復します。これにより、オペレーターの介入なしにシステムが自己回復できます。私たちの規模では、これらの自動化は週に数十回実行されます。

カーディナリティと集計

カーディナリティとは何で、なぜ重要なのでしょうか？

メトリクスのオーナーは、特定のディメンションでの問題のデバッグやインシデントの迅速な軽減に役立つように、ノードIDやポッドIDなどのラベルをしばしば追加します。しかし、これは古典的なオブザーバビリティの課題、すなわちカーディナリティの管理につながります。メトリクスのカーディナリティとは、ラベルのユニークな組み合わせの数です。監視しているポッドの数が増加すると、ポッドIDラベルを持つ任意のメトリクスのカーディナリティも同様に増加します。カーディナリティはTSDBの主要なスケーリング要因であり、既存のメトリクスのカーディナリティの増加は、Pantheonのコストとスケーリングのプレッシャーを増加させます。

Databricksでは、インフラの急速な成長という課題に恵まれています。顧客ベースと製品利用が大幅に増加すると同時に、多くの顧客が最近、サーバーレスコンピューティングアーキテクチャを採用しており、当社のサーバーレスコンピューティングプラットフォームは毎日数千万台のVMを起動しています。より多くのワークロードがサーバーレスに移行するにつれて、監視対象のインフラは変化が激しくなり、これらの識別子ラベルの有効期間は短くなり続けています。

これによりカーディナリティが急増し、Pantheonのスケーラビリティとコストの利点が食い潰されてしまいました。そのため、保存するメトリクスデータをより賢く管理する必要がありました。そこで登場したのが「集約」です。これは、サーバーレスシステムから高価なラベルをインジェスト時に削除しつつ、サービスオーナーに集約されたフリート全体のビューを提供するものです。メトリクスの自動集約戦略により、カーディナリティの増加の「カーブを曲げる」ことができ、監視インフラがDatabricksの他の部分よりも速くスケールする必要がないことを保証します。

集約アーキテクチャ

状態を持つため、大規模で信頼性の高い集約インフラを構築するのは困難です。数百万の入力カウンターを管理するアグリゲーターは、リセットを正しく処理できる必要があります。入力時系列が消えた場合、集約された出力値は減少するのではなく、単調に増加し続ける必要があります。アグリゲーター間でメトリクスがパーティション化されている場合、ポッドの再起動や負荷分散のシナリオも処理する必要があります。

これらの問題は、パーティション割り当てや以前のデータの維持のためにKafkaのようなメッセージングシステムを使用することで解決されることが多いですが、これは当社の規模ではコストがかかり、リアルタイムユースケースに影響を与えるインジェスト遅延を追加します。代替アプローチは、アグリゲーターにインメモリ状態を保存し、割り当てを尊重するためにアグリゲーター間でメトリクスをルーティングし直すことです。しかし、これはアグリゲーターが再デプロイされたときにデータ損失につながります。当社の集約インフラの初期バージョンでは、この動作により、集約されたメトリクスはユーザーにとってほとんど理解不能になりました。

これをシームレスに機能させるために、代わりにDatabricksの「auto-sharder」サービスであるDicerとTelegrafを使用して独自の集約システムを開発しました。このアーキテクチャは、メトリクスをアグリゲーター間でルーティングし直すのではなく、インテリジェントなスティッキールーティングを使用しており、再デプロイの障害モードに対処しました。Telegrafの上にさらに最適化を追加することで、最大のリージョンで1GB/秒を超えるパイプラインと数千の集約ルールにスケールさせることができました。

この新しい集約パイプラインは、長期的なカーディナリティの増加と予期せぬメトリクスサージの両方からTSDBを保護するシールドとなりました。例えば、最近のDatabricksインフラストラクチャのインシデントにより、さまざまなリージョンでメトリクス負荷が2〜5倍に急増しました。Telegrafはこれらの負荷の大部分を吸収し、Pantheonはわずか20%のサージしか観測されず、会社全体のエンジニアが影響なくデバッグおよびアラートクエリを実行できるようになりました。

レイクハウスでの高カーディナリティデータ

集約の問題点

当社の集約インフラストラクチャは、Pantheonを指数関数的なカーディナリティの増加から保護することを可能にしますが、それにはコストが伴います。それは、インシデント中にエンジニアが必要とする正確なディメンションを削除してしまうのです。以下のようなグローバルなフリートを考えてみましょう。

• 過去2時間で数百万のアクティブノード
• ノードあたりの複数のテナント
• 短命なワークロード
• 急速なオートスケーリング

集約されたメトリクスは以下を示します。

• リージョンレベルのCPU使用率が高い
• サービスレベルのレイテンシが急増している

しかし、以下は示しません。

• どのテナントがスワップ圧力を引き起こしているか
• どのノードがクラッシュしたか
• どのシャードが孤立しているか
• どのワークロードがノイズが多いか

Databricksのエンジニアは、これらの高カーディナリティラベルに依存するワークフローのトラブルシューティングのためのソリューションを依然として必要としていました。これらの「針のむしろ」シナリオでは、Pantheonでは対応できない大量の生データの効率的な保存と処理が必要でした。これらのユースケースをサポートするために、カーディナリティの増加に制限されない、異なるストレージアーキテクチャを模索しました。

レイクハウスの登場！

私たちの重要な洞察：Databricksレイクハウスは完璧なソリューションです！ストレージ（安価なオブジェクトストレージ + Delta Lake）とコンピューティング（ストリーミング + クエリクラスター）を分離し、両方の次元で大規模にスケーラブルです。

Databricksの機能を最大限に活用し、生データのトラブルシューティングプラットフォームであるHydraを開発しました。これにより、大規模な高カーディナリティデバッグが可能になりました。 Hydraは、世界中の数百万ノードから200億の集約されていないアクティブ時系列をインジェストし、エンドツーエンドで5分のデータ鮮度と、Thanosよりも50倍安価なデータストレージを実現しています。

これらの成果は、Hydraのレイクハウスネイティブ設計によって可能になりました。

• Databricks上のApache Spark™ Structured Streamingを使用して、到着するメトリクスデータを継続的に処理し、Delta Lakeに書き込む連続インジェストジョブを実行します。Structured Streamingを使用すると、バッチジョブと同じ方法でストリーミング計算を表現できますが、連続的かつ増分的な処理と、信頼性の高いインジェストのためのExactly-onceセマンティクスが利用できます。
• 数百万のオブジェクトストレージファイルを効率的に検出およびインジェストするために、Databricks Auto Loaderを活用しています。これは、手動でのリスト作成や状態管理を必要とせずに、新しいファイルを追跡および増分処理する高スループットのStructured Streamingソースです。Auto Loaderは、検出されたファイルのメタデータを自動的に永続化し、ほぼリアルタイムの到着パターンに対応するようにスケーリングします。
• また、リージョンごとにインジェストをパーティション化し、地理的に独立したストリーミングジョブを展開します。これにより、各パイプラインは独立して自動スケーリングでき、リージョン間の遅延を最小限に抑え、障害発生時の影響範囲を縮小できます。これらの設計上の選択を組み合わせることで、数十億シリーズのボリュームであっても、生メトリクスデータを数分以内にクエリ可能にし、ダッシュボードシステムのパフォーマンスを維持できます。

インターフェースの統合

Hydraの構築は、インフラストラクチャの課題であるだけでなく、インターフェース設計の課題でもありました。当初から、ストレージレイヤーやインジェストパイプラインではなく、エンジニアのクリティカルユーザージャーニー（CUJ）を中心にHydraを設計しました。目標は単純でした。エンジニアは、すでに利用しているインターフェースと同じインターフェースを使用して、高カーディナリティメトリクスを操作できるべきです。

Grafana経由でのクエリ

ほとんどのエンジニアは、Grafanaでデバッグワークフローを開始します。PromQLを記述し、既存のダッシュボードを使用し、ラベルをドリルダウンし、インシデント中に迅速にピボットすることを期待しています。

このワークフローを維持するために、HydraはDatabricksに保存されているデータに対してPromQLクエリを実行できるようにすることで、Grafanaと直接統合します。PromQL式をレイクハウスのDeltaテーブルで実行されるSQLクエリに変換するPromQLからSQLへの変換レイヤーを構築しました。このアプローチにより、エンジニアは、変更なしで使い慣れたPromQL構文とダッシュボードを引き続き使用できます。同時に、基盤となるクエリは、インメモリTSDBではなく、大規模なDeltaテーブルに対して実行されます。

Databricksでの直接SQLアクセス

Grafanaはライブデバッグに最適ですが、一部の調査ではより深い分析が必要です。エンジニアは、メトリクスを展開メタデータと結合したり、メトリクスとログを相関させたり、広範な時間範囲スキャンを実行したり、異常検出を実行したり、高度な分析のためにデータセットをエクスポートしたりする必要がある場合があります。

Hydraは、Databricks内で基盤となるDeltaテーブルにも直接アクセスできるようにします。エンジニアはDatabricks SQLやノートブックを使用してこれらのテーブルをクエリできるため、従来のモニタリングワークフローを超えた柔軟な分析が可能になります。

データはLakehouseに存在するため、他のエンタープライズデータセットと結合でき、同じセキュリティおよびアクセス制御の下で管理されます。これにより、オブザーバビリティデータは、孤立したモニタリングサイロではなく、ファーストクラスのアナリティカルアセットに変わります。

統一されたメトリックセマンティクス

Hydraの重要な設計原則は、エンジニアがインジェストアーキテクチャを理解する必要がないということです。メトリックがTSDBバックの集計パス経由でアクセスされるか、Lakehouseバックの生メトリックパス経由でアクセスされるかに関わらず、インターフェースは一貫しています。

メトリック名、ラベルセマンティクス、メタデータディメンションは、環境全体で統一されています。サービスチームは、標準化されたインターフェースを使用してメトリックを一度発行します。プラットフォームが、集計、生データの保存、インジェスト、ストレージ、クエリールーティングを処理します。この統一されたモデルは、認知的なオーバーヘッドを削減し、チームが異なるオブザーバビリティバックエンドのために個別の設定を管理する必要をなくします。

今後、Hydraのパフォーマンスを向上させ、Pantheonと同等のデータ鮮度を実現し、両方のエクスペリエンスをさらに統合していく予定です。

まとめ

Databricksのモニタリングインフラストラクチャをスケーリングするために、信頼性、効率性、運用性、および開発者のジャーニーを最適化する必要がありました。「スケーリング」とは、単にデプロイメントを増強すること以上の意味を私たちにとって持ちました。それは以下を意味しました。

• 「ハンズオフ」運用をこれらのグローバルで常に変化するシステムで実現するために、基盤となるアーキテクチャにレジリエンスと自動化を組み込むこと
• アラートからトラブルシューティング、データソースを横断した分析まで、さまざまなモニタリングユースケースに必要なシステムのあり方を、第一原理から再考すること
• Databricksの他のインフラストラクチャが私たちと共に進化するにつれて、アーキテクチャを進化させること

これらは私たちにとって終わりのない旅であり、インフラストラクチャエンジニアリングがDatabricksでこれほどダイナミックな分野である理由を示しています。難しいエンジニアリング問題の解決が好きで、この旅に私たちと一緒に参加したい場合は、databricks.com/careersをご覧ください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事