オブジェクトストレージ + WAL：エージェント時代のLakebase Postgres

従来のOLTPデータベースとやり取りするエージェントは、ストレージレイヤーでボトルネックを発生させがちです。新規デプロイ、コピー、リストア、レプリカの作成はすべて、大量のデータを移動させることを意味し、時間とコストがかかります。

オブジェクトストレージはその真逆です。たとえばAmazon S3は、安価でパフォーマンスが高く、運用コストもほとんどかかりません。エージェントメモリ向けに、スケーラブルで費用対効果の高いストレージレイヤーを構築できます。

そこで疑問が生じます。オブジェクトストレージをトランザクションデータベースの下層に配置し、エージェントの作業をより容易にすることはできるでしょうか？

この疑問から始まったのがLakebase Postgresです。その答えは、オブジェクトストアの速度だけでなく、信頼できる唯一の情報源（source of truth）をどこに配置するかによって決まります。

2つのOLTPモデル

OLTPの一般的なメンタルモデルは「データ中心」です。データは行と列を持つテーブルに整理され、それぞれがエンティティを表します。ストレージは現在の状態が保持される場所であり、データベースの役割はそれを保存し、取得することです。

しかし、もう1つのモデルがあります。それは「トランザクション中心」モデルです。ここでは、データベースはトランザクションのジャーナル（履歴）となります。各エントリは1つの操作であり、ストレージは現在のスナップショットではなく、それらの操作のタイムラインになります。現在の状態は、そのタイムラインから導き出せるものの1つにすぎません。

長年にわたり、実際に重要視されていたのはデータ中心モデルだけでした。運用チームがデータベースに求めていたのは、現在のデータに対する読み取りと書き込みだったからです。しかし、ここ数年で状況は劇的に変化しました。エージェントのワークロードが求める操作のほとんどは、トランザクション履歴に対する操作です。

• 作業用に、本番環境の隔離されたコピーを作成する
• 直近の3つのステートメントを実行する前の状態に戻す
• マイグレーション前のこのテーブルの状態を表示する
• これらを一度に20個実行し、1時間後にそのうちの19個を削除する

これらはすべてタイムラインに関するクエリです。現在の状態のみを保存するデータベースは、コピーやバックアップを提供しますが、これらは処理が遅く、コストもかかります。

しかし、Postgresにはすでにこのタイムラインが含まれています。それがライトアヘッドログ（WAL）と呼ばれるものです。

WALに書き込まれる内容

PostgresのWALは、データファイルに到達する前のすべての変更を記録します。もともとはPostgresの復旧（リカバリ）用に存在していたもので、ログの書き込みとデータファイルの書き込みの間にサーバーが停止した場合、WALをリプレイすることでそのギャップを埋めていました。

しかし、WALの内容は単なる復旧にとどまらない興味深いものです。あるテーブルと、そこへの挿入（INSERT）操作を例に考えてみましょう。

その変更がディスク上のusersテーブルに到達する前に、PostgresはそれをWALに追加します。ログはバイナリ形式ですが、pg_waldumpによってレンダリングされます。この挿入操作のレコードは、大まかに以下のようになります。

これらは4つのレコードと1つのトランザクションです。それぞれに、単調増加する識別子であるログシーケンス番号（LSN）が割り当てられていることに注目してください。

heapとbtreeの行は、変更された正確な8 KBのページも指定しています。ログには「行が追加された」とは記録されません。どのリレーションのどのページが、タイムラインのどの時点で変更されたかが記録されます。

これを復旧メカニズムとして捉えれば、クラッシュ後に再実行（redo）すべき作業のリストになります。しかし、これをトランザクションジャーナルとして捉えれば、まったく別のものになります。それは、データベースがこれまでに変更したすべてのページに関する、順序付けられた完全なバイトレベルの記録であり、すべてのエントリに一意の名前が付いていることになります。

その名前、つまりLSNこそが最も重要な部分です。これは、タイムラインがすでにアドレス可能であることを意味します。「特定時点のデータベース」を明確に定義するために、Postgresに何かを追加する必要はありません。必要なのは、ログを保持し、それに対する問い合わせに答えられるストレージレイヤーだけです。

ログが信頼できる唯一の情報源になる

従来のPostgresデプロイメントでは、WALは目的を達成するための手段にすぎません。データファイルこそがデータベースであり、ログはそれらを保護し、レコードが安全に適用されると削除されます。ストレージは単にPostgresを実行しているマシンに接続されたディスクであり、データベースのアイデンティティに関するすべてがそのマシンに紐付いています。

では、これを逆転させてみましょう。ログをデータベースとし、データファイルをそこから派生したキャッシュ表現にするのです。そうすれば、完全なタイムラインを保持でき、データベースのコピーや巻き戻し（リワインド）のためにデータを移動する必要がなくなります。履歴がアドレス可能になるため、データベースの「コピー」は、2つ目のファイル群ではなく、単なるポインタになります。これにより、デプロイ、リストア、レプリカ作成を、コードのように手軽に扱えるほど低コストで行えるようになります。

これが、私たちがLakebase Postgresで行ったことです。具体的には、システムを2つのレイヤーに分割しました。

コンピュートレイヤー

コンピュートレイヤーは、標準のPostgresを実行します。SQLのパース、クエリの計画と実行、MVCCの適用、ロックとインデックスの管理を行います。

クエリエンジンの中身は何も書き換えられていません。変わるのは、コンピュートノードが担う役割です。コンピュートノードはデータを保存するためではなく、処理を実行するために存在します。共有バッファ用のRAMと、ページキャッシュとしてのローカルNVMeを備えており、耐久性を損なうことなく、いつでも起動、停止、スケール、またはクラッシュさせることができます。

ストレージレイヤー

ストレージレイヤーは、正確性、耐久性、および履歴を管理します。個々のコンピュートノードよりも長寿命であり、それぞれ異なる役割を持つ3つのコンポーネントで構成されています。

• SafekeeperがWALをレプリケートする。コンピュートノードがWALレコードを生成すると、それを複数のSafekeeperにストリーミングし、Paxosベースのプロトコルを通じてクォーラムがレコードを承認した時点でトランザクションがコミットされます。耐久性は、1台のマシンのfsyncではなく、レプリケーションと合意形成（コンセンサス）の特性によって担保されます。
• PageserverがWALをページに変換する。ベースページとコミット済みのWALレコードを組み合わせて、特定のクエリが必要とするバージョンのページを実体化（マテリアライズ）し、それらの実体化されたバージョンを非同期でオブジェクトストレージに永続化します。
• オブジェクトストレージが長期的な不変の履歴を保持する。 実体化されたページバージョンと履歴の状態は、変更可能なファイルシステムではなく、追加専用（アペンドオンリー）のレコードとして保持されます。

書き込みパス

書き込みパスはどのようになっているでしょうか？このシステムにおけるコミットは、以下の手順で行われます。

1. Postgresがメモリ上で変更を適用します。通常とまったく同様に、バッファが更新され、インデックスが変更され、WALレコードが生成されます。
2. コンピュートノードは、WALをローカルファイルシステムにフラッシュする代わりに、ネットワーク経由でSafekeeperにストリーミングします。
3. Safekeeperのクォーラムがレコードを承認すると、トランザクションがコミットされます。この時点で、クライアントに成功が通知されます。
4. ページの実体化はその後、トランザクションのクリティカルパス外のストレージレイヤーで行われます。コミットがページの書き込みやアップロードを待つことはありません。

この設計に対しては、「ステップ2によってコミットパスにネットワークホップが追加される」という当然の反論があるかもしれません。しかし、耐久性を重視するPostgresのデプロイメントでは、すでに同期レプリケーション（これもネットワークホップを伴います）が実行されています。WALを外部化することは、ネットワークのラウンドトリップを増やすのではなく、あるラウンドトリップを別のものに置き換えるだけです。

読み取りパス

コンピュートノードからのすべての読み取りリクエストには、ページ識別子とLSNが含まれており、ストレージレイヤーはそのLSNの時点に存在していたページを返します。このGetPage@LSNは、このアーキテクチャにおける中心的な操作です。

これを処理する際には、以下の優先順位が適用されます。

1. 最優先されるのは、通常のPostgresと同様に、Postgresの共有バッファ用のRAMです。
2. 次に、高速でローカルに存在するローカルNVMeです。ページがメモリ上にない場合、コンピュートノードはローカルディスクキャッシュを確認します。
3. ローカルキャッシュに存在しない（ミスヒットした）場合にのみ、リクエストはネットワークを介してPageserverに送られます。Pageserverは、そのバージョンのページがすでに実体化されているかどうかを確認します。実体化されていない場合は、リクエストされたLSN以前の最も新しいページのイメージを見つけ、その上にWALレコードを重ねてリプレイし、再構築されたページを返します。

返されたページはRAMとNVMeにキャッシュされるため、次回の読み取りは再びローカルで行われます。

プライマリノードはすべてのページの最新バージョンを要求するため、定常状態ではウォームキャッシュから読み取る通常のPostgresと同じように動作します。しかし、プロトコルにおいて「最新」である必要はまったくありません。4時間前のLSNにおけるページを要求すれば、その4時間前のページを取得できます。

この便利な結果として、稼働中のデータと履歴バックアップの区別がなくなります。ストレージシステムは1つだけです。古いページのバージョンは、別の場所に異なる形式で保管される個別の成果物ではありません。それらは同じ不変（イミュータブル）なファイルであり、引き続きアドレス指定可能です。

上書きしないストレージ

言い換えれば、ページサーバーがファイルをその場で更新することは決してありません。ファイルは作成、マージ、削除されますが、変更されることはありません。これは、ランダムアップデートを提供しないオブジェクトストレージに最適であり、履歴を十分に低コストで保持できるようになります。

データは2種類のレイヤーファイルに整理されます。

• イメージレイヤーは、あるLSNにおけるキー範囲内のすべてのキーのスナップショットを保持します
• デルタレイヤーは、キーとLSNの範囲におけるすべての変更を保持します。変更されなかったキーは保存されません。入ってくるWALはデルタレイヤーとして書き出されます。

イメージレイヤーはバックグラウンドで作成されます。これには2つの理由があります。読み取り時にたどる必要のあるリプレイチェーンを短縮することと、古いデルタを回収可能にすることです。これらがないと、ページを再構築するために、任意の過去まで遡る必要が生じる可能性があります。

そのため、GetPage@LSNは探索になります。要求されたキーとLSNから開始し、レイヤーをたどってそのページのWALレコードを収集し、最初のイメージで停止します。この探索を短く保つために、デルタレイヤーとイメージレイヤーはバックグラウンドのコンパクションによって再編成され、保持期間の外にあるレイヤーはガベージコレクションされます。

適切なレイヤーを素早く見つける方法

上記の探索は単純に聞こえるかもしれませんが、そうではありません。設計全体が実現可能かどうかを左右するため、時間をかける価値があります。

読み取りでは、キーとLSNを指定します。ストレージシステムは、そのLSN以下でそのキーをカバーする最も近いレイヤーを見つける必要があります。これは幾何学的な問題であり、数千万ものレイヤーにわたってどのように解決するかは自明ではありません。線形探索は遅すぎますし、明らかな空間構造も適合しません。Rツリーは「このポイントの下にある最初のレイヤー」ではなく包含クエリに答えるものであり、セグメントツリーはレイヤー数ではなく座標空間のサイズに応じてスケールするためです。

この設計にはいくつかのアプローチがありますが、うまくいったのは、まず簡単な問題を解決し、次にデータ構造自体に過去を記憶させることでした。

ステップ1：単一のLSNに対して解決する

1つの固定されたLSNについて、どのレイヤーが各キーに対応するかを特定します。その答えはキースペース全体のわずかなポイントでしか変化しないため、それらのポイントを記録して二分探索木に保存します。そのツリーがそのLSNのレイヤーカバレッジとなり、1回のルックアップでそのLSNでの読み取りに対応します。

これは機能しますが、1つのLSNに対してのみです。レイヤーが追加されるたびにカバレッジは変化し、LSNは数百万もあるため、それぞれに対して個別のツリーを構築して保持することはできません。

ステップ2：ツリーを永続化する

ここでの永続化とは、「古いバージョンを利用可能な状態に保つ」という意味です。カバレッジを段階的に構築し、LSNの順に下から上へとレイヤーを挿入します。1つのレイヤーを挿入すると、ルートから下に向かう単一のパスに沿ったノードのみが影響を受けます。システムはそれらのノードを上書きする代わりにコピーし、オリジナルはそのまま残します。新しいコピーは、両側にある変更されていない古いサブツリーを指します。

これにより、次の2つのことが可能になります。

• パスから外れたものはすべて共有されるため、挿入コストはツリー全体を新しく作成するのではなく、わずかな新しいノード分だけで済みます
• 古いルートは挿入前のツリーの状態を正確に表したままであるため、以前のLSNに対する有効なカバレッジとして残ります

これをすべてのレイヤーに対して順番に行うことで、すべての未確定のルートを含む単一の構造が得られ、それぞれが異なるLSNでのカバレッジとなります。ほぼ1つ分のコストで、これらすべてのツリーを手に入れることができます。

これにより、履歴の読み取りコストは現在の読み取りコストと同じになります。システムは目的のLSNのルートを選択し、同じ1回のルックアップを実行します。

要約すると、仕組みは次のとおりです。

• 最新のみの読み取りは、1回のツリールックアップで済みます
• 履歴の読み取りは古いルートを使用するため、コストは同じです
• レイヤーが蓄積されてもこれらのルートの構築コストは低いままであるため、履歴が長くなってもルックアップが遅くなることはありません

オブジェクトストレージの実際の役割

Postgresとオブジェクトストレージに関する現在の議論は、双方向において誤解が生じやすい部分です。

オブジェクトストレージ上にOLTPを構築することに対する古典的な反論は、次のようなものです。

• Postgresは、レイテンシーに敏感な多数の小さなI/Oを処理します
• オブジェクトストレージは、より高いレイテンシーでより大きなリクエストを処理するように構築されており、そこからの読み取りには数百ミリ秒かかることがあります
• クエリ実行の前にS3を配置すると、データベースの動作が遅くなります

それ自体は異論のない主張です。この議論が誤っているのは、オブジェクトストレージ上に構築されたデータベースが、クエリに答えるためにオブジェクトストレージから読み取りを行わなければならないと仮定している点です。

私たちが提案するアーキテクチャでは、そのようなことは決してありません。

• クエリはオブジェクトストレージを読み取りません。コンピュートノードはRAM、ローカルNVMe、そしてページサーバーの順に読み取ります。オブジェクトストレージが読み取られるのはページサーバーの内部のみであり、保持していないページバージョンを再構築するときだけで、Postgresが直接読み取ることはありません。
• コミットはオブジェクトストレージに書き込みません。セーフキーパーのクォーラムがWALレコードを保持した時点でコミットが承認され、ページの具体化とアップロードはその後に行われます。

Postgresをこのように設計すると、エージェントワークロードを処理するために構築された、従来のOLTPシステムの進化形となります。これが、私たちがLakebase Postgresを開発した理由です。これは、コンピュートとストレージが分離され、永続的な信頼できる唯一の情報源（Source of Truth）がオブジェクトストレージ上に構築されたOLTPデータベースです。

バニラPostgresではなくLakebase Postgresを使用する理由

Lakebase Postgresを使用すると、トランザクション履歴はLSNによってアドレス指定可能になり、コピーはデータではなく参照になります。これにより、エージェントにとって絶対的な要件である軽量なワークフローをPostgresに提供する機能を構築できます。

ブランチ作成（ブランチング）

まず、Postgresでブランチを作成できるようになりました。ブランチを作成してもページはコピーされず、特定のLSNへのポインタが作成され、そこからコピーオンライト（Copy-on-Write）セマンティクスでブランチの分岐が開始されます。

ブランチへの書き込みは親に対するデルタとして保存されるため、2 TBのデータベースのブランチは数秒で作成され、変更が加えられるまでコストはかかりません。親データベースに追加の負荷はかからないため、本番環境に対して安全に実行できます。

これは、エージェントが安全に作業するために必要なものです。タスクごとにブランチを作成し、作成したばかりのマイグレーションを実際のデータと実際のボリュームに対して実行し、親データベースに影響を与える前に結果を確認できます。20個のエージェントが同時にこれを実行でき、それぞれが他のエージェントや本番環境から隔離されています。

Lakebase Postgresでは、データベースを超えてブランチ機能を拡張しました。オブジェクトストレージのバケット、Functions、Managed Better Authの状態、AI Gatewayの設定がデータベースとともに分岐するため、ブランチは単なるPostgresのテーブルではなく、バックエンドの隔離されたコピーとなります。

インスタントリストア

ポイントインタイムリカバリは、異なる目的を持ったブランチ作成です。リストアとは、以前のLSNを指してそこから再開することを意味するため、データを元の場所に戻すコピー処理は発生せず、そのコストはデータベースのサイズに比例しません。どこまで遡れるかは保持設定によって決まります。

これにより、エージェントのミスによるコストを低く抑えることができます。エージェントが誤ったステートメントを実行した場合、リストア期間や復旧計画を立てる必要はなく、実行前のLSNにブランチを戻すだけです。元に戻す（Undo）コストは、空のデータベースでも2 TB of データベースでも同じであるため、エージェントは人間にエスカレーションすることなく再試行できます。

タイムトラベルクエリ

ページサーバーは履歴ウィンドウ内の任意のLSNにおける任意のページを再構築できるため、最初にリストアすることなく、過去の状態を直接クエリできます。

実用的な用途としては、差分比較（Diff）があります。マイグレーションの前にこのテーブルがどのようになっていたか、そして現在はどのようになっているかを確認できます。また、リストアを実行する前に、正しいタイムスタンプを選択したかどうかを確認する手段でもあります。

レプリカなしのリードレプリカ

読み取り専用のコンピュートノードは、データのコピーではありません。プライマリと同じストレージレイヤーからページを要求するため、ノードを追加してもデータセットをプロビジョニングして同期を待つ必要はありません。ノードの起動はメタデータ操作のみで完了します。

ゼロへのスケール（スケール・トゥ・ゼロ）

永続状態はコンピュートの外部に存在するため、アイドル状態のコンピュートノードは、データを保護するために実行したままにするのではなく、完全にシャットダウンできます。コンピュートは5分間アクティビティがないと一時停止し、次のクエリが実行されると数百ミリ秒以内に再アクティブ化されます。セッションごと、またはブランチごとのデータベース群（そのほとんどはほとんどの時間アイドル状態です）にとって、これは実行可能なコストモデルと実行不可能なコストモデルの決定的な違いとなります。なお、一時停止中はコンピュートの課金は停止しますが、履歴は保持されるため、ストレージの課金は継続されます。

4分間動作した後に休止状態になったエージェントセッションは、誰も破棄（シャットダウン）しなくても、5分後にコンピュートコストの発生が停止します。これにより、エージェントごと、セッションごと、またはブランチごとのデータベースを、デフォルトとして採用できるほど手頃な価格で利用できるようになります。

トランザクションと分析で1つのコピーを共有

運用データをオブジェクトストレージに配置することには、もう1つの効果があります。

トランザクションデータベースの永続的な記録が汎用オブジェクトストレージに保存されると、特定のエンジンのディスク上にある独自のフォーマットにロックインされることがなくなります。他のエンジンからも読み取ることができるようになります。

これが、私たちがLTAP（Lake Transactional/Analytical Processing）と呼ぶものの基盤です。パイプラインによって同期される2つのフォーマットの2つのデータコピーを持つ代わりに、トランザクション側と分析側の両方が読み取るオープンな列指向フォーマットの永続コピーが1つだけ存在します。

この仕組みは、すでに説明した読み取りパスに基づいています。ページサーバーはページをオブジェクトストレージに実体化（マテリアライズ）する際、各値の正確なPostgres表現を保持したまま、Postgresの行フォーマットから列指向形式にトランスコードします。分析クエリはPostgresに現在のLSNを問い合わせ（これは低コストのメタデータ検索です）、そのLSN時点のデータの大部分をオブジェクトストレージから読み取り、まだ実体化されていない最新の変更のみをページサーバーから取得します。Postgresはその1つの数値を返すだけで、分析の読み取りトラフィックを一切処理しないため、大規模な分析クエリがトランザクションと同じCPUを奪い合うことはありません。

変更データキャプチャ（CDC）やミラーリングとの違いは、オプトイン（設定）が不要である点です。レプリケーションが存在しないため、レプリケートされたテーブルのリストもありません。テーブルはすでにレイク内に存在しているため、2つのビュー（トランザクションと分析）が乖離することもありません。

エージェント向けのLakebase Postgres

この記事の冒頭で、「オブジェクトストレージをPostgresの下層に配置し、エージェントがより扱いやすくすることはできるか？」という問いを投げかけました。

答えは「イエス」です。オブジェクトストレージをPostgresの下層に配置することで、データベースとのやり取りを大きく変えることができます。しかし、それは単にS3が高速であるとか、運用コストが安いからという理由だけではありません。この記事で説明したように、それ以上のエンジニアリングが必要です。クエリを十分に高速に処理するには、依然としてRAMやローカルNVMeが必要であり、コミットはバケットではなく、レプリケートされたWALに記録されます。

このWALの部分が鍵となります。オブジェクトストレージは、すべての履歴を保存するための安価でスケーラブルな方法を提供しますが、WALを信頼できる唯一の情報源（source of truth）とすることで、その履歴へのアクセスが可能になり、エージェントとPostgresのやり取りや、その上で構築できる機能が変化します。

エージェントにLakebase Postgresをデプロイさせて、その実力を試してみてください。今すぐ始める。

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

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