Engineer Blog

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

<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をカラムナに最適化する技術 

<h2>はじめに</h2>
<p>こんにちは，プレイドのCore Platformチーム<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>（プレイドで社内の全てのプロダクト基盤やリアルタイム解析基盤<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup><sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>を扱っているチーム）でインターンをしている<a href="https://lapla.dev/about/">lapla</a>といいます．プレイドでは2024年6月より働いており，この度社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います．<br>
データベースのバージョンアップは，データベースを使用しているシステムにとって避け難いタスクであり，それはプレイドも同様です．そこでプレイドでは， 単に公式のアップデートドキュメントを読むだけではなく， MongoDBの内部構造も理解した上で作業することにより，安全なバージョンアップを継続的にかつサービス無停止で行っています．今回はその点について説明しようと思います．<br>
なお，本記事はデータベースのいわゆるHow To記事ではなく， データベースの構造に興味のある方や， 既に他のデータベースを使用していて， 今後MongoDBを使ってみようという方向けに記述を行っているため， 前半にデータベースのバージョンアップに関する一般的な話や，プレイドでの使用状況を述べ，後半にMongoDBの内部構造に触れるという構成を取っています．</p>
<h2>自己紹介</h2>
<p>現在，筑波大学情報学群情報科学類の4年生で，主にシステムプログラミングやクラウドネイティブな技術に興味がありますが，OSから機械学習までレイヤを問わずにプログラムを書きます．<br>
趣味のプログラミングについて触れると，学部1年の頃に手が滑って，主にC++でx86_64向けのTCP/IPプロトコルスタックが搭載されたGUI操作可能なOSを書いた結果，その後も手が滑り続けて学部3，4年の頃にはRustで64bit RISC-V向けのOSを書いていました．他にもRust言語が好きなので，RustでELFのタイムトラベルデバッガを書いたり，ELFバイナリ難読化器（ELFバイナリの実行時の動作を変えずに，解析からの妨害対策がなされたバイナリを作り出す）を作っていたりしました．最近は内部でRISC-VバイナリをエミュレートするようなOCIコンテナランタイムを開発しています．<br>
比較的高いレイヤも好きで，例えば学部2年の頃には文章から音を生成するCGANを研究していたりしました．</p>
<h2>プレイドにおけるMongoDBとその周辺ソフトウェアの利用</h2>
<p>プレイドでは，主力プロダクトであるCXプラットフォーム<a href="https://karte.io/">KARTE</a>の様々な場面で主にMongoDBを使用しています．また，ODM（Object Document Mapper）として<a href="https://github.com/Automattic/mongoose">Mongoose</a>を用いていて，Node.js経由でMongoDBを操作しています．プレイドではサーバーサイドがほとんどNode.jsで書かれており，MongoDBは内部的にデータをBSONで保持している点や非同期処理との相性の良さという点でNode.jsとの親和性が高いため，積極的にMongoDBを使用しています．この辺りについては弊社のgamiが書いた「 <a href="https://tech.plaid.co.jp/plaid_loves_nodejs">PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと</a>」 をご覧ください．</p>
<h2>データベースのバージョンアップ</h2>
<p>さて， 冒頭にも述べた通り，データベースの定期的なバージョンアップは，多くのソフトウェア企業に付いて回るタスクの1つです．<br>
主にOSSとして公開されているような一般的なRDBをセルフホストしている場合において，バージョンアップなどの作業を行うためには，データの整合性を取るために一旦データベースへの書き込み処理を停止した上でレプリケーションをおこなってから，アプリケーションが参照するデータベースの接続先を変更する手順を踏むのが一般的と思われます．しかし，いわゆるNewSQLに属するMongoDBでは内部で複数同じ状態のデータを持つノードが複数おり、この特性を活用することで，プレイドでは平日の昼間であっても安全にバージョンアップの作業を行うことができています．<br>
なぜMongoDBの場合にはサービスを停止させずに， 安全にバージョンアップできるのかに関しては，本記事後半で紹介する，MongoDBの内部構造を，論文などを元にして理解することにより達成されています．平日昼間など，通常は忌避される時間帯であっても，安全性の根拠を持ってメンテナンスウィンドウなどを設けずにバージョンアップを行うことは，開発速度の向上などの開発者体験の向上に繋がります．また， サービスを停止させる時間が不要なことは，KARTEをご利用いただくユーザー様にとっても大きな恩恵があると考えます．</p>
<h2>今回のバージョンアップ完了までの手順</h2>
<p>ここでは今回行ったバージョンアップの大まかな手順について説明します．大枠としては以前にMongoDBをバージョン4からバージョン5に上げた際のものと同様です．当時の記録については以前インターンされていた方が書いた「<a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a>」に詳しく記載されていますので，ぜひご覧ください．</p>
<ol>
<li>アプリケーションコードに影響を与えそうな変更の調査<br>
まずはMongooseやMongoDB Serverの現在のバージョンから，バージョンアップする目標のバージョンまでの変更を確認し，主にプロダクトの動作に影響を与えそうなものをピックアップして調査しました</li>
<li>社内ライブラリのアップデート<br>
プレイド社内には，様々なアプリケーションが共用するライブラリが存在します．その中にはMongoDBのラッパーなども含まれているため，これらの更新を行いました</li>
<li>各アプリケーションのアップデート<br>
新しくなった社内のライブラリを用いて，各アプリケーションが動作するように修正を行います．この作業は基本的に各アプリケーションチームに依頼し，書き換えを行なってもらいました</li>
<li>データベースのアップデート<br>
最初に検証環境のデータベースのバージョンを上げ，問題がなさそうであれば本番環境のデータベースもバージョンアップを行います．この際に，本記事後半で触れる内部構造の理解により，安心感をもったバージョンアップを行えています．</li>
</ol>
<h2>バージョンアップ作業の今後</h2>
<p>現在は，バージョン7へのバージョンアップに必要な調査や実装を行っています．バージョン7へのバージョンアップに伴う，現状の我々のユースケースに大きな影響を与えそうなMongooseでの変更をいくつか紹介すると，次のようなものがあります：</p>
<ul>
<li>callbackを用いた処理を書くことができないようになる（社内のアプリケーションコードには，比較的昔に書かれたものではしばしばcallbackが使われている）</li>
<li>社内実装で多く使われている関数を使用できなくなる（findOneAndRemoveなど）</li>
</ul>
<p>このように，今後に控えているアップデートではより困難なアップグレード作業が予想されますが，今回のアップグレードで得られた経験も積極的に用いて，無事に作業を成功させるべく動いています．</p>
<p>—</p>
<p>ここからはよりMongoDBの内部構造を理解したい方向けに記述します．</p>
<h2>MongoDBの内部構造を想像する</h2>
<p>さて，冒頭でも述べた通り，本記事の後半ではMongoDBの内部構造について見ていきます. ここではあくまでも公開論文などをもとに内部の仕組みなどを想像して書いているため， 間違っている可能性は否定できないことを述べておきます.<br>
MongoDBの内部では，分散合意アルゴリズムとして著名なRaftを独自に改良したアルゴリズムを用いて合意を取っています．この機序を理解するためには次の3つの論文が特に参考になります：</p>
<ul>
<li><a href="https://raft.github.io/raft.pdf">In Search of an Understandable Consensus Algorithm (Extended Version)</a>（以下論文1）: 分散合意アルゴリズムのRaftについて紹介されている論文です</li>
<li><a href="https://www.usenix.org/conference/nsdi21/presentation/zhou">Fault-Tolerant Replication with Pull-Based Consensus in MongoDB</a>（以下論文2）: MongoDBの内部では，純粋なRaftアルゴリズムではなく，後述するPull-Based Consensusと呼ばれるアルゴリズムを用いてノード間での合意を取っています．このアルゴリズムについて解説した論文です</li>
<li><a href="https://dl.acm.org/doi/10.14778/3352063.3352125">Tunable consistency in MongoDB</a>: MongoDBでは，書き込みと読み込みの整合性をある程度自由に設定することができます（Tunable Consistency）．これによりアプリケーション特性に合わせた整合性を取ることができます．この内容についての説明がなされています</li>
</ul>
<p>今回はスペースの都合上，論文1で紹介されている純粋なRaftの動作についての説明はある程度既知のものとし，以降は論文2で提案されているpull-based Raftの動作について説明を行うことにします．</p>
<h3>Pull-Based Consensus</h3>
<p>先に述べた通り，MongoDBの内部では純粋なRaftではなく，動作が改造されたRaftアルゴリズムが用いられていて，これは論文内ではPull-Based Consensusとされています．本記事では，純粋なRaftの改造版であるということを強調するために，Pull-Based Raftと呼ぶことにします．<br>
まず一般的なRaftアルゴリズムは，次の図のように，LeaderノードからFollowerノードに対してログが配信され，Followerノードはそれを個々に有しているという構造を取っています．Leaderノードで何らかの不具合が起きると，クラスターはvotingを行い，新たなLeaderノードを選出します：<br>
<img src="https://ik.imagekit.io/plaid/0bd8ed16-d589-473f-8b78-7f10558ba122/image1.png" alt="image1.png"><sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup><br>
また，次図に示すように，クライアント側からのリクエストに対しては複数のモジュールにログが分散して保存されます：<br>
<img src="https://ik.imagekit.io/plaid/77f8ba01-c659-4897-84a7-0d49418acd13/image3.png" alt="image3.png"><sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup></p>
<p>分散合意を取るという目的であればこれで十分ですが，スケーリングやバージョンアップの際など，クラスター内のノードが増減する場合においては，データの同期を柔軟に行うのが難しいといった課題があります．<br>
これに対して，MongoDBは独自のPull-Based Raftアルゴリズムを実装しており，これはFollowerノードが自律的にLeaderノードに対してログの配信を要求しにいくような構造になっています．<br>
<img src="https://ik.imagekit.io/plaid/72eac0ca-f319-44ab-9df9-46c81ce2ed6b/image2_1.png" alt="image2_1.png"><sup class="footnote-ref"><a href="#fn6" id="fnref6">[6]</a></sup></p>
<p>これはレプリカのデータ同期を任意の2つのレプリカで行うことができるという特徴があり，様々なネットワークトポロジーを取ることができるようになります．また，これによりネットワークの帯域幅を削減できるという特徴も存在します．<br>
また，バージョンアップの作業を行うにあたっては，クラスター内の古いバージョンのノードが1つ，新しいバージョンのものと入れ替わって，問題が無ければ他の古いバージョンのものも順々に取り替えていくという方式を取っているものと思われます．このことは， MongoDBの公式のドキュメントには記述がありませんが，バージョンアップ時のメトリクスを観察した結果得られたヒューリスティックな観測です．この挙動が可能なのは， Pull-Based Raftによって任意のレプリカ間でのデータ同期を柔軟に行えるためだと考えています．このような挙動は，バージョンアップ時に何か不具合が生じてもサービスを停止させることなくロールバックできるという点で利点があります．</p>
<h2>最後に</h2>
<p>ここまで見てきたように，論文などのある程度信頼できるソースを元にした，ソフトウェアの内部構造理解は，より安全なシステム設計・運用につながるものであると言えます．<br>
私自身は今回のバージョンアップ作業に際して，こういった理論面から実装までの理解を一気通貫で行うことができたので，貴重な経験を積めたと思います．<br>
本記事ではその一端をお伝えすることができたと思うのですが，プレイドは計算機的に面白い業務が様々な場所に存在する環境であると思います．プレイドで働くことに興味を持たれた方は，ぜひ次のリンクもご覧ください．</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/engineer"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://recruit.plaid.co.jp/engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Frecruit.plaid.co.jp%2Fengineer&key=878c5bef402f0b2911bf6d4ce6261abd">エンジニアについて | 採用情報 | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p><a href="https://blog.plaid.co.jp/n/nfa3642bf9871">“エンドユーザーに露出するプラットフォーム”をつくる。Core Platformチームの仕事はなぜチャレンジングなのか</a> <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a> <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a> <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>Diego Ongaro and John Ousterhout. 2014. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX conference on USENIX Annual Technical Conference (USENIX ATC'14). USENIX Association， USA， 305–320. <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p><a href="https://www.yugabyte.com/tech/raft-consensus-algorithm/">What is the Raft Consensus Algorithm?</a> <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn6" class="footnote-item"><p><a href="https://www.usenix.org/system/files/nsdi21_slides_zhou-siyuan.pdf">Fault-Tolerant Replication with Pull-Based Consensus in MongoDB</a> <a href="#fnref6" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います．

MongoDBをサービス無停止で継続的かつ安全にバージョンアップしている話_プレイドエンジニアブログ

MongoDBをサービス無停止で継続的かつ安全にバージョンアップしている話

こんにちは。プレイドでWicleを開発しているchakeです。 Wicleはプロダクトを使うユーザーの行動を分析し、改善するサイクルを助けるプロダクトアナリティクスサービスです。先日パブリックベータ版をリリースし、だれでもオンライン上からサインアップすることができるようになりました。

新進気鋭の認証サービスClerkを実プロダクトで使いこなせ

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

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

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

<p>こんにちは、エンジニアの中間です。<br>
普段はKARTEのネイティブアプリ向けSDKの開発をしています。</p>
<p>React Nativeで遊んでみたことを紹介します。<br>
こちらの投稿は<a href="https://qiita.com/advent-calendar/2018/plaid">PLAID Advent Calendar 2018</a>の6日目の記事でもあります。</p>
<p>KARTEではWebサイトやアプリを通してユーザ一人一人に合わせたコミュニケーションをリアルタイムに取ることを大事にしています。<br>
例えばKARTEのSDKは、管理画面でHTML/CSS/JavaScriptで記述されたアクションをアプリ内メッセージ（ポップアップやバナー、アンケート等）として表示する機能を持っています。<br>
アプリ内メッセージの見た目や挙動を柔軟にカスタマイズできるので、様々な訴求を行えます。</p>
<p>今回は、よりリッチでネイティブライクな見た目のメッセージを出せないか、という可能性を探るために、React Nativeを使いアプリ内メッセージのような機能の実装・実験をします。<br>
ポイントは以下の点です。</p>
<ul>
<li>主となるアプリ上に、アプリ内メッセージを模した第二のアプリを読み込み表示できるか</li>
<li>第二のアプリをリアルタイムに（アプリアップデートの必要なく）変更できるかどうか</li>
</ul>
<h2>概要</h2>
<p>以下の構成のサンプルアプリを作り正常に起動・表示できるかを試します。</p>
<ul>
<li>メインのReact Nativeアプリの上にサブのReact Nativeアプリを表示する。サブのアプリではサーバからfetchしたbundleを使う（プロダクションを想定し、DeveloperSupportは使わない）</li>
</ul>
<p>通常React Nativeのアプリをリリース用にビルドするとassetsにbundleファイルが配置されますが、<code>ReactInstanceManager.setBundleLoader</code>によりbundleの読み込み方法は自由に指定できるようです。</p>
<p>メインのアプリは通常通りassetsに配置し、サブのアプリはサーバからInternal Storageにダウンロードしたbundleを使います。</p>
<p>今回はAndroidのみで試しました。</p>
<h2>React Nativeプロジェクト</h2>
<p>以下のようにプロジェクトを用意し、index.jsをメインのアプリ、index.sub.jsをサブのアプリとします。</p>
<pre><code class="language-plaintext">├── android/ (Androidのプロジェクト)
├── index.js
├── index.sub.js
├── node_modules/
└── package.json
</code></pre>
<p>index.jsは<code>Main App</code>の文字列を中央に表示するだけのアプリです。index.sub.jsも同じように、少しだけ見た目を変えたものを用意します。</p>
<pre><code class="language-jsx">class HelloWorld extends React.Component {
  render() {
    return (
      &lt;View style={styles.container}&gt;
        &lt;Text style={styles.hello}&gt;Main App&lt;/Text&gt;
      &lt;/View&gt;);
  }
}

var styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
  },
  hello:{
    fontSize: 30,
    textAlign: 'center',
  },
});
</code></pre>
<h2>設定</h2>
<p><code>build.gradle</code>の<code>project.ext.react.entryFile</code>に<code>index.js</code>を指定します。これによりindex.jsのビルドファイルがassets/下にindex.android.bundleとして配置されます。</p>
<pre><code class="language-jsx">project.ext.react = [  
        entryFile: &quot;index.js&quot;,  
        bundleInDebug: true,  
        bundleAssetName: &quot;index.android.bundle&quot;
]  
</code></pre>
<p><code>index.sub.js</code>は手動でビルドし、サーバから配布します。ビルドファイルは<code>index.sub.bundle.js</code>という名前にします。</p>
<pre><code class="language-shell">&gt; react-native bundle --platform android --entry-file index.sub.js --bundle-output index.sub.bundle.js --dev false
&gt; http-server ./  #https://www.npmjs.com/package/http-server
</code></pre>
<h2>Androidアプリの実装</h2>
<p>Androidアプリは単一のActivityを持ち、Activity上に二つの<code>ReactRootView</code>と<code>ReactInstanceManager</code>を保持して、二つのReactNativeアプリを読み込む構成にします。サブアプリはメインアプリの上に小さく重ねて表示させます。</p>
<pre><code class="language-java">public class TopActivity extends AppCompatActivity {
  public static final String SUB_BUNDLE_URL = &quot;http://172.16.1.58:8080/index.sub.bundle.js&quot;;

  private ReactRootView mainReactRootView;
  private ReactRootView subReactRootView;

  private ReactInstanceManager mainReactInstanceManager;
  private ReactInstanceManager subReactInstanceManager;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_top);
    final FrameLayout rootLayout = findViewById(R.id.root_layout);

    //mainReactInstanceManagerのセットアップ
    mainReactRootView = new ReactRootView(this);
    mainReactInstanceManager = ReactInstanceManager.builder()
      .setApplication(getApplication())
      .setBundleAssetName(&quot;index.android.bundle&quot;)
      .addPackage(new MainReactPackage())
      .setCurrentActivity(this)
      .setInitialLifecycleState(LifecycleState.RESUMED)
      .build();

    mainReactRootView.startReactApplication(mainReactInstanceManager, &quot;MainReactNativeApp&quot;);
    //メインAppは全画面表示
    rootLayout.addView(mainReactRootView, new FrameLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT));


    //index.sub.bundle.jsをダウンロードし、subReactInstanceManagerをセットアップ
    new AsyncTask&lt;Void, Void, Boolean&gt;() {

      @Override
      protected Boolean doInBackground(Void... voids) {
        return fetchSubBundle();
      }

      @Override
      protected void onPostExecute(Boolean isSuccessful) {
        if (!isSuccessful) return;

        subReactInstanceManager = ReactInstanceManager.builder()
          .setApplication(getApplication())
          .setJSBundleFile(getSubAppBundleFile().getAbsolutePath())
          .addPackage(new MainReactPackage())
          .setCurrentActivity(TopActivity.this)
          .setInitialLifecycleState(LifecycleState.RESUMED)
          .build();

        //サブAppは画面上部に小さく表示
        FrameLayout.LayoutParams params = new FrameLayout.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, 600);
        params.gravity = Gravity.TOP;
        params.setMargins(30, 30, 30, 0);

        subReactRootView = new ReactRootView(TopActivity.this);
        subReactRootView.startReactApplication(subReactInstanceManager, &quot;SubReactNativeApp&quot;);
        subReactRootView.setLayoutParams(params);

        rootLayout.addView(subReactRootView);
      }
    }.execute();
  }

  private File getSubAppBundleFile(){
    return new File(TopActivity.this.getFilesDir(), &quot;index.android.sub.bundle&quot;);
  }

  private boolean fetchSubBundle() {
    try {      
      ResponseBody body = new OkHttpClient()
        .newCall(new Request.Builder().url(SUB_BUNDLE_URL).build())
        .execute()
        .body();
      if (body == null) return false;

      BufferedInputStream input = new BufferedInputStream(body.byteStream());
      OutputStream output = new FileOutputStream(getSubAppBundleFile());

      byte[] data = new byte[1024];
      int count;
      while ((count = input.read(data)) != -1) {
        output.write(data, 0, count);
      }

      output.flush();
      output.close();
      input.close();
    } catch (IOException e) {
      return false;
    }
    return true;
  }

  @Override
  protected void onPause() {
    super.onPause();
    mainReactInstanceManager.onHostPause(this);
    if (subReactInstanceManager != null) {
      subReactInstanceManager.onHostPause(this);
    }
  }

  //onResume, onDestroyも同様に両方のmanagerにdispatchする
</code></pre>
<p>アプリを起動すると、正しくメインアプリの上にサブアプリが重なって表示されるのを確認できました。</p>
<img width="300" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3cfc0dba-9117-46c2-b6fd-b0c7f884420f/screenshot-1543926720606.jpg"/>
<p><code>ReactInstanceManager</code>のインスタンス毎にJSのコンテキストが作られるようで、実際、index.jsでglobalに定義した変数をindex.sub.jsからは参照できませんでした。</p>
<p>実際に活用するためには考えるべきことがまだまだ沢山ありますが、複数のReactNative アプリの共存を動かして試すことができました！</p>
<p>今回作ったサンプルアプリは以下にあげました。<br>
<a href="https://github.com/takaaki7/MultiReactNativeApp">https://github.com/takaaki7/MultiReactNativeApp</a></p>
<h2>最後に</h2>
<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
<p>_IgY4VF5ukBo_EUKZLg&quot; data-width=&quot;300&quot; data-height=&quot;60&quot;&gt;</div></p>
<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>


React Nativeで複数のアプリを共存させられるか試してみた | PLAID engineer blog

React Nativeで複数のアプリを共存させられるか試してみた

<p>こんにちは。エンジニアの@kei-tamiyaです。2018年4月に新卒で入社して8ヶ月ほど経ちましたが、エンジニアとして実際に何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返ってみたいと思います。<br>
　こちらの記事は<a href="https://qiita.com/advent-calendar/2018/plaid">PLAID Advent Calendar 2018</a> 4日目の記事でもあります。</p>
<h2>想定読者</h2>
<p>PLAIDの「人」や「考え方」に興味を持っている方<br>
PLAIDにはエンジニアとしてどんな成長機会があるか知りたい方</p>
<h2>入社前に抱いていたイメージ</h2>
<p>入社する前には累計2,3ヶ月ほどインターンをしていました。その間に、入社すると思考面と技術面に関して以下のようなことが経験できて得られそうだなと考えていました。</p>
<h3>思考面</h3>
<p><strong>(A) 物事の本質を捉える力を高められそう</strong></p>
<ul>
<li>常に目的に対して正しいと思う意見をぶつけ合う</li>
<li>間違っているものや考えはガンガン捨てる</li>
</ul>
<p><strong>(B) 自分が最高に楽しいと思える何かを見つけられそう</strong></p>
<ul>
<li>プロダクト愛と熱量を持っている人が多い</li>
<li>その環境でのめり込んで開発すると気づきがありそう</li>
</ul>
<h3>技術面</h3>
<p><strong>(C) 全般的な開発技術を習得できそう</strong></p>
<ul>
<li>フロントエンド・サーバーサイドで職種を分けていない</li>
</ul>
<p><strong>(D) サーバーサイドの開発力をしっかり高められそう</strong></p>
<ul>
<li>これまでフロントエンドの経験が多めだったのでサーバーサイドを強めたい</li>
<li>高トラフィックを前提にして、多種のDBを扱う経験ができそう</li>
<li>GCPをメインで使い倒していて、かなりのトラフィック・データ量がありそうなのも面白そう</li>
</ul>
<p><strong>(E) 早い段階で高難易度な経験を積めそう</strong></p>
<ul>
<li>KARTEが機能単位でプラガブルな（拡張性の高い）実装になっている</li>
<li>一人で丸ごと実装を担当できそう</li>
</ul>
<p>これらそれぞれが実際にはどうだったのかを振り返ってみます。</p>
<h2>実際にはどうだったのか</h2>
<h3>思考面</h3>
<p><strong>(A) 物事の本質を捉える力を高められそう</strong></p>
<p>実際にこの考え方を感じる場面・実践する場面は非常に多いです。「これってなんでやってるんだっけ？」「そもそも何を解決したいんだっけ？」という問いに立ち返り、元来の目的を再認識した上で現状で取りうるより良い方針に修正をし、トライするといった改善を行えるのは非常に建設的で面白い環境だなと思います。</p>
<p>そもそも私は人の感情を考えてなるべく不快な気持ちにさせないように発言・行動することを大切に生きているので、言葉を意識しすぎて逆にわかりにくくなったり、わざわざ議論しなくてもいいかと問題解決から遠のいてしまうことが多い人間だったのですが、「ああ、ここまではっきり言っていいんだ」と気付かされたのは大きな驚きでした。</p>
<p>「自分たちが解決したいことは目の前の課題および長期的な目標であり、それは達成すべき非常に重要なものである」という前提に立って考えると、事実ベースで課題の本質を認識して発言・共有することでチームとして向き合って解決していくことが重要で、目先の考えすぎな気遣いや感情等は不要なものである場面がほとんどなのだと認識できたのは思っていた以上に自分が成長できたことだなと感じています。</p>
<p><strong>(B) 自分が最高に楽しいと思える何かを見つけられそう</strong></p>
<p>私はそもそも何か特別にやりたいことがある人間ではありませんが、最高にのめり込めることを見つけることが目下の人生の目標だったりします。弊社のメンバーは前職までの経験でWeb上のユーザー体験に対して疑問や課題を感じたために、KARTEの「多様なデータをひとりの人として理解し、一人ひとりに合わせた体験づくりをする」という世界観に共感しているメンバーが多く、そのモチベーションを間近で感じて自分の探したい「何か」の参考にしたいなという思いがありました。</p>
<p>最近では月に1度エンジニア全体で、長期的な未来にKARTEを通して成し遂げたい理想像を全員でディスカッションするような場を設けています。普段の開発で精一杯になって視野が狭くなっていましたが、一歩引いて開発している意義を理解することによって、以前よりも主体的な立場で将来を見据えて開発に取り組めるようになりつつあると感じています。<br>
　<br>
自分の中でまだ「何か」は見つかってはいませんが、何かを成し遂げていくということは「圧倒的な熱量」と「覚悟」が必要なんだなと学んでいます。</p>
<h3>技術面</h3>
<p><strong>(C) 全般的な開発技術を習得できそう</strong></p>
<p>経験できています。役割を完全に分離して開発する形態は、どこか一部門の開発が遅れることでボトルネックになった場合に開発全体が滞ってしまったり、効率が悪くなってしまうような状態が好きではなかったので、機能ごとにIssueを切ってプロジェクトの進行状況やチームの状況次第で誰がどのIssueを担当してもある程度開発できる点はストレスフリーで良いです。</p>
<p>しかしながらまだまだ自分の開発速度も遅く、機能単位で担当する分、大きな機能を丸ごと実装する際はかなり時間がかかってしまって自分がチームのボトルネックになってしまうケースは多いです。この点は課題ですが、割と重要な機能であっても、実力がある程度伴っている場合においては自分で手を挙げれば任せてもらえるので、もっとできることを増やしていこうというモチベーションは高まります。</p>
<p><strong>(D) サーバーサイドの開発力をしっかり高められそう</strong></p>
<p>これも経験できています。学生の頃はフロントエンドの開発をメインで行っていましたが、先述したように幅広く開発技術を習得したい思いもあり、大規模トラフィックを考慮したDBの設計・運用ができて、開発速度の速い環境が良いなと考えていました。実際に規模の大きい配信機能の修正を担当する機会もあり、使われている諸々のDBの仕様を色々調べてキャッチアップし、コードを順に追いつつ理解して実装することで少しずつ実装力が上がってきていると感じています。<br>
　<br>
今年特に多く触れた機能の例としては、Node.jsからのBigQueryやSpannerの操作、QueueとしてのMongoDB, Spanner, Redis, Cloud Pub/Subの活用、Redisを用いた重複配信の制御などの実装・修正・レビューを行い、課題の解決手段の幅が非常に広がりました。</p>
<p><strong>(E) 早い段階で高難易度な経験を積めそう</strong></p>
<p>開発要件が多い新規の機能を少人数のチームで実装していたこともあり、大きな機能単位で担当する機会は早い段階で得られました。方針が定まっていない状態で大きめの機能を担当した際は、必要要件は何があるのかを誰に聞いて、どの粒度でIssueを分割してどの順で開発を進めれば良いのかがわからず相当な時間がかかってしまいました。技術力が至らなかったのはもちろんですが、どちらかというと仕事の進め方・コミュニケーションの取り方の点で圧倒的に力不足を感じて悔しかったので、「エンジニアリング組織論への招待」を読むなどして自分の何が問題だったのかについて冷静に理解して、不確実性と向き合う日々を絶賛送っています。</p>
<h2>学んだこと</h2>
<p>ここまでの内容を一度まとめると、以下のことを学び、徐々にできるようになってきているなと実感しています。</p>
<ul>
<li>目的を達成するために、不要な感情を切り離して、本質的な課題に対して向き合うこと</li>
<li>適切なコミュニケーションによって課題を理解し、解決可能な単位に分割すること</li>
<li>目の前の課題と長期的な課題を適切に捉えることで、主体的に開発に参加すること</li>
<li>Node.js, Vue.js, 各種DB（MongoDB, Redis, BigQuery/BigTable/Spanner等のGCP周り）を用いた開発力の向上
<ul>
<li>大規模トラフィックを考慮した実装</li>
<li>実装力（適切な実装方法を考える力、コーディング速度や可読性）</li>
<li>知らない技術を使用する際のキャッチアップ力</li>
</ul>
</li>
</ul>
<p>思考に関しては、入社前に体験できそうだと思っていたことを実践し自分なりの解釈をすることで新たな発見と学びを獲得し、技術に関しては新たな「学び」というよりは着々とできることが広がっている感覚です。</p>
<h2>逆に自然には学べていないこと</h2>
<p>もともと得たかったものは意識して取り組んでいることでもあり、ある程度身につくのは当然なので、逆にあまり伸びていない能力や課題感についても触れておきます。</p>
<ul>
<li>フルスクラッチでの開発力・企画力</li>
<li>厳密なスケジュールや方針を立てる力・厳格なテストを書く力</li>
<li>確実に予定通りに達成していく力</li>
</ul>
<p>現状での開発は基本的にKARTEの開発がメインで、新規事業としては<a href="https://karte.io/product/app/">KARTE for App</a> や<a href="https://karte.io/product/datahub/">KARTE Datahub</a>などの規模感の大きい機能を実装する形式なので、新規プロダクトを完全にゼロから開発する機会はまだ経験していません。現状で稼働している環境との親和性を考えてアーキテクチャを考える機会は多いですが、フルスクラッチでアーキテクチャ・フレームワーク等を考えて実装したり、ビジネスプランそのものを考えるなどの機会は少ないです。</p>
<p>また、スピード感をかなり重視し、今書いているコードは全て壊すぐらいのつもりで書く文化なので、全体の完全な設計や綿密なスケジュールを立てたり、仕様書通りに実装をするといったスキルは身についていません。テストに関しても、サーバーサイドのユニットテストがメインでコア部分をしっかり守る程度で、厳格に取り組んだ対象とは言えないです。</p>
<p>綿密な計画を立てないのは、より良い方針が浮かぶことでの仕様変更があったり、差し込みがあることを前提としていたり、「その場しのぎの実装」ではなく「少し時間をかけても根本的解決・より良い状態となる実装」を選ぶ傾向があるため、決められた時間内にある一定量のタスクを確実にこなしていくようなスキルは意識しないと高まらないと感じています。社内の開発スピードは非常に早いので、現状では成長余地を見込んで任せてもらえる内容も、「より良いものを作るためならどれだけ時間をかけてもいいんだ」といった勘違いをしてズルズルと長引かせていては自分がボトルネックになってしまいます。</p>
<p>そのため、意識的にミニマム機能を実装する期限を設定したり、この時間内にこれだけの機能を実装し終える、といった目標設定を都度しながら開発する必要性を感じています。</p>
<h2>まとめ</h2>
<p>本記事では、PLAIDの新卒エンジニアとして8ヶ月働いたことで私が学んだことを、入社前に抱いていたイメージと実際に感じたこととを比較することで考察しました。<br>
特に、課題への向き合い方や適切なコミュニケーションの重要性についての思考の変化と、KARTEの開発を通して経験できた技術/あまり自然には学べてはいない能力の一例を紹介しました。</p>
<p>なお、この記事の内容は完全に私の主観によるものですが、チーム環境や開発時の状況によって得られる経験も違うため、あくまでも1人のエンジニアの体験記として捉えていただけますと幸いです。</p>
<h2>最後に</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するPLAIDでは、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に入社して何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返りました。

新卒エンジニアから見たPLAID、そこで得られた経験と学び | PLAID engineer blog

新卒エンジニアから見たPLAID、そこで得られた経験と学び

<p>はじめまして、エンジニアの nito です。PLAID Advent Calendar 2018 の三日目の記事でもあります。</p>
<p>最近は KARTE の開発者向けのプラットフォーム開発を主戦場に、API の仕様策定や開発者向けの管理画面の実装、ドキュメンテーションなどを担当しています。</p>
<p>今回は <a href="https://support2.karte.io/update/2018/12/12347/">12/3 にリリースした KARTE の開発者向けプラットフォーム「Developer Portal」</a> の開発をおこなううえで、大切にしていた <strong>Developer Experience (DX)</strong> という考え方をご紹介します。</p>
<h1>KARTE Developer Portal とは?</h1>
<p><a href="https://developers.karte.io">KARTE Developer Portal</a> は KARTE が提供する開発者向けプラットフォームです。主に次の2つの機能で構成されています。</p>
<ul>
<li>ドキュメント: 具体的なユースケースに則した使いかの説明をするガイド・技術仕様を網羅するリファレンス</li>
<li>管理コンソール: KARTE の API や Webhook など開発者向けの機能にアクセスし管理する。</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e45005b-8956-41e9-bad1-6f5a928e5788/Screen-Shot-2018-12-03-at-4.49.26.png" alt="Screen-Shot-2018-12-03-at-4.49.26"></p>
<h1>Developer Experience とは?</h1>
<p>DX は、2011年に UX Magazine で投稿された <a href="http://uxmag.com/articles/effective-developer-experience">Effective Developer Experience</a> という記事で紹介されています。<br>
以下は一部引用したものになります。</p>
<blockquote>
<p>Platform product owners must be concerned with assisting developers in accomplishing this if end users are to have a good user experience overall. Attention to these details is called developer experience (DX), ...</p>
</blockquote>
<blockquote>
<p>(訳) エンドユーザーに、そのプラットフォーム上で、優れた体験をさせたいと考えているならば、プラットフォーム・オーナーは開発者がこれを達成するのを手助けしなければならない。そして、こうした開発者への細やかな配慮のことを Developer Experience (DX) と呼ぶ</p>
</blockquote>
<p>続けて、次のように言っています。</p>
<blockquote>
<p>and enabling app developers to be successful through better DX will create a more successful UX for the platform product.</p>
</blockquote>
<blockquote>
<p>(訳) より優れた DX を通して開発者を成功させることで、プラットフォームのユーザー体験をさらに成功させるだろう</p>
</blockquote>
<p>また、<a href="https://www.infoq.com/news/2015/10/api-developer-experience">What is API Developer Experience and Why It Matters</a> では、API 設計に対して DX という考え方を拡げ、</p>
<blockquote>
<p>API developer experience is a relatively novel focus aimed to improve API design so it provides a seamless experience to developers when writing software. It can help increase programmers’ efficience and make it easier for developers to achieve goals on behalf of end users.</p>
</blockquote>
<blockquote>
<p>(訳) API Developer Experience は、API 設計を良くするための目標としては比較的新しく、開発者にシームレスな開発を可能とします。そして、プログラマーの効率をあげ、開発者がエンドユーザーの利益になるように目標達成するのを簡単にすることができます。</p>
</blockquote>
<p>と伝えています。</p>
<p>DX は、開発者が気持ちよく生産的に開発できるかどうかに注意を向け、開発者の体験を良くすることで、それが結果としてエンドユーザーの良い体験につながるという考え方です。</p>
<h1>KARTE Developer Portal で実際に注意したこと</h1>
<p>この考え方は、タイトルにもあるように、KARTE Developer Portal を開発する上で非常に大事にしています。<br>
ここからは、実際に DX を意識したところ、ここでは、とくにドキュメンテーションに関して気をつけたところを、いくつか紹介していきます。</p>
<h2>実際のユースケースに合わせたガイド</h2>
<p>KARTE Developer Portal のドキュメントでは、KARTE が提供している API やフロントエンドから利用できる JavaScript モジュールなどの仕様をリファレンスとして網羅しています。しかし、(開発者の方なら経験があるかと思いますが、) リファレンスだけで、すべてを理解するのはかなり厳しいと思われます。</p>
<p>そのため、リファレンスで記載されている各API や関数の使い方としてガイドを提供しています。ガイドは、どのような目的で、どのように使うのかを例 (サンプルコード) を交えて紹介しているので、開発者が迅速に開発に取り掛かることができます。</p>
<p>たとえば、以下は [ガイド] &gt; [基本的な使い方] の「チャットボット連携」に関するドキュメントのタイトルですが、目的から記事にたどり着けるようにタイトルをユースケースを表すようにしています。また記事ごとに目的をもったシナリオと捉えて、動詞をタイトルにしているのも工夫のひとつです。</p>
<pre><code class="language-plaintext">チャットボットと繋げる
├── チャットボット連携のセットアップ
├── ユーザーにメッセージを送信する
├── ユーザーのメッセージを受け取る
├── ユーザーの担当者を変更する
└── ユーザーの担当者変更情報を受け取る

</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/82c73a32-efa4-4018-81f1-13173007a1a7/Screen-Shot-2018-12-03-at-22.16.04.png" alt="Screen-Shot-2018-12-03-at-22.16.04"></p>
<h2>コンセプトを最小限で理解するためのチュートリアル</h2>
<p>また、そもそもプラットフォーム上で開発する場合、そのプラットフォームがどのようなプロダクトで、どのようなコンセプトを持ったプロダクトであるかを理解することも非常に重要になります。そこで、[クイックスタート] というチュートリアルを設けて、KARTE の最小限の基本的な機能をさらいながら、そのコンセプトを理解できるコンテンツも提供しています。</p>
<h1>おわりに</h1>
<p>本記事では、Developer Experience という考え方を紹介しました。KARTE Developer Portal では、DX をもとに、紹介したドキュメントをはじめ、API 設計などにも適用しており、開発者、ひいては KARTE ユーザーに良い体験を提供することを目指しています。</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
<p>_IgY4VF5ukBo_EUKZLg&quot; data-width=&quot;300&quot; data-height=&quot;60&quot;&gt;</div></p>
<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>


開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方; KARTE の開発者向けプラットフォーム「Developer Portal」の開発をおこなううえで、大切にしていた Developer Experience (DX) という考え方をご紹介します。


開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方 | PLAID engineer blog

開発者向けプラットフォームを開発するうえで大切にした「Developer Experience」という考え方

<h1>0. はじめに</h1>
<p>PLAIDのEngineerの 大平和史 (<a href="https://twitter.com/tai_hey2?lang=ja">@tai-hey</a>) です。</p>
<p>前職でSEとして金融系超大規模プロジェクト(数年、数十億円規模、最大数百人)を経験し、現在は真逆となる小規模プロジェクト(4人チームでのサービス開発)でスタートアップのエンジニアとして経験を積んでいます。</p>
<p>ミッションクリティカルな、一つのエラーでも業務影響が存在する大規模な品質最重要のシステムと、toBではあるものの、攻めの開発かつスピード重視のSaaSスタートアップでの開発手法に目的と手法にかなりの差異を感じる毎日です。</p>
<p>それぞれのシステムは価値を提供するビジネスに合わせて作られるため一長一短であり、スピード重視・品質重視か、またそのバランスは生み出すビジネスの価値や目的に沿って特徴があります。その中でプレイドのこだわりはスピード重視の攻めの開発です。社員数を増やし、日々開発を進めていく中で、プロジェクトの規模が大きくなってもいかに開発スピードを落とさずにいれるかの対策を考察していきたいと思います。</p>
<p></p>
<h4>メッセージ</h4>
<p>今回のブログのメッセージをここで先にお伝えしたいと思います。「構造が硬直しがちなシステムを、肥大化する前に最適な単位に疎結合・高密度にアップデートし続け、 開発スピードを維持する」となります。</p>
<h1>1. ビジネスモデルと社会インパクトの特徴について</h1>
<p>まず、そもそもの品質重視の大規模システムと、スピード重視の開発では、ビジネスモデルの生まれや経緯が違うことが大きな源流となります。今後の考察にも役に立ちますので先に整理しておきたいと思います。<br>
両者には大きなビジネスモデルの差異(受託開発かプロダクト・アウトか)と社会インパクトについての観点から分析します。</p>
<h3>1.1 ビジネスモデル</h3>
<p><strong>大規模システム開発のビジネス(基本受託開発となる)</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b8de494-eac4-41ab-94f1-0767eb28fb8b/biz_jutaku-1.png" alt="biz_jutaku-1"></p>
<p>大規模システムは基本的に顧客から外部に開発を外注します。大規模システムの目的はミッションクリティカルで、SLAが他の業界にくらべ高く、求められる品質も高い傾向にあります。</p>
<p>そのため顧客の社内では開発要員の調整や、品質の保持を実現が難しいため、開発手法はウォーターフォールで実施し、顧客から求められた仕様でガチガチにシステム構築を行い、受託会社が顧客のシステムを構築します。</p>
<p>受託開発では顧客が仕様を決めてそれ通りに作るため、ソースコードなどの資産は顧客のものになり、顧客のものを修正することになるので修正一つ一つに契約の合意形成のプロセスが発生します。また、顧客のビジネスにほぼ100％アジャストすることが求められます。</p>
<p>作った後の話にはなりますが品質を求める実例としては下記のようなケースがあります。これで温度感をイメージしていただければと思います。</p>
<p>例えば</p>
<ul>
<li>業務を止められないので業務停止中に原則で夜10時〜朝の間に作業を行わなければならない</li>
<li>夜間一つのジョブが落ちてしまったら業務開始までに必ずリカバリする</li>
</ul>
<p>等があります。<br>
　　　　　<br>
　　　　　<br>
　　　　<br>
<strong>SaaSのビジネス</strong></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7502ecca-8ffb-4e46-ae0b-70f0a4554c36/biz_SaaS-1.png" alt="biz_SaaS-1"></p>
<p>SaaSプロダクトは自社製品としてプロダクトを開発し、顧客のシステムと連携する形になるため、プロダクトの仕様は自社で決めてそれに顧客の業務やシステムが、ある程度アジャストする方針になります。プロダクトのソースコードも自社資産になるのでコストの払い出しや修正の要否は自社で検討することになります。個別の顧客ビジネスに必ずしも100％アジャストしなくてもよいですし、プレイドの場合はKARTEを用いて新たな接客の形態や業務を提案することが弊社ビジネスの価値となります。</p>
<h3>1.2 社会インパクト</h3>
<p>次に社会インパクトについて比較してみます。</p>
<p><strong>大規模システムの社会インパクト</strong></p>
<p>受託大規模開発では顧客のビジネスや業務を理解し、深く入り込んでいくことがビジネスの強みです。個社適用でシステムを構築しており、システム作成当時から顧客数やデータ量が元々多いため、一つのミスのインパクトが社会的に大きいケースが多く、構造の変更よりも社会インフラとしての現状をいかに守るかの判断が重要視されます。</p>
<p><strong>SaaSスタートアップでの社会インパクト</strong></p>
<p>スタートアップも同様ではじめは小さい容量や機能でスタートすることが大半です。そのため始めは社会インパクトが小さいため実現可能性のスピードが重視される傾向にあります。ただし、今後利用顧客数も増え、インパクトが少なからず大きくなり、データ量も増大していく（弊社の場合既に大きくなっています）傾向にあります。<br>
また、利用機能やソースコード量も増えてきます。それにより既存の顧客を守るために保守的になりすぎてしまうのはビジネスの成長を考えた時に足かせとなる可能性があります。スピード減は事業リスクとなりうるので、そうならないような事業推進について考えることが必要です。</p>
<h1>２． 構造が硬直しがちなシステムを、肥大化する前に最適な単位に疎結合・高密度にアップデートし続ける</h1>
<p>いよいよビジネスモデルの前提を1章で踏まえた上でSaaSスタートアップがプロダクト規模、開発規模が大きくなってきた場合、2.1のモデルを使って、どのようなリスクがあり方向性が必要かを考察したいと思います。前職で超大規模システムに携わってきた際に感じた反省から、プレイドでも同様のデメリットを発生させないために攻めのアクションを考察していきたいと思います。</p>
<h3>2.1 価値創造のためのシステムとその構造について</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8ed7388f-7fe3-44a2-806a-3152c5671296/model.png" alt="model"></p>
<p>システムとビジネスを取り巻く環境は「価値、顧客のビジネス、管理/ ルール、処理、構造」を構成要素として把握することができます。構造(アーキテクチャ)を構築して、処理(ソースコード)として記載し、管理(インプットから出力されるアウトプットデータの管理)します。そこに顧客のビジネスが乗り価値が生まれる。このモデルを元に各ビジネスとシステムの構造を考えます。</p>
<h3>2.2 超大規模システムの特徴と変遷について</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0dc46a52-a512-4342-8473-639ec072124c/2daikibo.png" alt="2daikibo"></p>
<h4>構造と処理を変えられないシステムは硬直化・肥大化する</h4>
<p>構築したシステムは10〜20年前のシステムが多いと思いますが、当時の最新のアーキテクチャで作られているはずです。ただ、そこからアーキテクチャの構造を変化させることはほとんどなく現在業務を行っています。<br>
ビジネス要件が追加された場合、処理を追加するためにソースコードは増大するのが普通です。複数サブシステムを一つのモジュールに入れてしまうようなモノリシックで構築したものはそのままとなります。</p>
<p>アーキテクチャを更改するタイミングは5年に一度サーバリプレース案件が発生する時があるのですが、サーバを単純リプレースするだけでかなりのコストとリスクがかかるので、ソースコードを見直してリファクタリングするような活動はされづらいです。その時の判断と企業には寄りますが、業務上最低限の移行（保守が切れるサーバを新しいものに移行する）で遂行されることが多いと思います。</p>
<p>このようにミッションクリティカルなシステムなためどうしても現行業務を死守しなければならないと、<br>
・処理（ソースコード）複雑性が上がってしまうが、ひとまず動くように処理を増大させる方向に傾きやすい<br>
・構造（アーキテクチャ）をドラスティックに変えるチャレンジが数年に一度のチャンスしかない<br>
※但し顧客の予算とリスクテイクの関係で最低限のリプレースしか行われないことが多い。<br>
　<br>
という選択肢を取らざるを得なくなってしまいます。<br>
　<br>
　<br>
そうすると構造を変えられないので、それを補うために処理（ソースコード）を分岐処理や冗長なコードで増大していきます。（今はクラウド化の流れが来ているが）サーバもオンプレミスのままで、アップスケールで対応するのがメインとなります。</p>
<p>また、増える仕様を管理するためにエクセルでの管理資料を増大させることになります。顧客のビジネス要件を満たすきめ細やかな処理を追加するたびにシステムやその管理が増大し、図の各階層のバランスが肥大化するようになります。</p>
<p>早い段階でアーキテクチャやソースコードの最適化や分割を行わないと、構造を硬直させたまま肥大化させてしまうことが私の経験上での反省です。</p>
<h4>顧客のビジネスとの密着度が硬直化の要素の一つ</h4>
<p>また、顧客のビジネスとシステムとの密着度も要因の一つと考えます。大規模システムはミッションクリティカルが多いため、システム停止などが顧客のビジネスに直結します。そのため無闇にシステム構造を変更させることもできないため硬直した巨大システムは肥大化を続けていき、構造の変革が更に難しくなってきます。</p>
<p></p>
<h2>2.3 KARTEのシステム構造としての特徴について</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/656a26a4-30c0-406d-86b3-e07d41777b53/2plaid.png" alt="2plaid"></p>
<h4>現状は最適に近いシステム構成</h4>
<p>相対してスピード重視のプレイドはどうでしょうか。<br>
　<br>
現状私が把握できているプレイドでの構造は上記のように認識しています。プロダクトリリースから3年半が経っていて、構築にあたって2010年代に作られたこともあり、最近技術を取り入れていると感じています。構造（アーキテクチャ）を見てみるとインフラはマルチクラウドで構成され、スモールスケールで増大が可能です。処理（ソースコード）に関しても日常的にリファクタリングが行われ、日々モジュール化が行われています。</p>
<p>構造も処理もそれぞれモジュールとして分割して、余計なソースコードは日々削除するようになっているので、余計な関数などは積極的に集約する活動が行われているように感じます。</p>
<p></p>
<h4>今後の勝負は既存のデータを守りつつ積極的に構造と処理を変革させることができるか</h4>
<p>現状はうまく行っているように見えますが、今後のリスクもはらんでいます。それぞれの処理は現状のコード量と実現したいビジネスのバランスがある程度取れている状態ではありますが、ソースコードの全体量とそれぞれのコード量が増大しているのは間違いないです。更に既存データ量も増大しているため、サーバ上にはかなりのデータ量が格納され続けています。</p>
<p>そうすると大規模開発の状態にもあった顧客に対するインパクトが少なからず増大する傾向になります。本当はアーキテクチャやソースコードをドラスティックに変えていきたいですが、KARTEに入っている既存データや既存顧客のビジネスを守りつつ開発を進めることになるので、そこを考慮しつつ開発することが必要となります。</p>
<p>ソースコードが肥大化する前に構造を硬直化させずに、アーキテクチャやモジュールを分割、共通化、最適化を積極的に行うべきと思っています。マイクロサービス的に細かくすればよいというわけではなく、構造を変革することを直近のコストを考えすぎて先送りにするのは問題と思っているので、都度最適な粒度を検討して分割するべきと思っています。</p>
<h4>顧客ビジネスとの密着度は疎結合でありつつ、顧客のビジネスにインパクトを与える機能実装が必要</h4>
<p>既存のデータを守りつつ構造と処理を変革させることが必要ですが、受託大規模開発と比べKARTEは汎用的な業務を提案していくスタイルなので、顧客業務との密着度を疎結合的にそのままキープしつつ、開発スピードを上げていくことが事業の価値と直結すると私は考えています。少なくとも密着度を上げすぎるような特定の顧客向けに個別の実装をするなどは避けたいと思っています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a70c3377-2169-4022-81ad-753353813224/2hikaku.png" alt="2hikaku"></p>
<h1>３． 直近の構造を変革させる攻めの活動</h1>
<p>1章の前提の比較、2章までの考察を踏まえて、最後に開発スピードを落とさないために必要であった、<br>
構造と処理を積極的に変革させていく例がありました。その例を紹介します。</p>
<h4>リポジトリの分割による構造と処理の最適化</h4>
<p>直近の活動としては肥大化した特定のリポジトリを分割する活動を行っています。現在プロダクトリリースから開発をしている既存の大きくなりがちなリポジトリを分割し、機能ごとにデプロイを行えるようリポジトリ分割の活動を始めています。</p>
<p>ディレクトリ構成の変更や、共通的に使用するモジュールの集約化や、最適化を行っています。</p>
<p>実際に分割直後の機能を触ってみたのですが、buildも十数秒かかっていたものが体感で一瞬で終わるまでになっています。今後のプロジェクトは常に構造を変革することを念頭に入れながら開発をしていきたいと思っています。</p>
<h4>エンジニアとして必要なのは開発時のプロジェクト判断は、構造と処理の変革を常に頭に入れておくこと</h4>
<p>今後様々な開発プロジェクトを推進していく立場になっていくと考えると、特に既存機能が関わる箇所については、顧客と常に相対している、ビジネスサイドとのコミュニケーションを今回の考察を元に推進していきたいです。</p>
<p>機能開発を進めていく際に既存顧客を守りすぎて開発スピードを落とす方向に開発を進めることは避けたいです。既存顧客は守りつつ、開発スピードを落とさない方向、または長期的に見た時に構造や処理をそもそも作り変える着想を持ちつつ、プロジェクト判断をしていこうと思います。</p>
<h2>仲間を募集しています</h2>
<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>みなさま初めまして！<br>
PLAID Engineer Blog初投稿の韓 徹（<a href="https://twitter.com/sskt0809">@sskt0809</a> ）です。</p>
<p>プレイドは、2018/11/3(土)に秋葉原UDXで開催された<a href="https://vuefes.jp/">Vue Fes Japan 2018</a>にプラチナスポンサーとして協賛しました。<br>
私はスポンサーセッションで参加者全員の前で登壇する機会もいただき、Vue Fes Japan参加者の皆さんに<a href="https://karte.io/">KARTE</a>について伝えることができました。</p>
<p>今回のブログでは、Vue Fes Japanの様子や、スポンサー参加の裏話などをお伝えします。</p>
<h2>会場の様子</h2>
<p>自分が会場入りした午前9:00の時点でPLAID以外の各スポンサー企業さんも準備が整っていて、すでに会場はほぼ完成していました。</p>
<p>ヘイ株式会社さんはトイレットペーパーをノベルティに、株式会社リブセンスさんはガチャガチャを用意したりと、ユニークなブースもあり、見るだけで楽しいブースもいくつかありました。</p>
<p>私たちはKARTEのバナーや50インチのディスプレイに公式動画を写し、ノベルティは弊社デザイナーが用意してくれたPLAIDとKARTEのステッカーとメッセージカードを同梱した渾身のステッカーセットを用意しました。<br>
（結果ステッカーセットを渡すと「こんなにステッカーもらえるの？！」って反応がもらえて、大成功でした。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b9e49923-c8ae-483e-b779-4add5e8163be/45B2B854-035A-48D4-B649-5C62402E9464-2.JPEG.jpg" alt="45B2B854-035A-48D4-B649-5C62402E9464-2"><br>
<em>ブースの準備は整った！の様子。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b5999bcf-07d2-4d4c-b631-d90023827bd0/IMG_0875.JPG.jpg" alt="IMG_0875"><br>
<em>ノベルティのステッカーセット。来場者の皆様に好評でよかったです！</em></p>
<h2>そして開幕</h2>
<p>会場には続々と参加者が入場し、キーノート開始までに約300人の方が集まり会場は熱気に溢れていました。（会場スタッフやスポンサーの方を含むと400人強はいました。）<br>
そして、10:20にVue Fes Japan 2018主催のkazuponさんの開会の挨拶でイベントが開催されました。<br>
まず一発目のプレゼンはVue.jsクリエイターのEvan Youさんのキーノートです。Vue.js 3.0が登場する話、どこが2.x系と変わるかをプレゼンしていました。</p>
<p>そのEvanさんのプレゼンの次がお待ちかねのプラチナスポンサーセッションで弊社PLAIDの登壇です。登壇前はEvanさんの登壇の後であるのと会場の人数の多さのプレッシャーがありましたが、いっぱい練習したんだから大丈夫！大きい声で伝えたいことは強くゆっくり話す！って自分に言い聞かせてましたw</p>
<h2>登壇内容</h2>
<p>今回は「KARTEが1,000サイト以上でVue.jsを動かしている話」という内容で発表しました。以下がスライドです。</p>
<script async class="speakerdeck-embed" data-id="98c6724ce2c94580aa22383431fd7ba3" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>主な内容は以下です。</p>
<ul>
<li>プレイドでは、Vue.jsがリリースされた2014年からVue.jsをKARTEの開発で使用している</li>
<li>お客様がKARTEの管理画面で作成したアクション（エンドユーザーに出すポップアップなどのコンテンツのこと）もVue.jsで作られている
<ul>
<li>それらがお客様のWebサイト上（1,000サイト以上！）で動いている</li>
</ul>
</li>
</ul>
<p>プレゼンする前は緊張しましたが、話し始めるとちゃんと練習した甲斐があり、プレゼン自体は大きなミスなく話せたと思います。ただし、最後に言い間違って「ちゃいます、ちゃいます」というお茶目な関西弁が出てしまいました...。その関西弁についてのツイートが2ツイートくらいありました。今やいい思い出です！</p>
<p>発表後はツイートを見ると「KARTEの管理画面すごい！触ってみたい！」「650コンポーネントもあるんだ！」「2014年から使ってるんだ！」「関西弁に安心感を感じる」といったポジティブなツイートばかりだったので、安心と嬉しさがこみ上げました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7f2096f0-68a7-4413-84d9-343d334e7d25/04AA081E-AF0A-4C38-9D07-CFAC5F1F162F.JPEG.jpg" alt="04AA081E-AF0A-4C38-9D07-CFAC5F1F162F"><br>
<em>登壇時の様子。我ながら顔が硬いですね...。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3837230f-2643-47f6-8a33-e817229ae73f/Image-from-iOS.jpg" alt="Image-from-iOS"><br>
<em>聞いていただいた方々ありがとうございました！</em></p>
<h2>PLAIDのブースの様子</h2>
<p>プレゼンが終わったからと安心してはいけません。本当に会場の皆さんに魅力を伝えるのは発表の合間合間のブース対応なのです。<br>
発表見てブース来ていただいた人も多数いました。（弊社エンジニアであり、<a href="https://shiganai.org/">しがないラジオ</a>パーソナリティの池上に会いに来た方も多数いました。）</p>
<p>Vue.jsをどのように使われているかという質問はもちろん、KARTEがどういうことができるのか、サービス自身に興味を持っている方も多い印象を受けました。<br>
改めまして、ブースに来ていただいた方ありがとうございました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/78c2e7b4-783a-43a7-b933-9035f9acf530/Image-from-iOS--1-.jpg" alt="Image-from-iOS--1-"><br>
<em>ブースに多数の方々が来てくれました！</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bc056c5d-6cb1-49cd-85c0-3fa9d8367276/FC51D036-7939-4D81-9EA0-604039015FBD.JPEG.jpg" alt="FC51D036-7939-4D81-9EA0-604039015FBD"><br>
<em>エンジニアの民谷（タミー）もブース対応に参戦。ありがとう！</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2f677bec-23b4-44b6-946a-f71836d3a550/18C158A2-317C-48BC-BAD6-67730DD67073.JPEG.jpg" alt="18C158A2-317C-48BC-BAD6-67730DD67073"><br>
<em>エンジニアの野田(@positiveflat)はVue Fes Japanのスタッフとして大活躍していました！</em></p>
<h2>プレゼンで割愛した内容を一部紹介</h2>
<p>今回の発表はアクションの配信する箇所をメインに話しましたが、この内容にfixするまでにプレゼン内容に紆余曲折あり、説明したくても残念ながら割愛した部分を紹介したいと思います。</p>
<h3>Vue.jsをなぜ採用したか</h3>
<p>KARTE ではVue.jsがバージョン0系で登場した2014年から採用しています。当時、様々なフレームワークと比較しましたが、軽量でシンプルなフレームワークであること、状態管理のしやすさなどを理由にVue.jsに決めました。</p>
<p>実際には、学習ハードルが低く一部のデザイナーやフロント経験の浅いエンジニアでも直感的に使えるという特徴から、スピード感を持った開発を続けられています。また、ドキュメントやライブラリの充実など、Vue.jsコミュニティが活発である点もメリットを感じるところです。</p>
<h3>デザインシステムの導入</h3>
<p>PLAIDでは今年の頭からデザインシステム「BAISU（バイス）」の構築プロジェクトが始まりました。BAISUプロジェクトはKARTEのユーザー体験を良くし強いプロダクトを作るのが目的です。内部的にはデザイナーとエンジニアがよりスピード感を持って協業するために、デザイン原則、スタイルガイド、パターンライブラリを用意しました。</p>
<p>実際に一部の画面ではBAISUのガイドラインに沿ったリニューアルしたりと積極的にアップデートしています。弊社ではデザイナーもVue.jsを書くのでBAISUによりスピードを上げて開発できます。BAISUの詳細は後日、弊社デザイナーが書いてくれることを期待。</p>
<h2>最後に</h2>
<p>今回はVue Fes Japanの運営の方々、会場に来ていただいた皆さん、準備を手伝ってくれた弊社スタッフには本当に感謝しています。<br>
自分はこのような大規模なテックカンファレンスに登壇することは初めてで、新しい学びも多く、そして精神面でも色々鍛えられました！<br>
またこのような機会があれば、どんどん積極的に手を上げていこうと思います。</p>
<p>あと、Vue Fes Japanのアフターパーティは非常に豪華でEvan Youさんとも2ショット撮れたので最後まで大満足のカンファレンスでした！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5877741e-8196-4d88-a823-4f732167fc71/34C704BC-FFA2-4E37-8F73-5FAF34B4A683.JPEG.jpg" alt="34C704BC-FFA2-4E37-8F73-5FAF34B4A683"><br>
<em>アフターパーティの料理めちゃくちゃ豪華でした。とても美味しかったです。</em></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3bd4258d-5878-48df-8317-b5dc7ea6cce8/IMG_1339.JPG.jpg" alt="IMG_1339"><br>
<em>Evanさんとの2ショット！寿司トークも盛り上がり、楽しかったです。</em></p>
<h2>仲間を募集しています</h2>
<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>


プレイドは、2018/11/3(土)に秋葉原UDXで開催されたVue Fes Japan 2018にプラチナスポンサーとして協賛しました。
Vue Fes Japanの様子や、スポンサー参加の裏話などをお伝えします。

Vue Fes Japan 2018に登壇してきました！#vuefes | PLAID engineer blog

Vue Fes Japan 2018に登壇してきました！#vuefes

エンジニアである私が、ビジネスチームを加速させる為に取り組んだ4つのアプローチを記載しました。
エンジニア的な思考を使って、どうチームリーディングすることが効果的なのか。私が取り組んだ中から、特に効果が高かったものを紹介させていただきます。

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ | PLAID engineer blog

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ

<p>プレイドのエンジニア兼ハンターの <a href="https://github.com/algas">@algas</a> です。<br>
<a href="https://ramdajs.com">Ramda.js</a> の関数を例にして JavaScript による関数型プログラミングの考え方を紹介します。<br>
本記事では Ramda.js 自体を紹介するのではなく、より深い関数型プログラミングの考え方を学ぶきっかけを作れることを意図しています。</p>
<h2>想定読者</h2>
<ul>
<li>Node.js でアプリケーションを実装したことがある</li>
<li>関数型プログラミングに興味がある</li>
</ul>
<h2>JavaScript でなぜ関数型プログラミングが必要なのか</h2>
<p>JavaScript のモジュールの多くは Mutable で副作用の影響を受けやすい実装になっています。<br>
副作用の影響を受けやすければ、そのモジュールを複数の場所で利用するのが難しくなります。<br>
さらに関数などのインターフェースが適切でなかったり、意図したとおりに機能しなければ再利用するのが難しく冗長なコードが増えてしまうことになります。<br>
冗長なコードは可読性が低く理解するのにも時間がかかります。<br>
それによって不具合を混入しやすくなったり、不具合を解消するのに不要な時間がかかってしまいます。<br>
関数型プログラミングを導入することで、コードを短く保ち素早く実装して不具合を混入しにくくなることが期待できます。<br>
これはもちろん手法の一つであり、すべての問題を解決する万能の魔法ではありません。</p>
<h2>Ramda.js と関数型プログラミング</h2>
<p>Ramda.js は JavaScript の実用的な関数のライブラリです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c88bd433-7b95-48db-a621-3166bd1ad72c/ramdaFilled_200x235.png" alt="ramdaFilled_200x235"><br>
以下のような特徴を持っています。</p>
<ol>
<li>純粋関数型<br>
不変で副作用の影響を受けにくいような設計になっています。</li>
<li>自動カリー化<br>
関数の再利用がしやすくなります。</li>
<li>引数の最適化<br>
基本的には最後の引数にデータが来るようになっています。</li>
</ol>
<p>Ramda.js は便利な関数を数多く揃えていて、このライブラリを使ってアプリケーションを実装するだけでも非常に有益です。</p>
<p>Ramda.js を使うとどのように便利なのかについては、<a href="http://randycoulman.com/blog/2016/05/24/thinking-in-ramda-getting-started/">Thinking in Ramda</a> のブログに良くまとめられています。</p>
<h2>map の定義</h2>
<p>Ramda.js の <a href="https://ramdajs.com/docs/#map">map</a> 関数の定義を見てみましょう。</p>
<pre><code class="language-haskell">map :: Functor f =&gt; (a -&gt; b) -&gt; f a -&gt; f b
</code></pre>
<p>上記は JavaScript の文法ではありません。<br>
特に Haskell に馴染みがない読者向けに上記の定義を詳しく説明します。<br>
ちなみに Haskell では Ramda.js の map が <a href="http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#v:fmap"><code>fmap</code></a> という関数に該当します。</p>
<p>'=&gt;' の左側は関数の型制約です。<br>
<code>Functor f</code> とは f は <code>Functor</code> であることを示しています。<br>
Functor 自体が何かについては後ほど詳しく説明します。</p>
<p><code>-&gt;</code> は関数型コンストラクタです。<br>
<code>a -&gt; b</code> とは型 <code>a</code> の値を引き数に1つ取り、型 <code>b</code> の値を返す関数であることを示しています。<br>
例えば <code>a -&gt; b -&gt; c</code> は第一引数に型 <code>a</code> の値を、第二引数に型 <code>b</code> の値を取り、型 <code>c</code> の値を返す関数です。<br>
a, b のように小文字で書かれた型に特に制約がなければ任意の型であることを表しています。</p>
<p>小文字がスペース区切りで連続している場合には、関数を適用したことを表しています。<br>
つまり <code>f a</code> は関数 f を a に適用した値です。</p>
<p>上記を踏まえてもう一度 <code>map</code> の定義を見直してみます。<br>
<code>map</code> は第一引数に <code>a -&gt; b</code> という値(すなわち関数)、第二引数に <code>f a</code> という値を取り、<code>f b</code> という値を返します。</p>
<p>詳しくは <a href="https://github.com/fantasyland/fantasy-land">Fantasy Land Specification</a> をご参照ください。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3490a2b-51bb-45ed-865b-ca289e6f2314/logo.png" alt="logo"></p>
<h2>Functor とは何か？</h2>
<p>Fantasy Land Specification に記載されている <a href="https://github.com/fantasyland/fantasy-land#functor">Functor</a> の定義を見てみましょう。</p>
<ol>
<li>Identity<br>
<code>map(a =&gt; a, u) == u</code><br>
<code>a =&gt; a</code> という「何もしない」関数を map に適用しても、適用する前と同じです。</li>
<li>Composition<br>
<code>map(x =&gt; f(g(x)), u) == map(f, map(g,  u))</code><br>
これは <code>x =&gt; f(g(x))</code> という x に関数 g と関数 f を map で適用した値は、<br>
関数 g を map した値にさらに関数 f を map した値と同じです。</li>
</ol>
<p>Functor とは上記2つの性質 (Identity, Composition) を示すような型制約のことを指します。<br>
上記の map は Functor の例のために仮においたもので、map 以外の Functor の性質を持つ関数も同様の性質を示すことが期待されます。<br>
また map 関数の定義における f には任意の Functor を適用できます。</p>
<h2>Functor 制約を持つ関数の実装例</h2>
<p><a href="https://github.com/ramda/ramda-fantasy">Ramda Fantasy</a> では Functor として Maybe, Either など8つの実装が紹介されています。<br>
また Array, Object も Functor の性質を満たすことが分かっています。<br>
これらはすべて Functor の性質を満たしているので、Ramda.js の map 関数を適用できます。</p>
<p>以下で map 関数を使った実装例を紹介します。</p>
<pre><code class="language-javascript">const R = require('ramda');
const S = require('sanctuary');

const mapFunc = R.map(R.compose(S.mult(2), S.add(1)));
const a = [1,2,3];
const z = S.Just(42);
const n = S.Nothing;
const w = S.Right(99);
const e = S.Left(&quot;error&quot;);

console.log(mapFunc(a));
console.log(mapFunc(z));
console.log(mapFunc(n));
console.log(mapFunc(w));
console.log(mapFunc(e));
</code></pre>
<p><code>mapFunc</code> は Number を値に持つ Functor の中身に &quot;1 を足して 2 倍する&quot; 関数です。<br>
上記で mapFunc という関数を異なる Functor に適用していることに注目してください。<br>
ここでは List Number, Maybe Number, Either Number のそれぞれの値に全く同じ形式で mapFunc を適用しています。</p>
<p>出力結果は以下のとおりです。</p>
<pre><code>[ 4, 6, 8 ]
Just (86)
Nothing
Right (200)
Left (&quot;error&quot;)
</code></pre>
<p>各値に &quot;1を足して2倍した&quot; 結果が得られていますね。</p>
<h2>そもそも Functor を使うと何がうれしいの？</h2>
<p>Functor 自体は抽象的な存在であり、そのものが実践的な役割を持つわけではありません。<br>
Functor である Maybe などが実際に便利さを示します。<br>
したがって、ここでは Maybe を使うと何が便利になるかということを例に説明します。<br>
<code>Maybe a</code> は <code>Nothing</code> と <code>Just a</code> という2つの値コンストラクタを持ちます。</p>
<pre><code class="language-Haskell">Maybe a = Nothing | Just a
</code></pre>
<p>※ <a href="https://github.com/sanctuary-js/sanctuary">Sanctuary.js</a> の実装では <code>S.Nothing</code> と <code>S.Just(value)</code> という関数がコンストラクタです。<br>
ここで a は Non-Nullable Value になります。null は Nothing に変換されます。<br>
Maybe の世界には null は存在しないので、値が null であるかどうかをチェックする必要はありません。<br>
実装例で示したように Functor (Maybe) であることを前提とした関数を適用した場合には、Nothing か Just かを気にすることなく関数を適用することができます。<br>
Maybe を使う場合に null または Nothing を気にしなければならないのは、以下の2つの時だけです。</p>
<ol>
<li>外界から Maybe の世界に値を変換する時</li>
<li>Maybe の世界から外界に値を変換する時</li>
</ol>
<p>つまり、Maybe を使うと多くのプログラマにとって煩わしい null チェックの回数を大幅に減らすことができます。</p>
<p>本記事では Functor を主な例として説明しましたが、Fantasy Land に記載されているように Functor よりもさらに複雑な条件を持つ Applicative や Monad などの概念も存在します。<br>
これらを詳しくするには余白が足りないので他書にその役割を譲ることにします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2c88e33e-e64f-4f54-88ee-4205b516b80a/dependencies.png" alt="dependencies"></p>
<p>上記は Fantasy Land Specification から引用した図です。</p>
<h2>まとめ</h2>
<p>本記事では Ramda.js, Fantasy-Land を中心に Functor を使った JavaScript による関数型プログラミングに触れる試みをしました。<br>
現実的に現段階において本記事の概念に近づく実装をするためには以下を実践するほうがよいでしょう。</p>
<ul>
<li><a href="https://www.typescriptlang.org/">TypeScript</a> で <a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html">strictNullChecks</a> を有効にする</li>
<li><a href="http://www.purescript.org/">PureScript</a> で実装する</li>
</ul>
<p>また本記事では説明できなかった項目やさらに発展的な内容を知るには Haskell などのプログラミング言語の仕様や実装を学ぶことをオススメします。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://ramdajs.com/">Ramda.js</a></li>
<li><a href="https://github.com/fantasyland/fantasy-land">Fantasy Land Specification</a></li>
<li><a href="https://github.com/ramda/ramda-fantasy">Ramda Fantasy</a></li>
<li><a href="https://github.com/sanctuary-js/sanctuary">Sanctuary.js</a></li>
<li><a href="http://hackage.haskell.org/">Hackage</a></li>
<li><a href="http://randycoulman.com/blog/categories/thinking-in-ramda/">Courageous Software: Thinking In Ramda</a></li>
</ul>
<h2>最後に</h2>
<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>


Ramda.jsの関数を例にしてJavaScriptによる関数型プログラミングの考え方を紹介します


JavaScript で体感する関数型プログラミング | PLAID engineer blog

JavaScript で触れる関数型プログラミング

<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万行書いてわかったこと