【新機能】 Amazon API Gateway が Canary Release Deployments (新しいバージョンへの部分的な振り分け) に対応しました #reinvent

2017.11.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2017年11月28日、 API Gateway に新しい機能が追加されました。Canary Release Deployments です。つまり、一部の先行ユーザーにだけ、新しいAPIへ振り分ける機能、ということになります。東京リージョンで利用可能です。

さっそく試してみましょう。まずは画面から見ていきます。

Canary 設定をみる

まずは設定項目を眺めてみることにします。APIを用意しましょう。API を定義してデプロイし、「ステージ」メニューへ行きます。そこで、「Canary」タブが追加されていることが確認できると思います。

canary_tab.png

Create Canary ボタンを押してみましょう。入力項目が展開されます。

canary_input.png

項目と説明を見る限り、以下の内容が設定できそうです。

Stage's Request Distribution

現行版と、新しいAPIの重み付けを行います。合計100%になるように、二者間でパーセンテージを調整できます。

Canary Deployment

現行バージョンの情報が記載されているようです。

Canary State Variables

現行バージョンのステージ変数に対して上書き・追加ができます。新しいバージョンでステージ変数を変えたい場合などに有用です。

Canary 設定を入力する

今回実際に試すAPIは、以下のように、APIがコールされたら DynamoDB へ Query を発行し、結果をクライアントに返す構成とします。

arch.png

この構成は以下の記事で実装したものです。

そして、現行バージョンと Canary バージョンには以下のような違いを持たせています:

  • 現行: DynamoDB Query で 候補者ID のみ指定する
  • Canary: DynamoDB Query で 候補者IDと投票日 を指定する

次の図はリクエストマッピングテンプレートで見たときに追加した部分です:

mapping_template_after.png

リクエストパスは次です:

  • /candidates/MI12341011/votes?date=2017-11-11T22:00:12+09:00

DynamoDB には次のようなデータを保存しています:

候補者ID (パーティションキー) 投票受付日 (ソートキー) 投票ポイント 現行版で返る Canary版で返る
MI12341011 2017-11-10T12:00:12+09:00 345.11
MI12341011 2017-11-11T22:00:12+09:00 102.34
MI12341011 2017-11-12T09:12:45+09:00 344.11
SU40120055 2017-11-10T12:14:44+09:00 345.11

以上より、リクエストに対して、複数の結果が返ってきたら現行バージョン が、 ソートキーも指定することでひとつだけ結果が返ってきたら Canary バージョン がコールされたことになります。では、Canary バージョンをデプロイしましょう。

Canary デプロイ

実は先程、設定内容を見るために「Canaryを作成」した段階で Canary 機能が有効になっています。有効になっている状態で、いつもどおり API をデプロイしようとすると、

canary_deploy.png

ステージ名に「Canary が有効」とつきます。まずはここにデプロイしてOKです。Canaryの重みは現在0%にしているので、新しいAPIにリクエストが割り振られることはありません。デプロイしたら、リクエストを投げてみます。

postman_before.png

何度リクエストを送っても、複数の結果が返ってきます。すなわちソートキー指定機能が入っておらず、パーティションキーのみで Query が走っているからだ、とわかります。では、重みを変更してみましょう。

deploy_canary.png

何度かリクエストを送ってみます…

request_canary.png

要素数1のレスポンスが返ってきました。これは、新しいバージョンのAPIが適用されており、クエリパラメータが展開され DynamoDB Query のソートキーに指定されているからだ、ということが言えます。繰り返し試しましたが、たしかに体感重みづけた割合の通りの振り分け率になっていそうです。ステージ v1 には、現行バージョンと Canary バージョンが同時に存在していることがわかりました。

Canary バージョンに問題がなさそうだとわかったので、昇格させましょう。

canary_up.png

実行すると、Canary: 100%, v1: 0% となりました。すべてのリクエストが Canary へ振り分けられることになります。

CloudWatch メトリクスでも 区別できる

CloudWatch も見ておきましょう。Canary にリクエストが振り分けられた場合、以下のようなステージ名になり、メトリクスを現行バージョンと明確に区別することが可能です。新しく振り分けた Canary でエラーが発生していないかどうか確認できるので、とても便利ですね!

cloudwatch.png

まとめ

API Gateway に新しく追加された Canary Release Deployments を試しました。これまでは、本番ステージへ適用する前にテストステージなどで十分に確認したあと、100%置き換えることしかできませんでした。 Canary がサポートされたことによって一部のリクエストのみ振り分けられるようになった上、その結果を CloudWatch で確認することが可能になりました。A/B テストができるようになりましたので、素早いデプロイと効果測定が必要になるモバイル領域で活躍してくれそうですね。