Engineer Blog

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

Developer Experience & Performance チームでエンジニアをしている大矢です。今回は JavaScript の非同期処理で使われている callback を Promise に移行する手法について、具体的な事例をもとに紹介します。

Mongoose の callback を Promise に移行する手法

KARTEの複数のシステム間で共有する定数ファイルを、これまで社内向けのnpmパッケージとして配布していたところから、代わりとなる独自の仕組みを構築して管理する方式に切り替えたことと、その移行プロセスについて。

npmパッケージの代わりに独自の仕組みを構築して定数ファイルを配布する運用に切り替えた経緯と移行プロセス

<h1>はじめに</h1>
<p>こんにちは、桂田一輝と申します。2024年8月から10月の3ヶ月間、プレイドのEcosystemチームでソフトウェアエンジニアとしてインターンシップを行いました。インターンを通じて、Ecosystemチームが開発しているKARTE Craftというプロダクトの改善業務に携わってきました。そこで得られた学びについてお伝えします。</p>
<h1>EcosystemチームとKARTE Craftについて</h1>
<p>私が配属されたEcosystemチームは、KARTEと外部サービスを繋ぐ連携機能のオーナーを務めています。Ecosystemチームがオーナーとなっているプロダクトの一つに、<strong>KARTE Craft</strong>があります。</p>
<p>KARTE Craftはアプリケーション開発機能を提供するPaaSです。KARTEの機能拡張や独自のカスタマードリブンなサイト、アプリケーションを作成することができるため、KARTEの特徴であるユーザーの状態変化に応じた適切なアプリケーションの開発が可能になります。</p>
<p><a href="https://craft.developers.karte.io/get-started/about-karte-craft/">https://craft.developers.karte.io/get-started/about-karte-craft/</a></p>
<p>今回のインターンで私が担当したのは、KARTE Craftの <strong>Craft Functions</strong> という機能の改善でした。</p>
<h2>Craft Functionsとは</h2>
<p>Craft Functionsは、KARTE内外で発生するユーザーの状態変化に関するイベントをトリガーにして、任意のバックエンドプログラムを実行する機能です。外部サービスや自社システムとの連携、シンプルな連携から複雑な作り込みまで、あらゆるカスタマードリブンな独自のアプリケーションを作成できます。</p>
<p><a href="https://craft.developers.karte.io/get-started/about-karte-craft/#craft-functions%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF">https://craft.developers.karte.io/get-started/about-karte-craft/#craft-functionsの仕組み</a></p>
<p>Craft Functionsで実行するプログラムを<strong>ファンクション</strong>と呼びます。ファンクションの作成時には、インフラの構築・運用は不要で、AIによるサポートも搭載されているため、手軽に作成することができます。</p>
<h1>インターンで行ったタスク</h1>
<p>インターン期間中は、大きく3つのタスクに取り組みました。配属後の初めのタスクとして、KARTEのサーバーインフラを理解するための設定変更を行いました。その後は、Craft Functionsの改善として、次の2つのタスクを担当しました。</p>
<ul>
<li>ファンクションが意図せず操作不能となる事象を回避するためのジョブ機能の構築</li>
<li>ファンクション一覧をタイプ別に取得するサービス間APIの作成</li>
</ul>
<p>今回は、上記の2つのタスクを紹介し、そこから得られた学びを説明します。</p>
<h2>タスク1: ファンクションが意図せず操作不能となる事象を回避するためのジョブ機能の構築</h2>
<p>最初のタスクは、作成したファンクションの状態管理に関する課題を解決するものです。ファンクションの作成処理の流れ、課題、そして解決方法を説明します。</p>
<h3>課題</h3>
<p>Craft Functionsでファンクションを作成する際のシステム概要図は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/b48943b2-5706-4e92-9a4e-97345c8f456e/image.png" alt="image.png"></p>
<p>KARTEは複数のマイクロサービスで構成されており、サービス間通信にはAPIやqueueが使われています。図のwebサービスはKARTE Craftの管理画面を提供しています。workerサービスではファンクション用のコンピューティングリソース作成、更新、削除などの時間のかかる処理を非同期で行っています。</p>
<p>ファンクションの作成順序は次のとおりです。</p>
<ol>
<li>webサービスはファンクション作成リクエストを受け取り、MongoDBにstatus: <code>IN_PROGRESS</code> でファンクションの設定情報を保存し、workerサービスにファンクション作成メッセージを送信します。</li>
<li>workerサービスはファンクションを実行するためのコンピューティングリソースを作成します。</li>
<li>workerサービスはコンピューティングリソースの作成結果に基づき、ファンクションの設定情報を更新します。
<ul>
<li>リソース作成に成功した場合は設定情報のstatusを<code>SUCCESS</code>に変更します。</li>
<li>何らかのエラーで失敗した場合は<code>FAILED</code>に変更します。</li>
</ul>
</li>
</ol>
<p>KARTE Craftのアプリケーション上で予期しない不具合が発生した場合、ファンクションのstatusが <code>IN_PROGRESS</code> のままで操作ができなくなるという課題がありました。ユーザー自身でできる解決手段がないため、問題になっていました。</p>
<h3>解決策</h3>
<p>この課題の解決策として、ファンクションの設定情報を確認し、「最終更新から1時間以上経過」かつ「status: <code>IN_PROGRESS</code> 」なファンクションを作成失敗したとみなして <code>FAILED</code> に更新する仕組みを考えました。</p>
<p>実装方法として、以下の2つの方法を検討し、それぞれの長所と短所を比較しました。</p>
<ol>
<li>KubernetesのCronJobリソースを使用する。
<ul>
<li>メリット: 構成がシンプルで直感的に理解しやすい</li>
<li>デメリット: 新しいインフラの設定を追加する必要があり構成が複雑化する</li>
</ul>
</li>
<li>フロントエンドからファンクションに対するAPIを投げる
<ul>
<li>メリット: サーバーサイドの計算負荷が少ない</li>
<li>デメリット: フロントエンドの計算負荷が増える。APIの露出が増える。</li>
</ul>
</li>
</ol>
<p>今回はフロントエンドに対する余計な計算負荷やAPIの露出を避けることを優先し、方法1を選択しました。方法1を用いた際の構成図は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/d206cc8d-2e89-4677-b5b5-a669d2a9eee4/image(1).png" alt="image(1).png"></p>
<p>cron-jobというサービスをKubernetesのCronJobとして作成し、定期的にMongoDBにクエリを実行することで、上記で説明した状態のファンクションを<code>FAILED</code>に更新します。</p>
<h3>実装</h3>
<p>実装において工夫した点を3点説明します。</p>
<ul>
<li>汎用的なジョブ実行コンテナの整備</li>
<li>ファンクション設定の更新方法</li>
<li>テストの実装</li>
</ul>
<p><strong>汎用的なジョブ実行コンテナの整備</strong></p>
<p>今回の実装時点で、KARTE Craft上でスケジュール実行しているのはこのCronJobリソースのみでした。そのため、プログラムを単純に実装して実行すれば十分でした。しかし、他のKARTEプロダクトのコードを見ると、より汎用的にジョブを起動できる構造になっていたので、それを参考に実装しました。</p>
<p>次のコードは、その実装を抜粋し、説明用に改変したものです。</p>
<pre><code class="language-jsx">const argv = minimist(process.argv.slice(2));
const { jobname } = argv;

import(`./path/to/${jobname}`)
  .then(async cronjob =&gt; {
    await cronjob.default(argv);
  })
  .catch(err =&gt; {
    logger.error(err);
    process.exit(1);
  });
</code></pre>
<p><code>jobname</code>は引数としてプログラムを実行する際に渡します。今回はCronJobリソースの <code>command</code> 属性でコンテナ起動時に渡すようにしました。これにより、スケジュールの異なる複数のプログラムを1つのコンテナイメージで呼び出すことが可能になりました。</p>
<p><strong>ファンクション設定の更新方法</strong></p>
<p>CronJobで定期的に実行する関数では、「最終更新から1時間以上が経過」かつ「statusが<code>IN_PROGRESS</code>」という条件を満たすファンクションのドキュメントを全件取得し、それらを<code>FAILED</code>に更新します。</p>
<p>当初はMongooseの<code>updateMany()</code>メソッドで一括更新しようとしましたが、このメソッドでは更新したドキュメントの内容が確認できないことがわかりました。ジョブでは更新したドキュメントをログ出力したいので、今回は条件を満たすドキュメント一式を <code>find()</code> メソッドで取得し、 <code>findOneAndUpdate()</code>メソッドで1件ずつ更新しました。</p>
<p><strong>テストの実装</strong></p>
<p>作成した処理が正常に動作することを確かめるため、テストコードも実装しました。テストでは、更新日時が異なる複数のドキュメントを作成し、当該処理の結果を想定の値と比較しました。</p>
<h2>得られた学び</h2>
<p>このタスクでは、KARTE Craft上にジョブシステムを作成しました。タスクを通じて次の学びを得られました。</p>
<ul>
<li>インフラ〜バックエンドを跨いだ機能の実装
<ul>
<li>ジョブ用のプログラムを記述し、それをKubernetesのワークロードとして動かす方法がわかりました。</li>
</ul>
</li>
<li>設計・実装レベルでの取捨選択の方法
<ul>
<li>構成や実装を検討する際に、候補を挙げてその良し悪しを検討することで、より説得力のある設計・実装になることがわかりました。</li>
</ul>
</li>
</ul>
<h2>タスク2: ファンクション一覧をタイプ別に取得するサービス間APIの作成</h2>
<p>次に取り組んだのが、KARTEのHook機能経由でファンクションを起動する設定をする際に必要となる、ファンクション一覧APIの改善タスクでした。マイクロサービス間の通信に必要なAPIを作成し、サービス間通信の実装を行いました。</p>
<h3>Hook v2</h3>
<p>Hook v2は、KARTE内で発生した特定の変更や追加などの変化をトリガーとして、そのデータをリアルタイムで外部のシステムに送信する機能です。</p>
<p><a href="https://developers.karte.io/reference/about-hook-v2">https://developers.karte.io/reference/about-Hook-v2</a></p>
<p>Hook v2を使うことで、KARTE内で起きた出来事をトリガーとして、外部システムで処理を行うことができます。例えば、ユーザーからメッセージが送信された際にそれをトリガーとして特定のファンクションを実行させることができ、顧客のリアルタイムな行動に合わせたアクションを提供することができます。参考として、以下の記事では汎用のWebhookリクエストを行う方法を説明しています。</p>
<p><a href="https://solution.karte.io/blog/2023/06/craft-webhook/index.html">https://solution.karte.io/blog/2023/06/craft-webhook/index.html</a></p>
<h3>課題</h3>
<p>次の図はHook v2の設定画面です。この画面では、トリガーとなるイベントと、そのトリガーで起動するファンクションを指定します。</p>
<p><img src="https://ik.imagekit.io/plaid/80d8a018-8062-4657-8928-5f4da923980c/%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%882024-10-2316.14.09.png" alt="スクリーンショット2024-10-2316.14.09.png"></p>
<p>Craft Functionsのファンクションには、2種類のタイプがあります。HTTPタイプとイベント駆動タイプです。</p>
<div class="iframely-embed" data-embedded-url="https://craft.developers.karte.io/craft-functions/craft-functions-types/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://craft.developers.karte.io/craft-functions/craft-functions-types/" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcraft.developers.karte.io%2Fcraft-functions%2Fcraft-functions-types%2F&key=878c5bef402f0b2911bf6d4ce6261abd">ファンクションのタイプ</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>Hook v2において指定できるファンクションはイベント駆動タイプのみです。しかし、管理画面上はHTTPタイプ、イベント駆動タイプの両方が指定できるようになっていました。この相違を解決するため、管理画面上において指定できるファンクションからHTTPタイプを除き、イベント駆動タイプのみを表示する必要がありました。</p>
<h3>解決策と実装</h3>
<p>Hook v2機能はKARTE Craftとは異なるサービスで動作するため、マイクロサービス間でAPI通信を行いファンクション一覧を取得しています。今回はAPIの改善を行いました。具体的には、ファンクション一覧取得のリクエスト時に、タイプを指定できるAPIを追加し、それを利用するように変更しました。</p>
<p>Hook v2の管理画面においてファンクションの取得を行う際の構成図は次のとおりです。赤字で示すように、タイプを指定できるAPIへの切り替えを行いました。</p>
<p><img src="https://ik.imagekit.io/plaid/4745c925-fff4-4836-bda8-0a42cb293e9b/image(2).png" alt="image(2).png"></p>
<p>具体的な実装として、次の作業を行いました。</p>
<ul>
<li>Craft側にサービス間通信用のAPIを追加し、バックエンドを実装しました。</li>
<li>クライアントをOpenAPI Specから自動生成する仕組みを使って、サービス間通信用のクライアントを生成しました。</li>
<li>Hook v2のバックエンド処理で、新たに作成したサービス間通信用APIを利用するように変更しました。</li>
</ul>
<h2>得られた学び</h2>
<p>このタスクでは、マイクロサービス間の通信を行う仕組みを理解し、その改善を実施しました。タスクを通じて、次の学びが得られました。</p>
<ul>
<li>本番稼働するシステム上で、どのようにマイクロサービスが稼働しているかの全体像が掴めました。</li>
<li>インターフェース仕様（OpenAPI Spec）を活用してクライアントを自動生成することで、良い開発体験を提供できることがわかりました。</li>
</ul>
<h1>あとがき</h1>
<p>3ヶ月に渡って参加したインターンシップの感想を端的に言えば、非常に充実した経験でした。</p>
<p>今回のインターンシップを通して、次のような学びが得られました。</p>
<ul>
<li>実際に社員が担当するレベルのタスクを担当することで、本番稼働するプロダクトを開発する際に必要なレベル感を実感しました。</li>
<li>タスクを通じて、PaaSのインフラからバックエンドまで、一気通貫の開発を経験できました。</li>
<li>システム特性の面でも、Webシステムだけではなく、ジョブシステムを新たに作成する経験を通じて、開発の幅を広げることができました。</li>
</ul>
<p>これまでの私の開発経験は個人的なプロジェクトに限られており、実際のプロダクトに対する開発は初めてでした。今回のインターンシップで、実際に世の中に出ているシステムの開発に携わることで、多くの刺激を受けることができました。KARTEというアプリケーションの裏側の設計や動作原理を知った時の感動、そこで発生している課題に対して解決策を考え、技術選定をし、実装する楽しさ、そして自分が開発したものが実際にデプロイされる喜びを強く感じました。これらの経験を通じて、エンジニアリングそのものへの好奇心が大いに高まりました。また、この過程でコードを読み解き構造を把握する能力や、未知の技術を調査して組み込む力を養うことができたと考えています。</p>
<p>さらに、インターンシップの環境は非常に学びやすいものでした。メンターの方はいつ質問しても丁寧に答えてくださり、質問しやすい雰囲気が整っていました。加えて、インターンシップ期間中は他のチームの方々も交えたランチに頻繁に誘っていただき、様々なチームや職種の方々の話を聞くことで、多様な視点を知ることができました。</p>
<p>お世話になった社員の皆様に心から感謝申し上げます。本当にありがとうございました。</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&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>

こんにちは、桂田一輝と申します。2024年8月から10月の3ヶ月間、プレイドのEcosystemチームでソフトウェアエンジニアとしてインターンシップを行いました。インターンを通じて、Ecosystemチームが開発しているKARTE Craftというプロダクトの改善業務に携わってきました。そこで得られた学びについてお伝えします。

プレイドインターン体験記：プロダクトの改善活動から得た学び_プレイドエンジニアブログ

プレイドインターン体験記：プロダクトの改善活動から得た学び

<h1>自己紹介</h1>
<p>初めまして、プレイドでエンジニアインターンをしている小林雅史と申します。プレイド内ではあだ名である<a href="https://x.com/mercy34mercy">mercy</a>(マーシー)で呼ばれています。</p>
<p>立命館大学の修士1年生で、大学は情報理工学部、大学院は情報理工学研究科とコンピュータやプログラミングについて学び、研究しています。プログラミングは大学入学と同時に授業で取り組んできました。プログラミングに関しては授業だけでなく、ハッカソンなどでさまざまなアプリケーションを作成しました。特に<a href="https://cup.hackz.team/">ハックツハッカソン</a>が大好きで2度優勝しています。また<a href="https://ritsumeikanunivpress.com/07/11/4430/">大学生向けのバス時刻表アプリ</a>を先輩から引き継ぎ運用していたりもしています。3年生の時には学生IT団体<a href="http://www.watnow.jp/">watnow</a>の代表として<a href="http://www.watnow.jp/2022/10/20/%E9%96%A2%E8%A5%BF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%AB%E3%83%B3%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B92022%E3%82%92%E9%96%8B%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/">企業様とのイベント</a>や<a href="http://www.watnow.jp/2022/08/24/watnow%e3%83%8f%e3%83%83%e3%82%ab%e3%82%bd%e3%83%b3-beginners-cup%e3%82%92%e9%96%8b%e5%82%ac%e3%81%97%e3%81%be%e3%81%97%e3%81%9f%ef%bc%81/">団体内ハッカソン</a>を立ち上げたりとコミュニティの運営も行いました。</p>
<p>プレイドでは2023年の4月からインターンとして勤務していて、最初は<a href="https://tech.plaid.co.jp/platform-engineering-kaigi-2024-report">認証基盤の開発</a>を行いました。その後Redisの監視を簡単にDatadogで行うための社内向けツールを開発し、2023年10月ごろから<a href="https://karte.io/package/message/">KARTE Message</a>というプロダクトの開発を行うチームに加わり、開発を行っています。</p>
<h1>KARTE Messageについて</h1>
<p>KARTE Messageは、データを元にメールやプッシュ通知、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<div class="iframely-embed" data-embedded-url="https://karte.io/package/message/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://karte.io/package/message/" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fkarte.io%2Fpackage%2Fmessage%2F&key=878c5bef402f0b2911bf6d4ce6261abd">KARTE Message（マーケティングオートメーション/MA）｜顧客体験を磨きこみ、自動化のその先へ【KARTE（カルテ）】</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script> 
<h1>課題</h1>
<p>KARTE Messageの機能であるスマホアプリ向けのプッシュ通知配信では月間1億通を超える規模の配信を行っています。</p>
<p>今回、プッシュ通知に利用しているFCMの<a href="https://firebase.google.com/docs/reference/admin/node/firebase-admin.messaging.messaging.md?hl=ja#messagingsendall">sendAll API</a>が2024年の6月20日に廃止されることが決定し、この期日までに今後も引き続き使用できるAPIに乗り換える必要がありました。</p>
<p>また、これまで使用していたsendAll APIでは、最大500件の通知をバッチ的に送信することができましたが、これと完全に互換性のあるAPIは現在用意されておらず、1通1通を個別に送信する必要があります。</p>
<p>今回私はこのリプレース作業を担当することになりました。</p>
<h1>テスト送信の実装・切り替え</h1>
<p>最初に、移行時のリスクが小さいテスト送信から置き換えることとなりました。本番送信もテスト送信も1通1通を個別に送信するロジックは同じであり、違いは送信数です。そのため、テスト送信の実装を先に行いリリースすることで、バグがあった際の影響範囲をテスト送信のみに抑えつつ新しい実装の信頼性を検証することができます。テスト送信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>既存のコードとドキュメントを読み理解する</li>
<li>テスト送信の実装</li>
<li>テスト送信の実装の置き換え</li>
</ol>
<h3>1. 既存のコードとドキュメントを読み理解する</h3>
<p>既に動いているシステムをリプレースするため、まずは既存のコードを理解する必要がありました。コードを読むだけではなかなかコードの振る舞いを把握するのが難しいので、単体テストを新たに追加しました。</p>
<h3>2. テスト送信の実装</h3>
<p>リプレースする際のリスクを最小にするために、新規実装では既存の実装と同じケースの単体テストを書き、既存実装、新規実装ともにテストケースと結果が同じになることを確認することで、実装ミスがないかを検証しました。また、新規実装では、Goの実装が約1200行なのに対してテストコードは約5600行あります。テストはローカル環境で実行することができ、キャッシュがない状態でも30秒ほどで終了します。また、これらのテストはGithubActionsで自動で実行されており、生産性向上につながっています。</p>
<h3>3. テスト送信の実装の置き換え</h3>
<p>無事に実装が終わりテストも通ったら本番環境のテスト送信をリプレースしました。これまでの業務でバグの修正や新機能の実装をした事はあったものの、今正常に動いているものを全く新しいコードで作成されたシステムに置き換える経験は初めてでとても緊張しました。リリースの実行は社員さんに行ってもらい、検証環境で最終動作確認を行いました。テスト送信のリプレース後には、ユーザ企業様からバグ報告が数件ありました。その中でもGoへのリクエストのJSONのフィールドにnullがあった場合、Goのjson packageではnilに変換されるという仕様があり、nilのハンドリングがうまくできていないコードでバグが発生したのが印象的です。いくつかのバグを修正し、無事テスト送信の実装をsendAll APIからsend APIに切り替えることができました。</p>
<h1>本番配信の実装・負荷試験・切り替え</h1>
<p>テスト送信の置き換えが終了しバグの修正も終わると、本番配信も新しいAPIに置き換えます。本番配信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>本番送信の実装</li>
<li>負荷試験</li>
<li>カナリアリリース</li>
</ol>
<h3>1. 本番送信の実装</h3>
<p>本番送信の実装に関しては本番送信とテスト送信のロジックを共通化したため、基本的にテスト送信の実装を流用する形で実装しました。</p>
<h3>2.  負荷試験</h3>
<p>本番配信では、KARTE Messageを使用されている企業様が大量のアプリユーザに向けてプッシュ通知を送信します。また、お客様が設定した速度で正しく配信する必要があります。そのため、アプリケーションに負荷がかかっても正常に動作することを検証する必要がありました。KARTE MessageはインフラにGCPのGKEを使用しているため、正しい速度で負荷がかかっても送信できる適切なk8sのスケーリング設定を見つける必要がありました。</p>
<p>負荷試験の環境には本番環境とは完全に切り離された検証環境を使用しました。検証環境は本番環境と同じシステムが動作しており、スケーリングの設定などが違うだけで本番環境と同じようにシステムが動作します。</p>
<p>負荷試験に関しては、社員さんからは時間かかってもいいからとりあえずやってみよう！といった感じで言われたので、ほぼ初めてGKEとその設定が書かれたk8s用のyamlファイルと戦うこととなりました。本番配信は、データベース、配信サーバ(今回作成したもの)、配信準備サーバなどさまざまなシステムが連携して動くことで実行されます。サーバやデータベースの状況はリアルタイムでdatadogで確認しました。</p>
<p>負荷試験の目標値は16667rps(時速6000万)となりました。これはAPI置き換え前のシステムで過去に負荷試験をした際の最大値となっています。</p>
<p>最初はスケーリングの設定を何も変えずに、2.7prs、277rps、1667rps、5555rpsと上げて行きました。すると、時速5555rpsの試験では設定した速度で配信されず1100rpsほどでしか配信できませんでした。ここから数時間悩んで色々設定を見ているうちに、配信サーバのスケーリング設定が問題になっていることに気づきました。最大node数とpod数が非常に小さい数に設定されていて、一定以上の負荷に耐えられないようになっていました。そこで、podの最大数を500、nodeの最大数を250に設定し再度負荷試験を行ったところ、16667rpsを達成できました。この時、配信サーバのpod数は100台ほどにスケーリングしていました。</p>
<p>目標値をクリアしたので、次に最適な設定を探します。KARTE Messageではサービスの性質上、リクエストのスパイクが発生しやすいです。また、深夜帯などは配信がなくサーバに負荷がかからない状態になります。そのため、スパイクに耐えられる最小pod数と、最大負荷に耐えられる最大pod数を見つける必要があります。そこで、1podあたりどれくらいの配信数を捌けるのかを調査しました。調査するために、pod数を20台固定にし少しづつ少ない配信数から負荷試験を行い、限界の配信速度を見つけ出しました。20台のpodで2700万/hの配信を行うことができました。pod1台で約135万/hの配信が可能です。そこで、6000万/hの配信に耐えられるpod数より少し余裕を持たせた50を、最大pod数としました。</p>
<p>負荷試験だけで10営業日ほどかかりました、負荷試験の勘所やk8sの特性を理解するのに時間を要しました。初めてやることは、手探りで頑張ってみることも大事ですが、社員さんなど経験がある人にある程度、勘所を先に教わっておくともっと効率良くできたかなと感じました。学生が簡単に経験することができない、k8sを用いたシステムの負荷試験ができたことは非常に良い経験となりました。</p>
<h3>3. カナリアリリース</h3>
<p>負荷試験も終わり、ついに本番配信を新しいAPIに置き換えます。全ユーザに一斉に適用してしまうと、もしもバグなどがあった場合に影響範囲が広くなってしまうため、一部のお客様から順次新しいAPIを適用しました。APIの切り替えは環境変数で指定した特定のお客様の時のみ新しいAPIが実行されるように実装を行いました。環境変数で切り替えを行うことで、もし新しいAPIの実装に問題があった際に、修正やロールバックしたアプリケーションをデプロイすることなく、環境変数を切り替えるだけで既存のAPIの実装に戻せるため、環境変数を活用したカナリアリリースを行いました。カナリアリリースは、置き換え前と比べて、悪化している指標がないか確認しながら約1ヶ月かけて全てのお客様の配信APIを新しいAPIに切り替えました。</p>
<h1>リプレース結果</h1>
<p>リプレースは実装を始めてから約5ヶ月で終了しました。結果として、新しいAPIに切り替えたことによる大きな障害はありませんでした。そして、既存実装よりもエラー率も下がりました。</p>
<h1>最後に</h1>
<p>今回のプッシュ通知配信で使用するAPIのリプレースの実装、試験、移行は全て自分の手で行いました。もちろん社員さんの助けなしではできなかったです。今回のプロジェクトを通して長期インターンでしか体験できない貴重な経験ができました。また、自分は京都に住んでいるのでリモート勤務だったですが、地方に住んでいる学生についてはリモートでも受け入れてくれる環境は非常にありがたかったです。他のインターン生が行ったことについては、ぜひプレイドのエンジニアブログをご覧ください[1][2][3][4][5]。このような経験をしてみたい方、プレイドに興味を持った方は下記からプレイドのエンジニアインターンに応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>[1] <a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a></p>
<p>[2] <a href="https://tech.plaid.co.jp/intern-at-plaid-calloc">プレイドインターン体験記: はじめての開発インターンを通じて得た学び</a></p>
<p>[3] <a href="https://tech.plaid.co.jp/intern-at-plaid-kenshin">プレイドでの開発インターン: 3ヶ月のフルタイムエンジニアとしての挑戦を経て</a></p>
<p>[4] <a href="https://tech.plaid.co.jp/intern-at-plaid-shohei-shiraki">プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び</a></p>
<p>[5] <a href="https://tech.plaid.co.jp/mongo-atlas-to-bigquery">MongoDB AtlasからBigQueryへのリアルタイムレプリケーション</a></p>


KARTE Messageで使用しているFCMのsendAll APIが廃止となるため、APIの置き換えを行った後負荷試験を行なった。

FCMのSendAll API廃止対応

KARTE MessageにおけるFCMのSendAll API廃止対応について

カラムナフォーマットの利点を最大限活かすために書き込み処理、特にリアルタイムの書き込み処理における技術的な課題とOSS DBの具体的なアプローチを紹介しています

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 - PLAID engineer blog

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 

<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に登壇してきました

 CloudNative Days Tokyo 2020のKeynoteに登壇してきました | PLAID engineer blog

悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由 | PLAID engineer blog

悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由

<p>こんにちは。エンジニアの@ikemonnです。02019/11/13に<a href="https://www.wantedly.com/companies/datadog/post_articles/196576">Datadog Summit Tokyo</a>で「マルチクラウドな大規模サービスKARTEを支えるDatadog」というテーマで登壇してきました。</p>
<p>(イベント終了後にブログを書いた気でいましたが、書いていなかったのでその振り返りです。)</p>
<p>KARTEは下記のような特徴のサービスです。</p>
<ul>
<li>マルチテナント</li>
<li>低レイテンシ―/高負荷</li>
<li>大規模システム</li>
<li>マルチクラウド構成</li>
</ul>
<p>こういった特徴のKARTEをどのように運用コストを抑えて監視しているかについて話しました。1Datadogを例として話していますが、他の監視ツールを使っていても活かせる内容だと考えていますので、ぜひご覧ください！</p>
<script async class="speakerdeck-embed" data-id="47b0e8337a5b469ca6d08394d8c06bc1" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>概要</h2>
<p>KARTEは下記の特性を持った低レイテンシ―/高負荷なサービスです。</p>
<ul>
<li>秒間トラッキングイベント数 105,000 event(2020年3月時点)</li>
<li>ユーザの解析から最適なアクションを返すまで0.x秒以内</li>
</ul>
<p>インフラはGCP/AWSで構成されており、SREチーム2-3名で運用しています。2(マルチクラウド化への変遷については<a href="/google-cloud-day-digital-2020/">こちら</a> )</p>
<p>上記のサービスの特徴とインフラの特徴を踏まえて、KARTEでは監視ツールとして<a href="https://www.datadoghq.com/ja/">Datadog</a>を愛用しています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fd5819b5-5273-4850-b9e0-1f8e33e9b1f1/-2020-07-28-12.34.02.png" alt=""></p>
<p>そして、下記のポイントを抑えて監視をすることで少人数での運用を実現しています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8ab451db-f95a-484c-9d3a-7494ed750a50/-2020-07-28-12.34.20.png" alt=""></p>
<p>Datadogにすべて集約</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ddf68fd8-672b-4f81-b320-1ecc3d67f766/-2020-07-28-12.58.07.png" alt=""></p>
<p>3Custom Metricsの積極活用</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bb00499a-a8df-45e0-805e-70c246738ba6/-2020-07-28-12.58.18.png" alt=""></p>
<p>4Layerを分けたDashboard</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c36eeb7b-2233-466c-807b-d0a2425348f3/-2020-07-28-12.58.30.png" alt=""></p>
<p>このようにKARTE、マルチクラウドインフラ、Datadogの相性を考えながら最適な運用方法を日々模索しています。</p>
<p>より具体的な内容について知りたい方はぜひスライドや動画をご覧ください！</p>
<script async class="speakerdeck-embed" data-id="47b0e8337a5b469ca6d08394d8c06bc1" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<iframe width="612" height="344" src="https://www.youtube.com/embed/_Z4HBiwODbc?feature=oembed" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<h3></h3>
<h2>最後に</h2>
<p>マルチクラウド構成、高負荷低レイテンシーなKARTEのインフラを一緒に支えていく仲間は常に募集しています！興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


こんにちは。エンジニアの@ikemonnです。2019/11/13にDatadog Summit Tokyoで「マルチクラウドな大規模サービスKARTEを支えるDatadog」というテーマで登壇してきました。

Datadog Summit Tokyoに登壇しました！| PLAID engineer blog

Datadog Summit Tokyoに登壇しました！

継続的なセキュリティ対策をするために脅威分析をしました

<p>プレイドのエンジニア兼ハンター <a href="https://github.com/algas">@algas</a> です。<br>
この記事では Privacy Sandbox の中でも Web 広告に関連する Edge Computing の技術を紹介します。<br>
Ad Selection (広告の選択) の技術である <a href="https://github.com/michaelkleber/turtledove">TURTLEDOVE</a> と <a href="https://github.com/jkarlin/floc">FLoC</a> が <a href="https://www.chromium.org/Home/chromium-privacy/privacy-sandbox">Privacy Sandbox</a> で提案されています。<br>
この2つは個人を特定するデータをブラウザから送信せずに興味の似ているユーザの大規模なグループに広告を配信する技術です。<br>
TURTLEDOVE はブラウザで広告オークションを行う仕組みで、FLoC はブラウザで広告の興味モデルを学習させるグルーピングの仕組みです。<br>
どちらの技術もブラウザから個人を特定するデータを送らないという目的があります。</p>
<h2>ブラウザから個人を特定するデータを送信したくない3つの理由</h2>
<p>なぜブラウザから個人を特定するデータを送信しない仕組みが必要なのでしょうか？<br>
これには大きく3つの理由があります。</p>
<ol>
<li>
<p>プライバシーの保護<br>
ここ数年で GDPR のように企業が必要以上に個人を特定するデータを集めないようにする世界的な流れがより強まっています。データの取り扱いを正しく行えない企業には厳しい罰則や社会的な批判が強まることは避けれません。不要なデータを企業が持たなければ問題も起こりません。</p>
</li>
<li>
<p>ユーザが自分のデータ利用を制御できない<br>
これまではユーザを同定するためなどにブラウザの Cookie を使っていましたが、最近では情報漏えいを防ぐために Cookie を使わない方針になってきています。Cookie の代替として fingerprinting などの技術が一部の Web サイトで使われています。しかし、これらの技術にはユーザが制御できないという問題があります。個人を特定するデータがブラウザの外に出なければ制御できない対象もなくなります。</p>
</li>
<li>
<p>個人端末やブラウザの性能向上<br>
多くの Web ユーザはスマートフォンのブラウザからサイトにアクセスします。スマートフォンやブラウザの性能は日々向上しているのでサーバで処理しなくてもブラウザ側でできることが増えてきました。ブラウザでデータを処理することができればサーバやネットワークの負荷を減らすことができます。</p>
</li>
</ol>
<h2>技術要素</h2>
<h3>TURTLEDOVE</h3>
<p><a href="https://github.com/michaelkleber/turtledove">https://github.com/michaelkleber/turtledove</a><br>
TURTLEDOVE は Privacy Sandbox が提案するブラウザでの広告オークションの仕組みです。</p>
<p>Web広告の表示に重要な以下の2つのデータがあります。</p>
<ol>
<li>
<p>興味データ<br>
ウェブサイトの訪問者が何に興味を持っているかのデータです。<br>
このデータに基づいてどんな種類の広告を出すか決定されます。</p>
</li>
<li>
<p>アドオークションの勝者<br>
アドオークションというWeb広告のオークションでどの広告を表示するかが決められます。<br>
アドオークションの勝者が広告を出すことができます。<br>
アドオークションの詳細は <a href="https://support.google.com/adsense/answer/160525?hl=ja">広告オークションについて</a> を参照してください。</p>
</li>
</ol>
<p>これまではサイト運営や広告サーバがこの2つのデータを保持していました。</p>
<p>TURTLEDOVE の提案はこれらのデータをサーバではなくブラウザで処理してしまうように変更することです。<br>
ブラウザでデータを処理することによって訪問者のプライバシーを保護することにつながります。<br>
広告主は訪問者の興味に基づいて広告を出すが、他の情報との結びつけができなくなります。<br>
同様にウェブサイトや広告ネットワークは訪問者の興味について学習できません。</p>
<p>TURTLEDOVE は &quot;Two Uncorrelated Requests, Then Locally-Executed Decision On Victory&quot; の略語です。<br>
Two Uncorrelated Requests は「コンテンツ連動広告」と「広告主が特定した興味」の2つのデータを意味しています。<br>
前者は広告を表示するページのURLが含まれているデータ、後者は興味のデータのみで行動履歴と紐付けできないようになっています。<br>
Then Locally-Executed Decision On Victory は勝利した広告をアドネットワークがブラウザに表示することを意味しています。<br>
ただしこの判定はブラウザ内でローカルに実行されてブラウザの外に情報を送ることができません。</p>
<p>サーバからブラウザに広告データの扱いを移行することでプライバシーの保護以外にもメリットがあります。<br>
広告主が &quot;interest group&quot; をどう作って使っているかの透明性を確保できることやグループへの所属時間を制限できることです。<br>
ここで interest group は「広告主やアドネットワークがある種の広告に興味を持っていると信じている」人々の集合のことをいいます。</p>
<p>TURTLEDOVE の目的は主に以下の3つです。</p>
<ol>
<li>
<p>広告効果を改善したい<br>
サイト訪問者が興味を持つ広告を見続けられるようにします。<br>
嫌いな種類の広告を見なくていいようにします。</p>
</li>
<li>
<p>グルーピングの透明性を確保したい<br>
訪問者の興味を広告配信者がなぜ知っているのかに答えられるようにします。<br>
広告のターゲティングを止められるようにします。</p>
</li>
<li>
<p>プライバシーを保障したい<br>
広告主が訪問者の興味について学習できないようにします。<br>
ウェブサイトが interest group について学習できないようにします。</p>
</li>
</ol>
<p>広告が表示される流れは以下のとおりです。</p>
<ol>
<li>ブラウザが interest group に加入する<br>
ブラウザが特定の interest group に一定期間参加するAPIリクエストを広告主が実行します。オリジンはサイト所有者と同じウィンドウかiframeから呼び出されます。</li>
<li>2つの無相関リクエスト<br>
contextual リクエスト<br>
interest group リクエスト</li>
<li>オンデバイスオークション<br>
レスポンスには広告、メタデータ(広告の複数回利用の制限)、ローカル入札のためのオブジェクト、入札関数が含まれます。</li>
<li>オークションに勝った広告を表示する</li>
</ol>
<h3>FLoC</h3>
<p><a href="https://github.com/jkarlin/floc">https://github.com/jkarlin/floc</a><br>
Federated Learning of Cohorts (FLoC) は Privacy Sandbox が提案するブラウザによる興味ベース観測の仕組みです。<br>
企業が個人の閲覧履歴を観測するのに代わって、興味が似ている人々のグループ(cohort or flock)の動きを観測します。</p>
<p>典型的なWeb広告は3つのカテゴリを元に何を出すか決めています。</p>
<ol>
<li>
<p>ファーストパーティーとコンテンツ情報<br>
どのページに広告を出すか<br>
例：「バイクのWebページにこの広告を出そう」</p>
</li>
<li>
<p>広告を見ようとしている人の興味についての一般的な情報<br>
どういう人に広告を出すか<br>
例：「クラシック音楽好きのためのこの広告を見せよう」</p>
</li>
<li>
<p>閲覧者が取った直前の特定アクション<br>
何をした人に広告を出すか<br>
例：「カートに入れた靴のクーポンを出そう」</p>
</li>
</ol>
<p>人々の興味関心はWebの閲覧履歴を観測することで推測できます。もしサーバではなくブラウザで似たような興味関心を持つ人をグループ化できれば、特定の個人の閲覧履歴を集めることなく興味ベースの広告を出すことができるようになります。<br>
この仕組みを実現するのが FLoC です。<br>
FLoC は興味が似ている人々を集めて機械学習でラベルを生成します。このラベルを元にグループ化することで個人的すぎる情報を開示せずに大きなクラスタを形成することができます。<br>
広告配信側にはラベルしか伝わらないのでプライバシーを保護できます。</p>
<p>FLoC のキー(ラベル)をflockと呼びます。flock は短い文字列で表現され数千人で共有されます。個人の閲覧履歴はブラウザで切り離されます。ブラウザはユーザの行動によって flock を更新することがあります。</p>
<p>ブラウザはサイトの訪問履歴に基づくflockを開発するために機械学習アルゴリズムを使います。</p>
<ul>
<li>訪れたサイトのURL、ページのコンテンツなど</li>
<li>Web履歴を含む入力データがブラウザ内にだけ存在して外部にアップロードされないこと</li>
<li>ブラウザは差分プライバシーのような他の匿名化手法も利用することでさらにプライバシーを保護できます</li>
<li>flock の数が十分に小さいことで詳細な情報を運べなくします</li>
</ul>
<h2>関連技術</h2>
<p>TURTLEDOVE と FLoC 以外の技術を簡単に紹介します。</p>
<h3>Federated Learning</h3>
<p>Federated Learning とはエッジコンピューティングで機械学習を行う手法のことです。<br>
一般的な機械学習では大規模な中央サーバにデータを集約してモデルの学習をしますが、Federated Learning ではスマートフォンのような末端の端末でモデルの学習をします。</p>
<p>個人の行動履歴が直接クラウドに送信されず、各端末で学習されたモデルデータのみがクラウドに送信されて共有モデルの改善に使われます。<br>
たとえば Android 向けソフトウェアキーボード GBoard で Federated Learning が使われています。<br>
<a href="https://ai.googleblog.com/2017/04/federated-learning-collaborative.html">https://ai.googleblog.com/2017/04/federated-learning-collaborative.html</a></p>
<h3>差分プライバシー</h3>
<p>差分プライバシー (Differential Privacy) は公開された統計量に対してプライバシーの保護が十分であるかどうかを定義する指標のことです。<br>
差分プライバシーは利用者が持っている背景知識やアルゴリズムに関わらずに統計量のプライバシー安全性を保証します。</p>
<p>なぜ公開された統計量のプライバシー保護には差分プライバシーが必要なのでしょうか。<br>
公開された統計量の閲覧者においては攻撃者と一般データ利用者を区別できないので鍵の共有を使って完全秘匿性を実現することはできません。<br>
攻撃者にも見える形で完全秘匿性を達成すると公開した統計量が無意味(完全なランダムと同じ)になります。<br>
したがって弱い秘匿性の実現が必要となります。<br>
その弱い秘匿性の実現方法の1つが差分プライバシーです。</p>
<p>差分プライバシーには「ε-差分プライバシー」と「(ε, δ)-差分プライバシー」の2つの定義があります。<br>
詳しくは <a href="https://www.jstage.jst.go.jp/article/isciesci/63/2/63_58/_pdf/-char/ja">差分プライバシーとは何か</a> などを参照してください。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://www.chromium.org/Home/chromium-privacy/privacy-sandbox">https://www.chromium.org/Home/chromium-privacy/privacy-sandbox</a></li>
<li><a href="https://web.dev/digging-into-the-privacy-sandbox/">https://web.dev/digging-into-the-privacy-sandbox/</a></li>
<li><a href="https://github.com/michaelkleber/turtledove">https://github.com/michaelkleber/turtledove</a></li>
<li><a href="https://github.com/jkarlin/floc">https://github.com/jkarlin/floc</a></li>
<li><a href="https://security.googleblog.com/2019/06/helping-organizations-do-more-without-collecting-more-data.html">https://security.googleblog.com/2019/06/helping-organizations-do-more-without-collecting-more-data.html</a></li>
<li><a href="https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html">https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html</a></li>
<li><a href="https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html">https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html</a></li>
<li><a href="https://blog.chromium.org/2019/11/making-new-experiences-possible-on-web.html">https://blog.chromium.org/2019/11/making-new-experiences-possible-on-web.html</a></li>
<li><a href="https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html">https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html</a></li>
<li><a href="https://www.blog.google/products/chrome/building-a-more-private-web/">https://www.blog.google/products/chrome/building-a-more-private-web/</a></li>
<li><a href="https://ai.googleblog.com/2017/04/federated-learning-collaborative.html">https://ai.googleblog.com/2017/04/federated-learning-collaborative.html</a></li>
<li><a href="https://federated.withgoogle.com/">https://federated.withgoogle.com/</a></li>
<li><a href="https://www.jstage.jst.go.jp/article/isciesci/63/2/63_58/_pdf/-char/ja">https://www.jstage.jst.go.jp/article/isciesci/63/2/63_58/_pdf/-char/ja</a></li>
<li><a href="https://www.kspub.co.jp/book/detail/1529199.html">https://www.kspub.co.jp/book/detail/1529199.html</a></li>
</ul>
<h2>まとめ</h2>
<p>この記事では PrivacySandbox の中からWeb広告に関する Edge Computing の技術である TURTLEDOVE と FLoC について解説しました。54また関連技術として Federated Learning と差分プライバシーを簡単に紹介しました。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、Webの未来を作りたいエンジニア（インターンも！）を募集しています。<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>


Privacy Sandbox, Ad Selection, Web Browser, Edge Computing, FLoC, TURTLEDOVE,  Federated Learning, Differential Privacy

PrivacySandboxにおけるWeb広告のEdgeComputing技術 | PLAID engineer blog

Privacy Sandbox における Web 広告の Edge Computing 技術