【要約】Streamlit Cloudから Render へ移した判断の記録 -費用と失敗の全部- [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
個人開発者がStreamlit Community Cloudを用いてAIサービスを運用する中で、サービス成長に必要なインフラ要件を満たせない問題に直面した。開発者は、以下の技術的・運用的課題を抱えていた。
- ・SEO対策の困難さ：独自ドメインが利用できず、Google Search Consoleの所有権確認ができない。
- ・可用性の欠如：無料枠では12時間でサービスが停止し、ユーザー体験を損なう。
- ・製品特性の不一致：Streamlitの有料版はSnowflake経由の業務向けであり、消費者向けSaaSには適さない。
// Approach
開発者は、独自ドメインの利用とスリープ回避を目的として、RenderのStarterプランへの移行を選択した。移行にあたり、以下の具体的な手法を用いた。
- ・インフラ構成の分離：既存のWebhook用サービスを維持しつつ、フロントエンドをRenderへ新設した。
- ・環境変数の厳格な管理：Supabaseの公開鍵と管理者鍵を混同しないよう、役割を明確に分離した。
- ・コードの堅牢化：
secrets.tomlが存在しない環境でも動作するよう、try-exceptを用いた環境変数取得ヘルパーを実装した。 - ・DNS設定の実施：AレコードおよびCNAMEを用いて、取得した独自ドメインをRenderに紐付けた。
// Result
インフラの移行により、サービス運営における以下の成果を得た。
- ・SEOの実現：独自ドメインの適用により、Google Search Consoleの所有権確認とインデックス登録に成功した。
- ・可用性の向上：Render Starterの利用により、サービスの自動スリープを解消した。
- ・コストの可視化：ドメイン代、Render代、OpenAI APIの従量課金を含めた運用コストを明確化した。
Senior Engineer Insight
> Streamlitは開発速度に優れるが、消費者向けSaaSへの転用にはインフラの制約が伴う。本件は、ツールが想定する「業務用途」と「消費者用途」の乖離を突いた実戦的な記録だ。特に、Supabaseの管理者鍵（service_role）をフロントエンド側に露出させるリスクへの警告は、フロントエンドとバックエンドの境界を意識する上で極めて重要である。プロトタイプから本番運用へ移行する際の、典型的な「技術的負債の解消」プロセスと言える。