コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第58回　カナリアリリース支援サービス「Canary Analysis Service」（パート1）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第58回　カナリアリリース支援サービス「Canary Analysis Service」（パート1） (中井悦司) 2019年5月

はじめに

　今回からは、2018年に公開されたエッセイ「Canary Analysis Service」を紹介します。多数のユーザーに提供するインターネット上のサービスでは、新機能をリリースする際に、一部のユーザーのみが利用できるようにして機能に問題がない事を確認する、「カナリアリリース」と呼ばれる手法が用いられます。Googleの社内には、カナリアリリースを支援するためのサービスが用意されており、社内のデファクトスタンダードとして多数のプロジェクトが利用しています。今回から数回に分けて、このカナリアリリース支援サービス「Canary Analysis Service（CAS）」を紹介していきます。

カナリアリリースの考慮点とCASの役割

　冒頭でも説明したように、新機能をリリースする際に、一部のユーザーのみにリリースして安全性を確かめるのがカナリアリリースの手法です。考え方はシンプルですが、実際には、さまざまな考慮点があります。たとえば、「一部のユーザー」はどのように選択すればよいのでしょうか？　機能の安全性を確認するという意味では、特定のタイプのユーザーだけにリリースするのではなく、さまざまなパターンで使ってもらえるよう、幅広いタイプのユーザーを選択する必要があります。
　あるいは、何をもって「安全」と判断するのか、というのも重要なポイントです。一定時間、何もエラーが発生しなければよいのでしょうか？　しかしながら、大規模なスケールアウト型のシステムでは、システムの一部でなんらかの問題が発生するのは想定内の出来事です。一部の障害でサービス全体が停止しないように設計されているわけですので、エラーの発生の有無だけで単純に判断することはできません。今回紹介するCASは、この点を支援するサービスです。既存のリリースとカナリアリリース、それぞれのモニタリング情報をもとにして、カナリアリリースが安全かどうかを自動的に判別する機能を提供しています。

ユーザーから見たCASのワークフロー

　図1は、CASのユーザー（アプリケーション開発者）から見たワークフローです。図の上半分は、ユーザー側で持っているデプロイメントの仕組みで、カナリアリリースの対象となるユーザーの選択や実際のデプロイ作業は、ユーザー側で行う必要があります。図の右上にある「canary」は、カナリアリリースを提供するサーバー、「control」は、既存の機能を提供するサーバーを表します。

fig01

図1 CASを利用する際のワークフロー（エッセイより抜粋）

　カナリアリリースのデプロイが終わると、ユーザーは、「canary」と「control」のそれぞれのモニタリング情報の取得先をCASに登録します。すると、CASは、指定のモニタリング情報を取得して、「canary」と「control」の稼働状況を比較した後に、このカナリアリリースが安全かどうかについて、「PASS（合格）」、もしくは、「FAIL（不合格）」という二択の答えを返します。言葉で書くとおどろくほど単純なサービスに思えますが、実施のところ、このシンプルさがCASの大きな特徴であり、Google社内で広く使われるようになった要因とも言えます。
　さきほど、「デプロイメントの仕組みはユーザー側で用意する」と書きましたが、Google社内には、標準のデプロイメントツールやモニタリングツールが用意されており、これらは、CASと連携するようになっています。つまり、アプリケーション開発者は、これらの標準ツールを使ってアプリケーションを設計・デプロイすれば、アプリケーション稼働状況に関するさまざまなログがモニタリングシステムに自動収集されて、CASは、そのログから判断に必要な情報を自動的に選び出してくれるというわけです。

CASのAPIデザイン

　CASを実際に利用する際のAPIも、とてもシンプルにできています。CASが提供するAPIは、「Evaluate」と「GetResult」の2種類です。「Evaluate」は、チェック対象のシステムをCASに登録するためのAPIです。CASは、社内標準のデプロイメントツールやモニタリングツールと連携するようになっているので、このAPIに対して、デプロイメントやモニタリングの設定情報を与えれば、「合格／不合格」の判断に必要な情報は、CASが自動的に判別します。そして、「GetResult」は、判断結果を取得するAPIです。このAPIをコールすると、モニタリング情報の分析が行われて、判断結果が帰ってきます。
　モニタリングの情報やその値に対する判断基準を細かく指定することもできますが、冒頭でも説明したように、ここはまさに、カナリアリリースの「肝」となる部分です。プロジェクトが個別に設定を考えるのではなく、さまざまなプロジェクトからのフィードバックをもとにして、CASの開発チームが「ベストプラクティス」を考えて、CASの標準機能として実装していくというのが基本的な考え方になります。

次回予告

　今回は、2018年に公開されたエッセイ「Canary Analysis Service」をもとにして、Google社内のカナリアリリース支援サービスである「Canary Analysis Service（CAS）」の概要を紹介しました。CASのユーザー（アプリケーション開発者）から見て、とてもシンプルに利用できる点を強調しましたが、裏を返すと、CASの内部では、さまざまな判断が高度に自動化されて実装されているということになります。次回は、CASの内部アーキテクチャーと、このような自動化の仕組みについて解説したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡