トラフィックの少ないマイクロサービス型システムにおける複数A/Bテストの干渉回避技術の検討/multiple ab testing on microservices

Web System Architecture研究会 #8
---

要旨

マイクロサービスアーキテクチャ型システム内で複数チームが同時にA/Bテストを行うと結果が干渉しうる。しかし、システム内で同時に実行できるA/Bテストを一つに限定すると評価までの時間が長大化する他、交互作用を評価できなくなる。

複数のA/Bテストを同時に行う方法には多変量テストが挙げられるが、多変量テストは多数のテストケースでサンプルを収集する必要があるため、トラフィックの少ないシステムには適用できなかった。

本研究はシステムの接続情報およびA/Bテストの属性情報から交互作用の強いA/Bテストのサブセットを検出し、サブセットごとに多変量テストを適用することで必要なテストケースの数を削減し、トラフィックの少ないシステムにも適用できうるマイクロサービス向けA/Bテスト手法を提案する。

Transcript

1. © Hitachi, Ltd. 2021. All rights reserved. トラフィックの少ないマイクロサービス型システムにおける 複数A/Bテストの干渉回避技術の検討 Web System Architecture研究会 #8 株式会社 日立製作所 研究開発グループ 井出 貴也
2. © Hitachi, Ltd. 2021. All rights reserved. 要旨 マイクロサービスアーキテクチャ型システム内で複数チームが同時にA/Bテストを行うと結果 が干渉しうる。しかし、システム内で同時に実行できるA/Bテストを一つに限定すると評価 までの時間が長大化する他、交互作用を評価できなくなる。 複数のA/Bテストを同時に行う方法には多変量テストが挙げられるが、多変量テストは多 数のテストケースでサンプルを収集する必要があるため、トラフィックの少ないシステムには 適用できなかった。 本研究はシステムの接続情報およびA/Bテストの属性情報から交互作用の強いA/Bテス トのサブセットを検出し、サブセットごとに多変量テストを適用することで必要なテストケース の数を削減し、トラフィックの少ないシステムにも適用できうるマイクロサービス向けA/Bテス ト手法を提案する。 1
3. © Hitachi, Ltd. 2021. All rights reserved. 2 1. 背景 2. 既存技術 3. 提案方式 4. 評価案 5. まとめ 目次
4. © Hitachi, Ltd. 2021. All rights reserved. 背景 3
5. © Hitachi, Ltd. 2021. All rights reserved. A/Bテスト ▪ 複数パターンのシステムを無作為にユーザへ公開し、反応を比較するテスト ▪ 施策の良否を評価し、プロダクトの改善に活かす 4 Original (青色ボタン) クリック率 10% Buy Variation 1 (赤色ボタン) クリック率 15% ユーザ Buy
6. © Hitachi, Ltd. 2021. All rights reserved. マイクロサービスアーキテクチャ ▪ 複数の小さなサービスを連携させてシステムを構成する設計方式 ▪ サービスごとに小さなチームが存在し、自律的に開発・運用 5 マイクロサービスアーキテクチャ型のシステム (以降マイクロサービスと呼称) 決済管理 サービスチーム 発注 サービスチーム 開発・運用 UI 決済 管理 商品 管理 商品 推薦 プッシュ 通知 ユーザ 管理 発注 開発・運用
7. © Hitachi, Ltd. 2021. All rights reserved. マイクロサービスにてA/Bテストを行う際の問題 ▪ マイクロサービス上の複数チームが同じタイミングでA/Bテストを実施すると、 テストの内容によっては互いの結果が干渉 ▪ 一方、同時に実行できるA/Bテストを一つに絞るとシステム改善サイクルが鈍化 ▪ また、複数同時テストによる交互作用（相乗効果）も評価したい ◇ 例. 黒背景のA/Bテスト + 黒文字のA/Bテスト → 同時に適用すると読めない 6 ユーザ UI Original Variant 決済管理 Original Variant 商品管理 Original Variant 黒背景 適用 黒文字 適用 商品推薦 Original Variant Buy 干渉 干渉 干渉 交互作用 見落とし
8. © Hitachi, Ltd. 2021. All rights reserved. 既存方式 7
9. © Hitachi, Ltd. 2021. All rights reserved. Overlapping Experiment Infrastructure [TAB10] 以下ルールに基づきサンプルを収集することで複数同時のA/Bテストを実現 ▪ 同時に実行できないA/Bテストをサブセットに分け、サブセットごとにトラフィックを分割 ▪ ユーザID+サービスIDのハッシュ値でユーザをOri・Varどちらに割振るか決定 → サービス間で割振りが直交1 8 直交 : 各A/Bテストのユーザ割振のパターンを均一にする。数値化したCookieをSvcごとに異なる除数で剰余を取った値で振り分けることで実現 ユーザ Svc1 Svc2 Original Variant Ori Var Svc1 Svc2 Ori Ori Svc3 Svc4 Ori Var Ori Var Svc3 Svc4 Ori Ori サブセット トラフィック を分割 割振りを直交
10. © Hitachi, Ltd. 2021. All rights reserved. ユーザ Svc1 Svc2 Original Variant Ori Var Svc1 Svc2 Ori Ori Svc3 Svc4 Ori Var Ori Var Svc3 Svc4 Ori Ori サブセット トラフィック を分割 割振りを直交 Overlapping Experiment Infrastructure [TAB10] 以下ルールに基づきサンプルを収集することで複数同時のA/Bテストを実現 ▪ 同時に実行できないA/Bテストをサブセットに分け、サブセットごとにトラフィックを分割 ▪ ユーザID+サービスIDのハッシュ値でユーザをOri・Varどちらに割振るか決定 → サービス間で割振りが直交1 9 直交 : 各A/Bテストのユーザ割振のパターンを均一にする。数値化したCookieをSvcごとに異なる除数で剰余を取った値で振り分けることで実現 <問題> ▪ 交互作用の影響を測定できない ▪ 組合せによってはA/Bテストの結果と他テストの交互作用の効果が混ざりうる
11. © Hitachi, Ltd. 2021. All rights reserved. 多変量テスト (完全実施要因計画) 同時に実行されるA/Bテストの全組合せ パターンをテストする ▪ Svc1~4が2値のA/Bテストを同時に行う 場合は16通りのテストケースを作成(右表) ▪ テストケースごとにトラフィックを振り分け、 サンプルを収集 ▪ 分散分析にて各A/Bテストの効果と 交互作用を算出 10 # Svc 1 Svc 2 Svc 3 Svc 4 1 Original O O O 2 O O O V 3 O O V O 4 O O V V 5 O V O O 6 O V O V 7 O V V O 8 O V V V 9 Variant O O O 10 V O O V 11 V O V O 12 V O V V 13 V V O O 14 V V O V 15 V V V O 16 V V V V
12. © Hitachi, Ltd. 2021. All rights reserved. 多変量テスト (完全実施要因計画) 同時に実行されるA/Bテストの全組合せ パターンをテストする ▪ Svc1~4が2値のA/Bテストを同時に行う 場合は16通りのテストケースを作成(右表) ▪ テストケースごとにトラフィックを振り分け、 サンプルを収集 ▪ 分散分析にて各A/Bテストの効果と 交互作用を算出 11 # Svc 1 Svc 2 Svc 3 Svc 4 1 Original O O O 2 O O O V 3 O O V O 4 O O V V 5 O V O O 6 O V O V 7 O V V O 8 O V V V 9 Variant O O O 10 V O O V 11 V O V O 12 V O V V 13 V V O O 14 V V O V 15 V V V O 16 V V V V <問題> ▪ 同時に実行されるテストが多くなるとテストケースが爆発。各テストケースに割り振れる トラフィックが減少し、ユーザ数が少ないサービスは結果算出に時間を要する
13. © Hitachi, Ltd. 2021. All rights reserved. 一部実施要因計画 多少の交互効果の影響を許容し、多変量テ ストのうち一部の組合せのみテストケースとする ▪ テストケースを削減できるため、トラフィック を集中でき、テスト時間の短縮に寄与 ▪ テストケースとなる組合せは、直交表や ラテン方格実験、ランダムなどで抽出 12 # Svc 1 Svc 2 Svc 3 Svc 4 1 Original O O O 2 O O O V 3 O V V O 4 O V V V 5 V O V O 6 V O V V 7 V V O O 8 V V O V 4種のA/BテストにL8直交表を適用 (テストケースが16→8に減少)
14. © Hitachi, Ltd. 2021. All rights reserved. 一部実施要因計画 多少の交互効果の影響を許容し、多変量テ ストのうち一部の組合せのみテストケースとする ▪ テストケースを削減できるため、トラフィック を集中でき、テスト時間の短縮に寄与 ▪ テストケースとなる組合せは、直交表や ラテン方格実験、ランダムなどで抽出 13 # Svc 1 Svc 2 Svc 3 Svc 4 1 Original O O O 2 O O O V 3 O V V O 4 O V V V 5 V O V O 6 V O V V 7 V V O O 8 V V O V 4種のA/BテストにL8直交表を適用 (テストケースが16→8に減少) <問題> ▪ 抽出した組合せによってはA/Bテストの結果に交互作用が影響する ▪ 複数チームが連携してテスト計画を立案する必要があり自律性が損なわれる ▪ テストケースごとに収集するサンプルが異なり、トラフィック制御が複雑化
15. © Hitachi, Ltd. 2021. All rights reserved. 研究の目的 目的 ▪ マイクロサービス上にて各チームが自律的にA/Bテストを実行可能な方式の開発 要件 1. 他A/Bテストの影響を受けず、各チームが独立してA/Bテストの結果を評価できる 2. 個々のA/Bテストに長大な時間を要しない（開発サイクルを阻害しない） 3. 関連するA/Bテスト間では、その交互作用も評価できる 既存技術の単純な適用では要件を満たさない。 マイクロサービスの前提を置くことで、TAB10と多変量テストを上手く組合せられないか 14
16. © Hitachi, Ltd. 2021. All rights reserved. 提案方式 15
17. © Hitachi, Ltd. 2021. All rights reserved. アプローチ ▪ 交互作用が強い群をサブセット化し、ピンポイントに多変量テストを適用 ▪ それ以外はユーザトラフィックを直交させ、互いの影響を排除 ▪ 交互作用の強い群はマイクロサービスやA/Bテストの属性情報を用いて判別 16 サブセット トラフィックを 直交させること でサブセット外 の影響を排除 Svc2から見て 交互作用の強い テストをサブセット化 o v o v Svc4 Svc1 Svc2 Svc3 o v o v Svc5 Svc2を多変量テストで評価するには、 少なくとも24=16通りのテストケースが必要 o v o v Svc4 Svc1 Svc2 Svc3 o v o v Svc5 22=4通りのテストケースで Svc2の多変量テストが可能
18. © Hitachi, Ltd. 2021. All rights reserved. アプローチの前提となる仮説 仮説1：複数テスト間で直交に振り分けられたユーザトラフィックは数が多ければ 多変量テストのサンプルとして利用できる ▪ 多変量テストの各テストケースは分配される確率が同じ→大数の法則 ▪ これにより、ハッシュ値で割り振ったトラフィックを多変量テストのサンプルに利用できる 仮説2：交互作用の大小はマイクロサービスの構成やA/Bテストの種別に依存 ▪ 例. 通信を行っていないサービスとはレイテンシの交互作用が発生しえない ▪ 属性情報から干渉するテストの種別およびその影響範囲を算出できないか 17
19. © Hitachi, Ltd. 2021. All rights reserved. 処理の流れ 1. マイクロサービス開発者がA/Bテスト実行時に属性情報を入力 2. 入力された情報およびマイクロサービス間の接続関係から テストごとに1干渉するテストを検出し、サブセット化 3. 各A/BテストのOri・Varにはハッシュ値でトラフィックを振分け（=直交させる） 4. サブセット内のトラフィックの流れは分散トレースのログなどを用いて 多変量テストのテストケースごとに結果と紐付けてカウント 5. サブセット内のテストケースが統計的に十分なサンプルサイズになればテスト終了 18 1. 視点となるテストごとにサブセットが作られる。例えば、Svc1は[Svc1, Svc2, Svc3]のサブセットを作り、Svc2は[Svc1, Svc3]のサブセットを作るなどがある
20. © Hitachi, Ltd. 2021. All rights reserved. 処理の流れ 1. マイクロサービス開発者がA/Bテスト実行時に属性情報を入力 2. 入力された情報およびマイクロサービス間の接続関係から テストごとに1干渉するテストを検出し、サブセット化 3. 各A/BテストのOri・Varにはハッシュ値でトラフィックを振分け（=直交させる） 4. サブセット内のトラフィックの流れは分散トレースのログなどを用いて 多変量テストのテストケースごとに結果と紐付けてカウント 5. サブセット内のテストケースが統計的に十分なサンプルサイズになればテスト終了 19 1. 視点となるテストごとにサブセットが作られる。例えば、Svc1は[Svc1, Svc2, Svc3]のサブセットを作り、Svc2は[Svc1, Svc3]のサブセットを作るなどがある
21. © Hitachi, Ltd. 2021. All rights reserved. サブセット作成に利用する属性情報 以下情報からA/Bテストの影響の種別や範囲を判別する A/Bテスト情報 ▪ 変更箇所：テストを実施するサービス ▪ 測定箇所：メトリクスの測定先となるサービス ◇ 例. 商品推薦機能：変更箇所→推薦サービス、測定箇所→UIサービス 与干渉要因 / 被干渉要因（それぞれ指定） ▪ 種別：ユーザ(外観、推薦機能など)、レイテンシ、エラー率、消費リソース ▪ 範囲：変更箇所のみ、測定箇所のみ、変更箇所ー測定箇所間、 変更箇所とその依存先、測定箇所とその依存先、など 20
22. © Hitachi, Ltd. 2021. All rights reserved. 処理の流れ 1. マイクロサービス開発者がA/Bテスト実行時に属性情報を入力 2. 入力された情報およびマイクロサービス間の接続関係から テストごとに1干渉するテストを検出し、サブセット化 3. 各A/BテストのOri・Varにはハッシュ値でトラフィックを振分け（=直交させる） 4. サブセット内のトラフィックの流れは分散トレースのログなどを用いて 多変量テストのテストケースごとに結果と紐付けてカウント 5. サブセット内のテストケースが統計的に十分なサンプルサイズになればテスト終了 21 1. 視点となるテストごとにサブセットが作られる。例えば、Svc1は[Svc1, Svc2, Svc3]のサブセットを作り、Svc2は[Svc1, Svc3]のサブセットを作るなどがある
23. © Hitachi, Ltd. 2021. All rights reserved. 干渉の判定とサブセット化 以下手順で干渉を判定し、サブセットを構築する（下図はSvc2のサブセットを作成する例） 22 Svc4 Svc1 Svc2 Svc3 Svc5 o v Svc4 Svc1 Svc2 Svc3 o v o v Svc5 種別: レイテンシ 対象テスト(Svc2)の被干渉 種別と与干渉種別が同じ テストを列挙 分散トレーシングや通信ログ からマイクロサービスの接続 関係グラフを作成 対象テスト(Svc2)の被干渉範 囲と与干渉範囲が重なるテスト をサブセットに選定 → Svc2とSvc3をサブセット化 Svc2の 被干渉範囲 o v Svc4 Svc1 Svc2 Svc3 o v o v Svc5 Svc3の 与干渉 範囲 Svc5の 与干渉 範囲 対象 ↓
24. © Hitachi, Ltd. 2021. All rights reserved. 処理の流れ 1. マイクロサービス開発者がA/Bテスト実行時に属性情報を入力 2. 入力された情報およびマイクロサービス間の接続関係から テストごとに1干渉するテストを検出し、サブセット化 3. 各A/BテストのOri・Varにはハッシュ値でトラフィックを振分け（=直交させる） 4. サブセット内のトラフィックの流れは分散トレースのログなどを用いて 多変量テストのテストケースごとに結果と紐付けてカウント 5. サブセット内のテストケースが統計的に十分なサンプルサイズになればテスト終了 23 1. 視点となるテストごとにサブセットが作られる。例えば、Svc1は[Svc1, Svc2, Svc3]のサブセットを作り、Svc2は[Svc1, Svc3]のサブセットを作るなどがある
25. © Hitachi, Ltd. 2021. All rights reserved. 分散トレース情報を用いたサンプルのカウント方法 テストケースを基づくトラフィック送付は事前のテストケース把握と複雑な通信制御が必要。 そこで、仮説1に基づきトラフィック自体はハッシュ値で振り分け、分散トレース情報からトラ フィックの通信経路を得て、該当するテストケースのサンプルに加える 分散トレース ▪ ユーザリクエストごとに通信の経路や処理時間を可視化する監視方式 24 ingress product page raviews ratings Grafanaにて可視化したリクエストの分散トレース情報 （横: 時間、色: コンポーネント） details 通信経路 復元
26. © Hitachi, Ltd. 2021. All rights reserved. 提案システムの構成案 25 サービスチーム エンドユーザ サービス1 Original サービス1 Variant プロキシ テスト対象(サービス1を抜粋) トラフィック制御機能 (e.g., Istio) トラフィック 割振り サブセット 算出 結果 集計 テスト 評価 UI メトリクス収集機能 (e.g., Prometheus) 分散トレーシング機能 (e.g., Jaeger) A/Bテスト干渉回避システム A/Bテスト 属性情報 結果 サービス 利用 ユーザハッシュでの トラフィック割振り指示 通信経路情報 対象メトリクス テスト結果 信頼度が一 定以上にな るまでテスト 継続 サブセットごとに 多変量テスト集計 属性情報より サブセット算出 赤文字 :提案システムのポイント
27. © Hitachi, Ltd. 2021. All rights reserved. 評価案 26
28. © Hitachi, Ltd. 2021. All rights reserved. 現在検討中の評価案 仮説ごとに評価を行う 仮説1（ハッシュ振り分けのトラフィックを多変量テストのサンプルに利用できる） ▪ 可能なら理論的に、難しければ実験的に必要サンプル数を算出 仮説2（交互作用の大小はマイクロサービスの構成やA/Bテストの目的に依存） ▪ シミュレーションを用いて、多変量テストに比べた精度と処理時間を測定予定 ▪ 条件が恣意的になる懸念あり。現実と離れたパターンを許容してでもランダム化する？ ▪ 対象となるマイクロサービスのサンプル構成も見繕い中 良い方法を教えていただけると幸いです 27
29. © Hitachi, Ltd. 2021. All rights reserved. まとめ 28
30. © Hitachi, Ltd. 2021. All rights reserved. まとめと残課題 まとめ ▪ マイクロサービス内で複数チームが同時にA/Bテストを行うと結果が干渉しうる ▪ しかし、交互作用まで評価できる多変量テストではテストの時間が長大化 ▪ マイクロサービスの接続関係とA/Bテストの属性情報からA/Bテスト群を サブセットに分割し、それぞれ多変量テストを適用する方式を提案 残課題 ▪ 提案方式の評価 ▪ 動的に追加されたA/Bテストへの対応 ▪ サブセットが巨大化した場合の対応 29
31. © Hitachi, Ltd. 2021. All rights reserved. 参考文献 [TAB10] Tang, Diane, et al. "Overlapping experiment infrastructure: More, better, faster experimentation." Proceedings of the 16th ACM SIGKDD international conference on Knowledge discovery and data mining. 2010. 30
32. © Hitachi, Ltd. 2021. All rights reserved. 商標 ▪ Grafanaは、Grafana Labsの米国またはその他の国における登録商標または商標です ▪ Istioは、Google LLCの米国における登録商標または商標です ▪ Prometheusは、The Linux Foundationの米国またはその他の国における登録商標または商標です ▪ Jaegerは、 The Linux Foundationの米国またはその他の国における登録商標または商標です ▪ その他記載の会社名、製品名、サービス名、その他固有名詞は、 それぞれの会社の商標または登録商標です ▪ 本発表中の文章、図では、TM、🄬マークは表記しておりません。 31