Spinnaker を使用した Google Kubernetes Engine でのカナリア分析の自動化

このチュートリアルでは、Google Kubernetes Engine（GKE）上に Spinnaker の自動カナリア分析機能を構成する方法について説明します。

はじめに

Spinnaker は、App Engine、GKE、Compute Engine、AWS、Azure などのさまざまなコンピューティングプラットフォームでアプリのデプロイを管理するために Netflix と Google が主導するオープンソースの継続的デリバリーシステムです。Spinnaker を使用すると、カナリアデプロイを含む高度なデプロイ方法を実装できます。

カナリアデプロイでは、新しいバージョンのアプリを全面的に導入する前に、新しいバージョンを本番環境トラフィックのごく一部のみに組み込んでその動作を分析します。これにより、新しいバージョンをすべてのユーザーに公開する前にリスクを軽減できます。カナリアデプロイを使用するには、アプリの古いバージョンと新しいバージョンの動作を正確に比較する必要があります。両者の違いがわずかで、違いが現れるまで時間がかかることがあります。また、調べる指標が非常に多い場合もあります。アプリケーションのデプロイとテストの戦略でカナリアパターンの詳細をご覧ください。

このような問題を解決するため、Spinnaker には自動カナリア分析機能が用意されています。これは、モニタリングシステムから両方のバージョンの指標を読み取り、統計分析を実行して比較を自動化します。このチュートリアルでは、GKE にデプロイされた、Cloud Monitoring によってモニタリングされるアプリで自動カナリア分析を行う方法について説明します。

Spinnaker は、複雑なデプロイシナリオを実践している組織を対象とした（専用のリリースエンジニアリング部門が設けられていることも多い）、高度なアプリデプロイおよび管理プラットフォームです。このチュートリアルは、Spinnaker の使用経験がなくても実施できます。ただし、本番環境への自動カナリア分析の実装は一般に、Spinnaker の使用経験を持ち、リリースが安全かどうかを判断する方法を知っているチームが、強力なモニタリングシステムを介して行います。

このチュートリアルについて

このチュートリアルで使用するアプリは、エラー率が環境変数で構成されたシンプルな "Hello World" です。このアプリ用のビルド済みの Docker イメージが用意されています。次の図に示すように、このアプリは Prometheus 形式で指標を公開します。Prometheus は Kubernetes コミュニティでよく利用されるオープンソースのモニタリングシステムであり、Cloud Monitoring と互換性があります。

アプリのアーキテクチャ

目標

Spinnaker for Google Cloud Platform をインストールする。
カナリアデプロイなしでアプリを GKE にデプロイする。
アプリのカナリアデプロイを構成し、実行する。
自動カナリア分析を構成する。
自動カナリア分析をテストする。

料金

始める前に

Google Cloud プロジェクトを選択または作成します。

[リソースの管理] に移動
プロジェクトに対する課金を有効にします。

課金を有効にする
ワークスペースを作成します。

Monitoring ドキュメントに移動

注: このチュートリアルでは、ワークスペースの名前が、使用している Google Cloud プロジェクトの名前が同じであることを前提としています。この場合に限り、既存のワークスペースをこのチュートリアルで使用できます。

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

Cloud Shell を使用して Spinnaker for Google Cloud Platform をデプロイする

このセクションでは、チュートリアルを実施するために必要なインフラストラクチャを構成します。このチュートリアルでは、Cloud Shell からすべてのターミナルコマンドを実行します。

Spinnaker for Google Cloud Platform を使用すると、Google Cloud 向けに最適化され、本番環境に対応した構成で Spinnaker をセットアップして管理できます。Spinnaker for Google Cloud Platform は、Google Cloud で Spinnaker を実行するために必要な多くのリソース（GKE、Memorystore、Cloud Storage バケット、サービスアカウント）を設定し、Spinnaker を Cloud Build などの関連サービスと統合して、Spinnaker のインストールに使用する Cloud Shell ベースの管理環境をヘルパーや spin や hal などの一般的なツールとともに提供します。

Cloud Shell で Spinnaker for Google Cloud を開きます。これにより、Cloud Shell 環境に Spinnaker for Google Cloud Platform リポジトリのクローンが作成され、詳細なインストール手順が起動します。

Cloud Shell に移動
Spinnaker for Google Cloud Platform をインストールします。
```
PROJECT_ID=${DEVSHELL_PROJECT_ID} ~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup_properties.sh
~/cloudshell_open/spinnaker-for-gcp/scripts/install/setup.sh
```
注: このインストールコマンドは、このチュートリアルの基本セットアップ専用です。本番環境をセットアップする際は、Spinnaker for Google Cloud Platform に付属する詳細な手順で行ってください。

Monitoring-Prometheus 統合プラグインをインストールします。

export KUBE_NAMESPACE=prometheus
export GCP_PROJECT=$DEVSHELL_PROJECT_ID
export DATA_DIR=/prometheus/
export DATA_VOLUME=prometheus-storage-volume
export SIDECAR_IMAGE_TAG=0.7.0
export GCP_REGION=us-east1-c
export KUBE_CLUSTER=spinnaker-1

kubectl create namespace ${KUBE_NAMESPACE}
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/prometheus-service-account.yaml
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/prometheus-configmap.yaml
curl -sS https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-stackdriver-gke/master/gke-prometheus-deployment.yaml | \
  envsubst | \
  kubectl apply -f -

Cloud Shell を再起動して、新しい環境設定を読み込みます。

Spinnaker に接続します。

~/cloudshell_open/spinnaker-for-gcp/scripts/manage/connect_unsecured.sh

Cloud Shell でウェブでプレビュー アイコンを選択し、[ポート 8080 でプレビュー] を選択します。
注: 現時点では、この Spinnaker インスタンスは一般公開されておらず、今チュートリアルを進めている本人だけが認証なしにアクセスできます。本番環境の Spinnaker インスタンスはインフラストラクチャの重要なコンポーネントであるため、適切に保護する必要があります。セキュリティと認証には、いくつかのオプションを使用できます。
- Spinnaker for Google Cloud Platform は、SSL 証明書付きの IAP を使用してデプロイメントを保護するためのツールを提供しています。
- Spinnaker のセキュリティに関するドキュメントを表示します。
- Google Workspace を Spinnaker 認証の ID プロバイダとして使用します。
- Google グループを Spinnaker の認可に使用します。
- Spinnaker の手前に Identity-Aware Proxy を構成して、Spinnaker にアクセスできるユーザーをより詳細にコントロールします。

Spinnaker を使用したアプリのデプロイ

このセクションでは、Spinnaker を構成して、GKE クラスタにアプリをデプロイします。

Spinnaker アプリを作成する

デプロイする前に、Spinnaker のアプリを作成してください。

Spinnaker で [Actions] を選択し、[Create Application] を選択します。
[New Application] ダイアログで、次の値を入力します。
- Name: sampleapp
- Owner Email: [example@example.com]
  警告: このチュートリアルの残りの部分を問題なく進めるには、必ずアプリの名前を sampleapp にしてください。
[Create] を選択します。

これで Spinnaker の sampleapp に入りました。まだ何も構成していないため、ほとんどのタブは空です。

デプロイパイプラインを作成して実行する

このセクションではまず、successRate パラメータを受け取る単純な Spinnaker パイプラインを使用してアプリをデプロイし、4 つの Pod を持つ GKE Deployment を作成します。これらの Pod は、successRate パラメータに対応するレートでランダムにエラーをスローします。このチュートリアルでは、100 - successRate のレートで 500 エラーをスローします。

Cloud Shell で、用意された JSON ファイルを使用してパイプラインを作成します。次のコマンドは、パイプラインの JSON 定義を Spinnaker API に直接送信します。

cd ~
wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/simple-deploy.json
sed "s/my-kubernetes-account/spinnaker-install-account/g" simple-deploy.json > updated-simple-deploy.json
spin pipeline save --file updated-simple-deploy.json

Spinnaker の [Pipelines] セクションに、Simple deploy というパイプラインが表示されます。これが表示されない場合、ページを再読み込みします。[Start Manual Execution] を選択します。
[Confirm Execution] ウィンドウで、[Success Rate] として 70 を選択し、[Run] を選択します。数秒後、パイプラインによってアプリと 4 つの Pod の構成がデプロイされます。

Cloud Shell で、チュートリアルが終了するまでの間新しいアプリにリクエストを送信する Pod を作成します。

kubectl -n default run injector --generator=run-pod/v1 --image=alpine:3.10 -- \
    /bin/sh -c "apk add --no-cache curl; \
    while true; do curl -sS --max-time 3 \
    http://sampleapp:8080/; done"

インジェクタのログを確認する

アプリの動作を確認するため、インジェクタのログを確認します。

kubectl -n default logs -f \
    $(kubectl -n default get pods -l run=injector \
    -o=jsonpath='{.items[0].metadata.name}')

多数の内部サーバーエラーメッセージがログに表示されます。インジェクタのログの追跡を停止するには、Ctrl+C キーを押します。

アプリのヘルスチェックを行う

これでアプリがデプロイされてトラフィックが処理されるようになったので、次にアプリが正しく動作しているかどうかを確認します。もちろん、このチュートリアルでは 70% の成功率でアプリをデプロイしたため、アプリが正しく動作しないことが最初からわかっています。

このアプリは、Monitoring に取り込まれる Prometheus 形式の指標を持つ /metrics エンドポイントを公開します。このセクションでは、これらの指標を Monitoring で可視化します。

Google Cloud Console で [Monitoring] に移動します。

[Monitoring] に移動
ナビゲーションパネルに [Metrics Explorer] が表示されている場合は、 [Metrics Explorer] を選択します。それ以外の場合は、 [リソース] を選択して [Metrics Explorer] を選択します。
[Metric] タブが選択されていることを確認します。
「Find resource type and metric」というラベルが付いたチェックボックスを選択し、「external.googleapis.com/prometheus/requests」と入力します。
グラフを見やすくするために、[Group By] フィールドに「http_code」と入力します。

次のグラフでは、アプリが応答した HTTP リクエストの割合が HTTP ステータスコード別にグループ化されています。

Monitoring にデータがない場合や external.googleapis.com/prometheus/requests の指標が見つからない場合は、Monitoring でデータが取り込まれるまで数分待ってから、Metrics Explorer を再読み込みしてください。

グラフからわかるように、アプリの現在のエラー率は約 30%（予測どおり）であり、許容されないレベルにあります。チュートリアルの残りの部分では、カナリアデプロイパイプラインと自動分析をセットアップし、このようにエラー率の高いアプリがデプロイされないようにする方法を説明します。

カナリアデプロイの作成

このセクションでは、カナリアデプロイパイプラインを自動分析なしで作成し、アプリの新しいバージョンを本番環境に全面的にデプロイする前に新しいバージョンのテストを行います。わかりやすくするために、このセクションで説明するパイプラインは Kubernetes 負荷分散を使用して、カナリアバージョンにトラフィックを送信します。このため、カナリアのどの部分にトラフィックをルーティングするかを選択できません。高度なトラフィックルーティングポリシーを実装するには、Istio を使用します。

次の図は、このパイプラインのステージの全体図を示しています。

カナリアデプロイパイプラインのステージの図。

ステップ 0: Simple Deploy パイプラインと同様に、このパイプラインも Success Rate パラメータを入力として受け取ります。この新しいパイプラインは、このパラメータを使用してさまざまな成功率をシミュレートします。これはパイプラインの Configuration ステージです。
ステップ 1: Find Baseline Version ステージでは、直近に実行された Simple Deploy パイプラインから、本番環境で実行されているアプリの現在のバージョンが取得されます。このチュートリアルでは、現在デプロイされているアプリの成功率を取得します。

Find Baseline Version ステージと並行して、Deploy Canary Config ステージで、アプリのカナリアバージョンの新しい成功率構成がデプロイされます。
ステップ 2: Deploy Canary ステージと Deploy Baseline ステージでは、比較のために新しいカナリアバージョンとベースラインバージョンの 2 つのバージョンがデプロイされます。カナリアバージョンは Deploy Canary Config で作成された構成を使用するのに対し、ベースラインバージョンは本番環境バージョンで使用されている構成を使用します。
注: カナリアのベストプラクティスを参照すると、カナリアバージョンを本番環境で実行しているインスタンスと直接比較するより、ベースラインバージョンと比較するほうがよい理由がわかります。
ステップ 3: Manual Judgment ステージではパイプラインが停止し、手動で続行を指示するまで先に進みません。このステージで、カナリアバージョンが正しく動作するかどうかを確認できます。
ステップ 4: Manual Judgment ステージからパイプラインを続行した後、Delete Canary ステージと Delete Baseline ステージでインフラストラクチャがクリーンアップされます。

クリーンアップと並行して Deploy to Production ステージが開始され、最初に指定したときと同じ Success Rate パラメータを使用して Simple Deploy パイプラインがトリガーされます。カナリアでテストしたアプリと同じバージョンが本番環境にデプロイされます。

Deploy to Production ステージは、Manual Judgment ステージで手動で continue を選択した場合にのみトリガーされます。
ステップ 5: 最後に、Successful Deployment ステージでパイプライン全体が正常に完了したことが確認されます。ここでは、Manual Judgment ステージで本番環境へのデプロイを許可したことが確認されます。このステージは、Deploy to Production、Delete Canary、Delete Baseline の各ステージが正常に動作した場合にのみ実行されます。

これで、Canary Deploy パイプラインを作成して実行できます。

Canary Deploy パイプラインを作成するには、次のコマンドを実行して Simple deploy パイプラインの ID を取得し、Canary Deploy パイプラインに挿入します。

cd ~
wget https://raw.githubusercontent.com/spinnaker/spinnaker/master/solutions/kayenta/pipelines/canary-deploy.json
export PIPELINE_ID=$(spin pipeline get -a sampleapp -n 'Simple deploy' | jq -r '.id')
jq '(.stages[] | select(.refId == "9") | .pipeline) |= env.PIPELINE_ID | (.stages[] | select(.refId == "8") | .pipeline) |= env.PIPELINE_ID' canary-deploy.json | \
    sed "s/my-kubernetes-account/spinnaker-install-account/g" > updated-canary-deploy.json
    spin pipeline save --file updated-canary-deploy.json

Spinnaker に Canary Deploy パイプラインが表示されない場合は、sampleapp ページを再読み込みして、[Pipelines] を選択します。
次のようにして、Canary Deploy パイプラインを開始します。
1. [Start Manual Execution] を選択します。
2. [Success Rate] として 80 を選択します。
3. [Run] を選択します。
パイプラインが Manual Judgment ステージに到達した際、カナリアバージョンとベースラインバージョンを比較する必要があるため、[Continue] を選択しないでください。

Cloud Shell で kubectl -n default get pods コマンドを実行して、canary と baseline というラベルの付いた新しい Pod を表示します。

NAME                                READY STATUS  RESTARTS  AGE
injector-66bd655ffd-9ntwx           1/1   Running 0         30m
sampleapp-5cdf8f55dd-995rz          1/1   Running 0         28m
sampleapp-5cdf8f55dd-dqq8n          1/1   Running 0         28m
sampleapp-5cdf8f55dd-ntq57          1/1   Running 0         28m
sampleapp-5cdf8f55dd-rlpzp          1/1   Running 0         28m
sampleapp-baseline-567b8d6849-gsgqr 1/1   Running 0          4m
sampleapp-canary-54b9759dd6-gmjhc   1/1   Running 0          4m

Google Cloud Console で [Monitoring] に移動します。

[Monitoring] に移動
ナビゲーションパネルに [Metrics Explorer] が表示されている場合は、 [Metrics Explorer] を選択します。それ以外の場合は、（リソース）を選択して [Metrics Explorer] を選択します。
[Metric] タブが選択されていることを確認します。
ベースラインとカナリアの両方のエラー率を表示するには、次のパラメータを指定します。
1. Metric: external.googleapis.com/prometheus/requests
2. Filters:
  1. http_code = 500（http_code は 500 に等しい）
  2. version != prod（version は prod と異なる）
Monitoring のデータの一部に不足がある場合は、そのデータが表示されるまで数分待ちます。
カナリアバージョン（次のグラフの紫色）とベースラインバージョン（次のグラフの青色）を比較します。実際のグラフの色はこれとは異なる場合があります。このチュートリアルでは、カナリアバージョンのエラー率はベースラインバージョンよりも低くなっています。したがって、カナリアバージョンを本番環境に全面的にデプロイしても安全です。カナリアバージョンのエラー率の方が高い場合、この段階でデプロイを中止し、アプリを修正します。
Spinnaker の [Manual Judgment] ダイアログで、[Continue] を選択します。
デプロイが完了したら、[Monitoring] に戻ります。

[Monitoring] に移動
ナビゲーションパネルに [Metrics Explorer] が表示されている場合は、 [Metrics Explorer] を選択します。それ以外の場合は、 [リソース] を選択して [Metrics Explorer] を選択します。
[Metric] タブが選択されていることを確認します。
[Find resource type and metric] のボックスを選択して、リソースと指標をメニューから選択するか、リソースと指標の名前を入力します。次の情報を使用して、このテキストボックスのフィールドに入力します。
1. [Metric] で「external.googleapis.com/prometheus/requests」を選択または入力します。
2. [Group By] フィールドに「http_code」と入力します。
次のグラフでは、アプリが応答した HTTP リクエストの割合が HTTP ステータスコードによって分割されています。

このグラフは、本番環境、ベースライン、カナリアのすべての Pod の HTTP コード 200 および 500 の割合を示します。カナリアバージョンのほうがエラー率が低かったため、このバージョンを本番環境にデプロイしました。デプロイ中に短時間でリクエストの総数が若干少なくなり、その後全体のエラー率が低下したことがわかります。これはカナリアバージョンが本番環境に正しくデプロイされたことを示します。

カナリア分析の自動化

カナリアデプロイは便利ですが、現在の構成では手動プロセスです。全面的にデプロイする前に、カナリアが期待どおりに動作していることを人手を介して確認する必要があります。また、カナリアとベースラインの違いは常に明確であるとは限りません。

カナリア分析を自動化することは良い考えです。自動化すると、自ら分析作業を行わなくて済みます。また、自動化された統計分析の方が、人間が一連の指標に潜む問題を検出するよりも適しています。このセクションでは、Manual Judgement ステージを自動カナリア分析に置き換えます。

カナリアのサポートを有効にする

まず、Spinnaker で、Kayenta と呼ばれる自動カナリア分析機能を構成します。Kayenta の構成には Halyard を使用します。これは Spinnaker の構成やデプロイに使用するのと同じツールです。

Monitoring をバックエンドとして使用するように Kayenta を構成します。

hal config canary google enable
hal config canary google account add kayenta-tutorial --project $DEVSHELL_PROJECT_ID
hal config canary google edit --stackdriver-enabled=true

新しい構成を適用します。
```
~/cloudshell_open/spinnaker-for-gcp/scripts/manage/push_and_apply.sh
```
デプロイが完了するまで数分かかります。

自動カナリア分析機能を構成する

Kayenta が有効になったので、次に sampleapp で Kayenta を構成します。

Spinnaker で [Config] を選択します。
[Features] セクションで [Canary] を選択し、[Save Changes] を選択します。

カナリア構成を作成する

Spinnaker の自動カナリア分析は、さまざまな指標に対する統計テストを実行し、スコアを出力します。このスコアは範囲が 0〜100 で、ベースラインとカナリアを比較した結果合格基準を満たしていた、または満たしていなかった指標の数を表します。指標を複数のグループにまとめ、グループごとに重みを変えることで、スコアに影響を与えることができます。分析のスコアに応じて、デプロイを進めるかどうかを決定できます。このチュートリアルのように指標を 1 つしか使わない場合、スコアは 0（不合格）と 100（合格）のどちらかになります。

アプリには複数のカナリア構成を設定でき、1 つのカナリア構成を複数のアプリで共有できます。カナリア構成は、次の 2 つの主要な要素からなります。

分析する指標のセット（複数のグループにまとめることができます）。
スコアの下限しきい値と合格しきい値。

デプロイパイプラインでは、Canary Analysis ステージでカナリア構成が使用されます。このステージでは、カナリアランを複数回実行できます。いずれかのランのスコアが下限しきい値を下回った場合、このステージは中止され、他のランは実行されません。ステージ全体が合格とみなされるには、最後のランのスコアが合格しきい値を上回る必要があります。

カナリア構成を作成する手順は次のとおりです。

カナリアが有効になったので、[Pipelines] セクションは [Delivery] に置き換えられます（[Delivery] セクションが表示されていない場合は Spinnaker を再読み込みしてください）。[Delivery] セクションで、[Canary Configs] に移動します。
[Add Configuration] を選択します。
[Configuration Name] に「kayenta-test」と入力します。
[Metrics] セクションで [Add Metric] を選択します。
[Add Metric] ダイアログで、次の値を入力して [OK] を選択します。
- Name: error_rate
- Fail on: increase
- Resource Type: k8s_container
- Metric type: external.googleapis.com/prometheus/requests
- Aligner: ALIGN_RATE
- Filtner Template: [Create new] を選択します。
  - 新しいフィルタテンプレートの [Name] に「http_code」と入力します。
  - 新しいフィルタテンプレートの [Template] に「metric.labels.http_code = "500" AND resource.label.pod_name = starts_with("${scope}")」と入力します。
  - [Save] を選択します。
注: Aligner（整列指定子）は Cloud Monitoring API のパラメータで、絶対値ではなく指標の変化率を比較します。このチュートリアルのアプリは、起動してからのエラーの総数を指標として公開しています。Kayenta では、これらのエラーの割合がアプリの 2 つのバージョン間で変化したかどうかを比較する必要があります。
[Scoring] セクションで、Group 1 を 100 に設定します。
[Save Changes] を選択します。

パイプラインにカナリア分析ステージを追加する

カナリア構成を作成したら、次に既存のデプロイパイプラインの Manual Judgment ステージを、この構成を使用する Canary Analysis ステージに置き換えます。

[Delivery] > [Pipelines] に移動し、[Canary Deploy] パイプラインの [Configure] を選択します。
[Add Stage] を選択します。
[Type] で [Canary Analysis] を選択します。
[Depends On] セクションで、新しいステージの依存先を次のステージに設定します。
- Deploy Canary
- Deploy Baseline

[Canary Analysis Configuration] セクションで、次の値を入力します。

パラメータ名	値	定義
Analysis Type	Real Time（Manual）	カナリアとベースラインが自動的に作成される自動モードは、Kubernetes ではまだ使用できません。
Config Name	`kayenta-test`	前のステップで作成したカナリア構成の名前。
Lifetime	0 時間 5 分	カナリア分析の存続時間。
Delay	0	分析を行う前にアプリをウォームアップする時間。
Interval	5	Kayenta が統計分析を 1 回実行するために使用する時間枠。
Baseline	`sampleapp-baseline`	Kayenta がベースラインとして使用する GKE Deployment。
Baseline Location	default	ベースラインが存在する GKE Namespace。
Canary	`sampleapp-canary`	Kayenta がカナリアとして使用する GKE Deployment。
Canary Location	default	カナリアが存在する GKE Namespace。
Marginal	75	カナリアの下限合格のしきい値スコア。
Pass	95	カナリアの全体合格のしきい値スコア。

[Execution Options] セクションで、[Ignore the failure] を選択します。カナリア分析が失敗した場合でもベースラインとカナリアを破棄できるように、失敗を無視します。このチュートリアルの後の方で、カナリアが失敗する可能性を考慮に入れてステージを変更します。
パイプラインの線図で、[Deploy to Production] を選択します。
[Depends On] セクションを次のように変更します。
1. [Canary Analysis] を追加します。
2. [Manual Judgment] を削除します。
カナリア分析が成功した場合にのみ本番環境にデプロイされるようにするため、[Conditional on Expression] パラメータを変更します。
```
${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
```
パイプラインの線図で、[Delete Canary] を選択し、[Depend On] セクションを次のパラメータに変更します。
1. [Canary Analysis] を追加します。
2. [Manual Judgment] を削除します。
パイプラインの線図で [Delete Baseline] を選択し、[Depends On] セクションを変更します。
1. [Canary Analysis] を追加します。
2. [Manual Judgment] を削除します。
カナリア分析が失敗した場合にパイプライン全体が失敗するようにするため、パイプラインの線図で [Successful deployment] を選択し、既存の前提条件の [Edit] アイコンを選択します。
1. [Expression] を次のように変更します。
```
${ #stage('Canary Analysis')['status'].toString() == 'SUCCEEDED'}
```
2. [Update] を選択します。
最後に、Manual Judgement ステージを新しく作成した Canary Analysis ステージに置き換えます。
1. パイプラインの線図で、[Manual Judgment] を選択します。
2. [Remove stage] を選択します。
[Save Changes] を選択します。

これでパイプラインは次の図のようになります。

新しいパイプラインをテストする

自動カナリア分析の構成が完了したので、次にパイプラインをテストして期待どおりに動作することを確認します。

[Delivery] > [Pipelines] に移動します。Canary Deploy パイプライン、または Automated Canary Deploy で CLI を使用している場合は、[Start Manual Execution] を選択します。
[Success Rate] として 60 を選択し、[Run] を選択します。
カナリア分析の現在の進行状況を確認するには、[Canary Analysis] を選択し、[Task Status] を選択します。数分後、Canary Analysis ステージは失敗します。これは本番環境の現在の成功率が 80 であるためです。Canary Analysis ステージが失敗したら、このカナリア分析のレポートに移動します。
1. [Canary Analysis] を選択します。
2. [Canary Summary] を選択します。
3. [Report] アイコンをクリックします。
  
  レポートページでは、カナリアバージョンのエラー率がベースラインバージョンよりも高くなっています。
このセクションの手順をもう一度繰り返しますが、今度はカナリア分析を成功させるために [Success Rate] で 90 を選択します。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のチュートリアルとクイックスタートを検討する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て制限を超えないようにできます。

Cloud Console で [リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

リソースの削除

このチュートリアルで使用した Google Cloud プロジェクトを残しておく場合は、個々のリソースを削除します。

GKE クラスタを削除します。

gcloud container clusters delete spinnaker-1

確認のプロンプトが表示されたら、「Y」と入力します。

次のステップ

Spinnaker の詳細を確認する。
Waze と Netflix が Spinnaker / Kayenta をどのように利用しているかを見る。
継続的デリバリーに関するすべてのリソースを見る。
Spinnaker を Cloud Build や Cloud Source Repositories と組み合わせて使用する方法を学ぶ。
Spinnaker を使用した GKE への継続的デリバリーを扱った Codelab を試す。
spin（Spinnaker アプリとパイプラインを管理する CLI ツール）の概要を見る。
その他のアプリケーションのデプロイとテストの戦略について理解する。
Google Cloud のその他の機能を試す。チュートリアルをご覧ください。