メインのデプロイ先を調べてみる

## はじめに
個人アプリ開発という課題で最初の難関（個人的にそう感じている）`デプロイ`
金、違い、金、使用感（重要なことは2回言う）
少し前と違って個人開発者に優しくなくなっているような気がしています。money
よく知られているデプロイ先について執筆当時2024/7/31現在は一体どうなっているのか。サラッとまとめてみます。

英語苦手意識+GPTによろしく、ですので、違いがあったら申し訳ございません


## 3つまとめ
| サービス | プラン        | 料金（月＄） | 特徴                                               | 
| -------- | ------------- | ------------ | -------------------------------------------------- | 
| Render   | Free          | 無料         | 512MB RAM, 0.5 vCPU                                | 
|          | Starter       | 7            | 1GB RAM, 0.5 vCPU                                  | 
|          | Standard      | 25           | 2GB RAM, 1 vCPU                                    | 
|          | Pro           | 85           | 4GB RAM, 2 vCPU                                    | 
| Fly.io   | Hobby         | 5            | 256MB RAM, 1 shared CPU, 160GBアウトバウンドデータ | 
|          | Launch        | 29           | 1GB RAM, 1 shared CPU, 160GBアウトバウンドデータ   | 
|          | Scale         | 199          | 4GB RAM, 1 vCPU, 160GBアウトバウンドデータ         | 
| Heroku   | Free          | 無料         | 512MB RAM, 1 dyno                                  | 
|          | Eco           | 5            | 512MB RAM, 550 dyno hours                          | 
|          | Basic         | 7            | 512MB RAM, 1 dyno                                  | 
|          | Standard      | 25           | 1GB RAM, 1 dyno                                    | 
|          | Performanse-M | 250          | 2.5GB RAM, 1 dyno                                  | 
|          | Performance-L | 500          | 14GB RAM, 1 dyno                                   | 

#### RAMの違いによる影響
**1GB RAMの場合**
- パフォーマンス
画像のアップロードや処理、表示がスムーズになります。特に高解像度の画像を扱う場合に顕著な差が出る
- 同時ユーザー数
より多くのユーザーが同時にアクセスしても、パフォーマンスが低下しにくくなる
- キャッシュ
一時的なデータのキャッシュが増えるため、再読み込みの頻度が減少し、ユーザー体験が向上する
- バックエンド処理
画像のリサイズやフィルター適用などのバックエンド処理が速くなる


**256MB RAMの場合**
- パフォーマンス
画像のアップロードや処理が遅くなる可能性がある。大きな画像や複数の画像を同時に扱う際に、パフォーマンスの低下が顕著になる
- 同時ユーザー数
少数のユーザーが同時にアクセスする場合に限られる。多数のアクセスがあると、レスポンスが遅くなる可能性がある
- キャッシュ
キャッシュの容量が少ないため、頻繁にデータを読み直す必要があり、パフォーマンスが低下する
- バックエンド処理
画像処理に時間がかかり、ユーザーに遅延を感じさせることがある

#### 0.5 vCPU vs 1 Shared CPUの違い
- vCPUとは？
vCPU（仮想CPU）: 仮想マシンが物理CPUのリソースを共有して使用するために割り当てられる論理的なCPUです。例えば、0.5 vCPUは物理CPUの半分のリソースを使用することを意味する
- Shared CPUとは？
Shared CPU: 一つの物理CPUが複数の仮想マシンに共有される形で提供されます。例えば、1 shared CPUは特定の仮想マシンが物理CPU全体を独占せず、他の仮想マシンと共有するリソースを持つことを意味する

**?どちらを選ぶべきか？**
- **安定性を重視**: 0.5 vCPU。特に、パフォーマンスが一定であることが重要なアプリケーションや、リソースが他の仮想マシンの影響を受けにくい環境が必要な場合に適している
- **コストや柔軟性を重視**: 1 shared CPU。他の仮想マシンとリソースを共有し、コストを抑えつつも柔軟な利用が可能です。ただし、パフォーマンスの変動を許容できる場合に適している


## 無料プランの詳細
| サービス | 無料プラン内容                                    | 制限内容                                                                                                  | 
| -------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | 
| Render   | Webサービス、バックグラウンドジョブ、データベース | Webサービス: 月750時間まで<br>バックグラウンドジョブ: 月750時間まで<br>データベース: 月1000リクエストまで | 
| Fly.io   | コンピュート、ストレージ、データ転送              | コンピュート: 月160時間まで<br>ストレージ: 月10GBまで<br>データ転送: 月1GBまで                            | 
| Heroku   | Dyno、データベース                                | Dyno: 月550時間まで<br>データベース: 最大1GBのストレージ                                                  | 

https://render.com/pricing#compute


## 私の要件を満たしているか検証
プロジェクトの要件（Docker、PostgreSQL、Ruby on Rails、Google Maps API、TurboとStimulus）が執筆段階で決まっていました。
上記条件から推奨されたプランは2つ

- Fly.io Hobbyプラン
コストを抑えつつも、必要なリソースを確保できる点でおすすめ。また、スケーリングの柔軟性が高いため、プロジェクトが成長するにつれて簡単にリソースを増やすことが可能

- RenderのFreeまたはStarterプラン
特にコスト重視のプロジェクトには最適。無料プランでも基本的な開発を行うのに十分なリソースが提供される

## 調べてみて
どちらも5＄だったらRender何だろうけど…。初めてだから使用感はさっぱり。とりあえず使ってみないことには始まらない。
無料プランを試用し、その後必要に応じて有料プランに移行することが可能なRenderか・・・悩む悩む