この記事では、モノのインターネット (IoT) ソリューションで接続デバイス数のスケールアップをサポートする "デプロイ スタンプ" 戦略について説明します。 記事では、デプロイ スタンプ間で IoT デバイスとアプリケーションをデプロイする方法も詳しく説明します。
IoT ソリューションのデプロイ スタンプ戦略は、デプロイ スタンプの設計パターンに基づいています。 デプロイ スタンプは、定義されたデバイス群をサポートする異種コンポーネントで構成されるユニットです。 デプロイ スタンプでは、ソリューションのさまざまな部分を個別にスケールアップするのではなく、スタンプをレプリケートすることで、接続されている IoT デバイスの数をスケールアップします。
デプロイ スタンプの利点:
- geo 依存関係、ライフサイクル、リリースの状態など、条件に基づいてデバイスを配置および配布します。
- 停止またはサービスの低下の影響を特定のスタンプに限定します。
- 新しい機能、アーキテクチャの変更を、それらをサポートできる特定のスタンプにデプロイします。
- 機能とサービスを、指定されたデバイス群に合わせて調整することで、複数世代のデバイス管理をサポートします。
- 将来の成長に予測可能な形で対応するために、スタンプに基づくスケーリングとコストのモデルを提供します。
IoT デプロイ スタンプのアーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
上の図は、Azure IoT におけるデプロイ スタンプ戦略を示しています。 このソリューションでは、それぞれが以下で構成されるアトミック スタンプを構築します。
- Azure IoT Hub
- Azure Event Hubs のようなルーティング エンドポイント
- 処理コンポーネント
スタンプは必ず、明示的な容量に対応できるよう設計する必要があります。 サポートするデバイスの適切な数を決定するには、予想されるデバイスからの通信トラフィック量を検討します。 このソリューションでは、各スタンプで最適にサポートされるのは、1,000 から 1,000,000 デバイスで定義されたデバイス群です。 デバイス群が増加するにつれて、スタンプ インスタンスの追加により増加に対応します。
スタンプ間でデバイスとアプリケーションを移動する
デプロイ スタンプはアトミックなデプロイを意図したものですが、スタンプ間でデバイス群を移動することが必要になる場合があります。 たとえば、次のことが必要になる場合があります。
- リリース サイクルの一環として、テスト スタンプから運用スタンプにデバイス群を移動する。
- 高可用性シナリオにおいて、障害修復の一環としてデバイスとユーザーを別のスタンプに移動する。
- 負荷分散によって、スタンプ間でデバイス群をより均等に分散する。
ハブ間でデバイスを移動する
スタンプ コンポーネントに含まれるのが device-to-cloud 動作だけの場合は、ハブ間でデバイスを移動するだけで、スタンプ間でのデバイス移行に対応できます。 Azure IoT Device Provisioning Service (DPS) は、IoT Hub インスタンス間でデバイスを移動する方法を提供します。 スタンプ戦略で DPS を使用するには、IoT Hub Device Provisioning Service (DSP) の用語と概念について理解しておく必要があります。
注意
DPS に使用されるのは "登録 ID" ですが、IoT Hub に使用されるのは "デバイス ID" です。 多くの場合、これらの ID は同じ値ですが、異なることもあります。 DPS API を使用してデバイスに対してクエリを実行する、またはデバイスを管理する場合は、必ず登録 ID を使用してください。
自己完結型スタンプ間でデバイスとアプリケーションを移動する
デプロイ スタンプに、IoT Hub 経由で通信する Web フロントエンドまたは API アプリケーションが含まれている場合は、移動されたデバイスと引き続き通信できるように、これらのコンポーネントも新しいハブに移行する必要があります。 スタンプ間でアプリケーションとデバイス全体を移動できます。
各スタンプにエンドツーエンド アプリケーションが含まれている場合、Azure Traffic Manager によってスタンプ間でトラフィックを移動できます。 この戦略では、複数のスタンプを作成し、それぞれに独自の URL を持つアプリケーション全体を含めるようにします。 デバイスとアプリケーション ユーザー群全体が、あるスタンプから別のスタンプに移動します。
この完全自己完結型の戦略の特徴は次のとおりです。
- 実装が簡単。
- 高可用性戦略の一環として適切。
- デバイスとユーザーをテスト環境から運用環境に移行する場合に便利。
このアーキテクチャの Visio ファイルをダウンロードします。
上の図は、スタンプ 1 からスタンプ 2 に一連のデバイスを移動するプロセスを示しています。
- デバイスは、IoT Hub エンドポイントが不明または無効になっている場合、DPS 経由でそれを取得します。
- デバイスをスタンプ 2 に移動すると、Traffic Manager により、アプリケーション URL がアプリケーション 2 のインスタンスを指すように設定されます。
- DPS により、デバイス セット全体がスタンプ間で移動されます。
- 各アプリケーション スタンプには、アプリケーションのフロントエンドが含まれ、そのスタンプに対応する IoT Hub が参照されます。
1 つのアプリ ゲートウェイの背後のスタンプ間でデバイスを移動する
1 つのアプリケーション フロントエンドで複数のデバイス スタンプがサポートされている場合、アプリケーション フロントエンドは、cloud-to-device 通信を維持するために、デバイスとハブのマッピングを動的に更新する必要があります。 ゲートウェイでは、異なるスタンプおよび IoT Hub に移動するデバイスをサポートするために、デバイスとハブのマッピングでキャッシュ メカニズムを使用できます。 サービス クライアントは、共有検索ルーチンを使用して、デバイス呼び出しを動的に検出し、新しい IoT Hub に移行できます。
このアーキテクチャの Visio ファイルをダウンロードします。
このモデルでは、ゲートウェイはキャッシュを使用してデバイスを IoT Hub にマップします。既定では、キャッシュされたエンドポイントになります。 ゲートウェイは、デバイスが見つからないというエラーを受け取った場合、DPS サービス SDK を使用して個々のデバイス登録のクエリを実行し、デバイスで現在使用している IoT Hub を特定します。 ゲートウェイはその後、新しいマッピングでキャッシュを更新します。
この戦略の考慮点は次のとおりです。
共有検索のキャッシュによって、すべての呼び出しでエンドポイントの再ネゴシエーションが行われることはなくなりますが、キャッシュ エンドポイントがエラーになる可能性があります。 DPS を使用した再ネゴシエーションのフォールバック プランまたはセカンダリ キャッシュによって、ソリューションの信頼性を向上させることができます。
デバイス登録が進行中の場合、そのデバイスにはアクセスできません。 デバイスの登録状態の取得などの DPS API を使用して、デバイスに割り当てられた IoT Hub とその現在の登録状態を取得します。
デバイスのみの場合、デバイスがあるスタンプから別のスタンプに移動されると、それらは IoT Hub から切断されます。 アプリケーションからデバイスへの接続の場合、アプリが IoT Hub を介してデバイスに接続しようとしたときにエラーが発生します。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- ジェイソン・ワズワース | プリンシパル ソフトウェア エンジニア