Google Cloud Platform

Kayenta : Google と Netflix が共同開発したオープンソースの自動カナリア分析ツール

どのような規模であれ、継続的デリバリを行うには、ソフトウェア変更を迅速にリリースできるだけでなく、安全にリリースできるようにする必要があります。Google と Netflix が先ごろ発表した、オープンソースの自動カナリア分析サービスである Kayenta は、本番環境デプロイの迅速なロールアウトに伴うリスクを軽減します。

Kayenta は Google と Netflix によって共同開発されました。Netflix の社内カナリア システムを進化させ、完全にオープン、拡張可能で、高度なユース ケースに対応できるようにしたものです。Kayenta によって企業のチームは、エラーが起こりやすく時間もかかる面倒な手動またはアドホックのカナリア分析を減らし、自信を持って、変更を本番環境に迅速にプッシュできるようになります。

Kayenta は、オープンソースのマルチクラウド継続的デリバリ プラットフォームである Spinnaker とインテグレートされています。

これにより、チームは Spinnaker パイプラインに自動カナリア分析ステージを簡単にセットアップできます。Kayenta は、ユーザーが構成した指標をソースからフェッチし、統計テストを実行して、スコアを集計します。このスコアとあらかじめ設定された基準に基づいて、自動的にテスト結果を “成功” または “失敗” と判定するか、あるいは人間による承認プロセスをトリガーします。

自動カナリア分析は Netflix の本番デプロイ プロセスに不可欠な要素であり、私たちは Kayenta をリリースできたことをうれしく思っています。Kayenta に関する私たちと Google のパートナーシップは、アプリケーション、構成、データ変更など幅広いシナリオにおいて自動カナリア分析を実行するのに役立つ柔軟なアーキテクチャを生み出しました。Spinnaker と Kayenta のインテグレーションのおかげで、チームはカナリア分析のためにツールを切り替えることなく、パイプラインに沿って一貫したプロセスでデプロイを行えます。2018 年末までに、Kayenta はカナリア分析の判定を 1 日に数千回行うようになるでしょう。Spinnaker と Kayenta は高速で信頼性が高く、使いやすいツールであり、リスクを最小限に抑えながら迅速で大規模なデプロイを可能にします。Greg Burrell 氏、Netflix のシニア リライアビリティ エンジニア(Netflix のブログ記事で詳しくご覧になれます)

Kayenta によるカナリア分析の最終結果(要約)は次のようになります。

image3iaq6.max-700x700.png
Spinnaker のデプロイ パイプラインでカナリア分析を行えば、デプロイの失敗を自動的に特定できます。ただし、本番環境で 1,000 以上のパイプラインが実行されていると、カナリア分析の一環として人間が何らかの形で介在した場合、継続的デリバリに大きな支障が出てしまいます。Kayenta によって実現されるような自動カナリア デプロイを利用して、私たちのチームは早期に異常を発見し、開発をスピードアップしてきました。さらに Kayenta はオープンソースであるため、このツールで標準化することはベンダー ロックインのリスク軽減にもつながります。私たちは Google および Netflix と密接に協力し、開発サイクルへの Kayenta の統合を推し進めるとともに、自社で開発した Jenkins ジョブのカナリア プロセスをなくすことを楽しみにしています。Tom Feiner 氏、Waze のシステム オペレーション エンジニア

大規模な継続的デリバリの課題

カナリア分析は、エンドユーザーが使用する本番環境に新しい変更を適用する際のリスクを軽減するための良い方法です。

カナリア分析の基本的な考え方は、本番トラフィックのごく一部(たとえば 1 %)を、変更を反映したインスタンス(カナリア)と、本番環境と同じコードおよび構成で新たにデプロイしたインスタンス(ベースライン)に通すというものです。本番インスタンスには一切変更を加えません。

通常、ベースラインおよびカナリアとしてそれぞれ 3 つのインスタンスが作成され、本番環境には多数のインスタンスがあります。新しいベースラインの作成は、スタートアップ効果を最小化し、ベースラインとカナリアのシステム差異を抑制するのに役立ちます。

システムは、システム オーナーが選んだ主要なパフォーマンス指標および機能指標を、カナリアとベースラインで比較します。変更のデプロイを継続するには、カナリアが発揮するパフォーマンスと機能がベースラインと同等以上でなければなりません。

image2su4l.max-700x700.png

多くの場合、カナリア分析は手動またはアドホックな方法で、もしくは統計的に不正確な方法で行われます。たとえば、チーム メンバーが、カナリアと本番環境のさまざまな指標(CPU 使用量、メモリ使用量、エラー率、リクエストあたりの CPU 使用量など)を示すログやグラフを手動で調べ、提案された変更の扱いを決めるといった具合です。しかし、手動やアドホックのカナリア分析は以下の問題を引き起こすことがあります。

  • スピードやスケーラビリティのボトルネック : Google や Netflix のように、巨大な規模の本番環境を運用し、1 日に多数のデプロイについて多くの比較を行う組織では、手動のカナリア分析は現実的な選択肢ではありません。他の組織でも、手動のカナリア分析アプローチを採用すると、継続的デリバリのスピードや短いデリバリ サイクルについていけません。カナリア リリースごとにダッシュボードを構成することはかなりの手間であり、カナリアとベースラインで数百もの指標を手動で比較するのは面倒で大変な作業です。
  • 人的エラーの原因 : 手動のカナリア分析では主観評価が必要になり、人的バイアスや人的エラーが発生しやすくなります。本当の問題とノイズを区別することは容易ではありません。人間はしばしば、指標やログの解釈やカナリアの成功または失敗の判定を行う際にミスを犯します。しかも、人間の判断に起因するエラーが発生しうるだけでなく、カナリア分析のために多数の指標を手動で収集、モニタリングして集計することも、エラーの原因になりえます。
  • 誤った分析のリスク : 新しくデプロイしたインスタンスの短期間の指標と、長期間稼働している本番インスタンスの指標を、手動で、あるいはアドホックに比較することは、カナリアの健全性を見極める方法として正しくありません。カナリアに見られるパフォーマンスの差が統計的に意味のあるものか、ランダムなものにすぎないかを見分けることは難しい、というのがその理由です。判断を誤ると、デプロイの失敗の原因となった変更を本番環境にプッシュしてしまうおそれもあります。
  • 高度なユース ケースの貧弱なサポート : 継続的デリバリのサイクルをカナリア分析によって最適化するには、カナリアの成功または失敗の判定に対する高い信頼が必要になります。しかし、手動やアドホックなプロセスによる変更の可否の判定について信頼を得るには膨大な時間がかかります。その主な理由は、手動またはアドホックのカナリア分析では、リアルタイムでの境界やパラメータの調整といった高度なユース ケースを扱えないことにあります。

Kayenta のアプローチ

手動やアドホックの分析とは異なり、Kayenta は、ユーザーが指定した指標について自動的に統計テストを行い、集計スコア(成功、中間、失敗)を返します。この厳密な分析は、変更のロールアウトまたはロールバックを的確に判断したり、従来のカナリア分析では見過ごされてきたデプロイの失敗を特定したりするのに役立ちます。また、Kayenta は以下のメリットも提供します。

  • オープン : 企業が自動カナリア分析を商用製品で行いたい場合は、機密の指標をプロバイダーに提供しなければなりません。これはベンダー ロックインを招いてしまいます。
  • ハイブリッドおよびマルチクラウドに対応 : Kayenta は、ターゲットの環境がどのようなものであれ、一貫した方法でカナリアの問題を検出します。また、Kayenta と Spinnaker のインテグレーションにより、企業のチームは複数の環境を対象に自動カナリア分析を行えます。その中には、Google Cloud Platform(GCP)、Kubernetes、オンプレミス サーバー、他のクラウド サービスが含まれます。
  • 拡張可能 : Kayenta では、新しい指標のソース、ジャッジ(判定機能)、データ ストアを簡単に追加できます。そのおかげで、ニーズの変化に応じて、さまざまな環境向けに構成できます。
  • 迅速かつ的確 : Kayenta では、自動カナリア分析の実行中に境界やパラメータを調整できます。そのため、十分なデータを集めたら、直ちにカナリア分析を実行し、変更を適用すべきかどうかを判断できます。
  • 低いオーバーヘッド : Kayenta は簡単に使用できます。カスタム スクリプトを作成する必要はありません。カナリアの指標のフェッチ、それらのマージ、統計分析についても手動で行うことなく、変更をデプロイするか、ロールバックするかを判断できます。また、掘り下げた診断に役立つように、カナリア分析の結果内でディープ リンクを提供します。
  • 洞察 : 高度なユース ケースのために、Kayenta はレトロスペクティブ カナリア分析も支援します。この分析により、エンジニアリング チームやオペレーション チームは、カナリア分析を時間とともにどのように洗練させ、改良していくかについて洞察を得ることができます。

Spinnaker とのインテグレーション

image1zxv7.max-700x700.png

Kayenta と Spinnaker のインテグレーションに伴い、Spinnaker には新しい “カナリア” パイプライン ステージが追加されました。このステージでは、どのソースのどの指標をチェックするかを指定できます。ソースには、Stackdriver、Prometheus、Datadog、Atlas(Netflix の社内ツール)といったモニタリング ツールが含まれます。

次に、Kayenta はソースから指標データをフェッチし、制御/実験のための時系列データセットのペアを作成して、Canary Judge(カナリア ジャッジ)を呼び出します。Canary Judge では、統計テストを実行し、各指標を個別に評価して、あらかじめ構成された指標の重み付けに従って 0 ~ 100 の集計スコアを返します。

スコアは、ユーザーの構成に応じて、“成功”、“中間”、“失敗” に分類されます。成功の場合はカナリアが格上げされ、変更のデプロイが続行されます。中間の場合は人間による承認プロセスがトリガーされ、失敗の場合はロール バックがトリガーされます。

ぜひお試しを!

Kayenta を使うことで、オープンかつ自動化された方法でカナリア分析を行い、自信を持って変更を本番環境に迅速にデプロイできるようになります。

私たちの目標は、オープンソースの Kayenta を通じて、指標のストアとジャッジがオープンソース コミュニティとプロプライエタリ システムの両方によって提供されるコミュニティを構築することです。Kayenta の詳細を知る方法と、Kayenta プロジェクトに貢献する方法については以下のとおりです。


ご参加をお待ちしています。

* この投稿は米国時間 4 月 10 日、Product Marketing Manager の Nikhil Kaul と、Product Manager の Andrew Phillips によって投稿されたもの(投稿はこちら)の抄訳です。

- By Nikhil Kaul, Product Marketing Manager & Andrew Phillips, Product Manager