Service Workerの全体像の解説と、それがもたらすWebの未来を考察します。今後の動向を左右しそうなService worker meeting notesについても解説します。

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来 | PLAID Engineer Blog 

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

<html><head></head><body>こんにちは、プレイドの@wikrshです。
プレイドが提供している<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>では、サイトに来訪するユーザに応じて様々な接客アクションを行う機能を提供しています。
接客アクションのようなウェブサイト上の施作の効果を検証する方法としてはA/Bテストが有名だと思いますが、今回のエントリーではA/Bテスト以外の手法としてバンディットアルゴリズムをざっくりと紹介したいと思います。
<h3 id="A/Bテストとバンディットアルゴリズム">A/Bテストとバンディットアルゴリズム</h3>
バンディットアルゴリズムは、いくつかの施作を実験しながら実験中に得られる効果もできるだけ大きくしたい、という目的のためのアルゴリズムです。
例えばECサイトの商品画像としてAとBの2つの画像の内どちらを表示した方が購入確率が上がるかということを知りたい場合、ユーザによって画像をランダムに表示してどちらの画像を表示した方が購入確率が高いか(もしくは有意差がないか)を検証しますが、ある画像を表示した方が購入確率が高いのであればできるだけ多くその画像を表示した方が全体の購入確率は高くなります。
A/Bテストでは十分なサンプル数を集めるまであらかじめ決めた割合(例えば1:1)でランダムに表示することを繰り返すため劣っている案も一定数表示することが必要となりますが、劣っている案を表示することは結果的に（優れた案を表示するのと比較して）コストを払っているとも考えられます。 
バンディットアルゴリズムで対象としている問題はこのコストを小さくすることであり、その時点までに得られた結果の利用の仕方・次の案の表示のさせ方のアルゴリズムになっています。
<h3 id="Epsilon-Greedyアルゴリズム">Epsilon-Greedyアルゴリズム</h3>
ここでは具体的なアルゴリズムの例として、Epsilon-Greedyアルゴリズムを紹介します。
Epsilon-Greedyアルゴリズムは単純な動作のアルゴリズムになっていて以下のような動作となります。
<ul>
<li>ある割合(0 &lt; ε &lt; 1)で選択肢からランダムに選択する</li>
<li>1-εの割合でこれまでの結果が最も良い選択肢を選択する</li>
</ul>
例えばε=0.3とした場合、先の画像の例では以下のような動作となります。
<ul>
<li>画像A、Bをそれぞれ15%ずつの割合で表示</li>
<li>残り70%はその時点での結果が良い画像を表示</li>
</ul>
各画像は最低でも15%の確率で表示されるため、十分な回数繰り返せば各選択肢の効果を検証することが可能です。 
また、70%はその時点で最も良い結果の画像を表示するため、優れた案（最適な案）が正しく選択されれば全体の結果も向上する可能性があります。
このアルゴリズムについて簡易的な実装をしたのが以下のコードです。
<pre><code class="language-coffeescript hljs">_ = require 'lodash'

class EpsilonGreedyAlgorithm
 # @params {Number} nChoices 選択肢の数
 # @params {Number} epsilon ランダムに選択を行う割合
 constructor: (@nChoices, @epsilon) -&gt;
 @initialize()

 initialize: -&gt;
 @averages = _.fill Array(@nChoices), 0 # 選択肢ごとの得られた結果の平均値
 @counts = _.fill Array(@nChoices), 0 # 選択肢ごとの選択回数
 @nBest = 0 # 現状の最良の選択肢

 # 選択肢から一つ選択する
 select: () -&gt;
 if Math.random() &lt; @epsilon
 # 全ての選択肢からランダムに選択
 return Math.floor(Math.random() * @nChoices)
 else
 # その時点で最も良い結果の選択肢を選択
 return @nBest

 # 結果を受け取って状態を更新する
 # @params {Number} n 選択肢の番号(0..nChoices-1)
 # @params {Number} reward 得られた結果(報酬)
 update: (n, reward) -&gt;
 @counts[n] += 1
 c = @counts[n]
 @averages[n] = ((c - 1) / c) * @averages[n] + (reward / c)

 @nBest = n if @averages[n] &gt; @averages[@nBest]
</code></pre>
バンディットアルゴリズムはその時点の結果を元にいずれかの選択肢を選択するという動作となっているため、結果を受け取るためのメソッド(コード上の<code>update()</code>)と選択したものを返すメソッド(コード上の<code>select()</code>)を実装しています。
以下のような形で動作します。（A案を0、B案を1としています。）
<pre><code class="language-coffeescript hljs"># A案,B案の2つのみ、e = 0.3
ega = new EpsilonGreedyAlgorithm 2, 0.3
ega.select() # =&gt; 1 (B案を選択)
... # B案を表示して結果(例えばユーザが購入したかどうか)を得る
ega.update(1, 1) # B案を選択した結果、ユーザが購入を行った
ega.select() # =&gt; 0 (A案を選択)
... # A案を表示...
</code></pre>
<h3 id="動作の検証">動作の検証</h3>
バンディットアルゴリズムでは選んだ選択肢に対するフィードバックを受けて次の動作が決まっていくため、動作の検証のためにはシミュレーションが必要となります。
ここでは<a href="http://www.oreilly.co.jp/books/9784873116273/" target="_blank" rel="noreferrer">「バンディットアルゴリズムによる最適化手法」</a>を参考に、一回の試行の結果はランダムに決定し、シミュレーションを繰り返すことで動作を検証するという形でどのような動作になるのかを見ていきたいと思います。
例えばあるA案、B案の2つをコンバージョンレートで比較したい場合は、ある一回の試行の結果を0（コンバージョンしなかった）、1（コンバージョンした）で表すことでシミュレーションが行えます。
<pre><code class="language-coffeescript hljs">class ConversionSimulator
 constructor: (@cvr) -&gt;

 # 設定したコンバージョンレートでランダムに0 or 1の結果を返す
 get_result: () -&gt;
 if Math.random() &lt; @cvr
 return 1
 else
 return 0
</code></pre>
コンバージョンレートではなく購入金額で比較したい場合は、0/1ではなく購入金額を返すようにすればよさそうです。
<pre><code class="language-coffeescript hljs">class PurchasePriceSimulator
 constructor: (@cvr, @minPrice, @maxPrice) -&gt;

 get_result: () -&gt;
 if Math.random() &lt; @cvr
 return _.random @minPrice, @maxPrice
 else
 return 0
</code></pre>
コンバージョンレートでの比較を行う場合のシミュレーションとして、A案を提示した場合は5%のCVR、B案を提示した場合は10%のCVRが得られる状況のシミュレーションを行ってみます。
<pre><code class="language-coffeescript hljs"># A案は5%のCVR、B案は10%のCVR
cvrs = [0.05, 0.10]
choices = cvrs.map (cvr) -&gt;
 new ConversionSimulator(cvr)

algo = new EpsilonGreedyAlgorithm 2, 0.3
algo.initialize()

# 1000回A/B案の選択・提示を繰り返す
results = _.times 1000, -&gt;
 n = algo.select()
 reward = choices[n].get_result()
 algo.update(n, reward)
 return n
</code></pre>
このシミュレーションを1000回繰り返して、最適な案（B案)を提示した割合をプロットした結果が下の図です。（ε=0.3）
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/75d53380-c2f0-4cb4-80a9-bdc0130e0eda/test-1.png" alt="">
コンバージョンレートの低いA案を最適と予想して始めているため、始めの方は最適な案を選んだ割合は低いですが、回数を増すごとに最適な案を選ぶ割合が増加していることがわかると思います。 
一方でEpsilon-Greedyアルゴリズムでは一定の割合でランダムに案を選びに行くため、回数が増加しても最適な手を選ぶ割合は85%付近で収束しています。
<h3 id="その他の方法">その他の方法</h3>
バンディットアルゴリズムは上で紹介したEpsilon-Greedyアルゴリズム以外にも多種多様なものが提案されており、詳細については割愛しますが代表的なものには
<ul>
<li>Softmaxアルゴリズム</li>
<li>UCBアルゴリズム</li>
<li>Randomized Probability Matching</li>
</ul>
などがあります。 
Epsilon-Greedyアルゴリズムよりは探索・活用を単純な動作で行っていますが、これらのアルゴリズムはこれまでの結果から優位性の程度を算出して探索・活用を行ったり、サンプル数の増加に合わせて活用の割合を下げていくなどの工夫が入っています。 
また、Epsilon-Greedyアルゴリズムのεのようなパラメータを試行回数に応じて切り替えていくことで、最適な案に最終的に収束させるような方法もあります。
<h3 id="所感">所感</h3>
バンディットアルゴリズムはA/Bテストと比較して魅力的な点がある反面、 
実際の導入時に考慮する必要がある点は多いと感じました。 
今回はバンディットアルゴリズムの中でも最も単純なEpsilon-Greedyアルゴリズムを紹介しましたが、実際に導入する場合は
<ul>
<li>結果として使用する値（コンバージョンや購入金額等）に対してどのような動作になるか</li>
<li>パフォーマンスの面から逐次更新ではなくバッチ更新とした場合にはどのような挙動となるか</li>
<li>パラメータの設定やテスト期間をどのように設定するか</li>
</ul>
などを検討していく必要があると思います。 
バッチでの更新方法については実際の導入例もあるようですので、今後はこの辺りを検討していきたいと思います。
<h3 id="最後に">最後に</h3>
ウェブ接客プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、 
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">こちら</a>（Wantedly）をご覧ください。 
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
 (function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "https://platform.wantedly.com/visit_buttons/script.js";
 fjs.parentNode.insertBefore(js, fjs);
 }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
</body></html>

今回のエントリーではA/Bテスト以外の手法としてバンディットアルゴリズムをざっくりと紹介したいと思います。

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた / PLAID Engineer  Blog

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

こんにちは！プレイドでインフラエンジニアをしている@ikemonnです。
7/5(火)に<a href="http://plaidtech.connpass.com/event/33511/">【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 </a>を開催しました！
<img width="100%" alt="DSC09468.JPG (2.1 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fc9574b8-7728-4ae0-8e17-9586da3f4a38/79d8af47-57eb-4b5f-a566-f4b5f117b497.JPG.jpg">
<h2>TechBlog Deep Dive Meetup とは</h2>
色々な会社で書かれているTechBlogの人気記事の内容を深掘りしていく勉強会です！
実際にブログを書いたエンジニアに登壇してもらい、記事の内容+α(ブログに書ききれなかったこと、ブログを書いた後に行ったこと等)を発表してもらいます。
今回は、<a href="https://toreta.in/jp/">トレタ</a>さんと一緒に開催させていただきました！
トレタさんからは、<a href="http://tech.toreta.in/entry/2016/06/16/114919">EngineyardからAWSに移設してAuroraの運用を開始した</a>や<a href="http://tech.toreta.in/entry/2016/04/14/143248">トレタのインフラ運用、支えている道具(Packer, Terraform, Serverspec, Ansible, Roadworker, Circle CI)、考え方</a>を書かれた佐野氏に登壇して頂きました。
プレイドからは、<a href="http://tech.plaid.co.jp/autoscaling-ec2/">1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン</a>を書いた@tik-son が登壇しました。
<img width="100%" alt="DSC09506.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8c104bf9-0e02-4714-8bdd-d25e4cbda26c/78916cc8-85a5-4c44-b80e-b7741cc565a2.JPG.jpg">
<ul>
<li><a href="http://tech.toreta.in/">トレタ開発者ブログ</a></li>
<li><a href="http://tech.plaid.co.jp/">PLAID TechBlog</a></li>
</ul>
<h2>発表内容</h2>
<h3>トレタのインフラ運用</h3>
<img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/e3b4f649-f78c-43af-9fb5-38628244bf99/fc540804-45bb-425c-a2c2-1450070b8c29.JPG.webp" alt="fc540804-45bb-425c-a2c2-1450070b8c29.JPG.webp">
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="14b8185b93b947d8891888a9b7323372" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
トレタのインフラ運用について具体的に「どのようなツールを使って」「どのように運用しているか」を話していただきました。
Terraform, Packer, Ansible等、導入理由と運用上押さえておくべきポイントが上手くまとまっており、大変勉強になりました。
弊社でもTerraformを利用しており、お話にあった<code>tfstateファイルの扱い</code>や<code>すべてをterraform管理下には置かない</code>という部分は気をつけて運用しております。
<blockquote class="twitter-tweet" data-lang="ja">「すべてをterraform管理下に置かない」ほんとこれ <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a>&mdash; 謎の音 (@onigra_) <a href="https://twitter.com/onigra_/status/750294797047304192">2016年7月5日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
「この発表をTerraformを使い始める前に聞きたかった…」となるプレゼンでした！
<h3>KARTEを支えるAutoScaling~SpotInstance編</h3>
<img width="100%" alt="DSC09536.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/141a12e6-f165-4baf-9726-3852c6a0d86c/6dbf2a11-f9b2-42a4-9dc1-6f50a6cd2280.JPG.jpg">
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="c05b6b27593443b29aef55eb4b58c24c" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
いかにAutoScalingとSpotInstanceを上手く活用して運用しているかを話してもらいました。
SpotInstanceと聞くと「一時的なバッチ処理に使う」「テスト環境に使う」というイメージがあるかもしれないのですが、弊社では本番環境のステートレスなサーバ全てに使用しています。(管理画面用サーバ、解析サーバ等)
この発表では、SpotInstanceの価格変更にあわせて自動的にondemand⇔spotを切り替える仕組みを実装した話をしてもらいました。
ポイントは、<code>ondemand, spot, static</code>の3種類のサーバ群を用意すること。
「どのようなフローで切り替えを行っているのか」「実装する時に気をつけないといけない点」が詳しく書かれております。
実際に運用にのせたところ、サーバコストが1/2ほどになっているので、「サーバコスト減らしてよ！」と言われているインフラエンジニアの方必見です！
<h3>対談</h3>
<img width="100%" alt="DSC09597.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58866921-6538-4c73-a736-d5a7042aa481/36b32a79-67bb-4922-a011-c1e63d176994.JPG.jpg">
以下の3つのテーマで対談を行いました！
<ul>
<li>HashiCorp製品の何をどうやって使っている？</li>
<li>AWSで辛いところは？</li>
<li>今後の展望</li>
</ul>
<h4>HashiCorp製品の何をどうやって使っている?</h4>
トレタさんではTerraform,Vagrant,Packerを、プレイドではTerraformを使っています。
<ul>
<li>Terraform
<ul>
<li>トレタ
<ul>
<li>VPC</li>
<li>Security Group</li>
<li>EC2</li>
</ul>
</li>
<li>PLAID
<ul>
<li>AutoScaling Group</li>
<li>EC2</li>
<li>ELB</li>
<li>CodeDeploy等</li>
</ul>
</li>
</ul>
</li>
<li>Vagrant
<ul>
<li>トレタ
<ul>
<li>開発環境構築</li>
</ul>
</li>
</ul>
</li>
<li>Packer
<ul>
<li>トレタ
<ul>
<li>AMI作成</li>
<li>Vagrant box作成</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>AWSで辛いところは？</h3>
<ul>
<li>ELBのIPを固定できないのが辛い</li>
<li>ELBのスケールが遅い</li>
<li>AutoScaleのAPIの上限が低くてすぐRateExceededになる</li>
</ul>
<h3>今後の展望</h3>
<ul>
<li>その時点での最適で柔軟なインフラ構成にしたい</li>
<li>AWSやGCPのどちらか一方を使うのではなく、両方の良いサービスを取り入れたハイブリッドなインフラ構成にしたい</li>
</ul>
<h3>Railsアプリケーション郡の構成管理、デプロイ等の話</h3>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="80d97567b26a4ed3aded1d163c2458a4" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
サーバの構成管理とデプロイをどのように行っているのかを話していただきました。
構成管理で使っているのはTerraform。 
<a href="https://speakerdeck.com/hiroakis/toretafalseinhurayun-yong">トレタのインフラ運用</a>でもお話がありましたが、Terraformには<code>管理に向くリソースと向かないリソース</code>があります。 
具体的に<code>どのリソースを継続的に管理していて、どのリソースは構築時のみ使うのか</code>ということに触れられているので、何に使うべきか迷っている方は一読を！
<code>AMI作成まで</code>や<code>LaunchConfig作るまで</code>等を調整出来る、独自Packerクローンを作られたとのこと。すごい…！
 <a href="//www.slideshare.net/AkiraMiki/dockerize" title="Dockerizeして 大変だった話、幸せになった話" target="_blank">Dockerizeして 大変だった話、幸せになった話</a> from <a href="//www.slideshare.net/AkiraMiki" target="_blank">Akira Miki</a>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/W6DcWT9VRF9I3" width="100%" height="533" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> </div>
Docker導入して大変だったことと、その後に訪れた幸せについて話していただきました。
どんなことが大変だったのかの話では、運用に乗せてみないとなかなか想像しづらかった部分について話しておられたので勉強になりました！
苦労を乗り越えた後の幸せの話では、<code>リソースの有効活用とデプロイ時間の短縮</code>など「よーし、明日からDocker入れるぞ！」という気にさせられました！ 
次回はLTではなく、20分枠で是非！
<h3>2つのAuroraクラスタを同期したお話</h3>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="4d8d787993894ddca228419997c9b6ba" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
暗号化対応していない時期から使っていたAuroraを、リードレプリカを作ることで暗号化させた話をしていただきました。
<blockquote class="twitter-tweet" data-lang="ja">暗号化されてないAuroraから暗号化されたAuroraへの移行、つらそう <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a>&mdash; sue445 (@sue445) <a href="https://twitter.com/sue445/status/750312797397848064">2016年7月5日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
ぱっと聞いただけで大変そうな話で、工夫して<code>Binary Log</code>の位置を書き出されたりすることでレプリカセットを組み、無事暗号化されたとのことでした！
<h2>まとめ</h2>
AWS, Terraform, Docker等、サーバ構築からプロビジョニング、運用まで幅広く各社の取り組みを聞くことができた勉強会でした！ 
使用しているツールや、実運用の際にハマっていたり気をつけている部分が似通っていたこともあり、定期的にこのような会を開いて「上手くいったこと」「失敗したこと」の共有をしていければ良いなと思いました！
一緒に勉強会を開催してくださる企業さまも絶賛募集中です！ 
<a href="https://plaid.co.jp/#contact">弊社HPのお問い合わせフォーム</a>からご連絡いただくか、Twitterで #plaidtech をつけてツイートしてください！
<h2>次回</h2>
プレイドでは今後も色々なテーマで定期的に勉強会を開催する予定です！ 
次回は「機械学習」に関する勉強会を8月頃に開催する予定ですので、是非ご参加ください。 
今回もイベント募集開催日に募集人数がオーバーしてしまいましたので、ご興味がある方は<a href="http://plaidtech.connpass.com/">connpassのPLAID tech</a>でメンバー登録を！
ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）募集一覧をご覧ください。

7/5(火)に開催した【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 の開催レポートです。
