Engineer Blog

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

こんにちは！6月から8月までの3ヶ月間、プレイドでエンジニアインターンとして勤務しておりました伊藤孝太朗です。私は現在、カナダ・バンクーバーにあるブリティッシュコロンビア大学（University of British Columbia, UBC）で学部3年生としてコンピュータサイエンスを専攻しています。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月_プレイドエンジニアブログ

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月

長期運用システムにおけるNode.js / npmアップデート工程を紹介します

KARTEの分析システムのNode.jsを16から20にアップデートしました

<p>株式会社プレイドでデザインエンジニアをしている安田です。</p>
<p>この記事では、社内向けに提供しているライブラリの使用状況を把握すべく作成した、プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。</p>
<h2>ライブラリ開発の問題と使用状況の解析</h2>
<p>弊社では、KARTEのプロダクト群全体のデザインシステムである「Sour」を開発しています。その一環として、React製のUIライブラリ「sour-react」を作成し、社内向けのnpmパッケージとして提供しています。現在、sour-reactはKARTEのいくつものプロダクトにおいて採用されており、UI開発に欠かせないものになるほど浸透しています。</p>
<p>作成したライブラリが広く使われるようになるのは喜ばしくもありますが、一方、それに伴って新たな問題が生じることもあります。その一つが、後からの仕様変更、とりわけ破壊的変更が難しくなってしまうことです。</p>
<p>原則的には、できるだけライブラリの破壊的変更を起こさないように開発を進めるべきではあります。しかし、ライブラリの機能が増え続けたり運用期間が長期化したりした結果、いずれその必要に迫られることは多かれ少なかれ避けがたいものです。</p>
<p>もし、ライブラリのユーザー数が少なく、その使用範囲も微々たるものであれば、破壊的変更が発生しても対応は容易です。しかしsour-reactは、数多くのプロダクトのUIにふんだんに組み込まれているため、破壊的変更に伴う影響を軽視できなくなりつつあります。また、破壊的変更に対応するためのユーザー側の労力が大きくなればなるほど、バージョンアップ作業が滞ってしまい、UIの不具合が放置される結果に繋がってしまうこともあります。とはいえ、その影響を必要以上に懸念して、変更すべきものを変更せずに誤魔化し続けるのも不健全です。</p>
<p>そこで、仕様変更に伴う影響範囲を適切に把握すべく、ライブラリの使用状況を解析して可視化する仕組みを作成しました。具体的に言えば、KARTEのすべてのソースコードの中から、sour-reactが読み込まれている箇所を検出して、どのプロダクトからどのモジュールが参照されているかを個別に自動集計するというプログラムを作成しています。これを用いて、マークダウンファイルとして次のような集計結果を出力しています。</p>
<p><img src="https://ik.imagekit.io/plaid/b771e07d-ef2a-4f12-a1cb-05c25b971b8a/1.png" alt="表形式で「Accordion」「AdminLayout」「AutoComplete」などの行が並び、列ごとに数値がそれぞれ表示されている"></p>
<p><img src="https://ik.imagekit.io/plaid/0f570cbc-c10d-414a-9123-a67b638c14e1/2.png" alt="「sour-reactのモジュールごとの集計」という大見出しがあり、「Button (422)」という中見出しに続いて「XXX (140)」という小見出しがある。続いてファイルパスがリストで表示されている"></p>
<p><img src="https://ik.imagekit.io/plaid/02a8f29d-635b-4b2e-99dc-2eb40a111be7/3.png" alt="「sour-reactを利用するパッケージごとの集計」という大見出しがあり、「XXX (1720)」という中見出しに続いて「Button (140)」という小見出しがある。続いてファイルパスがリストで表示されている"></p>
<p>これらの集計はGitHub Actionsによって定期的に自動実行され、毎朝9時になるたび最新の状態にアップデートされるようになっています。</p>
<p>この仕組みによって、実際にモジュールが参照されている箇所や、どのモジュールの使用頻度が高いか、どのプロダクトにおいて積極的に採用されているかなどを、効率的に調査できるようになりました。</p>
<p>一つの活用例としては、不要なモジュールをライブラリから削除するために、この集計結果を参考にして選定したことが挙げられます。Sourにはその歴史的な経緯により、特定のプロダクトでしか使われないような特殊なモジュールや機能が多く含まれていました。それらは本来的には、共有ライブラリとしてではなく、それぞれのプロダクト側のソースコードとして管理されるべきです。とはいえ、すでにライブラリとしての提供を行なってしまっている以上、意図せずそれらが使用されてしまっている可能性もあり、その疑念が晴れない限りは削除してしまうことが必ずしも得策とは言い切れませんでした。そこで、こうした集計結果を参考にすることで、各モジュールの使用状況を正確に把握し、確信を持って安全に変更を行うことができました。</p>
<h2>実装方法の解説</h2>
<p>続いて、先述した仕組みの実装方法について解説します。なお、この記事で紹介する仕組みは、OSSとしてGitHubに公開しています。解説と併せて参照してください。</p>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats">yuheiy/internal-library-reference-stats</a></p>
<p>集計結果の出力形式は次の3種類とします。</p>
<ol>
<li><code>README.md</code>: 横軸がsour-reactのモジュール名、縦軸がプロダクト名になったテーブルを出力する。セルにはそれに対応する参照箇所数を表示する。最終列と最終行には合計値を表示する。</li>
<li><code>by-module-export-name.md</code>: 見出し2がsour-reactのエクスポート名、見出し3がプロダクト名という文書構造になり、参照箇所のファイル一覧がそれに続く。</li>
<li><code>by-user-package.md</code>: 見出し2がプロダクト名、見出し3がsour-reactのエクスポート名という文書構造になり、参照箇所のファイル一覧がそれに続く。</li>
</ol>
<p>処理の流れは主に次のようになります。</p>
<ol>
<li>
<p>KARTEのソースコードを含むGitリポジトリから、拡張子が<code>js,ts,jsx,tsx</code>のいずれかに当たるファイルすべてを読み込む</p>
</li>
<li>
<p>TypeScriptのCompiler APIを使って、sour-reactを読み込むimport文を抽出する</p>
</li>
<li>
<p>import文の形式がnamed importsであれば、そのエクスポートの名前とimport文が出現する行数を取得する</p>
</li>
<li>
<p>named importsの解析結果をフラットな配列としてまとめる</p>
<pre><code class="language-tsx">export type NamedImportsStat = {
  sourcePath: string;
  moduleExportName: string;
  lineRange: LineRange;
};

export function getNamedImportsStats(filePaths: string[]): NamedImportsStats[] {
  // ...
}
</code></pre>
</li>
<li>
<p>解析結果をまとめたものを出力形式に応じて加工して出力する</p>
</li>
</ol>
<p>これらについて、いくつかにポイントを絞って解説します。</p>
<p>まず、ソースコードを解析するに当たって、対象となるソースコードを用意します。この仕組みをGitリポジトリとして管理するのであれば、解析対象のソースコードは<a href="https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB">サブモジュール</a>として取り込むのがよいでしょう。</p>
<p>それらのソースコードからimport文を抽出するには、ASTを使用するのが最適です。ソースコードからASTを生成するためにはいくつかのやり方がありますが、今回は<a href="https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API">TypeScriptのCompiler API</a>を使用することとします。</p>
<p>sour-reactでは、必要なモジュールを都度named importsによって読み込むことを推奨しています。具体的な使用例は次の通りです。</p>
<pre><code class="language-tsx">import { Button, Tabs } from '@plaidev/sour-react';
</code></pre>
<p>このようなソースコードを解析して、named importsによって読み込まれているエクスポート名と、ソースコード内でimport文が出現する行数を取得します。たとえば次のような実装になります。</p>
<pre><code class="language-tsx">import fs from 'node:fs';
import ts from 'typescript';

type LineRange = {
  start: number;
  end: number;
};

type NamedImports = Record&lt;string, { lineRange: LineRange }&gt;

export function analyzeNamedImports(filePath: string, targetModuleName: string): NamedImports {
  const fileContent = fs.readFileSync(filePath, 'utf8');
  const sourceFile = ts.createSourceFile(filePath, fileContent, ts.ScriptTarget.Latest, true);

  const namedImports: NamedImports = {};

  function visit(node: ts.Node) {
    if (ts.isImportDeclaration(node)) {
      const moduleSpecifier = node.moduleSpecifier.getText().slice(1, -1); // Remove quotes

      if (moduleSpecifier === targetModuleName) {
        const start = sourceFile.getLineAndCharacterOfPosition(node.getStart()).line + 1;
        const end = sourceFile.getLineAndCharacterOfPosition(node.getEnd()).line + 1;
        const lineRange: LineRange = { start, end };

        const importClause = node.importClause;

        if (importClause) {
          if (importClause.namedBindings &amp;&amp; ts.isNamedImports(importClause.namedBindings)) {
            importClause.namedBindings.elements.forEach((element) =&gt; {
              const importName = element.propertyName?.text ?? element.name.text;
              if (!(importName in namedImports)) {
                namedImports[importName] = { lineRange };
              }
            });
          }
        }
      }
    }

    ts.forEachChild(node, visit);
  }

  visit(sourceFile);

  return namedImports;
}
</code></pre>
<p>そして、この結果を後続の処理で扱えるように、フラットな配列としてまとめます。</p>
<pre><code class="language-tsx">import { analyzeNamedImports, type LineRange } from './import-analyzer';

const targetModuleName = '@plaidev/sour-react';

export type NamedImportsStat = {
  sourcePath: string;
  moduleExportName: string;
  lineRange: LineRange;
};

export function getNamedImportsStats(filePaths: string[]) {
  const result: NamedImportsStat[] = [];

  for (const filePath of filePaths) {
    const namedImports = analyzeNamedImports(filePath, targetModuleName);

    for (const [moduleExportName, { lineRange }] of Object.entries(namedImports)) {
      result.push({
        sourcePath: filePath,
        moduleExportName,
        lineRange,
      });
    }
  }

  return result;
}
</code></pre>
<pre><code class="language-tsx">import fg from 'fast-glob';
import { analyzeFiles } from './import-analysis-organizer';

async function main() {
  const filePaths = await fg.glob('internal-library-reference-stats-user-a/**/*.{js,ts,jsx,tsx}');
  const namedImportsStats = getNamedImportsStats(filePaths);
  // ...
}

main().catch((e) =&gt; {
  throw e;
});
</code></pre>
<p>こうして作成した配列を、データの出力形式に応じて分類します。モジュールのエクスポート名とプロダクト名というそれぞれの軸に応じて処理します。</p>
<pre><code class="language-tsx">function groupByModuleExportName(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  // ...
}

function groupByUserPackage(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  // ...
}

const byModuleExportName = groupByModuleExportName(namedImportsStats);
const byUserPackage = groupByUserPackage(namedImportsStats);
</code></pre>
<p>データをプロダクトごとに分類する際には、import文が書かれているファイルがどの<code>package.json</code>に属しているかに基づいて処理します。<a href="https://github.com/sindresorhus/pkg-dir">pkg-dir</a>を使うことで、そのファイルの親に当たる<code>package.json</code>のパスを取得できます。</p>
<pre><code class="language-ts">import path from 'node:path';
import { packageDirectorySync } from 'pkg-dir';

function groupByUserPackage(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  const result = Map.groupBy(namedImportsStats, ({ sourcePath }) =&gt;
    packageDirectorySync({ cwd: path.dirname(sourcePath) })
  );
  // ...
}
</code></pre>
<p>これらのような操作によって、最終的に出力するコンテンツを生成します。実際の処理はやや複雑であるため、説明は割愛します。ご興味があればソースコードを見てみてください。</p>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats/blob/main/scripts/renderers.ts">internal-library-reference-stats/scripts/renderers.ts</a></p>
<p>最後に、これらの処理を定期的に実行させるために、GitHub Actionsのワークフローをセットアップします。ソースコードの解析を行う前に、サブモジュールとsour-reactのバージョンを最新の状態にアップデートするようにします。ワークフローは、日本時間で午前9時になるたび毎日実行されるように設定します。</p>
<pre><code class="language-yaml">name: Auto update

on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

jobs:
  auto-update:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: true
      - name: Update submodules
        run: git submodule update --remote
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: npm
      - name: Install dependencies
        run: |
          npm ci
          npm update @plaidev/sour-react
      - name: Build
        run: npm run build
      - name: Commit changes
        run: |
          git config user.name github-actions[bot]
          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
          git add --all
          git commit -m &quot;Automated build&quot;
          git push
</code></pre>
<h2>internal-library-reference-statsの使い方</h2>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats">internal-library-reference-stats</a>はOSSとして公開されているので、どなたでもご自由に利用することができます。基本的には、次のようにすることで使い始められます。</p>
<ol>
<li>
<p>internal-library-reference-statsをテンプレートリポジトリとして新規リポジトリを作成する</p>
</li>
<li>
<p>作成したGitリポジトリをクローンする。<code>git clone</code>に<code>--recursive</code>フラグを付与するとサブモジュールも併せてクローンできるが、この時点では不要</p>
</li>
<li>
<p>サンプル用のサブモジュールとその設定を削除する</p>
<pre><code class="language-sh">rm -rf user-repositories/*/
rm .gitmodules
git add .
git commit -m &quot;deinit submodules&quot;
</code></pre>
</li>
<li>
<p>解析対象のGitリポジトリをサブモジュールとして追加する</p>
<pre><code class="language-sh">git submodule add https://github.com/&lt;user&gt;/&lt;name&gt; user-repositories/&lt;name&gt;
</code></pre>
</li>
<li>
<p>サブモジュールをクローンするためにトークンが必要であれば、<code>.github/workflows/auto-update.yml</code>でのチェックアウトのステップにトークンを設定する</p>
<pre><code class="language-yml">- name: Checkout
  uses: actions/checkout@v4
  with:
    token: ${{ secrets.GITHUB_ACCESS_TOKEN }}
    submodules: true
</code></pre>
</li>
<li>
<p><code>package.json</code>の<code>name</code>を任意の名前に変更する。これが<code>README.md</code>のタイトルになる</p>
</li>
<li>
<p>解析対象のモジュールをインストールする</p>
<pre><code class="language-sh">npm remove antd
npm install @plaidev/sour-react
</code></pre>
</li>
<li>
<p><code>scripts/config.ts</code>の設定を書き換える</p>
<ul>
<li><code>targetModuleName</code>は解析対象のモジュール名。この記事で言うところの<code>@plaidev/sour-react</code></li>
<li><code>targetModuleTitle</code>は解析対象のモジュールのタイトル。<code>README.md</code>に表示される。<code>targetModuleName</code>と同じでも構わない</li>
<li><code>targetModuleUrl</code>は解析対象のモジュールのURL。<code>README.md</code>からリンクされる</li>
<li><code>userPackageNameMap</code>はプロダクトの表示名。対象となるプロダクトのディレクトリへのパスと、その名前の対応関係を設定する。未設定の場合は、ディレクトリのパスが表示名として出力される。ビルドを実行することで対象ディレクトリを把握できるので、一度ビルドを行ってからの方が設定しやすい</li>
</ul>
</li>
<li>
<p><code>.github/workflows/auto-update.yml</code>でのインストールのステップで、解析対象のモジュールをアップデートするように設定する</p>
<pre><code class="language-yml">- name: Install dependencies
  run: |
    npm ci
    npm install @plaidev/sour-react@latest
</code></pre>
</li>
<li>
<p>依存関係をインストールしてからビルドする。プロダクトの表示名が未設定の場合はディレクトリのパスが出力されるので、別の表示名にしたければ<code>scripts/config.ts</code>で設定する</p>
<pre><code class="language-sh">npm ci
npm run build
</code></pre>
</li>
<li>
<p><code>.github/workflows/auto-update.yml</code>でコメントアウトされた<code>schedule</code>を有効化する</p>
<pre><code class="language-yml">on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:
</code></pre>
</li>
<li>
<p>変更をコミットしてプッシュする</p>
</li>
</ol>
<h2>最後に</h2>
<p>ライブラリの使用状況を解析する仕組みについては、ライブラリを開発するエンジニアであれば一度は考えたことがあるかと思いますが、開発コストや実現可能性などの問題により、実際に作成された例はあまり多くはないのではないでしょうか。</p>
<p>今回作成したこの仕組みをオープンソースとして公開することで、みなさんの開発現場においても、使用状況の可視化を実現するための助けになれば幸いです。</p>


プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。

ソースコードを解析して社内向けUIライブラリの使用状況を自動で集計する

<p>ごきげんよう、@tik-son です。</p>
<p>2024年7月25日(木)に開催された <a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service Dev Day（AOAI Dev Day）</a>にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。<br>
今回はそのレポートをお届けします。</p>
<h2>イベント概要</h2>
<p>AOAI Dev Day は、Azure OpenAI Service を活用する開発者コミュニティの祭典です。<br>
「開発者が実際のプロジェクトから得た経験や教訓を共有する」という趣旨のもと、実践的なセッションが多く見受けられ、オフライン開催限定ならではの一体感と熱気に包まれていました！</p>
<h2>登壇内容サマリー</h2>
<p>今回の私のセッションでは、プレイドが開発する PaaS である「KARTE Craft」の開発を支援する AI アシスタント「Craft Copilot」の仕組みについて、アーキテクチャや技術選定の背景を交えながら解説しました。</p>
<script defer class="speakerdeck-embed" data-id="b43df62d30944212a86f0c5e92c65d8b" data-ratio="1.7772511848341233" src="//speakerdeck.com/assets/embed.js"></script>
<h3>Craft Copilot とは？</h3>
<p>「Craft Copilot」は、KARTE Craft での開発体験を向上させるために生まれた AI アシスタントです。<br>
現在β版として提供中で、将来的には KARTE Craft を利用する開発者の強力なパートナーとなることを目指しています。</p>
<h3>Craft Copilot の機能</h3>
<p>Craft Copilot は、色々あるのですが、今回の登壇では主要機能である以下の2つの機能についてお話しました。</p>
<ol>
<li><strong>AI によるサイト制作支援</strong><br>
Craft Sites Copilot」機能により、HTML や CSS のコードを書かずに、自然言語の指示やイメージ画像から Web ページを自動生成できます。</li>
<li><strong>Craft のルールを踏まえたコード改善</strong><br>
既存のコードを Craft のルールに沿って自動的に修正できます。</li>
</ol>
<h3>技術スタックの裏側</h3>
<p>Craft Copilot は、Microsoft が提供する Azure OpenAI Service を中心に、Azure の様々なサービスを組み合わせて開発されています。</p>
<p><strong>Azure OpenAI Service (GPT-4o, GPT-4o-mini)</strong></p>
<ul>
<li>自然言語処理の中核を担っており、HTML 生成やコード修正の指示理解、回答生成などを実現しています。</li>
</ul>
<p><strong>Azure AI Search</strong></p>
<ul>
<li>Craft Copilot が参照するドキュメントをベクトル化して保存・検索するために利用しています。</li>
<li>セマンティックハイブリッド検索によって、高精度な検索を実現しています。</li>
</ul>
<p><strong>Azure API Management</strong></p>
<ul>
<li>API の可用性、キャパシティ、メンテナビリティを向上させるために利用しています。</li>
<li>Backend Pool やサーキットブレーカーを活用することで、柔軟な API 運用を実現しています。</li>
</ul>
<h2>登壇を終えて</h2>
<p>今回の AOAI Dev Day では、Craft Copilot のアーキテクチャや Azureサービス利用におけるTips などに対して高い関心を寄せていただき、登壇後に、Ask the Speakerで多くの方とお話ししました。</p>
<p>また、他の登壇者の方々との交流を通して、Azure OpenAI Service を活用したサービス開発の最新動向や、AI 開発における課題や展望を共有することができ、<br>
改めて、Azure OpenAI Service は、開発者にとって大きな可能性を秘めていることを実感しました。</p>
<h2>イベント後のアップデート</h2>
<p>実は、今回の登壇時には OpenAI の GPT-4o-mini を利用していたのですが、先日、<a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service 版の GPT4o-mini がリリース</a>されたので置き換えました。<br>
このスピード感は開発者としてはありがたいですね。</p>
<p>Craft Copilot はまだβ版ですが、今後も Azure OpenAI Service の最新機能やアップデートを積極的に活用し、より強力な AI アシスタントを目指して、今後も開発を続けていきます。<br>
一緒に改善していきたい人も<a href="https://recruit.plaid.co.jp/requisitions/product-engineer">絶賛募集中</a>です！</p>


2024年7月25日(木)に開催された Azure OpenAI Service Dev Day（AOAI Dev Day）にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。今回はそのレポートをお届けします。

Azure OpenAI Service Dev Day に登壇しました_プレイドエンジニアブログ

Azure OpenAI Service Dev Day に登壇しました

<h1>はじめに</h1>
<p>こんにちは、プレイドのCore Platformチームに所属している西村です。今回のブログではGCE上でセルフホストしていたMongoDBインスタンスをMongoDB Atlasに移行した際の取り組みについて紹介します。移行に伴う要件や制約を考慮した結果、今回はあえてMongoDB固有の機能を使わずにGKEのJobを使って愚直にデータ移行する方法を採用したので、同じような移行作業を行う場合は参考になれば幸いです。</p>
<h2>背景</h2>
<p>プレイドではDBとして多くの部分で<a href="https://www.mongodb.com/ja-jp/atlas">MongoDB Atlas</a>を使用しています。MongoDB Atlasでは定期的にサポートバージョンが更新され、プレイドでもそれに合わせて適宜バージョンアップ対応を行っています。<a href="https://tech.plaid.co.jp/internship-mongodb-update">前回のバージョンアップ作業</a>は2023年末から2024年3月頃にかけて実施したのですが、そこで長らくGCE上で稼働していた古いバージョンのMongoインスタンスをこの機会にMongoDB Atlasに移行することにしました。</p>
<p>このインスタンスはOplogというKARTEの管理画面の操作履歴を保存しているもの（以降、旧Oplog）で、通常はほとんど参照されないデータなのでこれまでのバージョンアップ作業でも見落とされてしまっていました。しかし今回のバージョンアップでこのインスタンスで稼働しているMongoのバージョン（3.x）と更新後のバージョン（5.x）の互換性がなくなるため、こちらもバージョンアップ対応するかMongoDB Atlasに移行するか選択する必要がありました。今後のバージョンアップ対応や管理の煩雑さを考えて、この機に旧Oplogを廃止してMongoDB Atlas（以降、新Oplog）に移行する判断をしました。</p>
<h2>移行方法の検討</h2>
<p>移行にあたってまず要件を決める必要があります。今回の移行プロジェクトの要件は以下のように定めました。</p>
<ul>
<li>旧Oplogの過去データをすべて新Oplogに移行する</li>
<li>サービスは無停止でデータおよび書き込み先の移行を行う</li>
<li>想定外のトラブルがあってもデータの欠損が極力発生しないようにする</li>
<li>移行完了後に旧Oplogは廃止する</li>
</ul>
<p>上記の要件を満たすために以下の作業を順次実施することにしました。</p>
<ol>
<li>MongoDB Atlasに移行用Clusterを作成する（新Oplog）</li>
<li>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</li>
<li>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</li>
<li>データ移行完了後、旧Oplogへの書き込みを停止しインスタンスを破棄する</li>
</ol>
<p>図にすると以下のようなイメージです。<br>
<img src="https://ik.imagekit.io/plaid/ee37750e-63d1-47ac-9991-552cf0506361/migrate-oplog-2.png" alt="migrate-oplog-2.png"></p>
<p>以下ではそれぞれの手順で実施した内容について要点を解説します。</p>
<h3>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</h3>
<p>DBの移行にあたって必要な作業は主にデータ移行と接続先の変更の2つです。論理的には旧Oplogに書き込んでいる箇所の書き込み先を新しく作成した新Oplogに変更すれば新規に書き込むデータに関しては移行できるはずですが、いきなり接続先を切り替えると不具合があって書き込みができないなどのトラブルが発生した場合にデータが欠損してしまうため、慎重を期すために従来通り旧Oplogへの書き込みをしつつ新たに新Oplogへも同時に書き込む仕組みを実装し、既存の仕組みに影響を与えないようにしました。</p>
<h3>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</h3>
<p>2重書き込みについては特に大きな問題もなく実装することができました。これは一部のシステムを除いて旧Oplogを書き込む処理は社内の共通ライブラリ経由で実行されており、書き込み先の設定を変えて新Oplogへの書き込み処理を追加するだけで済んだためです。</p>
<p>あとは旧Oplogのデータを移行すれば必要な作業はほぼ終わりだったのですが、データ移行処理がなかなかうまくいかず試行錯誤が必要でした。その試行錯誤について詳しく見る前に、まずはMongoDBで推奨されているデータ移行方法と、なぜ今回それらの方法を採用しなかったのか簡単に説明します。</p>
<h3>MongoDB標準のデータ移行方法</h3>
<p>MongoDB標準のデータ移行方法としてJSON/CSVでの<a href="https://www.mongodb.com/docs/compass/current/import-export/">Import/Export</a>と<a href="https://www.mongodb.com/ja-jp/products/platform/migrate">Live Migration</a>があります。それぞれについて簡単に説明します。</p>
<h4>Import/Export</h4>
<p>Import/Exportは<a href="https://www.mongodb.com/ja-jp/products/tools/compass">MongoDB Compass</a>での操作もしくはCLIでそれぞれに対応したコマンドを実行することでCollectionのデータを指定したフォーマットでExportおよびImportすることができる機能です。前回のMongoバージョンアップ作業で4.x→5.xでも想定外の微妙な挙動の差異があったが今回は3.x→5.xなので動作差分が読めないこと、本番データ量が膨大（約2.3億レコード、500GB以上）で一括Importに懸念があることなどから今回は採用しないことにしました（とはいえ一度試してみてもよかったかも）。</p>
<h4>Live Migration</h4>
<p>Live MigrationはMongoDB Atlasで提供されている機能で、コンソールから設定するだけでオンプレミスも含めて任意の環境からMongoDB AtlasのClusterにデータ移行できるという機能です。Live Migrationではデータ移行中も移行元DBへの読み取りおよび書き込みが可能ですが、別のチームで試してみたところ断続的に常に書き込みが発生しているシステムだとデータ移行が完了できないという特性があり、完全に無停止でデータを移行しきるのは難しいとのことでした。</p>
<p>上記のようにMongoDBの標準的なデータ移行方法では今回の要件を満たすことが難しそうだったため、旧OplogからCursorでデータを取得し新Oplogに書き戻すという愚直な方針を採用することにしました。</p>
<h3>GKEでデータ移行用のJobを実行する</h3>
<p>プレイドではアプリケーションの実行環境として多くの場所でGKEを使用しています。既存のデプロイの仕組みを流用するため、今回はデータ移行用のスクリプトをGKEのJobで実行することにしました。データ移行にあたっては以下の手順で段階的に進めていきました。</p>
<ol>
<li>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</li>
<li>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</li>
<li>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</li>
</ol>
<p>以下で各手順で試した内容と結果を説明します。</p>
<h4>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</h4>
<p>まずは旧Oplogから取得した任意のデータを新Oplogに書き込めることを確認するため、Dev環境で作成したテスト用ClusterにEvaluation環境の旧Oplogの1日分のデータを書き込んでみることにしました。データ量としては約5000〜6000レコード程度で、以下のような移行スクリプトで問題なく書き込めることが確認できました（サンプル用に簡略化しています）。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行時点以前のデータを抽出する（日付は仮）
  const dateBegin = new Date('2024-04-01T00:00:00.000+00:00');
  const dateEnd = new Date('2024-04-02T00:00:00.000+00:00');
  const cursor = oplogGce.find({ timestamp: { $gte: dateBegin, $lt: dateEnd } }).cursor({ batchSize: 5000 });

  cursor.on('data', (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    oplog.save();
  });

  cursor.on('end', () =&gt; {
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h4>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</h4>
<p>テスト用Clusterへの書き込みが問題なく行えたので次はEvaluationの過去データ（約300万件、5GB程度）を移行するために日付の指定と書き込み先を変えて先ほどのJobを動かしたところOOM(Out Of Memory)エラーが発生するようになりました。</p>
<p>お気づきの方も多いかと思いますが、先ほどのコードではCurosrで取得したデータを1件ずつ書き込んでいたためデータ件数が多くなると書き込み処理が追いつかずOOMが発生してしまいます。今回のケースだと数万件程度処理が進んだ段階でOOMが発生しました。OOMを避けるためバッチサイズごとにバルクで書き込むように修正することでOOMの発生を抑えることができました。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行対象のデータを抽出する（日付は仮）
  const date = new Date('2024-04-01T00:00:00.000+00:00');
  const batchSize = 5000;
  const cursor = oplogGce.find({ timestamp: { $lte: date } }).cursor({ batchSize });

  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
    }
  });

  cursor.on('end', async () =&gt; {
    if (bulkOps.length &gt; 0) {
      await oplogAtlas.bulkWrite(bulkOps);
    }
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h5>途中でJobが止まる問題が発生</h5>
<p>前項のようにCurosrで取得したデータをバルクでまとめて処理することで安定的にJobを実行することができるようになりましたが、今度は20万件程度のデータを処理した時点で、残りの処理が完了する前にJob自体が終了してしまうという問題に遭遇しました。ここに至るまでにもOOM対策としてヒープメモリを追加したりCPUスペックの強化、 <code>async/await</code> で新Oplogへの書き込み結果を待つなどの試行錯誤をしてきたのですが、エラーログやGKEのメトリクスを見ても特に問題はなく、Jobとしてはすべての処理が完了して正常終了しているように見えました。</p>
<p>原因を調べるために調査用のログを仕込んで観察してみると、どうやら新Oplogへ書き込んでいる箇所のawaitが効いていなさそうだということがわかりました。つまり新Oplogへの書き込み箇所でawaitすることで書き込み処理の完了を待っているつもりだったのですが、Cursorの <code>on('data', ...)</code> はデータがある限り実行され続けてしまうため、新Oplogへの書き込みが完了する前にCursorの読み込みが終わってしまうという状態になっていそうだということがわかりました。</p>
<p>上記の現象の対策として新Oplogへの書き込み中はCursorの読み込みを一時停止し完了後に再開することで、無事に意図通りの挙動にすることができました。最終的なコードは以下のようになりました。</p>
<pre><code class="language-typescript">  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      cursor.pause();  // 書き込み前にCursorの読み込みを中断
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
      cursor.resume();  // 書き込み完了後にCursorの読み込みを再開
    }
  });
</code></pre>
<h4>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</h4>
<p>前項まで見てきたようにいろいろな落とし穴にハマりつつ、なんとか安定的にJobを動かしCursorで逐次的にデータを取得しMongoDB AtlasのClusterに大量データを書き込むという一連の処理を実装することができました。最後の仕上げとしてProduction環境の旧Oplogから新Oplogへのデータ移行Jobを実行して無事に全データを移行することができました。ちなみにProductionのデータは5年以上分、500GB程度ありJobの完了までに27時間程度かかりました。</p>
<h2>まとめ</h2>
<p>本ブログではGCE上で稼働しているMongoDBインスタンスを無停止でMongoDB Atlasに移行した取り組みを紹介しました。今回の取り組みではサービス固有の機能に依存しない汎用的な手法で移行を行ったので、似たような作業をされる場合の一つの方法として参考になれば幸いです。</p>


GCE上でセルフホストしていたMongoDBインスタンスをサービス無停止でMongoDB Atlasに移行した取り組みを紹介します

セルフホストしてるMongoDBをMongoDB Atlasに移行した話_プレイドエンジニアブログ

セルフホストしているMongoDBをMongoDB Atlasに移行した話

<p>こんにちは、PLAIDのエンジニアの池上 a.k.a. gami(@jumpei_ikegami) です。</p>
<p>好きなブキは、「プロモデラーMG」です。</p>
<p>さて今回は、仕事で調査用の「Chrome拡張機能」を作ったので、「Chromeデベロッパーツール」に「独自ツール」を追加するための手順について紹介したいと思います。</p>
<h1>Chromeデベロッパーツール、使っていますか？</h1>
<p>弊社では、「<a href="https://karte.io/">KARTE</a>」というサービスを開発しています。</p>
<p>「KARTE」の主な機能として、サイトにJavaScriptのタグを埋め込んでもらい、サイト上からユーザーの行動履歴や属性情報を取得し、それに応じたコンテンツをサイト上に配信するというものがあります。</p>
<p>しかし、「KARTE」の「タグ」が正しく設置されていないと、ユーザーの情報が取得できず、コンテンツの配信が思ったようにできないことがあります。</p>
<p>そんなときは、「Chromeデベロッパーツール」を使って、お客様のサイトで「KARTE」が動作しない原因を調査します。</p>
<p>例えば、「Elementsタブ」では、サイトのHTMLを見て、実際にscriptタグでJavaScriptの「タグ」が埋まっているかを確認できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6a87df74-810b-4245-b832-c2155a579030/----------2017-08-14-4.47.14.png" alt=""></p>
<p>JavaScriptのオブジェクトがページ上から参照できるようになっているかは、「Consoleタブ」でそのオブジェクトを実際に参照してみるとわかります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fce82a31-ebc1-4d72-9ab0-afae7bca9c35/----------2017-08-14-4.51.50.png" alt=""></p>
<p>また、サーバーとの間の通信内容を追いたい場合は、「Networkタブ」から見ることができます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b56e220-563c-4056-9231-a7c0cde0edbc/----------2017-08-14-4.46.36.png" alt=""></p>
<p>これらを駆使して、サイト上のあらゆる情報にアクセスすることができます。</p>
<p>フロント寄りのWebエンジニアであれば、サイトの状態を可視化するために「Chromeデベロッパーツール」など、ブラウザの「開発者向け機能」を使う機会は多いと思います。</p>
<h1>Chromeデベロッパーツールでは物足りない！</h1>
<p>しかし、「Chromeデベロッパーツール」がデフォルトで提供する機能だけでは物足りなくなることがあります。</p>
<p>当たり前ですが、「Chromeデベロッパーツール」は、どんなWebサイトでも使える機能だけが入っており、中立的に作られています。</p>
<p>しかし、「KARTE」の「タグ」が正しく設置されているかの調査であれば、「ブラウザ」と「KARTEのサーバー」との間の通信有無だけが可視化されれば事足ります。</p>
<p>あわよくば、「KARTEのサーバー」との間の通信内容だけを見やすく表示することができれば、さらに便利になります。</p>
<p>こうしたニーズに応えるために、「Google Chrome」では、デベロッパーツールを拡張して、独自のタブを追加することができます。</p>
<h1>デベロッパーツール拡張の例</h1>
<p>「Chromeデベロッパーツール拡張機能」の例としては、Web系のフレームワークに関するものが多くあるようです。</p>
<p>例えば、弊社でも使っている「Vue.js」にも、「<a href="https://chrome.google.com/webstore/detail/vuejs-devtools/nhdogjmejiglipccpnnnanhbledajbpd?hl=ja">Vue.js devtools</a>」というChrome拡張が用意されています。</p>
<p>インストールすると、「Vue.js」を使っているサイトで機能がアクティブになり、デベロッパーツールに「Vue」というタブが追加されます。</p>
<p>「Vue」タブの中では、サイトで検知された「Vue」のバージョンや、「Vue Component」の中身が、可視化されます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b9b39063-78ed-4394-85c3-44a62fff53f8/----------2017-08-14-5.15.29.png" alt=""></p>
<p>他にも、Googleが公開している「<a href="https://developer.chrome.com/devtools/docs/extensions-gallery">Featured DevTools Extensions</a>」のページを見ると、「React」、「Angular」、「Rails」、「jQuery」などでも同様のツールがあるようです。</p>
<h1>KARTEデベロッパー向けツールを作った</h1>
<p>これらの例を参考に、「KARTE」の「タグ」が正常に発火しているかを調査するための「Chromeデベロッパーツール拡張機能」を作りました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5f50e51f-6074-490f-bb0b-02b51affba46/----------2017-08-14-5.30.51.png" alt=""></p>
<p>「KARTE」のサーバーとの間の通信を監視し、ユーザー情報に当たる部分のみを取得して「KARTEタブ」の中に表示しています。</p>
<p>タブ内のUI制御には、「Vue.js」を使っています。</p>
<p>残念ながらソースコードは非公開なので、以下では「Chromeデベロッパーツール拡張機能」の簡単なサンプルを作ってみます。</p>
<h1>Twitter検出ツールを作ってみる</h1>
<p>ここでは、「Chromeデベロッパーツール拡張機能」の作り方を紹介しながら、サイト上にTwitterの「埋め込みTL」や「Followボタン」が設置されているかどうかを瞬時に見極めるツールを、「Chromeデベロッパーツール」内に作ってみます。</p>
<h2>ステップ1. ディレクトリ作成</h2>
<p>「Chrome拡張機能」に読み込ませるディレクトリを作成します。</p>
<p><code>$ mkdir chrome-extension-sample</code></p>
<p><code>$ cd chrome-extension-sample</code></p>
<p>以下、全てのファイルは<code>chrome-extension-sample</code>ディレクトリ直下に置いていきます。</p>
<h2>ステップ2. デベロッパーツールにタブを追加する</h2>
<p>次に、デベロッパーツールに独自タブを追加します。</p>
<p>以下が、Googleの公式概念図です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3fe1d071-7f95-41a5-b36e-7adb52e9a779/devtools-extension.png" alt=""></p>
<p>（出典: https://developer.chrome.com/extensions/devtools ）</p>
<p>これを見ると、「DevTools page」に「Panel」が複数格納されていることがわかります。<br>
この「Panel」一つ一つが、「Chromeデベロッパーツール」内のタブとして表示されます。</p>
<p>まず、<code>manifest.json</code>という名前でjsonファイルを作成し、以下のように記述します。</p>
<pre><code class="language-json">{
  &quot;name&quot;: &quot;Twitter Detector&quot;,
  &quot;manifest_version&quot;: 2,
  &quot;version&quot;: &quot;1&quot;,
  &quot;devtools_page&quot;: &quot;devtools.html&quot;
}
</code></pre>
<p>ここでは、「Chrome拡張機能」としての設定を記述します。<br>
<code>devtools_page</code>の値に指定した<code>devtools.html</code>が、DevTools pageのエントリーポイントになります。</p>
<p>manifest.jsonの詳しい仕様については、<a href="https://developer.chrome.com/extensions/manifest">Manifest File Format</a>を参照してください。</p>
<p>次に、<code>manifest.json</code>で指定した<code>devtools.html</code>を、以下の内容で作成します。</p>
<pre><code class="language-html">&lt;!DOCTYPE html&gt;
&lt;html&gt;
  &lt;head&gt;
    &lt;script src=&quot;./devtools.js&quot;&gt;&lt;/script&gt;
  &lt;/head&gt;
  &lt;body&gt;
  &lt;/body&gt;
&lt;/html&gt;
</code></pre>
<p>そして、<code>devtools.html</code>内で読み込んだ<code>devtools.js</code>を、以下の内容で作成します。</p>
<pre><code class="language-js">chrome.devtools.panels.create(
  &quot;TWDetector&quot;,
  &quot;&quot;, // icon画像を指定できる
  &quot;./panel.html&quot;,
  (panel) =&gt; {} // callback
);
</code></pre>
<p>ここでは、chromeのAPIを使って、<code>TWDetector</code>という名称のPanelを新たに追加しています。</p>
<p>具体的には、ChromeのAPIである「<a href="https://developer.chrome.com/extensions/devtools_panels#method-create">chrome.devtools.panels.create</a>」に対して、第一引数に「Panel」の名前を、第三引数に「Panel」表示用htmlファイル名を渡します。</p>
<p>最後に、<code>devtools.js</code>内で指定した、<code>panel.html</code>(「Panel」用のhtmlファイル)を以下の内容で作成します。</p>
<pre><code class="language-html">&lt;!DOCTYPE html&gt;
&lt;html&gt;
  &lt;head&gt;
    &lt;meta charset=&quot;utf-8&quot;&gt;
  &lt;/head&gt;
  &lt;body&gt;
    &lt;h1&gt;Twitter Detactor&lt;/h1&gt;
    &lt;h2 id=&quot;message&quot;&gt;&lt;/h2&gt;
    &lt;script src=&quot;./panel.js&quot;&gt;&lt;/script&gt;
  &lt;/body&gt;
&lt;/html&gt;
</code></pre>
<p>h2タグ内には、後でメッセージを表示させます。</p>
<p>ここまでできたら、試しにChromeに読み込ませて見ます。</p>
<p>アドレスバーに <code>chrome://extensions/</code> と入力し、「Chrome拡張機能」の「設定画面」に移動します。</p>
<p>右上の「デベロッパーモード」にチェックを付け、「パッケージ化されていない拡張機能を読み込む」ボタンから、「chrome-extension-sampleディレクトリ」を読み込むます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dfc41cf6-6ad2-4540-bb77-a76f60cfd20c/----------2017-08-14-11.26.11.png" alt=""></p>
<p>その後、<a href="https://plaid.co.jp/">適当なページ</a>に遷移して、「Chromeデベロッパーツール」を開きます。</p>
<p>作業が全てうまくいっていれば、一瞬遅れて「TWDetectorタブ」が追加されます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aa608450-572b-45c7-a016-96ee800fdca6/----------2017-08-14-6.16.21.png" alt=""></p>
<p>ここまでで、無事に「Chromeデベロッパーツール」内に自由にカスタマイズできる領域を作ることに成功しました。<br>
あとは、ここを好きなようにいじっていきます。</p>
<h2>ステップ3. ログを出す</h2>
<p>「Panel」の表示を作っていく前に、「Chromeデベロッパーツール」内から、Consoleにログを出してみます。</p>
<p>まず、<code>panel.html</code>内で読み込んだ<code>panel.js</code>を、以下の内容で作成します。</p>
<pre><code class="language-js">console.warn(&quot;hoge&quot;);
</code></pre>
<p>コードの変更を再読み込みするには、デベロッパーツールを一度閉じてから開き直します。</p>
<p>早速、「TWDetectorタブ」の横にある「Consoleタブ」を開いて、logを確認しましょう。</p>
<p>はい、何も出ていません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/89795e24-31f9-4a5d-a30e-e71e91d06b9b/----------2017-08-14-6.28.57.png" alt=""></p>
<p>実は、ここで見ている「Consoleタブ」は「対象のWebページ」に対するコンソールであり、「Chromeデベロッパーツール」それ自体に対するコンソールは別の場所にあります。</p>
<p>そのコンソールを見るためには、「Chromeデベロッパーツール」を「別ウィンドウで表示」(&quot;Undock into separate window&quot;)し、表示されたそのウィンドウに対して、更にデベロッパーツールを開きます。</p>
<p>Macでは、「TWDetectorタブ」を開いているデベロッパーツールを別Windowにし、そのWindowをアクティブにした状態で、</p>
<ul>
<li>表示 &gt; 開発 /管理 &gt; デベロッパー ツール</li>
</ul>
<p>を選択します。<br>
ショートカットキーでも表示させることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6dc2cdc7-407c-44e9-9dca-802a200e824b/----------2017-08-14-6.24.25.png" alt=""></p>
<p>実際に表示をしてみると、問題なくlogがはき出されていることが確認できます。</p>
<h2>ステップ4. Twitterのサーバーへのリクエストを検知する</h2>
<p>いよいよ、実際の機能を追加していきます。</p>
<p>簡単な機能として、デベロッパーツールの「Networkタブ」に出ているようなブラウザからのリクエストの内容を監視し、urlに「twitter」と含まれている場合だけメッセージを画面に表示してみます。</p>
<p><code>panel.js</code>に、以下の記述を追加します。</p>
<pre><code class="language-js">chrome.devtools.network.onRequestFinished.addListener((req) =&gt; {
  const url = req.request.url;
  if (url.indexOf(&quot;twitter&quot;) !== -1) {
    console.log(`req:${JSON.stringify(req)}`); // ついでに、requestの内容をconsoleに表示
    document.getElementById(&quot;message&quot;).innerText = &quot;このサイトから、Twitterの香りがするでゲソ&quot;;
  }
});
</code></pre>
<p>ブラウザからのリクエストを検知して処理を行うには、Chromeが提供する「<a href="https://developer.chrome.com/extensions/devtools_network#event-onRequestFinished">chrome.devtools.network.onRequestFinished</a>イベント」に対して、「イベントリスナー」を追加します。</p>
<p>外部リクエストが発生する度に、「イベントリスナー」に登録した関数の引数に、検知したリクエストの内容が渡されて実行されます。</p>
<p>デベロッパーツールを再読み込みしてみると、「Panel」にメッセージが表示され、Twitterのサーバーへのリクエスト内容がConsoleに出力されました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/15c13779-6c79-49cc-a92f-0bd0a88da749/----------2017-08-14-7.04.05.png" alt=""></p>
<h2>ステップ5. 画面更新時の処理を追加する</h2>
<p>実際にこのツールを使う場合は、デベロッパーツールを開いたまま、色々なサイトを回遊して「Twitterの香りがするページ」を探したくなるでしょう。</p>
<p>そのため、画面遷移時に「Panel」内のメッセージをクリアする処理を追加します。</p>
<pre><code class="language-js">// リクエスト終了時（ステップ4で記述）
chrome.devtools.network.onRequestFinished.addListener((req) =&gt; {
  const url = req.request.url;
  if (url.indexOf(&quot;twitter&quot;) !== -1) {
    console.log(`req:${JSON.stringify(req)}`);
    document.getElementById(&quot;message&quot;).innerText = &quot;このサイトから、Twitterの香りがするでゲソ&quot;;
  }
});
// 画面更新時や、画面遷移時（本ステップで追加）
chrome.devtools.network.onNavigated.addListener((url) =&gt; {
    document.getElementById(&quot;message&quot;).innerText = &quot;&quot;;
    console.clear();
  }
);
</code></pre>
<p>画面遷移時の処理は、「<a href="https://developer.chrome.com/extensions/devtools_network#event-onNavigated">chrome.devtools.network.onNavigated</a>イベント」に対して、「イベントリスナー」を追加します。</p>
<p>ついでに、Consoleに出力していた内容も、「<a href="https://developers.google.com/web/tools/chrome-devtools/console/console-reference?hl=ja#clear">console.clear()</a>」を使って綺麗にしています。</p>
<h2>ステップ6. 動作の確認</h2>
<p>最後に、作成したツールの動作を確認します。</p>
<p>例えば、一見するとTwitterを使っているかわからない「<a href="https://karte.io/">KARTE</a>」のサイトを、「TWDetectorタブ」を開いたまま見てみます。</p>
<p>作成したツールに問題がなければ、「Panel」内に「Twitterの香りがするでゲソ」と表示されます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4b17444a-d40e-45d7-95af-0b34b96fe643/----------2017-08-14-7.15.32.png" alt=""></p>
<p>ページをスクロールしてみると、実際に「<a href="https://twitter.com/karte_io">KARTEの公式Twitterアカウント</a>」のツイートが埋め込まれていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/16bc5819-b360-43ac-9f58-2487df50c564/----------2017-08-14-7.17.08-1.png" alt=""></p>
<p>このように、このサイトがTwitterの「埋め込みTL」や「Followボタン」を設置しているかを、一瞬で知ることができます。</p>
<p>試しに、Twitterの香りがしない「<a href="https://www.google.co.jp/">google.co.jp</a>」を見てみると、何も反応しないことがわかります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2cb098a3-fdca-4e57-a2f4-ec52c925e5d4/----------2017-08-14-7.15.00.png" alt=""></p>
<p>このように、「Chromeデベロッパーツール」を拡張すれば、自分だけの便利ツールを簡単に作ることができます。</p>
<p>この記事をお読みの皆さんも、便利ツールや面白ツールを、自分の「Chromeデベロッパーツール」に追加してみてはいかがでしょうか？</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム<a href="https://karte.io/">「KARTE」</a>を運営する<a href="https://plaid.co.jp/">PLAID</a>では、オフィスで「スプラトゥーン2」をしていても怒られないような職場で働きたいエンジニア社員やインターンを募集しています。</p>
<p>詳しくは<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>


Chromeデベロッパーツールに独自機能を追加する方法を、6つのステップに分けて解説しました！

Chromeデベロッパーツールに独自機能を追加する6つのステップ  | PLAID engineer blog

Chromeデベロッパーツールに独自機能を追加する6つのステップ

チャットボット基盤ツールを公開しつつ、作成時に得た知見を解説します。juman++とknpによる解析を活用

日本語を理解するチャットボットに挑戦した話【デモあり】 | PLAID engineer blog

日本語を理解するチャットボットに挑戦した話

<p>プレイド エンジニア / Hunter<br>
山内 雅浩 @algas</p>
<p><a href="http://2017.dockercon.com/">DockerCon 2017</a> で発表された <a href="http://mobyproject.org/">Moby Project</a> の一部である &quot;LinuxKit&quot; を使ってみました。実際に触ってみることで理解できたことやハマったこと、プロジェクトの思想を少しでも多くの人に共有したいと思って今回の記事を書きました。</p>
<h2>対象読者</h2>
<p>本記事は主に以下のような方々をターゲットとしています。</p>
<ul>
<li>Docker 環境の構築に不安や不満がある人</li>
<li>クラウド環境の設計・構築に携わっている人</li>
<li>Moby Project という名前は聞いたことがあるけど中身を理解していない人</li>
</ul>
<h2>LinuxKit とは？</h2>
<p>https://github.com/linuxkit/linuxkit</p>
<h3>概要</h3>
<p>LinuxKit は複数の Docker コンテナを含む軽量の Linux VM を作るためのツールです。<br>
誤解を恐れずに言うと &quot;Docker VM&quot; です。<br>
Docker コンテナやコンテナの作成手段を置き換えるものではありません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/daf5cb72-5255-45ee-b670-b650bd919e5b/----------2017-07-14-11.19.33.png" alt="moby os architecture"></p>
<p>(https://www.slideshare.net/Docker/dockercon-2017-general-session-day-1-solomon-hykes-75362520 からの引用)</p>
<h3>特徴</h3>
<blockquote>
<p>&quot;LinuxKit, a toolkit for building custom minimal, immutable Linux distributions.&quot;</p>
</blockquote>
<ul>
<li>Custom<br>
Dockerコンテナイメージを組み合わせて構成します。自作のコンテナも当然使えます。</li>
<li>Minimal<br>
アプリケーションを実行するための最低限のコンポーネントだけを動かすようにします。不要な機能を入れないことで、容量を小さく実行速度を上げセキュリティレベルを高めます。</li>
<li>Immutable<br>
LinuxKit の構成を変える場合には新しくビルドして差し替えるので全く別のものになります。</li>
</ul>
<p>以下のプラットフォームに対応しています。</p>
<ul>
<li>ローカル
<ul>
<li>HyperKit (macOS)</li>
<li>Hyper-V (Windows)</li>
<li>qemu (macOS, Linux, Windows)</li>
<li>VMware (macOS, Windows)</li>
</ul>
</li>
<li>クラウド
<ul>
<li>Amazon Web Services</li>
<li>Google Cloud</li>
<li>Microsoft Azure</li>
<li>packet.net</li>
</ul>
</li>
</ul>
<h2>LinuxKit は何に使うの？</h2>
<h3>複数のコンテナを1つのVMとして定義できる</h3>
<p>例えば、メインのアプリケーションとロガーやWebサーバ、画像変換アプリケーションを同じホスト上に同居させたくなったとしましょう。<br>
これを Docker コンテナを使って実現するには以下のような方法がありました。</p>
<ol>
<li>同じコンテナにまとめてしまう<br>
コンテナシステムにおける「1プロセス1コンテナの原則」に反する悪手。コンテナ内でプロセスを管理する必要があります。</li>
<li>ホストの機能で実現する<br>
アプリ以外を Docker コンテナの外側、つまり Docker Engine が動いているホスト上で動作させてしまう方法です。できれば Docker で解決したいですよね？</li>
<li>コンテナ間通信を使う<br>
標準では <code>docker-compose</code> を使えば実現できます。同じホスト上で複数のコンテナを動作させてコンテナ間を link でつなぐ必要があるのと、複数のコンテナを制御・管理する必要があるのがデメリットです。</li>
</ol>
<p>例えば  &quot;Amazon EC2 Container Service&quot; や &quot;Azure Container Service&quot; のようなホスト型のオーケストレーション機能では実現が困難だったりします。<br>
LinuxKit を使うと設定ファイル1つで簡単に設定できますし、機能が VM 単位でまとめられているので管理するのも楽です。</p>
<h2>LinuxKit の設定ファイル  yaml を読む</h2>
<p>LinuxKit をビルドするための yaml ファイルの例として公式の <code>sshd</code> の yaml を読んでみましょう。<br>
https://github.com/linuxkit/linuxkit/blob/master/examples/sshd.yml</p>
<pre><code class="language-yaml"># VM を起動する時にだけ使う
kernel:
  image: &quot;linuxkit/kernel:4.9.35&quot;
  cmdline: &quot;console=ttyS0 page_poison=1&quot;
# init システム用のイメージで root のファイルシステムに直接展開する
init:
  - linuxkit/init:14a38303ee9dcb4541c00e2b87404befc1ba2083
  - linuxkit/runc:2310ad9d266cf5d9c4d07613bd2135ed7eb8a21f
  - linuxkit/containerd:c977f27c234d55b85172813b8451f67ea86be4a3
  - linuxkit/ca-certificates:67acf038c44bb191ebb704ec7bb39a1524052cdf
# 次の services の前に短時間だけ実行する
onboot:
  - name: sysctl
    image: &quot;linuxkit/sysctl:d1a43c7c91e92374766f962dc8534cf9508756b0&quot;
# containerd で長時間実行する
services:
  - name: getty
    image: &quot;linuxkit/getty:5ab31289889d61a5d2ecbeea8e36ce74ac54737c&quot;
    env:
     - INSECURE=true
  - name: rngd
    image: &quot;linuxkit/rngd:1516d5d70683a5d925fe475eb1b6164a2f67ac3b&quot;
  - name: dhcpcd
    image: &quot;linuxkit/dhcpcd:4b7b8bb024cebb1bbb9c8026d44d7cbc8e202c41&quot;
  - name: sshd
    image: &quot;linuxkit/sshd:89b2e91d7d1bf2f40220be0e3ed586e74746cceb&quot;
# 外部からファイルを読む込む
files:
  - path: root/.ssh/authorized_keys
    source: ~/.ssh/id_rsa.pub
    mode: &quot;0600&quot;
    optional: true
# 信頼する Docker コンテナ
trust:
  org:
    - linuxkit
</code></pre>
<p>上記は単純な例なので項目数が少なく、把握するのは難しくないと思います。<br>
特徴的な設定は以下の3つです。</p>
<ol>
<li>getty: コンソールでログインする</li>
<li>sshd: ssh daemon を動かす</li>
<li>files: ssh 公開鍵をローカルからコピーする</li>
</ol>
<p>詳細は <a href="https://github.com/moby/tool/blob/master/docs/yaml.md">Reference</a> で確認してください。</p>
<h2>LinuxKit で sshd を動かしてみる (macOS)</h2>
<p>LinuxKit で sshd を動かし、ssh クライアントで接続します。</p>
<h3>設定手順</h3>
<p><code>$HOME/.ssh/id_rsa.pub</code> が存在していることを前提としています。<br>
もし上記のファイルがない場合には、<code>ssh-keygen</code> コマンドで公開鍵のペアを作成してください。</p>
<ol>
<li>moby と linuxkit をインストール<br>
<code>brew tap linuxkit/linuxkit</code><br>
<code>brew install --HEAD moby</code><br>
<code>brew install --HEAD linuxkit</code></li>
<li>sshd をビルドする<br>
<code>git clone https://github.com/linuxkit/linuxkit.git</code><br>
<code>cd linuxkit/example</code><br>
<code>moby build sshd.yml</code></li>
<li>sshd を起動する<br>
<code>linuxkit run sshd</code></li>
<li>ip address を確認する<br>
<code>ifconfig</code> コマンドで eth0 の ipv4 アドレスを記録しておきます。</li>
<li>docker network を作成する<br>
<code>docker network create --driver bridge --subnet=192.168.65.100/24 --gateway=192.168.65.101 linuxkit</code></li>
<li>socat コンテナを用意する<br>
sshd linuxkit に接続するための proxy を用意します。<br>
https://github.com/linuxkit/linuxkit/issues/1674<br>
<code>docker run -p 127.0.0.1:8080:8080 --name linuxkit-proxy -it --rm alpine sh</code><br>
<code>/ # apk -U add socat</code><br>
<code>/ # socat TCP-LISTEN:8080,fork TCP:[linuxkit_vm_ip]:22</code><br>
事前に確認した ipv4 アドレスを <code>[linuxkit_vm_ip]</code> のところに入れてください。</li>
<li>socat コンテナに network を追加する<br>
<code>docker network connect linuxkit linuxkit-proxy</code></li>
<li>sshd コンテナに接続する<br>
<code>ssh -o StrictHostKeyChecking=no localhost -p 8080 -l root</code></li>
</ol>
<p>以上です。<br>
linuxkit を終了するには、コンソールで <code>halt</code> コマンドを入力します。</p>
<h3>設定でハマったところ</h3>
<ul>
<li>コンソールから脱出できない<br>
<code>halt</code> コマンドで LinuxKit を終了させる方法に気づくまでは、何度も <code>exit</code> しては auto login されるのを繰り返していた。</li>
<li>ssh クライアントから sshd に接続できない<br>
sshd を動かすのは難しくないけど ssh クライアントで接続するのが簡単ではなかった。</li>
<li>Docker のネットワーク設定方法がわからない<br>
普段はほとんどデフォルトのままで使っているので Docker のネットワークをカスタマイズしたことがなかった。linuxkit のデフォルトの ip address レンジと docker のそれを合わせるのがポイントです。</li>
</ul>
<h2>Moby Project という思想</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4cfccbff-5196-4c57-a8b5-1a25e45c5c63/moby-project-logo-1.png" alt="moby project"></p>
<p>Docker が Moby Project を作った理由は一体何でしょうか。<br>
Moby Project 以前の Docker に足りなかったもの、それは Docker コンテナを「現実の環境で動作させる仕組み」です。<br>
Docker コンテナを動作させるためには以下のものが必要です。</p>
<ol>
<li>Docker コンテナを動かす仕組み = Docker Engine</li>
<li>Docker Engine を動かす仕組み = OS</li>
<li>OS または OS が動作するインスタンスを管理する仕組み</li>
</ol>
<p>しかし、これらを管理・制御するための仕組みとして Docker Engine 以外は Docker の外側の世界のものでした。<br>
Moby Project では上記にそれぞれ対応するシステムがあります。</p>
<ol>
<li>Docker コンテナを動かす仕組み = Containerd</li>
<li>Containerd を動かす仕組み = LinuxKit</li>
<li>LinuxKit を管理する仕組み = InfraKit</li>
</ol>
<p>しかも、Moby Project で用意された上の3つは、それぞれ別のソフトウェアに置き換えることが可能です。その Pluggable である性質が、Moby Project の大きな特徴の1つです。<br>
Docker やそれ以外のチームが作った Docker を動かす仕組みはこれまでにもありましたが、Moby Project はコンテナ運用の新しい仕組みによって Docker を再定義するものと言えます。</p>
<h2>まとめ</h2>
<p>LinuxKit は Docker コンテナを活かしつつ新しいコンテナ実行環境を提供する仕組みです。<br>
新しく Docker を使ったシステム構築する際には LinuxKit を使うのが選択肢の1つになると思います。<br>
出てきたばかりで情報が少ないのが LinuxKit を使う上での一番の障壁ですが、今後普及してくるに連れて改善していくことでしょう。</p>
<p>InfraKit についての記事も書こうと考えているのですが、今回は長くなってしまったので次の機会に書くことにします。</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>


LinuxKit の Tutorial です。LinuxKit を実際に動かしてみる方法と Moby Project による
 Docker の未来について書いています。

 LinuxKit で実現する新しい Docker 実行環境 | PLAID engineer blog

LinuxKit で実現する新しい Docker 実行環境

<p>こんにちは。プレイドの@sdaikichiです。現在のトレーナーレベルは28、捕まえたポケモンは183種です。</p>
<p>突然ですが、皆さん、お酒は好きですよね？僕も大好きです。</p>
<p>最近はビールが美味しい季節になってきました。</p>
<p>さて、エンジニアには半ば都市伝説のような通説があるのをご存知でしょうか。</p>
<p><a href="http://isononami.blogspot.jp/2013/01/ballmer-peak.html">バルマーピーク</a>です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/53f62989-6978-49d9-8cf1-f9d443480f7f/ballmer_peak-1.png" alt="ballmerpeak"></p>
<p>この説は、「血中アルコール濃度が0.129~0.138%のときに超人的なプログラミング能力を発揮できる」というものです。（このマンガだとWindows MEを引き合いに出してディスられていますが）</p>
<p>エンジニア同士の飲み会では一度は話の種になったことがあるのではないでしょうか。</p>
<p>バルマーピーク、もし本当だったらアツくないすか？</p>
<p>このグラフ（と呼んでいいかわかりませんが）では、ピーク時には平常時の倍ほどのプログラミング能力になると書かれています。</p>
<p>生産性の追求はエンジニアの至上命題です。「お酒を飲みながら仕事なんて！」という固定概念を取り払い、試せるものは試すのがエンジニアとしての矜持ではないでしょうか。</p>
<p>日本の労働生産性は先進国で最低と言われています。さらにIT分野では諸外国に遅れを取っていると言わざるを得ません。<br>
もしバルマーピークの有用性が認められれば、日本のエンジニア達は酒を片手に以前とは比較にならない速度でアウトプットを出し続けることでしょう。ということは、ITはいまや日本の主要産業ですから、国内の生産性も一気に上昇します。ひいては日本のGDP増加、世界でのプレゼンスを再び得ることができるに違いありません。<strong>絶対成功させよう東京オリンピック！！</strong></p>
<p>さて、始めましょう。</p>
<h1>ルール</h1>
<h2>プログラミング能力の計測</h2>
<p>生産性を比べるという点からすると弊社プロダクトのコードを使うのが一番ですが、酒を飲みながらプロダクションにコミットしていることが露見するとワンチャン解雇まであるので、ここは控えます。</p>
<p>「コーディング能力とは何か」を考え出すとキリがないため、いったんここは粒度の自由さとコーディング能力の客観的指標を兼ね備えている、<a href="https://paiza.jp/">paiza</a>を使って結果を比べてみることにします。</p>
<p>時間を計測してくれたり、テストケースによる採点も行ってくれるため、飲酒時・素面時の客観的比較が可能です。<br>
paizaスキルチェックのレベルですが、B~Cあたりの難易度で比較するのが普段の業務に近そうなので、ここを使います。<br>
A以上になると数学的な設計能力も問われ、酔っ払った状態では明らかに不利そうなので、今回は避けます。普通に難しくて心が折れたというのもある。</p>
<h2>濃度の計測</h2>
<p>血中アルコール濃度が基準なので常に血液を取って測定できると良いのですが、さすがに機材が用意できないので、<a href="http://amzn.asia/1X3MO4L">呼気で計測するもの</a>を利用します。<br>
（余談ですが本当は国内メーカーのものを使いたかったのですが、おそらく車の運転可否の判定に主眼を置いているのか、濃度の測定範囲が今回のピークより低かったため、この製品を利用します。）</p>
<p>説によると、血中アルコール濃度0.129~0.138%、呼気中アルコール濃度に換算すると0.64~0.69mg/Lがピークとなります。お酒を飲み続け、この範囲までアルコール濃度が上がったのを確認してから、paizaの問題に取り掛かることにします。</p>
<h2>濃度の維持</h2>
<p>生産性が上がるのはかなり狭い範囲なので、アルコール濃度を維持する必要があります。<br>
自分の体重だとアルコール分解の速さは1時間あたり(血中濃度の低下が)およそ 0.012% なので、維持するためにはビールだったら60分で200mlのペースで飲み続けながらコーディングしていきます。ちびちびと言った感じですね。</p>
<h1>検証開始</h1>
<p>まずはアルコール濃度をピーク範囲まで上げる必要があります。</p>
<img width="300px" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/283f8ef4-2396-4319-a748-d969f7f6292a/IMG_2600-1.JPG.jpg"/>
<p>近くの居酒屋さんからテイクアウトしてきたもつ煮込みと焼鳥でおっぱじめます。</p>
<h2>20分後</h2>
<p>そろそろ濃度を計測してみましょう。</p>
<img width="300px" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0e5bf0da-a6da-407f-bc4f-a8c379d827da/IMG_0737-1.JPG.jpg"/>
<p>ピークの濃度をオーバーしてしまいました。<br>
お酒を飲まずにアルコール濃度が下がるのを待ちます。20分ほどマンガでも読んでましょう。</p>
<h2>さらに20分後</h2>
<p>富田流のそれは左鉤突きから始まる、それとは即ちーーー<strong>ピピピッ</strong><br>
おっと、タイマーが鳴りました。濃度を計測しましょう。</p>
<p>&lt;0.23%&gt;(写真撮るのを忘れてしまいました・・・)</p>
<p>今度は下がりすぎてしまいました。<br>
再度ビールで濃度を上げていきます。</p>
<h2>そのまたさらに20分後</h2>
<img width="300px" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/caf144fb-2908-4a2b-82e3-f139763a473d/IMG_2674.JPG.jpg">
<p>**よっしゃ来た！**コーディング開始です。<br>
ちなみにこのときの体感酔っぱらい度は微妙にほろ酔いといった感じで、人と喋りながらだったら自分が酔ってることに気付かないんじゃないかな、といったレベルです。</p>
<h1>結果</h1>
<p>こんなことを繰り返しつつ問題を解いていき、また後日素面の状態で別の問題を解きました。<br><br>
点数・回答時間は以下のような結果に。</p>
<h2>素面の結果</h2>
<table>
<tr><th>ランク</th><th>かかった時間</th><th>受験者の平均時間</th><th>点数</th><th>平均との乖離</th></tr>
<tr><td>B</td><td>17:40</td><td>31:03</td><td>100</td><td>-45.0%</td></tr>
<tr><td> B </td><td>19:02  </td><td> 29:25 </td><td> 100 </td><td>-35.3%</td></tr>
<tr><td> C </td><td>9:52  </td><td> 21:40 </td><td> 100 </td><td>-54.5%</td></tr>
<tr><td> C </td><td> 23:54 </td><td>25:57  </td><td> 100 </td><td>-7.9%</td></tr>
<tr><td> C </td><td>11:42  </td><td>17:38  </td><td> 100 </td><td>-33.7%</td></tr>
<tr><td>平均</td><td></td><td></td><td></td><td><b>-35.28%</b></td></tr>
</table>
<h2>お酒を飲んだ結果</h2>
<table>
<tr><th> ランク </th><th> かかった時間 </th><th> 受験者の平均時間 </th><th> 点数 </th><th>平均との乖離</th></tr>
<tr><td> B </td><td> 25:20 </td><td> 58:56</td><td> 100  </td><td>-57.0%</td></tr>
<tr><td> B </td><td>17:29  </td><td>31:36  </td><td>100  </td><td>-44.7%</td></tr>
<tr><td> C </td><td> 14:44 </td><td>27:35  </td><td><b>60</b></td><td>-46.6%</td></tr>
<tr><td> C </td><td> 9:09 </td><td> 20:56 </td><td> 100 </td><td>-56.3%</td></tr>
<tr><td> C </td><td> 8:23 </td><td> 13:40 </td><td> 100 </td><td>-38.7%</td></tr>
<tr><td> 平均 </td><td>  </td><td>  </td><td>  </td><td> <b>-48.66%</b> </td></tr>
</table>
<p><strong>うーん・・・・</strong></p>
<p>平均に対する速さでいうと微妙に早くはなっていますが、先述のグラフほどの生産性向上は見られませんでした。<br><br>
また、飲んだ方では1度凡ミス（採点時後すぐ原因箇所は判明）によりテストケース採点で60点を出しており、注意力の低下が見られます。<br>
<br>ちなみに後々両者のコードを読み返してみて読みやすさ等を比較してみましたが、そこまで違いはありませんでした。というか、提出時間を最優先した結果有り体に言って両方共クソコードでした。</p>
<p>結局「バルマーピークはあります！」と言えるほどの結果にならず残念です。<br>
とはいえ、そもそも「酒なんか飲んだら仕事にならない」という固定観念からすると、速度の向上が見られている時点で有意義な結果になったと言ってもいいのではないでしょうか。</p>
<p>読者諸兄におかれましては、是非この記事を片手にチームのマネージャーに飲酒コーディングの許可を直訴してみてはいかがでしょうか。私は責任を一切負いません。</p>
<p>ただやはり注意力の低下は避けられなさそうなので、もし不安な場合はテストを書いて<a href="/multi-browesr-test/">BrowserStackで実行</a>しましょう。</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、生産性の向上に余念のないエンジニアを募集しています！</p>
<p>詳しくは<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 engineer blog

【エンジニアの】バルマーピークは本当にあるのか 検証してみた【夢？】

<p>こんにちは。エンジニアの藤川です。<br><br>
この頃は穏やかで過ごしやすい季節となりましたが、皆さんいかがお過ごしでしょうか。</p>
<p>今回はプレイドのエンジニア、デザイナー、インターンの皆で山梨県は河口湖にある <a href="http://www.c-ban.com/">河口湖カントリーコテージ</a> さんにお邪魔して、開発合宿を行ってきましたのでその様子をご紹介していこうと思います。</p>
<h1>出発の地は新宿</h1>
<p>今回の出発の地は新宿です。観光バスを貸し切って山梨県河口湖を目指します。<br>
<br>なんだか遠足みたいでワクワクしますね。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cd45da35-81aa-4821-a550-48cbdeb94419/_P5256874.jpg">
<h1>河口湖カントリーコテージに到着</h1>
<p>途中、渋滞に巻き込まれてしまうなど軽いハプニングはありましたが、無事に河口湖カントリーコテージへ到着しました。<br>
<br>美しい森林に囲まれながら河口湖を見下ろす景観はなかなかのものです。都会の喧騒を忘れて開発に集中するには絶好の環境ですね。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b361a2fa-07ef-42c9-abd1-1b06f2d8406b/_P5256934.jpg">
<p>そして今回、私たちが宿泊する場所がこちら。<br><br>
なんと35名まで宿泊可能という <a href="http://www.c-ban.com/cottage_type35.php">エクストラコテージ</a> にメンバーのテンションも上がります！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7fded079-e977-4432-b471-662fad51fd35/_P5256942.jpg">
<p>リビングエリアは吹き抜けになっています。<br>
快適！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/99f3253b-99e4-4c04-9ea5-4b14c561bd84/_P5256979.jpg">
<h1>さっそくCTO柴山から企画説明</h1>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4f8bda3e-280c-4390-87e4-5fa6839bdb22/_P5267117.jpg">
<p>実はこれまでエンジニアメンバーで行ってきた合宿では、基本的にディスカッションをメインに行ってきました。以前の合宿については<a href="http://blog-plaid.com/event/2772/">こちらの記事</a>をご参照ください。</p>
<p>しかし今回の合宿は少し毛色が違うようです。<br><br>
今回はハッカソンを行います。テーマは<strong>日常業務ではなかなか作れない、自分が作りたいと思っているもの</strong>です。</p>
<h1>開発開始</h1>
<p>企画説明が終わると皆さっそく開発に入ります。<br>
<br>どんなものが出来上がるのでしょうか。合宿の最後に１人３分間でプレゼンテーションを行います。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ed7f6f3-99e7-4efe-9902-5cffa7eeeeb0/_P5257008.jpg">
<p>ついさっきまで河口湖の景色や大きなコテージにテンションが上がりっぱなしだったメンバーですが、いざ開発を始めるとみんな物凄い集中力でコードを書き始めました。<br><br>
この辺りはさすがだなと、感心してしまいます。</p>
<p>麦わら帽子をかぶったまま開発するメンバーも！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bdc58c15-aa3c-4afb-ab6c-1a68e1838f0d/_P5257012.jpg">
<h1>どうやら優勝賞品があるらしい...</h1>
<p>しばらくするとSlack上でnaokiさんがつぶやきます。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7849e609-b5a8-4668-a7b6-77aabd4aae43/----------2017-06-09-2.41.01.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/98f2197b-872a-4c22-a2d9-7dc687654fa3/----------2017-06-09-2.38.08.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/876eefc6-477b-4ccc-9eeb-e87f4a837fe2/----------2017-06-09-2.38.36.png">
<p>どうやら最も良いものを作り上げた人には優勝賞品が与えられるそうです。<br>
そして頑なにharibo１年分を推している。。</p>
<p>優勝賞品は一体何になるのか。<br><br>
すべてnaokiさんの独断と偏見に委ねられることになりました。</p>
<h1>夜はBBQ、そして温泉</h1>
<p>さて、開発に集中しているとあっという間に日が暮れてしまい夕食の時間になりました。<br><br>
今回の合宿の夕食はバーベキューです！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1d7749cc-4ffb-4191-b579-acf58d167b6c/_P5257040.jpg">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/637bc15f-1f7b-424f-bcdc-1790153119e2/_P5257045.jpg">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df949c4d-61d2-407b-adc6-812f1a69d785/_P5257082.jpg">
<p>こうして仕事を忘れて肉を囲みながらワイワイするのも良いものですね！<br><br>
みんな本当に楽しそうにしていました。</p>
<p>そして夕食のあとはコテージのすぐそばにある温泉で疲れた体を癒します。<br>
銭湯部に所属する私にとっては、この上なく幸せな時間でした。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f2f4da4-170b-4511-9dc1-bdedc2b382ca/bath_main4.jpg">
（画像は[公式サイト](http://www.c-ban.com/bath.php)より転載）
<h1>翌日</h1>
<p>さて、日付は変わり２日目の朝です。<br><br>
この日は、まず午前中の１時間ほどを使って社内コミュニケーションの課題感と対策についてディスカッションをしました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/555050dc-fb54-469a-b344-8cf08320cb34/_P5267103.jpg">
<p>社内コミュニケーション、とりわけエンジニアメンバーとフロントメンバー間のコミュニケーションというものは常に課題感を持って取り組まなければならないテーマです。<br><br>
なかなか完璧な解を見つけることは難しいですが、少しずつより良い方向に変化していけるように努力していきたいところです。</p>
<p>そんなディスカッションが終わると、成果発表までの残りの時間は各自開発をしたり、昼食をとったりと自由に過ごしました。</p>
<p>ほうとううまい。すごいうまい。</p>
<h1>いよいよ成果発表</h1>
<p>さて、いよいよ成果発表のプレゼンテーションの時間です。<br><br>
ここでは数ある中から、いくつかの発表を紹介していきたいと思います。</p>
<h2>採用周りの業務効率化</h2>
<p>今まで手付かずだった採用周りの業務の効率化を試みたのは、nodaさん、kadoppeさん、nitoさん、そしてインターンのtanakaくん。<br><br>
プレイドの採用周りの情報はGoogleスプレッドシート・カレンダー、Trello、FormStack、Wantedlyなど他にも複数のサービス上で管理していますが、多くのものが手動で管理されていて効率が悪かったり、これらの情報へのアクセシビリティも良くないなど、いろいろな課題を抱えていました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a91e7a8-99e5-4f03-8ef7-f59381351e42/_P5267137.jpg">
<p>そこで彼らはZapierを用いたAPI連携や、スクレイピングなどの技術を使って採用周りの業務を一部自動化することに成功していました。</p>
<p>また採用関連情報へのアクセシビリティという観点では、Trello上で管理されている採用候補者のステータスが変わるとSlack上でメンバー全員に周知してくれる「さいよーぼっと」君を作ることで、採用に直接関わっていないメンバーでも早い段階で次にどんな人が、プレイドの仲間に加わるのかを知ることができるようになりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b58f73e7-2555-49f0-9fb7-c4b58faf258c/----------2017-06-06-17.27.13.png" alt=""></p>
<h2>KARTEで計測したユーザー行動情報を学習</h2>
<p>makinoyさんはKARTEで実際に計測されたユーザーの行動ログから、ユーザーの行動パターンを学習させた結果や、それによって得られた知見を共有していました。<br>
KARTEによって集まった大量の行動ログデータを、どのようにしてKARTEを使っていただいているクライアントや、さらにはその先のエンドユーザーの価値にまで還元させることができるか、というのは我々にとって非常に重要なテーマです。<br>
簡単なことではありませんが、妥協することなく考え抜き、着実に前に進めていきたいところです。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4a867335-f0b0-4c73-961c-efeca2e9a513/_P5267157.jpg">
<h2>Slackによるデプロイ自動化機能の強化</h2>
<p>ikemonさんは、すでに実際に現場で運用されているSlackを使ったデプロイ自動化機能をさらに使いやすいものへとアップデートしていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aab39af9-4bc4-4bcc-ab58-14ee9af9d77c/slackdemo-1.gif" alt=""></p>
<p>なんとボタンをポチポチ押していくだけでワンストップでデプロイ〜リリースまでを完了することができてしまいます。<br>
いま実際に運用されているHubotを用いたデプロイの自動化機能も十分に便利なものなのですが、さらに使い勝手がよくなりそうです。</p>
<h2>KARTEソースコードエディタの再デザイン</h2>
<p>デザイナーのkazutoさんは、現在KARTEに実装されているソースコードエディタを０ベースで再デザインしていました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0ad1fc79-7a1d-4af0-b8d3-dabffe07b2fe/_P5267187.jpg">
<p>KARTEを運用するユーザーが、「Atomicデザインという考え方をベースに直感的にコードを組み立てられるようなエディタ」をテーマにしてデザインをされていたのですが、なぜこのデザインなのか？というポイントが非常にロジカルに考えられていて個人的には目からウロコの発表でした。</p>
<h2>労務Bot「鳥場はる子」さんのアップデート</h2>
<p>otoanさん、yukkeさん、daikichiさん、monoiさんによる「はる子チーム」は労務 Bot「鳥場はる子」さんのアップデートに取り組んでいました。<br>
構文解析周りの強化や新機能の追加が行われた上、デザイナーのyukkeさんによって正式にキャラクターデザインも作られました。</p>
<img width="30%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a750f51-43cf-49b9-a9ab-0ac6055d161a/image.png">
<p>ここだけの話、今までの鳥場はる子さんは少々そっけない回答が多く、アイコン画像もいかにも素材ですという雰囲気の女性の画像だったので、なかなか愛着が湧いてくることはありませんでした。<br><br>
しかし、今回のアップデートでより賢く、より可愛くなった「鳥場はる子」さん。とても人気者になりそうな予感がしてきます。</p>
<h2>サポート業務を効率化するChrome拡張機能</h2>
<p>普段、クライアントのテクニカルな問い合わせのサポートを行っているgamiさんは、そのサポート業務を劇的に効率化するChrome拡張を作っていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1d28862f-49d0-47be-90e8-e649dd672400/4e45e4b8-3678-11e7-9e49-760e71a1a66a.png" alt=""></p>
<p>KARTEのサポート業務を行うためには、クライアントのサイト上でKARTEのタグが正常に動作しているか、正しくデータが送信されているかなどを素早く把握する必要があります。</p>
<p>このChrome拡張を使えばそういった情報をサポートメンバーが素早く把握することができるようになり、結果的にサポートの質を格段に上げることに繋がります。<br><br>
こういった視点からプロダクトの質を上げることができるのは素晴らしいですね。</p>
<h1>そして栄えある優勝は..</h1>
<p>全員の発表が終了すると、１人１票を各々が最も良いものを作ったと思う人に投票しました。<br>
そこで栄えある優勝に輝いたのは、グロッチさんことmeguroさん。</p>
<p>USB Type-Cのアダプタを用意していなかったため、PCの画面を直接見せながらの発表となりました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d8b577df-daa5-4fae-a7ce-85f9f4c2fa11/_P5267169.jpg">
<h2>画像付きQRコード発行機能</h2>
<p>meguroさんが作ったのは、KARTE上でQRコードを発行できる機能です。<br>
例えば画像をアップロードして設定するだけで、簡単にこんなQRコードを作れてしまいます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/659e56dd-e0c0-432f-a446-5d783c454325/qr____________.png" alt=""></p>
<p>おもしろいですね。</p>
<p>ちなみに色付きのQRコードも発行できます。<br>
このQRコードからのアクセスはKARTE上で計測されるので、興味を惹くQRコードを作って印刷物に掲載→サイトへ流入→コンバージョンUP！なんてシナリオも考えられそうです。</p>
<p>meguroさんのユーモアを交えた発表にはみんな興味津々で、一番の盛り上がりを見せていました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/17f33358-75b0-464d-b2ad-eb28951d9e12/_P5267158.jpg">
<p>この機能がKARTEに搭載される日を楽しみに待ちたいと思います。</p>
<h1>開発合宿 終了</h1>
<p>さて、そんなこんなで楽しかった開発合宿もお開きの時間です。<br><br>
最後に集合写真をパシャり。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a94f7cbe-f5df-4ea7-a427-e080b13b211b/_P5267192.jpg">
<p>こうして開発合宿２０１７春は無事に全ての工程を終えました。<br><br>
プレイドのエンジニア陣にとって今回のように実際に手を動かしてモノを作る合宿というのは初めての試みでしたが、２日間という短い時間のなかで良いアウトプットがたくさん生まれ、とても収穫のある合宿だったのではないでしょうか。</p>
<h1>そして後日</h1>
<p>いつものように出社してきたグロッチことmeguroさん。<br>
自分のデスクの様子がいつもと違うことに気がつきます。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8b8d93e2-e4cd-4b06-93cf-2b427359fd11/meguro1.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/01893b36-caf0-4e85-a082-dbddb055e985/meguro2.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/20381e69-dca7-4a5f-989b-6aed63840235/DSC08683.JPG.jpg">
<p>なんとそこに置いてあったのは大量のharibo！<br><br>
そして、さりげなくApple Watchも置いてあります！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5cb7df6-cc7b-4089-9aa8-0c63742355f7/DSC08686.JPG.jpg">
<p>どうやら優勝賞品はharibo１年分とApple Watchに決まったみたいですね。<br><br>
おめでとうございます！！</p>
<p>と、ここでmeguroさん。</p>
<p>meguroさん「そうそう、これをこうして・・・」<br>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dd9ba188-df16-49af-83bd-4a33eced1737/DSC08694.JPG.jpg"></p>
<p>meguroさん「こうして・・・」<br>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58b368bf-819b-4f1b-8351-0733785c47ed/DSC08703.JPG.jpg"></p>
<p>meguroさん「・・・」<br><br>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/52b6bdfb-df46-471c-968f-4eb2ffdde0ad/DSC08713.JPG.jpg"></p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、こんな開発合宿に参加してharibo１年分が欲しいエンジニアを募集しています！</p>
<p>詳しくは<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 engineer blog

山梨県河口湖に開発合宿へ行ってきました！

<p>プレイドの @nashibao です。</p>
<p>弊社は<strong>大量のログデータを収集し、人軸で解析するサービス</strong>を展開しています。収集したデータの利用方法には様々な目的と様々な手法がありますが、そのうちの大きな一つに、<strong>中・大規模のデータに対して、アドホックなクエリをインタラクティブにかけアグリゲーション結果を得る</strong> というものがあります。</p>
<p>このようなアグリゲーションの問題において、<code>クエリの自由度</code> x <code>データ規模</code> x <code>レイテンシー</code>を共存するのはなかなか難しい問題になります。(1)</p>
<p>元ネタは結構有名かと思いますが、<code>Square</code> が開発している、<code>Crossfilter</code><a href="https://github.com/crossfilter/crossfilter">GitHub - crossfilter/crossfilter: Fast n-dimensional filtering and grouping of records.</a>というものです。<code>Crossfilter</code>を内部に使ったビジュアライゼーションとして <a href="https://dc-js.github.io/dc.js/">dc.js - Dimensional Charting Javascript Library</a> というものもありますが、こちらの方が有名かもしれません。</p>
<p>というわけで、このエントリは、bit matrixやbit twiddlingといったテクニックで効率的なフィルタリングとアグリゲーションを実現することで、数百万レコード程度であれば、数十msで結果を出すといった優れものについてのお話になります。(2)</p>
<p>（1 余談ですが、こんなエンジニアリングの課題と市場の要望の乖離があるフィールドはプロダクトアウトなビジネスを始める良い条件が揃っていると考えられるかもしれません。たぶん。）</p>
<p>（2 本来は数百万レコード程度であれば大規模とは言えないと思いますが、中・大規模と書いたのは、<strong>出来るだけ盛って描きたい、という気持ちがあったというのは前提ですが</strong> 前処理として1段aggregationしてからインタラクティブな環境に持ってくれば、それで十分という場合が意外と多いと思うからです）</p>
<h1>ポイント</h1>
<p>jsでブラウザで動かしてここまでパフォーマンスが出るのは目からウロコ感があります。その肝は色々あると思いますが、僕個人としては次の3点が面白いところじゃないかと考えています。</p>
<ol>
<li>問題を制限する（<code>filtering</code> x <code>reduceによるaggregation</code>に制限）</li>
<li>BitMatrixとBit演算による高速なフィルタリング</li>
<li>Sorted Arrayを使った効率的な差分更新</li>
</ol>
<p>以下、この3点についてまとめてみます。</p>
<h1>問題を制限する</h1>
<p>上に書いたように、<code>クエリの自由度</code> x <code>データ規模</code> x <code>レイテンシー</code>全てを同時に満たすのは難しい問題です。そのため、ここではクエリに対してある程度の制限をかけることで、データの圧縮と高速な取出しを可能にしています。</p>
<ol>
<li>クエリ = フィルタリング  x アグリゲーション のみ</li>
<li>アグリゲーションは<code>reduce</code>（データの追加/削除による値の変化が、追加/削除されるデータにのみ左右される）のみ</li>
</ol>
<p><code>SQL</code>のように何でもかんでもという感じで複雑な処理は書くことはできませんが、1. <code>WHERE</code>と<code>GROUP BY</code>、2. 集計関数としても<code>Max|Min|Sum|Count|Average</code>など<code>reduce</code>処理として書けるものだけ、これを一段階だけ、に制限しているイメージです。ある程度 <code>前処理すること</code>を前提とすれば、上記のような制限をかけても、大体のことはできそうなイメージはあるんじゃないでしょうか。</p>
<p>このような制限をかけることで、やりたいことは制限しすぎずに → 効率的なデータ表現を使って → 高速なアグリゲーションを、というシナリオです。</p>
<h1>全体構造/概念</h1>
<p>crossfilterの簡単なコードを下記に表します。コードを読めばなんとなくやろうとしていることはわかるかな、と思いますが、詳しくは <a href="https://github.com/square/crossfilter/wiki/API-Reference">API Reference · square/crossfilter Wiki · GitHub</a> を参照してください。</p>
<ol>
<li>dimension作成（フィルタリング/Aggregateする軸を決める）</li>
<li>group作成（グルーピング単位を決める）</li>
<li>reducer作成（aggregateの関数を設定）</li>
<li>最後にfiltering x aggregation</li>
</ol>
<pre><code>data = [{fld1: 'type1', fld2: 10},...]
cf = crossfilter(data)

# create dimension
dim1 = cf.dimension (d) -&gt; return d.fld1
dim2 = cf.dimension (d) -&gt; return d.fld2

# create group
group = dim2.group (fld2) -&gt; return fld2 % 5

# creaate reducer
sumAdd = (p, v) -&gt; return p + v
sumReduce = (p, v) -&gt; return p - v
reducer = group.reduce sumAdd, sumRemove, 0

# filtering
dim1.filter('type1')

# get result
console.log reducer.top(3)
</code></pre>
<p>これらの概念は内部的には</p>
<ol>
<li>filters:データ数 x フィルタ数のBitMatrix</li>
<li>dimension: sort済みArray x lower/upper bounds</li>
</ol>
<p>で表現されています。</p>
<h1>BitMatrixによるフィルタリング</h1>
<p>さて一つ目のテクニックはBitMatrixによるフィルタリング行列の実装です。<br>
<code>N</code>（データ数）x <code>D</code>（Dimension数）のBitMatrixは、Javascriptだと<code>Uint8Array</code>などの<code>TypedArray</code>で表現されます。例えば、<code>30</code>行のデータ x <code>8</code>Dimension の場合、<code>new Uint8Array(30)</code>（30 x 8 = 240 bit) が実態になり、一つのデータが<code>Uint</code>一つで表されます。もしDimension数が8に満たない場合は、使わない部分はできますが<code>Uint8Array</code>で、16までであれば<code>Uint16Array</code>で、32までなら<code>Uint32Array</code>で表現する、といった具合です。（それ以上であれば<code>TypedArray</code>を並べて表現します、が、パフォーマンスは落ちるはずです。）</p>
<p>また、一つのbitは</p>
<ul>
<li><code>0</code>: フィルタリング<code>されてない</code>状態</li>
<li><code>1</code>: フィルタリング<code>されている</code>状態</li>
</ul>
<p>を表します。下図の例で言えば、データ(1)がフィルタ(2)で弾かれた場合、XOR演算で<code>0^32=32</code>になり、さらにフィルタ(5)で弾かれると<code>32^4=36</code>になります。そして、<code>0</code>と比較すればデータ(1)が弾かれているかどうかチェックすることができます。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/b86087dc-7aad-4b91-988b-af38c925e7e8/58e9dcea6ec63b0bbac5853c.png" alt="58e9dcea6ec63b0bbac5853c.png"></p>
<p>このように<code>O(N)</code>なメモリスペースを比較的高速な演算のみで利用することでfilteringを実現しています。</p>
<h1>Sorted Arrayを使った差分更新</h1>
<p>二つ目の面白ポイントはaggregationの差分更新の部分です。</p>
<p>上のコードに書いたように、reducerは常に<code>reduceAdd</code>, <code>reduceRemove</code>の両方を定義する必要があり差分更新を効率的に対応します。それに加えて、dimensionは、値をソートした配列 x 元データのindex配列 x 現在のlower/upper bound を持ち、BitMatrixも差分更新することができます（旧lower/upper boundと新lower/upper boundの差分indexだけXORで更新する）。</p>
<p>ちょっと端折って書いていますが、下記に例を書きました。sortされた配列からbinary searchでboundsを更新し、次に上記で説明したBitMatrixを更新し、更新のあったデータ行のみreducerを差分更新する、といった具合です。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/5e3a0d79-b8ff-40b1-828c-9325f21b2bff/58e9dcee6ec63b0bbac5853d.png" alt="58e9dcee6ec63b0bbac5853d.png"></p>
<p>ちなみに、上記のトリックはequalやrangeでのフィルタリングの話ですが、<code>crossfilter</code>は<a href="https://github.com/square/crossfilter/wiki/API-Reference#dimension_filterFunction">関数を定義したフィルタリング</a>もかけることができます。</p>
<pre><code>dim.filter([100, 200]) # range
dim.filter(120) # equal
dim.filter((d) -&gt; return d % 2) # function
</code></pre>
<p>その場合は上記のトリックは効かないため、若干パフォーマンスが落ちると考えられます。そのため、できれば<code>dimension</code>の時点で前処理をしておいて、<code>filter</code>はequalやrangeでかける方がパフォーマンスが良いと考えられます。</p>
<h1>感想</h1>
<p>さて、とりあえず3つほど<code>Crossfilter</code>のキモっぽいポイントを紹介しましたが、実際のパフォーマンスのインパクトの割にはなんだか地味だな、、と書いていて思ったのと、自分には絵を書いているうちに力尽きる傾向があることに気がつきました。<code>Crossfilter</code>自体には他にもbit演算を駆使した高速化（ <a href="https://graphics.stanford.edu/~seander/bithacks.html">Bit Twiddling Hacks</a>）が散らばっていて  <s>ぶっちゃけかなり読みづらい</s> 結構面白いので興味があったらコードリーディングしてみると良いかもしれません。</p>
<p>また、filter|reducer共に並列化可能な形式であったり、tree上のcacheを使えばaggregationをさらに高速化できそうな所、サーバーとしての利用など、随所にupdateできそうな部分があります。ここら辺も詳しい人|知らないけど議論してみたい人など募集しています。是非とも気軽に五反田まで遊びに来てください。やけに安いけれど美味しくない焼肉屋とか奢ります！</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>


このエントリは、bit matrixやbit twiddlingといったテクニックで効率的なフィルタリングとアグリゲーションを実現することで、数百万レコード程度であ

Bit Matrixを使って超高速にアグリゲーションする | PLAID engineer blog

Bit Matrixを使って超高速にアグリゲーションする

<p>こんにちは！プレイドの@ikemonnです。<br>
<a href="/aws_gcp_multicloud_2/">前回</a>はAWSとGCPをVPNで接続した話をしました。<br>
今回はGCPでの検証を行った際の進め方について説明していきます。</p>
<p>インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気づくことができ、予定していなかったインフラ構成の変更が必要であることが確認できました。</p>
<p>マルチクラウドインフラを構築する際には「小さく始めて、検証できる環境を作る」ことがポイントになります。</p>
<h2>目次</h2>
<ul>
<li>小さく始める</li>
<li>検証する</li>
<li>まとめ</li>
</ul>
<h2>小さく始める</h2>
<h3>最初に検証するサーバの選定</h3>
<p>今回は下記の3点を基準にどのサーバをまずGCPへ移行するかを選定しました。</p>
<ol>
<li>お客様への影響が少ないサーバ</li>
<li>GCPへ移行のメリットが大きいサーバ(パフォーマンス向上等)</li>
<li>関連するコンポーネントが少ないサーバ</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dcbce60b-6fbf-42b7-b5d1-9ccb6c54698c/131d4ecd-a618-4ae8-bc0a-4426f98ed44d.png" alt=""></p>
<p>KARTEでは処理の内容毎にサーバ群が分かれており、大きく分けると「エンドユーザからのアクセスを受けるWebサーバ群」と「タスクキューからタスクを取得して処理していくサーバ群」の2種類があります。</p>
<ol>
<li><a href="https://cloud.google.com/bigtable/">Cloud BigTable</a>を一番使用していて移行のメリットが大きい</li>
<li>LB等の関連するコンポーネントが少ないので構築が楽</li>
</ol>
<p>という特性の「タスクキューからタスクを取得して処理していくサーバ群」から移行を始めることにしました。</p>
<h3>検証用サーバの構築</h3>
<p>構築の際には下記の点を意識しながら構築を進めていきました。</p>
<ol>
<li>GCPの操作に慣れ、特徴をつかむためにまずWebコンソールから手動でサーバを立てる</li>
<li>GCPに慣れた後は今後のことを考えて使いまわせるようにする</li>
</ol>
<h3>Webコンソールからサーバを構築する</h3>
<p>まずはWebコンソールから手動でサーバを構築することから始めました。</p>
<p>もともとAWS上のサーバはTerraformを用いて構築していました。<br>
しかし、いきなりGCPもTerraformで構築しても設定すべきパラメータや各コンポーネントとの関連が理解できておらず効率が悪いです。<br>
まず最初は手動で作るのがオススメです。</p>
<p>Webコンソールから構築をすることで、「AWSとGCPではブロックデバイスの扱いが異なっている(GCPではImageにブロックデバイスの情報は付与されていない)」ことや「AutoScaling Groupで設定すべき項目が大きく異なる」ことなど、プラットフォームの違いが分かり、後のTerraform化作業がスムーズに行えました。</p>
<p>下記がTerraformでのlaunch config/instance templateコードです。<br>
disk周りの設定が異なっていることがわかります。</p>
<pre><code># GCPのinstance template (Imageにdisk情報が含まれていないので指定する必要がある)
resource &quot;google_compute_instance_template&quot; &quot;foobar&quot; {
  name        = &quot;terraform-test&quot;
  machine_type         = &quot;n1-standard-1&quot;

  // Create a new boot disk from an image
  disk {
    source_image = &quot;debian-cloud/debian-8&quot;
    auto_delete  = true
    boot         = true
  }

  // Use an existing disk resource
  disk {
    source      = &quot;foo_existing_disk&quot;
    auto_delete = false
    boot        = false
  }
...(中略)
}
</code></pre>
<pre><code># AWSのlaunch config (AMIにdisk情報も含まれているので指定する必要が無い)
resource &quot;aws_launch_configuration&quot; &quot;as_conf&quot; {
  name_prefix   = &quot;terraform-lc-example-&quot;
  image_id      = &quot;${data.aws_ami.ubuntu.id}&quot;
  instance_type = &quot;t2.micro&quot;

  lifecycle {
    create_before_destroy = true
  }
}
</code></pre>
<p>「この部分はAWSでいう〇〇だ」というようなことを考えながら構築するのがオススメです。</p>
<h3>最低限使いまわせるようにする</h3>
<p>手動でサーバを構築することで、設定すべき項目のあたりがつくようになりました。<br>
今後のことを考えると、手動構築ではサーバをスケールさせてパフォーマンスを見たい時や、他の役割のサーバ群を立てる時に大変です。<br>
そこで、後々使いまわせるようにサーバの構成管理とImage作成に関しては、再利用できるようにすることにしました。</p>
<p>様々なツールがでているのですが、「マルチプラットフォームで使用できる」という点を踏まえて下記のツールを選びました。</p>
<ul>
<li>サーバの構成管理: <a href="https://www.terraform.io/">Terraform</a></li>
<li>Image作成: <a href="https://www.packer.io/">Packer</a></li>
</ul>
<p>AWSでもサーバの構成管理はTerraformで行っていたので引き続き使うことにしました。<br>
問題はImageを作成する部分でした。<br>
もともと、<a href="https://aws.amazon.com/jp/cloudformation/">AWS CloudFormation</a>で作っていたのですが、CloudFormationではGCEのイメージは作成できません。</p>
<p>また、Googleのサービス<a href="https://cloud.google.com/deployment-manager/">Google Cloud Deployment Manager</a> もありますが、CloudFront/Deployment Managerの双方を使いコードを2重管理するのは面倒です。</p>
<p>「マルチプラットフォームのimageを簡単に作れる」「コードを2重管理しなくて良い」という点を考えてツールを探した結果、<a href="https://www.packer.io/">Packer</a>を使用することにしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5ebd17e-6cc9-41e3-9bd8-ffd2a602c4e1/f83816eb-c62b-48c3-9eb8-37036d0125c4.png" alt=""></p>
<p>PackerとはTerraformや<a href="https://www.vagrantup.com/">Vagrant</a>を作っている<a href="https://www.hashicorp.com/">HashiCorp</a>社の製品で、ユーザが準備した設定ファイルに従って、仮想マシン等のイメージ作成とプロビジョニングを行ってくれるツールです。<br>
Packerを使うことでAWS/GCP両方のイメージを作成することができます。</p>
<p>下記のように、AWSとGCPのサーバの設定をそれぞれ指定して書いていきます。</p>
<pre><code>{
  &quot;variables&quot;: {
     &quot;node_ver&quot;: &quot;6.9.2&quot;,
     &quot;npm_ver&quot;: &quot;3.8.8&quot;,
     ...
     },
  &quot;builders&quot;: [
    {
      &quot;type&quot;: &quot;googlecompute&quot;,
      &quot;instance_name&quot;: &quot;{{user `environment`}}-node-{{isotime \&quot;2006-01-02-1504\&quot;}}&quot;,
      &quot;image_name&quot;: &quot;{{user `environment`}}-node-{{isotime \&quot;2006-01-02-1504\&quot;}}&quot;,
      &quot;account_file&quot;: &quot;{{user `gcp_account_file`}}&quot;,
      &quot;project_id&quot;: &quot;{{user `gcp_project_id`}}&quot;,
      &quot;disk_type&quot;: &quot;pd-ssd&quot;,
      &quot;machine_type&quot;: &quot;n1-standard-2&quot;,
      &quot;disk_size&quot;: &quot;{{user `root_volume_size`}}&quot;,
      &quot;ssh_username&quot;: &quot;root&quot;,
      &quot;source_image&quot;: &quot;{{user `gcp_source_image`}}&quot;,
      &quot;zone&quot;: &quot;asia-east1-a&quot;
    },
    {
      &quot;type&quot;: &quot;amazon-ebs&quot;,
      &quot;access_key&quot;: &quot;{{user `aws_access_key`}}&quot;,
      &quot;secret_key&quot;: &quot;{{user `aws_secret_key`}}&quot;,
      &quot;region&quot;: &quot;{{user `aws_region`}}&quot;,
      &quot;iam_instance_profile&quot;: &quot;{{user `aws_iam_instance_profile`}}&quot;,
      &quot;source_ami&quot;: &quot;{{user `aws_source_image`}}&quot;,
      &quot;instance_type&quot;: &quot;c4.large&quot;,
      &quot;ssh_username&quot;: &quot;ubuntu&quot;,
      &quot;associate_public_ip_address&quot;: &quot;true&quot;,
      &quot;ami_name&quot;: &quot;{{user `environment`}}_nodeami_{{isotime \&quot;2006-01-02-1504\&quot;}}&quot;,
      &quot;enhanced_networking&quot;: &quot;true&quot;,
      &quot;launch_block_device_mappings&quot;:[
        {
          &quot;device_name&quot;: &quot;/dev/sda1&quot;,
          &quot;volume_size&quot;: &quot;{{user `root_volume_size`}}&quot;,
          &quot;volume_type&quot;: &quot;gp2&quot;,
          &quot;delete_on_termination&quot;: &quot;true&quot;
        },
        {
          &quot;device_name&quot;: &quot;/dev/sdf&quot;,
          &quot;volume_size&quot;: &quot;10&quot;,
          &quot;volume_type&quot;: &quot;gp2&quot;,
          &quot;delete_on_termination&quot;: &quot;true&quot;
        }
      ],
      &quot;vpc_id&quot;:&quot;{{user `vpc_id`}}&quot;,
      &quot;subnet_id&quot;:&quot;{{user `subnet_id`}}&quot;,
      &quot;communicator&quot;: &quot;ssh&quot;,
      &quot;user_data_file&quot;: &quot;common/aws_user_data.sh&quot;
    }
  ],
  &quot;provisioners&quot;: [
    {
      &quot;only&quot;: [&quot;amazon-ebs&quot;],
      &quot;type&quot;: &quot;shell&quot;,
      &quot;script&quot;: &quot;common/init_for_aws.sh&quot;,
      &quot;execute_command&quot;: &quot;{{ .Vars }} sudo -E sh '{{ .Path }}'&quot;
    },
    {
      &quot;only&quot;: [&quot;googlecompute&quot;],
      &quot;type&quot;: &quot;shell&quot;,
      &quot;script&quot;: &quot;common/init_for_gcp.sh&quot;,
      &quot;execute_command&quot;: &quot;{{ .Vars }} sudo -E sh '{{ .Path }}'&quot;
    },
    {
      &quot;type&quot;: &quot;shell&quot;,
      &quot;scripts&quot;: [&quot;common/exec_serverspec.sh&quot;],
      &quot;execute_command&quot;: &quot;{{ .Vars }} sudo -E sh '{{ .Path }}'&quot;
    }
  ]
</code></pre>
<p>Packerの良い点は、コマンドを実行するだけでイメージを作成できるところです。<br>
CloudFormationを使っていた時はインスタンスを立てた後、AMIを作成する &amp; image作成後のインスタンス削除は手動で行っていました。<br>
Packerに変えることで、image作成&amp;インスタンス削除が全てコマンドラインだけで行えるので作業効率化につながりました。</p>
<p>また、下記のようにimage作成処理は並列で実行されるところも良い点です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c9968569-4555-4b10-81ce-10137fe0c725/b1a72c54-1a15-46ff-a49f-d9bdcc2e4877.png" alt=""></p>
<p>実際にイメージを作ってみたところ、GCPのimageの方がAWSよりも2~3分早く作成されました。<br>
弊社はNode.jsを使用しており、Node.jsのinstallまではAWSの方が1.5分ほど早いのですが、node_moduleのinstallになるとGCPが逆転していました。<br>
処理内容を見てみると、EBSへのファイル書き込みで時間がかかっているようなので、GCPの方がそのあたりは速いようです。</p>
<h2>検証する</h2>
<p>Packer + Terraformでサーバを構築できたので検証に移ります。</p>
<p>弊社では<a href="https://www.datadoghq.com/">Datadog</a>というモニタリングツールを使い、インフラ&amp;アプリケーションの監視を行っています。(詳しくはこちら→ <a href="/freee-plaid-monitoring-meetup/">【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！</a>)<br>
今回もAWSとGCPのパフォーマンスをDatadogで可視化し、どの処理に時間がかかっているかを調べました。</p>
<p>弊社の @makinoy が作成した<a href="https://github.com/makinoy/libs-dogstatsd">makinoy/libs-dogstatsd</a>という、処理の実行時間や処理回数をDatadogに送信できるラッパーを使用して実行時間を計測しました。</p>
<pre><code>var dogstatsd = require('libs-dogstatsd')

const stats = dogstatsd.start();
// some method
stats.tick(‘test’, 1, 1, [pid:1234]);
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0e4b0ffd-24f9-4be0-a211-f5ea4828e038/9bd9a590-407d-4da6-9d2d-33393c00efb9.png" alt=""></p>
<p>この時点では、上記のような構成でGCP上のサーバからAWSのDBを見に行くようになっているので、VPN越しのDBへの接続がボトルネックになっていることが分かりました。</p>
<p>一方、BigTableへの接続は同じGCP上にあることで、AWS環境で動かしていた時よりも早いということも分かりました。</p>
<p>また、一気に大量のインスタンスを立てて検証していた時に、想定外のボトルネックが見つかりました。<br>
一定台数以上のインタンスを立てるとパフォーマンスが出なくなったのです。<br>
よくよく調べてみると、ドキュメントには明記されていなかったのですが、どうもVPNの帯域に上限があるようでした。<br>
このままではGCP上でサーバをスケールできないので、DBの配置を変更してVPN経由の通信を減らす必要があることが分かりました。</p>
<p>このような想定外のボトルネックも早めに検証することで確認できたのが大きかったです。</p>
<p>DB構成については、次回以降の記事でどのように改善したのかお伝えしていきます！</p>
<h2>まとめ</h2>
<p>マルチプラットフォームでの検証を進める際には、下記を意識して進めていくと良いと思います。</p>
<ul>
<li>まずは手動でサーバを立ててみて、そのプラットフォームに慣れる</li>
<li>初めは極力作り込まずにサーバを立てて検証を始める</li>
</ul>
<p>「頑張りすぎずに小さく始めて、検証していく」ことでマルチプラットフォーム化を効率よく進めていきましょう！</p>
<h2>関連リンク</h2>
<ul>
<li><a href="/aws_gcp_multicloud_1/">AWSとGCPでマルチクラウドインフラを構築した話とそのポイント| PLAID engineer blog</a></li>
<li><a href="/aws_gcp_multicloud_2/">AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント| PLAID engineer blog</a></li>
</ul>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、マルチクラウドインフラを成長させたい、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<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>


今回はGCPでの検証を行った際の進め方について説明していきます。インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気

AWSとGCPのマルチクラウドインフラ検証の進め方

<p>みなさん、ごきげんよう。プレイドの@tik-sonと申します。</p>
<p><a href="http://tech.plaid.co.jp/aws_gcp_multicloud_1/">前回のエントリー</a>では、<br>
弊社の<a href="https://karte.io">KARTE</a>で、インフラには<a href="https://aws.amazon.com">AWS</a>と<a href="https://cloud.google.com/">GCP</a>の２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しているというお話をいたしました。<br>
今回のエントリーではその中から、「AWSとGCPをVPNで接続した」内容についてフォーカスして</p>
<ul>
<li>各クラウドプラットフォームでのVPNの仕様</li>
<li>KARTEではどのようなVPN設計にしているのか</li>
</ul>
<p>等をお話したいと思います。</p>
<h1>目次</h1>
<ul>
<li>VPNを用いる理由</li>
<li>AWSとGCPのSubnetの違い</li>
<li>VPNを接続する</li>
<li>可用性を考える</li>
<li>パフォーマンスを考える</li>
<li>VPN周りの設計について</li>
<li>悩まされたこと</li>
<li>最後に</li>
</ul>
<h1>VPNを用いる理由</h1>
<p><a href="http://tech.plaid.co.jp/aws_gcp_multicloud_1/">前回のエントリー</a>で、マルチクラウドインフラの要件として <strong>「各クラウドプラットフォームのサーバが相互に通信できる」</strong> と記載しましたが、私達はその実現方法としてVPNを選択しました。<br>
VPNであればプライベートネットワークを拡張する形になるので<br>
既存のAWSのネットワーク構成変更を少なく、GCPのサーバとセキュアに通信ができるようにすることができるからです。</p>
<p>もちろんサーバにグローバルIPアドレスを持たせて直接通信させる案も考えましたが、</p>
<ul>
<li>外部に対して通信できるように新たにポートを空けなければならない</li>
<li>通信を暗号化しなければならない</li>
</ul>
<p>など考慮しなければいけないポイントが多くでてきてしまい、実装まで時間がかかりそうだったため、今回は選択しませんでした。</p>
<h1>AWSとGCPのSubnetの違い</h1>
<p>はじめにVPNにて利用するSubnetにおけるAWSとGCPの違いについて軽くお話をします。</p>
<h2>AWSのSubnet</h2>
<p>AWSでプライベートなネットワークを作る時は<a href="https://aws.amazon.com/vpc/">VPC</a>という機能を使います。1つのVPCの中に最大 <code>/16</code> のネットマスクのプライベートネットワークを定義でき、そのプライベートネットワークの中で更にSubnetを切っていくことができます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/a72f0973-8348-4b17-b040-ae9458865846/1-1.png" /></div>
`https://cloud.google.com/compute/docs/networking#subnet_network`
<h2>GCPのSubnet</h2>
<p>GCPではAWSのVPCのようなサービスとして定義はされていないのですが、以下の図のように1つのGCP Networkという単位の中に様々なSubnetを作成することができます。<br>
例えば、<code>10.240.0.0/24</code> と <code>192.168.1.0/24</code> を１つのGCP Networkを共存させることができ、それぞれのSubnetは特に設定不要で相互通信が可能になります。<br>
GCPの方がAWSより柔軟にSubnetを作れるようです。<br>
ただし、Subnetは柔軟に作れますが、 GCP Network上で稼働させるインスタンスの<a href="https://cloud.google.com/compute/docs/networking#quotas_and_limits">台数制限はデフォルトだと7000台</a> だということ は注意しなければなりません。(なかなかその上限に引っかかることは無いと思いますが)</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/33ed5504-df40-4ef3-ab1f-a51109c43da4/2-1.png" /></div>
<p><code>https://cloud.google.com/compute/docs/networking#subnet_network</code></p>
<h1>VPNを接続する</h1>
<p>VPNには色々な種類がありますが、今回使用するVPNはAWS、GCPが共にサポートしているIPsecVPNになります。</p>
<p>AWSとGCPをVPN接続する際の詳細な手順については<br>
<a href="http://dev.classmethod.jp/cloud/vpn-interconnect-amazon-vpc-and-gce/">クラスメソッドさんの記事</a>に記載されているので参考にさせていだきました。少し古い記事になりますが、流れとしてはほとんど変わっていないので、こちらとあわせて<br>
<a href="http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html">AWSのドキュメント</a>と<br>
<a href="https://cloud.google.com/compute/docs/vpn/creating-vpns">GCPのドキュメント</a><br>
を参考にしていただければ、特につまることなくVPN接続が出来るかと思います。<br>
記事内でも紹介されていますが、VPN接続の設定順番が重要になってきます。<br>
また、この記事の記載後にGCEのネットワークの機能が拡張されたことで、現在はVPN接続を定義したリージョン以外のインスタンスからもVPN接続を利用できるようになっています。</p>
<h1>可用性を考える</h1>
<p>本番環境で運用する上で可用性を考えないわけにはいきません。<br>
VPNトンネルが１つしかない状態でそのVPNトンネルが切断されてしまうとどうなるでしょうか？<br>
答えは簡単でAWS、GCP間で通信ができなくなるというクリティカルな問題が発生してしまいます。<br>
したがって<code>VPNを冗長化</code> することはとても大切です。</p>
<p>AWSでは1VPN設定に対して、2VPNトンネル、GCPでは1VPN設定に対して1VPNトンネルが提供されます。<br>
GCP、AWS共に2VPN設定ずつ用意し、以下の図のように構成を組むことで、冗長構成を取ることができます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/14be069b-2a93-43b1-b569-f7c034014df7/3-2.png" /></div>
<p><code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html#VPNConnections</code></p>
<p>尚、どちらのプラットフォームにおいても、それぞれのゲートウェイで同じルーティングを設定しておけば、片方のトンネルが落ちてしまった時に残りのトンネルを利用してくれるようになります。</p>
<p><strong>GCP</strong></p>
<blockquote>
<p>Cloud VPN ゲートウェイは、ピア VPN ゲートウェイが停止して一方の VPN トンネルが使用できなくなっても、もう一方の VPN トンネルを使用し続けます。停止した VPN トンネルが復帰すると、また自動的に両方のトンネルを使用します<code>https://cloud.google.com/compute/docs/vpn/advanced#redundancy_and_failover</code></p>
</blockquote>
<p><strong>AWS</strong></p>
<blockquote>
<p>AWS はときどき、仮想プライベートゲートウェイに対して定期的にメンテナンスを実行します。このメンテナンスによって VPN の 2 つのトンネルのうち 1 つが短時間無効になることがあります。このメンテナンスの実行中、VPN 接続は自動的に 2 番目のトンネルにフェイルオーバーします。サービスが中断されないようにするために、両方のトンネルを設定することが重要です。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#CustomerGateway</code></p>
</blockquote>
<blockquote>
<p>カスタマーゲートウェイが使用できなくなった場合に接続が失われるのを防ぐために、2 番目のカスタマーゲートウェイを使用して、VPC および仮想プライベートゲートウェイへの 2 番目の VPN 接続を設定できます。冗長な VPN 接続とカスタマーゲートウェイを使用すれば、1 つのカスタマーゲートウェイでメンテナンスを実行しながら、2 番目のカスタマーゲートウェイの VPN 接続を通してトラフィックの送信を継続することができます。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html#VPNConnections</code></p>
</blockquote>
<p>ちなみに<a href="https://cloud.google.com/vpn/sla">GCPはVPNのSLA</a>が定義されていますが、AWSにはSLAの記述がないようです。<br>
また、GCPにもSLAはありますがGoogleのコントロール外の部分(インターネット等)による問題については保証されていない点については意識しておかなくてはいけません。</p>
<h1>パフォーマンスを考える</h1>
<p>もちろん本番環境で運用する上では可用性だけではなくパフォーマンスも考えないわけにはいきませんよね。ということで話をします。</p>
<h2>VPNのスループット</h2>
<p>各プラットフォームは以下の通りスループットについて説明があり、まとめると以下の通りです。</p>
<ul>
<li>AWSでは仕様上、スループットの制限は特にない</li>
<li>GCPは仕様上、VPN ゲートウェイごとに1.5 Gbpsまでのスループットのサポートはしている</li>
<li>スループットは利用環境によって変わるので実質、保証はされない</li>
</ul>
<p><strong>AWS</strong></p>
<blockquote>
<p>Q: VPN 接続のスループット制限はありますか?<br>
VPN のスループットについて、Amazon はいかなる制限も実施していません。ただし、その他の要因、例えばカスタマーゲートウェイの暗号化能力や、お客様側のインターネット接続速度、平均パケットサイズ、使用されているプロトコル（TCP か UDP か）、カスタマーゲートウェイと仮想プライベートゲートウェイの間のネットワークレイテンシーなどが、スループットに影響を与える可能性があります。<br>
<code>https://aws.amazon.com/jp/vpc/faqs/</code></p>
</blockquote>
<p><strong>GCP</strong></p>
<blockquote>
<p>各 Cloud VPN ゲートウェイでは、すべてのトンネルで最大 1.5 Gbps のスループットがサポートされています。スループットを最大にするには、トンネルごとに Cloud VPN ゲートウェイを作成します。 実際のパフォーマンスは次の要因によって変動します。</p>
</blockquote>
<ul>
<li>2 つの VPN ピア間のネットワーク容量。</li>
<li>ピアデバイスの機能。詳しくは、デバイスのドキュメントをご覧ください。</li>
<li>パケットサイズ。パケット単位で処理が発生するため、小さなパケットの割合が高いと全体的なスループットが低下します。</li>
<li>RTT やパケット損失率の値が高いと、TCP のスループットが大幅に低下します。<br>
<code>https://cloud.google.com/compute/docs/vpn/advanced#vpn_throughput</code></li>
</ul>
<h2>VPNトンネルへのトラフィックをコントロール</h2>
<p>スループットについてお話しましたが、仕様上においても1VPNトンネルだけだとスループットに限界があるため、複数のVPNトンネルを組み合わせることが大切だということが分かると思います。<br>
AWS、GCP共に、トラフィックを流すVPNトンネルをコントロールすることができるので、その仕様について紹介します。両クラウドプラットフォームともにトラフィックをコントロールすることはできるものの出来ることが少し異なっています。</p>
<p><strong>GCP</strong></p>
<ul>
<li>各VPNトンネルへのルーティング、Priorityを同じにすると、トラフィックをそれぞれのトンネルにバランシングしてくれます。</li>
<li>各VPNトンネルへのルーティングを同じにし、Priorityに差をつけると、Priorityが高いVPNトンネルがプライマリーのVPNトンネルとして利用されるようになります。<br>
<code>https://cloud.google.com/compute/docs/vpn/advanced#redundancy_and_failover</code></li>
</ul>
<p><strong>AWS</strong></p>
<ul>
<li>
<p>VPCのVPNでは Multi Path でのルーティングには未対応なので、バランシングはしてくれません。AWS側で定められたロジックによって、必ずVPNトンネルのどれかを利用することになります。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#MultipleVPNConnections</code></p>
</li>
<li>
<p>静的ルーティングの場合は最も具体的な IP プレフィックスが優先されます。<br>
例を示します。(参考: <a href="http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html#route-tables-priority">ルーティングの優先度について</a>)</p>
<p>IP プレフィックスについて少しややこしいと思うので以下の静的ルーティングが設定されたVPN1、VPN2という2つのVPN接続を例に説明してみます。</p>
  <table>
  <tr>
  <th> </th>
  <th>VPN1</th>
  <th>VPN2</th>
  </tr>
  <tr>
  <td>設定された静的ルーティング</td>
  <td>10.1.0.0/18,  10.1.64.0/18,  10.1.128.0/17</td>
  <td>10.1.0.0/17, 10.1.128.0/18, 10.1.192.0/18</td>
  </tr>
  </table>
  この場合
  - 全VPNが正常な場合はそれぞれ `/18` を設定したVPNが優先になります。
  - 片方のVPN切断時には `/18` で設定されたルーティングを包括する `/17` のルーティングが別のVPNに設定されているのでそちらの経路が使って迂回されることになります。
</li>
</ul>
<h1>VPN周りの設計について</h1>
<p>可用性やパフォーマンスについて記載してきましたが、それらを踏まえてVPN周りは以下のように設計にしています。</p>
<ul>
<li>VPNトンネルは複数作成する。</li>
<li>特定のVPNトンネルにトラフィックが偏らないように、
<ul>
<li>GCP側のサーバは複数のSubnetにサーバを分散させて配置する。</li>
<li>AWS側のルーティングは特定のSubnetへの通信が特定のVPNトンネルを利用するよう設定する。</li>
<li>GCP側のルーティングは全VPNトンネルでバランシングされるように同じプライオリティで同じ内容を設定する。</li>
</ul>
</li>
<li>VPNトンネルが切断された時に別トンネルで迂回できるよう、
<ul>
<li>AWS側のルーティングでは全VPNトンネルに対して別VPNトンネルのルーティングを包括するルーティングを記載しておく。</li>
<li>GCP側のルーティングでは全VPNトンネルに対して、同じルーティングを設定しておく。</li>
</ul>
</li>
</ul>
<p>イメージとしては以下の図のようになります</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/976999df-225b-4dbb-9f5c-d01a2270601c/4-1.png" /></div>
<p>ちなみにKARTEではシンプルなネットワーク構成にしているので、静的ルーティングを利用し<br>
ています。</p>
<h1>悩まされたこと</h1>
<h2>VPNのDropパケットの増加問題</h2>
<p>AWSとGCPをVPNで接続して運用していたある日、GCPのサーバのパフォーマンスが悪化することがありました。<br>
GCPは<a href="https://www.stackdriver.com/">StackDriver</a>でVPNの様々なメトリックををモニタリングできるので確認してみたところ、特定のVPNトンネルでDropパケットの増加が見受けられました。<br>
VPNトンネルが切断されてしまえば別のVPNトンネルを利用するようにしていたのですが、そのVPNトンネルは劣化した状態で生き続けていました。<br>
対応としては、特定のVPNトンネルの問題として判断し、劣化したVPNトンネルを切断し正常なVPNトンネルのみを利用するようにしたところ現象が改善しました。</p>
<p>後々、GCP、AWS両方のサポートなどに問い合わせて原因を突き詰めていったところ、AWSにおけるネットワークの劣化が原因で、VPNトンネルは落ちないがパケットがDropされているという状況でした。<br>
ネットワーク周りの問題は切り分けが難しいですが、モニタリングツールが存在することで切り分け、対応が迅速に行うことが出来ました。<br>
この件以降、VPNトンネルに対し、DropパケットなどのMetricでアラートを仕掛けるようにしています。</p>
<h2>VPNのスループット問題</h2>
<p>元々単一クラウドプラットフォーム内のプライベートネットワーク内で通信していたものをVPN越しで通信させようとすると、想定した以上にアプリケーションの性能が出ませんでした。<br>
その主な理由としては、DBとの通信の多くがVPN経由になっていたことでした。</p>
<p>VPNトンネルを増やしていけば暫定的には解決できる話になりますが、そもそも元々のアーキテクチャがマルチクラウドインフラに最適なアーキテクチャになっているとは言えなかったので、その部分について考え直しました。このあたりの話はまた別エントリーでお話しようと思うので乞うご期待を。</p>
<h1>今後について</h1>
<p>AWSとGCPの周りにはまだまだ改善の余地はあるので、今後以下を考えていきたいと思っています。</p>
<ul>
<li>特定の条件でVPNトンネル切断→接続する等のVPN運用周りでの自動化の仕組み</li>
<li>VPNトンネルのAutoscalingの仕組み</li>
<li>VPN経由ではないサーバ間通信の仕組み</li>
</ul>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、マルチクラウドインフラを成長させたい、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<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>


AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイントを説明します。
マルチクラウドインフラ連載の第二回。

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント| PLAID engineer blog

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

<p>ごきげんよう。プレイドの@tik-sonと申します。<br>
みなさんはクラウドプラットフォームを利用していますか？</p>
<p>弊社の<a href="https://karte.io">KARTE</a>は</p>
<ul>
<li>秒間3000イベントをリアルタイムで解析</li>
<li>累計解析ユーザがリリースから2年で12.5億<br>
https://karte.io/infographic/2017.html</li>
</ul>
<p>という規模のサービスになっています。<br>
そこで動いているインフラもそれなりに大規模になっており、インフラをいかに改善していくかが事業進捗に大きく関わってきます。</p>
<p>そのインフラを改善する試みとして半年ぐらい前から、<a href="https://aws.amazon.com">AWS</a>と<a href="https://cloud.google.com/">GCP</a>の２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しています。<br>
<a href="http://tech.plaid.co.jp/">PLAID Enginner Blog</a>では複数回に渡ってマルチクラウドインフラを作る上で試行錯誤したポイントなどを紹介していこうと思います。<br>
今回は初回ということで概要部分について記載し、次回以降のエントリーで深掘りをしていきます。<br>
興味を持たれた方は本ブログをブックマーク等をしていただけば幸いです。</p>
<h1>目次</h1>
<ul>
<li>マルチクラウドインフラとは？</li>
<li>なぜマルチクラウドインフラを作るのか？</li>
<li>マルチクラウドインフラの構成</li>
<li>マルチクラウドインフラへの移行手順</li>
<li>まとめ</li>
<li>最後に</li>
</ul>
<h1>マルチクラウドインフラとは？</h1>
<p>私達がお話するマルチクラウドインフラとは、<br>
複数のクラウドプラットフォームを組み合わせ、それぞれのサーバが相互通信でき、あたかも１つのプラットフォームのように稼働させることができるインフラのことです。<br>
イメージにすると以下の図のようになります。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/77d17f92-74f7-4789-8e80-a0fd89074a1b/1.png" /></div>
<h1>なぜマルチクラウドインフラを作るのか？</h1>
<h2>可用性の向上</h2>
<p>各クラウドプラットフォームではそれぞれのサービスごとにSLAが定義されていますが、100%の稼働を保証するものではありません。<br>
<a href="https://cloudharmony.com/">CloudHarmony</a>というサービスで過去の稼働率を確認することが出来るのですが、例えば、<a href="https://aws.amazon.com/ec2">EC2</a>、<a href="https://cloud.google.com/compute/">GCE</a>においてもDowntimeはそこそこ発生しているようです。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/9361312a-04fd-445e-9c56-3a01eb3aa8e3/2.png" /></div>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3efb0ce-00bb-4ac6-afd9-a4ea45e23788/2.5.png" /></div>
<p>また、各クラウドプラットフォーム内にてMultiAZやMultiRegionの構成を取ることで可用性を高めることは可能ですが、クラウドプラットフォームの共通部分で問題が起きてしまうと、MultiAZやMultiRegion構成を取っていてもサービスダウンを避けることは出来ません。<br>
実際、GCPで<a href="https://status.cloud.google.com/incident/compute/16020#5177473553661952">LoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害</a>が発生したこともあります。<br>
複数の異なるクラウドプラットフォームで稼働させることは、単一クラウドプラットフォームの障害の影響を抑えることができ、可用性を高めることができます。</p>
<h2>パフォーマンスの向上</h2>
<p><a href="https://aws.amazon.com/products/">AWS</a>、<a href="https://cloud.google.com/products/">GCP</a>共に様々な特色のサービスを提供しています。<br>
それぞれのサービスには得意、不得意な部分があり、適材適所で使うことでアプリケーションのパフォーマンスを向上させることができます。<br>
KARTEにおいても処理の一部をGCPの<a href="https://cloud.google.com/bigtable/">Cloud Bigtable</a>に置き換えたことにより、パフォーマンスが大きく改善しました。</p>
<p>ただ、「AWSのEC2からGCPのCloud Bigtableを利用する」といったようなクラウドプラットフォームをまたいでサービスを利用する際は、以下の要素がパフォーマンスを悪化させることがあり、無視することはできません。</p>
<ul>
<li>同じクラウドプラットフォーム内からの通信に比べて Latencyが大きくなる</li>
<li>各クラウドプラットフォーム管理外のネットワークが間に挟まってしまうので、問題が起きやすくなる</li>
</ul>
<p>当然ですが、Cloud BigtableのSLAにも <code>(c) errors: (i) caused by factors outside of Google's reasonable control; </code> というようにGoogleのコントロール外の部分でのエラーはSLA適用外と明記されています。<br>
https://cloud.google.com/bigtable/sla</p>
<p>サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることで、各サービスの恩恵をより多く受け、アプリケーションのパフォーマンスを向上させることができます。</p>
<h2>コストの低減</h2>
<p>各クラウドプラットフォームのサービスを適材適所に利用するだけでコストの低減が期待できるように思えますが、何も考えずに他クラウドプラットフォームのサービスを使用してしまうと、パフォーマンスは向上はする一方で、膨大なコストがかかってしまうことがあります。<br>
Cloud Bigtableを例に考えてみます。<br>
Cloud BigtableはGCPのサービスですが、もちろんAWSからも利用することができます。しかしAWS側から利用するとなると、インターネット経由でCloud Bigtableと通信することになるので、以下の図のように <strong>データ転送コストが有料</strong>になってしまいます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a5a6ab0-6f8d-4e7a-8864-0ad5c52b6392/3.png" /></div>
<ul>
<li>EC2でのCloud Bigtableからのread(①)はCloud BigtableのInternet EgressとしてGCP側で課金</li>
<li>EC2からCloud Bigtableへのwrite(②)はEC2のInternet EgressとしてAWS側で課金</li>
<li>Cloud Bigtableと同RegionのGCEであればread(③)、write(④)共に無料</li>
</ul>
<p>少量のデータを扱う際には対して気にならないかもしれませんが、大量のデータを扱うサービスは注意が必要です。請求を見て寿命が縮むことになります。<br>
実際に私達もCloud Bigtableの請求を見て寿命が縮んだ経験があります。<br>
私達がCloud Bigtableを導入しようと検証していた際にはインターネット経由のデータ転送コストが <strong>無料</strong> だったのですが、あるタイミングから有料に変更になり、気がついた時には <strong>サービス使用量全体の約30%</strong> をCloud Bigtableデータ転送コストが占めていたこともありました。。コストのアラートは適切に設定しておくことをおすすめします。<br>
パフォーマンスの話と同様にコストにおいても、サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることは重要です。</p>
<h2>そこに新しくて良い技術があったから</h2>
<p>新しいサービス/技術はどんどん触りたいし、良いものはどんどん導入したいというモチベーションが煮えたぎっていました。**「そこに新しくて良い技術があったから」**というのはプレイドのエンジニア文化として根付いています。</p>
<h1>マルチクラウドインフラの構成</h1>
<p>上記のモチベーションを元に作ってみたマルチクラウドインフラの構成概要図を掲載します。<br>
詳細は別のエントリーでお話することになると思いますが、ポイントとしては以下の通りです。</p>
<ul>
<li>AWS、GCPのPrivateNetworkをVPNで接続する。</li>
<li>Cloud Bigtableや<a href="https://cloud.google.com/bigquery/">Bigquery</a>などGCPのサービスを多く使うサーバは主にGCPで、<a href="https://aws.amazon.com/jp/dynamodb/">DynamoDB</a>などAWSのサービスを多く使うサーバは主にAWSで稼働させる。</li>
<li>特定のクラウドプラットフォームで何か問題があっても片方のクラウドプラットフォームで動くようにする。</li>
</ul>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/11449304-378e-4495-b7d0-9e0a5a173e88/4.png" /></div>
<p>また、運用周りのツール/サービスは基本的マルチクラウド対応しているものを利用しています。以下に一部を記載します。</p>
<table>
<tr>
<th>用途</th>
<th>ツール名</th>
</tr>
<tr>
<td>インフラの構成管理</td>
<td><a href="https://www.terraform.io/">Terraform</a></td>
</tr>
<tr>
<td>マシンイメージの作成</td>
<td><a href="https://www.packer.io/">Packer</a></td>
</tr>
<tr>
<td>マシンイメージのテスト</td>
<td><a href="http://serverspec.org/">Serverspec</a></td>
</tr>
<tr>
<td>メトリックの監視/アラート</td>
<td><a href="https://www.datadoghq.com/">Datadog</a></td>
</tr>
</table>
<h1>マルチクラウドインフラへの移行手順</h1>
<p>KARTEは元々はAWS上でのみで稼働していたので、既存のAWSで作っていた仕組みをベースに以下のステップでマルチクラウドインフラへと移行していきました。<br>
ちなみに移行作業はKARTE利用ユーザに影響が出ないよう、サービス停止を伴うメンテナンス作業は実施せずに進めていきました。<br>
本エントリーでは概要を説明するにとどまりますが、各ステップで試行錯誤したポイントについては次回以降のエントリーで記載していこうと考えています。</p>
<ol>
<li>AWSとGCPをVPNで接続する</li>
<li>GCPでAWSと同じようにリソースを立てれるようにする</li>
<li>GCPでリソースを一部稼働させパフォーマンスを計測する</li>
<li>計測したパフォーマンスを元にマルチクラウドを意識した構成/コードに修正する</li>
<li>修正完了後、GCPの割合を徐々に増やしていく</li>
<li>運用を整える</li>
</ol>
<p>*3,4,5のステップは一度ではなく何度も繰り返し、構成/コードを洗練させていきました。</p>
<h1>まとめ</h1>
<h2>良かった点</h2>
<h3>可用性の向上</h3>
<p>前述したようにGCPで<a href="https://status.cloud.google.com/incident/compute/16020#5177473553661952">LoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害</a>が発生したのですが、AWS/GCPのマルチクラウドインフラを作った後だったため、AWSに寄せて稼働させることができ、その影響を抑えることができました。</p>
<h3>パフォーマンスの向上</h3>
<p>Cloud Bigtableなど適材適所にサービスを導入し、GCPとAWSで双方で問題なく動かせるよう構成/コードを見直した結果、マルチクラウドインフラ構築前に比べ、パフォーマンスが格段に向上しました。<br>
またAWS/GCPそれぞれのサービスを導入しやすくなり、マルチクラウドインフラ構築後においても、日々パフォーマンスは改善しています。</p>
<h3>コストが 約40%低減</h3>
<p>データ転送コストを抑えつつ、パフォーマンスを向上させた結果、コストが約40%低減しました。</p>
<h3>エンジニアとしてのレベルアップ</h3>
<p>まとまった情報があまりない取り組みだったので、自分で考え抜く力、もがいて結果を出すという力が向上しました。</p>
<h2>意識しておかなければいけない点</h2>
<h3>利用サービスが増えることによって、学習コストも増える</h3>
<p>プレイドでは「新しいサービス/技術はどんどん触って、いいものはどんどん導入しようという」絶対的な文化があるので本項目は基本的には歓迎なのですが、企業文化やステージによっては考える必要があると思います。</p>
<h3>移行コストについて</h3>
<p>やってみないと分からない部分はありますが、移行に伴う以下のコストをある程度見積もっておくことは重要です。</p>
<ul>
<li>インフラのコスト：検証時、移行作業時にリソースを追加で立てる必要があるので</li>
<li>人のコスト：インフラの改修だけではなく、サービスのアーキテクチャを把握した上でコードの改修等の作業も必要になってくると思うので、それなりに覚悟は必要になります。折れない心が大切でした。プレイドではインフラ、アプリケーション、opsまで一通り修正をエンジニア2.5人×3ヶ月で実施しました</li>
</ul>
<h1>最後に</h1>
<p>私達のマルチクラウドインフラはまだ始まったばかりで、随時、拡張/改善していきたいと思っています。<br>
プレイドでは、マルチクラウドインフラをもっと成長させたい、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>


AWSとGCPでマルチクラウドインフラを始めた話。複数回連載予定の第一回です！

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント| PLAID engineer blog

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

<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を使ってユーザーがサイト内の各ページを遷移している様子をアクセスログから可視化してみました。

Engineer Blog

Recent Article

Chromeデベロッパーツールに独自機能を追加する6つのステップ

日本語を理解するチャットボットに挑戦した話

LinuxKit で実現する新しい Docker 実行環境

【エンジニアの】バルマーピークは本当にあるのか検証してみた【夢？】

山梨県河口湖に開発合宿へ行ってきました！

Bit Matrixを使って超高速にアグリゲーションする

AWSとGCPのマルチクラウドインフラ検証の進め方

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

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

Archives

Writers

Recent Article

Chromeデベロッパーツールに独自機能を追加する6つのステップ

日本語を理解するチャットボットに挑戦した話

LinuxKit で実現する新しい Docker 実行環境

【エンジニアの】バルマーピークは本当にあるのか 検証してみた【夢？】

山梨県河口湖に開発合宿へ行ってきました！

Bit Matrixを使って超高速にアグリゲーションする

AWSとGCPのマルチクラウドインフラ検証の進め方

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

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

Archives

Writers

【エンジニアの】バルマーピークは本当にあるのか検証してみた【夢？】