Lakebaseにおけるゼロダウンタイムパッチ適用 パート1：事前ウォーミング

Lakebaseで最も重要なことの1つは、お客様のデータベースを常に利用可能にすることです。システムはあらゆるレベルで冗長性を備えるように設計されており、ハードウェアまたはソフトウェアの障害が発生した場合でも、データベースのフェイルオーバーとリカバリを自動的に行います。

大規模システムでは、そのような計画外の障害は統計的に予期されるものですが、個々のデータベースにとってはそれほど頻繁には発生しません。個々のデータベースにとっては、計画メンテナンスの方がワークロードの中断を引き起こす傾向があります。結局のところ、通常のデータベースはハードウェア障害が発生するよりも頻繁にパッチが適用されます。

今日、ほぼすべてのデータベースプロバイダーはメンテナンスウィンドウを採用しています。これは、データベースがすべてのアクティブな接続を一時停止し、数秒から数分かかる可能性のあるプロセスで更新および再起動される期間です。Lakebaseでは、最適な時間に更新をスケジュールできますが、それでも発生時には一時的な中断となります。

私たちは、もっとうまくやれると考えています。このブログ記事は、計画メンテナンスの影響を完全に排除するために、lakebaseアーキテクチャを活用する方法に関する一連の記事の最初のものです。私たちの目標は、バージョン更新とセキュリティパッチを完全に気付かれないようにすることです。

この記事では、データベース再起動後のパフォーマンス低下を防ぐテクニックである事前ウォーミングについて説明します。今後の記事では、フェイルオーバープロセス自体の改善と、真のゼロダウンタイムパッチ適用に近づく追加の最適化について説明します。

コールド再起動の問題

PostgreSQLの再起動における課題は、インメモリキャッシュ（特にバッファキャッシュとローカルファイルキャッシュ）が失われることです。データベースは非常に迅速にオンラインに戻ります（P99で1秒）が、ワークロードは再起動後の最初の数分間でスローダウンする可能性があります。これは、ストレージからデータを読み戻し、キャッシュがウォームアップする間にキャッシュヒット率が低くなるためです。これはパフォーマンスの問題のように思えるかもしれませんが、スローダウンが深刻で、データベースがワークロードに対応できずタイムアウトが発生する場合、可用性の問題になる可能性があります。

Postgresにはこれに対処するテクニックが存在します。pg_prewarmはバッファキャッシュをウォームアップするために使用できます。しかし、これはワークロードがすでに影響を受けている再起動の後に実行されます。ストリーミングレプリケーションを使用してレプリカを設定し、フェイルオーバーする前に（プライマリに昇格させる前に）事前ウォーミングを行うことができます。しかし、これには完全なレプリカを作成し、フェイルオーバー前に事前ウォーミングを慎重にオーケストレーションする必要があります。

Lakebaseアーキテクチャでの事前ウォーミング

のlakebaseアーキテクチャでは、ステートレスで弾力性のあるコンピューティングノードと、分離された共有ストレージを組み合わせています。コンピューティングノードはローカルキャッシュを利用して、サーバーレスプロパティを犠牲にすることなく最大のパフォーマンスを提供します。キャッシュは上記のコールドスタートの問題に直面しますが、Lakebaseアーキテクチャではより多くの選択肢があります。

LakebaseのPostgresコンピューティングレプリカはステートレスであるため、オンデマンドで起動およびシャットダウンできます。私たちはこれを利用し、計画された再起動時の自動事前ウォーミングと組み合わせて、ワークロードへのパフォーマンスの影響を最小限に抑えます。仕組みは次のとおりです。

1. LakebaseのPostgresコンピューティングイメージの新しいバージョンが利用可能になります。通知を受け取り、都合の良い時間に再起動をスケジュールできます。
2. スケジュールされた時間の直前に、コントロールプレーンがバックグラウンドで新しいPostgresコンピューティングを起動します。これは表示されず、課金もされません。現在のプライマリのワークロードには影響しません。
3. 現在のプライマリのキャッシュ内のページのリストが新しいコンピューティングに送信されます。新しいコンピューティングは、共有ストレージ層からこれらのページをキャッシュにロードします。これはプライマリに影響しません。
4. 新しいコンピューティングはWAL（ライトアヘッドログ）をサブスクライブして、キャッシュを最新の状態に保ちます。効率化のため、通常のPostgresレプリカとは異なり、キャッシュに影響しないすべてのWALレコードを無視できます。WALは、プライマリコンピューティングに余分な負荷をかけずに、当社のSafekeepersから取得します。
5. 事前ウォーミングが完了すると、古いプライマリを迅速にシャットダウンし、新しいコンピューティングをプライマリに昇格させ、切り替えます。昇格にはOSS Postgresの標準pg_promoteが使用され、データベースサーバーは再起動されません。

前:

後:

Lakebaseアーキテクチャを使用すると、追加料金なしで、追加のレプリカに料金を支払うことなく、これを利用できます。本日現在、読み取り/書き込みエンドポイントのすべての計画された再起動は、お客様が行う必要なしに、このように実行されます。まもなく、読み取り専用エンドポイントにも拡張する予定です。

結果

コールドキャッシュの影響を測定するために、10 GBのpgbench（スケールファクター670）をデータベースで実行し、再起動しました。まず事前ウォーミングを有効にして、次に事前ウォーミングなしで実行しました。最初のチャートは読み取り専用ワークロード（pgbench「select only」）を示し、2番目のチャートは読み取り/書き込みワークロード（pgbench「simple update」）を示しています。

どちらの場合も、事前ウォーミングによりスループットはほぼ瞬時に回復することがわかります。事前ウォーミングがない場合、コールドキャッシュがウォームアップしている間、回復ははるかに遅くなります。読み取り専用ワークロードでは、事前ウォーミングがキャッシュヒット率を向上させ、書き込みよりも読み取りに比例して効果が高いため、差が最も顕著です。

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