Lakebase Postgresのオートスケーリング

ワークロードがわからないうちにデータベースのインスタンスサイズを選択するのは、古い開発パターンです。このプロセスは一般的に不安定で、特にコンピューティングが贅沢品になりつつある現在では、コンピューティングが非常に無駄に感じられます。

Lakebase Postgresは、オートスケーリングのおかげで、サイズ選定の手間を完全に省くことができます。オートスケーリングの優れた応答性は、インプレースでのVMのサイズ変更と、CPU、メモリ、データベースのワーキングセットを追跡するアルゴリズムによって実現されています。

Lakebase Postgresデータベースの任意のサンプルにおけるオートスケーリングの様子。これがわずか1時間の動きであることに注目してください。

アーキテクチャ上の要件

従来のPostgresは、マシンとそのディスクに紐づいたステートフルなプロセスとして実行されます。マシンが実行と永続的な状態の両方を保持しているため、そのマシンのリプレースやサイズ変更はデータベース操作を伴います。しかし、Lakebase Postgresのアーキテクチャでは、これらの役割が分離されています。

• コンピューティングレイヤーはPostgresを実行し、クエリを処理します。低レイテンシのアクセスのためにRAMとローカルNVMeを使用し、永続的な状態は保持しません。
• ストレージレイヤーは永続性と履歴を保持します。WALはSSD上で動作するセーフキーパーによってレプリケートされ、ページサーバー（こちらもSSD）がページバージョンを再構築し、オブジェクトストレージが長期的な不変レコードを保持します。 （このブログ記事では主にコンピューティングに焦点を当てていますが、ご興味があればストレージ部分に関する詳細な解説記事もご覧ください。）

したがって、コンピューティングノードは、その下にあるデータベースを移動させることなく、起動、停止、移動、またはサイズ変更を行うことができます。これは不可欠な基盤です。

さて、オートスケーリングの実装に関しては、2つのステップがあります。1つ目は、容量をスケールアップまたはスケールダウンするタイミングを決定すること。2つ目は、Postgresを停止せずにそれを実行する方法です。

この2つを順番に説明していきましょう。

パートI：アルゴリズム

3つのオートスケーリングシグナル

サイズ変更のタイミングを推測するため、Lakebase Postgresのオートスケーリングアルゴリズムは3つのシグナルを追跡し、それぞれのシグナルが独自のターゲットコンピューティングサイズを生成します。

1. CPU負荷：cpuGoalCU
2. メモリ使用量：memGoalCU
3. コンピューティングキャッシュのワーキングセットサイズ：lfcGoalCU

最終的なスケーリングターゲットは、これら3つのうち最大のサイズとなり、ユーザーがそのデータベースに対して設定した最小および最大のコンピューティングサイズ（オートスケーリングの制限）に制限されます：

CPU（cpuGoalCU）

CPUは、3つのシグナルの中で最もシンプルです。アルゴリズムはプロセッサの稼働状況を厳密に監視します。

• 5秒ごとに、autoscaler-agentがVMの1分間のCPU平均負荷を読み取ります。
• CPU目標は、その負荷を利用可能なCPU容量の90%以下に維持することを目指します。
• 負荷がそのターゲットを上回ると、cpuGoalCUが増加します。負荷の低下が持続すると、目標値もそれに伴って低下します。

1分間の平均値を使用することで、非常に短い一時的な変動をフィルタリングしつつ、需要の有意な変化に対応できます。5秒のポーリング間隔により、平均値の動きに合わせてシステムがターゲットを更新できます。

しかし、Postgresを適切にオートスケーリングするには、CPUだけでは不十分です。ネットワーク経由でのデータ到着を待っているクエリは、パフォーマンスが低下しているにもかかわらず、CPU使用率が低く表示されることがあります。そのため、アルゴリズムはメモリとキャッシュのプレッシャーも考慮する必要があります。

メモリ（memGoalCU）

メモリの障害モードはCPUとは異なります。需要が一時的に利用可能なCPUを超えた場合、クエリは遅くなりますが、PostgresがVMの搭載量を超えるメモリを割り当てると、カーネルがプロセスを強制終了（ターミネート）する可能性があります。したがって、オートスケーラーはメモリ枯渇に対して、CPUよりもはるかに高速なシグナルを必要とします。

そのため、システムは2つの頻度でメモリを監視します。

• 5秒ごとに、autoscaler-agentがVMから全体的なメモリメトリクスを読み取ります。
• 100ミリ秒ごとに、vm-monitorがPostgresによって使用されているメモリをチェックします。

メモリ目標は、使用率を割り当てられたRAMの75%未満に維持します。このヘッドルーム（余裕）により、システムは新しいメモリ割り当てに対応する余地を確保でき、ゲストOSや他のプロセスのためのメモリも残されます。

また、vm-monitorは提案されたすべてのスケールダウンをチェックします。実行中のプロセスに十分なスペースが残らなくなる場合、メモリを削減することはできません。

少し歴史を振り返ると： このポーリングアプローチは、cgroupの memory.high イベントに基づいていた以前の設計に代わるものです。memory.high を超えると、Linuxがメモリを回収し、cgroup内のプロセスをスロットリングしていました。ポーリングは、Postgresメモリの100ミリ秒単位のビューをシステムに提供しつつ、より予測可能で安定していることが証明されました。

コンピューティングキャッシュ（lfcGoalCU）

3つ目のシグナルは、ワークロードのアクティブデータがPostgresの近くに収まっているかどうかを測定します。大まかな仕組みは以下の通りです。

Lakebase Postgresはストレージとコンピューティングを分離しています。ページがローカルに存在しない場合、コンピューティングはページサーバーにそれを要求し、返されたページは後続の読み取りのためにキャッシュされます。私たちが当初Local File Cache（LFC）と呼んでいたコンピューティングキャッシュは、カーネルページキャッシュに収まるようにサイズ調整されたディスクバックのキャッシュです。これは、Postgresの共有バッファのサイズ変更可能な拡張機能として機能します。コンピューティングが拡張されると、vm-monitorはキャッシュを拡張して、追加されたメモリの一部を使用します。

多くのOLTPワークロードでは、ワーキングセットがローカルメモリに収まると、パフォーマンスが劇的に変化します。これは、CPUのみのオートスケーリングにおける盲点を浮き彫りにします。キャッシュミスが発生するとクエリがネットワーク要求を待つことになり、CPU使用率が低下します。そのため、キャッシュを大きくすればパフォーマンスが向上するまさにその瞬間に、システムはCPUプレッシャーが低いと判断してしまう可能性があります。そこでLakebase Postgresでは、Postgresのワーキングセットを直接推定する3つ目のオートスケーリングシグナルを用意しています。

これはアルゴリズムの中で最も興味深い部分ですので、その推定がどのように機能するかを見てみましょう。

詳しく見る：Postgresのワーキングセットを推定する方法

ワークロードのワーキングセットとは、特定の期間に繰り返しアクセスされるデータベースおよびインデックスページのセットです。オートスケーリングのためにすべてのページを正確にカウントすると、大量のメモリが必要になります。そのため、これを解決する古典的な方法は、少量の固定された状態を使用してセット内のユニークなアイテム数を推定できる確率的カーディナリティ推定器であるHyperLogLogに依存することです。

標準的なHyperLogLogの実装では、Postgresの各ページアクセスに対して以下を行います。

1. ページ識別子をハッシュ化します。
2. ハッシュの最初の数ビットを使用してレジスタを選択します。
3. 残りのビットのリーディングゼロ（先頭のゼロ）をカウントします。
4. この観測値が以前の値を上回る場合、選択されたレジスタを更新します。

これらのレジスタ値の分布により、これまでに観測されたユニークなページ数の推定値が得られます。

しかし、オートスケーリングに単にHyperLogLogを使用することには問題があります。標準的なHyperLogLogは増加する一方だからです。レジスタが一度値を観測すると、どのアイテムがそれを生成したのか、あるいはそのアイテムが最後にいつ見られたのかを特定できません。

そのため、「Postgresが起動して以降、このコンピューティングがアクセスしたユニークなページ数はいくつか？」という問いに答えるのには適しています。しかし、オートスケーリングに必要なのは、「現在実行中のワークロードに属するユニークなページ数はいくつか？」という、より現在に近い答えです。

時間的な境界がないと、古いインポートや分析クエリが推定値に残り続け、その処理が終了した後も長期間にわたってコンピューティングが過剰なサイズのまま維持されてしまいます。そこで、私たちはHyperLogLogレジスタが保存する内容を変更しました。

HyperLogLogへの時間の追加

Lakebase Postgresにおける実際の仕組みは以下の通りです。

ハッシュが観測されたときにビットを設定する代わりに、推定器はその位置に現在のタイムスタンプを保存します。時間 T 以降のカーディナリティを推定するために、T 以降に更新された位置を「設定済み」とし、それより古い位置を「未設定」として扱います。

Lakebase Postgresのオートスケーリングにおける、変更されたHyperLogLog。

これにより、現在終了する任意のウィンドウに対する推定値が生成されます。これには以下が含まれます。

• 過去1分間にアクセスされた一意のページ数
• 過去5分間にアクセスされた一意のページ数
• 過去1時間にアクセスされた一意のページ数

アルゴリズムの話に戻ると、粒度は実際には次のように機能します。20秒ごとに、autoscaler-agentが1分から60分までのウィンドウのワーキングセット推定値を収集します。

しかし、話はこれで終わりではありません。お気づきのように、これは広い時間ウィンドウです。実際にはどのように選択すればよいのでしょうか？

ワーキングセットの時間ウィンドウの選択

問題は、データベースの現在のワーキングセットを説明する普遍的なウィンドウが存在しないことです。短いウィンドウを選択すると、ワークロードの終了時にオートスケーリングエンジンが迅速に反応しますが、バースト間でキャッシュが過剰に破棄されてしまいます。長いウィンドウを選択すると、アルゴリズムはキャッシュを保護しますが、すでに実行されていない処理に対してもメモリが割り当てられたままになります。

アルゴリズムは、ワーキングセットが時間の経過とともにどのように変化するかを観察することで、この問題を解決します。例えば、安定したワークロードの場合、推定ページ数は最初は増加し、その後横ばいになります。ウィンドウを延長すると時間は増えますが、同じワーキングセットに繰り返しアクセスされるため、新しく追加されるページはほとんどありません。

ここで、最近終了した重いワークロードを考えてみましょう。短いウィンドウには現在の軽いワークロードのみが含まれますが、ウィンドウが過去に十分に遡って前のワークロードが含まれるようになると、推定値が急上昇します。アルゴリズムはその急上昇を検索し、それが現在のプラトー（安定状態）の終わりを示します。

要約すると、次のようになります。

実装は5分後に検索を開始します。これにより、短い一時停止中にコンピュートがすぐに縮小し、次のバーストで再び拡張するのを防ぎます。しかし、急激な増加が見つからない場合、アルゴリズムは60分の推定値を使用します。これは、1時間を通じてワーキングセットがアクティブなままである安定したワークロードで期待される結果です。

キャッシュ増加の予測

これには最後にもう1つの要素があります。現在のワーキングセットの測定は、わずかに遅すぎます。例えば、ワークロードが新しいページセットのスキャンを開始したとします。それらのページが読み取られた後にのみコンピュートキャッシュが増加する場合、後続のページ用のスペースを確保するために、初期のページがすでに破棄されている可能性があります。そのため、キャッシュは同じデータの一部を再度取得する必要があります。

そのため、アルゴリズムはワーキングセットの将来の増加も予測します。ある期間から次の期間にかけて推定値がどのように増加するかを調査し、次の制御インターバルで予想されるワーキングセットに対して十分なキャッシュを割り当てます。

キャッシュメトリクスは20秒ごとに取得されるため、予測は1分未満のわずかな時間をカバーするだけです。より長い予測を行えば反応は早くなりますが、一時的なスパイクが増幅され、コンピュートが振動（オシレーション）する原因にもなります。

予測されるサイズは（ついに！）lfcGoalCUになります。そしてアルゴリズムの目標は、コンピュートキャッシュが利用可能なメモリ部分（コンピュートRAMの最大75%）にワーキングセットを収めることです。

パート II：実行中のコンピュートのサイズ変更

おさらいすると、スケーリングのターゲットは次のとおりでした。

これら3つのシグナルが、システムに目指すべきサイズを伝えます。そのサイズを適用することは、Postgresを中断することなく、実行中のVMのCPUとメモリを変更することを意味します。

Lakebase Postgresの各Postgresインスタンスは、Kubernetesクラスター内の独自のVM内で実行されます。VMを使用するのは、強力な分離境界を提供し、従来のコンテナ割り当てとは異なり、実行中のゲストに対してCPUやメモリを追加または削除できるためです。

4つのコンポーネントが連携して、各コンピュートのサイズ変更を調整します。

1. autoscaler-agentは、すべてのKubernetesノードで実行されます。そのノード上のPostgres VMからメトリクスを収集し、ターゲットサイズを計算して、スケーリングを開始します。
2. vm-monitorは、各VMの内部で実行されます。Postgresのメモリを綿密に監視し、ダウンスケール要求を検証して、コンピュートキャッシュのサイズを変更します。
3. カスタマイズされたKubernetesスケジューラは、利用可能なリソースのグローバルビューを維持します。メモリがコミットされる前に、すべてのアップスケールがスケジューラによって承認される必要があります。
4. NeonVMが変更を適用します。これはQEMUとKVMで構築されたカスタムのKubernetesリソースおよびコントローラーであり、実行中のVMからCPUやメモリを追加または削除できます。（免責事項：Lakebase PostgresのアーキテクチャはNeonから始まったため、リソース/コントローラー名はそのまま残っています）。

アップスケーリング

先ほど見たように、3つの目標のいずれかが、VMが現在保持している以上のコンピュートを要求したときにアップスケーリングが発生します。アップスケールは次の手順で行われます。

1. autoscaler-agentが、CPU、メモリ、およびワーキングセットの目標から新しいターゲットを計算します。
2. Kubernetesスケジューラが、メモリをオーバーコミットすることなくノードが要求を満たせるかどうかを確認します。
3. 承認されると、autoscaler-agentがNeonVMリソースを更新します。
4. NeonVMコントローラーが、実行中のVMにCPUとメモリを追加します。
5. vm-monitorがコンピュートキャッシュを拡張し、新しい容量を使用できるようにします。

スケジューラは、割り当てに関する唯一の真実の情報源（Single Source of Truth）です。通常のKubernetesスケジューリングとオートスケーリング要求の両方を認識します。この調整がないと、オートスケーラーが残りのメモリをPostgres VMにコミットしたのとまったく同じ瞬間に、スケジューラがノードに新しいワークロードを配置してしまう可能性があります。

ノードが満杯でその場での拡張が難しい場合、NeonVMはVMを別のノードにライブマイグレーションできます。VMはIPアドレスを維持するため、既存の接続は開いたままになります。Lakebase Postgresのコンピュートには移動すべき永続的なローカル状態がほとんどないため、マイグレーションは主にVMのメモリとランタイム状態の移動になります。

ダウンスケーリング

ダウンスケールでもまったく同じコンポーネントを使用しますが、VM内で追加のチェックが1つ行われます。vm-monitorは、メモリを削除してもPostgresやその他のゲストOSに十分なメモリが残ることを確認します。十分でない場合、ダウンスケールは実行されません。

注意：ダウンスケーリングは、アップスケーリングと同じくらい重要です。一部のオートスケーリングシステムは、容量の追加は迅速ですが、返却は遅いため、スパイクが去った後も長期間にわたってデータベースが過剰なサイズのまま放置されることがあります。Lakebase Postgresは、双方向のスケーリングを同様に扱います。目標は、ワークロードを刻一刻と可能な限り正確に追跡し、不要になった瞬間に容量への支払いを停止することです。

まとめ

Lakebase Postgresは、実行中のワークロードを監視し、それに合わせてリアルタイムでコンピュートのサイズを変更します。これを可能にしているのがlakebaseアーキテクチャです。ストレージが分離され、それ自体で耐久性を持っているため、データを心配することなくコンピュートを自由に移動できます。

その結果、システムは稼働中のデータベース上で、接続を切断することなく双方向にスケーリングします。最も重要なのは、明らかなシグナルだけにとどまらない点です。CPUのみを追跡すると、キャッシュミスで停滞しているワークロードを見落とすため、アルゴリズムはメモリプレッシャーと、時間を考慮したワーキングセットの推定値も追跡します。

最終的なループは、3つのタイムスケールで実行されます。

• 100ミリ秒：vm-monitorがPostgresのメモリをチェックし、急速な割り当てを検出します
• 5秒：autoscaler-agentがCPUと全体的なメモリを読み取ります
• 20秒：autoscaler-agentが1分から60分までのウィンドウにわたるワーキングセットの推定値を評価します

このようにして、本番環境のデータベースは月に32,000回以上サイズを変更することができます。

コンピュートコストが高くなり、競争が激化する中、めったに達しないピーク時の容量に対して支払うという構築パターンは、間もなく通用しなくなる可能性があります。オートスケーリングは、コンピュートの無駄が許されないワークロードに対してPostgresを適合させます。

実行する

エージェントにLakebase Postgresのデプロイを依頼し、そのオートスケーリング機能を試してみましょう。今すぐ始める。

Lakebase Postgresはスタンドアロンのデータベースとして使用できるほか、Unity Catalogによるガバナンス、レイクハウス分析、ノートブック、AIワークフローなど、DatabricksのData + AIプラットフォームの他の機能と統合することも可能です。

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