Dicerのオープンソース化: Databricksの自動シャーダー

1. 発表

本日、Databricks は、最も重要なインフラストラクチャ コンポーネントの 1 つである Dicer: Databricks の自動シャーダーのオープンソース化を発表できることを嬉しく思います。これは、低レイテンシーでスケーラブル、かつ信頼性の高いシャーディングされたサービスを構築するために設計された基盤システムです。これは、Databricks のすべての主要製品のバックグラウンドで動作しており、フリート効率を向上させ、クラウドコストを削減しながら、一貫して高速なユーザー エクスペリエンスを提供することを可能にしています。Dicer は、シャーディングの割り当てを動的に管理することで、再起動、障害、ワークロードの変動に直面しても、サービスの応答性と回復性を維持します。このブログ記事で詳しく説明されているように、Dicer は、高性能サービング、ワーク パーティショニング、バッチ処理パイプライン、データ集計、マルチテナンシー、ソフト リーダー選出、AI ワークロードのための効率的な GPU 利用など、さまざまなユースケースで使用されます。

Dicerをより幅広いコミュニティに公開することで、産業界や学術界と協力して、堅牢で効率的、かつ高性能な分散システムの構築における最先端技術を発展させていくことを楽しみにしています。この記事の残りの部分では、Dicerの背景にある動機と設計思想について説明し、Databricksでの成功事例を紹介するとともに、ご自身でシステムをインストールしてエクスペリメントするためのガイドを提供します。

2. 動機: ステートレスおよび静的シャーディング アーキテクチャからの脱却

Databricksは、データ処理、アナリティクス、AI向けの急速に拡大する製品スイートを提供しています。これを大規模にサポートするため、当社では応答性を維持しながら大量の状態を処理する必要がある数百ものサービスを運用しています。これまで、Databricksのエンジニアは2つの一般的なアーキテクチャに依存していましたが、サービスが成長するにつれて、どちらも重大な問題を引き起こしました。

2.1.ステートレスアーキテクチャの隠れたコスト

Databricks のほとんどのサービスは、ステートレスモデルから始まりました。一般的なステートレスモデルでは、アプリケーションはリクエスト間でメモリ内の状態を保持せず、リクエストごとにデータベースからデータを再読み取りする必要があります。このアーキテクチャは、すべてのリクエストでデータベースヒットが発生するため、本質的にコストが高く、運用コストとレイテンシの両方が増加します [1]。

これらのコストを軽減するために、開発者は多くの場合、リモートキャッシュ（Redis や Memcached など）を導入して、データベースから作業をオフロードしていました。これによりスループットとレイテンシは改善されましたが、いくつかの根本的な非効率性を解決することはできませんでした。

• ネットワーク レイテンシ: すべてのリクエストは、依然としてキャッシュ レイヤーへのネットワーク ホップという「代償」を払っています。
• CPU オーバーヘッド: データがキャッシュとアプリケーション間を移動する際の (デ)シリアライゼーションで、大量のサイクルが無駄になります [2]。
• 「オーバーリード」問題: ステートレスサービスは、データのほんの一部しか使用しないにもかかわらず、キャッシュからオブジェクト全体または大きな BLOB をフェッチすることがよくあります。これらのオーバーリードは、アプリケーションが時間をかけてフェッチしたデータの大部分を破棄するため、帯域幅とメモリを浪費します [2]。

シャーディングされたモデルに移行し、状態をメモリにキャッシュすることで、状態を操作するロジックと直接併置し、これらのオーバーヘッドのレイヤーを排除しました。しかし、静的シャーディングは新たな問題を引き起こしました。

2.2.静的シャーディングの脆弱性

Dicer の登場以前、Databricks のシャーディングされたサービスは、静的シャーディング手法 (例: コンシステント ハッシュ) に依存していました。このアプローチはシンプルで、サービスがメモリ内で状態を効率的にキャッシュできるという利点がありましたが、本番運用で 3 つの重大な問題を引き起こしました。

• 再起動および自動スケーリング中に利用できなくなる問題: クラスタ マネージャーとの連携不足が、ローリング アップデートなどのメンテナンス作業中や、サービスの動的スケーリング時に、ダウンタイムやパフォーマンスの低下につながっていました。静的シャーディング方式では、バックエンドのメンバーシップの変更に事前に対応できず、ノードが削除された後にのみ反応していました。
• 障害発生時のスプリットブレインとダウンタイムの長期化: 一元的な調整がない場合、ポッドがクラッシュしたり、断続的に応答しなくなったりすると、クライアントがバックエンド ポッドのセットに対して不整合なビューを持つ可能性があります。その結果、「スプリットブレイン」シナリオ（2つのポッドが同じキーを所有していると認識する）や、顧客のトラフィックが完全にドロップされる（どのポッドもキーを所有していると認識しない）といった事態が発生しました。
• ホットキー問題: 定義上、静的シャーディングは、負荷の変動に応じてキー割り当てを動的に再調整したり、レプリケーションを調整したりすることはできません。その結果、単一の「ホットキー」が特定のポッドに過負荷をかけ、フリート全体で連鎖的な障害を引き起こす可能性のあるボトルネックを作り出していました。

需要を満たすためにサービスが拡大し続けるにつれて、やがて静的シャーディングはひどいアイデアのように思えてきました。これにより、パフォーマンスとリソースのコストを犠牲にしても、堅牢なシステムを構築するにはステートレス アーキテクチャが最善であるという考えが、当社のエンジニアの間で一般的になりました。これは Dicer が導入された頃のことです。

2.3.シャーディングされたサービスの概念の再定義

静的シャーディングの**本番運用**における危険性と、ステートレス化に伴うコストとを比較検討した結果、当社の最も重要な**サービス**のいくつかは困難な状況に置かれていました。これらのサービスは、顧客に軽快なユーザーエクスペリエンスを提供するために、静的シャーディングに依存していました。それらをステートレスモデルに変換すると、当社にとってクラウドコストが増加するだけでなく、パフォーマンスが大幅に低下する可能性がありました。

これを変えるために Dicer を構築しました。Dicer は、サービスのシャード割り当てを継続的かつ非同期に更新するインテリジェントなコントロールプレーンを導入することで、静的シャーディングの根本的な欠点に対処します。アプリケーションのヘルス、負荷、終了通知、その他の環境入力など、さまざまなシグナルに反応します。その結果、Dicer は、ローリング再起動、クラッシュ、オートスケールイベント、および深刻な負荷の偏りがある期間でも、サービスの可用性を高く保ち、バランスを保ちます。

オートシャーダーとして、Dicer は Centrifuge [3]、Slicer [4]、Shard Manager [5] といった以前から続く一連のシステムを基盤としています。次のセクションでは Dicer を紹介し、それが当社のサービスのパフォーマンス、信頼性、効率性の向上にどのように貢献したかを説明します。

3. Dicer: 高パフォーマンスと可用性を実現する動的シャーディング

ここでは、Dicerの概要、そのコアとなる抽象化、そしてさまざまなユースケースについて説明します。Dicerの設計とアーキテクチャに関する技術的な詳細については、今後のブログ記事にご期待ください。

3.1 Dicer の概要

Dicer は、アプリケーションを、論理キーに関連付けられたリクエストを処理する（またはその他の作業を実行する）ものとしてモデル化します。たとえば、ユーザープロファイルを処理するサービスは、キーとしてユーザー ID を使用する場合があります。Dicer は、キーのポッドへの割り当てを継続的に生成することでアプリケーションをシャーディングし、サービスの可用性を高く保ち、負荷を分散させます。

数百万または数十億のキーを持つアプリケーションにスケールするために、Dicer は個々のキーではなくキーの範囲に対して動作します。アプリケーションは SliceKey（アプリケーションキーのハッシュ）を使用して Dicer にキーを表し、SliceKeys の連続した範囲は Slice と呼ばれます。図1に示すように、DicerのAssignmentはアプリケーションのキースペース全体を網羅するSliceのコレクションであり、各Sliceは1つ以上のリソース（つまりPod）に割り当てられます。Dicerはアプリケーションのヘルスシグナルと負荷シグナルに応じてSliceを動的に分割、Merge、複製、再割り当てし、キースペース全体が常に正常なPodに割り当てられ、単一のPodが過負荷にならないようにします。また、Dicerはホットキーを検出して独自のSliceに分割し、そのようなSliceを複数のPodに割り当てて負荷を分散させることもできます。

図 1 は、ユーザー ID によってシャーディングされたアプリケーションにおける、3 つのポッド (P₀、P₁、P₂) にまたがる Dicer の割り当て例を示しています。ID 13 のユーザーは SliceKey K₂₆ (ID 13 のハッシュ) で表され、現在ポッド P₀ に割り当てられています。ユーザー ID 42 を持ち SliceKey K₁₀ で表されるホットなユーザーは、独自の スライスに分離され、負荷を処理するために複数のポッド (P₁ と P₂) に割り当てられています。

図 2 は、Dicer と統合されたシャーディングされたアプリケーションの概要を示しています。アプリケーションポッドは、Slicelet (Sはサーバーサイドの意) と呼ばれるライブラリを通じて現在の割り当てを把握します。Slicelet は、Dicer サービスから最新の割り当てを取得し、更新を監視することで、ローカル キャッシュを維持します。更新された割り当てを受信すると、SliceletはリスナーAPIを介してアプリケーションに通知します。

Slicelet が監視する割り当ては結果整合性を持ちます。これは、強力なキー所有権の保証よりも可用性と迅速な復旧を優先するための、意図的な設計上の選択です。私たちの経験では、これは大多数のアプリケーションにとって適切なモデルでした。ただし、将来的には Slicer や Centrifuge と同様に、より強力な保証をサポートする予定です。

割り当てを最新の状態に保つだけでなく、アプリケーションは Slicelet を使用して、リクエストの処理時やキーの作業実行時にキーごとの負荷を記録します。Slicelet はこの情報をローカルで集計し、概要を Dicer サービスに非同期で報告します。割り当ての監視と同様に、これもアプリケーションのクリティカルパスの外で発生するため、高いパフォーマンスが保証されることに注意してください。

Dicerでシャーディングされたアプリケーションのクライアントは、Clerk（クライアントサイドのC）と呼ばれるライブラリを通じて、特定のキーに割り当てられたPodを見つけます。Sliceletと同様に、Clerkもクリティカルパス上のキールックアップで高いパフォーマンスを確保するため、バックグラウンドで最新の割り当てのローカルキャッシュを積極的に維持します。

最後に、Dicer Assignerは、アプリケーションのヘルスシグナルと負荷シグナルに基づいて割り当てを生成し、配布する役割を担うコントローラーサービスです。その中核にあるのは、Sliceの分割、Merge、レプリケーション/デレプリケーション、移動を通じて最小限の調整をコンピュートし、キーを健全なPodに割り当て続け、アプリケーション全体の負荷を十分に分散させるシャーディングアルゴリズムです。Assignerサービスはマルチテナントであり、リージョン内のすべてのシャーディングされたアプリケーションに自動シャーディングサービスを提供するように設計されています。Dicerによって提供される各シャーディングされたアプリケーションは、Targetと呼ばれます。

3.2 Dicer によって強化された幅広いアプリケーション

特定のポッドにワークロードをアフィニタイズする機能は、パフォーマンスを大幅に向上させるため、Dicer は幅広いシステムにとって価値があります。本番運用での経験に基づき、私たちはいくつかの主要なユースケースのカテゴリを特定しました。

インメモリおよび GPU サービング

Dicer は、大量のデータをメモリから直接ロードして提供する必要があるシナリオで優れています。特定のキーへのリクエストが常に同じポッドにヒットするようにすることで、キーバリューストアのようなサービスは、リモート ストレージからデータをフェッチするオーバーヘッドを回避しながら、ミリ秒未満のレイテンシーと高い throughput を達成できます。

Dicerは、アフィニティを維持することが不可欠な、最新のLLM推論ワークロードにも非常に適しています。例としては、セッションごとのKVキャッシュにコンテキストを蓄積するステートフルなユーザーセッションや、多数のLoRAアダプタを提供し、制約のあるGPUリソース全体で効率的にシャーディングする必要があるデプロイメントなどが挙げられます。

制御およびスケジューリング システム

これはDatabricksにおける最も一般的なユースケースの1つです。これには、スケーリング、コンピュートスケジューリング、マルチテナンシーを管理するためにリソースを継続的に監視する、クラスターマネージャーやクエリーオーケストレーションエンジンなどのシステムが含まれます。効率的に動作するために、これらのシステムはモニタリングおよび制御の状態をローカルに維持し、繰り返しのシリアル化を回避して、変更へのタイムリーな応答を可能にします。

リモート キャッシュ

Dicerは、高性能な分散リモートキャッシュを構築するために使用できます。これは、Databricksの本番運用で実際に導入されています。Dicerの機能を利用することで、当社のキャッシュはヒット率を損なうことなくシームレスにオートスケールおよび再起動でき、ホットキーによる負荷の不均衡を回避できます。

ワークパーティショニングとバックグラウンドワーク

Dicerは、サーバーフリート全体でバックグラウンドタスクと非同期ワークフローを分割するための効果的なツールです。例えば、巨大なテーブルの状態をクリーンアップまたはガベージコレクションするサービスは、Dicerを使用して、各Podがキースペースの重複しない個別の範囲を担当するようにし、冗長な作業とロック競合を防ぐことができます。

バッチ処理と集約

大量の書き込みパスの場合、Dicer は効率的なレコード集約を可能にします。関連するレコードを同じポッドにルーティングすることで、システムは更新を永続ストレージにコミットする前にメモリ内でバッチ処理できます。これにより、必要な 1 秒あたりの入出力操作が大幅に削減され、データパイプラインの全体的なthroughputが向上します。

ソフト リーダー選出

Dicer は、特定のキーまたはシャードのプライマリー コーディネーターとして特定のポッドを指定することで、「ソフト」なリーダー選出を実装するために使用できます。たとえば、サービング スケジューラは Dicer を使用して、単一のポッドがリソースのグループを管理するためのプライマリーとして機能することを保証できます。Dicer は現在アフィニティベースのリーダー選出を提供していますが、従来のコンセンサス プロトコルのような重いオーバーヘッドなしに、調整されたプライマリーを必要とするシステムのための強力な基盤として機能します。これらのワークロードの相互排除に関して、より強力な保証を提供するための将来的な機能強化を検討しています。

ランデブーとコーディネーション

Dicerは、リアルタイムの協調を必要とする分散クライアントのための、自然なランデブーポイントとして機能します。特定のキーに対するすべてのリクエストを同じポッドにルーティングすることで、そのポッドが中心的な集合場所となり、外部ネットワークホップなしでローカルメモリ内の共有状態を管理できるようになります。

例えば、リアルタイムチャットサービスにおいて、同じ「チャットルームID」に参加する2人のクライアントは、自動的に同じPodにルーティングされます。これにより、Podはメモリ内でメッセージと状態を即座に同期できるため、共有データベースのレイテンシや通信用の複雑なバックプレーンが不要になります。

4. 成功事例

Databricksの数多くのサービスがDicerで大きな成果を上げており、以下にこれらの成功事例のいくつかをハイライトします。

4.1 Unity Catalog

Unity Catalog (UC) は、Databricks プラットフォーム全体のデータおよび AI アセット向けの統合ガバナンス ソリューションです。当初はステートレス サービスとして設計された UC は、主に非常に高い読み取り量によって人気が高まるにつれて、重大なスケーリングの課題に直面しました。各リクエストを処理するにはバックエンド データベースへの繰り返しアクセスが必要で、これが法外なレイテンシを引き起こしていました。キャッシュを増分更新し、ストレージとのスナップショットの整合性を維持する必要があったため、リモート キャッシュなどの従来のアプローチは実現可能ではありませんでした。さらに、顧客のカタログは数ギガバイトのサイズになる可能性があるため、大幅なオーバーヘッドを発生させることなくリモート キャッシュで部分的または複製されたスナップショットを維持するには、コストがかかります。

この問題を解決するため、チームはDicerを統合して、シャーディングされたインメモリのステートフルキャッシュを構築しました。この移行により、UCは高コストなリモートネットワークコールをローカルメソッドコールに置き換えることができ、データベースの負荷を大幅に削減し、応答性を向上させました。下の図は、Dicerの初期ロールアウトと、その後の完全なDicer統合のデプロイメントを示しています。Dicerのステートフルアフィニティを利用することで、UCは90～95%のキャッシュヒット率を達成し、データベースへのラウンドトリップの頻度を大幅に削減しました。

4.2 SQLクエリー オーケストレーションエンジン

Sparkクラスターでのクエリスケジューリングを管理するDatabricksのクエリーオーケストレーションエンジンは、当初は静的シャーディングを使用したインメモリのステートフルサービスとして構築されました。サービスの規模が拡大するにつれて、このアーキテクチャの制限が大きなボトルネックになりました。実装が単純なため、スケーリングには非常に骨の折れる手動での再シャーディングが必要であり、システムはローリング再起動中でさえも頻繁な可用性の低下に悩まされていました。

Dicer との統合後、これらの可用性の問題は解消されました (図 4 参照)。Dicer は再起動およびスケーリング イベント中のダウンタイムをゼロにしました。これにより、チームはあらゆる場所で自動スケーリングを有効にして労力を削減し、システムの堅牢性を向上させることができました。さらに、Dicer の動的負荷分散機能は、慢性的な CPU スロットリングの問題を解消し、フリート全体でより一貫したパフォーマンスをもたらしました。

4.3 Softstore リモートキャッシュ

シャーディングされていないサービス向けに、分散型リモートキーバリュー キャッシュである Softstore を開発しました。Softstore は、状態転送と呼ばれる Dicer の機能を活用しています。これは、リシャーディング中にポッド間でデータを移行して、アプリケーションの状態を維持するものです。これは、キースペース全体が必然的にチャーンされる計画的なローリング再起動において特に重要です。当社の本番運用フリートでは、計画的な再起動が全再起動の約 99.9% を占めています。このメカニズムは特に影響が大きく、キャッシュ ヒット率への影響を無視できるレベルに抑えつつ、シームレスな再起動を可能にします。図 5 は、ローリング再起動中の Softstore のヒット率を示しています。代表的なユースケースにおいて、状態転送によってヒット率は約 85% で安定しており、残りの変動は通常のワークロードの変動によるものです。

5. 皆様もご利用いただけます!

お使いのマシンにこちらから Dicer をダウンロードして、本日すぐにお試しいただけます。その使用方法を示す簡単なデモがこちらで提供されています。これは、1 つのクライアントといくつかのサーバーを使用したアプリケーション向けの Dicer のサンプル セットアップを示しています。Dicer の README と ユーザーガイドをご覧ください。

6. 今後の機能と記事

DicerはDatabricks全体で使用される重要なサービスであり、その使用量は急速に増加しています。今後、Dicerの内部構造や設計に関する記事をさらに公開していく予定です。また、社内で構築、テストしながら、クライアントおよびサーバー用のJavaライブラリやRustライブラリ、本記事で言及した状態転送機能など、より多くの機能をリリースしていく予定です。フィードバックをお寄せいただき、今後の情報にご期待ください！

困難なエンジニアリングの問題を解決することがお好きで、Databricks への入社にご興味があれば、databricks.com/careers をぜひご覧ください!

7. 参考文献

[1] Ziming Mao、Jonathan Ellithorpe、Atul Adya、Rishabh Iyer、Matei Zaharia、Scott Shenker、Ion Stoica（2025 年）。データセンター サービスにおける分散キャッシュのコストの再考。Proceedings of the 24th ACM Workshop on Hot Topics in Networks、1～8。

[2] Atul Adya、Robert Grandl、Daniel Myers、Henry Qin。高速キーバリュー ストア: 時代遅れになったアイデア。Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS ’19)、2019 年 5 月 13～15 日、イタリア、ベルティノーロ。ACM、7 ページ。DOI: 10.1145/3317550.3321434。

[3] Atul Adya、James Dunagan、Alexander Wolman。Centrifuge: Integrated Lease Management and Partitioning for クラウドサービス。第 7 回 USENIX Symposium on Networked Systems Design and Implementation (NSDI) プロシーディング、2010 年。

[4] Atul Adya, Daniel Myers, Jon Howell, Jeremy Elson, Colin Meek, Vishesh Khemani, Stefan Fulger, Pan Gu, Lakshminath Bhuvanagiri, Jason Hunter, Roberto Peon, Larry Kai, Alexander Shraer, Arif Merchant, Kfir Lev-Ari.Slicer: Auto-Sharding for Datacenter Applications.Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2016, pp.739–753.

[5] Sangmin Lee、Zhenhua Guo、Omer Sunercan、Jun Ying、Chunqiang Tang、他Shard Manager: A Generic Shard Management Framework for Geo distributed Applications。ACM SIGOPS 第 28 回オペレーティング システム原理に関するシンポジウム (SOSP) 論文集、2021 年。DOI: 10.1145/3477132.3483546。

[6] Atul Adya, Jonathan Ellithorpe。ステートフル サービス: 低レイテンシ、効率性、スケーラビリティ — 3 つすべてを実現。High Performance Transaction Systems Workshop (HPTS) 2024、カリフォルニア州パシフィック グローブ、2024 年 9 月 15～18 日。