2026/01/14 4:56

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

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

Databricks のオープンソース自動シャーダ Dicer は、データをポッドにわたって自動的にパーティション化し、低レイテンシーでスケーラブルかつ信頼性の高いサービスを提供します。
Dicer は SliceKeys を通じて論理キーを動的に割り当て、ヘルスメトリクス、ロードレベル、およびその他のシグナルに基づいてスライスを継続的に分割・結合・複製・再割り当てします。そのアーキテクチャは、Assigner（コントローラ）、Slicelet（サーバ側割り当てキャッシュ）、そして Clerk（クライアント側キー検索）の3つの主要コンポーネントで構成されています。
実際のユースケースでは以下のような効果が確認されています：

インメモリ／GPU サービング環境において、Unity Catalog がデータベース呼び出しを 90–95 % 削減しつつ、高いキャッシュヒット率を維持。
SQL Query Orchestration Engine は再起動時もダウンタイムゼロで稼働し、自動スケーリングを実現。
Softstore のリモートキャッシュはノードのローリングアップデート中でも約 85 % のヒット率を維持。

Dicer は無料でダウンロード可能で、README / ユーザーガイドにサンプルコードとドキュメントが掲載されています。今後のリリースでは Java/Rust ライブラリ、より強固な一貫性保証、および拡張された状態転送機能が追加される予定で、レイテンシーのさらなる低減、稼働時間の向上、そして高性能分散システム構築におけるメンテナンス負荷の軽減が期待できます。

本文

1. お知らせ
本日、Databricks の最重要インフラコンポーネントの一つである Dicer：Databricks の自動シャーダー をオープンソース化することを発表できることに大変喜びを感じております。Dicer は低レイテンシ、スケーラブルかつ高い信頼性を備えたシャードサービス構築の基盤となるシステムであり、Databricks の主要プロダクトすべての背後に存在しています。これにより、一貫して高速なユーザー体験を提供しながら、フリート効率の向上とクラウドコストの削減が実現できます。Dicer はシャード割り当てを動的に管理することで、再起動・障害発生・ワークロード変化に直面してもサービスをレスポンシブかつレジリエントに保ちます。

Dicer の主な利用ケースは次の通りです：

高性能サービング
ワークパーティショニング
バッチングパイプライン
データ集約
マルチテナンシー
ソフトリーダー選出
AI ワークロード向け GPU 効率化

Dicer を広範なコミュニティへ公開することで、業界や学術界と協力しながら、堅牢で効率的かつ高性能な分散システム構築の最先端を推進できることを期待しています。本投稿では、Dicer の動機付けと設計哲学、Databricks での導入成功事例、そして自ら試すためのインストール・実験ガイドをご紹介します。

2. 動機：ステートレス／静的シャーディングアーキテクチャを超えて

Databricks はデータ処理、分析、AI の分野で急速に拡大する製品群を提供しています。これをスケールで支えるためには、大量の状態を扱いつつレスポンス性を維持する数百のサービスを運用しなければなりません。過去、Databricks のエンジニアは二つの代表的なアーキテクチャに頼っていましたが、サービス規模が拡大すると両者とも重大な問題を抱えるようになりました。

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

ほとんどのサービスはステートレスモデルから始まりました。典型的なステートレスモデルでは、アプリケーションがリクエスト間でインメモリ状態を保持せず、毎回データベースからデータを再読み込みします。この構造は本質的に高コストです：

ネットワークレイテンシ – すべてのリクエストでキャッシュ層へのネットワークホップが発生
CPU オーバーヘッド – （非）シリアライズサイクルが CPU を浪費し、データをキャッシュとアプリ間で移動
オーバーリード問題 – サービスはキャッシュから全オブジェクトまたは大きなバイオを取得するが、その一部しか使用しない

遠隔キャッシュ（Redis, Memcached）を追加するとスループットは向上しますが、これらの非効率性を解消できません。

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

Dicer 前は、シャードサービスは静的シャーディング技術（例：一貫性ハッシュ）に依存していました。これは三つの重大な問題を生み出しました：

再起動・オートスケーリング時の不可用 – クラスター管理者との調整が欠如し、ローリングアップデートやダイナミックスケーリング中にダウンタイムまたは性能低下
分裂脳と障害時のダウンタイム – 中央協調がないため、クライアントはバックエンドポッドの不整合ビューを持つ可能性
ホットキー問題 – 静的シャーディングではロードシフトに応じてキー割り当てやレプリケーションを動的再バランスできない

2.3 シャードサービス物語の再定義

静的シャーディングの本番リスクとステートレス化のコストが対比され、重要なサービスは難しいジレンマに直面しました。ステートレス化すると大きな性能低下とクラウドコスト増を招くためです。そこで Dicer を構築し、アプリケーションヘルス・ロード・終了通知などのシグナルに基づいてシャード割り当てを継続的かつ非同期で更新するインテリジェント制御プレーンを導入しました。これにより、ローリング再起動、クラッシュ、オートスケーリングイベント、極端なロードスキュー時でもサービスは高可用性とバランスを保ちます。

3. Dicer：高性能・可用性のためのダイナミックシャーディング

3.1 概要

Dicer はアプリケーションを「論理キーに紐づくリクエスト（または作業）」としてモデル化し、サービスが常に高い可用性とロードバランスを保つよう、キーをポッドへ継続的に割り当てます。

SliceKey – アプリケーションキーのハッシュ。連続範囲が Slice を形成
Assignment – キースペース全体を網羅する Slice の集合で、それぞれ一つまたは複数のリソース（ポッド）に割り当てられる
Dicer はシグナルに応じてスライスを分割・統合・レプリケート・再割り当てし、健康なポッドが過負荷にならないようにすべてのキーを受け取ります。
ホットキーは専用スライスに隔離され、複数ポッドにレプリケーション

3.2 アーキテクチャ

Slicelet – サーバー側ライブラリで、Dicer から最新の割り当てを取得しローカルキャッシュし、リスナー API を通じてアプリへ通知。さらにキーごとのロードを集計し非同期に Dicer に報告
Clerk – クライアント側ライブラリで、重要経路で高速なキー検索ができるようローカル割り当てキャッシュを保持
Assigner – コントローラサービスで、ヘルスとロードシグナルに基づき割り当てを生成・配布。最小限の調整（分割・統合・レプリケーション）を実施し、キーが健康なポッドへ割り当てられつつバランスを維持

4. Dicer が恩恵をもたらすアプリケーション領域

Dicer はワークロードと特定のポッド間に親和性を生み出し、顕著な性能向上を実現します。主なカテゴリは以下の通りです：

インメモリ・GPU サービング – キーバリューストアがサブミリ秒レイテンシを達成；LLM 推論ワークロードが GPU 間で状態フルセッションキャッシュを維持
制御・スケジューリングシステム – クラスター管理者やクエリオーケストレーションエンジンがタイムリーなスケール決定のためにローカル監視状態を保持
遠隔キャッシュ – 高性能分散キャッシュがヒット率低下なく自動スケール可能
ワークパーティショニング・バックグラウンド作業 – ガーベジコレクタなどのサービスがポッド間でタスクを分割し重複作業を防止
バッチングと集約 – 関連レコードを同一ポッドへルーティングし、永続化前にインメモリバッチング
ソフトリーダー選出 – 重いコンセンサスオーバーヘッドなしでシャードごとのプライマリーコーディネータを指定
ランデブーと協調 – リアルタイム協調が必要なクライアントを同一ポッドへルーティングし、ローカル状態同期を可能に

5. 成功事例

サービス	課題	Dicer の解決策	結果
Unity Catalog	ステートレス設計で高読取量が発生し、データベースアクセスの繰り返しによりレイテンシとコストが増大	Dicer を利用したインメモリ状態フルキャッシュをシャード化；90–95 % のヒット率達成	データベース呼び出しの劇的削減、応答性向上
SQL Query Orchestration Engine	静的シャーディングにより手動再シャーディングが必要で、再起動時に可用性低下	Dicer のダイナミックオートシャーディング；再起動・スケーリングイベント中のゼロダウンタイム	可用性損失を排除、CPU スロットリング削減、一貫した性能
Softstore Remote Cache	ロールアウト時に状態喪失とヒット率低下が発生	Dicer のステート転送機能でポッド間のデータ移行を実現	再起動中も約 85 % のヒット率維持、キャッシュ性能への影響はほぼゼロ

6. 試してみる

Dicer をローカルにダウンロードし、単一クライアントと複数サーバーを用いた簡易デモで実験できます。詳細手順は README とユーザーガイドをご覧ください。

7. 今後の機能・記事予定

以下のような内容をさらに発表していきます：

Java および Rust ライブラリ（クライアント／サーバー向け）
ステート転送機能の拡張

皆様からのフィードバックは非常に貴重です。ご期待ください！

8. 参考文献

Ziming Mao ら, Rethinking the cost of distributed caches for datacenter services, 2025.
Atul Adya ら, Fast key‑value stores: An idea whose time has come and gone, HotOS ’19, 2019.
Atul Adya ら, Centrifuge: Integrated Lease Management and Partitioning for Cloud Services, NSDI 2010.
Atul Adya ら, Slicer: Auto‑Sharding for Datacenter Applications, OSDI 2016.
Sangmin Lee ら, Shard Manager: A Generic Shard Management Framework for Geo Distributed Applications, SOSP 2021.
Atul Adya & Jonathan Ellithorpe, Stateful services: low latency, efficiency, scalability — pick three, HPTS 2024.

同じ日のほかのニュース

一覧に戻る →

2026/01/14 5:45

**ゲームズ・ワークショップ、スタッフのAI使用を全面禁止　経営陣はテクノロジーに興味津々でない** - 同社は従業員が業務上人工知能ツールを利用することを一律で禁じる方針を採用しました。 - 経営層は知的財産の安全性や創造的コントロールへの影響を懸念していると述べています。 - 業界内では注目が集まっても、上級経営者はAIがデザイン・生産フローに与えるメリットに対し慎重な姿勢を保ち続けています。

## Japanese Translation: **改善された概要** Games Workshop は、コンテンツ制作と設計プロセスにおける生成型 AI ツールの使用を正式に禁止しました。この方針では、厳格な監視下で数名の上級マネージャーのみが AI を実験できるようになっていますが、その可能性についてはまだ誰も興奮していません。外部コンペティションへの参加を含む不正使用は禁止されており、企業はデータ準拠・セキュリティ・ガバナンスを監視し、AI/ML エンジンがデバイスに自動インストールされるのを防止する必要があります。 GW の禁止措置は知的財産権を保護し、人間クリエイターを尊重するとともに、上級スタッフによる限定的な調査を許可しています。この決定は、より広い文脈の中で行われました。GW は *Warhammer 40,000* や *Age of Sigmar* などのフラッグシップテーブルトップタイトルを所有し、高品質のコデックス本・ミニチュア・アニメーションを販売しており、最近は新規採用で Warhammer Studio を拡大しました。Displate の作品に関する最近の紛争―Displate がそのアートワークが AI によって生成されたと否定し、「赤旗」を人為的なミスに帰せたケース―は、ファンが生成型 AI アートに対して反発していることを示しています。特に Warhammer の美学に大きな影響力を持つアーティスト John Blanche の存在がその背景にあります。今後も GW はデータ準拠とセキュリティの監視を継続します。上級マネージャーは AI の可能性を探るかもしれませんが、内部方針の変更や外部圧力が変わらない限り、広範な採用は見込めません。この禁止措置により GW は Genvid、EA、Square Enix など AI を積極的に導入している競合他社に比べて遅れを取ることになり、ゲーム開発の競争ダイナミクスが変わる可能性があります。これは生成型 AI の統合に対する業界全体の慎重な姿勢を反映しています。

2026/01/14 2:10

**チューリップ・クリエイティブ・コンピュータ** - 芸術と技術のユニークな融合 - 革新的なビジュアル体験を設計 - 鮮やかなカラーパレットと最先端ハードウェアを組み合わせる

## 日本語訳： **Tulip CC** は低電力で手頃な価格のセルフコンテインドポータブルコンピュータで、オープンソースの音楽ワークステーションとしても機能します。ESP32‑S3マイクロコントローラを中心に構築され、MicroPython を実行し、AMY ステレオ 120 ボイスシンセサイザーエンジン（加法／減法/F‑M 合成、サンプラー、Karplus–Strong、アナログフィルタ、シーケンサー、ドラムマシン、パッチエディタ）とキャパシティブ・マルチタッチ対応のタッチスクリーンディスプレイを備えています。デバイスは 8.5 MB の RAM（MicroPython 用 2 MB、OS 用 1.5 MB、残りがグラフィックスフレームバッファ）と 32 MB のフラッシュ（うち 24 MB が使用可能）、Wi‑Fi、USB キーボード/マウス/MIDI、I²C/Grove/Mabee コネクタをセンサーや周辺機器用に搭載し、組み込みの pico/nano スタイルエディタ（構文ハイライトと REPL）も備えています。グラフィックスは LVGL によって処理されます：テキストフレームバッファ 128 × 50（ANSI 256 色）、スキャンラインあたり最大 32 スプライト（32 KB ビットマップメモリ）、1024 × 600 の背景フレームバッファでスクロール、PNG ローディング、デフォルト 30 FPS、解像度調整可能、256 色。電力消費は 5 V で 575 mA（中程度の輝度）で、LiPo、18650、または USB バッテリーパックに対応しています。追加ソフトウェア機能として、ネイティブチャット/ファイル共有 BBS「TULIP ~ WORLD」、MIDI 入出力コールバック、およびクリエーションの共有用 Web バージョンがあります。 Tulip CC は市販ユニット、DIY ハードウェアキット、フル機能の Web アプリ、またはネイティブデスクトップアプリ（Mac/Linux/WSL）として入手可能です。開発リソース—完全な API ドキュメント、チュートリアル、Discord コミュニティ、およびオープンソース GitHub リポジトリ—が提供されており、埋め込みデバイスとデスクトップ環境の両方で動作するために貢献が必要です。将来のファームウェア更新では、合成モジュールの拡張、LVGL を介したグラフィックス解像度の向上、および電力効率の改善がコミュニティの入力を受けて行われる可能性があります。

2026/01/14 1:22

「二つの頭（＝複数の視点）が一つより優れているのでしょうか？」

## Japanese Translation: ## 要約コイントスの結果を時折だけ報告する人々がいる場合、報告者数が奇数であると予測精度が向上し、さらに1人追加して偶数にすると追加効果は得られないという点が主旨です。シミュレーションと解析的な検証から次のように示されています：正直な友人（80 % 正解率）を1人だけ持つ場合、2人目を加えても精度は80 %のままであり、合意しても不一致が相殺されるため利益がありません。3人目が参加すると精度は90 %に上昇し、4人目が加わると再び90 %に戻ります。このパターンは奇数回報者ごとに繰り返されます。この発見はコンドルセートの陪審理論を反映しており、偶数規模のグループでは多数決が引き分けになる可能性があるため、新たな情報を提供しないことを説明しています。著者は、創造的執筆プロジェクトを開催するプログラミングリトリート「Recurse Center」でベッティングシミュレーションを実行している際にこの現象に気付きました。今後の研究では、この傾向がより複雑な投票設定や大規模グループでも維持されるかどうかを検証することが期待されます。グループサイズと偶奇性が意思決定品質に与える影響を理解することで、クラウドソーシングサイト、陪審制度、または人間の判断を集約するあらゆるプラットフォームの設計者が、不必要な偶数参加者を追加しないよう助けることができます。

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