マネージドPostgres：Lakebaseが実際に肩代わりしてくれること

すべてのPostgresベンダーは自社を"マネージド"と呼んでいます。しかし、その言葉が何をカバーしているかについて、意見が一致しているベンダーはほとんどありません。オペレーティングシステム（OS）のパッチ適用のみを行い、残りはデータベースチームに任せるという意味のベンダーもあれば、チームの誰も設定ファイルに触れることなく、データベースが拡張（スケール）し、障害を処理し、自動的にバックアップを実行するという意味のベンダーもあります。

マネージドPostgresとは、プロバイダーが基盤となるインフラストラクチャを運用し、パッチ適用、スケーリング、フェイルオーバー、バックアップなどのコアなデータベース運用を処理するデータベースサービスです。これにより、データベースチームはメンテナンスに費やす時間を減らし、その上で動作するアプリケーションの構築により多くの時間を割くことができます。プロバイダーが担当する運用作業が多いほど、顧客が負担するデータベース管理作業は少なくなります。

PostgresがAIアプリケーションに移行するにつれて、この違いはさらに重要になります。データベースは、従来のトランザクションワークロードに加えて、アプリケーションの状態、会話履歴、埋め込み（embeddings）、エージェントデータなどを保持するようになるため、運用範囲は単にデータベースを稼働させ続けることだけに留まらなくなります。

Lakebase Postgresは、そのマネージドなアプローチをサーバーレスPostgresに適用し、自動スケーリング、PostgreSQL互換性、リカバリ、そしてDatabricksとの統合を組み合わせています。問題は、それが実際にどれだけの運用作業を削減できるかです。

TL;DR

• マネージドPostgresは、パッチ適用、スケーリング、フェイルオーバー、バックアップなどの日常的なデータベース運用をデータベースチームの負担から取り除く必要があります。
• Lakebaseは、自動スケーリング、ゼロへのスケール（scale-to-zero）、自動スナップショット、ポイントインタイムリカバリ（PITR）、ブランチ機能、およびpgvectorやPostGISなどの一般的な拡張機能のサポートを備えたサーバーレスインフラストラクチャ上でPostgreSQLを実行します。
• Lakebaseは、リージョン内のほとんどのマネージドPostgres運用を処理します。

マネージドPostgresの本当の意味

マネージドPostgresは、データベースの鍵を渡すようなものだと考えてください。チームがどれだけ引き渡すかは、プロバイダーによって異なります。一方の極端な例では、データベースチームが依然としてサーバー、バックアップ、フェイルオーバー、スケーリングを担当します。もう一方の極端な例では、完全にマネージドされたサービスが、その下のインフラストラクチャだけでなく、チームに代わって運用作業全般を処理します。ほとんどのプロバイダーはその中間に位置し、VMやネットワークを処理する一方で、一部のデータベース運用、スケーリングの決定、フェイルオーバーの構成、バックアップポリシーをチームに委ねています。

プロバイダーがOSにパッチを適用してデータベースを「マネージド」と呼ぶ一方で、チームはデータベースの可用性と回復性を維持するための作業に引き続き責任を負う、ということもあり得ます。

パッチ適用、スケーリング、フェイルオーバー、バックアップは、その境界線を引くのに適した基準です。また、マネージドサービスは、Postgres周辺のセキュリティ、リカバリ、移行、AIワークロード、開発者向けツールのうち、チームが引き続き所有（管理）しなければならない範囲も決定します。

マネージドPostgresは、プロバイダーがデータベースインフラストラクチャを運用し、パッチ適用、スケーリング、フェイルオーバー、バックアップなどのコアな運用タスクを処理するサービスです。完全にマネージドされたサービスは、これらの運用の責任を引き受けるため、チームはPostgresの実行ではなく、Postgresを利用した構築に集中できます。

マネージドPostgresが処理すべきこと

サービスがそのスペクトルのどこに位置するかを示す最も明確な基準は、これら4つの運用タスクをチームの負担から取り除いてくれるかどうかです。

メンテナンスとパッチ適用

マネージドプロバイダーは、データベースチームが手動でスケジュールを設定したり実行したりすることなく、OSパッチ、マイナーなPostgreSQLバージョン、およびバキューム調整（vacuum tuning）などの日常的なメンテナンスを適用する必要があります。これは、すべてを自分たちで行うセルフホスト型Postgresとは対照的です。メジャーバージョンのアップグレードには依然として計画が必要ですが、拡張機能やアプリケーションの動作が変わる可能性があるため、優れたプロバイダーは関与を最小限に抑え、アップグレードパスを明確にします。

スケーリング

プラットフォームエンジニアが手動でインフラストラクチャのサイズを変更することなく、ワークロードに合わせて容量が調整される必要があります。これには、コンピューティングやメモリを増やすための垂直スケーリング、読み取りトラフィック用のリードレプリカ、そして理想的には決定自体を不要にするサーバーレススケーリングが含まれます。Lakebaseの自動スケーリングは本番環境における一例であり、標準的なPostgresよりも5倍高速なPostgres書き込みを可能にします。本当の試金石はトラフィックの急増時です。データベースチームが使用率を監視し、サイズ変更を待っている状態であれば、スケーリングは依然として彼らの仕事です。

高可用性とフェイルオーバー

インフラストラクチャに障害が発生した場合でも、オンコールのエンジニアが午前2時に手動でレプリカを昇格させることなく、データベースは稼働し続ける必要があります。一部のプロバイダーは、自動的に引き継ぐスタンバイインスタンスでこれを処理します。Lakebaseなどの他のプロバイダーは、永続的なローカル状態を保持しないため、障害が発生したコンピューティングを完全に置き換えます。それでも、すべてのプロバイダーが同じ速度で、または同じデータ損失でフェイルオーバーするわけではありません。プロセス中に数秒分の書き込みが失われるプロバイダーもあれば、まったく失われないプロバイダーもあります。ラベルを信用する前に、フェイルオーバーが存在するかどうか、またフェイルオーバーが開始されたときに処理中の書き込みがどうなるかを含め、詳細を確認する価値があります。

バックアップとリカバリ

自動バックアップと、サポートチケットなしでチームが実行できる復元プロセスが基本です。ポイントインタイムリカバリ（PITR）は、単に最後のスナップショットだけでなく、特定の時点への復元を可能にするもので、午後の時間帯に不適切な移行によってデータが破損した場合などに重要になります。リージョン全体のダウンはさらに大きな問題であり、目標復旧時間（RTO）（ダウンしている時間）と目標復旧時点（RPO）（失っても許容できるデータ量）で測定されます。これら両方の数値が定義されていないプロバイダーは、災害復旧計画を持っているのではなく、単に予測しているだけです。

マネージドPostgresがデータを保護する方法

マネージドデータベースは、保存時（at rest）および転送時（in transit）のデータを暗号化し、アクセスできるユーザーを制御し、データチームにデータベースアクティビティの可視性を提供する必要があります。具体的には以下の通りです。

• 暗号化：データは、ディスク上での保存時、およびアプリケーションとデータベース間の転送時の両方で保護される必要があります。確認すべき詳細は、誰が鍵を管理しているかです。一部のプロバイダーは暗号化を完全に自社側で管理していますが、コンプライアンス要件や社内ポリシーによって組織が鍵を保持する必要が生じた瞬間に、これが問題になります。顧客管理の鍵（customer-managed keys）を使用すると、基盤となるデータベース運用をプロバイダーに任せながら、その制御を維持できます。
• アクセス制御：ロールベースのアクセス制御は、異なるユーザーやサービスに異なる権限を付与するという基本を処理しますが、本番システムではそれ以上の機能が必要になることが多く、決済データを扱う業界では、さらにPayment Card Industry Data Security Standard（PCI DSS）などの基準を満たす必要があります。Unity Catalogによる属性ベース of アクセス制御は、ロールだけに依存するのではなく、ユーザー、リソース、またはリクエストのプロパティを考慮することで、これらのポリシーをさらに拡張します。
• 監査ログ：誰がいつ何をしたかの可視性がなければ、インシデントの調査は難しくなり、コンプライアンスの証明も困難になります。監査ログは、データチームがデータベース上に別のパイプラインとして構成、運用、保守しなければならないものではなく、デフォルトでデータベースや管理アクティビティの可視性を提供するものであるべきです。

既存のPostgreSQLデータベースを移行する際の考慮事項

移行は、新しいデータベースがアプリケーションの依存する拡張機能、構成、またはPostgreSQLの機能をサポートしていないことが判明するまでは、簡単そうに見えることがあります。何かを移動する前に、アプリケーションが何に依存しているかを確認してください。既存のPostgreSQLデータベースを移行する際に考慮すべき主な事項は以下の通りです：

• 互換性：現在のセットアップが新しいプラットフォームでも同じように動作するかどうかを確認します。これには、PostgreSQLバージョンのサポート、カスタム構成、およびインフラストラクチャが変更された後に維持されない可能性のあるアプリケーションレベルの前提条件が含まれます。標準的なPostgresワイヤプロトコル互換性があるということは、既存の接続文字列、オブジェクト関係マッパー（ORM）、ドライバー、およびツールがコードを変更することなく動作する可能性が十分にあります。
• 拡張機能：移行は、データベースが依存しているすべての拡張機能が移行先でも利用可能かどうかをチームが確認するタイミングです。そのため、何かに取り組む前に、プロバイダーのサポート対象リストと実際に使用されているものを照らし合わせて確認してください。AIや埋め込み（embedding）ワークロードについてはpgvectorを確認する価値があり、地理空間データについてはPostGISが重要です。また、一般的な拡張機能が提供されていると仮定するのではなく、アプリケーションが依存する他のすべての拡張機能を個別に確認する価値があります。
• 移行方法：ダンプベースの移行（新しいプラットフォームへのエクスポートと復元）はシンプルで、小規模なデータベースや計画されたメンテナンスウィンドウに適しています。ロジカルレプリケーションは、移行元を稼働させたまま変更を移行先にストリーミングするため、両者が同期した後に非常に短い中断で切り替えることができます。適切な選択は、データベースのサイズ、書き込み量、およびビジネスが許容できるダウンタイムの長さによって決まります。

PostgresはAIアプリケーションに適していますか？

アプリケーションが同一システム内でトランザクション状態とベクトル検索の両方を必要とする場合、PostgresはAIアプリケーションに最適です。これは、それを可能にする拡張機能であるpgvector、検索用のベクトル検索、リクエスト間で状態を保持するための大規模言語モデル（LLM）メモリ、そしてその両方を同時に必要とするエージェントワークロードの4つの要素に集約されます。

pgvector

pgvectorは、ベクトルデータ型と類似性検索インデックスをPostgres内に直接追加するため、埋め込み（embeddings）は独自のシステムではなく、他のアプリケーションデータと同じ場所に保存されます。トレードオフとして、別のベクトルデータベースを使用すると、埋め込みと運用データの同期を維持することが独自のエンジニアリング課題になりますが、pgvectorは専用のベクトルストアを必要としないワークロードにおいて、この課題を解消します。

ベクトル検索とセマンティック検索

pgvectorを使用すると、埋め込みを保存し、近似最近傍（ANN）インデックスを使用して、データセットの増加に合わせて類似ベクトルを効率的に検索できます。これにより、Postgres内でセマンティック検索、検索拡張生成（RAG）、および意味ベースのマッチングが可能になります。適切なインデックス戦略は依然としてデータセットのサイズやクエリパターンに依存するため、pgvectorを導入しても、特定のワークロードに対するパフォーマンス評価の必要性がなくなるわけではありません。

LLMメモリ

LLMアプリケーションは、会話履歴、ユーザーの好み、取得したドキュメント、ツールの実行結果など、リクエスト間で状態を保持する場所を必要とします。Postgresは、その状態を通常の非構造化またはリレーショナルデータとして保存でき、同時にpgvectorが同じデータベース内で埋め込みを処理します。非常に大規模で専門的なベクトル検索を必要とするワークロードでは、依然として専用のベクトルデータベースが適している場合がありますが、多くのAIアプリケーションでは、運用状態と検索をまとめて管理できます。

エージェントワークロード

エージェントは実行中に状態を継続的に読み取り、更新します。会話を追跡し、中間結果を保存し、ツールの呼び出しを記録するため、データベースは単にコンテキストを取得する場所ではなく、エージェントの実行レイヤーの一部となります。AIエージェントワークロード向けに構築されたデータベースは、絶えず変化するトランザクション状態と、エージェントが関連するコンテキストを見つけるために使用する検索の両方を、単一のシステムでサポートする必要があります。

アプリケーション開発におけるPostgres

本番ワークロードの実行だけでなく、Postgresはチームの実際の開発手法をサポートする必要があります。つまり、スケールアップしても接続がボトルネックにならず、スキーマ変更のテストによって本番データが危険にさらされないようにすることを意味します。

接続管理

Postgresが同時に保持できる接続数には限りがあり、水平方向にスケールするアプリケーションインスタンスは、コンピューティングやストレージがボトルネックになる前にその制限に達する可能性があります。接続プーリングは、リクエストごとに新しい接続を開くのではなく、確立されたデータベース接続をリクエスト間で再利用します。マネージドサービスにおいて重要なのは、プーリングが組み込まれているか、それともチームが個別に運用する必要があるかです。

データベースブランチング

本番データに対してスキーマ変更をテストすることは、本番環境を危険にさらすか、時間の経過とともに同期がずれていくステージングデータベースを維持することを意味します。データベースブランチングは、既存のデータベース状態または特定の時点のスナップショットから隔離された環境を作成するため、開発者は現実的なデータに対して移行をテストし、進化型データベース開発のように作業し、不要になったブランチを削除できます。

マネージドPostgresでLakebaseを採用する理由

マネージドPostgresが処理すべき主要なタスクと照らし合わせることで、Lakebaseのアプローチがより明確になります：

• サーバーレス：Lakebaseは、需要に応じて自動的にスケールするサーバーレスコンピューティング上でPostgreSQLを実行します。アイドル時にはゼロまでスケールダウンするため、事前に対象インスタンスのサイズを決定したり、未使用の容量に対して支払いをしたりする必要はありません。Databricksのテストでは、Lakebaseを使用することでPostgresの書き込みスループットが最大5倍高速化したと報告されていますが、結果はワークロードや構成によって異なります。
• PostgreSQL互換性：Lakebaseは標準のPostgreSQL接続を使用するため、既存のドライバー、ORM、およびpsql、pgAdmin、DBeaverなどのツールは、他のPostgresインスタンスと同じ方法で接続できます。アプリケーションとデータベースの間に独自のプロトコルが介在することはありません。
• 信頼性：Lakebaseは、セカンダリコンピューティングを別のアベイラビリティゾーンで実行し、プライマリが障害を起こした場合は自動的に昇格させ、接続エンドポイントを変更せずに維持します。データベースチームは、障害発生時にレプリカを手動で昇格させたり、アプリケーションを再構成したりする必要はありません。
• 価格：恒久的にプロビジョニングされたインスタンスではなく、ワークロードに応じてコンピューティングがスケールし、データベースが一時停止すると課金が停止します。ストレージは個別に請求されます。
• レイクハウス統合：Lakebaseは、孤立したPostgresサービスとして動作するのではなく、Databricksプラットフォームの他の機能と接続します。同期テーブルにより、カスタム同期パイプラインなしでUnity CatalogのデータをPostgresアプリケーションで利用できるようになります。また、現在パブリックプレビュー中のChange Data Feedにより、レイクハウスでのダウンストリーム処理用にデータベースの変更が公開されます。

チームの負担が軽減されるタスク

以下の表は、Lakebaseが処理するデータベース運用と、引き続きデータベースチームが担当する運用を示しています：

上記の表の通り、パッチ適用、スケーリング、フェイルオーバー、バックアップはすべて自動的に実行されます。災害復旧は例外であり、依然としてプライベートプレビュー（AWSのみ）であり、手動フェイルオーバーと顧客管理の復旧手順が必要です。リージョンをまたぐ用途でLakebaseを信頼する前に、この詳細を確認しておく価値があります。Databricks Lakebaseの詳細はこちら。

まとめ

「マネージド」が意味する内容は、提供元によって異なります。OSにパッチを適用して完了とするものから、スケーリング、フェイルオーバー、バックアップ、セキュリティ、移行、AIワークロード、そしてそれらすべてを取り巻く開発者体験など、本番データベース運用の全責任を担うものまで様々です。

Lakebaseは、そのほとんどにおいて基準をクリアしています。パッチ適用、スケーリング、フェイルオーバーはチームの介入なしで実行され、ポイントインタイムリカバリが組み込まれており、セキュリティ、拡張機能、接続プーリング、ブランチングがすべてサービスに付属しています。クロスリージョンの災害復旧は唯一の例外であり、依然としてプライベートプレビュー段階で手動フェイルオーバーが必要であり、Lakebaseがリージョン内で提供する自動保護とは異なります。

マネージドPostgresを検討しているチームにとって重要な問いは、運用作業のどれだけが実際に自分たちの手を離れるかということです。Lakebaseはリージョン内におけるその作業の大部分を処理しますが、クロスリージョンの災害復旧については、引き続きチームが責任を負う領域となっています。

よくある質問

マネージドPostgresとセルフホストPostgresの違いは何ですか？

セルフホスト型のPostgresでは、パッチ適用、スケーリング、フェイルオーバー、バックアップポリシー、災害復旧など、すべての運用タスクをデータベースチームが担当する必要があります。マネージドPostgresは、これらのタスクの一部またはすべてをプロバイダーに移行しますが、移行される範囲はプロバイダーによって大きく異なります。部分マネージドサービスはインフラのみを管理し、それ以外はユーザー側で対応する必要があります。一部の完全マネージドサービスには、セキュリティツール、移行支援、データベースブランチなどの開発者ワークフローも含まれています。

サーバーレスPostgresとは何ですか？

サーバーレスPostgresは、需要に応じてコンピューティングが自動的にスケーリングされるマネージドデータベースモデルであり、固定のインスタンスサイズをプロビジョニングする必要がありません。データベースがアイドル状態のときにコンピューティングをゼロにスケーリングするプロバイダーもあれば、ベースラインの容量を維持するプロバイダーもあります。料金は通常、永続的にプロビジョニングされたインスタンスではなく、使用されたコンピューティング量に基づいて決定されます。

Postgresにおけるデータベースブランチの仕組みは？

データベースブランチは、基盤となるストレージを複製することなく、データベースの分離されたコピーオンライト（copy-on-write）ブランチを作成します。各ブランチは、本番環境に影響を与えることなく、独自のコンピューティングとデータの変更を保持できます。開発チームはこれを利用して、実際のデータに対してスキーマ移行をテストしたり、プルリクエストごとにブランチを立ち上げたり、特定の時点からブランチを復元したりして、作業が完了したら削除することができます。

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