この記事では、Microsoft Fabricにおける信頼性サポートについて説明し、可用性ゾーンによる地域的なレジリエンスと地域横断の復旧および事業継続性の両方を含みます。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。
可用性ゾーンのサポート
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Fabric では、Azure 可用性ゾーンを使用して、Fabric と Power BI の項目とデータをデータセンターの障害から保護します。 このサービスは、顧客の設定を必要とせずに複数のゾーンに自動的にFabricリソースを分散させます。
- OneLake をお使いの場合は、データ エンジニアリングで Availability Zones がサポートされます。 ADLS Gen2 などの他のデータ ソースをお使いの場合は、ゾーン冗長ストレージ (ZRS) が有効になっていることを確認する必要があります。
ゾーンダウンの体験
ゾーン全体の停止中は、利用者の操作は必要ありません。 ファブリック機能は、正常なゾーンを利用するために自動的に自己修復と再調整を行います。 場合によっては、進行中の作業を再開する必要があることもあります。 例えば、Spark Jobsを実行すると、プライマリノードが失敗ゾーンにある場合に失敗することがあります。 その場合は、求人を再提出する必要があります。 フロントエンドノードが失敗ゾーンにある場合、データウェアハウスやSQL分析エンドポイントのクエリが失敗することがあります。 その場合は、安全にクエリを再開する必要があります。
Important
Microsoft では、一定で一貫性のある可用性ゾーンのサポートを提供するよう努めていますが、可用性ゾーンの障害が発生した場合、顧客需要の変動が大きな Azure リージョンに置かれた Fabric 容量での待機時間が、通常よりも長くなる可能性があります。
リージョン間のディザスター リカバリーおよび事業継続
ディザスター リカバリー (DR) とは、自然災害やデプロイの失敗など、ダウンタイムやデータ損失につながる影響の大きいイベントから組織が復旧するために使用するプラクティスを指します。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR 計画と、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を開始する前に、 ディザスター リカバリー戦略の設計に関する推奨事項を参照してください。
DR の場合、Microsoftは、共有責任モデルを使用します。 このモデルでは、Microsoftベースライン インフラストラクチャとプラットフォーム サービスが使用可能であることを確認します。 ただし、多くのAzure サービスでは、データが自動的にレプリケートされたり、障害が発生したリージョンからフォールバックして別の有効なリージョンにクロスレプリケートしたりすることはありません。 それらのサービスに対して、ワークロードに適したディザスター リカバリー計画を設定する責任はユーザーにあります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されています。 サービス固有の機能を使用して高速復旧をサポートし、DR プランの開発に役立ちます。
このセクションでは、計画外のリージョンの障害が発生した場合に、組織がデータを安全かつアクセス可能に維持できるように設計された Fabric のディザスター リカバリー計画について説明します。 この計画では、次のトピックが対象になります。
リージョン間レプリケーション: Fabric では、OneLake の格納データのリージョン間レプリケーションが提供されます。 要件に基づいて、この機能をオプトインまたはオプトアウトできます。
障害発生後のデータ アクセス: リージョンの障害シナリオでは、Fabric によって一定の制限付きでデータ アクセスが保証されます。 フェールオーバー後には新しい項目の作成や変更は制限されますが、主な重点が、既存のデータが引き続きアクセス可能で、損傷を受けないようにすることに変わりはありません。
回復のためのガイダンス: Fabric では、回復プロセスをガイドする、構造化された一連の手順が提供されます。 構造化されたガイダンスにより、通常の操作への移行が容易になります。
現在、Fabric の一部となっている Power BI には、強固なディザスター リカバリー システムが導入されており、次の機能が用意されています。
BCDR は既定: リージョンが Power BI をサポートするリージョン と ペアになっている 場合、ディザスター リカバリー機能が既定で含まれます。 この機能を個別にオプトインまたはアクティブにする必要はありません。
リージョン間レプリケーション: Power BI では、Azure ストレージ geo 冗長レプリケーションと Azure SQL geo 冗長レプリケーションを使って、バックアップ インスタンスが確実に他のリージョンに存在し使用できるようにします。 これは、データは異なるリージョンにわたって複製されるため、可用性が向上し、リージョンの障害に関連するリスクが軽減されることを意味します。
障害後の継続的なサービスとアクセス: 破壊的なイベントの間でも、Power BI 項目は読み取り専用モードでアクセスできる状態に留まります。 項目にはセマンティック モデル、レポート、ダッシュボードが含まれており、企業が大きな障害なしに分析と意思決定のプロセスを継続できるようにします。
詳細については、Power BIの高可用性、フェイルオーバー、災害復旧FAQをご覧ください。
Important
災害の影響を受けた顧客で、ホームリージョンにFabric対応のAzureペアリージョンがない場合、たとえその容量内のデータが複製されていても、Fabricの容量を活用する能力が損なわれる可能性があります。 この制約は、能力運用に不可欠な本拠地のインフラに結びついています。 Fabric をサポートするリージョンの一覧を表示するには、Fabric リージョンの可用性に関するページを参照してください。
ホーム リージョンと容量の機能
効果的なディザスター リカバリー計画を立てるには、ホーム リージョンと容量の場所の関係を理解することが重要です。 ホーム リージョンと容量の場所を理解すると、容量のリージョンや、対応するレプリケーションと回復プロセスを戦略的に選ぶのに役立ちます。
組織のテナントとデータ ストレージのホーム リージョンは、最初にサインアップしたユーザーの請求先住所の場所に設定されます。 テナントのセットアップの詳細については、「Power BI 実装計画: テナントのセットアップ」を参照してください。 新しい容量を作成すると、データ ストレージは既定でホーム リージョンに設定されます。 データストレージ地域を別の地域に変更したい場合は、Fabric Premium機能であるMulti-Geoを有効にする必要があります。
Important
容量に対して別のリージョンを選んでも、すべてのデータがそのリージョンに完全に再配置されるわけではありません。 一部のデータ要素は引き続きホーム リージョンに格納されます。 どのデータがホーム リージョンに残り、どのデータが Multi-Geo 対応リージョンに格納されているかを確認するには、Fabric Premium の Multi-Geo サポートの構成に関する記事を参照してください。
ペアリージョンが存在しないホームリージョンの場合、マルチジオ対応リージョンの容量は、ホームリージョンが災害が発生した場合に運用上の問題に直面する可能性があります。なぜなら、コアサービス機能がホームリージョンに紐づいているからです。
EU 内の Multi-Geo 対応リージョンを選ぶと、データが EU データ境界内に格納されることが保証されます。
ホーム リージョンを特定する方法については、「Fabric のホーム リージョンを確認する」を参照してください。
ディザスター リカバリー容量の設定
Fabric では、容量設定のページにディザスター リカバリー スイッチが用意されています。 Azure のリージョン ペアが Fabric のサービスの存在と一致する場合に使用できます。 このスイッチの詳細は次のとおりです。
ロール アクセス: 容量管理者以上のロールを持つユーザーのみがこのスイッチを使用できます。
細分性: スイッチの細分性は容量レベルです。 Premium 容量とファブリック容量の両方で使用できます。
データ スコープ: ディザスター リカバリー切り替えは、特に、Lakehouse と Warehouse データを含む OneLake データに対応します。 スイッチはOneLakeの外に保存されたデータには影響しません。
Power BIのBCDR継続性:OneLakeデータの災害復旧はオン・オフを切り替えられますが、Power BIのBCDRはスイッチのオン・オフに関わらず常にサポートされています。
頻度:災害復旧容量の設定を変更した後は、再度変更できるまで30日間待つ必要があります。 待機期間は安定性を保ち、絶え間ない切り替えを防ぎます。
Note
災害復旧容量設定を有効にしたり、容量内で新しいワークスペースを作成した後、データレプリケーションの開始には時間がかかることがあります。 各ワークスペースの状態は、この容量に 割り当てられているワークスペースの容量設定ページで確認できます。 OneLake geo レプリケーション列には、geo レプリケーションを有効にするための状態が表示されます。
データのレプリケーション
ディザスター リカバリー容量の設定を有効にすると、OneLake データのディザスター リカバリー機能としてリージョン間レプリケーションが有効になります。 Fabric プラットフォームは Azure リージョンと連携して、geo 冗長ペアをプロビジョニングします。 ただし、一部のリージョンには Azure ペア リージョンがないか、ペア リージョンが Fabric をサポートしていません。 これらのリージョンでは、データ レプリケーションは使用できません。 詳細については、「可用性ゾーンがあるリージョンとリージョン ペアのないリージョン」と「ファブリック リージョンの可用性」を参照してください。
Note
Fabric はディザスター リカバリーをサポートするために OneLake でのデータ レプリケーション ソリューションを提供していますが、重要な制限があります。 たとえば、KQL データベースとクエリ セットのデータは OneLake の外部に格納されるため、別のディザスター リカバリー アプローチが必要になることを意味します。 各 Fabric 項目のディザスター リカバリー アプローチの詳細については、このドキュメントの残りの部分を参照してください。
Billing
Fabric のディザスター リカバリー機能により、セキュリティと信頼性を強化するためにデータの geo レプリケーションを行うことができます。 この機能では、より多くのストレージとトランザクションが使われ、それぞれ BCDR ストレージと BCDR 操作として課金されます。 これらのコストは、Microsoft Fabric Capacity Metrics アプリで監視および管理でき、個別の項目として表示されます。
関連するすべてのディザスター リカバリー コストの、それに応じた計画と予算の作成に役立つ、詳細な内訳については、「OneLake のコンピューティングとストレージの消費量」を参照してください。
ディザスター リカバリーを設定する
Fabric にはデータの回復性をサポートするディザスター リカバリー機能が用意されていますが、中断時にサービスを復元するには、特定の手動の手順に従う必要があります。 このセクションでは、潜在的な中断に備えるために実行する必要があるアクションについて詳しく説明します。
フェーズ 1: 準備
ディザスター リカバリー容量の設定を有効にする: ディザスター リカバリー容量の設定を定期的に確認して設定し、保護とパフォーマンスのニーズを満たしていることを確認します。
データ バックアップの作成: ディザスター リカバリー計画に合わせた形で、OneLake の外部に格納されている重要なデータを別のリージョンにコピーします。
フェーズ 2: 障害時のフェールオーバー
重大災害でプライマリーリージョンが回復不能になると、Microsoft Fabricはリージョンフェイルオーバーを開始します。 フェイルオーバーが完了するまでFabricポータルにアクセスできません。 通知はMicrosoft Fabricのサポートページに掲載されます。
フェールオーバーが完了するまでにかかる時間はさまざまですが、通常は 1 時間未満です。 フェールオーバーが完了したら、次のことが予期されます。
Fabric ポータル: ポータルにはアクセス可能で、既存のワークスペースの閲覧、ワークスペース内のタスク フローやアイテムの参照などの読み取り操作は引き続き利用できます。 ワークスペースの作成や変更などのすべての書き込み操作は一時停止されます。
Power BI: ダッシュボードやレポートの表示などの読み取り操作を実行できます。 更新、レポートの発行操作、ダッシュボードとレポートの変更、メタデータの変更が必要なその他の操作はサポートされていません。
Lakehouse/Warehouse:これらのアイテムは開けませんが、OneLakeのAPIやツールを通じてファイルにアクセスできます。
Sparkジョブ定義:Sparkジョブ定義は開けませんが、OneLakeのAPIやツールを通じてコードファイルにアクセスできます。 メタデータや設定はフェイルオーバー後に保存されます。
ノートブック:ノートブックは開けず、災害後はコード内容も保存されません。
ML モデル/実験: ML モデルまたは実験を開くことはできません。 コード内容や実行指標、設定などのメタデータは災害後に保存されません。
Dataflow Gen2/パイプライン/Eventstream: これらの項目を開くことはできませんが、サポートされているディザスター リカバリー先 (レイクハウスまたはウェアハウス) を使ってデータを保護できます。
KQLデータベース/クエリセット:フェイルオーバー後はKQLデータベースやクエリセットにアクセスできません。 KQL データベースとクエリ セットのデータを保護するには、さらに前提条件となる手順が必要です。
災害時には、FabricポータルとPower BIは読み取り専用モードとなり、他のFabricアイテムは利用できません。 API やサードパーティ製ツールを使用して、OneLake に保存されているそれらのデータにアクセスできます。 ポータルと Power BI は両方とも、そのデータに対して読み取り/書き込み操作を実行する機能が保持されます。 この機能により、重要なデータへのアクセスと変更が可能になり、ビジネス業務の中断の可能性が軽減されます。
OneLakeのデータには複数のチャネルでアクセスできます:
OneLake ADLS Gen2 API: 「Microsoft OneLake への接続」を参照してください
OneLake データに接続できるツールの例:
Azure Storage Explorer: 「OneLake と Azure Storage Explorer の統合」を参照してください
OneLake エクスプローラー: 「OneLake エクスプローラーを使って Fabric データにアクセスする」を参照してください
障害シナリオでは、OneLake カタログは読み取り専用モードです。
[探索] タブ: [探索] タブにアクセスして、メタデータや関連する詳細を含むすべてのアイテムとワークスペースを表示できます。
[管理] タブ: [ガバナンス] タブにアクセスすると、フェールオーバー前の最新の成功したモデルの更新に基づいて、分析情報、推奨されるアクション、ガバナンス ツールを表示できます。
フェーズ 3: 復旧計画
Fabric は障害発生後もデータにアクセスできることを保証しますが、サービスをインシデント前の状態に完全に復元させるようにすることもできます。 このセクションでは、回復プロセスを実行するのに役立つステップ バイ ステップ ガイドを提供します。
回復後の手順
障害発生後、任意のリージョンに新しい Fabric 容量を作成します。 このようなイベントでの需要が高いため、主要な地理圏外の地域を選択して、コンピュートサービスの利用可能性を高めましょう。 容量の作成については、「Microsoft Fabric サブスクリプションを購入する」を参照してください。
新しく作成した容量にワークスペースを作成します。 必要に応じて、古いワークスペースと同じ名前を使います。
回復する項目と同じ名前の項目を作成します。 この手順は、カスタム スクリプトを使ってレイクハウスやウェアハウスを回復する場合に重要です。
項目を復元します。 各項目について、「エクスペリエンス固有のディザスター リカバリーのガイダンス」の関連セクションに従って項目を復元します。