SpinnakerのAutomated Canary Analysis Workshopを受けてきた

はじめに

Spinnaker Summit 2018でAutomated Canary Analysis Workshopを受けてきたのでメモ

• 元のスライド: https://github.com/spinnaker/spinnaker/blob/master/codelabs/gke-kayenta-workshop/Automated%20Canary%20Analysis%20Workshop%20-%20Spinnaker%20Summit%202018.pdf

概要

Canary Releaseとは

新しいコードをデプロイした際に先に少量の実サービストラフィックを流して評価することで、全体への影響を抑えつつ展開していける手法

Kayenta

KayentaはStackdriverやPrometheusなどのメトリクスを使ってCanaryが現在のProductionよりデグレしていないか解析し、自動的に判断してくれるSpinnakerのコンポーネント

Workshop

環境

GCP上にGKE, GCR, GCS, Stackdriver, Pub/Sub, CloudBuildなどを使って構築する
yamlをGCSにアップロード、もしくはCloud Buildでコンテナイメージをビルドを契機にパイプラインが走る構成

yaml -> GCS
Dockerfile -> Cloud Build -> GCR

GCS, GCR -> Pub/Sub -> Spinnaker(Staging -> Canary -> Production) -> K8s(GKE)

インストール

GoogleCloudShell

gsutil cp gs://gke-spinnaker-codelab/base/install.tar .
tar xvf install.tar
./setup.sh kayenta-workshop

これでKubernetesクラスタが作成され, その上にSpinnaker(Kayenta入り)とサンプルのサービスがデプロイされる
また、8080ポートでSpinnakerのWeb UIにアクセスできる

(Automatedでない) Canary Release

割愛、この辺からやればOK

• https://codelabs.developers.google.com/codelabs/cloud-spinnaker-kubernetes-cd/index.html#2

※コンテナのメモリを減らした場合は戻すのを忘れずに

Stackdriverでメトリクスを見てみる

以下のような設定でMetrics Explorerを開いておくとproduction環境のコンテナのメモリ使用率が見れる

Resource type: k8s_container
Metric: kubernetes.io/container/memory/request_utilization
Filter:
    cluster_name=spin-kayenta-workshop
    namespace_name=production
Group By: label top_level_controller_name
Aggregation: mean

Canary Configの作成

SpinnakerのWeb UIの
Applications -> demo -> DELIVERY -> CANARY CONFIGS -> Add configuration
から

NAME AND DESCRIPTION:
     Configration Name: sample-canary-config
FILTER TEMPLATES:
     - Name: mem-request-util-template
       Template: resource.label.cluster_name="spin-kayenta-workshop" AND resource.label.namespace_name="${location}" AND metadata.system_labels.top_level_controller_name="${scope}"
METRICS: 
     - Group: Group 1
       Name: mem-request-util
       Filter Template: mem-request-util-template
       Metric Type: kubernetes.io/container/memory/request_utilization
SCORING:
     Metric Group Weights:
          - Group 1: 100 

てきな感じで作る、見ればわかるが上のStackdriverで見たメトリクスと同じもの

Canary Analysisへパイプラインの変更

PIPELINES -> Deploy Simple Canary to Production -> Configure
からManually Validate Canary Resultsのステージを消して、Wait For Canary ResultsをCanary Analysisに変更する

Canary Analysisの設定はこんな感じ

Analysis Config:
     Analysis Type: Real Time (Manual)
     Config Name: sample-canary-config
     Lifetime: 0h5min
     Delay: 2min
     Step: 60sec
Baseline + Canary Server Groups:
     Baseline: backend-primary
     Baseline Location: production
     Canary: backend-canary
     Canary Location: production
Metric Scope:
     Resource Type: k8s_container
Advanced Settings:
     Metrics Account: my-google-account
     Storage Account: my-google-account

Baseline, Canaryの設定は上で設定したCanary Configの${scope}と${location}に入り、これを元にメトリクスの比較が行われる

Canary Analysisの動作確認

テスト環境ではトラフィックが来るわけではないので、コードの変更によってパフォーマンスが悪化した場合をシミュレートするために（だと思う）backendのメモリの設定を128Mi -> 12Miに変更してみる

~/services/manifests/backend.yml

        resources:
          requests:
            cpu: 100m
            memory: 12Mi
          limits:
            cpu: 100m
            memory: 12Mi

$ cd services/manifests/
$ ./update-backend.sh

Deploy to StagingはManual JudgementになっているのでOKする

上で作ったクエリをStackdriverで見てみると（当たり前だが）canaryのメモリの使用"率"が今のproductionと比べて大幅に高いことがわかる これをみてCanary Analysisは自動的にProducationへのデプロイを止める

おまけ

ThresholdsのMarginalとかMetricのCriticalityとかそのうち書きたい