Engineer Blog

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

Developer Experience & Performance チームでエンジニアをしている大矢です。今回は JavaScript の非同期処理で使われている callback を Promise に移行する手法について、具体的な事例をもとに紹介します。

Mongoose の callback を Promise に移行する手法

KARTEの複数のシステム間で共有する定数ファイルを、これまで社内向けのnpmパッケージとして配布していたところから、代わりとなる独自の仕組みを構築して管理する方式に切り替えたことと、その移行プロセスについて。

npmパッケージの代わりに独自の仕組みを構築して定数ファイルを配布する運用に切り替えた経緯と移行プロセス

<h1>はじめに</h1>
<p>こんにちは、桂田一輝と申します。2024年8月から10月の3ヶ月間、プレイドのEcosystemチームでソフトウェアエンジニアとしてインターンシップを行いました。インターンを通じて、Ecosystemチームが開発しているKARTE Craftというプロダクトの改善業務に携わってきました。そこで得られた学びについてお伝えします。</p>
<h1>EcosystemチームとKARTE Craftについて</h1>
<p>私が配属されたEcosystemチームは、KARTEと外部サービスを繋ぐ連携機能のオーナーを務めています。Ecosystemチームがオーナーとなっているプロダクトの一つに、<strong>KARTE Craft</strong>があります。</p>
<p>KARTE Craftはアプリケーション開発機能を提供するPaaSです。KARTEの機能拡張や独自のカスタマードリブンなサイト、アプリケーションを作成することができるため、KARTEの特徴であるユーザーの状態変化に応じた適切なアプリケーションの開発が可能になります。</p>
<p><a href="https://craft.developers.karte.io/get-started/about-karte-craft/">https://craft.developers.karte.io/get-started/about-karte-craft/</a></p>
<p>今回のインターンで私が担当したのは、KARTE Craftの <strong>Craft Functions</strong> という機能の改善でした。</p>
<h2>Craft Functionsとは</h2>
<p>Craft Functionsは、KARTE内外で発生するユーザーの状態変化に関するイベントをトリガーにして、任意のバックエンドプログラムを実行する機能です。外部サービスや自社システムとの連携、シンプルな連携から複雑な作り込みまで、あらゆるカスタマードリブンな独自のアプリケーションを作成できます。</p>
<p><a href="https://craft.developers.karte.io/get-started/about-karte-craft/#craft-functions%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF">https://craft.developers.karte.io/get-started/about-karte-craft/#craft-functionsの仕組み</a></p>
<p>Craft Functionsで実行するプログラムを<strong>ファンクション</strong>と呼びます。ファンクションの作成時には、インフラの構築・運用は不要で、AIによるサポートも搭載されているため、手軽に作成することができます。</p>
<h1>インターンで行ったタスク</h1>
<p>インターン期間中は、大きく3つのタスクに取り組みました。配属後の初めのタスクとして、KARTEのサーバーインフラを理解するための設定変更を行いました。その後は、Craft Functionsの改善として、次の2つのタスクを担当しました。</p>
<ul>
<li>ファンクションが意図せず操作不能となる事象を回避するためのジョブ機能の構築</li>
<li>ファンクション一覧をタイプ別に取得するサービス間APIの作成</li>
</ul>
<p>今回は、上記の2つのタスクを紹介し、そこから得られた学びを説明します。</p>
<h2>タスク1: ファンクションが意図せず操作不能となる事象を回避するためのジョブ機能の構築</h2>
<p>最初のタスクは、作成したファンクションの状態管理に関する課題を解決するものです。ファンクションの作成処理の流れ、課題、そして解決方法を説明します。</p>
<h3>課題</h3>
<p>Craft Functionsでファンクションを作成する際のシステム概要図は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/b48943b2-5706-4e92-9a4e-97345c8f456e/image.png" alt="image.png"></p>
<p>KARTEは複数のマイクロサービスで構成されており、サービス間通信にはAPIやqueueが使われています。図のwebサービスはKARTE Craftの管理画面を提供しています。workerサービスではファンクション用のコンピューティングリソース作成、更新、削除などの時間のかかる処理を非同期で行っています。</p>
<p>ファンクションの作成順序は次のとおりです。</p>
<ol>
<li>webサービスはファンクション作成リクエストを受け取り、MongoDBにstatus: <code>IN_PROGRESS</code> でファンクションの設定情報を保存し、workerサービスにファンクション作成メッセージを送信します。</li>
<li>workerサービスはファンクションを実行するためのコンピューティングリソースを作成します。</li>
<li>workerサービスはコンピューティングリソースの作成結果に基づき、ファンクションの設定情報を更新します。
<ul>
<li>リソース作成に成功した場合は設定情報のstatusを<code>SUCCESS</code>に変更します。</li>
<li>何らかのエラーで失敗した場合は<code>FAILED</code>に変更します。</li>
</ul>
</li>
</ol>
<p>KARTE Craftのアプリケーション上で予期しない不具合が発生した場合、ファンクションのstatusが <code>IN_PROGRESS</code> のままで操作ができなくなるという課題がありました。ユーザー自身でできる解決手段がないため、問題になっていました。</p>
<h3>解決策</h3>
<p>この課題の解決策として、ファンクションの設定情報を確認し、「最終更新から1時間以上経過」かつ「status: <code>IN_PROGRESS</code> 」なファンクションを作成失敗したとみなして <code>FAILED</code> に更新する仕組みを考えました。</p>
<p>実装方法として、以下の2つの方法を検討し、それぞれの長所と短所を比較しました。</p>
<ol>
<li>KubernetesのCronJobリソースを使用する。
<ul>
<li>メリット: 構成がシンプルで直感的に理解しやすい</li>
<li>デメリット: 新しいインフラの設定を追加する必要があり構成が複雑化する</li>
</ul>
</li>
<li>フロントエンドからファンクションに対するAPIを投げる
<ul>
<li>メリット: サーバーサイドの計算負荷が少ない</li>
<li>デメリット: フロントエンドの計算負荷が増える。APIの露出が増える。</li>
</ul>
</li>
</ol>
<p>今回はフロントエンドに対する余計な計算負荷やAPIの露出を避けることを優先し、方法1を選択しました。方法1を用いた際の構成図は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/d206cc8d-2e89-4677-b5b5-a669d2a9eee4/image(1).png" alt="image(1).png"></p>
<p>cron-jobというサービスをKubernetesのCronJobとして作成し、定期的にMongoDBにクエリを実行することで、上記で説明した状態のファンクションを<code>FAILED</code>に更新します。</p>
<h3>実装</h3>
<p>実装において工夫した点を3点説明します。</p>
<ul>
<li>汎用的なジョブ実行コンテナの整備</li>
<li>ファンクション設定の更新方法</li>
<li>テストの実装</li>
</ul>
<p><strong>汎用的なジョブ実行コンテナの整備</strong></p>
<p>今回の実装時点で、KARTE Craft上でスケジュール実行しているのはこのCronJobリソースのみでした。そのため、プログラムを単純に実装して実行すれば十分でした。しかし、他のKARTEプロダクトのコードを見ると、より汎用的にジョブを起動できる構造になっていたので、それを参考に実装しました。</p>
<p>次のコードは、その実装を抜粋し、説明用に改変したものです。</p>
<pre><code class="language-jsx">const argv = minimist(process.argv.slice(2));
const { jobname } = argv;

import(`./path/to/${jobname}`)
  .then(async cronjob =&gt; {
    await cronjob.default(argv);
  })
  .catch(err =&gt; {
    logger.error(err);
    process.exit(1);
  });
</code></pre>
<p><code>jobname</code>は引数としてプログラムを実行する際に渡します。今回はCronJobリソースの <code>command</code> 属性でコンテナ起動時に渡すようにしました。これにより、スケジュールの異なる複数のプログラムを1つのコンテナイメージで呼び出すことが可能になりました。</p>
<p><strong>ファンクション設定の更新方法</strong></p>
<p>CronJobで定期的に実行する関数では、「最終更新から1時間以上が経過」かつ「statusが<code>IN_PROGRESS</code>」という条件を満たすファンクションのドキュメントを全件取得し、それらを<code>FAILED</code>に更新します。</p>
<p>当初はMongooseの<code>updateMany()</code>メソッドで一括更新しようとしましたが、このメソッドでは更新したドキュメントの内容が確認できないことがわかりました。ジョブでは更新したドキュメントをログ出力したいので、今回は条件を満たすドキュメント一式を <code>find()</code> メソッドで取得し、 <code>findOneAndUpdate()</code>メソッドで1件ずつ更新しました。</p>
<p><strong>テストの実装</strong></p>
<p>作成した処理が正常に動作することを確かめるため、テストコードも実装しました。テストでは、更新日時が異なる複数のドキュメントを作成し、当該処理の結果を想定の値と比較しました。</p>
<h2>得られた学び</h2>
<p>このタスクでは、KARTE Craft上にジョブシステムを作成しました。タスクを通じて次の学びを得られました。</p>
<ul>
<li>インフラ〜バックエンドを跨いだ機能の実装
<ul>
<li>ジョブ用のプログラムを記述し、それをKubernetesのワークロードとして動かす方法がわかりました。</li>
</ul>
</li>
<li>設計・実装レベルでの取捨選択の方法
<ul>
<li>構成や実装を検討する際に、候補を挙げてその良し悪しを検討することで、より説得力のある設計・実装になることがわかりました。</li>
</ul>
</li>
</ul>
<h2>タスク2: ファンクション一覧をタイプ別に取得するサービス間APIの作成</h2>
<p>次に取り組んだのが、KARTEのHook機能経由でファンクションを起動する設定をする際に必要となる、ファンクション一覧APIの改善タスクでした。マイクロサービス間の通信に必要なAPIを作成し、サービス間通信の実装を行いました。</p>
<h3>Hook v2</h3>
<p>Hook v2は、KARTE内で発生した特定の変更や追加などの変化をトリガーとして、そのデータをリアルタイムで外部のシステムに送信する機能です。</p>
<p><a href="https://developers.karte.io/reference/about-hook-v2">https://developers.karte.io/reference/about-Hook-v2</a></p>
<p>Hook v2を使うことで、KARTE内で起きた出来事をトリガーとして、外部システムで処理を行うことができます。例えば、ユーザーからメッセージが送信された際にそれをトリガーとして特定のファンクションを実行させることができ、顧客のリアルタイムな行動に合わせたアクションを提供することができます。参考として、以下の記事では汎用のWebhookリクエストを行う方法を説明しています。</p>
<p><a href="https://solution.karte.io/blog/2023/06/craft-webhook/index.html">https://solution.karte.io/blog/2023/06/craft-webhook/index.html</a></p>
<h3>課題</h3>
<p>次の図はHook v2の設定画面です。この画面では、トリガーとなるイベントと、そのトリガーで起動するファンクションを指定します。</p>
<p><img src="https://ik.imagekit.io/plaid/80d8a018-8062-4657-8928-5f4da923980c/%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%882024-10-2316.14.09.png" alt="スクリーンショット2024-10-2316.14.09.png"></p>
<p>Craft Functionsのファンクションには、2種類のタイプがあります。HTTPタイプとイベント駆動タイプです。</p>
<div class="iframely-embed" data-embedded-url="https://craft.developers.karte.io/craft-functions/craft-functions-types/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://craft.developers.karte.io/craft-functions/craft-functions-types/" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcraft.developers.karte.io%2Fcraft-functions%2Fcraft-functions-types%2F&key=878c5bef402f0b2911bf6d4ce6261abd">ファンクションのタイプ</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>Hook v2において指定できるファンクションはイベント駆動タイプのみです。しかし、管理画面上はHTTPタイプ、イベント駆動タイプの両方が指定できるようになっていました。この相違を解決するため、管理画面上において指定できるファンクションからHTTPタイプを除き、イベント駆動タイプのみを表示する必要がありました。</p>
<h3>解決策と実装</h3>
<p>Hook v2機能はKARTE Craftとは異なるサービスで動作するため、マイクロサービス間でAPI通信を行いファンクション一覧を取得しています。今回はAPIの改善を行いました。具体的には、ファンクション一覧取得のリクエスト時に、タイプを指定できるAPIを追加し、それを利用するように変更しました。</p>
<p>Hook v2の管理画面においてファンクションの取得を行う際の構成図は次のとおりです。赤字で示すように、タイプを指定できるAPIへの切り替えを行いました。</p>
<p><img src="https://ik.imagekit.io/plaid/4745c925-fff4-4836-bda8-0a42cb293e9b/image(2).png" alt="image(2).png"></p>
<p>具体的な実装として、次の作業を行いました。</p>
<ul>
<li>Craft側にサービス間通信用のAPIを追加し、バックエンドを実装しました。</li>
<li>クライアントをOpenAPI Specから自動生成する仕組みを使って、サービス間通信用のクライアントを生成しました。</li>
<li>Hook v2のバックエンド処理で、新たに作成したサービス間通信用APIを利用するように変更しました。</li>
</ul>
<h2>得られた学び</h2>
<p>このタスクでは、マイクロサービス間の通信を行う仕組みを理解し、その改善を実施しました。タスクを通じて、次の学びが得られました。</p>
<ul>
<li>本番稼働するシステム上で、どのようにマイクロサービスが稼働しているかの全体像が掴めました。</li>
<li>インターフェース仕様（OpenAPI Spec）を活用してクライアントを自動生成することで、良い開発体験を提供できることがわかりました。</li>
</ul>
<h1>あとがき</h1>
<p>3ヶ月に渡って参加したインターンシップの感想を端的に言えば、非常に充実した経験でした。</p>
<p>今回のインターンシップを通して、次のような学びが得られました。</p>
<ul>
<li>実際に社員が担当するレベルのタスクを担当することで、本番稼働するプロダクトを開発する際に必要なレベル感を実感しました。</li>
<li>タスクを通じて、PaaSのインフラからバックエンドまで、一気通貫の開発を経験できました。</li>
<li>システム特性の面でも、Webシステムだけではなく、ジョブシステムを新たに作成する経験を通じて、開発の幅を広げることができました。</li>
</ul>
<p>これまでの私の開発経験は個人的なプロジェクトに限られており、実際のプロダクトに対する開発は初めてでした。今回のインターンシップで、実際に世の中に出ているシステムの開発に携わることで、多くの刺激を受けることができました。KARTEというアプリケーションの裏側の設計や動作原理を知った時の感動、そこで発生している課題に対して解決策を考え、技術選定をし、実装する楽しさ、そして自分が開発したものが実際にデプロイされる喜びを強く感じました。これらの経験を通じて、エンジニアリングそのものへの好奇心が大いに高まりました。また、この過程でコードを読み解き構造を把握する能力や、未知の技術を調査して組み込む力を養うことができたと考えています。</p>
<p>さらに、インターンシップの環境は非常に学びやすいものでした。メンターの方はいつ質問しても丁寧に答えてくださり、質問しやすい雰囲気が整っていました。加えて、インターンシップ期間中は他のチームの方々も交えたランチに頻繁に誘っていただき、様々なチームや職種の方々の話を聞くことで、多様な視点を知ることができました。</p>
<p>お世話になった社員の皆様に心から感謝申し上げます。本当にありがとうございました。</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

こんにちは、桂田一輝と申します。2024年8月から10月の3ヶ月間、プレイドのEcosystemチームでソフトウェアエンジニアとしてインターンシップを行いました。インターンを通じて、Ecosystemチームが開発しているKARTE Craftというプロダクトの改善業務に携わってきました。そこで得られた学びについてお伝えします。

プレイドインターン体験記：プロダクトの改善活動から得た学び_プレイドエンジニアブログ

プレイドインターン体験記：プロダクトの改善活動から得た学び

<h1>自己紹介</h1>
<p>初めまして、プレイドでエンジニアインターンをしている小林雅史と申します。プレイド内ではあだ名である<a href="https://x.com/mercy34mercy">mercy</a>(マーシー)で呼ばれています。</p>
<p>立命館大学の修士1年生で、大学は情報理工学部、大学院は情報理工学研究科とコンピュータやプログラミングについて学び、研究しています。プログラミングは大学入学と同時に授業で取り組んできました。プログラミングに関しては授業だけでなく、ハッカソンなどでさまざまなアプリケーションを作成しました。特に<a href="https://cup.hackz.team/">ハックツハッカソン</a>が大好きで2度優勝しています。また<a href="https://ritsumeikanunivpress.com/07/11/4430/">大学生向けのバス時刻表アプリ</a>を先輩から引き継ぎ運用していたりもしています。3年生の時には学生IT団体<a href="http://www.watnow.jp/">watnow</a>の代表として<a href="http://www.watnow.jp/2022/10/20/%E9%96%A2%E8%A5%BF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%AB%E3%83%B3%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B92022%E3%82%92%E9%96%8B%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/">企業様とのイベント</a>や<a href="http://www.watnow.jp/2022/08/24/watnow%e3%83%8f%e3%83%83%e3%82%ab%e3%82%bd%e3%83%b3-beginners-cup%e3%82%92%e9%96%8b%e5%82%ac%e3%81%97%e3%81%be%e3%81%97%e3%81%9f%ef%bc%81/">団体内ハッカソン</a>を立ち上げたりとコミュニティの運営も行いました。</p>
<p>プレイドでは2023年の4月からインターンとして勤務していて、最初は<a href="https://tech.plaid.co.jp/platform-engineering-kaigi-2024-report">認証基盤の開発</a>を行いました。その後Redisの監視を簡単にDatadogで行うための社内向けツールを開発し、2023年10月ごろから<a href="https://karte.io/package/message/">KARTE Message</a>というプロダクトの開発を行うチームに加わり、開発を行っています。</p>
<h1>KARTE Messageについて</h1>
<p>KARTE Messageは、データを元にメールやプッシュ通知、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<div class="iframely-embed" data-embedded-url="https://karte.io/package/message/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://karte.io/package/message/" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fkarte.io%2Fpackage%2Fmessage%2F&key=878c5bef402f0b2911bf6d4ce6261abd">KARTE Message（マーケティングオートメーション/MA）｜顧客体験を磨きこみ、自動化のその先へ【KARTE（カルテ）】</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script> 
<h1>課題</h1>
<p>KARTE Messageの機能であるスマホアプリ向けのプッシュ通知配信では月間1億通を超える規模の配信を行っています。</p>
<p>今回、プッシュ通知に利用しているFCMの<a href="https://firebase.google.com/docs/reference/admin/node/firebase-admin.messaging.messaging.md?hl=ja#messagingsendall">sendAll API</a>が2024年の6月20日に廃止されることが決定し、この期日までに今後も引き続き使用できるAPIに乗り換える必要がありました。</p>
<p>また、これまで使用していたsendAll APIでは、最大500件の通知をバッチ的に送信することができましたが、これと完全に互換性のあるAPIは現在用意されておらず、1通1通を個別に送信する必要があります。</p>
<p>今回私はこのリプレース作業を担当することになりました。</p>
<h1>テスト送信の実装・切り替え</h1>
<p>最初に、移行時のリスクが小さいテスト送信から置き換えることとなりました。本番送信もテスト送信も1通1通を個別に送信するロジックは同じであり、違いは送信数です。そのため、テスト送信の実装を先に行いリリースすることで、バグがあった際の影響範囲をテスト送信のみに抑えつつ新しい実装の信頼性を検証することができます。テスト送信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>既存のコードとドキュメントを読み理解する</li>
<li>テスト送信の実装</li>
<li>テスト送信の実装の置き換え</li>
</ol>
<h3>1. 既存のコードとドキュメントを読み理解する</h3>
<p>既に動いているシステムをリプレースするため、まずは既存のコードを理解する必要がありました。コードを読むだけではなかなかコードの振る舞いを把握するのが難しいので、単体テストを新たに追加しました。</p>
<h3>2. テスト送信の実装</h3>
<p>リプレースする際のリスクを最小にするために、新規実装では既存の実装と同じケースの単体テストを書き、既存実装、新規実装ともにテストケースと結果が同じになることを確認することで、実装ミスがないかを検証しました。また、新規実装では、Goの実装が約1200行なのに対してテストコードは約5600行あります。テストはローカル環境で実行することができ、キャッシュがない状態でも30秒ほどで終了します。また、これらのテストはGithubActionsで自動で実行されており、生産性向上につながっています。</p>
<h3>3. テスト送信の実装の置き換え</h3>
<p>無事に実装が終わりテストも通ったら本番環境のテスト送信をリプレースしました。これまでの業務でバグの修正や新機能の実装をした事はあったものの、今正常に動いているものを全く新しいコードで作成されたシステムに置き換える経験は初めてでとても緊張しました。リリースの実行は社員さんに行ってもらい、検証環境で最終動作確認を行いました。テスト送信のリプレース後には、ユーザ企業様からバグ報告が数件ありました。その中でもGoへのリクエストのJSONのフィールドにnullがあった場合、Goのjson packageではnilに変換されるという仕様があり、nilのハンドリングがうまくできていないコードでバグが発生したのが印象的です。いくつかのバグを修正し、無事テスト送信の実装をsendAll APIからsend APIに切り替えることができました。</p>
<h1>本番配信の実装・負荷試験・切り替え</h1>
<p>テスト送信の置き換えが終了しバグの修正も終わると、本番配信も新しいAPIに置き換えます。本番配信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>本番送信の実装</li>
<li>負荷試験</li>
<li>カナリアリリース</li>
</ol>
<h3>1. 本番送信の実装</h3>
<p>本番送信の実装に関しては本番送信とテスト送信のロジックを共通化したため、基本的にテスト送信の実装を流用する形で実装しました。</p>
<h3>2.  負荷試験</h3>
<p>本番配信では、KARTE Messageを使用されている企業様が大量のアプリユーザに向けてプッシュ通知を送信します。また、お客様が設定した速度で正しく配信する必要があります。そのため、アプリケーションに負荷がかかっても正常に動作することを検証する必要がありました。KARTE MessageはインフラにGCPのGKEを使用しているため、正しい速度で負荷がかかっても送信できる適切なk8sのスケーリング設定を見つける必要がありました。</p>
<p>負荷試験の環境には本番環境とは完全に切り離された検証環境を使用しました。検証環境は本番環境と同じシステムが動作しており、スケーリングの設定などが違うだけで本番環境と同じようにシステムが動作します。</p>
<p>負荷試験に関しては、社員さんからは時間かかってもいいからとりあえずやってみよう！といった感じで言われたので、ほぼ初めてGKEとその設定が書かれたk8s用のyamlファイルと戦うこととなりました。本番配信は、データベース、配信サーバ(今回作成したもの)、配信準備サーバなどさまざまなシステムが連携して動くことで実行されます。サーバやデータベースの状況はリアルタイムでdatadogで確認しました。</p>
<p>負荷試験の目標値は16667rps(時速6000万)となりました。これはAPI置き換え前のシステムで過去に負荷試験をした際の最大値となっています。</p>
<p>最初はスケーリングの設定を何も変えずに、2.7prs、277rps、1667rps、5555rpsと上げて行きました。すると、時速5555rpsの試験では設定した速度で配信されず1100rpsほどでしか配信できませんでした。ここから数時間悩んで色々設定を見ているうちに、配信サーバのスケーリング設定が問題になっていることに気づきました。最大node数とpod数が非常に小さい数に設定されていて、一定以上の負荷に耐えられないようになっていました。そこで、podの最大数を500、nodeの最大数を250に設定し再度負荷試験を行ったところ、16667rpsを達成できました。この時、配信サーバのpod数は100台ほどにスケーリングしていました。</p>
<p>目標値をクリアしたので、次に最適な設定を探します。KARTE Messageではサービスの性質上、リクエストのスパイクが発生しやすいです。また、深夜帯などは配信がなくサーバに負荷がかからない状態になります。そのため、スパイクに耐えられる最小pod数と、最大負荷に耐えられる最大pod数を見つける必要があります。そこで、1podあたりどれくらいの配信数を捌けるのかを調査しました。調査するために、pod数を20台固定にし少しづつ少ない配信数から負荷試験を行い、限界の配信速度を見つけ出しました。20台のpodで2700万/hの配信を行うことができました。pod1台で約135万/hの配信が可能です。そこで、6000万/hの配信に耐えられるpod数より少し余裕を持たせた50を、最大pod数としました。</p>
<p>負荷試験だけで10営業日ほどかかりました、負荷試験の勘所やk8sの特性を理解するのに時間を要しました。初めてやることは、手探りで頑張ってみることも大事ですが、社員さんなど経験がある人にある程度、勘所を先に教わっておくともっと効率良くできたかなと感じました。学生が簡単に経験することができない、k8sを用いたシステムの負荷試験ができたことは非常に良い経験となりました。</p>
<h3>3. カナリアリリース</h3>
<p>負荷試験も終わり、ついに本番配信を新しいAPIに置き換えます。全ユーザに一斉に適用してしまうと、もしもバグなどがあった場合に影響範囲が広くなってしまうため、一部のお客様から順次新しいAPIを適用しました。APIの切り替えは環境変数で指定した特定のお客様の時のみ新しいAPIが実行されるように実装を行いました。環境変数で切り替えを行うことで、もし新しいAPIの実装に問題があった際に、修正やロールバックしたアプリケーションをデプロイすることなく、環境変数を切り替えるだけで既存のAPIの実装に戻せるため、環境変数を活用したカナリアリリースを行いました。カナリアリリースは、置き換え前と比べて、悪化している指標がないか確認しながら約1ヶ月かけて全てのお客様の配信APIを新しいAPIに切り替えました。</p>
<h1>リプレース結果</h1>
<p>リプレースは実装を始めてから約5ヶ月で終了しました。結果として、新しいAPIに切り替えたことによる大きな障害はありませんでした。そして、既存実装よりもエラー率も下がりました。</p>
<h1>最後に</h1>
<p>今回のプッシュ通知配信で使用するAPIのリプレースの実装、試験、移行は全て自分の手で行いました。もちろん社員さんの助けなしではできなかったです。今回のプロジェクトを通して長期インターンでしか体験できない貴重な経験ができました。また、自分は京都に住んでいるのでリモート勤務だったですが、地方に住んでいる学生についてはリモートでも受け入れてくれる環境は非常にありがたかったです。他のインターン生が行ったことについては、ぜひプレイドのエンジニアブログをご覧ください[1][2][3][4][5]。このような経験をしてみたい方、プレイドに興味を持った方は下記からプレイドのエンジニアインターンに応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>[1] <a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a></p>
<p>[2] <a href="https://tech.plaid.co.jp/intern-at-plaid-calloc">プレイドインターン体験記: はじめての開発インターンを通じて得た学び</a></p>
<p>[3] <a href="https://tech.plaid.co.jp/intern-at-plaid-kenshin">プレイドでの開発インターン: 3ヶ月のフルタイムエンジニアとしての挑戦を経て</a></p>
<p>[4] <a href="https://tech.plaid.co.jp/intern-at-plaid-shohei-shiraki">プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び</a></p>
<p>[5] <a href="https://tech.plaid.co.jp/mongo-atlas-to-bigquery">MongoDB AtlasからBigQueryへのリアルタイムレプリケーション</a></p>


KARTE Messageで使用しているFCMのsendAll APIが廃止となるため、APIの置き換えを行った後負荷試験を行なった。

FCMのSendAll API廃止対応

KARTE MessageにおけるFCMのSendAll API廃止対応について

カラムナフォーマットの利点を最大限活かすために書き込み処理、特にリアルタイムの書き込み処理における技術的な課題とOSS DBの具体的なアプローチを紹介しています

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 - PLAID engineer blog

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 

<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

<p>エンジニアチームの mkataigi です。たまには趣向を変えて、エンジニアっぽくないコードの出てこない話を書いてみようかなと思います。以下多分に個人の見解です。</p>
<p>ベンチャーに限らず、あらゆる組織において「最良の結果」を出すことは大事です。「最良の結果」を出せない組織は、一時的には成功したとしても、いずれ「最良の結果」を出した組織に追い抜かれてしまいます。一見着実に進んでるように見えるのに、なぜか競合に差をつけられていく、イノベーションのジレンマというやつですね。</p>
<p>有名な言葉ですが『「最良」の敵は「良」である』と言う言葉があります。人間の時間は有限なので、やったほうがいい（=良）ことをやり続けてしまうと、最大の結果（=最良）を出すための時間がなくなってしまう。つまり、組織が成功し続けるためには、常に「最良の結果」にフォーカスし続けることが必要、ということです。</p>
<p>なお、参考文献は以下になります。</p>
<ul>
<li>イシューからはじめよ―知的生産の「シンプルな本質」
<ul>
<li><a href="https://www.amazon.co.jp/dp/4862760856">https://www.amazon.co.jp/dp/4862760856</a></li>
</ul>
</li>
<li>仮説思考 BCG流 問題発見・解決の発想法
<ul>
<li><a href="https://www.amazon.co.jp/dp/4492555552">https://www.amazon.co.jp/dp/4492555552</a></li>
</ul>
</li>
</ul>
<h1>解くべき課題を考える</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/">http://www.projectcartoon.com/</a></p>
<h1>最良の課題の条件</h1>
<p>では「最良の結果を出すための課題」を発見するにはどうすれば良いのでしょう。見つける方法を考える前に、まず、自分たちがどんなものを探すのかを明確にするために、どんな課題が最良の課題なのはっきりさせましょう。以下の３点がポイントかなと思います。</p>
<ul>
<li>その課題が解決されることで、将来に大きな影響を与える</li>
</ul>
<p>まず一つ目が、その課題が解決されると将来の展開が大きく変わるもの、になります。その課題が解決されることで別の課題をそもそも解く必要がなくなる課題です。</p>
<pre><code class="language-plaintext">「運転の自動化」という課題が解決されたら、
「大阪への移動経路を探す」「電車内で寝過ごさないようにする」などの課題が、そもそも課題ですら無くなる
</code></pre>
<ul>
<li>その課題は自分だけが解決できる</li>
</ul>
<p>次がなぜ自分がその課題に取り組むか、の部分です。自分以外の人には解決できないけど自分にだけ解決できる課題というのは、自分が解決しないとずっと課題のまま残り続けるため、より解決する重要度が高い問題となります。組織としてもそれがいわゆる競合優位性に繋がるので重要です。</p>
<pre><code class="language-plaintext">「大阪へ直行する路線を作ってしまう」ことができれば、
大阪へ行くための方法を探す必要は無くなる
</code></pre>
<p>（自分にはできないが、世の中にはできる人がいるかもしれない！）</p>
<ul>
<li>その課題に答える方法がある</li>
</ul>
<p>そして当たり前ですが、課題の答えを出せる、出す方法を思いつけることが重要です。結果を出すという観点から考えるとアウトプットが無いと無意味です。</p>
<pre><code class="language-plaintext">「ワープ」する機械を開発できれば大阪へ行くための方法を探す必要はないが、
現代の技術ではできる可能性は非常に薄い
</code></pre>
<h1>最良の課題を見つける方法</h1>
<p>最良の課題をテクニカルに見つける方法を、、、といきたいのですが、課題の定義からもわかる通り、誰にでも同じ方法で見つけられる、というものでは無いようです。とはいえ、それで諦めるのではなく、見つける可能性を高める方法を考えてみたいと思います。</p>
<p>一般的な方法として、最良の課題を探り当てられなくても、「これは良い課題かな？」というところから課題をブラッシュアップして最良に近づけていく思考法を考えてみます。状況によらずに常に成り立つ課題は、将来への影響が大きい可能性が高いと言うことはできそうです。</p>
<ul>
<li>極端な状態を考える</li>
</ul>
<p>状況を極端にしてみることで、状況が変わっても変わらない課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">毎日大阪にいく場合はどうすればいいか
お金を無限に持っている場合にはどうするか
逆にお金がない場合はどうするか
</code></pre>
<ul>
<li>別の人の視点から考える</li>
</ul>
<p>複数の人の視点の重ね合わせることで、誰から見ても重要な、課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">老人が大阪へいきたい場合はどうすればいいか
外国人ならどうするか
</code></pre>
<ul>
<li>抽象化したり具体化したりする</li>
</ul>
<p>課題を抽象的にしてみたり、具体的にしてみたりすることで、普遍的な課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">抽象的にして別の場所に時間通りに着くにはどうするか
具体的にして大阪に15時に着くにはどうするか
</code></pre>
<h1>さいごに</h1>
<p>以上、最良の課題を見つけるための方法について見てきました。プレイドでも「データによって人の価値を最大化する」ために、日々最良の課題を発見するために奮闘しています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、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>


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

最良の課題を発見する技術 | 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で記述する上での工夫などについても解説しています。

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと | PLAID engineer blog

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと

<p>はじめまして。デザイナーの @kazutokojima です。<br>
KARTEを実際に利用されている方の目線でプロダクトの使い勝手や体験を良くしていく「Kaizen」チームとして活動しています。</p>
<p>今回は、昨今よく聞くコンピュテーショナルデザインの考え方とその取り組みについてお話します。</p>
<hr>
<h2>デザインの種類</h2>
<p>「<strong>Design in Tech Report</strong>」については、2015年版の最初のレポートから読まれている方も多いと思います。</p>
<p>最近ではTHE GUILD勉強会「Design in Tech Report 2018 を読み解く」でも取り上げられました。<br>
今回の記事を書く上でとても参考になったのですが、その内容が<a href="https://goodpatch.com/blog/1st-design-in-tech-report-2018-the-guild/">記事として公開</a>されていますので、もしまだお読みでない方はぜひ読んでみてくださいね。</p>
<p>さて、同レポートでは2016年版から「<strong>３つの種類のデザイン</strong>」が提唱されています。</p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/3XJKMfA5UIw6Rw?startSlide=47" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/johnmaeda/design-in-tech-report-2016-59530038" title="Design In Tech Report 2016" target="_blank">Design In Tech Report 2016</a> </strong> from <strong><a href="//www.slideshare.net/johnmaeda" target="_blank">John Maeda</a></strong> </div>
<p>上記のスライドを参考にそれぞれ見てみましょう。</p>
<h4>クラシカルデザイン：</h4>
<p>ロゴやポスターや建築、家具などデザイナー自身の意匠により最終的な完成品を仕上げることを目的としたデザインを指してそう呼んでいるようです。一般的に、他者への影響力や受賞歴など外部的な要因が成果となるようです。</p>
<h4>デザイン思考：</h4>
<p>同レポートではユーザーニーズ（共感）からビジネス上の課題（バイアス）を見つけ出し問題解決するために用いるプロトコル（手順）を指してそう呼んでるように思います。クラシカルデザインとは対象に、複数のステークホルダーとの合意形成など内部的な要因が成果となることが多いです。</p>
<h4>コンピュテーショナルデザイン：</h4>
<p>本来は設計などの知的作業をコンピューターに任せる新しいデザイン手法を指すようですが、同レポートでは利用環境や利用者数などの違いからクラシカルデザインと対比して、永遠に持続することを目的としたデザインというように捉えることができると思います。常に変わり続けて完成しないため、成長を続けていることだけが成果と言えるかもしれません。</p>
<br/>
<br/>
と、同レポートに記載されている内容を書き出してみました。
<p>それぞれのデザインの違いと、コンピュテーショナルデザインをどういう文脈で語ろうとしているかについてはご察しいただけたかと思いますが、これだけでは「コンピュテーショナルデザイン」がどういうものかまだピンと来ないですね。</p>
<p>では、どういう文脈でコンピュテーショナルデザインを語ろうとしているかという前提が共有できたものとして、今回の記事の本題に入っていきたいと思います。</p>
<hr>
<h2>デザインのScaleの関係</h2>
<p>ここから今回の記事の主張に入っていきたいと思います。</p>
<p>さきほどのスライドの図では、よく見ると3つの種類のデザインを「<strong>Scale</strong>」という横軸をとって並べています。<br>
その関係性を知ることで、コンピュテーショナルデザインをより立体的に理解出来るようになります。</p>
<p>では、「クラシカルデザイン」→「デザイン思考」→「コンピュテーショナルデザイン」のScaleの関係を整理してみましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8fcd9593-d113-418d-938e-7571482ff9d2/Untitled---New-frame--2-.jpg" alt="Untitled---New-frame--2-"></p>
<h5>→ クラシカルデザイン</h5>
<p>クラシカルデザインで重要なポイントとして「デザインをモノに定着させること」が挙げられます。<br>
デザイナー自身の意匠により見た人にとって良いと思えるような完成品に仕上げることはデザインにとって最重要と言えます。</p>
<p>まずは、クラシカルデザインのキーワードを「<strong>定着</strong>」としてみます。</p>
<h5>クラシカルデザイン → デザイン思考</h5>
<p>本来の「クラシカルデザイン」は才能ある個人による専門領域と言えますが、徐々にチームで対抗するプロセスが生まれていきます。自身の発想に依るのではなく、他者のニーズから着眼点を得る手法は今日ユーザー中心デザインなどと呼ばれています。</p>
<p>天才でなくともよいデザインが生み出せるようになり製品・サービスのコモディティ化が進むと、クラシカルデザインで言う「定着」作業の前段階においてさらに大きな視点で考えよう、という流れが出てきます。</p>
<p>そして、ユーザー中心にビジネス全体を考える「デザイン思考」が大きく注目されます。<br>
デザイン思考を広めたとされるIDEOのCEOティム・ブラウンは以下のように述べています。</p>
<blockquote>
<p>デザイナーの感性と手法を用いて、顧客価値と市場機会の創出をはかるもの</p>
</blockquote>
<p>デザイン思考は、「定着」作業を除くユーザー中心のクラシカルデザインのプロセスと同じと言えます。<br>
クラシカルデザインとの親和性はもちろん、デザイナーだけでは困難な規模の「発想」が出来るようになった点に「クラシカルデザイン→デザイン思考」のScaleの関係性をとることが出来ます。</p>
<h5>デザイン思考 → コンピュテーショナルデザイン</h5>
<p>クラシカルデザインとデザイン思考が深く結びついたことで、製品やサービスの品質は今まで以上に向上しています。</p>
<p>ただ、近年スマートフォンなどのテクノロジーが急速に発展を遂げながら個人に行き渡り、たくさんの人たちのコンテクストが実データとして得られるようになると、ユーザー中心に課題を捉えて解決策を形にするというプロトコルは、ユーザーからの情報量の増加に対してアウトプットのスピードが足りない、という事態に陥っているように捉えられるようになります。</p>
<p>そうなると、1つのモノに関わる利用者数の増加やテクノロジーの進歩に対して、ユーザーのニーズを満たす製品・サービスを提供するための考え方が必要とされるようになります。</p>
<p>そして、コンピュテーショナルデザインがそれにあたるのではないか、と同レポートからは受け取れるように思います。コンピュテーショナルデザインの核が、完成を求めず常に進化を続けることなら、別の言い方をすると、持続可能性を担保することとも表現できます。</p>
<p>それを「デザイン思考→コンピュテーショナルデザイン」のScaleにあてはめて考えると、デザイン思考で得た「発想」を「持続」して成長させ続けることができる関係が見えてきます。</p>
<br/>
<br/>
こうしてScaleの関係を整理してみると、3つの種類のデザインには密接な関わりがあり、またそれぞれのデザインへの取り組みが製品やサービスを大きく成長させるために必要だと言えることがわかりました。
<p>KARTEという自社のプロダクトに関わり、大きく成長しようとしている今、まさにこのコンピュテーショナルデザインの「持続」という考え方がぴったりとハマるように思います。そうすると、それをどのように実行していくのかが重要になってきます。</p>
<p>では、コンピュテーショナルデザインの取り組みへの第一歩として、KARTEで具体的にどのようなアプローチを進めているのかを見ていきましょう。</p>
<hr>
<h2>コンピュテーショナルデザインの第一歩</h2>
<p>「発想」を「持続」するために何から始めると良さそうか。</p>
<p>デザイン思考のScaleとしてコンピュテーショナルデザインを捉えると、製品やプロダクトのデザイン面だけの成長だけでなく、中期・長期的には組織の成長にも適用していけるように思います。</p>
<p>私個人としては、コンピュテーショナルデザインへの第一歩は将来的には組織・チームとしての持続性の醸成につなげていくためのものと考えています。</p>
<p>少しづつコンピュテーショナルデザイン的な考え方を広げていくために、個人規模で出来ることから探ってみます。<br>
まず、デザイン思考で上手く行かない部分からきっかけを見つけようと思います。</p>
<p>デザイン思考で「発想」し続けることが難しいと思われる理由に、ユーザー中心デザインの核とも言える「ペルソナ」が機能しないと思える点が多いことが挙げられます。</p>
<p>事実、KARTEのプロダクトにおいても業種や役職など多種多様で、チーム内でのブレない人物像を作り上げることは非常に困難なことです。仮に時間をかけて作成したとして、そのペルソナの行動の背後にある状況については推測が多くなるのが実際で、実データを原動力とするコンピュテーショナルデザインにおいては推測する時点ですでに不適合だと感じてしまいます。</p>
<p>ペルソナが上手く機能しづらい「事実」や「スピード」の要素を補完する他の方法はないかと検索していると、<a href="https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/">こちらの記事</a>で「<strong>Job Story</strong>」という手法の存在を知りました。</p>
<p>記事の主旨は、ペルソナを使用するユーザーストーリーの代替として、ユーザーのジョブに着目したJob Storyの利点についての説明になります。ジョブという言葉が示すように、クレイトン・Ｍ・クリステンセン氏のJTBDの考え方をベースとしているようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/550204c1-a2a9-481f-ae28-8f71e07b462e/Untitled---New-frame--1-.jpg" alt="Untitled---New-frame--1-"></p>
<p>ユーザーストーリーは、ユーザーが実現したいことやユーザーにとって価値があることを簡潔にまとめた文章のことで、アジャイル開発などでよく使われるモデリングの手法のようです。短い期間でイテレーションをまわすアジャイル開発において、ユーザーストーリーはそれ自体が機能要件として扱われることもあるようです。</p>
<p>対してジョブストーリーは、アジャイル開発におけるユーザーストーリーの機能的な側面を持ちつつ、ペルソナなどの推測部分を取り除くことで、ストーリーの因果関係をより明確にすることが出来ると説明されています。</p>
<p>両者の違いとして前者は「誰の」視点なのかにフォーカスしているのに対し、後者は「どういう時に」という状況にフォーカスを置いています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3dd5c4a9-5675-428c-9bef-b01326cd5398/Untitled---New-frame--5-.jpg" alt="Untitled---New-frame--5-"></p>
<p>具体的にどういう違いがあるかを書いて比べてみます。</p>
<p><strong>ユーザーストーリー：</strong></p>
<ol>
<li>マーケターとして</li>
<li>ユーザーの個別の行動を知りたい</li>
<li>だからKARTEを使う</li>
</ol>
<p><strong>ジョブストーリー：</strong></p>
<ol>
<li>ユーザー獲得もいよいよ天井が見えてきて、ユーザーごとの売上を伸ばすのが重要になってきた</li>
<li>ユーザーの個別の行動を知りたい</li>
<li>だからユーザーに対して個別にアクションを行え、LTVを高めやすいKARTEを使う</li>
</ol>
<p>あくまで例ですが、フォーカスを置く対象が変わることで、前提条件との因果関係がよりはっきりするように思います。また、同じような規模のサービスが似た状況にあるだろうことも事実に基づいて考えることが出来ます。KARTEで言えば、「似た状況にあるサービスの数」×「LTVを高めるためのアイデアのインパクト」から優先度の決定までスムーズに行えそうです。</p>
<p>「Job Story」であれば、事実に基づき素早く判断して製品やサービスの成長を「持続」させることが出来そうなので、まずは下記の要望・フィードバックフォームを作成するところから始めました。</p>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/65513e5f-0e46-46aa-9f92-148a3924ca2a/----------2018-08-06-22.05.32.png" width="50%">
<p>最初ということもありわりと忠実にJob Storyを再現しています。<br>
当初は本当に和訳に近い形式で制作していたのですが、チームのメンバーにレビューを受ける中で日本語との違いや、文章の理解にブレが生じやすいことがわかったので、何度か修正を繰り返してこのフォーマットにしています。</p>
<p>現在は、このフォームを手始めに、いくつかある要望やフィードバックを受け付ける際のフォーマットを同じようなものに統一していきたいと考えています。また、チーム内でもジョブの考え方が広まってきており、少しづつユーザーの状況にフォーカスする取り組みが増えてきています。</p>
<p>直近は、ユーザーからの要望やフィードバックに細かな粒度で個別に素早く対応することになると思いますが、このようなフォーマットで要望やフィードバックを積み重ねていけば、本質的な改善を事実に基づいてブレのない状態でチームとしてこなせるようになるのではないかと期待しています。</p>
<p>事実に基づいていれば情報や判断に迷いが無くなるので当然スピードも上がります。また、足し算的な修正ではなく、引き算を含めた本来の意味での改善にも根拠を持って取り組めるようになります。</p>
<p>こうして、コンピュテーショナルデザインの言う常に変わり続けることを「持続」し続ける状態を生み出し、さらにこの繰り返しがやがて本来の意味でのコンピュテーショナルデザインに合流できれば良いなと思います。</p>
<h2>終わりに</h2>
<p>というわけで、自分なりの考えでコンピュテーショナルデザインの第一歩に「Job Story」を選び、実際にトライをしてみている、というお話でした。</p>
<p>ネット上では、「ペルソナに変えてJTBDモデルにしよう」という記事もたくさん見かけまし、それがベースとなっている「Job Story」自体は非常に有効なのではないかと思っています。</p>
<p>とはいえ、今回ご紹介した要望やフィードバックの集め方は遅効性の高い取り組みで、コンピュテーショナルデザインに求められるデータ駆動のスピードを獲得するにはまだまだ時間がかかりそうに思います。まだまだ工夫が必要そうです。</p>
<p>この記事を読んで、興味を持つきっかけや何かの助けになりましたら幸いです。</p>
<hr>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体のデザインに興味がある！というデザイナーを募集しています。</p>
<p>詳しくは <a href="https://plaid.co.jp/recruit.html#designer">弊社採用ページ</a><br>
または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a></p>
<p>をご覧ください。</p>
<p>もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</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>
<hr>
<p>最後までお読みいただきありがとうございました!</p>


スケールには必要？コンピュテーショナルデザインの考え方とその取り組み

<p>はじめまして。プレイドの @tomoponzoo です。<br>
2018年4月に入社、現在プレイド暦4ヶ月目のエンジニアです。<br>
プレイドでは、今年の3月にローンチした「<a href="https://karte.io/product/app/">KARTE for App</a>」のモバイルSDK開発をメインで担当しております。</p>
<p>開発に携わって4ヶ月が経ちましたが、今でもSDKをリリースする際は緊張してしまいます。それはSDKに非常に高いレベルの品質が求められるからです。</p>
<p>今回は、SDK開発の勘所や品質の重要性、仮にSDKで問題が発生してもアプリを絶対に死なせないための方法について考えていきたいと思います。</p>
<h2>SDK開発の勘所 - 品質の重要性</h2>
<p>冒頭で述べた通り、非常に高いレベルの品質が求められるSDKですが、それはなぜでしょうか？</p>
<p>仮に低品質なSDKを組み込んだ時に起こり得ることについて、想定してみます。</p>
<ul>
<li>アプリがクラッシュするなどの問題が頻発</li>
<li>アプリクラッシュにより、エンドユーザーの体験が悪化</li>
<li>エンドユーザーの体験が悪化することにより、クライアントのビジネスに悪影響を及ぼす</li>
<li>最終的には自らのビジネスも毀損する</li>
</ul>
<p>以上のように考えると、なぜSDKに高い品質が求められるのか理解できると思います。</p>
<p>このように高いレベルの品質が求められるSDKですが、開発するためには、エンジニアの想像力や品質への拘りが重要になります。これは非常に大変ですが奥深く面白い部分でもあります。</p>
<h2>品質維持のためのアプローチ</h2>
<p>では、高い品質の維持、また万が一問題が発生したときに影響を最小限に抑えるためにどんなことができるでしょうか？</p>
<ul>
<li>問題を起こさない仕組みを整える
<ul>
<li>ソースコードレビューの実施</li>
<li>テストの自動化</li>
</ul>
</li>
<li>問題が発生したときに影響を最小限に抑える仕組みを整える
<ul>
<li>確実なエラーハンドル</li>
<li>プロセス分離</li>
</ul>
</li>
</ul>
<p>このように品質維持のためのアプローチは様々ですが、今回は表題にもあるとおり、堅牢なSDKを実現するための方法として「プロセス分離」について考えてみます。</p>
<h2>堅牢なSDKを目指す！</h2>
<p>プロセス分離 - これはアプリケーションのプロセスと、SDKのプロセスを分離することです。<br>
プロセスを分けることで、仮にSDKのプロセスがクラッシュしたとしても、アプリケーションのプロセスには影響を与えず、処理を継続することが可能になります。</p>
<p>なお本質的には、SDKがクラッシュしないように実装すべきです。<br>
ただし人間が作る以上、バグが入り込む可能性は0ではありません。もちろんバグが入り込まないように様々な対策を行うわけですが、それらをすり抜けバグが入り込む可能性は否定できません。<br>
万が一の事態におけるフェイルセーフとしてプロセス分離を活用すべきです。</p>
<p>ちなみに、iOSプラットフォームにおいてプロセス分離を行うのは至難の業です。というのも通常のアプリケーションからはプロセスを自由に生成することができません。そのため今回はその制限の中でどうやってプロセス分離を実現するか試行錯誤しながら考えていきたいと思います。</p>
<h2>マルチプロセス（プロセス分離）を実現するための手段</h2>
<p>では、マルチプロセスを実現する場合にどんな手段があるでしょうか？<br>
パッと思いつくものを列挙してみました。</p>
<ul>
<li>fork</li>
<li>App Extension</li>
</ul>
<h2>forkとは？</h2>
<p>あまりにも有名で説明は不要かと思いますが、forkはUNIXシステムにおけるシステムコールのひとつです。<br>
forkを使うことで、これを呼び出したプロセスのコピーを生成することができます。</p>
<p>iOSは、UNIX系システムのひとつであるため、forkを使うことが可能です。</p>
<h2>forkを試す</h2>
<p>では、早速forkを使ってプロセスの生成ができるか試してみたいと思います。<br>
まずXcodeで適当なプロジェクトを作成、<code>main.c</code> を以下のように修正し、シミュレーターで実行してみます。<br>
うまく行けば、子プロセスが作成されプロセス分離への道が開けます。</p>
<pre><code class="language-obj-c">int main(int argc, char * argv[]) {
  pid_t pid = fork();
  if (pid == -1) {
    NSLog(@&quot;fork() failed&quot;);
  } else if (pid) {
    NSLog(@&quot;[Parent] PID: %d, PPID: %d&quot;, getpid(), getppid());
  } else {
    NSLog(@&quot;[Child]  PID: %d, PPID: %d&quot;, getpid(), getppid());
  }
}
</code></pre>
<pre><code class="language-plaintext">2018-07-28 17:35:45.858546+0900 MultiProc[39705:13798053] [Child]  PID: 39705, PPID: 39702
2018-07-28 17:35:45.858704+0900 MultiProc[39702:13797947] [Parent] PID: 39702, PPID: 39703
</code></pre>
<p>おっ！意外にも、あっさりプロセスの生成ができてしまいました。<br>
子プロセスの親プロセスIDを確認すると、親プロセスのIDと一致しており、親子関係があることが確認できます。</p>
<p>同じことを実機を使ってやってみたいと思います。</p>
<pre><code class="language-plaintext">2018-07-28 18:17:47.617257+0900 MultiProc[4926:1877048] fork() failed
</code></pre>
<p>今度は失敗しました。<br>
iOSでは、アプリケーションの<a href="https://developer.apple.com/jp/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html">バックグラウンド実行</a>にかなりの制限があります。そのため独自にプロセスを生成して動かすこと自体不可能なのでは？と思っていましたが、やはり当初の想定通りダメなようです。</p>
<h2>App Extensionとは</h2>
<p>forkがダメだったので、もうひとつのアプローチについて考えてみます。</p>
<p>App Extensionですが、 <a href="https://developer.apple.com/jp/documentation/General/Conceptual/ExtensibilityPG/index.html">App Extensionプログラミングガイド</a>で説明されている通り。<br>
iOSアプリケーションを拡張する仕組みのひとつです。アプリケーションとは分離された別のプロセスとして動作するのが特徴です。</p>
<p>アプリケーションを拡張するために用意された仕組みであるため、通常はAppleが用意した拡張ポイントに対応するExtensionしか開発できません。<br>
今回は、プロセス分離を実現すべく非公開の拡張ポイントを利用して独自のExtensionを作ってみます。</p>
<h2>App Extensionの仕組み</h2>
<p>独自のExtensionを作る前に、Extensionの仕組みについてみておきます。</p>
<p><strong>Extensionのライフサイクル</strong><br>
通常は停止しています。<br>
アプリケーションからのリクエストに応じて起動し、処理を実行、最後に結果をレスポンスし、終了する流れになります。</p>
<p><strong>Extensionとのやりとり</strong><br>
アプリケーションとExtension間のやりとりには、XPCと呼ばれる仕組みが利用されており、シリアライズしたプロパティリストをやりとりすることでプロセス間通信が実現されています。<br>
なお実際にやりとりを行う際は、XPCをラップしたNSExtensionと呼ばれる非公開クラスを利用して、やりとりを行うことになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1704575d-34af-4e4b-a1da-d28ace594fa2/extension.png" alt="extension"></p>
<h2>App Extensionを作る</h2>
<p><strong>注意！！！<br>
App Extensionの作成過程で非公開APIを利用しています。<br>
非公開APIを利用した場合、審査でリジェクトされる可能性がありますのでご注意ください。</strong></p>
<p>では、Extensionを作っていきましょう。<br>
適当なプロジェクトを1個作成しておきます。</p>
<h4>1. App Extensionを作成</h4>
<p>任意のテンプレートを利用してExtensionを作成します。</p>
<h4>2. App Extensionの設定を修正</h4>
<p>Info.plistにExtensionの拡張ポイントや主要クラスの設定があるので、以下のように修正します。</p>
<pre><code class="language-xml">&lt;key&gt;NSExtension&lt;/key&gt;
&lt;dict&gt;
　&lt;key&gt;NSExtensionPointIdentifier&lt;/key&gt;
　&lt;string&gt;com.apple.app.non-ui-extension&lt;/string&gt;
　&lt;key&gt;NSExtensionPrincipalClass&lt;/key&gt;
　&lt;string&gt;Extension&lt;/string&gt;
&lt;/dict&gt;
</code></pre>
<h4>3. 非公開APIのインターフェースを定義</h4>
<p>NSExtensionは非公開のAPIです。<br>
利用するためには、APIに対応するヘッダーファイルを各々で用意する必要があります。</p>
<p>なお非公開APIのインターフェースを調べるには、<a href="http://stevenygard.com/projects/class-dump/">class-dump</a>などのツールを利用します。</p>
<p>今回は、以下のようなヘッダーファイルを作ります。</p>
<pre><code class="language-obj-c">@interface NSExtension : NSObject
+ (instancetype)extensionWithIdentifier:(NSString *)identifier error:(NSError **)error;

- (void)beginExtensionRequestWithInputItems:(NSArray *)inputItems completion:(void (^)(NSUUID *requestIdentifier))completion;
- (int)pidForRequestIdentifier:(NSUUID *)requestIdentifier;
- (void)cancelExtensionRequestWithIdentifier:(NSUUID *)requestIdentifier;

- (void)setRequestCancellationBlock:(void (^)(NSUUID *uuid, NSError *error))cancellationBlock;
- (void)setRequestCompletionBlock:(void (^)(NSUUID *uuid, NSArray *extensionItems))completionBlock;
- (void)setRequestInterruptionBlock:(void (^)(NSUUID *uuid))interruptionBlock;
@end
</code></pre>
<h4>4. ホストアプリケーションを実装</h4>
<p>Extensionとプロセス間通信を行うために、NSExtensionクラスのインスタンスを生成し、リクエスト処理やレスポンス処理を実装します。</p>
<p><strong>NSExtensionインスタンスの生成</strong></p>
<pre><code class="language-obj-c">NSExtension *extension = [NSExtension extensionWithIdentifier:@&quot;jp.co.plaid.MultiProc.Extension&quot; error:nil];

[extension setRequestCompletionBlock:^(NSUUID *uuid, NSArray *extensionItems) {
　　// リクエスト完了
　　NSLog(@&quot;Request completed: %@&quot;, uuid);
}];
</code></pre>
<p><strong>Extensionにリクエストする</strong></p>
<pre><code class="language-obj-c">NSExtensionItem *item = [[NSExtensionItem alloc] init];
[item setAttachments:@[@&quot;VALUE&quot;]];

[extension beginExtensionRequestWithInputItems:@[item] completion:^(NSUUID *requestIdentifier) {
　　int pid = [extension pidForRequestIdentifier:requestIdentifier];
　　NSLog(@&quot;Began extension request: %@. Extension PID: %i&quot;, requestIdentifier, pid);
}];
</code></pre>
<h4>5. Extensionを実装</h4>
<p>ヘッダーファイルを修正します。<br>
Extensionクラスが<a href="https://developer.apple.com/documentation/foundation/nsextensionrequesthandling?language=objc">NSExtensionRequestHandling</a>プロトコルに適合することを宣言します。</p>
<pre><code class="language-obj-c">@interface Extension : NSObject &lt;NSExtensionRequestHandling&gt;
@end
</code></pre>
<p>実装ファイルを修正し、NSExtensionRequestHandlingプロトコルに適合させます。</p>
<pre><code class="language-obj-c">@implementation Extension
- (void)beginRequestWithExtensionContext:(NSExtensionContext *)context {
　　// レスポンスを返す
　　[context completeRequestReturningItems:@[] completionHandler:^(BOOL expired) {
　　　　NSLog(@&quot;Completed request.&quot;);
　　}];
}
@end
</code></pre>
<h2>App Extensionを動かしてみる</h2>
<p>ここまでできたらシミュレーターで実行してみます。<br>
以下のようなログが出ればOKです。<br>
ホストアプリケーションのプロセスIDが74665、ExtensionのプロセスIDが74671となっており、それぞれ別のプロセスで動作していることが確認できます。</p>
<pre><code class="language-plaintext">2018-07-29 22:19:03.749751+0900 MultiProc[74665:14952372] App PID: 74665
2018-07-29 22:19:12.725051+0900 MultiProc[74665:14952478] Began extension request: 34E68F5B-520A-48EC-93EE-03599A310B24. Extension PID: 74671
2018-07-29 22:19:12.730459+0900 MultiProc[74665:14952478] Received response.
</code></pre>
<h2>App Extensionをクラッシュさせてみる</h2>
<p>さて、ここまで色々試してきましたが、ここで当初の目的である「SDKがクラッシュしても、アプリが絶対に死なない！」ことを確認してみたいと思います。</p>
<p>以下のように、Extensionをクラッシュさせるためのコードを入れて実行してみます。</p>
<pre><code class="language-obj-c">NSExtensionItem *inputItem = context.inputItems[1];
</code></pre>
<p>Extensionでは、NSRangeExceptionが発生しクラッシュしますが、アプリケーションは影響を受けず何事もなかったかのように動作しています。</p>
<h2>まとめ</h2>
<p>今回は「プロセス分離」という手段を用いて、堅牢なSDKを実現する方法とその可能性について探ってみました。</p>
<p>現状はプラットフォームとしての制約が大きく、また非公開APIを利用しないと実現できないなど、実際にプロダクトに適用するのは難しいということが分かりました。<br>
アプリケーションからプロセス生成できない理由として、端末の性能やリソース制約の問題が大きいと考えています。将来端末のリソース制約について考えなくて良くなった時には、このような手段も現実味を帯びてくるのではないかと思いました。</p>
<p>なお今回作成したアプリのソースコードは<a href="https://github.com/tomoponzoo/MultiProc">GitHub</a>で公開していますので、動作や実装が気になる方は、ぜひダウンロードして動かしてみてもらえればと思います。</p>
<h2>最後に</h2>
<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>


はじめまして。プレイドの @tomoponzoo です。
今回は、SDK開発の勘所や品質の重要性、仮にSDKで問題が発生してもアプリを絶対に死なせないための方法について考えていきたいと思います。

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法 | PLAID engineer blog

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法

<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日ゼロベースで議論する開発合宿@館山に行ってきました！

Engineer Blog

Recent Article

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

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

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと

スケールには必要？コンピュテーショナルデザインの考え方とその取り組み

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法

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

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

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

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

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

Archives

Writers

Recent Article

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

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

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと

スケールには必要？コンピュテーショナルデザインの考え方とその取り組み

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法

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

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

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

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

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

Archives

Writers

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