1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

RustのWebアプリをCloudflare Workersにデプロイしてみたら、驚くほど簡単で安かった

1
Posted at

こんにちは。コロンビア大学の博士課程でシステムセキュリティ・AIを研究している Koukyosyumei です。

さて、皆さんはRustでWebアプリケーションを開発するとき、デプロイ先として何を使っていますか?AWS EC2やECS、Fly.io、Renderなど、数えきれないほどの選択肢がありますが、最近はCloudflare Workers もかなり便利なのではないかと感じています。

筆者は普段Rustをメインに開発を行っているのですが、Cloudflare Workersは最近Rustのサポートを急速に拡大させています。例えば、RustをWebAssembly (Wasm) にコンパイルすることで、Rustで書いたWebアプリケーションをそのままエッジ環境で実行できます。そのため、axumやh5iなどのweb フレームワークで通常通り作成したRustのプログラムを、簡単にデプロイすることができます。

この記事では、最近筆者が暇つぶしでo5s というRust製のWebアプリケーションを作った経験をもとに、RustアプリケーションをCloudflare Workersで公開する方法や、料金・使い勝手について紹介します。

Cloudflare Workersとは?

Cloudflare Workers は、Cloudflareが提供するサーバーレスのアプリケーション実行環境です。一般的なVPSや仮想マシンとは異なり、サーバーのセットアップや管理を自分で行う必要がなく、コードをデプロイするだけで、Cloudflareのグローバルネットワーク上でアプリケーションを公開できます。

特に便利だと感じたのは、以下の点です。

  • サーバー管理が不要:OSの更新、Webサーバーの設定、プロセス管理などを自分で行う必要がない
  • 無料枠が大きい:1日10万リクエストまで無料で利用できる
  • デプロイが簡単:基本的には wrangler deploy だけ
  • HTTPSが標準で利用可能:workers.dev のサブドメインが提供される
  • GitHubとの連携:GitHubへのpushをきっかけにビルド・デプロイできる
  • Rustをサポート:RustコードをWasmにコンパイルして実行できる

コンパイルしたバイナリをLinuxサーバーに配置し、リバースプロキシやTLS証明書を設定するなどの作業は、Cloudflare側で自動的にやってくれます。

RustでCloudflare Workersを使う

Cloudflareは、Rust向けの公式SDKとして workers-rs を提供しています。これを用いると、Rustのコードは wasm32-unknown-unknown ターゲット向けにコンパイルされ、Cloudflare Workers上で実行されます。

まずは開発環境を準備します。

rustup target add wasm32-unknown-unknown
cargo install cargo-generate

次に、公式テンプレートからプロジェクトを作成します。

cargo generate cloudflare/workers-rs

生成されたプロジェクトには、Rustコードのほかに wrangler.toml という設定ファイルが含まれています。WranglerはCloudflare Workersの開発・デプロイ用CLIで、これだけで、Rustで書いたAPIをインターネットに公開できます。

# ローカルで実行
npx wrangler dev

# Cloudflareにデプロイ
npx wrangler deploy

初回はCloudflareへのログインやサブドメインの設定が必要ですが、一度設定すれば、以降はCLIから簡単に更新できます。詳細は公式のRustガイドにまとまっています。

実例:Rust製Webアプリケーション「o5s」

今回Cloudflare Workersにデプロイしたのは、先週末に暇つぶしで開発してみた o5s というオープンソースプロジェクトです。

o5sは、多数のAIエージェントが同じコードベースを並行編集することを想定した、Git互換のバージョン管理・コラボレーションシステムです。通常のGitでは、複数のエージェントが同時にコードを変更すると、rebaseやコンフリクト解決がボトルネックになることがあります。そこで、o5sでは、変更を依存関係付きのpatchとして管理し、競合しない変更を順序に依存せず統合できる仕組みを実装しています。

ただし、今回紹介したいのはバージョン管理アルゴリズムではなく、そのWebアプリケーションをどのようにホスティングしたか、という部分です。

アプリケーション構成

o5sのバックエンドはRustで実装されています。Webフレームワークには、Axumベースの h5i-app を使用しています。

h5i-appは、通常のRust Webアプリケーションを構築するためのフレームワークで、Axumのエコシステムを利用しながら、必要に応じてLean 4を使った形式検証も行えることが特徴です。例えば、認可チェックや状態遷移など、アプリケーションの重要なロジックについて、Rustの実装をLean 4へ変換し、性質を数学的に証明できます。o5sでもこの仕組みを使い、パッチの承認条件や組織間のデータ分離などの性質を検証しています。

ローカルとCloudflare Workersでロジックを共有

o5sは、ローカル環境ではAxumベースのHTTPサーバーとして、Cloudflare環境では workers-rs を使ったWorkerとして動作します。

ここで便利なのは、アプリケーションのコアロジックを両方の環境で共有できることです。デプロイ先に応じてHTTPリクエストの受け取り方は異なりますが、ビジネスロジックを二重に実装する必要はありません。

o5sでは、おおむね次のような構成にしています。

              Web UI / API Clients
                       |
              +--------+--------+
              |                 |
         Local Server      Cloudflare
           (Axum)            Workers
              |                 |
              +--------+--------+
                       |
              Shared Rust Logic
                 (h5i-app)
                       |
                  PostgreSQL
                       |
              Lean 4 verified core

実際にはCloudflare側ではHyperdrive経由でPostgreSQLへ接続し、Gitリポジトリの保存にはCloudflare Artifactsも利用しています。

Cloudflare Workersへのデプロイ

実際のo5sでは、リポジトリのルートに wrangler.toml を配置しています。設定の一部を抜粋すると、次のようになっています。

name = "o5s"
main = "crates/worker/build/index.js"
compatibility_date = "2026-10-01"

[build]
command = "[ -f build.sh ] || cd crates/worker; sh build.sh"

[placement]
region = "aws:us-east-1"

設定ファイル全体はこちらで確認できます。main にはビルドされたWorkerのエントリーポイントを、build.command にはRustコードをWasmへコンパイルするためのコマンドを設定しています。

また、今回のアプリケーションはPostgreSQLを利用しているため、CloudflareのHyperdriveを使用しています。Hyperdriveは、Workersから外部のPostgreSQLなどへアクセスするためのサービスで、接続プーリングなどを提供しています。

デプロイコマンド

RustからWorkers向けのWasmを生成するために、worker-build を使います。

cargo install worker-build

o5sでは、必要なビルド処理をスクリプトにまとめています。

# Cloudflareへのログイン
npx wrangler login

# デプロイ
npx wrangler deploy

PostgreSQLのテーブル作成やSecretの登録などは事前に済ませる必要がありますが、アプリケーションの更新自体はこのコマンドで完了します。デプロイ後は、独自ドメインを持っていなくても、Cloudflareが提供する workers.dev サブドメインに公開されます。

さらに、GitHub連携のWorkers Buildsを使えば、main ブランチへのpushに合わせて自動的にビルド・デプロイすることもできます。

料金がかなり安い

2026年10月時点のCloudflare Workersの料金は、以下のようになっています。

項目 Free Paid(Standard)
基本料金 $0 $5/月
リクエスト数 10万/日 1,000万/月を含む
超過リクエスト 無料枠超過後は制限 100万回あたり$0.30
CPU時間 1リクエストあたり10ms 月3,000万CPU-msを含む
CPU時間の追加料金 — 100万CPU-msあたり$0.02

出典:Cloudflare Workers Pricing

例えば、1日1万リクエスト程度の小規模なWeb APIであれば、CPU時間などの制限にも収まる限り、無料枠だけで運用できるので、個人開発や小規模なWebアプリケーションにとっては、かなり余裕のある数字ではないでしょうか。

もちろん、実際の料金はCPU使用時間に依存します。また、PostgreSQLやCloudflare Artifactsなどの外部サービス・追加機能の費用は別途考える必要があります。

RustでWorkersを使う際の注意点

もちろん、Cloudflare WorkersがすべてのRustアプリケーションに最適というわけではありません。実際に使ってみて、特に注意が必要だと感じた点もあります。

1. すべてのRust crateが使えるわけではない

WorkersではRustをWasmにコンパイルして実行するため、Linuxのシステムコールやネイティブライブラリに依存するcrateは、そのままでは動作しない場合があります。

例えば、通常のサーバー環境向けに実装されたファイル操作やネットワーク処理では、Workers向けの実装への切り替えが必要になることがあります。Cloudflareは対応crateに関するガイドも公開しています。

2. データベースは別途用意する必要がある

Workers自体は、一般的なLinuxサーバーのようにローカルディスクへ永続的なデータを書き込んで保存する環境ではありません。そのため、データの永続化には、Cloudflare D1、KV、R2、あるいは外部のPostgreSQLなどを使用する必要があります。

まとめ

今回、Rust製のWebアプリケーションであるo5sをCloudflare Workersへデプロイしてみて、RustのWebアプリケーションにとってかなり魅力的な選択肢だと感じました。RustでWebサービスを作っていて、デプロイ先を探している方は、ぜひ一度Cloudflare Workersを試してみてください。

参考リンク

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?