Engineer Blog

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://twitter.com/calloc134">calloc134</a> といいます。<br>
情報工学系の学生で、普段は Web アプリケーション開発について学習しています。</p>
<p>今回、2024年2月から3月の5週間、プレイドでソフトウェアエンジニアとしてインターンシップを行いました。<br>
この記事では、インターンシップの振り返りとともに、学んだことや感じたことをまとめていきたいと思います。</p>
<h1>インターンシップ開始まで</h1>
<p>当インターンシップは、知り合いから紹介をいただいたことがきっかけで始まりました。<br>
自分は今までインターンシップを経験したことがなく、実務経験もありませんでした。<br>
プレイドのインターンでは、任される開発業務に必要な範囲で、社員さんと同じ環境・同じシステムに対して開発・コーディングを行うことができるという特徴がありました。<br>
この特徴は、実際の開発現場でどのように開発が進められているかを知りたい自分にとって、非常に魅力的でした。<br>
そのほか、技術領域が自分の普段の学習と近いことや、エンジニアインターンではフルリモートでも勤務でき、都心住みでない自分でも働きやすいことなどが決め手となりました。</p>
<p>インターン開始前にカジュアル面談を行い、簡単な技術スタックと業務内容について説明を受けました。<br>
プレイドでは、担当するプロダクトによって開発チームが分割されています。<br>
自分はMessageチームに入ることになったので、そのチームでの業務内容について説明を受けました。</p>
<p>Message チームは <a href="https://karte.io/package/message/">KARTE Message</a> というプロダクトを開発しています。<br>
当プロダクトは、データを元にメールやプッシュ配信、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h1>技術スタック</h1>
<p>Message チームの技術スタックについては、同じ Message チームの方が書かれた<a href="https://tech.plaid.co.jp/intern-at-plaid-yurihttps://tech.plaid.co.jp/intern-at-plaid-kenshin">こちら</a>のブログ記事が参考になると思います。</p>
<p>簡単に解説すると、下記のような技術スタックになっています。</p>
<ul>
<li>フロントエンド
<ul>
<li>Vue(メイン)</li>
<li>React (一部メニュー)</li>
</ul>
</li>
<li>バックエンド
<ul>
<li>サーバサイド Node.js / Express.js</li>
<li>Golang</li>
<li>Java</li>
</ul>
</li>
<li>インフラ
<ul>
<li>MongoDB (データベース)</li>
<li>Redis</li>
<li>Cloud Pub/Sub</li>
<li>GKE (Google Kubernetes Engine)
<ul>
<li>ArgoCD (デプロイ)</li>
</ul>
</li>
</ul>
</li>
<li>DevOps
<ul>
<li>GitHub Actions</li>
<li>CircleCI</li>
</ul>
</li>
<li>監視
<ul>
<li>Sentry</li>
<li>Datadog</li>
</ul>
</li>
</ul>
<p>また、開発については、下記の技術を使用していました。</p>
<ul>
<li>Git/ GitHub (コード管理)</li>
<li>Docker Compose (開発環境)</li>
<li>Kind (Kubernetes in Docker)</li>
</ul>
<p>自分にとって、このインターンが初めてのエンジニアとしての実務経験となります。<br>
そのため、技術レベルも含めて最初はインターンで活躍できるかすごく不安でした。</p>
<h1>インターンの内容</h1>
<h2>最初の二日間</h2>
<p>インターン開始してすぐの二日間は、自分の開発環境を整えることから始まりました。</p>
<p>まず開発環境セットアップの資料を確認してインストールを行ったのですが、リポジトリの更新や仕様の変更により、資料と異なる部分がありました。また、資料に存在しないような issue に遭遇することがしばしば起こりました。</p>
<p>そこでSlack に開発環境構築専用のチャンネルが存在したため、そこにスレッドを立てて技術チームに質問を行いながら、一つずつ課題を解決していきました。<br>
フルリモートで意思疎通が難しくなるかもと心配していましたが、チームメンバーの皆さんが迅速に対応してくれたため、スムーズに進めることができました。<br>
また、解決した課題は、times と呼ばれる自分専用のメモ書きチャンネルにまとめていくことで、後から振り返りが容易になるようにしました。</p>
<p>一通り開発環境の構築が完了した後、開発環境構築の手引きとして社内ドキュメントを執筆しました。新しく入ったインターン生が同じような問題に遭遇した際に、自分の経験が役立つことを願っています。</p>
<h2>タスク</h2>
<p>開発環境の構築が完了した後、実際に開発に取り組むことになりました。</p>
<p>5週間という比較短い期間の中でもさまざまなタスクに着手してきましたが、ここでは一番印象に残ったタスクをピックアップし、振り返りたいと思います。</p>
<h3>LINEコンテンツのサムネイル生成機能</h3>
<p>KARTE Messageでは、メール、プッシュ配信、またはLINEを用いてユーザにコンテンツを送信することができます。</p>
<p>コンテンツの保存時に自動的にコンテンツのサムネイル画像を生成し、プレビューすることができる機能が存在するのですが、この機能が実装されているのはメール配信とプッシュ配信のみであり、LINE には実装されていませんでした。</p>
<p>そこで、LINEコンテンツのサムネイル画像を生成する機能を実装することになりました。</p>
<p><img src="https://ik.imagekit.io/plaid/f65747e2-4ff0-4320-ac33-48a8f6cd8c5e/Untitled(1).png" alt="Untitled(1).png"></p>
<p>タスクに取り組むにあたり、はじめに現状のサムネイル生成機能を理解するところから始めました。</p>
<p>まず管理画面上でコンテンツが保存されたタイミングでpubsubのキューにHTML と CSS の情報がメッセージとして登録されます。<br>
サムネイル生成用サービスがそのメッセージをsubscribeしており、メッセージの内容からサムネイル画像を生成する、というシンプルな構成でした。<br>
具体的には、メッセージから取り出した HTML と CSS の情報をpuppeteerでレンダリングし、レンダリング結果のスクリーンショットを生成、S3のsignedURLを用いてS3に保存します。</p>
<p><img src="https://ik.imagekit.io/plaid/b7ded338-bbcd-49b9-a48e-b50fa26298fd/Untitled(2).png" alt="Untitled(2).png"></p>
<p>ではLINEコンテンツのサムネイル生成機能を実装するためにはどのような実装が必要なのでしょうか。</p>
<p>現状の構成では、サムネイル生成用サービスのインターフェースはHTMLとCSSとなっています。</p>
<p>一方で、管理画面で表示しているコンテンツのプレビューはReactやTailwind CSSといったフレームワークを用いて描画しているため、ここからなんとかして等価のHTMLやCSSを生成する必要があります。<br>
あるいは、サムネイル生成用サービスを改修し、Reactコンポーネントを描画する方法もとりえます。<br>
<img src="https://ik.imagekit.io/plaid/3e8f31ec-5a52-4e93-9deb-30b69085fbf7/Untitled(3).png" alt="Untitled(3).png"></p>
<p>上記に加え、さらにいくつか設計の選択肢をリストアップし、メリットとデメリットを比較してみました。<br>
<img src="https://ik.imagekit.io/plaid/4edc16e3-5bc3-45fc-85d7-a02d22801e60/Untitled(4).png" alt="Untitled(4).png"></p>
<p>まず、一番目と二番目の選択肢は実装が難しいと感じたため、採用を見送りました。</p>
<p>そこで三番目の選択肢で実装を進めていましたが、画像がロード中の表示のままサムネイル生成されてしまう可能性があるという問題が発生しました。</p>
<p>これはサーバサイドでのReactコンポーネントのレンダリングの場合、画像の描画に時間がかかってしまうことが原因でした。<br>
従って、最終的に四番目の解決策である、クライアント側の React コンポーネントの HTML を取得してレンダリングする方法を採用しました。</p>
<p>クライアントサイドにおいて、React Componentの描画結果のHTMLはuseRefを利用することで簡単に取得できました。</p>
<pre><code class="language-tsx"> 	const previewHTMLRef = useRef&lt;HTMLDivElement&gt;(null);
 	const previewHTML = previewHTMLRef.current?.innerHTML

  return (
    &lt;&gt;
      &lt;LineEditorPreview controller={controller} previewHTMLRef={previewHTMLRef} /&gt;
    &lt;&gt;
  )
</code></pre>
<p>またスタイリングにはTailwindCSSを用いていたため、プレビューのコンポーネントで適用されているTailWindCSSのクラスをあらかじめビルドしておけば、プレビューに使われているCSS を生成することができます。</p>
<p>TailwindCSS は CLI での呼び出しに対応しており、構成ファイルを指定して手動コンパイルを行いました。</p>
<p>今回は、LINE プレビューに関連するコンポーネントを全て指定した構成ファイルを作成し、TailwindCSS CLI でビルドを行うことで、CSS を生成しました。</p>
<pre><code class="language-tsx">// 構成ファイル

/** @type {import('tailwindcss').Config} */
module.exports = {
  presets: [require('@plaidev/sour-react/tailwind')],
  content: [
    './src/page/template-edit/line-editor/preview.util.tsx',
    './src/page/template-edit/line-editor/preview.tsx',
  ],
  variants: {
    extend: {},
    animation: [],
  },
};
</code></pre>
<pre><code class="language-bash"># TailwindCSS CLI
tailwind -o path/of/output -c path/to/config -m
</code></pre>
<p>最終的にあらかじめ生成しておいたCSSをサーバー側で保持しておき、クライアントサイドから送られてくるHTML情報と合わせてpubsubに登録することで、LINE コンテンツのサムネイル画像を生成することができました。</p>
<p><img src="https://ik.imagekit.io/plaid/ec4733fa-d507-427b-bf8d-1bdd8cbdb5be/Untitled(5).png" alt="Untitled(5).png"></p>
<h1>インターンを振り返って</h1>
<p>社員さんと同じ環境で開発を行っていくことで、自分の中における仕事に対する解像度が上がったと感じています。<br>
これまでは個人的な開発しかしてこなかったため、自身のスキルが社会に出てから実際に活かすことができるのか不安でした。<br>
しかしプレイドのインターンシップを通じて、今まで学習してきたスキルが仕事に活かせることを実感し、また必要なスキルをどのように向上させていけばよいのかを学ぶことができました。</p>
<h2>インターンから得た学び</h2>
<h3>コーディングについての学び</h3>
<p>一例としては、コードの可読性やコメントの重要性を学びました。<br>
これまでの開発では自分がわかりやすいようなコメントや変数名を付けることが多かったのですが、プレイドではロジックの背景を意識したコメントや変数名を付けることが求められ、普段の開発でもこれらの意識を持って開発を行うようになりました。</p>
<h3>ロジックの理解</h3>
<p>また、ロジックを理解する大切さについても学習しました。<br>
挙げられた issue に関して場当たり的な修正は簡単に見えても、その根本的な原因は別のところにあることが多く、ロジックを含めて全体を理解することが重要であると感じました。</p>
<h3>issueの理解</h3>
<p>タスクの内容を深く理解することも重要です。</p>
<p>タスクは基本的に ~ ができない　のような課題形式で書かれているのですが、その解決には様々な方法が考えられます。その中でもどういった仕様が良いのかを正しく導くためには、既存ロジックの理解に加え、ドメインや顧客の理解も非常に重要となってきます。<br>
プレイドでは仕様に関するディスカッションも頻繁に行われるため、こういった能力も養うことができました。<br>
コーディングならAIでもできるようになってきている時代において、仕様設計はますます重要になると考えており、今後も磨いていきたいと思っています。</p>
<h1>インターンの特徴</h1>
<p>プレイドのインターンの特徴を以下にまとめました。</p>
<ul>
<li>実際のエンジニアと同じチームでプロダクト開発を行う</li>
<li>社員と同じ一連の開発フロー(issue アサインと方針の整理、修正とデプロイ、動作確認まで)</li>
<li>技術力に応じてコア開発に近いタスクへのアサインも可能</li>
</ul>
<h2>こんな人におすすめ</h2>
<ul>
<li>実際の開発現場で、開発のサイクルを学びたい</li>
<li>技術力を向上させたい・フルスタックで活躍したい</li>
<li>課題解決力の向上・設計・実装・運用までの幅広い業務経験を積みたい</li>
</ul>
<h1>まとめ</h1>
<p>自分にとって初めてのインターンでしたが、実際の開発を通して色々なことを指導していただき、無事やり遂げることができました。<br>
お世話になった社員さん、インターン生の皆さん、本当にありがとうございました。<br>
今後もこの経験を活かして、さらに活躍できるようなエンジニアを目指していきたいと思います。</p>
<p>プレイドの開発インターンに興味のある方はぜひ下記から応募してみてください。</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>

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot の仕組みとその中で利用されている Azure サービスの役割について説明します。

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot

<p>こんにちは、エンジニアの白木です。</p>
<p>2023年4月 - 2024年2月までインターンとして開発に携わりました。</p>
<h2>自己紹介</h2>
<p>分散システム、データベースについて勉強しています。<br>
最近は、NewSQL、MPPデータベース、io_uring に最適化したデータベースの勉強をしています。</p>
<h2>プレイドのインターンに参加した理由</h2>
<p>プレイドの存在を知ったきっかけは<a href="https://bootjp.me/2023/independence_for_next/">ブログ記事</a>で、そこで大規模な分散システムを開発・運用していることを知りました。<br>
今まで分散システムを プロダクトに応用している例を身近で見たことがなかったため、 CX （Customer Experience）プラットフォームである KARTE を提供しているプレイドに興味を持ちました。そのような中、プレイドがインターン募集をしているを知り、是非参加したいと思い応募しました。</p>
<h2>インターンに入る前の前提知識の話</h2>
<p>インターンに入る以前は データ処理に関する知識は深く持っていませんでした。<br>
大規模データにおける分散処理フレームワークの Apache Hadoop、Apache Spark を用いたデータ処理について少しだけ知っていました。そのため、バッチ処理、ストリーム処理に関する 何となくのイメージがついていました。ただ、データ解析基盤を手を動かして作った経験はなく、どういったアーキテクチャで実装しているかのイメージが全くついていませんでした。<br>
データベースに関しては、MySQL、PostgreSQL などのOLTP(Online Transaction Processing) の処理向けのデータベースについては知識はありましたが、BigQueryのようなDWH (Data Warehouse) や OLAP（Online Analytical Processing) 向けのデータベースの知識は持っていませんでした。<br>
そのため、大規模データを処理するためにどのようなアーキテクチャで構築しているのか、大規模な解析用途で使われている データベースを扱えることが非常に楽しみにして参加しました。</p>
<h2>インターンで開発した内容の話</h2>
<p>インターン開発タスクの一つとして、KARTEのリアルタイム解析基盤に関わるAPIの改善を行いました。具体的にいうと、ユーザーの行動解析結果を取得するAPIが常に最新情報を返すようにするというものです。リアルタイム解析基盤の詳細については以下記事を参考にしてください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析</a></li>
</ul>
<p>タスクの説明を受けた際に、該当のAPIについて「強整合性モード」を実現したいという話を聞き、「結果整合性」、「強整合性」という概念を正しく理解するところから始めました。<br>
結果整合性では、データ読み込み時に最終的に全ての更新が反映されることを保証するものの、即時ではないため古いデータを返す可能性があります。強整合性においては、データ読み込み時に全ての更新が反映されたデータが返ってくることを保証します。<br>
今までビッグデータの処理の文脈で見る BASE特性、また、Apache Cassandra が採用している整合性モデルであることから概念自体は理解できました。しかし、どう実装するかについてイメージができていませんでした。<br>
最初はリアルタイム解析基盤の実装部分やインフラの構成図を元にどう実装するかを考えようとしましたが、どう実装するかのイメージはつかないばかりでした。そこでリアルタイム解析基盤の概略について書かれた<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">こちらの記事</a>を読み直し、大枠のロジックの理解に努めました。</p>
<p><img src="https://ik.imagekit.io/plaid/e52a44f2-f17c-467e-86c4-71e04bdbaeb4/Untitled.png" alt="Untitled.png"><br>
<em>Blitz の強整合を実現している図</em></p>
<p>結果、この図に強整合を実現するロジックが詰め込まれていることが理解できました。Realtime Queue にイベントを書き込んでおき、 Backend Servers で まだユーザーデータに反映されていないイベントを動的に遡求していくことで常に最新のデータを読み込めるという強整合性を実現していました。このアーキテクチャは今まで自分では想像ができなかった部分だったので、すごい仕組みだなと興奮しました。<br>
一度コンセプトを理解してしまえば、APIの実装部分も未反映のイベントを Realtime Queue から取得をして動的にユーザーデータを最新化すればいいという実装イメージが湧き、強整合性モードの実現も無事行うことができました。</p>
<h2>インターンで開発してみて得られた知見・経験</h2>
<h3>分散システムを用いた設計についての知見を得られた</h3>
<p>KARTE では秒間最大 13万4千イベント、月間 180PB を超える解析を行なっています。それを支えるプレイド独自のリアルタイム解析基盤は大規模な分散システムであり、アーキテクチャ上の工夫が随所に見られます。<br>
例を挙げると、リアルタイム解析で結果を同期的に配信するレイテンシー重視な処理と裏側でデータを溜めて一気に更新するスループット重視な処理を完全に分けて考えている点です。ここまで大規模かつシビアなパフォーマンスが求めれる環境だと、目的別にコンポーネントを分離することで、コスト最適化や柔軟なスケーラビリティが可能になっているなと感じました。<br>
分散システムを本で学習していても設計意図を肌で理解できず、中々身につかないなと思っていました。今回、インターンで実務を通じて分散システムに携わることでプロダクトと分散システムが結び付き、理解が深まりました。また、分散システムを通じて価値提供できる面白さを感じることができました。</p>
<h3>プロダクト・ビジネスへの貢献を意識した開発ができる</h3>
<p>プレイドのエンジニアは、技術的にかなり尖っています。しかし、技術だけを見ているだけでなく、プロダクト・ビジネスにも強くフォーカスしています。そのため、日々のタスクに関してもどのようにすれば最もプロダクト・ビジネスに貢献できるかを強く意識しています。例えば、単にプログラムを修正してタスクを完了するのではなく、将来的にどういった構想になっていれば良いかを意識してタスクに取り組んでいます。これによって、アーキテクチャの複雑度を下げています。ただ単にタスクを素早く終わらせる簡単な方法を取るだけでなく、将来までを意識して必要なコストは割いているのは、今後エンジニアとして働く上で学ぶべきことがありました。</p>
<h3>現場のエンジニア・ビジネスの方とディスカッションできる</h3>
<p>プレイドのインターンでは社員と同様の裁量を与えられてタスクに取り組めます。そのため、タスクに関しても現場の社員と同様にディスカッションできます。ディスカッションをすることでプレイドの社員の方の考えが分かり、タスクを進めるにあたりどういったことを意識すればいいのかを知れます。例えば、将来的に見ると価値は高いが直近だと賛否両論が生まれる機能をリリースする攻めの手を打つか、そういった手は打たず保守的な実装をするべきかについて、トレードオフを意識してタスクに取り組むことの重要性、締め切りが迫っている場合にどういったマインドでタスクに取り組むべきかなど、今後のエンジニア人生で大事なことをディスカッションを通じて学べました。</p>
<h3>仕事にやりがいを持っている社員と働ける</h3>
<p>プレイドの社員の方は仕事にやりがいを持っています。社員の方とお昼を一緒にしていると、どの方も楽しそうに仕事に関する話をします。楽しそうにやっている方、事業を本気で成長させようとしている方々と働ける経験は大事です。自分もこのように仕事に対してやりがいを持って働けるようになりたいと思えるようになりました。</p>
<h3>目的達成のためならばどのような技術でも扱う</h3>
<p>手を動かす Web エンジニアは大きく「フロントエンド」、「バックエンド」、「インフラ」などに分かれているところが多いと思います。プレイドでは、プロダクト・ビジネスにインパクトを与えるためならば、エンジニアはこれらの役割に囚われません。どのような領域の技術であっても役割に依らずタスクに取り組みます。役割に囚われずに 貢献していく姿勢は、人にタスクを依頼するコストを減らすことができ、高い生産性を出す上で大事だと感じました。このマインドは私も今後も続けていきたいです。また、どのような技術でも扱うため技術的な刺激を受ける機会がたくさんあります。自身も成長できる素晴らしい環境でインターンできました。</p>
<h2>最後に</h2>
<p>インターンを通じて、分散システムなどの技術的な成長を得られただけでなく、タスクを進めるにあたって考えるべきこと、エンジニアとしてのマインド、モチベーション高く働ける環境への解像度が高くなりました。</p>
<p>プレイドのインターンではエンジニアとして大きく成長できると思います。<br>
興味のある方は下記から応募してみてください！</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>株式会社プレイドのCore Platformチームに所属しているBrownです。今回のブログでは2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。</p>
<h1>前提となるプレイド社内でのデータの管理方法</h1>
<p>プレイドでは、CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」の計測タグ経由で収集したイベントデータを元にWeb上のユーザーの行動を分析するサービスに加え、クライアント企業が社内外に保有する多種かつ大量なデータをKARTEに統合・連携して利活用できる<a href="https://karte.io/feature/integration/">KARTE Datahub</a>（以下、Datahub）を提供しています。<br>
KARTEの内外に散らばったサイロ化されたデータをDatahubに集約して、KARTEのプロダクトの中でユーザーのセグメントに活用したり、WidgetやKARTE内のアクション機能から参照したりすることができます。<br>
<img src="https://ik.imagekit.io/plaid/46c800d9-dd3d-4ff1-a605-a2cd7272ace9/datahub_case01_image-1.webp" alt="datahub_case01_image-1.webp"><br>
<em><a href="https://cxclip.karte.io/casestudy/tips/datahub_case01/">「KARTE Datahubに蓄積した様々なデータを活用する｜KARTE Datahub事例集 vol.1</a>」より引用</em></p>
<p>Datahubでは、KARTEに関わらず様々なデータの統合・利活用するプラットフォームであるため、他のKARTEのProductとデータの取り扱いを区別する必要があります。</p>
<h1>プレイドでのデータ共有</h1>
<p>データへのアクセスの安全性を高めるために、Datahub以外のKARTEのプロダクトから、クライアント企業の許諾なく直接Datahubに連携されたデータを参照することはできません。<br>
そのため、クライアント企業から許諾を受けたデータのみを、Datahub以外のプロダクト側に共有することで、イベントデータと組み合わせて使用したり、加工済みデータを生成しています。</p>
<p>また、データ連携の際に使用するBigQueryのDataset（以下、Dataset）やGCPのサービスアカウント（以下、SA）はクライアント企業ごとに分離されており、例えば、企業AのSAではその企業AのDatasetのみが操作でき、それ以外のクライアント企業のDatasetへの権限は一切持ちません。</p>
<h1>従来のDatasetの共有方法の問題点</h1>
<p><img src="https://ik.imagekit.io/plaid/26051d0a-c445-4260-90ff-0c084d3f9bfc/image1.png" alt="image1.png"></p>
<p>従来の仕組みでは、クライアント企業がDatahubを通じてKARTEにインポートしたデータを、Datahub以外のプロダクトから利用する場合には、KARTE Data LayerのSAがDatahub Data Layerに直接アクセスできないため、そのDatasetのデータを含めてKARTE Data Layerにコピーする必要がありました。<br>
この方法では、明示的に必要なDatasetだけをKARTE Data Layerに共有できる反面、以下の二点の問題があります。</p>
<ul>
<li>KARTE Data Layerにコピーされた後のDatasetへのアクセス権限を持つSAの管理・監視が煩雑</li>
<li>Origin DatasetからShared Datasetへ定期的にデータをコピーする必要がある</li>
<li>Origin Dataset・Shared Dataset双方でストレージコストがかかる</li>
</ul>
<h1>Analytics Hubを用いて問題点を改善</h1>
<p>まず前提として、Analytics Hubでは以下の構成によりDatasetを共有することができます。各権限の詳細は<a href="https://cloud.google.com/bigquery/docs/analytics-hub-grant-roles?hl=ja">公式ドキュメント</a>をご覧ください。<br>
<img src="https://ik.imagekit.io/plaid/c0d7cca4-fe2a-4291-90c9-24d0d260a7e4/image3.png" alt="image3.png"><br>
<em><a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction#subscriber_workflow">Introduction to Analytics Hub</a>より引用</em></p>
<ul>
<li>Publisher : 共有元となるDatasetを持つGCP Project</li>
<li>Data Exchange : Publisherが共有対象となるListingを作る場所</li>
<li>Listing : PublisherがData Exchange内に作成した、共有対象となるDatasetのリストで、SubscriberはこのListingへの <code>roles/analyticshub.subscriber</code> 権限を持つ</li>
<li>Subscriber : Analytics Hub経由で共有されたLinked Datasetを使う側を指し、このSubscriberはListingをSubscribeすることでLinked Datasetを自分のGCP Project内に作成する</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ea657c14-c835-4176-8c15-616c4be357dc/image2.png" alt="image2.png"></p>
<p>Analytics Hubを通じてDatasetを共有することで、Datasetのデータ実体はKARTE Data Layerに共有することなく、Origin Datasetの内部にあるデータと同じものをShared Datasetに対してクエリを実行することで取得できます。この時、Origin Datasetに対して権限を持っているGCPのService Accountのみが共有対象のAnalytics HubのListingを作ることができるように権限管理をしているため、Data ExchangeはDatahub Data Layerに置いています。<br>
Analytics HubでDatasetを共有することで、従来のSAで直接共有する形式では見えずらかった、共有先での使用状況や、共有先が明確になりました。<br>
また、データコピーの必要がなく、かつストレージはOrigin Datasetにのみ課金されるため、上記の2点の問題点が両方とも解決できます。</p>
<h1>セキュアなデータガバナンスの取り組み</h1>
<p>KARTE Data Layerに一度共有されたDatasetは、そのクライアント企業がKARTEの他のプロダクトから利用することができます。しかし、一度共有したDatasetであっても、何かの事情がありそのDatasetをKARTEの他のサービスへ共有停止したいというケースもあります。<br>
そのような際には、Analytics HubのPublisher側でそのDatasetのSubscriptionを削除する、Subscriber側で共有されているDatasetを削除するなど、いずれの方法でも瞬時に共有を停止できます。<br>
また、現在共有されているDatasetをListingから取得できるため、共有中のDatasetのListingへ監視を入れておくことで、意図せずDatasetが共有されてしまっているという状態をすぐに検知することも可能です。</p>
<h1>実際にAnalytics Hubを使ってみて</h1>
<p>Analytics Hubでは、一般公開されているDatasetをSubscribeして使うことや、異なる組織間でDatasetをセキュアに共有しつつ、クエリに対する課金も分離するという用途のみならず、同一組織内でもデータガバナンスの観点で、データへのアクセス権限を管理したり、特定のDatasetのみを特定の目的で他のGCPのプロジェクトへ共有して使うという用途でも使いやすい機能だと思いました。<br>
しかし、まだAnalytics Hubも出たばかりの機能ということで、以下の機能に関して改善が行われると、より使いやすい機能になると感じました。</p>
<ul>
<li>Listingを消した時に自動でLinked Datasetも削除されること</li>
<li>共有用URL経由でLinked Datasetを作成できるGCPプロジェクトを限定したい
<ul>
<li>Service Accountの権限で制限をかけることもできるが、Service Accountの権限設定ミスで想定外のGCPプロジェクトのSAが権限を持ってしまった場合に備えて、Listingごとに共有先として許可するGCPプロジェクトを指定したい</li>
</ul>
</li>
<li>Node.js API Clientの拡充</li>
</ul>
<p>上記のように改善点はいくつかあるものの、KARTEのデータガバナンスを強化する機能としては非常に有効な機能なので、今後も使用箇所を増やしていこうと思っています。</p>


2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。 

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有 - PLAID engineer blog

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

OLAPデータベースにおける高速化の技術 - PLAID engineer blog

OLAPデータベースにおける高速化の技術

<h1>はじめに</h1>
<p>こんにちは！５月初旬から７月末までの３ヶ月間、ソフトウェア開発のインターンとして株式会社PLAIDで働いていた西村悠です。私はカナダにあるUBC (The University of British Columbia) の2年生です。専攻はコンピュータサイエンスで、以前にソフトウェアエンジニアとして働いた経験がありましたが、学生としてやる個人プロジェクトや他のインターンで扱うシステムには限りがあり、どことなく自分のスキルや経験に自信が持てずにいました。そこで私は、ソフトウェアエンジニアリングのスキルを加速させる素晴らしい機会を期待して、SaaSのプロダクトを持つPLAIDのインターンシップに応募しました。</p>
<p>実際、今回のインターンシップは、私のスキルを向上させ、伸ばすことができたと確信していますし、この経験は私の財産になると思っています。今日は、どのようにインターンが進んでいったのか、私が所属するチームで行ったこと、PLAIDのカルチャーについてお話します。</p>
<h1>PLAIDのプロダクト</h1>
<h4>KARTEについて</h4>
<p>PLAIDのメインプロダクトはKARTEと呼ばれる、CX（顧客体験）プラットフォームを提供するSaaSです。KARTEは、実店舗と同じように人間が実際に接客しているかのようなCS（顧客サービス）をwebsite上で実現します。ユーザーの行動データをリアルタイムに可視化し、ウェブサイトを管理する人が自分たちのサービスをより良く更新できるようにします。</p>
<h4>KARTEのミッション</h4>
<p>この製品は、顧客サービスを必要とするすべてのビジネスに使用できると考えています。ある企業では既存のWebサイトのCXを向上させるためにKARTEを使うかもしれませんし、ある企業は実店舗ではなくWebサイトで新しいビジネスを始めるためにKARTEを使うかもしれません。KARTEは、インターネットを利用したあらゆる顧客サービスをサポートしてくれます。このように、KARTEには壮大なミッションとスケールの可能性があります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d386e02f-ced1-4dfd-a77d-227751ad7471/----------2021-07-30-12.08.25.png" alt="----------2021-07-30-12.08.25"><br>
KARTE</p>
<h1>KARTE Messageチームにジョイン</h1>
<h4>ジョインしたチーム</h4>
<p>PLAIDでのインターンシップでは、KARTEの機能を開発するチームにジョインします。私はKARTE Message チームにジョインしました。私たちのチームでは、KARTEのメッセージプラットフォームを開発しています。このプラットフォームでは、クライアントが独自のメールマーケティングのコンテンツやユーザーリストを作成し、多くの顧客にメッセージを送信することができます。この製品のおかげで、企業のマーケティング担当者はKARTEのデータを活用して、独自のマーケティング戦略を立てることができます。私たちのプロジェクトは、KARTEのユーザーにこのようなエンド・ツー・エンドの体験を提供することを目的としています。</p>
<h4>チーム内技術スタック</h4>
<p>Messageチームで扱っていた主な技術スタックとして、Vue.jsとNode.jsがフロントエンド、バックエンドそれぞれにTypescriptで書かれていて、インフラはKubernetesやTerraformを使って管理していました。また、多くのCloud Serviceも使用していて、AWSのSES, S３や、GCPのGKE, Big Query, Spanner, Pubsub, Cloud Function, Cloud Run, Cloud Buildなどを扱っています。</p>
<p>特にMessageチームが他のチームと違うところは、KARTEの管理画面を動かしているKubernetesクラスターとは別の配信基盤用のクラスターを用意していて、スケーリングやCI/CDが独自に設定されているところです。</p>
<p>このような環境のため、私はフロントエンドやバックエンドのような典型的な開発から始まり、インフラ側（CI/CDのためのオペレーション）やいくつかの分散システムに至るまで、様々な種類の仕事を任せてもらうことができました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/674d8570-6c45-4b4c-9b7f-fc669179d3e9/IMG_2483.JPG.jpg" alt="IMG_2483"><br>
Message チームの島</p>
<h1>インターン初日 ~ 1ヶ月</h1>
<h4>最初の1週間</h4>
<p>チームにジョインしてすぐはPLAIDの開発環境、開発サイクルやチームで扱うシステムに慣れるために細かいバグを修正するタスクが与えられ、それに従事していました。なるべく早くKARTE全体のシステム設計や技術スタック、チームの課題などをキャッチアップするためにレコードされていた解説動画やメンターの方とのコミニュケーションを積極的に行いました。２週間ほど経ち、基本的な開発フローに慣れてきたところで徐々にタスクの難易度が高くなっていきました。</p>
<h4>テスト配信</h4>
<p>最初の1ヶ月で印象的だったタスクは、テスト送信機能です。会社のマーケターは、施策を作った後、最初にエンドユーザーにマーケティング広告を送るわけではありません。その代わりに、テスト送信を行い、メッセージ内容についてのフィードバックをテスト送信先から得るのです。メッセージサービスを利用したことのある方は、テスト送信ボタンがあることをご存知だと思います。私はこの仕事を任されました。難易度が上がった初めての課題で、自分の技術力とKARTEの理解度が試されているようでした。</p>
<h4>解決アプローチ</h4>
<p>ページのバグを修正するような単純な作業とは異なり、コーディングだけでなく、問題を解決するための論理的な道筋を立てる能力が求められました。例えば、どんなデータが必要なのか、そのデータはどこから来るのか、どうやってデータを入手するのか、データにアクセスするためにはどんな情報やトークンが必要なのか、といったことを考える必要がありました。そして、この問題の要件を見つけ出した後、実装の方針を決めます。このようなプロセスは、問題を解決する上であらゆる状況に応用できると思いました。</p>
<h4>使用したスキル</h4>
<p>具体的なテクノロジースタックとしては、Vue.jsでUIを作り、Node.jsでAPIリクエスト用のエンドポイントを作りました。また、メールはAmazon SES、ネイティブプッシュはFirebase Cloud Messagingといった外部サービスとの連携も必要で、それぞれのサービスのAPIを理解し活用できるようになりました。このタスクでは、KARTE Messageのページがどのように構成されているのか、KARTE Messageのシステムがどのように送信機能を得ているのかを理解することができました。また、これまでの経験で培ってきたWeb開発のスキル（フロントエンド・バックエンド）が活かすことができ、自分のスキルがある程度通じると思える自信を持つことができました。</p>
<h1>２ヶ月 ~ ３ヶ月</h1>
<h4>残り1ヶ月</h4>
<p>インターンシッププログラムが進むにつれて、扱う課題は難しく、挑戦的なものになっていきました。これらの課題はすべて、ソフトウェアエンジニアリングの理論を包括的に理解し、複数のスキルを組み合わせて適用することが求められます。特にインターンが残り１ヶ月となってからは抽象度の高いタスクを扱いました。その１つとして、送信のためのエンド・ツー・エンド・テスト（E2Eテスト）を実装するという課題をやりました。</p>
<h4>E2Eテスト</h4>
<p>ペースの速い開発では、コードの一部が何度も変更され、それがシステムの正常な動作を脅かします。この観点から、E2Eテストは、KARTEメッセージの機能を保証するために、私たちの製品にとってとても重要でした。このテストを作成するためには、KARTE上のシステムの多くの相互作用を考慮しなければなりませんでした。また、調査、設計、技術の選択、コーディング、テスト、パイプラインの構築など、総合的なソフトウェアエンジニアリングが必要となりました。私は実際に様々な技術やツールを使いました。UIテストにはCypress、分散システム間のやりとりには内部APIサービス、サーバーの設定にはTerraform、CI/CDパイプラインにはArgoCD、Kubernetes、Cloud Buildを使用しました。</p>
<h4>苦労した点</h4>
<p>課題の中で特に難しかったのは、E2Eテストのジョブをどのように実行するかでした。メッセージ配信プラットフォームのシステムは、ユーザーデータや管理ページを保存するプログラムとは異なる環境で動作しています。しかし、E2Eテストのプログラムはユーザーデータを扱う必要があるため、管理画面上で実行する必要があります。２つの別々のネットワーク内で動いているプログラム間で通信する必要があったため、この問題を解決するには、ネットワークやKubernetesの知識が必要でした。</p>
<p>私はそこまでKubernetesを使った開発をした経験がなかったため、その環境に慣れるためにかなり苦労しました。配信基盤で動かしているKubernetesクラスターのmanifestを読んでどのように各リソースが動いているのか、KubernetesのリソースをGCPのアカウントと紐づけるためにどのようにTerraformを書かないといけないのか、など新しく学んだことはたくさんありました。そうすることで、初めてKubernetesクラスター内でのネットワークを理解できるようになり、上記の問題が理解できるようになりました。</p>
<h4>最終解決案</h4>
<p>解決策として異なるクラスター間の通信は権限的に難しいということが分かり、問題をシンプルにするために管理画面を通したE2Eを実行できるようにしました。E2Eテスト実行用のページを用意してあげれば、HTTPによる通信で実行できるようになり、クラスター間の権限を考慮しなくて良くなりました。この時に改めてシンプルな設計をすることの重要性に気付かされました。</p>
<p>このタスクは、もちろん1人ではなく、多くの社員さんの協力を得ることで実装できました。彼らの助けがなければ、この課題を解決することはできませんでした。逆に言えば、どのようにして他の人を巻き込んで協力を得るべきかということの大切さを知り、それを実践する良い機会になりました。E2Eテストの実装を通してKARTEの複合的で複雑なシステムと、PLAIDのクラウド運用技術に精通する良い機会となりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/afc835f3-074f-41e0-8407-c9b52b64d4b2/----------2021-07-30-18.04.16.png" alt="----------2021-07-30-18.04.16"><br>
実際のディスカッションボード</p>
<h1>PLAIDインターンシップの文化</h1>
<h4>PLAIDエンジニアのレベル</h4>
<p>PLAIDでのインターンシップは、私のこれまでの経験の中でも最高に素晴らしいものだったと強く言いたいです。この素晴らしい機会は、PLAIDの職場環境が生み出しているのだと思います。その一つがエンジニアの質です。PLAIDは急成長しているスタートアップで、フルタイムのポジションに就くのはとても難しいです。そのため、PLAIDにいるほとんどのエンジニアは他のソフトウェア会社でリードエンジニアとして活躍できるくらいの技術力があり、PLAIDではどの分野でも最低1人はスペシャリストがいるような環境になります。このような高いレベルの人材は、インターンシップの学生にとっては、スペシャリストとのコミュニケーションが可能になり、彼らから大きな学びの機会を得ることができるため、貴重な存在となるでしょう。</p>
<h4>PLAIDインターンの価値</h4>
<p>また、PLAIDが素晴らしい職場環境であるもう一つの理由として、学生が会社の実際の製品の実装を担当するというインターンシップは他に代えがたいものでした。KARTEには何百万人ものエンドユーザーがいて、システムは何先万ものリアルタイムのユーザーデータを扱っています。この膨大なデータはPLAIDの財産であり、学生がこの本物の顧客データに触れることは他の会社ではめったにありません。私の場合は、何百万人ものユーザーに使われることを想定して実装を考えなければならないので、スケーリングを考慮したコーディングを行う貴重な機会となりました。</p>
<h1>インターンを振り返って</h1>
<p>ご存知のように、PLAIDのインターンでは、エンジニアリングの質とスピードの面で高いレベルが要求されます。このような目標を達成するのは難しいと思うかもしれませんが、PLAIDでのインターンシップを終えた後には、自分のエンジニアとしてのスキルやキャリアに自信を持てるようになることを絶対に約束します。実際、私はこの経験によって、自分の開発力が次の段階に進み、今後どのようなシステムを扱うことになっても心配する必要がないという自信を持つことができました。</p>
<p>チームメンバーの大逸さんや山本さん、塩澤さんをはじめとする社員の皆さん、同僚インターン生の皆さんには感謝の言葉しかありません。3ヶ月間のインターンは短く感じましたが、充実した時間を過ごすことができました。これからのPLAIDの成長がとても楽しみです！<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a43df00d-d8a3-4a66-b43e-5a266bdc37ad/DSC04309.jpg" alt="DSC04309"><br>
チームの写真</p>
<h1>最後に</h1>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>


こんにちは！５月初旬から8月までの３ヶ月間、ソフトウェア開発のインターンとして株式会社PLAIDで働いていた西村悠です。PLAIDでのインターンの模様をブログにしました！

カナダから海を渡って辿り着いたPLAIDインターン | PLAID engineer blog

カナダから海を渡って辿り着いたPLAIDインターン

<p>この度、PLAIDは<a href="https://github.com/sponsors">GitHub Sponsors</a>を利用してOSS(オープンソースソフトウェア)にスポンサーしました！</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8be40299-62fb-48e6-ae0c-8268a94414d2/image-2.png" /><figcaption><a href="https://github.com/sponsors">GitHub Sponsors</a></figcaption></figure>
<h2>OSSにスポンサーするモチベーション</h2>
<h3>利用しているOSSの持続</h3>
<p>OSSに対して金銭的な支援をすることは、OSSの作者やOSSの開発をリードする人、そしてOSSで活動するチームに対して継続的な活動を支援できることを意味します。</p>
<p>私達が利用しているOSSは様々な規模なものがあります。個人で開発した特定の問題解決にフォーカスしたライブラリやツールのような小さい規模のもの、そして、フレームワーク、SDK、ToolKit、データベース、そしてプログラミング言語といった大きい問題を解決するために提供されている大規模なものまで。</p>
<p>OSSは使うユーザーが増えてくるとOSSの成長とともに、機能追加、改善、バグ修正などの開発の他に、ドキュメントの整備やissues のトリアージュといったメンテナンスに関する活動、そしてカンファレンスイベント登壇やワークショップなどの啓蒙活動等に関わる時間が増えてきます。</p>
<p>OSSの開発やメンテナンスに関わる時間は、会社で業務時間を使って活動できているところもありますが、ほとんどはOSSに関わる人たちのボランタリーベースによって活動が続けられています。</p>
<p>OSSの規模が小さい場合は、OSS作者一人や、ボランタリーなチームメンバーやコントリビューターによって何とかなりますが、OSSが成長するに従い誰かしらフルタイムで対応する時間が必要になってきます。</p>
<p>そうしたOSSにフルタイム活動できる支援がないと、OSSは持続が厳しくなり徐々に衰退していきます。これは利用しているOSSユーザーにとって不幸なことです。</p>
<h3>価値あるプロダクトの提供を持続させる</h3>
<p>昨今、プレイドを含めた私達IT業界が提供しているプロダクトは、OSSを利用してエンドユーザーに価値を提供されていることが一般的になりつつあります。</p>
<p>つまり、私達はOSSに支えられながらプロダクトを提供して事業をしているといっても過言ではありません。</p>
<p>利用しているOSSが持続できなくなることは、私達が提供しているプロダクトにも影響を及ぼします。</p>
<p>私達エンジニアにおいては開発の時間的な損失が発生します。利用しているOSSを代替となるOSSへの切り替え、持続できなくなったOSSをフォークして独自パッチによる対応、そして独自開発といったり。</p>
<p>その開発の対応による予期せぬ時間的損失は、会社の事業ロードマップへも影響を与えることにもなります。</p>
<p>プロダクトの新しい機能を待ちわびているエンドユーザーにとっても、OSSが持続できなくなることは良いことではありません。</p>
<h2>Vue.jsとViteのOSS作者にスポンサー</h2>
<p>PLAIDではまずはじめにVue.jsとViteの作者である<a href="https://github.com/sponsors/yyx990803">Evan You氏</a>にスポンサーしました。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8fbf5c4e-307b-4733-9142-f8794f1e8c4e/image-3.png" /><figcaption><a href="https://github.com/sponsors/yyx990803">Evan You氏</a></figcaption></figure>
<p>PLAIDのプロダクトKARTEの管理コンソール周りはVue.jsを使って作られており、Vue.jsがリリースされた初期の頃 (v0.12) から利用しています。</p>
<p><a href="/self-contained-systems">弊社CPO柴山のブログ記事</a>においても紹介しましたが、PLAIDのシステムはMicroservicesなアーキテクチャで構築されています。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/63ceee08-d660-4203-9111-c33f9a274649/image-4.png" /><figcaption><a href="/self-contained-systems">Self Contained Systems の紹介</a></figcaption></figure>
<p>その結果、service単位でプロダクトの要件に合わせる形で、Webフロントエンドも最適化が始まっています。あるsystemではReact、別のあるsystemではSvelteが使われており、そこではWebフロントエンドのビルドにViteが使われています。</p>
<p>Viteが提供する高速な開発サーバーの立ち上がり、特定のフレームワークにとらわれない、そして高速なビルドスピードを提供するDX(Developer Experience)は、PLAIDの新しいプロダクト開発において恩恵を受けています。</p>
<p>このように、PLAIDのプロダクトでWebフロントエンドのアプリケーションに関わる部分は、ほぼEvan You氏によって作られたOSSによって提供されているといっても過言ではありません。</p>
<p>PLAIDの事業の成長を支えたVue.js、そしてこれから未来にPLAIDが提供していくプロダクトの支えになるVite、これらの2つのOSSに支援するために、これらの開発者Evan You 氏にスポンサーさせて頂いた次第です。</p>
<h2>企業でGitHub Sponsorsするのは難しくない</h2>
<p>GitHub Sponsorsは企業向けOrganizationアカウントにも提供していますが、PayPal またはクレジットカード払いのみしか現時点で対応していません。PLAIDではGitHub Enterprise Cloudを利用しておりOrganizationアカウントは請求書払いです。</p>
<p>企業のOrganizationアカウントでGitHub Sponsorsしたかったので、サイボウズさんのブログ記事方法と同じく、GitHub Sponsors用の専用Organizationアカウントを作ってGitHub Sponsorsしました。</p>
<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.cybozu.io%2Fentry%2F2021%2F03%2F19%2F110000" title="GitHub Sponsorsを使って「企業」として寄付をした話 - Cybozu Inside Out | サイボウズエンジニアのブログ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>
<p>ブログ記事は丁寧にチュートリアル的に書いてあったので、GitHub Sponsors自体は特に途中詰まらずにGitHub Sponsorsすることができました。(サイボウズさんの前例の記事には大変感謝しています！)</p>
<p>ブログ記事にも書いていますが、別OrganizationアカウントでGitHub Sponsorsしても、請求書払いのOrganizationアカウントに紐付けることがきるので、メインOrganizationアカウントにもきちんとスポンサーしているOSSのアカウントがリストアップされます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5dad4334-9610-48f4-ae03-4e433e976b66/image.png" alt=""></p>
<h2>最後に</h2>
<p>PLAIDでは今回のGitHub Sponsorsを機に、Vue.js、Viteだけでなく、他のOSSにもスポンサーしていく予定です。</p>
<p>GitHub Sponsorsの登場を機に、企業もOSSに対してスポンサーしやすくなっています。今回紹介したVue.js、Vite以外にも、成長して支援を必要としているOSSはいくつもあります。今回のこのブログ記事は、支援を必要としているOSSにもっとスポンサーが増えればと思い書きました。</p>
<p>このブログ記事が、OSSの支援のきっかけになれば幸いです。</p>
<p>プレイドではここで紹介したようなWebフロントエンドの技術を使って面白いProductを開発していきたいエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</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はGitHub Sponsorsを利用してOSSのスポンサーになりました

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a>  です。02021/05/25 - 2021/05/27 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21">Google Cloud Day: Digital</a> に 弊社3名で「Analytics」「Datahub」「ML」というテーマでそれぞれ登壇してきました。</p>
<p>こちらのブログでもその内容を簡単にまとめておきます。</p>
<h1>「100億人のユーザー行動からインサイトを得るための大規模分析基盤〜BigQueryを活用して〜」</h1>
<p>こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。</p>
<p>我々が提供するKARTEはついに累計解析ユーザー数が100億人を超えるまでに成長しました。KARTEには「顧客の解像度を上げることで事業成長へ」というコンセプトがあります。</p>
<p>これを実現するソリューションとして</p>
<p>といったユーザー行動からインサイトを得るためのプロダクトをご提供しております。1これらのプロダクトを支える大規模な分析基盤はBigQueryを主軸に構築されています。2月間で約200PB近くも蓄積される大規模のデータを素早く分析するには様々な工夫が必要です。今回のセッションでは具体的に3点</p>
<p>についてお話ししております。</p>
<p>他にもたくさんの工夫がなされており、弊社内でも分析基盤のアップデートは日々行われています。特にBigQueryはアップデートが早いプロダクトなので、最新情報をキャッチアップしつつ、運用改善を常に回せる体制が重要だと思います。そうすることにより、データ分析をビジネス上の価値へと繋げやすくなるはずです。</p>
<p>発表については <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d1-da-05">YouTube Live</a> でご覧いただけます。3また、<a href="https://speakerdeck.com/kargo113/10billion-user-analytics-architecture-using-bigquery">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="3855f3cfe4c547238af631a827001843" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「これからの環境の変化に強いデータ基盤をつくるためには」</h1>
<p>こちらは <a href="https://twitter.com/everydaycompman">@moto</a> より以下の内容をご紹介致しました。</p>
<p>近年プロダクトのライフサイクルは短く、顧客のデータ量は増加する中で短期間で大量のデータを扱う必要性が生じています。4しかし多くの企業のデータ活用はプロダクトと人の分断により進んでいない状況です。</p>
<p>KARTE DatahubはBigQueryやDataFlowを活用してデータの収集から活用までをワンストップで実現するプロダクトを提供しています。5データに関わる誰もが自分の得意な方法でデータ活用できるプロダクトを目指し、今後も機能を拡充していきます。</p>
<p>全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d3-pl-21">YouTube Live</a> よりご覧頂けます。</p>
<p>資料は追ってアップロード致します。</p>
<h1>「 GKE Autopilot で Ops レスなリアルタイム ML を実現 」</h1>
<p>こちらは @nichimuより、以下の２つのことをご紹介いたしました。</p>
<p>「GKE Autopilot を使用したリアルタイム推論基盤の構成」 では、リアルタイム推論基盤の内部用推論用APIとしてCloud Runを使用していましたが、「VPC内にデプロイ不可」「コンピュータリソースの永続性」の課題があり、今年の3月にローンチしたGKE Autopilotに置き換えることで、これらの課題を解決いたしました。</p>
<p>「Google Cloud の Professional Service (PSO) を活用したMLプロジェクトの遂行」では、もともと弊社で遂行していたMLプロジェクトが少なかった時期からPSOを活用することにより、Google Cloudが世界で培ってきた ML プロジェクトの進め方のノウハウを上手に活用することができました。</p>
<p>全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d3-ml-05">YouTube Live</a> よりご覧頂けます。</p>
<p>また、<a href="https://speakerdeck.com/nichimu/gke-autopilot-de-ops-resunariarutaimu-ml-woshi-xian">SpeakerDeck</a> に @nichimu 発表分の資料をアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="103959147e954d99b4d29113d4cccb3c" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
<p>今回も昨年に引き続きオンラインでの登壇となりました。6今年はなんと弊社だけで3セッションも登壇させて頂き、Googleさんには大変感謝致します。</p>
<p>全体を通して、基調講演含め他社様の事例や製品の最新情報などを知ることができ、非常に勉強になりました。ご紹介したように、弊社は「データによって人の価値を最大化する」というミッションのもと、様々なプロダクトを迅速に開発していっているので、来年も新たな情報を踏まえて登壇できたら良いなと思っています。</p>
<p>そんな弊社ではスピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


Google Cloud Day: Digital 2021 で「100億人のユーザー行動からインサイトを得るための大規模分析基盤」等、3セッション登壇しました

Google Cloud Day: Digital 2021 にて Analytics/ML/Datahub について3セッション登壇しました

<p>ごきげんよう、エンジニアの @tik-son です。02021/05/11 - 2021/05/12 に行われた <a href="https://aws.amazon.com/jp/events/summits/online/japan/">AWS Summit Online 2021 </a>で登壇してきましたので、このブログでもその内容を簡単にまとめておきます。</p>
<h1>「 基調講演： ビジネス変革に必要な柔軟性」</h1>
<p>まず、今回のAWS Summit Online 2021 では<a href="https://www.youtube.com/watch?v=RccC1gPGj2Q&amp;t=1130s">CEOの倉橋より「AWS活用による事業と組織のAgility強化」</a>というテーマでお話をさせていただきました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/50ea3466-de8d-407b-bb02-4a51229d8a89/image.png" alt=""></p>
<p>「<strong>数字への仕事から人への仕事に戻す</strong>」がPLAID の一つの野望でありまして、その実現においては、AWSやKARTEを上手く組み合わせることは有効であるということをお伝えしました。</p>
<p>そして、AWSとKARTEを組み合わせた一つの例として @tik-son より「AWS と KARTE で作る User State Driven System」についてお話しました。</p>
<h1>「AWS と KARTE で作る User State Driven System」</h1>
<p>1我々が提供するKARTEはAWSとGCPのマルチクラウドでインフラが構成されているのですが、アプリケーションレイヤーにおいてもAmazon Eventbridge やAmazon S3 などを介してお客様の AWS 環境と密な連携が可能です。</p>
<p>またKARTEの特徴の一つとして、人の状態(User State)の変化をトリガーに駆動するUser State Driven Systemといった概念があるのですが、この連携を通じて、サイト上のポップアップなどだけではなく、AWSのサービスを活用して、人の状態の変化をリアルタイムに捉えた様々なシステムを作ることができます。</p>
<p>本セッションでは、AWSとKARTEを組み合わせることでどのようにUser State Driven Systemを作ることが出来るのが具体例を含めてお話をしています。</p>
<p>発表については<a href="https://www.youtube.com/watch?v=FHFHsIVFaxI">アーカイブ配信</a>にてご覧いただけます。2また、<a href="https://speakerdeck.com/tikson/user-state-driven-system-with-aws-and-karte">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="14f427f918da4cf2b79d63728727fde8" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>また、このAWS Summit Onlineにあわせて、</p>
<ul>
<li><a href="https://integrations.solutions.karte.dev/aws/eventbridge">Amazon Eventbridge 連携</a></li>
<li><a href="https://developers.karte.io/reference#karte-datahub">Datahub Api V2</a></li>
</ul>
<p>がGAになっているので是非、そちらもご覧いただければと思います。</p>
<h1>最後に</h1>
<p>この記事を読んでお気づきの方もいらっしゃるかもしれませんが、PLAIDではKARTE単体だけでなく、AWSなど外部のサービスと組み合わせることで新たな価値を生み出すことが出来ないかという検証も始めています。</p>
<p>ですので 、KARTE自体の開発に興味がある！というエンジニアはもちろんのこと、KARTEとAWSなどの外部サービスを組み合わせて新たなシステム/価値を創出したい！というBiz/Devのメンバーも絶賛募集しています！3詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


AWS Summit Online 2021 にて「AWS と KARTE で作る User State Driven System」について話してきました

<p>エンジニアの大矢です。<br>
本日、Google Cloud Japan Blog で「<a href="https://cloud.google.com/blog/ja/topics/customers/plaid-anthos-clusters-on-aws">Anthos clusters on AWS を活用し、マルチクラウドでもGKE 由来の高度なマネージド環境を享受</a>」というタイトルで弊社の事例が紹介されました。<br>
私たちがどのような背景でマルチクラウド構成を採用するに至ったか、どのような狙いで <a href="https://cloud.google.com/anthos/clusters/docs/aws/concepts?hl=ja">Anthos clusters on AWS</a> を導入したかについて書かれていますので、ぜひ読んでみてください。また、細かいアーキテクチャの変遷について気になった方は<a href="/google-cloud-day-digital-2020/">こちら</a>の記事にある動画も合わせて見ていただけると幸いです。</p>
<p>この記事ではもう少し細かく、実際どう運用しているかや注意するポイントなどを書いています。</p>
<h1>Anthos clusters on AWS を活用したアーキテクチャ</h1>
<p>まずはじめに、Anthos clusters on AWS を導入することでどのようなアーキテクチャになったかを簡単に説明します。<br>
KARTE には大きく分けて2つのサーバ群があり、解析基盤（Track/Analyze）と管理画面（Admin）に分かれています。下図のように今回 Anthos clusters on AWS を採用したのは Admin の方で、Route53 Traffic Flow を利用してアクセスを振り分けています。通常時には、ほぼ全てのリクエストが GKE<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> 側にルーティングされるようになっており、AWS 側では GKE で動いてるものと同じワークロードがデプロイされ、停止した状態になっています。<br>
また Anthos clusters on AWS には、専用の VPC 内にクラスタを作成する方法と、既存の VPC にクラスタを作成する方法がありますが、図のように既存の VPC 内にある EC2 で動く mongoDB にアクセスできる必要があったため、既存の VPC に作成しました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b543e5a8-7c49-4de0-a173-09de140534d6/image6-2.jpeg" alt="image6-2"></p>
<p>また、管理画面で発生するほぼ全てのリクエストは GKE 側にルーティングされると書いたのですが、実は管理画面のコンポーネントのいくつかは Anthos clusters on AWS がメインとして動いており、その一つは KARTE 管理画面上で接客を編集する際にプレビューするための Proxy サーバになります。<br>
この Proxy サーバは元々 EC2 で動いており、サブドメインが動的に作られるため、AWS Certificate Manager（ACM） のワイルドカード証明書を利用していました。管理画面が GKE で動くようになった後、Proxy サーバも GKE に移行したかったのですが、GCP ではマネージドなワイルドカード証明書が利用できず、移行するにはセルフマネージド証明書の管理が必要でした。そのため、Proxy サーバを Anthos clusters on AWS 上でのみ動かすことにして、ACM のワイルドカード証明書をそのまま利用しています。<br>
このように AWS の機能を利用した方が管理が楽になったり、AWS にしかないような特徴を持つサービスを使いたい、となったときに簡単に AWS 上で Kubernetes を動かすことができます。</p>
<h1>マルチクラウド Kubernetes 運用のポイント</h1>
<p>今回 Anthos clusters on AWS を導入しマルチクラウド運用にする際に考慮したポイントは、運用にかかるコストを極力減らすことです。Anthos clusters on AWS では、<a href="https://cloud.google.com/anthos/multicluster-management/connect/overview?hl=ja">Connect</a> という機能を使うことで GKE の管理画面で AWS 上にあるクラスタを同じように管理できるなど、AWS 上のクラスタも同じように扱える仕組みがあります。<br>
しかし、いくつか注意点もあります。secret の管理もその 1 つですが、既に記事を書いてる<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>のでここには書きません。下記の 4 つについて、どのようにして運用しているかを説明します。</p>
<ul>
<li>デプロイ</li>
<li>manifest の管理</li>
<li>Ingress</li>
<li>監視</li>
</ul>
<h2>pull 型のデプロイ</h2>
<p><a href="https://www.weave.works/technologies/gitops/">GitOps</a> では push 型と pull 型の 2 つのパターンがあります。push 型は kubernetes クラスタ外にある CI システム上で スクリプトを実行することによりデプロイします。pull 型は kubernetes operator がクラスタの内部からデプロイをします。<br>
Anthos clusters on AWS はプライベートクラスタを構成するため、VPC 内のインスタンスからでないとデプロイを実行できません。<br>
push 型のデプロイシステムを採用していた場合は VPC 内に CI システムを置くか、VPC 内にある踏み台サーバに対して ssh tunnel を貼る必要がありました（現在はベータ版の <a href="https://cloud.google.com/anthos/multicluster-management/gateway/using?hl=ja">Connect Gateway</a>  を使うことで VPC の外からでも kubectl を使うことができます）。<br>
私たちは pull 型のデプロイツールである <a href="https://argoproj.github.io/argo-cd/">ArgoCD</a> を採用していたため、GKE にデプロイするのと同じように AWS にもデプロイすることができます。具体的には、ArgoCD の Application の設定ファイルを1つ書き加えるだけで、AWS のデプロイフローを整えることができました。</p>
<h2>Kustomize を利用した manifest の管理</h2>
<p>マルチクラウドに限った話ではないですが、複数環境の差分を管理するためのツールとして Kustomize はとても便利です。<br>
冒頭に書いたように、Active/Standby 構成のため AWS にも GKE と同じものデプロイしていますが、ほとんどのワークロードは停止しています。また、GKE で利用してる一部のリソースやワークロード（BackendConfig や <a href="https://cloud.google.com/kubernetes-engine/docs/tutorials/custom-metrics-autoscaling?hl=ja">custom-metrics-stackdriver-adapter</a>）はそのまま使うことはできません。<br>
共通の部分は同じ manifest を使いつつ、環境ごとにパラメータを変えたり Active/Standby 構成を実現するために、Kustomize を利用しています。<br>
例えば、全ての Deployment と CronJob を止めるために、下記のようなパッチを使っています。</p>
<pre><code class="language-yml">- op: replace
  path: /spec/suspend
  value: true
</code></pre>
<pre><code class="language-yml">- op: replace
  path: /spec/replicas
  value: 0
</code></pre>
<pre><code class="language-yaml">patches:
  - path: path/to/cronjob-suspend.yml
    target:
      kind: CronJob
  - path: path/to/replicas-zero.yml
    target:
      kind: Deployment
</code></pre>
<p>このようにすることで、新しく追加したワークロードが AWS 上で意図せず動いてしまう心配もないですし、仮に GCP 側で障害が起こり待機系に切り替えなければいけなくなった際には、このパッチを外してデプロイするだけで GKE と同じように全てのワークロードが立ち上がります。</p>
<h2>Ingress</h2>
<p>Anthos clusters on AWS では Classic Load Balancer, Network Load Balancer および Application Load Balancer（ALB）が利用できます。私たちは L7 Load Balancer を使う必要があったので ALB を利用しました。<br>
ALB を利用するためには AWS Ingress Controller をインストールしたり、サブネットにタグをつけたりする必要がありましたが、ドキュメントに手順が詳しく書いていたため導入まではスムーズに進むことができました。<br>
注意する必要があるのは、GCP の Cloud Load Balancer と ALB ではパスベースルーティングにおけるルールの評価方法が異なることです。Cloud Load Balancer ではワイルドカードが指定でき、複数のルールにマッチする場合はより限定されたルールの方に従います。ルールの定義順はルーティングに影響しません。例えば下記のような spec を持つ Ingress によって生成された Cloud Load Balancer があり、<code>http://example.com/hoge/123</code> にリクエストを送ると、2番目のルールが適用されて hoge service にルーティングされます。</p>
<pre><code class="language-yaml">spec:
  rules:
    - host: example.com
      http:
        - path: /*
          backend:
            serviceName: default
            servicePort: 80
        - path: /hoge/*
          backend:
            serviceName: hoge
            servicePort: 80
        - path: /huga/*
          backend:
            serviceName: huga
            servicePort: 80
</code></pre>
<p>しかし、上記の spec の Ingress から生成された ALB では <code>http://example.com/hoge/123</code> にリクエストを送ると default service にルーティングされます。<br>
これは、ALB ではルールの評価が上に定義されたものから順に行われ、マッチした時点でそのルールが適用されるためです。下記のように<code>/*</code> のルールを一番下に書くことでこの問題を回避し、GKE と AWS で同じ Ingress の manifest を利用できました。</p>
<pre><code class="language-yaml">spec:
  rules:
    - host: example.com
      http:
        - path: /hoge/*
          backend:
            serviceName: hoge
            servicePort: 80
        - path: /fuga/*
          backend:
            serviceName: fuga
            servicePort: 80
        - path: /*
          backend:
            serviceName: default
            servicePort: 80
</code></pre>
<h2>監視</h2>
<p>監視についてもいくつか選択肢があります。オープンソースの Logging Agent および Monitoring Agent を追加でインストールすることで、Cloud Logging, Cloud Monitoring が利用できます<sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>。<br>
私たちは元々マルチクラウドを構成を採用していたため、全ての監視を Datadog に集約していました<sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup>。そのため、Anthos clusters on AWS の監視についても Datadog を採用しました。既に GKE でも Datadog を利用していたため、同じように datadog-agent などのコンポーネントをデプロイする<sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup>だけで簡単にロギング・モニタリングを実現できました。</p>
<h1>最後に</h1>
<p>Anthos clusters on AWS を利用することで、運用コストを余計にかけすぎることなく、高可用性や AWS サービスの活用を実現しました。<br>
今後はさらにマルチクラウドの特性を活かして、新たな価値を生み出していきたいです。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>Anthos clusters on AWS も GKE ではありますが、この記事では Google Cloud 側の GKE のことを単に GKE、AWS 側の GKE のことを on AWS と書いています。 <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p><a href="/nayanda-kubernetes-secret-management/">悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由 | PLAID engineer blog</a> を読んでいただけると幸いです。 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p><a href="https://cloud.google.com/anthos/clusters/docs/aws/how-to/logging-and-monitoring?hl=ja">AWS 上の Anthos クラスタのロギングとモニタリング  |  Google Cloud</a> <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>私たちが Datadog をどのように活用しているかより詳しく知りたい場合は<a href="/datadog-summit-tokyo/">こちら</a>の記事を是非読んでみてください。 <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p>詳しい手順は<a href="https://cloud.google.com/solutions/partners/monitoring-anthos-with-datadog?hl=ja">公式ドキュメント</a>に書いてあります。 <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


エンジニアの大矢です。本日、Google Cloud Japan Blog で「Anthos clusters on AWS を活用し、マルチクラウドでもGKE 由来の高度なマネージド環境を享受」というタイトルで弊社の事例が紹介されました。

Google Cloud Japan Blog で Anthos clusters on AWS を活用した事例が紹介されました | PLAID engineer blog

Google Cloud Japan Blog で Anthos clusters on AWS を活用した事例が紹介されました

<p>こんにちは！エンジニアの@tik-son, @ikemonnとMLエンジニアの@nichimuです。</p>
<p>本日ついに待望の<a href="https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot">GKE Autopilotがリリース</a>されましたね！<br>
この記事では、GKE Autopilot上で動いているリアルタイム推論基盤でなぜ我々がGKE Autopilotを利用することにしたのかについてお話しします。</p>
<h1>MLリアルタイム推論基盤とは</h1>
<p>リアルタイム推論基盤とは、機械学習のモデルを使用して、リアルタイムに推論が行える基盤のことです。<br>
このリアルタイム推論基盤を用いることで、</p>
<ul>
<li>エンドユーザーがsession内で電話するかを予測する</li>
<li>エンドユーザーが会員登録を行ったsession内で資料請求をするか予測する</li>
</ul>
<p>のように数秒-数分後にエンドユーザーがどんな状態であるかなどを予測することが実現可能になります。<br>
この基盤はまだ絶賛開発中で誰もが簡単に使える状態になっていないのですが、このブログを読んで何かビジネス課題を解決したい！という方がいましたら、ぜひ、弊社までお問い合わせください！という宣伝はさておき、さっそく本題に入っていきます。</p>
<p>リアルタイム推論基盤のデータの流れとしては、以下のようになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f4c8102-da2d-4ba7-987f-339b82717b88/realtime_inference.png" alt="realtime_inference"></p>
<ol>
<li>エンドユーザーがwebやapp上で何かしらの行動を行い、Event DataをKARTEのリアルタイム解析/アクション基盤 (Not ML) に送信する</li>
<li>リアルタイム解析/アクション基盤に送られたEvent Dataをリアルタイム推論基盤 (ML) にCloud Pub/Subを通じて送信する</li>
<li>Cloud Dataflow上でEvent Dataに関する以下の処理を行う
<ol>
<li>Event Dataを整形して、生ログとしてCloud Spanner<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>に保存する</li>
<li>Event Dataをfilterして、推論用APIへの推論トリガーをCloud Pub/Subを通じて投げる</li>
</ol>
</li>
<li>推論用API (Cloud Run) で、機械学習モデル<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>を用いた推論を行い、推論結果をCloud Bigtableに書き込む</li>
<li>Cloud Bigtableに書き込まれた推論結果をコア基盤から読み込み、クーポンなどのActionを配信する</li>
</ol>
<p>今回、GKE Autopilotを使用した部分としては、図の赤枠で囲ってある推論用内部API componentになります。<br>
GKE Autopilotがローンチされるまでは、compute resourceとしてCloud Runを使用しており、以下でどのようにしてGKE Autopilotを使うようになったかをお話してまいります。</p>
<h1>推論用内部API の要件と抱える課題</h1>
<p>さて、推論用内部API として、Cloud Runを使用していると記述しましたが、推論用内部API の要件としては以下になります。</p>
<ol>
<li>以下を実現するため、自由度高くコードを書くことができるDocker Imageベースでデプロイできること
<ul>
<li>Cloud Pub/Subから推論トリガーを受け取り、予測を開始する</li>
<li>生ログデータをCloud Spannerから取得する</li>
<li>Pythonで書かれた機械学習のモデルを使って、予測を行う</li>
<li>Cloud Bigtableに予測結果を書き込む</li>
</ul>
</li>
<li>リアルタイム解析/アクション基盤に組み込んで使用するため、システムとして高スケーラビリティや高可用性などのシステムとしての強さがあること</li>
<li>基盤における運用/開発ではなく、モデルの作成やデータの活用など、MLエンジニアが本質的な価値にフォーカスする状態を作れること</li>
</ol>
<p>当初、これらの要件を満たすために、色々とベンチマークをした結果Cloud Runを使用していましたが、以下の課題がありました。</p>
<ul>
<li>Service Accountでの制御はかけているものの、CloudRunの仕様でCloudRun自体に外部IPを持たせないといけないため、セキリュティ的に綺麗な設計ではない</li>
<li>Cloud Pub/Subで推論トリガーを受け取るときにPush型を使用するが、Push型でのError Handlingが難しいので、なるべくPull型で扱いたい</li>
</ul>
<p>この課題はGKEを利用することで解決できるのですが、</p>
<blockquote>
<ol start="3">
<li>基盤における運用/開発ではなく、モデルの作成やデータの活用など、MLエンジニアが本質的な価値にフォーカスする状態を作れること</li>
</ol>
</blockquote>
<p>この要件と先程述べた課題とのバランスが難しく、最終的にはMLエンジニアがGKEのインフラレイヤーを管理/運用する大変さを鑑みて、課題に目をつぶりCloud Runを利用している状況でした。</p>
<h1>GKE Autopilotとは？</h1>
<p>そういった課題をかかえたところ、我々にとってちょうどいい塩梅のProductが発表されました。それが<a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview">GKE Autopilot</a>です。<br>
GKE Autopilotとは、GKEの新しいmodeです。(従来のGKEはGKE Standard)<br>
Control Planeに加えて、Nodeの管理もGoogleのSREが行ってくれるので、クラスター管理の運用コストを下げることができます。さらに、SLAも提供されているので、Nodeの可用性やサイジング、スケーリングなどを気にすることなく、GKEを利用することができます。GKE Autopilotでは、ワークロードに応じて自動で裏側のHWをプロビジョニングするので、サービスやアプリケーションの開発に専念することができます。</p>
<p>特徴は下記です。</p>
<ul>
<li>NodeもGoogleが管理してくれる</li>
<li>ユーザーのワークロードにもとづいてリソースがプロビジョニングされる</li>
<li>Podに対してもSLAが設定されている</li>
<li>Podレベルで課金される</li>
<li>ユーザーのプロジェクト内でclusterが構築される(他のユーザとリソースを共有しない)</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b23f1257-08bb-44af-833f-ab67e42db6da/gkeauto.png" alt="gkeauto"><br>
<a href="https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot">https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot</a></p>
<p>また、GKE Autopilotでは下記のようなよく使われるワークロードやツールがサポートされており(一部今後サポート予定)で、様々なユースケースで活用できます。</p>
<ul>
<li>Stateless web app</li>
<li>Custom Database (StatefulSet)</li>
<li>Long-running batch job (Job)</li>
<li>DaemonSets that don’t violate GKE Autopilot rules</li>
<li>Add-ons: Cloud Run for Anthos, Istio</li>
<li>Machine Learning (GPU, TPU)</li>
<li>Tools and ecosystem - for example, Helm charts that don’t violates GKE Autopilot rules</li>
</ul>
<p>さらに、下記のような設定も利用できるため、使い勝手としても限りなくGKEに近い自由度があります。</p>
<ul>
<li>高可用性: Regional, Regular Release Channel, Auto-Update, Auto-Repair, Surge Upgrade</li>
<li>スケーリング: HPA, VPA, NAP</li>
<li>ネットワーク: Private clusters, VPC Native (alias IP), IP-friendly (limit cluster size/ pods per node), setup Cloud NAT</li>
<li>セキュリティー: Workload Identity, Shielded Nodes, Secure-boot-disk, etc</li>
</ul>
<p>以下のように、manifestの書き方もGKEのmanifestとほぼ同様に書くことができます。</p>
<pre><code class="language-yaml">apiVersion: &quot;apps/v1&quot;
kind: &quot;Deployment&quot;
metadata:
  name: &quot;plaid-test&quot;
  namespace: &quot;plaid&quot;
  labels:
    app: &quot;plaid-test&quot;
spec:
  replicas: 3
  selector:
    matchLabels:
      app: &quot;plaid-test&quot;
  template:
    metadata:
      labels:
        app: &quot;plaid-test&quot;
    spec:
      serviceAccountName: gke-auto
      containers:
      - name: &quot;realtime-inference&quot;
        image: &quot;gcr.io/plaid-test/realtime-inference:latest&quot;
        resources:
          requests:
            memory: &quot;6Gi&quot;
            cpu: &quot;2&quot;
          limits:
            memory: &quot;6Gi&quot;
            cpu: &quot;2&quot;
</code></pre>
<p>くわしくは<a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#limits">GKE Autopilotのドキュメント</a>をご確認ください。</p>
<h1>GKE Autopilotの導入</h1>
<p>GKE Autopilot導入は、KARTEのリアルタイム解析/アクション基盤を作っているエンジニア、MLリアルタイム推論基盤を作っているエンジニアの両方で検証をしながら進めていきました。<br>
<code>推論用内部APIの要件と抱える課題</code> でお話した要件と課題をほぼ満たせることとなり、productionのworkloadで現在稼働しているのですが、その中で以下のようなPros/Consを感じました。</p>
<h2>リアルタイム解析/アクション基盤を作っているインフラエンジニアが感じたこと</h2>
<ul>
<li>Pros
<ul>
<li>クラスタのインフラレイヤーをGoogleが管理してくれるので運用が楽そう。(productionの運用は本日から始めるので、実際の恩恵を受けるのはこれからだと思っている)</li>
</ul>
</li>
<li>Cons
<ul>
<li>vpc native cluser前提なので、正しく設計/構築するには、利用するip range/NAT等のNWインフラの知識が必要になり、アプリケーションエンジニアだけでは現状難しそう。(privateなNW通信を行わない、vpc NWはdefaultでcloud pubsubでコンポーネント間を通信するというようなシステムであれば、NWを意識しなくていいので構築は楽かもしれない)</li>
<li>preemptible vmに対応していない</li>
<li>基本GKEなので、GKEで出来ないことはできない。例えば、clusterレベルのスケールアウトがGKEより速いなどはない。(厳密にはこれはConsではないとは思うが、マネージドサービスである期待をこめて、一応書いておく)</li>
</ul>
</li>
</ul>
<h2>MLリアルタイム推論基盤を作っているMLエンジニアが感じたこと</h2>
<ul>
<li>Pros
<ul>
<li>manifestにresourcesのlimitsとrequestsを記述するだけで、MLエンジニアが欲しいマシンリソースが簡単に用意でき、運用まで期待できる</li>
<li>リソースはCloudRunと異なり、動き続ける前提なのでPub/SubのPull型を簡単に扱うことができる</li>
<li>インフラの柔軟性を担保しつつ、運用を考えなくていいのはいい。開発が捗る。</li>
</ul>
</li>
<li>Cons
<ul>
<li>MLリアルタイム推論基盤で今後利用したい、GPUがまだサポートされていない</li>
</ul>
</li>
</ul>
<h1>まとめ</h1>
<p>GKE Autopilotは銀の弾丸ではないので、インフラエンジニアからすると微妙な部分が少し多めに見えてしまうのですが、このProductのポイントはそこではなく、 <code>ある程度柔軟なインフラが必要だけど運用までは面倒見きれないようなユースケースに絶妙にハマる</code> ということだと実際使ってみて強く感じました。<br>
(くわしくは<a href="https://medium.com/google-cloud-jp/gke-autopilot-87f8458ccf74">Google CloudのKazuuさんのブログ</a>をご確認ください)</p>
<p>Consで書いたことはGCPのことなので、GA後にすぐに対応してもらえるだろうと勝手に期待しています(笑)<br>
また、privateなvpc内通信が必要にならないよう、cloud pubsubなどでシステム間を疎にして設計していけば、GKE Autopilotの恩恵をより受けやすくなるのではないかとも感じました。もちろん、システム間のやり取りが大量なものはprivateなvpc通信前提で作る方がコストが安くなるとは思いますが、このあたりはトレードオフになると思うので上手く見極めながら設計していくといいと思われます。<br>
我々も今後はこのあたりを意識しながら上手くGKE Autopilotなどを駆使し、システムを作っていきたいと思います。</p>
<h1>最後に</h1>
<p>プレイドではGKE Autopilotのような新しい技術をうまく使い、面白いProductを開発していきたいエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>
<p><a href=""></a></p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>Cloud SpannerにEvent Dataを書き込んでいる理由としては、以下の２つの理由があります。(1. 機械学習のモデルを使用した推論ではエンドユーザーの過去の情報も必要だが、Event Dataには過去の情報はあまり含まれていないため、過去の情報も保持しておく必要がある, 2. 機械学習のモデルを作成する際にはBigQueryにSQLを投げて特徴量作成の試行錯誤をするため、推論時もSQLがかけるDBだと相性がよい) <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p>機械学習のモデルの作成やデプロイなどは、AI Platform NotebookやAI Platform Pipelinesを使用して行っています。 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


本日ついに待望のGKE Autopilotがリリースされましたね！
この記事では、GKE Autopilot上で動いているリアルタイム推論基盤でなぜ我々がGKE Autopilotを利用することにしたのかについてお話しします。

GKE Autopilotで作るMLリアルタイム推論基盤 | PLAID engineer blog

GKE Autopilotで作るMLリアルタイム推論基盤

<p>PLAIDでエンジニアをしている@kantetsuです。</p>
<p>現在はKARTEの<a href="https://cxclip.karte.io/product/userstory_renewal/">ユーザーを知る</a>画面のリニューアルや改善を主に行なっています👨‍💻</p>
<p>PLAIDでは、ここ数年デザイナーとエンジニアが一緒のチームとなり、デザイナーも機能公開に携わるようになって、機能を公開するプロセスが仕組み化されてきました🤖</p>
<p>例えば、シナリオテストやユーザビリティテストもここ最近では定着してきました（以前に書いた<a href="/release_survey_form/">KARTEのアンケートフォーム（β版）公開までの道のり</a>でも一部触れています）。</p>
<p>このような王道のテストをやりつつも、実は機能を公開するまでの手順でKARTEや社内ツールを用いたユニークな改善方法があるので、今回この場を借りて共有したいと思い、執筆しました✍️</p>
<h1>KARTEとは</h1>
<p>どのような改善方法があるのかを紹介する前に「KARTEって何なのか？」を説明させてください。ここをすっ飛ばしちゃうと、あとでよく分からないことになりそうなので🙏</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/86be2ac0-77b2-41a5-a4a0-8d449ad32ee6/insight.png" /><figcaption>https://karte.io をチェック！</figcaption></figure>
<p><a href="https://karte.io/">KARTE</a>では、サイトに計測タグを貼ることによって、ユーザーの行動解析をします。そのサイトでのエンドユーザーの一つ一つの行動（これをKARTEの中ではイベントと言う）をクライアントさんはKARTEの管理画面内で見ることができます。その中でエンドユーザーの行動を見れるのはもちろん、エンドユーザーに配信するアクションの編集やライブ・レポートの閲覧などができます。</p>
<h2>KARTEでイベントを発火させてユーザーを観察する</h2>
<p>KARTEでクライアントさんがどの画面でどのような行動をしているか見るために、実はKARTEの管理画面ではKARTEのタグを入れています。</p>
<p>で、これをどう開発で利用しているかというと、画面のリニューアルや改善をした際に「この週にどのくらいの人が保存ボタンを押したのか」「この日にどのくらいモーダルが開かれたのか」をKARTEのイベントを発火させることで観測しています📊</p>
<p>私たちのチームでは開発後にデザイナーがどの機能が使われているかを下記のようにリストアップして、それらを計測できるようにソースコードに計測のコードを入れていきます👨‍💻</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/387a6d83-2aed-46c0-b95f-27cdcd023eca/----------2020-11-02-23.03.02.png" /><figcaption>取りたい指標をリストアップしています</figcaption></figure>
<p>そして、実際にイベントが発火すると、KARTEのイベント画面やストーリー画面に表示され、「誰がどのタイミングで、どのくらいの人が〇〇ボタンを押したのか」などがKARTEで見ることができました👏</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e2546b14-22f4-427d-81a6-b115a5c86575/event.png" /><figcaption>計測されるとイベント画面に発生数と発生したユーザーと時刻が表示されます</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6b8bb35e-5289-431b-893c-7ff5600489e5/story.png" /><figcaption>もっと解像度高く見たい場合はストーリー画面で見ることもあります</figcaption></figure>
<p>一部のメンバーは<a href="https://mode.com/">Mode</a>を使って、SQLを書くことでこれらのイベントをより細かく集計もして、定期的にslackに通知してチームにシェアしています。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cecae12e-cadf-4a1b-a8f2-a719fc540693/mode.png" /><figcaption>実際に発生したイベントをModeで集計したレポート</figcaption></figure>
<h2>KARTE Liveで管理画面をどのように利用しているか見てみる</h2>
<p>KARTEの管理画面ではKARTE Liveによって可視化しているので、クライアントさんがどのように管理画面を使っているのかを視覚的に見ています。</p>
<p>例えば、新画面をリリースした場合にその新画面にクライアントさんがアクセスしたら、社内のSlackに「〇〇さんがこの画面にアクセスしました」っていう通知を飛ばして、その人のストーリーに飛んで、<a href="https://karte.io/product/live/">KARTE Live</a>を開いて見てみます👀</p>
<p>これによって、自分たちの新画面で想定された使い方をされているのか、画面上で戸惑っている部分はあるのかを実際の画面を通して見ることができます。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/060017a7-e3f4-4ae3-9263-8d9bf68f23f7/image.png" /><figcaption>KARTEを使った通知の仕組み</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76db6004-25b1-438a-8ba5-b98d7ef10777/s_DE66FBEA70BB0CBF23B9F0B5499DD68BB499403C478D678EB3C5F0DE92B2B6F9_1604482900676_slack.png" /><figcaption>該当ユーザーが通知され、チーム内で会話しています</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c01c4e69-a9eb-4a1e-b2f9-75d68921cadd/----------2020-11-04-19.30.33.png" /><figcaption>KARTE Liveでユーザーの動きをもっと強烈に見て、改善に繋げています</figcaption></figure>
<p>自分たちのチームはユーザーを知る画面をKARTEを使ってまさに「ユーザーを知る」ことで改善しています！</p>
<p>手前味噌ですが、KARTEは画面の改善にも強力なサービスでもあると思っています🚀</p>
<h2>KARTEの管理画面にコメントして、Issueに起票する</h2>
<p>今までのはKARTEを利用したKARTEの管理画面の改善方法を紹介しましたが、社内ツールもKARTEを進化させています💪</p>
<p>下記の二つのアプリを使っています。（これら二つはPLAIDの社内アプリなので外部公開していないので悪しからず…🙇‍♂️）</p>
<p>自分たちのチームではチーム内で自分たちの開発した画面を触って、バグのある箇所やユーザビリティが低い箇所にP Appでコメントしていくぽちぽち会を実施しました👨‍💻</p>
<p>P Appを使うことでブラウザ上でどこに誰がコメントしているのかを簡単に見ることができ、また簡単に投稿もできます。そして、Slack上でもその要素の画像も添えて投稿されるので、Slackにフィードバックを集約もすることができます。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1b643170-3092-4e50-8bdb-1550744fc9b7/slack2-2.png" /><figcaption>P AppにコメントされるとSlackにも同期される</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/679a0414-0e56-40bf-9477-be8b20167734/image-1.png" /><figcaption>サイト上の要素にコメントできるP App</figcaption></figure>
<p>そして、PLAIDでは基本的にはGitHubのIssueに起票してから開発するので、先ほどP Appで投稿されたSlackの投稿をS Appを使ってIssueにします。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e9de211c-2f3b-4ac0-a912-96f3debb8a91/image-2.png" /><figcaption>さっきP Appで投稿された投稿をSlack上でIssue化するS App</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fd9d488b-b897-4959-8295-857d0a4dd161/----------2020-11-04-18.51.33.png" /><figcaption>Issueのタイトルを記入して、Issueを作るボタンを押すと該当のレポジトリにIssueが起票される</figcaption></figure>
<p>これによって、画面でおかしいと思った箇所を逐一スクショしてSlackやGitHubに共有する手間がなく、シームレスにIssueにあげることにできました👏</p>
<h2>最後に</h2>
<p>今回はKARTEの開発ではPLAIDだからこそ、KARTEだからこそできる管理画面の観察方法や改善方法を紹介しました😊</p>
<p>もし他のチームで使われている改善方法があったり、新しい改善術があれば、別の機会で紹介したいと思います！</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。0詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


PLAIDでは機能公開する際にユーザビリティテストなどを行なっていますが、それとは別にKARTEの機能や社内ツールを用いたユニークな改善方法を行なっているので、それらをご紹介します！

PLAID流プロダクト改善術をお見せします！

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


"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 について話してきました

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

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


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

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


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