コラム

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

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

CTC 教育サービス

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

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

はじめに

　前回に引き続き、2018年に公開されたエッセイ「Canary Analysis Service」を元にして、Google社内で活用されているカナリアリリース支援サービス「Canary Analysis Service（CAS）」を紹介します。
　前回は特に、ユーザー（アプリケーション開発者）視点でのCASの利用方法を説明しました。ユーザーがモニタリング情報の取得先を登録すると、具体的なモニタリングの項目やカナリアリリースが安全であることの判定基準は、CASが自動判別する仕組みになっています。今回は、このような自動化を実現する、CASの内部アーキテクチャーを紹介します。

CASの内部アーキテクチャー

　CASを構成する内部コンポーネントは、図1のようになります。

fig01

図1 CASの内部コンポーネント（エッセイより抜粋）

　前回説明したように、Google社内のデプロイメントツール（図の「roolout tool」）はCASと連携するようになっており、アプリケーションがデプロイされたタイミングで、CASのAPIを用いてモニタリング情報を登録します。図1で言うと、APIサーバー（図の「RPC front end」）を経由して、データベース（spanner）に情報を登録する流れになります。その後は、「coordinator」が評価処理のプロセスを進めていきます。
　coordinatorは、はじめに、「config server」からアプリケーションに対応した評価項目を取得して、低レベルの評価処理（個別項目のチェック）を「evaluator」に依頼します。ここで実施するチェック内容は単純で、エッセイの中では次のような例があげられています。

・カナリアリリースのクラッシュ率は、既存リリースのクラッシュ率より著しく高くないか
・RPCエラーの発生率は、既存リリースより著しく高くないか
・メモリー上に読み込まれたデータセットのサイズは、同等かどうか

　evaluatorは、評価項目ごとに、事前に定義された統計関数を用いて、「著しく高くないか」といった判定を行い、その結果をcoordinatorに返します。これらの情報が集まると、coordinatorは、「model server」に対して、「これらの判定結果は予想範囲内のできごとなのか」という問い合わせを行います。ここが、CASのユニークな仕組みになります。
　仮に、evaluatorの評価結果が「FAIL（不合格）」だったとしても、該当アプリケーションの過去の動作実績（新機能のリリースにともなう動作の変動など）を踏まえると、カナリアリリースの動作は、必ずしも異常とは言えない場合があります。model serverは、該当アプリケーションの過去の動作状況に基づいて、このようなハイレベルな判断を行います。最終的に、model serverによっても除外されないような異常が残った場合、coordinatorは、このカナリアリリースに対して、「FAIL（不合格）」という判定を行います。

model serverの学習プロセス

　前述の処理を実現するために、model serverは、それぞれのアプリケーションの過去の動作状況を学習します。たとえば、カナリアリリースによって大幅な機能変更が行われると、アプリケーション開発者から見ると想定内の変化でも、model serverは、それを「予想範囲内のできごと」と認識できず、CASの最終判定が「FAIL」になることがあります。このような場合、アプリケーション開発者は、CASの判定結果を無視してカナリアリリースを正式にリリースしますが、model serverは、このような状況を学習して次回からの判定に反映します。
　このような学習プロセスは、アプリケーション開発者がCASの判定結果を（基本的には）信頼しているという前提が重要になります。仮に、アプリケーション開発者がCASの判定を何も考えずに無視してリリースし続けた場合、本来は異常と判定すべき状況が異常とは認識されなくなってしまいます。CASが出した「FAIL」という判定をアプリケーション開発者が精査して、「本当に無視しても構わない」と断言できる時に限って、CASの結果を無視してリリースする必要があります。
　つまり、CASの判定精度を高めることと、ユーザーからの信頼を得ることは、相互に深く関連しています。これは、CASに限らず、モニタリングツール、あるいは、自動化ツール一般に当てはまるポイントと言えるでしょう。

次回予告

　今回は、2018年に公開されたエッセイ「Canary Analysis Service」をもとにして、Google社内のカナリアリリース支援サービスである「Canary Analysis Service（CAS）」の内部アーキテクチャーを紹介しました。model serverは、それぞれのアプリケーションの過去の動作状況を学習すると説明しましたが、実は、model serverは、バイナリーファイル単位で個々のアプリケーションの情報をトラッキングしています。つまり、新しくデプロイされたバイナリーファイルが、過去のどのバイナリーファイルの新規バージョンに当たるかがきちんと認識されているのです。これは、社内標準のビルドツールをCASとインテグレーションすることで実現されています。プロジェクト個別のツールの利用を避けて、社内標準ツールを広く活用するメリットがここにも現れていると言えるでしょう。
　次回は、IT業界の永遠のテーマ（？）とも言える、「ソフトウェアエンジニアの生産性」に関する話題をお届けする予定です。

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