AIエージェントのワークロードがクラウドインフラの限界に挑戦する中、Databricksのレイクベースアーキテクチャは信頼性を確保するために設計されています。エージェントは人間より4倍速くデータベースを作成し、サーバーレスで自動スケーリングするインフラを要求し、コントロールプレーン操作（データベース起動など）を重要なデータプレーン作業として扱います。レイクベースでは現在、毎日数千万のデータベースを起動しています。
レイクベースアーキテクチャは、耐障害性を後付けではなく設計段階から組み込んでいます。ステートレスPostgresコンピュートをゾーン冗長ストレージ上で動作させることで、インスタンスをホットスタンバイやクラッシュリカバリなしで即座に置き換えられます。ホットパスのコントロールプレーン操作を専用サービスに分離し、クラウドプロバイダーへの依存を最小限に抑え、各リージョンを自己完結型のセルに分割しています。
信頼性はテストと測定によって証明され、約束ではありません。すべてのリリースは、プロセス、ノード、アベイラビリティゾーンレベルでの障害注入を含むカオステストを経て、SqlLancerなどのオープンソースツールで検証されます。データベースごとの可用性（フリート平均ではなく）を99.99%の月間目標に対して追跡し、達成状況を公開しています。
過去1年間、エージェントは新たな使用パターンでクラウドインフラの限界を試してきました。コントロールプレーン操作のスループット向上、オンデマンドインフラへの需要増加、容量不足などです。レイクベースアーキテクチャは以下の重要な設計でこれらの課題に取り組みます。
高可用性アーキテクチャ：分離されたコンピュートとストレージアーキテクチャを基盤とし、高可用性はアドオンではなく中核的な設計原則です。ステートレスPostgresコンピュートはすべての永続データをリモートストレージサービスに保存するため、ローカルディスクに永続状態を持ちません。Postgresまたはハードウェアに障害が発生した場合、ホットスタンバイへのデータ複製やクラッシュリカバリなしで即座に置き換えられます。ゾーン冗長ストレージにより、すべてのデータベース（ティアや設定に関わらず）は分散型でゾーン冗長な高可用ストレージにバックアップされます。
コントロールプレーンは新しいデータプレーン：従来のアーキテクチャでは、データプレーンが重要で、コントロールプレーンは管理操作のみを担当していました。しかし、エージェントワークロードでは、データベースを起動するコントロールプレーン部分が実質的にデータプレーンとなります。そのため、コントロールプレーンの重要な部分をデータプレーンコントローラーサービスとして分離し、ホットパス操作（起動/一時停止）のみを処理するようにしています。このサービスはビジネスロジックが少なく、厳格に最小限の外部依存関係を持ち、耐障害性、グレースフルデグラデーション、多層防御を考慮して設計されています。
クリティカルパス依存関係の注意深い検討：エージェントワークロードに対応するには、データベースの作成と再開が高度に信頼できる必要があります。レイクベースでは、クラウドプロバイダーから大きなベアメタルインスタンスのプールを事前割り当てし、バッファを保持してプロビジョニング停止に備えます。独自の垂直スケーリング仮想化レイヤーを構築し、複数のPostgresインスタンスをそれらのインスタンスにスケジュールします。また、クラウドブロックストレージデバイスに依存せず、データを独自のゾーン冗長ストレージに保存し、最終的にS3やAzure Blob Storageなどのオブジェクトストアにバックアップします。
セル化と爆発半径の制限：単一のモノリシックなリージョンデプロイメントではなく、レイクベースはリージョンを1つ以上の同一形状のセルで構成します。セルはKubernetes、コントロールプレーン、コンピュート、ストレージを含む完全で自己完結型のスタックです。これにより、リージョンの拡張と障害の分離が容易になります。例えば、2026年5月8日のAWSアベイラビリティゾーン障害では、1つのセルだけが影響を受け、他の7つのセルは正常に動作し、リージョンの約13%のデータベースのみが影響を受けました。
障害シミュレーションと注入：すべてのレイクベースリリースは、本番投入前に障害注入とカオステストを受けます。実際のクラスターにリリースをデプロイし、エージェントおよび非エージェントのOLTPおよびOLAPワークロードをストレスレベルの並行性で実行しながら、プロセスの強制終了、ノードの停止、ネットワーク障害の注入、ディスク内容の消去、コンポーネントの再起動などを行います。SqlLancerやSqlSmithなどのオープンソースツールを使用して、Postgresの正しい動作を検証します。また、アベイラビリティゾーン全体のネットワーク切断シミュレーションを実施し、ストレージが正常なレプリカに移行する速度、コンピュートが健全なAZにフェイルオーバーする速度、プロキシレイヤーが接続を再ルーティングする速度を観測し、30秒以内のダウンタイムを目標としています。
測定、測定、測定：「測定できなければ科学ではない」という原則に従い、可用性と信頼性を科学的に測定しています。データベースごとの可用性やデータベース起動時間などのサービスレベル指標（SLI）を測定し、目標（SLO）を設定しています。