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

昨年、エージェントは新しい使用パターンでクラウドインフラストラクチャの限界を押し広げてきました。 コントロールプレーン操作のスループット向上：エージェントは、人間よりもはるかに高いレートでデータベース、ストレージ、コンピューティング、その他のインフラストラクチャコンポーネントをプログラムで作成および管理します。Databricks Lakebaseでは、 エージェントは人間よりも4倍多くのデータベースを作成します 。 オンデマンドの需要増加：サーバーレス、 オートスケーリング 、および自動一時停止インフラストラクチャが新しい標準となっています。エージェントがスリープ状態になった場合、プロビジョニングされたインフラストラクチャに料金を支払う意味があるでしょうか？ 容量不足：コンピューティング、GPU、およびクラウドインフラストラクチャの需要は 増加しています 。クラウドには「無限」の容量があるという考えはひび割れを見せています。 これは、プラットフォームビルダーとクラウドプロバイダーの両方にとって課題です。コントロールプレーンは、インフラストラクチャの作成、管理、スケーリングのためのリクエストボリュームの大幅な増加を見ており、信頼性にストレスを与えています。新しいクラウド容量の割り当てが常に成功するとは限りません。同時に、エージェントワークロードは、運用フローの一部として、コアコントロールプレーン操作に対してデータプレーンレベルの信頼性を要求します。過去数か月で、エージェントがデータベースの起動を指数関数的に増加させているのを見てきました。そして今、私たちは毎日数千万のデータベースを起動しています。 その結果生じたクラウドサービス間の障害とインシデントの連鎖は、信頼性ロードマップに影響を与える教訓を私たちに与えてくれました。そして、私たちはlakebaseアーキテクチャと設計をクラウド障害に対してより回復力のあるものにする方法を共有したいと思います。一部の項目はすでに本番環境にあり、その他は進行中です。 高可用性アーキテクチャ 基盤となるのは、コンピューティングとストレージを分離したアーキテクチャであり、高可用性（HA）はシステムのコア設計原則であり、アドオンではありません。 ステートレスPostgresコンピューティング 多くのクラウドPostgresデータベースサービスの設定がモノリシックでステートフルなコンピューティングであるのとは異なり、lakebaseアーキテクチャのPostgresはステートレスです。すべての永続データはリモートストレージサービスに保存されるため、コンピューティングプロセスはローカルディスクに永続的な状態を持ちません。Postgresまたはそれが実行されているハードウェアが失敗した場合、ホットスタンバイにデータを複製したり、通常のPostgresクラッシュリカバリを実行したりすることなく、即座に交換できます。モノリシックセットアップでのホットスタンバイは、データの完全なコピー（無料ではない）を必要としますが、クラッシュリカバリは最後のチェックポイントからのライトアヘッドログを再生する必要があります。これはクラッシュ時の書き込みレートによってスケーリングし、構成によっては数十分かかる場合があります。データベースの内容は、ゾーン冗長ストレージサービスに保存されているため、LakebaseのシングルコンピューティングPostgresインスタンスは、追加のホットスタンバイコンピューティングインスタンスのコストなしで、シングルステートフルPostgresインスタンスと比較して可用性が大幅に向上しています。 最も高いレベルの可用性を必要とするデータベースについては、 高可用性 を構成できます。これは、データベースのために複数のアベイラビリティゾーンにわたる専用コンピューティングをプロビジョニングし、クラウドプロバイダーが障害イベント中（またはその結果）に容量を使い果たした場合でも、データベースが利用可能であることを保証します。これらのコンピューティングは、さらに読み取りをスケーリングするためにも利用できます。 すべてにゾーン冗長ストレージ モノリシックPostgresセットアップは通常、ゾーン冗長性の低いローカルブロックデバイスによってバックアップされます。これにより、物理レプリケーションと複数のアベイラビリティゾーンにわたる高価なホットスタンバイレプリカが必要になります。 Lakebase...