This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

More than 1 year has passed since last update.

目からウロコ！Node-REDのアンチパターン10選

Posted at 2022-08-28

　私がNode-REDを使い始めて4年が経ちました。これまでにハッカソンや勉強会等でNode-REDのフローを見てきて、開発の後戻りや混乱が起きやすいアンチパターンが分かってきたため、紹介します。

Node-REDとは

　マウスで部品をつなぐ操作のみでアプリケーションをノンプログラミングで開発できる開発環境です。IoT分野に注力している企業は、ほぼ全て活用しておりIoT業界標準のソフトウェアとなっています。
　Node-REDは、クラウドとエッジデバイスの環境で使えるため、両環境に対応させたフローを開発することでポータピリティ性の高いフローになります。また、Node-REDはクラウドネイティブアプリケーションの開発ルールである12 Factor Appに沿った作りとなっているため、フローにおいても本ルールに従うことで、今時の(?)開発手法の恩恵を受けることができます。

それではさっそく作りがちなアンチパターンと解決方法を紹介します。

1. コーディング能力が必要となるfunctionノードを多用する

　functionノードはJavaScriptを記述できる便利ノードですが、沢山使ってしまうとコーディングになってしまいノンプログラミングで素早く開発できるNode-REDの利点がなくなってしまいます。例えば以下のフロー内では、1つ目のfunctionノード「AbCdを設定」では「msg.payload = 'AbCd';」というコードを記載し、msg.payloadに値を設定しています。2つ目のfunctionノード「大文字を小文字に変換」では、「msg.payload = msg.payload.toLowerCase();」というコードで大文字を小文字に変換しています。

　値の代入を行う際は、changeノードかtemplateノードを使いましょう。やむをおえずfunctionノードを用いた場合は、Node generatorを用いて一般的な自作ノードに変換し、フローライブラリに公開すると良いです。これによってコーディングができない他のユーザがノードを再利用できるようになります。

　その他、四則演算などの簡単な処理を行いたい場合は、changeノードのJSONata機能を使うとシンプルになります。

2. changeノードで複数の変数を代入する

　前述の様にfunctionノードで値の代入を行う代わりとして、changeノードを用いて代入することがあります。1個の変数の代入であれば、changeノードを用いると簡単ですが、複数の変数を代入しだすと、どの値を扱っているかが分かりにくくなってしまいます。例えば、以下のフローではmsg.payloadに入った「タイムスタンプ」とmsg.topicに入った「topicValue」という値を合わせて、「{"timestamp": "<タイムスタンプ>", "value": "topicValue"}」というJSONオブジェクトを生成しています。

　changeノードのプロパティでは、msg.payloadのタイムスタンプをmsg.tmpに移動した後、新規にJSONオブジェクトに値を代入しています。ルールが3つもあり何をしているか分かりにくいです。
　本問題を解決するには、templateノードのMustacheテンプレートを用いると複数の変数の代入が分かりやすくなります。Mustacheテンプレートでは前のノードから受け取ったJSONデータ内の変数を「{{}}」で指定して新たなJSONオブジェクトを生成できます。

3. injectノードに初期値を定義する

　injectノードのノードプロパティでは、次のノードに渡す値として、タイムスタンプ値以外にも変数やJSONデータを定義できる様になっています。例として以下では、GPIO端子のON/OFFを制御するために0または1をgpioノードに送るフローを用いました。

　フローの実行と値設定を同時にできて一見便利そうですが、フローの再利用の観点だと値は設定しない方が良いです。以下の様にinjectノードとtemplateノードに分けてフローを作っておいた方が、後々フローを修正する手間が減ります。

　例えば、後からswitchノードで判定結果を基に0か1を送る様に変更したい場合、templateノードの前にswitchノードを追加するだけでよくなります。もしinjectノードに値を設定していた場合は、後からtemplateノードを追加しないといけないことが分かるかと思います。

4. execノードで環境依存のコマンドを実行する

　execノードはNode-REDから手軽にコマンドを実行できて便利ですが、Mac、Linux、Windows環境間でフローの受け渡しをすると、環境依存のコマンドが実行できないためトラブルが起こります。例えば、Raspberry PiのIPアドレスを取得するために「hostname -i」コマンドをexecノードで実行することがよくあります。

　この書き方をしてしまうと、MacやWindowsで動作しなくなってしまいます。代替手段としてIPアドレスを取得するサードパーティノードを用い、全てのNode.js環境で動作する書き方の方が親切です。

　他のケースにおいても、execノードに環境依存のコマンドを書く前に、他の環境でも動くサードパーティノードがないか探してみましょう。

5. fileノードを用いてデータを保存する

　Node-REDでは「センサから集めたデータをcsv形式でfileノードを用いて保存する」というフローを書きがちですが、データ管理で後から困るケースが多いです。

　まずPaaS環境では、インスタンスを再起動するとファイルシステムに保存したデータが消える仕様になっているものが多いため、データを消失してしまいます。そのため、初めからfileノードが使えない様になっているNode-RED環境もあります。クラウドとエッジデバイスの両方で動作するフローにするには、fileノードの代替としてDBノードを用いた方が良いです。Node-RED公式のMySQLノードやMongoDBノードがおすすめです(MySQLノードの使い方はこちらが参考になります)。

DBを用いることで古いデータがディスク領域を圧迫してきた際に、一部データを削除することも容易になります。

6. フローの編集が困難なsubflowを多用する

　subflowノードは、一連のフローをノード化して再利用するために用いるノードです。プログラミング言語の関数の様に使えますが、一度subflow化してしまうと中のフローは編集が困難です。特にsubflowが入れ子になっている場合は、階層構造が複雑化しバグを作り込む原因となります。

　subflow化したいフローは、代わりにhttp-in、http responseノードを用いてREST API化し、http requestノードから呼び出すようにしましょう。

　REST API化の副次的な効果として、一部のフローを切り出して別のNode-REDインスタンスで動作させ、負荷分散や障害に強いマイクロサービスアーキテクチャに変更できるメリットもあります。マイクロサービス向けのテストツールも使えるため、フローの品質維持もできるようになります。

7. ノードの説明をcommentノードに記載する

　ノードの説明を書くために、各ノードの横にcommentノードを配置することがあります。

　このフローを編集する際、ノードの移動と合わせて対応するcommentノードも移動する必要が出てきて、開発の時間の殆どがノードの配置に費やされてしまいます。commentノードはフローの説明だけとし、ノードの説明はノードプロパティの中にある「説明」の中に記載しましょう(v0.20から有効)。

　ノードの説明を記載すると、情報タブでノードの説明を確認できます。

　特にhttp-inノードにおいては、HTTPエンドポイントの説明を記載できるnode-red-node-swaggerノードを用いましょう。

　本機能を用いるとhttp://localhost:1880/http-api/swagger.jsonからOpen API定義を取得できるため、API Managementとの連携したり、Node generatorを用いてREST APIにアクセスする自作ノードを開発したりできるようになります。また、Node-REDフローエディタ上で以下の様なSwagger UIを用いてエンドポイントをテストすることもできます。

8. フロー内に環境固有の変数を定義する

　Node-RED起動時に初期化処理としてグローバルコンテキストやフローコンテキストに値を入れるフローを作成される方がよくいます。

　固定の値なら問題ないですが、環境毎に異なる値を入れる必要がある場合、フローを新環境に読み込む毎に値を記入する必要があります。クラウドネイティブアプリケーションの開発では、一般的に環境変数に環境固有の情報を格納します。Node-REDは環境変数から値を読み取る機能があるため、Node-REDにおいても環境変数に設定した値を用いるようにしましょう。

　これによって複数のNode-RED環境を用意する際、環境変数を設定するのみで環境固有の情報を設定できるため、デプロイ作業が簡単になります。

9. 変数名が衝突する可能性があるグローバルコンテキストを使う

　ノード間で値を共有する場合、グローバルコンテキストを用いることがあります。もし2つの異なるフローを1つのNode-REDに読み込んだ場合、グローバルコンテキストの変数名が衝突してしまい、フローの挙動がおかしくなってしまうことがあります。

　全てのタブで共有する必要がある変数以外は、タブ内のノードで共有するフローコンテキストを用いるようにしましょう。

10. デバックタブのみでログを参照する

　Node-REDの開発では、debugノードを用いてデータをデバッグタブに出力し、フローを流れているデータを確認します。この確認方法は開発時の一時的な方法であり、WebSocket接続切断や表示件数超過によってデータがデバッグタブから消えてしまいます。
　ログ管理を行いたい場合は、debugノードのノードプロパティにて「システムコンソール」にチェックを入れます。

　これによってデフォルトで標準出力にログを出力できるため、Papertrailの様な標準出力をログとして収集するツールが使えます。また、settings.jsにlogstash等のカスタムロガーを指定することもできます。

最後に

　Node-REDはプロトタイプで用いることが多いことから、その場限りのフローを書きがちです。しかし、今後フローのバージョン管理機能や、クラウドやエッジデバイスにデプロイできるデスクトップ版Node-REDが一般的になり本番適用が進んでくると、環境に依存しない再利用性の高いフローが重要になってくると考えます。みなさんもアンチパターンのノウハウを見つけましたら、ぜひ共有してみてください。

紹介したフロー