PostgreSQL
PostgreSQLデータベースをホストする5つの方法
はじめに
プロジェクトや組織でPostgreSQLインスタンスを取得する方法はたくさんあります。PostgreSQLを自分でインストールして構成する方法を学ぶことも、サービスプロバイダーにPostgreSQLデータベースの管理を依頼することもできます。
このガイドでは、PostgreSQLを実行するさまざまな方法と、それぞれの利点と欠点について説明します。異なるオプションを比較することで、あなたのプロジェクトや開発段階に最適なソリューションの種類について、より良いアイデアを得られるはずです。
セルフマネージドPostgreSQL
最も柔軟で説明が簡単なオプションは、PostgreSQLサーバーをセルフホストすることです。PostgreSQLをセルフホストするということは、他のソフトウェアと同様に、あなたが管理するコンピューターにデータベースをインストールして構成することを意味します。
セルフホスティングでは、データベースをインストールして実行する場所について多くの選択肢が得られます。このセクションのオプションのいずれかを選択した場合、このガイドでシステムにPostgreSQLをインストールする方法を学ぶことができます。
ローカル開発コンピューターへのPostgreSQLのインストール
初期開発、テスト、概念実証のために、PostgreSQLをローカル開発マシンにインストールすると、データベースへの信頼性が高く、管理しやすいアクセスを提供できます。
| ホスティングオプション | ローカル開発マシン |
|---|---|
| プロジェクト段階 | 開発 |
| コスト | 追加費用なし |
| パフォーマンス | 低い |
| スケーラビリティ | なし |
| 管理の複雑さ | 低い |
| 追加メモ | ネットワーク設定は不要。ローカル開発に 適している。 |
コスト
開発マシンにPostgreSQLをセットアップするのは無料です。データベースは、開発中にすでにアクティブになっているコンピューター上で実行されます。考慮すべきは、稼働中にPostgreSQLが消費するリソースの量だけです。
パフォーマンス
開発マシンへのPostgreSQLのインストールは、パフォーマンスの低いオプションです。
データベースは他のユーザーに簡単に、または確実に利用可能になりません。あなた自身のデータベースの使用は、あなたのハードウェアとPostgreSQLに割り当てられるリソースの量によって制限されます。これらの懸念は、通常、ローカルでのテストや開発中には問題になりませんが、より複雑なものには全く不十分です。
スケーラビリティ
開発マシンでのホスティングでは、スケーラビリティはほとんどありません。PostgreSQLに割り当てられるリソースの量は変更できますが、それ以上はあまりできません。開発マシンをアップグレードすることはできますが、それは長期的には実用的でも特に有用でもありません。
管理の複雑さ
複雑さという点では、ローカルマシンでのPostgreSQLのホスティングは通常、非常に簡単です。ほとんどのオペレーティングシステムでのインストールプロセスはよく考えられており、結果として得られるデータベースは簡単に起動または停止できます。ただし、ローカルのPostgreSQLインスタンスを外部アクセス用に構成することは、リソースの制限と消費者ネットワークの不安定性を考えると、通常、労力に見合いません。
PostgreSQLをローカルにセットアップするのは複雑ではありませんが、データベースを管理し、必要に応じてアップグレードを実行する必要があります。これらは、時折セキュリティパッチのために必要になる場合があり、データの安全性を懸念するならば、これらのインスタンスを追跡することはあなたの責任になります。
追加メモ
ローカルにインストールするということは、ネットワークが停止していても、開発コンピューターからデータベースにアクセスできることを意味します。これは、旅行中に特に役立ちます。データにローカルでアクセスすることで、ネットワークの複雑さがなくなり、データベースアクセスではなく開発に集中できます。
ローカル開発コンピューターへのPostgreSQLのインストールは有用ですが、いくつかの明確な制限があります。マルチユーザーアクセスを簡単に構成できず、データベースの稼働時間はコンピューターの可用性とネットワークの安定性に直接結びついています。これらの理由から、開発マシンへのインストールは、生産性と柔軟性を高めるための補完的なオプションであり、唯一のデータベースインストールではありません。
別のサーバーへのPostgreSQLのインストール
もう1つのセルフホスティングオプションは、別のコンピューターにPostgreSQLをインストールして管理することです。一般的な実装には次のものがあります。
- 専用サーバーへのインストール：PostgreSQLは、専用コンピューター上で唯一のサービスとして実行されるように構成されています。マシンリソースのすべてにアクセスできます。
- 関連アプリケーションと並行してインストール：PostgreSQLは、それを必要とするアプリケーションと並行してインストールされます。これは、すべてのコンポーネントを1台のマシンで管理できるため、小規模なデプロイメントで人気のある選択肢です。コンピューターのリソースは、PostgreSQLと他の実行中のアプリケーションの間で共有されなければなりません。
別のサーバーへのPostgreSQLのインストールは、開発マシンへのインストールとは大きく異なります。
| ホスティングオプション | 別のサーバー |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番 |
| コスト | 可変。追加のサーバーの購入またはレンタル および追加の管理費用。 |
| パフォーマンス | 高い可能性 |
| スケーラビリティ | 高い可能性 |
| 管理の複雑さ | 高い |
| 追加メモ | 最も柔軟なオプション。最も多くの 手動管理を必要とする。社内にハードウェアやデータベースの 専門知識があり、管理に専念できる場合は良い選択肢。 さらに強調すべき考慮事項の1つは、PostgreSQLを自分で管理する場合、セキュリティがあなたの責任になるということです。組織の他の部分ですでにインフラストラクチャ、ソフトウェア、ネットワークセキュリティを処理している場合は、これは問題にならないかもしれません。しかし、あまり詳しくない場合は、PostgreSQLインスタンスとその保持するデータを保護することは、大きな課題となる可能性があります。この道を選ぶ前に、計画にこれを考慮するようにしてください。 |
さらに強調すべき点の1つは、PostgreSQLを自分で管理する場合、セキュリティはあなたの責任であるということです。もし既に組織の他の部門でインフラストラクチャ、ソフトウェア、ネットワークのセキュリティを扱っているのであれば、これは問題にならないかもしれません。しかし、もし不慣れな場合は、PostgreSQLインスタンスとそれが保持するデータを保護することは、大きな課題となる可能性があります。この道を選ぶことを決定する前に、計画にこれを確実に考慮に入れてください。
コスト
専用または共有マシンでPostgreSQLを実行するには、使用するサーバー領域を購入またはレンタルする必要があります。実際のサーバーは、組織のオンプレミス、データセンター内のコロケーション、またはクラウドプロバイダーがホストする仮想マシン（仮想プライベートサーバーまたはVPSsとも呼ばれる）として運用される場合があります。
サーバーのコストは大きく変動する可能性があります。低電力のVPSは非常に安価ですが、複数の専用サーバーはすぐに高価になります。ただし、サーバーのコストだけが考慮事項ではありません。追加の管理コストも考慮に入れる必要があります。デプロイ環境によっては、データベース層、サーバーのソフトウェア、ハードウェアを管理するための人件費が含まれる場合があります。これらのコストは、可用性要件、ホスティング環境、および運用の規模によって異なります。
パフォーマンス
PostgreSQLを別のサーバーにデプロイすると、非常に高いパフォーマンスが得られる可能性があります。PostgreSQLを実行するマシンの仕様はあなたの管理下にあるため、ニーズに合ったハードウェアを自由に選択できます。将来拡張する必要がある場合は、ハードウェアをアップグレードするか、追加のサーバーを購入してワークロードをスケーリングできます。
また、データベース構成を微調整して、追加のパフォーマンス上の利点を得ることもできます。メモリ管理、キャッシュ、オープンファイル処理、クライアント接続など、関連する設定を微調整できます。これにより多くのパワーが得られますが、これらのオプションを活用するには時間、専門知識、および実験が必要です。独自のサーバーを実行する他の側面と同様に、利点はプロジェクトのこの側面に割り当てられる時間とお金によって制限されます。
スケーラビリティ
前述の通り、専用サーバーで実行することで、データベースシステムへの変化する要求に対応できます。データベースサーバーにリソースとハードウェアを追加することでスケール
管理の複雑さ
一般的に言えば、スケーリングにはパフォーマンスチューニングと同じ利点と限界があります。信じられないほどの柔軟性とパワーがありますが、コストと構成の管理はあなたの責任です。追加のハードウェアを必要とする変更（需要の増加など）は、組織がハードウェアを調達し、ソフトウェアを構成し、ワークロードをバランスさせる時間を確保するために、プロアクティブな監視と組み合わせる必要があります。
追加メモ
要約すると、独自のPostgreSQLを管理することは、信じられないほど効率的、強力、かつ柔軟ですが、多大な時間とリソースを必要とする場合があります。このオプションは、データベースの実行環境、構成、およびアーキテクチャのトポロジーを制御したい、社内にインフラストラクチャおよびサーバーの専門知識を持つ組織に最適です。
DockerとPostgreSQL
もう1つのセルフホスティングオプションは、Dockerを使用してPostgreSQLをコンテナとして実行することです。Dockerを使用すると、ローカルまたはリモートマシン上の分離された環境でPostgreSQLを実行できます。
| ホスティングオプション | Dockerコンテナ |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番 |
| コスト | 可変。追加のサーバーの購入またはレンタル および追加の管理費用。 |
| パフォーマンス | 中～高 |
| スケーラビリティ | 高い |
| 管理の複雑さ | 中～高 |
| 追加メモ | コンテナ化されたインフラストラクチャは、複雑さの点で 劇的に異なります。コンテナは開発中やステージング中に 多くのことを容易にしますが、本番環境で適切に実行するには 経験と複雑なオーケストレーションも必要とします。 本番ワークロードの場合、コンテナはKubernetesのような コンテナオーケストレーションにすでに投資している場合にのみ 良い選択肢となるでしょう。 Kubernetesのようなコンテナオーケストレーション。 |
従来のローカルインストールに比べてDockerを使用する利点には、次のようなものがあります。
- 公式のPostgreSQL Dockerイメージを使用すると、PostgreSQLのインストールと比較して手間が省けます。
- Dockerを使用すると、複数の環境でまったく同じデータベース構成を再現できるため、同じPostgreSQL構成を必要とするプロジェクトで協力するチームに役立ちます。
- Dockerを使用して、PostgreSQLに割り当てられるCPU、メモリ、ストレージリソースを制御できます。
- Dockerは、PostgreSQLとマシン上で実行されている他のソフトウェアとの間の非互換性の可能性を低減します。
Dockerを使用してPostgreSQLをローカルまたはリモートマシンにインストールすることは似ていますが、本番ワークロードにPostgreSQLを使用するかどうかによって、いくつかの追加の考慮事項があります。
DockerはPostgreSQLの実行における特定の側面を簡素化しますが、注意すべきいくつかのトレードオフがあります。
- 構成によっては、Dockerでの実行によりネットワーク構成の複雑さが増す可能性があります。
- Dockerは追加の抽象化レイヤーを追加するため、追加のセキュリティ上の考慮事項が必要になり、トラブルシューティングがより間接的になる可能性があります。
コンテナとKubernetes
Kubernetesを使用すると、複数のサーバーで構成されるクラスター上でDockerコンテナを実行できます。クラスター内の1つのサーバーをメンテナンスのために停止する必要がある場合でも、基盤となるデータパーティションにアクセスできる限り、KubernetesはPostgreSQLコンテナを別のサーバーに移動します。また、PostgreSQLを使用するアプリケーションをKubernetes上で実行することもでき、これによりアプリケーションとPostgreSQL間のネットワーク遅延を低減できます。
マネージドサービス
PostgreSQLを自分で実行する代わりに、プロバイダーからPostgreSQLデータベースをレンタルまたは購入するという選択肢もあります。マネージドサービスを使用すると、PostgreSQLソフトウェアや基盤となるサーバーの舞台裏の管理を気にすることなく、データベースをサービスまたはAPIとして簡単に操作できます。
さまざまなニーズに対応するために、異なる種類のマネージドサービスが存在します。このセクションでは、ホスティングプロバイダーまたはクラウドプロバイダーが提供するサービス、サードパーティのマネージドデータベース、およびアプリケーションプラットフォームが提供するデータベースについて説明します。
クラウドプロバイダーが管理するデータベース
おそらく最もよく知られているマネージドPostgreSQLホスティングの種類は、クラウドまたはホスティングプロバイダーによって提供されるものです。これには、Amazon Web ServiceのRDS（リレーショナルデータベースサービス）、Google Cloud PlatformのCloud SQL、Azure Databaseなどがあります。
| ホスティングオプション | クラウドプロバイダーマネージド |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番 |
| コスト | 選択と使用状況に応じて大きく異なります。 と使用。 |
| パフォーマンス | 大きく異なる |
| スケーラビリティ | 高い |
| 管理の複雑さ | 低い |
| 追加メモ | アプリケーションを実行できる同じクラウドプロバイダーによって 提供される、非常にスケーラブルなソリューション。これにより、 独自のサーバーを運用する重労働なしで、ネットワーキングと パフォーマンスに対する追加の制御が可能になります。 自前のサーバーを運用する重労働。 |
クラウドプロバイダーは、データセンターで実行され、他のサービスとシームレスに連携するように微調整された、多種多様なPostgreSQLデータベースを提供しています。
クラウドプロバイダー
以下のクラウドプロバイダーは、必要に応じて購入、設定、スケールできるマネージドPostgreSQLデータベースを提供しています。
サーバーとPostgreSQLの大部分はホスティングプロバイダーによって管理されますが、スケーリングオプションの設定、設定の微調整、アクセス管理はあなたが行うことができます。データベースはインターネットから接続できるように構成することも、同じプロバイダーによって管理されているアプリケーションに直接接続することもできます。
コスト
クラウドプロバイダーによって管理されるPostgreSQLデータベースのコストは、広範囲にわたります。最小限のパフォーマンスと稼働時間で無料枠を提供するプロバイダーもあります。一方で、予期せぬトラフィックの増加があった場合、需要に合わせて自動的にスケーリングすると、一夜にして数千ドルの費用がかかることもあります。クラウドのほとんどのサービスと同様に、実際の使用量によって毎月の請求額が変動します。多くのクラウドはコストアラートや、使用量/コストが一定のポイントを超えた場合に自動停止する機能も提供しています。データベースシステムの運用コストを管理するために、使用量を監視し、カットオフを設定することが重要です。
スケーラビリティ
コストは予測が難しい場合もありますが、朗報はクラウドでのスケーリングが信じられないほど簡単であることです。データベースに割り当てられるリソースはオンザフライで構成可能です。これは、アカウントの設定を変更するだけで、ストレージ容量、メモリと計算能力、またはデータを管理するレプリカの数を増やすことができることを意味します。慎重に構成しないと高コストにつながる可能性がある強力な機能の1つは、現在の需要に応じてデータベースのリソースを動的にスケーリングする機能です。これにより、コストをカバーできると仮定すれば、常に要件に対応できる容量を確保できます。
パフォーマンス
スケーラビリティに関連して、パフォーマンスもクラウドで非常に柔軟な領域です。使用パターンに合わせて、データベースのパフォーマンスに最も大きな影響を与える設定を微調整できることがよくあります。現在の構成が力不足の場合、追加のリソースを割り当てることもできます。データベースを使用するアプリケーションとデータベースを併置することも、データベースとアプリケーション間の良好なネットワーキングパフォーマンスを得るのに役立ちます。
管理の複雑さ
管理の複雑さの観点から見ると、クラウドホスト型データベースは非常にシンプルです。あなたは、ほとんどの管理負担をプロバイダーに肩代わりしてもらうために料金を支払っています。アカウントやデータベースに影響を与える設定は引き続き管理する必要がありますが、ハードウェア、オペレーティングシステム、およびPostgreSQL構成の大部分はあなたのために処理されます。これはデータベースの使用に伴う管理オーバーヘッドを大幅に削減する可能性がありますが、特別な場合には、希望するレベルのチューニングにアクセスできない場合があります。
追加メモ
一般的に、クラウドプロバイダーが管理するPostgreSQLデータベースに費用を支払うことは、魅力的な選択肢です。スケーリングとパフォーマンスに関して大きな柔軟性を提供し、管理作業も少なくて済みます。クラウドプロバイダーのデータベースサービスを選択する欠点は、場合によっては、他の方法よりも多くの費用がかかる可能性があることです。さらに、ツールがプロバイダー固有の機能に過度に依存し始めると、現在のプロバイダーに縛られる危険性もあります。
サードパーティマネージドデータベース
クラウドプロバイダーから直接データベースを購入する代わりに、サードパーティプロバイダーを通じてデータベースを管理することを選択できます。ほとんどの場合、このオプションは、選択したクラウドまたはクラウドにデータベースをデプロイおよび管理し、データベース管理を基盤となるリソースプロバイダーから切り離します。
| ホスティングオプション | サードパーティマネージド |
|---|---|
| プロジェクト段階 | 開発、ステージング、本番 |
| コスト | 選択によって大きく異なる と使用。 |
| パフォーマンス | 大きく異なる |
| スケーラビリティ | 高い |
| 管理の複雑さ | 低い |
| 追加メモ | サードパーティマネージドデータベースは、クラウド提供の データベースと多くの点で同じ利点があります。 しかし、サードパーティを介してデータベースを管理することで、 データベース管理を基盤となるクラウドプロバイダーから 切り離すことができます。これにより、将来的に別のホストへの 移行が容易になり、より強力な管理オプションが 可能になる場合もあります。 より強力な管理オプション。 |
サードパーティプロバイダーによって管理されるデータベースは、クラウドプロバイダー自体が提供するものと同じ基本的なコンポーネントを使用することがよくあります。ただし、サードパーティプロバイダーは複数のクラウドと連携し、あなたのアカウントでリソースを起動し、必要であればより低レベルのアクセスを提供することがよくあります。クラウドプロバイダーが提供するデータベースを使用する代わりに、サービスはプロバイダー上で仮想サーバーを起動し、これらを使用してPostgreSQLをインストールおよび構成します。彼らはオペレーティングシステムの設定を調整し、インスタンスをホストするサーバーへのアクセスを提供できます。サードパーティのPostgreSQLプロバイダーの例としては、現在4つの異なるクラウドでインスタンスを管理できるElephantSQLがあります。
サードパーティのサービス
以下のサードパーティプロバイダーは、必要に応じて購入、設定、スケールできるマネージドPostgreSQLデータベースを提供しています。
- Aiven
- Compose
- ElephantSQL
- Database Labs
- ScaleGrid
サーバーとPostgreSQLの大部分はプロバイダーによって管理されますが、データベースが実行されるクラウドプラットフォーム、スケーリングオプション、設定の微調整、アクセス管理はあなたが行うことができます。データベースはインターネットから接続できるように構成することも、同じプロバイダーによって管理されているアプリケーションに直接接続することもできます。
コスト
コストの面では、サードパーティのソリューションも非常に可変的です。ユーザーとしては、デプロイするクラウドの計算リソースと、データベース管理サービスが請求する管理コストの両方を支払う必要があります。マネージドデータベースではなく、より基本的なリソースに対してクラウドプロバイダーに支払うため、その側のコストは小さくなるかもしれません。しかし、管理サービスに関連するコストにより、特定の価格帯では累積的に高くなる可能性があります。合計コストを決定するには、各サイドが異なるレベルでどのようにスケールするかを把握する必要があります。
パフォーマンス
データベースのパフォーマンス特性も大きく異なる可能性があります。管理サービスがクラウド上の計算インスタンスにインストールされているため、プロバイダーはPostgreSQLの設定に加えてサーバー構成も調整できます。これは、ニーズに合わせて一部の設定をより適切に調整できる可能性があることを意味します。
一方で、十分にチューニングするために必要な仮想化およびハードウェアコンポーネントの低レベルのレイヤーにアクセスできない場合があります。クラウドプロバイダーが提供するネイティブデータベースと比較してパフォーマンスをテストすることを強くお勧めします。
スケーラビリティ
サードパーティが管理するデータベースのスケーラビリティは、一般的に非常に優れています。これらのプロバイダーは十分なリソースを持つ任意の計算インスタンスにデプロイできるため、クラウドプロバイダーが公開するよりも広範なスケーリングオプションを提供できる場合があります。スケーリングの理由の1つが可用性を高めることである場合、多くのサードパーティサービスは複数のアベイラビリティゾーン、さらにはプロバイダーにまたがることが可能です。
管理の複雑さ
データベースを管理するサードパーティサービスには、さまざまな複雑さがあります。このオプションは、2つの異なるプロバイダー（計算インスタンスをホストするクラウドとデータベース管理サービス）間の連携を必要とするため、クラウドプロバイダーが提供するネイティブデータベースサービスを使用する場合と比較して、複雑さが本質的に増加します。
一部の管理サービスは、共有ウェブホスティングとほぼ同じように複雑さを隠蔽し、簡素化されたオプションとして位置付けられています。その他のソリューションは、オペレーティングシステムにアクセスできるという事実を活用して、幅広い設定オプションをユーザーに公開します。多くのサービスは、ユーザーが好みの複雑さのレベルを見つけられるように、両方のエクスペリエンスを提供しています。
追加メモ
データベース管理を基盤となるリソースプロバイダーから切り離すことには、利点と欠点の両方があります。
データベース管理サービスが基盤となる層を抽象化していれば、別のクラウドプロバイダーへの移行がより柔軟になる可能性があります。この抽象化により、あなたは自分が快適な複雑さのレベルを選択することもできます。データベース管理サービスが提供する完全な抽象化とインターフェースを使用することもできますが、プロビジョニングされたデータベースサーバーへのアクセスも可能であるため、ログインしてデータベースサーバーを自由に修正できます。データベース管理サービスは、これらのオペレーティングシステムレベルの調整を管理するための簡単なインターフェースも提供する場合があります。
この設定の欠点は、データベースの正しい運用を複数の当事者に依存することになるという事実に起因します。これにより、サービス中断の可能性が高まる可能性があります。また、クラウドプロバイダーが提供するデータベースサービスで利用可能な内部最適化を見逃す可能性もあります。データベース管理サービスは、クラウドプロバイダーが公開しているものにのみアクセスでき、基盤となる仮想化またはハードウェアレイヤーを最適化することはできません。
全体として、サードパーティの管理サービスを利用するかどうかは、好みとテストの問題です。使用レベルに応じてパフォーマンスをテストし、料金体系があなたにどのように影響するかを理解する必要があります。
まとめ
ここでは、ここで議論された様々なオプションが互いにどのように比較されるかの概要を示します。
データベースのホスティングに最適な選択は、アプリケーションの要件、開発の段階、およびPostgreSQLを自分で管理する能力に大きく依存します。異なる選択肢は、これらの要因間でトレードオフを提供し、特定の時期や特定の組織により適したものとなります。
PostgreSQLデータベースがあれば、Prisma Clientを使用してJavaScriptまたはTypeScriptアプリケーション内から管理できます。既存のプロジェクトにPrismaを追加する方法や、Prismaをゼロから始める方法をご覧ください。
ジャスティン・エリングウッド
ジャスティンは2013年からデータベース、Linux、インフラ、開発者ツールについて執筆しています。現在は妻と2匹のウサギと共にベルリンに住んでいます。彼は通常、三人称で書く必要がないので、関係者全員にとって安心です。