Engineer Blog

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

プレイドインターン体験記：インターンを通じて得た技術力と開発力の学び

<h1>はじめに</h1>
<p>この記事は <a href="https://qiita.com/advent-calendar/2024/datadog">Datadog Advent Calendar 2024</a> の 18 日目の記事です。<br>
こんにちは、プレイドの Developer Experience &amp; Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は <a href="https://docs.datadoghq.com/continuous_integration/">CI Visibility</a> と <a href="https://docs.datadoghq.com/dashboards/widgets/split_graph/">Split Graph</a> です。</p>
<p>Datadog の CI Visibility は CI のパフォーマンスを可視化できるプロダクトです。 GitHub Actions や CircleCI など多くのインテグレーションがサポートされていますが、GCP の CloudBuild はサポートされていません。また、CloudBuild には継続的にパフォーマンスを可視化できるような機能がありません。</p>
<p>そこで、CloudBuild のパフォーマンスを <a href="https://docs.datadoghq.com/api/latest/ci-visibility-pipelines/">CI Visibility の API</a> を活用して計測することにしました。</p>
<h1>CI Visibility とは</h1>
<p>CI Pipeline のパフォーマンスを可視化します。APM のように、Pipeline トレースを可視化できるところが大きな利点だと思っていて、他にもさまざまな機能がサポートされています。サポートされる機能は、プロバイダごとに異なり、<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#supported-features">こちら</a>で確認することができます。弊社では主に GitHub Actions と CircleCI を利用していますが、GitHub Actions では Step spans や Queue time、Infrastructure metric correlation がサポートされているのに対して、CircleCI ではそれらがサポートされておらず、ボトルネックの特定が難しかったりします。GitHub Actions や CircleCI 自体にもこのような Insight の機能は備わっているのですが、Datadog では使い慣れたクエリで柔軟に集計したり、Dashboard や Monitor との連携もできるので、なるべく Datadog を使うようにしています。</p>
<p>ちなみに CloudBuild は Integration はサポートされていないので OTHER CI PROVIDER というところに書いてある機能が使えます。</p>
<h1>CI Visibility Event の Level について</h1>
<p>CI Visibility には Event という形でデータを送ります。Event には Pipeline, Stage, Job, Step の4段階の Level があります。</p>
<p>Pipeline は Stage をまとめたもの、Stage は Job をまとめたもの、Job は Step をまとめたもの、というように階層構造になっています。<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#terminology">こちら</a>にプロバイダごとの対応づけが書かれています。例えば GitHub Actions であれば下記の対応になります。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>GitHub Actions</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Workflow</td>
</tr>
<tr>
<td>Job</td>
<td>Job</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>CloudBuild のパフォーマンスを可視化するにあたっては、下記のように Level を対応づけました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>CloudBuild</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Build</td>
</tr>
<tr>
<td>Stage</td>
<td>キューに格納・ソースの取得・全てのビルドステップ・（ある場合は）イメージの PUSHの4つのステージ</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>Pipeline や Step に関しては議論の余地はあまりなさそうです。Stage という単位は別に使わなくても良いのですが、実際に可視化してみると最初の Step が実行されるまでにかなり時間がかかっていて、その内訳も知れた方が良いと感じたので導入しました。</p>
<p>また、階層構造さえあっていれば可視化はできるので、Stage ではなく Job としてこれらを表現してもよかったのですが、CircleCI や GitHub Actions における Job とはかなり別物という感覚があったので Stage として表現しました。</p>
<p>CircleCI や GitHub Actions では Job は1つのコンテナ（もしくは VM）実行環境という単位になっています。そのため異なる Job 間ではボリュームの永続化などは明示的に書く必要があります。CloudBuild においては、1つの Build 内で複数の実行環境を立ち上げることはなく、前の Step で書き込まれたディスクには後続の Step でアクセスすることができます。</p>
<p>Stage がしっくりくるかというとわからないのですが、消去法で決めました。</p>
<h1>実装</h1>
<p>各所要時間をどの Level として送るかが決まったので、実装のステップに入ります。</p>
<p>CloudBuild は、実行の各タイミングで Cloud PubSub にイベントを送っています。PubSub イベントをトリガーに Cloud Run Functions を実行することができるので、今回は Cloud Run Functions で実行することにしました。他の方法としては、定期実行して特定の期間内に実行された CI Pipeline の結果を送るというやり方もありそうですが、パフォーマンス改善タスクに取り組む際にはなるべく早く結果が可視化できた方が良いというのもあり、上記の手法にしました。</p>
<h2>Queue Time</h2>
<p>Queue Time は startTime から createTime を差し引いた時間としています。また、Pipeline の attribute にも queueTime がありますが、GitHub Actions のような良い感じの可視化がされなかったので、Stage としても実装しました。</p>
<p>GitHub Actions の Queue time の良い感じの可視化:<br>
<img src="https://ik.imagekit.io/plaid/97e233cd-f4e8-4928-8c08-220bed39e581/github-actions-queue.png" alt="github-actions-queue.png"></p>
<h2>Status</h2>
<p>Cloud Build における Status と、CI Visibility Pipeline で定義されている Status はちょっと違うので、注意が必要です。</p>
<p>Ci Visibility Pipeline で定義されている status は下記になります。</p>
<table>
<thead>
<tr>
<th>Level</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>Step</td>
<td>success, error</td>
</tr>
<tr>
<td>Stage, Job</td>
<td>success, error, canceled, skipped</td>
</tr>
<tr>
<td>Pipeline</td>
<td>success, error, canceled, skipped, blocked, running</td>
</tr>
</tbody>
</table>
<p>Cloud Build の場合、 <code>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED, EXPIRED</code> があります。</p>
<p>今回のユースケースとしては実行中の Pipeline に関しては対象外としても良いかなと思ったので、完了後のステータス（ <code>SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED</code> ）のイベントが来た時だけ処理を実行するようにしました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>Cloud Build</th>
</tr>
</thead>
<tbody>
<tr>
<td>success</td>
<td>SUCCESS</td>
</tr>
<tr>
<td>error</td>
<td>FAILURE, INTERNAL_ERROR, TIMEOUT</td>
</tr>
<tr>
<td>canceled</td>
<td>CANCELED</td>
</tr>
<tr>
<td>処理しない</td>
<td>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, EXPIRED</td>
</tr>
</tbody>
</table>
<h2>Git</h2>
<p>CI Visibility Pipeline では git というフィールドに git repository の url や commit sha、authorEmail などを入れることができます。sha や repo url は Cloud Build のイベントに入ってるのですが、authorEmail は取り出せなかったので適当に入れました。GitHub API を叩いて commit sha から authorEmail を取得する方法もあると思いますが、実行者が気になったら commit のページに飛べば良いのでそこまでしなくても良いと判断しました。</p>
<h2>ソースコード</h2>
<p>最終的なソースコードは下記のようになります。依存ライブラリをインストールしてビルドすれば別の環境でも動くと思うので、ぜひ試してみてください。注意点としては <code>DD_API_KEY</code> と <code>DD_APP_KEY</code> を secret として Cloud Run Functions で読み込めるようにする必要があるのと、Datadog で us1 以外のリージョンを使っている場合には <code>DD_SITE</code> 環境変数を指定する必要があります。</p>
<pre><code class="language-typescript">/**
 * Cloud Build 終了後に Datadog にイベントを送る
 */

import { PubsubMessage } from '@google-cloud/pubsub/build/src/publisher';
import { google } from '@google-cloud/cloudbuild/build/protos/protos';
import { client, v2 } from '@datadog/datadog-api-client';

type Build = google.devtools.cloudbuild.v1.Build;
type Status = keyof typeof google.devtools.cloudbuild.v1.Build.Status;

export async function main(event: PubsubMessage): Promise&lt;void&gt; {
  const jsonstr = Buffer.from(event.data as string, 'base64').toString();

  const data = JSON.parse(jsonstr) as Build;

  if (!isFinishedStatus(data.status as Status)) {
    console.log('event does not meet conditions.');
    return;
  }

  // pipeline
  const { status, createTime, startTime, finishTime, id, logUrl } = data;
  const triggerName = data.substitutions['TRIGGER_NAME'];
  const commitSha = data.substitutions['COMMIT_SHA'];
  const repositoryUrl = data.substitutions['REPO_FULL_NAME'];
  const queueTime = startTime
    ? new Date(startTime as string).getTime() - new Date(createTime as string).getTime()
    : undefined;

  const configuration = client.createConfiguration();
  configuration.unstableOperations['v2.createCIAppPipelineEvent'] = true;
  const apiInstance = new v2.CIVisibilityPipelinesApi(configuration);
  const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
    body: {
      data: {
        attributes: {
          resource: {
            end: finishTime ? new Date(finishTime as string) : new Date(),
            start: new Date(createTime as string),
            name: triggerName,
            status: getDatadogPipelineStatus(status as Status),
            level: 'pipeline',
            uniqueId: id,
            url: logUrl,
            git: {
              sha: commitSha,
              repositoryUrl,
              authorEmail: 'unknown@example.com',
            },
            partialRetry: false,
            queueTime,
          },
          service: 'cloud-build',
        },
        type: 'cipipeline_resource_request',
      },
    },
  };
  const result = await apiInstance.createCIAppPipelineEvent(params);

  // stage
  const stages = Object.entries(data.timing).map(([key, timing]) =&gt; {
    return {
      id: key,
      startTime: timing.startTime,
      endTime: timing.endTime,
    };
  });

  const stagesIncludeQueueTime = [
    ...stages,
    {
      id: 'QUEUE',
      startTime: createTime,
      endTime: startTime,
    },
  ];

  for (const stage of stagesIncludeQueueTime) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: stage.endTime ? new Date(stage.endTime as string) : new Date(),
              start: new Date(stage.startTime as string),
              name: stage.id,
              status: 'success',
              level: 'stage',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              id: stage.id,
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // step
  for (const step of data.steps) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: step.timing?.endTime ? new Date(step.timing.endTime as string) : new Date(),
              start: new Date(step.timing!.startTime as string),
              name: step.id!,
              status: getDatadogStepStatus(step.status as Status),
              level: 'step',
              id: step.id!,
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'BUILD',
              stageName: 'BUILD',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // image
  for (const image of data.results?.images ?? []) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: image.pushTiming?.endTime ? new Date(image.pushTiming.endTime as string) : new Date(),
              start: new Date(image.pushTiming!.startTime as string),
              name: image.name!,
              id: image.name!,
              status: 'success',
              level: 'step',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'PUSH',
              stageName: 'PUSH',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }
}

function isFinishedStatus(status: Status): boolean {
  return ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT', 'CANCELLED'].includes(status);
}

function getDatadogPipelineStatus(status: Status): 'success' | 'error' | 'canceled' {
  if (status === 'SUCCESS') {
    return 'success';
  } else if (status === 'CANCELLED') {
    return 'canceled';
  } else {
    return 'error';
  }
}

function getDatadogStepStatus(status: Status): 'success' | 'error' {
  if (status === 'SUCCESS') {
    return 'success';
  } else {
    return 'error';
  }
}

</code></pre>
<h1>Datadog CI Visibility でみてみる</h1>
<p>こんな感じで Cloud Build のパフォーマンスを可視化することができました。Critical Path を特定し、最もボトルネックになっている step を効率的に改善することができるようになりました！</p>
<p><img src="https://ik.imagekit.io/plaid/56474a37-da8b-423f-bbf9-965d86aee2c3/datadog-ci-visibility.png" alt="datadog-ci-visibility.png"></p>
<p>具体的な改善ポイントとしては下記のようなものがありそうです。Stage を可視化することで、よりパフォーマンス改善の選択肢が増えると思います。</p>
<table>
<thead>
<tr>
<th>時間がかかっている Stage</th>
<th>改善手段の例</th>
</tr>
</thead>
<tbody>
<tr>
<td>QUEUE</td>
<td>Cloud Build の同時実行数を増やす、Private Pool を使う</td>
</tr>
<tr>
<td>FETCH_SOURCE</td>
<td>リポジトリを分割する</td>
</tr>
<tr>
<td>BUILD</td>
<td>キャッシュを使う、並列化する</td>
</tr>
<tr>
<td>PUSH</td>
<td>イメージサイズを小さくする、Artifact Registry と Cloud Build の実行のリージョンを合わせる</td>
</tr>
</tbody>
</table>
<h1>最後に</h1>
<p>Cloud Build のパフォーマンスを Datadog CI Visibility で可視化する方法を紹介しました。</p>
<p>Datadog は各種 Integration 対応が充実していると思いますが、未対応であってもこんな感じで提供されてる API を使って気軽に実装できるのが嬉しいところです。</p>
<p>Cloud Build と Datadog を使っていて、パフォーマンスの改善をしたいと考えている方がいたら参考にしていただけると幸いです！</p>


この記事は Datadog Advent Calendar 2024 の 18 日目の記事です。 こんにちは、プレイドの Developer Experience & Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は CI Visibility と Split Graphです。

Datadog CI Visibility で Cloud Build のパフォーマンスを可視化する

プレイドでエンジニアをしている塩澤です。今回は MongoDB から BigQuery へのリアルタイムレプリケーションシステムをマネージドサービスのみを用いて開発したので紹介します。

MongoDB to BigQuery: フルマネージドなリアルタイムレプリケーションの実現

<h1>はじめに</h1>
<p>初めまして、<a href="https://github.com/jdkfx">田添春樹</a>と申します。2024年9月から12月までの3ヶ月間、KARTE Webチームでエンジニアとしてインターンシップを行なっておりました。</p>
<p>インターンシップに参加する以前、趣味で関わっていたOSSプロジェクトにおいて、Vueを用いた開発を行なっておりました。その際の開発経験が楽しかったことと、これからもVueを用いて開発を行いたいことなどを、プレイドに勤務している親友と話した際に、このインターンシップに誘っていただきました。</p>
<p>私はどちらかと言えば、縁の下の力持ちとして物事に取り組むことが多く、開発においても、開発者が今後の開発をストレスなく、より良い環境で行えるようにリファクタリングなどを行なってきました。面談の際に、その旨を伝え、インターンシップとして開発体験を向上させるための業務をすることとなりました。</p>
<p>このインターンシップで行った内容は以下のようになっております。</p>
<ul>
<li>KARTEのエレメントビルダーのViteバージョンアップ</li>
<li>KARTEのユーザーリストや行動チェーン、ユーザーストーリーといった機能（以下、これらの機能をまとめてinsight-frontと呼称します。）における、開発体験向上を目的としたViteへの移行と、Vueのバージョンアップやそれらに伴う依存パッケージのバージョンアップ</li>
</ul>
<p>本記事ではインターンシップで行ってきたことの内容について、上記の二点をお伝えします。</p>
<h1>エレメントビルダーのViteバージョンアップ</h1>
<h2>課題</h2>
<p>KARTEの<a href="https://support.karte.io/post/67aMq2qoqXQMw6WaDL22Vl">エレメントビルダー</a>は、顧客⼀⼈ひとりに合わせて、最適なコミュニケーションができるように、顧客の行動に基づいてポップアップ表示などのアクションを作成・カスタマイズできる機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/f1201e44-6886-48d6-ba49-83231770813a/action-editor.png" alt="action-editor.png"></p>
<p>しかし、これまでのエレメントビルダーには以下のような課題がありました。</p>
<ul>
<li>開発環境がメンテナンスされていないため、ここ最近のフロントエンド環境と乖離が生じてきて、開発しにくい状況になってきていた</li>
<li>Viteのバージョンが古いため、KARTEのデザインシステムの導入に特別な対応が必要になる</li>
</ul>
<p>特に、一点目の課題が大きく、これまでのエレメントビルダーの開発環境におけるViteやVitestなどのパッケージはエレメントビルダーが開発されていた当時の状態のままになっておりました。これまでの開発環境のままでも開発はすることができますが、フロントエンド周りの環境は日々変わっていきます。今後新たな機能を実装する際、または新たなパッケージを導入する際、開発環境の遅れによって、それらの新しい機能の実装やパッケージの導入により多くの時間をかけてしまうことになります。</p>
<p>これらの課題を解決するために、エレメントビルダーのViteのバージョンを上げることになりました。</p>
<p>これまでエレメントビルダーで使用していたViteのバージョンは<code>3.2.5</code>で、今回のバージョンアップで<code>4.5.3</code>になりました。これまで使用していたVite 3系から一気にViteの最新バージョンへ上げるのではなく、小さくアップデートを行いたかったため、今回は4系へアップデートしました。</p>
<p><a href="https://v4.vite.dev/">https://v4.vite.dev/</a></p>
<p>また、それに伴って、Vitestのバージョンも上げることとなり、<code>0.24.3</code>から<code>0.34.6</code>にアップデートしました。</p>
<p>これまで使用していたVitest 0系から1系に上げるには、Vite 5系が必要となっており、先述のVite 4系を使う方針のために、1系ではなく0系の最新バージョンへアップデートしました。</p>
<p><a href="https://v0.vitest.dev/">https://v0.vitest.dev/</a></p>
<h2>テストが動かない</h2>
<p>ViteとVitestのバージョンアップを行ったことで、テストが動かなくなってしまったため、関連するパッケージのバージョンアップも行っていきました。</p>
<p>エレメントビルダーは細分化されたモジュールで作られており、それぞれに対応するパッケージの管理が複雑になっています。バージョンを上げたパッケージが他のパッケージのバージョンをサポートしていないことや、メンテナンスされていないパッケージを使用していることなど、複数の要因でテストが動かなくなってしまいました。</p>
<p>たとえば、<code>@testing-library/react-hooks</code>というパッケージでは、React 18で<code>renderHook</code>APIが<code>react-testing-library</code>と<code>react-native-testing-library</code>の両方に追加されたことにより、<code>@testing-library/react-hooks</code>を<code>@testing-library/react</code>に書き換える必要があります。</p>
<p><a href="https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support">https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support</a></p>
<p>他にも、<code>@sveltejs/vite-plugin-svelte</code>というパッケージにおいて、Vitest は基本的に<code>node_modules</code>配下にあるモジュールは<code>alias</code>で設定していなくても、モジュール依存を解決してくれるのですが、テスト内でコンポーネントをレンダーした際に<code>onMount</code>が実行されないというバグを解決するために、以下のように明示的に設定しないといけませんでした。</p>
<pre><code class="language-js">import { defineConfig } from 'vitest/config';
import { svelte } from '@sveltejs/vite-plugin-svelte';
import { dirname, resolve } from 'node:path';

export default defineConfig({
  // ...
  resolve: process.env.TEST ? {
    alias: [{
      find: /^svelte$/,
      replacement: resolve(__dirname, &quot;node_modules/svelte/index.mjs&quot;) 
     }]
  } : {
    alias: {
      '@plaidev/karte-action-sdk/templates': resolve(__dirname, './src/templates.ts'),
    },
  },
  // ...
});
</code></pre>
<p><a href="https://github.com/testing-library/svelte-testing-library/issues/222">https://github.com/testing-library/svelte-testing-library/issues/222</a></p>
<p><a href="https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components">https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components</a></p>
<h2>小さく解決する</h2>
<p>先述の通り、エレメントビルダーは細分化されたモジュールで作られており、それぞれにテストが用意されています。（以下は一部抜粋）</p>
<pre><code class="language-text">.
├── api
├── asset-builder
├── core
│   ├── action-compiler
│   ├── action-sdk
│   └── action-utils
├── front
└── internal
</code></pre>
<p>これらのテストのほとんどが動かなくなってしまったので、それぞれのモジュールごとに小さくテストが通るよう修正を行い、最終的に全てのテストが通るようにパッケージのバージョンアップやパッケージの置き換えを行いました。</p>
<p>パッケージのバージョンアップを行った結果、パッケージの破壊的変更によってテストコードの修正を行う必要がありました。修正を行うためには、どこに問題があるのか探す必要があり、使用しているパッケージのソースコードを実際に動かしてみて、意図的にエラーを発生させ、エレメントビルダーのテストにおける問題のある箇所を発見することができました。</p>
<h1>insight-front開発体験改善</h1>
<h2>課題</h2>
<p>insight-frontを開発する際、他のシステムからイベントを飛ばしてデータを作る必要があり、フロントエンドのデバッグに時間を要するという課題がありました。</p>
<p><img src="https://ik.imagekit.io/plaid/a1d7ef2d-33b6-475a-b520-5a8df50adac6/insight-front.png" alt="insight-front.png"></p>
<p>この部分の課題を解決することで、今後新たな機能を開発する際や修正を行う際に素早く対応できるため、これまで使用されていたWebpackからViteへ移行することになりました。</p>
<p>Viteに移行することによって具体的にどんな点がより良くなるのかというと、開発サーバーの立ち上がりがWebpackよりも早くなるのでデバッグに要する時間が少なくなります。</p>
<p><a href="https://vite.dev/guide/why.html#slow-server-start">https://vite.dev/guide/why.html#slow-server-start</a></p>
<h2>Vite移行に向けて</h2>
<p>WebpackからViteへ移行するために、以下のような手順を踏んでいきます。</p>
<h3>Vue 2.7へアップデート</h3>
<p>insight-frontはVue 2で開発されており、ViteではVueアプリケーションのバンドルをするために、Vueの単一ファイルコンポーネントのサポートを提供している<code>@vitejs/plugin-vue2</code>を導入する必要があります。</p>
<p>insight-frontで使用されていたVueのバージョンは<code>2.6.12</code>だったため、<code>@vitejs/plugin-vue2</code>が要求するVue 2の最新バージョンであるVue 2.7へアップデートする必要がありました。</p>
<p>また、Vue 2はすでにサポートが終了しているため、セキュリティパッチを当てたVue 2を使用しています。</p>
<p><a href="https://v2.vuejs.org/v2/guide/migration-vue-2-7.html">https://v2.vuejs.org/v2/guide/migration-vue-2-7.html</a></p>
<h3>ES ModulesとCommonJSによるデュアルパッケージ化</h3>
<p><code>localDependencies</code>というプレイド独自の依存関係の解決機構を使用しており、ここに使用される社内の共通パッケージはCommonJSでビルドされていました。これまではWebpackを使用してバンドルしていたので、CommonJSで書かれた共通パッケージも問題なくバンドルし、アプリケーションを動作させることが出来ました。（Webpackを用いてバンドルしている場合でも、使用しているパッケージがNode.js依存である場合、手動でpolyfillを挿入するように設定する必要があります。）</p>
<p>しかし、この<code>localDependencies</code>の解決機構を使っていることにより、Viteで共通パッケージのCommonJSの依存解決ができずバンドル出来ないため、これらの共通パッケージをES ModulesとCommonJSでバンドルする必要がありました。</p>
<pre><code class="language-json">&quot;localDependencies&quot;: {
  &quot;@plaidev/xxx-common&quot;: &quot;../../../common&quot;,
  &quot;@xxx/insight-front-common&quot;: &quot;../front-common&quot;
},
</code></pre>
<p>insight-frontにおいて、<code>localDependencies</code>という解決機構で依存解決を行なっている共通パッケージ内には大量のコードが存在しており、その中からinsight-frontを動かすために必要なコードを調査する時間や、それらのコードをES ModulesとCommonJSでデュアルパッケージ化するための時間、実際にES ModulesとCommonJSでデュアルパッケージ化した後に、関連するシステムが動くかどうか確認するための時間など、多くの時間を費やすことになるだろうと予想しました。</p>
<p>ES ModulesとCommonJSによる共通パッケージのデュアルパッケージ化をするには多くの時間がかかってしまうため、Viteの機能を利用してES ModulesとCommonJSでバンドル出来ないか試してみることにしました。</p>
<p><a href="https://vite.dev/config/build-options#build-lib">https://vite.dev/config/build-options#build-lib</a></p>
<h3>Viteでビルドする</h3>
<p>上記に書いた通り、insight-frontを取り巻く依存関係の問題は大きく、それらを解決するために大量に時間を要することが予想されました。また、私自身がフロントエンドについての知識がまだまだ浅く、一気にこれらを解決させようとしてどこに問題が発生しているのか調査すること自体にも多くの時間を使ってしまいました。</p>
<p>この失敗を受けて、小さく小さく課題に取り組むことを意識し、最初からアプリケーションのソースコード全体をビルドさせることは考えないようにしました。まずは、小さなHTMLファイルのビルドから行い、実際にアプリケーションを動かした際に問題がないことを確かめることから始めました。そこにVue 2で書かれた小さなコードを追加するような形で、必要なプラグインなどを細かく追加していくなど、インクリメンタルな実装を行なっていくことで自身のViteに対する解像度も上がってきました。</p>
<p>しかし、ここでインターンシップ期間が終わってしまい、insight-frontをWebpackからViteに移行することが出来ませんでした。複雑な問題が絡み合い、この課題を解くのは難しかったのですが、自身が普段のめり込むことが無いような部分にのめり込み、様々なことを学ぶことが出来ました。</p>
<h1>インターンシップを終えて</h1>
<h2>総括</h2>
<p>インターンシップとして主に二つの内容に取り組んできました。</p>
<p>開発環境をメンテナンスをしないまま、放置してしまうことにより、今後のバージョンアップで大きな障壁となってしまうことを避けるためにも、日頃からメンテナンスを怠らないようにしたいです。</p>
<p>しかし、プロダクトの開発において、メンテナンスをすることにより、本来先に実装したかった内容に遅れが生じてしまうことがあります。その実装の遅れとメンテナンスをすることによる恩恵を考えて、両方を天秤にかけ、どちらがプロダクトにより大きなインパクトを与えられるのか考え続けなければなりません。</p>
<p>そして、目の前の難しい課題に対して、直線的に解決策を取ろうとするのではなく、回り道をしつつ、小さく小さく問題を区切りながら解決に向かうことを意識していきたいです。</p>
<h2>成長</h2>
<p>これまでは、主にPHPを用いたバックエンドの開発を行なっており、フロントエンドの開発は自作のブログや先述のOSSプロジェクトの小さな機能の開発以外ではほとんど触ったことがなく、こんなにもガッツリとフロントエンドの領域にのめりこむのは初めてでした。</p>
<p>フロントエンドの技術について、あまり知識がない状態からキャッチアップを行いつつ、大きな成果を出すことが出来て、とても学びのあるインターンシップだったと感じております。</p>
<p>もちろん、一人では抱えきれない悩みや課題などが生じた際に一緒に解決してくださったメンターの方やKARTE Webチームの方々のおかげだと感じております。</p>
<p>KARTEの強みを理解し、どうすればその強みをプロダクトに機能として実装できるのか。そして、顧客に大きなインパクトを与えられるか、という思考のサイクルを止めることなくプロダクトに向き合っているプレイドの方々の姿勢に感銘を受けました。</p>
<p>そして、インターンシップを行なっていく中で自分に何が足りないのか、プロダクト開発やその会社に属する人間としてどんな視点を持てば良いのか、深く考えることのできたインターンシップでした。</p>
<h2>最後に</h2>
<p>インターンシップ期間中は広島からフルリモートでの勤務をしていました。フルリモートでなかなか顔を合わせてお話しする機会がない中、広島から東京のオフィスに出社した際には、他のインターンシップ生とのランチに誘っていただいたり、多くの方々とお話しさせていただく機会に参加させていただいたりと、社内の雰囲気もとても良かったです。</p>
<p>3ヶ月という短い間でしたが、メンターの方やKARTE Webチームの方々など、多くの方々のおかげで濃密な3ヶ月を過ごすことが出来ました。本当にありがとうございました。</p>
<hr>
<p>プレイドでは開発インターンを募集しています。興味のある方はぜひ下記のリンクからご応募ください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドインターン体験記：開発体験の向上を目指し行なったこと

Developer Experience & Performance チームでエンジニアをしている大矢です。今回は JavaScript の非同期処理で使われている callback を Promise に移行する手法について、具体的な事例をもとに紹介します。

Mongoose の callback を Promise に移行する手法

<p>みなさん、ごきげんよう。プレイドの@akobaです。<br>
プレイドではCXチームのエンジニアとして、プロダクトの機能開発、ならびに弊社のウェブ接客プラットフォームKARTEで提供するアプリケーションの開発を行っています。<br>
今回は、KARTEでできることを広げる試みの一環として、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。<br>
具体的には、ユーザーの閲覧履歴、レビュー／コメント機能、今この記事をxx人が見ていますといった機能を作ってみました。<br>
通常ネイティブアプリ向けとして使われることが多いFirebaseですが、Webブラウザ上でも色々と面白いことができます。<br>
この記事が皆さんの開発の参考になれば幸いです。</p>
<h2>目次</h2>
<ul>
<li>Firebaseとは</li>
<li>Firebaseにデータを貯めていく</li>
<li>ページ内でユーザーの情報を共有する</li>
<li>リアルタイム機能を使う</li>
<li>KARTEを使ってアプリを配信</li>
<li>まとめ</li>
</ul>
<h2>Firebaseとは</h2>
<p><a href="https://firebase.google.com/">Firebase</a>とは、最近大きく注目を集めているMBaaS(Mobile Backend as a Service)、つまりモバイル開発のためのクラウド・ベースのバックエンドサービスです。2014年にGoogleに買収され、Google I/O 2016で新バージョンが発表されました。<br>
ここでのバックエンドとはDB、認証、ストレージ、解析、メッセージングプラットフォームなど（詳細は公式サイト参照）で、主にネイティブアプリ向けのプラットフォームとして提供されています。<br>
ただし、Web用のSDKも準備されており、今回はこのSDKをWebサイト上で使ってみたいと思います。</p>
<p>SDKといっても、Webページに下記のようなタグを貼るだけです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5c996e6-805a-4054-8eaa-d1d6bbab1717/-2016-09-29-7.23.18.png" alt="web-setup-code"><br>
（xxxの箇所はFirebaseのプロジェクトによって異なります。詳細は<a href="https://firebase.google.com/docs/web/setup">こちら</a>）</p>
<p>Firebaseには様々な機能が用意されていますが、今回は<a href="https://firebase.google.com/docs/database/">Realtime Database機能</a>にフォーカスして使ってみます。<br>
この機能、BaaSなので当然なのですが、自分でサーバーを立てる必要がなく、上記のタグを貼るだけでブラウザからアクセス可能なKVSとして利用できます。<br>
DBとしての特徴は主に下記となります。</p>
<ol>
<li>DB全体が1つのJSON treeとして扱える</li>
<li>データの更新時、データを使っている各クライアントにリアルタイムで同期される</li>
<li>オフライン時もクライアント側でデータを保持し、オンラインになった時点でオンラインデータとマージされる</li>
</ol>
<p>1のために、個別のデータを更新するにはそのパスを指定して更新、全体を更新するにはルートパスに大きなJSONを1つ送るだけで済みます。（ただし大きすぎるJSONについてはそのまま送信はできないので、細かく分割して送信する<a href="https://github.com/firebase/firebase-import">ツール</a>が公開されています。）また読み込みの際も、全体のデータが欲しいのか、一部のデータが欲しいのかを、参照するJSONのパスを指定することで細かく指定することができます。<br>
2は色々と面白いことができそうですね。<br>
3もかなり便利そうですが、今回は使いません。</p>
<h2>Firebaseにデータを貯めていく</h2>
<p>では、実際にFirebaseのDBを使ってみましょう。</p>
<p>FirebaseのDBはKVS(Key Value Store)なので、なんらかのキーを軸にデータを集めていくことになります。<br>
キーとして もっともよく使われるのはユーザーID（ユーザー軸）でしょう。それ以外にWebページのURLやWebページ上のアイテム・コンテンツID、もしくは地域やユーザー属性のようなものをキーにしても面白いかもしれません。<br>
今回は、ユーザー軸とWebページ軸の情報をFirebaseに集めることにします。</p>
<p>まず最初にWebページ軸の情報。</p>
<pre><code>var pagePath = 'page/' + encodeURIComponent(location.pathname).replace(/\./g, '%2E');
firebase.database().ref(pagePath)
  .set({
    image: image,
    title: title
  });
</code></pre>
<p>ページのURLパスをキーとして、ページ毎に、そのページのタイトルと画像URLを保存してみます。<a href="http://ogp.me/">Open Graph</a>の値などを入れておくといいですね。<br>
<code>page/</code>の部分はなんでもいいですが、RDBのテーブル名のように、データの種類を区別するためにつけておきます。また、Firebaseのキー名には<code>., $, #, [, ], /</code>は使えないのでパーセントエンコードしておきます。（が、以下では簡略化のためにエンコードのコードは記載しません）</p>
<p>次にユーザー軸の情報。単純に、閲覧したページのURLを保存しておきましょう。</p>
<pre><code>var userPath = 'user/' + userId;
firebase.database().ref(userPath + '/visit/' + location.pathname)
  .set({
    timestamp: parseInt(new Date() / 1000)
  });
</code></pre>
<p>ごちゃっとしていますが、<code>user/[ユーザーID]/visit/[URLパス]</code>に<code>timestamp</code>という値を書き込んでいます。<br>
<code>userId</code>の箇所は、なんらかの形で保持しているユーザー毎のIDを使用します。</p>
<p>ユーザーがページを見るたびにその情報をFirebaseに書き込んでいくと、FirebaseのDBには下記のようにデータが溜まっていきます。</p>
<pre><code>{
  &quot;page&quot; : {
    &quot;%2Fproducts%2Fdetail%2F12&quot; : {
      &quot;image&quot; : &quot;http://xxx.jpg&quot;,
      &quot;title&quot; : &quot;xxx&quot;
    },
    ...
  },
  &quot;user&quot; : {
    &quot;akoba&quot; : {
      &quot;visit&quot; : {
        &quot;%2Fproducts%2Fdetail%2F12&quot; : {
          &quot;timestamp&quot; : 1474968518
        }
      }
    },
    ...
  }
}
</code></pre>
<p>こうやって、ユーザー毎にそのユーザーが見たページのURL（パス）、ページ毎にそのページのタイトルと画像を保存しておくと、最近見たページのリスト（いわゆる閲覧履歴）が表示できます。</p>
<p>まず最初に、自分のユーザー情報を取得します。</p>
<pre><code>firebase.database().ref(userPath)
  .once('value')
  .then(function(snapshot) {
    var myUserData = snapshot.val();
    ...
  });
</code></pre>
<p><code>once</code>とは、このタイミングでデータを一度だけ取得するということです。更新の監視は行いません。</p>
<p>myUserDataには上記のJSONの一部、下記のようなデータが入っています。</p>
<pre><code>&quot;visit&quot; : {
  &quot;%2Fproducts%2Fdetail%2F12&quot; : {
    &quot;timestamp&quot; : 1474968518
  }
}
</code></pre>
<p>このvisit以下の各キーについて、ページの情報を取得すると、過去閲覧したページの画像とタイトルを表示できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/91964ea1-84de-4013-8086-3e5df2208773/-2016-09-28-19.07.08.png" alt="recent_items"></p>
<p>1点注意ですが、当然閲覧履歴はどんどん溜まっていきます。残念ながら、現状FirebaseのDBにはexpireの機能がないようなので、ある程度の数を超えたらtimastampの古いものから消していく等の対応が必要です。</p>
<h2>ページ内でユーザーの情報を共有する</h2>
<p>先ほどの例は、ユーザーを軸に、ページの情報を取得しましたが、その逆も可能です。<br>
たとえば、</p>
<pre><code>firebase.database().ref(pagePath + '/review/' + userId)
  .set({
    nickname: nickname,
    comment: comment,
    starCount: starCount,
    timestamp: parseInt(new Date() /1000)
  });
</code></pre>
<p>のような値を書き込むことで、ページにユーザーレビューを投稿する機能も実装できます。<br>
ユーザーレビューまで行かなくても、書き込みを例えばサイトのスタッフのみに制限しておけば、各ページ、そのページに表示されている商品や記事への、スタッフのコメント機能が実現できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2a0b8dd-d4d3-4a52-8478-60aa1ef0f73f/-2016-09-27-23.09.33.png" alt="staff_comment"></p>
<p>スタッフは、実際に自分のサイトにアクセスして、該当のページでコメントを入力するだけです。<br>
こういった機能はいかにもウェブ接客という感じですね。</p>
<h2>リアルタイム機能を使う</h2>
<p>Firebaseの特長でもある、リアルタイムのデータ同期機能を使ってみましょう。<br>
今度もページ軸で、</p>
<pre><code>firebase.database().ref(pagePath + '/visit/' + userId)
  .set({
    timestamp: parseInt(new Date() /1000)
  });
</code></pre>
<p>そのページを見ているユーザーをどんどんページ情報に追加していきます。<br>
ページ側では、そのページの情報を下記のように取得します。</p>
<pre><code>firebase.database().ref(pagePath + '/visit')
  .on('value', function(snapshot) {
    updateUserCount(snapshot.numChildren());
  });
</code></pre>
<p>先ほどの<code>once</code>と違い、<code>on</code>では対象の値が更新されるたびに都度、指定した関数が実行されます。<code>numChildren</code>でデータ内の子要素の数を取得し、<code>updateUserCount</code>で表示するユーザー数の値を更新します。<br>
こうしておくと、表示されているユーザー数が、新しくユーザーが来訪するたびに増えるようになります。</p>
<p>ということで、今このページに出ている↓は、実際にFirebaseで作っています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7e1e941a-c86e-4a93-8cd1-8c06e596093f/-2016-09-28-18.57.14.png" alt=""></p>
<p>なんか出てたけど消しちゃったよという方は、このページをリロードいただくともう一度出るかと思います。</p>
<p>こちらについても、timestampをチェックして一定時間以上前のユーザーは削除していく等の対応が必要です。このページに設置してあるものについては、ページの閲覧から10分以上経過したユーザーを削除しています。</p>
<h2>KARTEを使ってアプリを配信</h2>
<p>最後に、こうやって作ったアプリケーションを、弊社のウェブ接客プラットフォームKARTEで実際に配信してみます。<br>
上記のサンプルでは、ユーザー軸、ページ軸ともFirebaseのDBを使ったのですが、KARTE自体がユーザー軸の解析を行っているので、ユーザー軸のデータの管理はKARTEに任せることができます。<br>
したがって、KARTEを使って上記のアプリを配信する際は、下記のような役割分担となります。</p>
<ul>
<li>KARTE：いつ・誰に・どうやって配信するかを制御。ユーザー情報を管理</li>
<li>Firebase：ページ毎の情報を管理</li>
</ul>
<p>KARTEでは、通常あらかじめ用意されたテンプレートを利用し、色やテキスト、画像等を差し替えるだけでコンテンツが配信可能です。しかし、もちろんフルカスタマイズすることも可能で、HTML、CSSに加えてJavaScriptの実行も可能な自由度の高いプラットフォームとして作られています。<br>
したがって、今回のような外部のサービスを利用することも、そのためにそのサービスのタグを呼び出すことも可能です。また、今回の記事では触れていませんが、いわゆるウィジェットを作る用のAPIも用意されています。</p>
<p>実際に作成しているエディタの画面です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1462c55a-bbfe-4b20-b725-232def824886/-2016-09-27-16.44.49.png" alt=""><br>
HTML、CSS、JavaScriptが自由に編集できるので、ここにFirebaseを使用するコードを書きます。</p>
<p>先ほどご紹介した、このページで表示しているユーザー数のカウンターも、KARTEを使って配信しています。</p>
<h2>まとめ</h2>
<p>最後は少し駆け足になってしまいましたが、Firebaseを使って簡単にWebサイト上で動作するリアルタイムアプリケーションが作れる様子、またそれをKARTEを使ってWebサイト上に自由に配信できる様子が伝わりましたでしょうか。<br>
実際、Firebaseでアプリケーションを開発する際には、事前に用意する必要があるものもほとんどなく、思い立ったタイミングでサクッと簡単に機能を実装できてしまいます。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" id="wantedly-visit-buttons-wjs" 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>


今回は、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた | PLAID engineer blog

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

<p>こんにちは。プレイドインターンの岡田です。</p>
<p>2月初めごろからエンジニアのインターンをさせていただいています。<br>
未経験で飛び込んだエンジニアでしたが、優しく面白い社員さん達に技術を教わりながらbugfixや機能追加などのお仕事をさせていただいてます。</p>
<p>さて、今回はプレイドの講演があったので、9月13日(火)に慶應義塾大学 日吉キャンパスで開幕した<a href="http://db-event.jpn.org/webdbf2016/index.html">WebDB Forum 2016</a>に参加してきました。その様子をご紹介します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ac15a42d-a576-45ce-a1ae-f45aeae42bc1/kanban-1.jpg" alt=""></p>
<h2>WebDB Forumとは</h2>
<p>WebDB Forumは情報処理学会データベースシステム研究会、日本データベース学会、電子情報通信学会データ工学研究専門委員会が主催で、WebとDB技術に興味のある研究者、大学院生、学部生、企業やオープンソースコミュニティの技術者が最新研究動向や成果について議論し、交流を行うイベントです。</p>
<p>参加者は例年300から400人で、半数以上はWebとDB技術において最先端の研究を行っている大学院生・学部生のようです。</p>
<p>プレイドはこのイベントのスポンサーをさせてもらっているので、受付後にもらえる紙袋やパンフレットの裏に社名が載っています！Googleや東芝と並んでいるのが嬉しいですね！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d862d412-986e-47a9-a635-aa28e0080d9e/IMG_8576.jpg" alt=""></p>
<h2>WebDB Forumの様子</h2>
<p>テーマはビッグデータ、IoT、機械学習、データ分析、データ構造など様々で、テーマごとにいくつかの会場に分かれて同時に複数のセッションが行われていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a152a6f-6d04-4002-9354-99b750da29eb/---2016-09-13-13-54-20.jpg" alt=""><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4899c171-7d8f-4c68-a894-113d7d18e1fc/---2016-09-13-12-35-04.jpg" alt=""></p>
<p>技術報告のほかに招待講演「ビッグデータと秘密計算」と「データ処理基盤」のセッションを聴講しましたが、どちらも質疑応答の時間にアツい議論が交わされていて圧倒されました。</p>
<p>休憩時間には大会議室前で飲み物と軽食が提供され、企業の方と学生が交流している様子や、聴講を終えた人たちがコーヒーを飲みながら意見を交わしている様子などが見受けられ、とてもいい雰囲気が漂っていました。</p>
<p>学生なら無料で参加できますし(学生証提示が必要です)、先生方の研究発表や企業の方の技術報告などが聞けて交流もできるなんて、とても素敵なイベントです。WebやDB技術に興味のある学生は次回、参加してみてはいかがでしょうか。</p>
<h2>プレイドの技術報告紹介</h2>
<p><a href="http://blog-plaid.com/event/2642/?draftsforfriends=7UMtQCI4RFrXGZAcwN4sUDkz8aMNHORC">「GCP NEXT World Tour in Tokyo」でプレイドのGCP活用事例を紹介</a>した@makinoyが「ビッグデータの高速・分散処理」というテーマでKARTEの解析エンジンについて技術報告をしました。(当ブログでも<a href="/streaming-algorithm/">大規模データを解析するストリーミングアルゴリズムをサクッと見てみる</a>の記事を書いています)</p>
<p>タイトルは <strong>「大規模分散リアルタイム解析エンジン Brook」</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0dec0269-574a-40b1-a62f-91662015435a/P9130345.jpg" alt=""></p>
<p>私たちが提供している「KARTE」は、Webサイトへの訪問者をリアルタイムに可視化し、会員登録や購買に繋げるためのウェブ接客を可能にするサービスです。</p>
<p>KARTEはリリースから1年半で累計ユーザー数<strong>5億UU</strong>を解析してきました。</p>
<p>今回は、そのKARTEを支える独自解析エンジン「Brook (ブルック)」の紹介をします。</p>
<p>Webサイト上で現実のようなコミュニケーションをするためには、 <strong>「いま」の来訪者がどういう人で、どういう行動をしているのか</strong>を知る必要があります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2e5045c6-5827-4b31-ae18-25f1a1090447/---2016-09-13-14-54-11.jpg" alt=""><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6f213078-db8c-483d-a6a5-89b43a3b4153/---2016-09-13-14-55-35.jpg" alt=""></p>
<p>それを実現するためには最新のユーザーの解析結果を計算し、結果に応じたアクションを決定するための時間を<strong>0.x秒</strong>にしなければなりません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/afdc84b2-5736-429c-a143-47f0bcaa48e8/P9130347-2.jpg" alt=""></p>
<p>通常、データの解析には大きく2つの方法があります。</p>
<ul>
<li><strong>数時間〜数十秒で大量</strong>のデータをMapReduceする<strong>バッチ処理</strong>
<ul>
<li>BigQuery、 Prest、Spark、Hadoop</li>
</ul>
</li>
<li><strong>1秒以内で直近の短期間少量</strong>のデータをMapReduceする<strong>ストリーミング処理</strong>
<ul>
<li>Spark Streaming、Storm</li>
</ul>
</li>
</ul>
<p>これらの技術では、<strong>Web上でリアルのようなおもてなしをするために1秒以内に大規模な蓄積データの解析結果を返すこと、またその結果を使ったアクションの実行を可能にしたいという想い</strong>を実現することができませんでした。</p>
<p>そこで、それを可能にするために開発したのが「Brook」です。</p>
<p>Brookでは<strong>あらかじめ解析軸を一つだけ定義しておく</strong>ことによって次のことを可能にしています。</p>
<ul>
<li>実時間(秒以内)で、イベントログ送信と同期的に結果整合性のある解析結果に基づいたアクションができる</li>
<li>解析軸は固定だが、スキーマレスな解析、次元数が多い大きめのデータを扱える</li>
<li>全てが分散化されているので大規模のデータを扱えスケーラブルである</li>
</ul>
<p>解析軸を複数設けずに1つに制限することで、<strong>0.x秒で全データの解析処理を行う</strong>ことができ、KARTEでのリアルタイム接客が可能になっているのです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d08565a2-5d40-4c83-ad48-017346c27445/P9130346-1.jpg" alt=""></p>
<p>20分の発表でしたが、他にもデータフロー、Hadoopと比較したBrookの特徴、スキーマレス統計処理、解析に用いているアルゴリズムなど、盛りだくさんの内容でした。<br>
学生さんをはじめ、聴講に来ていただいた方々ありがとうございました！</p>
<p>以上、WebDB Forumとプレイドの技術報告の様子をご紹介させていただきました。</p>
<p>KARTEやBrookのことを少しは伝えられたでしょうか。<br>
今回はあまり紹介できませんでしたが、KARTEやBrookの技術をもっと知りたい方は、ぜひプレイドのオフィスに遊びに来てください！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>


WebDB Forum 2016でKARTEを支えるリアルタイム解析エンジン「Brook」の発表をしてきました。

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました | PLAID engineer blog

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました

<p>こんにちは。プレイドの@sdaikichiです。現在のトレーナーレベルは22、捕まえたポケモンは103種です。</p>
<p><a href="/2016_08_24_uitest_automation/">前回の@positiveflatの記事</a>ではプレイドにおける自動テスト環境をご紹介しました。</p>
<p>今回は、プレイドが</p>
<ul>
<li>__40通り以上の環境__を対象に</li>
<li>__すべて自動__で</li>
<li>ついでに__CircleCIのコンテナリソースもそんなに使わない__で</li>
</ul>
<p>マルチブラウザテストを実現している環境についてご紹介します。</p>
<h2>目次</h2>
<ul>
<li>なぜマルチブラウザテストが必要なのか</li>
<li>BrowserStackの紹介</li>
<li>運用してみてわかったコツ</li>
<li>まとめ</li>
<li>最後に</li>
</ul>
<h2>なぜマルチブラウザテストが必要なのか</h2>
<p>KARTEをお客様が利用する際には、来訪者をトラッキングしたり接客サービスを表示するためのscriptタグをお客様サイトに埋め込んでいただきます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ae5043c1-f735-4ca2-94e4-98f14d0f5371/2dd29a3e-b556-4503-afe4-04ac37414d8c.png" alt=""><br>
(接客サービス配信のイメージ)</p>
<p>お客様サイトには当然様々な環境(OS,ブラウザ,端末...)の来訪者がいらっしゃいます。</p>
<p>その際に特定のブラウザでのみ意図した挙動をしない、といった事態は当然避ける必要があります。<br>
世のフロントエンドエンジニアの皆様はIE対応というワードを聞いただけで__仕事を放り投げて目黒川にミニリュウを捕りに行きたくなる衝動に駆られる__かと存じますが、KARTEではそうはいきません。</p>
<p>全ての環境をトラッキングや接客サービス配信の対象としているわけではありませんが、どんな環境でもScriptの実行はされるため、古いブラウザとはいえエラーの発生などは防ぐ必要があります。</p>
<p>例えば有名なのがこちら。この構文が紛れ込んでしまうだけでIE6,7でSyntaxErrorが発生してしまいます。</p>
<pre><code>var data = { hoge:1, fuga:2, piyo:3, }; // オブジェクトリテラル末尾のカンマ
</code></pre>
<p>エンジニアが気をつけていても、例えば依存ライブラリの更新などでこういったエラーが入り込む可能性があります。<br>
かといってこういったエラーにエンジニアが過度に敏感になると開発スピードが著しく落ちてしまいます。</p>
<p>そこで、これまであったトラブルや考えうるケースを抽象化し、CircleCI上でマルチブラウザのテストを行おう！ということになりました。</p>
<h2>BrowserStackの紹介</h2>
<p>マルチブラウザテストの実行には<a href="https://www.browserstack.com/">BrowserStack</a>の<a href="https://www.browserstack.com/automate">Automate</a>を利用しています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf010a08-183d-4aec-b779-074ac181b4e8/afefb92d-4bda-4f9f-a967-8dc6cc9d8c6e.png" alt=""><br>
このサービスの特徴として</p>
<ul>
<li>
<p><a href="https://www.browserstack.com/list-of-browsers-and-platforms?product=automate">かなり自由度の高い組み合わせのOS/ブラウザ/端末が用意されており</a>、設定ファイルに追記するだけで簡単にテスト対象を追加できます。</p>
</li>
<li>
<p>管理画面も非常に充実しており、Selenium testではなんと <strong>実行画面を全て録画し、動画として管理画面上で再生することができます</strong>。<br>
これにより不便になりがちなCI環境のSelenium Testのデバッグが格段に行い易くなりますし、コマンドラインに表示されるテスト結果からはわからない各ブラウザでの細かい表示の違いなどにも気付きやすくなります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/daff3600-92f5-4f18-9a1f-d35592fedcce/1064fcae-374b-4b3e-b823-0c9794020dc4.png" alt=""></p>
</li>
<li>
<p>Javascript Testing(ブラウザ上で行うユニットテスト)、Selenium Testing(Selenium webdriverを利用したUIのテスト)に対応しています。</p>
</li>
</ul>
<p>テスト対象はブラウザ上で動作するJavascriptですが、メソッドごとのユニットテストはJavascript Test、接客サービスの表示・操作などUI的な部分はSelenium Testと、観点によりテストを分けています。</p>
<h2>Javascript Test</h2>
<p>BrowserStackのJavascript Testを利用するにあたり、様々なライブラリが公開されています。<br>
https://www.browserstack.com/javascript-testing-api<br>
プレイドでは<a href="https://github.com/browserstack/browserstack-runner">BrowserStack Runner</a>を利用しています。</p>
<p>BrowserStack Runnerはjsonの設定ファイルに</p>
<ul>
<li>実行するテスト対象ファイル</li>
<li>テストフレームワーク(mocha, jasmine, qunit)</li>
<li>対象ブラウザ</li>
</ul>
<p>などを指定するだけでテストを実行してくれるため、簡単に導入することができます。</p>
<p>jsonの設定ファイルを切り替えれば、たとえばサービスの対象ブラウザ用のテストと非対象ブラウザ用のテストを用意して、それぞれ別に実行することができます。</p>
<p>target.json</p>
<pre><code class="language-json">{
    &quot;username&quot;: &quot;yourusername&quot;,
    &quot;key&quot;: &quot;youraccesskey&quot;,
    &quot;test_path&quot;: &quot;target_browser_test.html&quot;,
    &quot;test_framework&quot;: &quot;mocha&quot;,
    &quot;browsers&quot;:[
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Firefox&quot; , &quot;browser_version&quot;: &quot;47&quot;},
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Chrome&quot;, &quot;browser_version&quot;: &quot;51&quot; },
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Edge&quot;, &quot;browser_version&quot;: &quot;13&quot; }
    ]
}
</code></pre>
<p>no_target.json</p>
<pre><code class="language-json">{
    &quot;username&quot;: &quot;yourusername&quot;,
    &quot;key&quot;: &quot;youraccesskey&quot;,
    &quot;test_path&quot;: &quot;no_target_browser_test.html&quot;,
    &quot;test_framework&quot;: &quot;mocha&quot;,
    &quot;browsers&quot;:[
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;IE&quot; , &quot;browser_version&quot;: &quot;7.0&quot;},
        { &quot;os&quot;: &quot;OS X&quot;, &quot;os_version&quot;:&quot;El Capitan&quot;, &quot;browser&quot;: &quot;Safari&quot;, &quot;browser_version&quot;: &quot;9.1&quot; },
        {&quot;os&quot;: &quot;ios&quot;, &quot;os_version&quot;: &quot;9.3&quot;, &quot;device&quot;: &quot;iPhone 6S&quot;},
    ]
}
</code></pre>
<p>設定ファイルはBROWSERSTACK_JSONという環境変数を読みにいきます。<br>
CircleCIではコマンド実行時の環境変数をcircle.ymlで簡単に指定することができるので、以下のように記述すればOKです。</p>
<pre><code class="language-yml">test:
  override:
    browserstack-runner:
      BROWSERSTACK_JSON: target.json
    browserstack-runner:
      BROWSERSTACK_JSON: no_target.json
</code></pre>
<p>実行すると管理画面にはこのように結果が表示されます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3a74810e-8958-499d-8678-1ea451173cf1/7741e0d3-ab45-4fa2-bebf-7683fde93f07.png" alt=""></p>
<h2>Selenium test</h2>
<p>Selenium testは、自サーバに用意したテストページにアクセスして行っています。<br>
このページにはお客様にサイトに埋め込んでいただくScriptが置かれており、実際の接客サービスの配信やエラーの有無などを確認することができます。</p>
<p>BrowsesrStackからローカル(この場合CircleCIのサーバー)にアクセスさせるために<a href="https://www.browserstack.com/local-testing#command-line">BrowserStack Local</a>をダウンロードし、実行しておきます。</p>
<pre><code class="language-YAML">dependencies:
  pre:
    - cd /usr/local/bin;
    sudo wget &quot;https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip&quot;;
    sudo unzip BrowserStackLocal-linux-x64.zip;
    sudo rm BrowserStackLocal-linux-x64.zip;
test:
  pre:
    - /usr/local/bin/BrowserStackLocal youraccesskey:
      background: true
</code></pre>
<p>テストコードの中でBrowserStackを利用するようにselenium webdriverのcapabilityを指定します。</p>
<pre><code class="language-coffee">CAPABILITIES = [
  { os: 'Windows', os_version:'10', browserName: 'Edge'}
  { os: 'Windows', os_version:'10', browserName: 'IE', browser_version: '11.0' }
  { os: 'OS X', os_version:'El Capitan', browserName: 'Safari' }
  { os: 'OS X', os_version:'El Capitan', browserName: 'Firefox' }
  { browserName: 'iPhone', platform: 'MAC', device: 'iPhone 6S Plus', emulator: true } #emulator: trueの理由は後述
  { browserName: 'iPhone', platform: 'MAC', device: 'iPhone 6S', emulator: true}
]

CAPABILITIES.forEach (capability) -&gt;
  before -&gt;
     @driver = new webdriver.Builder()
        .usingServer('http://hub-cloud.browserstack.com/wd/hub')
        .withCapabilities(capabilities)
        .build()
  #以下テストケースを記述。
  #ローカルへのアクセスが発生する部分のURLはlocalhostでOK
</code></pre>
<h2>運用してみてわかったコツ</h2>
<h3>BrowserStackでのテスト並列化</h3>
<p><a href="/2016_08_24_uitest_automation/">前回の記事</a> ではCircleCIのコンテナ追加による並列化・高速化について触れました。<br>
BrowserStackのSeleniumテストも、ローカルやCIで行う場合と同様、時間がかかります。<br>
しかしながらBrowserStack AutomateのSelenium Testは実行はBrowserStackのサーバ上で行われるため、手元のリソース(CircleCiのコンテナ)は必要ありません。</p>
<p>逆に言いますと、ボトルネックになるのはBrowserstack側の並列上限数です。<br>
1〜25の並列数で<a href="https://www.browserstack.com/pricing">Pricingが用意されています</a> 。サービス規模やリポジトリへのpush頻度にあわせて選ぶと良いでしょう。</p>
<p>プレイドでは契約した並列数に合わせてCircleCI上でテストを__すべてバックグラウンドで実行する__shell scriptを記述し、circle.yml上で実行しています。</p>
<h3>Mobileは自由度低め</h3>
<p>Mobileのテスト環境はPCに比べ、自由度が若干落ちます。<br>
PCがOS/Browser、それらのバージョンを自由に組み合わせて使えるのに対して、Mobileは端末/OS/Browser及びそれらのバージョンは固定です。それでも圧倒的なバリエーションですが。<br>
また、最近エミュレーターではなく実機でのテストがリリースされたようですが、こちらを試してみたところまだ動作が不安定だったため、プレイドでは導入を一旦見送っています。（これがSelenium Testでのemulator:true の理由）</p>
<h3>Retry機構は必要</h3>
<p>BrowserStackではたまにインスタンス・エミュレータの起動に失敗することがあるようで、1ケースも実行されずタイムアウトで落ちることがあります。<br>
そのため、プレイドでは各環境のテストが失敗した際には3回までのRetryを行っています。<br>
ここは開発速度とのトレードオフで現在も試行錯誤中です。</p>
<h2>まとめ</h2>
<p>以上、プレイドにおけるマルチブラウザテストについてご紹介いたしました。<br>
<code>{ os: 'OS X', os_version:'Snow Leopard', browserName: 'Firefox' }</code>  のような、シェアの低さゆえにもし問題が起こるとしたらかなり気付くのが遅れそうな環境でも手軽にテスト対象に加えられるようになったのは大きいと思います。</p>
<p>もちろん、まだまだテストケースをはじめテスト環境も改善を加えていきます。</p>
<p>ウチはこんなことやってるよ！といった事例がございましたらぜひぜひシェア時にコメントくださいませ！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<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>


CircleCI上で、BrowserStackを利用したマルチブラウザJavascript Test,Selenium Test を実現している方法についてご紹介します。Selenium webdriver, CircleCI, BrowserStack

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する| PLAID engineer blog

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

<p>こんにちは。プレイドの野田(<a href="https://twitter.com/positiveflat">@positiveflat</a>)です。<br>
弊社株式会社プレイドでは、ウェブ接客プラットフォームの<a href="https://karte.io/">KARTE</a>というサービスを開発・提供しています。今回は、私たちのチームの開発方針に触れ、その方針を実現するための取り組みの一部として行っている、我々の製品の品質を維持するGUIテストの仕組みについてご紹介いたします。</p>
<h2>目次</h2>
<ul>
<li>プレイドの開発方針とGUIテストの位置付け</li>
<li>GUIテストの自動化が進むにつれて起こる問題</li>
<li>CircleCI上でのテストの並列実行による総実行時間の短縮</li>
<li>CircleCI Enterpriseの導入によるテストの高速化</li>
<li>Ghost Inspectorを使ったGUIテストスクリプト開発の高速化</li>
<li>課題</li>
<li>最後に</li>
</ul>
<h2>プレイドの開発方針とGUIテストの位置付け</h2>
<p>弊社の開発チームでは、以下の方針のもと、フラットな組織でスピード感のある開発を目指しています。</p>
<ul>
<li>全員が自分で判断する</li>
<li>全員がゼロベースで考える</li>
<li>全員が成長する</li>
</ul>
<p>これらの実現のために、あえてマネジメントを置かずに自由でフラットなチーム体制で開発を行っています。</p>
<p>スピードを重視したまま各メンバーが自走するには、失敗を許容し、トライアンドエラーを許容する文化が必要であると考えています。とにかく試してみて、失敗したら考え直します。</p>
<p>一方で、お客様に安心して使っていただくために、当然品質は担保しなければなりません。KARTEは現在、大企業から中小企業、地方の商店まで、多数のお客様に導入いただいております。</p>
<p>私たちは日々KARTEの新機能の追加や既存機能の改善を行っており、ほぼ毎日本番環境に変更を反映させています。</p>
<p>本番環境に反映させた変更に問題があると、直接お客様の業務に影響を与える可能性があります。また、接客サービスの配信に関わる箇所に関しては、お客様のサイトを閲覧している来訪者にも正しく接客ができなくなる可能性があります。</p>
<p>ユーザーに安定的にサービスを提供し、一方で開発のスピードを高速化するためには、トライアンドエラーのサイクルの中に品質を保証する仕組みを導入していく必要があります。</p>
<p>そこで、我々は重要なシナリオに関してはGUIテストの自動化を行い、正しくアプリケーションの操作が行えることを自動でテストできるような仕組みを作っています。</p>
<h2>GUIテストの自動化が進むにつれて起こる問題</h2>
<p>日々の開発の中で、追加した変更が生む欠陥をできるだけ早期に発見できるようにするために、リモートブランチに変更がpushされる度にCIツールのプロセスが回り、ユニットテスト（UT）や自動化されたGUIテストが流れるようにしています。</p>
<p>ちなみに、GUIテストはSelenium webdriverを使用してテストスクリプトを書いています。リリース時にはCircleCI上でproduction buildを作成したりもしていますが、これについての説明は本記事の主題と外れるので割愛します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eba4a7e4-148a-4033-8ab6-6e3a02ecfff2/flow-1.png" alt=""></p>
<p>自動化されたGUIテストを流すことには、以下のようなメリットがあります。</p>
<ul>
<li>人手よりも短時間でテストを実行することができる</li>
<li>人手では気が付きにくいバグも発見することができる</li>
<li>regressionの早期発見ができる</li>
</ul>
<p>一方で、GUIテストの自動化が進むにつれて、以下のような問題も起きます。</p>
<ul>
<li>テストコードが長くなると、テストを流すのに時間がかかり、テスト待ちが起きる</li>
<li>UIを変更した際に、テストコードのメンテナンスに時間がかかる</li>
</ul>
<p>弊社では、上記の課題を解決するために、様々な取り組みをしてきましたので、ここからはその取り組みを紹介します。</p>
<h2>CircleCI上でのテストの並列実行による総実行時間の短縮</h2>
<p>弊社では、上でも触れたように、githubのブランチへのpushごとにCircleCIのプロセスが走るようにしています。その中でGUIテストとUTが流れ、そのブランチを紐付けたPull Request上にテストの結果を表示して、レビュー前に確認できるようにしています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/045c0a75-c978-42fa-974a-191da5603361/CIProcess-1.png" alt=""></p>
<p>CircleCIの並列化は、CircleCIの管理画面でコンテナ数を増やした後に、circle.ymlで並列実行したいコマンドに以下のようにオプションを渡すだけで簡単にできます。</p>
<pre><code class="language-yml">test:
    override:
        [並列実行したいコマンド]:
           parallel: true
</code></pre>
<p>(参考: https://circleci.com/docs/parallel-manual-setup/ )</p>
<h2>CircleCI Enterpriseの導入によるテストの高速化</h2>
<p>テストやビルド、デプロイのためのCIツールとして、<a href="https://circleci.com/enterprise/">CircleCI Enterprise</a>を使用しています。当初はCircleCIのコンテナ数ごとの課金の通常プランを使用していましたが、テストの実行時間に課題がありました。</p>
<p><a href="https://codeship.com/">codeship</a>や<a href="https://travis-ci.org/">Travis CI</a>などの他のCIツールも試してみましたが、現在はマシンスペックをコントロールすることができるCircleCI Enterpriseを導入しています。</p>
<p>CircleCI Enterpriseですと、コンテナは独自にインスタンスを立てて管理する必要がありますが、pushが少ない深夜はインスタンス数を減らすなど、独自に工夫して管理しています。</p>
<h2>Ghost Inspectorを使ったGUIテストスクリプト開発の高速化</h2>
<p>新しい機能が頻繁に追加されたり、既存の機能が頻繁にアップデートされたりすると、更新すべきGUIテストのスクリプトが多くなり、更新が追いつかなくなります。</p>
<p>そこで、Ghost Inspectorというサービスを使い、テストスクリプト作成を簡易化する取り組みにもチャレンジしています。Ghost InspectorはSelenium IDEベースのウェブサービスで、実際の画面操作をレコーディングして、テストケースに落とし込むことができます。</p>
<p>Ghost Inspectorでは、下図のようにChromeの拡張機能を使ってレコーディングをスタートすることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/da4a6914-c5dc-4801-8574-5d4a589bf0f7/GI1-2.png" alt=""></p>
<p>レコーディングしたテストはAPI経由で実行可能なので、CircleCIなどのCIツールからも呼び出すことが可能です。  また、テスト結果はビデオで録画されているため、テストが失敗した場合はどこでテストが失敗したかを確認することができます。</p>
<p>ただし、CircleCIで使用しているインスタンスはプライベートネットワーク上にあるため、Ghost Inspectorからそのままアクセスすることはできません。</p>
<p>通常プランのCircleCIのインスタンスを使用する場合は、<a href="https://ngrok.com/">ngrok</a>などを利用してトンネルを掘り、外からアクセスを可能にする方法が便利です。CircleCIから実行する場合のcircle.ymlは、大まかに以下のようになります。</p>
<pre><code class="language-yml">test:
  override:
    - [環境変数の設定やビルドの設定コマンド];
    - [KARTE(テスト対象サービス)の起動コマンド];
          background: true
    - npm install ngrok -g #ngrokのインストール
    - ngrok authtoken &lt;auth_token&gt; #authtokenの設定
    - ngrok http -subdomain=&lt;testhostname&gt; 8020;
          background: true
    - sleep 120
    - curl &quot;https://api.ghostinspector.com/v1/suites/&lt;suite name&gt;/execute/?apiKey=&lt;api_key&gt;&amp;startUrl=https://&lt;testhostname&gt;.ngrok.io/&quot; &gt; ghostinspector.json
    - if [ $(grep -c '&quot;passing&quot;:false' ghostinspector.json) -ne 0 ]; then exit 1; fi
      fi
</code></pre>
<p>このサービスの便利なところは、レコーディングを使ってテストを追加するGUI操作ができれば誰でもテストを作ることができるようになるところです（ただし、実際はUIの更新の待ち時間の調整など、微調整が必要でした。）。</p>
<p>最終的にはテストコードを書いた方が良い場合でも、新しい機能や変更があった機能に対してGUIのテストをまず早い段階で用意しておくことは、回帰テストとしては有効だと考えられます。</p>
<h2>課題</h2>
<p>以上のように、プレイドでは攻めの開発方針を実現するために、CIによるテストの自動化など様々なことに取り組んでおります。</p>
<p>しかし、テストカバレッジは今後も上げていかなければならないですし、それと共にテストの実行時間は長くなるので、依然として課題は残ります。レコーディングによるテスト自動化も、レコーディング後に継続的に実行できるように微調整が必要なため、なかなかうまくフローに組み込めないなどの課題もあります。</p>
<p>今後もこれらの課題の解決の解決に取り組みつつ、開発方針を維持できるような仕組みづくりをしていきたいと考えています。</p>
<h2>最後に</h2>
<p>テスト自動化に関しては、この他にもPCやスマートフォンなどの複数端末上でのテストを自動化し、並列実行する取り組みなども行っていますが、それについても後日このブログで紹介させていただきます。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<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>


スピード重視の開発体制を実現するために、KARTEの開発で取り組んでいるテスト自動化について紹介します。Selenium webdriver, CircleCI, Ghost Inspector

スピード重視の開発体制を実現するためのUIテスト自動化 | PLAID engineer blog

スピード重視の開発体制を実現するためのUIテスト自動化

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b1a2c506-1fcb-4018-910c-f4b365481cf1/80eb8949-86ff-4ffd-a522-c5fb93ff2926.jpg" alt="DSC00055.jpg (1.4 MB)"></p>
<p>本日は8/3(水) に開催しました「【FiNC×プレイド】Machine Learning Meetup #1」のレポートをお届けしたいと思います！<br>
機械学習を用いた画像認識の話、チャットBotの話等、面白い内容でした！</p>
<h2>発表内容</h2>
<ul>
<li>食事指導を機械学習技術で助ける話 (FiNC 小林さん)</li>
<li>ちゃんと使えるBotについて考える (プレイド CTO 柴山)</li>
<li>いまさら聞けない機械学習の評価指標 (dr_paradi さん)</li>
<li>データマイニングやってて思うこと (おおとや さん)</li>
</ul>
<h2>食事指導を機械学習技術で助ける話</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f98743bb-41f3-4d72-9645-8c34d8558cf8/9d316b23-3cda-4231-adef-862ccc5a06d9.jpg" alt="DSC00030.jpg (895.4 kB)"></p>
<p>まずFiNC 小林さんから「食事指導を機械学習技術で助ける話」についてお話頂きました。<br>
FiNCさんでは機械学習に力を入れておられ、<a href="http://www.nikkei.com/article/DGKKZO06187280X10C16A8TI5000/">ＡＩ特化の研究所を新設</a>されるそうです！</p>
<div style="width: 100%;">
<script async class="speakerdeck-embed" data-id="287f253add1f423496e837716ddf9d48" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>FiNCさんは、アプリを通じてダイエットのマンツーマン指導を受けることができるサービスを提供されています。その中で、機械学習を用いてユーザーが送った食事の写真の内容を自動で認識したり、食事の内容の偏りや睡眠、体重の時系列変化に異常があったりした際に自動でそれを検知するという取り組みをされているそうです。</p>
<p>どのような食べ物が写っているかに関しては、畳み込みニューラルネットワーク(CNN; Convolutional Neural Network)を用いて行っているそうです。また、Faster R-CNN; Faster Regions with Convolutional Neural Networkを用いて一つの写真の中に何種類の食べ物が写っているかを認識させ、食事内容をより高度に認識させることを検討されているそうです。</p>
<p>今後はさらに、Mechanical Turkを使って教師データを作成したり、自動で食事指導の文書を生成することも視野に入れられているとのことでした。</p>
<p>近年フィットネストラッカー等で日々の生活の記録を取ることができますが、健康を考える上で重要な食事の記録を、写真を撮影するだけで行えるようになれば便利そうですね！</p>
<h2>ちゃんと使えるBotについて考える</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/720be3c5-d846-47f5-8bbb-96bb8a926bd4/8d8f51e5-35e5-4e80-b116-7c52e5a854f1.jpg" alt="DSC00048.jpg (1.3 MB)"></p>
<p>次にプレイドCTOの柴山から「ちゃんと使えるBotについて考える」についての発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="a86a7e669718491db72207aa96633c11" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>Botを使ってコミュニケーションさせようとすると、大量のデータが必要になってきます。<br>
しかし、シナリオ/ビジネスロジックを覚えるには現状ではデータが足りないので、先人たちのアプローチとしては下記をとっているとのことでした。</p>
<ul>
<li>シナリオベース(Google/Facebook/Softbank/Apple)</li>
<li>自然言語から定型化されたクエリにして処理 (Google/Facebook)</li>
<li>Outputは定型化したUI(Google)
<ul>
<li>検索結果</li>
</ul>
</li>
<li>対応できなかった時の次善策(Facebook/Google)
<ul>
<li>人が対応する等</li>
</ul>
</li>
</ul>
<p>こう考えてみると結局検索の延長線上でしか、Botを活かしきれていないことがわかります。</p>
<p>柴山の持論だと、このような定型化された作業の中で最もシステムがレバレッジを効かせられる部分はDBだとのことです。</p>
<p>ですので、Botのストロングポイントである、<code>検索/DB</code> を活かして一次回答をしながら、拾えないところは人間が返すという形がわかりやすいのではないかとのことです。</p>
<p>一次回答でBotが解釈できるシナリオを拡大するのに <a href="http://superscriptjs.com/">superscritpt</a>が面白そうなので興味のある方は見てみてはいかがでしょうか！</p>
<h2>いまさら聞けない機械学習の評価指標</h2>
<p>続いて <a href="https://twitter.com/dr_paradi">@dr_paradi</a>さんから「いまさら聞けない機械学習の評価指標 」についてお話頂きました。</p>
<p><strong> <a href="//www.slideshare.net/keisukeosone/ss-64685474" title="いまさら聞けない機械学習の評価指標" target="_blank">いまさら聞けない機械学習の評価指標</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/keisukeosone">圭輔 大曽根</a></strong></p>
<iframe src="////www.slideshare.net/slideshow/embed_code/key/um9FdtijcinP9B" 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>
<p>最近は機械学習が流行り周辺ツールやライブラリ、データが充実してきており、機械学習を試しやすくなっている一方で「どのような指標を設定すればよいか」「指標を評価する関数をどう選ぶか」がポイントになってきています。</p>
<p><a href="https://twitter.com/dr_paradi">@dr_paradi</a>さんの発表では、代表的な評価関数を説明してくださいました！</p>
<p><a href="http://data.gunosy.io/entry/2016/08/05/115345">Gunosyデータ分析ブログ</a>に詳しい説明を書いてくださっていますので興味のある方はぜひ御覧ください！</p>
<h2>データマイニングやってて思うこと</h2>
<p>最後におおとやさんから「データマイニングやってて思うこと」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="07f6770726dd4f24836ddfb65c369684" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>機械学習のツールを盲目的に信じてデータ解析しても意味がなく、「解析の目的」「データの種類」「データの分布」「解析方法」をしっかり考えてPDCAサイクルをまわしながらデータ解析をしていこうというお話でした！</p>
<h2>次回</h2>
<p>次回は<strong>9月下旬</strong>にFiNCさんのオフィスで**【FiNC×プレイド】Machine Learning Meetup #2**を開催します！<br>
<a href="http://plaidtech.connpass.com/">Connpass</a>でイベントの募集を行いますので、ご興味のある方は是非ご参加ください！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。<br>
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！</p>
<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>


機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました！

機械学習&チャットBotについて語る！【FiNC×プレイド】機械学習の勉強会を開催しました！| PLAID engineer blog

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

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

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

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

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

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

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


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

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

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

<p>こんにちは！プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>7/5(火)に<a href="http://plaidtech.connpass.com/event/33511/">【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 </a>を開催しました！</p>
<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>
<p>色々な会社で書かれているTechBlogの人気記事の内容を深掘りしていく勉強会です！</p>
<p>実際にブログを書いたエンジニアに登壇してもらい、記事の内容+α(ブログに書ききれなかったこと、ブログを書いた後に行ったこと等)を発表してもらいます。</p>
<p>今回は、<a href="https://toreta.in/jp/">トレタ</a>さんと一緒に開催させていただきました！</p>
<p>トレタさんからは、<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>を書かれた佐野氏に登壇して頂きました。</p>
<p>プレイドからは、<a href="http://tech.plaid.co.jp/autoscaling-ec2/">1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン</a>を書いた@tik-son が登壇しました。</p>
<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>
<p><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"></p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="14b8185b93b947d8891888a9b7323372" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>トレタのインフラ運用について具体的に「どのようなツールを使って」「どのように運用しているか」を話していただきました。</p>
<p>Terraform, Packer, Ansible等、導入理由と運用上押さえておくべきポイントが上手くまとまっており、大変勉強になりました。</p>
<p>弊社でもTerraformを利用しており、お話にあった<code>tfstateファイルの扱い</code>や<code>すべてをterraform管理下には置かない</code>という部分は気をつけて運用しております。</p>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">「すべてをterraform管理下に置かない」ほんとこれ <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a></p>&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>
<p>「この発表をTerraformを使い始める前に聞きたかった…」となるプレゼンでした！</p>
<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>
<p>いかにAutoScalingとSpotInstanceを上手く活用して運用しているかを話してもらいました。</p>
<p>SpotInstanceと聞くと「一時的なバッチ処理に使う」「テスト環境に使う」というイメージがあるかもしれないのですが、弊社では本番環境のステートレスなサーバ全てに使用しています。(管理画面用サーバ、解析サーバ等)</p>
<p>この発表では、SpotInstanceの価格変更にあわせて自動的にondemand⇔spotを切り替える仕組みを実装した話をしてもらいました。</p>
<p>ポイントは、<code>ondemand, spot, static</code>の3種類のサーバ群を用意すること。</p>
<p>「どのようなフローで切り替えを行っているのか」「実装する時に気をつけないといけない点」が詳しく書かれております。</p>
<p>実際に運用にのせたところ、サーバコストが1/2ほどになっているので、「サーバコスト減らしてよ！」と言われているインフラエンジニアの方必見です！</p>
<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">
<p>以下の3つのテーマで対談を行いました！</p>
<ul>
<li>HashiCorp製品の何をどうやって使っている？</li>
<li>AWSで辛いところは？</li>
<li>今後の展望</li>
</ul>
<h4>HashiCorp製品の何をどうやって使っている?</h4>
<p>トレタさんではTerraform,Vagrant,Packerを、プレイドではTerraformを使っています。</p>
<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>
<p>サーバの構成管理とデプロイをどのように行っているのかを話していただきました。</p>
<p>構成管理で使っているのはTerraform。<br>
<a href="https://speakerdeck.com/hiroakis/toretafalseinhurayun-yong">トレタのインフラ運用</a>でもお話がありましたが、Terraformには<code>管理に向くリソースと向かないリソース</code>があります。<br>
具体的に<code>どのリソースを継続的に管理していて、どのリソースは構築時のみ使うのか</code>ということに触れられているので、何に使うべきか迷っている方は一読を！</p>
<p><code>AMI作成まで</code>や<code>LaunchConfig作るまで</code>等を調整出来る、独自Packerクローンを作られたとのこと。すごい…！</p>
<p><strong> <a href="//www.slideshare.net/AkiraMiki/dockerize" title="Dockerizeして 大変だった話、幸せになった話" target="_blank">Dockerizeして 大変だった話、幸せになった話</a> </strong> from <strong><a href="//www.slideshare.net/AkiraMiki" target="_blank">Akira Miki</a></strong></p>
<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>
<p>Docker導入して大変だったことと、その後に訪れた幸せについて話していただきました。</p>
<p>どんなことが大変だったのかの話では、運用に乗せてみないとなかなか想像しづらかった部分について話しておられたので勉強になりました！</p>
<p>苦労を乗り越えた後の幸せの話では、<code>リソースの有効活用とデプロイ時間の短縮</code>など「よーし、明日からDocker入れるぞ！」という気にさせられました！<br>
次回はLTではなく、20分枠で是非！</p>
<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>
<p>暗号化対応していない時期から使っていたAuroraを、リードレプリカを作ることで暗号化させた話をしていただきました。</p>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">暗号化されてないAuroraから暗号化されたAuroraへの移行、つらそう <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a></p>&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>
<p>ぱっと聞いただけで大変そうな話で、工夫して<code>Binary Log</code>の位置を書き出されたりすることでレプリカセットを組み、無事暗号化されたとのことでした！</p>
<h2>まとめ</h2>
<p>AWS, Terraform, Docker等、サーバ構築からプロビジョニング、運用まで幅広く各社の取り組みを聞くことができた勉強会でした！<br>
使用しているツールや、実運用の際にハマっていたり気をつけている部分が似通っていたこともあり、定期的にこのような会を開いて「上手くいったこと」「失敗したこと」の共有をしていければ良いなと思いました！</p>
<p>一緒に勉強会を開催してくださる企業さまも絶賛募集中です！<br>
<a href="https://plaid.co.jp/#contact">弊社HPのお問い合わせフォーム</a>からご連絡いただくか、Twitterで #plaidtech をつけてツイートしてください！</p>
<h2>次回</h2>
<p>プレイドでは今後も色々なテーマで定期的に勉強会を開催する予定です！<br>
次回は「機械学習」に関する勉強会を8月頃に開催する予定ですので、是非ご参加ください。<br>
今回もイベント募集開催日に募集人数がオーバーしてしまいましたので、ご興味がある方は<a href="http://plaidtech.connpass.com/">connpassのPLAID tech</a>でメンバー登録を！</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）募集一覧をご覧ください。</p>


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


【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 を開催しました！

ウェブ接客プラットフォームKARTEの解析周りのアルゴリズムの利用検討の一環として、ストリーミングアルゴリズムについて検討したので、ストリー

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

Engineer Blog

Recent Article

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

スピード重視の開発体制を実現するためのUIテスト自動化

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

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

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

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜を開催しました！

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

Archives

Writers

Recent Article

今Googleで最も熱いサービスFirebaseで、リアルタイムWebアプリをサクッと作ってみた

WebDB Forum 2016 で独自解析エンジン「Brook」の技術報告をしてきました

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

スピード重視の開発体制を実現するためのUIテスト自動化

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

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

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

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 を開催しました！

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

Archives

Writers

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜を開催しました！