View a markdown version of this page

時間の経過に伴う最適化 - IoT レンズ

時間の経過に伴う最適化

AWS の新機能を評価することで、デバイスのパフォーマンスを分析し、デバイスと IoT との通信方法を変更することでコストを最適化できます。

デバイスファームウェアの変更によってソリューションのコストを最適化するには、AWS IoT などの AWS のサービスの料金コンポーネントを確認し、特定のサービスの請求計測しきい値を下回っているかどうかを判断してから、コストとパフォーマンスのトレードオフを比較検討する必要があります。

IOTCOST 3.デバイスと IoT プラットフォーム間のペイロードサイズを最適化するにはどうすればよいですか?

IoT アプリケーションは、エンドデバイスで実現できるネットワーキングスループットと、IoT アプリケーションでデータを処理する最も効率的な方法のバランスを取る必要があります。IoT デプロイでは、デバイスの制約に基づいてデータ転送を最初に最適化することをお勧めします。まず、デバイスからクラウドに個別のデータイベントを送信し、1 つのメッセージで複数のイベントのバッチ処理を最小限に抑えます。後で、必要に応じて、シリアル化フレームワークを使用して IoT プラットフォームに送信する前にメッセージを圧縮できます。

コストの観点からは、MQTT ペイロードサイズは AWS IoT Core の重要なコスト最適化要素です。IoT メッセージは、5 KB 単位で請求されます (最大 128 KB) 。このため、各 MQTT ペイロードサイズは最大 5 KB に近くなる必要があります。例えば、現在 6 KB のサイズのペイロードは、10 KB のペイロードほどコスト効率が良くありません。これは、1 つのメッセージが他のメッセージよりも大きいにもかかわらず、そのメッセージのパブリッシュにかかる全体的なコストが同じであるためです。

ペイロードサイズを利用するには、データを圧縮するか、データをメッセージに集約する機会を探ります。

  • 値を読みやすくしながら短くする必要があります。5 桁の精度で十分であれば、ペイロードに 12 桁を使用しないでください。

  • IoT ルールエンジンのペイロード検査が不要な場合は、シリアル化フレームワークを使用してペイロードをより小さいサイズに圧縮できます。

  • データを送信する頻度を低く抑え、請求可能な増分内でメッセージを集約できます。例えば、1 つの 2 KB のメッセージを 1 秒おきに送信することは、2 つの 2 KB のメッセージを 2 秒おきに送信することにより、より低い IoT メッセージのコストで実現できます。

このアプローチには、実装前に考慮する必要があるトレードオフがあります。デバイスに複雑さや遅延を追加すると、予期せず処理コストが増加する可能性があります。IoT ペイロードのコスト最適化の演習は、ソリューションが本稼働状態になった後にのみ行われ、データ駆動型のアプローチを使用して、AWS IoT Core へのデータ送信方法の変更によるコストへの影響を判断できます。

IOTCOST 4.IoT デバイスの現在の状態を保存するコストをどのように最適化しますか?

Well-Architected IoT アプリケーションには、クラウド内のデバイスの仮想表現があります。この仮想表現は、マネージド型データストアまたは専門的な IoT アプリケーションデータストアで構成されます。いずれの場合も、デバイス状態の変更を IoT アプリケーションに効率的に送信するようにエンドデバイスをプログラムする必要があります。たとえば、デバイスの完全な状態が同期していない可能性があり、現在の設定をすべて送信することで最適な一致がファームウェアロジックで指示されている場合にのみ、デバイスは完全なデバイス状態を送信する必要があります。個々の状態の変化が発生すると、デバイスは、その変更をクラウドに送信する頻度を最適化する必要があります。

AWS IoT では、Device Shadow およびレジストリ運用は 1 KB 単位で計測され、課金は 100 万回のアクセス/変更オペレーションごとに課金されます。シャドウには、各デバイスの目的の状態または実際の状態が保存され、レジストリはデバイスの名前と管理に使用されます。

デバイスシャドウとレジストリのコスト最適化プロセスは、実行されるオペレーションの数と各オペレーションのサイズの管理に重点を置いています。運用がシャドウ運用およびレジストリ運用にコスト依存する場合は、シャドウ運用を最適化する方法を探す必要があります。たとえば、シャドウの場合、報告された各変更を個別に送信する代わりに、レポートされた複数のフィールドを 1 つのシャドウメッセージ更新に集約できます。シャドウの更新をグループ化すると、サービスの更新を統合することで、シャドウの全体的なコストが削減されます。