この記事はSpeee Advent Calendar 2016 の12日目の記事です。
前日の記事は
@suemocのre:dashの権限管理とその活用事例 - Qiita
です。
新卒エンジニアの@_miyachikです。今回は(フロントの変更なら)エンジニアの工数を必要とせず、アプリケーションの開発言語を問わない汎用的ABテスト基盤の話をします。
前提
今回のABテスト基盤では
- ブランチを分けた状態で個別にABテストができる(masterにマージする必要なし)
- フロントの軽微な修正はエンジニアにはエンジニアの工数は割かない(ディレクターとデザイナーのみで行えるようにする)
- API側などbackendのロジックに対するABテストも行えるようにする
- 開発言語にとらわれずABテスト基盤導入をすることが可能
を実現することが出来ます。まずは最上段の振り分けについて話したいと思います。
* ただ立ち上がるインスタンスのIPがわからないオートスケールにはまだ対応しきれていません
やったこと
- HAProxyによるABテスト振り分けと再抽選の防止
- HAProxyの設定ファイルをRailsアプリケーションから動的に吐き出し、アプリケーションをデプロイとHAproxyの設定を再読込するタスクを作成
- ABテストサーバをbackendから切り離し
- 対象のABテストブランチをABテストサーバにデプロイ
- 生成したHAProxyの設定を再読込
- フロントのダウンタイムはゼロになるように
HAProxyについて
HAProxy とはプロキシサーバであり、ソフトウェアロードバランサーです。
HAProxyが何であって、何でないかは公式のドキュメントに書いてあります。
ドキュメントにもある通りHAProxyにはロードバランサーとしての機能があり、HAProxy自身がCookieを発行することができます。そしてCookieがセットされているかを判断することもできます。
また、HAProxy単体でABテスト振り分けに関する機能は実現可能なため、Front/backendのアプリケーションの種類は問われません。
インフラ構成図
ざっくりとした構成は以下です。各sideごとのサーバ台数はHAProxyのbackend定義により行えます。
ABテストパターンが反映されたブランチはab_sideにのみにデプロイされ、結果が芳しくない場合にはmergeせずに次のABテストに進むことが出来ます。
HAProxyによるABテスト振り分け
振り分けについてはHAProxyのACLとbackendの複数定義により行っています。
ACL(Access Control List)
公式ドキュメント
HAProxyのACLは非常に柔軟なアクセスを振り分けることができます。
下記のように書くことでCookieを判断して振り分けるbackendを変更することが可能です。
acl normal hdr_sub(cookie) ab-test-pattern=0
acl ab-test-pattern hdr_sub(cookie) ab-test-pattern=1
use_backend normal_side if normal
use_backend ab_side if ab-test-pattern
default_backend first_side
ab-test-patternというCookieが存在していない場合(初回アクセス時)には first_side に振り分けら、Cookieが存在しており && 値が1なら ab_sideへ、値が0なら normal_sideへ振り分けられます。
backendの定義
backendの定義は下記の様に行い、初回アクセス時にはCookieを挿入し、重み付け付きの振り分けに関してはweightで行います。この様にすればweightによってABテストサーバーに振り分けられたユーザはその証拠としてCookieの値として 1が書き込まれます。
下記の例ではnormal:AB = 75:25になっています。normalの確立 = ホスト名末尾が 0に行く確立の総和です。なので、設定を吐き出すときにはnormal_sideのweightは設定されている(normal_sideのホスト数)/(設定したいnormal側のweight)
である必要があります。
デプロイされているアプリケーションのブランチが違うので、アプリケーション側で ab_side側かnormal_side側のアクセスなのかは判断する必要はありませんが、事故を防ぐ場合Cookieの値を参照することによりユーザがどちら側に抽選されたのかを判断することができます。
初回アクセス時にはCookieはセットされておらず、X-HOST-NAME を使用しHeaderからホスト名を参照しab_sideかnormal_sideかを判断することが出来ます。
backend first_side
mode http
cookie ab-test-pattern insert nocache
balance roundrobin
http-send-name-header X-HOST-NAME
server web1-0 127.0.0.1:80 weight 25% check cookie 0 inter 1000 fall 2
server web2-0 127.0.0.2:80 weight 25% check cookie 0 inter 1000 fall 2
server web3-0 127.0.0.3:80 weight 25% check cookie 0 inter 1000 fall 2
server web4-1 127.0.0.4:80 weight 25% check cookie 1 inter 1000 fall 2
あとはnormal_sideにはnormal側のホストのみを宣言すればnormalにしか行きません。
ただし、ab_sideにはnormal側のホストを含めて宣言しないと、万が一ABテストサーバ(今回の場合web4-1)が落ちていた場合に該当するホストが見つからずアクセスできなくなってしまうので注意が必要です。(check cookieをしている場合でもホストが落ちていると振り分けは行われず別のサーバへ振り分けられる)
以下が実際に吐き出されるファイルです。負荷などを気にする場合は適切にmaxconn等の設定を追記してください。ブランチ名はab-test-patternの想定です。
normal_sideのIPなどはRailsのconfigファイル内に配列で書いています。
global
log 127.0.0.1 local2 info
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 10000
user haproxy
group haproxy
daemon
defaults
log global
timeout connect 60s
timeout server 1m
timeout client 1m
timeout check 5s
# web
listen frontside
maxconn 4000
fullconn 4000
bind 0.0.0.0:80
mode http
acl normal hdr_sub(cookie) ab-test-pattern=0
acl ab-test-pattern hdr_sub(cookie) ab-test-pattern=1
use_backend normal_side if normal
use_backend ab_side if ab-test-pattern
default_backend first_side
backend first_side
mode http
cookie ab-test-pattern insert nocache
balance roundrobin
http-send-name-header X-HOST-NAME
server web1-0 127.0.0.1:80 weight 25% check cookie 0 inter 1000 fall 2
server web2-0 127.0.0.2:80 weight 25% check cookie 0 inter 1000 fall 2
server web3-0 127.0.0.3:80 weight 25% check cookie 0 inter 1000 fall 2
server web4-1 127.0.0.4:80 weight 25% check cookie 1 inter 1000 fall 2
backend normal_side
mode http
balance roundrobin
server web1-0 127.0.0.1:80 check inter 1000 fall 2
server web2-0 127.0.0.2:80 check inter 1000 fall 2
server web3-0 127.0.0.3:80 check inter 1000 fall 2
backend ab_side
mode http
cookie ab-test-pattern insert nocache
balance roundrobin
server web1-0 127.0.0.1:80 check cookie 0 inter 1000 fall 2
server web2-0 127.0.0.2:80 check cookie 0 inter 1000 fall 2
server web3-0 127.0.0.3:80 check cookie 0 inter 1000 fall 2
server web4-1 127.0.0.4:80 check cookie 1 inter 1000 fall 2
HAProxyの設定変更とアプリケーションのデプロイを行うタスクは、今回はJenkinsのJobを連鎖させることで実現しました。
用意したJobは
- HAProxyからab_sideを切り離したconfigをreload
- 指定したブランチをデプロイ
- 生成したHAProxyのconfigファイルを再読込
です。HAProxyはgraceful restartが可能なので、デプロイによる表側への影響はありません。
作成したHAProxyのconfigのみを吐き出すアプリケーションは現在公開準備中になりますので、今しばらくお待ち下さい