データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

ab 分割のトラフィック保護機能を紹介する前に、ab 分割の概念と用語をいくつか普及させてみましょう。

用語集:

実験: リクエストの処理方法を決定する機能や戦略を検証するために使用されるトラフィックの一部で、通常はシステム指標 (PV/UV、CRT、注文変換率など) に対する特定の機能や戦略の影響を検証するために使用されます。、など）。
トラフィック :アクセスユーザーからのすべてのリクエストを指します
ハッシュ係数:実験にアクセスするユーザーの uuid、つまり、特定のトラフィックユーザーを識別できる一意の識別子として理解できます。
ハッシュアルゴリズム:ハッシュアルゴリズムを通じて任意の長さの入力を固定長の出力に変換、任意のファイルから小さなデジタル "フィンガープリント" を作成する方法です。指紋と同様に、ハッシュアルゴリズムはファイルの一意性を確保するために短い情報を使用します。
バケットポジション： abテストはバケットテストとも呼ばれます。ユーザーのリクエストがオフロードの実験にヒットすると、オフロードエンジンはリクエストの uuid + 強整合性ハッシュアルゴリズムに基づいてグローバル固定値を生成します (各バケットへの分散がランダムで平均的であればあるほど、より良いものになるようにするため
実験バージョン:実験バージョンは実験的なグループ化であり、A/B 実験は通常、新しい戦略の効果を検証するために使用されます。実験中、選択されたユーザーはグループ A とグループ B にランダムに割り当てられました。グループ A のユーザーは新しい戦略を体験しましたが、グループ B のユーザーは引き続き古い戦略を体験しました。この実験プロセスでは、グループ A が実験グループ、グループ B が対照グループです。複数の実験グループと 1 つのコントロールグループで構成される実験もあり、それらが共同でトラフィックリクエストの 100% を伝送します。

ユーザーバケット番号を生成する方法

上の図に示すように、ユーザーが実験にアクセスするときに一意の固定番号を持つことは誰もが知っています。

その意味をよりよく説明するために、26 人のトラフィックユーザー、つまり AZ に 26 人のユーザーがいると仮定します。

{ A 、 B 、 C 、 D 、 E 、 F 、 G 、 H 、 I 、 J 、 K 、 L 、 M 、 N 、 O 、 P 、 Q 、 R 、 S 、 T 、 U 、 V 、 W 、 X 、 Y 、Z }

Experiment Xにアクセスすると、ハッシュ (uid + Experiment) を通じて次の実験番号が生成されました。

A_11,B_9,C_12,D_10,E_7,F_9,G_24,H_22,I_18,J_8,K_21,L_15,M_1,N_4,O_76,P_33,Q_40,

R_5,S_12,T_80,U_67,V_25,W_33,X_49,Y_87,Z_100

実験 Yにアクセスすると、ハッシュ (uid + 実験 X シード) を通じて次の実験番号が生成されました (命名規則はユーザー x_bucket 番号です)。

A_25、B_17、C_19、D_2、E_1、F_18、G_19、H_22、I_12、J_2、K_22、L_14、M_4、N_16、O_28、P_30、

Q_92,R_93,S_8,T_55,U_18,V_100,W_1,X_100,Y_50,Z_36

上記のケースの説明を通じて、ランダムトラフィックユーザーが実験にアクセスすると、一部のユーザーによって生成されたバケット番号は同じになり、実験では同じグループに参加します。

実験版とバケットの位置の関係

1 つのバケット番号は、総トラフィックの 1 パーセント (100%) を表します。

実験的トリアージのデモンストレーション

実験の 3 つのバージョン、つまり 3 つのグループ、つまり実験グループ 1 = VA、実験グループ 2 = VB、およびコントロールグループ = VC があるとします。

初期グループ化率は、VA=10%、VB=10%、VC=80%です。

次に、実験グループのトラフィックを拡張する必要があります。トラフィックは VA=20%、VB=20%、VC=60% です。

拡張後のこの種の転用は、転用の観点からは問題ありませんが、注意深い学生は、以前にバケット番号 11 ～ 20 で実験グループ 2 に入ったユーザーが、実際には...実際には実験グループの拡張後に...実験グループ 1 に割り当てられました。このように、ユーザーはグループに飛び移っていきますが、規模が拡大し続けると、実験グループ 2 に入ったユーザーが拡張後は実験グループ 1 に振り分けられる、という問題が必ず発生します。

実験グループでは毎回ユーザー汚染の問題が発生しますが、運用メンバーは比率を調整するたびにバックエンドの割り当てロジックを知らず、トラフィックの割り当てがOKであることを当然と思い込んでしまいます。データ分析の問題やユーザーエクスペリエンスの問題が発生する可能性があり、比率調整後に他のグループのユーザーが汚染されている可能性もあります。このような結果はビジネスでは容認できません。

では...この状況に実際に最適な割り当ては何でしょうか? 読み続けてください。

正しい流用レンダリング

上のレンダリングに示すように、次のようになります。

VA バージョンは、元の 10% から 20% に拡張されました。正しい分布は次のとおりです。

新しい 10% のトラフィックは、コントロールグループ VC のトラフィックユーザーからのものです。つまり、バケット位置範囲は 21 ～ 30 です。

拡張後、VA のトラフィックの 20% は 2 つのバケット範囲 (1 ～ 10 と 21 ～ 30) に分割されます。

VB バージョンは、元の 10% から 20% に拡張されました。正しい分布は次のとおりです。

新しい 10% のトラフィックは、コントロールグループ VC のトラフィックユーザーからのものです。つまり、バケット範囲は 31 ～ 40 です。

拡張後、VB のトラフィックの 20% は 2 つのバケット範囲 (11 ～ 20 と 31 ～ 40) に分割されます。

この種の拡張後は、以前のようにトラフィックユーザー間でグループがジャンプすることはなくなります。つまり、元のユーザーが拡張後に入力したバージョンが以前のバージョンのままであることが保証されます。

この種のオフロード最適化をトラフィック保護と呼び、この記事で焦点を当てる機能です。

トラフィック保護を行う理由:

回答:実験の反復中、バージョンの増減と比率の調整が最も頻繁に行われる操作です。このとき、プラットフォームは [トラフィック保護] 機能を採用しています。比率を低減したバージョンからトラフィックを分割し、スケールを拡大したバージョンを提供します。トラフィックを最大限に隔離し、実験グループ間の相互汚染を軽減します。

トラフィック保護機能の導入

AB 迂回は、この非科学的なトラフィック調整問題を早急に解決する必要があります。[トラフィック保護] 機能をアップグレードした後、次のように一連の実験バージョンのトラフィック反復の導出プロセスを見てみましょう (赤はグループ A、青はグループ B、緑色はグループCを表します)

多くの調整を行った後、各実験では独自の範囲の変更を最小限に抑え、ユーザーの維持を確保し、実験指標への影響を軽減します。

交通保護アニメーション減算

4つのバージョンの比率調整の控除を直接楽しむことができます（各バージョンのカラーブロックの変化に注目できます）

上記の例からわかるように、複数回のトラフィック調整の後、各実験の間隔分布はより複雑になりますが、ユーザーの観点から見ると、ユーザーの観点からは、各実験のトラフィック比率だけを気にする必要があり、トラフィック比率は考慮されません。基礎となる実験トラフィックの間隔分布に注意する必要があるため (これは彼にとってブラックボックスです)、ユーザーの操作の難易度が上がることはありません。

交通保護配布ルール

グループバージョンスケーリング調整: バージョン変更の前後のデータを比較します。3 つの変更グループを順番に特定します: 新しい割合、減少した割合、変化のない割合
縮小バージョングループのバケットを分割する:縮小グループバージョンのバケット範囲を右端から分割し、バケット範囲セグメントが縮小変動率を満たすまで一致させます。
分割バケット範囲の並べ替えと移動: リダクショングループの分割バケット範囲を左から右に並べ替え、順番に新しいバージョンに割り当てます。
バージョン変更後のバケットのソートとマージ: 割り当て後のすべてのバージョンはバケット間隔でソートされ、隣接するバケット間隔がマージされます。

著者: Jingdong Technology Fu Haojun

出典：JD Cloud Developer Community 転載の際は出典を明記してください

Growth Lab-AB Traffic トラフィック保護機能の紹介 | JD Cloud テクニカルチーム