Lakebase Postgres コンピュートキャッシュの改善

Lakebase Postgresのストレージ分離型モデルは、機能が豊富で柔軟性が高く、低コストなプラットフォームを提供します。データがS3などのオブジェクトストアに保存されている間、高いスループットと低レイテンシを実現するには、効率的なデータのキャッシュが不可欠です。

このキャッシュは2つのレイヤーで行われます。1つ目は分散ストレージレイヤーで、高い書き込みスループットと読み取り処理を実現するためにPostgresページが実体化（マテリアライズ）されます。2つ目はPostgresのコンピュート自体で、頻繁にアクセスされるページをDRAMから提供して超高速アクセスを実現します。

私たちはコンピュート側のキャッシュ機能の改善に精力的に取り組んできました。このブログでは、今後の短期的な計画を説明するとともに、すでに提供開始されている機能について詳しく解説します。

まずは、これまでの経緯について背景を説明します。

標準的なPostgresのキャッシュ

データベースがDRAM（メモリ）を大量に消費することはよく知られています。データベースは主にこのメモリをデータキャッシュとして使用し、キャッシュ内の行へのアクセスがナノ秒単位（最も高速なNVMeドライブよりも桁違いに高速）で行われることを想定しています。

Postgresはデータをページ上の行として整理し、アクティブにアクセスされているページは「shared buffers（共有バッファ）」として知られるメモリ領域にロードされる必要があります。Postgresは伝統的にオペレーティングシステムのファイルシステムを使用してページを保存するため、OSカーネルもその柔軟なページキャッシュを使用して、Postgresの共有バッファとディスクの間でキャッシュを提供します。

この共有バッファとページキャッシュを組み合わせた仕組みはそれなりにうまく機能しますが、いくつかのデメリットと課題があります。

デメリット

1. 二重バッファリングにより、コンピュート上で効果的にキャッシュできるデータ量が減少します。例えば、4 GBのRAMを搭載したコンピュートで、1 GBを共有バッファに使用しているとします。ディスクからページを読み込んで1 GBの共有バッファに配置する際、その読み取りはOSのページキャッシュを経由するため、ページキャッシュ側にも同じデータが保持されます。その結果、1 GBのデータをキャッシュするために2 GBのRAMを消費することになります。
2. OSのページキャッシュは、共有バッファやPostgresの内部構造を認識していないため、どのページを置き換えるべきかについて賢明な判断を下すことができません。

技術的な課題

1. Lakebase Postgresのようなストレージ分離型システムでは、ストレージから読み取られたデータはOSのファイルシステムやページキャッシュを経由しません。
2. 共有バッファは静的なパラメータです。つまり、Postgresの起動前に設定され、データベースを再起動しなければ変更できません。これは、Lakebaseのようなサーバーレスのオートスケーリングシステムにとって大きな課題となります。
3. Postgresはアクティブな接続ごとに個別のOSプロセスを使用するため、共有バッファが大きくなる（つまり、Postgresに割り当てるメモリが増える）ほど、OSはすべての接続に対してより多くのメモリ管理を行う必要があり、結果としてメモリを消費します。

Lakebaseのキャッシュパス

背景を説明したところで、Databricksでこれらの課題をどのように解決しているかについて説明します。

私たちが目指す最終的なゴールは、ワークロードに応じて自動スケーリングし、利用可能なメモリの最大75%を使用するPostgresの動的共有バッファを介して、コンピュート上のDRAMを最も効率的に活用することです。

最終的には自動スケーリングする共有バッファを活用するようにコンピュートプラットフォームを調整する必要がありますが、利用可能になった段階で、実用的な段階的改善をお客様に提供したいとも考えています。段階的なリリースを行うことで、ロードマップの一部を確実に提供しながら、お客様に実際のメリットをもたらすことができます。そのため、自動スケーリングするコンピュートが最終目標であっても、次のセクションで説明するように、まずは固定サイズのコンピュートから開始しました。

以下は、私たちが実装した内容です。

より大きな共有バッファ

前述の技術的な課題で触れたように、Lakebaseのようなストレージ分離型システムは、標準のOSファイルシステムやそのページキャッシュを経由して読み取りを行いません。また、Postgresの共有バッファは静的であり、自動スケーリングできないことも思い出してください。

これを解決するために、私たちはローカルファイルキャッシュ（LFC）と呼ぶレイヤーを作成しました。LFCは代替手段として機能し、共有バッファと連携して動作する自動スケーリングキャッシュを作成し、可能な限り多くのデータをコンピュート上にキャッシュした状態に保ちました。これは、Lakebase Postgresが自動スケーリングを開始できるようにした巧妙かつ実用的なソリューションであり、ローンチ以来すべてのコンピュートで使用されています。

ユーザーには単一の高速コンピュートキャッシュとして公開されていますが、基礎となるアーキテクチャは最大2つの階層をサポートしています。

• 共有バッファ：Postgresのインメモリ共有バッファ。最も低レイテンシなアクセスパスを提供します。
• ローカルファイルキャッシュ：コンピュートノードのローカルNVMeに存在する拡張セカンダリキャッシュ。メモリよりも大容量ですが、ページへのアクセスにはディスクI/Oが必要です。

共有バッファは、最小構成のCUで実行したときにメモリを消費しすぎないように保守的に調整されており、これまでに構成された最大サイズは1 GBの共有バッファで、残りの合計コンピュートキャッシュ容量（DRAMの最大75%）はLFCが消費していました。両方の階層でキャッシュミスが発生したリクエストは、コンピュートノードから分散ストレージレイヤーにルーティングされます。

より大きなワーキングセットでは、共有バッファを1 GBに制限すると、ほとんどのキャッシュヒットがより低速なLFC階層を経由せざるを得なくなりました。LFCはこれまで十分に役立ってきましたが、完全に動的な共有バッファへの移行を進めるにあたり、現在の形態を終了する予定です。

ホットデータをOSのページキャッシュではなく共有バッファに保持することは、前述のデメリットの解消にもつながります。二重バッファリングが発生しないため、1 GBのキャッシュデータは2 GBではなく1 GBのRAMを消費するだけです。また、キャッシュはカーネルではなくPostgresの内部に存在するため、データベースの状態を把握した上で破棄（エビクション）の判断を下すことができます。これにより、OSが提供できるものよりもスマートな置き換えポリシーを追求することが可能になります。

固定サイズのコンピュートで共有バッファのサイズをDRAMの75%に設定することは、単に設定を変更するほど簡単なことではありませんでした。なぜなら、3番目の技術的課題である「バックエンドごとのプロセス」アーキテクチャがあるからです。

次のセクションでは、私たちのソリューションについて説明します。

huge pagesによるメモリと変換オーバーヘッドの解消

Postgresはプロセスベースの構造を使用しており、各バックエンドが共有バッファを独自のアドレス空間にマッピングするため、独自のページテーブルエントリ（仮想アドレスを物理メモリに変換するためにハードウェアが走査する、カーネルが管理する構造）が必要になります。デフォルトでは、Linuxはこのマッピングを4 KBページで行います。

簡単な数値を挙げると、共有バッファ1 GBごとに、プロセスあたり262,144個のページテーブルエントリが対応します。共有バッファが32 GBでバックエンドが512個の場合、これは約43億個のエントリに相当し、32 GBのキャッシュをマッピングするために約32 GBのページテーブルが必要になります。

このワーキングセットは、仮想から物理への変換を高速化するCPUのメモリ管理ユニット内のキャッシュであるTLB（Translation Lookaside Buffer）の容量も大幅に超えています。そのため、共有バッファがヒットした場合でも、TLBミスやページテーブルウォークによるペナルティが発生します。

これを軽減するために、Postgresコミュニティは、大容量の共有バッファを使用する際に、huge pages（それぞれ2 MB）と呼ばれるOSのメカニズムを使用することを推奨しています。huge pagesに切り替えることで、ページテーブルのサイズが512分の1に削減され、TLBミス率が大幅に低下します。

私たちのベンチマークテストでは、Postgresをhuge pagesで構成することにより、テール読み取りレイテンシが最大約40%削減され、CPU使用率が最大約30%低下しました。

仮想化環境におけるhuge pageのサポート

Lakebase Postgresは、ベアメタルホスト上の軽量なゲスト仮想マシン（VM）内で実行されます。メモリアドレスの変換には、2つの仮想化レイヤーが関与します。huge pagesを活用するには、ホストレベルでの予約から、VMのメモリをバッキングするハイパーバイザ、そしてゲストカーネルに至るまで、スタック全体で一貫した実装が必要です。いずれかの層で不具合が生じると、得られるパフォーマンス上のメリットが損なわれます。

私たちは最近、VMインフラ全体に専用のhuge-pageバッキングを導入しました。ベストエフォート型のtransparent huge pages（透過的huge pages）に依存するのではなく、明示的な2 MBのHugeTLBページを使用することを選択しました。現在、大容量の固定サイズコンピュートに割り当てられたVMは、Postgresの起動に十分な、あらかじめ決められた量のhuge pagesで初期化されます。システムリソースを最適化するため、コンピュートの起動時に、Postgresが必要とする量を超える余分なhuge pagesは自動的に解放されます。

本番環境での結果

ロールアウトは数週間前にリージョンごとに開始されました。以下の例は、新しい構成を有効にする再起動の後に、大規模な本番エンドポイントで測定されたものです。

例1：スループットが約2倍に向上、ストレージからの読み取りが5分の1に減少

ある大規模なエンドポイントでは、この変更は8月11日の06:10 UTC頃に有効になりました。1秒あたりにアクセスされたPostgresブロック数が倍増しました。ここではこれをスループットの代替指標として使用しています。お客様からは、前日、前週、前月と比較して、p50およびp99のレイテンシーが低下したとの報告がありました。

このエンドポイントは、大規模なローカルファイルキャッシュを構成していました。共有バッファが大きくなったことで、ストレージのGetPage/秒は1秒あたり約8Kから約1.5Kに減少しました。

例2：スループットが1.3倍に向上

別の計画的な大規模エンドポイントでは、この変更は8月14日の01:30 UTC頃に有効になりました。スループットは約43%向上しました。

コンピュートキャッシュのヒット率は100%近くに達し、リクエストはほぼ完全に共有バッファから処理されました。

例3：CPU使用率が5分の1に低下、スループットが2倍に向上

このワークロードでは、8月15日のロールアウト後、CPU使用率が20コアから4コアに低下しました。コンピュートキャッシュのヒット率はほぼ100%に上昇し、測定されたスループットは倍増しました。

パート2：オートスケーリング

現在、オートスケーリングを行うPostgresコンピュートに、より大きな共有バッファを導入する取り組みを進めています。オートスケーリングにはさらなる複雑さが伴います。スケールアップ時には共有バッファを動的に拡張し、スケールダウン時には縮小する必要があります。これらはすべて、必要な正確な量のヒュージページを割り当てながら行う必要があります。

固定サイズのコンピュートから脱却するため、ゲストに提供されるヒュージページをオートスケーリングするためのプロトコルを開発しました。ヒュージページは動的共有バッファと連携してスケーリングされ、高い同時実行性とメモリサイズでも効率的なアドレス変換を維持できるようにします。次回の投稿（パート2）では、オープンソースのPostgresの現状や、この機能をさらに進化させてアップストリームに貢献するために当社が選択した領域など、この動的共有バッファ実装の技術的な詳細について掘り下げます。

試してみる

これらのパフォーマンス向上はすべて、Lakebase Postgresのアーキテクチャに起因しています。ストレージレイヤーは信頼できる唯一の情報源（system of record）として機能し、コンピュートノードはステートレスであり、そのメモリはキャッシュレイヤーとして機能します。

Lakebase Postgresをデプロイして、そのパフォーマンスをお試しください。ここから開始できます。

Lakebase Postgresはスタンドアロンのデータベースとして使用できるほか、Databricks Data + AIプラットフォームの他の機能（Unity Catalogによるガバナンス、レイクハウス分析、ノートブック、AIワークフローなど）と統合することもできます。

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