みなさんごきげんよう、Engineerの @tik-son です。02020-10-28に開催された<a href="https://pages.awscloud.com/SaaS_Svrless_EventBridge_seminar.html">&quot;ビジネスにアジリティーをもたらす「SaaS + サーバーレス」&quot;</a>というイベントに 
&quot;User State Driven System with Amazon EventBridge &amp; KARTE&quot; というテーマで登壇してきました。
PLAIDは2020年1月ごろから<a href="https://aws.amazon.com/jp/blogs/news/new-jp-eventbridge-partners/">EventBridgeのSaaS Partner</a>であり、KARTEのActionの一つとしてEventBridgeが選択できます。 
今回のセミナーではEventBridgeを活用したUser State Driven Systemということで、３つの連携例などについてお話しました。
<ul>
<li>ユーザの状態に応じた電話サポート(KARTE × Amazon Connect)</li>
<li>自由記述アンケート分析 (KARTE × Amazon Comprehend)</li>
<li>プロアクティブCall (KARTE × Amazon Connect × shopify)</li>
</ul>
詳細についてはスライドをご覧いただければと思います。
<script async class="speakerdeck-embed" data-id="ac3b373bbd2a47e6b084eb9e90a98a70" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
このセミナーではPLAIDの他には以下のS(P)aaS Providerが、それぞれ異なる切り口でEventBridgeについて話をされておりました。 
我々はEventBridgeのユーザでもあるのでそういう観点でも色々と勉強になったとともに、これからのEventBridgeのさらなる盛り上がりも感じ取ることできるセミナーでした。
<ul>
<li>Auth0 株式会社</li>
<li>Datadog Japan 合同会社</li>
<li>Game Server Services 株式会社</li>
<li>株式会社はてな</li>
<li>Shopify Japan 株式会社</li>
</ul>
*2020/11/17 追記 AWS Blogにも取り上げていただいたので他の方の発表内容などの詳細を知りたい方はぜひここちらもご覧ください。<a href="https://aws.amazon.com/jp/blogs/news/saas_serverless_eventbridge_seminar/">https://aws.amazon.com/jp/blogs/news/saas_serverless_eventbridge_seminar/</a>
<h2>最後に</h2>
発表の中でも話しましたが、KARTEとEventBridge(AWS)で出来ること / 可能性というのはまだまだ未探索なので、面白いことを思いついたり何かフィードバック等ある方は是非コメントなどをいただければと思います。 
また、このような連携を通じて、KARTEの新たな価値を作り上げていく仲間も募集しています。興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！

"User State Driven System with Amazon EventBridge & KARTE" というテーマで、"ビジネスにアジリティーをもたらす「SaaS + サーバーレス」"というイベントに登壇してきました

User State Driven System with Amazon EventBridge & KARTE について話してきました | PLAID engineer blog

User State Driven System with Amazon EventBridge & KARTE について話してきました

<html><head></head><body>フロントエンド/Node.js エンジニアの mizchi です。plaid では新しい分析エンジンのフロントエンド側の技術的な仕様を考えたり、それを実装したりしています。趣味として社内の他のプロダクトのパフォーマンスを勝手に測って、貼り付けていくこともあります。
plaid のエンジニア組織には「組」という制度があって、メインとなるプロダクト以外にも、そのテーマで会社横断で活動するグループがあり、最低一つ所属することが奨励されています。例えばセキュリティ組、バグトリアージ組、Tech 勉強会組などがあります。
最近になって パフォーマンス組を新設しました。これは主にフロントエンドのパフォーマンスを調査して、各プロダクトにその改善を促すグループです。
plaid のフロントエンドは PaaS としての外向けのサードパーティスクリプトと、その管理画面があるのですが、サードパーティの方はパフォーマンスも計測しているのですが、管理画面の方は歴史が長く設計変更も多々あり、富豪的な感じになってしまっています。
これを改善するためにいくつか調査を行い、実際にいくつかは修正したのですが、本質的には「組織的なパフォーマンス意識」を向上させる必要がある、という結論になりました。組織としてのパフォーマンスを意識できないと、目の前の問題を解決したとして、いずれ再発します。(これはセキュリティなどでも同様ですね)
そこで、その文化の改善のために、まず社内のプロダクトをテーマにハッカソンの開催を開催してみよう、という話になりました。
<h2 id="開催の経緯">開催の経緯</h2>
とある日の slack のスレッドの自分とデザイナーの高橋さんの会話。
mizchi 「ところで Baisu (社内の CSS ガイドライン兼モック) むちゃくちゃ重くないですか」
高橋「めちゃ重いですよね」
mizchi 「なんで重いんだろう… JS でした」
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a087da95-c435-4fd2-abfd-38e3a72107b2/hev.png" alt="">
高橋「モック環境だから色んなライブラリとか試すのにいれまくってるからか！なるほど」
mizchi 「ここパフォチュのお題によさそう。lighthouse で高得点出した人が優勝」
mizchi 「壊しても悲しむのが高橋さんだけってのがパフォチュ向き」
見ていた同僚が突然テザーサイトを作成
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a3f2fe0-1e1b-444a-abd2-752765626970/aaf620d4154ddc6357cdb16485c6987a.png" alt="">
開催決定！
mizchi「業務時間使って開催しますね」
nashibao(CPO)「どんどんやっていけ」
<h2 id="真面目な話">真面目な話</h2>
社内のワークフローでは、社内のモノレポの一部の baisu というプロダクトで vue.js のモックページを作成し、それを元に各プロダクトで実装が行われています。
このワークフローの抱える問題として、 baisu の抱えるパフォーマンス上の問題は、そのままプロダクトに引き継がれてしまいます。実際いくつかパフォーマンス上の問題として表出していました。
ここでの改善は、そのまま管理画面やその他のページの改修にそのまま活かせます。プロダクトに直接コミットするより、まず同じ問題を抱えたモックページをチューニングすることで、心理的な負荷を減らしつつ大胆なアプローチを取れるはずだ、と考えました。
<h2 id="まず自分で解いてみた">まず自分で解いてみた</h2>
前提として、この baisu というのは、基本的に vue.js + vue-router で構築された SPA です。html-webpack-plugin と webpack, webpack-dev-server で起動し、本番は静的サイトとして superstatic 上で動作します。
<a href="https://github.com/firebase/superstatic" target="_blank" rel="noreferrer">firebase/superstatic: Superstatic: a static file server for fancy apps.</a>
そもそも問題として適当かどうかを測るため、自分でまず自分がチューニングしつつ問題を洗い出しました。
<ul>
<li>チャンク分割の前に面倒だったのが、babel6 =&gt; 7 のアップグレードだったので、ここで詰まっては本質的ではないので babel 7 へ更新</li>
<li>webpack も dynamic import が使いづらいバージョンだったのを最新版に更新</li>
</ul>
その上で発生している問題の洗い出し。
<ul>
<li>大量のルーティングあるにも関わらず、チャンク分割がなされずに、単一の js として出力されてる</li>
<li>moment の locale をすべて読みこんでいる</li>
<li>vue 用のビューライブラリで、 element-ui というライブラリのコンポーネントを、使うかどうかに関わらず全部読み込んでいる</li>
<li>apexcharts という重いチャートライブラリを全画面で読み込んでいる</li>
<li>fontawesome の全アイコンフォントを読み込んでいる</li>
</ul>
これによって、適当なお題だと判断。あえて放置して本番を迎えました。
<h2 id="開催告知">開催告知</h2>
<ul>
<li>社内勉強会で他社のハッカソンのお題に対する解法を解説 <a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC" target="_blank" rel="noreferrer">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a></li>
<li><a href="https://www.amazon.co.jp/dp/B07JJ344WK/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" target="_blank" rel="noreferrer">超速本の布教</a></li>
</ul>
弊社は 2 ヶ月に一回チームを入れ替えるのですが、その入れ替え期で比較的締め切りなどがない余裕があるタイミングで開催しました。事前に「業務時間を使って参加していいよ、ただしチームの同意はとってね」という周知をしました。
<h2 id="レギュレーションとスコアサーバーの実装">レギュレーションとスコアサーバーの実装</h2>
<ul>
<li>baisu/app のビルド結果を競う</li>
<li>npm run bundleAnalyze した後の npm run evaluation で localhost:8080 にサーバーを起動</li>
<li>計測サーバーの実装を clone して localhost:8080 のスコアを計測</li>
<li>UI が大幅に壊れている場合は計測対象外とする</li>
</ul>
周知した方向性として、「計測対象となるページの個別の最適化は避けて、できるだけ一般的な、マージしたいと思えるような実装で解いてね(それでもスコアは十分伸びるので)」という感じに。
計測用スクリプトはこんな感じ。
<pre><code class="language-js hljs">const fs = require('fs');
const path = require('path');
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');

const TARGET_URLS = [
 "http://localhost:8080/",
 "http://localhost:8080/user/story/",
 "http://localhost:8080/karte/wizard/",
 "http://localhost:8080/organization/",
 "http://localhost:8080/account/register/",
];
const metricsLighthouse = async (chrome, url) =&gt; {
 const options = { logLevel: 'error', output: 'html', onlyCategories: ['performance'], port: chrome.port };
 const runnerResult = await lighthouse(url, options);
 const filename = url.replace("http://localhost:8080/", "").replace(/\//g, "_");
 const reportHtml = runnerResult.report;
 fs.writeFileSync(`report_${filename}.html`, reportHtml);
 return {
 url,
 score: runnerResult.lhr.categories.performance.score * 100,
 totalByte: runnerResult.lhr.audits["total-byte-weight"].numericValue
 }
};

(async () =&gt; {
 const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });
 try {
 const results = [];
 for (const url of TARGET_URLS) {
 const result = await metricsLighthouse(chrome, url);
 results.push(result);
 }
 const totalScore = results.reduce((total, result) =&gt; {
 return total + result.score;
 }, 0);
 const totalByte = results.reduce((total, result) =&gt; {
 return total + result.totalByte;
 }, 0);
 console.log(`Total score: ${totalScore}`);
 console.log(`Total bytes: ${totalByte} bytes`);
 console.table(results);
 } finally {
 await chrome.kill();
 }
})();

</code></pre>
要は lighthouse の Performance のスコアです。
<h2 id="開催">開催</h2>
<ul>
<li>カレンダーで 14:00~19:30 を確保</li>
<li>14:00 に zoom のオンラインミーティングでレギュレーションの説明</li>
<li>18:30 に終了。最終ビルドのスコアを自己申告してもらう。</li>
<li>参加者一人ずつ、PullRequest を見ながらやったことの紹介。全員で講評。</li>
</ul>
<h2 id="結果">結果</h2>
<ul>
<li>事前の周知の甲斐あって、ほぼ全員が router の lazy load の実装を完了 80mb =&gt; 16mb</li>
<li>ほぼ全員が momment の未使用 locale を削除</li>
<li>半数が element-ui をなんらかの形で未使用コードのドロップを実装</li>
<li>ほぼ全員が fontawesome の最適化に挑むも、削れた人は一部だけ</li>
<li>apexcharts を問題視した人はいたが、アプリケーションコードに手を入れないといけないので放置</li>
</ul>
ほぼ全員が 80mb を 10mb 付近まで削っていたのですが、最終的に優勝したのは、 html-webpack-plugin の吐くコードを書き換えた人で defer にしたことで、lighthouse のスコアが上がった、新卒一年目の <a href="https://github.com/kosukeoya" target="_blank" rel="noreferrer">kosukeoya</a> でした。
kosukeoya 曰く、「自分はフロントエンドのパフォーマンスチューニングは初めてだったが、事前資料として共有されたサイバーエージェントのハッカソンでの最適化を上から順になぞった」ということで、あの資料やっぱ有効だったんだなぁという感じに。
<a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC" target="_blank" rel="noreferrer">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a>
<h2 id="参加者の声">参加者の声</h2>
<ul>
<li>webpack-bundle-analyzer がリポジトリに組み込まれていたので、普段は意識しないものを意識できた</li>
<li>やってよかった。いろいろなテクニックにふれる機会があった</li>
<li>フロントエンドの経験値が少なく、直し方はまだ難しく感じるが、問題の見つけ方がわかるようになったのが大きい</li>
<li>最適化ははじめてだったが、コスパよくできる場所があるのがわかった</li>
<li>ベストプラクティスはそんなに難しくなく、知ってれば日常的に採用できるコードが多い</li>
<li>競プロ的な感じ(小難しい解法)かと思ったら普通に一番いいコードが一番効く</li>
<li>(baisu そのものの感想) そもそもうちにこんな数のモックページがあったのか</li>
</ul>
<a href="https://www.npmjs.com/package/webpack-bundle-analyzer" target="_blank" rel="noreferrer">webpack-bundle-analyzer - npm</a>
<h2 id="技術的な感想 / 得られた教訓">技術的な感想 / 得られた教訓</h2>
<ul>
<li>vue.use 使ってしまうと最適化が難しい</li>
<li>fontawesome が強敵</li>
<li>jquery 消そうとして時間がかかった</li>
<li>chunk に名前つけた方がデバッグしやすい</li>
<li>chunk いっぱい吐くとグラデーションが綺麗</li>
<li>高橋さんの PC のメモリ節約できて嬉しい！</li>
</ul>
きれいな webpack chunk の様子です
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f241e3fb-755b-42c1-9736-9870c2b0a1bc/a11849230c29ee02f649700750dfcae1.jpg" alt="baisu [11 Sep 2020 at 18:25] - Gyazo">
<h2 id="講評中に見つかった、プロダクトに活かせそうなものの">講評中に見つかった、プロダクトに活かせそうなものの</h2>
<ul>
<li>superstatic の compression(gzip) を有効にする(なってなかった)</li>
<li>JS によって挿入される css で呼ばれる webfont を &lt;link rel=preload ...&gt; で先読みすると、 適用時のガタツキがなくなり、layout junk が減って LCP のスコアがよくなる</li>
</ul>
この辺やらないとわからなかった気がします。
<h2 id="運営してみての感想 / 反省">運営してみての感想 / 反省</h2>
プロダクトと同じ構成のモックの読み込み改善というお題がよかったと思います。そのまま業務にフィードバックできるので、明日からやっていけそう、みたいな声が多かったです。
そもそもルーティングのチャンク分割、 lazyload にたどり着いてくれないとその後の改善がないのが心配だったんですが、参加者全員、そこはたどり着いていました。ハッカソン中に時間経過でヒントを小出ししたのも、何もできない人が出なくてよかったかなと思います。
反省として、最終的な script の defer 属性によるスコア差については、今回のお題ではやや評価が難しいところがあります。なぜなら、baisu は js を読み込まないと画面に何も表示されない、SSR なしの SPA なので、エントリポイントの同期/非同期は、結果的なユーザー体験にあまり影響がありません。
まあ、スコアサーバーの機嫌を読むのもコンテストの一部ということだと思うので、これはこれで良いと思います。ただ html-webpack-plugin の吐くコードに手を入れる、というのは気づきづらかったですね。
人が集まりやすい事前準備をして、告知の反応も多かったんですが、やはり業務時間を使う心理的な抵抗からか人が集まりづらく、想定の半分ぐらいでした。ここは次にもっと工夫したいと思います。
社内プロダクトの改善という他社で再現性があるか微妙なテーマではあり、これも外に出せないのが申し訳ないんですが、似たようなモックと課題をもつような会社では開催できるのではないでしょうか。そもそも実プロダクトを対象にしてもいいと思います。
<h2 id="Hiring">Hiring</h2>
plaid では webpack chunk を 1byte でも絞り込みたいという人を募集しています。
<h2 id="参考にした先行事例">参考にした先行事例</h2>
<ul>
<li><a href="https://www.cyberagent.co.jp/careers/students/career_event/detail/id=24500" target="_blank" rel="noreferrer">https://www.cyberagent.co.jp/careers/students/career_event/detail/id=24500</a></li>
<li><a href="https://techkondo.com/2020/03/13/recuruit-speed-hackathon/" target="_blank" rel="noreferrer">https://techkondo.com/2020/03/13/recuruit-speed-hackathon/</a></li>
</ul>
</body></html>

社内でフロントエンドのパフォーマンスチューニングコンテストを開催した

みなさん、こんにちは。CTO の @makinoy です。02020-09-08の<a href="https://event.cloudnativedays.jp/cndt2020">CloudNative Days Tokyo 2020</a>のに<a href="https://event.cloudnativedays.jp/cndt2020/talks/46">「急速な成長を加速させるアーキテクチャ〜オープンテクノロジー・マルチクラウドの活用〜</a>」というタイトルで登壇してきました。
我々も非常にお世話になっている<a href="https://www.amazon.co.jp/dp/4295009792">Kubernetes完全ガイド</a>の著者である<a href="https://twitter.com/amsy810">青山真也さん</a>にお声がけいただき、今回の登壇の機会をいただきました。1素晴らしい機会をいただきありがとうございました！
<h3>「急速な成長を加速させるアーキテクチャ」</h3>
このKeynoteでは、k8sなどCloud Native オープンテクノロジーを活用して、どのようにプロダクトの急速な成長を、単に支えただけでなく加速したのかについて、これまでのアーキテクチャの変遷を踏まえて、考え方をご紹介しました。
話したかったポイントとしては、なるべく自分たちでやることを減らして技術の力を利用する、その時に、技術的な”良さ”を鵜呑みするのではなく、なぜその技術を導入するか、組織やプロダクトの状態を考えて導入していくことが、ビジネスを含めたプロダクトとしてのハイスケーラビリティを実現するのではないかと考えている、ということです。
<script async class="speakerdeck-embed" data-id="d2bf4f81df504279b3133bc198d36dc9" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
動画は<a href="https://event.cloudnativedays.jp/cndt2020/talks/46">CNDT公式サイト</a>からご覧いただけます。
アーキテクチャーの変遷に関して詳しくは、 <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital">Google Cloud Day: Digital</a> で @tik-son の「 <a href="https://speakerdeck.com/tikson/plaids-journey-with-multi-cloud-10128526-d75f-41de-98ec-27025f8d35a9">PLAID’s Journey with multi cloud</a> 」を、2k8sに移行した話に関して詳しくは @kumokumo の「<a href="https://speakerdeck.com/komukomo/migrating-to-microservices">Migrating to Microservices - Speaker Deck</a>」を参考にして下さい。
<h2>Toolスポンサーとして</h2>
もしかするとCNDTのイベントページを見てお気づきの方もいらっしゃったかもしれませんが、実は今回のCNDT 2020 Tokyo ではPLAID がTool スポンサーとして協力させていただいてます。3具体的には CNDTのイベントページでKARTEが導入されているのですが、みなさまWeb接客を受けましたでしょうか？後日、KARTEで取得したデータを分析した情報なども公開されるようなので、楽しみにしていてください！
今回の登壇の中でもお話しましたが、我々としてはこのようにOpen Technologyの恩恵を受けるだけでなく還元もしていきたいと考えており、KARTEを通じて今回のCNDTでの皆様の体験向上に繋がっていれば幸いです！
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/05c7f4f0-c9b4-45f0-aa69-e673e828d3bf/image.png" alt="">
<h2>最後に</h2>
Cloud Native オープンテクノロジーをフルに活用して、KARTEを一緒に作り上げていく仲間は常に募集しています。興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！

CloudNative Days Tokyo 2020のKeynoteに登壇してきました