貴社の事業継続性とディザスタリカバリ戦略は、エンタープライズ要件に本当に対応できていますか？

次のような場合を想像してみてください。現在、会計四半期の最終週を迎えているとします。御社のセールスチームが案件をまとめ、財務チームが取締役会向けのレポートを準備しています。御社のマーケティングチームは、次の四半期の予算を設定するためにキャンペーンのパフォーマンスを分析しています。そして、ある火曜日の午後4時、クラウドプロバイダーの障害によりアナリティクスプラットフォームが停止したとします。

多くの組織にとって、このシナリオは仮説ではなく、繰り返される悪夢です。SnowflakeのCEOであるSridhar Ramaswamyが最近のブログ記事で指摘したように、今日の相互接続され、急速に変化するデジタル経済に対応する組織にとって、ディザスタリカバリは不可欠です。たった1つのインシデントが、何千ものアプリケーションやサービスに波及し、ビジネスプロセスが中断して重要な意思決定が遅延する可能性があります。

しかし、データ＋AIプラットフォームの評価では、事業継続性とディザスタリカバリ（BCDR）は後回しになりがちです。残念ながら、すべてのプラットフォームが真のエンタープライズレジリエンスを実現するように設計されているわけではありません。つまり、システム障害が発生した際、事業継続性は自らの責任で解決すべき問題となり、企業の信頼失墜というリスクを背負うことになるのです。

すべてのデータリーダーが問いかけるべき3つのBCDR質問

ダウンタイムのリスクを受け入れるか、レジリエンスに投資するか、という選択は、すべてのビジネスが直面する問題です。問題は、BCDRソリューションを導入できるかどうかではなく、導入しない余裕があるかどうかです。

現在のプラットフォームを評価する場合、または新しいソリューションを評価する場合は、次の3つの重要な質問により、自社のビジネスが十分に保護されているかどうかを確認できます。

1.「御社のプラットフォームでは、復旧要件をどのように達成できますか？」

ダウンタイムのリスクは、ほとんどの組織が認識しているよりもはるかに高くなります。Enterprise Management Associates（EMA）の2024年の調査によると、計画外のダウンタイムのコストは1分あたり平均14,056ドルで、大企業では23,750ドルに上昇しています。 

ビジネスには、目標復旧時点（RPO）や目標復旧時間（RTO）などの具体的な復旧目標がある場合があります。評価対象のソリューションがそれを実現できるかどうかを尋ねる必要があります。

エンタープライズニーズに合わせて構築されたプラットフォームは、ディザスタリカバリプロシージャを順を追って設定できるはずです。具体的には、次の点を確認します。「DRアカウントで失われたデータを簡単に再取り込み、15分間のRTOを達成するにはどうすればよいですか？」その仕組みを説明できないのであれば、チームが十分な可視性を持たないまま運用せざるを得ないプラットフォームを検討していることになります。

2.「クロスリージョンとクロスクラウドのフェイルオーバーの仕組みを実証できますか？」

真のエンタープライズグレードのBCDRは、ローカルの冗長性だけでなく、リージョン間やクラウドプロバイダー間においてもシームレスなフェイルオーバーを実現します。BCDRは、データセンターの障害、地域のサービスの中断、リージョンやクラウドプロバイダー間での移行のいずれにも対応します。

また、サードパーティ分析によると、Snowflakeはクロスリージョンとクロスクラウドのフェイルオーバーを自動的に処理し、複数のリージョンとクラウドにまたがるデータ、処理能力、ガバナンス制御を維持できます。他のプラットフォームでは、クロスリージョンとクロスクラウドのフェイルオーバーを実現するために、広範な手動介入とカスタムエンジニアリングが必要になる可能性があります。 

本番稼働までに要する時間を必ず確認してください。たとえばDatabricksは自社のBCDRについて「初回の立ち上げと運用開始までに数か月、場合によっては1年かかることもある」と公に認めています。SnowflakeのBCDRは、クロスリージョン保護とクロスクラウド保護のどちらであっても数分でセットアップできます。

3.「中断時にガバナンスポリシーを確実に適用するにはどうすれば良いでしょうか？」

データは、災害発生時においても適切にガバナンスを確保できなければ価値がありません。

プラットフォームによっては、行レベルセキュリティ、列のマスキングルール、ユーザー権限などのポリシーがシームレスに復元されないため、規制違反や高額な罰金に晒されます。

Snowflakeなどの最も強力なプラットフォームは、アカウント全体を単一のマネージドユニットとして複製します。これにより、すべてのデータ、メタデータ、アカウント情報が保護されます。つまり、ガバナンスポリシーも保護されるため、コンプライアンスとセキュリティを維持できます。

Snowflake Backups機能（現在一般提供中）は、この保護をさらに進化させています。変更不可能なバックアップを設定し、管理者でも変更や削除を行えないポイントインタイムスナップショットを作成できます。災害シナリオでは、スナップショットとSnowflakeのアカウントレプリケーションを組み合わせることで、すべてのスナップショットセットとポリシーを別のリージョンまたはクラウドプロバイダーに複製して復旧できます。Snowflake Backupsは、お客様のコンプライアンス遵守をサポートし、ランサムウェアなどの脅威に対するサイバーレジリエンスを強化するとともに、監査や法務目的で必要となるデータの長期的な整合性を維持します。

BCDRの失敗が、数百万ドルの損失やキャリアへの影響につながるとしたら

災害発生時には、データを取り戻すだけでなく、パイプライン、ガバナンスポリシー、ユーザー権限、ビジネスロジックなど、データ資産全体を復元する必要があります。 

しかし、一部のプラットフォームはBCDRを、まるで「DIYの科学実験」のように扱っています。そこでは最低限の構成要素が提供されるだけで、ディザスタリカバリプロシージャの設計、実装、そして維持管理はすべて現場のチームに委ねられます。表面的には、柔軟性があるように見えるかもしれません。実態は以下のような状況を招くだけです。

• フェイルオーバーシナリオを処理するための数千行のカスタムコード。

• 複数のベンダーが連携して、重要なデータのレプリケーションを確保。

• カスタムソリューションが最も必要なタイミングで機能するとは限らない。

• あらゆる障害モードに備えるため、万一の事態に備えて各自の責任で対処する必要がある。

これは膨大な運用負荷となり、エンジニアリングに数百時間もの工数を費やすことになります。さらに、ビジネスをリスクにさらすだけでなく、本来イノベーションに充てるべきチームのリソースをBCDRソリューションの維持管理に浪費させてしまいます。 

DIY型のアプローチ（自前での構築）を選択すると、チームの仕事はデータやAIソリューションの構築だけにとどまらなくなります。複雑なフェイルオーバープロシージャを書き上げる「ディザスタリカバリの専門家」になることを強いられ、自分たちのコードがいざという時に本当に機能するかを確かめずに済むことを願うしかありません。

BCDRに対するDIYアプローチの打破

セルフマネージドの複雑なソリューションでは、障害発生時に読み取りと書き込みの継続性を確保するために、すべてのコンポーネントを調整してプロビジョニングする必要があります。こうした連携には、以下が含まれます。

• データとメタストア：ストレージレプリケーションを処理し、デュアルプロビジョニングスクリプトを使用してデータベース、スキーマ、テーブル、ビュー、その他のデータオブジェクトを管理する必要があります。

• セキュリティとガバナンス：冗長なセキュリティモデル（ユーザー、ロール、ネットワークルールなど）とガバナンスポリシー（行レベルと列レベルのセキュリティ、タグなど）を維持するには、別のスクリプトが必要です。

• コンピュートおよびAIサービス：コンピュートリソース、コンテナ、さらにはAIサービス用の登録済みモデルアーティファクトも、セカンダリリージョンで手動でプロビジョニングする必要があります。

• 統合とパイプライン：IDプロバイダー、キーボールト、その他のAPI、データパイプライン、コードリポジトリとの外部統合は、フェイルオーバー後にシステムが正しく機能するように冗長化する必要があります。

• リダイレクト：アプリ、BIツール、AIサービスなどのエンドクライアントにシームレスなアクセスを提供するには、手動でリダイレクトする必要があります。多くの場合、DNSホスト名やIPアドレスの変更が必要になります。

これをSnowflakeのようなプラットフォームと比較してみてください。SnowflakeにとってBCDRは、導入初日からすぐに使える即戦力のソリューションです。チームがビジネス価値の創出に専念できるよう、Snowflakeが継続的な可用性を担保します。Snowflakeの調査によると、これにより計画外のダウンタイムを平均75%削減し、直接コストを30%節約することが可能になります。

継続的な可用性を実現するために必要な要素

最新のBCDRは、障害からの復旧だけではありません。また、そもそもビジネスに悪影響を与えないようにすることも重要です。そのためには、以下に対応したプラットフォームが必要です。

• 簡単なセットアップ：複雑なレプリケーションロジックを構築するのではなく、数回のクリックでBCDRをアクティベートし、複数のリージョンやクラウドにわたって機能するソリューションが必要です。

• ニアゼロダウンタイム：プラットフォームは、レプリケーションのアプローチによって分単位のRTOとニアゼロのデータロス（RPO）を達成する必要があります。

• アカウントの完全同期：ガバナンスルール、ユーザー権限、セキュリティポリシーは、カスタムコードを使用せず、すべてのリージョンやクラウドにわたって一貫して適用および維持する必要があります。

現実はというと、これら3つの要件をすべてすぐに実現できるのは、Snowflakeだけです。

すべてのプラットフォームがエンタープライズに対応しているわけではなく、基本的なフェイルオーバーを実現するためには数か月のカスタムエンジニアリングが必要です。しかし、Snowflakeのアカウントレプリケーションとフェイルオーバーは、数分で構成できます。その後、Snowflakeは、ガバナンスポリシー、ユーザー権限、統合、セキュリティルールなど、サポートされている複数のリージョンやクラウドプロバイダーのデータ資産全体を自動的にメンテナンスします。詳細については、デモをご覧ください。

他のプラットフォームでは、BCDRは高価なDIYプロジェクトとして扱われますが、Snowflakeは、このテクノロジーをエンタープライズの中核的な要件として扱います。このアプローチの影響は、障害が発生したときに顕著に現れます。コラボレーション、ガバナンス、事業継続性を実現するクロスクラウドのテクノロジーレイヤーであるSnowgridによって、私たちは障害をお客様にとってほとんど影響のない出来事に変えることができました。

プラットフォームのBCDRに関する主張の検証

現在のプラットフォームの評価や新しいソリューションの評価にあたっては、BCDRを最も重要な考慮事項とする必要があります。主な評価基準は以下のとおりです。

• 以下についての証明を要求する：プラットフォームのディザスタリカバリプロセスを確認します。クロスリージョンおよびクロスクラウドのフェイルオーバーを実証できるか、セットアップの難易度、所要時間はどれだけかかるか、です。  

• アカウントの継続性を理解する：アカウントポリシーの復元について具体的に尋ねます。リージョンに障害が発生した場合、ポリシーと権限はどの程度迅速に復元されますか？

• 責任共有モデルを評価する：災害が発生した際、具体的に何が起きるのか、そして誰が復旧プロセスを管理するのでしょうか？

• クロスクラウドを探索する：規制の厳しい業界では特に、クロスクラウドのディザスタリカバリが必要になる可能性があります。クラウドプロバイダー間で自動的にフェイルオーバーできるか？

• 実際の稼働環境でのテストについて確認する：フェイルオーバーシナリオのテスト頻度はどれくらいですか？ビジネスを中断することなく独自のフェイルオーバーテストを実行できますか？

既存のプラットフォームのBCDR機能を評価する場合は、以下の質問に焦点を当てたテクニカルレビューをスケジュールすることを検討してください。

• 「ディザスタリカバリの仕組みを順を追って説明してください」

• 「フェイルオーバー時のガバナンスポリシーの復元方法について、順を追って説明してください」

• 「クロスリージョンとクロスクラウドのポリシー同期をどのように処理していますか」

• 「プライマリリージョンが利用できなくなった場合の実際のRTOはいつですか」

• 「御社のBCDRソリューションは、データロスやビジネスへの影響のないDRドリルを可能にし、弊社のテクノロジースタック全体のフォールトトレランスを定期的にテストできるようにしていますか」

机上の空論を受け入れてはいけません。デモと文書化されたプロシージャを要求してください。システムがダウンした際、唯一重要となるのは迅速、完全、かつ正確に復旧させることだからです。ビジネスの存続は、その一点にかかっています。

御社の現在のBCDR戦略を評価する準備はできていますか？包括的な事業継続性評価については、Snowflakeにお問い合わせください。Snowflakeのエンタープライズクラスのディザスタリカバリ機能によって、重要なデータワークロードがどのように保護されるかをご確認いただけます。また、クイックスタートガイドでハンズオンを行い、数分でBCDRを設定する方法を学習できます。