Engineer Blog

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

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。</p>
<p>今回は、2023年4月からBigQueryが<strong>Editions</strong>という料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。</p>
<p>BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。</p>
<p>しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり</p>
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
<p>による影響が発生しました。</p>
<p>storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、<strong>Long-Term Physical Storage</strong> という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。</p>
<p>一方で、slotの単価が <strong>$0.024/slothour</strong> から <strong>$0.048/slothour</strong> へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、<strong>Bigquery-Slot-Optimization Team</strong>です！</p>
<p>本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。</p>
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
<p>Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。<br>
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png"></p>
<p>MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。</p>
<p>まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。</p>
<p>時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。<br>
単純には</p>
<pre><code class="language-sql">  SELECT
    job_id,
    period_start,
    period_slot_ms
  FROM
    `{YOUR_PROJECT_NAME}.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
</code></pre>
<p>のようにすれば、簡単に取得できます。</p>
<p><strong>period_slot_ms</strong>とはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。</p>
<p>このテーブルをさらに、<code>INFORMATION_SCHEMA.JOBS</code> というテーブルを用いて、job_idをkeyにjoinすることで、実行されたqueryを取得できます。取得したqueryをさらに、<code>REGEXP_CONTAINS</code> 関数を用いて、正規表現で任意のJobに集約します。例えば、<code>WHEN REGEXP_CONTAINS(query, r'/* JOURNEY') THEN 'journey'</code> という表記により、queryのコメントに<code>/* JOURNEY</code> が含まれているqueryを <a href="https://karte.io/product/journey/">Journey</a> というProductのために使っているQuery Jobという形で集約できます。</p>
<p>集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。</p>
<p>Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。<br>
TypeScriptで書くとこのようになります。（※一部抜粋）</p>
<pre><code class="language-typescript">  const slots: v2.MetricSeries = {
    metric: '${metric_name}',
    type: 2,
    interval: 1,
    points: points,
    tags: [`project:${projectId}`, `task:${task}`],
  };

  const params: v2.MetricsApiSubmitMetricsRequest = {
    body: {
      series: [slots],
    },
  };

  apiInstance
    .submitMetrics(params)
    .then((data: v2.IntakePayloadAccepted) =&gt; {
      console.log('API called successfully. Returned data: ' + JSON.stringify(data));
    })
    .catch((error: any) =&gt; console.error(error));
</code></pre>
<p>この関数をDeployするには</p>
<pre><code class="language-bash">gcloud functions deploy $FUNCTION_NAME \
  --project=$GCP_PROJECT \
  --region=$REGION \
  --runtime nodejs14 \
  --entry-point=index \
  --gen2 \
  --source ./build \
  --trigger-topic=$TOPIC_NAME \
  --trigger-service-account=$TRIGGER_SERVICE_ACCOUNT_ADRESS \
  --service-account=$SERVICE_ACCOUNT_ADRESS \
  --retry \
  --timeout=180s \
  --set-env-vars=DATADOG_APP_KEY=$DATADOG_APP_KEY,DATADOG_API_KEY=$DATADOG_API_KEY
</code></pre>
<p>というgcloudコマンドだけでdeployできます。</p>
<p>さらに、このFunction を Cloud Scheduler で定期的に実行します。<br>
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。</p>
<p>結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。<br>
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png"></p>
<p>これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。<br>
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。</p>
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
<p>BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。</p>
<p>弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。<br>
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。<br>
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。<br>
これを最適化するために導入されたのが、AutoScaleです。</p>
<p>そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。</p>
<p>そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。</p>
<p>これらを考慮した上で、弊社で最適化した結果が以下の通りです。<br>
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png"></p>
<p>いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。<br>
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。<br>
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。<br>
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png"></p>
<p>ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。<br>
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。</p>
<p>最も大事なのは、<strong>Productごとに要件を把握し適切にReservationを配分する</strong>ことであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。</p>
<h2>最終的なコストは...?</h2>
<p><strong>全体で約20%のコスト削減を実現</strong> することができました。<br>
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。</p>
<p>以上のように<br>
① Monitoringの整備によるJobごとのSlot監視と削減<br>
② AutoScaleの導入によるSlotBaseLineの最適化全体</p>
<p>でBigQuery全体として、約20%のコスト削減を実現しました。</p>
<p>BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


BigQuery Editionsにおけるコスト最適化

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内で脆弱性診断を行なっている理由や、どのように診断から修正までを行なっているか、また社内で脆弱性診断をやることでどのような変化が起きたかについて紹介します。

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

今回のブログではプラットフォームチームにて取り組んだ、異なるデータベース間のリアルタイムレプリケーションについて解説いたします。

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

<p>初めまして！エンジニアのとさ (@tosa_now)です！</p>
<p>プレイドは、2023/10/28 (土) に開催された<a href="https://vuefes.jp/2023/">Vue Fes Japan 2023</a>にゴールドスポンサーとして協賛しました。</p>
<p>スポンサーブースの運営をする機会をいただき、参加者の皆さんに<a href="https://karte.io/">KARTE</a>のデモや現在作成中の機能についての説明やお話をすることができました。</p>
<p>今回のブログでは、参加したVue Fes Japanの様子をお伝えできればと思います。</p>
<p>今回スポンサーとして参加した理由は、PLAIDが開発しているKARTEというプロダクト内ではなんとVueが0系の時から利用しており、現状でも管理画面の大部分がVueで書かれておりコミュニティに助けられているので少しでも還元したいという思いから参加しました！</p>
<h2>Vue Fes 当日の様子</h2>
<p><img src="https://ik.imagekit.io/plaid/20f62fe9-7a00-4d55-b0bc-8e3702e7b810/1000002289.jpg" alt="1000002289.jpg"><em>スポンサーブースの準備完了後の写真</em></p>
<p>主にブースではKARTEのプロダクト説明をメインで行っていました。<br>
来訪してくださった方とVue2からVue3への移行をどのように進めているのかなどの技術雑談話でもりあがりました。</p>
<p><img src="https://ik.imagekit.io/plaid/bcbfc85c-7535-4087-a132-75fbb2c890cc/IMG_4361.jpg" alt="IMG_4361.jpg"><em>エンジニアのnichimuさんがスポンサーブースに立っている様子</em></p>
<p>プロダクト説明では、<a href="https://blocks.karte.io/">KARTE Blocks</a>と新機能であるエレメントビルダーを開発しているエンジニアのjunjun (@junish_js) さんによるデモで大いに盛り上がりました！！</p>
<p>エレメントビルダーの開発の裏側は<a href="https://cxclip.karte.io/products/developer/action-editor/">こちら</a>の記事で解説しています</p>
<p><img src="https://ik.imagekit.io/plaid/4a62f6c0-d15d-49ff-a81f-cb11fe87f2d6/IMG_4364.jpg" alt="IMG_4364.jpg"><em>エンジニアのjunjunさんがプロダクト説明をしている様子</em></p>
<p>とさの個人的な趣味でVue Fesの開催二日前に発売されたHHKB Professionalのお試し会も開催しました。興味を持ってくださる方が多くて嬉しかったです。<br>
<img src="https://ik.imagekit.io/plaid/00ea3072-8ce7-4ef7-ad70-6a0cfcf0e2a3/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-11-0510.53.04.png" alt="スクリーンショット2023-11-0510.53.04.png"></p>
<p>Vue Fesのスポンサーブース全体が賑やかでどの企業さんも回っていてとても楽しかったです。</p>
<h3>参加した開発メンバーの感想</h3>
<p>デザイナーの今西さん<br>
今回、ブース対応を初めて担当し、KARTEの魅力が少しでも伝わっていれば嬉しいなと思います。ひさしぶりのオフラインカンファレンスということで、当日は大いに盛り上がり、とても楽しい1日を過ごすことができました！</p>
<p>エンジニアのjunjunさん<br>
Vue Fesにスポンサーとして参加したのが新鮮でした。また、イベントは参加者と交流するという楽しみかたがあるんだと気づきました。私はVue Fesがきっかけでプレイドを知って入社したので、皆さんも知っていただけたら嬉しいです。またお会いましょう！</p>
<h3>おわりに</h3>
<p>Vue Fesのスタッフの皆さん、準備及びに当日の運営ありがとうございました！<br>
PLAIDはこれからもVue.jsのコミュニティグループの活動を応援しています。</p>
<p><img src="https://ik.imagekit.io/plaid/a0f082ec-3452-4958-a31d-50c506335c07/1000002292.jpg" alt="1000002292.jpg"><em>ブース撤収直後のサインボードの様子</em></p>


株式会社PLAIDはVue Fes Japan 2023にゴールドスポンサーとして参加して、スポンサーブースの運営を行いました！

Vue Fes Japan 2023にゴールドスポンサーとして参加しました！

KARTE 管理画面のパフォーマンスの監視をするにあたって考えたことや Datadog の活用のポイント、改善で取り組んだことについて紹介します。

Datadog を使った KARTE 管理画面パフォーマンス改善の取り組み

2021年9月14日に正式リリースしたKARTE Blocksの裏側を紹介する連載の第一弾です。
KARTE Blocksを支える技術とその技術を選んだ理由について紹介します。

KARTE Blocksを支える技術

プレイドの dev インターンに参加した記録をまとめました！

PLAIDのインターンでやったこと ~ KARTE接客の施策の基盤改善の試み | PLAID engineer blog

PLAIDのインターンでやったこと ~ KARTE接客の施策の基盤改善の試み

<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 + サーバーレス」"というイベントに登壇してきました