Cloud Runにデプロイしたn8nでワークフローを作成し、セキュアにバッチ処理を実施する
背景
最近流行りのn8nで遊んでいます。
公式のDockerイメージも存在するため、ローカルではとても簡単に始められることが魅力的でした。
n8nはエンジニアのみならず他の人でも触りやすいツールとなっているため、利用拡大を考えCloud Runでホスティングし特定の人であればログインでき、気軽に触れられる環境を作成しようとしました。
作成したもの
今回こちらの記事を参考にさせていただき、同様にGoogle CloudのリリースノートをAI要約するワークフローを作成しました。
異なる点としてはCloud Runにホスティングしているくらいです。
当初考えていた構成
今回行いたい処理は1日一回のバッチ処理であり、それ以外は動かしていないため料金面を考慮し最小インスタンス数は0に設定することを前提に構成を考えていました。
まずCloud SchedulerでCloud Runを起こします。そしてn8n内部のタイマーで定時になったらワークフローを実行し結果をSlackに通知するシンプルな構成です。
n8nのデータはCloud Storageにボリュームマウントしてデータの永続化を実施しました。
ポイントとしてはCloud RunにIAPを直接付与し簡便かつ強力な認証機能を備えているところです。
課題
n8nをCloud Runにホスティングし構築までは簡単にできたのですが、運用面でいくつか問題がありました。
Cloud Runのコールドスタート問題
起動する時は当然コールドスタートが走るのですが、n8nとの相性が悪いらしく数分くらい下記メッセージが出る状態でした。
n8n is starting up. Please wait
そのためもし特定の時間に通知するためには、コールドスタートによる起動時間を加味したSchedulerの設定が必要でした。
Cloud Run x IAPとCloud Scheduler
ホスティングしたCloud Runに対してIAPを用いて簡単に認証機能をつけたのですが、執筆当時プレビュー版であることもあり、ブラウザ以外からのアクセスの制御が大変でした。
具体的にはCloud SchdulerからCloud Runへアクセスしようとすると、いろんな手段を取ってもIAPの認証を超えられず断念してしまいました。
課題解決した実装
構成の再検討
今回はなるべく簡便に尚且つセキュアに実装したかったので構成を再度検討し以下のような構成にしました。
ポイントとしては新たに実行サーバーとしてCloud Run Jobsを作成したところです。
同じCloud StorageをマウントしCloud Schedulerで実行することで、サーバーごとに役割を分割しました。
詳細
Cloud Run（管理画面）
特に工夫はしていないです。イメージも公式のイメージを直接使用しています。ボリュームはCloud Storageに画像のように設定しています
Cloud Run Jobs（実行サーバー）
ここが唯一の工夫点です。
あまり知られていないのですが、n8nには公式でCLIコマンドが存在します。ワークフローのIDを指定することで実行が可能です。
なおIDは管理画面でワークフローを開いたページのURLから取得できます。
同じデータを使用してCLIの実行だけ別サーバーとして設けることでIAPの認証もなく、n8nのダウンタイムも解消することができました。
最後に
最初だけエンジニアの手が必要ですが、ここだけ構築できれば他の人でも簡単に管理ができると思いますので、何かのお役に立てれば幸いです。
Discussion