Engineer Blog

Takuma Shibuya

plaidinc

Hideyuki Okada

Daikichi Sasamori

Kazuto Kojima

Atsushi Kobayashi

Kenichi Suzuki

Wataru Ikarashi

Nobuhiro Ito

Kei Tamiya

Shinnosuke Ozawa

Hiroto Harada

kazushi oohira

Tatsuya Monoi

Naoki Shibayama

daigo.isamatsu

Ryosuke Suzuki

Jumpei Ikegami

Takuya Ogawa

Yohei Meguro

Tomoki Koga

Rei Ishikawa

Naoto Kato

koichi tanaka

Masahiro Yamauchi

Yoshiyuki Komazaki

Yuki Makino

Takaaki Nakama

kantetsu

akira.kasuga

kazupon

Shinji Eto

Yu Nishimura

Arnaud Avondet

Atsushi Fujikawa

Yuta Nishimura

mizchi

Takumi Katayama

Kohei Kadowaki

Kosuke Oya

Blocks Team

Yohei Noda

Takami Yamada

Daiki Matsui

Jun Kusahana

Naohiko Takemura

Takahiro Tokunaga

Security Team

Makoto Kataigi

Takanori Koga

AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術

インクリメンタルに新しい技術を取り入れる方法。TypeScriptへの移行を例にしたプロセス

CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方

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 を活用した事例が紹介されました