IoT Hub の高可用性とディザスター リカバリー

  • [アーティクル]

回復力のある IoT ソリューションを実装するための第一歩として、設計者、開発者、経営者は、構築しているソリューションのアップタイム目標を定義する必要があります。 この目標は、主にシナリオごとの細かい事業目標に基づいて定義できます。 このような背景から、このAzure ビジネス継続性テクニカル ガイダンスに関する記事では、ビジネス継続性とディザスター リカバリーについて考慮する際に役立つ一般的なフレームワークについて説明しています。 「Disaster recovery and high availability for Azure applications」(Azure アプリケーションのディザスター リカバリーと高可用性) では、高可用性 (HA) とディザスター リカバリー (DR) を実現するための Azure アプリケーションの戦略に関するアーキテクチャのガイダンスを確認できます。

この記事では、特に IoT Hub サービスによって提供されている HA および DR の機能について説明します。 この記事では、次のように幅広い分野について取り上げています。

  • リージョン内 HA
  • リージョン間 DR
  • リージョン間 HA の達成

IoT ソリューションに定義するアップタイム目標に応じて、この記事で説明するオプションから、事業目標に最適なものを判断することをお勧めします。 こうした HA/DR の代替方法のいずれかを IoT ソリューションに組み込むには、以下の条件間のトレードオフを慎重に評価する必要があります。

  • 必要な回復性のレベル
  • 実装とメンテナンスの複雑さ
  • COGS への影響

リージョン内 HA

IoT Hub サービスは、サービスのほぼすべてのレイヤーに冗長性を実装することで、リージョン内 HA を提供しています。 IoT Hub サービスで発行されている SLA は、これらの冗長性を利用することで達成されます。 これらの HA 機能を利用するために、IoT ソリューションの開発者が追加の作業を行う必要はありません。 IoT Hub ではかなり高いアップタイムが保証されていますが、分散コンピューティング プラットフォームの場合と同様に一時的な障害が発生する可能性があります。 ソリューションをオンプレミス ソリューションからクラウドに移行し始めたばかりの場合は、重視する点を "平均失敗間隔" の最適化から "平均回復時間" の最適化に移す必要があります。 言い換えると、混在環境のクラウドで運用している場合、一時的な障害は正常とみなされます。 一時的な障害に対処するには、クラウド アプリケーションと対話するコンポーネントに適切な再試行パターンを組み込む必要があります。

可用性ゾーン

IoT Hub は Azure 可用性ゾーンをサポートしています。 可用性ゾーンとは、アプリケーションとデータをデータセンターの障害から保護する高可用性オファリングです。 可用性ゾーンをサポートするリージョンは、そのリージョンをサポートする 3 つのゾーンで構成されます。 それぞれのゾーンの一意の物理的な場所に、1 つまたは複数のデータセンターがあり、独立した電源、冷却手段、ネットワークを備えています。 この構成により、リージョン内でレプリケーションと冗長性が確保されます。

可用性ゾーンには、データの回復性とよりスムーズなデプロイという 2 つの利点があります。

"データの回復性"は、基になるストレージ サービスを、可用性ゾーンがサポートされているストレージに置き換えることで生まれます。 IoT ソリューションではデータの回復性が重要です。これらのソリューションは、多くの場合、複雑かつ動的で、不確実な環境で動作しており、障害や中断によって重大な影響が及ぼされる可能性があるためです。 IoT ソリューションによるサポート対象が製造現場か、小売やレストランの環境か、医療システムか、またはインフラストラクチャかどうかに関係なく、障害から復旧し、信頼性のある一貫したサービスを提供するためには、データの可用性と品質が必要です。

"よりスムーズなデプロイ"は、基になるデータセンター ハードウェアを、可用性ゾーンがサポートされている新しいハードウェアに置き換えることで実現します。 これらのハードウェアの機能強化により、デバイスの切断と再接続によるお客様への影響と、その他のデプロイ関連のダウンタイムが最小限に抑えられます。 IoT Hub エンジニアリング チームは、セキュリティ上の理由と機能強化の両方の目的で、毎月各 IoT ハブに複数の更新プログラムをデプロイしています。 可用性ゾーンがサポートされているハードウェアは 15 個の更新ドメインに分割されるため、各更新はよりスムーズになり、ワークフローへの影響は最小限に抑えられます。 更新ドメインの詳細については、可用性セットに関するページを参照してください。

IoT Hub の可用性ゾーンのサポートは、次の Azure リージョンで作成された新しい IoT Hub のリソースに対して自動的に有効になります。

リージョン データの回復性 よりスムーズなデプロイ
オーストラリア東部
ブラジル南部
カナダ中部
インド中部
米国中部
米国東部
フランス中部
ドイツ中西部
東日本
韓国中部
北ヨーロッパ
ノルウェー東部
カタール中部
米国中南部
東南アジア
英国南部
西ヨーロッパ
米国西部 2
米国西部 3

リージョン間 DR

停電やその他の物理的な資産の不具合により、データセンターに長時間の停止が発生する場合があります。 このようなイベントはまれであり、その間に、前述のリージョン内 HA 機能があっても常に役立つとは限りません。 IoT Hub には、このような長時間の停止から回復するための複数のソリューションが用意されています。

このような状況でお客様が利用できる回復オプションは、Microsoft が開始するフェールオーバーと手動フェールオーバーです。 この 2 つの根本的な違いは、前者は Microsoft が開始し、後者はユーザーが開始する点です。 また、Microsoft が開始するフェールオーバー オプションと比較して、手動フェールオーバーは目標復旧時間 (RTO) が短くなります。 各オプションで指定する具体的な RTO については、以下のセクションで説明します。 いずれかのオプションを使用してプライマリ リージョンから IoT ハブのフェールオーバーを実行すると、対応する Azure geo ペア リージョンでそのハブは完全に機能します。

これらのいずれのフェールオーバー オプションにも、次の回復ポイントの目標 (RPO) が提供されています。

データ型 回復ポイントの目標 (RPO)
ID レジストリ 0 ～ 5 分間のデータ損失
デバイス ツイン データ 0 ～ 5 分間のデータ損失
クラウドからデバイスへのメッセージ1 0 ～ 5 分間のデータ損失
親1とデバイスのジョブ 0 ～ 5 分間のデータ損失
デバイスからクラウドへのメッセージ すべての未読メッセージが失われる
クラウドからデバイスへのフィードバック メッセージ すべての未読メッセージが失われる

1 cloud-to-device メッセージと親ジョブは、手動フェールオーバーの一部として回復されません。

IoT Hub のフェールオーバー操作が完了すると、デバイスおよびバックエンド アプリケーションからのすべての操作は、機能し続けることが期待されます。手動操作は必要ありません。 これは、device-to-cloud メッセージが引き続き動作するはずであり、デバイス レジストリ全体が破損していないことを意味します。 Event Grid から発行されたイベントは、Event Grid のサブスクリプションを引き続き利用できる限り、以前に構成されたその同じサブスクリプションから使用できます。 カスタム エンドポイントに対して追加の処理は必要ありません。

注意事項

  • その IoT Hub の組み込みイベント エンドポイントの Event Hubs 互換の名前とエンドポイントは、フェールオーバー後に変更されます。 Event Hubs クライアントまたはイベント プロセッサ ホストを使用して組み込みエンドポイントからテレメトリ メッセージを受信する場合は、その IoT ハブの接続文字列を使用して接続を確立する必要があります。 これにより、フェールオーバー後に手動操作することなく、バックエンド アプリケーションは継続的に動作します。 アプリケーションでイベント ハブと互換性のある名前とエンドポイントを直接使用する場合、フェールオーバー後も運用を継続するには、新しいイベント ハブと互換性のあるエンドポイントをフェッチする必要があります。 詳細については、「手動フェールオーバーとイベント ハブ」を参照してください。
  • Azure Functions または Azure Stream Analytics を使用して組み込みイベント エンドポイントを接続する場合は、再起動が必要になる場合があります。 これは、フェールオーバー中に以前のオフセットが無効になるためです。
  • ストレージにルーティングするときは、パーティションを想定せずにすべての BLOB またはファイルを確実に読み取るために、BLOB またはファイルの一覧を取得したうえでそれらを反復処理することをお勧めします。 Microsoft が開始するフェールオーバー中や手動フェールオーバー中にパーティションの範囲が変化する可能性があります。 List Blobs API を使用して BLOB の一覧を、または List ADLS Gen2 API を使用してファイルの一覧を列挙できます。 詳細については、「ルーティング エンドポイントとしての Azure Storage」を参照してください。

Microsoft が開始するフェールオーバー

Microsoft が開始するフェールオーバーは、Microsoft によって実行されます。まれではありますが、影響を受けるリージョンのすべての IoT ハブは、対応する geo ペア リージョンにフェールオーバーされます。 このプロセスは既定のオプションであり、ユーザー操作は必要はありません。 Microsoft は、このオプションを実行するタイミングを決定する権利を留保します。 このメカニズムでは、ユーザーのハブがフェールオーバーされる前にユーザーの同意を必要としません。 Microsoft が開始するフェールオーバーには、2 時間から 26 時間の目標復旧時間 (RTO) があります。

RTO が大きい値なのは、Microsoft がそのリージョンの影響を受けるすべてのお客様に代わってフェールオーバー操作を実行する必要があるためです。 約 1 日のダウンタイムに耐えうる、あまり重要ではない IoT ソリューションを実行している場合は、IoT ソリューションの全体的なディザスター リカバリー目標を満たすために、このオプションを利用しても問題ありません。 このプロセスがトリガーされた後、ランタイム操作が完全に使用できるようになるまでの合計時間については、「回復時間」を参照してください。

この機能をオプトアウトできるのは、ブラジル南部と東南アジア (シンガポール) のリージョンに IoT ハブをデプロイしているユーザーのみです。 詳細については、「ディザスター リカバリーを無効にする」を参照してください。

Note

Azure IoT Hub によって、サービス インスタンスをデプロイする地域の外部に顧客データが格納されたり、処理されたりすることはありません。 詳細については、Azure でのリージョン間レプリケーションに関するページを参照してください。

手動フェールオーバー

Microsoft が開始するフェールオーバーで指定されている RTO ではビジネスのアップタイム目標が満たされない場合は、手動フェールオーバーを使用してフェールオーバー処理を開始することを検討してください。 このオプションを使用する場合の RTO は、10 分から数時間の間の任意の時間にすることができます。 現在、RTO は、フェールオーバーされている IoT ハブ インスタンスに対して登録されているデバイス数の関数です。 約 100,000 台のデバイスをホストしているハブの RTO は約 15 分であると想定できます。 このプロセスがトリガーされた後、ランタイム操作が完全に使用できるようになるまでの合計時間については、「回復時間」を参照してください。

プライマリ リージョンでダウンタイムが発生しているかどうかにかかわらず、手動フェールオーバー オプションは常に使用できます。 そのため、このオプションは、計画されたフェールオーバーを実行する場合にも使用することができます。 計画されたフェールオーバーの使用例の 1 つとして、定期的なフェールオーバー ドリルを実行する場合です。 ただし、計画されたフェールオーバー操作により、このオプションの RTO で定義された期間にハブのダウンタイムが発生し、前述の RPO の表で定義されたデータ損失が発生する点にも注意してください。 実際の災害が発生したときにエンドツーエンドのソリューションが稼動することを確認するために、計画されたフェールオーバー オプションを定期的に実行するように、テスト IoT Hub インスタンスを設定することをお勧めします。

2017 年 5 月 18 日より後に作成された IoT ハブでは、追加料金なしで手動フェールオーバーを利用できます

詳細な手順については、チュートリアル:IoT ハブの手動フェールオーバーを実行する

手動フェールオーバーと Event Hubs

IoT Hub の組み込みイベント エンドポイントの Event Hubs 互換の名前とエンドポイントは、手動フェールオーバー後に変更されます。 これは、Event Hubs クライアントから IoT Hub イベントを確認できないためです。 これは、他のクラウドベースのクライアント (Functions や Azure Stream Analytics など) にも当てはまります。 エンドポイントと名前を取得するには、Azure portal または .NET SDK を使用できます。

ポータルの使用

ポータルを使用して、イベント ハブ互換性エンドポイントとイベント ハブと互換性がある名前を取得する方法の詳細については、「組み込みのエンドポイントに接続する」を参照してください。

.NET SDK を使用する

IoT Hub の接続文字列を使って Event Hubs 互換エンドポイントを再キャプチャするには、https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs にあるサンプルを使います。 このコード例では、接続文字列を使って新しい Event Hubs エンドポイントを取得し、接続を再確立します。 Visual Studio をインストールする必要があります。

テスト ドリルを実行する

運用環境で使用されている IoT Hub では、テスト ドリルを実行しないでください。

手動フェールオーバーを使用して IoT ハブを別のリージョンに移行しない

手動フェールオーバーは、Azure の geo ペア リージョン間でハブを永続的に移行するメカニズムとして使用 "しない" でください。 デバイスがハブのプライマリ リージョンに最も近い場所に配置されている場合、ハブがセカンダリ リージョンにフェールオーバーすると、IoT ハブに対して実行される操作の待機時間が長くなります。

フェールバック

フェールオーバー アクションをもう一度トリガーすることで、以前のプライマリ リージョンにフェールバックできます。 元のプライマリ リージョンで長時間の停止から回復するために、元のフェールオーバー操作が実行された場合、その場所が停止状態から回復した後にハブを元の場所にフェールバックすることをお勧めします。

重要

  • 1 日に 2 回の正常なフェールオーバーと 2 回の正常なフェールバック操作のみを実行できます。
  • バックからバックへのフェールオーバー/フェールバック操作は許可されていません。 これらの操作の間に 1 時間待機する必要があります。

回復時間

IoT Hub インスタンスの FQDN (したがって接続文字列も) はフェールオーバー後も同じままですが、基の IP アドレスは変更されます。 フェールオーバー プロセス後に、IoT Hub インスタンスに対して実行されるランタイム操作が完全に機能するようになるまでの時間は、次の関数を使って表すことができます。

回復時間 = RTO [手動フェールオーバーの場合は 10 分から 2 時間 | Microsoft が開始するフェールオーバーの場合は 2 時間から 26 時間] + DNS 伝達遅延時間 + クライアント アプリケーションでキャッシュされている IoT Hub IP アドレスを更新するためにかかる時間。

重要

IoT SDK は、IoT Hub の IP アドレスをキャッシュしません。 SDK とのインターフェイスがあるユーザー コードの場合、IoT Hub の IP アドレスをキャッシュしないことをお勧めします。

ディザスター リカバリーを無効にする

IoT Hub は、データを各 IoT ハブのペア リージョンにレプリケートすることで、Microsoft が開始するフェールオーバーと手動フェールオーバーを提供します。 一部のリージョンでは、IoT ハブを作成するときにディザスター リカバリーを無効にすることで、リージョンの外部でのデータ レプリケーションを回避できます。 次のリージョンがこの機能をサポートしています。

  • ブラジル南部。ペア リージョン、米国中南部。
  • 東南アジア (シンガポール)。ペア リージョン、東アジア (香港特別行政区)。

サポートされているリージョンでディザスター リカバリーを無効にするには、IoT ハブを作成するときに [Disaster recovery enabled] (ディザスター リカバリーが有効) がオフになっていることを確認してください。

シンガポール リージョンの IoT ハブのディザスター リカバリー オプションを示すスクリーンショット。

ARM テンプレートを使用して IoT ハブを作成するときにディザスター リカバリーを無効にすることもできます。

IoT ハブのディザスター リカバリーを無効にした場合、フェールオーバー機能は使用できません。

シンガポール リージョンの IoT ハブのディザスター リカバリーが無効になっている様子を示すスクリーンショット。

ペア リージョンの外部でのデータ レプリケーションを回避するために、IoT ハブを作成するときにディザスター リカバリーを無効にできるのは、ブラジル南部または東南アジアのみです。 ディザスター リカバリーを無効にするように既存の IoT ハブを構成する場合は、ディザスター リカバリーを無効にして新しい IoT ハブを作成し、既存の IoT ハブを手動で移行する必要があります。 ガイダンスについては、「IoT ハブを移行する方法」を参照してください。

リージョン間 HA を達成する

Microsoft が開始するフェールオーバーまたは手動フェールオーバーのオプションで指定される RTO によってビジネスのアップタイム目標が満たされない場合は、デバイスごとの自動リージョン間フェールオーバーのメカニズムを実装することを検討してください。 IoT ソリューションでのデプロイ トポロジの詳しい説明はこの記事の範囲外です。 この記事では、高可用性とディザスター リカバリーのための "リージョン内フェールオーバー" デプロイ モデルについて検討します。

地域フェールオーバー モデルの場合、ソリューション バック エンドは主に 1 つのデータセンターの場所で実行されます。 セカンダリ IoT ハブとバック エンドは、別のデータセンターの場所にデプロイされています。 プライマリ リージョンの IoT ハブに障害が発生した場合、またはデバイスからプライマリ リージョンへのネットワーク接続が中断された場合、デバイスはセカンダリ サービス エンドポイントを使用します。 1 つのリージョン内ではなく、リージョン間フェールオーバー モデルを実装することで、ソリューションの可用性を改善できます。

大まかに言えば、IoT Hub で地域フェールオーバー モデルを実装するには、次の手順を実行する必要があります。

  • セカンダリ IoT Hub とデバイス ルーティングのロジック:プライマリ リージョンでサービスの中断が発生した場合、セカンダリ リージョンへのデバイスの接続を開始する必要があります。 関連するサービスのほとんどが状態認識型の場合、ソリューションの管理者がリージョン間のフェールオーバー プロセスをトリガーするのはよくあることです。 プロセスの制御を維持しながら、新しいエンドポイントをデバイスに伝達する最善の方法は、 コンシェルジェ" サービスで、現在のアクティブなエンドポイント サービスがないかどうかを定期的にチェックすることです。 コンシェルジェ サービスは Web アプリケーションで、DNS リダイレクト手法 (Azure Traffic Manager など) を使用してレプリケートされ、到達可能な状態が保持されます。

    注意

    Azure Traffic Manager では、IoT Hub サービスはサポートされているエンドポイントの種類ではありません。 エンドポイントの正常性プローブ API を実装して、提案されたコンシェルジュ サービスを Azure Traffic Manager に統合することをお勧めします。

  • ID レジストリ レプリケーション:使用するには、ソリューションに接続できるすべてのデバイス ID をセカンダリ IoT ハブに格納する必要があります。 ソリューションでは、デバイス ID の geo レプリケートされたバックアップを保持し、デバイスのアクティブなエンドポイントを切り替える前に、そのバックアップをセカンダリ IoT ハブにアップロードしなければなりません。 IoT Hub のデバイス ID エクスポート機能は、この点で役に立ちます。 詳細については、IoT Hub 開発者ガイドの ID レジストリに関するページを参照してください。

  • マージ ロジック:再度プライマリ リージョンが使用可能になった時点で、セカンダリ サイトで作成されたすべての状態とデータをプライマリ リージョンに移行する必要があります。 状態とデータは主にデバイス ID およびアプリケーション メタデータと関連しており、プライマリ IoT ハブとマージする必要があります。また、プライマリ リージョンにある他のアプリケーション固有のストアとのマージが必要になることもあります。

この手順を簡単にするには、べき等操作を使用する必要があります。 べき等操作により、最終的に一貫性のあるイベント分布だけでなく、イベント重複や順不同配信の副次的な影響を最小限に抑えられます。 また、アプリケーション ロジックは、潜在的な不整合を許容するように、あるいはやや時代遅れに設計する必要があります。 これは、回復ポイントの目標 (RPO) に基づいてシステムが回復するために追加の時間がかかるためです。

適切な HA/DR オプションを選択する

この記事で説明した HA/DR のオプションの概要です。実際のソリューションに適したオプションを選択する際の基準の枠組みとして利用してください。

HA/DR のオプション RTO RPO 手動操作が必要? 実装の複雑さ コストの影響
Microsoft が開始するフェールオーバー 2 - 26 時間 前述の RPO の表を参照してください いいえ なし なし
手動フェールオーバー 10 分 - 2 時間 前述の RPO の表を参照してください はい 非常に低い。 この操作は、ポータルからトリガーする必要があります。 なし
リージョン間 HA < 1 分 カスタム HA ソリューションのレプリケーション頻度によって変わります いいえ 高 > 1 IoT Hub のコストの 1 倍

次のステップ