プロビジョニングを超えて：Databricks Lakebaseオートスケール開発者ガイド

データベースをプロビジョニングする際には、2つの選択肢しかありません。

• 過剰プロビジョニング: ワーストケース シナリオに合わせてコンピュートを高く設定し、アイドル状態の CPU に過剰に支払うことです
• 過小プロビジョニング: コンピュートを低く設定してコストを節約しますが、後でワークロードが急増するとシステムが機能不全に陥ります

これが「プロビジョニングのパラドックス」です。本番運用のデータベースを管理したことがある方なら、この課題に直面したことがあるでしょう。

長年、私たちはこれをリレーショナルデータベースを扱う上での当然のコストとして受け入れてきました。しかし、 Databricks Lakebase 、つまり Databricks と統合された serverless の Postgres の登場により、状況は一変しました。私たちは、固定サイズの「常時稼働」インスタンスから脱却し、よりインテリジェントで弾力性のあるモデル、つまりオートスケールへと移行したのです。

この投稿では、Lakebaseのオートスケールが実際にどのように機能するのか、なぜそれが最新の開発者ワークフローにとって救世主となるのか、そしてインフラストラクチャの管理ではなく機能の構築に集中できるようにガードレールを設定する方法について詳しく説明します。

Lakebase オートスケールとは何ですか？

Lakebase オートスケールは、データベースのサイズをアプリケーションの当面の要件に確実に一致させる、インテリジェントなコンピュートモデルです。

データベースの適切なサイジングは、お使いのアプリケーションの要件によって決まります。データベースのコンピュートは、Tシャツのサイズのように静的で制約のあるものではなく、リアクティブであるべきです。オートスケールでは、データベースに割り当てるリソースの範囲を定義します。システムは現在の負荷に応じて、データベースで利用可能なコンピュート量を動的に調整します。

Lakebaseでは、これはコンピュートユニット（CU）と呼ばれる抽象化を通じて処理されます。オートスケールではきめ細かなアプローチを採用しており、1 CU で 2 GB のメモリが割り当てられます。これにより、システムはより小さく、より正確な単位でスケールできるようになり、パフォーマンスとコストの両方をより厳密に制御できます。

仕組み: スケーリングアルゴリズムの動作原理

オートスケールは単にCPU使用率だけを見ていると思われがちですが、Lakebaseはそれよりもスマートです。アプリケーションのパフォーマンスが低下しないように、オートスケール アルゴリズムは 3 つの主要な技術的柱を監視します。

1. CPU負荷

最も直感的なメトリクスです。アプリケーションが複雑な結合の実行を開始したり、並列リクエストの量が増加したりすると、システムはプロセッサー使用率の急上昇を検出し、CUを追加してクエリーのレイテンシーを低く保ちます。

2. メモリ使用量

リレーショナルデータベースは、メモリを大量に消費することで知られています。このメトリクスは、アクティブなプロセスとバッファが消費するメモリ量を追跡します。Lakebase はメモリをモニタリングすることで、セッションがクラッシュする前にスケールアップしてメモリ不足 (OOM) の問題を未然に防ぎ、高負荷時でも安定した可用性を確保します。

3. ワーキングセットサイズ

これがおそらく、最も重要なプロレベルのメトリクスです。ワーキングセットとは、頻繁にアクセスされるデータ部分のことで、キャッシュ内で「ホット」な状態に保つのが理想的です。ワーキングセットが現在割り当てられているRAMよりも大きくなると、データベースはデータをディスクに「スワップ」する必要があり、これは桁違いに低速です。Lakebaseはワーキングセットのサイズを推定し、コンピュートをスケールアップして、"ホット"なデータが高速メモリに保持されるようにします。

このアプローチの素晴らしい点は、すべてが再起動なしで行われることです。データベース接続は開いたまま維持され、基盤となるインフラストラクチャがトラフィックに柔軟に適応する間も、アプリケーションは応答性を保ちます。

ガードレールの設定: 最小CUと最大CU

オートスケールは、無限のリソースや無限の請求を意味するものではありません。開発者として、パフォーマンスの下限とコストの上限をコントロールする必要があります。これを行うには、スケーリング範囲を設定します。

スケーリング境界の定義

Lakebase のコンピュート インスタンスを設定する際には、2 つの主要な値を設定します。

• 最小CU: これはベースラインです。これにより、トラフィックの少ない期間でも、データベースが管理タスクやバックグラウンドジョブに応答するのに十分な"機敏性"を確保できます。
• 最大 CU: これは予算のセーフティネットです。プロセスの暴走、再帰的なクエリーのバグ、または予期しないトラフィックの急増によって、承認した範囲を超えてコストがスケーリングされるのを防ぎます。

境界に関する重要な注意: スケーリングの予測可能性と高い応答性を維持するため、Lakebase ではコンピュート サイズの最大値と最小値の差が 8 CU を超えないようにする必要があります (例: 2 ～ 10 CU の範囲)。Lakebase オートスケール機能は、最大 32 CU の範囲をサポートします。一貫してより多くのパワーを必要とするワークロードには、より大きな固定サイズのコンピュートも利用できます。

実世界のシナリオ: オートスケールが効果的な場合

1. AI エージェントとインタラクティブなアプリのワークロード

Databricks 上で AI 駆動のアプリケーションや自律エージェントを構築している場合、トラフィック パターンが線形になることはほとんどありません。エージェントは何時間もアイドル状態になった後、複雑なプロンプトの処理や新しいデータセットの取り込みを行う際に、突然、大量のクエリーの連鎖をtriggerすることがあります。

オートスケールにより、インフラストラクチャを「事前ウォームアップ」することなく、データベースがこれらの突然のアクティビティの急増に対応できるようになります。エージェントがタスクを完了すると、データベースは自動的にスケールダウンし、プロジェクトの予算を守ります。

2. 開発、テスト、およびブランチング

Lakebase の最新のデータベースワークフローでは、しばしば データベースブランチングが利用されますが、これは特定の機能や PR のために分離されたコピーオンライト環境を作成する機能です。

これらの開発ブランチのほとんどは、90%の時間アイドル状態です。オートスケール機能により、これらの環境は使用されていないときは最小のCUに留まります。しかし、CI/CD パイプラインが負荷の高い統合テストの起動を開始するか、開発者が手動でのデータ検証を開始した瞬間に、環境は即座にスケールアップし、本番運用レベルのパフォーマンスを提供します。

スケールトゥゼロの利点

オートスケールはアクティブな時間帯を処理しますが、業務時間が終了するとどうなるのでしょうか？

そこで、ゼロへのスケールが究極のコスト最適化ツールになります。オートスケーリングと同時に有効にすると、Lakebaseは完全な非アクティブ期間を検出できます。クエリーが15分間ないなど、ユーザーが定義したタイムアウト時間が経過すると、コンピュートインスタンスは完全に一時停止します。

• コンピュートコストゼロ：インスタンスが一時停止している間、コンピュート料金はゼロになります。
• 即時再起動: 新しい接続またはクエリが到着した瞬間に、データベースは設定されたオートスケールの最小サイズで即座に再開します。

開発環境や、営業時間中にのみ使用される社内ダッシュボードの場合、この組み合わせによって月々のコンピュートコストを70%以上削減できます。

現代の開発者がLakebaseに移行する理由

オートスケールへの移行は、費用面と同様に、運用の簡素化を目的としています。

• 手動でのサイズ変更は不要:CPU使用率が80%に達したときに、Grafanaのボードを監視してインスタンスを手動でサイズ変更する必要はありません。
• 予測可能なパフォーマンス: ワーキングセットとメモリ使用量をモニタリングすることで、Lakebaseはユーザーが速度低下に気づく前にスケールします。
• きめ細かな制御: CUあたり2GBのモデルにより、少しRAMを増やすためだけにインスタンスサイズと請求額を倍増させることを強いる従来のクラウドプロバイダーよりも、はるかにきめ細かなチューニングが可能になります。

まとめ

当て推量によるデータベースのサイジングの時代は終わりました。Databricks Lakebase オートスケールを活用することで、パートタイムのシステム管理者のような業務から解放され、本来注力すべきこと、つまりご自身のコードとデータに集中できるようになります。

境界を設定し、開発Branchでスケールトゥゼロを有効にすれば、あとはLakebaseアルゴリズムが大変な作業を処理してくれます。ユーザーやステークホルダーにも喜ばれるでしょう。

無料お試し・その他ご相談を承ります

最初のオートスケールのコンピュートインスタンスを今すぐ設定する方法については、Lakebaseオートスケールのドキュメントでさらに詳しくご覧ください。

よくある質問 (FAQ)

オートスケールとは？ オートスケールは、データベースのサイズをアプリケーションの要件に合わせて調整する、インテリジェントなコンピュート モデルです。固定サイズのインスタンスから脱却し、現在の負荷に基づいてデータベースで利用可能なコンピュートを調整するエラスティックなモデルに移行します。

オートスケール の主な目的は何ですか？ 主な目的は、プロビジョニングのパラドックスを解決することです。従来、開発者はアイドル状態のCPUに過剰に支払うか、ワークロードの急増時にシステム障害のリスクを冒すかの選択を迫られていました。これにより、データベースのコンピュートは静的なサイズに制約されるのではなく、リアクティブで正確なサイズに調整できます。

オートスケーリングを使用するメリットは何ですか？メリットとして、手動でのサイズ変更が不要になることによる運用の簡素化や、メモリとワーキングセットのプロアクティブなモニタリングによる予測可能なパフォーマンスが挙げられます。さらに、CUあたり2 GBというきめ細かいモデルにより、RAMを増やすためにインスタンスサイズを倍増させる必要があるプロバイダーと比較して、より精密なコストとパフォーマンスのチューニングが可能になります。

オートスケールはどのように容量を動的に管理しますか？ 容量はコンピュートユニットと呼ばれるきめ細かな抽象化を通じて管理され、1ユニットあたり2GBのメモリが割り当てられます。システムはデータベースの再起動を必要とせずにこれらのユニットを追加または削除するため、基盤となるインフラストラクチャが適応している間も接続は開いたままになります。

オートスケールはクラウドのスケーラビリティをどのように向上させますか？ オートスケールは、手動のプレウォーミングを必要とせずにデータベースが突然のアクティビティの急増に対応できるようにすることで、スケーラビリティを向上させます。この弾力性により、重いタスクの実行中に本番運用レベルのパフォーマンスを発揮できるようインフラストラクチャをスケールアップし、終了後には予算を保護するために自動的にスケールダウンすることが保証されます。

Lakebase Autoscalingはどのようなメトリクスを監視しますか？ このアルゴリズムは、低いクエリーレイテンシを維持するためのCPU負荷、メモリ不足の問題を防ぐためのメモリ使用量、頻繁にアクセスされるデータを確実にキャッシュに保持するためのワーキングセットサイズという3つの主要な技術的柱を監視します。

Lakebase におけるコンピュート ユニット (CU) とは？ コンピュート ユニットは、スケーリング範囲を定義するために Lakebase で使用される、きめ細かいリソースの抽象化です。各ユニットは、正確に 2 GB のメモリを提供します。

Lakebase オートスケールでサポートされるCUの最大範囲は？Lakebase オートスケールは最大32 CUまでの範囲をサポートします。その範囲内で、ユーザーが定義したCUの最小値と最大値の差が8 CUを超えないようにする必要があります。

Lakebaseではスケールトゥゼロはどのように機能しますか？ スケールトゥゼロは、完全な非アクティブ期間を検出し、ユーザーが定義したタイムアウト後にコンピュートインスタンスを完全に一時停止します。新しい接続またはクエリーが到着すると、データベースは定義された最小オートスケールサイズで再開します。

Lakebase のオートスケールとスケールトゥゼロの違いは何ですか？ オートスケールは、アクティブな時間帯に、変動する需要に合わせて設定された範囲内でコンピュート サイズを調整します。スケールトゥゼロは、非アクティブな期間に、クエリーがない場合にインスタンスを完全に一時停止してコンピュート コストをなくします。

Lakebase Autoscalingはデータベースのブランチングと併用できますか？ オートスケールは、アイドル時に機能ごとの分離された環境を最小CUで維持できるため、データベースのブランチングに非常に有益です。これらのブランチ化された環境は、開発者が検証を開始したり、CI/CDパイプラインがテストを実行したりするたびにスケールアップして、本番運用レベルのパフォーマンスを提供します。

オートスケールにはデータベースの再起動が必要ですか？いいえ。Lakebaseが基盤となるリソースをスムーズにスケーリングしている間も、データベース接続はアクティブなまま維持されます。

Lakebase の RAM 対 CU 比は？各コンピュートユニット (CU) は、正確に 2 GB のメモリを提供します。

スケールトゥゼロを使用すると、どのくらい節約できますか？開発ブランチや社内ダッシュボードなど、1日の特定の時間帯にのみアクティブになるワークロードの場合、多くの場合、コンピュートコストが70%以上削減されます。

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