GCP - Cloud Run で自動ビルド＆デプロイと、パフォーマンス計測

気がついたら、Cloud Run という新しいサーバーレスのサービスが追加されていました。
nginxで静的コンテンツをホスティングして、色々と動かしてみたいと思います。

*(2020/10/5追記) いつの間にか、自動デプロイの手順が少し簡素化されていましたので、追記しました。

Summary

• とりあえず、構築する。
• Gitへのプッシュをトリガーにしてビルド＆デプロイを自動化する。
• トラフィック分割
• 監視
• パフォーマンス計測

ToDo

• 前準備と後始末

  • プロジェクトを作る。
  • プロジェクトを削除する。

• 手動ビルドとデプロイ

  • API有効化(Cloud RunとBuildとRepositoryなど)
  • Dockerfile等の準備
  • コンテナイメージのビルド
  • デプロイ
  • 動作確認

• 自動ビルド＆デプロイ

  • 権限設定
  • リポジトリの作成
  • トリガーの作成
  • コードおよびビルド構成ファイルのプッシュ
  • デプロイ結果の確認

• いろいろ確認

  • トラフィック分割
  • 監視
  • パフォーマンス測定
  • Worpressでパフォーマンス測定(参考)

Prepairing and cleanup

Create a new project

あとですぐに消せるように、一時的なプロジェクトを作成します。

1. 画面の上にある [Select a project] を選択する。
2. [NEW PROJECT] を選択する。
3. 「Project Name」に任意の名前を入れる。
   グローバルで一意になるように、IDには数字が付与される。
4. [Create]を選択する。

Delete the project

無駄に課金されることを避けるため、プロジェクトを削除します。

1. ハンバーガーから、「Home」を選択する。
2. [Go to project settings]を選択する。
3. [SHUT DOWN]を選択する。
   30日間は消えずに残っている。

Procedure of a manual build and deployment.

Enable APIs

APIを有効化します。

1. ハンバーガーから、「API & Services - Library」を選択する。
2. 虫眼鏡欄に、「Cloud Run API」を入力する。
3. 結果から、「Cloud Run API」を選択する。
4. [ENABLE]を選択する。
5. 同様に「Cloud Build API」も有効化する。
6. 同様に「Google Container Registry API」も有効化する。

Prepare the code files

1. Cloud SDKを起動する。

2. プロジェクトを設定する。

   $ gcloud config set project [上で作ったプロジェクトのID]
   

3. 任意のディレクトリを作成し、そこに移動する。

   $ mkdir -p nginx-test/html
   $ mkdir -p nginx-test/nginx
   $ cd nginx-test
   

4. htmlファイルを作成する。

   ./html/index.html

   OK
   

5. default.conf を作成する。待ち受ける通信ポート番号をCloud Run側と合わせます。

   ./nginx/default.conf

   server {
       listen       8080;
       server_name  localhost;
   
       location / {
           root   /usr/share/nginx/html;
           index  index.html;
           if ($request_method != GET ) {
               return 403;
           }
       }
   }
   

6. Dockerfile を作成します。今回はDockerの公式イメージを使います。

   Dockerfile

   FROM nginx
   COPY html /usr/share/nginx/html
   COPY nginx/default.conf /etc/nginx/conf.d/default.conf
   

Build container image

1. Container Registry へ登録します。SUCCESS と出ればOK。

   $ gcloud builds submit --tag gcr.io/[上で作ったプロジェクトのID]/nginx-test:v1
   

2. イメージの確認。v1タグがついたイメージが出来上がっていればOK。

   $ gcloud container images list-tags gcr.io/[上で作ったプロジェクトのID]/nginx-test
   

   結果例

   DIGEST        TAGS    TIMESTAMP
   xxxxxxxxxxxx  v1      yyyy-mm-ddTHH:MM:SS
   

Deploy to Cloud Run

1. Cloud Runにデプロイします。
   今回はフルマネージドのサービスを東京リージョンにデプロイします。
   また、外部からの未認証アクセスを許容します。

   $ gcloud run deploy nginx-test \
     --image gcr.io/[上で作ったプロジェクトのID]/nginx-test:v1 \
     --platform managed \
     --region=asia-northeast1 \
     --allow-unauthenticated
   

2. デプロイ結果を確認するために、サービス一覧を出します。

   gcloud run services list --platform managed --region=asia-northeast1
   

   結果例

       SERVICE     REGION           URL                                         LAST DEPLOYED BY         LAST DEPLOYED AT
   ✔  nginx-test  asia-northeast1  https://nginx-test-xxxxxxxx-xx.x.run.app  YOURMAILADDRESS@YOURDOMAIN  yyyy-mm-ddTHH:MM:SS.000Z
   

3. 同じくリビジョン一覧を確認します。

   $ gcloud run revisions list --platform managed --region=asia-northeast1
   

   結果例

      REVISION              ACTIVE  SERVICE     DEPLOYED                 DEPLOYED BY
   

✔ nginx-test-99999-xxx yes nginx-test yyyy-mm-dd HH:MM:SS UTC YOURMAILADDRESS@YOURDOMAIN
```

1. リビジョンの設定値はdescribeで確認できます。
   デフォルトでは、自動スケーリングは最大1,000。同時実行数は80。vCPUは1つ。メモリは256MiBとなるようです。

   $ gcloud run revisions describe [リビジョン] --platform managed --region=asia-northeast1
   

   結果例

   ✔ Revision nginx-test-00001-baw in region asia-northeast1
   
   Image:         gcr.io/[プロジェクトID]/nginx-test:v1
   Port:          8080
   Memory:        256Mi
   CPU:           1000m
   Concurrency:   80
   Max Instances: 1000
   Timeout:       300s
   

Confirmation

1. 先程のサービス一覧で表示されたURLにアクセスします。OKがでればOKです。

   curl https://[表示されたURL]/
   

   結果例

   OK
   

Procedure of a automatic build and deployment(new).

新しい手順。

Enable APIs

APIを有効化します。

1. ハンバーガーから、「API & Services - Library」を選択する。
2. 虫眼鏡欄に、「Cloud Source Repositories API」を入力する。
3. 結果から、「Cloud Source Repositories API」を選択する。
4. [ENABLE]を選択する。

Create a repository

Cloud Source Repository上にリポジトリを作成します。

1. Cloud SDKを起動する。

2. プロジェクトを設定する。

   $ gcloud config set project [上で作ったプロジェクトのID]

3. リポジトリの作成
   「課金されるで」的なWARNINGは無視でOK。

   $ gcloud source repos create nginx-test
   

   Created [nginx-test].
   

4. クローン
   「空のリポジトリやで」的なWARNINGは無視でOK。

   $ gcloud source repos clone nginx-test
   

   Cloning into '/home/ユーザ名/nginx-test-repository'...
   warning: You appear to have cloned an empty repository.
   Project [上で作ったプロジェクトのID] repository [nginx-test] was cloned to [/xxx/xxx/nginx-test].
   

Setting up Continuous deployment

1. ハンバーガーから、「Cloud Run - [上で作ったサービス]」を選択する。

2. 画面の上の方にある「SET UP CONTINUOUS DEPLOYMENT」を選択する。

3. 「Source Repository」で、以下のとおり設定する。

   項目	設定値
   Repository Provider	Cloud Source Repositoies
   Repository	nginx-test(上で作ったリポジトリ)

4. 「Build COnfigration」で、以下のとおり設定する。

   項目	設定値
   Branch	^master$
   Build Type	Dockerfile

5. [SAVE]を選択する。

Register a code and build configuration file

リポジトリにコードと、ビルド構成ファイルを登録します。

1. Cloud SDKを起動する。

2. プロジェクトを設定する。

   $ gcloud config set project [上で作ったプロジェクトのID]
   

3. リポジトリをクローンしたディレクトリへ移動

   $ cd ./nginx-test
   

4. 先ほど作成したDockerfileとhtml/index.htmlとnginx/default.confをコピーする。

5. index.html を編集します。

   html/index.html

   OK this revision has deployed by Cloud Build.
   

6. .gcloudignore を作成する。

   .gcloudignore
   .git
   .gitignore
   node_modules
   *.exe
   *.exe~
   *.dll
   *.so
   *.dylib
   *.test
   *.out
   

7. ファイルの追加

   $ git add .
   

8. コミット

   $ git commit -m "This is a first time of deploy container image."
   

   「*** Please tell me who you are.(つーかお前誰やねん)」が出たら、

   git config --local user.email "your_name@your_domain.com"
   git config --local user.name "your_name"
   

9. プッシュ

   $ git push origin master
   

Confirm build result

ビルド結果を確認します。

1. ビルド結果の確認
   STATUSがSUCCESSであれば、デプロイ成功です。

   $ gcloud builds list
   

   ID                                    CREATE_TIME                DURATION  SOURCE                    IMAGES  STATUS
   xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  yyyy-mm-ddTHH:MM:SS+00:00  xxS       nginx-test@master  -       SUCCESS
   

2. Cloud Runのリビジョン一覧を確認します。新しいリビジョンがACTIVEになっていればOKです。

   $ gcloud run revisions list --platform managed --region=asia-northeast1
   

   結果例

      REVISION              ACTIVE  SERVICE     DEPLOYED                 DEPLOYED BY
   

✔ nginx-test-99999-xxx yes nginx-test yyyy-mm-dd HH:MM:SS UTC YOURMAILADDRESS@YOURDOMAIN
```

1. Cloud Runの動作確認
   以下のように結果がかえってくればOKです。

   $ curl https://[Cloud RUnのサービスのURL]/
   

   結果例

   OK this revision has deployed by Cloud Build.
   

Procedure of a automatic build and deployment.

従来の手順。新しい手順でやった場合、こちらは実施不要。

Enable APIs

APIを有効化します。

1. ハンバーガーから、「API & Services - Library」を選択する。
2. 虫眼鏡欄に、「Cloud Run API」を入力する。
3. 結果から、「Cloud Run API」を選択する。
4. [ENABLE]を選択する。
5. 同様に「Cloud Build API」も有効化する。
6. 同様に「Cloud Source Repositories API」も有効化する。
7. 同様に「Google Container Registry API」も有効化する。
8. 同様に「Cloud Resource Manager API」も有効化する。

Add roles for Service Account

Cloud Buildのサービスアカウントに役割を追加します。

1. ハンバーガーから、「Cloud Build - Settings」を選択する。

2. Service account permissionsの一覧より、「Cloud Run Admins」のStatusを[ENABLE]にする。

3. 「GRANT ACCESS TO ALL SERVICE ACCOUNTS 」を選択する。

4. Cloud SDKを起動する。

5. プロジェクトを設定する。

   $ gcloud config set project [上で作ったプロジェクトのID]
   

6. プロジェクトを情報を確認する。

   $ gcloud projects describe [上で作ったプロジェクトのID]
   

   createTime: 'yyyy-mm-ddTHH:MM:SS.000Z'
   lifecycleState: ACTIVE
   name: プロジェクトの名前
   projectId: プロジェクトのID
   projectNumber: 'プロジェクトの番号'
   

7. Cloud BuildのサービスアカウントをCloud Functionsのランタイムサービスアカウントとして機能させる。
   ([プロジェクトのID]と[プロジェクトの番号]を置き換えて実行する。)

   gcloud iam service-accounts add-iam-policy-binding \
     [プロジェクトの番号][e-mail] \
     --member="serviceAccount:[プロジェクトの番号]@cloudbuild.gserviceaccount.com" \
     --role="roles/iam.serviceAccountUser"
   

Create a repository

Cloud Source Repository上にリポジトリを作成します。

1. Cloud SDKを起動する。

2. プロジェクトを設定する。

   $ gcloud config set project [上で作ったプロジェクトのID]

3. リポジトリの作成
   「課金されるで」的なWARNINGは無視でOK。

   $ gcloud source repos create nginx-test
   

   Created [nginx-test].
   

4. クローン
   「空のリポジトリやで」的なWARNINGは無視でOK。

   $ gcloud source repos clone nginx-test
   

   Cloning into '/home/ユーザ名/nginx-test-repository'...
   warning: You appear to have cloned an empty repository.
   Project [上で作ったプロジェクトのID] repository [nginx-test] was cloned to [/xxx/xxx/nginx-test].
   

Create a build trigger

1. ハンバーガーから「Cloud Build - Triggers」を選択する。

2. [CREATE TRIGGER]を選択する。

   Item	Defult Value	Value	Comment
   Name	-	nginx-test-trigger	任意のトリガー名(プロジェクト内で一意)
   Description	-	←	説明文
   Event	Push to a branch	←	トリガーとなるイベント(今回はプッシュを対象とする)
   Repository	-	nginx-test	今回は上で作ったリポジトリを選択
   Branch	-	^master$	今回はmasterを対象とする
   Invert Regex	No	←
   File Type	Cloud Build configuration fle(yaml or json)	←
   Cloud Build configuration file location	/cloudbuild.yaml	←	ビルド構成ファイルを指定

3. [CREATE]を選択する。

Register a code and build configuration file

リポジトリにコードと、ビルド構成ファイルを登録します。

1. Cloud SDKを起動する。

2. プロジェクトを設定する。

   $ gcloud config set project [上で作ったプロジェクトのID]
   

3. リポジトリをクローンしたディレクトリへ移動

   $ cd ./nginx-test
   

4. 先ほど作成したDockerfileとhtml/index.htmlとnginx/default.confをコピーする。

5. index.html を編集します。

   html/index.html

   OK this revision has deployed by Cloud Build.
   

6. ビルド構成ファイルを cloudbuild.yaml という名前で作成。

   steps:
       - name: 'gcr.io/cloud-builders/docker'
         args: ['build', '-t', 'gcr.io/[上で作ったプロジェクトのID]/nginx-test:v2', '.']
       - name: 'gcr.io/cloud-builders/docker'
         args: ['push', 'gcr.io/[上で作ったプロジェクトのID]/nginx-test:v2']
       - name: 'gcr.io/cloud-builders/gcloud'
         args:
         - 'run'
         - 'deploy'
         - 'nginx-test'
         - '--image'
         - 'gcr.io/[上で作ったプロジェクトのID]/nginx-test:v2'
         - '--region'
         - 'asia-northeast1'
         - '--platform'
         - 'managed'
         - '--allow-unauthenticated'
   

   Item	Option	Value
   Service name	-	nginx-test
   Image	-image	gcr.io/[上で作ったプロジェクトのID]/nginx-test:v2
   Platform	--platform	managed
   Region	--region	asia-northeast1
   Unauthenticated access	--allow-unauthenticated	allow
   vCPU	--cpu	(1000m)
   Memory	--memory	(256Mi)
   Max Instances	--max-instances	(1000)
   Concurrency per instance	--concurrency	(80)
   ※括弧のやつは、省略値。

7. .gcloudignore を作成する。

   .gcloudignore
   .git
   .gitignore
   node_modules
   *.exe
   *.exe~
   *.dll
   *.so
   *.dylib
   *.test
   *.out
   

8. ファイルの追加

   $ git add .
   

9. コミット

   $ git commit -m "This is a first time of deploy container image."
   

   「*** Please tell me who you are.(つーかお前誰やねん)」が出たら、

   git config --local user.email "your_name@your_domain.com"
   git config --local user.name "your_name"
   

10. プッシュ

    $ git push origin master
    

Confirm build result

ビルド結果を確認します。

1. ビルド結果の確認
   STATUSがSUCCESSであれば、デプロイ成功です。

   $ gcloud builds list
   

   ID                                    CREATE_TIME                DURATION  SOURCE                    IMAGES  STATUS
   xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  yyyy-mm-ddTHH:MM:SS+00:00  xxS       nginx-test@master  -       SUCCESS
   

2. Cloud Runのリビジョン一覧を確認します。新しいリビジョンがACTIVEになっていればOKです。

   $ gcloud run revisions list --platform managed --region=asia-northeast1
   

   結果例

      REVISION              ACTIVE  SERVICE     DEPLOYED                 DEPLOYED BY
   

✔ nginx-test-99999-xxx yes nginx-test yyyy-mm-dd HH:MM:SS UTC YOURMAILADDRESS@YOURDOMAIN
```

1. Cloud Runの動作確認
   以下のように結果がかえってくればOKです。

   $ curl https://[Cloud RUnのサービスのURL]/
   

   結果例

   OK this revision has deployed by Cloud Build.
   

Various testing

Traffic management

1. ハンバーガーより、「Cloud Run」を選択する。

2. 表示されたサービス一覧より、「nginx-test」を選択する。

3. 「REVISIONS」タブを選択する。

4. 「Revision」ごとの振り分けを「Traffic Percentage」で指定する。
   今回は最初のリビジョンと2番目のリビジョンに50%:50%で振り分けます。

5. Cloud Runの動作確認
   以下のように概ね50%:50%で振り分けられたことがわかると思います。

   $ while true;do curl https://[Cloud RUnのサービスのURL]/;sleep 1;done
   

   結果例

   OK
   OK this revision has deployed by Cloud Build.
   OK
   OK
   OK this revision has deployed by Cloud Build.
   OK
   OK
   

Monitoring

Stackdriver Monitoringで、アラートが上がるようにします。
今回は、なるべくAlways Freeの無料枠で安心して遊べるようにするための
通知ポリシーを考えてみます。

1. Cloud Runにおける料金
   
   Cloud Runの料金は、このようになっています。
   
   CPUとメモリがわかりにくいですが、インスタンスに割り当てたvCPUが1(1000ms)、
   メモリが256MiBの場合、実行時間が1秒だと1vCPU秒/256MiB秒。500msであれば、
   0.5vCPU秒/128MiB秒。3秒であれば、3vCPU秒/768MiB秒ということですね。
   
   また、同時に複数リクエストを実行した際に、処理がかぶっていた場合には、最初の
   リクエストを受け付けたタイミングから、最後のリクエストが完了したタイミングまで
   の時間が請求対象となるようです。
   
   さらに上記リンクには明記されていませんが、インスタンスが複数ある場合は、インスタンス
   ごとの時間が積算されるものと思われます(当たり前といえば、当たり前ですが)。

   

2. Cloud Runにおける無料枠
   Cloud Runには、月ごとにリセットされる無料枠があります(日、時間、分は筆者にて計算)。
   今回はこれを基準にして、通知ポリシーを考えてみます。

   	per Month	per Day	per Hour	per Minute
   Requests	2,000,000	64,516	1,075	17.92
   vCPU	180,000 vCPU sec	5,806 vCPU sec	97 vCPU sec	1.61 vCPU sec
   Memory	360,000 GiB sec	11,613 GiB sec	194 GiB sec	3.23 GiB sec
   Network band(MiB)	1,024 MiB	33 MiB	1 MiB	0.01 MiB

3. 通知ポリシーの条件
   通知ポリシーの作り方

   |Resorce Type|Metric|Advanced Aggregation|Configuration
   |:-:|:-:|:-:|:-:|:-:|
   |Cloud Run Revision|Request Count|sum/1minute|Any time series violates/is above/18/1min|
   |Cloud Run Revision|Billable Instance Time|sum/1minute|Any time series violates/is above/1610ms/1min|
   |Cloud Run Revision|Container CPU Allocation|sum/1minute|Any time series violates/is above/1610ms/1min|
   |Cloud Run Revision|Container CPU Allocation|sum/1minute|Any time series violates/is above/3463683303B.s/1min|

Performance measurement

1. 環境条件
   請求時間に影響する部分が大きい、インスタンス数を変えて、測定してみます。

   	max1000instances 80 concurrency	max1instances 80 concurrency	max2instances 80 concurrency
   vCPU per instance	1	1	1
   Memory per instance	256MiB	256MiB	256MiB
   Concurrency per instance	80	80	80
   Autoscalling (Min instances)	0	0	0
   Autoscalling (Max instances)	1000	1	2

2. 測定条件
   Apache Benchの条件は以下のとおりです。
   1多重あたり100リクエストを投げる感じでやってみます。

   同時実行数	リクエスト数
   1	100
   2	200
   3	300
   5	500
   10	1,000
   20	2,000
   30	3,000
   40	4,000
   50	5,000
   total	16,100

3. リクエストあたりレスポンスタイム(ms)
   ちょっと予想と反して、インスタンス数に関わらず、ほぼ同じタイミングでレスポンス悪化が始まりました。
   なお、AB搭載マシンは、n1-standardのDebian9を東京リージョンに配置してまして、
   割と余裕がある状態(CPU使用率10%くらい)でしたので、クライアント側に原因はなさそうです。

   

   Concurrency	1000inst/80con	1inst/80con	2inst/80con
   1	44.949	47.628	45.382
   2	44.612	44.388	44.011
   3	44.621	44.351	44.795
   5	44.561	44.730	43.951
   10	45.064	45.006	44.963
   20	44.875	45.150	45.831
   30	58.851	46.252	45.873
   40	49.047	47.082	48.567
   50	55.483	53.768	53.198

4. 秒間あたりの処理リクエスト
   同様です。ひとまず、今回の使い方では40多重くらいまでは、健全にサービス提供できそうです。

   

   Concurrency	1000inst/80con	1inst/80con	2inst/80con
   1	22.25	21.00	22.04
   2	44.83	45.06	45.44
   3	67.23	67.64	66.97
   5	112.21	111.78	113.76
   10	221.91	222.19	222.40
   20	445.68	433.37	436.39
   30	509.76	648.62	653.98
   40	815.55	849.58	823.60
   50	901.18	928.22	939.89

5. Cloud Run サービスの請求対象のインスタンス時間
   左から、最大1000インスタンス⇒1インスタンス⇒2インスタンスです。

   

6. CPU割り当て
   並びは上と同じです。やってることは同じなのに、インスタンス数によって増減するということは、何かしらのオーバーヘッドがあるということなんでしょうか。
   別途、確認してみたいですね。

   

7. メモリ
   傾向はCPUと同じです。

   

(FYI)Wordpress

ちょっと意外な結果となりましたので、Wordpressを入れて、DBアクセス(Cloud SQL)ありのパターンも見てみます。
ついでにGAEでも計測してみます。

1. リクエストあたりレスポンスタイム(ms)
   以下のGAEのような結果になると思ってましたが、Cloud Runだとインスタンス数に依存してないですね。

   

   Concurrency	Run(1000inst/80con)	Run(1inst/80con)	GAE(auto-inst/10con)	GAE(2inst/80con)
   1	91.565	95.494	136.453	137.882
   2	93.994	93.286	156.219	234.754
   3	86.566	95.769	210.714	224.766
   5	112.16	64.442	186.916	312.255
   10	135.246	95.019	208.332	645.477
   20	285.680	191.509	226.097	1234.163

2. 秒間あたりの処理リクエスト
   GAEはまだまだスケールしそうな感じですので、こういうのを期待していたのですが、、今後もう少し検証してみたいと思います。。

   

   Concurrency	Cloud Run (1000inst/80con)	Cloud Run (1inst/80con)	App Engine (auto-inst/10con)	App Engine (2inst/80con)
   1	10.92	10.47	7.33	7.25
   2	21.28	21.44	12.8	8.52
   3	34.66	31.33	14.24	13.35
   5	44.58	77.59	26.75	16.01
   10	73.94	105.24	48	15.49
   20	70.01	104.43	88.46	16.21

Reference

• リソースモデル(公式ドキュメント)
• 同時実行(公式ドキュメント)
• 自動スケーリング(公式ドキュメント)
• 料金(公式ドキュメント)
• Continuous deployment from git using Cloud Build(公式ドキュメント)