Lakebase アーキテクチャ
ベータ版
6月15日より、LakebaseはGCPでベータとして利用可能です。サポートされているリージョンについては、「リージョンの可用性」を参照してください。
Lakebase はストレージとコンピュートを分離します。クエリーを実行する Postgres エンジンはステートレスであり、データは独立して永続化される耐久性のあるストレージレイヤーに存在します。この分離により、オートスケール、ゼロへのスケール、インスタント Branch、リードレプリカ、および高速フェイルオーバーが可能になります。
Lakebaseが何を変更するかを示すため、このページではまず対比として従来のシングルマシンデータベース設計を取り上げ、次にLakebaseがその設計をどのように独立したレイヤーに分離し、各要素がどのような役割を果たすかを説明します。
従来のデータベースの構築方法
Lakebaseを見る前に、そのモデルに置き換えられていることを考えてみてください。従来のPostgresデータベースはモノリス型である。単一のマシンがクエリエンジンを実行し、 書き込み先行 Logs (WAL) とデータファイルの両方をローカルマウントポイントに接続されたディスクに書き込みます。従来、これらのディスクは完全にローカルなものであり、同じマシンの一部であったが、インフラストラクチャの進化に伴い、ネットワーク接続ストレージデバイスとなることが多くなった。
WALとデータファイルは、2つの補完的な役割を果たします：
- WAL は書き込みを高速化します。 Postgres は、commit を確認する前に各変更をログに順次追加します。これは単一ディスク上で高速かつ耐久性があります。
- データファイルは読み取りを高速化します。 Postgresは、すべてのページの現在のバージョンをデータファイルに具体化するため、クエリーはlogをリプレイすることなく行を読み取ることができます。
1台のマシンですべてのデータにアクセスすることには、欠点があります：
- 耐久性は、そのマシンの物理インフラストラクチャに直接関連付けられています。また、ストレージを事前にプロビジョニングし、ワークロードがどれだけ増加するかを予測する必要があり、コスト管理とレジリエンス計画の両方が複雑になります。
- 高可用性および多くの種類の水平スケーリングには、データベース全体の物理クローンが必要です。
- そのマシンが故障すると、データが失われる可能性があります。RAIDストレージのような技術はこのリスクを軽減しますが、冗長性が追加されることでシステム実行コストが大幅に増加する可能性があります。
Lakebaseのアーキテクチャ
Lakebaseは同じ役割を維持しつつ、それらを2つの独立したレイヤーに分離します。
- 標準のステートレス Postgres を実行する コンピュート レイヤー 。
- セーフキーパー、ページサーバー、およびクラウドオブジェクトストレージで構成される ストレージレイヤー 。
モノリスの2つのロールは、新しいコンポーネントに直接マッピングされます。書き込みを高速化したWALは safekeepers となり、書き込みをスケールさせます。読み取りを高速化したデータファイルは pageservers となり、読み取りをスケールさせます。
データは単一のマシンではなくクラウドオブジェクトストレージに存在するため、Lakebaseは弾力的でスケーラブルなコンピュートと、アベイラビリティゾーン間で複製される耐久性の高い書き込みを実現します。プロビジョニングするストレージはありません。消費したストレージに対してのみ料金が発生するため、ディスク不足のような障害モードを考慮して計画を立てる必要はありません。
このモデルはパフォーマンスも向上させる。Lakebaseは各変更を複数の場所に直接書き込むため、従来のトーンライト保護やブロックアライメントのオーバーヘッドを回避できます。すべての書き込みは既に複数の場所に送信されるため、高可用性が有効になっているかどうかに関わらず、パフォーマンスは一定に保たれます。
次の表は、モノリスの各パーツとそれに対応するLakebaseのパーツをマッピングしたものです。
従来型モノリス | Lakebase | ロール |
|---|---|---|
シングルマシン | ステートレスコンピュート | Postgres クエリーエンジンを実行します |
ローカル WAL ディスク | セーフキーパー | コミットされたすべての変更を永続的に記録します |
ローカルデータファイル | ページサーバーとオブジェクトストレージ | ページバージョンをマテリアライズして保存します |
コンピュート層
コンピュートレイヤーはPostgresを実行します。これは一時的な状態のみを保持します。具体的には、メモリ内のPostgres共有バッファと、高速なローカルディスクによってバックアップされるローカルコンピュートキャッシュです。永続的なデータは保持しません。
コンピュートは永続的な状態を保持しないため：
- データを移動したり損失したりすることなく、置換、再起動、オートスケール、またはゼロへのスケーリングが可能です。
- ローカルファイルシステムに書き込む代わりに、WAL をストレージレイヤーにストリームします。
- 複数のコンピュート インスタンスを同じストレージ層に接続できます。これが Lakebase の読み取りレプリカと高速フェイルオーバーの仕組みです。
ストレージレイヤー
ストレージ層は耐久性が高く、コンピュートとは独立して動作します。これには 3 つのコンポーネントがあります。
Safekeepers
Safekeeper とは、単一のマシンから取り出され、高可用性が確保された WAL です。Postgres が WAL レコードを生成すると、Paxos ベースのコンセンサスプロトコルを使用してクォーラム全体で log を複製する Safekeeper のグループにそれらがストリームされます。
トランザクションは、単一のマシンがローカルの fsync を完了したときではなく、セーフキーパーのクォーラムが WAL レコードを承認したときに commit されます。耐久性は、単一のディスクからではなく、ノード間でのレプリケーションによって確保されます。
Pageserver
Pageserver とは、WAL から取り出され、再構築されたデータファイルです。Pageserver は Safekeeper からの WAL ストリームを消費し、オンデマンドでページバージョンをマテリアライズします。コンピュートが特定のログシーケンス番号（LSN）でページを要求すると、Pageserver がそれを再構築して返します。
Pageserversは、オブジェクトストレージ上のライトスルーキャッシュとして機能します。これらはマテリアライズされたページをクラウドオブジェクトストレージに非同期で永続化するため、ページの再構築がトランザクションのcommitをブロックすることはありません。
クラウドオブジェクトストレージ
クラウドオブジェクトストレージは、ストレージレイヤー全体の耐久性の基盤となります。これは、pageserverが永続化するページデータを保持します。
GCP 上では、Lakebase はデータを Google Cloud Storage に永続化します。
オブジェクトストレージは、ホットクエリーパスから外れた場所に保持されます。Pageserverのみがそこから読み取ります。ストレージの冗長性がどのように機能するか、また、なぜそれがコンピュートの高可用性設定から独立しているのかの詳細については、「ストレージアーキテクチャ」を参照してください。
書き込みの仕組み
書き込みはコンピュートからストレージレイヤーへと流れます:
- Postgres はメモリ内の影響を受けるページを変更し、WAL レコードを生成します。
- コンピュートは WAL レコードをセーフキーパーにストリームします。
- セーフキーパーのクォーラムがレコードを承認すると、トランザクションがcommitされ、クライアントは成功を受け取ります。
- Pageserver は WAL を非同期に適用し、更新されたページをオブジェクトストレージに永続化します。
safekeepersのクォーラムがWALレコードを保持した時点でトランザクションは永続化されます。logだけでデータを再構築するのに十分だからです。Pageserversはその後、commitパスの外でデータページを再構築して保存するため、commitされた変更を危険にさらすことなく、書き込みの高速性が維持されます。
読み取りの仕組み
読み取り処理では、キャッシュの階層を高速なものから順に確認し、ページが存在する最初のレイヤーで停止します：
- バッファプール（メモリ）： コンピュートRAM内のPostgres共有バッファ。
- ローカル コンピュート キャッシュ: コンピュート ノード上のディスクベースのキャッシュで、コンピュートのメモリに対してサイズが設定されます。
- Pageserver： キャッシュミスが発生すると、コンピュートはPageserverにページをリクエストし、PageserverはリクエストされたLSNでページを再構築します。
- オブジェクトストレージ： pageserver は、必要に応じて内部的にオブジェクトストレージから読み取ります。クエリーはオブジェクトストレージに直接到達しません。
このアーキテクチャで実現できること
ステートレスなコンピュートと永続的なストレージを分離することで、いくつかの Lakebase 機能が実現可能になります：
機能 | 有効になる機能 |
|---|---|
コンピュートはステートレスであるため、Lakebaseはデータを移動することなく、ワークロードに応じてコンピュートサイズをスケールアップまたはスケールダウンします。 | |
ストレージが保持されている間、コンピュートは完全に停止でき、コンピュートが再開されるとデータはすぐに利用可能になります。 | |
データベースの分離された書き込み可能なコピーを数秒で作成します。ブランチングは共有ストレージに対するコピーオンライトのメタデータ操作であるため、データは複製されません。 | |
複数のコンピュートインスタンスが同じストレージレイヤーから読み取るため、レプリカはデータのコピーを必要とせず、数秒で起動します。 | |
ストレージレイヤーが履歴を保持しているため、コンピュートは過去の時点にアタッチし、データを元の場所にコピーし直すことなく、その時点のデータベースを読み取ることができます。 | |
フェイルオーバーは、データを移動させることなく、既存のストレージに接続するセカンダリのコンピュートインスタンスをプロモートします。 | |
RPO = 0（commitされたデータの損失なし） | Lakebaseは、すべてのcommitされたトランザクションを承認する前に永続的に記録するため、コンピュートの障害、再起動、またはスケール トゥ ゼロが発生しても、commitされたデータが失われることはありません。 |
このアーキテクチャが LTAP をサポートする方法
Lakebaseはコミットされたすべての変更をクラウドオブジェクトストレージに永続的に保存するため、個別のレプリケーションパイプラインを必要とせずに、同じデータをトランザクションと分析ワークロードの両方で利用できます。これは、データの単一コピーでトランザクションエンジンと分析エンジンの両方をサポートする、Lake Transactional and Analytical Processing（LTAP）の基盤となります。LTAPがこのアーキテクチャをどのように構築しているかについては、「 LTAPアーキテクチャ」を参照してください。
次のステップ
- ストレージアーキテクチャ： ストレージの冗長性がどのように機能するか、また、それがコンピュートの高可用性設定から独立している理由について説明します。ストレージアーキテクチャを参照してください。
- データベースBranch： Branchがコピーオンライトストレージを使用して、即座に分離された環境を作成する方法をご覧ください。See Branch.
- 読み取りレプリカ: 同じストレージ層を共有する読み取り専用のコンピュートインスタンスを追加します。読み取りレプリカを参照してください。
- 基本概念: Lakebase をユニークなものにしている一連の概念を確認します。基本概念を参照してください。