lakebaseアーキテクチャがPostgresへの書き込みを5倍高速化する方法

lakebaseでは、コンピューティングとストレージは設計上分離されています。この分離は元々スケーリング、ブランチング、即時リカバリなどの運用上の柔軟性のために構築されましたが、これにより大規模なパフォーマンスの可能性も開かれました。

これらのレイヤーを分離することで、従来のモノリシックなPostgresデプロイメントでは構造的に不可能だった方法で、Postgresコンピューティングから分散ストレージに作業をオフロードできます。この記事では、このアーキテクチャ上の利点をどのように活用して、長年のPostgresのボトルネックを解消し、Postgresの書き込みスループットを5倍に向上させ、読み取りテールレイテンシを2倍削減し、WALトラフィックを94%削減したかを探ります。

従来のPostgresの耐久性の隠れたコスト

マネージドPostgresのパフォーマンスを5倍向上させた方法を理解するには、従来のPostgresがどのように耐久性を処理しているかを見る必要があります。

Postgresでは、データベースの変更はすべて、クラッシュ時にデータが失われないように、まずシーケンシャルログ（Write-Ahead Log、WAL）に保存されます。クラッシュリカバリ時間を短縮するために、Postgresは定期的に「チェックポイント」と呼ばれるバックグラウンドクリーンアップイベントを実行します。スナップショットとは異なり、チェックポイントはログ内の単なるマイルストーンマーカーです。チェックポイント中に、Postgresは現在メモリ内にあるすべての変更されたデータ（「ページ」と呼ばれる8KBチャンクで管理）を、ログ内の特定のポイントまでメインディスクにフラッシュします。クラッシュが発生した場合、Postgresはそのチェックポイントマイルストーンから開始し、最近のWALログをディスクにリプレイすることでデータを復元します。

しかし、リスクがあります。サーバーが8KBページをディスクに保存している最中にクラッシュした場合、ページが部分的にしか書き込まれず、破損した「torn page」（破損ページ）が発生する可能性があります。Postgresがtorn pageの上に小さなログ更新をリプレイしようとすると、データは永久に破壊されます。これを修正するために、Postgresはリカバリに破損したディスクに決して依存しないようにする必要があります。

これは「Full Page Write」（FPW）を使用して行われます。チェックポイントマイルストーン後にページが最初に変更される際、Postgresは小さな変更をログに記録するだけでなく、8KBページ全体をWALにコピーします。クラッシュが発生し、ディスクページが破損した場合、Postgresは破損したディスクを無視し、WALから元の8KBバックアップを取得し、それを残りのログをリプレイするための完璧な開始点として使用します。これは絶対的な安全性を保証しますが、コストがかかります。書き込み負荷の高いアプリケーションでは、8KBページ全体をログに記録すると、ログのボリュームが最大15倍に膨れ上がり、しばしばシステムの最大のパフォーマンスボトルネックとなります。

lakebaseソリューション：torn pageのリスクを排除する

lakebaseアーキテクチャでは、コンピューティングはステートレスです。ローカルデータディレクトリに依存しません。代わりに、WALをPaxosベースのセーフキーパーのクォーラムにストリーミングします。

破損するローカルディスクページがないため、FPWが防止するように設計された障害モードは単純に存在しません。しかし、FPWを安易にオフにすると、二次的な問題、つまり読み取りパフォーマンスが発生します。ログに定期的なフルページイメージがない場合、ストレージレイヤーは読み取りリクエストのためにページを再構築するために、無限に長い小さなデルタのチェーンをリプレイしなければなりません。かつては有界だったO(チェックポイント頻度)のリプレイは、無界のチェーンとなり、読み取りレイテンシとリソース消費の急増につながります。

イノベーション：分散ストレージへのイメージ生成プッシュダウン

この問題は、コンピューティングノードからストレージレイヤーにインテリジェンスを移動させることで解決しました。これをイメージ生成プッシュダウンと呼んでいます。

Postgresコンピューティングがストレージからページを要求すると、pageserver（Lakebase分散ストレージシステムの一部）は、そのページの最新のマテリアライズドイメージを見つけ、その上にWALデルタをリプレイすることでページを再構築します。コンピューティングがWALに埋め込んでいたフルページイメージは、デルタチェーンの定期的なリセットポイントとしても機能し、自然にチェーンを合理的に有界に保ち、読み取りを高速化していました。このメカニズムの詳細については、Deep dive into Neon storage engineをご覧ください。

フルページ書き込みが無効になると、これらのリセットポイントはなくなります。分散ストレージシステムに追加のインテリジェンスがない場合、頻繁に更新されるページは、途中にイメージがないまま、小さなデルタの長いチェーンを蓄積する可能性があります。その結果、pageserverが読み取りを処理するためにチェーン全体をリプレイすることになり、読み取りレイテンシとリソース消費が望ましくない増加につながります。

この問題を回避するため、イメージ生成の責任をコンピューティングのWALストリームからストレージレイヤーにプッシュダウンしました。これにより、ストレージの有界な読み取り動作を維持しつつ、コンピューティング上のWALオーバーヘッドを排除しました。pageserverは、ページが設定されたしきい値を超えるデルタレコードを、途中にイメージがないまま蓄積した場合に、フルページイメージを生成するようになりました。これは、新しいイメージを生成する決定が、無関係なPostgresのチェックポイントプロセスではなく、ページの実際の変更数に基づいているため、自然により良いアプローチです。

これがパフォーマンスにとって大幅に優れている理由は次のとおりです。

1. ネットワーク効率： コンピューティングは実際の変更であるコンパクトなデルタのみを送信するため、ベンチマークでは トラフィックが94%削減されました。
2. スケーラビリティ：作業は単一のPostgresライターから、分散された独立してスケーラブルなストレージレイヤーに移動されます。プロジェクトブランチのイメージ生成は、現在、複数のpageserver間でバックグラウンドで共有されています。
3. 最適な読み取り：イメージが生成されるタイミングは、無関係なPostgresのチェックポイントプロセスではなく、ページの実際の変更に基づいています。

影響の定量化：ラボから本番環境へ

この最適化は、HammerDB TPROC-C（TPC-Cから派生したOLTPベンチマーク）を使用してベンチマークを行い、実際の運用ワークロードで結果を検証しました。

1. サーバーレスコンピューティングのスケーリング

スループットは1分あたりの新規注文数（NOPM）で測定されます。コンピューティングインスタンスのサイズに応じて、その効果は劇的に向上します。

32 vCPUコンピューティングでは、改善率は450%を超えました。

コンピューティングでフルページイメージが生成される場合、各トランザクションは平均58KBのWALを生成します。イメージ生成がプッシュダウンされると、これは4KB未満に減少し、94%の削減となります。スループットの向上はこれに直接続きます。WALが少ないということは、書き込みパスでの競合が少なくなり、消費されるネットワーク帯域幅が減り、ストレージレイヤーが取り込む作業が少なくなることを意味します。

PostgresのFPWボトルネックを解消することで、スループットがコンピューティングリソースに比例してスケーリングできるようになりました。これは、モノリシックなPostgresが重い書き込み負荷の下で苦労することです。

2. 実世界での本番環境検証

56 vCPUの注目度の高いプロジェクトの本番環境では、イメージプッシュダウンを有効にすることで、定常状態のWAL生成が30 MB/sからわずか1 MB/sに削減されました。

このボリュームの減少は、日中のピーク時のトランザクションスループットの増加に直接関連していました。

これは書き込みだけでなく、デルタチェーンを最適化することで、読み取りごとに適用する必要があるWALレコードの数が大幅に減少しました。p99の読み取りレイテンシーは30%から50%減少し、p50のレイテンシーは約30%減少しました。

視野を広げて地域レベルで見ると、有効化後、コンピューティングによって生成されるWALの総量が最大4倍減少しました。ストレージエンジンからの読み取りのp99レイテンシーは最大3倍改善され、はるかに安定しました。

3. Lakebase同期テーブル

データ集約型の同期テーブルでは、その影響は即座に現れました。ある顧客は、画像プッシュダウンを有効にするだけで、取り込みスループットが毎秒17,000行から毎秒62,000行へと3倍に増加しました。

シームレスな展開: 中断のないパフォーマンス

3月下旬以降、これをフリート全体に展開しました。現在、すべてのLakebase ServerlessおよびNeonデータベースでグローバルに有効になっています。

この変更は、当社のコントロールプレーンとストレージシステムを介して実行中のコンピューティングに適用され、移行は自動的に調整されました。これは既存のPostgres XLOG_FPW_CHANGE WAL レコードメカニズムを使用して実現されたため、お客様の再起動や中断は必要ありませんでした。

マネージドPostgresパフォーマンスの次なる展開は？

Lakebaseアーキテクチャは柔軟性のために構築されましたが、パフォーマンスのために設計されました。フルページ書き込みのプッシュダウンは、ストレージとコンピューティングの分離の利点を享受するための 体系的な取り組みの一部です。

私たちが ゼロダウンタイムパッチ適用におけるキャッシュの事前ウォームアップを導入したように、私たちは重い処理タスクをトランザクションから切り離し、スケーラブルなバックグラウンドストレージスタックに移行し続けています。Postgresの書き込み税は正式に過去のものとなりました。

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