実際にワークフローを組んでみた図。ローコード自体を知らない人でも理解できる。
ローコードとは
Zapier、IFTTT、あるいは国産のエンタープライズ向けソリューションまで…ノーコード・ローコードは昨今大企業のバックオフィスのRPAの代替から、本格的なサーバーサイドの補助実装まで、広く使われるようになってきました。ローコードのシステムとしては後発であるn8nについて、導入してみた感想を書いてみます。
競合ローコードツールと比較したn8nの特徴
OSS（フェアコードライセンス）でAWSにデプロイ可能
n8nを自社で契約したインフラ上で稼働させる事をセルフホストと呼ぶのですが、その場合、ライセンスとしては無料のライセンスと、エンタープライズのライセンス2形態を選ぶことができます。 エンタープライズライセンスの場合、ユーザー管理やワークフローのシェア等、コラボレーション機能について自由度が出るのですが、社内業務用途であれば無料のライセンスを利用して、インフラコストのみで利用でき、なおかつ自由にスケーリングできるローコード環境を整備することが出来ます。
Zapierと比較すると連携先は少ないが、ある程度主要なサービス間連携はノーコードで実装できる
ワークフローとしての手続きの構築手法（Schedule, IF, SplitInBatchなど）はZapierと比較して変わらない感じ。n8nはワークフローのコンポーネントをNodeと呼ぶが、それら自体のサービス連携用のNodeの数自体は劣る上に、コミュニティNode（有志が作ってnpmにpublishされたNode）も少なく、連携が弱い場合は自前でCodeを実装しなければならないため、実装難易度としては高く、ノーコードで完成するパターンは少ない。 しかし、n8nならではの機能もあり、一概に「Zapier Alternative」と言うわけにもいきません。
- 柔軟なフロー分岐・ハンドリングが構築可能
- 1つのワークフロー内での予期せぬエラー等に対する再実行のポリシーや、IF/Merge/Case/Loop等の思い描く処理を楽に実装できる
- テストの実行が容易で、デバッグがやりやすい
- 特定ステップまで実行して、その時のコンテキストをチラっと見たり、CodeノードでConsole.logしたり、開発に対するイライラは少ない
セルフホストって何？
簡単に言うとn8nのコードはオープンソースで公開されているため、自分たちの好きなインフラ上で構築すればメモリが許す限りの長いワークフローを構築したり、実行数の制限なく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書き込みともにレイテンシを気にするシーンは今のところありません。