Herokuの現状と移行の必要性について
- 「Herokuが終了するというわけではありませんが、メンテナンスモードのような状態になり、これ以上の発展が見込めないため移行先を探しています」
- 「Salesforceの方針として、Herokuというプラットフォーム自体を積極的に運営するよりも、別の方向に注力したいという背景があるようです」
- 「既存の環境は使えますが、将来性やコスト感を踏まえると『もっと良い選択肢はないか』と模索している段階ですね」
今回のテックトークでは、長年Web開発の定番プラットフォームとして親しまれてきたHerokuの現状と、それに代わる新たなインフラ選定について議論が交わされました。
Herokuが完全にサービス終了するわけではありませんが、実質的なメンテナンスモードに入っており、新しい機能追加や積極的なサポートが見込めない状況です。特に新人研修や小規模な案件において、Herokuの手軽さは非常に魅力的でしたが、コスト面や将来性を考慮すると、そろそろ別のプラットフォームへ移行すべき時期に来ているという認識で一致しました。
研修・開発環境に求められる要件定義
- 「研修で使う上では、Linuxやネットワークといったインフラの細かい知識がなくても動かせるという点が非常に重要です」
- 「Herokuの偉大だった点は、SSL証明書、データベース、メールサーバーなどがアドオン一つで完結し、個別の契約が不要だったことです」
- 「Rails自体も『All-in-One』で機能が揃っているのが魅力ですが、インフラ側も環境変数やデプロイ周りを自動でよしなにやってくれる手軽さが求められます」
代替サービスを選定するにあたり、まずは「なぜHerokuが使いやすかったのか」という要件の洗い出しが行われました。
特にインフラ未経験者の研修においては、インフラ構築の学習コストを下げることが重要です。HerokuはWebサーバーだけでなく、データベースやメール配信（SendGrid等）、SSL化、スケジューラー、モニタリングといった周辺機能がエコシステム内で完結しており、個別に外部サービスを契約・設定する必要がない点が最大のメリットでした。
移行先を検討する上でも、この「インフラ知識がなくてもアプリを公開できる手軽さ」と「周辺機能の統合」が重要な選定基準となります。
有力な移行先候補とAWS/Google Cloudの再評価
- 「Fly.io、Railway、Renderなどが候補に挙がりますが、AWS App RunnerやGoogle Cloud Runも初心者向けに使いやすくなっています」
- 「AWSやGoogle Cloudは設定が難しい印象がありますが、サービスが突然終了するリスクが低く、実務で使われている安心感は大きいです」
- 「外部サービスをあれこれ組み合わせる手間を考えると、結局AWSやGoogle Cloudのような大手クラウドでまとめてしまった方が管理しやすい側面もあります」
具体的な移行先として、Fly.io、Railway、RenderといったPaaS（Platform as a Service）の名前が挙がりました。一方で、AWSのApp RunnerやGoogle CloudのCloud Runといったコンテナベースのサービスも、以前に比べて格段に使いやすくなっています。
PaaS系は手軽ですが、サービス継続性への不安や、独自の制約に縛られるリスクもあります。その点、AWSやGoogle Cloudであれば、業界標準として広く使われているため学習が無駄にならず、サービス終了のリスクも極めて低いです。多少の学習コストを払ってでも、最初から大手クラウドベンダーのマネージドサービスを利用する方が、長期的にはメリットが大きいのではないかという意見も出ました。
データベースのコスト問題とレイテンシ
- 「コンピュートリソースは安くても、結局データベースを契約すると高額になるというのは、どのサービスでも共通の悩みです」
- 「PlanetScaleやSupabase、Neonなどの新しいDBサービスもありますが、東京リージョンがないとレイテンシの問題で本番利用は厳しい場合があります」
- 「VercelはNext.jsとの相性は最高ですが、DB接続で外部サービスを経由すると遅延が発生したり、構成が複雑になったりする懸念があります」
アプリの実行環境だけでなく、データベース（DB）をどこに置くかも大きな課題です。サーバーレスDBとしてPlanetScale、Neon、Supabaseなどが検討されましたが、無料枠の制限や、東京リージョンが利用できないことによる通信遅延（レイテンシ）の問題が懸念されます。
特にVercelを利用する場合、DBを外部に置く構成になりますが、物理的な距離による遅延はユーザー体験に直結します。また、RDS（Amazon Relational Database Service）などのマネージドDBは信頼性が高いもののコストがかさむため、研修や小規模案件での利用には工夫が必要です。
認証基盤と次世代スタック（Cloudflare）への期待
- 「Auth0やFirebase Authは便利ですが、メール文面のカスタマイズ制限やDBとのデータ同期の手間を考えると、自前で実装した方が楽な場合もあります」
- 「新しいスタックとしてCloudflareに注目しており、コストの安さとパフォーマンスの高さから、検証を進めている最中です」
- 「Cloudflare WorkersやPagesに加え、コンテナが動くようになれば、Railsアプリも含めて移行できる可能性があり、非常に期待しています」
認証機能については、Auth0やFirebase AuthenticationなどのIDaaS（Identity as a Service）を利用するか、自前で実装するかの議論になりました。外部サービスは導入が楽な反面、日本語化やメールカスタマイズの制限、ユーザーデータの同期といった運用上の課題も発生します。最近では「Better Auth」のようなライブラリを活用し、アプリ内で完結させる流れも再評価されています。
また、次世代の有力候補としてCloudflareが挙がりました。圧倒的なコストパフォーマンスとエッジでの実行能力に加え、コンテナサポートが進めばRailsアプリもホストできる可能性があります。Next.jsなどのモダンなフロントエンド技術との親和性も含め、Cloudflareを中心としたスタックが今後の本命になるかもしれません。
まとめ
今回のテックトークでは、Herokuからの移行をきっかけに、現代のWeb開発におけるインフラ選定について議論しました。
Herokuの現状: メンテナンスモードに近い状態で、新規採用は難しい。
移行先の要件: インフラ知識不要で、DBやメール等の周辺機能も一括管理できる手軽さが理想。
候補サービス: Fly.io、Railway、Render等のPaaSに加え、安定性の高いAWS App RunnerやGoogle Cloud Runも有力。
DBの課題: サーバーレスDBは魅力的だが、東京リージョンの有無（レイテンシ）とコストがネック。
認証: IDaaSは便利だが制約も多い。自前実装やライブラリ活用（Better Auth等）も選択肢。
今後の展望: コストと性能のバランスからCloudflare（Workers/Pages/コンテナ）への移行を有力視し、検証を進めていく。
