大規模環境における高速リカバリを実現するLakebase Postgresのブランチベースのリストア

 

マネージドOLTPにおいて、リストアは常に非常に時間がかかるものであり、規模が大きくなるほどさらに遅くなります。そのため、ダウンタイムのコストが最も高くなる大規模な本番データベースほど、復旧までに最も長く待たされることになります。

通常の回避策は困難で、コストがかかり、リスクも伴います。これには、追加のレプリカや環境の用意、さらにはリストア作業へのDBAの関与が必要になりますが、それでも完全に保護される保証はありません。マシンの障害時には正常なレプリカへのフェイルオーバーが有効ですが、誤った書き込みがすでにスタンバイ側にも反映されている場合には役に立ちません。その場合はやはりリストアが必要になり、リストアには数時間のダウンタイムが発生する可能性があります。

この課題は、従来のマネージドOLTPシステムのアーキテクチャに起因しています。コンピュートとストレージが1つのマシンとして一体化しているため、リストアは新しいインスタンスのプロビジョニングから始まります（この時点で待機が発生します）。スナップショットはオブジェクトストレージに保存されている一方で、Postgresはそのボリューム上で動作するため、スナップショットをディスクにプルする必要があります（さらに待機が発生します）。その後、WALの再生によって、スナップショットの時点から正確な復旧タイムスタンプまでの差分を埋める必要があります（さらに待機が発生します）。データベースの規模が大きくなるにつれて、このプロセスはさらに遅くなり、コストも増加します。

Lakebase Postgresのアーキテクチャは、このモノリスを解体し、リストアの仕組みを根本から変えます。Lakebaseでは、コンピュートとストレージが分離されており、データベースの履歴は即座に参照可能な形でオブジェクトストレージにすでに保存されています。このアーキテクチャでは、リストア時に新しいディスクにデータをコピーすることはありません。代わりに、特定のタイムスタンプでブランチを作成するだけであり、これは数時間かかるコピーや再生の作業ではなく、シンプルなメタデータ操作にすぎません。

実際、データベースが100 TBであっても、リストアにかかる時間は数秒にまで短縮されます。しかも、エージェントが実行できるほどシンプルです。

従来のOLTPリストアのプロセス（とその限界）

従来のPostgresのポイントインタイムリカバリ（PITR）は、ファイルのベースバックアップと、そのバックアップ以降のすべてのアーカイブされたWALという2つの要素で構成されています。Amazon RDSなどのマネージドPostgres環境では、そのバックアップは通常、オブジェクトストレージに保存されているスナップショットです。

特定の時点Tに「バックアップからリストア」するプロセスは、実際には次の3つのステップで構成されています。

1. 新しいインスタンスのデプロイ
2. Tの直前の利用可能な最新スナップショットのリストア
3. そのスナップショットからTまでのWALの再生

1. 新しいインスタンスのデプロイ

これには、プライマリと少なくとも同等のコンピュートおよびストレージボリューム（一体型）を用意する必要があります。小規模なインスタンスであれば数分で起動しますが、大容量のEBSボリュームを持つ大規模なインスタンスでは通常さらに時間がかかり、リストアプロセスを開始する前に待機が発生します。

2. スナップショットからのリストア

RDSのスナップショットはS3に保存されているため、「リストア」とはそのスナップショットをオブジェクトストレージから取り出してPostgresのディスクに配置することを意味します。

このプロセスはデータサイズが大きいと遅くなるため、RDSはリストアされたインスタンスをavailableにする前に、プロセスの完了を待ちません。大容量ボリュームの場合、これはほとんどのテーブルやインデックスのページがまだS3にある状態で発生します。しかし、「利用可能」になったからといって、ワーキングセットがPostgresボリューム上にあるわけではありません。クエリがまだローカルに存在しないブロックにアクセスすると、ボリュームはその場でS3からそれを取得し、残りのデータはバックグラウンドでハイドレーション（データの取り込み）を続けます。

このようなクエリにはレイテンシが発生するため、内部的な確認には問題なくても、本番環境には適していません。実際に必要なデータがボリューム上に配置されて初めてリストアが完了しますが、大規模なデータベースではこれに時間がかかります。データベースの規模が大きくなるほど、これにかかる時間（時間単位）は長くなります。

3. TまでのWALの再生

スナップショットは、そのスナップショットが取得された時点でのみ整合性が保たれています。Tに到達するには、Postgresはそのスナップショットの後にアーカイブされたトランザクションログを再生する必要があります。再生にかかる時間は、スナップショットからTまでの間にどれだけの処理が発生したかによって異なります。1時間前のスナップショットであれば、昨夜のスナップショットよりもはるかに高速に処理できます。さらに、書き込みが多い日であった場合、再生すべきWALの量も膨大になります。これにより、インスタンスがS3からハイドレーションを行っている最中であることに加え、再び長い待機時間が発生することになります。

長時間のダウンタイム

データベースが小規模でない限り、PITRはほぼ常に数時間かかる作業になります。モノリスをプロビジョニングし、S3からスナップショットをプルし、WALを再生し、トラフィックを受け入れるのに十分な量のボリュームがローカルに配置されるまで待つ必要があります。

その期間中ずっと、ダウンタイムが発生する可能性があります。プライマリが停止してもレプリカに正常なデータが残っていれば、健全な高可用性（HA）レプリカによって救われる可能性があります。しかし、テーブルの削除や誤った書き込みがすでにスタンバイ側にも反映されている場合、PITRが必要になるため、レプリカでは救われない可能性があります。

データベースの遅いリストアがもたらす課題

 

ある調査では、1TB以上の本番環境Postgresを運用している50人の開発者を対象に、リストアの経験について質問しました。

• 59%が過去12か月間に本番環境で重大な障害を経験した
• 30%が3時間以上ダウンし、中には半日以上かかったケースもあった
• 60分未満で復旧できたのはわずか21%だった

これにより、ビジネスに悪影響が及ぶ可能性が生じました。

• 40%が重大な業務停止を報告した
• 52%が障害による顧客からの否定的なフィードバックを経験した
• 再び障害が発生した場合に迅速に復旧できる自信が「ある程度しかない」と感じたのは72%だった

ブランチベースのリストアがもたらす新しいアプローチ

Lakebase Postgresでは、モダンなアーキテクチャによって異なるリストアアプローチが可能になります。

コンピュートとストレージの分離

コンピュートと永続ストレージは分離され、WALによって接続されています。コンピュートはPostgresを実行します。つまり、SQLの実行、クエリの計画、MVCCの適用、ロックの管理、WALの生成など、通常のPostgresのタスクをすべて行います。一方で、データの永続的なコピーを保持することはありません。

ストレージが永続性と履歴を保持し、その役割は3つの異なるコンポーネントによって実行される3つの部分に分かれています。

• SafekeepersはコンピュートからWALを受け取ります。クォーラム（過半数）のsafekeeperがWALレコードを確認すると、トランザクションの永続性が確保されます。
• Pageserverは、WALをPostgresが読み取るページに変換します。指定されたLSNにおける指定されたキーの任意のページを再構築できます。
• オブジェクトストレージは、不変の長期履歴を保持します。コンピュートがこれを直接読み取ることはなく、pageserverがその間に介在します。

書き込みが発生すると、次の処理が行われます。

1. Postgresがメモリ内の行を変更し、WALを生成する
2. コンピュートがそのWALをsafekeepersにストリーミングする
3. クォーラムがそれを確認し、トランザクションが永続化される
4. pageserverが後からそのWALをページバージョンに変換する
5. これらのバージョンが不変の履歴としてオブジェクトストレージに保存される

アドレス指定可能なタイムラインとしての履歴保存

この設計では、書き込みパスがユニークな形をとります。上記のアーキテクチャでは、トランザクションのコミットとページの具体化が分離されています。これは簡単に言うと、古いページバージョンが上書きされることは決してないということです。データベースの履歴は、変更を加える単一のコピーではなく、指定可能なタイムラインとして蓄積されていきます。

Lakebaseにおけるリストアは特定時点のブランチ作成

従来のプロセスでは、リストアとは主に過去の状態を別のインスタンスに再構築することを意味していました。しかしLakebaseでは、参照可能な不変のストレージ履歴が存在するため、そのステップは不要であり、代わりに別のプリミティブであるブランチに置き換えられます。

従来のリストアが新しいインスタンスをプロビジョニングしてデータをコピーするのに対し、Lakebaseでのリストアは履歴上の特定の時点におけるブランチの作成です。この新しいブランチは、独自の独立したコンピュートと接続文字列を持ち、本番環境とは完全に独立してクエリを実行できます。元のインスタンスのレプリカではありませんが、まったく同じように機能します。

このプリミティブをリストアに使用する方法は次のとおりです。

• メインブランチで何らかの障害が発生した場合、過去のタイムスタンプを選択します（リストアを確定する前に、クエリを実行するなどして、そのタイムスタンプの内容を実際に検査できます）。
• 検証が完了すると、コントロールプレーンはそのタイムスタンプをストレージ履歴の正確な時点（適切なLSN）にマッピングし、そのブランチを作成してコンピュートをアタッチします
• 「復元されたデータベース」とはその新しいブランチのことであり、基盤となるデータベースに保存されているデータ量に関係なく、「デプロイ」を押すとほぼ瞬時に利用可能になります。

これは重要なコンセプトですので、改めて説明します。

ブランチはデータベースをコピーしない

この復元方法では、データのコピーが完全に不要になります。復元されたブランチはデータをコピーする必要がなく、その時点までにすでに存在しているイメージレイヤーとデルタレイヤーを単に指し示すだけです。

• コピー＆リプレイ方式のシステムでは、復元はデータ移動ジョブです。コピーとWALのリプレイが完了するまで、データベースは「存在」しません。
• Lakebaseでは、「データベース」はすでにそこに存在しています。復元とはメタデータ、つまり履歴内の一時点を指すポインターにすぎません。あとは、その時点を独自のコンピュートを持つブランチとして公開するだけです。

結果：100 TBの復元も10 GBの復元と同じくらい高速

メリットは、スケーリングが運用上の脅威ではなくなることです。復元がメタデータ処理であれば、所要時間はデータ量に応じて増加せず、仕組みも変わりません。

データベースの大きさに関係なく：

• アドレス指定可能な過去の状態へのアクセスはほぼ瞬時に行えます
• その状態の検証にかかる時間は、チェックと読み取りを選択したデータの量によってのみ決まります

巨大なPostgresデータベースであっても、障害発生後に人間やエージェントはクエリ可能な過去の状態にいつでもすぐにアクセスできます。

エージェントは復元をベースに構築可能

Lakebaseでの復元は、タイムスタンプを指定してブランチを作成するというシンプルな操作です。このループは十分に短いため、エージェントは障害対応だけでなく、通常のツール呼び出しとして扱うことができます。

これこそが、Replitやv0のようなエージェントプラットフォームが、バージョン管理や元に戻す（Undo）機能を構築するために実際に製品化している要素です。一般的なループは次のようになります。

1. エージェントがアプリを変更し、それによってデータベースが変更されます
2. プラットフォームは、mainのスナップショットとしてチェックポイントを保存します。そして、コードバージョンの隣にチェックポイントIDを保存します
3. ユーザーが「元に戻す」を押すか、UIで古いバージョンを選択します
4. プラットフォームはそのチェックポイントを検索し、アクティブなブランチに復元します
5. スキーマとデータは、瞬時に「古いコード」に対応するデータベースバージョンに戻ります

従来のPITRは、本番のワークフローをサポートするには遅すぎて重すぎますが、タイムスタンプ指定のブランチ作成は、製品の一部として組み込めるほど高速かつ低コストです。

Lakebaseのアーキテクチャがリカバリのあり方を変える

従来の復元は、データベースが大きくなるにつれて遅く、重くなります。しかし、ブランチベースの復元はそうではありません。履歴はすでにコンピュートの外部に存在しているため、過去の時点は再構築するものではなく、ブランチとして開くことができるものです。10 GBであろうと100 TBであろうと、復元の手順は同じです。タイムスタンプを選択し、ブランチを作成して、コンピュートをアタッチするだけです。大規模な障害も、もはや恐れる必要はありません。

ぜひご自身で体験してください。Lakebase Postgresデータベースを作成し、まとまったデータをロードして復元を実行してみてください。これまでこれなしでどうやってやってこれたのだろうと不思議に思うはずです。

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