Cloud Run インフラ プログラミング

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
 

-Cloud Run, インフラ, プログラミング
-, ,

Copyright© , 2020 All Rights Reserved Powered by STINGER.