Rust Axum + Cloudflare Tunnelでpolicy-api.graxel.aiを運用する

Rust Axum + Cloudflare Tunnelでpolicy-api.graxel.aiを運用する

インターネット上にAPIサーバーを公開した瞬間から、無数のボットによるポートスキャンや脆弱性探索が毎秒数十回のペースで襲いかかってくることをご存知でしょうか。私はOracle Cloud上で動作する内製API（policy-api.graxel.ai）を構築した際、IPアドレスを直接公開することの恐ろしさを痛感しました。パフォーマンスを犠牲にせず、いかにしてセキュアなバックエンドを構築するか。Rust（Axum）とCloudflare Tunnelを組み合わせた、私の実戦的な運用記録です。

なぜRust Axumを選んだのか

このAPIは、11,600件の政策データに対する複雑なベクトル計算と全文検索を担っています。PythonのFastAPIやNode.jsも候補にありましたが、限られたメモリ（Oracle無料枠）で最大の並行処理性能を引き出し、かつランタイムの予期せぬクラッシュを防ぐために、型安全なRustを採用しました。Webフレームワークとして選んだAxumは、マクロの魔法が少なく、ミドルウェアの層が非常に直感的に記述できる点が優れています。最大接続数（Max Connections）をあえて12〜14程度に絞り込むことで、DBへの負荷を完璧にコントロールしています。

Cloudflare Tunnelによる「ステルス化」

セキュリティの観点から、サーバーのインバウンドポート（80番や443番）は一切開放していません。代わりにCloudflare Tunnel（cloudflared）をデーモンとして常駐させ、サーバー内からCloudflareのエッジへ向かってトンネルを掘り、そこへトラフィックを流し込んでいます。これにより、APIはグローバルIPを持たずして安全にHTTPSで世界中に公開されています。

ダウンタイム2秒の罠とBlue-Greenデプロイ

運用開始から1ヶ月後、私はAPIのバイナリを更新する際、単純にsystemctl restart policy-apiというコマンドで再起動をかけていました。Rustの起動は極めて速いため、ダウンタイムはわずか「2秒」程度でした。私はこれで問題ないと思っていました。

しかし、アクセスログを見て青ざめました。この2秒の間にトンネルを経由してアクセスしてきたユーザーに対し、Cloudflareは容赦なく「502 Bad Gateway」の真っ赤なエラー画面を返していたのです。ユーザー体験としては最悪です。私はこの失敗を猛省し、直ちにアーキテクチャを改修しました。
現在はポート8080（Blue）と8081（Green）の2つのプロセスを用意しています。新しいバージョンをアイドル状態のポートで立ち上げ、ヘルスチェック（/health）が完全に通ることを確認してから、cloudflaredのルーティング設定を瞬時に切り替える方式です。この簡単なBlue-Greenデプロイメントの導入により、現在では5xxエラーの発生率は0.01%未満に抑え込まれています。

セキュアで可用性の高いAPI設計は、SaaSの心臓部です。私たちのプラットフォームの全体的なビジョンについてはGRAXELについてを、技術的なディスカッションをご希望の方はぜひお問い合わせからご連絡ください。1人開発のインフラ論は、語り尽くせません。