Databricks Lakebase の自動節約機能、Always-On 価格プランのご紹介

ほとんどのマネージド運用データベースでは、柔軟性を重視するなら「サーバーレス」を選択して割高な料金を支払うか、単価は安いものの俊敏性を犠牲にする「プロビジョニング済み」を選択するか、という二者択一を迫られます。それは誤った選択です。Databricks Lakebase に 常時稼働価格 を導入します。サーバーレスの柔軟性と、ベースライン使用量に対する予測可能で低価格な料金設定です。コンピューティングのスケーリングパラメータを設定するだけで、 ベースライン容量が 25% 割引になります。

これが重要な理由：

• 最適化の手間なし： コスト削減のために、手動でのサイジングや、使わないと損をする長期コミットメントは不要になります。
• シームレスな弾力性： スパイクに対応するためにデータベースは引き続き自動でスケールしますが、ベースラインリソースの料金は低くなります。
• 完全な透明性： ワンクリックで、低価格、ゼロ・フレクション。

夜間や週末にインスタンスのチューニングに時間を費やすのはやめましょう。トグルを切り替えてパフォーマンスを維持し、予算を節約しましょう。

解消されるトレードオフ

クラウドの Postgres 製品では、従来、オペレーターは 2 つの選択肢のどちらかを選ぶ必要がありました。レガシーな プロビジョニング済み 製品 では、ピーク時の使用量に対して継続的に支払いが発生するため、需要の急増に対応するために過剰なサイジングが必要でした。 サーバーレス 製品は弾力的にスケーリングしますが、時間あたりの料金が大幅に高いため、アイドル状態にならないワークロードにはコストがかかります。両者の切り替えにはダウンタイムやメンテナンスが必要でした。

Lakebase はすでに、ストレージとコンピューティングの分離、ストレージレイヤーへのフルページ書き込みの追加、インスタントブランチングの追加など、いくつかの Postgres のトレードオフを解消しています。常時稼働価格は、商用モデルに革新をもたらします。予測可能で低コストなベースラインと、スパイクを吸収する弾力的なコンピューティングとのトレードオフはなくなりました。それぞれに対して 1 つのアーキテクチャを選択する必要はありません。同じデータベースで両方を利用できます。

常時稼働価格の仕組み

1. スケールツーゼロを無効にし、自動スケーリング範囲を設定： Lakebase Postgres 自動スケーリングプロジェクトで、スケールツーゼロをオフにし、自動スケーリング範囲を設定します。最小容量が常時稼働ベースラインとなり、データベースが常に利用できるコンピューティング容量となります。
2. ベースライン容量は低価格の常時稼働レートで請求： 24 時間連続使用後、ベースライン使用量は低価格の「常時稼働」レートで請求されます。コミットメント不要、過剰プロビジョニング不要。ワークロードに最適なレートで自動的に請求します。
3. 最小値を超えて標準レートで自動スケーリング： データベースの負荷がベースライン容量を超えて急増した場合、Lakebase は自動スケーリング範囲で設定された最大容量まで自動スケーリングします。ベースラインを超える使用量は、通常の自動スケーリングレートで請求されます。

必要に応じて、後で再度有効にすると、インスタンスは標準の自動スケーリング価格に戻ります。

他の Postgres オプションとの比較

ほとんどのマネージド PostgreSQL 製品では、プロビジョニング時にプロビジョニング済みバージョンかサーバーレスバージョンのどちらかを選択するという構造的な選択を迫られます。24 時間 365 日稼働するワークロードの料金を改善するために、プロビジョニング済み製品を選択して利用率の低い容量に対して支払うか、サーバーレス製品で 1 年以上の使用義務のあるコミットメントを行うかのいずれかです。

実際にはどのようなメリットがありますか？

• コミットメントフリーの価格設定： 長期コミットメントや過剰な容量プロビジョニングなしで、自動的に最良の価格を得られます。要件の変化に応じて、いつでもデータベース構成やスケーリングパラメータを変更できます。
• 単一の統合製品： ワークロードに合わせてスケーリングする単一の製品で、「プロビジョニング済み」と「サーバーレス」インスタンスの初期選択が不要になります。
• すべての対象インスタンス（HA インスタンスを含む）が自動的にメリットを得られます： 高可用性レプリカと最大の Lakebase インスタンスは、設計上ゼロにスケールしません。常時稼働により、設定変更なしで低価格で請求されるようになります。

常時稼働を使用する場合とスケールツーゼロを維持する場合

常時稼働は、確立されたベースラインに使用します。 アクティビティの安定したフロアがあり、その上にピークが重なるロード履歴を持つ本番ワークロードは、コンピューティングがアイドル状態になることがなかったため、スケールツーゼロの恩恵を受けられませんでした。今日まで、すべての CU 時間に対して標準の自動スケーリングレートを支払っていました。今日からは、ベースライン部分は 25% 低い価格で請求され、自動スケーリングは引き続きピークに対応します。

スケールツーゼロは、新規または断続的なワークロードに使用します。 新規プロジェクトでは、通常、わかりません。適切な最小 CU を設定するためのロード履歴がなく、誤った推測のコストは大きいです。高すぎると不要なヘッドルームに対して支払い、低すぎると自動スケーリングが最小値を超えて多くの時間を費やし、低価格の利点が損なわれます。これはまさに、新規プロジェクトでスケールツーゼロがデフォルトになっている理由です。数週間かけてワークロードの形状を把握し、情報に基づいた判断を下してください。

負荷が断続的なワークロードの場合は、スケールツーゼロを有効にしたままにします。データベースが 75% の時間アイドル状態である場合、それらの時間に対して $0 を支払う方がはるかに有利です。自動スケーリング履歴で、コンピューティングがゼロで多くの時間を費やしていることが示されている場合は、スケールツーゼロを有効にしたままにします。

弾力性税の支払いをやめる準備はできましたか？

Lakebase プロジェクトを開き、スケールツーゼロをオフにして、実際のベースラインを反映する最小 CU を設定します。これだけで構成の変更は完了です。24 時間連続使用後、ベースライン容量は自動的に常時稼働レートで請求され、トラフィックが急増した際には自動スケーリングが引き続き機能します。署名するコミットメントはなく、プロビジョニングする新しい製品もなく、スケジュールするダウンタイムもありません。

さらに、2027 年 1 月 31 日まで実施される 50% のプロモーション割引を適用すれば、Postgres の請求額は大幅に削減されます。今すぐ Lakebase を使い始めるか、完全な価格設定については https://www.databricks.com/product/pricing/lakebase をご覧ください。

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