Natureのインフラアーキテクチャ

Natureでは、自宅にある家電のスマート操作を可能にするIoTプロダクト「Nature Remo」とエネマネHEMSプロダクト「Nature Remo E」の開発・製造・販売などを行っています。販売台数も70万台を突破し、インフラに求められる信頼性も上がってきていると感じています。

アーキテクチャ選択の背景や意図

IoTプロダクトなのでエッジデバイス(Nature Remo)が存在するというところが通常のWebサービスとは大きく違うところです。が、Nature Remoはセンサ、赤外線信号送受信、各種ローカル通信などのみを担い、ロジックはバックエンドに寄せるようにしています。これにより一般的なWebサービスと比べてバックエンドの使用技術や機能追加の頻度もそこまで変わらなかったりします。

特殊な部分として、それぞれのNature Remoはセンサデータのアップロードや赤外線コマンド送信など双方向にサーバーとの通信を頻繁に行うため、WebSocketサーバー(Stream)に常時接続しています。このStreamはAPIとは別で建ててロジックを持たないようにしておくことで、Nature Remoとの接続状況を気にすることなくAPIをデプロイできるような構成にしています。

Nature Remoには時刻などをトリガに家電を自動で操作できるオートメーションという機能がありますが、こちらはSQSと自前のJob Workerを利用して実現しています。オートメーションのトリガ判定は時刻、センサ値、ジオフェンスなどのインプットに対してさまざまなタイミングで実施し、トリガ判定が満たされた場合各プロセスはSQSにイベントをenqueueします。Workerは各イベントをdequeueし、家電操作などのアクション実行を行うという流れになっています。

現在の課題と今後の改善予定

Nature Remoを使うすべての操作はバックエンドを経由するため、バックエンドが障害などで使用不能になるとNature Remoによる家電操作が不可能になってしまうという課題があります。これについてはアプリとNature Remoのみで操作としては完結させ、操作履歴を別途バックエンドへ送信するといった対応で改善することを検討しています。

またオートメーションについては、特定の時刻で大量のオートメーションが同時に実行されMySQLが高負荷になってしまうという事象も発生しています。SQS x Workerの構成はシンプルで良いのですが、オートメーション1件についてWorkerのGoroutineが1つ走るため、各々のプロセスからのMySQLアクセスが同時に大量発生してしまうというのが原因です。MySQLからワークロードに適した別のデータストアに移行したり、Workerでのプロセスあたりのイベント処理数を増やしたりと言った対応をしていく予定です。

◆執筆：的場 一将 X:@bamato_t, GitHub : @goro9

【サービス公式サイト】
・公式サイト
・Nature Remoシリーズ 製品ページ