マルチクラウドでContinuous Deliveryを実現するSpinnakerについて

マルチクラウドでContinuous Deliveryを
実現するSpinnakerについて

本日のお話
マルチクラウドで継続的デリバリー（Continuous Delivery）を実現する
Spinnakerについて知ってもらい興味を持ってもらう

継続的デリバリー（Continuous Delivery）は何故必要なの？
・今日では、ユーザはソフトウェアやサービスに対して24時間のサービスアク
セスと100%の稼働率を期待している
・サービスの計画的あるいは計画外のダウンタイムが発生すると信頼性の低下
が著しい一方で、継続的なサービスのアップグレードも望まれる
24時間使えない検索
エンジンだなんて失望
しました。他の検索エ
ンジンを常用します
急なメンテナンスがこ
んなにあるなんて失望
しました。他の類似サ
ービスに乗り換えます
1ヶ月も更新がないな
んて失望しました。こ
んなサービス解約しま
す

Continuous Deliveryには何が必要なの？
ソフトウェアやサービスの稼働を維持しつつ継続的なアップデートをするには
何が必要か？
・アプリケーションのデプロイを短時間で自動的に行いたい
・新規アプリのデプロイを確実に行いたい。問題が発生しても即切り戻したい
・APIの差分吸収で異なるプロジェクト環境でもデプロイ方法は共通化したい

SpinnakerでContinuous Deliveryを実現しよう
・アプリケーションのデプロイを短時間で自動的に行いたい
→Pipelineによってイベントの取得やデプロイイメージ作成、インスタンス作成、
ロードバランサ配下への配置まで全て自動で行える
・新規アプリのデプロイを確実に行いたい。問題が発生しても即切り戻したい
→Blue/Green DeploymentやCanary Deploymentなど問題があったら即ロールバッ
ク可能な複数のデプロイ方法をサポート
・ APIの差分吸収で異なるプロジェクト環境でもデプロイ方法は共通化したい
→複数のクラウドAPIをサポートすることでデプロイプロセスの共通化

Spinnakerとは
● マルチクラウドでContinuous Delivery（CD）を実現するプラットフォーム
● クラスタの管理やImageの作成、デプロイ管理などの Pipeline を提供
● Netflix社が開発し、OSSとして公開されているが現在はGoogleやPivotal,
Microsoft, Mirantisなども開発に参加している
● AWSやK8S, GCP全体にクラスタをデプロイして管理可能で、現在でも多くの
機能が追加されている

パイプラインはアプリケーションのコードをプロダクションにリリースするため
に必要なすべての手順を実行するプロセス
PipelineとCI/CD
Test/Build Deploy Test Approve
CI CD

Spinnaker Cloud Target
詳細はリポジトリを御覧ください
https://github.com/spinnaker/clouddriver/
● AWS (EC2)
● Docker
● GCP (AppEngine, GCE, GKE)
● Kubernetes
● Microsft Azure
● OpenStack
● etc...

Blue / Green Deployment
SpinnakerはBlue / Green Deploymentを実現
Green (new) に問題があった場合はBlue（old）にRollbackが可能
https://www.spinnaker.io/concepts/

Canary Deployment
Spinnaker ではCanary Deploymentもサポート
新規のプロダクトやサービスをデプロイした際に先に少量の実トラフィックを流
すことで、全体への影響を抑えつつ展開していくことが可能

参考：NetflixのCanary Release Process
3つのクラスタで運用しそれぞれに同じトラフィックから量を変えて流す
1. Production：本番環境 (many servers)
2. Baseline：Canaryと比較するための現行バージョン(1 + m servers)
3. Canary：新バージョン(1 + m servers)
Traffic Router
Metrics
Canary
Analysis
Production(v1.0)
Baseline(v1.0)
Canary(v2.0)

参考：NetflixのCanary Release Process
3つのクラスタで運用しそれぞれに同じトラフィックから量を変えて流す
1. Production：本番環境 (many servers)
2. Baseline：Canaryと比較するための現行バージョン(1 + m servers)
3. Canary：新バージョン(1 + m servers)
Traffic Router
Metrics
Canary
Analysis
Production(v1.0)
Baseline(v1.0)
Canary(v2.0)
指標値の取得にはStackdriver, Prometheus, DataDog, New Relicが使用可能
で応答時間やエラーレート、メモリ使用率などを取得可能
取得した多くの指標値から問題ないか評価可能、また指標値ごとに応答時間
は重要度高、リソース飽和度は重要度低など重み付けが可能

実際に動作検証
・目的：
Gitやコンテナレジストリにコードをアップするだけでデプロイ→テスト→更新や
切り戻しをできるのか確認
動作の一連の流れ
１.「Hello world」と表示する簡単なwebアプリを「Hello Spinnaker」に変更して
グーグルコンテナレジストリ（gcr）に登録
２.下記パイプラインで自動検知→自動デプロイ→canary分析→本番環境の更新が
できるか確認
３.前のバージョンにも切り戻しできるか確認

・初期状態：
簡易な文字列のみを表示するウェブアプリがデプロイ・公開されている
これをgcrにコードを上げることで自動でバージョンUPしたい

・自動検知：
GCRに新規バージョンコードをUPすると自動で検知しパイプラインを起動

・自動検知：
GCRに新規バージョンをアップロード

・自動検知：
SpinnakerがGCRにアップロードされたことを検知して、自
動的にパイプラインを起動

・自動デプロイ：
トリガーによって比較用の現行バージョン(Baseline)と投稿された新バージョン
(Canary)が自動でデプロイされる

トリガーによって自動的に比較用の現行バージョン（Baseline）と投稿された新
バージョン(Canary)がデプロイされる
パイプラインが走ると既存のバージョンイメージを読み取り、
新規バージョンと比較するための現行バージョンのコピーが
自動でデプロイされる

トリガーによって自動的に比較用の現行バージョン（Baseline）と投稿された新
バージョン(Canary)がデプロイされる
同時に投稿された新規バージョンについても自動的にデ
プロイされる

・Canary分析：
立ち上げたBaselineとCanaryバージョンについて比較確認し、問題がないかテス
トできる。一例としてWebアプリならHTTPステータスコードや例外数、応答時
間・負荷平均などに大きな差がないか確認

・Canary分析設定：
各条件については詳細に設定可能
・Fail on: increaseは増加時にFail, decreaseは減少時にFail, eitherは増減時にFail
・Criticality: この条件が失敗した場合は即Fail。特に重要な指標に用いる
・NaN Strategy:取得した値がNaNだった時の処理を指定

デフォルトの分析アルゴリズムはNetflixAXAJudgeである。重要度に基づいて重み
付けを行った各条件が成功した割合で成功か判定がなされる。Passの値を超えて
いれば成功。Marginalを超えていれば人目で判断。Marginal以下なら失敗。

デフォルトの分析アルゴリズムはNetflixAXAJudgeである。重要度に基づいて重み
付けを行った各条件が成功した割合で成功か判定がなされる。Passの値を超えて
いれば成功。Marginalを超えていれば人目で判断。Marginal以下なら失敗。
例えば、以下のようにCPURAW関連に30, 接続関係に50, processと
systemcpu関連に10の重み付けを行って、右図のように各条件の判定
結果が出た場合、全体として85%成功しておりPassの70%を超えてい
るので成功判定を出し、下流のパイプラインに進む

・本番環境の更新：
Canary分析に成功したら本番環境を新規バージョンにアップデートする。アップ
デート後立ち上げたBaselineとCanary バージョンも自動で削除

・本番環境の更新：
Canary分析に成功したら本番環境を新規バージョンにアップデートする。アップ
デート後立ち上げたBaselineとCanary バージョンも自動で削除
GCRに登録するだけで検知→デプロイ→canary分析→本番環境更新まで自動化できた

切り戻しの確認
・CLUSTERS情報から過去のバージョンに簡単にロールバックを実行可能

切り戻し先のバージョン番号を指定切り戻しが自動で実行される

・容易に切り戻しを実行できることも確認できた

Spinnaker Monitoring
● Spinnakerを用いることで各アプリケーションのテストやロールバック
を容易に扱え、正常に動作させることが可能となる
● 一方でSpinnaker自体が正しく動作しているかはどう判断すれば良い
か？
● 以降では、Spinnakerの構成要素を紹介しつつPrometheusを利用して
Spinnakerの各要素から取れる主要なメトリックを紹介する。
参考
https://docs.armory.io/docs/
https://blog.spinnaker.io/monitoring-spinnaker-sla-metrics-a408754f6b7b

Spinnaker Architecture
● Deck – Spinnaker UI
● Gate – API Gateway
● Orca - Orchestrate engine
● Cloddriver - Cloud controller
● Fiat - Authorization
● Front50 - Metadata management
● Rosco - Image builder
● Kayenta - Canary Analysis
● Echo - Event bus
● Igor - Pipelines trigger

Spinnaker Architecture
・Spinnaker内のPipeline, Stage, Taskの
オーケストレーションを担当。
・専用の遅延分散キューライブラリ
Keikoを使用して作業を管理
・単一のスレッドで最も古い「準備が
できている」メッセージをポーリング
し、ワーカースレッドに割り当てる。
従ってスケーリング機能はワーカープ
ールのスレッド可用性に依存

Spinnaker Monitoring Orca
オーケストレーションを担当しているため多くの重要なメトリックスが取れる
・task.invocation.duration(count)
-個々のキューのタスクの実行時間。個数をカウントすればどのくらい処理してい
るかの指標にもなる。アプリケーションでグループ分けすることでどのサービスが
主に負荷をかけているかも確認できる

・controller.invocations
-http statusの応答確認の総計などが取得可能。status=5xxでFilterして異常にスパイ
クしているようならCloudDriverで問題があるかポーリングするスレッド容量がほ
とんどないなどの問題がある。

・executions.active(started,completed)
-実行中のPipelineとOrchestrationを確認可能。ほぼプログラム的に同一だが前者は
事前定義された永続的な構成であるのに対して、後者はスケジュールされていない
アドホックAPI送信アクションでありリクエスト時に任意に構成される。異常があ
れば明らかに減るので監視・アラート第一候補
また、started,completedを確認すればどれくらい成功できているか確認できる

・queue.pushed/queue.acknowledged
-2つの指標を見比べて後者の応答がない場合には、ダウンストリームに問題がある
ことを示す指標として有効
・queue.depth(ready,unacted)
-readyのtaskが溜まっている場合、すぐに処理に移行可能だが払い出しを待ってい
るのが多数ある状態なのでスケールUPが必要
・queue.message.lag
-メッセージの望ましい配信時間と実際に配信された時間差。通常バックアップが
走らない限り極小であり、頻繁に何秒も待つ場合はスケールUPが必要

Spinnaker Monitoring Echo
● Echo - Event bus
・Notificationやalert、Triggerを管理。
主に外部からの通知等に問題がないかどうかの指標が取れる
・echo.triggers.count
-トリガーによって起動されたパイプライン数を確認できる。サービスの統合・
廃止をしない限り安定していることが望まれる
・echo.pubsub.messagesProcessed
-処理したPubSubトリガー数を確認できる。こちらもブレはあるが数分反応がな
いならアラートを出すようにしたりと設定できる

Spinnaker Monitoring Igor
● Igor - Pipelines trigger
・JenkinsなどのCIツールと通信するラッパーAPI
-他：Artifactory, Nexus, Concourse, GitlabCI, Google Cloud
Buile, Travis, Wercker
・pollingMonitor.failed
-SCMポーリングの失敗率。多くの場合0を超えていたらCIツール側がオフラ
インなどの問題がある。
・pollingMonitor.newItems
-ポーリングサイクル中に特定のモニターでキャッシュされたアイテム数。
想定外の値なら外部に問題あり

まとめ
・Spinnakerを使うことで、本番環境までのデプロイメントを自動化できる。
ーGithubやGitlabなど複数のリソースから更新を検知可能
・本番環境を想定したテストやロールバック機能を有する
ーBlue /GreenやCanaryなど複数のデプロイ戦略をサポート
・Prometheusと連携することでSpinnakerが正常に動作しているか確認するため
の有効な指標値を取得することができるため、より安定したCI CDを実現可能

マルチクラウドでContinuous Deliveryを実現するSpinnakerについて

More Related Content

More from NTT Communications Technology Development

マルチクラウドでContinuous Deliveryを実現するSpinnakerについて

Editor's Notes