GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析
GoogleとNetflixは、共同開発したカナリアリリース分析ツールの「Kayenta」をオープンソースで公開した。新規リリースを本番環境に対して小規模にデプロイし、問題がないかを検証する作業を自動化。より迅速で確実な継続的デリバリを実現する。
GoogleやNetflixのようにWebサービスを提供している企業では、そのWebサービスに次々と改良が加えられ、1日に何度も新しいリリースがデプロイされています。
しかし新しいリリースのデプロイはいきなり大規模に行われるわけではありません。リリースされるコードに対しては継続的デリバリのパイプラインの中で一通りの自動テストが行われ、ある程度の品質が保証されているはずです。しかし、それでも新しいリリースに何らかのバグなどが含まれている可能性を排除できません。
そこで新規リリースはまず、本番環境全体に対していきなりデプロイされるのではなく、ごく一部のユーザーだけに利用されるように小さな割合でリリースされます。そしてしばらくその振る舞いが観察され、問題がないと判断されてから大規模にデプロイされるのです。
一般に、このような試験的なリリースを小規模に行うこと、あるいはその対象となるリリースは「Canary Release」(カナリアリリース)と呼ばれています。
これはかつて炭鉱夫が、炭鉱のなかで一酸化炭素や有毒ガスが発生した場合にそれをいち早く察して逃げるため、そうした変化に弱いカナリアを鳥かごに入れて炭鉱に持ち込んだことに由来すると言われています。カナリアリリースは、そのリリースになにか問題があった場合にいち早く気づくためのものなのです。
「Kayenta」を公開。GoogleとNetflixが共同開発
GoogleとNetflixは、このカナリアリリースの振る舞いを自動的に分析しスコアリングするカナリアリリース分析ツール「Kayenta」を共同開発し、オープンソースとして公開しました(Googleのブログ「Introducing Kayenta: An open automated canary analysis tool from Google and Netflix」、Netflixのブログ「Automated Canary Analysis at Netflix with Kayenta」)。
GoogleはKayentaを次のように紹介しています。
Kayenta is an evolution of Netflix’s internal canary system, reimagined to be completely open, extensible and capable of handling more advanced use cases. It gives enterprise teams the confidence to quickly push production changes by reducing error-prone, time-intensive and cumbersome manual or ad-hoc canary analysis.
KayentaはNetflixの革新的なカナリアシステムを完全にオープンで拡張可能で、より幅広いユースケースに対応可能なように再構築したものだ。これによって企業の開発チームは、エラーが発生しやすく時間がかかり、煩雑な手作業またはアドホックな分析作業を減らすことができ、変更したリリースを自信を持って迅速に本番環境へデプロイできるようになる。
Kayentaは、カナリアリリースと既存のリリースとをあらかじめ決められたメトリクスで比較し、スコアリングします。そして一定の値をスコアが下回った場合、そのカナリアリリースはロールバックされることになります。
KayentaとSpinnakerで、継続的デリバリにカナリアリリースを統合し自動化
Kayentaは、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker」と統合されています。このSpinnakerもNetflixがオープンソースとして公開し、その後Googleが開発に加わっているツールです。
- Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開
- Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」リリースを発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応
SpinnakerとKayentaを統合すると、Spinnakerの継続的デリバリのパイプラインに対して新たに「Canary」ステージが追加、Canaryステージの設定ページでスコア計算の基になるメトリクスなどを指定することができます。
つまりSpinnakerとKayentaによって、継続的デリバリのパイプラインに乗ってコードがビルドされ、テストされ、カナリアリリースのデプロイが実行され、問題があればロールバック、問題がなければ本番デプロイといった一連の作業が自動化されるのです。
カナリアリリースは既存の新規インスタンスと比較
典型的なカナリアリリースの方法は、既存の本番リリースに対してカナリアリリースを3インスタンス以上、そしてカナリアリリースの比較対象として既存のリリースとまったく同じリリースを同じく3インスタンス以上、それぞれを同時にデプロイする、というものです。
そしてカナリアリリースと比較対象となる既存リリースのメトリクス、例えばCPUやメモリの消費量、エラー発生率などを比較するわけです。
カナリアリリースの比較対象として既存のリリースと同じリリースをあらためてデプロイするのは、長期間実行されているリリースと新規にリリースされたカナリアリリースの比較では、実行初期時に引き起こされる振る舞いの違いの影響を排除できないためです。カナリアリリースの比較対象として正確を期すために既存リリースも同一タイミングで新規デプロイする必要があるのです。
下記はKayentaのスコアと結果表示画面です。測定時間が6分(もしくは6秒かもしれません)、スコアが85。あらかじめ設定しておいたスコアよりも下回ったため、このカナリアリリースは停止されました。
カナリアリリースから手動作業を排除、より迅速なリリースへ
Kayentaのようなカナリアリリースの自動分析ツールを用いない場合、カナリアリリースを評価するには人間がマニュアル操作でメトリクスを設定し、評価する必要がありました。
これはカナリアリリースをするたびにマニュアル操作が必要となり手間と時間がかかってしまうだけでなく、操作ミスや勘違いなどによる間違った判断などが行われる可能性がありました。
Kayentaによってカナリアリリースの分析を自動化し、それをSpinnakerによって継続的デリバリのパイプラインと統合することで、こうした課題を解決し、より迅速なリリースのデリバリが可能になります。
KayentaはGoogle Cloud Platform以外にKubernetes環境やオンプレミス、ほかのクラウドなどにも対応するとのことです。
関連記事
あわせて読みたい
IBMがメインフレームの筐体をデータセンターの19インチラックに合わせてきた。クラウド向けメインフレーム「IBM z14 Model ZR1」発表
≪前の記事
Ruby on Rails 5.2正式版発表。Active Storageによるクラウドストレージ対応、Redisでのキャッシュ対応など