Oracle Cloud Always Free ARMで本番APIを動かす

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について、または著者ページをご一読ください。インフラ構成に関する議論は大歓迎ですので、ぜひお問い合わせからお声がけください。