Microsoft Fabric の信頼性

この記事では、Microsoft Fabric の信頼性サポートについてと、可用性ゾーンによるリージョンの回復性、リージョン間の回復とビジネス継続性の両方について説明します。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

可用性ゾーンのサポート

可用性ゾーンとは、各 Azure リージョン内にある、物理的に分離されたデータセンターのグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Azure での Availability Zones の詳細については、「Availability Zones とは」を参照してください。

Fabric では、ゾーン冗長可用性ゾーンをサポートするために、商業的に合理的な努力を行っています。これにより、ユーザーは設定や構成を行うことなく、リソースがゾーン間で自動的にレプリケートされます。

前提条件

• Fabric では現在、限られた数のリージョンで部分的な可用性ゾーンのサポートを提供しています。 この可用性ゾーンの部分的サポートは、エクスペリエンス (や 1 つのエクスペリエンス内の特定の機能) を対象としています。
• イベント ストリームなどのエクスペリエンスでは、Availability Zones はサポートされていません。
• OneLake をお使いの場合は、データ エンジニアリングで Availability Zones がサポートされます。 ADLS Gen2 などの他のデータ ソースをお使いの場合は、ゾーン冗長ストレージ (ZRS) が有効になっていることを確認する必要があります。
• ゾーンの可用性は、Fabric エクスペリエンスやプレビュー段階の機能では、使用できる場合と使用できない場合があります。
• Power BI のオンプレミス ゲートウェイと大規模なセマンティック モデルでは、可用性ゾーンをサポートしていません。
• Data Factory (パイプライン) では西ヨーロッパの可用性ゾーンがサポートされていますが、ゾーンの停止が発生した場合、新規または進行中のパイプラインの実行が失敗する可能性があります。

サポートされているリージョン

Fabric では、以下のように多様なリージョンで可用性ゾーンのサポートを提供するため、商業上合理的な努力を行っています。

南北アメリカ	Power BI	データマート	データ ウェアハウス	リアルタイム分析	Data Factory (パイプライン)	Data Engineering	SQL Database
ブラジル南部
カナダ中部
米国中部
米国東部
米国東部 2
米国中南部
米国西部 2
米国西部 3
ヨーロッパ	Power BI	データマート	データ ウェアハウス	リアルタイム分析	Data Factory (パイプライン)	Data Engineering	SQL Database
フランス中部
ドイツ中西部
イタリア北部
北ヨーロッパ
ノルウェー東部
ポーランド中部
英国南部
西ヨーロッパ
中東	Power BI	データマート	データ ウェアハウス	リアルタイム分析	Data Factory (パイプライン)	Data Engineering	SQL Database
カタール中部
イスラエル中部
アフリカ	Power BI	データマート	データ ウェアハウス	リアルタイム分析	Data Factory (パイプライン)	Data Engineering	SQL Database
南アフリカ北部
アジア太平洋	Power BI	データマート	データ ウェアハウス	リアルタイム分析	Data Factory (パイプライン)	Data Engineering	SQL Database
オーストラリア東部
東日本
東南アジア

ゾーン ダウン エクスペリエンス

ゾーン全体の停止中、ゾーンの復旧中に必要なアクションはありません。 サポートされているリージョンに記載されているリージョンのファブリック機能は、正常なゾーンを利用するために自動的に自己修復および再調整を行います。 マスター ノードが障害の発生したゾーン内にある場合、Spark ジョブの実行が失敗する可能性があります。 このような場合は、ジョブを再送信する必要があります。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (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」を参照してください

ホーム リージョンと容量の機能

効果的なディザスター リカバリー計画を立てるには、ホーム リージョンと容量の場所の関係を理解することが重要です。 ホーム リージョンと容量の場所を理解すると、容量のリージョンや、対応するレプリケーションと回復プロセスを戦略的に選ぶのに役立ちます。

組織のテナントとデータ ストレージのホーム リージョンは、最初にサインアップしたユーザーの請求先住所の場所に設定されます。 テナントのセットアップの詳細については、「Power BI 実装計画: テナントのセットアップ」を参照してください。 新しい容量を作成すると、データ ストレージは既定でホーム リージョンに設定されます。 データ ストレージ リージョンを別のリージョンに変更する場合は、Fabric Premium の機能である Multi-Geo を有効にする必要があります。

ホーム リージョンを特定する方法については、「Fabric のホーム リージョンを確認する」を参照してください。

ディザスター リカバリー容量の設定

Fabric では、容量設定のページにディザスター リカバリー スイッチが用意されています。 Azure のリージョン ペアが Fabric のサービスの存在と一致する場合に使用できます。 このスイッチの詳細は次のとおりです。

• ロール アクセス: 容量管理者以上のロールを持つユーザーのみがこのスイッチを使用できます。

• 細分性: スイッチの細分性は容量レベルです。 Premium 容量とファブリック容量の両方で使用できます。

• データ スコープ: ディザスター リカバリー切り替えは、特に、Lakehouse と Warehouse データを含む OneLake データに対応します。 このスイッチは、OneLake の外部に格納されているデータには影響しません。

• Power BI の BCDR 継続性: OneLake データのディザスター リカバリーはオンとオフを切り替えることができますが、Power BI の BCDR は、スイッチがオンかオフかに関係なく、常にサポートされます。

• 頻度: ディザスター リカバリー容量の設定を変更したら、再度変更できるようになるまで 30 日間待つ必要があります。 待機期間は、安定性を維持し、繰り返される切り替えを防ぐために設定されています。

データのレプリケーション

ディザスター リカバリー容量の設定を有効にすると、OneLake データのディザスター リカバリー機能としてリージョン間レプリケーションが有効になります。 Fabric プラットフォームは Azure リージョンと連携して、geo 冗長ペアをプロビジョニングします。 ただし、一部のリージョンには Azure ペア リージョンがないか、ペア リージョンが Fabric をサポートしていません。 これらのリージョンでは、データ レプリケーションは使用できません。 詳細については、「可用性ゾーンがあるリージョンとリージョン ペアのないリージョン」と「ファブリック リージョンの可用性」を参照してください。

請求

Fabric のディザスター リカバリー機能により、セキュリティと信頼性を強化するためにデータの geo レプリケーションを行うことができます。 この機能では、より多くのストレージとトランザクションが使われ、それぞれ BCDR ストレージと BCDR 操作として課金されます。 これらのコストは、Microsoft Fabric Capacity Metrics アプリで監視および管理でき、個別の項目として表示されます。

関連するすべてのディザスター リカバリー コストの、それに応じた計画と予算の作成に役立つ、詳細な内訳については、「OneLake のコンピューティングとストレージの消費量」を参照してください。

ディザスター リカバリーを設定する

Fabric にはデータの回復性をサポートするディザスター リカバリー機能が用意されていますが、中断時にサービスを復元するには、特定の手動の手順に従う必要があります。 このセクションでは、潜在的な中断に備えるために実行する必要があるアクションについて詳しく説明します。

フェーズ 1: 準備

• ディザスター リカバリー容量の設定を有効にする: ディザスター リカバリー容量の設定を定期的に確認して設定し、保護とパフォーマンスのニーズを満たしていることを確認します。

• データ バックアップの作成: ディザスター リカバリー計画に合わせた形で、OneLake の外部に格納されている重要なデータを別のリージョンにコピーします。

フェーズ 2: 障害時のフェールオーバー

大規模な障害によりプライマリ リージョンが回復不能になった場合、Microsoft Fabric はリージョンのフェールオーバーを開始します。 フェールオーバーが完了し、Microsoft Fabric サポート ページに通知が投稿されるまで、Fabric ポータルにはアクセスできません。

フェールオーバーが完了するまでにかかる時間はさまざまですが、通常は 1 時間未満です。 フェールオーバーが完了したら、次のことが予期されます。

• Fabric ポータル: ポータルにはアクセスでき、既存のワークスペースや項目の参照などの読み取り操作は引き続き機能します。 ワークスペースの作成や変更などのすべての書き込み操作は一時停止されます。

• Power BI: ダッシュボードやレポートの表示などの読み取り操作を実行できます。 更新、レポートの発行操作、ダッシュボードとレポートの変更、メタデータの変更が必要なその他の操作はサポートされていません。

• レイクハウス/ウェアハウス: これらの項目を開くことはできませんが、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 データにアクセスする」を参照してください

フェーズ 3: 復旧計画

Fabric は障害発生後もデータにアクセスできることを保証しますが、サービスをインシデント前の状態に完全に復元させるようにすることもできます。 このセクションでは、回復プロセスを実行するのに役立つステップ バイ ステップ ガイドを提供します。

回復後の手順

1. 障害発生後、任意のリージョンに新しい Fabric 容量を作成します。 このようなイベント中の需要が高いことを考えると、コンピューティング サービスの可用性を高めるために、プライマリ geo の外部のリージョンを選ぶことをお勧めします。 容量の作成については、「Microsoft Fabric サブスクリプションを購入する」を参照してください。

2. 新しく作成した容量にワークスペースを作成します。 必要に応じて、古いワークスペースと同じ名前を使います。

3. 回復する項目と同じ名前の項目を作成します。 この手順は、カスタム スクリプトを使ってレイクハウスやウェアハウスを回復する場合に重要です。

4. 項目を復元します。 各項目について、「エクスペリエンス固有のディザスター リカバリーのガイダンス」の関連セクションに従って項目を復元します。

次のステップ

• エクスペリエンス固有のディザスター リカバリーのガイダンス
• Azure での信頼性