ビジネス継続性の概要および障害復旧¶

このトピックでは、別のリージョンのSnowflakeアカウント、または異なるクラウドプラットフォームにデータを複製してフェールオーバーする主な使用例について説明します。

Snowflakeの複製およびフェールオーバー/フェールバック機能は、次の機能で構成されています。

データベースの複製: データベースの複製を使用すると、プライマリデータベースの読み取り専用レプリカを他のSnowflakeアカウントに保存できます。これらのアカウントは、同じ組織にグループ化する必要があり、異なるリージョンまたはクラウドプラットフォームに配置できます。各レプリカ（セカンダリデータベース）を更新すると、データベースオブジェクトと保存されているデータがプライマリデータベースと同期されます。
データベースのフェールオーバー/フェールバック: データベースのフェールオーバー/フェールバックは、レプリカをプライマリデータベースとして機能するように昇格します。その時点で、以前のプライマリデータベースは読み取り専用のセカンダリデータベースになり、以前のレプリカは読み取り/書き込み用のプライマリデータベースになります。
クライアントリダイレクト: クライアントリダイレクトは、SnowflakeクライアントがSnowflakeに接続するために使用できる 接続 URL を提供します。接続 URL は、必要に応じて別のSnowflakeアカウントにリダイレクトできます。

まとめると、これらの個々の機能は、次のようなさまざまな基本的なビジネスシナリオをサポートするように設計されています。

クラウドプラットフォームリージョンでの停止からの回復、データベースの読み取りよりも書き込みを強調。
クラウドプラットフォームリージョンの停止からの回復、データベースの書き込みよりも読み取りを強調。
クラウドプラットフォームリージョンの停止からの回復、データベースの読み取りと書き込みの両方を強調。
あるクラウドプラットフォームまたはリージョンから別のクラウドプラットフォームまたはリージョンへのデータベースの移行。

さらに、 Snowflake Secure Data Sharing とデータベースの複製により、リージョンやクラウドプラットフォーム間でデータを安全に共有できます。

このトピックの内容:

ビジネス継続性および障害復旧
アカウントの移行

ビジネス継続性および障害復旧¶

特定のリージョンのクラウドサービスが中断される大規模な停止が（ネットワークの問題、ソフトウェアのバグなどの理由により）発生した場合、停止の原因が解決され、サービスが復旧されるまでSnowflakeへのアクセスは利用できません。このようなシナリオで継続的な可用性とデータの耐久性を確保するには、重要なデータベースを組織内の別のリージョンにある、異なるSnowflakeアカウントに複製します。

非同期複製では、セカンダリレプリカは通常、構成した複製頻度に基づいてプライマリデータベースより遅れます。たとえば、プライマリデータベースを30分ごとに複製することを選択した場合、セカンダリレプリカは、停止中にプライマリから最大30分遅れます。

ビジネスニーズに応じて、次を選択できます。

データベース読み取りを最初に復旧して、クライアントアプリケーションが30分古いデータを読み取れるようにする。

データベース書き込みを最初に復旧して、クライアントアプリケーションからの読み取りを開く前に、新しいプライマリで過去30分のデータを調整する。

データベースの読み取りと書き込みの両方を同時に復旧する。つまり、新しいプライマリで過去30分のデータを調整するときに、30分古いデータでクライアントアプリケーションからの読み取りを開く。

データベースの読み取りと書き込みの両方を優先する場合は、次に挙げるシナリオのいずれかのステップに従います。リージョンで停止が発生した場合は、重要なデータベースとSnowflakeクライアント接続の両方を同時にフェールオーバーすることを選択します。

書き込み前のデータベース読み取り¶

リージョンの停止によりSnowflakeの可用性が完全にまたは部分的に失われた場合、このパスを使用すると、ダウンタイムを最小限に抑えるため、Snowflakeクライアントを重要なデータベースの読み取り専用レプリカに最初にリダイレクトできます。短期間の停止時には、読み取り専用モードでの動作を選択することが望ましい場合が多くあります。

最新のデータの必要性と組み合わされた長期の停止には、読み取り/書き込みモードが必要です。

このパスのステップは次のとおりです。

通常のステータス: リージョンは運用可能¶

データベースの複製: プライマリ（ソース）データベースを保存するアカウントとは異なるリージョンの、1つ以上のSnowflakeアカウントに重要なデータベースを複製します。データベースオブジェクトと保存されたデータを頻繁に更新します。

リージョンの停止¶

クライアントリダイレクト: 読み取り専用レプリカ（セカンダリ）データベースを保存するSnowflakeアカウントに対して使用されるクライアントが使用する接続 URL をポイントします。
データベースのフェールオーバー（必要な場合）: 長期間の停止が発生した場合は、接続 URL が読み取り/書き込みプライマリデータベースとして機能するようにポイントしているSnowflakeアカウントでセカンダリデータベースを昇格します。

通常のステータス: 停止は解決済み¶

データベースの複製: 停止が発生したリージョンのSnowflakeアカウントのデータベースを更新します。
データベースのフェールバック: 停止が発生したSnowflakeアカウントのデータベースを昇格して、プライマリデータベースとして再び機能させます。
クライアントリダイレクト: クライアントが使用する接続 URL を停止が発生したリージョンのSnowflakeアカウントにポイントします。

読み取り前のデータベース書き込み¶

リージョンの停止によりSnowflakeの可用性が完全にまたは部分的に失われた場合にこのパスを使用すると、重要なデータベースを回復し、最初にデータを処理し続けることができます。このオプションは、データベースと ETL （抽出、変換、読み込み）プロセスを最初にフェールオーバーし、データが最新の場合にのみSnowflakeクライアントをリダイレクトすることを選択するアカウント管理者に適しています。

このパスのステップは次のとおりです。

通常のステータス: リージョンは運用可能¶

データベースの複製: プライマリ（ソース）データベースを保存するアカウントとは異なるリージョンの、1つ以上のSnowflakeアカウントに重要なデータベースを複製します。データベースオブジェクトと保存されたデータを頻繁に更新します。

リージョンの停止¶

データベースフェールオーバー: プライマリデータベースとして機能するように、異なるリージョンの重要なデータベースのレプリカを昇格します。これにより、これらのデータベースへの書き込みが可能になります。データベースが書き込み可能になると、 ETL プロセスを使用して書き込みに優先順位を付け、データを調整できます。
クライアントリダイレクト（必要な場合）: クライアントが使用する接続 URL を新しいプライマリデータベースを格納するSnowflakeアカウントにポイントします。

通常のステータス: 停止は解決済み¶

データベースの複製: 停止が発生したリージョンのSnowflakeアカウントのデータベースを更新します。
データベースのフェールバック: 停止が発生したSnowflakeアカウントのデータベースを昇格して、プライマリデータベースとして再び機能させます。
クライアントリダイレクト: クライアントが使用する接続 URL を停止が発生したリージョンのSnowflakeアカウントにポイントします。

ビジネス継続性および障害復旧のフロー¶

このセクションの図は、事業継続および障害復旧のフローを示しています。

データベースのフロー¶

次の図は、同じ組織内の異なるリージョン（Region A と Region B）の2つのアカウントを示しています。1つのアカウントで、ローカルデータベースがプライマリデータベースとして機能するように昇格されました。プライマリデータベース（つまり、セカンダリデータベース）のレプリカを保存できるように、他のアカウントの複製が有効になっています。
次の図は、 Region B のアカウントで作成されたセカンダリデータベースを示しています。緑色の矢印は、プライマリデータベースからセカンダリデータベースに進行中のデータ更新操作を示しています。
次の図は、フェールオーバーのシナリオを示しています。プライマリデータベースを含むアカウントが存在する Region A でサービスが停止しました。セカンダリデータベース（Region B 内）がプライマリデータベースとして機能するように昇格されました。同時に、以前のプライマリデータベースは、セカンダリの読み取り専用データベースになりました。

データベースをフェールオーバーする手順については、複数のアカウントにまたがるデータベースのフェールオーバーをご参照ください。
次の図は、 Region A のサービス停止が解決されたことを示しています。プライマリデータベース（ Region B 内）からセカンダリデータベース（ Region A 内）へのデータベース更新操作が進行中です。
最後の図は、初期構成に戻された操作（フェールバック）を示しています。セカンダリデータベース（ Region A 内）は、通常のビジネスオペレーションのプライマリデータベースとして再び機能するように昇格されました。同時に、以前のプライマリデータベース（ Region B 内）は、セカンダリの読み取り専用データベースになりました。

接続のフロー¶

次の図は、同じクラウドプラットフォームまたは異なるクラウドプラットフォームのいずれかで、同じ組織内の異なるリージョン（Region A と Region B）にある2つのアカウントを示しています。クライアント接続の接続 URL は、 Region A のアカウント用に構成されています。
次の図は、 Region A でのサービスの停止を示しています。このため、クライアント接続に失敗します。
次の図は、クライアント接続の接続 URL が Region B のアカウント用に構成されていることを示しています。接続 URL に接続しているクライアントは、 Region B のアカウントに接続しています。

クライアントリダイレクトは手動のプロセスであることに注意してください。詳細については、クライアント接続のリダイレクトの手順をご参照ください。

アカウントの移行¶

アカウントの移行は、Snowflakeオブジェクトと保存されたデータを別のリージョンまたは別のクラウドプラットフォームのアカウントに移行（または転送）する1回限りのプロセスです。アカウントを移行する一般的な理由には、ユーザーベースに近いことや、企業戦略や他のクラウド資産（例: データレイク）とのコロケーションに基づいた、異なるクラウドプラットフォームの優先順位などがあります。

現在、Snowflakeオブジェクトの複製のサポートは、データを保存するオブジェクト（例: マテリアライズドビューを含むテーブルやビュー）のコンテナーとしてのデータベースに限定されています。複製されたオブジェクトの完全なリストについては、複製されたデータベースオブジェクトをご参照ください。Snowflakeサポートと連携して、アカウントオブジェクト（例: ユーザーやロール）やその他のSnowflakeオブジェクトを新しいアカウントに複製します。

注釈

データベースのフェールオーバー/フェールバックには、Business Critical（またはそれ以上）が必要です。Snowflakeは、1回限りのアカウント移行のために、この要件を一時的に放棄することができます。