AWS IoT Coreで動作検証中にアウトバウンドメッセージが多い問題

エラー解決
スポンサーリンク

AWS IoT Coreで動作検証中にメトリックス内でアウトバンドメッセージが多くカウントされていることが分かりました。
その原因と解決方法をまとめたので、よろしかったらご覧ください。

 

目次

 


 

AWS IoT Coreで動作検証中に大量のアウトバンドメッセージが発生!!!

AWS IoT CoreとIoT Device間の接続/通信の動作検証をしていたら、以下のようにアウトバンドメッセージが大量発生していました。(Publishは数十発しかしていません。)

【AWS IoT Coreのモニタリング】

【CloudWatch】

AWS無料利用期間中だったので、課金は発生しなかったのですが、14.1kのメッセージが無料利用期間外に出ていたらって考えると冷や汗がでました。

 

 

 

大量のアウトバンドメッセージの原因は?

いろいろ調査した結果、AWS IoT CoreのMQTTテストクライアントが怪しいということが分かりました。

2021年8月頃に調査した結果、MQTTテストクライアントは以下の傾向があります。

【MQTTテストクライアント動作確認の結果】

  • MQTTテストクライアントでサブスクライブすると、15分ごとにMQTTテストクライアントが追加接続される(サブスクライブ対象のデバイスが15分おきに+1増えていく)
  • MQTTテストクライアントを立ち上げるだけで、サブスクライブしなければ、Outboundの増加は発生しない。
  • デバイスがサブスクライブしてもOutboundの増加は発生しない。
  • MQTTテストクライアントのページを消して、再度MQTTテストクライアントを立ち上げサブスクライブすれば、Outboundの増加はリセットされる。

 

仕様なのか!?

MQTTテストクライアントでサブスクライブすると、15分ごとにMQTTテストクライアントのデバイスが追加接続されていくため、長時間動作検証をしているとアウトバンドメッセージが増えていきます。

以下のチャートは、MQTTテストクライアントで[#]トピックをサブスクライブした状態で、IoTデバイスから1分間隔でPublishしたときのアウトバンドメッセージの推移です。
MQTTテストクライアントの接続数が5分間隔で+1増加していき、それに伴いアウトバンドメッセージが+5回分(Publish1回/分 x 5分)ずつ増加していることが分かります。

 

 

 

大量のアウトバンドメッセージを発生させないためにはどうすればいいか?

MQTTテストクライアントのページを再ロードすれば、追加接続されたMQTTテストクライアントのデバイスがリセットされ、アウトバンドメッセージの増加がリセットされます。
ですので、

MQTTテストクライアントを使って長期の動作検証をする場合は、定期的にMQTTテストクライアントをリセットしましょう!

 

 

 

そもそもインバンドメッセージとアウトバンドメッセージとはなにか?

AWS IoT Coreの構成は以下のようになっています。

引用元:https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/aws-iot-how-it-works.html#aws-iot-components-data

また、AWS IoT Coreのメトリックスは以下のように定義されています。

メトリクス 説明
Connect.Success メッセージブローカーへ正常な接続の数。Protocol ディメンションには、
CONNECT メッセージの送信に使用されたプロトコルが含まれます。
PublishIn.Success メッセージブローカーによって正常に処理された発行リクエストの数。
Protocol ディメンションには、PUBLISH メッセージの送信に使用されたプロトコルが含まれます。
PublishOut.Success メッセージブローカーによって正常に行われた発行リクエストの数。
Protocol ディメンションには、PUBLISH メッセージの送信に使用されたプロトコルが含まれます。

※メトリックスは抜粋しています。

引用元:https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/metrics_dimensions.html#message-broker-metrics

 

つまり、インバウンド/アウトバンドメッセージはMQTTメッセージブローカーにとってのIN/OUTとのことのようです。
デバイスからPublishされると、MQTTメッセージブローカーがメッセージを受信するため、このタイミングでINが(+1)されます。その後サブスクライブしているデバイスがいたら、MQTTメッセージブローカーがそこに向けてメッセージを転送するため、そのタイミングでOUTが(+サブスクライブしているデバイス数)となるみたいです。

 

 

 

さいごに

初めて大量に発生したアウトバンドメッセージを見たときは驚きました。
自分のプログラムのバグかと思っていろいろ調査していましたが、まさか犯人がMQTTテストクライアントだとは思いませんでした。。。
解決方法はわかったので、MQTTテストクライアントを使って長期動作検証をする場合は気を付けたいと思います。

 

以上!

コメント

タイトルとURLをコピーしました