によって Benjamin Nwokeleme, フィラス・ファラー 、 Jen Darrouzet による投稿
Lakebaseは、現代のアプリケーション開発における運用の実態に合わせて構築された、フルマネージドなPostgresデータベースです。Postgresエンジンを提供する市場の他のデータベースベンダーと一線を画すのは、その基盤となるアーキテクチャ、サーバーレスコンピュートレイヤーによって分離されたストレージとコンピュート、そしてLakehouseおよびデータインテリジェンスプラットフォームとの緊密な統合です。このアーキテクチャといくつかのメリットの詳細については、こちらでお読みいただけます。しかし、見落とされがちなメリットとして、このアーキテクチャによってLakebaseのコスト効率が非常に高くなるという点があります。このブログでは、そのコスト効率がどこから生まれるのかを解説し、それを最大限に活用するための実践的なヒントを紹介します。
データベースブランチを使用すると、開発者は開発、テスト、または実験目的で、本番データを含む隔離された環境を作成できます。環境ごとにデータベースの個別の物理コピーを作成する必要があるアプローチとは異なり、Lakebaseのブランチは同じ基盤ストレージを共有し、ブランチが親から分岐した時点からの変更のみを追跡します。これにより、短期間しか使用しない開発・テスト環境においてブランチ機能は非常にコスト効率が高くなります。チームは、データベースの完全に独立したコピーをプロビジョニングして維持することなく、本番に近いデータを使用して作業できます。
オートスケーリングは、アクティビティの変動レベルに応じて、Lakebaseインスタンスのコンピュートリソースを動的に変更します。インスタンスがスケーリングする最小値と最大値の範囲を制御できます。この機能のコストメリットは明らかです。ピーク時の使用量に合わせてコンピュート容量を静的にプロビジョニングする代わりに、ワークロードの需要に合わせてスケーリングできます。
最大コンピュートサイズを設定することで、コンピュートコストの上限を抑えて予期しない支出を防ぎ、コストを予測可能にすることができます。使用率が低い時間帯はコンピュートがスケールダウンし、コストが削減されます。ゼロへのスケール（scale to zero）と組み合わせると、一定時間アクティビティがない場合にコンピュートが完全にサスペンドされ 、コンピュートコストがゼロになります。ゼロへのスケール状態からのコンピュートの再開は、数百ミリ秒で完了します。これは、開発ワークフロー、本番以外のアプリ、2桁ミリ秒台のレイテンシを必要としない本番アプリなど、レイテンシに対して極端に敏感ではないシナリオにおいて特に魅力的です。
ゼロへのスケールがオフの場合、Lakebaseにはベースライン容量が25%割引になる常時稼働価格設定（always on pricing）が適用されます。このコスト削減は、HA構成など、ゼロにスケールできないコンピュートにも適用されます。
Lakebaseのストレージとコンピュートの分離は、リードレプリカと高可用性（HA）のコスト効率も向上させます。リードレプリカは、プライマリと同じ基盤ストレージレイヤーから読み取る独立したコンピュートインスタンスであるため、読み取り容量をスケーリングするためにデータベースの別のコピーを作成してその料金を支払う必要はありません。同様に、高可用性は、既存の高可用性ストレージレイヤーを引き続き使用しながら、アベイラビリティゾーン全体に冗長コンピュートを追加します。つまり、ストレージのフットプリントを増やすことなく、読み取りスケールとコンピュートの冗長性を追加できます。
Lakebaseと広範なDatabricks Intelligence Platformとの緊密な統合により、2つの環境間でのマ ネージド同期が可能になります。同期テーブル（Synced Tables）は、Unity CatalogのデータをLakebaseデータベースに表示し、アプリケーションや機能提供のユースケースにおける低レイテンシのトランザクション読み取りをサポートします。
お客様がよく犯す誤りは、アプリケーションがはるかに小さなアクティブなサブセットのみをクエリするにもかかわらず、大規模なDeltaテーブルをLakebaseにプッシュしてしまうことです。これにより、Lakebaseのストレージが肥大化し、同期コストが増加し、シナリオによってはパフォーマンスの問題につながる可能性さえあります。解決策は簡単です。アプリケーションに必要なワーキングセットのみを同期することです。マテリアライズドビュー（MV）を使用して、アプリが必要とする正確なデータ（例：直近60日間のローリングウィンドウなど）を定義し、それだけを同期します。Lakebaseの同期パイプラインは、MVの自動変更データフィード（automatic change data feed）を使用して、読み取り時に行レベルの変更を計算できます。つまり、ローリングウィンドウから行が古くなって削除されるなど、MVへの変更をLakebaseに段階的に伝播できます。その結果、完全な履歴はDeltaに残したまま、最新で低レイテンシのアクティブなサブセットをLakebaseに保持できます。これを、以下で説明する要件を満たす最も無駄のない同期モードと組み合わせることで、はるかにコスト効率の高いリバースETLパターンを実現できます。
同期テーブル（Synced Tables）は、内部的にはマネージドなサーバーレスSpark宣言型パイプライン（SDP）であり、同期の実行期間中に動作します。その結果、同期コストは、移動されるデータ量やLakebaseインスタンスのサイズ／キャパシティユニット（CU）などの要因によって決まります。
LakehouseからLakebaseにデータを移動するための同期モードには3つあり、データに実際に求められる最新性にモードを合わせることが重要です。適切なモードを選択することで、コストを抑えながらレイテンシ要件を満たすことができます。
| モード | 説明 | 最適なユースケース |
|---|---|---|
| Snapshot | すべてのデータのコピー | ソースの変更が1サイクルあたり10%以上の行に及ぶ場合。これらのシナリオでは、Triggeredよりも大幅にコスト効率が高くなります。 |
| Triggered | オンデマンドまたは一定の間隔で実行される増分更新 | ソース行が既知の周期で変更される場合。更新のたびに、挿入、更新、削除が伝播されます。 |
| Continuous | 数秒のレイテンシを伴うリアルタイムストリーミング | 変更をほぼリアルタイムでLakebaseに反映させる必要がある場合。これは、最も高いコストで最も低い遅延を提供します。 |
Snapshotは、更新頻度が低いテーブルや変動の激しいテーブルに対して最もコスト効率の高いオプションですが、Continuousはパイプラインが継続的に実行され、処理する変更がない場合でもコンピュートを消費するため、最も高価になる可能性があります。同期の間にソースデータの10%以上が変更される場合は、最大10倍効率的になるため、Snapshotモードが推奨されます。増分ワークロードの場合、Triggeredモードはコストとレイテンシの理想的なバランスを提供します。Triggeredモードをテーブル更新トリガー（table-update trigger）と組み合わせることで、ソースデータが変更されたときにのみ実行されるようにし、予算内でほぼ継続的な最新性を実現できます。一般的に、実行の間隔を長くしすぎないようにしてください。大量の変更バックログが発生すると、その後の同期が遅くなり、コストが高くなる可能性があります。
もう1つの便利なコスト最適化は、複数のテーブルを単一の同期パイプラインにビンパック（グループ化）する機能です。ユースケースで許可されている場合、同じパイプラインで複数のDeltaテーブルからLakebaseへの変更を同期できるため、それらのテーブルで同じ基盤コンピュートを共有できます。これは、パイプラインが常に実行されているContinuous同期において、テーブルごとに個別の継続実行パイプラインの料金を支払う必要がなくなるため、特に価値があります。
Lakebaseプロジェクトが作成されると、本番ブランチとプライマリ読み書きコンピュートが自動的に付属します。デフォルトでは、そのコンピュートは8〜16 CUの間でオートスケー リングするように構成されており、24時間アクティビティがない場合にゼロへのスケールが有効になります。これらのデフォルト設定はワークロードに対して完全に合理的かもしれませんが、アプリケーションに必要なコンピュートが少ない場合、変更しないままにしておくと、必要以上の容量に対して料金を支払うことになる可能性があります。
プロジェクトを作成した後にサイズ変更を思い出すのではなく、プログラムでプロジェクトをプロビジョニングするときに初期コンピュート範囲を設定できます。たとえば、Databricks SDKを使用する場合：
宣言型自動化バンドル（DABs）を使用してLakebaseを宣言的に管理する場合、プロビジョニングするエンドポイントのコンピュート範囲を同様に定義できます：
サイジングにおいて最も重要な要素は、ディスク上のデータベースのフルサイズではなく、アプリケーションが頻繁にアクセスするデータとインデックスであるワーキングセットです。20 GBのホットワーキングセットを持つ2500 GBのデータベースは、2500 GBのRAMを必要としません。その20 GBに加えて、ある程度の余裕（ヘッドルーム）をキャッシュに保持できるだけのメモリがあれば十分です。これは、コンピュートがメモリをどのように使用するかにかかわるため重要です。RAMはコンピュ ートのサイズに応じて線形にスケールし、コンピュートのRAMの最大75%がコンピュートキャッシュとして利用可能です。ワーキングセットがそのキャッシュに収まっている場合、読み取りの大部分はメモリから処理されるため、高速に維持され、レイテンシも安定します。収まらない場合、Postgresはキャッシュミスしたページをストレージから取得する必要があり、これはメモリヒットよりもはるかに遅く、アプリケーションで体感できるようなレイテンシの変動を引き起こします。したがって、サイジングとは、主に他の操作のための余裕を残しつつ、キャッシュがワーキングセットを上回るコンピュートを選択する作業になります。ただし、コンピュートのサイズに応じてスケールするのはメモリだけではありません。クエリの複雑さ、同時実行性、レイテンシの目標も考慮してください。同時実行性が高いワークロードやレイテンシに敏感なワークロードは、同じデータサイズであっても、使用頻度の低い社内ツールよりも多くの余裕を必要とするためです。
データベースへの接続にも特に注意を払う必要があります。max_connections、すなわち同時Postgres接続のハード上限もコンピュートのサイズによって決定され、自動スケールするコンピュートの場合は特定のルールに従います。制限は、最大CUと最小CUの8倍のいずれか小さい方に設定されます。そのため、最大値を上げても、接続数は最小値の8倍までしか増えず、そのポイントを超えると、最小値が小さいことがボトルネックとなり、最大値を大きくしても効果が制限されます。大量の接続を開くアプリケーションは、この上限に達し、エラー を伴って新しい接続を拒否し始める可能性があります。接続数が実際に制約となっている場合は、それを最小CUに考慮し、Lakebaseの前に接続プーラーを配置してください。プーラーを使用すると、多くのクライアント接続でPostgres接続のプールを共有でき、最大10,000の同時クライアント接続をサポートできます。プーリングは通常、多くの接続を開くアプリにとって適切な解決策であり、接続上限を上げるためだけにコンピュートサイズを大きくするよりも安価です。
これらを推測する必要はありません。Lakebaseメトリクスダッシュボードは、5分、15分、1時間のウィンドウにおけるワーキングセットのサイズをレポートし、利用可能なコンピュートキャッシュと並べて直接表示するため、ホットデータが収まっているかどうかを一目で確認できます。キャッシュヒット率、CPU、RAM、接続の使用率と合わせて確認することで、初期サイジングを検証し、スケールアップまたはスケールダウンの調整を行うことができます。アクセスパターンが安定しているワークロードの場合、1時間のワーキングセットと利用可能なコンピュートキャッシュを比較することは、特に有用なシグナルとなります。自動スケールは、最小CUでワーキングセットがすでにメモリに収まっている場合に最大のメリットをもたらします。そうでない場合、コンピュートがスケールアップするたびにコールドキャッシュのペナルティが発生するためです。これらのメトリクスを使用して、ワーキングセットを保持する最小値と、ピー クを吸収する最大値を設定してください。
サイズ不足が完全に致命的な障害として現れることは稀です。多くの場合、誤診しやすい以下のような症状として現れます。
ポイントインタイムリカバリ（PITR）は、2〜30日の設定可能なリカバリウィンドウ内の任意の時点にデータベースを復元するために必要な履歴を継続的に保持します。一方、スナップショットは、ルートブランチの特定の時点の個別のキャプチャであり、手動で作成することも、日次、週次、または月次の自動スケジュールで作成することもできます。
Lakebaseはその期間全体の変更履歴を保持する必要があるため、PITRストレージは書き込みアクティビティとリカバリウィンドウの長さの両方に比例して増加します。書き込み負荷の高いアプリケーションでは、PITRウィンドウが長いとストレージ消費量が大幅に増加する可能性があります。コストを意識したアプローチとしては、インシデント復旧の要件を満たすPITRウィンドウを選択し、より長期的な復旧ポイントが必要な場合はスケジュールされたスナップショットで補完することです。
幸いなことに、どちらも通常のLakebaseブランチストレージよりも低い料金に設定されています。スナップショットストレージ（$0.090/GB-月）は通常のブランチストレージよりも約74%安価であり、PITRストレージ（$0.200/GB-月）は約42%安価です。スケジュールされたスナップショットは、特に ストレージ効率に優れています。スケジュールの最初のスナップショットはフルスナップショットとして保存されますが、それ以降のスナップショットは増分変更に対してのみ課金されます。
リカバリウィンドウ内の任意のタイミングで発生する可能性のある、誤った削除や不正な書き込みなどの予期しないインシデントから復旧するには、PITRを使用します。計画的な復旧ポイントにはスナップショットを使用します。たとえば、リスクの高い移行や一括更新の前に手動でスナップショットを取得し、日常的かつ長期的な保護にはスケジュールされたスナップショットを使用します。
最終的には、実際の復旧要件に合わせて復旧構成を調整してください。必要以上の履歴や復旧ポイントを保持すると、有意義な付加価値を得られないままストレージコストが増加する可能性があります。
前述のように、Lakebaseのコストは、データベースコンピュート、データベースストレージ、そしてSynced Tablesを使用している場合は、レイクハウスからLakebaseにデータを同期するために使用されるサーバーレスパイプラインコンピュートの3つの領域に分類されます。
コンピュートは、時間経過に伴うCUの使用量に基づいて計測されます。自動スケールを使用すると、データベースが設定された範囲内でスケールするにつれて消費されるコンピュート容量に従って使用量が変動します。
ストレージには、データベースブランチストレージ、ポイントインタイムリカバリ（PITR）履歴、およびスナップショットストレージが含まれます。これらは、基盤となるスト レージ使用量に基づいて個別に計測されます。
Synced Tablesは、管理されたパイプラインを使用してUnity CatalogからLakebaseにデータを移動します。同期に使用されるパイプラインコンピュートは、Lakebaseデータベースコンピュートとは別に請求されます。
Lakebaseのコンピュートおよびストレージの使用状況は、system.billing.usageで確認できます。ストレージの使用状況は、product_features.lakebase.storage_typeを使用してさらに詳細に分類できます。
BRANCH_DATA_STORAGE: 有効期限のないデータベースブランチのストレージBRANCH_CHANGE_STORAGE: 有効期限のあるブランチに保存されている変更データBRANCH_HISTORY_STORAGE: PITR用に保持されている履歴以下のクエリは、usageをsystem.billing.list_pricesに結合して、実効定価での1日のコストを見積もります。
Lakebaseは、課金システムテーブルで個別のコンピュートおよびストレージSKUを公開しており、ストレージタイプフィールドによって上記のような詳細な内訳が提供されます。
プロジェクトUIDは、Lakebase UIの [プロジェクト] > [設定] > [UID] で確認できます。プログラムで取得す る場合、プロジェクト名がわかっていれば、プロジェクトをリストしてstatus.display_nameで一致させることで、そのUIDを取得できます。
同期テーブルパイプラインの使用状況は、system.billing.usageからクエリすることもできます。基になるパイプラインIDでフィルタリングし、system.billing.list_pricesに結合することで、パイプラインの1日のコストを見積もることができます。
これらのクエリは、使用期間の有効な定価を使用してコストを見積もります。顧客固有の契約割引は反映されません。
パイプラインIDを確認するには、UIで同期テーブルを開き、パイプラインIDをコピーします。プログラムで取得する場合は、同期テーブルを取得してstatus.pipeline_idを読み取ります。
Lakebaseは、共有ストレージやブランチ作成から、自動スケーリングやサーバーレスコンピュートに至るまで、アーキテクチャの段階からコスト効率が高くなるように設計されています。これらの組み込みの効率性と、サイジング、同期戦略、リカバリに関する適切な構成を組み合わせることで、アプリケーションに必要なパフォーマンス、可用性、開発者エクスペリエンスを維持しながら、コストを予測可能な状態に保つことができます。
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。