<p>こんにちは、SREの @ikemonnです。<br>
先日開催された <a href="https://builderscon.io/tokyo/2018/">builderscon tokyo 2018</a>で、<a href="https://karte.io/">KARTE</a>にSpinnakerを本番導入して得られた知見について発表させていただきました！</p>
<p>「<a href="https://www.spinnaker.io/">Spinnaker</a>」とは、Netflixが開発したマルチクラウド環境へのCD(Continuous Delivery)ツールです。<br>
利用企業としては、<a href="https://www.waze.com/">Waze</a>や<a href="https://www.mercari.com/jp/">mercari</a>等が有名です。</p>
<ul>
<li>Waze: <a href="/google-cloud-next-18-spinnaker/">Google Cloud Next '18でWazeのSpinnakerのセッションを聞いてきました!</a></li>
<li>mercari: <a href="https://tech.mercari.com/entry/2017/08/21/092743">SpinnakerによるContinuous Delivery</a></li>
</ul>
<p>KARTEでも2018年の1月からSpinnakerを本番環境で導入しており、Spinnakerの<a href="https://www.spinnaker.io/community/">community page</a>にロゴを載せてもらっています！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fc6f3d32-3193-42e8-b01c-5332fdf0a732/2018-09-11_10_25_27-1.png" alt="2018-09-11_10_25_27-1"></p>
<p>スライド:<a href="https://speakerdeck.com/ikemonn/builderscon-tokyo-2018">Multi-Cloud deploy with Spinnaker</a></p>
<script async class="speakerdeck-embed" data-id="538d3911f1db4e47aa40ad3a676a8853" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<h2>概要</h2>
<p>Spinnakerの主な特徴は「Multi-Cloud」「Automated Releases」「Built-in Deployment Best Practices」です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dc6f7d76-58e8-44b0-9c91-b9f87e94f4c4/-2018-09-11-10.07.55-1.png" alt="-2018-09-11-10.07.55-1"></p>
<p>KARTEでは、SpinnakerをAWSとGCPのマルチクラウドへのデプロイで利用しています。<br>
(マルチクラウド構成についてはこちら:<a href="/devsumi-2018/">Developers Summit 2018に登壇してきました #devsumi</a>)</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0432da5b-c632-45b2-922b-70ca3ed885bf/-2018-09-11-10.20.09-1.png" alt="-2018-09-11-10.20.09-1"></p>
<p>インフラの負荷としては、秒間最大22,000events/sec、1日10億eventsくらいで、これらを支えるインフラにデプロイしても問題なく稼働しています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ed57ddbf-4de6-4fda-b61f-b2e7fb2438bb/-2018-09-11-10.19.43-1.png" alt="-2018-09-11-10.19.43-1"></p>
<p>Spinnakerは、「マルチクラウド対応」「デプロイ機能が充実」「Immutable Infraを強制する」等といった点で、マルチクラウドへのデプロイにはかなりオススメのツールです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6d614f1c-2327-4fe5-91b5-bb2fb9241cd2/-2018-09-11-10.21.13-1.png" alt="-2018-09-11-10.21.13-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a6e480ef-9b83-4b1f-b45c-c2673dda32dc/-2018-09-11-10.21.31-1.png" alt="-2018-09-11-10.21.31-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f08e5e82-12f4-4289-ae8f-3d062010db3b/-2018-09-11-10.21.46-1.png" alt="-2018-09-11-10.21.46-1"></p>
<p>しかし、Googleで検索しても運用周りの情報が少なく導入/検討しづらいなと感じていました。</p>
<p>そこで、今回の発表では「Spinnakerへの移行のきっかけ」「移行コスト」「運用してみて期待通りだった/期待と違ったこと」等の運用に関する内容を盛り込みました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ac75b9b-9553-48b4-ae9d-263ac4df0c20/-2018-09-11-10.24.09-1.png" alt="-2018-09-11-10.24.09-1"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8e99a1f6-0bf4-49cd-89aa-38583038df87/-2018-09-11-10.22.25-1.png" alt="-2018-09-11-10.22.25-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7ccc4733-3151-4df6-bc75-24cf18965a81/-2018-09-11-10.22.51-1.png" alt="-2018-09-11-10.22.51-1"></p>
<p>「期待と違っていたこと」でバグの話をしましたが、Spinnakerも徐々に安定化してきており、現状回避できないバグには遭遇していません。(v1.9)<br>
(導入当時はどうしても回避できないバグがあり、修正してPR出してました…！)</p>
<p>マルチクラウドのCDをやっていくには自信を持ってオススメできるツールなので、ぜひぜひ試してみてください！</p>
<h2>補足</h2>
<p>スライドで紹介したツールやドキュメント等のリンクです。</p>
<ul>
<li><a href="https://www.spinnaker.io/">Spinnaker</a></li>
<li><a href="https://cloudplatform.googleblog.com/2017/06/spinnaker-10-continuous-delivery.html">Spinnaker 1.0: a continuous delivery platform for cloud</a></li>
<li>カナリアデプロイ
<ul>
<li><a href="https://github.com/spinnaker/kayenta">spinnaker/kayenta</a></li>
</ul>
</li>
<li>pipelineをコードで管理する
<ul>
<li><a href="https://blog.spinnaker.io/spin-and-roer-managed-pipeline-templates-4fde2951c648">spin and roer + Managed Pipeline Templates</a></li>
<li><a href="https://github.com/spinnaker/roer">spinnaker/roer</a></li>
<li><a href="https://github.com/spinnaker/dcd-spec">spinnaker/dcd-spec</a></li>
<li><a href="https://github.com/spinnaker/spin">spinnaker/spin</a></li>
<li><a href="https://docs.google.com/document/d/17Ifm562aypjLSHnNJ02COFv_VMv3spicH-7zMYd-oXE/edit#">Spinnaker CLI Design</a></li>
</ul>
</li>
<li><a href="https://join.spinnaker.io/">SpinnnakerのSlackグループ</a></li>
</ul>
<h2>最後に</h2>
<p>リアルタイム解析を実現するCXプラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、マルチクラウド環境の大規模インフラの設計/構築/運用をしていきたい！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


先日開催された builderscon tokyo 2018でスピーカーとして登壇させていただきました！ 概要 「Spinnaker」は、Netflixが開発したマルチクラウド環境へのCDツールです。今回はSpinnakerをKARTEに導入し、半年以上運用して得られた知見についてお話しました。 

Netflix発のOSS"Spinnaker"でマルチクラウドにデプロイしている話 #builderscon

<html><head></head><body><p>エンジニアチームの mkataigi です。たまには趣向を変えて、エンジニアっぽくないコードの出てこない話を書いてみようかなと思います。以下多分に個人の見解です。</p>
<p>ベンチャーに限らず、あらゆる組織において「最良の結果」を出すことは大事です。「最良の結果」を出せない組織は、一時的には成功したとしても、いずれ「最良の結果」を出した組織に追い抜かれてしまいます。一見着実に進んでるように見えるのに、なぜか競合に差をつけられていく、イノベーションのジレンマというやつですね。</p>
<p>有名な言葉ですが『「最良」の敵は「良」である』と言う言葉があります。人間の時間は有限なので、やったほうがいい（=良）ことをやり続けてしまうと、最大の結果（=最良）を出すための時間がなくなってしまう。つまり、組織が成功し続けるためには、常に「最良の結果」にフォーカスし続けることが必要、ということです。</p>
<p>なお、参考文献は以下になります。</p>
<ul>
<li>イシューからはじめよ―知的生産の「シンプルな本質」
<ul>
<li><a href="https://www.amazon.co.jp/dp/4862760856" target="_blank" rel="noreferrer">https://www.amazon.co.jp/dp/4862760856</a></li>
</ul>
</li>
<li>仮説思考 BCG流 問題発見・解決の発想法
<ul>
<li><a href="https://www.amazon.co.jp/dp/4492555552" target="_blank" rel="noreferrer">https://www.amazon.co.jp/dp/4492555552</a></li>
</ul>
</li>
</ul>
<h1 id="解くべき課題を考える">解くべき課題を考える</h1>
<p>「最良の結果」を出すためには何をすればよいのでしょう。まず「結果を出す」ためのステップを考えて見ます。</p>
<ol>
<li>課題を設定する</li>
<li>課題を解決する</li>
</ol>
<p>このうちどちらをより優先する必要があるのでしょうか。</p>
<p>抽象的でわかりにくくなってきたので、例えば<code>大阪で友達と会う</code>という結果を得ることを考えて見ます。この場合それぞれ次のようになります。</p>
<ol>
<li>課題設定 <code>大阪へ行く</code></li>
<li>解決方法 <code>新幹線で行く</code></li>
</ol>
<p>例えば大阪へ新幹線ではなく鈍行列車で行った場合（課題設定は正しく、解決方法が間違い）はどうなるでしょう。この場合は時間はかかるもののいずれ着くし、途中で間違いに気づけば特急に乗り換えするなどリカバリーをすることもできます。逆に、新幹線に適当に乗った場合（課題設定が間違い、解決方法は正しい）はどうなるでしょう。いくらたっても大阪に着くことはないですし、どこにいるかわからずリカバリーすることも難しくなります。つまり課題設定を正しくするほうが重要ということなります。</p>
<p>エンジニア業界でよくある「顧客が本当に必要だったもの」というやつですね。課題設定が正しくないと、結果が出ないどころか、不要なものを作ってしまいメンテナンスコストだけかかるという、マイナスの効果しか得られません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c3be8e6e-0e62-437d-98ff-9738cbcc0c8c/----------2018-08-23-17.29.13.jpg" alt="顧客が本当に必要だったもの"><br>
<a href="http://www.projectcartoon.com/" target="_blank" rel="noreferrer">http://www.projectcartoon.com/</a></p>
<h1 id="最良の課題の条件">最良の課題の条件</h1>
<p>では「最良の結果を出すための課題」を発見するにはどうすれば良いのでしょう。見つける方法を考える前に、まず、自分たちがどんなものを探すのかを明確にするために、どんな課題が最良の課題なのはっきりさせましょう。以下の３点がポイントかなと思います。</p>
<ul>
<li>その課題が解決されることで、将来に大きな影響を与える</li>
</ul>
<p>まず一つ目が、その課題が解決されると将来の展開が大きく変わるもの、になります。その課題が解決されることで別の課題をそもそも解く必要がなくなる課題です。</p>
<pre><code class="language-plaintext hljs">「運転の自動化」という課題が解決されたら、
「大阪への移動経路を探す」「電車内で寝過ごさないようにする」などの課題が、そもそも課題ですら無くなる
</code></pre>
<ul>
<li>その課題は自分だけが解決できる</li>
</ul>
<p>次がなぜ自分がその課題に取り組むか、の部分です。自分以外の人には解決できないけど自分にだけ解決できる課題というのは、自分が解決しないとずっと課題のまま残り続けるため、より解決する重要度が高い問題となります。組織としてもそれがいわゆる競合優位性に繋がるので重要です。</p>
<pre><code class="language-plaintext hljs">「大阪へ直行する路線を作ってしまう」ことができれば、
大阪へ行くための方法を探す必要は無くなる
</code></pre>
<p>（自分にはできないが、世の中にはできる人がいるかもしれない！）</p>
<ul>
<li>その課題に答える方法がある</li>
</ul>
<p>そして当たり前ですが、課題の答えを出せる、出す方法を思いつけることが重要です。結果を出すという観点から考えるとアウトプットが無いと無意味です。</p>
<pre><code class="language-plaintext hljs">「ワープ」する機械を開発できれば大阪へ行くための方法を探す必要はないが、
現代の技術ではできる可能性は非常に薄い
</code></pre>
<h1 id="最良の課題を見つける方法">最良の課題を見つける方法</h1>
<p>最良の課題をテクニカルに見つける方法を、、、といきたいのですが、課題の定義からもわかる通り、誰にでも同じ方法で見つけられる、というものでは無いようです。とはいえ、それで諦めるのではなく、見つける可能性を高める方法を考えてみたいと思います。</p>
<p>一般的な方法として、最良の課題を探り当てられなくても、「これは良い課題かな？」というところから課題をブラッシュアップして最良に近づけていく思考法を考えてみます。状況によらずに常に成り立つ課題は、将来への影響が大きい可能性が高いと言うことはできそうです。</p>
<ul>
<li>極端な状態を考える</li>
</ul>
<p>状況を極端にしてみることで、状況が変わっても変わらない課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext hljs">毎日大阪にいく場合はどうすればいいか
お金を無限に持っている場合にはどうするか
逆にお金がない場合はどうするか
</code></pre>
<ul>
<li>別の人の視点から考える</li>
</ul>
<p>複数の人の視点の重ね合わせることで、誰から見ても重要な、課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext hljs">老人が大阪へいきたい場合はどうすればいいか
外国人ならどうするか
</code></pre>
<ul>
<li>抽象化したり具体化したりする</li>
</ul>
<p>課題を抽象的にしてみたり、具体的にしてみたりすることで、普遍的な課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext hljs">抽象的にして別の場所に時間通りに着くにはどうするか
具体的にして大阪に15時に着くにはどうするか
</code></pre>
<h1 id="さいごに">さいごに</h1>
<p>以上、最良の課題を見つけるための方法について見てきました。プレイドでも「データによって人の価値を最大化する」ために、日々最良の課題を発見するために奮闘しています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/" target="_blank" rel="noreferrer">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html" target="_blank" rel="noreferrer">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">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>
</body></html>

組織をより成長させるために、解くべき最良の課題にフォーカスする。そのための解くべき課題の見つけ方を考えてみる。

最良の課題を発見する技術 | PLAID engineer blog

最良の課題を発見する技術

<p>エンジニアの<a href="https://twitter.com/jumpei_ikegami">gami</a>です。<a href="https://twitter.com/search?vertical=default&amp;q=%23%E3%81%97%E3%81%8C%E3%81%AA%E3%81%84%E3%83%A9%E3%82%B8%E3%82%AA&amp;src=tyah">趣味はポッドキャスト配信</a>です。</p>
<p>今回は、「<a href="https://nodejs.org/">Node.js</a>」に焦点を当てた記事です。</p>
<p><a href="https://plaid.co.jp/">PLAID</a>では、約5年前から「<a href="https://karte.io/">KARTE</a>」というサービスを開発しています。そのサーバーサイドの実装は、ほとんどがNode.jsで記述されています。</p>
<p>一方、国内企業の中で、サーバーサイド実装にNode.jsを採用している企業は少ない印象があります。<br>
そこで、以下についてご紹介します。</p>
<ol>
<li>PLAIDがNode.jsで実現しているプロダクト</li>
<li>Node.jsを5年間使ってわかった強みと弱点</li>
<li>Node.jsを使いこなすための工夫</li>
</ol>
<h1>1. PLAIDがNode.jsで実現しているプロダクト</h1>
<p>実際にPLAIDがどのようにNode.jsを使っているかを紹介します。PLAIDでは、「リアルタイムユーザー解析サービス」であるKARTEを主に開発しているので、KARTEの開発について説明します。</p>
<h2>プロダクトの規模</h2>
<p>まずは前提として、KARTEのプロダクトとしての規模がわかるデータを紹介します。</p>
<h3>リクエスト数、イベント数</h3>
<p>KARTEが解析しているデータの規模感は、2018年8月現在の値でおよそ以下の通りです。</p>
<ul>
<li>最大 約20,000 イベント/秒</li>
<li>最大 約10億 イベント/日</li>
</ul>
<p>KARTEが扱うユーザー情報は、「イベント」という単位で連携、解析されます。エンドユーザーのブラウザから飛んでくるリクエストの中に、1つ以上のイベントが含まれています。<br>
1日で10億回ものユーザー解析を処理しているので、かなり「大規模」と言えるかと思います。</p>
<h3>ファイル数</h3>
<p>KARTEのメインのリポジトリのうち、Node.jsで書かれたサーバーサイドの実装に関するファイルの数と行数をカウントすると、以下の結果になりました。</p>
<ul>
<li>ファイル数
<ul>
<li>1,759ファイル</li>
</ul>
</li>
<li>行数
<ul>
<li>126,256行</li>
</ul>
</li>
</ul>
<p>（マイグレーションバッチ、テストコード、空行、コメント行などは除く）</p>
<p>他にも、一部の独自ライブラリはリポジトリを分けて開発しているので、それを加えるともう少し大きくなります。</p>
<h2>実現している機能</h2>
<p>以下の図がKARTEの大まかな構成図です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1e0a1a17-d440-48a9-988a-55b9a5058519/----------2018-08-15-14.41.54-1.png" alt="----------2018-08-15-14.41.54-1"></p>
<p>今後の説明のために、ざっと解説します。</p>
<h3>track/analyze（エンドユーザーの解析とデータ送受信）</h3>
<p>KARTEでは、解析対象のサイトにタグ（ネイティブアプリならSDK）を設置してもらいます。<br>
そこから送られるイベントをリクエストとして受け取り解析をするのが、「track」と「analyze」です。</p>
<ul>
<li>タグやSDKからイベントデータを受信
<ul>
<li>エンドユーザーのセグメントを解析</li>
</ul>
</li>
<li>1秒以内にエンドユーザーにポップアップなどの最適なアクションを送信</li>
<li>レスポンス後の処理も含めて、ユーザーデータを再計算</li>
</ul>
<p>特に、エンドユーザーからのリクエストに対してポップアップなどの最適なアクションを1秒以内に返す必要があり、高いパフォーマンスが求められる部分です。後述するように、NodeのClusterモジュールを使って負荷分散しています。</p>
<p>なお、KARTEではエンドユーザーから送られるイベントデータのスキーマをほとんど決めていないため、大量のスキーマレスなJSONデータを受け取る必要があります。Node.jsはJSONデータの取り回しが楽である反面、大規模なJSONを大量に扱うというCPUインテンシブな処理が苦手なのが悩みです。</p>
<h3>admin（クライアントに管理画面を提供）</h3>
<p>「admin」では、管理画面上でユーザーデータを閲覧できる機能等を提供しています。</p>
<ul>
<li>ルーティング
<ul>
<li>(SPA部分はvue-routerに任せる)</li>
</ul>
</li>
<li>設定値などを保存するMongoDBの操作
<ul>
<li>スキーマ定義</li>
<li>read/write</li>
</ul>
</li>
<li>フロントエンドから叩くRPC APIの提供</li>
</ul>
<p>KARTEではスキーマレスなNoSQL DBである「<a href="https://www.mongodb.com/">MongoDB</a>」を多用しています。MongoDBはほぼJSONライクなドキュメントを扱うので、Node.jsとの相性はかなりよく、DB周りの処理を自然に書くことができます。</p>
<p>主に実現している機能は以上です。</p>
<p>KARTEは「単純なWebサーバーとしての機能」だけではなく、「エンドユーザーの解析機能」をプロダクトのコアとして提供しています。その両方の機能について、特に言語を分けずに全てNode.jsで記述しています。</p>
<p>なお、システムの全体像や解析サービスを実現するGCPの活用方法については、PLAIDのエンジニア陣が執筆した以下の記事をご覧ください。</p>
<p><a href="https://codezine.jp/article/corner/711">大規模解析サービスを支えるGCP活用事例連載一覧：CodeZine</a></p>
<p><a href="https://codezine.jp/article/corner/711"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d31e904e-3650-45c6-9e29-730796f284af/----------2018-08-17-12.09.24.png" alt="----------2018-08-17-12.09.24"></a></p>
<h2>言語（AltJS）</h2>
<p>言語については、場所によって使い分けています。</p>
<ul>
<li>解析部分
<ul>
<li><a href="https://www.typescriptlang.org/">TypeScript</a></li>
</ul>
</li>
<li>その他
<ul>
<li>ES6</li>
<li><a href="https://coffeescript.org/">CoffeeScript</a>（一部）</li>
</ul>
</li>
</ul>
<p>解析エンジン部分だけは、固めに書きたいのでTypeScriptを使っています。大半のソースコードは、開発速度を優先して生のJavaScriptで記述しています。</p>
<p>元々はCoffeeScriptを使っていたのですが、世の多くの会社がそうであるように、Pure JavaScriptの機能強化に伴い、徐々に書き換えを進めています。</p>
<h2>フレームワーク、ライブラリ</h2>
<p>主に以下を使っています。（挙げるとキリがないので、だいぶ削っています）</p>
<ul>
<li><a href="http://expressjs.com/">Express.js</a>
<ul>
<li>薄いので拡張しやすい</li>
</ul>
</li>
<li><a href="https://lodash.com/">Lodash</a>
<ul>
<li>主に複雑なオブジェクトの操作で利用</li>
</ul>
</li>
<li><a href="https://caolan.github.io/async/">async</a>
<ul>
<li>非同期処理を連続/並列で実行するときに便利</li>
</ul>
</li>
<li><a href="http://mongoosejs.com/">Mongoose</a>
<ul>
<li>MongoDB用のODM（Object Document Mapper）</li>
</ul>
</li>
<li><a href="https://www.npmjs.com/package/cron">cron</a>
<ul>
<li>定期バッチの実行</li>
</ul>
</li>
<li><a href="http://plaidev.github.io/bolt-rpc/">bolt-rpc</a>
<ul>
<li>PLAID独自RPCライブラリ
<ul>
<li>OSSとして公開中</li>
</ul>
</li>
<li>内部で<a href="https://socket.io/">socket.io</a>を利用</li>
<li>Node.jsで記述</li>
</ul>
</li>
<li><a href="/webdb-forum-2016/">Brook</a>
<ul>
<li>PLAIDの独自解析エンジン</li>
<li>Node.jsで記述</li>
</ul>
</li>
</ul>
<h1>2. Node.jsを5年間使ってわかった強みと弱点</h1>
<p>上述したKARTEの実装を日々書いているPLAIDのエンジニアに、Node.jsのメリットとデメリットを訊いてみました。カテゴリ別に整理します。</p>
<h2>ノンブロッキング/イベントループ</h2>
<h3>強み</h3>
<p>Node.jsの良く知られたメリットは、KARTEの開発でも享受できています。</p>
<ul>
<li>大量のリクエストが来ても、パフォーマンスが低下しにくい</li>
</ul>
<h3>弱点</h3>
<p>逆に、非同期処理を多用するため、例外発生時やプロファイルをするときに問題の箇所を特定するのが難しかったり、そもそも記述が複雑になりやすかったりします。</p>
<ul>
<li>例外が起こったときのデバッグがキツい</li>
<li>プロファイルむずすぎ</li>
<li>非同期処理がわかりにくい</li>
</ul>
<h2>シングルスレッド</h2>
<h3>強み</h3>
<p>シングルスレッドであることで設計がシンプルになりやすい点は、意外とメリットを感じる点です。</p>
<ul>
<li>コンテキストスイッチによるパフォーマンス低下を防げる</li>
<li>ハードな制約なので、message queueなどを使って綺麗にプロセス分離したシンプルな設計になりやすい</li>
</ul>
<h3>弱点</h3>
<p>やはりCPUバウンドな処理が苦手な点が大きな弱点です。特に弊社の場合は大規模なJSONを扱うことが多く、JSONのパージングが同一スレッドで起きることでブロックされることに悩まされたりしています。</p>
<ul>
<li>シングルスレッド・マルチプロセスの癖/限界</li>
<li>シングルスレッドなのでハングすることがたまにあるし、原因特定が難しい</li>
<li>CPUをゴリゴリ使う処理とは相性が悪い</li>
</ul>
<h2>言語としての性質</h2>
<h3>強み</h3>
<p>特にPLAIDではフロントエンド/サーバーサイドでエンジニアを分けずに開発しているので、どちらも同じ言語で書けるというメリットは大きいです。</p>
<ul>
<li>フロントとサーバーサイドを同じ言語で書けるのでスイッチングコスト低い</li>
<li>JSONをそのまま扱える</li>
<li>非同期処理が簡単に書ける</li>
<li>決まりごとが少なく、用途が自由</li>
</ul>
<h3>弱点</h3>
<p>逆に、Node.js自体が自由すぎて起こる問題もあります。なお、一部では前述のようにTypeScriptを導入しています。</p>
<ul>
<li>シンプル過ぎるので、ファイル構成からコードの書き方まで混乱しがち</li>
<li>typoなどで実行時エラーが起こる</li>
<li>型が弱い</li>
</ul>
<h2>npm/エコシステム</h2>
<h3>強み</h3>
<p>大量のnpmライブラリがOSSとして公開されていて、CTO曰く「センスがいいモジュールが多い」ということです。</p>
<p>また、Node.jsが使っているJavaScriptエンジンであるV8の進化が早く、Node.jsのバージョンを上げただけでパフォーマンスが大幅に向上したことがあります。過去にはKARTEでも、Node.jsのバージョンを6から8に上げたとき、パフォーマンスが2倍以上上がった例がありました。</p>
<ul>
<li>ミニマムでセンスがいいライブラリが多い印象</li>
<li>GoogleがV8をどんどん進化させてくれる</li>
<li>Express.jsがシンプルで良い</li>
</ul>
<h3>弱点</h3>
<p>反面、npm自体のバグや依存性解決の難しさで時間を溶かすことも多かったです。依存性解決については、以前<a href="/npm-to-yarn/">このブログでも紹介</a>しています。ただし、npmのバージョンアップで徐々に解消されつつあります。</p>
<ul>
<li>npmのバグが多い</li>
<li>node_moduleの依存関係周りが辛い</li>
</ul>
<h1>3. Node.jsを使いこなすための工夫</h1>
<p>大規模で高いパフォーマンス要求を求められるプロダクトの実現や、Node.jsの弱点の補完のために実施していることをいくつか紹介します。</p>
<h2>Node.jsのClusterモジュールによる負荷分散</h2>
<p>KARTEでは最大で1秒間に数千リクエストを処理する必要があります。ただし、通常は1つのポートにアクセスできるプロセスは1つだけであり、そこがボトルネックになってしまいます。</p>
<p>そこで、Node.jsのClusterモジュールを使うことで、Cluster内に組み込まれたロードバランサが、リクエスト処理を複数のワーカープロセスに分割してくれます。これにより、CPUのコア数を最大限活かすことができます。</p>
<p>KARTEでは、特にtrackのパフォーマンス向上に役立っています。</p>
<h2>perfコマンドとFlameGraphを使ったCPUプロファイル</h2>
<p>CPU使用率が急上昇したときに、どの処理が重いのかを調べるため、CPUのプロファイリングをすることは多いと思います。しかし一部のプロファイリング用のライブラリは実際にコードの中に組み込むため、アプリケーション自体のパフォーマンスに影響する可能性があります。</p>
<p>そこで、perfコマンドで外側からプロファイルを取ることで、パフォーマンスにほぼ影響を与えずにCPUリソースを無駄に使っている関数を特定できるようにしています。</p>
<p>Node.jsでperfを使ったプロファイルを実現するには、<code>--perf-basic-prof-only-functions</code>などのプロファイル用のオプションを起動時に付ける必要があります。オプションを付けるとperf用の<code>.map</code>ファイルを吐いてくれます。</p>
<p>プロファイル結果は、<a href="https://github.com/brendangregg/FlameGraph">このライブラリ</a>を使ってFlameGraphとして出力しています。FlameGraphというのは、こういうやつです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b6c3bea-7c5f-4c82-8ce8-d67603d64957/----------2018-08-17-11.23.12.png" alt="----------2018-08-17-11.23.12"></p>
<p>出典: <a href="https://nodejs.org/en/blog/uncategorized/profiling-node-js/">Profiling Node.js | Node.js</a></p>
<p>使いどころとしては、hubotのコマンド経由でいつでも実行できるようにしている他、特定のインスタンスについて自動でプロファイル結果を出力するようにしています。KARTEではDatadogで各インスタンスのパフォーマンスを監視していますが、パフォーマンスが出ないインスタンスは自動で殺すようにしています。後からその原因を追いたい場合に備えて、殺す前に自動でperfコマンドを実行してプロファイルをしています。</p>
<p>なお、KARTEを支える監視サービスと構成については、以下の記事をご覧ください。</p>
<p><a href="https://codezine.jp/article/detail/10674">大規模解析サービスを支える監視サービスと監視構成のポイント | CodeZine（コードジン）</a></p>
<h2>マルチスレッド処理へ</h2>
<p>Node.jsは基本的にシングルスレッドで動作するので、特にCPUインテンシブな処理が苦手です。KARTEではスキーマレスな構造データを大量に行うため、その点がボトルネックになりやすいのが悩みでした。</p>
<p>Node.jsでもマルチスレッド処理がしたいという熱い想いは、弊社エンジニアの牧野が以前ブログで書いています。</p>
<p><a href="https://tech.plaid.co.jp/js_multi_threading/">MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する | PLAID engineer blog</a></p>
<p>Node.js v10.5.0からWorker Threadsが使えるようになったので、今後は一部の処理をそちらに置き換える計画を立てています。</p>
<h1>まとめ</h1>
<p>Node.jsを採用して5年間ほどKARTEの開発に使い続けましたが、特に「リアルタイムユーザー解析サービス」である特性上、その恩恵を受けることが多い。</p>
<p>また、Node.jsやV8の進化も早く、今後の発展が非常に楽しみです。</p>
<p>国内企業がプロダクションでNode.jsを採用する例はまだまだ少ないですが、とても強力な言語なのでぜひ使っていきましょう！</p>
<hr>
<p>リアルタイムユーザー解析プラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


Node.jsをリアルタイム解析サービスの開発で5年間使って知ったメリットやデメリットを紹介します。大規模な解析サービスをNode.jsで記述する上での工夫などについても解説しています。