Engineer Blog

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
<p>こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。</p>
<p>今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。</p>
<h1>KARTE Messageについて</h1>
<p>本題に入る前に、まずKARTE Messageについて説明します。</p>
<p>KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。</p>
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
<p>これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。</p>
<p>* LINEとの連携機能は現状β版として提供しています。</p>
<h1>このブログで出てくる用語</h1>
<p>まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。</p>
<p><code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。</p>
<p><code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。</p>
<p><code>トランザクションメール</code> :  受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。</p>
<p><code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。</p>
<p><code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。</p>
<p><code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。</p>
<p><code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。</p>
<p><code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。</p>
<p><code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。</p>
<p><code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。</p>
<h1>大量メール配信の運用における課題</h1>
<p>マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。</p>
<p>そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。</p>
<p>メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。</p>
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
<p>上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。</p>
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
<p>ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。</p>
<h2>AWS SESを利用したマルチテナント構成</h2>
<p>大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。</p>
<p>そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。</p>
<p><img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png"></p>
<p>KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。</p>
<p><img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png"></p>
<p>結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。</p>
<p>また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。</p>
<p>こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。</p>
<h2>まとめ</h2>
<p>マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。</p>
<p>KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。</p>
<p>興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

<p>こんにちは！SREの@ikemonnです。</p>
<p>7/24-26@San Franciscoで行われた<a href="https://cloud.withgoogle.com/next18/sf/">Google Cloud Next '18</a>に参加してきました。</p>
<p>いくつかのセッションを聞いてきたのですが、今回はKARTEのデプロイでも利用している<a href="https://www.spinnaker.io/">Spinnaker</a>のセッション、<a href="https://cloud.withgoogle.com/next18/sf/sessions/session/155951">Large-Scale Continuous Delivery at Netflix and Waze Using Spinnaker (Cloud Next '18)</a> が面白かったのでご紹介します。</p>
<h2>概要</h2>
<ul>
<li>WazeでのSpinnakerの使い方</li>
<li>Googleがリソースを割いてなぜSpinnakerを開発しているのか</li>
<li>Spinnakerのroadmap</li>
<li>まとめ</li>
</ul>
<h3>WazeでのSpinnakerの使い方</h3>
<p>Wazeはmulti-cloud(AWS/GCP)でインフラを構成しています。<br>
サービスが成長するにつれ、サーバが何千台にも増えていき次第にデプロイが大変になっていったそうです。<br>
SREチームがデプロイにかかりっきりになり、batchやbug fixのデプロイやrollbackも気軽にできなくなってきた時にSpinnakerを見つけました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ed5fc9f2-abc7-49e9-ab79-ccb5401b4702/-2018-07-30-9.00.51.png" alt="-2018-07-30-9.00.51"></p>
<p>OSS, multi-cloud対応したツールであることからSpinnakerの導入を決定しました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f513304d-4466-43c9-90c7-1481025c8f7a/-2018-07-30-7.31.36.png" alt="-2018-07-30-7.31.36"></p>
<p>Spinnakerを導入することで下記のメリットがあったそうです。</p>
<ul>
<li>SREチームにデプロイを頼まなくて良くなった</li>
<li>rollbackやデプロイを部分的に行えるので改善サイクルが早くなった</li>
<li>VM, k8s, AppEngine等を意識せずに統合的なインターフェースでデプロイできるようになった</li>
</ul>
<p>しかし、しばらくするとpipeline数が増えすぎて(1000以上!)、UIからの管理が大変になってきました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9d1e8c69-5711-4835-88fb-9aa3dabf4ace/-2018-07-30-7.37.25.png" alt="-2018-07-30-7.37.25"></p>
<p>pipeline自体は個々で大きく異なっているわけではなく、ちょっとした差分があるだけだったのでtemplateを作り、そこからpipelineを作るようにしたそうです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3c6a3b4-598a-4be0-acd0-d4d7231ded33/-2018-07-30-7.41.57.png" alt="-2018-07-30-7.41.57"></p>
<p>まず、<code>bake -&gt; smoke test -&gt; deploy</code> というpipelineのtemplateを作ることからはじめました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8621dbdf-3479-4810-94bb-7534e12a9fb2/-2018-07-30-7.44.26.png" alt="-2018-07-30-7.44.26"></p>
<p>v1ではまだリスクがあったので、canaryステージを追加し、  <code>bake -&gt; smoke test -&gt; canary -&gt; deploy</code> を作ったりと徐々にpipelineを改善していったそうです。</p>
<p>pipelineをテンプレート化していることにより、1000以上pipelineがあっても変更をすぐに反映できて良かったとおっしゃっていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/81534a64-c683-46d5-8f62-69bcc84f5407/-2018-07-30-7.48.13.png" alt="-2018-07-30-7.48.13"></p>
<p>Wazeではデプロイ以外にもCassandraのデプロイにもSpinnakerを使っているそうです。</p>
<p>今後Wazeでは、SLO/error budget等のSREのコンセプトを考慮した、下記のようなデプロイを行う予定と言っていました。</p>
<ul>
<li>error budgetを超えそうになると自動的にカナリアデプロイの検証時間を長くする</li>
<li>普段は自動でデプロイされるけど、デプロイしてよいかを手動で決定しなければならないようにする</li>
</ul>
<h3>Googleがリソースを割いてなぜSpinnakerを開発しているのか</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f4def9fc-5743-4ef9-9d35-5d2ba7e8e826/-2018-07-30-8.08.05.png" alt="-2018-07-30-8.08.05"></p>
<p>GoogleもSpinnakerの開発にリソースを割いているようで、去年に比べて現在では2倍の人員がいるようです。<br>
Full timeの開発者が13人、PM/TPM/EngMgrが各1人と、かなりリソースを割いているようでした。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/da003478-dd55-4ec3-9cd1-49343ae49df5/-2018-07-30-8.11.36.png" alt="-2018-07-30-8.11.36"></p>
<p>GoogleがSpinnaker開発に力を入れているのは、下記のような理由だそうです。</p>
<ul>
<li>Spinnakerで実現できることが社内のbest practice にマッチしている</li>
<li>デプロイ、ロールバック等が抽象化されているので、multi-cloudなインフラでもそれぞれのcloudの詳細な知識なしにデプロイできる</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a30cb370-993a-44c2-93a1-2859c30eed48/-2018-07-30-8.19.16.png" alt="-2018-07-30-8.19.16"></p>
<p>Googleとして早い段階からSpinnakerの開発に関わっており、 2014年に20%プロジェクトとして、とあるエンジニアがSpinnakerに関わりだしたのが始まりだそうです。<br>
そして、GCE, GKE, AppEngine等の機能を追加していったと言っていました。</p>
<h3>Spinnakerのroadmap</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/faf1c7da-b7ea-471f-b35d-39f5d093bf5b/-2018-07-30-8.29.56.png" alt="-2018-07-30-8.29.56"></p>
<p>上記がSpinnakerのroadmapです。<br>
個人的に最も気になったのが Configuration as Codeについてでした。<br>
デプロイ内容について宣言的なconfigを書いて、Codeとして管理できるようにしていくとのことです。<br>
KARTEでは <a href="https://github.com/spinnaker/dcd-spec">spinnaker/dcd-spec</a> を使ってpipelineを管理しているので、dcd-specとの違いを後で質問しにいきました。<br>
「dcd-specをより良くしたものをCLI経由で反映できるようにするよ」と教えてもらったのですが、まだ開発中なのか、具体的にどのようなものかは教えてもらえませんでした。<br>
<a href="https://docs.google.com/document/d/17Ifm562aypjLSHnNJ02COFv_VMv3spicH-7zMYd-oXE/edit#">Spinnaker CLI Design Doc</a>を見ると、<a href="https://github.com/spinnaker/spin">spinnaker/spin</a> が上記のCLIのようです。</p>
<p>Spinnakerに関する情報についてはこちら<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a1d3c567-4e16-4810-a5f8-a95fc1591345/-2018-07-30-8.35.43-1.png" alt="-2018-07-30-8.35.43-1"></p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/PLNheBiWOGI" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<h3>まとめ</h3>
<p>Wazeのような大規模マルチクラウドインフラを運用している会社でもSpinnakerを使っていること、Googleも開発にリソースを割いていることから、Spinnakerを今後も継続して利用しておけばしばらく安心だと思いました。<br>
他のセッションでもSpinnaker活用事例がいくつか発表されていたので、良いデプロイツールを探している方は一度触ってみると良いと思います。<br>
KARTEへのSpinnaker導入時にバグを見つけ、PRを出したのですが、それをマージしてくれた <a href="https://github.com/duftler">Matt Duftler</a>に直接質問できたのが個人的に良かったです。</p>
<h2>最後に</h2>
<p>2018/8/3(金)に開催予定の<a href="https://plaidtech.connpass.com/event/92694/">プレイドオフィス移転パーティー ※エンジニア&amp;デザイナー向け</a>でもGCP Nextについて話す予定なので、お時間が空いている方はぜひぜひご参加ください！</p>
<p>また、KARTEでのSpinnakerの使い方は、2018/9/8(土)に行われるbuildersconのセッション:<a href="https://builderscon.io/tokyo/2018/session/e3b9f6e2-7fc8-44fa-bb4f-238144e5cd1b">Multicloud deploy with Spinnaker</a>で発表する予定なので、ご興味のある方はお越しください！</p>
<p>CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、尖ったサービス/ツールを使いつつ大規模分散システムの構築/運用をしたいエンジニア（インターンも！）を募集しています。<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>


こんにちは！ SREの@ikemonnです。 7/24-26@San Franciscoで行われたGoogle Cloud Next '18に参加してきました。 いくつかのセッションを聞いてきたのですが、KARTEのデプロイで利用しているSpinnakerのセッションが面白かったのでご紹介します。

Google Cloud Next '18でSpinnakerのセッションを聞いてきました! | PLAID engineer blog

Google Cloud Next '18でSpinnakerのセッションを聞いてきました!

「イマドキのDocker力」を0から身につけるための一連のチュートリアルを紹介します。PLAID社内のKARTE開発環境のDocker化に伴い、扱い方を実践的に身につけるための教材として作成されました。

イマドキの「Docker力」を身につけるPLAID式チュートリアル | PLAID engineer blog

イマドキの「Docker力」を身につけるPLAID式チュートリアル

<p>こんにちは、プレイドの @nashibao です。今回は少し前に話題になった <a href="https://metaparticle.io/tutorials/javascript/">Metaparticle</a> というプロジェクトについて紹介します。</p>
<p><code>Metaparticle</code>は <code>a standard library for cloud native applications on Kubernetes.</code>と唄っていますが、要はjava/javascript/goなどのapplication code上にdocker/k8sのInfrastructure/Orchestrationのうち、Applicationとして関心がある部分は組み込んでしまおう、というプロジェクトです。</p>
<p>多機能のサービスを開発していると、様々なところで有限のベストプラクティス（ただし単一では無い）に沿ったDistributed Programmingをして堅牢性や冗長性を高めたり負荷分散をしたくなります。</p>
<p>ただ、これらを実現したいと考えて設計/実装をするのは多くはApplicationエンジニアですが、Infrastructure/Orchestrationの様々なツールがその間に横たわっていて機動性が失われてしまいます。</p>
<h1>CloudのThread/ProcessとしてのContainer</h1>
<p>Threadは扱いやすいです。パフォーマンス等を考えて様々なパターンを駆使して劇的にApplicationのパフォーマンスを上げることができます。</p>
<p>Processは？そこまで隔たりはありません。プレイドで好んで使っているNode.jsでいえば <a href="https://nodejs.org/api/cluster.html">Cluster</a> moduleを使うだけです。</p>
<pre><code>const cluster = require('cluster');
if (cluster.isMaster) {
  // master
  cluster.fork();
} else {
  // worker
}
</code></pre>
<p>ThreadもProcessもどちらもworkerへの分散には色々なパターンがあって、それらを使うと並列性が高いプログラムを容易にかけます。iOSの<code>NSOperationQueue</code>などその代表ですが、各言語に様々なパターンがあります。そしてこれはApplicationエンジニアの手元にあって自由に設計できます。</p>
<p>Containerは？yamlの世界、kubectlの世界です。Applicationエンジニアの手元にあるように見えて遠くに行きがちです。PortとVolumeがコントロールされていて、古き良きPubsub/Queueやmessaging用の各ツール（zeromqは好きだ）を使って自由に協調はできますが、言語が異なる他のPlatformというものが邪魔をします。</p>
<h1>Language idiomatic cloud</h1>
<p>分散性をある程度ラップしつつ、コントローラブルにするアプローチは昔からあって、例えば <code>MapReduce</code> があります。<code>Metaparticle</code>と目的は似ているがPipeline状のData処理に特化している所が異なります。<code>PySpark</code>を使うとlambda関数を単にローカルで動かしているのと同じように見えます。<code>Google Dataflow</code>や<code>Apatch Beam</code>もまま似てる。</p>
<p>Microservice流行りで、<a href="https://aws.amazon.com/jp/lambda/">AWS Lambda</a>や <a href="https://cloud.google.com/functions/">Cloud Functions</a> のような便利なツールが出てきてるので <a href="https://github.com/pywren/pywren">pywren</a>のように、それらをwrapしちゃえば良くね？みたいなアプローチもあります。</p>
<pre><code class="language-python">  def my_function(b):
    x = np.random.normal(0, b, 1024)
    A = np.random.normal(0, b, (1024, 1024))
    return np.dot(A, x)

  pwex = pywren.default_executor()
  res = pwex.map(my_function, np.linspace(0.1, 100, 1000))
</code></pre>
<p>サイトに書いてあるコードそのままだけれど、中が同一スレッドだろうが、別プロセスだろうがAWS Lambdaだろうが同じようなマナーで書けます。</p>
<h1>Metaparticle</h1>
<p><code>Spark</code>や<code>pywren</code>はかなり抽象化されていて、やれることも制限されますが（その代わりパフォーマンスに焦点がある）、<code>Metaparticle</code>はもう少し自由度に焦点があります。つまりdocker/k8sのconfigへcompileするためのメタ言語のようなものです。</p>
<pre><code>const mp = require('@metaparticle/package');

mp.containerize(
	{
        	ports: [8080],
        	replicas: 4,
		    runner: 'metaparticle',
		    repository: 'docker.io/docker-user-goes-here',
		    publish: true,
		    public: true
	},
	() =&gt; {
		// closure for each workers
	}
);

</code></pre>
<p>これだけです。これを素で使っても良いけれど、先ほどいった有限のパターンについては <code>standard library</code>なので当然提供する。sharingなら</p>
<pre><code>const http = require('http');
const os = require('os');
const mp = require('@metaparticle/package');

const port = 8080;

const server = http.createServer((request, response) =&gt; {
	console.log(request.url);
	response.end(`Hello World: hostname: ${os.hostname()}\n`);
});

mp.containerize(
	{
		ports: [8080],
		shardSpec: {
			shards: 3,
			&quot;urlPattern&quot;: &quot;\\/users\\/(.*)[^\\/]&quot;
		},
                repository: 'docker.io/your-docker-user-goes-here',
                publish: true,
                public: true,
		runner: 'metaparticle',
	},
	() =&gt; {
		server.listen(port, (err) =&gt; {
			if (err) {
				return console.log('server startup error: ', err);
			}
			console.log(`server up on ${port}`);
		});
	}
);
</code></pre>
<p>だし、electionなら</p>
<pre><code>var mp = require('@metaparticle/sync');

var election = new mp.Election(
    // Name of the election shard
    'test',
    // Event handler, called when a program becomes the leader.
    () =&gt; {
        console.log('I am the leader');
    },
    // Event handler, called when a program that was leader is no longer leader.
    () =&gt; {
        console.log('I lost the leader');
    });

election.run();
</code></pre>
<p>という感じです。上に書いたように、ここは有限のパターンがそれなりにあるので、それらが今後作られていくのだろうと思うが今の所ほぼ上の二つくらいしか書かれてないw</p>
<h1>感想</h1>
<p>thread/processとのアナロジーなどからContainerが扱いやすくなることについて書きましたが、<code>metaparticle</code>自体はdynamicにcluster/podを変更するわけではありません。scriptでdynamicに変更できるようになると、より上記のアナロジーがハマり、k8sに乗っかったままかなり柔軟に分散プログラムが書けると思ったりします。<br>
プレイドでも下手にクラスタ管理や組込済みの単純なオートスケールを使うより、nodeのgcp/api経由でインスタンス数の増減をさせるやり方をやってみたりしつつ、なんか違うな、と思ったりしていますw</p>
<p>今回は<code>a standard library for cloud native applications on Kubernetes.</code>な<code>Metaparticle</code>を紹介しました。個人的にはこのアプローチの先にDistributed Programmingの桃源郷があるのかもしれないし無いかもしれないと思っています。</p>
<p>CXプラットフォーム「<a href="karte.io">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。</p>


こんにちは、プレイドの @nashibao です。今回は少し前に話題になった [Metaparticle](https://metaparticle.io/tutorials/javascript/) というプロジェクトについて紹介

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ | PLAID engineer blog

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ

KARTEのロゴ刷新に至った経緯やデザインプロセスについてお伝えします！

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ | PLAID engineer blog

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ

<p>おはようございます！プレイドのエンジニアの <a href="https://twitter.com/jumpei_ikegami">@jumpei_ikegami</a> です。<br>
趣味はポッドキャスト配信です。</p>
<p>さて、プレイドでは定期的に、開発チームで合宿に行っています。</p>
<p>(過去の開発合宿のブログ記事は下記）</p>
<p><a href="http://blog-plaid.com/event/2772/">2016年:秋</a></p>
<p><a href="/plaid-developpers-camp-2017-spring/">2017年:春</a></p>
<p>今回は、開発フォーカスの区切りということで、前フォーカスの振り返り、4月以降の新チーム体制でのフォーカス、プロダクトの見せ方などについて、議論を深めてきました。</p>
<p>開発をしない開発合宿も珍しいと思いますが、目の前の開発業務を離れて、長期的な視野で開発の仕方や、何をするべきかを見つめ直すことで、本当にやるべき仕事にフォーカスできるようになります。</p>
<p>特に、<a href="/software-development-not-start-from-shu/">先日のエンジニアブログ記事</a>で弊社kadoppeが書いていた、「『常にゼロベースで考えて進む』プレイドの文化」が、議論の中にも表れていました。</p>
<p>そんな開発チーム合宿の様子を、写真多めでお送りします。</p>
<h1>五反田発、館山行き貸切バス</h1>
<p>館山の合宿先までは、オフィスのある五反田から貸切バスで移動しました。</p>
<p>バスの写真は、私が寝ぼけていたのでありません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e8fb80a-ae61-455a-af07-e722a3f393cd/010-2.jpg" alt=""><br>
（途中のサービスエリアで食べた、「つみれ汁:¥200」と、「ふきのとうの天ぷら:¥50」）</p>
<p>お酒が無いのが不思議です。</p>
<p>車内では、遠足気分を高めるための駄菓子の配給がありました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a37dd1e-d700-42ad-b9c1-bef6a1f0573b/020-2.jpg" alt=""><br>
(宿に着いてから「ソースせんべい」を食べる、ぐろっちさん)</p>
<h1>海の見える宿</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf8baae9-a779-4953-9634-11eb1c205532/030-1.jpg" alt=""></p>
<p>今回は、千葉県館山市、房総半島の南の端にある「<a href="https://tateyama-retreat.jp/">館山リトリート</a>」という宿にお世話になりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/68720b41-1492-4546-8ba8-e91932fae1d7/040-2.jpg" alt=""></p>
<p>議論に使った大広間からも、海が見えました。</p>
<p>考えに詰まったら大海原をみながら頭を整理することができました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/22d452a0-ffb7-47b8-85c4-9132b17c34a1/043-1.jpg" alt=""></p>
<p>食事は自分たちで準備するスタイルで、広々としたキッチンを自由に使えます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc1ae859-d3bd-40e0-b4c3-49cd063ec2ee/045.jpg" alt=""></p>
<h1>ゼロベースで議論！議論！議論！</h1>
<p>合宿のコンテンツは、ひたすら議論を重ねるものでした。</p>
<p>主な内容は4つありました。</p>
<h2>未来のユーザーに、KARTEをどのように見せる？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23b7183b-23a9-4614-a915-7627c592c3a8/050.jpg" alt=""></p>
<p>「<a href="https://karte.io/">KARTE</a>のキャッチコピーを考える」という題材を通して、未来のKARTEユーザーにどんなメッセージを伝えたいかを考えました。</p>
<p>出た意見をいくつか挙げます。</p>
<ul>
<li>KARTEを単なるツールとしてではなく、プラットフォームとして見せていくべき</li>
<li>要望への「最適化」では足りない。それを知った上で、どう期待を超えていくか？</li>
<li>クライアント企業の指標を上げるだけではなく、その先のエンドユーザーを幸せにすることを含めて見せ方を考えたい。是即ち「愛」</li>
</ul>
<p>開発チームの仕事は、ただプロダクトを作って終わりではありません。<br>
自分たちが作っているプロダクトがどのようにユーザーに届けられるのか、という点についても関心が高いのが、プレイドの開発チームのよいところだと感じました。</p>
<h2>チーム間の連携、どうすればうまくいく？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3640d85d-416a-4dc6-a5cd-d9d31267dfdb/060.jpg" alt=""></p>
<p>これまで、開発内の別チームや、ビジネス側のチームとの連携などがうまくいかなかったことで、手戻りが発生したり、ユーザーへのデリバリー方法に問題が生じたりしました。</p>
<p>そこで、「チーム間連携」というテーマで、理想・課題・解決策を挙げるために議論しました。</p>
<p>出た意見をいくつか挙げます。</p>
<ul>
<li>理想は、「スタンドプレーから生じるチームワーク」</li>
<li>チームを固定化せずに、ビジネスメンバーも巻き込んで流動的に変えていく</li>
<li>生産性を優先すると、社内で情報格差が生じてカオスになる。それをある程度許容すべき。ルールを作るのではなく、そういうカオスな状況でもパフォーマンスを出せるメンバーを増やしていく方が建設的</li>
</ul>
<p>「チーム間連携」という話だと、「定例ミーティングしよう！」というような安易な話になりがちです。<br>
それを超えて、さらに深い議論に発展していたのが、印象的でした。</p>
<p>プレイドには「常にゼロベースで考える」以外にも、「ルールをなるべく作らない」という文化があります。今回の議論も、ルールではなく、マインドやチームのあり方の話で課題を解決しようとするところに、「らしさ」が出ていました。</p>
<h2>コーヒーブレイク</h2>
<p>休憩時間では、コーヒー好きが集まるプレイドらしく、コーヒーミルを持ち込んで、コーヒーを飲むメンバーもいました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/705d5c03-7111-4b1e-bece-7e74b01ea541/070.jpg" alt=""><br>
(ハッピーターン」を取りに来た、デザイナーのミギーさん)</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2b9eb2ad-e8c2-46db-8418-ecf2ef85ff3e/080.jpg" alt=""><br>
(カメラを向けると、わざとらしい笑顔を向けてくる、ぐろっちさんと、ノブくん)</p>
<p>全く外に出る時間はありませんでしたが、昼間の天気も最高でした！<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/08c6cf6d-e1c3-45bd-9261-d249b0b55700/090.jpg" alt=""></p>
<h2>新しいチームでのミッションどうしよう？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/320f652e-821e-49ba-a0f5-cf3a5ad302bd/100.jpg" alt=""></p>
<p>4月から開発チームの再編があり、最初の3ヶ月で行うミッションの言語化、状態目標の設定、注力issueの洗い出し、などを行いました。</p>
<p>PLAIDには固定的な「部署」という概念はなく、定期的にチーム構成が再編されます。<br>
それによって、ナレッジが蛸壺化しにくくなったり、個人が色々な役割を担えるようになります。</p>
<p>開発チームも同様で、機能の多いKARTEの中でも、定期的に自分が開発を担当する機能が変わっていきます。</p>
<p>この議論では、前のチームでのやり方に捉われず、そもそもどんな課題を解決するべきか？を「ゼロベース」で考えていきました。</p>
<p>私はBizDevチームというビジネスサイドのチームに属しているのですが、「開発チームが作った機能のデリバリーに関して課題があり、その整備に注力していこう」という目線合わせができてよかったです。</p>
<h2>前フォーカスどうだった？</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b6f792f-35a1-426e-8286-857fc92ad9fd/110.jpg" alt=""><br>
(CTOが買って飲まなかった「プロテインドリンク」をみんなで勝手に飲んでいる図)</p>
<p>最後に前回のフォーカスについて、その進め方のKeepとProblemをみんなで挙げていきました。</p>
<p>出た意見をいくつか挙げます。</p>
<ul>
<li>Keep
<ul>
<li>作り始めたものを一回壊して、ゼロから作り直すことで、本当に良いものができた</li>
<li>「既存機能の改善」を束ねて大きくリリースしたのは、ただ新機能を出すより難しいことができた</li>
<li>チームが自律的にパラレルで動けるようになった</li>
<li>1人でやるよりもチームでやることで、より良いものができた実感がある</li>
</ul>
</li>
<li>Problem
<ul>
<li>差し込みタスクでスイッチングコストがかかった</li>
<li>もっと細かい粒度でリリースして、反応を見ながら開発しても良かった</li>
<li>チームの壁が厚く似たようなものを別で作ってしまったので、もっと流動的に人の入れ替えがあると良かった</li>
<li>不安定なテストがあるなど、フォーカス外のissueが放置されがちで、負債が溜まってしまった</li>
</ul>
</li>
</ul>
<p>この議論についても、結果として、「新しいルール作ろう！」ではなく、「次に同じ状況になったらもっとうまくできる！」という実感の共有をできたのが、良かったと思いました。</p>
<p>次に似たような課題に直面するときも、チームメンバーやプロダクトの状況はそのときとは違うかもしれません。<br>
無批判にルールを当てはめるのではなく、その都度「全力で考える」という前提を置いた上で、その考えるための材料を、この議論で洗い出せたと思います。</p>
<h1>うまい魚に、うまい酒</h1>
<p>議論の合間の食事も、みんなで楽しみました。</p>
<p>1日目の夜は、豪勢に鯛のあら汁と寿司でした。<br>
寿司には、「ストロング・ゼロ」がよく合います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f7e8c85f-a71a-414b-a8c0-7e9d1ce06a31/120.jpg" alt=""></p>
<p>一日中議論をしても、飲み会の話題は尽きません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9b190878-dacf-49c9-9f36-5eb0c99582f3/130-1.jpg" alt=""></p>
<p>期待のルーキー、カンテの悪酔いに、先輩藤川くんも苦笑い。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18de3482-98db-424d-bf9b-2ba505576086/135.jpg" alt=""></p>
<p>2日目の朝から、余った寿司を食べました。箸がなかったので、まさかのスプーンです。<br>
寿司は昼まで余ったので、夢の「3食お寿司のすしざんまい生活」が実現しました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58f58376-5fc2-46c8-8f64-56aa9dc73d8b/140-1.jpg" alt=""></p>
<p>2日目の昼は、なんと海鮮鍋でした。<br>
このシズル感。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/73a2f0aa-8395-4c20-92f9-27e8b27fa2c5/150-1.jpg" alt=""></p>
<p>鍋にすると、こうなります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5a4dbb25-68cc-4721-a775-77225a2a81d2/160.jpg" alt=""></p>
<h1>アクアラインを通って五反田へ</h1>
<p>2日間の日程も、あっという間に過ぎました。</p>
<p>帰りも、バスでアクアラインを通って東京に帰りました。</p>
<p>この日は強風が吹いていて、途中の「<a href="https://www.umihotaru.com/">海ほたる</a>」では階段を登っている途中で吹き飛ばされるかと思いました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a1f54dd-515d-4c6e-b694-2eede764e709/170.jpg" alt=""></p>
<p>バスでは、一部のメンバーが余った「ストロング・ゼロ」で宴会をしていました。私も2本目を空けるまでは記憶がありました。</p>
<p>思えば、この合宿で何本の「ストロング・ゼロ」を飲んだのだろう。プレイドの文化は、「常にゼロベースで考える」こと。昼に「ゼロベース」の議論を重ねて、夜に「ストロング・ゼロ」を飲み明かす。これが本当の......「ストロング・ゼロ・ベース思考」？？</p>
<p>......ふと、目を開くと、そこはいつもの五反田の街でした。</p>
<p>ということで、合宿で持ち帰ったアイデアを、ここ五反田のオフィスから実現していきます！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5cd766d1-f9ac-4d98-ab5f-f0654af798c3/180.jpg" alt=""></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>


開発チームで、千葉県館山市に合宿に行って来ました！開発の節目ということで、KARTEをどう見せていくか、何にフォーカスすべきかなど、1泊2日に�

1泊2日ぶっ通しで議論する開発合宿をしに、館山に行ってきました！ | PLAID engineer blog

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

<p>こんにちは、はじめまして。プレイドの @kadoppe です。</p>
<p>2017年4月に入社したエンジニアです。この記事を書いている時点のプレイド歴は11ヶ月です。</p>
<p>この記事では、自分が個人的に最近大事だと考えている『「型を守る」ことから始めないソフトウェア開発」』というトピックについて書いてみようと思います。</p>
<p>技術成分が少なめの内容ですが、こういうことを考えているエンジニアもいるんだよ、ということで興味がある方はご覧ください。</p>
<h1>５行まとめ</h1>
<p>少し長いので5行で内容をまとめます。</p>
<ul>
<li>「守破離」というソフトウェア開発の技術・方法論を効果的に学ぶための考え方がある。</li>
<li>「型を守る」ことから始めるソフトウェア開発は、問題を解決する上で最適・最速ではない可能性がある。</li>
<li>「型を守る」「型を破る」「型を離れる」のどこから始めるべきか、問題の内容や、プロダクト・チームの状態を考慮した上で決めるべき（最初から型破りでいい＝型を守ることから始めないソフトウェア開発）</li>
<li>「常にゼロベースで考えて進む」プレイドの文化において、型を守ることから始めないソフトウェア開発は進めやすい、というか自然とそう考えさせられる力学が働いている。</li>
<li>僕にとっての「プレイドの良いところ・好きなところ」はそういうところ。</li>
</ul>
<h1>守・破・離 〜 shu ha ri 〜</h1>
<p>唐突ですが、みなさん「守破離」について知ってますか？</p>
<p>「守破離」とは、ソフトウェア開発の技術・方法論を効果的に学ぶための考え方の一つです。本来は日本の合気道に由来する、武術を学ぶ際の考え方ですが、日本に止まらず世界的に使われています。</p>
<p>この考え方の中では、人が技術や知識を得るまでには、「守（型を守る）」「破（型を破る）」「離（型から離れる）」の３つの段階を経るとされています。</p>
<blockquote>
<p><strong>守</strong>：最初の段階では、学習者は師の教えを正確に模写する。理論についてあれこれ考えずに、その作法に集中する。作法が複数ある場合でも、師の教えをただ忠実に守る。</p>
<p><strong>破</strong>：この段階では、学習者は新しいことに手を出す。基本的な実践を身に着けたなら、技術の裏にある原則や理論を学んでいく。また、他の師からも学び、得たものを自身の実践に採り入れていく。</p>
<p><strong>離</strong>：この段階では、学習者は、自身の実践を通じて、他者から学んでいく。自身の手法を生み出し、学んだことを自身の環境に適応させていく。</p>
</blockquote>
<p>引用元: <a href="http://bliki-ja.github.io/ShuHaRi/">守破離</a></p>
<p>この３つの段階に従うことで、効果的に技術や方法論を身に付けることができ、最終的には分野でイノベーションを起こすことができるようになる、という考え方です。</p>
<p>非常にわかりやすいので、個人的にはとても好きです。前職でもこの考え方は凄く大事にした上で、新しいやり方や方法論などをチームに取り入れたりしていました。</p>
<h1>ソフトウェア開発における型</h1>
<p>では、ソフトウェア開発における型とは何でしょうか。</p>
<p>ソフトウェア開発を進めていく中で、プロダクトやチーム、エンジニアは、日々様々な種類の幅広い問題に直面します。</p>
<p>世の中にはそういった問題に対する解決策が、事例やフレームワーク、あるいは開発プロセスとして、書籍やWeb上の記事といった形で、広く一般に公開されています。</p>
<p>例えば、以下のようなものが例として挙げられます。</p>
<ul>
<li>アジャイル開発手法やウォーターフォールモデルといった開発手法</li>
<li>スクラムのようなフレームワーク</li>
<li><a href="https://www.amazon.co.jp/dp/B00G9QJ1ZO/">組織パターン</a>のような書籍にまとめられているパターンランゲージ</li>
<li><a href="https://12factor.net/ja/">The Twelve-Factor App</a> のような方法論</li>
<li>ブログの記事に記載されている小さな tips</li>
<li>etc.</li>
</ul>
<p>大きさや粒度は違えど、これらは全て、ソフトウェア開発において発生した何らかの問題に対する解決策です。このような解決策が「ソフトウェア開発における型」だと考えます。</p>
<h1>「型を守る」ことから始めることをあえて批判的に捉える</h1>
<p>突然何を言っているんだという感じではありますが、プレイドという新しい環境にジョインしてから、プレイドの文化や雰囲気に触れて、今までの自分の仕事のやり方や考え方を見つめ直す機会があったので、色々考えたのです。</p>
<p>上に紹介した「守・破・離」という考え方では、「守」から始めることが「良し」とされていると捉えることができます。しかし、「型を守る」ことから始めることが常に正しいとはいえないと思います。</p>
<p>ここでは、こじつけかもしれませんが、型を守ることから始めることを、あえて批判的に捉えてみます。</p>
<h2>思考停止では？</h2>
<p>「型を守る」＝「理論についてあれこれ考えずに、その作法に集中する。」で本当にいいんでしょうか。その理論は自分たちが抱えている問題に対して本当に正しく、適切なものなのでしょうか。</p>
<p>そもそも正しい理論を教えてくれる「師」なんて存在するのでしょうか？そもそも正しい理論なんて存在するのでしょうか？</p>
<p>一般的な解決策を信じきって、自分たちが直面している個別の問題に適用してしまってもいいのでしょうか。</p>
<h2>問題に対してその解決策は最適解か？</h2>
<p>同じように見える問題でも、その問題が発生した環境や背景、プロダクトやチームが違えば、本質的には違う問題です。</p>
<p>問題が違えばそれに最適な解決策も異なるはず。なので、そこから生まれる結果も最適なものではない可能性があります。</p>
<p>その前提の上で、「作法が複数ある場合でも、師の教えをただ忠実に守る。」のは本当に正しいアプローチなんでしょうか。</p>
<p>問題が少しは改善するかもしれません。でも、実はそれは局所最適解で、本当の最適解には気づけないまま、時間が過ぎていってしまうかもしれません。</p>
<p>最初から、自分たちの直面した問題に対して、ゼロベースでフルカスタマイズされた解決策を適用する。そのために問題をしっかり認識・分析することが、問題を最適に近い形で解決するための近道なのではないでしょうか。</p>
<h2>時間がかかりすぎないか？</h2>
<p>「守」から始めたとして、では「破」「離」にたどり着くまでにはどのくらいの時間がかかるのでしょうか。</p>
<p>例えば「スクラム」の例を挙げてみると、とあるスクラムコーチ曰く、スクラムをはじめたばかりのチームが「守」のフェーズが終わるまでに短くても「3ヶ月くらいかかる」とのことでした。</p>
<p>でも、自分たちにその時間的余裕はあるのでしょうか。ユーザーや市場は待ってくれるのでしょうか。「破」や「離」にたどり着く頃には会社はプロダクトはどうなっているのでしょうか。</p>
<p>最初はとりあえず始めてみて、そこで得られたフィードバックをもとに、あとで調整しながら最適に持っていく方法もあります。</p>
<p>問題を解決するまでにフィードバックループは何度か回すことになると思いますが、「守」から始めることで、少なくとも一回は余分に多くフィードバックループを回すことになってしまいます。</p>
<p>その1回を許容できる時間的余裕が、自分たちにはあるんでしょうか。</p>
<h1>「型を守る」ことから始めないソフトウェア開発</h1>
<p>ここまでで、言いたかったのは『「型を守る」ことから始めるソフトウェア開発は、問題を解決する上で最適・最速ではない可能性がある』ということです。「型を守る」ことから始めることが正しいときもありますが、必ずしもそうとは限りません。</p>
<p>大切なのは以下の2点だと思います。</p>
<ul>
<li>自分たちが直面している問題を、自分たち固有のものだと捉えて、問題についてしっかり認識した上で正しく理解すること。</li>
<li>問題に直面しているプロダクトやチーム、個人の状態（問題に対する習熟度、背景、環境など）を正しく理解すること。</li>
</ul>
<p>その上で、</p>
<ul>
<li>世の中に一般的に公開されている解決策をまずはそのまま適用してみるのか（＝型を守る）</li>
<li>それを参考に少しカスタマイズした上で試してみるのか（＝型を破る）</li>
<li>ゼロからフルスクラッチで自分たちだけの解決策を考えて適用してみるのか（＝型を離れる）、</li>
</ul>
<p>その時々に応じて最適だと考えられる選択肢を取ることが重要だと考えています。</p>
<p>これが『「型を守る」ことから始めないソフトウェア開発』です。最初から型破りでもいいんです。</p>
<p>これが自分たちが最適かつ最速に問題解決に近づくためのアプローチだと思いますし、個人的には凄く重要なポイントだと考えています。</p>
<h1>え、そんなの当たり前のことでしょ？</h1>
<p>ここまで書いた内容を眺めてみると「当たり前のこと / 誰でも気付いていること」を書いてるいるなぁと思いますし、ここまで読んでいただいている方も同じ感想をお持ちかと思います。</p>
<p>ですが、僕の経験上、</p>
<ul>
<li>ついつい思考停止した上で「型を守る」ことから始めてしまう</li>
<li>問題をしっかり認識・理解することよりも、先に解決策ありきで物事を進めようとしてしまう</li>
</ul>
<p>といった罠が、ソフトウェア開発に日々取り組む中で、いろんな場所に仕掛けられているような気がしています。「型を守る」ことに引っ張られる、そういう力学や雰囲気が自然と当たり前のように存在しているような。</p>
<p>「型を守る」ことから始めることや、解決策ありきで物事を進める方が、圧倒的に楽です。考えることの量がとても少ないです。一般的な解決策の方が、ゼロベースでフルカスタマイズした解決策よりも、周りの人が理解しやすかったりします。</p>
<p>人間は弱いものなので、気を抜くと、どうしても楽な方に引っ張られてしまいます。</p>
<p>だからこそ、楽ではないが、本質的なアプローチが取ることは難しいことだと思いますし、それがやりやすい環境がもしあるとするならば、それ自体凄く価値のあることだと思います。</p>
<h1>「常にゼロベースで考えて進む」</h1>
<p>プレイドのコーポレートサイトに、エンジニアリングチームの文化について書かれているページがあり、そこには以下のような記述があります。</p>
<blockquote>
<p><strong>カオスと問題を楽しむ</strong><br>
フレームややり方は決めずに、常にゼロベースで考えて進むのが重要であり何より面白い作業だと考えています。</p>
</blockquote>
<p>このように、プレイドには「フレームややり方は決めずに、常にゼロベースで考えて進む」ことを良しとする文化があります。</p>
<p>僕がすごく共感していて、実際にプレイドで仕事をする上で「良い」と感じているのが、この「常にゼロベースで考えて進む」という考え方・スタンスです。プレイドには多様なメンバーが所属していますが、ベースとしてこの考え方が根付いているように感じます。</p>
<p>そして、これによって『「型を守る」ことから始めないソフトウェア開発』がとてもやりやすくなっているように思います。意識しなくても気づいたら、そういう方向に思考が向いているというか、自然とそうなっているというか。</p>
<p>型（フレームややり方）を最初から作らずに、まずは問題をしっかり認識・理解した上で、自分たちにとって最適なやり方を作っていく。自然とそういう思考になるような、力学や雰囲気がプレイドには存在しています。</p>
<p>仮にそういう力学や雰囲気がないと、ついつい「フレームややり方」ありきで問題を解決しにいってしまうのではないでしょうか。</p>
<h1>大変だけど、楽しいし、価値があること</h1>
<p>ゼロベースで考えることはとても大変ことです。自分たちのプロダクトやチーム、個人のことを真剣に見つめ直す必要があります。辛くなる時ももしかしたらあるかもしれません。</p>
<p>ゼロベースで考えたことで、スピードがもの凄く遅くなっていては元も子もありません。フルスクラッチで解決策を考えるとはいえ、時間をかけすぎてはいけない、そういったプレッシャーの中で物事を考える必要があります。</p>
<p>それでも、その思考のプロセスが楽しいのです。これまでたくさんは使ってこなかった脳の部分をたくさん使う感じがします。</p>
<p>それが自分自身を成長させますし、何より、プロダクトやチームが抱えている問題を本質的に解決するための近道であり、さらには長期的なプロダクトの成長やユーザーへの価値向上に繋がると信じています。</p>
<p>それができる環境で僕は今働いていて、こうやって言葉を並べるだけではなく、自分の仕事をどんどん価値に繋げていきたいと、日々取り組んでいます。</p>
<h1>おわりに</h1>
<p>最近、「プレイドで働く上で楽しいこと、良かったことはなんですか？」と社外の人に質問される機会が何度かあったのですが、毎回上に書いたようなことを答えています。</p>
<p>具体的なエピソードを書いていないですが、それはまた別の機会に紹介できればと思います。</p>
<p>なお、この記事の内容は、あくまでも、僕個人の考え、僕個人から見たプレイドについての考えです。</p>
<p>プレイドのエンジニアチームは、幅広いスキル・バックグラウンド・ビジョンを持った多様なエンジニアで構成されており、なので、全然違うことを考えているエンジニアもいます。</p>
<p>この記事では、こういうことを考えているエンジニアもいますよ、という一例を紹介しました。</p>
<hr>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ 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>みなさん、ごきげんよう。プレイドの@tik-sonです。</p>
<p>現在、PLAIDエンジニア陣で<a href="https://codezine.jp/article/corner/711">CodeZineで連載</a>をしているのですが、<br>
今回は<a href="https://codezine.jp/article/detail/10674">KARTEを支える監視構成についての記事を書きました。</a></p>
<p>記事のリード文で紹介しているように、シビアな要件が求められる、大規模解析サービスの監視のポイントや、構成などを書いているので、是非とも御覧ください！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0c95bcdc-12bd-491a-baff-7aa28c0af6ed/image--2--2.png" alt="image"><br>
<a href="https://codezine.jp/article/detail/10674">大規模解析サービスを支える監視サービスと監視構成のポイント</a></p>


12.5億UUを解析するKARTEを支える監視構成について記事を書きました。

12.5億UUを解析する大規模解析サービスの監視構成 | PLAID engineer blog

12.5億UUを解析する大規模解析サービスの監視構成

<p>みなさん、ごきげんよう。プレイドの竹村(a.k.a. tik-son)です。<br>
2018/2/15,16に雅叙園東京で開催された <a href="http://event.shoeisha.jp/devsumi/20180215/">Developers Summit 2018</a>にて<a href="http://event.shoeisha.jp/devsumi/20180215/session/1621/">「マルチクラウドで構築する大規模解析サービス～戦略とポイントについて」</a> というテーマで登壇してきました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dbe903fb-d3a5-46e2-ab12-5babcac9292c/Image-uploaded-from-iOS.jpg" alt="Image uploaded from iOS.jpg (2.7 MB)"></p>
<h1>発表内容</h1>
<p>最近、「マルチクラウド」という言葉をよく聞くようになりましたが、まだ世の中には具体的な話があまり出ていないなと感じていたので、「マルチクラウドでの構築/運用でのポイント」を出来る限り実例ベースでお話しました。<br>
<strong>6000events/secの負荷</strong>  を <strong>0.x秒で解析する</strong> KARTEの構築/運用を通して培ったマルチクラウドでの様々なノウハウが詰まっているので是非ともご覧いただければと思います。<br>
発表資料はこちらです。</p>
<div>
<script async class="speakerdeck-embed" data-id="d87b6e822d0149bb89f11cd50e18c9e6" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>この発表内容については、<a href="https://classmethod.jp/">クラスメソッド</a>さんにかなりいい感じにまとめてもらっているので、こちらもご覧いただければ理解を更に深めていただけると思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/51d7d4df-1512-4fae-b6bf-2f64e376da35/image.png" alt="image.png (211.4 kB)"></p>
<p><a href="https://dev.classmethod.jp/cloud/aws/devsumi2018-multicloud/">「ほんまに運用できるの？」毎秒6000イベントをミリsec対応するウェブサービスを、マルチクラウドで構築した話を聞いてきた #devsumi</a><br>
(タイトルが関西弁感出てるのは、関西弁で発表したからなのだろうか)</p>
<blockquote>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4f8b255c-b57b-4be9-90b5-1e1391884a7c/image--1-.png" alt="image.png (91.9 kB)"></p>
</blockquote>
<p>発表者冥利に尽きるありがたいお言葉もいただいております。</p>
<h1>デブサミに登壇してみて</h1>
<p>かなり大きな会場、たくさんの方に来場いただいたので、楽しく発表させていただくことができました。<br>
色々と喋りすぎてしまって、最後の方は結構時間がギリギリだったのはここだけの話です。<br>
また、Ask the speakerのコーナーでも来場者の方々と色々と質問、意見交換などをさせていただき、とても有意義な時間でした。<br>
お声がけをいただいた翔泳社さんを初め、デブサミ運営に携わっている皆様ありがとうございました。</p>
<p>一方で、来場いただいたようなDeveloperの方々には、KARTEって自分が思っていた以上に知られていないんだなと痛感し、このようなカンファレンスやTechBlogを通してもっとガンガン外部に発信することの重要性を感じました。<br>
KARTE内ではマルチクラウドをはじめとした、外に発信できる面白い取り組み/ノウハウがたくさんあるので、今後もこのTechBlogなどで積極的に発信していきたいと思います。</p>
<h1>最後に</h1>
<p>プレイドでは、今回お話したようなマルチクラウドインフラをガッツリ触って成長させたい！というエンジニアを募集しています。<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>
</div>


Developers Summit 2018にて「マルチクラウドで構築する大規模解析サービス～戦略とポイントについて」話してきました。

Developers Summit 2018に登壇してきました #devsumi |  PLAID engineer blog

Developers Summit 2018に登壇してきました #devsumi

ビッグデータよりストリームデータの時代！KARTEのリアルタイム解析でも使われているストリーム処理について学んでみる。

ストリーム処理を１からKappa Architectreまで学ぶ | PLAID engineer blog

ストリーム処理を１からKappa Architectreまで学ぶ

<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をマルチスレッド化する

Engineer Blog

Recent Article

Google Cloud Next '18でSpinnakerのセッションを聞いてきました!

イマドキの「Docker力」を身につけるPLAID式チュートリアル

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ

刷新したKARTEロゴのプロセス公開ープロダクトが目指す理想像から始めるアプローチ

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

「型を守る」ことから始めないソフトウェア開発ー常にゼロベースで考える

12.5億UUを解析する大規模解析サービスの監視構成

Developers Summit 2018に登壇してきました #devsumi

ストリーム処理を１からKappa Architectreまで学ぶ

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

Popular Articles

Popular Tags

Archives

Writers

Recent Article

Google Cloud Next '18でSpinnakerのセッションを聞いてきました!

イマドキの「Docker力」を身につけるPLAID式チュートリアル

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ

刷新したKARTEロゴのプロセス公開 ー プロダクトが目指す理想像から始めるアプローチ

1泊2日ゼロベースで議論する開発合宿@館山に行ってきました！

「型を守る」ことから始めないソフトウェア開発 ー 常にゼロベースで考える

12.5億UUを解析する大規模解析サービスの監視構成

Developers Summit 2018に登壇してきました #devsumi

ストリーム処理を１からKappa Architectreまで学ぶ

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

Popular Articles

Popular Tags

Archives

Writers

刷新したKARTEロゴのプロセス公開ープロダクトが目指す理想像から始めるアプローチ

「型を守る」ことから始めないソフトウェア開発ー常にゼロベースで考える