動的 PostgreSQL の紹介: クラウドデータベースの自然な進化

今日から、 。 タイムスケールで動的 PostgreSQL データベースを作成できます 動的 クラウド データベースの自然な進化であり、プロビジョニングされたデータベースとサーバーレス データベースの両方の問題を解決します。これは、負荷に応じて事前定義された最小/最大範囲内で利用可能なコンピューティングを即座にスケールするタイムスケールのイノベーションである動的コンピューティングによって支えられています。ピークに合わせてプロビジョニングする (そして常に料金を支払う) のではなく、コンピューティング範囲を選択できるようになりました。データベースは基本容量で動作し、必要な場合にのみ瞬時にピークにアクセスします。ベースを購入し、ピークをレンタルします。 PostgreSQL は これにより、比類のないコストパフォーマンスが実現します。実稼働ワークロードを実行しているお客様は、AWS RDS for PostgreSQL から移行する場合は 10 ～ 20 %、AWS Aurora Serverless から移行する場合は 50 ～ 70 % を節約できます。 今すぐ Dynamic PostgreSQL を試すことができます。クレジット カードは不要で、30 日間プラットフォームに完全にアクセスできる無料トライアルを提供しています。 動的 PostgreSQL サービスを作成するには、Timescale にログインするときに PostgreSQL オプションを選択するだけです。 アプリケーションは常に稼働しているのに、データベースは稼働していてはいけないのはなぜでしょうか? 未来へようこそ。 問題 1: 開発者が必要以上のコンピューティングをプロビジョニングしている Timescale を初めて立ち上げて以来、過去数年間、私たちは開発者がデータベースをどのように使用するかを最前列で見てきました。たとえば、ここ数か月の間に、 Insights 製品の一部として。 私たちは 1 兆を超えるクエリを分析しました 私たちが学んだことの 1 つは、開発者は実際に必要とするよりもはるかに多くのコンピューティングをプロビジョニングすることが多いということです。 一方で、これは当然のことです。データベースについて心配する必要はまったくありません。ほとんどのデータベース ワークロードは継続的であり、通常はある程度の変動性やバースト性を伴います。たとえば、夜間の使用量が多いゲーム、日中の使用量が多いビジネス アプリケーション、平日よりも週末の使用量が多いコネクテッド ホーム デバイスなどです。 データベースのリソースが不足することは決して望ましくありません。データベースが最大容量に達している場合、顧客エクスペリエンスはひどいものになります (または顧客エクスペリエンスがまったくありません!)。そのため、ほとんどの開発者は、ピークに加えてバッファーをプロビジョニングすることになります。その結果、開発者は実際に必要なコンピューティングよりもはるかに多くのコンピューティングに対して支払うことになります。 一方、これは私たちにとってはおかしなことのように思えます。組織が必要以上に支出しても大丈夫なビジネス リソースが他にあるでしょうか?無駄なコンピューティングは無駄なお金と同じです。 問題 2: サーバーレス データベースは実稼働ワークロードに対応していない 「サーバーレス データベースについてはどうですか?」と疑問に思う人もいるかもしれません。 サーバーレスの概念は、ステートレス ワークロードから始まりました。クラウド上の仮想マシンが成功し、ユーザーがハードウェアについて心配する必要がなくなると、次に、アプリケーション サーバーの実行についてそもそもなぜ心配する必要があるのかと疑問が生じました。結局のところ、多くのユーザーは機能を実行したいだけで、その機能が実行されている時間に対してのみ料金が発生することを望んでいました。また、関数はステートレスであるため、必要に応じて関数を簡単かつシームレスにスピンアップできます。サーバーレス、および Function-as-a-Service (FaaS) がヒットし、AWS Lambda がその地位を引き継ぎました。 そこで開発者は、「データベースを使用していないのに、なぜ料金を支払う必要があるのでしょうか?」と自問しました。実際の質問は適切です。リソースの無駄はデータベースの大規模な問題です。また、特定のサーバー インスタンス (db.m6gd.2xlarge) 上に AWS RDS データベースをプロビジョニングするという実践は、固定 CPU、固定メモリ、固定ローカル ディスクなど、現代的でも柔軟でもないように思えます。そのほとんどはほとんどの場合十分に活用されていません。 しかし、ここからが問題になります。データベースは Lambda 関数とは大きく異なります。 現在のサーバーレス データベースは、次の 2 つの主な理由により、ほとんどの実稼働ワークロードに対して不適切です。 サーバーレス データベースは、スケールアップとスケールダウン、さらにはゼロまでの極端なスケールに重点を置いています。 サーバーレス データベースでは、変化する需要に対応するために予約されているリソースの「ヘッドルーム」を考慮して、はるかに高い価格設定が導入されています (さらに悪いことに、理解や予測が難しい価格設定モデルが使用されることがよくあります)。 まずは「ゼロへのスケール」という注目のトピックについて説明しましょう。実際には、ほとんどの実稼働データベースではゼロにスケーリングする必要がなく、実際にはゼロにスケーリングするメリットもありません。 現在、「ゼロにスケールする」ことが意味のあるユースケースがいくつかあります。たとえば、概念実証のデモや趣味的なアプリケーションなどです。データセットに対してアドホック クエリを時折実行する機能 (AWS Athena と Google BigQuery は、非常に断続的な使用向けの低コストのサーバーレス クラウド データ ウェアハウスを強力に主張します)。もう 1 つの適切な使用例は、終了後にクラウド開発インスタンスをスピンダウンするのを忘れないようにすることです。非運用データベースを「自動一時停止」することに価値があります (ただし、これにはサーバーレスで想定されているよりもはるかに単純な機能が必要です)。 しかし、運用データベースやその他の運用設定ではどうでしょうか?ゼロまでスケールする必要はありません。 ゼロへのスケーリングは、再起動時の「コールド ブート」を意味します。空のデータベース共有バッファ、空の OS キャッシュ、空のカタログ キャッシュ (PostgreSQL の場合)。 (はい、一部のサーバーレス データベースではデータベースの実行開始にかかる時間が短縮されますが、空の状態から開始されます。PostgreSQL のようなリレーショナル データベースでは、ウォーム ワーキング セットを再度構築するのに数分 (またはそれ以上!) かかる場合があります。特に大規模なデータベースの場合。) 多くのサーバーレス データベースが異なるクラウド ストレージ アーキテクチャを採用しているため、コールド スタートのパフォーマンスへの影響はさらに大きくなり、リモート ストレージからデータベース ページをメモリにフェッチするコストと遅延がさらに大きくなります。これらのオーバーヘッドは再びパフォーマンスの低下につながるか、プラットフォームプロバイダーがより多くの物理リソース（たとえば、Amazon Aurora データベースには RDS の 2 倍のメモリがあります）を使用することで補うことを余儀なくされ、そのコストは最終的にユーザーに転嫁されます。 そのため、多くのシナリオでは、サーバーレス データベースの価格はより高く、予測不能な価格設定になります。 たとえば、Aurora Serverless と Amazon RDS を比較すると、Serverless 上の 8 vCPU コンピューティングと 500 GB のストレージは RDS より 85 % 高価であることがわかります (1,097 ドル対 593 ドル)。これには、Aurora I/O Optimized と、わずか 6 か月前にリリースされた、より予測可能なストレージ価格が使用されています。 (ただし、ここでも実際のコンピューティング能力を推測する必要があります。Aurora Serverless の価格は、不透明な「Aurora キャパシティー ユニット」を混同することで設定されているためです。最もよく知られた情報によると、これは 1 ACU = 0.25 vCPU であると推定されています。) これらの結果を裏付ける完全なベンチマークを近々公開する予定です。乞うご期待。 編集者注: 以前の Aurora Standard では、ユーザーは内部 I/O 操作ごとに料金も支払うことになり、予測や予算を立てることはほとんど不可能でした。多くのサーバーレス データベースでは、引き続きそのような読み取りと書き込みに対して料金が発生します。実際、サーバーレス AWS タイムストリームのベンチマークを行ったところ、 これらすべての限界コストが高いため、Timescale よりも優れています。費用の予測不可能性と変動性は、安心とは裏腹でした。 最終的に 100 倍以上の費用がかかった つまり、サーバーレス データベースは、ワークロードが拡大するにつれて、パフォーマンスが低下し、請求額が予測不能になり、コストが高くなる傾向があります。これらは、たまにしか起動しない断続的なワークロードにのみ適しており、メモリ内データ キャッシュがないためコールド スタートに耐えることができます。 開発者のジレンマ 最終的に行き着いたのは次のとおりです。 多くの開発者は、信頼性の高いパフォーマンス、制御、理解しやすさのため、実稼働アプリケーション用のプロビジョニングを備えた従来の DBaaS サービスを依然として選択していますが、オーバープロビジョニングの必要性から生じる無駄を嫌います。 開発者の中には、明らかなコスト削減、柔軟性、使いやすさを理由にサーバーレス データベースを選択する人もいますが、パフォーマンスの低下や予測不能で不明瞭な価格設定 (プロビジョニングされたインスタンスよりも不思議なことに請求額が高くなることがよくあります) を嫌います。 私たち開発者としても、これらのオプションはどちらもあまり魅力的ではありません。改善のチャンスはあります。 解決策: 動的 PostgreSQL の導入 これが、私たちが Dynamic PostgreSQL を開発した理由です。 動的 PostgreSQL はベースラインを一貫してサポートし、必要なときにコンピューティングを定義された最大値までシームレスに拡張します。これにより、実稼働環境で通常見られる一連の継続的なワークロード (均一、変動、バーストを問わず) に最適になります。 動的 PostgreSQL は 100% PostgreSQL であり、PostgreSQL コミュニティとエコシステムの利点をすべて備えているだけでなく、 。動的 PostgreSQL を構築するために、PostgreSQL の内部を変更するのではなく、PostgreSQL インフラストラクチャの運用方法を革新しました。これにより、フォークされた PostgreSQL クエリやストレージ エンジンでの実行を心配することなく、PostgreSQL (および Timescale プラットフォーム) が提供するすべてのものにアクセスできるようになります。 Timescale のデータベース プラットフォームの成熟度 動的 PostgreSQL では、ワークロードのニーズに対応するコンピューティング (最小および最大 CPU) を選択します。このコンピューティング範囲には、ほとんどの DBaaS サービスが従来コンピューティング範囲の「最大」端で提供していたものと同等の有効メモリも付属しています。 範囲 CPU 範囲のベース (最小) は、プロビジョニングされた DBaaS モデルとまったく同じように動作します。最小 CPU は、アプリケーションを実行するためのサービス専用として常に使用されます。外部アプリケーションの要求によって、または増分バックアップやテーブルの自動バキュームなどの時折の内部データベース タスクによって負荷が増加すると、データベースは遅延なしで CPU 範囲のピーク (最大値) まで使用できます。 遅延ゼロを達成するにはどうすればよいでしょうか?動的コンピューティングは、他のサーバーレス データベースや自動スケーリング データベース製品とは動作が異なるため、リモート移行でよく見られるスケーリングの遅さ (およびパフォーマンスの低下) が発生しません。代わりに、当社のインフラストラクチャ構成およびワークロード配置アルゴリズムにより、再起動や再構成を行わずにデータベースが基盤となるノード上でスケールアップできることが保証されます。インスタンスは、必要に応じて常に最大のコンピューティングにアクセスできます。 そして最も良い点は、基本料金とそれ以上で使用した分の料金のみを支払うということです。コンピューティング範囲を選択し、その範囲内でスケーリングするこのモデルを、「 」と呼びます。 ベースを購入し、ピークをレンタル たとえば、4 ～ 8 CPU オプションを選択した場合、サービス専用の 4 つの CPU と 32 GB の実効メモリが常に利用可能になります。これにより、常に良好な基本パフォーマンスが保証されます。負荷が増加すると、アプリケーションは必要に応じて最大 8 個の CPU を瞬時に使用できます (CPU 単位で計測および課金されます)。これが最大制限である場合、8 個の CPU を超えることはありません。 動的モデルを使用すると、データベースの「サイズ設定」をよりコスト効率よく、安心して行うことができます。標準的な需要が最小値に適合するコンピューティング範囲を選択できますが、必要に応じてピーク (最大値) まで拡張またはスパイクアップすることができます。この最大値により、基本コンピューティングを超える使用量に固有の上限が設けられ、わかりやすいコスト上限が生じます。さらに、基本使用量とこれを超える従量制使用量の両方に対して、(端数の) CPU 時間あたり同じ料金が請求されます。基本使用量を超えて使用しても追加料金は発生しないため、スケーリングによる料金ペナルティはありません。 最後に、プロビジョニングしたサイズ範囲が小さすぎる、または高すぎることに気付いた場合は、コンピューティング範囲をアプリケーションのニーズにより適したサイズに簡単に調整できます。 お金を節約できるように設計されています 現在、ワークロードのサイズに基づいて 5 つの異なるコンピューティング範囲が提供されており、瞬間的な使用量に関係なく、その範囲で受け取れる対応する有効なメモリが提供されます。 Dynamic PostgreSQL は、Timescale の使用量ベースのストレージも使用します。この場合、プロビジョニングされたディスク サイズではなく、保存されたデータの量 (GB 時間単位) に対してのみ料金が発生します。過剰にプロビジョニングされたディスクによってお金が無駄になることを心配したり、同様にディスク容量が不足することを心配したりする必要はありません。 Timescale の動的なクラウド インフラストラクチャにより、必要なときに十分なストレージ容量が確保され、使用した分だけお支払いいただけます。 当社は、コストを節約するために意図的に Dynamic PostgreSQL を開発しました。実稼働ワークロードを実行しているお客様は通常、AWS RDS for PostgreSQL から移行する場合は 10 ～ 20 %、AWS Aurora Serverless から移行する場合は 50 ～ 70 % を節約できます。 月末の請求書は、シンプルでわかりやすい 2 つのメトリクスで構成されます。(1) コンピューティング コスト。時間単位の基本コンピューティングに加え、ピークを超えない部分の CPU 使用量として請求されます。 (2) ストレージ コスト。データ消費量として GB 時間単位で請求されます。測定したり理解したりするための新しい指標や派生単位はありません。 使った分だけお支払いください。追加費用や隠れた手数料はゼロです。 コンピューティング: 定義された範囲に基づいて予測可能 ストレージ: 保存した分のみお支払いください 無駄なリソースはありません。過払いはありません。夜も眠れなくなることはありません。上司に説明できる法案。 今日試してみましょう 今すぐ Dynamic PostgreSQL を試すことができます。 — クレジット カードは必要ありません — 30 日間プラットフォームに完全にアクセスできます。動的 PostgreSQL サービスを作成するには、Timescale にログインするときに PostgreSQL オプションを選択するだけです。 Timescaleは無料トライアルを提供しています このプラットフォームでは、データベースの特定のニーズに応える 2 つのサービス タイプが提供されるようになりました。 最も要求の厳しいワークロードのクエリ速度とスケーラビリティを向上させるように設計されており、ハイパーテーブル、列指向圧縮、連続集計、階層化ストレージなどの主要なタイムスケール機能を提供します。これらを使用して、センサー データ、エネルギー メトリクス、財務データ、イベント、その他のデータ集約型ワークロードをホストします。 時系列サービスは、 コスト効率と使いやすさを考慮して最適化された動的な Postgres サービスです。ビジネス記録などのリレーショナル専用データベースに使用します。 PostgreSQL サービスは、 「PostgreSQL」を選択すると、動的 PostgreSQL サービスの構成は非常に簡単になります。リージョン、動的コンピューティング範囲、高可用性と接続プーリングのオプションを選択してください。 💥 これで、実稼働環境で使用できる動的 PostgreSQL データベースが完成しました。 ご質問がございましたら、 。皆様からのフィードバックをお待ちしており、PostgreSQL のユースケース (時系列かどうかにかかわらず) にお役に立てれば幸いです。 私たちに連絡してください これは始まりにすぎない。私たちは 3 週間連続のリリース週の真っ最中ですが、これは第 2 週目、つまりダイナミック インフラ週間の始まりにすぎません。今週、今月、今年、そして今後数年間のさらなる情報にご期待ください。 🙂 - マイク・フリードマンとグラント・ゴデク著。 こちらでも公開しております。