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

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

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

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

![無題のプレゼンテーション (10).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/d7b79c3b-d5a8-0b39-a55e-41be62a916d6.png)


## 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」に任意の名前を入れる。<br>  グローバルで一意になるように、IDには数字が付与される。
4. [Create]を選択する。

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

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



## Procedure of a manual build and deployment. 

### Enable APIs
APIを有効化します。

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

### Prepare the code files

1. Cloud SDKを起動する。
1. プロジェクトを設定する。

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

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

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

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

    ```HTML:./html/index.html
    OK
    ```

1. 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;
            }
        }
    }
    ```

1. 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
    ```

1. イメージの確認。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にデプロイします。<br>今回はフルマネージドのサービスを東京リージョンにデプロイします。<br>また、外部からの未認証アクセスを許容します。

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

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

    ```
    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
    ```

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

    ```
    $ 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で確認できます。<br>デフォルトでは、自動スケーリングは最大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」を選択する。
1. 虫眼鏡欄に、「Cloud Source Repositories API」を入力する。
1. 結果から、「Cloud Source Repositories API」を選択する。
1. [ENABLE]を選択する。


### Create a repository
Cloud Source Repository上にリポジトリを作成します。
1. Cloud SDKを起動する。
1. プロジェクトを設定する。


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


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

    ```
    $ gcloud source repos create nginx-test
    ```

    ```
    Created [nginx-test].
    ```

1. クローン
「空のリポジトリやで」的な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(上で作ったリポジトリ)|

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

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

1. [SAVE]を選択する。

### Register a code and build configuration file
リポジトリにコードと、ビルド構成ファイルを登録します。

1. Cloud SDKを起動する。
1. プロジェクトを設定する。

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

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

    ```
    $ cd ./nginx-test
    ```

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

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

    ```:html/index.html
    OK this revision has deployed by Cloud Build.
    ```


1. .gcloudignore を作成する。

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

1. ファイルの追加

    ```
    $ git add .
    ```

1. コミット

    ```
    $ 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"
    ```


1. プッシュ

    ```Shell:
    $ git push origin master
    ```


### Confirm build result
ビルド結果を確認します。

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

    ```Shell:
    $ 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
    ```

1. 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」を選択する。
1. 虫眼鏡欄に、「Cloud Run API」を入力する。
1. 結果から、「Cloud Run API」を選択する。
1. [ENABLE]を選択する。
1. 同様に「Cloud Build API」も有効化する。
1. 同様に「Cloud Source Repositories API」も有効化する。
1. 同様に「Google Container Registry API」も有効化する。
1. 同様に「Cloud Resource Manager API」も有効化する。


### Add roles for Service Account
Cloud Buildのサービスアカウントに役割を追加します。

1. ハンバーガーから、「Cloud Build - Settings」を選択する。
1. Service account permissionsの一覧より、「Cloud Run Admins」のStatusを[ENABLE]にする。
1. 「GRANT ACCESS TO ALL SERVICE ACCOUNTS 」を選択する。

1. Cloud SDKを起動する。
1. プロジェクトを設定する。

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

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

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

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

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

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



### Create a repository
Cloud Source Repository上にリポジトリを作成します。
1. Cloud SDKを起動する。
1. プロジェクトを設定する。


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


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

    ```
    $ gcloud source repos create nginx-test
    ```

    ```
    Created [nginx-test].
    ```

1. クローン
「空のリポジトリやで」的な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」を選択する。
1. [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|←|ビルド構成ファイルを指定|

1. [CREATE]を選択する。


### Register a code and build configuration file
リポジトリにコードと、ビルド構成ファイルを登録します。

1. Cloud SDKを起動する。
1. プロジェクトを設定する。

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

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

    ```
    $ cd ./nginx-test
    ```

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

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

    ```:html/index.html
    OK this revision has deployed by Cloud Build.
    ```

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

    ```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)|
    ※括弧のやつは、省略値。


1. .gcloudignore を作成する。

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

1. ファイルの追加

    ```
    $ git add .
    ```

1. コミット

    ```
    $ 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"
    ```


1. プッシュ

    ```Shell:
    $ git push origin master
    ```


### Confirm build result
ビルド結果を確認します。

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

    ```Shell:
    $ 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
    ```

1. 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」を選択する。
1. 表示されたサービス一覧より、「nginx-test」を選択する。
1. 「REVISIONS」タブを選択する。
1. 「Revision」ごとの振り分けを「Traffic Percentage」で指定する。<br>今回は最初のリビジョンと2番目のリビジョンに50%:50%で振り分けます。

1. 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](https://cloud.google.com/free/docs/gcp-free-tier?hl=ja)の無料枠で安心して遊べるようにするための
通知ポリシーを考えてみます。

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

    ![無題のプレゼンテーション (5).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/f0473482-4df5-f2b7-e045-089011cb2475.png)

1. 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|


1. 通知ポリシーの条件<br>[通知ポリシーの作り方](https://qiita.com/mitonattou919/items/a36612cad1840efa1362)

    |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<br>80 concurrency|max1instances<br>80 concurrency|max2instances<br>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|


1. 測定条件
  Apache Benchの条件は以下のとおりです。<br>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|
    

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


    ![無題のプレゼンテーション (7).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/211716d2-7df9-f223-0cd4-21b0a732fffc.png)


    |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|


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

    ![無題のプレゼンテーション (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/0dc72b24-5304-3015-b5db-7a45cb569b33.png)


    |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|

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

    ![Billable Instance Time.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/76600eb6-beec-98fc-4232-d5fd83f76630.png)

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

    ![Container CPU Allocation.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/72787956-447b-72da-7e3b-41bbdf32c0d6.png)

1. メモリ<br>傾向はCPUと同じです。

    ![Container Memory Allocation.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/5266dce7-b07a-bc73-0883-149f6905ea90.png)



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

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

    ![無題のプレゼンテーション (8).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/cc36d584-cdde-259c-9956-4e25bf7bfe82.png)

    |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|



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

    ![無題のプレゼンテーション (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525959/4173bf70-1345-f713-53eb-bb79db526d70.png)


    |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
- [リソースモデル(公式ドキュメント)](https://cloud.google.com/run/docs/resource-model?hl=ja)
- [同時実行(公式ドキュメント)](https://cloud.google.com/run/docs/about-concurrency?hl=ja)
- [自動スケーリング(公式ドキュメント)](https://cloud.google.com/run/docs/about-instance-autoscaling?hl=ja)
- [料金(公式ドキュメント)](https://cloud.google.com/run/pricing?hl=ja)
- [Continuous deployment from git using Cloud Build(公式ドキュメント)](https://cloud.google.com/run/docs/continuous-deployment-with-cloud-build?hl=ja)