クラウドアプリケーションの復旧を目指すDreeze、3,300万ドルのシード資金調達でステルスを脱却

Dreezeは3,300万ドルのシード資金を調達し、ステルス状態を脱した。同社が取り組むのは、クラウドコンピューティングで最も厄介な障害の一つ、つまりデータは復元できても、そのデータに依存する業務アプリケーションまでは復旧できないという問題だ。

今回の資金調達はNorwestとBessemer Venture Partnersが主導し、Claltechも参加した。資金調達の発表に合わせ、テルアビブに本社を置く同社は、完全なクラウドアプリケーションを再び稼働させるために必要なリソースの把握、保護、再構築、テストを行う「Application Revival」プラットフォームを立ち上げる。

Dreezeは2025年、ZertoとKashyaでの経験を持つバックアップ・復旧業界のベテラン、Ziv Kedem、Oded Kedem、Avi Raichelによって設立された。同社によると、イスラエルと米国に計70人の従業員を擁しており、調達した資金は製品開発の加速、営業・マーケティングの拡大、より多くの企業顧客の獲得に充てる。

データを復元してもアプリケーションがオフラインのままになる場合

Dreezeが取り組む課題は、バックアップからの復元に成功しても、サービスが機能する状態には至らない、その間にある。クラウドアプリケーションは、インフラ、設定情報、ID情報、シークレット、暗号鍵、ほかのリソースとの接続に依存している場合がある。データベースを復元しても、システム全体の一部に対処したにすぎない。

周辺のコンポーネントが利用できない場合や、誤った順序で復元された場合、ITチームは依存関係を手作業で再構築しなければならないことがある。Dreezeは、この作業を「復旧時の混乱」と呼ぶ。データは戻っているのに、アプリケーションは依然として使えない状態を指す。

Dreezeの共同創業者兼CEOであるZiv Kedem氏は発表の中で、「企業はデータのバックアップを何年もかけて改善してきました。しかし、データが戻ったからといって、事業まで復旧したことにはなりません」と述べた。

この違いによって、復旧の目標も変わる。企業にとって重要なのは、従業員や顧客が再び利用できるサービスの状態に戻すことだ。ストレージボリュームの復元は重要な節目だが、それだけでは認証が機能すること、必要なリソースが接続されていること、アプリケーションが通常のタスクを完了できることは確認できない。

アプリケーション復旧を実現する4つの段階

Dreezeのプラットフォームは、検出と保護に加え、復旧の実行とテストを組み合わせた4つの機能を中心に構成されている。

把握：障害発生前に依存関係をマッピング

同社によると、自律型の依存関係マッピング機能は、リソースとそれらが支えるアプリケーションを関連付け、稼働中の環境に基づいて復旧計画を作成する。目的は、古くなったランブックに復旧チームが頼らざるを得ない状態を避け、アプリケーションの変更に合わせて計画を最新の状態に保つことだ。

これが同社のアプローチの基盤となる。自動化された復旧手順の完全性は、復旧対象をどこまで把握できているかに左右される。障害が起きる前に依存関係を特定しておけば、その作業をインシデント発生時に行わずに済む。

保護：アプリケーションを支えるリソースもバックアップ

Dreezeによると、保管庫型バックアップでは、データとともに設定情報、鍵、その他のアプリケーション依存関係も保護する。発表では、変更不能でエアギャップ化された保管庫と、リージョン間の任意のレプリケーションについて説明している。

オーケストレーション：依存関係の順序に沿って再構築

Dreezeによると、プラットフォームの「Revival Automation」機能は復旧計画を実行し、依存関係の順序に沿ってデータ、インフラ、設定、ID情報、接続を再構築する。

オーケストレーションの価値は、各コンポーネント間の引き継ぎを調整できる点にある。たとえば、必要なリソースが利用可能になる前にサービスを復元すると、チームは一部しか再構築されていない環境のトラブルシューティングに追われることがある。依存関係を考慮した計画によって、こうした手作業での順序調整を減らすことを目指す。

検証：復旧計画全体をテスト

Dreezeは、検証機能について、稼働するアプリケーションを再構築する自動化されたエンドツーエンドのテストだと説明している。同社によると、これらのテストは本番環境に影響を与えず、終了後の手作業による後片付けも必要ない。

テストは、製品の商業的な価値を訴えるうえで重要な要素となっている。文書化された計画は何が起きるはずかを示す一方、リハーサルが成功すれば、テスト環境で実際に何が起きるかを裏付ける証拠が得られる。発表では、独立したベンチマーク、復旧時間の測定値、包括的なサポート対象一覧は明らかにされていない。

AWSで提供開始、Azureは今後対応予定

Dreezeによると、同社のAWS向けサービスは一般提供を開始している。Microsoft Azure向け製品は早期アクセス段階にあり、一般提供は2027年初頭を予定している。両方のクラウドへの導入を計画する企業にとって、この違いは重要だ。発表では、それぞれ提供段階が異なることが示されている。

Coravantの創業者兼CEOであるJeremy Miller氏は、顧客が懸念しているのは、依存関係を正しい順序で含めてアプリケーション全体を復旧することだと、発表資料の中で述べた。これはDreezeが解消を目指す運用上のギャップである。障害によって不足している要素が明らかになる前に、復旧までの全工程を整えておくことだ。

今回の資金調達が重要な理由

Dreezeが参入する市場では、復旧にあたって保護対象データの量だけでなく、ほかの要素も考慮する必要がある。アプリケーションが利用するサービス、権限、インフラへの依存関係が増えるにつれ、復旧はストレージの問題であると同時に、調整の問題にもなっていく。

AIの登場により、企業が復旧に向けた準備を明確にしておく必要性がさらに高まっている。Unite.AIが取り上げたAIエージェントにおけるバックアップ認識に関する記事では、復元に向けた十分な準備がないまま自動化システムが環境を変更するリスクを検証している。Dreezeの発表が扱っているのは、障害発生後にアプリケーションを再構築するという、より広範な運用上の課題であり、このプラットフォームがエージェントによる危険な操作を防ぐことを示すものではない。

シード資金により、Dreezeはアプリケーション単位の復旧という構想を、より幅広いエンタープライズ事業へと発展させるための資金を得た。次の課題は、依存関係の検出、保護、オーケストレーション、テストが、顧客の実際の環境全体で連携して機能することを実証することだ。顧客にとって魅力的な成果は明快だ。重要なサービスが停止した際に、利用可能なアプリケーションへ戻るための経路がテスト済みであることだ。