クラウド障害に対するレイクベースアーキテクチャの耐障害性

昨年、エージェントは新しい使用パターンでクラウドインフラストラクチャの限界を押し広げてきました。

• コントロールプレーン操作のスループット向上：エージェントは、人間よりもはるかに高いレートでデータベース、ストレージ、コンピューティング、その他のインフラストラクチャコンポーネントをプログラムで作成および管理します。Databricks Lakebaseでは、エージェントは人間よりも4倍多くのデータベースを作成します。
• オンデマンドの需要増加：サーバーレス、オートスケーリング、および自動一時停止インフラストラクチャが新しい標準となっています。エージェントがスリープ状態になった場合、プロビジョニングされたインフラストラクチャに料金を支払う意味があるでしょうか？
• 容量不足：コンピューティング、GPU、およびクラウドインフラストラクチャの需要は増加しています。クラウドには「無限」の容量があるという考えはひび割れを見せています。

これは、プラットフォームビルダーとクラウドプロバイダーの両方にとって課題です。コントロールプレーンは、インフラストラクチャの作成、管理、スケーリングのためのリクエストボリュームの大幅な増加を見ており、信頼性にストレスを与えています。新しいクラウド容量の割り当てが常に成功するとは限りません。同時に、エージェントワークロードは、運用フローの一部として、コアコントロールプレーン操作に対してデータプレーンレベルの信頼性を要求します。過去数か月で、エージェントがデータベースの起動を指数関数的に増加させているのを見てきました。そして今、私たちは毎日数千万のデータベースを起動しています。

その結果生じたクラウドサービス間の障害とインシデントの連鎖は、信頼性ロードマップに影響を与える教訓を私たちに与えてくれました。そして、私たちはlakebaseアーキテクチャと設計をクラウド障害に対してより回復力のあるものにする方法を共有したいと思います。一部の項目はすでに本番環境にあり、その他は進行中です。

高可用性アーキテクチャ

基盤となるのは、コンピューティングとストレージを分離したアーキテクチャであり、高可用性（HA）はシステムのコア設計原則であり、アドオンではありません。

ステートレスPostgresコンピューティング

多くのクラウドPostgresデータベースサービスの設定がモノリシックでステートフルなコンピューティングであるのとは異なり、lakebaseアーキテクチャのPostgresはステートレスです。すべての永続データはリモートストレージサービスに保存されるため、コンピューティングプロセスはローカルディスクに永続的な状態を持ちません。Postgresまたはそれが実行されているハードウェアが失敗した場合、ホットスタンバイにデータを複製したり、通常のPostgresクラッシュリカバリを実行したりすることなく、即座に交換できます。モノリシックセットアップでのホットスタンバイは、データの完全なコピー（無料ではない）を必要としますが、クラッシュリカバリは最後のチェックポイントからのライトアヘッドログを再生する必要があります。これはクラッシュ時の書き込みレートによってスケーリングし、構成によっては数十分かかる場合があります。データベースの内容は、ゾーン冗長ストレージサービスに保存されているため、LakebaseのシングルコンピューティングPostgresインスタンスは、追加のホットスタンバイコンピューティングインスタンスのコストなしで、シングルステートフルPostgresインスタンスと比較して可用性が大幅に向上しています。

最も高いレベルの可用性を必要とするデータベースについては、高可用性を構成できます。これは、データベースのために複数のアベイラビリティゾーンにわたる専用コンピューティングをプロビジョニングし、クラウドプロバイダーが障害イベント中（またはその結果）に容量を使い果たした場合でも、データベースが利用可能であることを保証します。これらのコンピューティングは、さらに読み取りをスケーリングするためにも利用できます。

すべてにゾーン冗長ストレージ

モノリシックPostgresセットアップは通常、ゾーン冗長性の低いローカルブロックデバイスによってバックアップされます。これにより、物理レプリケーションと複数のアベイラビリティゾーンにわたる高価なホットスタンバイレプリカが必要になります。LakebaseおよびNeonでは、すべてのデータベースは、ティアと構成に関係なく、分散型でゾーン冗長で高可用性のあるストレージによってバックアップされています。データは、非常に耐久性の高いゾーン冗長オブジェクトストレージに保存され、パフォーマンスは、追加費用なしで、複数のアベイラビリティゾーンにわたるNVMe SSDキャッシュによって加速されます。

コントロールプレーンは新しいデータプレーンです

モノリシックなクラウドデータベースサービスアーキテクチャでは、データプレーンはサービスの重要な部分です。これは99.99%以上の可用性と静的安定性のために設計されています。コントロールプレーンは管理操作に「のみ」重要です。エージェントおよびオンデマンドワークロードでは、データベースを起動するコントロールプレーンの部分は、事実上データプレーンです。これは私たちのアーキテクチャの考え方を変えました。現在、私たちのコントロールプレーンは、データベースの起動から請求まで、すべてを処理しています。前者の方が明らかに重要です。バックグラウンドメンテナンス操作がオンデマンドデータベースの起動をリソース不足にした障害がありましたが、それは明らかに問題ありません。

現在、コントロールプレーンの重要な部分を、ホットパス操作（起動/一時停止）のみを処理するデータプレーンコントローラーサービスに分離するために懸命に取り組んでいます。このサービスは、ビジネスロジックが少なく、厳格で最小限の外部依存関係（次のセクションを参照）を持ち、回復力、正常な低下、および防御の深さを念頭に置いてゼロから設計されています。

コントロールプレーンがデータベーストラフィックの中心であることを示すために、コンピューティングセッションのライフタイム（受信接続による自動再開から非アクティブによるシャットダウンまでの時間）を分析できます。Neonでは、自動一時停止データベースのコンピューティングセッションの90%は10分未満です。

クラウドプロバイダーのコントロールプレーンを含む、クリティカルパスの依存関係を慎重に検討してください

エージェントワークロードを提供するには、データベースの作成と再開が高信頼性である必要があります。信頼性は、依存関係チェーンとフローに関与する機械の量と強く相関しています。クラウドプロバイダーのVMでPostgresを使用する従来のセットアップでは、これはデータプレーンをはるかに超えています。

• VMをプロビジョニングするためのクラウドプロバイダーのコンピューティングコントロールプレーン
• 利用可能なVM容量（クラウドプロバイダーが誰がそれを得るかのポリシーを制御する場所）
• ローカルストレージをプロビジョニングするためのクラウドプロバイダーのブロックストアコントロールプレーン
• 新しいVMにIPを割り当て、ファイアウォールとネットワークルートを構成するためのクラウドプロバイダーのネットワーキングコントロールプレーン
• Kubernetes（K8s）を使用する場合 - K8sシステムサービスへの追加の依存関係。

Lakebaseでは、クリティカルなデータベースフローに関与するコントロールプレーンの機械の量を劇的に削減するアプローチを採用しています。

• クラウドプロバイダーから大きな（多くの場合ベアメタル）インスタンスのプールを割り当てます。クラウドプロバイダーのプロビジョニング障害を維持するためのバッファを保持します。
• これらのクラウドインスタンスに複数のPostgresインスタンスをスケジュールする、独自の垂直オートスケーリング仮想化レイヤーを構築しました。
• クラウドブロックストアデバイスには依存せず、代わりにS3やAzure Blobストレージなどのオブジェクトストアに最終的にバックアップされる、独自のゾーン冗長ストレージにデータを保存します。

Databricksの他の多くのサービスも同様の信頼性の課題に直面しています。ここでLakebaseはDatabricksの一部であることから恩恵を受けています。Databricksは、3つの主要クラウドすべての製品の信頼性を向上させるための共通プラットフォームの構築手段を持ち、そこに多額の投資を行っています。

区画化して爆発半径を封じ込める

単一のモノリシックなリージョンデプロイメントを実行するのではなく、Lakebase は 1 つ以上の同一形状のセルからリージョンを構成します。セルとは、Kubernetes、コントロールプレーン、コンピューティング、ストレージといった Neon および Lakebase スタックの、完全で自己完結型のスライスです。

これは 2 つの方法で役立ちます。

• スケーリング: リージョンを成長させるには、別のセルを追加します。既存のセルが Kubernetes とコントロールプレーンのスケーラビリティの限界に近づくと、新しいプロジェクトの作成は新しくプロビジョニングされたセルにルーティングされます。需要が増加するにつれて、セルは迅速に起動されます。
• 影響範囲の封じ込め: 徹底的なテストと組み込みの保護策があっても、本番環境では問題が発生します。Kubernetes コントロールプレーン/システムサービスのトラブル、コードや設定の回帰、DoS 状況などです。セルの境界は障害を隔離し、状況が広がるのを防ぎ、リージョンの他のセルが通常どおりトラフィックを提供できるようにします。

これらを組み合わせることで、プラットフォームは単一障害の影響範囲を制限しながら、リージョンを弾力的にスケーリングできます。2026 年 5 月 8 日のインシデントで AWS が us-east-1 のアベイラビリティゾーンで問題を抱えていた際、セルの 1 つで正常なノードへのフェイルオーバーに問題が発生しました。影響はそのセルに限定されました。リージョンの他の 7 つのセルは正常にフェイルオーバーしたため、インシデントはリージョンのデータベースの約 13% にのみ影響しました。この場合、セルベースのアーキテクチャにより、影響は約 10 分の 1 に削減されました。

障害シミュレーションと注入

冗長アーキテクチャと原則は、実際に機能しない限り、あまり価値がありません。あらゆる可能な障害モードを考え出すことができますが、マーフィーの法則 は健在であり、複雑なシステムは常に驚くべき方法を見つけます。すべての Lakebase リリースは、本番環境に移行する前に、障害注入とカオス テストを経ます。リリースを実際のクラスターにデプロイし、エージェント型と非エージェント型の OLTP および OLAP ワークロードの混合をストレスレベルの同時実行性で実行し、その後、基盤となるものを破壊し始めます。プロセスを停止し、ノードをシャットダウンし、ネットワーク障害を注入し、ディスクの内容を消去し、コンポーネントをループで再起動します。これらすべてをワークロードが実行され続けている間に行います。コードにはフェイルポイントを多用し、最悪のタイミングでのクラッシュなど、再現が困難なエラーを注入します。これは、単一のプロセスをターゲットにしたり、セル全体にわたるクラスター規模の障害を調整したりできる内部障害注入フレームワークによって駆動されます。

私たちの合格基準は、「テストでエラーが発生しなかった」よりも厳格です。Postgres の正しい動作を検証するために、SqlLancer や SqlSmith などのオープンソースツールや、同様の内部ツールを使用しています。障害注入を実行している間、内部データの一貫性、コミットされたトランザクションが失われていないこと、およびすべてのコンポーネントが独自の判断で一貫した状態に回復することを検証します。

現在、コンポーネントレベルのカオスから、AZ 全体のダウンシミュレーションへとレベルを上げています。ワークロードが実行されている実際のクラスターで、アベイラビリティゾーンのネットワークをクラスターの他の部分からプログラム的に切断し、システムがどのように反応するかを観察します。ストレージが生存レプリカにどれだけ早くシフトするか、コンピューティングが正常な AZ にどれだけ速くフェイルオーバーするか、プロキシレイヤーが接続をどのようにリダイレクトするか、そして個々のデータベースがどれくらいの期間ダウンタイムを経験するかです。私たちの目標は、30 秒を超えてワークロードがダウンしないことです。

測定、測定、測定

ケルビン卿は、「測定できないものは科学ではない」と言いました。私たちはこれを体現しており、可用性と信頼性の測定を科学にしています。https://neonstatus.com/ で表示されるユーザー可視のステータスは、ハイレベルなビューです。内部的には、サービスレベルインジケーター (SLI) を測定し、すべてのシステムコンポーネントと主要な操作、特にユーザーに表示される操作に対してターゲット (SLO) を設定します。たとえば、次のようなものを測定します。

• データベースの可用性: 各個々のデータベースが利用可能な時間の割合。個々の顧客は、自分のデータベースがダウンしていた場合、フリート全体が優れた可用性を持っていたとしても気にしないため、フリート全体の集計可用性のみを測定するわけではありません。
• データベースの起動時間: 停止中のデータベースが接続時に利用可能になる速さ、または新しいデータベースが起動する速さ。
• データベースの切り替え/フェイルオーバー: 頻度とレイテンシ。可能な限り少なく、発生した場合は可能な限り迅速に。
• ストレージ: Postgres からストレージへのページ読み取りと永続書き込みの可用性とレイテンシ。これらは、ワークロードが必要なものを取得しているかどうかを示します。
• コントロールプレーン API: ブランチングなどの重要な操作の成功率とレイテンシ。

私たちの目標は、毎月 99.99% を超える可用性をすべてのデータベースで達成することです。この目標にどれだけ近づいているかを達成率で測定します。目標を達成したフリートのデータベースの割合です。以下は、2026 年の月次アクティブデータベースの Neon の可用性達成率です。

運用システムにおいて、クラス最高の信頼性と可用性は最も重要です。私たちは、データベースサービスに対するお客様の信頼を築くために懸命に取り組んでいます。

チーム

上記の信頼性に関する取り組みは、リレーショナルデータベースの構築と運用にキャリアを費やしてきた人々によって推進されています。その一部を紹介します。

• Jasraj Dange - Lakebase のエンジニアリングリーダー。以前は Azure SQL Database のパフォーマンスとスケーラビリティに関する作業を主導し、Azure SQL Database をアプリケーション向けの堅牢なプラットフォームにしました。
• Hans Norheim - Lakebase の可用性と信頼性に注力。Microsoft で SQL Server と Azure SQL Database に 13 年間勤務し、SQL Server をダウンタイムなしで更新できるホットパッチ技術や、Azure SQL Database を 99.995% のアップタイム SLA に維持するアップグレードオーケストレーションに携わりました。
• Stas Kelvich - Neon の共同設立者であり、現在は Lakebase に取り組んでいます。Neon 以前は、Postgres Professional で 5 年間 Postgres の内部構造に取り組みました。これには、クォーラムコミットによる耐障害性のあるマルチマスターレプリケーション、緩やかに同期されたクロックを使用したクロスノードスナップショット分離、2 フェーズコミットと論理レプリケーションの改善が含まれます。
• John Spray - Lakebase ストレージをリード。以前は、シャーディングなどの主要なスケール改善を推進するストレージとコンピューティングをリードしていました。それ以前は、Redpanda、Red Hat (Ceph)、Intel で分散ストレージとシステムに取り組んでいました。

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