ゼロにスケール

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

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

• コンピュートは、一定期間操作が行われないと自動的に一時停止します。 非アクティブタイムアウトはデフォルトで24時間ですが、60秒から7日間の間で設定できます。
• アイドル期間ではなく、アクティブなコンピュート時間に対してのみ料金が発生します
• 新しいクエリを実行すると、コンピュートは数百ミリ秒以内に自動的に再アクティブ化されます。

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

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

ゼロスケールの仕組み

自動停止

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

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

自動再アクティブ化

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

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

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

タイムアウト設定

ゼロへのスケール タイムアウトを構成して、コンピュートがアイドル状態になってからどれだけ早くサスペンドするかを制御します。 設定期間は60秒（1分）から7日間までです。タイムアウトは、以下の間のバランスを決定します。

• タイムアウト時間を短縮（数分単位） ：停止時間を短縮することでコストは削減できますが、断続的なワークロードの場合、再起動の頻度が高くなる可能性があります。
• タイムアウト時間を長くする（数時間から数日） ：再アクティベーションの回数を減らすことで、断続的なアクティビティにおけるユーザーエクスペリエンスが向上します。24 時間のタイムアウトは、ほとんどの本番運用データベースに適しています。 コンピュートをアイドル状態の時にもより長くアクティブな状態に保ちたい場合は、ウィンドウを最大7日間まで延長できます。

ゼロ利益へのスケール

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

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

ゼロへのスケールは、どのコンピュートでもオンまたはオフにできます。 有効にすると、サスペンドをトリガーする非アクティブタイムアウトを設定できます。デフォルト値は24時間で、許容範囲は60秒から7日間です。

デフォルトの24時間タイムアウトはほとんどのデータベースでうまく機能し、長時間のアイドル期間中のコストを削減しつつ、再アクティブ化の頻度を低く抑えます。ワークロードで起動遅延のない継続的な可用性が必要な場合は、そのためにスケールをゼロにオフにします。 開発ブランチの場合、タイムアウト時間を30分など短く設定することで、コストをさらに削減できます。

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

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

開発およびテスト環境

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

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

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

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

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

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

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

重要な考慮事項

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

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

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

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

起動遅延

再アクティベーションまでの短い期間（通常は数百ミリ秒）は、停止後の最初のクエリにおけるユーザーエクスペリエンスに影響を与える可能性があります。即時応答が求められるアプリケーションの場合は、以下の方法があります。

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

本番運用ブランチの動作

プロジェクトを作成すると、デフォルトでスケール・トゥ・ゼロが有効になり、24時間の非アクティブタイムアウトが設定されたproductionブランチが作成されます。ワークロードで継続的な可用性が必要な場合は、タイムアウトを調整したり、スケールをゼロにオフにしたりできます。

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

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

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

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

次のステップ

• ゼロへのスケール設定を構成する : コンピュートのゼロへのスケールを有効、調整、またはオフにする方法を学びます。 「ゼロにスケールする」を参照してください。
• コンピュート メトリクスの表示 : 非アクティブなコンピュート期間とゼロへのスケール動作がメトリクスにどのように反映されるかを確認します。 メトリクスダッシュボードをご覧ください。
• オートスケール : コンピュートがアクティブ期間中にどのようにリソースを調整するかを理解します。 See オートスケール.
• データベースブランチ ：開発およびテスト用に分離されたデータベース環境を作成します。支店を参照してください。