ローコードとは

Zapier、IFTTT、あるいは国産のエンタープライズ向けソリューションまで…ノーコード・ローコードは昨今大企業のバックオフィスのRPAの代替から、本格的なサーバーサイドの補助実装まで、広く使われるようになってきました。ローコードのシステムとしては後発であるn8nについて、導入してみた感想を書いてみます。

競合ローコードツールと比較したn8nの特徴

OSS（フェアコードライセンス）でAWSにデプロイ可能

n8nを自社で契約したインフラ上で稼働させる事をセルフホストと呼ぶのですが、その場合、ライセンスとしては無料のライセンスと、エンタープライズのライセンス2形態を選ぶことができます。
エンタープライズライセンスの場合、ユーザー管理やワークフローのシェア等、コラボレーション機能について自由度が出るのですが、社内業務用途であれば無料のライセンスを利用して、インフラコストのみで利用でき、なおかつ自由にスケーリングできるローコード環境を整備することが出来ます。

Zapierと比較すると連携先は少ないが、ある程度主要なサービス間連携はノーコードで実装できる

ワークフローとしての手続きの構築手法（Schedule, IF, SplitInBatchなど）はZapierと比較して変わらない感じ。n8nはワークフローのコンポーネントをNodeと呼ぶが、それら自体のサービス連携用のNodeの数自体は劣る上に、コミュニティNode（有志が作ってnpmにpublishされたNode）も少なく、連携が弱い場合は自前でCodeを実装しなければならないため、実装難易度としては高く、ノーコードで完成するパターンは少ない。
しかし、n8nならではの機能もあり、一概に「Zapier Altternative」と言うわけにもいきません。

• 柔軟なフロー分岐・ハンドリングが構築可能
  • 1つのワークフロー内での予期せぬエラー等に対する再実行のポリシーや、IF/Merge/Case/Loop等の思い描く処理を楽に実装できる
• テストの実行が容易で、デバッグがやりやすい
  • 特定ステップまで実行して、その時のコンテキストをチラっと見たり、CodeノードでConsole.logしたり、開発に対するイライラは少ない

セルフホストって何？

簡単に言うとn8nのコードはオープンソースで公開されているため、自分たちの好きなインフラ上で構築すればメモリが許す限りの長いワークフローを構築したり、実行数の制限なくn8nを使い倒すことが出来ます。

n8nはワンコードのモノリシックなサービスとしてデプロイ出来ますが、デプロイ実行時の寸断や高負荷時のスケールアップ戦略を考慮すると、上図のような構成になります。（→参考）

• WebUI(main)インスタンスはWeb管理画面をリッスンするためのインスタンスで、これは必ずシングルインスタンスでなければいけません
  • 認証系や、管理画面の操作のコンテキストがサーバーのメモリ上に格納されているため、セッションをRedisで保有して冗長化…みたいな構成を取れないので2インスタンス以上をロードバランサで処理するとバグる。
• WebHookインスタンスはWebHookをリッスンしてワークフローが動くようRedisにジョブを送る。冗長化可能だし、Workerインスタンスが兼務しても良い。冗長化可能。
• Workerインスタンスは送られてきたジョブを逐次実行してゆく。冗長化可能。

簡単なタスクスケジューラーで予算が少なければもちろんシングルインスタンス構成であっても良いですが、n8n謹製のSaaS版のほうが安定しているとも言えますし、使い倒す気があるのであれば最初から冗長化構成を組んでしまったほうが楽です。
公式資料ではAWS EKSでの構築について書かれていますがマイクロサービス構成においてサービス間の協調動作はすべてDBとRedisを経由しているので、ECSにデプロイしても、Elastic Beanstalkにデプロイしても動きます。

弊社のテスト環境ではECSを要するほど複雑ではないと考え、Elastic Beanstalk上に2アプリを共有ALBで構築し、片方がスケールアップを取れるように構成しています。
1ワークフローあたりの最大のメモリ使用量が10MB程度であれば、ざっくり2~3万で十分稼働できる構成が組めそうです。
組んだ感想としては、

• DBレイヤーは頻繁にデータの出し入れをしないので、IOPSは求められない(RDS for MySQLのt2.mediumでも十分使えそう。ServerlessV2等の柔軟なスケーリング構成は要らなかったし0.5ACUの最小構成からスケールアップした痕跡もない)
• Redisは一番小さい構成でOK。
• ワーカーはオンメモリでNodeの処理をするものの、処理のタイミングが極端に寄らなければt3.micro系でも十分パフォーマンスが出る

といった感じで、アプリケーション全体としてかなり軽量な印象を受けました。データの永続化さえ注意できるならVPSに雑にデプロイしても十分実用に耐えうるといった感じです。パフォーマンスベンチマークは取っていませんが、DB読み込み、DB書き込みが1回ずつあるようなワークフローでも実行時間0.2秒でWebhookのリクエスト～レスポンスが終わる。

n8nで注意しなければならないこと

• ユーザー管理としてロールの粒度がしょぼいので、特権ユーザー以外は別のユーザーのワークフローを閲覧することができず、運用的にはパスワード共有にならざるをえない
  • →フェアコードライセンスらしく、無料で使えるのですがかゆい所に手を伸ばすにはエンタープライズライセンスを契約するか、運用を仕様に合わせる努力が必要です。
• Credentialsの保持は一律サーバー環境変数のENCRYPTION KEYでDB内では暗号化されているが、KMS等の暗号化の仕組みが無かったり、Nodeを経由して次のNodeで秘密鍵を使う場合等、コンテキストをまたいでデータを渡すとRedisで平文で保存されてしまう
  • セキュアなインフラ環境において問題になりづらいが、DBとサーバーにアクセス出来る人間は暗号化済み文字列とサーバー内で保持されている暗号化キーを使って復号化できてしまう
  • →サーバー、DB自体を触れる人間は限定しておく
• Workflowの複雑さにも寄るが、実行ログを長期間保持しようとすると結構ストレージを食う
  • n8nの実行ログ（時間や成功可否、フローをどのように通ったか等）はDBで保持される。下図は1ヶ月でおおよそ25万件のワークフローを実行した結果、容量が3GB増えているのがわかる。この程度と言ってしまえばこの程度だが、サーバーのストレージを食わないようにしたい場合はログローテーション（破棄）を短くしたり、件数の上限を設定したほうが良い（→参考）

• WebHookのエンドポイントは簡単に実装できるが、CORS処理は実装できない（WebHookのエンドポイントに対してOptionsリクエストが存在しないためブラウザでエラー）ため、Nginx等サーバーのレイヤーでなんとかするか、前段にCORSを許可するAPI Gatewayをリバースプロキシとして設置する等の対応が必要
  • そもそもリクエストが不用意にスパイクしうるフロントエンド向けAPIとしては、DBに実行ログを残す堅実な設計思想の意に反しているため、そもそもこの使い方は推奨されるべきではないです（内部向けAPIとしてならギリ許せる）

実務でn8nを導入するために必要なこと

取引先の企業に対してn8nの導入を支援している所（30-80人規模のIT系）があるのですが、主に構築面としての所感は次の通りです。

• n8nのワークフロー構築はローコードではあるものの、「このステップで5件のJSONが出るんだけど1回しか実行されない」であるとか、出力形式について1:nでフローが肥大化するアーキテクチャであることを理解していない等による相談ケースがあるため、ローコードの実装者に対する継続的なアドバイスが必要
  • 「クセが無い完全なるローコードツール」としては未だ発展途上のツールであることを理解してもらう
• 実行漏れや内部エラーの遭遇は無い
  • SaaSとして提供されているツールなだけあってOSSとしての安定性はある程度担保されているみたいです。ただしForumを見ていると若干怪しい挙動があったりデグレ報告もあるので、アップデート実施時はちょっと注意する必要がありそう。
• 思ったよりも軽量
  • 秒間◯◯req/sみたいな過度なパフォーマンスを求められさえしなければ、少ない費用でクラウド版のローコードツールを超えた実行数や柔軟性を得ることが出来ます。
• Elastic Beanstalk環境が意外と使いやすい
  • GUIによるデプロイメントの管理、ヘルス状況の監視、Cloudwatchへのサーバーリソースの記録、およびアラート監視体制の構築など、ちょっと要件がフワっとしている状況の中では「とりあえずElastic Beanstlakのエコシステムの中で管理できる」システムである、という点は導入コストや管理の手間、ドキュメンテーション化からしてメリットは大きいと思います。
• Custom Nodeは需要はあれど、完パケとしてnode_modules化するほど仕様が決まりきっていないので結局Codeノードでなんとかしちゃう
  • 独自の外部連携（Web3.jsやAthena等、既存のNodeで処理出来ないタスク）はDockerイメージをビルドする時に対象のnpmライブラリを一緒に突っ込んであげればCodeノードでrequireできてしまうので、わざわざ「この要件のためにCustom Node実装してデプロイします」みたいな形にならず、惰性でDockerイメージが肥大化してゆく
  • Codeノードはビルド済みのノードと比較してインタプリタのオーバーヘッドが大きい、との言説があるものの無視できるレベルだと思いますが、結局npmライブラリって破壊的なメソッドの変更も含まれているので、ある日デプロイした時にうっかりライブラリのバージョンが上がったことによる破壊的変更に巻き込まれてワークフローが死ぬ、というリスクは認識しなければならない
    • npmモジュールを入れる時は、ライブラリのバージョンをlatestではなく固定のバージョンでfixしておいた方がよさげ。でもワークフローでrequireされているモジュールを逆引きするのは折れる（DBに部分一致でrequire構文を引っ張れば抽出はできそうだけど）ので、このnpmライブラリ使ってたっけ…？みたいなフワっとした運用だと間違いなく事故る。これは運用が長期化した時に起こりうるリスクだと思います。

もう一つのセルフホスト型ローコードツール「Activepieces」について

今年の頭くらいにredditのとあるコミュニティで「私たちは、Zapier に代わるオープンソースの Activepieces を構築しました。」という投稿があり、GitHubのStarも3000に届きそうな勢いで、セルフホスト型ローコードツールに対するダークホースだという認識があります。
少し触ってみたのですが完全にZapierクローンといった感じで、UI/UXの触り心地は評価があるようですが、現状ではバージョンが0.4.0と、リリースノートを見ても実用に届くにはまだまだ時間がかかりそうなプロジェクトに見えます。
ただし、このプロジェクトはMITライセンスで頒布されており、n8nと比較して非常にゆるい再頒布や改変を含めて商業的な利用が見込まれていることから、コミュニティとして開発が力強く続いていく様子が見て取れます。
自社で大規模なローコード環境を構築する場合、いつかはこちらも検討するべきソフトになる予感がします。

最後に

弊社では、n8nを始めとしたローコードツールの導入からワークフローの構築まで、知見と責任を持って取り組むリソースがございます。
この記事をご覧になってローコードツールの活用にご興味がある場合、お気軽にご相談下さいませ。