Tweet
Tweet

Slide 1

Slide 1 text

AB test with Docker 2019/05/24 Docker Meetup Kansai #3 rito

Slide 2

Slide 2 text

Agenda ❏ 自己紹介 ❏ サービス改善時の課題 ❏ テスト基盤概要 ❏ テスト基盤の課題および解決方法 ❏ 同一ページの表示 ❏ 複数ページでの同時 テスト実施 ❏ 静的ファイルの配信 ❏ まとめ 2

Slide 3

Slide 3 text

自己紹介 名前： rito 職業： Webエンジニア （アプリケーションエンジニア） 分野： Ruby on Rails, Nodejs, React, Docker, AWS, GCP 所属： Ateam Finergy Inc. CTO コミュニティ： Rails follow-up Osaka Osaka Web Developers Meetup twitter: @chimame_rt GitHub: chimame 3

Slide 4

Slide 4 text

サービス改善時の課題

Slide 5

Slide 5 text

サービス改善手法 ❏ ❏ ❏ 5

Slide 6

Slide 6 text

6 A/Bテストするためのツール

Slide 7

Slide 7 text

軽く テストするなら これらのツールでも可能 7

Slide 8

Slide 8 text

凝った テストするにはちょっと 8

Slide 9

Slide 9 text

自社で一番よくやられている テストの手法 9

Slide 10

Slide 10 text

10 トップページをA/Bテストする 一定のルールでディレクトリを分けると テストできる を社内で開発・使用

Slide 11

Slide 11 text

確かに実施できるが課題もある 11

Slide 12

Slide 12 text

以前のA/Bテスト手法の課題 ◂ 「一定のルールでディレクトリを作成する」という仕 様が理解しづらい ◂ コピペされたコードが大量に発生する ◂ テストを行っているページでパーシャルファイ ルを参照すると不具合が誘発しやすい 12

Slide 13

Slide 13 text

A/Bテスト基盤

Slide 14

Slide 14 text

14 アプリケーションで テストを サポートするの辛いな

Slide 15

Slide 15 text

15

Slide 16

Slide 16 text

“ インフラで テストをサポートするに は と があれば成立するんだから、 つサーバ並べれれば テストでき るよね？ なら コンテナ つ並べればでき るんじゃない？ 16

Slide 17

Slide 17 text

Dockerの特徴 ◂ コードベースでインフラを定義 ◂ 環境構築の差異を最小限することが可能 ◂ サーバ計算資源を効率よく使用 ◂ デプロイが容易に可能 17

Slide 18

Slide 18 text

平たく言うと 18

Slide 19

Slide 19 text

環境構築もしくは再現が容易 19

Slide 20

Slide 20 text

“ インフラで テストをサポートするに は と があれば成立するんだから、 つサーバ並べれれば テストでき るよね？ なら コンテナ つ並べればでき るんじゃない？ 20

Slide 21

Slide 21 text

“ インフラで テストをサポートするに は と があれば成立するんだから、 つサーバ並べれれば テストでき るよね？ なら コンテナ つ並べればでき るんじゃない？ 21 できなくはないけど、クラウド使ってて コピーして作るとしても結構面倒くさ い。更には計算資源（サーバ）無駄過 ぎる。

Slide 22

Slide 22 text

“ インフラで テストをサポートするに は と があれば成立するんだから、 つサーバ並べれれば テストでき るよね？ なら コンテナ つ並べればでき るんじゃない？ 22 環境構築が簡単。計算資源が多少は いるけど、サーバを2つ構えるよりは断 然まし。

Slide 23

Slide 23 text

基盤構成 23 Target group Target group

Slide 24

Slide 24 text

これを見てこんなこと思いませんでした？ 24

Slide 25

Slide 25 text

「めっちゃ普通やん」 25

Slide 26

Slide 26 text

その感覚は正しいです （でも少しだけ普通と違う箇所もある） 26

Slide 27

Slide 27 text

「裏側でめっちゃ頑張っ てそう」 27

Slide 28

Slide 28 text

それも正しいです （現に裏側はめっちゃ色々やってる） 28

Slide 29

Slide 29 text

A/Bテスト基盤の課題と 解決方法

Slide 30

Slide 30 text

最初に作った初期型の構成 30

Slide 31

Slide 31 text

初期型構成 Target group 31 Original Challenger 対応内容 ・普段は ブランチをデプロイ ・特定ブランチ名で すると と言 われる テスト用のコンテナをデプロイ

Slide 32

Slide 32 text

第 の課題発生 32

Slide 33

Slide 33 text

Target group 33 初期型構成 Original Challenger UserはABどちらかのページを表示さ れる。A/Bテスト実施時にAとBの表示 がアクセスの度に変わるのはよくな い。

Slide 34

Slide 34 text

第 の課題解決 34

Slide 35

Slide 35 text

35 初期型構成 Target group Original Challenger ALBのtarget groupには「sticky session」と いう設定が存在する。 それをオンにすれば一定期間は同一コンテ ナにアクセスさせることが可能。

Slide 36

Slide 36 text

なんかイケそうだったけど 第２の課題発生 36

Slide 37

Slide 37 text

Target group 37 初期型構成 Original Challenger 2画面分の別々A/Bテストを同時に実施 するので、Challengerコンテナを2つ配 置する。 （A/B/Cテストではない） どのコンテナに当たるかは1/3

Slide 38

Slide 38 text

もう少しわかりやすく説明 38

Slide 39

Slide 39 text

top画面とthanks画面の2しかないアプケーションとする 39 画面 画面 Original Original A/Bテストを実施していないのでコンテナ1つで どちらもOriginalが表示される状態

Slide 40

Slide 40 text

top画面とthanks画面の2しかないアプケーションとする 40 画面 画面 Original Original Challenger Original top画面でA/Bテストを実施した状態。 top画面だけ1/2でユーザが振り分けられる。 thanks画面は同じなので、振り分けは実質なし。

Slide 41

Slide 41 text

top画面とthanks画面の2しかないアプケーションとする 41 thanks画面も同時にA/Bテストを実施したい場合の状態。 thanks画面のChallengerコンテナはthanks画面だけの変更 なので、top画面は変更されない。 画面 画面 Original Original Challenger Original Original Challenger

Slide 42

Slide 42 text

top画面とthanks画面の2しかないアプケーションとする 画面 画面 Original Original Challenger Original Original Challenger 42 Challengerへのアクセス確率が1/3になってしまう。

Slide 43

Slide 43 text

❗❓ 43

Slide 44

Slide 44 text

第2の課題の整理 ◂ 別々の画面を同時に テストをすると へのアクセス率が悪くなる ◂ へのアクセス率が悪くなると テス ト結果のログが貯まるのに時間が必要となる ◂ もっというと コンテナは つで動くというこ とはなく、冗長性を持たせて つ以上で動くので つ 目の テストでも起こりうる 44

Slide 45

Slide 45 text

第 の課題解決 45

Slide 46

Slide 46 text

46 型構成 Target group Target group Target group A/Bテストしたい画面のURLは決まっているのでALB のルール設定でURLごとにtarget groupを分ける。 Challenger Original Challenger Original /thanksへの アクセス /topへの アクセス

Slide 47

Slide 47 text

47 型構成 Target group Target group Target group target group単位でA/Bテス トを実施する形にする。 OriginalとChallengerのコン テナをセットとし、1/2の確率 でA/Bテストできるようにする Challenger Original Challenger Original /thanksへの アクセス /topへの アクセス

Slide 48

Slide 48 text

48 型構成 Target group Target group Target group Challenger Original Challenger Original Original Original /*への アクセス /thanksへの アクセス /topへの アクセス A/Bテスト対象外はoriginal用の target groupに割り振る。

Slide 49

Slide 49 text

次こそいけそう！ 49

Slide 50

Slide 50 text

そんな甘くなかった 50

Slide 51

Slide 51 text

第 の課題発生 51

Slide 52

Slide 52 text

52 型構成 Target group Target group /*への アクセス /thanksへの アクセス Challenger Original Original Original ② を返却 ① リクエスト 仮に画像をA/Bテストすると想定して Challengerにアクセスされたとする。

Slide 53

Slide 53 text

53 型構成 Target group Target group /*への アクセス /thanksへの アクセス Challenger Original Original Original ③画像等を再度取得 静的ファイルの取得パスが /images/* となっている場合に、必ず Originalに取得しにいってしまう。 OriginalにはChallengerの画像はないので、404となってしまう。 ④404 Not Found

Slide 54

Slide 54 text

第 の課題解決 54

Slide 55

Slide 55 text

55 型構成 Target group Target group /*への アクセス /thanksへの アクセス Challenger Original Original Original ② を返却 ① リクエスト ③画像等を再度取得 CDNを使う設定で Challenger用の静的 ファイルをS3に配置し、 そこから取得させる

Slide 56

Slide 56 text

まとめ

Slide 57

Slide 57 text

A/Bテストをインフラでサポートする時に目指した もの ◂ 簡単に テストが 実施 できる ◂ 簡単に テストが 停止 できる ◂ オリジナルコンテンツに 影響 なく テストが実 施できる 57

Slide 58

Slide 58 text

58 Target group Target group 基盤構成 git pushすればこれらのインフラが自動で構築されるものを 構築している。 ブランチを消せば停止するようになっている。

Slide 59

Slide 59 text

59 Target group Target group 基盤構成 ここにそれらを構築する泥臭い処理を任せて頑張っている。 ということは、ここにこれらのノウハウが溜まっている。

Slide 60

Slide 60 text

◂ コンテナを使っての テストって意外と できる ◂ アプリケーションエンジニアでも、 使えば インフラのことがある程度できる ◂ 本当はまだまだ細かいこと（ハマりポイント）ある ので、後で聞いてください 60 言いたいこと

Slide 61

Slide 61 text

61

Slide 62

Slide 62 text

62

Slide 63

Slide 63 text

63 Thanks! ご清聴ありがとうございました。 ◂ ◂