Cloud Runの大きな魅力は、その優れたコスト効率です。しかし、その料金体系にはいくつかの選択肢があり、特に「リクエストベースの課金」と「インスタンスベースの課金」の違いは、サービスのパフォーマンスと費用に大きく影響します。
今回は、この2つの課金モデルがどのように異なるのか、そしてあなたのCloud Runサービスにどちらが適しているのかを解説していきます。
Cloud Runの課金モデルの選択肢
Cloud Runサービスを作成または編集する際、Google Cloud ConsoleのUIやgcloudコマンドで「CPU 割り当て（CPU allocation）」に関する設定項目があります。
ここで、Cloud RunインスタンスのCPUがどのように割り当てられ、それに応じてどのように課金されるかを選択できます。この選択が、実質的に「リクエストベース」または「インスタンスベース」の課金を決定します。
- リクエストベースの課金（CPU割り当て：リクエストの処理中のみ）
- インスタンスベースの課金（CPU割り当て：常に有効）
1. リクエストベースの課金（CPU割り当て：リクエストの処理中のみ）
これがCloud Runのデフォルトであり、一般的なサーバーレスアプリケーションに適した課金モデルです。
CPU割り当て
CPUは、リクエストを処理している間のみ割り当てられます。
リクエストがないアイドル状態の期間は、CPUは非常に低い消費電力モードになるか、割り当てが停止されます（ただし、インスタンス自体がシャットダウンされるまで、メモリは割り当てられたまま課金されます）
課金対象
- CPUとメモリ: コンテナインスタンスがリクエストを処理している時間に対して課金されます。
- リクエスト数: 受信したリクエストの数に対して課金されます。
- ネットワーク下りトラフィック: コンテナから外部へのデータ送信量に対して課金されます。
特性
- アイドル時の低コスト: リクエストがない時間はCPU課金がほとんど発生しないため、アクセスが散発的、または利用頻度が低いアプリケーションに非常に適しています。
- コールドスタートの可能性: トラフィックがゼロになるとインスタンスがゼロにスケールダウンし、次のリクエストでコールドスタート（コンテナの起動時間）が発生する可能性があります。
- 無料枠の適用: Cloud Runの generous な無料枠（CPU-秒、GiB-秒、リクエスト数）がこのモデルに適用されます。
最適なユースケース
- WebサイトのバックエンドAPI
- モバイルアプリケーションのAPI
- Webhookの処理
- アクセス頻度が低い、またはバースト的なアクセスがあるサービス
2. インスタンスベースの課金（CPU割り当て：常に有効）
CPU割り当て
CPUは、**コンテナインスタンスのライフサイクル全体（起動中ずっと）**にわたって割り当てられます。
つまり、リクエストを処理していなくても、コンテナが起動していればCPUが常に利用可能です。
課金対象
- CPUとメモリ: コンテナインスタンスが起動している間ずっと、CPUとメモリの割り当てに対して課金されます。
- リクエスト数: インスタンスベースの課金を選択した場合、リクエスト数に対する料金は発生しません。
- ネットワーク下りトラフィック: コンテナから外部へのデータ送信量に対しては課金されます。
特性
- コールドスタートの回避: CPUが常に有効なため、インスタンスが起動していれば、初回リクエスト時のコールドスタートが（ほぼ）発生しません。
- 安定したパフォーマンス: CPUが常に割り当てられているため、レイテンシが予測しやすくなります。
- アイドル時のコスト: リクエストがないアイドル状態でもCPUの課金が発生し続けるため、アクセスが少ないサービスではリクエストベースよりもコストが高くなる可能性があります。
- 料金単価の優遇: Google Cloudの公式ドキュメントによると、インスタンスベースの課金では、CPU/メモリの単価がリクエストベースよりも安価に設定されています。これは、常にCPUが割り当てられる分、割引が適用されるためです。
最適なユースケース
- レイテンシが非常に重要なサービス（例: リアルタイム処理、金融取引など）
- 起動に時間のかかる複雑なアプリケーション
- 常に一定量のアクセスがあるサービス（ピーク時だけでなく、アイドル時もインスタンスを維持したい場合）
- バックグラウンド処理やイベント処理など、リクエスト外の活動をインスタンス内で継続したい場合（例: コネクションプール、インメモリキャッシュの維持）
リクエストベースとインスタンスベースの比較表
| 特徴 | リクエストベースの課金 | インスタンスベースの課金 |
| CPU割り当て | リクエスト処理中のみ | インスタンスのライフサイクル全体 |
| アイドル時のCPU課金 | ほぼなし | 発生する |
| リクエスト数課金 | 発生する | 発生しない |
| CPU/メモリ単価 | 通常料金 | 割安 |
| コールドスタート | 発生する可能性がある | ほとんど発生しない |
| 予測可能なレイテンシ | 低トラフィック時に変動する場合あり | 高い |
| 最適なトラフィックパターン | 散発的、バースト、急増 | 安定している、または常に稼働が必要 |
どちらを選ぶべきか？
- ほとんどのCloud Runサービスは、まずは「リクエストベースの課金」で始めるのが適切です。 これがCloud Runの真価である「使った分だけ支払う」というサーバーレスのメリットを最大限に享受できるモデルだからです。
- サービスをデプロイした後、Cloud Monitoringで実際のCPU使用率、メモリ使用率、リクエストパターンを監視してください。
- もし、常に多くのリクエストが一定の速度で処理されており、アイドル状態のインスタンスがほとんどないような高負荷なサービスであれば、インスタンスベースの課金に切り替えることで、トータルのコストを抑えられる可能性があります（リクエスト課金がなくなるため）。
- 逆に、アクセスがほとんどなく、コールドスタートが許容できる場合は、断然リクエストベースが有利です。
まとめ
Cloud Runの「リクエストベースの課金」と「インスタンスベースの課金」は、CPU割り当てと課金体系が異なる2つのモデルです。
- リクエストベース: アクセス頻度が変動するサービス向け。アイドル時のコストが低い。
- インスタンスベース: レイテンシが重要で常にウォームなインスタンスが必要なサービス向け。CPU/メモリ単価は割安だが、アイドル時も課金される。
あなたのCloud Runサービスの特性と予算に合わせて最適な課金モデルを選択し、サーバーレスのメリットを最大限に引き出しましょう。
コメント