メインコンテンツまでスキップ

ゼロにスケール

備考

ベータ版

Lakebase Postgres (オートスケール Beta) は、 Lakebase の次のバージョンであり、評価のみに利用できます。 本番運用ワークロードの場合は、 Lakebase Public Previewを使用します。 どのバージョンが適しているかを判断するには、バージョンの選択を参照してください。

Scale to Zero は、一定期間の非アクティブ状態の後に Lakebase コンピュート を自動的に停止し、継続的にアクティブではないデータベースのコストを最小限に抑えます。 この機能は、開発、テスト、ステージング環境、およびアイドル期間が予測可能な本番運用データベースに特に役立ちます。

ゼロへのスケールが有効な場合:

  • コンピュートは一定期間非アクティブ状態が続くと自動的に一時停止します (最長は 5 分、最短は 60 秒)
  • アイドル期間ではなく、アクティブなコンピュート時間に対してのみ料金が発生します
  • 新しいクエリを実行すると、コンピュートは数百ミリ秒以内に自動的に再アクティブ化されます。

この図はオートスケールと並んでゼロへのスケールの動作を示しており、データベースが再びアクセスされるまでの非アクティブ期間とそれに続く自動停止を示しています。

スケールゼロの視覚化

ゼロスケールはオートスケールとは独立して機能します。 オートスケールは、ワークロードの需要に基づいてアクティブ期間中にコンピュート リソースを調整しますが、ゼロにスケールすると、非アクティブ期間中にコンピュートが完全に一時停止され、コンピュート コストがゼロに削減されます。

ゼロスケールの仕組み​

自動停止​

コンピュートが設定されたタイムアウト期間にわたってアイドル状態 (クエリや接続を受信しない) のままになると、Lakebase はコンピュートを自動的に一時停止します。 停止中:

  • コンピュートはリソースを消費せず、コンピュートコストもかかりません
  • データは安全に保存され、利用可能
  • 接続文字列と資格情報は有効なままです
  • コンピュート エンドポイントはアクセス可能なままですが、非アクティブです

自動再アクティブ化​

新しいクエリまたは接続リクエストが一時停止されたコンピュートに到着すると、Lakebase はそれを自動的に再アクティブ化します。 再アクティブ化のプロセス:

  • 手動介入は不要
  • アクティブになると、接続要求を透過的に処理します
  • コンピュートを設定された最小サイズに復元します (オートスケールが有効な場合)

アプリケーションは、短い再アクティブ化期間を適切に処理するために、接続再試行ロジックを実装する必要があります。

タイムアウト設定​

ゼロへのスケール タイムアウトを構成して、コンピュートがアイドル状態になってからどれだけ早くサスペンドするかを制御します。 タイムアウトによって次のバランスが決まります。

  • タイムアウトの短縮（60秒～5分） ：停止が速いほどコストは削減されますが、断続的なワークロードの再アクティブ化が頻繁に発生する可能性があります。
  • タイムアウトが長い（5分～1時間） ：再アクティブ化が少なくなると、散発的なアクティビティのユーザーエクスペリエンスが向上しますが、アイドル期間が長くなるとコストが増加する可能性があります。

最小タイムアウトは 60 秒です。最大値はユースケースに応じて構成可能です。

ゼロ利益へのスケール​

  • コスト削減: 非アクティブなコンピュートを一時停止することで、実際の使用時間に対してのみ支払いが発生します。 1 日あたり 8 時間使用される開発データベースのコストは、常時アクティブなコンピュートの 3 分の 1 です。
  • 柔軟な展開: ゼロへのスケールにより、複数の環境をコスト効率よく展開できます。それぞれに 24 時間 365 日のコストをかけずに、個別の開発、テスト、ステージング、プレビュー環境を維持できます。
  • 手動管理は不要: システムが自動的に停止と再起動を処理するため、使用パターンに基づいてコンピュートを手動で起動および停止する必要がなくなります。
  • 保存された構成: すべてのコンピュート設定、接続の詳細、およびデータベース構成は、一時停止中もそのまま残ります。 コンピュートが再アクティブ化されると、同じ構成で再開されます。

スケールをゼロに設定する​

ゼロへのスケールは、どのコンピュートでも有効または無効にできます。 有効にすると、一時停止をトリガーする非アクティブ タイムアウトを構成します (おそらく 5 分、最小は 60 秒)。

一般的な構成では、継続的な可用性を確保するために本番運用ブランチのスケール トゥ ゼロを無効にし、コストを最適化するために開発ブランチのスケール トゥ ゼロを有効にします。

ゼロスケール設定の詳細な手順については、「コンピュートの管理」を参照してください。

一般的なゼロスケールシナリオ​

開発およびテスト環境​

スキーマ変更のテスト、データ パイプラインの検証、または新機能の実験のための開発ブランチでは、通常、断続的なアクティビティが発生します。 ゼロにスケールすると、夜間、週末、および作業セッションの合間にこれらのコンピュートが自動的に一時停止され、コストが大幅に削減されます。

ステージングおよびプレビュー環境​

デプロイメント前の検証に使用されるステージング環境や、プル リクエスト用に作成されたプレビュー環境は、テスト サイクル間でアイドル状態のままになることがよくあります。スケールをゼロにすると、これらの環境ではアクティブなテスト期間中にのみリソースが消費されるようになります。

アイドル期間のあるAIエージェントとアプリケーション​

特定の営業時間に対応したり、ダウンタイム パターンが予測可能な AI エージェント、チャットボット、または内部ツールは、ゼロへのスケールのメリットを享受できます。コンピュートは営業時間外には一時停止され、ユーザーが戻ると自動的に再アクティブ化されます。

マルチテナントアプリケーションデータベース​

複数の顧客にサービスを提供するアプリケーションでは、テナント固有のデータベースに対してスケール ゼロを使用できます。非アクティブなテナントのコンピュートは自動的に一時停止され、すべてのテナントにわたる総コンピュート コストが削減されます。

重要な考慮事項​

セッションコンテキストのリセット​

コンピュートが一時停止され、後で再アクティブ化されると、セッション コンテキストがリセットされます。 これには以下が含まれます:

  • メモリ内統計とキャッシュ内容
  • 一時テーブルと準備済みステートメント
  • セッション固有の構成設定
  • 接続プールとアクティブなトランザクション

アプリケーションで永続的なセッション データが必要な場合は、継続的なコンピュート可用性を維持するために、スケールをゼロに無効にすることを検討してください。

起動遅延​

短い再アクティブ化期間 (通常は数百ミリ秒) により、一時停止後の最初のクエリのユーザー エクスペリエンスが影響を受ける可能性があります。即時の応答時間を必要とするアプリケーションの場合は、次のことが可能です。

  • 常に利用可能なコンピュートのためにゼロへのスケールを無効にする
  • アプリケーションレベルの接続ウォーミングを実装する
  • 再アクティブ化の頻度を減らすために、タイムアウト期間を長くする

デフォルトのブランチ動作​

無理ブランチ (通常は本番運用) は、継続的な可用性を確保するために、無意識によってゼロにスケールが無効にされています。 本番運用ワークロードに予測可能なアイドル期間がある場合はこれを有効にできますが、ユーザー エクスペリエンスへの影響を慎重に検討してください。

ゼロスケールとオートスケール​

オートスケールをゼロにスケールして、パフォーマンスとコストの両方を最適化します。

  • アクティブ期間中: オートスケールは、構成された範囲内のワークロード需要に基づいてコンピュート サイズを調整し、アクティビティが多いときはスケールアップし、負荷が軽いときはスケールダウンします。
  • 非アクティブ期間中: ゼロスケールへのタイムアウトの後、コンピュートは完全に一時停止され、設定されたオートスケール範囲に関係なく、コンピュート コストはゼロに下がります。
  • 再アクティブ化すると: コンピュートは最小オートスケール サイズで再起動され (オートスケールが有効な場合)、オートスケールは新しいワークロードに基づいてリソースを調整します。

この組み合わせにより効率が最大化されます。オートスケールはアクティビティ中のリソース使用量を最適化し、ゼロにスケールすると非アクティビティ中のコストを排除します。

次のステップ​

に最終更新