Engineer Blog

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

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。</p>
<p>今回は、2023年4月からBigQueryが<strong>Editions</strong>という料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。</p>
<p>BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。</p>
<p>しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり</p>
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
<p>による影響が発生しました。</p>
<p>storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、<strong>Long-Term Physical Storage</strong> という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。</p>
<p>一方で、slotの単価が <strong>$0.024/slothour</strong> から <strong>$0.048/slothour</strong> へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、<strong>Bigquery-Slot-Optimization Team</strong>です！</p>
<p>本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。</p>
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
<p>Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。<br>
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png"></p>
<p>MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。</p>
<p>まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。</p>
<p>時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。<br>
単純には</p>
<pre><code class="language-sql">  SELECT
    job_id,
    period_start,
    period_slot_ms
  FROM
    `{YOUR_PROJECT_NAME}.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
</code></pre>
<p>のようにすれば、簡単に取得できます。</p>
<p><strong>period_slot_ms</strong>とはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。</p>
<p>このテーブルをさらに、<code>INFORMATION_SCHEMA.JOBS</code> というテーブルを用いて、job_idをkeyにjoinすることで、実行されたqueryを取得できます。取得したqueryをさらに、<code>REGEXP_CONTAINS</code> 関数を用いて、正規表現で任意のJobに集約します。例えば、<code>WHEN REGEXP_CONTAINS(query, r'/* JOURNEY') THEN 'journey'</code> という表記により、queryのコメントに<code>/* JOURNEY</code> が含まれているqueryを <a href="https://karte.io/product/journey/">Journey</a> というProductのために使っているQuery Jobという形で集約できます。</p>
<p>集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。</p>
<p>Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。<br>
TypeScriptで書くとこのようになります。（※一部抜粋）</p>
<pre><code class="language-typescript">  const slots: v2.MetricSeries = {
    metric: '${metric_name}',
    type: 2,
    interval: 1,
    points: points,
    tags: [`project:${projectId}`, `task:${task}`],
  };

  const params: v2.MetricsApiSubmitMetricsRequest = {
    body: {
      series: [slots],
    },
  };

  apiInstance
    .submitMetrics(params)
    .then((data: v2.IntakePayloadAccepted) =&gt; {
      console.log('API called successfully. Returned data: ' + JSON.stringify(data));
    })
    .catch((error: any) =&gt; console.error(error));
</code></pre>
<p>この関数をDeployするには</p>
<pre><code class="language-bash">gcloud functions deploy $FUNCTION_NAME \
  --project=$GCP_PROJECT \
  --region=$REGION \
  --runtime nodejs14 \
  --entry-point=index \
  --gen2 \
  --source ./build \
  --trigger-topic=$TOPIC_NAME \
  --trigger-service-account=$TRIGGER_SERVICE_ACCOUNT_ADRESS \
  --service-account=$SERVICE_ACCOUNT_ADRESS \
  --retry \
  --timeout=180s \
  --set-env-vars=DATADOG_APP_KEY=$DATADOG_APP_KEY,DATADOG_API_KEY=$DATADOG_API_KEY
</code></pre>
<p>というgcloudコマンドだけでdeployできます。</p>
<p>さらに、このFunction を Cloud Scheduler で定期的に実行します。<br>
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。</p>
<p>結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。<br>
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png"></p>
<p>これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。<br>
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。</p>
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
<p>BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。</p>
<p>弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。<br>
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。<br>
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。<br>
これを最適化するために導入されたのが、AutoScaleです。</p>
<p>そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。</p>
<p>そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。</p>
<p>これらを考慮した上で、弊社で最適化した結果が以下の通りです。<br>
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png"></p>
<p>いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。<br>
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。<br>
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。<br>
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png"></p>
<p>ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。<br>
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。</p>
<p>最も大事なのは、<strong>Productごとに要件を把握し適切にReservationを配分する</strong>ことであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。</p>
<h2>最終的なコストは...?</h2>
<p><strong>全体で約20%のコスト削減を実現</strong> することができました。<br>
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。</p>
<p>以上のように<br>
① Monitoringの整備によるJobごとのSlot監視と削減<br>
② AutoScaleの導入によるSlotBaseLineの最適化全体</p>
<p>でBigQuery全体として、約20%のコスト削減を実現しました。</p>
<p>BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


BigQuery Editionsにおけるコスト最適化

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内で脆弱性診断を行なっている理由や、どのように診断から修正までを行なっているか、また社内で脆弱性診断をやることでどのような変化が起きたかについて紹介します。

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

今回のブログではプラットフォームチームにて取り組んだ、異なるデータベース間のリアルタイムレプリケーションについて解説いたします。

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

<p>初めまして！エンジニアのとさ (@tosa_now)です！</p>
<p>プレイドは、2023/10/28 (土) に開催された<a href="https://vuefes.jp/2023/">Vue Fes Japan 2023</a>にゴールドスポンサーとして協賛しました。</p>
<p>スポンサーブースの運営をする機会をいただき、参加者の皆さんに<a href="https://karte.io/">KARTE</a>のデモや現在作成中の機能についての説明やお話をすることができました。</p>
<p>今回のブログでは、参加したVue Fes Japanの様子をお伝えできればと思います。</p>
<p>今回スポンサーとして参加した理由は、PLAIDが開発しているKARTEというプロダクト内ではなんとVueが0系の時から利用しており、現状でも管理画面の大部分がVueで書かれておりコミュニティに助けられているので少しでも還元したいという思いから参加しました！</p>
<h2>Vue Fes 当日の様子</h2>
<p><img src="https://ik.imagekit.io/plaid/20f62fe9-7a00-4d55-b0bc-8e3702e7b810/1000002289.jpg" alt="1000002289.jpg"><em>スポンサーブースの準備完了後の写真</em></p>
<p>主にブースではKARTEのプロダクト説明をメインで行っていました。<br>
来訪してくださった方とVue2からVue3への移行をどのように進めているのかなどの技術雑談話でもりあがりました。</p>
<p><img src="https://ik.imagekit.io/plaid/bcbfc85c-7535-4087-a132-75fbb2c890cc/IMG_4361.jpg" alt="IMG_4361.jpg"><em>エンジニアのnichimuさんがスポンサーブースに立っている様子</em></p>
<p>プロダクト説明では、<a href="https://blocks.karte.io/">KARTE Blocks</a>と新機能であるエレメントビルダーを開発しているエンジニアのjunjun (@junish_js) さんによるデモで大いに盛り上がりました！！</p>
<p>エレメントビルダーの開発の裏側は<a href="https://cxclip.karte.io/products/developer/action-editor/">こちら</a>の記事で解説しています</p>
<p><img src="https://ik.imagekit.io/plaid/4a62f6c0-d15d-49ff-a81f-cb11fe87f2d6/IMG_4364.jpg" alt="IMG_4364.jpg"><em>エンジニアのjunjunさんがプロダクト説明をしている様子</em></p>
<p>とさの個人的な趣味でVue Fesの開催二日前に発売されたHHKB Professionalのお試し会も開催しました。興味を持ってくださる方が多くて嬉しかったです。<br>
<img src="https://ik.imagekit.io/plaid/00ea3072-8ce7-4ef7-ad70-6a0cfcf0e2a3/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-11-0510.53.04.png" alt="スクリーンショット2023-11-0510.53.04.png"></p>
<p>Vue Fesのスポンサーブース全体が賑やかでどの企業さんも回っていてとても楽しかったです。</p>
<h3>参加した開発メンバーの感想</h3>
<p>デザイナーの今西さん<br>
今回、ブース対応を初めて担当し、KARTEの魅力が少しでも伝わっていれば嬉しいなと思います。ひさしぶりのオフラインカンファレンスということで、当日は大いに盛り上がり、とても楽しい1日を過ごすことができました！</p>
<p>エンジニアのjunjunさん<br>
Vue Fesにスポンサーとして参加したのが新鮮でした。また、イベントは参加者と交流するという楽しみかたがあるんだと気づきました。私はVue Fesがきっかけでプレイドを知って入社したので、皆さんも知っていただけたら嬉しいです。またお会いましょう！</p>
<h3>おわりに</h3>
<p>Vue Fesのスタッフの皆さん、準備及びに当日の運営ありがとうございました！<br>
PLAIDはこれからもVue.jsのコミュニティグループの活動を応援しています。</p>
<p><img src="https://ik.imagekit.io/plaid/a0f082ec-3452-4958-a31d-50c506335c07/1000002292.jpg" alt="1000002292.jpg"><em>ブース撤収直後のサインボードの様子</em></p>


株式会社PLAIDはVue Fes Japan 2023にゴールドスポンサーとして参加して、スポンサーブースの運営を行いました！

Vue Fes Japan 2023にゴールドスポンサーとして参加しました！

KARTE 管理画面のパフォーマンスの監視をするにあたって考えたことや Datadog の活用のポイント、改善で取り組んだことについて紹介します。

Datadog を使った KARTE 管理画面パフォーマンス改善の取り組み

<p>こんにちは、プレイドの @makinoy です。<br>
久しぶりのBlog投稿です。書こうとして止めていた記事はひとまず置いといて今回新しく一つ記事を書くことにしました。<br>
テーマはNapa.jsを使ってJavaScriptでmulti-threadingをやってみる、です。</p>
<h4>背景</h4>
<p>フロントエンドからバックエンドまで含めて考えると、KARTEのコードの大部分はJavaScriptで書かれています。その理由の大半は、特にフロントエンドよりの話が多く、Angular.js, React.js, Vue.jsに代表されるWebフレームワークの著しい発展や、V8のパフォーマンスの進化、Node.jsやNPMなどその周辺のモジュールのエコシステムの充実が大きいと思います。</p>
<p>KARTE的には、スキーマレスな構造データを扱えることが特徴の一つなので、その周辺の操作に関しては動的言語が適しているというポイントもあります。それに、加えアーキテクチャ的な特徴から、解析処理とWeb上でのアクションがワンセットになっているということもあり、バックエンドでもフロントエンド実行されるデータの中身を評価する必要があったりします。そういう理由から、かなりCPUインテンシブな処理をJavaScriptで書き、その上で動しているの多いのが特徴です。（一部のコードはJavaやPythonを使っています。）</p>
<p>バックエンドのコードはNode.jsを使ってJavaScriptを実行しています。Node.jsは1 workerに対して1プロセスを割り当て、1CPUでイベントループを回すことによって処理します。(詳しくはこちら <a href="https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/">https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/</a>) I/Oインテンシブな処理が多いWebサーバーなどの場合、workerに対してスレッド割り当てるよりは、I/O待ちのプロセスに新規リクエストを処理させることで、コンテクストスイッチが少なくて高速です。</p>
<p>ですが、KARTEのように、Webのリクエスト処理中に解析処理も行うアプリケーションにとってみると、1 worker - 1 CPUの制約が少々ボトルネックになってくるという課題があります。基本的には、Node.jsのworkerを増やせばスループット的には問題ないと思います。ただ、KARTEの<strong>0.x秒で解析処理を終わらせリクエストを処理する</strong>ということを考えると、安定的に低レスポンスで処理しなればなりません。そうすると、どこかのCPU処理がたまたま多くリソースを使うと、その処理の影響が同じworkerの処理にも影響が出てしまいます。これを避けるには、自分でCPU処理を分割する、スレッドを使ってOSのスケジューラーに任せるなどの必要があります。あらかじめ自分でCPU処理を分割するのは大変なので、スレッドを使う方が楽です。ですがNode.js上では、JavaScriptのプログラムからスレッドを使うことはできません。</p>
<p>結構悩んでいる問題なので、背景がちょっと長くなってしまいました…<br>
つまり、JavaScript(Node.js)でスレッドが必要となるポイントは</p>
<ol>
<li>JavaScript便利</li>
<li>Node.jsとNPMが便利</li>
<li>でもNode.jsは基本的にI/Oインテンシブな処理に向いてる</li>
<li>CPUインテンシブな処理を効率的にしたいのでスレッドを使いたい</li>
</ol>
<p>という感じでしょうか。</p>
<p>そんな中、マイクロソフトが、CPUインテンシブな処理をJavaScriptでmulti-threadingを使って実現する仕組みであるNapa.js (<a href="https://github.com/Microsoft/napajs">https://github.com/Microsoft/napajs</a>) を作ったみたいなので、調べてみました。なぜ名前がNapaなのかは調べてません。Napa valleryのNapa? Nodeっぽいから？</p>
<h4>モチベーション</h4>
<p>Napa.jsも同様にJavaScriptの柔軟さとNode.jsがバックエンドとして使っているV8のパフォーマンスが高い点に着目して、さらにC++のハイパフォーマンス要素が融合すれば次の段階に進化できることを目指して作られてます。開発者が、C++とJavaScriptの利点をダイナミックにバランスをとっていけることを目指していて、例えば最初はJavaScriptで始め、固まってきたらC++に移していくようなことが気軽にできるになることを目指しています。</p>
<p>開発者のDaiyi Pengは4つのポイントの実現が重要だと言ってます。</p>
<ol>
<li>アルゴリズム上で素早くやり取り(反復)ができる。</li>
<li>マルチコアの利点を活かす</li>
<li>Workerが構造データを共有メモリでシェア</li>
<li>スレッド間の通信コストを最小にして可能な限り粒度が細かい並列処理を行う</li>
</ol>
<p>これを現時点でNode.jsで実現しようとすると、JavaScriptのasync関数としてC++のコードを使えるようにするか、Node.jsが持つclusterモジュールを使うかです。一つ目は、1を満たせず。二つ目は、3を満たせません。プロセスが別れてしまうと、データを受け渡すのにヒープメモリを使うことができないので、大変です。clusterモジュールを使う場合は、プロセス間通信を使ってデータをやり取りする必要があるので、worker間のデータのやり取りにコストがかかります。</p>
<h4>概要</h4>
<p>Napa.jsの設計概念と構成要素を紹介します。</p>
<h5>ゾーン (Zone)</h5>
<p>すべてのマルチスレッドワーカーは、ポリシー定義したりや実際にJavaScriptを実行するゾーン (zone)と呼ばれるものに属します。１プロセスに対して、複数のJavaScriptワーカーで構成されたゾーンが複数紐付きます。</p>
<p>ゾーンの中ではワーカーは同じコードをロードし、同じ<code>broadcast</code>や<code>execute</code>リクエスト（後で説明）を受け取り処理します。ゾーン内の一つのワーカーに対して選択的にリクエストを出すことはできません。一方で、異なるゾーンのワーカーどうしは非対称的です。アプリケーションは、複数のゾーンを異なるポリシーや目的のワークロードのために使い分けます。</p>
<h6>Napa zoneとNode zone</h6>
<p>ゾーンには2タイプあります。<strong>Napa zone</strong>と<strong>Node zone</strong>の二つです。Napa zoneは、切り離されたV8上のNapa.jsが管理するJavaScriptワーカーで構成されるゾーンです。Napa zoneではNode.jsのAPIが制限されています。Node zoneは、Node.jsのイベントループ上の仮想のゾーンで、Node.jsのAPIが全て使えます。Napa zoneは重いタスクをこなし、一方でNode zoneはIO処理やNode.jsのAPIを利用する、という形で互いに補完し合います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4280fa81-7c8f-4669-ab22-84e1f080a678/a.png" alt="a.png (37.6 kB)"></p>
<h5>BroadcastとExecute</h5>
<p>ゾーン上ではBroadcastとExecuteという二つのオペレーションを実行できます。</p>
<p>Broadcastはすべてのワーカーの状態を変更するコードを走らせます。その実行が成功したか失敗したかをPromise経由で受け取ることができます。起動やあらかじめキャッシュを作っておくなどするときに使います。</p>
<p>Executeはワーカーの状態を変更しないでコードを走らせます。実際にタスクを実行するときはこちらを使用し、Promise経由で計算結果を受け取ることができます。</p>
<h5>オブジェクト転送</h5>
<p>V8は、複数の分離したメモリ空間でJavaScriptを走らせるように作られていません。なので、ヒープメモリは、それぞれで管理する必要があり、値を別のV8に渡すには、シリアライズ/デシリアライズ(marshall/unmarshall)する必要があります。なので、オブジェクトのペイロードのサイズや複雑性は、通信効率に大きな影響を与えます。</p>
<h6>Transportable型</h6>
<p>Transportable（トランスポート可能な）な型は、他のV8に渡すことができ、ワーカー間で透過的なJavaScriptの型です。broadcastやexecuteの引数として渡すことができ、ワーカー間の共有オブジェクトにset/getで渡すこともできます。</p>
<p>Transportable型は、1. JavaScriptのプリミティブ、2.Transportableインタフェースを実装したオブジェクト(Typescript)、3.これらのコンポジットでできているArrayとオブジェクト、4. undefinedです。</p>
<h5>ワーカー間ストレージ</h5>
<p>Store APIはJavaScriptのワーカー間でtransportableな型を共有するために必要なAPIです。<code>store.set</code>するとそのプロセスのヒープにJSONでシリアライズされ保存され、すべてのスレッドは<code>store.get</code>でシリアライズして受け取ることができます。</p>
<p>参照カウントされているので自動でGCされるようです。Worker間でメモリがシェアされたとしても、GCがある言語上でGCがない部分でデータを自分で管理しようとすると大変です。</p>
<h5>メモリ管理</h5>
<p>APIとしてnapajsメモリを触れるものも用意してあるようです。ポインタを表す<code>Handle</code>、 Native Objectをワーカー間でシェアできる<code>Shareable</code>、メモリを確保する<code>Allocator</code>が用意されいるようですが、詳細に関してはあまり記述が無いです。</p>
<h5>C++モジュール</h5>
<p>Node.jsと同様にC++を使ったモジュールを作成できるようになるみたいですが、APIの詳細はまだ固まっていないようです。</p>
<h4>試してみる</h4>
<p>では実際に試してみましょう。</p>
<h5>インストール</h5>
<pre><code class="language-shell">npm install napajs
</code></pre>
<h5>実行</h5>
<h6>ゾーンの作成</h6>
<pre><code class="language-js">const napajs = require('napajs');
const zone = napajs.zone.create('simple-zone', {wokers: 8});
</code></pre>
<h6>Nodeゾーンにアクセス</h6>
<pre><code class="language-js">const node_zone = napajs.zone.node;
</code></pre>
<h6>boradcastしてexecute</h6>
<pre><code class="language-js">function f() {
  console.log('hi');
}
// fを定義
zone.broadcast(f.toString());
// 定義したfを実行
zone.execute(() =&gt; { f() });
// &gt; hi
</code></pre>
<h6>transportableかチェック</h6>
<pre><code class="language-js">napajs.transport.isTransportable(undefined)
// &gt; true
// napajs.transport.isTransportable(null)
// TypeError. bug
napajs.transport.isTransportable({a:1})
// &gt; true
napajs.transport.isTransportable({a:1, b:/regexp/})
// &gt; false
</code></pre>
<h6>marshall / unmarshall</h6>
<pre><code class="language-js">var jsonPayload = transport.marshall([1, 'string'], context);
console.log(jsonPayload);
// [1,&quot;string&quot;]
napajs.transport.unmarshall(jsonPayload, context);
// &gt; [ 1, 'string' ]
</code></pre>
<h6>store</h6>
<pre><code class="language-js">var zone = napajs.zone.create('zone1');
var store = napajs.store.create('store1');

store.set('key1', { 
    a: 1, 
};

zone.execute(() =&gt; {
    var store = global.napa.store.get('store1'); // globalにnapaが定義されている
    console.log(JSON.stringify(store.get('key1')));
});
// &gt; {&quot;a&quot;;1}
</code></pre>
<h5>フィボナッチ数列を計算する</h5>
<p>並列計算の例ではみんな大好きフィボナッチ</p>
<pre><code class="language-js">var napa = require(&quot;napajs&quot;);
var zone = napa.zone.create('zone', { workers: 4 });

function fibonacci(n) {
    if (n &lt;= 1) {
        return n;
    }

    var p1 = zone.execute(&quot;&quot;, &quot;fibonacci&quot;, [n - 1]);
    var p2 = zone.execute(&quot;&quot;, &quot;fibonacci&quot;, [n - 2]);

    return Promise.all([p1, p2]).then(([result1, result2]) =&gt; {
        return result1.value + result2.value;
    });
}

function run(n) {
    var start = Date.now();

    return zone.execute('', &quot;fibonacci&quot;, [n])
        .then(result =&gt; {
            console.log(n, result.value, Date.now() - start);
            return result.value;
        });
}

// 初期化
zone.broadcast(' \
    var napa = require(&quot;napajs&quot;); \
    var zone = napa.zone.get(&quot;zone&quot;); \
');
zone.broadcast(fibonacci.toString());

// 実行
run(10)
.then(() =&gt; run(11))
.then(() =&gt; run(12))
.then(() =&gt; run(13))
.then(() =&gt; run(14))
.then(() =&gt; run(15))
.then(() =&gt; run(16))
.then(() =&gt; run(17))
.then(() =&gt; run(18))
.then(() =&gt; run(19))
.then(() =&gt; run(20))
.then(() =&gt; run(21))
.then(() =&gt; run(22))
</code></pre>
<p>上のコードをworkers:1, 2, 4で計算したら、手元のMac( 2.5 GHz Intel Core i7 4 cores)フィボナッチ数22がそれぞれ、3.7 sec, 1.8 sec, 1.3 sec程度で計算ができ、CPUコアを有効に使えてるることがわかりました。かなり粒度が細かい並列実行ですが、オーバーヘッドも少なさそうです。</p>
<h4>まとめ</h4>
<p>JavaScriptでmulti-threadingするNapa.jsについて、それが(PLAIDにとっても)必要となる背景から、その概要について、まとめてみました。まだ、bugがあったりして生まれたて感があるようですが、threadを使った並列化コードをシンプルに書くことができて非常に使えそうな印象があります。このような技術を使って、データ解析のようなCPUインテンシブな処理もJavaScriptでメンテナンスできるようになると嬉しいですね。</p>
<h4>参考</h4>
<p><a href="https://github.com/Microsoft/napajs/wiki">https://github.com/Microsoft/napajs/wiki</a><br>
<a href="https://github.com/Microsoft/napajs/wiki/introduction">https://github.com/Microsoft/napajs/wiki/introduction</a><br>
<a href="https://github.com/Microsoft/napajs/wiki/why-napa.js">https://github.com/Microsoft/napajs/wiki/why-napa.js</a><br>
<a href="https://github.com/Microsoft/napajs/tree/master/examples/tutorial/recursive-fibonacci">https://github.com/Microsoft/napajs/tree/master/examples/tutorial/recursive-fibonacci</a><br>
<a href="https://www.linkedin.com/pulse/napajs-multi-threaded-javascript-runtime-daiyi-peng/">https://www.linkedin.com/pulse/napajs-multi-threaded-javascript-runtime-daiyi-peng/</a></p>
<h4>最後に</h4>
<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>


今回の記事のテーマはNapa.jsを使ってJavaScriptでmulti-threadingをやってみる、です。

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する | PLAID engineer blog

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する

<p>こんにちは。エンジニアの@elcih17です。<br>
<a href="/webdb-forum-2016/">この記事</a>を書いた頃はインターンでしたが、現在は新卒エンジニアとして日々奮闘しています。</p>
<p>最近、APIの設計に関することを調べていたら「GraphQL」という言葉をよく見かけました。<br>
API用の技術として注目されているそうで、<strong>REST APIの次のパラダイムだ</strong>という意見もあるようです。</p>
<p>どんな技術なのかとても気になり<a href="https://www.howtographql.com/">HOW TO GRAPHQL</a>のチュートリアルと簡単な実装をしてみたら、なんとなくGraphQLのことがわかったので書いてみます。</p>
<p><strong>実装例</strong></p>
<ul>
<li>バックエンド (express-graphql) <a href="https://github.com/elcih17/graphql-example/tree/master/graphql-server">graphql-server</a></li>
<li>フロントエンド (vue-apollo) <a href="https://github.com/elcih17/graphql-example/tree/master/vue-apollo">vue-apollo-example</a></li>
</ul>
<h2><a href="http://graphql.org/">GraphQL</a> とは</h2>
<ul>
<li>API用のクエリ言語</li>
</ul>
<h2>特徴</h2>
<ul>
<li>シングルエンドポイント</li>
<li><strong>複数のリソース</strong>の欲しいデータを<strong>1リクエスト</strong>で取得できる</li>
<li>スキーマ定義と型システム</li>
</ul>
<h2>機能</h2>
<h3>Query</h3>
<p>RESTにおけるGET</p>
<p><strong>idが&quot;1&quot;のユーザーの名前と年齢を取得する</strong>GraphQLは次のように書けます。</p>
<pre><code class="language-graphql">query {
  user(id:&quot;1&quot;) {
    name
    age
  }
}
</code></pre>
<p>response</p>
<pre><code class="language-json">{
  &quot;data&quot;: {
    &quot;user&quot;: {
      &quot;name&quot;: &quot;elcih17&quot;,
      &quot;age&quot;: 22
    }
  }
}
</code></pre>
<h3>Mutation</h3>
<p>RESTにおけるPOST、PUT、DELETE</p>
<p><strong>新規ユーザーを作成する</strong>GraphQLは次のように書けます。</p>
<pre><code class="language-graphql">mutation {
  createUser(id: &quot;2&quot;, name: &quot;KARTE&quot;, age:2) {
    name
    age
  }
}
</code></pre>
<p>response</p>
<pre><code class="language-json">{
  &quot;data&quot;: {
    &quot;user&quot;: {
      &quot;id&quot;: &quot;2&quot;,
      &quot;name&quot;: &quot;KARTE&quot;,
      &quot;age&quot;: 2
    }
  }
}
</code></pre>
<h3>Subscription</h3>
<p>QueryとMutationの実行をsubscribeできる</p>
<p>試してないので詳しくはわかりませんが、データの更新を受け取って何かしたいときに使えそうです。</p>
<h2>GraphQLの何が良いのか</h2>
<ul>
<li>不要なデータの取得と無駄なリクエストを防げる</li>
<li>スキーマと型定義によってAPIが提供する機能が明確になる</li>
<li><a href="https://github.com/graphql/graphiql">GraphiQL</a>が便利</li>
</ul>
<h3>不要なデータの取得と無駄なリクエストを防げる</h3>
<p><strong>複数のリソースの欲しいデータを1リクエストで取得できる</strong> ので無駄が無くなります。<br>
例えば、<strong>あるユーザーの名前と投稿記事タイトルと記事についたコメントを取得する</strong>ケースを考えてみます。</p>
<p><strong>RESTの場合</strong></p>
<ol>
<li><code>GET /users/:id</code></li>
<li><code>GET /users/:id/posts</code></li>
<li><code>GET /posts/:id/comments</code></li>
<li>取得したデータからそれぞれ名前、記事のタイトル、コメントを抽出します</li>
</ol>
<p><strong>GraphQLの場合</strong></p>
<ol>
<li><code>/graphql</code>に対し下記のようなクエリをリクエストします</li>
</ol>
<p>必要なデータのみ取得しているのでデータを抽出する必要はありません</p>
<pre><code class="language-graphql">query {
  user(id: &quot;1&quot;) {
    name
    posts {
      title
        comments {
        content
      }
    }
  }
}
</code></pre>
<h3>スキーマと型定義によってAPIが提供する機能が明確になる</h3>
<ul>
<li>入出力と型を定義することによって何が出来るかかが分かりやすい</li>
<li>後述するGraphiQLで見ることが出来るAPIドキュメントはスキーマ定義から自動生成される</li>
</ul>
<h3><a href="https://github.com/graphql/graphiql">GraphiQL</a>が便利</h3>
<ul>
<li>GraphQLのIDE</li>
<li>APIドキュメントの閲覧とクエリの実行ができる</li>
<li>デバッグがしやすい
<ul>
<li>クエリをサクサク試せる</li>
<li>エラーメッセージがわかりやすい</li>
</ul>
</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/34e38b86-2c72-4147-ad5b-1217475aeb62/----------2017-08-28-23.37.56.png" alt=""></p>
<h2>GraphQLサーバーの例(express-graphql)</h2>
<p>Query、Mutationの機能紹介で例示したクエリを実行可能にするための実装はこのようになります</p>
<p><strong>GraphQLスキーマの定義 (GraphQLの入出力と型定義)</strong></p>
<ul>
<li><code>!</code>は<code>required</code></li>
</ul>
<pre><code class="language-graphql">type Query {
  user(id: String!): User! // relation
}
type Mutation {
  createUser(id: String!, name: String!, age: Int!): User // relation
}
type User {
  id: String!
  name: String!
  age: Int!
}
</code></pre>
<p><strong>リゾルバ関数の実装 (GraphQLとバックエンド処理のマッピング)</strong></p>
<pre><code class="language-js">const users = [
  {
    id: '1',
    name: 'elcih17',
    age: 22
  }
]
const resolvers = {
  Query: {
    user: (root, {id}) =&gt; {
      return users.find(user =&gt; user.id === id)
    }
  },
  Mutation: {
    createUser: (root, args) =&gt; {
      const {id, name, age} = args
      const newUser = {id, name, age}
      users.push(newUser)
      return newUser
    }
  }
};
</code></pre>
<h4>GraphQLオブジェクトとrelation(関連づけ)を使う</h4>
<p>標準のオブジェクトタイプ(<code>Query</code> 、<code>Mutation</code>、<code>Subscription</code>)以外にも独自のオブジェクトを定義できます。<br>
また、定義したオブジェクト同士のrelationが可能です。</p>
<p><strong>スキーマ</strong></p>
<pre><code class="language-graphql">type User {
  name: String!
  posts: [Post]
}
type Post {
   author: User!
   title: String!
}
</code></pre>
<p>relationを使えば次のようなクエリを受け取った際にデータを構築するのが簡単になります。</p>
<pre><code class="language-graphql">query {
  user(id: &quot;1&quot;) {
    posts {
      title
    }
  }
}
</code></pre>
<p><strong>リゾルバ (データの構築)</strong></p>
<pre><code class="language-js">Query: {
 user: (root, args) =&gt; {
    const {id} = args
    return users.find(user =&gt; user.id === id)
 }
},
User: {
  posts: (author) =&gt; {
    const {id} = author
    return posts.filter(post =&gt; post.author_id === id)
  }
}
</code></pre>
<p>GraphQLクエリの実行の流れについては<a href="https://dev-blog.apollodata.com/graphql-explained-5844742f195e">この記事</a>が分かりやすいです。</p>
<p><a href="https://github.com/elcih17/graphql-example/tree/master/graphql-server">実装例</a>ではMongoDBに接続して実装してみました。</p>
<p><strong>所感</strong></p>
<ul>
<li>GraphiQLのおかげでデバッグがしやすくて良い</li>
<li>GraphQLのスキーマ定義とDBのスキーマ定義が二重管理になって面倒
<ul>
<li>DBのスキーマからGraphQLスキーマを生成するようなライブラリが出てくれば楽になるかも</li>
</ul>
</li>
</ul>
<h2>フロントエンドGraphQL</h2>
<p>現在、GraphQLを扱うためのClientに <a href="http://dev.apollodata.com/">Apollo</a> と <a href="https://facebook.github.io/relay/">Relay</a> があります。</p>
<p>RelayはReact用に構築されていてApolloはそのほかのフレームワークにも対応しているようです。<br>
React + Apolloという組み合わせもあるので、Reactを使っている人はRelayとApolloを比べてみても面白いかもしれません。</p>
<p>今回は<a href="https://github.com/Akryum/vue-apollo">vue-apollo</a>を使うためにApolloを使用してみました。</p>
<p>一部実装例を載せておきます。</p>
<p>src/main.js</p>
<pre><code class="language-js">import 'isomorphic-fetch'

import Vue from 'vue'
import {ApolloClient, createNetworkInterface} from 'apollo-client'
import VueApollo from 'vue-apollo'
import App from './App.vue'

const uri = 'http://localhost:3000/graphql'
const networkInterface = createNetworkInterface({
  uri,
  transportBatching: true,
})

Vue.use(VueApollo)

const apolloClient = new ApolloClient({networkInterface})
const apolloProvider = new VueApollo({
  defaultClient: apolloClient,
})

new Vue({
  el: '#app',
  apolloProvider,
  render: h =&gt; h(App),
})
</code></pre>
<p>src/App.vue</p>
<pre><code class="language-html">&lt;!-- template --&gt;

&lt;div id=&quot;app&quot;&gt;
  &lt;h1&gt; Vue Apollo Example &lt;/h1&gt;
  &lt;p&gt;{{hello}}&lt;/p&gt;

  &lt;label&gt;name&lt;/label&gt;
  &lt;input type=&quot;text&quot; v-model=&quot;userName&quot;&gt;

  &lt;label&gt;age&lt;/label&gt;
  &lt;input type=&quot;number&quot; v-model=&quot;userAge&quot;&gt;

  &lt;a href=&quot;#&quot; @click=&quot;createUser&quot;&gt;createUser&lt;/a&gt;

  &lt;div v-if=&quot;createdUser&quot;&gt;
    &lt;p&gt;User created!&lt;/p&gt;
    &lt;p&gt;name: {{createdUser.name}}&lt;/p&gt;
    &lt;p&gt;age: {{createdUser.age}}&lt;/p&gt;
  &lt;/div&gt;
&lt;/div&gt;
</code></pre>
<pre><code class="language-js">// script

import gql from 'graphql-tag';

const helloGQL = gql`
  query {
    hello
  }
`;
const createUserGQL = gql`
  mutation ($userName: String!, $userAge: Int!){
    createUser(name: $userName, age: $userAge) {
      _id
      name
      age
    }
  }
`
export default {
  name: 'app',
  data() {
    return {
      hello: '',
      userName: '',
      userAge: '',
      createdUser: null
    };
  },
  apollo: {
    hello: {
      query: helloGQL,
    }
  },
  methods: {
    createUser() {
      this.$apollo.mutate({
        mutation: createUserGQL,
        variables: {
          userName: this.userName,
          userAge: this.userAge
        }
      }).then(res =&gt; {
        this.createdUser = res.data.createUser
      }).catch(err =&gt; {
        console.error(err);
      })
    }
  }
};
</code></pre>
<p>詳細は<a href="https://github.com/elcih17/graphql-example/tree/master/vue-apollo">実装例</a>をご覧ください。</p>
<p><strong>所感</strong></p>
<ul>
<li>欲しいデータだけを1リクエストで取得できるのは確かに良さそう
<ul>
<li>しかし、rootのデータを取得してロジックで整形みたいなことをするとRESTとあまり変わらない</li>
<li>不要なデータ取得と無駄なリクエストを実際に減らせるかは使用者次第という感じ</li>
</ul>
</li>
<li>エンドポイント × GraphQLクエリの分だけ管理が必要なので複雑になってくるとツラそう</li>
</ul>
<h2>プロダクションで使えるか？</h2>
<p>現在プロダクション環境でGraphQL APIを運用しているサービスはGithub、Coursera、Twitterなどがあるようです。<br>
Githubの<a href="https://developer.github.com/v4/">GraphQL API v4</a>を見る限り、運用の仕組みを作れば十分使えそうな気がします。</p>
<p>プロダクションで運用・提供するに当たって考慮する必要がありそうなこと</p>
<ul>
<li>バックエンド
<ul>
<li>クエリ(スキーマ)のライフサイクル管理
<ul>
<li>deprecatedフィールドなど</li>
</ul>
</li>
<li>クエリのキャッシュ管理
<ul>
<li><a href="http://graphql.org/learn/caching/">フィールドにGlobal Unique IDを持たせる方法など</a>があるようです</li>
</ul>
</li>
<li>セキュリティ
<ul>
<li>巨大なクエリ、複雑なクエリへの対策
<ul>
<li>タイムアウト処理</li>
<li>クエリの実行回数制限</li>
<li>1クエリのfield数制限</li>
<li>1クエリのネスト(深さ)制限</li>
</ul>
</li>
<li>Githubの<a href="(https://developer.github.com/v4/guides/resource-limitations/)">Rate limits</a>が参考になります</li>
</ul>
</li>
</ul>
</li>
<li>フロントエンド
<ul>
<li>クエリが自由にかけて属人性が高い</li>
<li>規約が必要になることもあるかも？</li>
</ul>
</li>
</ul>
<h2>まとめ</h2>
<ul>
<li>クエリが直感的に書ける
<ul>
<li>必要なデータだけをリクエストできるので分かりやすい</li>
<li>自由に書けるので複雑なクエリをリクエストされるリスクもある</li>
</ul>
</li>
<li>GraphiQLが便利</li>
<li>不要なデータ取得、無駄なリクエストを減らせるのは大きなメリット</li>
<li>プロダクションで運用する際にはセキュリティ対策は必須</li>
</ul>
<p>以上で説明を終わります。</p>
<p>GraphQLについて少しはわかっていただけたでしょうか？<br>
今回紹介できなかった機能を使えばもっと色々とできて面白そうなので興味のある方はぜひ試してみてください。</p>
<h2>最後に</h2>
<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>
<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>


API用の技術として注目されている「GraphQL」をexpress + Vueで実装して試してみました！


express-graphql + vue-apollo で GraphQLを試してみた | PLAID engineer blog

express-graphql + vue-apollo で GraphQLを試してみた

<p>こんにちは、お久しぶりです、プレイドの @makinoy です。ブログ記事を書こう書こうと思い、2,3記事下書きを残しながらも、最後まで書き終えられていません。</p>
<p>そんな中、今日からPLAIDエンジニア陣でCodeZineで連載をはじめまして、ブログを書かずに連載の第一回の記事を書いてしまいました。そのうち、またブログの記事を書きたいと思います。</p>
<p>今回の連載は、**”大規模解析サービスを支えるGCP活用事例”**というタイトルで、GCPの利用例を中心に大量のデータをリアルタイムに捌くKARTEの裏側の話が中心です。</p>
<p>第一回の今回は、GCPがどういう役割を果たしているかという全体的な話を**”大規模データ解析サービス実現のために、Google Cloud Platformが果たす役割”**というタイトルで書きました。いろんな人に読んでもらうために、少々GCPの広告のようなタイトルになってますが、中身は前提知識そこまでなく8割ぐらい読める内容を書いたつもりです。ぜひ、読んでいただければと思います。記事はこちら。</p>
<p><a href="http://codezine.jp/article/detail/10350">大規模データ解析サービス実現のために、Google Cloud Platformが果たす役割</a></p>
<p>次回以降も、なかなか良い感じに濃い内容になりそうなので、ぜひ読み続けていただければと思います。</p>


今回の連載は、”大規模解析サービスを支えるGCP活用事例”というタイトルで、GCPの利用例を中心に大量のデータをリアルタイムに捌くKARTEの裏側...

CodeZineで、解析サービスの裏側とGCPについて連載はじめました

<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>バルマーピーク、<strong>もし本当だったらアツくないすか？</strong></p>
<p>このグラフ（と呼んでいいかわかりませんが）では、ピーク時には平常時の倍ほどのプログラミング能力になると書かれています。</p>
<p>生産性の追求はエンジニアの至上命題です。「お酒を飲みながら仕事なんて！」という固定概念を取り払い、試せるものは試すのがエンジニアとしての矜持ではないでしょうか。</p>
<p>日本の労働生産性は先進国で最低と言われています。さらにIT分野では諸外国に遅れを取っていると言わざるを得ません。<br>
もしバルマーピークの有用性が認められれば、日本のエンジニア達は酒を片手に以前とは比較にならない速度でアウトプットを出し続けることでしょう。ということは、ITはいまや日本の主要産業ですから、国内の生産性も一気に上昇します。ひいては日本のGDP増加、世界でのプレゼンスを再び得ることができるに違いありません。<strong>絶対成功させよう東京オリンピック！！</strong></p>
<p>ただ__「酒を飲みながら仕事したい」__という本音を隠すためだけに話を無理矢理国家レベルまで上げました。<br>
うだうだ言ってないで始めましょう。</p>
<h1>ルール</h1>
<h2>プログラミング能力の計測</h2>
<p>生産性を比べるという点からすると弊社プロダクトのコードを使うのが一番ですが、酒を飲みながらプロダクションにコミットしていることが露見すると__ワンチャン解雇__まであるので、ここは控えます。</p>
<p>「コーディング能力とは何か」を考え出すとキリがないため、いったんここは粒度の自由さとコーディング能力の客観的指標を兼ね備えている、<a href="https://paiza.jp/">paiza</a>を使って結果を比べてみることにします。</p>
<p>時間を計測してくれたり、テストケースによる採点も行ってくれるため、飲酒時・素面時の客観的比較が可能です。<br>
paizaスキルチェックのレベルですが、B~Cあたりの難易度で比較するのが普段の業務に近そうなので、ここを使います。<br>
A以上になると数学的な設計能力も問われ、酔っ払った状態では明らかに不利そうなので、今回は避けます。<s>普通に難しくて心が折れたというのもある</s></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>富田流のそれは左鉤突きから始まる、それとは即ちーーー__ピピピッ__<br><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><b>うーん・・・・</b></p>
<p>平均に対する速さでいうと微妙に早くはなっていますが、先述のグラフほどの生産性向上は見られませんでした。<br><br>
また、飲んだ方では1度凡ミス（採点時後すぐ原因箇所は判明）によりテストケース採点で60点を出しており、注意力の低下が見られます。<br>
<br>ちなみに後々両者のコードを読み返してみて読みやすさ等を比較してみましたが、そこまで違いはありませんでした。<s>というか、提出時間を最優先した結果有り体に言って__両方共クソコード__でした。</s></p>
<p>結局「バルマーピークはあります！」と言えるほどの結果にならず残念です。<br><br>
とはいえ、そもそも「酒なんか飲んだら仕事にならない」という固定観念からすると、速度の向上が見られている時点で有意義な結果になったと言ってもいいのではないでしょうか。</p>
<p>読者諸兄におかれましては、是非この記事を片手にチームのマネージャーに飲酒コーディングの許可を直訴してみてはいかがでしょうか。<strong>私は責任を一切負いません。</strong></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での検証を行った際の進め方について説明していきます。インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気

Engineer Blog

Recent Article

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する

express-graphql + vue-apollo で GraphQLを試してみた

CodeZineで、解析サービスの裏側とGCPについて連載はじめました

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

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

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

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

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

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

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

Archives

Writers

Recent Article

MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する

express-graphql + vue-apollo で GraphQLを試してみた

CodeZineで、解析サービスの裏側とGCPについて連載はじめました

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

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

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

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

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

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

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

Archives

Writers

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