Databricks、Lakebase PostgresのコンピュートキャッシュにおけるCPU・レイテンシー改善策を発表
Databricksによると、大規模なLakebaseコンピュートノードにおいてPostgresの共有バッファを拡大し、新たにヒュージページメモリのサポートを追加したことで、レイテンシーとCPU使用率が低下したという。本番環境でのテストでは、スループットが最大2倍に向上した例も示されている。
ひとことで言うと
DatabricksはLakebase Postgresのコンピュートキャッシュ改善について何を発表したのか。
Databricksによると、大規模な固定サイズのLakebaseコンピュートノード(CU 80以上)において、Postgresの共有バッファをDRAMの75%まで引き上げ、専用のヒュージページメモリのサポートを新たに追加した。これにより、共有バッファを約1GBに制限していた従来のローカルファイルキャッシュ方式を置き換えたという。同社は、本番環境でスループットが最大2倍に向上し、ストレージからの読み取りが減少、CPU使用率とレイテンシーも低下したと報告している。
要点
- Databricksによると、大規模な固定サイズのLakebaseコンピュートノード(CU 80以上)において、Postgresの共有バッファを従来の約1GBの上限から利用可能なDRAMの75%まで引き上げ、これらのノードではローカルファイルキャッシュを無効化したという。
- 同社は、共有バッファの拡大に伴うメモリ変換のオーバーヘッドを軽減するため、仮想マシンインフラ全体にわたって専用の2MBヒュージページメモリのサポートを導入したとしている。
- Databricksはベンチマークテストの結果として、ヒュージページによりテールリードレイテンシーが最大約40%、CPU使用率が最大約30%削減されたと報告している。
- Databricksが挙げる本番環境の事例では、あるエンドポイントでアクセスされたブロックのスループットがおよそ倍増する一方でストレージ層からの読み取りが約5分の1に減少し、別のエンドポイントではCPU使用が20コアから4コアに減少した。
- Databricksによると、この展開は2026年9月10日の記事公開の数週間前からリージョンごとに開始されており、シリーズ第2弾となる予定の記事では共有バッファのオートスケーリングに関する取り組みを取り上げるとしている。
Databricksが発表した内容
Databricksは2026年9月10日、Lakebase Postgresサービスがコンピュートノード上でデータをキャッシュする仕組みの変更点について解説するブログ記事を公開した。シリーズ第1弾と位置付けられるこの記事は、David Wein氏、Sunil Kamath氏、Haoyu Huang氏によるものだ。Databricksは、より多くのデータをPostgresの最速メモリ層に保持することで、Lakebaseコンピュートで利用可能なDRAMをより効率的に活用することが狙いだとしている。
キャッシュ構成の背景
Databricksによると、Lakebase Postgresは分離型ストレージモデルを採用しており、キャッシュは分散ストレージとコンピュートノード自体の両方で行われる。標準的なPostgresの構成では、データベースは「共有バッファ」と呼ばれるインメモリ領域にデータをキャッシュする一方、オペレーティングシステムも同じページを独自のページキャッシュに別途キャッシュする。Databricksは、この構成が二重バッファリングを引き起こし、1GBのキャッシュデータが結果的に2GBのRAMを消費することになると指摘する。またDatabricksは、Postgresの共有バッファは通常静的な設定であり、変更にはデータベースの再起動が必要になるため、サーバーレスでオートスケーリングするシステムにとっては課題になると述べている。
この問題を回避するため、Databricksはローカルファイルキャッシュ(LFC)を構築し、これをサービス開始以来すべてのLakebaseコンピュートで稼働させてきたという。LFCはコンピュートノードのローカルNVMeストレージ上に位置し、共有バッファの背後にある二次層として機能する。DatabricksはこれまでLakebaseの共有バッファを保守的にチューニングしており、コンピュートの総メモリ量にかかわらず約1GBに制限していた。
共有バッファの拡大とヒュージページ
Databricksは現在、大規模な固定サイズのコンピュートノードについて、この約1GBの上限を撤廃したという。CUが80以上のコンピュートでは、LFCを無効化し、Postgresの共有バッファを利用可能なDRAMの75%に設定することで、頻繁にアクセスされるページをより多く最速のメモリ層に保持し、低速なローカルキャッシュへのフォールバックを減らしているとしている。Databricksによれば、顧客はPostgres接続で「show shared_buffers」を実行することで設定を確認でき、80 CUのエンドポイントでは20971520という値が返されるはずだという。
共有バッファの拡大はPostgresのプロセス・パー・コネクション方式においてメモリ変換のオーバーヘッドを増大させるため、Databricksは仮想マシンインフラ全体にわたって専用の2MBヒュージページメモリのサポートも導入したという。ベストエフォート型のトランスペアレント・ヒュージページに頼るのではなく、明示的なHugeTLBページを採用した形だ。同社は、これを実現するにはホストレベルからハイパーバイザー、ゲストカーネルに至るまで一貫したサポートが必要だったとしている。顧客は「show huge_pages」を実行することで設定を確認でき、80 CUのエンドポイントでは「on」が返されるはずだとDatabricksは説明している。
報告された成果
Databricksによると、ベンチマークテストではヒュージページの導入によりテールリードレイテンシーが最大約40%、CPU使用率が最大約30%低下したという。同社は、この展開が記事公開の数週間前からリージョンごとに順次開始されたとし、コンピュート再起動後に計測した3つの本番環境の事例を挙げている。ある大規模エンドポイントでは、アクセスされたPostgresブロック数が毎秒ベースで倍増し、ストレージ層からの読み取りが毎秒約8,000件から約1,500件に減少した一方、顧客側では前日・前週・前月と比べてp50およびp99レイテンシーが改善したと報告されたという。2つ目のエンドポイントでは、スループットが約43%向上し、コンピュートキャッシュのヒット率がほぼ100%に達したとしている。3つ目のエンドポイントでは、変更後にCPU使用が20コアから4コアに減少すると同時に、スループットが倍増したという。
Databricksは、共有バッファは現時点で動的にスケールできないため、今回の変更は固定サイズのコンピュートに適用されるものであり、シリーズ第2弾となる予定の記事では共有バッファのオートスケーリングに関する取り組みを取り上げるとしている。
出典:Databricksブログ「Improving Lakebase Postgres compute cache」、2026年9月10日公開。
よくある質問
- Databricksが発表したLakebase Postgresのコンピュートキャッシュの変更点とは何か。
- Databricksによると、大規模な固定サイズのコンピュートノード(CU 80以上)において、Postgresの共有バッファを利用可能なDRAMの75%まで引き上げた。これにより、共有バッファを約1GBに制限し、二次的なローカルファイルキャッシュに依存していた従来の構成を置き換えたという。
- Databricksはどのような性能改善を報告しているのか。
- Databricksは、本番環境の事例としてスループットが約1.3倍から2倍に向上したこと、あるエンドポイントではストレージ層からの読み取りが最大で5分の1に減少したこと、別のエンドポイントではCPU使用が20コアから4コアに減少したことを挙げている。
- 共有バッファの拡大に伴うオーバーヘッドに、Databricksはどう対処したのか。
- 同社は、仮想マシンインフラ全体にわたって専用の2MBヒュージページメモリのサポートを追加したとしており、ベンチマークテストではテールリードレイテンシーが最大約40%、CPU使用率が最大約30%削減されたという。
- 今回の変更はすべてのLakebase Postgresコンピュートに適用されるのか。
- Databricksによると、拡大された共有バッファの設定は現在、CU80以上の固定サイズのコンピュートにのみ適用されており、オートスケーリング型のコンピュートについてはシリーズ第2弾となる予定の記事で取り上げるとしている。