分析のポイント（1）最適なメトリクスの選択
分析のプロセスは、メトリクスの種類を選択するところから始まります。このプロセスは非常に大切です。普段のモニタリングで使用している全てのメトリクスを使えば良いのでしょうか？
メトリクス数が少なければ問題ないかもしれませんが、多すぎるとデプロイの度に偽陽性が生じ、デプロイプロセスから円滑さが失われることになるでしょう。
では、どのようなメトリクスをカナリア評価に使うべきなのでしょうか。最初に選択するメトリクスは、実際にエンドユーザーに見える問題を示すものであるべきです。
あなたのチームがSLI（Service Level Indicator）を明確に定めているのであれば、それを計測するためのメトリクスを真っ先に採用するべきです。迷ったら、『Site Reliability Engineering』で定義されている「The Four Golden Signals」のうちの以下の3つを選択することをおすすめします。
- Latency：レスポンスを返すまでにかかる時間
- Errors：失敗したリクエストの割合
- Saturation：システムが処理できないリクエストを抱えている度合い
焦りは禁物です。優れたメトリクス選択のために、段階的にクエリを追加していくことをおすすめします。
分析のポイント（2）最適な閾値の選択
メトリクスを選択したら、今度は閾値をどのように決めるかを考える必要があります。
どんなに良いメトリクス選択をしても、デプロイを失敗させる基準の設定を誤るとたちまち偽陽性や偽陰性が生じてしまいます。
継続的デリバリーをSaaSとして提供しているHarness社は、既存ソリューションを面白い観点で2つに分けています。どのように閾値を決定するかという観点でStatic RulesとDynamic Dataという表現をしており、これが説明の上で役立つので本記事でも拝借します。
Static Rulesとは、システムオーナー自身が閾値を静的に定義する方法です。
例えばシステムオーナーが失敗条件を「HTTPエラーレートが1％未満」と定義した場合、条件を変えない限り全てのデプロイをそのルールに従って分析します。これは非常にシンプルな手法であるため、分析自体を容易にコントロールできます。
プログレッシブデリバリーを始めて間もない時期は、Static Rulesに基づいた分析で十分であると思います。メトリクスの種類も少ないでしょうし、SLIに基づいた適切な閾値設定がされていれば、限りなく理想的な分析が行えるでしょう。
ただ、アプリケーションは時間の経過とともに進化します。静的に閾値を定義するという柔軟性に欠けた方法では、いずれ閾値自体の設定に疲弊してしまうことにもなりかねません。そういったケースでは、Dynamic Dataに基づいた閾値の決定が有効です。これは、CDシステム側で動的にデータを取得しながら閾値を判断していく手法です。
それぞれの特徴をまとめると次のようになります。
Static Rules
メリット
- シンプルで、トラブルシュートが容易
- 自由度が高い
デメリット
- アプリケーションの状態は常に変わっていくのでスケールしない場合がある
Dynamic Data
メリット
- 最適な閾値を模索するコストが減る
- アプリケーションの状態に応じてスケール可能
デメリット
- メトリクスの分析処理がブラックボックス化され、内部動作が分かりづらい
次からは、プログレッシブデリバリーを行うための既存ソリューションを、Static RulesとDynamic Dataに分けて紹介していきます。
