サーバーレスPostgreSQLとは？

サーバーレスPostgreSQL（Postgres）は、コンピュートとストレージを分離した、完全に管理されたクラウドデータベースモデルです。これにより、需要に基づいてそれぞれを独立して自動的にスケーリングできます。アプリケーションはデータベースサーバーを直接管理する代わりに、ワークロードに応じてコンピュートリソースを自動的にプロビジョニングし、アイドル時にスケールダウンするシステムとやり取りします。

対照的に、従来のPostgres環境では、チームは事前にインフラストラクチャのサイズを決定し、容量要件を予測し、時間の経過とともにスケーリングを管理する必要があります。これにより、オーバープロビジョニング、アイドルコストの無駄、および需要が利用可能な容量を超えた場合のパフォーマンスのボトルネックが頻繁に発生します。

サーバーレスPostgresは、以下によってそのオーバーヘッドの多くを排除します。

• サーバーのプロビジョニングとインフラストラクチャ管理の排除
• 手動での容量計画の必要性の排除
• アイドル状態のコンピュートではなく、アクティブな使用量に対してのみ課金

「サーバーレス」という用語は、アプリケーションがサーバーやインフラストラクチャなしで実行されることを意味するわけではないため、誤解を招く可能性があります。基盤となるシステムは依然として存在しますが、それらは抽象化され、クラウドプロバイダーによって完全に管理されます。サーバーのセットアップ、スケーリング、メンテナンスなどのタスクは、ユーザーからはほとんど見えず、直接構成やメンテナンスを行う必要はありません。

従来のPostgreSQLとサーバーレスPostgreSQLの比較

PostgreSQLのアーキテクチャは時間の経過とともに進化し、プロビジョニングされたインフラストラクチャモデルから、より動的でクラウドネイティブな設計へと移行してきました。

従来のPostgresのデプロイでは、ワークロードに関係なく、固定されたコンピュートリソースが継続的に実行されます。スケーリングには手動での介入または事前設定されたしきい値が必要であり、データベースがアイドル状態であっても、常にオン状態のコストが発生します。

サーバーレスPostgresは、異なるモデルを導入しました。コンピュートリソースはオンデマンドでプロビジョニングされ、ワークロードのアクティビティに応じて自動的にスケーリングし、使用されていないときはゼロにスケールダウンします。課金は、予約された容量ではなく、実際の消費量に基づきます。

サーバーレスPostgresは、Databricks SQLなどのサーバーレスコンピュートプラットフォームと併用することもでき、統合されたレイクハウスアーキテクチャ内で同じ基盤データにアクセスしながら、分析クエリを独立して実行できます。

この移行は、分離されたストレージレイヤーやオンデマンドのコンピュートオーケストレーションなどのアーキテクチャの変更によって可能になり、リソースが独立してスケーリングし、ワークロードのアクティビティに動的に対応できるようになります。

主な違いは以下の通りです。

次の進化：レイクベースアーキテクチャ

データベースアーキテクチャが進化するにつれて、サーバーレスPostgresをベースにしながら、その制限に対処する第3のモデルが登場しています。このアプローチは、レイクベースアーキテクチャと呼ばれることがあります。

サーバーレスPostgresはスケーラビリティを向上させ、運用オーバーヘッドを削減しますが、通常は分析システムとは分離されたままです。この分離により、運用データベースと分析プラットフォームの間でデータの移動、複製、または同期が必要になることがよくあります。

レイクベースアーキテクチャは、データの保存と処理に対する考え方を変えつつあります。トランザクションデータベースのパワーとレイクハウス基盤の柔軟性を組み合わせ、運用ワークロードと分析ワークロードの両方を一緒に実行できる単一のプラットフォームを構築します。これは、異なるタスクごとに個別のシステムを用意する代わりに、すべてを1つの共有データプラットフォーム上で行えることを意味します。その結果、データの重複が減り、データへのアクセスと利用方法が大幅に簡素化されます。すべてを統合することで、レイクベースアーキテクチャはデータの管理と分析を容易にし、より優れた意思決定とより効率的な運用につながります。

レイクベースアーキテクチャの仕組み

レイクベースアーキテクチャは、サーバーレスPostgresのパターンをベースにしながら、クラウドストレージやデータプラットフォームとのより緊密な統合を導入しています。

主なコンポーネントは以下の通りです。

• 分離されたコンピュートとストレージ
  コンピュートはステートレスで独立してスケーリングし、ストレージは永続的かつ分散された状態を維持します。
• エフェメラル（一時的）コンピュート
  コンピュートリソースはクエリを処理するために起動し、アイドル時にはスケールダウンするため、常時稼働のインフラストラクチャを維持することなく弾力性を実現します。
• ログベースのストレージシステム
  データの変更は連続的なログとしてキャプチャされ、データベースの状態の再構築や、ブランチ作成、リカバリ、時間ベースのアクセスなどの機能のサポートに使用できます。
• 基盤としてのオブジェクトストレージ
  耐久性のあるデータはクラウドオブジェクトストレージに保存され、スケーラビリティ、耐久性、およびレイクハウスアーキテクチャとの整合性を実現します。
• コントロールプレーンとオーケストレーション
  コントロールレイヤーがスケーリング、ルーティング、ライフサイクルイベントを管理し、コンピュートとストレージを動的に調整します。

これが重要である理由

共有基盤上でトランザクション機能と分析機能を組み合わせることで、レイクベースアーキテクチャは以下を実現できます。

• システム間のデータの重複を削減または排除
• 運用データに対するほぼリアルタイムの分析を可能に
• インフラストラクチャを統合することでデータアーキテクチャを簡素化
• トランザクションアクセスと分析アクセスの両方を必要とするAIアプリケーションなど、新たなワークロードをサポート

この移行は、個々のシステムを最適化することから、それらを単一のデータアーキテクチャ内に統合することへの移行を反映しています。

サーバーレスPostgresアーキテクチャの仕組み

サーバーレスPostgresは、コンピュートとストレージを独立したレイヤーに分離するクラウドネイティブなアーキテクチャに基づいて構築されています。この基本的な設計原則により、各コンポーネントが独立してスケーリングできるようになり、効率性と柔軟性が向上します。

このアーキテクチャの主な特徴は、ゼロへのスケール（scale-to-zero）動作です。クエリが実行されていない場合、システムは自動的にコンピュートリソースを一時停止します。新しいクエリが発行されると、コンピュートが再アクティブ化されます。これにより、コールドスタートレイテンシと呼ばれる短い遅延が発生します。これは、プロバイダーや構成に応じて、ミリ秒から数秒の範囲に及ぶことがあります。

もう1つの重要な機能は、コピーオンライト技術を使用して実装されることが多いデータベースのブランチ作成（ブランチング）です。ブランチ作成により、チームはデータを複製することなく、開発、テスト、またはステージング用の隔離されたデータベース環境を作成できます。ブランチで行われた変更は元のデータベースに影響を与えないため、より迅速なイテレーションと安全な実験が可能になります。

主なサーバーレスPostgresプロバイダー

サーバーレスPostgres製品は、プロビジョニングされたデータベースから完全なクラウドネイティブアーキテクチャへの進化におけるさまざまな段階を反映しています。初期のマネージドサービスは、既存のデータベースアーキテクチャ内に自動スケーリングを導入しました。より最近のクラウドネイティブ設計は、AIエージェント、リアルタイムアプリケーション、および最新の運用ワークロードをサポートするように構築されています。これらのシステムは、コンピュートとストレージを完全に分離し、迅速なスケーリング、ブランチ作成、より柔軟なリソース管理など、以前のモデルでは実現が困難だった機能を導入しています。NeonとDatabricks Lakebaseはこの基盤の上に構築されており、AI先進アプリケーションやエージェントベースのシステムの需要に合わせて設計されています。

• Databricks Lakebase
  レイクベースアーキテクチャに基づいて構築された運用データベースであり、トランザクションデータベースをレイクハウス基盤と統合することで、サーバーレスPostgresを拡張します。AIエージェント、リアルタイムアプリケーション、および最新の運用ワークロードの需要に合わせて設計されたDatabricks Lakebaseにより、運用ワークロードと分析ワークロードが共通のデータプラットフォームを共有できます。ユースケースには、AIエージェントの状態の保存、トランザクションアプリケーションの強化、アプリやワークフローへの分析インサイトの直接提供などがあります。その結果、データの移動が減少し、ユースケース全体でより一貫したアクセスが可能になります。
• Amazon Aurora Serverless v2
  データベースの再起動を必要とせずにきめ細かな自動スケーリングを提供する、AWS内のPostgres互換マネージドサービスです。Aurora Serverless v2はエンタープライズワークロード向けに設計されており、ネットワーキング、セキュリティ、モニタリングのためのAWSサービスと緊密に統合されています。運用のオーバーヘッドは削減されますが、スケーリング動作やリソースの分離には、依然として基盤となるインフラストラクチャの制約が反映される場合があります。
• Neon
  ログベースのストレージを備え、完全に分離されたコンピュートとストレージのモデル上に構築されたlakebaseアーキテクチャ。Neonは、ゼロへのスケール動作とデータベースのブランチ作成をサポートしており、迅速な環境構築とよりダイナミックな開発ワークフローを可能にします。

分析やデータ処理のワークロード向けに、Databricks SQLなどのプラットフォームでもサーバーレスコンピュートが利用可能です。これらはトランザクション処理用（OLTP）データベースではありませんが、分析用のサーバーレスなクエリ実行を提供し、Postgresベースのシステムと並行して動作させることができます。

オープンソースのルーツとクラウドネイティブな選択肢

Postgresは、広く利用されているオープンソースの関係データベースシステムです。サーバーレスPostgresのサービスは、この基盤の上に構築されており、拡張機能、psqlなどのコマンドラインツール、一般的なORMなどを含む、より広範なPostgresエコシステムとの完全な互換性を維持しています。

実装方法は、基盤となるシステムのどの程度がオープンであるか、あるいはプロプライエタリであるかによって異なります。Neonなどの一部のプロバイダーは、オープンソースのインフラストラクチャ上に構築されており、そのアーキテクチャの多くをコミュニティに公開しています。一方、Amazon Aurora Serverlessなどのプロバイダーは、基盤となる実装の大部分を抽象化した、プロプライエタリなマネージドサービスです。

アプローチに関わらず、ほとんどのサーバーレスPostgresソリューションは、自動スケーリング、データベースのブランチ作成、マネージド運用などのクラウドネイティブな機能を追加しつつ、完全なPostgres互換性を維持することを目指しています。

これらの違いは、チームがパフォーマンスやコストに対してどの程度の可視性と制御性を持れるかに影響を与える可能性があります。オープンソースベースのシステムは、より高い透明性と柔軟性を提供する傾向がありますが、プロプライエタリなマネージドサービスは、使いやすさや運用のシンプルさを優先することがよくあります。

料金モデルとパフォーマンスのトレードオフ

本番環境のワークロード向けにサーバーレスPostgresを評価する際は、料金モデルやパフォーマンス特性がコスト、レイテンシ、システム全体の挙動にどのように影響するかを理解することが重要です。

従量課金制：実際に支払う対象とは

ほとんどのサーバーレスPostgresプロバイダーは、主に以下の3つの要素に基づいて課金します：

• Compute（コンピュート）： 通常、vCPU時間やACU秒など、クエリ実行中に使用されたリソースに基づいて測定されます
• Storage（ストレージ）： 保存されたデータ量に基づいて請求され、通常は月あたりのGB単位で計算されます
• Data transfer（データ転送）： リージョンやネットワーク構成に応じて、データベースに出入りするデータの移動に対して課金されます

コンピュートはオンデマンドでプロビジョニングされるため、コストはワークロードのアクティビティに応じて増減します。これにより、サーバーレスの料金体系は、トラフィックが変動しやすい、または予測困難なアプリケーションに最適です。

多くのプロバイダーが、開発、テスト、小規模なワークロードに役立つ無料枠を提供しています。これらの枠には通常、コンピュート使用量、ストレージ、またはアクティブな実行時間に対する制限が設けられているため、本番環境のワークロードや、トラフィックが継続的に発生するアプリケーションにはあまり適していません。

サーバーレスの料金体系は変動するワークロードに対して効率的ですが、常に最も低コストな選択肢になるとは限りません。高トラフィック、常時稼働のワークロード、または実行時間の長いクエリが発生する場合、総コストが固定容量のプロビジョニングされたデータベースインスタンスを上回ることがあります。

コールドスタート、スケーリング、本番環境の信頼性

サーバーレスPostgresにおける主要なパフォーマンス上の考慮事項の1つは、コールドスタートのレイテンシです。データベースがゼロにスケールダウンしている場合、クエリを実行する前にコンピュートを再アクティブ化する必要があります。これにより、プロバイダーや設定に応じて、約100ミリ秒から数秒の遅延が発生します。

コールドスタートの影響を軽減するためのいくつかの対策があります：

• 完全なサスペンドを防ぐために、定期的な「キープアライブ」ピングを送信する
• リソースを部分的にアクティブに保つために、最小限のコンピュート下限を設定する
• アーキテクチャ設計によってコールドスタートを最小限に抑える、または排除しているプロバイダーを選択する

また、サーバーレスシステムは、変化するワークロードに対応するために自動スケーリングに依存しています。コンピュートリソースをクエリ量の増加に応じてスケールアップでき、場合によっては、同時アクセスをサポートするためにリードレプリカを個別にスケーリングすることも可能です。この弾力性は、予測不可能なトラフィックスパイクが発生するアプリケーションに特に有用です。

本番環境のワークロードでは、可用性と耐障害性が極めて重要な考慮事項となります。ほとんどのマネージドサーバーレスPostgresプロバイダーは、複数のアベイラビリティゾーン間でデータを複製し、組み込みのバックアップおよび復旧機能を提供しています。ただし、サービスレベル保証（SLA）や復旧動作はプロバイダーによって異なるため、本番環境で使用する前にSLAの適用範囲を確認・検証することが重要です。

コールドスタート動作や自動スケーリングなどの機能により、サーバーレスPostgresはトラフィックが変動するワークロードに適していますが、レイテンシに敏感なアプリケーションや常時稼働のアプリケーションにとってはトレードオフが生じる可能性があります。

サーバーレスPostgresのユースケースと制限事項

サーバーレスPostgresとlakebaseアーキテクチャは、それぞれ異なるワークロードのニーズに対応します。どちらのモデルがご自身のユースケースに適しているかを理解することで、不要な複雑さやコストを回避できます。

以下のガイドラインは、サーバーレスPostgresとlakebaseアーキテクチャのどちらがワークロードに適しているかを判断するのに役立ちます。

サーバーレスPostgresが適しているケース

• ほとんどのOLTPワークロード

lakebaseアーキテクチャがより適しているケース：

• AIエージェントの開発とデプロイ
• 変動しやすい、またはバースト性の高いワークロード
• 開発、テスト、ステージング環境
• コスト削減と運用オーバーヘッドの低減を最適化したいスタートアップ企業
• サーバーレスまたはエッジベースのアプリケーション
• 迅速な環境構築を伴うCI/CDワークフロー
• マルチテナントSaaSアプリケーション（ブランチ作成と自動スケーリング）

より一貫したパフォーマンスや常時稼働の可用性を必要とするワークロードに対して、lakebaseアーキテクチャは、共有データプラットフォーム上でコンピュートとストレージをどのように調整するかを再考することで、これらのニーズに対応します。

サーバーレスPostgresの始め方

サーバーレスPostgresの開始は、通常、以下のようなシンプルなセットアッププロセスで行えます：

1. ワークロードの要件、スケーリング動作、エコシステムの好みに基づいてプロバイダーを選択する
2. プロバイダーのコンソールまたはAPIを介してデータベースインスタンスを作成する
3. 認証情報、リージョン、アクセス設定を含む接続文字列を設定する
4. 標準的なPostgresクライアント、ORM、またはpsqlコマンドラインツールを使用して接続する

セットアップは比較的簡単ですが、初期の選択が全体的なパフォーマンスや耐久性に重大な影響を与える可能性があります。最初のデプロイ時に考慮すべき事項は以下の通りです：

• コールドスタートのレイテンシが懸念される場合は、最小コンピュートレベルを設定する
• サーバーレス環境やエッジ環境での同時接続を管理するために、コネクションプーラーを設定する
• データ損失を防ぐために、バックアップとポイントインタイムリカバリを有効にする
• スケーリングとタイムアウトの設定を確認し、想定されるトラフィックパターンと一致しているか確認する

サーバーレスPostgresは、分析やデータエンジニアリング向けに、Databricks SQLなどのサーバーレスコンピュートプラットフォームと並行して使用できます。この分離により、同じ基盤データ上で動作しながら、分析クエリをトランザクション処理から独立して実行できます。

分析と並行して運用データを管理するチーム向けに、Databricks Lakebaseなどの新しいアーキテクチャは、共有データプラットフォーム上でトランザクションワークロードと分析ワークロードを統合することで、このアプローチを拡張します。これにより、データの移動が削減され、システム間でのデータアクセス方法がシンプルになります。

lakebaseアーキテクチャはあなたに適したサーバーレスPostgresでしょうか？

サーバーレスPostgresは、インフラストラクチャ管理の大部分を排除し、コストを実際の使用量に近づけることで、データベースの運用をシンプルにします。コンピュートとストレージが分離されているため、リソースは需要に応じて調整されます。より要求の厳しいワークロードを抱えるチームにとって、lakebaseアーキテクチャはこの基盤をさらに拡張します。

これらのトレードオフを慎重に評価することが重要です。パフォーマンスの予測可能性、大規模時のコスト、コールドスタートのレイテンシや接続管理などの要因は、ワークロードによって異なります。

プロバイダーの選定は極めて重要です。コールドスタートの挙動、価格モデル、スケーリングの粒度、エコシステムとの適合性における違いは、成果に大きな影響を及ぼす可能性があります。分析やデータエンジニアリングのワークロード向けに、Databricks SQLなどのプラットフォームはサーバーレスのクエリ実行機能を提供しています。チームは、Databricks Lakebaseのプロダクトツアーを通じて、このモデルがどのように運用ワークロードに拡張されるかを確認することもできます。

データベースアーキテクチャが進化し続ける中、レイクベースアーキテクチャは、共有データ基盤上で運用ワークロードと分析ワークロードを統合します。

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