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>こんにちは、プレイドの@wikrshです。</p>
<p>弊社の<a href="https://karte.io/">KARTE</a> では属性データやサイト上での行動情報など様々なデータを元に来訪したユーザーの状況をリアルタイムに可視化しており、どのような情報の見せ方をすればよりユーザーへの理解を深められるのか、社内では日々議論・改良を重ねています。</p>
<p>今回は現在KARTEで行っているものとは異なる表現を実験してみたい + アニメーションを作るのが面白そうという動機で、「各ユーザーがサイト内の各ページを遷移している様子」の可視化に取り組んでみましたので紹介いたします。</p>
<h1>作成するアニメーションのイメージ</h1>
<p>各ページをノードとして表し、ユーザーを表すノードが各ページのノードを移っていく形で表現することを考えました。</p>
<p><code>/page1</code>を見ていたあるユーザーが<code>/page2</code>にアクセスした場合は、<code>/page1</code>を表すノードから<code>/page2</code>を表すノードへユーザーを表すノードが移動するイメージです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/890d6805-9a38-4b41-b9b8-4fd9fc66baeb/blog.001.jpeg" alt=""></p>
<p>このノードを各ページ・各ユーザーについて表示して、時刻を変化させる（再生する）ことで、各時刻でユーザーがどのように移動しているかを可視化することが今回の目標です。<br>
実装にはチュートリアルや例が豊富でありアニメーションも容易な <a href="https://d3js.org/">D3.js</a> を使用し、ブラウザ上にSVGで表示を行うことにしました。</p>
<h1>ページの表現</h1>
<p>サイト内の各ページの配置方法は様々考えられますが、今回はサイト間のページ構造に依らずに適用でき、かつ実装も容易であるため環状に配置することを考えました。</p>
<p>各ページ間の遷移についてはこれらのノード間を移動させることで表現できますが、セッションの初回アクセスは表現できません。<br>
そのため、中心にノードを一つ配置し初回アクセス時は中心のノードからアクセスページへ移動するものとします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/faccdde3-0d1f-4e0e-8ede-6d39c2355504/blog.002.jpeg" alt=""></p>
<p>また、各ページを閲覧しているユーザー数はページのノードの大きさで表現することにしました。<br>
SVGの<code>circle</code>の大きさは半径で指定しますが、面積をユーザー数に比例させたいので半径はユーザー数の平方根に比例させるようにします。</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/a4owsx0d/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h1>閲覧中のユーザーの取得</h1>
<p>今回は一般的なアクセスログを想定し、一つのレコードが、</p>
<ul>
<li>アクセス日時</li>
<li>ユーザーID</li>
<li>アクセスしたページ</li>
</ul>
<p>の情報からなるデータを使用します。</p>
<p>このデータに従ってある時刻<code>t</code>で発生したページアクセスを表示すれば良いのですが、このデータからはユーザーがいつページの閲覧を止めたか（離脱したか）は分かりません。<br>
ページアクセス以外のデータを組み合わせればより正確な離脱の計測も可能ですが、今回は簡単のためページアクセスから一定時間<code>T</code>経ったら閲覧を止めたとみなすことにします。</p>
<p>この条件の元である時刻<code>t</code>でサイトを閲覧中のユーザーを考えると、ページアクセスの時系列データの内、時刻<code>t-T</code>〜<code>t</code>でページアクセスをしたユーザーになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a19b9522-01e0-464c-8e71-9d1dd7378a1b/blog.003.jpeg" alt=""></p>
<p>アニメーションの再生時は、この時刻<code>t</code>を進める→閲覧中のユーザーを更新という流れを繰り返して表示を行います。</p>
<h1>ユーザーのページ遷移アニメーション</h1>
<p>ユーザーがページ間を遷移するアニメーションはD3.jsの <a href="https://github.com/d3/d3-transition">transition</a>で実装します。<br>
詳細については多くのチュートリアルや例があるので割愛しますが、D3.jsを使用するとシンプルにアニメーションを実装できます。</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/hbgb5v3v/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>注意点としては、ユーザーとノードを対応させるためにユーザーIDをキーとして渡す必要があります。<br>
これを行わないと、異なるユーザーのノードが使われてしまう可能性があります。</p>
<p>キー指定無し：</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/bjzkmnfe/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>キー指定有り：</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/sdcuzkxp/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>上の例ではデータ上は2人のユーザーがページを遷移していますが、キー指定無しの場合はノードとユーザーの紐付けが行われないため、遷移が起こっていないように見えてしまいます。</p>
<h1>作成したアニメーション</h1>
<p>弊社の運営する<a href="http://shopping-tribe.com/">Shopping Tribe</a>へのある日のアクセスデータをサンプリングした上で抽出してアニメーションを作成してみました。<br>
ノード数を抑えるためにアクセス数の上位49ページをそれぞれ一つのノードで表し、残りのページへのアクセスは一つのノード（<code>others</code>）にまとめて表現しました。</p>
<iframe src="https://player.vimeo.com/video/207268708" width="640" height="668" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
<p>作成したアニメーションを眺めていると、</p>
<ul>
<li>各ページへのアクセスのほとんどはサイト外からの流入で行われており、トップページ等サイト内での遷移からのアクセスの割合は多くない</li>
<li>アクセスの集中しているページとその他のページ間の遷移が多いわけではなく、決まった遷移の流れにはなっていない</li>
<li>アクセス数が上位49ページに入っていないページへのアクセス割合が比較的大きく、幅広くアクセスが発生している</li>
</ul>
<p>といった大まかな傾向は見てとれますが、新しい知見を得るためにはまだまだ改良が必要そうです。</p>
<h1>最後に</h1>
<p>今回行ってみたユーザー行動の可視化では、大まかなユーザーの動きの傾向や時間帯ごとの動きの違い程度の傾向はつかめるように思いますが、データから新しい知見を得るという点までは達しておらず、サイトに来訪したユーザーについての理解を深めるためには改良が必要そうです。</p>
<p>ここから意義のある知見を得られるレベルまで改良するには、</p>
<ul>
<li>個々のユーザーをどのように表現するか</li>
<li>各ページのノードをどのように配置するのが良いか</li>
</ul>
<p>が主なポイントになるかと思います。</p>
<p>特に、個々のユーザーの表現方法については、KARTEに取り込まれたユーザー情報やセグメント情報と合わせればより多くの知見を得られるのではなかと思いますので、より良い表現を考えたいところです。<br>
また、今回は閲覧データのみを使用しましたが、KARTE上には購入や会員登録を含む様々な行動データが存在するため、閲覧よりもより細かい行動の遷移を見るのも面白そうです。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><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>


D3.jsを使ってユーザーがサイト内の各ページを遷移している様子をアクセスログから可視化してみました。

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた | PLAID engineer blog

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ab738df8-3e11-4248-b37b-c8b4f16dfd83/16196179_1291472420896304_1281133783_o--1-.png" alt=""></p>
<p>こんにちは！<br>
プレイド エンジニアの@ikemonnです。</p>
<p>2/22(水)に開催しました「<a href="https://plaidtech.connpass.com/event/49170/">【KUFU×プレイド】Tech Meetup ~Docker編~</a>」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ECS を使って PR ごとに検証環境を用意した話</li>
<li>CIにWerckerを使うべき5つの理由</li>
<li>Building Minimal Docker Containers</li>
<li>Docker社が買った会社</li>
<li>効率的なdocker build用directory構造について</li>
</ul>
<h2>ECS を使って PR ごとに検証環境を用意した話</h2>
<p>まず<a href="http://kufuinc.com/">KUFU</a> <a href="http://twitter.com/elbowroomer">@elbowroomer</a>さんから「ECS を使って PR ごとに検証環境を用意した話」というテーマで発表がありました。</p>
<p>もともと検証環境が1台だったところを、ECS &amp; Dockerを使ってPRごとに検証できるようにされたとのことでした！</p>
<p>修正内容を、文字やスクリーンショットベースではなく、実際に触って試せるのは良いですね！</p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/gZ4hajTEanBRb" 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"> <strong> <a href="//www.slideshare.net/AtsushiYoshinari1/ecs-pr-72456169" title="ECS を使って PR ごとに検証環境を用意した話" target="_blank">ECS を使って PR ごとに検証環境を用意した話</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/AtsushiYoshinari1">Atsushi Yoshinari</a></strong> </div>
</div>
<p>詳細はブログに書いてくださっているので、併せてお読みください！</p>
<p><a href="http://tech.smarthr.jp/tech/466">「ECS を使って PR ごとに検証環境を用意した話」というテーマで登壇しました！ | SmartHR Tech Blog</a></p>
<h2>CIにWerckerを使うべき5つの理由</h2>
<p>次に<a href="https://plaid.co.jp/">PLAID</a> <a href="https://twitter.com/algas">@algas</a>から<a href="https://algas.github.io/plaid-meetup-20170222/#1">CIにWerckerを使うべき5つの理由</a>というテーマで発表がありました。</p>
<p>CIをしていると</p>
<ul>
<li>CIが何をしているのか把握できない</li>
<li>CIと同じ環境を構築できない</li>
<li>CIで起こった問題が再現できない</li>
</ul>
<p>という部分でハマりがちです。</p>
<p>「ローカルでは動くのにCIでコケた」のような状況を、<a href="http://www.wercker.com/">Wercker</a> というDockerネイティブなCIサービスを使えば解決できるという話でした！</p>
<p>弊社ではお客様に配布するJSファイルをbuildする部分からWerckerを取り入れ始めています！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/01a66a0e-7bfc-4347-a54e-762f53ce81d1/----------2017-03-01-14.47.46-1.png" alt=""></p>
<p><a href="https://algas.github.io/plaid-meetup-20170222/#1">スライドはこちら！</a></p>
<h2>Building Minimal Docker Containers</h2>
<p>続いて<a href="https://twitter.com/yepn">@gavinzhm</a> さんから「Building Minimal Docker Containers」というテーマで発表がありました。</p>
<p>軽量なLinuxディストリビューションである<a href="https://www.alpinelinux.org/">alpine Linux</a>を用いてイメージを作ったり、必要なレイヤーだけを注意深く選ぶことでビルド時間を短縮したりと実践的な内容でした！</p>
<script async class="speakerdeck-embed" data-id="bd98fa070456443096f8ebffc688b9c5" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>Docker社が買った会社</h2>
<p>次にPLAID <a href="https://twitter.com/otoan52">@otolab</a>から「Docker社が買った会社」というテーマで発表がありました。</p>
<p>Docker社が今まで買収した会社と、その買収によってどのような機能が実装されてきたか &amp; 今後どのような機能が実装されそうかということを発表してもらいました！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bbc96057-b5ad-48cc-a922-cf38fa68f556/----------2017-03-02-11.09.23.png" alt=""></p>
<p><a href="https://otolab.github.io/plaid-meetup-20170222/#1">スライドはこちら！</a></p>
<h2>効率的なdocker build用directory構造について</h2>
<p>最後に<a href="https://twitter.com/negabaro">@kimsehwa</a>さんから「効率的なdocker build用directory構造について<br>
」というテーマで発表がありました。</p>
<p><code>Git push -&gt; CI -&gt; Docker build, run, push</code> といったフローを行いたい時に、どのようなディレクトリ構成にするのが効率的かという内容でした！</p>
<script async class="speakerdeck-embed" data-id="f12a99e526614ad58a2cf5dadf610191" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを支えるマルチプラットフォームインフラに興味がある！KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。</p>


2/22(水)に開催しました【KUFU×プレイド】Tech Meetup ~Docker編~のレポートです。
「ECS を使って PR ごとに検証環境を用意した話」「CIにWerckerを使うべき5

【KUFU×プレイド】Tech Meetup ~Docker編~を開催しました！

エディタ、ターミナル、UNIXシェルについて、PLAIDのエンジニアが何を使っているのか、アンケート形式で訊いてみた。果たして、1位のエディタは？

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの開発ツール調べてみた〜 | PLAID engineer blog

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの使っている開発ツール調べてみた〜

<p>こんにちは。プレイドの＠etoです。<br>
プレイドではバックエンド全般から外部API連携までを担当しています。</p>
<p>うちの妻がBot作りたいとか言ってたので、自分で作れるようにサポートしてみました。<br>
妻はエンジニアではありませんのでコード書いたりとか一切なしです。</p>
<p>設定して動作確認するところまでで、簡単につくれるLINE BOTの話になります。</p>
<h2>目次</h2>
<ol>
<li>BOT作りたい</li>
<li>事前準備編</li>
<li>動作確認編</li>
<li>その他できそうなこと</li>
<li>まとめ</li>
</ol>
<h2>BOT作りたい</h2>
<p>妻「チャットボット作りたい。作って。」</p>
<p>わし「えっ、自分（の会社）でやればいいじゃん。」</p>
<p>妻「無理。何とかして。」</p>
<p>わし（なんとかしてって言われても・・・）</p>
<p>(注)実話を元にしたフィクションです。</p>
<p>という感じで、<s>妻の機嫌が悪くならないように</s>簡単にBOT作れないか考えていたところ、<br>
登録したけど全く使ってなかった<code>docomo Developer support</code>からちょうどいい感じのメールが届きました。</p>
<p><code>Repl-AIに「LINE連携用シナリオ」のテンプレートが追加されました。（中略）Repl-AIであればLINEを簡単に自動応答させることができます。（後略）</code>とあるではないですか。<br>
折しもプレイドで LINE Messenger API をやったばかりということもあり、LINEとこれで妻<s>をちょろまかす</s>に LINE BOT 作らせてみればよくないかと思ったわけで、実際にやってもらってみました。</p>
<p>本稿とは一切関係ありませんが、プレイドには有能なBOTがいっぱいあります。<br>
こちらで紹介してありますのでどうぞ。<br>
/making-slack-bot-with-lambda/</p>
<h2>事前準備編</h2>
<p>まずは Repl-AI に登録します。<br>
アカウント自体はdocomo Developer support(dDs)なのでこっちに登録すればログインできるようになります。<br>
Repl-AI にログインしてクレジットカード情報を登録すれば使えるようになります。</p>
<p>LINEと連携する方法ですが、ドキュメントがあるのでこちらを参考にすれば簡単にできます。<br>
https://repl-ai.jp/#docs/tutorial/line<br>
基本的にはLINEとRepl-AIのアカウントがあればできる感じです。</p>
<ol>
<li>LINE BUSINESS CENTER に LINE のアカウントでログインしビジネスアカウントを作成</li>
<li>LINE@MANAGER のアカウント設定からBot設定に行きAPIを利用する</li>
<li>同じようにWebhook送信を利用する</li>
<li>LINE Developers で必要な情報の確認する</li>
</ol>
<p>わかりにくいのは LINE  側の設定が LINE@MANAGER と LINE Developers にわかれているあたりでしょうか。</p>
<p>前準備はこれで完了です。</p>
<h2>動作確認編</h2>
<p>次は Repl-AI でBOTを作ってLINEと連携させます。</p>
<h3>1.新規プロジェクト作成</h3>
<p>プロジェクト名を入れでプランを選択して保存します。<br>
とりあえずなので Light で問題ありません。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/26707329-b553-401c-a410-f2807c3e1795/----------2017-01-30-13.07.10.png" alt=""></p>
<p>無料期間を過ぎると自動で課金されてしまいますので注意が必要です。<br>
退会しなくてもプロジェクトを削除してしまえば問題ないかと思います。</p>
<h3>2. 新規ボット作成</h3>
<p>ボットIDとボット名を入れるだけです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cd472223-bec9-45ea-aa7a-5fd27f25b976/----------2017-01-30-13.10.05.png" alt=""></p>
<h3>3. 新規シナリオ作成</h3>
<p>シナリオIDとシナリオ名を入れて、連携ボットシナリオを選択しましょう。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/32947865-2e29-41f7-b631-f712dc50235e/----------2017-01-30-12.23.06.png" alt=""></p>
<h3>4. LINE連携</h3>
<p>LINE Developers から各種情報を入力<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e2fde64-9dca-4c85-b94f-74e9a397168a/----------2017-01-30-13.12.53.png" alt=""></p>
<p>LINE Developers に Repl-AI から発行されるWebhook URL をコピペしましょう。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eb56e28d-aae7-490c-80b1-f7e528767bed/----------2017-01-30-10.23.30.png" alt=""></p>
<h3>5. LINE Developers のQRコードからLINEで友達になる</h3>
<p>これで動作確認できます。<br>
Repl-AI 単体でもシミュレータから動作確認できたりするので便利です。</p>
<p>連携ボットシナリオ中身は以下のようになってます。</p>
<ul>
<li>「教えて」が含まれる発言に対して「知識Q&amp;Aボット」</li>
<li>「ニュース」が含まれている発言に対して「トレンド記事ボット」</li>
<li>その他は「雑談対話ボット」</li>
</ul>
<p>LINE上で話しかけて反応を楽しみましょう。</p>
<p>妻「なんかできてる。でも会話成立してなくない？」</p>
<p>わし「何もしてないしそんなもんよ。」</p>
<p>妻「思ってたのと違うんだけど、どうやったらちゃんと作れるの？」</p>
<p>わし（ネタにしかならんかったか・・・）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/52f0a22f-451f-41c6-8cb3-9b0ac86f0b86/----------2017-01-30-18.44.35.png" alt=""></p>
<h2>その他できそうなこと</h2>
<p>ここまでは簡単に誰にでもできると思います。<br>
次はシナリオに対応したBOTを作るためにはどうすればいいかですが、ある程度まではRepl-AIで簡単にできそうです。</p>
<p>上の手順の新規シナリオ作成の部分で「LINE連携シナリオ」を選択します。<br>
LINE Messenger API の内 Imagemap を除くAPI の雛形が用意されています。<br>
以下の文字を入力すると対応する応答が用意されていますので、好きにカスタマイズしてみてください。<br>
()内はLINE Message API での呼称です。</p>
<ul>
<li>テキスト (Text)</li>
<li>画像 (Image)</li>
<li>動画 (Video)</li>
<li>音楽 (Audio)</li>
<li>位置 (Location)</li>
<li>スタンプ (Sticker)</li>
<li>ボタン (Template Button)</li>
<li>確認 (Template Confirm)</li>
<li>カルーセル (Template Carousel)</li>
</ul>
<p>LINE BOT の中身として使用するのであれば結構有力な候補になると思います。<br>
お値段はそれなりですが、サーバーが不要なのとエンジニアでなくても作れそうなのでいいと思います。</p>
<p>こんな感じのが欲しいらしい。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/675eefaf-eebe-40cd-bd3a-188acafc9699/----------2017-01-30-18.35.19.png" alt=""></p>
<p>青い東京タワーの写真を表示するの図</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a></p>
<p>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><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>


ある日突然チャットボット欲しいと言われ、楽にLINEでBOTを作る方法を模索し、実際に5分で作れるか試してみました

誰でも5分で作れるLINE BOTを試してみた | PLAID engineer blog

誰でも5分で作れるLINE BOTを試してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d45c2be8-638e-4eed-a7a5-5713d61b0a1b/7984ab2d5c90fe4021010a8f381885f6.png" alt=""></p>
<p>こんにちは！<br>
プレイドで主にインフラを担当しているikemonnです。</p>
<p>1/19(木)に<a href="https://www.freee.co.jp/">freee</a>さんの会場をお借りして、「【freee×プレイド】Tech Meetup 〜インフラ監視編〜」を開催しました！</p>
<p>そこで、KARTEを支えるマルチプラットフォームインフラ監視について話してきましたので、本日はこの勉強会のレポートをお届けしたいと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0ae92521-5b87-46f1-856a-9a618316c4ce/DSC05081.JPG.jpg" alt=""></p>
<p>卓球台！<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23ebabde-a4c6-45ea-b847-0be2208a3981/DSC05069.JPG.jpg" alt=""></p>
<p>PLAIDの &quot;Nice Deploy&quot; カップ<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/09206030-401c-4bbc-9120-9fc66c287778/DSC05073.JPG.jpg" alt=""></p>
<h2>発表タイトル</h2>
<ul>
<li>freee を支えるインフラ監視</li>
<li>KARTEを支えるマルチプラットフォームインフラ監視</li>
<li>対談</li>
<li>プロセス生存確認サービス始めました</li>
<li>grafana-zabbix 活用術</li>
<li>prometheus 監視で変わるもの</li>
</ul>
<h2>freee を支えるインフラ監視</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76d5caee-43e6-4355-8fd6-afdccab00340/DSC05127.JPG.jpg" alt=""><br>
まずfreee <a href="https://twitter.com/manabusakai">@manabusakai</a>さんから「freee を支えるインフラ監視」についてお話して頂きました！</p>
<script async class="speakerdeck-embed" data-id="351643d1ce91448f891b9a2b47ab8ace" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>freeeさんで使っている監視系サービスや少人数(インフラエンジニアが3人！)で運用するためのノウハウについてお話して頂きました！</p>
<p>freeeさんでは下記の5点を工夫することで少人数で運用しておられるとのことでした。</p>
<ol>
<li>情報はプルよりプッシュ</li>
<li>フルマネージドサービスの活用</li>
<li>障害が起きることを前提にインフラを設計する</li>
<li>本業にフォーカスする</li>
<li>トラッキングして見える化</li>
</ol>
<p>上記の内容はプレイドでも当てはまることが多く、特に「本業にフォーカスする」は強く意識しています。</p>

<p>スタートアップでインフラ監視をする際に考えるべき重要なポイントが上手くまとまっていてとても参考になりました！</p>
<p>登壇ブログも書いてくださっています！<br>
<a href="https://blog.manabusakai.com/2017/01/freee-plaid-tech-meetup/">【freee × プレイド】 Tech Meetup に登壇しました</a></p>
<h2>KARTEを支えるマルチプラットフォームインフラ監視</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dfe14c2b-9d8b-4ac3-87a2-63bb7beee4a4/DSC05161.JPG.jpg" alt=""></p>
<p>次に私、プレイド <a href="https://twitter.com/ikemonn">@ikemonn</a>から「KARTEを支えるマルチプラットフォームインフラ監視」の発表を行いました。</p>
<script async class="speakerdeck-embed" data-id="4fb2e580439e49aebad935111d848a58" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<p>プレイドではもともとAWSのみでインフラを構築していました。</p>
<p>しかし、GCPのBigTableやBigQueryを積極的に利用するにあたり、latencyやnetworkコストの面からGCPにもインスタンスを立てており、現在AWSとGCPの両プラットフォームでインフラを構築しています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ea8c4d56-f532-40ea-bbd8-6cf8479a8b99/----------2017-01-20-18.12.38.png" alt=""></p>
<p>今回の発表では以下のことについて話しました。</p>
<ul>
<li>具体的にどのような値をどのように監視しているのか</li>
<li>ダッシュボードを作るときのコツ</li>
<li>マルチプラットフォームの監視でハマったこと</li>
</ul>
<p>プレイドのインフラエンジニアは2名でして、少数でマルチプラットフォームの監視を行っていくために以下のことを工夫しています。</p>
<ul>
<li>情報/アラートを一元管理する</li>
<li>問題をドリルダウンして追っていけるようにする</li>
</ul>
<p>マルチプラットフォーム監視にご興味のある方は是非スライドを御覧ください！</p>
<h2>対談</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d32537a3-8b77-423c-b38f-ba5814547d9b/DSC05196.JPG.jpg" alt=""></p>
<h6>Dashboardやアラートを作ったり、整理したりするタイミングは?</h6>
<ul>
<li>障害駆動でDashboardやアラートを作る</li>
<li>アラートの数は抑え気味で、監視しすぎないことを意識している</li>
</ul>
<h6>適切な負荷ってどうやって監視するの?</h6>
<ul>
<li>時系列のデータから低負荷を定義しやすい。ソーシャルゲーム等だと色々イベントあるから難しい</li>
<li>決めの問題で、余裕があるときに一気に落として見たり負荷テストしてみたりすると良い</li>
<li>自分のカードで支払うとしたら?と考えてコスト落とす。勇気のある方は自分のカードを登録してもいいかもｗ</li>
</ul>
<h6>使用中のモニタリングツールの辛いところ、改善して欲しいところは?</h6>
<ul>
<li>Datadog
<ul>
<li>セキュリティ, 99 percentile位まで見たい, 異常値検出でインスタンスの起動/終了時を省けない</li>
</ul>
</li>
<li>Mackerel
<ul>
<li>Zabbixに比べて画面が重い。画面を開き続けているとバッテリーの持ちが悪い。</li>
<li>障害が今起きてるのに画面が遅いのは困る！簡易版で良いから画像で出すoptionとか欲しい</li>
</ul>
</li>
</ul>
<h6>通知を受け取る範囲/対象はどのように設定していますか？ 通知が多すぎるとオオカミ少年になるので。</h6>
<ul>
<li>緊急の場合はPagerdutyで、その他は緊急度に応じてSlackのchannelを分ける</li>
<li>緊急性の高い問題が飛んでくるチャンネルと、少し気にしておけば良い優先度の低い問題を飛ばしているchannelをわけている</li>
<li>twilioを使ってインフラエンジニアにランダムで電話をかける</li>
</ul>
<h6>新しい監視ツール・サービスを導入する際、社内をどう説得しているか</h6>
<ul>
<li>PLAIDはCTOが新しいサービスが好きで、hackernewsなどで見つけたものをshareしてくれる
<ul>
<li>free trialですぐ試して、ある程度の金額までだったらすぐに導入できる</li>
</ul>
</li>
<li>freeeにいると苦労しないが、前職だと稟議を通したりしないといけなかった
<ul>
<li>ツールを導入することでどれくらい安くなるかを言えると話が早い</li>
</ul>
</li>
<li>社内稟議が大変な会社は
<ul>
<li>何をやっているかわからない人の言うことはなかなか理解されないので、社内で勉強会をやったりして何をやっているかアピールする</li>
<li>社内でPRすると色々実現しやすくなる</li>
</ul>
</li>
</ul>
<h2>プロセス生存確認サービス始めました</h2>
<script async class="speakerdeck-embed" data-id="2fb4c7a90f25461599d4a8e0bf62d5ab" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://github.com/narita-takeru">@narita-takeru</a>さんから「プロセス生存確認サービス始めました」というテーマで発表して頂きました。<br>
「サーバにsshせずとも、バッチ処理のプロセスの死活監視を簡単に行いたい」という想いから、プロセスの死活監視ツール<a href="https://nursecall.io/#/signin?redirect=%2F">NurseCall</a>を作られたそうです！</p>
<p>プロセスが生きている/生きていたかの監視を行いたい方はぜひ使ってみてはいかがでしょうか？</p>
<h2>grafana-zabbix 活用術</h2>
<script async class="speakerdeck-embed" data-id="df7ec85f5c7847e2a988fc9234892ecc" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://twitter.com/kakakakakku">@kakakakakku</a>さんから「grafana-zabbix活用術」についてお話していただきました。<br>
<a href="https://github.com/alexanderzobnin/grafana-zabbix">alexanderzobnin/grafana-zabbix</a> を使うことで、モダンな見た目のzabbixが使えるようになるそうです！<br>
grafana-zabbixの良いところが、zabbixサーバには影響を与えずに試せるため、手軽にTryできるところです。<br>
zabbixを使っておられる方も多いと思いますので、一度試してみてはいかがでしょうか！</p>
<p>発表の際にあげておられた、<a href="https://www.amazon.co.jp/Effective-Monitoring-Alerting-Web-Operations/dp/1449333524/ref=sr_1_1?s=english-books&amp;ie=UTF8&amp;qid=1484893216&amp;sr=1-1&amp;keywords=Effective+Monitoring+and+Alerting%3A+For+Web+Operations">Effective Monitoring and Alerting: For Web Operations(Oreilly)</a>をちょうど年末に読んでおり、監視に関するオススメ本なのでぜひ読んでみてください！</p>
<p>勉強会の参加ブログも書いていただきました！<br>
<a href="http://kakakakakku.hatenablog.com/entry/2017/01/20/003857">Tech Meetup に参加して「grafana-zabbix 活用術」を紹介してきた - kakakakakku blog</a></p>
<h2>prometheus 監視で変わるもの</h2>
<script async class="speakerdeck-embed" data-id="ae4d55d171af409a8f50e4b0d4948340" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://github.com/sugitak">@sugitak</a>さんから「prometheus 監視で変わるもの」についてお話していただきました。<br>
最近話題になっている<a href="https://prometheus.io/">Prometheus</a>を実際に使用されていて、Prometheusの思想や具体的にどのように使っているのかについてお聞きできました！<br>
「大量のホストのCPU使用率を１つのグラフに表示する」のではなく「CPU使用率の最小値と最大値だけを表示する」と言ったように、「本当に必要な情報だけを表示する」思想は良いなと思いました！</p>
<p>Qiitaの方にも記事を書かれていますので、ご興味のある方は是非！<br>
<a href="http://qiita.com/sugitak/items/ff8f5ad845283c5915d2">次世代監視の大本命！ Prometheus を実運用してみた</a></p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを支えるマルチプラットフォームインフラに興味がある！KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。</p>

【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！
KARTEを支えるマルチプラットフォーム(AWS/GCP)インフラ監視について話してきました

【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！

<p>PLAID エンジニア/HUNTER<br>
山内 雅浩<br>
@algas</p>
<h2>概要</h2>
<p>node.js (npm) での依存性解決とパッケージマネージャを <a href="https://docs.npmjs.com/cli/shrinkwrap">shrinkwrap</a> から <a href="https://yarnpkg.com/">yarn</a> へ移行した話。<br>
<a href="https://algas.github.io/npm-to-yarn-slide">プレイド勉強会での発表資料</a> も合わせてご覧ください。</p>
<h3>対象読者</h3>
<ul>
<li>node.js で継続的に開発を行っているエンジニア</li>
<li>npm 依存関係地獄に苦しんでいる同志</li>
</ul>
<h3>結論</h3>
<p>shrinkwrap を捨てて yarn を使いましょう。<br>
ただし production に使うのはちょっと早い。<br>
執筆時点での yarn のバージョンは 0.17.10 です。</p>
<h2>shrinkwrap vs yarn</h2>
<p>(npm) shrinkwrap と yarn を比較してみましょう。</p>
<table>
<tr>
<th>項目名</th>
<th>Node.js</th>
<th>Yarn</th>
</tr>
<tr>
<td>パッケージマネージャ名</td>
<td>npm</td>
<td>yarn</td>
</tr>
<tr>
<td>パッケージファイル</td>
<td>package.json</td>
<td>package.json</td>
</tr>
<tr>
<td>パッケージ指定ファイル</td>
<td>npm-shrinkwrap.json</td>
<td>yarn.lock</td>
</tr>
</table>
<p>yarn を使う利点と欠点は以下のとおりです。</p>
<h3>PROS</h3>
<ul>
<li>インストール処理が高速かつ安定<br>
ネットワークパフォーマンス改善やオフラインモード、リトライの実装がされていてパッケージのインストールが標準の <code>npm install</code> に比べて高速かつ安定に動作します。</li>
<li>依存性解決の向上<br>
複数のパッケージで使われている同じパッケージを1つのインデックスにまとめることでインストールするパッケージ数を減らし、ディスク容量の軽減・インストール速度の向上を実現しています。</li>
</ul>
<h3>CONS</h3>
<ul>
<li>yarn 自体のインストールが必要<br>
他のパッケージよりも先に yarn をインストールしなければなりません。shrinkwrap は npm に標準装備されているのでインストールは必要ありません。</li>
<li><code>npm ls</code> と <code>yarn ls</code> の互換性がない<br>
<code>npm install</code> 済みのパッケージを確認するコマンドである <code>npm ls</code> と <code>yarn install</code> 済みのパッケージを確認する <code>yarn ls</code> に互換性がありません。<code>yarn install</code> が正常にできた環境で <code>npm ls</code> を実施しても OK と返らない場合があります。</li>
<li>yarn 自体の不具合<br>
yarn のバージョンは執筆時点で 0.x であり、正式バージョンである 1.0 以上になっていません。公開されて間もないこともあり、issue が大量に上げられていて yarn 自体の不具合に悩まされることもあります。</li>
</ul>
<h2>node パッケージの追加と削除</h2>
<p>パッケージを追加・削除する方法にはコマンドからインストールするのと、package.json に書いてからインストールする2通りの方法があります。<br>
CIなどのリモート環境では後者の方法で運用する場合もあります。</p>
<ul>
<li>
<p>npm + shrinkwrap の場合</p>
<ol>
<li>コマンドからインストール
<ol>
<li><code>npm install --save new_package</code> or <code>npm uninstall --save new_package</code></li>
<li><code>npm ls</code></li>
</ol>
</li>
<li>package.json からインストール
<ol>
<li>dependencies に new_package を追加/削除する</li>
<li><code>npm update --save</code> (危険)</li>
<li><code>npm ls</code> (失敗しがち)</li>
</ol>
</li>
</ol>
</li>
<li>
<p>yarn の場合</p>
<ol>
<li>コマンドからインストール
<ol>
<li><code>yarn add new_package</code> or <code>yarn remove new_package</code></li>
<li><code>yarn check</code></li>
</ol>
</li>
<li>package.json からインストール
<ol>
<li>dependencies に new_package を追加/削除する</li>
<li><code>yarn upgrade</code></li>
<li><code>yarn check</code></li>
</ol>
</li>
</ol>
</li>
</ul>
<p>shrinkwrap を使った場合には package.json に手動でパッケージを追加すると、それを削除した際に追従できずにエラーが発生することがありますが、yarn を使った場合に同じ作業を行っても問題が発生しません。</p>
<h2>依存関係地獄 (dependency hell)</h2>
<p><code>npm-shrinkwrap.json</code> を使うことで確かに <code>npm install</code> で同じパッケージ群をインストールすることはできるようになります。<br>
この環境に package.json への追加によって新しいパッケージを追加しようとした場合には shrinkwrap は正しく依存関係を更新できません。</p>
<p>以下の手順で依存性解決をすることになります。</p>
<ol>
<li>本体またはサブモジュールの <code>package.json</code> を更新する</li>
<li><code>npm install</code> or <code>npm update --save</code> を実行する</li>
<li>パッケージの更新に失敗する</li>
<li>1.に戻る(依存性解決できるまで繰り返す)</li>
</ol>
<p>結局、問題が解決できずに <code>npm-shrinkwrap.json</code> を削除するしかない状況に陥ることも多くあります。<br>
これが継続的に依存性問題を解決できない理由です。</p>
<h2>依存性解決できない問題</h2>
<p>node.js でデファクトスタンダードになっているパッケージ管理ツールである npm (node package manager) で依存性を解決するのが難しいという問題があります。<br>
現状では shrinkwrap という npm に標準装備されている方法を使ってインストールされるパッケージを固定(バージョン指定のスナップショット)できます。<br>
<code>npm shrinkwrap</code> コマンドでパッケージ指定ファイル <code>npm-shrinkwrap.json</code> を生成することで、他の環境で <code>npm install</code> を実行した際に(依存関係も含めて)同じパッケージがインストールされるようにします。<br>
上記で書いたとおりに shrinkwrap を使えばインストールされるパッケージを固定することはできます。しかし上述の通り、実際に運用してみると shrinkwrap ではパッケージの固定はできても、継続的な依存性解決ができるわけではないことがわかります。</p>
<h2>Yarn の不具合</h2>
<ul>
<li>production install できない<br>
<code>yarn install --production</code> が効かない。つまり devDependencies もインストールされる。<br>
https://github.com/yarnpkg/yarn/issues/761</li>
<li>postinstall を実行してない問題<br>
deep dependencies で preinstall, install, postinstall を実行できてない。<br>
https://github.com/yarnpkg/yarn/issues/2142</li>
</ul>
<h2>自作ツールの紹介</h2>
<p>緩やかに移行したい方へ <code>npm-shrinkwrap.json</code> から <code>yarn.lock</code> を生成するツールを作りました。<br>
https://github.com/algas/shrinkwrap2yarn<br>
使い方は上記リポジトリの README をご参照ください。<br>
動かなかったり不具合を見つけたりした場合には issue, PR をお待ちしております。<br>
自社の製品では~~<code>shrinkwrap.json</code> の作成フローが雑だったので~~結局使いませんでした。</p>
<h2>ハマったこと</h2>
<ul>
<li>npm でのインストールの挙動(サブコマンドの動作など)が把握できなくて、理解するまでにすごく時間がかかりました。</li>
<li>自社の node.js プロジェクトの依存性解決に手間取りました。</li>
<li>うちの package.json はいろんな処理を書きすぎじゃね？</li>
</ul>
<h2>参考文献</h2>
<ul>
<li><a href="https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc">NPM vs Yarn Cheat Sheet</a></li>
<li><a href="https://yarnpkg.com/en/docs/migrating-from-npm">Migrating from npm</a></li>
</ul>
<h2>まとめ</h2>
<p>今すぐ <code>shrinkwrap</code> を捨てて <code>yarn</code> と旅に(ry</p>
<h2>エンジニア募集中</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><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>


PLAIDエンジニア 山内雅浩 @algas yarn を使って node.js の依存性解決 npm shrinkwrap と yarn との比較

まだ node.js の依存性解決で消耗してるの？ | PLAID engineer blog

まだ node.js の依存性解決で消耗してるの？

<p>こんにちは。プレイドの@monoiです。<br>
プレイドでは主に管理画面周りの開発を担当しています。</p>
<p>さて、突然ですがプレイドには最近ある課題が浮上しています。<br>
それはメンバーが増えるに伴って、コミュニケーションの機会がなかなかない人ができてしまうこと。</p>
<p>この課題には多くの会社が頭を悩ませていると思いますが、コミュニケーションと言えば何と言っても<strong>ランチ</strong>ですよね。<br>
普段の業務であまり関わりのない人でも、一緒にランチに行けばそこには<strong>深い友情</strong>が芽生えるかもしれません。</p>
<p>そんなわけで今回は、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotを、AWS Lambdaを使って作成しました。</p>
<h1>目次</h1>
<ul>
<li>プレイドのbot紹介</li>
<li>AWS Lambdaとは？</li>
<li>作る</li>
<li>完成</li>
<li>最後に</li>
</ul>
<h1>プレイドのbot紹介</h1>
<p>botを作る方法は様々あります。</p>
<p>プレイドにはすでに多くのおもしろいbotがいるので、これらを紹介しつつ、処理方式を検討していきます。</p>
<h2>はる子さん</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bf5fcce8-3d22-467e-b818-f7ebe5f594da/hal.png" alt=""></p>
<p>はる子さんは優秀な人事・労務管理botです。<br>
勤務時間を管理してくれたり、社員のプロフィールを教えてくれたりします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/695cb0dc-1c30-41c7-979f-d558d15b6966/----------2016-12-14-16.09.02.png" alt=""></p>
<p>はる子さんは、社内に置いてあるMacBookAirにnode.jsサーバーを立てて動かしています。<br>
以前はiBeaconを使って社員がオフィスにいた時間を把握し、自動で勤務時間を記録してくれる仕組みもありました。（リモート勤務や外出が多い社員の勤務時間をうまく取得できないため、一時休止中。）</p>
<h2>KARTEくま</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dd9c67da-d00d-41c8-ba1a-ba8a53b73e02/cap4.png" alt=""></p>
<p>KARTEくまはCX(Customer Experience)チームをサポートするためのbotです。プレイドが提供しているサービスで、異常な数値が検出されていないか等のチェックを行っています。</p>
<p>Google App Scriptで定期実行し、SlackのIncoming Webhookを叩いています。</p>
<h2>karte-hubot &amp; DeployBot</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6dfe76a1-b314-4ad3-8bd4-fba5e6ab7004/deploy_bot.png" alt=""></p>
<p>日々のデプロイを補助してくれるbotです。<br>
デプロイをするのにいちいちコマンドを叩くのは面倒だ、ということで、Slack上で特定のキーワードを打つとデプロイできるような仕掛けが作られました。</p>
<p>こちらはEC2インスタンス上で動作させています。<br>
karte-hubotは名前の通りgithub社の<a href="https://hubot.github.com/">hubot</a>フレームワークを使っています。</p>
<h2>さてどうするか。</h2>
<p><strong>完全に余計な手間ですが</strong>、まだ社内で使われていない方法で作ってみたい・・・！</p>
<p>というわけで今回は<strong>AWS Lambda</strong>で作ってみました。</p>
<h1>AWS Lambdaとは？</h1>
<p>FaaS（Function-as-a-Service）の一種で、AWS上に関数を置いておき、インスタンスを立ち上げることなくクラウド上でアプリケーションを実行できるサービスです。<br>
CloudWatch（定期実行）や、S3（データがアップロードされたら実行）など様々なAWSのサービスをトリガーにして実行させることができます。<br>
2016年12月現在、Node.js、Python、Java、 C#に対応しています。</p>
<p>実際に処理が行なわれている時間のみしか課金されないため、常時動かす必要のないアプリケーションとは相性がいいです。<br>
お昼の時間しか動かさない今回のbotにはうってつけですね。</p>
<h1>作る</h1>
<h2>作成するbot</h2>
<p>ランチメンバーを募集してグループ分けしてくれる<strong>ランチくまbot</strong>。</p>
<ul>
<li>12:00に「一緒にランチに行く人募集ー！」と誘いがくる。</li>
<li>13:00に上のメッセージに対してリアクションした人を適度な人数でグループ分けする。</li>
</ul>
<h2>slackでBot Userを作る</h2>
<p>まず https://slack.com/apps/build からBot Userを作成します。</p>
<p>作成が完了したら、登場させたいchannelにinviteしてあげましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b37bc27-bb31-4c86-8027-28ca66844a22/----------2016-12-14-18.51.08.png" alt=""></p>
<h2>Lambdaのsetup</h2>
<p>続いて<a href="https://aws.amazon.com/jp/">AWSコンソール</a>からLambda Functionを作成します。</p>
<p>今回は定期実行なので、トリガーはCloudWatch Eventを使います。<br>
「平日12時」に実行の場合、CloudWatchのスケジュールは<code>cron(0 3 ? * MON-FRI *)</code>としてあげればOKです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9e584509-f549-4993-a992-083e09fd7ea7/----------2016-12-14-16.47.42.png" alt=""></p>
<p>「平日12時」のCloudWatch Eventでは<code>{&quot;event_name&quot;: &quot;send&quot;}</code>を投げるようにしています。<br>
「平日13時」のEventでは<code>{&quot;event_name&quot;: &quot;aggregate&quot;}</code>を投げます。<br>
event_nameによって処理内容をハンドルします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f78cd9a1-3b7b-42a7-b198-ee7ff5133f1a/----------2016-12-14-16.53.12.png" alt=""></p>
<p>また、タイムアウトまでの時間がデフォルトでは3秒になっているのですが、slackのAPIを何度か叩くので念のため10秒にしておきます。</p>
<h2>コードを書く</h2>
<p>通常通りローカルでコードを書き、その後zip化してAWSのコンソール画面からアップロードします。<br>
ブラウザ上でもちょっとしたコードを書くことはできますが、モジュールのインストールなどはローカルで行う必要があります。</p>
<p>ボタンひとつでテスト実行することもでき、デバッグも容易です。<br>
もちろんただの関数なので、ローカルでも簡単にテストできます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f963c72b-8523-4763-aef1-004a7f388a37/----------2016-12-15-2.47.08.png" alt=""></p>
<p>Lambda Function内からのみアクセス可能な環境変数をコンソール画面から設定することができます。<br>
例えばCHANNEL名をここで設定できるようにすると、再アップロードせずに投稿先のチャンネルを切り替えられるようになり、テストが非常に楽になります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c4cfced0-5cbc-4561-b729-3488edd2994f/env.png" alt=""></p>
<p>その後は<a href="https://api.slack.com/">SlackAPI</a>を見ながらコードを書き進めていきます。<br>
SlackのAPIは非常に豊富でわかりやすいです。</p>
<h1>完成</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18ed12f5-d0df-4398-842c-bd5afb093da5/cap.png" alt=""></p>
<p>まずは自己紹介から入ります。<br>
先ほど紹介したKARTEくまbotの作成者である@akobaさんからも受け入れられたようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18f9c763-e4d4-4759-9807-54dfb60e1cc3/cap5.png" alt=""></p>
<p>12:00になるとlunchチャンネルにメッセージを投稿し、募集を開始します。<br>
よく分からないリアクションもいっぱい付いてますが、lunch_kumaは余裕で全て受け入れます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c03c1d8e-7a5e-4589-b478-7fe83421136d/cap3.png" alt=""></p>
<p>13:00になるとリアクションをしたメンバーをシャッフル、グループ分けします。<br>
いい感じにグループ分けできました！</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくはこちら（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>


社内のコミュニケーションを活性化させるため、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotをAWS Lambdaを使って作成しました！

SlackbotをAWS Lambdaでサクッと作ってみた | PLAID engineer blog

ランチメンバーを自動でグループ分けしてくれるSlackbotをAWS Lambdaでサクッと作ってみた

<p>プレイドの @nashibao です。</p>
<p>弊社では結構<code>BigQuery</code>を使い倒させていただいていて、社内向けのバッチ解析や<code>ChartIO</code>/<code>ModeAnalytics</code>等を介した社外向けのレポーティングとしての利用だけでなく、ABテストなどの集計系では（Query数のコントロールのためにキャッシュは介していますが）ほぼ直接アプリケーションのバックエンドとして利用しています。</p>
<p>またStreaming Insertが思ったより安定しているので、ニアリアルタイムにイベントを反映することができ、<strong>適当なQueryを投げ込んでPBの集計を気軽にやって、数百万使って唖然としてとりあえず寝て忘れる</strong>、みたいなことをしています。</p>
<p>先日も&quot;GCP NEXT World Tour in Tokyo&quot;において、弊社 @makinoy がジョブズばりのプレゼンをさせてもらいました。</p>
<p><a href="http://blog-plaid.com/event/2642/"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df784d2b-d07b-4eac-b2d1-afb1e918b464/DSC00529.jpg" alt="gcp"></a><br>
<a href="http://blog-plaid.com/event/2642/">Google Cloud Platform 国内最大のイベント「GCP NEXT World Tour in Tokyo」にプレイドが登壇しました</a></p>
<p>さて、これだけBigQueryを使い込んでいる弊社ですが、仕組みについてはあまり外に出てないため、ほとんど知りません。</p>
<p><a href="http://research.google.com/pubs/pub36632.html">DremelのPaper（2010/VLDB)</a> が6年前に出ていますが、その内容としては非常に単純なQuery Processingのケースのみを扱っていて、<code>シンプルな分割統治型のツリー処理</code> と、<code>独自の省スペースかつ効率的なNested Dataのカラムナ表現</code> の二点を中心に議論されています。論文の最後でも次のように締められています。</p>
<blockquote>
<p>In the future, we plan to cover in more depth such areas as<br>
formal algebraic specification, joins, extensibility mechanisms, etc.</p>
</blockquote>
<p>後半に乗っている<code>Dremel</code>と既存の<code>Google MapReduce/Sawzall</code>（Google 社内のMapReduce実装）とのパフォーマンス比較、キレイに線形にスケールする実験結果は一見の価値があります。ただ、カラムナについて独自のエンコーディング/FBMを使ったアセンブリ手法は、これがポッと作れてしまうGoogleはさすがだなぁ、と思う反面、カラムナにしたらそりゃパフォーマンスは上がるだろうという感じだし、割となんでもござれのHDDベースのMapReduceと比較して分割統治に特化した構造がパフォーマンスが出るのも当然だろ、という気がします。</p>
<p>それよりもむしろ、<code>テラ/ペタサイズのJOINやGroup Byが入り組んだクエリが数秒~数十秒で返ってくる</code>という理解不能な事象について深掘りして欲しい気がします。つまりちょうど<code>Dremel</code>のペーパーの範囲外ですw</p>
<p><a href="https://www.amazon.co.jp/Google-BigQuery-Analytics-Jordan-Tigani-ebook/dp/B00JUUZIZI">Amazon.co.jp: Google BigQuery Analytics 電子書籍: Jordan Tigani …</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5438d3eb-fff3-4106-bd6e-4db25c4b588e/583ec39bdd099caa2040f48c::image.png" alt="img"></p>
<p>そしてようやく本題ですが、JOINを含めたQuery Processingについては2014年に出ているこちらの本の方が詳しいので、少し紹介したいと思います。<br>
ちなみにタイトルは（かなり）盛り気味です。</p>
<h1>先に感想</h1>
<p>いくつかポイントがあると思いますが、僕が個人的に思うBigQueryのキモは次の3点です。（ちょっと想像で物を言っているので間違ってたら、、すみませんw）</p>
<ol>
<li>まずまずDisk IOの並列化（並みの並列化じゃない）</li>
<li>スピード重視でメモリとネットワークを酷使する設計（並みの酷使っぷりじゃない）</li>
<li>Slowなところを避ける代わりに出来なきゃ死ぬ設計。やり直せばいいという割り切り（その点逆にMapReduceはすごい）</li>
</ol>
<p>Disk IOを並列化して、読込をボトルネックから解放するのはこれ系では前提感あります。それに加えてネットワークを酷使したり、Hash PartitionによるShufflingなどで、メモリオーバーでabortするリスクをとるポリシーあたりがHadoopを含めたMap Reduce界隈と違うのかな、と感じます。</p>
<h1>基本構造とベーシックなクエリ処理</h1>
<p>基本的な構造としては次のようになっているようです。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/55a1103a-d5c9-4f85-a446-1a0f8faa8ea2/583ec39bdd099caa2040f48b.png" alt="583ec39bdd099caa2040f48b.png"></p>
<p>クエリは<code>Root/Mixer/Slot</code>の順で伝播します。その時Slotのみで解決できないQuery要素に関しては排除されて伝播されます。<code>Slot</code>は実際にStorageレイヤと通信し最初の処理をする<code>Leaf Server</code>のスレッドのことのようです。そして、処理結果がSlot/Mixer/Rootの順で伝播し、それぞれ統治処理が行われます。</p>
<p>例えばJOINやGroup Byが絡まず、単純な分割統治処理のようなケースの場合</p>
<pre><code>SELECT corpus, word, word_count FROM tbl 
  WHERE LENGTH(word) &gt; 4 
  ORDER BY word_count 
  DESC LIMIT 5
</code></pre>
<p>（word_countが最初からaggregationされているという現実にはなさそうなケースですが）単純に同じQueryがSlotに伝播され、それぞれのSlotが返す結果に対してMixerが同じQueryをかければ終了です。</p>
<h1>Small Group By</h1>
<p>次のようにGroup Byがある場合も分割統治型で処理されます。</p>
<pre><code>SELECT corpus, word, SUM(word_count) AS total FROM tbl 
  WHERE ... 
  Group By corpus 
  ORDER BY total 
  DESC LIMIT 5
</code></pre>
<p>まず <code>Order</code>句と<code>LIMIT</code>句を排除してSlotに渡しクエリし、その結果をMixerに渡し、Mixerでは元のクエリをかけて終了です。ただしDistinctなKeyが多い場合メモリに乗り切らずabortします。</p>
<h1>BroadCast Join</h1>
<p>さてJoinですが、単純な場合としてJoinする片方がSlotにバラまけれるサイズであれば分割統治型の繰り返しで対応できます。（BigQueryでは <code>8mb</code>が閾値のようです）。こちらは</p>
<pre><code>SELECT hoge FROM a 
  JOIN 
    (SELECT fuga FROM b) AS c 
  ON a.hoge = c.fuga
</code></pre>
<ol>
<li>サブクエリ<code>SELECT fugue FROM b</code>のみをSlotに配布</li>
<li>Mixerに結果が返される</li>
<li>返された結果をインライン展開して、全体のクエリを配布</li>
<li>Mixerに結果が集められ、Aggregationして終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0f92e382-bd5f-4629-b49c-fa7a9c372f90/583ec39bdd099caa2040f48a.png" alt="583ec39bdd099caa2040f48a.png"></p>
<p>一つ面白いのは、例えば5000 Leafあれば 5000 x 8MB = 40GBのネットワークコストをかけている、というところです。</p>
<h1>Shuffled Query（Big Join/Big Group By）</h1>
<p>最後に複雑なケースとして、大規模なJOINと大規模なGroup Byのケースです。MapReduceと同じようにShuffleフェーズを組み合わせて処理をしますが、Merge Sortではなく、単純なHash Partitioningで分散します。つまり100台のLeafで処理していれば、keyに対して100でmodを取り対応する各Leafに配布します。</p>
<p>（元々は <code>JOIN EACH</code>や<code>GROUP EACH BY</code>といった特殊な句が用意されていましたが、自動で判断するようになったようなので、省きます。( <a href="https://cloud.google.com/bigquery/docs/reference/legacy-sql">Query Reference </a> )）</p>
<pre><code>SELECT hoge FROM a 
  JOIN 
    (SELECT fuga FROM b GROUP BY fuga) AS c 
  ON a.hoge = c.fuga
</code></pre>
<ol>
<li><code>b</code>に関するサブクエリをLeafに配布する。（例えば100Leaf）</li>
<li><code>fuga</code>を100個にHash Partitioning（<code>shuffle</code>）し、Leaf間でデータを交換する</li>
<li>Leafでサブクエリを実行しMixerに終了したかどうかだけを返す（データは返さない）</li>
<li>次に<code>a</code>に関するクエリをLeafに配布する（例えば500Leaf）</li>
<li><code>hoge</code>を500個にPartitionしLeaf間でデータを交換する</li>
<li>さらに3のデータも500個にPartitionし、Leaf間でデータを交換する（この処理がどこに挟まるかちょっと書いてなくて想像で書いてます）</li>
<li>Shard上でJOINのクエリを実行し、Mixerに結果を返す</li>
<li>Mixerで統合し終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6e7a1ef9-4119-4d18-8b8c-dba18a848b52/583ec39bdd099caa2040f489.png" alt="583ec39bdd099caa2040f489.png"></p>
<p>大きな注意としては、どでかいデータでHashが偏ると乗り切らずAbortする、という点です。</p>
<h1>最後に</h1>
<p>先に書いた感想と同じですが、割と古典的というか泥臭いやり方でShuffleを実装したりしているところ、ネットワーク/メモリを酷使し、合わないものはAbortするところなど、失敗を許容する代わりにパフォーマンスを出す設計が重要なように思います。</p>
<p>もう少しMapReduce界隈との設計思想の違いについても想いを馳せてみたかったんですが、図を作っていたら力尽きた感じがあるので、議論したい方は是非ともPlaidの社内勉強会等に来てください！</p>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit.html">プレイドの採用ページ</a>か、<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


プレイドで使い倒しているBigqueryの内部構造について徹底解剖してみました！

BigQueryの内部処理について徹底解剖してみた| PLAID engineer blog

Bigqueryの内部処理について徹底解剖してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/81e6ad0d-7393-4edb-9ddf-8d6a74776c40/b169e8b6-b251-40e6-82a2-dfea82be77ff.png" alt=""></p>
<p>こんにちは！<br>
プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>本日は10/27(木)に開催しました「【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ペパボを支える大統一CI基盤と人々</li>
<li>KARTEを支えるCI環境</li>
<li>自動マルチブラウザテストを導入・運用した話</li>
<li>グーペのE2Eテスト運用事情</li>
<li>並行処理のテストは難しい</li>
</ul>
<h2>ペパボを支える大統一CI基盤と人々</h2>
<p>まずペパボ @ravelllさんから「ペパボを支える大統一CI基盤と人々」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0c5f4b9d8bc74e09ae75265cc73e9a8b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>ペパボさんのCI環境の変遷や現在の姿、現場の声、課題などについて発表して頂きました。<br>
各チームがそれぞれ <code>いいかんじに</code> CI環境を立てていた時代からdrone.ioを用いた社内統一CIができるまでのお話です。</p>
<p>CI環境を社内で統一することによって、「CI環境自体のトラブルが減ったり」「困ったときに誰にでも質問できて楽」といったメリットがあったそうです。<br>
とは言え、Dockerfileをメンテする人が有識者に限られたり、drone.io/Docker側の問題があったりと課題もあるので改善しつつ運用されているようです。</p>
<p>弊社も現在絶賛Dockerize中ですので、大変勉強になりました。</p>
<h2>KARTEを支えるCI環境</h2>
<p>次にプレイド @positiveflatから「KARTEを支えるCI環境」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="61d9c5aa1a3340e2b3a8510fd90ef810" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>プレイドでは、Web接客サービスKARTEのサービス開発当初から、CIの仕組みを強化し続けています。今回は、弊社のCIの全体像と、CI環境強化の途中で発生したいくつかの問題とその解決策について簡単に紹介しました。会場にいた方は、CIに取り組みたいけどまだ取り組んでいないという方が多かったので、今回の内容がCI導入のきっかけになれば幸いです。詳しくは<a href="/2016_08_24_uitest_automation/">こちらのブログの記事</a>でも説明していますので、是非ご覧ください。</p>
<h2>自動マルチブラウザテストを導入・運用した話</h2>
<p>次にプレイド @sdaikichiから「自動マルチブラウザテストを導入・運用した話」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="537b41d4a4434a58b6c69ebb1b701d07" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p><a href="/multi-browesr-test/">40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する</a> を元に、PLAIDでマルチブラウザ（クロスブラウザ）テストを導入・運用をした経験から、設定方法やハマりどころを紹介しました。<br>
（sdaikichiが挙手制アンケートをとったところ）会場にはほぼマルチブラウザテストを行っている人はおらず、CIのマルチブラウザテストはかなりハードルが高いことが伺えました。<br>
twitterでは「(BrowserStackに関して)テストを全て動画にしてくれるのはありがたい」などの感想がつぶやかれていました。</p>
<p>ポケモンやりすぎ！</p>
<h2>グーペのE2Eテスト運用事情</h2>
<p>続いてペパボ @hypermktさんから「グーペのE2Eテスト運用事情」の発表がありました。</p>
<div style="width: 100%">
 <script async class="speakerdeck-embed" data-id="d8b089ddbf864a848a0a88035eb4d176" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>自己紹介をPHPUnit(テストはちゃんとパスする)で書かれていて、掴みからバッチリでした！<br>
テストが全くなかったサービスにテストを導入されたお話で、チームメンバーにテストコードの必要性から実装方法までを説明し、今ではUTもE2Eテストも都度追加しておられるそうです。<br>
まずは正常閲覧テストから始めてみると簡単に実装できて良いとのことでした！</p>
<h2>並行処理のテストは難しい</h2>
<p>最後にペパボ @nakano_akihitoさんから「並行処理のテストは難しい」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0da601e2e2f1483b9cb21791d7bb0e0c" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>並列・並行処理が注目されている中、どのように並列・並行処理のテストをすればよいかを具体的にコードを見つつ説明して頂きました。<br>
<code>sleep 1</code> のように不安定な処理をいれるのではなく、<code>Humble Object pattern</code>で処理を切り出したり、<code>メッセージパッシング</code> を使うことでテストを上手く書くことが出来ます。</p>
<p>ご自身でもPHPの並列処理をするライブラリ<a href="https://github.com/ackintosh/snidel">ackintosh/snidel</a>を書かれておられるので、ご興味のある方はご覧ください！</p>
<h2>最後に</h2>
<p>今後も引き続き勉強会を開催したいと思っておりますので、一緒に勉強会を開いてくださる方を募集中です。</p>
<p>また、ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>


drone.io, CircleCI Enterprise, BrowserStack等を使用したテスト環境について、ペパボとプレイドで勉強会を開催しました！

【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜を開催しました！

<p>こんにちは。プレイドの藤川(@atsushiss15)です。<br><br>
プレイドには学生時代よりインターンとして参加しており、今年の４月に新卒社員として正式に入社しました。現在に至るまで弊社の提供するKARTEの機能開発を担当しています。</p>
<p>今回はVue.jsを利用したコンポーネント指向のUI開発において、私たちが実際に遭遇した問題とその解決策として導入したStoreパターンについてご紹介したいと思います。<br>
Vue.jsというフレームワークが題材にはなりますが、Storeパターンの考え方自体は他のフレームワークを使った開発にも転用できると思うので、ぜひ読んでみていただければと思います。</p>
<h1>目次</h1>
<ul>
<li>Vue.jsとは？</li>
<li>アプリケーションの大規模化に伴って生じた問題</li>
<li>解決策としてのStoreパターン</li>
<li>サンプルコード他</li>
<li>Storeパターンに移行した感想</li>
<li>最後に</li>
</ul>
<h1>Vue.jsとは？</h1>
<p><a href="http://jp.vuejs.org/">Vue.js</a>を一言で表現するならば、「シンプルさが売りのMVVMフレームワーク」です。<br>
他の有名なMVVMフレームワークにはAngularJSやReactなどが挙げられますが、それらに比べてVue.jsはそのシンプルさ故に学習コストが低い上、あらゆる規模のアプリケーションで利用することができる設計になっています。</p>
<p>Vue.jsを知らない方でも、簡単なToDoアプリの実装例を見てみれば大体の使い方が理解できるのではないでしょうか。</p>

<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>
<script async src="//jsfiddle.net/atsushiss15/kj29sbh1/embed/js,html,result/"></script>
<p>上記のコードは、Vue.jsの公式サイトに掲載されているサンプルのコードを便宜上CoffeeScriptで書き直したものです。</p>
<p>簡単に解説をしてみます。<br>
id属性を用いてVueインスタンスと仮想DOMの紐付けを行い、<code>v-model</code>でデータの双方向バインディング、<code>{{ }}</code>構文でテキストのレンダリング、<code>v-for</code>でリストのレンダリング、<code>v-on</code>で要素にイベントリスナのアタッチをそれぞれ行っています。</p>
<p>Vue.jsはこの辺りさえ抑えておけば、とりあえずコードを書き始めることができるので便利です。</p>
<h1>アプリケーションの大規模化に伴って生じた問題</h1>
<p>Vue.jsの最も大きな特徴の一つにコンポーネントシステムがあります。<br>
この仕組みを利用して、アプリケーションのUIをコンポーネントレベルに分割し、組み合わせるように実装することで、コードの再利用性が向上し、ロジックも各コンポーネントの中にカプセル化することができます。</p>
<p>コンポーネントの状態は各コンポーネントがそれぞれ管理し、状態やイベントの共有は<a href="http://jp.vuejs.org/api/#props">props</a>や<a href="http://jp.vuejs.org/api/#vm-dispatch">$broadcast</a>/<a href="http://jp.vuejs.org/api/#vm-broadcast">$dispatch</a>といった仕組みを利用して行います。<br>
下図はコンポーネント間でのデータやイベントの伝達をイメージしています。propsを用いてデータを子コンポーネントへ明示的に受け渡したり、$broadcastや$dispatchを使って他コンポーネントへイベントの通知を送ることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ad51dcdd-703b-4f66-8255-89a89c6bdbcb/----------2016-10-12-19.27.58.png" alt=""></p>
<p>しかし、これらの仕組みを利用すると、アプリケーションの大規模化に伴い状態管理が複雑になってきてしまいます。<br>
状態が多くのコンポーネントに分散し、更にそれらが相互作用するようになるとpropsや$broadcastを使ったコンポーネント間でのデータやイベント伝達の仕組みが多用され、コンポーネント同士が密結合・複雑化し始めるのです。<br><br>
実際にKARTEの開発においても、これらが原因でコード変更の影響範囲が分かりづらく改修が困難になり、コードの重複やサーバーサイドとの無駄な通信などが散見されるようになっていました。</p>
<h1>解決策としてのStoreパターン</h1>
<p>そこで私たちはStoreパターンによって<strong>アプリケーションの状態（State）・処理（Actions）・イベントの共有</strong>を行うことで、密結合しているコンポーネントの分離、コードの重複や無駄な通信の削減を目指しました。</p>
<h2>私たちがStoreパターンと呼んでいるもの</h2>
<p>Storeパターンは、Storeというグローバルな共有オブジェクトに複数のコンポーネントから使用される共通の状態・処理・イベントを管理させることで、コンポーネント同士を分離する考え方です。</p>
<p>下図のように、ユーザーから何らかの入力を受けたコンポーネントはStoreの共有処理（Shared Actions）を直接Callすることで共有状態（Shared State）を更新します。各コンポーネントはこの共有状態を監視することでそれぞれの表示を変化させます。<br>
また、Storeには共有のイベントも管理させます。何らかのイベントをトリガにしてコンポーネントごとの処理を行いたいケースなどは、これを利用して各コンポーネントに通知を送信します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6593975e-2483-4c37-a10a-0c568d0ed4bd/----------2016-10-13-3.02.32.png" alt=""></p>
<h2>「Fluxとは何が違うの？」</h2>
<p>というご指摘が挙がってきそうなので、<a href="https://facebook.github.io/flux/">Fluxアーキテクチャ</a>との差分についても少し触れておきたいと思います。</p>
<p><a href="http://v1.vuejs.org/guide/application.html#State-Management">Vue.js公式ドキュメント</a>でも言及されていますが、store patternは共有の状態・処理をグローバルなオブジェクトに管理させることでコンポーネント同士が密結合・複雑化してしまうのを防止することを目的としています。</p>
<p>そういった意味で、Fluxはstore patternの考え方をベースに、Event Dispatcherによる一方向（one-way）の状態更新フロー以外は許容しないという制約を加えたアーキテクチャであることが分かります。<br>
対して、私たちがStoreパターンと呼んでいるものは、Fluxの思想自体は汲み取りつつ柔軟性とシンプルさを担保したものであるといえます。</p>
<p>具体的には、状態更新に関する制約を設けないことで柔軟性を確保し、Event Dispatcher等は介さず直接関数をCallして状態更新を行うことでシンプルさを保つようにしています。そのためTPOに応じてコンポーネントが直接Storeの状態を書き換えることも許容します。</p>
<p>このように私たちがFluxのように、制約によってキレイに整理された（しかし少し大げさな）アーキテクチャよりも、柔軟性やシンプルさといったものを求めたのは**「ルールをできるだけ作らずに属人的に判断する」**という企業文化を大切にしているからです。<br>
また別の観点からみれば、KARTEの管理画面がサブアプリごとにページを分けるような構造になっており、そもそもフロントエンドが大規模化しすぎないように設計されているということも、このような方針を採る際の後押しとなりました。</p>
<h1>サンプルコード他</h1>
<p>何はともあれコードで説明するのが一番です。<br>
せっかくなので、冒頭でご紹介したToDoアプリのコードをStoreパターン的に実装してみます。</p>
<script async src="//jsfiddle.net/atsushiss15/fgone3us/1/embed/js,html,result/"></script>
<p>この例ではStoreによって状態（state）と処理（addToDo, removeTodo）の共有を行っています。<br>
一見コードが増えたようにも見えますが、複数コンポーネントで状態や処理の共有が行われるようになるとStoreパターンによる恩恵を享受できるはずです。</p>
<h2>イベントの通知について</h2>
<p>イベントの通知については幾つかの手段が考えられますが、次の２つをケースにより使い分けるのが良いのではないでしょうか。</p>
<h3 style="color:#494a50;">1. StoreのEventEmitterを利用してEventの通知を行う</h3>
<pre><code># Store側
{EventEmitter} = require 'events'
class XxxYyyStore extends EventEmitter
# 省略...
</code></pre>
<pre><code># コンポーネント側
# ...省略
methods: -&gt;
    hogeAction: -&gt;
      # 別vueや別componentに変更等を通知
      xxxYyyStore.emit 'conditionChanged', {}

  compiled: -&gt;
    # 別vueや別componentからStore経由でイベントハンドリング
    xxxYyyStore.on 'conditionChanged', () -&gt;
      # handling
</code></pre>
<h3 style="color:#494a50;">2. watchやcomputedを利用して間接的にイベントハンドリングを行う</h3>
```
# Store側
# ...省略
watch:
  'xxxYyyStoreState.todos': ->
     # 共有状態に変更があった場合の処理
computed:
    isEmpty: ->
      @xxxYyyStoreState.todos.length is 0 
```
複雑な変更と明示的なタイミングの制御が必要なものは **1.** の方法で個別にハンドリングし、そうでない場合は **2.** の方法でハンドリングするといった要領で使い分けてみると良さそうです。
<h2>その他に留意すべき点</h2>
<p>また、Vue.jsでStoreパターンを構築する際には以下の点にも留意するようにしてください。</p>
<h3 style="color:#494a50;">1. XxxYyyStore.stateに余分なものを入れない</h3>
XxxYyy.stateは、Storeの外に公開されるオブジェクトです。Vueのデータ更新監視の対象になるので、あまり大きなものを入れないほうが良いです。
<h3 style="color:#494a50;">2. XxxYyyStore.stateを置き換えない</h3>
一つのStoreインスタンスを複数箇所で使い回す形になります。
constructorで作ったstateを、複数のVueコンポーネントで監視するようになるので、state自体を置き換えるコードがあると、値の追跡が正常に行われなくなります。
```
# まずい例
constructor: ->
  @state=
    value: ''
updateXxx: (newState) ->
  @state = newState # <- @stateを置き換えているので、更新が拾えなくなる
```
<h3 style="color:#494a50;">3. 基本的に$broadcast, $dispatch, $parent, $childは使用しない</h3>
これらの仕組みはほとんどStoreパターンで補うことができるので、コンポーネントの密結合・複雑化を防ぐためにも使うべきではありません。props（データを子コンポーネントに明示的に伝達する仕組み）に関しても使用を必要最小限に抑えてください。
<br>
さて、簡単なサンプルコードを使って説明してきましたが、なんとなく感覚は掴んでいただけたかと思います。実際にはもう少し考えなければならない事があるのですが、基本的には上記のシンプルなパターンを拡張していくイメージになります。
<h1>Storeパターンに移行した感想</h1>
<h2>良かった点</h2>
<ul>
<li>サーバーとの通信処理や複雑なロジックがStore側に集約されたことで、コンポーネント側はVueが本来担うべき表示系の処理に集中できるようになった。</li>
<li>コンポーネント間の密結合が解消され、コンポーネントの再利用性が高まった。</li>
<li>全体的に見通しが良くなるのでロジックの改修等が楽に行えるようになった。</li>
</ul>
<h2>考えるべき点</h2>
<ul>
<li>重い初期化処理に対しては適宜遅延させるなどの工夫が必要になる</li>
<li>Storeでの処理後にコンポーネント側で後処理を行う際は、コールバックで行うのか、状態の変更を監視して行うのか、イベントをハンドリングして行うのか、などを適宜使い分ける必要がある</li>
<li>状態の更新フローに関する制約をどこまで設けるかは再考する必要がある</li>
</ul>
<p>所感としては、Storeパターンへの移行の目的としていた点はおおよそ満たせたのではないかと感じています。もちろんまだまだ試行錯誤が必要な点はあると思うので、より良いアーキテクチャを目指して日々改善していきたいと考えています。</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>

Vue.jsを用いたコンポーネント指向のフロントエンド開発において弊社が導入したStoreパターンについてご紹介します。

コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する