この記事には、IoT ソリューションを運用環境に移行するときに考慮する必要がある項目の一覧が含まれています。
デプロイ スタンプを使用する
スタンプは、定義済みデバイス数をサポートする、コア ソリューション コンポーネントの個別の単位です。 各コピーは "スタンプ" または "スケール ユニット" と呼ばれます。 たとえば、スタンプは、設定デバイス群、IoT Hub、イベントハブ、またはその他のルーティング エンドポイントと処理コンポーネントで構成されている場合があります。 各スタンプは、定義されたデバイス群をサポートしています。 スタンプで保持できるデバイスの最大数を選択します。 デバイス群が増大すると、ソリューションのさまざまな部分が個別にスケールアップされるのではなく、スタンプ インスタンスが追加されます。
スタンプを追加するのではなく、IoT ソリューションの単一のインスタンスを運用環境に移行する場合は、次の制限事項が発生する可能性があります。
スケールの制限: 単一のインスタンスでスケーリングの制限が生じる可能性があります。 たとえば、受信接続、ホスト名、TCP ソケット、その他のリソースの数に制限があるサービスがソリューションで使用される可能性があります。
非線形のスケーリングまたはコスト: ソリューション コンポーネントでは、要求数または取り込まれたデータの量に応じて直線的にスケーリングできない場合があります。 代わりに、コンポーネントによっては、しきい値に達すると、パフォーマンスが低下したり、コストが増加したりする可能性があります。 容量を追加してスケールアップすることは、スタンプを追加してスケールアウトするほど有効な戦略にならない場合があります。
顧客の分離: 特定の顧客のデータを他の顧客のデータから分離しておくことが必要な場合があります。 同様に、サービスを提供するために、他の顧客よりも多くのシステム リソースを必要とする顧客がいる場合があります。この場合、それらの顧客を別のスタンプにグループ化することを検討します。
シングルテナントおよびマルチテナント インスタンス: ソリューションの独自の独立したインスタンスを必要とする大規模な顧客がいる場合があります。 また、マルチテナント デプロイを共有できる小規模な顧客のグループがある場合もあります。
複雑なデプロイ要件: 制御された方法でサービスに更新プログラムをデプロイしたり、異なるタイミングでデプロイしたりすることが必要な場合があります。
更新頻度: システムの頻繁な更新を許容する顧客もいれば、リスクを嫌い、サービスが頻繁に更新されないことを望む顧客もいます。
地理的または地政学的な制約: 待機時間を短縮するためや、データの主権要件に準拠するために、一部の顧客を特定のリージョンにデプロイすることがあります。
上記の問題を回避するには、サービスを複数のスタンプにグループ化することを検討してください。 スタンプは互いに独立して動作するので、個別にデプロイして更新できます。 1 つの地理的リージョンに、1 つのスタンプを含めることも、リージョン内で水平方向にスケールアウトできるように複数のスタンプを含めることもできます。 各スタンプには、顧客のサブセットが含まれています。
一時的な障害が発生した場合にバックオフを使用する
リモートのサービスやリモートのリソースとやり取りするすべてのアプリケーションは、一過性の障害に特別な注意を払う必要があります。 とりわけクラウドは、環境の特性やインターネットでの接続性から、一過性の障害を起こしやすく、そこで動作するアプリケーションでは、一過性の障害への対応が特に重要となります。 一時的な障害には次のものがあります。
- コンポーネントやサービスとのネットワーク接続が一瞬的に失われる
- サービスを一時的に利用できない
- サービスがビジー状態になってタイムアウトになる
- デバイスを同時に送信した場合に競合が発生する
多くの場合、これらの障害は自動修正され、少し時間をおいてから操作を再試行すれば、高い確率で正常に実行されます。 適切な再試行間隔を決めるのは、難しい場合がありますが、 一般に、次のような再試行間隔が用いられます。
- 指数バックオフ。 少し間を置いて 1 回目の再試行を行い、その後、再試行を重ねるたびに加速度的にその間隔を増やしていく手法です。 たとえば、1 回目は 3 秒後、2 回目は 12 秒後、3 回目は 30 秒後というように再試行を行います。
- 一定間隔。 アプリケーションが待機する試行間隔は一定で変化しません。 たとえば、3 秒おきに操作を再試行します。
- 即時再試行。 ネットワーク パケットの衝突、ハードウェア コンポーネントにおける瞬時性電圧上昇などのために、一過性の障害の中でも、短時間で終わる障害もあります。 その場合、アプリケーションが次の要求を組み立てて送信するまでの間に障害が解消されれば操作に成功する可能性があるので、直ちに操作を再試行するのが妥当です。 ただし即時再試行を複数回にわたって行うことは避けてください。即時再試行に失敗した場合は、指数バックオフやフォールバック アクションなど、別の手法に切り替える必要があります。
- 無作為化。 特定のクライアントの複数のインスタンスが同じタイミングで再試行要求を送信するのを防ぐために、これまでに挙げた再試行方式にはいずれも無作為化を取り入れることができます。
次のアンチパターンも避けてください。
- 再試行コードを多層化した実装は避けてください。
- 再試行が際限なく繰り返される設計は確実に避けてください。
- 即時再試行を複数回にわたって実行しないでください。
- 一定間隔での再試行は使用しないでください。
- 同じクライアントであれ異なるクライアントであれ複数のインスタンスが同時に再試行要求を送ることのないようにします。
ゼロタッチ プロビジョニングを使用する
プロビジョニングは、Azure IoT Hub にデバイスを登録する操作です。 プロビジョニングを行うことで、デバイスと、そのデバイスによって使用されている構成証明メカニズムが IoT Hub によって認識されます。 Azure IoT Hub Device Provisioning Service (DPS) を使用するか、IoT Hub Registry Manager API を使用して直接プロビジョニングできます。 DPS を使用すると "遅延バインディング" の利点が得られます。つまり、デバイス ソフトウェアを変更せずに、フィールド デバイスを削除して IoT Hub に再プロビジョニングできます。
次の例は、DPS を使用して、テスト環境から運用環境への移行ワークフローを実装する方法を示しています。
- ソリューション開発者が、テスト IoT クラウドと運用 IoT クラウドをプロビジョニング サービスにリンクします。
- デバイスに IoT Hub を見つけるための DPS プロトコルが実装されます (プロビジョニングされていない場合)。 デバイスは最初にテスト環境にプロビジョニングされます。
- デバイスはテスト環境に登録されているため、その環境に接続されます。そこでテストが実行されます。
- 開発者は、デバイスを運用環境に再プロビジョニングし、テスト ハブから削除します。 次回デバイスが再接続されたとき、テスト ハブはそのデバイスを拒否します。
- デバイスはプロビジョニング フローに接続され、再ネゴシエートが行われます。 これでデバイスは DPS によって運用環境にダイレクトされます。デバイスは接続され、そこで認証が行われます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Matthew Cosner | プリンシパル ソフトウェア エンジニアリング マネージャー
- Ansley Yeo | プリンシパル プログラム マネージャー
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。