Oracle Cloud Always Free ARMで本番APIを動かす
GRAXELが重いバックエンド処理をポータルから分離して運用する理由です。
Oracle Cloud Always Free ARMで本番APIを動かす
多くのクラウドプロバイダーが提供する「無料枠」のサーバーは、せいぜい1GBのRAMと1つのvCPUであり、本格的なデータベースやAIの実行には到底耐えられません。しかし、例外が存在します。それが、Oracle Cloudが提供する「Always Free」のARMインスタンスです。4つのOCPU、24GBの大容量RAM、そして200GBのブロックストレージ。私はこの信じられないほど寛大な無料インフラ上で、GRAXELの重要なバックエンドAPIを本番運用しています。
本番環境としてのスペックと構成
この強力なARMインスタンス上には、Ubuntu 24.04 LTSをベースとして、pgvectorを組み込んだPostgreSQL 17、RustのAxumで書かれた高性能APIサーバー、さらにはローカルLLMを動かすためのOllamaまで同居させています。メモリが24GBもあるため、1万件を超える政策データのインメモリキャッシュや、大規模なベクトル検索インデックス(HNSW)を展開しても、全くリソースが枯渇する気配がありません。Oracle Cloudの公式ページにある通りのスペックを、本当に1円も払わずに使い倒しています。
2時間を溶かした悪夢:iptablesとOracle Linuxの亡霊
しかし、無料のインフラには必ず「癖」があります。私が最も苦しめられた失敗談は、ネットワークのポート開放に関するものでした。OracleのVCN(Virtual Cloud Network)の管理コンソールで正しくセキュリティリストのIngressルールを設定し、特定のポート(例: 8080番)を開けたはずなのに、外部からのアクセスが全てタイムアウトして繋がらないのです。
設定を何度見直しても間違っていません。最終的にSSHでサーバー内部に入り、パケットの挙動を追跡して判明した原因は、OS内部のファイアウォールでした。Ubuntuイメージを選択してインストールしたにもかかわらず、ベースとなっていた古いOracle Linux時代のiptablesの強固なREJECTルールが、初期設定として深く根付いていたのです。sudo iptables -L INPUTを実行して不要なルールを全てパージするまでに、実に2時間以上の貴重な時間を溶かしました。クラウドプロバイダー独自のOSイメージの挙動を過信してはいけないという、痛烈な教訓です。
Cloudflare Tunnelによるセキュアな公開
この教訓を生かし、現在ではグローバルIPアドレスに対して直接ポートを開放することは一切やめました。代わりにCloudflare Tunnel(cloudflared)を導入しています。サーバー側からCloudflareのエッジネットワークに対してアウトバウンドの接続を確立するだけで済むため、VCNのインバウンドルールは実質的にすべて閉じたまま、安全にHTTPSでAPIを外部公開できています。
無料枠を維持するための生存戦略
Always Freeインスタンスは、一定期間CPUやネットワークの使用率が極端に低いと、Oracle側からリソースを回収(Reclaim)されるというリスクが規約に明記されています。そのため、私はクーロン(cron)を用いて定期的に軽い分析バッチジョブを走らせ、「このサーバーは活発に利用されている」というシグナルを意図的に作り出しています。
1人開発者として、固定費を限界まで抑えつつ高いパフォーマンスを引き出すこのインフラ構築は、一種のパズルゲームのようです。私のより詳しい技術スタックや背景についてはGRAXELについて、または著者ページをご一読ください。インフラ構成に関する議論は大歓迎ですので、ぜひお問い合わせからお声がけください。
共有
関連記事
同じテーマやタグに基づき、GRAXELの運用文脈を続けて確認できます。
無料枠でSaaSポータルを運用する — Cloudflare Pages、Supabase、Upstash
固定費を抑えながら公開サイトを運用するためのGRAXELの考え方です。
Rust Axum + Cloudflare Tunnelでpolicy-api.graxel.aiを運用する
MyHyetaekの背後にある政策検索APIを安全に公開するための構成を解説します。
OllamaでローカルLLMを運用に組み込む — 使いどころと限界
GRAXELがローカルLLMをどのようにコスト削減と自動化に使うかを整理します。