Cloud Runを利用検討するときのまとめ |

こんにちは、mabuiです。
新規サービスを開発する時に使用する、コンテナ管理サービスとして何か良いものがないか調べてみたところ、GCPのCloud Runが良さそうだったため、2019年12月現在、利用検討したときのまとめを箇条書きでのっけていきます！

全体まとめ

箇条書きを載せる前に、検討時のまとめを書きます。

利用時特に検討した方がいいのは、コンテナスペックが小さめな点、Cloud SQLのコネクション数。
個人開発、新規開発のスモールスタート用途で十分活躍できそう。
DB、CI/CD等、周辺サービスのGCPロックインが多い印象。

使用の検討に必要な情報のまとめ（箇条書き）

k8sのマネージドサービスKnativeから作られたサービス。
knativeはコンテナイメージをデプロイの単位として認識する。
コンテナで動く、lambdaのようなイベント起動のサーバレス。
App Engineのコンテナ版って感じ。App Engineはアプリのサーバレス。
サーバーのプロビジョニング、構成、管理など、すべてのインフラストラクチャ管理が不要。つまりクラスタの管理が不要。
ステートレスコンテナを好きなクラスタ(主にGKE)にデプロイ。
課金は使用したリソース分で、無駄な出費がない。
毎月の無料割り当て分が結構ある。ネットワーキングの料金が膨らみやすいようなので、静的コンテンツはGCSやFirebase Hosting等から配信してレスポンスサイズを抑えた方がいい。
この課金モデルだとトラフィックないとほぼ課金発生しないので、個人開発、受託の新規開発両方の用途に使用できそう。
東京リージョンも利用可能。
レスポンスタイムアウトはデフォルト5分(最大15分)。
コンテナスペック
- 1 virtual CPUで変更不可。
- メモリデフォルト256MB、変更可128MB〜2G。
- ファイルシステム読み書き可能、コンテナ上のメモリを使用、永続性なし。
アプリケーションはステートレス推奨。コンテナインスタンスが増減するため。
- セッション情報はDBやKVSに保存。
HTTPSアクセス
- デプロイすると、FQDNとSSL証明書が割り当てられ、httpsでアクセス可能。
デフォルトでIAMによる認証が有効なので、一般公開する場合はデプロイ時に—allow-unauthenticatedオプションで認証なしアクセスを許可する。
メッセージングサービスとの連携、非同期処理、定期実行可能。
Concurrency(コンテナ受信リクエストの同時実行数)を設定できる。デフォルト値80。
サービスの最大同接数はConcurrency * インスタンス数。
Cloud SQLに接続できる。
- Cloud SQLの最大同接(コネクション)数に注意。デフォルトの数はマシンタイプで違って、db-f1-microは250、db-g1-smallは1000、その他は4000。
- Concurrencyが設定できる(=DBコネクションを節約できる)ため、Cloud SQLの最大同接数 * Concurrencyが、DBが捌ける同時リクエスト数。
インスタンスのコールドスタートを防ぐには、Cloud Schedulerを利用して、定期的にリクエストを投げる。
カスタムドメイン
- デフォルトはrun.appのサブドメインが割り当てられるが、独自ドメインの使用も可能。
CI/CD
- ソースコード管理にCloud Source Repository、ビルドとデプロイにCloud Build、コンテナイメージ管理にGoogle Container Registryを利用してCI/CDワークフローをサーバレスに構築可能。

参考資料

[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレスアプリケーション開発 ~
料金 | Cloud Run | Google Cloud
Cloud Run が GA になったから改めて色々見てみる - google-cloud-jp - Medium