Azure IoT ソリューションをスケールアウトして何百万台ものデバイスをサポートする

[アーティクル]
10/14/2024

この記事では、スケールアウトパターンを使用してモノのインターネット (IoT) ソリューションをスケーリングする方法について説明します。スケールアウトパターンを使用すると、インスタンスのサイズを大きくするのではなく、インスタンスをデプロイに追加することで、スケーリングの課題を解決できます。ここでは、実装ガイダンスとして、数百万台ものデバイスで IoT ソリューションをスケーリングする方法と、Azure でのサービスとサブスクリプションの制限について説明する方法を示します。この記事では、ニーズに合わせて採用できるスケールアウトパターンのロータッチデプロイモデルとゼロタッチデプロイモデルの概要について説明します。詳細と例については、次の記事をご覧ください。

Note

このドキュメントでは、ホスティング Kubernetes プラットフォーム構成に基づいてスケーリングされる Azure IoT Operations プラットフォームについては説明しません。

要件を集める

新しい IoT ソリューションを実装する前には、必ず要件を収集する必要があります。要件から始めておくと、実装と事業目標が確実に合致するようになります。事業目標と運用環境によって、収集が必要な要件が決まってきます。少なくとも、次の要件を把握しておく必要があります。

展開するデバイスの種類を把握します。 IoT には、単純なマイクロコントローラー (MCU) から中規模のシステムオンチップ (SOC) やマイクロプロセッサ (MPU) のソリューション、さらには完全な PC レベルの設計に至るまで、幅広いソリューションがあります。デバイス側のソフトウェアの機能が、ソリューションの設計に直接影響します。

展開する必要があるデバイスの台数を把握します。 IoT ソリューションの実装に関する基本原則の一部は、すべてのスケールで適用されます。スケールを把握しておくと、必要以上に複雑なソリューションを設計せずに済みます。 1,000 台のデバイスを対象とするソリューションと、100 万台のデバイスを対象とするソリューションは、根本的に違います。ソリューションの設計を開始したときにターゲットのスケールが考慮されていなかった場合、10,000 台のデバイスを対象とした概念実証 (PoC) ソリューションが 1,000 万台のデバイスに適切にスケーリングされることはないでしょう。

展開する必要があるデバイスの台数を把握しておけば、適切な Azure IoT サービスを選択できます。 IoT Hub と IoT Hub Device Provisioning Service (DPS) では、スケーリングが異なります。設計上、1 つの DPS インスタンスは複数の IoT Hub インスタンスにルーティングできます。そのため、各サービスのスケールは、デバイスの台数に応じて個別に考慮する必要があります。ただし、バキュームには制限が存在しません。 1 つのサービスで制限が問題となっている場合、通常それは別のサービスでの問題です。そのため、サービスの制限は、それぞれ異なってはいても関連しているクォータとして考えるべきです。

予想されるデバイスの場所を文書化します。物理的な場所に限らず、電源の有無やインターネットの接続性も含まれます。 1 つの地域 (たとえば、北米のみ) にデプロイされるソリューションは、全世界向けのソリューションとは異なります。同様に、電力を常時使用できる工場にデプロイされた産業用 IoT ソリューションは、電力の状況や場所がさまざまに変化する自動車にデプロイされたフリート管理ソリューションとは異なります。また、使用するプロトコルに加え、ゲートウェイへの、または直接クラウドサービスへのデバイス通信に利用できる帯域幅は、各レイヤーでの設計スケーラビリティに影響します。この側面で見落とすのは、接続状況という点です。デバイスが Azure に接続されたままの状態を想定していますか? または、長期間にわたって切断モードで動作するのでしょうか?

データの地域的要件を調査します。ソリューションのデータ (テレメトリなど) やメタデータ (存在しているデバイスなど、データに関するデータ) を格納できる場所に対しては、法的要件、コンプライアンス要件、顧客要件があります。これらの制限が存在する場合、ソリューションの地域的設計に対して重要な情報となります。

データ交換要件を決定します。基本的なテレメトリ ("現在の気温" など) を 1 時間ごとに送信するソリューションは、10 分ごとに 1 MB のサンプルファイルをアップロードするソリューションとは異なります。主に 1 方向のソリューションである device-to-cloud (D2C) ソリューションは、device-to-cloud であり cloud-to-device (C2D) でもある双方向のソリューションとは異なります。また、製品のスケーラビリティの制限によって、メッセージサイズとメッセージ量は、異なるディメンションとして扱われます。

予想される高可用性とディザスターリカバリー要件を文書化します。運用ソリューションと同様に、完全な IoT ソリューションの設計には、可用性 (アップタイム) の要件が含まれます。この設計では、計画メンテナンスのシナリオと計画外のダウンタイム (ユーザーエラー、環境要因、ソリューションのバグなど) の両方をカバーする必要があります。また、このような設計には、リージョンの恒久的な喪失や悪意のあるアクターなどの障害が発生した場合の目標復旧時点 (RPO) と目標復旧時間 (RTO) を文書化しておく必要があります。この記事では、デバイスのスケールに焦点を当てているため、高可用性とディザスターリカバリー (HA/DR) の問題については、限られた情報のみを示しています。

顧客テナントモデル (該当する場合) を決定します。マルチテナント独立系ソフトウェアベンダー (ISV) ソリューションは、ソリューション開発者が外部の顧客のためにソリューションを作成するというものであり、設計では顧客データを分離および管理する方法を考慮する必要があります。 Azure アーキテクチャセンターでは、、一般的なパターンについて説明するとともに、IoT 固有のガイダンスについて説明しています。

Azure IoT の概念について

ソリューションの作成には、サポートしているサービスを含め、ソリューションの一部として使用する Azure IoT コンポーネント (およびサポートしている他の Azure サービス) の選択がその一環として挙げられます。アーキテクチャの観点から大きな取り組みを行います。これが、このドキュメントの焦点です。 Azure IoT Hub サービスと Azure IoT Hub DPS サービスを適切に使用することで、何百万台ものデバイスにソリューションをスケーリングできるようになります。

Azure IoT Hub

Azure IoT Hub は、クラウドでホストされる管理サービスです。IoT アプリケーションとそこに接続されたデバイスとの間における通信において、中央のメッセージハブとしての役割を担います。これは、単独での使用も、Azure IoT Hub DPS との併用も可能です。

Azure IoT Hub を使用すると、必要な機能の組み合わせ、および 1 日あたり必要なメッセージ数または 1 日あたり必要なデータ量に基づいてスケーリングされます。 3 つの入力がインスタンスのスケーリングの選択に使用されます。

レベル (free、Basic、または Standard) によって利用できる機能が決まります。運用環境のインスタンスでは、free レベルを使用しません。スケールが制限されているうえに導入開発シナリオのみを対象としているからです。ほとんどのソリューションでは、Standard レベルを使用して IoT Hub の機能を完全に取得します。
サイズによって、IoT ハブでの device-to-cloud メッセージに対するメッセージとデータスループットの基本単位が決まります。 IoT ハブのインスタンスの最大サイズは、サイズ 3 であり、1 ユニットごとに 1 日あたり 3 億件のメッセージと 1 日あたり 1,114.4 GB のデータをサポートします。
ユニット数によって、サイズに対するスケールの乗数が決まります。たとえば、3 つのユニットは、1 つのユニットのスケールの 3 倍をサポートします。サイズ 1 またはサイズ 2 のハブのインスタンスは 200 ユニット、サイズ 3 のハブのインスタンスは 10 ユニットに制限されています。

サイズとユニット数に関連した 1 日あたりの制限やレベルに関連した一般的な機能の制限以外には、スループットに対する 1 秒あたりの制限があります。また、ソフト制限として、1 つの IoT Hub インスタンスあたりのデバイス数は 100 万台に制限されています。これはソフト制限ですが、ハード制限もあります。制限の引き上げを要求するつもりであっても、将来の問題を回避するために、設計時にソフト制限を設計制限として指定する必要があります。データ交換の要件は、ここでのソリューションをガイドする際に役立ちます。詳細については、他の制限を参照してください。

ソリューションの要件によって、手始めとして、IoT ハブの必要なサイズと数を判断できます。 IoT Hub DPS を使用する場合、Azure は、複数の IoT Hub インスタンス間でのワークロードの分散に役立ちます。

Azure IoT Hub Device Provisioning Service

IoT Hub Device Provisioning Service (DPS) は、IoT Hub のヘルパーサービスです。適切な IoT Hub へのゼロタッチの Just-In-Time プロビジョニングを人間の介入を必要とせずに行うことができます。 Azure サブスクリプションあたり 10 個の DPS インスタンスというハード制限があります。このサービスには、サービスインスタンスごとの 100 万件の登録のハード制限もあります。今後、問題を回避するには、ワークロード設計の制限のサービス制限に対処する必要があります。

DPS のサービスインスタンスは、地理的に配置されますが、既定ではグローバルパブリックエンドポイントが含まれます。特定のインスタンスには ID スコープを通してアクセスされます。インスタンスは特定のリージョンにあり、各インスタンスには独自の ID スコープがあるため、デバイスの ID スコープを構成できる必要があります。

回復性の共有の概念について

回復性の共有には、一時的な障害の処理やデバイスの場所への影響に加え、ISV の場合はサービスとしてのソフトウェア (SaaS) データの回復性など、考慮する必要があるいくつかの重要な概念があります。

一時的な障害の処理について理解します。 運用環境に分散されたソリューションは、オンプレミスかクラウドかにかかわらず、一時的な障害から復旧する機能を備えている必要があります。一時的な障害は、次の理由により、クラウドソリューションで発生する可能性がより高いと考えられる場合があります。

外部プロバイダーへの依存。
デバイスとクラウドサービス間のネットワーク接続への依存。
クラウドサービスの実装制限。

Azure アーキテクチャセンターで説明されているように、一時的な障害の処理を行うには、デバイスコードに再試行機能が組み込まれている必要があります。「一時的な障害の処理」では、複数の再試行戦略が説明されています (ジッターによるエクスポネンシャルバックオフとも呼ばれる、ランダム化によるエクスポネンシャルバックオフなど)。この記事では、それらのパターンについて詳しく説明することはしません。それらについてよく知らない場合は、上記のページをご覧ください。

次のさまざまな要素が、デバイスのネットワーク接続に影響を与える場合があります。

デバイスの電源。バッテリー駆動のデバイスや、一時的な電源 (太陽や風など) を利用するデバイスは、電力線を常時使用するデバイスよりもネットワーク接続性が低い場合があります。
"デバイスを展開する場所"。多くの場合、都市工場環境にあるデバイスは、孤立した野外環境にあるデバイスよりもネットワーク接続に優れています。
デバイスの場所の安定性。多くの場合、モバイルデバイスは場所が固定されたデバイスよりもネットワーク接続が劣ります。

また、これらの問題はすべて、デバイスの可用性と接続のタイミングにも影響を与えます。たとえば、電力線を使用しているが高密度の都市環境に一般的なデバイス (スマートスピーカーなど) の場合、多数のデバイスが一度にオフラインになり、一度にオンラインに戻る場合があります。次のようなシナリオが想定されます。

停電時に、電力網の喪失と再接続により、100 万台のデバイスがすべて同時にオフラインになり、同時にオンラインに戻る場合。このシナリオは、コンシューマーのシナリオ (スマートスピーカーなど) にも、ビジネスや産業での IoT シナリオ (接続して使う電気式のサーモスタットを不動産管理会社に報告する場合など) にも、どちらにも該当します。
多くのコンシューマーが比較的短い間隔でデバイスの電源を入れる場合の短期間の大規模なオンボード (ブラックフライデーやクリスマスなど)。
スケジュールされたデバイスの更新。つまり、短い期間に多くのデバイスが更新プログラムを受信し、そのすべてがほぼ同時に新しい更新プログラムで再起動する場合。

多くのデバイスが同時に再起動するシナリオが原因で、スロットリング (サービスで許可されるトラフィックを制限すること) など、ネットワーク接続が 100% に近いとみなされているシナリオもクラウドサービスの懸念事項の影響を受ける可能性があります。

ネットワークやクォータの問題以外にも、Azure サービスの停止について考慮する必要があります。これは、サービスの停止やリージョン全体での停止である可能性があります。一部のサービス (IoT Hub など) は geo 冗長ですが、他のサービス (DPS など) では 1 つのリージョンにデータを格納します。これによりリージョンの冗長性が制限されているように見えますが、1 つの IoT Hub を複数の DPS インスタンスにリンクできることに気づくのが重要です。

リージョンの冗長性が問題となっている場合は、geode パターンを使用します。これを使用すると、異なる地域間で異種のリソースグループをホストできます。同様に、"デプロイスタンプ" ("スケールスタンプ" とも呼ばれます) を使用すると、複数のワークロードまたはテナントを操作するこのパターンが適用されます。詳細については、「デプロイスタンプパターン」を参照してください。この記事では、デプロイスタンプの IoT 固有の例について説明しています。また、マルチテナントについてのドキュメントでこの記事が参照されています。

デバイスの場所への影響について理解します。 アーキテクトがコンポーネントを選択するときは、グローバルエンドポイントを持つ DPS のようなサービスであっても、ほとんどの Azure サービスがリージョンベースであることを理解しておく必要があります。例外には、Azure Traffic Manager と Microsoft Entra ID があります。そのため、デバイスの場所、データの場所、メタデータ (Azure リソースグループなど、データに関するデータ) の場所に関する決定は、設計における重要な情報となります。

"デバイスの場所"。デバイスの場所の要件は、トランザクション待機時間に影響するため、リージョンの選択に影響します。
"データの場所"。データの場所は、デバイスの場所に関連付けられており、コンプライアンスの問題の対象でもあります。たとえば、米国のある州に関するデータを格納するソリューションには、米国地域内でのデータの格納が必要となる可能性があります。また、その必要性は、データの地域性の要件によっても高まる可能性があります。
"メタデータの場所"。デバイスの場所は通常、メタデータの場所には影響しませんが、デバイスはソリューションメタデータではなくソリューションデータと相互作用するため、コンプライアンスとコストの問題はメタデータの場所に影響します。多くの場合、利便性の理由から、メタデータの場所はリージョンサービスのデータと同じ場所になります。

Azure クラウド導入フレームワークには、リージョンの選択についてのガイダンスが含まれています。

独立系ソフトウェアベンダー (ISV) SaaS の問題について理解します。 SaaS を提供している ISV には、可用性と回復性に対する顧客の期待に応えることが重要です。 ISV は、高可用性を備えた Azure サービスを設計する必要があり、顧客に課金する際の回復性と冗長性のコストを考慮する必要があります。

各ソフトウェア顧客の顧客データの分離に基づいて、売却済商品の原価 (COGS) を分離します。この区別は、エンドユーザーと顧客が同じではない場合に重要です。たとえば、スマートテレビプラットフォームでは、プラットフォームベンダーの顧客がテレビベンダーである可能性がありますが、エンドユーザーはテレビの購入者です。このような分離は、要件から得られる顧客のテナントモデルによって推進され、個別の DPS インスタンスと IoT Hub インスタンスを必要とします。また、プロビジョニングサービスにも、一意のエンドポイントまたは一意のデバイス認証プロセスを通じて示される一意の顧客 ID が必要となります。詳細については、IoT マルチテナントのガイダンスを参照してください。

サポートサービスを利用してコンポーネントをスケールアウトする

IoT ソリューションのスケーリングについて説明する際は、各サービスとその相互関係を確認するのがよいでしょう。 IoT ソリューションは、複数の DPS インスタンス間で、または Azure IoT Hub を使用してスケーリングできます。

複数の DPS インスタンス間でのスケールアウト

DPS サービスに制限がある場合、複数の DPS インスタンスへの拡張が必要となることが多くあります。複数の DPS インスタンス間でデバイスプロビジョニングにアプローチするには、いくつかの方法があります。これは、ゼロタッチプロビジョニングとロータッチプロビジョニングという 2 つの大きなカテゴリに分類されます。

次のすべてのアプローチでは、回復性とスケールアウトに関する前述の "スタンプ" の概念を適用します。このアプローチには、Azure Traffic Manager や新しいリージョン間ロードバランサーなどのツールを使用した複数のリージョンでの Azure App Service のデプロイも含まれています。簡素化のため、次の図では示していません。

(1) 複数の DPS インスタンスを使用したゼロタッチプロビジョニング: ゼロタッチ (自動) プロビジョニングの場合、実証済みの戦略として、デバイスで Web API から DPS ID スコープを要求するという戦略があります。これは、水平方向にスケールアウトされた DPS インスタンス間でデバイスを把握してバランスを取るというものです。このアクションにより、Web アプリは、プロビジョニングプロセスの重要な一部となるため、スケーラブルで高可用性であることが必要となります。この設計には主に 3 つのバリエーションがあります。

次の図は、適切な DPS プールにデバイスをマッピングしてから適切な IoT Hub インスタンスに (標準 DPS の負荷分散メカニズムを介して) マッピングする方法を管理するカスタムプロビジョニング API を使用するという 1 つ目のオプションを示しています。

このデバイスによって、Azure App Service でホストされているプロビジョニング API に対して、DPS ID スコープの要求が要求されます。プロビジョニング API は、永続的なデータベースをチェックし、既存のデバイスインベントリに基づいてデバイスを割り当てるのに最適なインスタンスを確認し、DPS ID スコープを返します。この場合、提案されるデータベースは、各デバイスに割り当てられた DPS を保存し、(リージョン間の高可用性のために) マルチマスター書き込みが可能な Azure Cosmos DB インスタンスです。その後、このデータベースを使用して、すべての適切なメトリック (1 分あたりのプロビジョニング要求数、プロビジョニングされたデバイスの合計台数など) での DPS インスタンス使用量を追跡できます。また、このデータベースでは、必要に応じて、同じ DPS iD スコープで再プロビジョニングを指定することもできます。プロビジョニング API を認証して、不適切なプロビジョニング要求を防ぎます。
デバイスが、割り当てられた ID スコープを持つ DPS に対して要求を行います。 DPS は、IoT ハブを割り当てるデバイスに詳細を返します。
デバイスによって、永続ストレージに ID スコープと IoT ハブの接続情報が格納されます。その場所は、セキュリティで保護された場所 (ID スコープは DPS インスタンスに対する認証の一部であるため) であるのが理想的です。その後、デバイスはこの IoT ハブ接続情報を使用して、システムへの要求をさらに行います。

この設計では、Azure IoT デバイスの一般的な設計として、DPS SDK が含まれていることに加え、DPS 登録プロセスを管理するデバイスソフトウェアが必要です。ただし、この設計は、デバイスソフトウェアのサイズが設計の重要な要素となるマイクロコントローラー環境では好ましくないため、別の設計を行うことになる可能性があります。

(2) プロビジョニング API を使用したゼロタッチプロビジョニング: 2 つ目の設計では、DPS 呼び出しがプロビジョニング API に移動しています。このモデルでは、ほとんどの再試行ロジックと同様に、DPS に対するデバイス認証がプロビジョニング API に含まれています。このプロセスにより、より高度なキューシナリオが可能になり、デバイス自体のより簡単なプロビジョニングコードも使用できる可能性があります。また、割り当てられた IoT ハブをキャッシュして、cloud-to-device メッセージングを高速化することもできます。メッセージは、割り当てられたハブ情報について DPS に問い合わせなくても送信されます。

デバイスは、Azure App Service のインスタンスでホストされているプロビジョニング API に対して要求を行います。プロビジョニング API は、永続的なデータベースをチェックし、既存のデバイスインベントリに基づいてデバイスを割り当てるのに最適なインスタンスを確認し、DPS ID スコープを決定します。この場合、提案されるデータベースは、各デバイスに割り当てられた DPS を保存し、(リージョン間の高可用性のために) マルチマスター書き込みが可能な Azure Cosmos DB インスタンスです。その後、このデータベースを使用して、すべての適切なメトリック (1 分あたりのプロビジョニング要求、プロビジョニングされたデバイスの合計数など) の DPS インスタンスの使用を追跡できます。また、このデータベースでは、必要に応じて、同じ DPS ID スコープを使用して再プロビジョニング要求を指定することもできます。何らかの方法でプロビジョニング API を認証して、不適切なプロビジョニング要求を防ぎます。これは、プロビジョニングサービスで DPS に対して使用しているのと同じ認証 (発行された証明書の秘密キーなど) を使用して行うことができます。ただし、他のオプションも考えられます。たとえば、FTA は、サービス認証プロセスの一環としてハードウェア一意識別子を使用している顧客に協力しました。このデバイス製造パートナーは、データベースに読み込む一意識別子の一覧をデバイスベンダーに定期的に提供しています。そこでは、カスタムプロビジョニング API の背後にあるサービスを参照しています。
プロビジョニング API は、割り当てられた ID スコープを使用して DPS プロビジョニングプロセスを実行し、効果的に DPS プロキシとして機能します。
DPS の結果はデバイスに転送されます。
デバイスは IoT ハブ接続情報を永続的なストレージに保存します。ID スコープは DPS インスタンスに対する認証の一部であるため、理想的にはセキュリティで保護された保存場所に保存されます。デバイスは、その後のシステムへの要求でこの IoT ハブ接続情報を使用します。

この設計では、DPS SDK または DPS サービスを参照する必要がありません。また、デバイスでの DPS スコープの格納や維持が不要になります。プロビジョニングサービスを適切で最終的な顧客 DPS インスタンスに指定できるため、結果として所有権の移転シナリオが可能になります。ただし、これにより、プロビジョニング API では概念上 DPS が多少重複することになるため、理想的ではないかもしれません。

(3) 所有権の移転でのゼロタッチプロビジョニング: 3 つ目に考えられるゼロタッチプロビジョニングの設計では、出荷時に構成されている DPS インスタンスを起点として使用し、その後それを必要に応じて他の DPS インスタンスにリダイレクトします。この設計では、カスタムプロビジョニング API を使用せずにプロビジョニングできますが、DPS インスタンスを追跡して必要に応じてリダイレクトを提供する管理アプリケーションが必要です。

管理アプリケーションの要件には、特定の各デバイスでのアクティブ DPS を追跡する機能が含まれます。 "所有権の移転" シナリオには、このアプローチを使用できます。ここでは、デバイスベンダーが、デバイスの所有権をそのベンダーからデバイスのエンドカスタマーに移転します。

デバイスは、出荷時に構成されている DPS インスタンスに接続され、初期プロビジョニングプロセスを要求します。
デバイスは、目的のターゲット DPS インスタンスを含む初期構成を受信します。
デバイスは、目的のターゲット DPS インスタンスに接続され、プロビジョニングを要求します。
その後、デバイスによって、IoT ハブ接続情報が永続ストレージに格納されます。その場所は、セキュリティで保護された場所であるのが理想的です (ID スコープが DPS インスタンスに対する認証の一部であるためです)。デバイスによって、この IoT ハブ接続情報が利用され、システムへの要求がさらに行われます。

(4) 複数の DPS インスタンスを使用したロータッチプロビジョニング: コンシューマー向けシナリオやフィールド展開チームデバイスなど、場合によっては、ロータッチ (ユーザー支援) プロビジョニングを提供するという選択が一般的です。ロータッチプロビジョニングの例として、インストーラーのスマートフォン上のモバイルアプリケーションや、デバイスゲートウェイ上の Web ベースのアプリケーションなどがあります。この場合、実証済みのアプローチとして、ゼロタッチプロビジョニングプロセスと同じ操作を実行するというアプローチがありますが、デバイスの詳細はプロビジョニングアプリケーションによって転送されます。

管理者は、デバイスに接続するデバイス構成アプリを起動します。
構成アプリは、Azure App Service のインスタンスでホストされているプロビジョニング API に接続して、DPS ID スコープを要求します。プロビジョニング API は、永続的なデータベースをチェックし、既存のデバイスインベントリに基づいてデバイスを割り当てるのに最適なインスタンスを確認し、DPS ID スコープを返します。この場合、提案されるデータベースは、各デバイスに割り当てられた DPS を保存し、(リージョン間の高可用性のために) マルチマスター書き込みが可能な Azure Cosmos DB インスタンスです。その後、このデータベースを使用して、すべての適切なメトリック (1 分あたりのプロビジョニング要求、プロビジョニングされたデバイスの合計数など) の DPS インスタンスの使用率を追跡できます。このデータベースでは、適切な場合に同じ DPS ID スコープで再プロビジョニングを指定することもできます。プロビジョニング API は、不適切なプロビジョニング要求が処理されないように何らかの方法で認証する必要があります。
アプリがプロビジョニング ID スコープをデバイスに返します。
デバイスが、割り当てられた ID スコープを持つ DPS に対して要求を行います。 DPS は、IoT ハブを割り当てるデバイスに詳細を返します。
デバイスは ID スコープと IoT ハブ接続情報を永続的なストレージに保存します。ID スコープは DPS インスタンスに対する認証の一部であるため、理想的にはセキュリティで保護された保存場所に保存します。デバイスはこの IoT ハブ接続情報を使用して、システムへの要求をさらに行います。

この記事では詳しく説明されていない、考えられる他のバリエーションもあります。たとえば、プロビジョニング API を使用したゼロタッチプロビジョニングで前述したように、DPS 呼び出しをプロビジョニング API に移動することで、ここで示すアーキテクチャを構成できます。目標は、各レベルがスケーラブルで構成可能で、容易にデプロイできるようにすることです。

一般的な DPS プロビジョニングガイダンス: この Azure サービスでの一般的なベストプラクティスを表している次の推奨事項を DPS 展開に適用する必要があります。

起動のたびにプロビジョニングしないてください。 DPS ドキュメントでは、起動のたびにプロビジョニングすることがベストプラクティスではないと明記されています。小規模なユースケースの場合、起動のたびにプロビジョニングすることが展開への最短パスであるため、妥当に思えるかもしれません。ただし、数百万台ものデバイスにスケールアップする場合は、DPS がボトルネックになる可能性があります。これは、サービスインスタンスごとの 1 分あたりの登録数が 1,000 件にハード制限されているためです。デバイス登録状態の参照さえも、1 秒あたりのポーリング操作回数が 5 から 10 回に制限されているため、ボトルネックになる可能性があります。大抵、プロビジョニングの結果は、IoT ハブへの静的マッピングです。そのため、要件に自動再プロビジョニング要求が含まれている場合を除き、必要に応じてのみ実行することをお勧めします。より多いトラフィックが想定される場合、そのようなシナリオをサポートするには、複数の DPS インスタンスにスケールアウトします。

時間差プロビジョニングスケジュールを使用します。時間ベースの制限事項の一部を軽減するには、1 つの推奨事項として時間差プロビジョニングスケジュールの使用が挙げられます。初期プロビジョニングでは、展開の要件に応じて、このスケジュールは、数秒、または最大で数分のランダムオフセットに基づいている場合があります。

プロビジョニングを要求する前に状態のクエリを必ず実行します。ベストプラクティスとして、デバイスでは、プロビジョニングを要求する前に、デバイス登録状態参照 API を使用して状態のクエリを必ず実行する必要があります。この呼び出しが現在は課金対象アイテムとしてカウントされていないことに加え、制限は登録制限とは無関係です。クエリ操作は、プロビジョニング要求と比較すると相対的に高速です。つまり、デバイスでは、その状態を検証できるうえに、より高速に通常のデバイスワークロードへ移行できるということです。該当するデバイス登録ロジックについては、大規模な展開についてのドキュメントを参照してください。

プロビジョニング API に関する考慮事項に従います。ここで提案する設計には、プロビジョニング API が含まれているものがいくつかあります。プロビジョニング API には、Azure Cosmos DB などのバッキングメタデータストアが必要です。これらのスケールレベルでは、この API とバッキングデータストアに適したパターンとして、グローバルに利用可能で回復性のある設計パターンを実装することをお勧めします。これは、Azure Cosmos DB の組み込みのマルチマスター、geo 冗長機能、待機時間の保証により、このシナリオでの最適な選択肢となります。この API の主な役割は次のとおりです。

DPS ID スコープを提供します。このインターフェイスには GET 要求を指定できる場合があります。物理デバイスまたは管理アプリケーションは、このインターフェイスに接続されていることに注意してください。
デバイスのライフサイクルをサポートします。デバイスに再プロビジョニングが必要な場合があります。または、その他の予期しないイベントが発生する可能性があります。少なくとも、デバイス ID と、デバイスに割り当てられた DPS を維持することが重要です。このようにして、割り当てられた DPS からプロビジョニングを解除して別の DPS で再プロビジョニングすることができます。または、デバイスのライフサイクルが終了している場合は、システムから完全に削除できます。
負荷分散システム。デバイス ID と DPS について同じメタデータを使用すると、各サブシステムの現在の負荷を把握しやすくなるうえに、その情報を適用して、水平方向にスケールアウトされたコンポーネント間でデバイスのバランスを取りやすくなります。
システムのセキュリティを維持します。前述のように、プロビジョニング API は各要求を認証する必要があります。ベストプラクティスとして、デバイスごとに固有の X.509 証明書を使用することを推奨します。アーキテクチャがこれをサポートしている場合は、これにより、プロビジョニング API と DPS インスタンスの両方に対して認証が行われます。フリート証明書やトークンなどの他の方法も使用できますが、安全性が低いと見なされています。具体的な実装方法に加え、実装によるセキュリティへの影響は、ゼロタッチとロータッチのどちらのオプションを選択するかによって異なります。

Azure IoT Hub のスケールアウト

DPS のスケールアウトと比較すると、Azure IoT Hub のスケールアウトは比較的簡単です。前述のように、DPS の利点の 1 つは、インスタンスを多数の IoT Hub インスタンスにリンクできることです。すべての Azure IoT ソリューションで推奨されているように DPS が使用されている場合、IoT Hub のスケールアウトでは次のことが問題になります。

IoT Hub サービスの新しいインスタンスの作成。
適切なルーティングとその他の詳細を使用した新しいインスタンスの構成。
適切な DPS インスタンスへの新しいインスタンスのリンク。
必要に応じた DPS 割り当てポリシー、またはカスタム割り当てポリシーの再構成。

デバイスソフトウェアを設計する

スケーラブルなデバイス設計には、従うべきベストプラクティスに加え、スケーラブルなデバイス設計についてのデバイス側の考慮事項が数多くあります。これらのいくつかは、現場で経験したアンチパターンから直接得たものです。このセクションでは、正常にスケーリングされたデプロイの鍵となる概念について説明します。

デバイスのライフサイクルのさまざまな部分とライフサイクルにおけるシナリオでのワークロードを見積もります。デバイス登録ワークロードは、開発フェーズ (パイロット、開発、運用、使用停止、サポート終了) ごとに大きく異なることがあります。場合によっては、前述の停電シナリオなど、外部要因によって異なることもあります。 "最悪のケース" のワークロードに対して設計すると、間違いなく大きな成功を収めることができます。

オンデマンドでの再プロビジョニングをサポートします。この機能は、デバイスコマンドと、製品ドキュメントに記載されている管理ユーザー要求を使用して提供できます。このオプションを使用すると、所有権の移転のシナリオと出荷時の既定値のシナリオに対応できます。

必要ない場合は再プロビジョニングしないでください。プロビジョニング情報は比較的静的であるため、フィールド内でアクティブな動作中のデバイスに再プロビジョニングが必要となることはめったにありません。正当な理由がなければ、再プロビジョニングしないでください。

頻繁に再プロビジョニングする必要がある場合は、プロビジョニング状態を確認してください。プロビジョニング状態が不明の場合は、まずプロビジョニング状態のクエリを実行することから始めてください。クエリ操作は、プロビジョニング操作とは異なるクォータに対して処理されるものであり、プロビジョニング操作より高速な操作です。このクエリを実行すると、先に進む前にデバイスでプロビジョニング状態を検証できます。デバイスが、プロビジョニング結果を格納するために使用できる永続ストレージを備えていない場合などがあります。

再試行ロジック戦略が適切であることを確認します。デバイスには、初期プロビジョニングと、後に行われる再プロビジョニングの両方に適した再試行アルゴリズムがデバイスコードに組み込まれている必要があります (前述の "ランダム化によるエクスポネンシャルバックオフ" など)。これらのシナリオは、2 つのユースケースで異なる場合があります。定義上、初期プロビジョニングでは、ユースケースによっては再プロビジョニングよりも再試行プロセスを積極的に行う必要がある場合があります。スロットルが行われた場合、DPS はほとんどの Azure サービスと同様に HTTP 429 ("要求が多すぎます") エラーコードを返します。 Azure アーキテクチャセンターには、再試行についてのガイダンスと、さらに重要なものとして再試行シナリオで回避すべきアンチパターンについてのガイダンスが用意されています。また、DPS ドキュメントには、サービスで推奨されている再試行の間隔に加え、スケーリングのガイダンスの一部として適切なジッターを計算する方法についても記載されています。デバイスの場所の安定性と接続アクセスも、適切な再試行戦略に影響します。たとえば、デバイスが一定期間オフラインであることがわかっていると同時にオフラインであることがそのデバイスで検出可能である場合は、そのデバイスがオフラインの間はオンライン操作を再試行しても意味がありません。

無線 (OTA) での更新をサポートします。 2 つの単純な更新モデルとして、自動デバイス管理を使用したデバイスツインプロパティの使用と、単純なデバイスコマンドの使用があります。より高度な更新シナリオとレポートについては、Azure Device Update サービスのプレビューをご覧ください。 OTA 更新プログラムを実行すると、デバイスコードの欠陥を修正したり、必要に応じて基本的なサービス再構成 (DPS ID スコープなど) を行ったりすることができます。

すべてのレイヤーとすべての証明書の使用における証明書の変更のためのアーキテクト。この推奨事項は、OTA 更新のベストプラクティスに関連付けられています。証明書のローテーションを検討する必要があります。 IoT Hub DPS ドキュメントでは、このシナリオをデバイス ID 証明書の観点から説明します。ただし、デバイスソリューションの一部として、IoT Hub アクセス、App Service アクセス、Azure Storage アカウントアクセスなど、他の証明書が使用されていることを覚えておく必要があります。 Azure プラットフォーム全体におけるルート証明書の変更では、すべてのレイヤーで変更を予測する必要があることを示しています。また、証明書のピン留めを慎重に使用します。認定書がデバイス製造元の制御可能な範囲外にある場合は特にそうです。

妥当な "既定" の状態を検討します。初期プロビジョニングエラーを解決するために、状況に応じて、適切な切断済みまたはプロビジョニング解除された構成を使用します。初期プロビジョニングの一環としてデバイスに負荷の高い相互作用コンポーネントがある場合、ユーザーが他のプロビジョニングタスクを実行している間に、バックグラウンドでプロビジョニングプロセスが発生する可能性があります。いずれの場合も、既定値の使用に、適切な再試行パターンの使用とサーキットブレーカーアーキテクチャパターンの適切な使用が暗黙的に示されています。

適切な場合、エンドポイント構成機能を含めます。 DPS ID スコープ、DPS エンドポイント、またはカスタムプロビジョニングサービスエンドポイントの構成を許可します。 DPS エンドポイントが変更されることは予想されませんが、デバイスで変更できるため、柔軟性が向上します。たとえば、Azure に直接アクセスすることなく、統合テストを使用して、デバイスプロビジョニングプロセスを自動検証する場合を考慮します。または、プロビジョニングプロキシサービスを使用するシナリオなど、現在は実施されていなくても将来実施される可能性があるプロビジョニングシナリオを考慮します。

プロビジョニングに Azure IoT SDK を使用します。 DPS 呼び出しがデバイス自体に対して行われるのか、カスタムプロビジョニング API で行われるのかに関係なく、Azure IoT SDK を使用すると、実装のベストプラクティスを "無料" でいくつか入手できるとともに、よりクリーンなサポートエクスペリエンスが可能になります。 SDK はすべてオープンソースで公開されるため、動作を確認したり、変更を提案したりすることができます。主に、選択するデバイスハードウェアとそのデバイスで使用可能なランタイムの組み合わせにより、選択する SDK が決まります。

デバイスをデプロイする

デバイスの展開は、デバイスのライフサイクルの重要な一部ですが、ユースケースによって異なるため、この記事で扱う範囲外とします。上記で参照されている "所有権の移転" についてのディスカッションポイントは、プロビジョニングアプリケーション (モバイルアプリケーションなど) が関わっている展開やパターンに適用される場合がありますが、これについては、使用中の IoT デバイスの種類に基づいて選択してくだださい。

デバイスを監視する

展開全体では、ソリューションを最初から最後まで監視してシステムが適切に実行されているかを確認することが重要な部分となります。この記事では、ソリューションの運用に関する事柄ではなく、アーキテクチャと設計に明示的に注目しているため、監視についての詳細はこの記事の対象範囲に含まれません。ただし、大まかに言うと、ソリューションが制限に到達しないように、監視ツールが Azure Monitor を介して Azure に組み込まれています。詳細については、次の記事を参照してください。

これらのツールは、個別に使用することも、より高度な SIEM ソリューション (Microsoft Sentinel など) の一部として使用することもできます。

ドキュメントには、DPS の使用状況を経時的に監視するための次の監視パターンが含まれています。

DPS インスタンスの各登録グループに対してクエリを実行するアプリケーションを作成し、そのグループに登録されているデバイスの合計数を取得し、さまざまな登録グループからの数値を集計します。この数値により、DPS を介して現在登録されていて、かつサービスの状態を監視するために使用できるデバイスの正確な数が判明します。
特定の期間、デバイスの登録を監視します。たとえば、前の 5 日間の DPS インスタンスの登録率を監視します。この方法は、おおよその数値を示しており、設定した期間が上限になります。

まとめ

何百万台、何億万台ものデバイスをサポートする IoT ソリューションをスケールアップするのは、簡単な作業ではありません。考慮すべき要素は数多く、そのようなスケールで発生する問題を解決する方法はさまざまです。この記事では、問題についてまとめると同時に、展開が成功した場合のそのような問題への取り組み方に対するアプローチについて説明します。

共同作成者

この記事は、Microsoft によって保守されています。当初の寄稿者は以下のとおりです。

プリンシパル作成者:

Michael C. Bazarewsky | Microsoft Azure CXP G&I、シニアカスタマーエンジニア

その他の共同作成者:

David Crook | Microsoft Azure CXP G&I、プリンシパルカスタマーエンジニア
Alberto Gorni | シニアカスタマーエンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

Microsoft Azure IoT デバイスの大規模な展開のベストプラクティスについての製品グループのガイダンスを確認する
クラウド導入フレームワークの回復情報を確認する

次の方法で共有

Azure IoT ソリューションをスケールアウトして何百万台ものデバイスをサポートする

要件を集める