![[アップデート] AWS AppConfig に A/B テストやマルチバリエイト実験を実行できる「実験」機能が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-01e475488936f346bfb20fe16f208909/5ade12fa8d981ee9775c3c6eef7d7523/aws-appconfig?w=3840&fm=webp)
[アップデート] AWS AppConfig に A/B テストやマルチバリエイト実験を実行できる「実験」機能が追加されました
いわさです。
AWS AppConfig はアプリケーションの設定変更をコードデプロイなしに安全に行えるサービスで、フィーチャーフラグや動的な設定管理が可能です。
これまで AppConfig のフィーチャーフラグはオン/オフの切り替えやバリアント分岐に使われていましたが、「新しい UI を一部のユーザーにだけ見せて、購入率が上がるかどうかを比較する」といった A/B テストを行うには、トラフィック分割や統計的な結果分析の仕組みを別途用意する必要がありました。
先日のアップデートで、AWS AppConfig に実験機能が追加され、A/B テストやマルチバリエイトテスト（3 つ以上のパターンを同時に比較する実験）をマネージドに実行できるようになりました。
公式ドキュメントによると、コンソールからの実験セットアップ、柔軟なセグメンテーション、コントロール群とトリートメント群の統計分析などが提供されるとのこと。
AWS AppConfig experimentation offers the following features: Easy experiment setup and management through the AWS Management Console. Powerful and flexible segmentation options for experiment participants. Best-practices for data science analytics between control and treatment groups.
今回こちらを確認してみたので紹介します。
実際に確認してみる
まずはマネジメントコンソールで実験メニューが表示されるか確認してみました。
なお、アナウンスでは「all AWS Regions」と記載されていますが、本日時点では東京リージョンの AppConfig コンソールに「実験」メニューはまだ表示されていませんでした。
左メニューには「ダッシュボード」「アプリケーション」「拡張機能」「デプロイ戦略」のみで、「実験」の項目がありません。
一方、バージニア北部リージョンでは「実験」メニューが「新規」バッジ付きで表示されていることを確認できました。
今回はバージニア北部リージョンで検証してみます。一応アナウンスには全リージョンって書いてあったんですけどね。
「実験」メニューを開くと、実験の仕組みの概要が表示されます。
なお、画面下部には料金に関する注記があり、「AWS AppConfig の実験ツールは追加の有料呼び出しであり、実行されている実験の期間中は時間単位で課金されます」と記載されています。
料金は実験時間あたり $0.90 のようです。
追加料金が必要という点を気をつけましょう。
実験を作成してみる
では「実験を作成」ボタンから実験の作成フローを進めてみます。
実験の作成は 5 つのステップで構成されています。
仮説を文書化する
最初のステップでは実験名、仮説、リリース基準を記述します。
「Help me write a hypothesis and launch criteria」ボタンがあり、AI に仮説とリリース基準の文書化を支援してもらえるようです。
仮説には「何を検証したいのか」、リリース基準には「どうなったら勝者トリートメントを本番に反映するか」の条件を記述します。
また、この実験で使用する AppConfig アプリケーションをここで選択します。
AI 支援機能を触ってみたのですが、実体はコンソールに Amazon Q パネルが表示されるくらいでして、組み込みの支援機能ってほどではなさそうでした。たぶん。
ターゲットオーディエンスを指定
次に、実験の対象となるユーザー（オーディエンス）をルールで定義します。
ルールビルダーとエディタの 2 つのモードが用意されており、サンプルブループリントも複数提供されています。
サンプルブループリントには「ユーザー ID 別の許可リスト」「従業員フィルター」「ベータテスター専用トラフィックを 95% 対 5% で分割」「プレミアム階層の顧客」などよくありそうなテンプレートが揃っています。
今回は「ベータテスター専用トラフィックを 95% 対 5% で分割」のサンプルブループリントを選択してみました。
ルールビルダーで確認すると、$group が "BetaTesters" に等しいユーザーを対象に、$userId ベースで 5% のトラフィックを分割する設定になっています。
エディタモードに切り替えると、ルールの DSL 表現を確認できます。
(and
(eq $group "BetaTesters")
(split by::$userId pct::5 seed::"")
)
この split 式がトラフィック分割の肝で、$userId のハッシュ値に基づいて決定論的にユーザーを振り分けるようです。
pct::5 は対象トラフィックの 5% を実験に含めることを意味し、seed でハッシュのシード値を変更できるみたいですね。
なお、$group や $userId などの属性は AppConfig 側にユーザーデータベースがあるわけではなく、アプリケーション側が AppConfig Agent へのリクエスト時に Context ヘッダーで渡す仕組みになっています。
公式ドキュメントによると、以下のように Agent のローカルエンドポイントに対して HTTP ヘッダーでコンテキストを渡すみたいです。
The available attributes depend on your application and how data is passed to AWS AppConfig.
具体的には以下のように Agent にリクエストします。
curl http://localhost:2772/applications/MyApp/environments/Prod/configurations/MyFlags \
-H "Context: userId=user123" \
-H "Context: group=BetaTesters"
つまりアプリが「このユーザーは BetaTesters グループです」「userId は user123 です」と Agent に申告し、Agent がそのコンテキストを使ってルール評価 → トリートメント割り当てを行う流れです。
実験の実行には AppConfig Agent が必須で、通常の AWS CLI の設定取得 API ではコンテキストを渡せないためトリートメントの分岐が動作しません。
実験の機能フラグを選択
実験で使用する既存のフィーチャーフラグを選択します。
環境、設定プロファイル、機能フラグの 3 つを指定します。
今回は事前に作成済みのアプリケーション hoge0830app2 の設定プロファイル hoge0830flag2 にある aaa フラグを選択しました。
このフラグは 2024 年 8 月に作成したもので、現在の値は「オフ」です。
トリートメントを追加
実験のコントロール群と、1 つ以上のトリートメント群を定義します。
ここでいうトリートメントとは、実験対象のユーザーに提供する「処置」のことで、フラグの値を変えた別バージョンの体験を指します。
各トリートメントにフラグの値を設定し、トラフィックの配分比率を決めます。
コントロールはいわゆる「現状維持」のグループで、トリートメントが「新しい体験」を受けるグループです。
Amazon のベストプラクティスとして、コントロールグループは単に「それ以外の全員」ではなく、実験の一部として明示的に定義することが推奨されています。
今回はコントロール + トリートメント 2 つの計 3 群で構成したので、トラフィックは均等配分（33.33% ずつ）になっています。
詳細設定の「カスタム配分の重みを使用する」にチェックを入れると、任意の比率でトラフィックを配分できます。
ただし不均等にすると「統計的検出力を下げる」旨の警告が表示されるので、基本は均等配分が推奨のようです。
レビューして実験を作成
設定内容を確認して実験を作成すると、実験の詳細画面に遷移します。
「実験を定義する」「実験を実行する」のセクションがあり、「実験の実行を開始する」ボタンが表示されます。
実験の開始画面
「実験の実行を開始する」を押すと、実行の詳細設定画面が表示されます。
右側に実験の定義（アプリケーション、フラグキー、ターゲットオーディエンス、トリートメント配分）のサマリーが表示されます。
「環境内で実験実装をテスト」が推奨マークされており、「開始時に 0% のエクスポージャーで最初にテストする」チェックボックスがデフォルトでオンになっています。
0% で開始する場合、まだ誰にもトリートメントが配信されず、エンティティ ID を指定したオーバーライドでのみトリートメントをテストできるとのことです。
実データに影響を与えずに環境内でテストできるので、いきなり本番トラフィックに影響を与えない安全な仕組みになっています。
今回は AppConfig Agent 側までは用意していないので検証はここまでとしています。
さいごに
本日は AWS AppConfig に A/B テストやマルチバリエイトテストをマネージドに実行できる実験機能が追加されたので確認してみました。
以前は CloudWatch Evidently という A/B テストのための機能があったのですが現在は廃止されています。今回のアップデートで AppConfig を使うことでその替わりというか、A/B テストを行いやすくなったかもしれないですね。
また、改めて今回思ったのですが、AppConfig は導入の段階でコンテキスト情報をアプリ側から正しく渡すなどベストプラクティスの準拠が必要そうです。普段から意識して実装しないとなぁと思いました。
そのあたりをしっかりやれていれば、今回のような拡張機能の利用はしやすそうだなとおもいました。
