IoT Hub ベースのソリューションをテストから運用環境に移行する
この記事では、Azure IoT Hub ベースのソリューションを運用環境に移行するための重要な考慮事項の一覧を示します。
デプロイ スタンプを使用する
デプロイ スタンプは、定義された数のデバイスをサポートするコア ソリューション コンポーネントの個別の単位です。 1 つのユニットはスタンプまたはスケール ユニットと呼ばれます。 スタンプは、設定されたデバイスの作成、IoT ハブ、イベント ハブまたはその他のルーティング エンドポイント、および処理コンポーネントで構成される場合があります。 各スタンプは、定義されたデバイス群をサポートしています。 スタンプが保持できるデバイスの最大数を選択します。 デバイスの人口が増えるにつれて、ソリューションのさまざまな部分を個別にスケールアップするのではなく、スタンプ インスタンスを追加します。
スタンプを追加する代わりに、IoT Hub ベースのソリューションの 1 つのインスタンスを運用環境に移動すると、次の制限が発生する可能性があります。
スケールの制限: 1 つのインスタンスでスケーリングの制限が発生する可能性があります。 たとえば、ソリューションでは、受信接続、ホスト名、伝送制御プロトコル ソケット、またはその他のリソースの数に制限があるサービスを使用できます。
非線形のスケーリングまたはコスト: ソリューション コンポーネントは、要求の数や取り込まれたデータの量に比例してスケーリングされない場合があります。 代わりに、一部のコンポーネントでは、しきい値に達した後にパフォーマンスの低下やコストの増加が発生する可能性があります。 このような場合、スタンプを追加してスケールアウトすると、容量を増やすよりも効果的な戦略になる可能性があります。
顧客の分離: 特定の顧客のデータを他の顧客のデータから分離することが必要になる場合があります。 異なるスタンプに対するリソースの需要が高い顧客をグループ化できます。
単一およびマルチテナント インスタンス。 ソリューションの独自の独立したインスタンスを必要とする大規模な顧客が複数いる場合があります。 または、マルチテナントデプロイを共有できる小規模な顧客のプールがある場合もあります。
複雑なデプロイ要件: 管理された方法でサービスに更新プログラムをデプロイし、異なる時間に異なるスタンプにデプロイすることが必要になる場合があります。
更新頻度: 頻繁なシステム更新に耐え、他の顧客はリスクを嫌い、サービスの更新頻度が低い場合があります。
地理的または地政学的な制約: 待機時間を短縮したり、データ主権要件に準拠したりするために、一部の顧客を特定のリージョンにデプロイできます。
前の問題を回避するには、サービスを複数のスタンプにグループ化することを検討してください。 スタンプは互いに独立して動作するので、個別にデプロイして更新できます。 1 つの地理的リージョンに 1 つのスタンプが含まれている場合や、複数のスタンプを含む場合があります。このリージョン内で水平方向のスケールアウトを有効にします。 各スタンプには、顧客のサブセットが含まれています。
詳細については、「 デプロイ スタンプ パターン」を参照してください。
一時的な障害が発生した場合にバックオフを使用する
リモート サービスとリソースと通信するすべてのアプリケーションは、一時的な障害を処理するように設計する必要があります。 このニーズは、接続によってこれらの障害が発生する可能性が高まるクラウド環境では特に重要です。 一時的な障害には次のものがあります。
- コンポーネントとサービスへのネットワーク接続の一瞬の損失。
- サービスの一時的な利用不可。
- サービスがビジー状態のときに発生するタイムアウト。
- デバイスが同時に送信するときに発生する競合。
多くの場合、これらのエラーは自己修正であり、適切な遅延の後にアクションが繰り返されると、成功する可能性があります。 ただし、再試行間の適切な間隔を決定することは困難です。 一般に、次のような再試行間隔が用いられます。
指数バックオフ。 アプリケーションは、最初の再試行の前に少し待ってから、後続の試行の間の待機時間を徐々に増やします。 たとえば、3 秒、12 秒、または 30 秒後に操作を再試行できます。
定期的。 アプリケーションが待機する試行間隔は一定で変化しません。 たとえば、3 秒ごとに操作を再試行できます。
即時再試行。 一時的な障害が短く、ネットワーク パケットの競合やハードウェア コンポーネントの急増などのイベントが原因で発生することがあります。 このシナリオでは、すぐに操作を再試行することが適切です。 アプリケーションがアセンブルして次の要求を送信するまでに障害が解消された場合、操作は成功します。 ただし、複数回の即時再試行は実行しないでください。 即時再試行が失敗した場合は、指数バックオフやフォールバック アクションなどの代替戦略に切り替えます。
無作為 化。 上記の再試行戦略には、クライアントの複数のインスタンスが後続の再試行を同時に送信できないようにするランダム化要素が含まれている場合があります。
次のアンチパターンは避けてください。
実装に再試行コードの重複したレイヤーを含めないでください。
再試行が際限なく繰り返される設計は確実に避けてください。
即時再試行を複数回実行しないでください。
一定間隔での再試行は使用しないでください。
同じクライアントの複数のインスタンス、または異なるクライアントの複数のインスタンスが同時に再試行を送信できないようにします。
詳細については、「一時的な障害の処理」を参照してください。
ゼロタッチ プロビジョニングを使用する
プロビジョニングは、デバイスを IoT Hub に登録するプロセスです。 プロビジョニングでは、デバイスを IoT Hub に登録し、使用する構成証明メカニズムを指定します。 IoT Hub デバイス プロビジョニング サービス (DPS) を使用することも、IoT Hub Registry Manager API を介して直接プロビジョニングすることもできます。 DPS を使用すると、遅延バインディングの利点が得られます。これにより、デバイス ソフトウェアを変更することなく、フィールド デバイスを IoT Hub に取り外して再プロビジョニングできます。
次の例は、DPS を使用して、テスト環境から運用環境への移行ワークフローを実装する方法を示しています。
ソリューション開発者は、テストと運用の IoT クラウドの両方をプロビジョニング サービスにリンクします。
デバイスは DPS プロトコルを実装して、IoT ハブがプロビジョニングされなくなった場合に検出します。 デバイスは最初にテスト環境にプロビジョニングされます。
デバイスはテスト環境に登録されているため、そこに接続してテストが行われます。
開発者は、デバイスを運用環境に再プロビジョニングし、テスト ハブから削除します。 テスト ハブは、次回再接続するとデバイスを拒否します。
デバイスが接続し、プロビジョニング フローを再ネゴシエーションします。 DPS はデバイスを運用環境に誘導し、デバイスはそこに接続して認証します。
詳細については、「 IoT Hub デバイス プロビジョニング サービスの概要」を参照してください。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパルの作成者:
- Matthew Cosner | プリンシパル ソフトウェア エンジニアリング マネージャー
- Ansley Yeo | プリンシパル プログラム マネージャー
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。