はじめに
最近、ワークフロー自動化ツールの「n8n」をお客様のPoC案件でホスティングする必要がありました。コストはできるだけ抑えつつ、いざという時にはスケールできるような、そんな都合の良い環境が作れないだろうか。そう考えて、Google Cloud RunとSupabaseの組み合わせに挑戦してみることにした、というのが今回の話です。
今回はその過程でちょっとハマった、いくつかの「壁」の解消方法をシェアします。
ちなみに、基本的なアイデアはzerebomさんの記事「n8n + Cloud Run + supabaseで「AIニュース要約Bot」を自作してDiscordに流すまで」を参考にさせていただきました。素晴らしい記事に感謝です。
今回の構成の面白いところは、n8n本体をCloud Runでサーバーレスに動かし、データベースにはSupabaseの無料枠を活用している点です。これによって、普段はほとんどコストがかからず、使った分だけ支払うという環境が手に入ります。
なぜこの構成にたどり着いたのか
ご存知の方も多いと思いますが、n8nには公式のクラウド版も存在します。ただ、正直なところ、PoCで色々と試すには月額料金が少し気になってしまう価格帯かな、と感じていました。そこでセルフホストの道を探ることにしたのですが、私の中にはいくつかの譲れない要件がありました。
- 低コストであること: これはもう絶対です。PoCプロジェクトなので、できるだけ費用はかけたくありません。
- スケールできること: 今は小さくても、将来的にアクセスが増えた時に柔軟に対応できると嬉しいです。
- メンテナンスが楽なこと: サーバーの面倒を見る時間は、できるだけ他の創造的なことに使いたいです。
- セキュリティが確保されていること: 当然ですが、安心して使えることは大前提です。
どんな構成になったのか
最終的に出来上がった構成は、非常にシンプルです。
ユーザー → Cloud Run (n8nコンテナ) → Supabase (PostgreSQL)
使った技術は以下の通りです。
- n8n: 言わずと知れたワークフロー自動化プラットフォーム
- Google Cloud Run: 個人的に大好きなサーバーレスコンテナ環境
- Supabase: これまた大好きなBaaS。今回はPostgreSQLデータベースとして活用
- Docker: アプリケーションのコンテナ化の必需品
- Artifact Registry: Dockerイメージを置いておく場所
設定中にハマった壁
実際にデプロイを始めてみると、情報のアップデートもあるようで、いくつかの予想外の問題にぶつかりました。ここでは、その試行錯誤の過程を共有したいと思います。
1. Supabase接続方式の選択という、最初の罠
最初にぶつかった壁が、Supabaseへの接続方式でした。「Database is not ready」という無慈悲なメッセージが表示され、先に進めなくなってしまったのです。
どうやら、Supabaseには主に3つの接続方式があるようです。
- Direct Connection: データベースへの直接接続
- Transaction Pooler: 短時間のトランザクションに特化したプール
- Session Pooler: セッション単位のプール
最初は何も考えずに「Direct Connection」を使っていたのですが、これが間違いの始まりでした。Cloud Runから接続すると、なぜか頻繁にタイムアウトしてしまいます。
調べてみると、どうやらDirect ConnectionはIPv6でのアクセスを前提としているらしく、多くのクラウドサービスで一般的なIPv4環境だと接続が不安定になりがち、ということのようです。これはなかなかの罠じゃないでしょうか。
そこで解決策として選んだのが、Transaction Poolerへの切り替えです。こちらはIPv4に対応しており、Cloud Runのようなサーバーレス環境からの接続に最適化されているとのこと。まさに、今回のためのような仕組みですね。
# Direct Connection (うまく動かなかった設定)
DB_POSTGRESDB_HOST=xxx.supabase.co
DB_POSTGRESDB_PORT=5432
# Transaction Pooler (正解だった設定)
DB_POSTGRESDB_HOST=aws-1-ap-southeast-1.pooler.supabase.com
DB_POSTGRESDB_PORT=6543
ちなみに、ユーザー名の形式もpostgres.プロジェクトIDのように少し変わるので、注意が必要かもしれません。
2. ライセンス登録で心を折る「403エラー」
次に現れたのが、ライセンス登録の壁でした。n8nを起動すると、コミュニティライセンスの登録画面が出てくるのですが、何度やっても「Failed to register community edition: Request failed with status code 403」というエラーが出て、一瞬途方に暮れました。
これも調べてみると、n8nのライセンス認証はセキュリティ上の理由からHTTPS接続が必須になっているようです。HTTPでアクセスしようとすると、403エラーを返す仕組みなのですね。
「でも、Cloud RunのURLは最初からHTTPSのはずでは？」と思ったのですが、どうやらn8nのアプリケーション自身に「君はHTTPS環境で動いているんだよ」と明示的に教えてあげる必要があったようです。なるほど、そういうことか。
解決策は、先程のTransaction Poolerに加えて、N8N_EDITOR_BASE_URLという環境変数を設定してみました。
N8N_EDITOR_BASE_URL=https://your-cloud-run-url.run.app
これを設定することで、n8nが自身の状況を正しく認識し、無事にライセンス登録を完了させることができたのかもしれません。
3. じっと待つことの大切さ（データベース接続タイムアウト）
Cloud RunからSupabaseへの接続で、初期化処理中にタイムアウトが発生することがありました。特にn8nの初回起動時は、データベースのマイグレーション処理が走るため、思った以上に時間がかかることがあるようです。
この問題に対しては、おそらくSSL接続を明示的に有効にすることで解決できたように思います。
DB_POSTGRESDB_SSL=true # SSL接続を強制
根本的な解決になったかは断言できませんが、結果的にこれで安定したので、同じ問題に直面した方は試してみる価値はあるかもしれません。
環境変数の最終設定
そんなこんなで試行錯誤を繰り返した結果、最終的に以下の環境変数設定に落ち着きました。
# Google Cloud設定
PROJECT_ID=your-project-id
SERVICE_NAME=n8n-app
REGION=asia-northeast1
REPOSITORY=n8n-repo
# n8n基本設定
N8N_ENCRYPTION_KEY=生成した暗号化キー
N8N_BASIC_AUTH_PASSWORD=強固なパスワード
# Supabase設定（Transaction Poolerを使うのがポイント）
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=aws-1-ap-southeast-1.pooler.supabase.com
DB_POSTGRESDB_PORT=6543
DB_POSTGRESDB_DATABASE=postgres
DB_POSTGRESDB_USER=postgres.プロジェクトID
DB_POSTGRESDB_PASSWORD=Supabaseパスワード
DB_POSTGRESDB_SCHEMA=public
DB_POSTGRESDB_SSL=true
# HTTPS設定（ライセンス登録の鍵）
N8N_EDITOR_BASE_URL=https://your-cloud-run-url.run.app
ちなみに、Basic認証に関する変数は、どうやら2023年頃からサポートされなくなったようです。なので、以下の設定は残念ながら効果がありませんでした。これも一つの発見ですね。
N8N_BASIC_AUTH_ACTIVE, N8N_BASIC_AUTH_USER, N8N_BASIC_AUTH_PASSWORD
(参考: Self-hosted n8n basic auth not working, always redirected)
デプロイまでの道のり
実際のデプロイは、大まかに以下のステップで進めました。
- Google Cloudプロジェクトの準備: 新しいプロジェクトを作り、Cloud Run、Cloud Build、Artifact RegistryのAPIを有効化します。
- Supabaseプロジェクトの作成: 無料アカウントでプロジェクトを作り、Transaction Poolerの接続情報をメモしておきます。
-
環境変数の設定:
.envファイルなどに、これまで集めた情報を書き込みます。暗号化キーもopenssl rand -hex 32のようなコマンドで生成しておきましょう。 - デプロイ実行: スクリプトを実行し、Cloud Runの世界へ旅立たせます。
実際に運用してみた感想
実際にこの環境を運用してみると、当初の期待を上回る快適さでした。
- コスト面: アクセスがない時は本当に静かで、コストもほぼゼロ。使いたい時だけリソースが立ち上がる、この従量課金モデルはやはり素晴らしいと感じます。
- 性能面: Cloud Runが自動でスケールしてくれるので、負荷の心配から解放されます。
- メンテナンス性: サーバー管理という概念がなくなり、アプリケーションの更新もDockerイメージを再デプロイするだけ。これは本当に楽です。
- セキュリティ: HTTPS通信やSSL接続など、基本的な要件は満たせているので、安心して使えています。
トラブルシューティングのヒント
今回の私の経験から、同じような構成に挑戦する方のために、いくつかヒントを残しておきたいと思います。
- Supabaseの接続方式: Cloud Runのようなサーバーレス環境なら、迷わず「Transaction Pooler」を選びましょう。Direct Connectionは、一見すると直接的で良さそうに見えますが、思わぬところで足元をすくわれるかもしれません。
-
ライセンス登録エラー: もしn8nでHTTPS関連のエラーが出たら、まずは
N8N_EDITOR_BASE_URLの設定を思い出してください。 - 初期化の待機時間: 初回デプロイ後、「Cannot GET /」と表示されても、慌てないでください。2〜3分ほどコーヒーでも飲みながら待っていると、データベースのマイグレーションが完了し、魔法のように画面が表示されるはずです。
まとめ
n8nをCloud RunとSupabaseで動かすという今回の試みは、特に、PoC（概念実証）のような小さなプロジェクトでも、コストを気にせず気軽に始められるこの構成は、多くの人にとって価値があるのではないでしょうか。
この試行錯誤の記録が、ワークフロー自動化の新たな可能性を探っている方や、同じような構成を考えている方の、何かしらのヒントになれば嬉しいです。
About me
現在、市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
ぜひお気軽にチャットしましょう！
お仕事のご相談は以下まで、AIエージェントの開発や研修、調査代行やビジネスコンサルなどの対応も可能です。
生成AIデスクリサーチサービス Deskrex | サービスページ
生成AIデスクリサーチエージェント Deskrex App | アプリケーションサイト
DeskrexAIリサーチ | メディア
株式会社Deskrex | 会社概要
Deskrex | Xページ
- 会社概要：https://www.deskrex.ai/
- Deskrex App：https://app.deskrex.ai/
- サービスページ：https://lp.deskrex.ai/
- メディア：https://media.deskrex.ai/
- X：https://x.com/deskrex
Discussion