1️⃣ はじめに：なぜOCIでTeslamateを構築するのか
Teslaのログ管理を行うTeslamateは、 「安定した常時稼働」「低コスト」「APIアクセスの安全性」が求められるワークロードです。
その条件を満たすクラウドとして、 OCI（Oracle Cloud Infrastructure）＋ A1.Flex（Arm CPU） は非常に相性が良い選択肢です。
- Always Free枠で0円運用が可能
- Arm CPUの省電力・低負荷特性がTeslamateに最適
- 大阪リージョンの安定性と低レイテンシ
- TailScaleやCaddyとの組み合わせで安全なAPI Proxy構成が作れる
ただし、OCIには「アイドル削除ポリシー」という独特の挙動があり、 これを理解しておくことが安定運用の鍵になります。
2️⃣ OCIのアイドル削除ポリシーとは何か
OCIは内部的に、インスタンスを以下の2つのプールで管理しています。
- Freeアカウント用の共有キャパシティプール
- Payアカウント用の通常キャパシティプール
この違いが、インスタンスの「作成しやすさ」「削除されやすさ」に直結します。
以前構築時に体感した 「FreeだとA1.Flexが全然作れないのに、Pay化したら一発で通る」 という現象も、この構造が理由です。
🖼️ Free と Pay のキャパシティ構造図
┌──────────────────────────────┐
│ OCI 内部キャパシティ構造 │
└──────────────────────────────┘
【Free Tier ユーザー】
┌──────────────────────────────┐
│ Free 専用キャパシティプール（小さい） │
│ ・A1.Flex の枠が非常に少ない │
│ ・利用者が多く常に枯渇 │
│ ・空きがあっても Free 枠が埋まると作れない │
└──────────────────────────────┘
↓（アップグレードすると移動）
【Pay ユーザー】
┌──────────────────────────────┐
│ 通常キャパシティプール（大きい） │
│ ・Free より圧倒的に枠が大きい │
│ ・枯渇しにくい │
│ ・再試行が通りやすい │
│ ・内部キューの優先度が Free より高い │
└──────────────────────────────┘
この図が示すとおり、 Free と Pay は「同じインスタンスを使える」ように見えて、内部的には全く別の世界です。
3️⃣ 実際に発生する削除条件とタイミング
Oracleは公式に明確な閾値を公開していませんが、 実運用の観測から以下の条件が削除対象になりやすいとされています。
- CPU使用率がほぼ0%の状態が長期間続く
- ネットワーク通信が完全に途絶している
- 停止状態のまま数週間以上放置されている
- Always Free枠の容量が逼迫しているタイミング
特に「CPU 0% ＋ ネットワークなし」の組み合わせは危険で、 Freeアカウントでは数週間〜数か月で削除されるケースがあります。
4️⃣ Payアカウント化で挙動はどう変わるか
私が今回行ったように、アカウントをPay化すると挙動は大きく変わります。
- 自動停止 → 基本的に発生しない
- 自動削除 → 有料インスタンスでは発生しない
- Always Free枠 → Freeプールに残るため、削除対象になる可能性は残る
つまり、Pay化は「削除リスクを大幅に下げる」ものの、 Always Freeインスタンスだけは例外的に監視対象のままです。
5️⃣ Teslamate構成が削除リスクを回避できる理由
Teslamateは以下の理由で「アイドル判定」を回避できます。
- 車両の状態ログが定期的に書き込まれる
- CaddyやNginxのアクセスログが自然に生存信号になる
- TailScale接続が常時維持される
- GrafanaやPrometheusが軽負荷で動作し続ける
つまり、Teslamate構成はOCIの削除ポリシーと非常に相性が良く、 常時稼働が前提のワークロードとしては理想的な動作環境と言えます。
6️⃣ まとめ：OCIでTeslamateを安定運用するためのポイント
- Always Free枠は「使われていないと削除される」仕組み
- Payアカウント化で削除リスクは大幅に低減
- Teslamate構成は常時通信があるため削除対象になりにくい
- TailScale＋Caddy＋Teslamateの組み合わせはOCIと非常に相性が良い
総帥の構成は、OCIの特性を最大限に活かした 「安定・安全・低コスト」なTeslamate運用モデルになっています。
コメント