Engineer Blog

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フロントエンド/Node.js エンジニアの mizchi です。plaid では新しい分析エンジンのフロントエンド側の技術的な仕様を考えたり、それを実装したりしています。趣味として社内の他のプロダクトのパフォーマンスを勝手に測って、貼り付けていくこともあります。
plaid のエンジニア組織には「組」という制度があって、メインとなるプロダクト以外にも、そのテーマで会社横断で活動するグループがあり、最低一つ所属することが奨励されています。例えばセキュリティ組、バグトリアージ組、Tech 勉強会組などがあります。
最近になって パフォーマンス組を新設しました。これは主にフロントエンドのパフォーマンスを調査して、各プロダクトにその改善を促すグループです。
plaid のフロントエンドは PaaS としての外向けのサードパーティスクリプトと、その管理画面があるのですが、サードパーティの方はパフォーマンスも計測しているのですが、管理画面の方は歴史が長く設計変更も多々あり、富豪的な感じになってしまっています。
これを改善するためにいくつか調査を行い、実際にいくつかは修正したのですが、本質的には「組織的なパフォーマンス意識」を向上させる必要がある、という結論になりました。組織としてのパフォーマンスを意識できないと、目の前の問題を解決したとして、いずれ再発します。(これはセキュリティなどでも同様ですね)
そこで、その文化の改善のために、まず社内のプロダクトをテーマにハッカソンの開催を開催してみよう、という話になりました。
<h2>開催の経緯</h2>
とある日の slack のスレッドの自分とデザイナーの高橋さんの会話。
mizchi 「ところで Baisu (社内の CSS ガイドライン兼モック) むちゃくちゃ重くないですか」
高橋「めちゃ重いですよね」
mizchi 「なんで重いんだろう… JS でした」
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a087da95-c435-4fd2-abfd-38e3a72107b2/hev.png" alt="">
高橋「モック環境だから色んなライブラリとか試すのにいれまくってるからか！なるほど」
mizchi 「ここパフォチュのお題によさそう。lighthouse で高得点出した人が優勝」
mizchi 「壊しても悲しむのが高橋さんだけってのがパフォチュ向き」
見ていた同僚が突然テザーサイトを作成
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a3f2fe0-1e1b-444a-abd2-752765626970/aaf620d4154ddc6357cdb16485c6987a.png" alt="">
開催決定！
mizchi「業務時間使って開催しますね」
nashibao(CPO)「どんどんやっていけ」
<h2>真面目な話</h2>
社内のワークフローでは、社内のモノレポの一部の baisu というプロダクトで vue.js のモックページを作成し、それを元に各プロダクトで実装が行われています。
このワークフローの抱える問題として、 baisu の抱えるパフォーマンス上の問題は、そのままプロダクトに引き継がれてしまいます。実際いくつかパフォーマンス上の問題として表出していました。
ここでの改善は、そのまま管理画面やその他のページの改修にそのまま活かせます。プロダクトに直接コミットするより、まず同じ問題を抱えたモックページをチューニングすることで、心理的な負荷を減らしつつ大胆なアプローチを取れるはずだ、と考えました。
<h2>まず自分で解いてみた</h2>
前提として、この baisu というのは、基本的に vue.js + vue-router で構築された SPA です。html-webpack-plugin と webpack, webpack-dev-server で起動し、本番は静的サイトとして superstatic 上で動作します。
<a href="https://github.com/firebase/superstatic">firebase/superstatic: Superstatic: a static file server for fancy apps.</a>
そもそも問題として適当かどうかを測るため、自分でまず自分がチューニングしつつ問題を洗い出しました。
<ul>
<li>チャンク分割の前に面倒だったのが、babel6 =&gt; 7 のアップグレードだったので、ここで詰まっては本質的ではないので babel 7 へ更新</li>
<li>webpack も dynamic import が使いづらいバージョンだったのを最新版に更新</li>
</ul>
その上で発生している問題の洗い出し。
<ul>
<li>大量のルーティングあるにも関わらず、チャンク分割がなされずに、単一の js として出力されてる</li>
<li>moment の locale をすべて読みこんでいる</li>
<li>vue 用のビューライブラリで、 element-ui というライブラリのコンポーネントを、使うかどうかに関わらず全部読み込んでいる</li>
<li>apexcharts という重いチャートライブラリを全画面で読み込んでいる</li>
<li>fontawesome の全アイコンフォントを読み込んでいる</li>
</ul>
これによって、適当なお題だと判断。あえて放置して本番を迎えました。
<h2>開催告知</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>
弊社は 2 ヶ月に一回チームを入れ替えるのですが、その入れ替え期で比較的締め切りなどがない余裕があるタイミングで開催しました。事前に「業務時間を使って参加していいよ、ただしチームの同意はとってね」という周知をしました。
<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>
周知した方向性として、「計測対象となるページの個別の最適化は避けて、できるだけ一般的な、マージしたいと思えるような実装で解いてね(それでもスコアは十分伸びるので)」という感じに。
計測用スクリプトはこんな感じ。
<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>
要は lighthouse の Performance のスコアです。
<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>
ほぼ全員が 80mb を 10mb 付近まで削っていたのですが、最終的に優勝したのは、 html-webpack-plugin の吐くコードを書き換えた人で defer にしたことで、lighthouse のスコアが上がった、新卒一年目の <a href="https://github.com/kosukeoya">kosukeoya</a> でした。
kosukeoya 曰く、「自分はフロントエンドのパフォーマンスチューニングは初めてだったが、事前資料として共有されたサイバーエージェントのハッカソンでの最適化を上から順になぞった」ということで、あの資料やっぱ有効だったんだなぁという感じに。
<a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a>
<h2>参加者の声</h2>
<ul>
<li>webpack-bundle-analyzer がリポジトリに組み込まれていたので、普段は意識しないものを意識できた</li>
<li>やってよかった。いろいろなテクニックにふれる機会があった</li>
<li>フロントエンドの経験値が少なく、直し方はまだ難しく感じるが、問題の見つけ方がわかるようになったのが大きい</li>
<li>最適化ははじめてだったが、コスパよくできる場所があるのがわかった</li>
<li>ベストプラクティスはそんなに難しくなく、知ってれば日常的に採用できるコードが多い</li>
<li>競プロ的な感じ(小難しい解法)かと思ったら普通に一番いいコードが一番効く</li>
<li>(baisu そのものの感想) そもそもうちにこんな数のモックページがあったのか</li>
</ul>
<a href="https://www.npmjs.com/package/webpack-bundle-analyzer">webpack-bundle-analyzer - npm</a>
<h2>技術的な感想 / 得られた教訓</h2>
<ul>
<li>vue.use 使ってしまうと最適化が難しい</li>
<li>fontawesome が強敵</li>
<li>jquery 消そうとして時間がかかった</li>
<li>chunk に名前つけた方がデバッグしやすい</li>
<li>chunk いっぱい吐くとグラデーションが綺麗</li>
<li>高橋さんの PC のメモリ節約できて嬉しい！</li>
</ul>
きれいな webpack chunk の様子です
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f241e3fb-755b-42c1-9736-9870c2b0a1bc/a11849230c29ee02f649700750dfcae1.jpg" alt="baisu [11 Sep 2020 at 18:25] - Gyazo">
<h2>講評中に見つかった、プロダクトに活かせそうなものの</h2>
<ul>
<li>superstatic の compression(gzip) を有効にする(なってなかった)</li>
<li>JS によって挿入される css で呼ばれる webfont を &lt;link rel=preload ...&gt; で先読みすると、 適用時のガタツキがなくなり、layout junk が減って LCP のスコアがよくなる</li>
</ul>
この辺やらないとわからなかった気がします。
<h2>運営してみての感想 / 反省</h2>
プロダクトと同じ構成のモックの読み込み改善というお題がよかったと思います。そのまま業務にフィードバックできるので、明日からやっていけそう、みたいな声が多かったです。
そもそもルーティングのチャンク分割、 lazyload にたどり着いてくれないとその後の改善がないのが心配だったんですが、参加者全員、そこはたどり着いていました。ハッカソン中に時間経過でヒントを小出ししたのも、何もできない人が出なくてよかったかなと思います。
反省として、最終的な script の defer 属性によるスコア差については、今回のお題ではやや評価が難しいところがあります。なぜなら、baisu は js を読み込まないと画面に何も表示されない、SSR なしの SPA なので、エントリポイントの同期/非同期は、結果的なユーザー体験にあまり影響がありません。
まあ、スコアサーバーの機嫌を読むのもコンテストの一部ということだと思うので、これはこれで良いと思います。ただ html-webpack-plugin の吐くコードに手を入れる、というのは気づきづらかったですね。
人が集まりやすい事前準備をして、告知の反応も多かったんですが、やはり業務時間を使う心理的な抵抗からか人が集まりづらく、想定の半分ぐらいでした。ここは次にもっと工夫したいと思います。
社内プロダクトの改善という他社で再現性があるか微妙なテーマではあり、これも外に出せないのが申し訳ないんですが、似たようなモックと課題をもつような会社では開催できるのではないでしょうか。そもそも実プロダクトを対象にしてもいいと思います。
<h2>Hiring</h2>
plaid では webpack chunk を 1byte でも絞り込みたいという人を募集しています。
<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>

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

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

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

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

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

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

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

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

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

Datadog Summit Tokyoに登壇しました！

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

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

こんにちは、エンジニアの <a href="https://twitter.com/tikson">@tik-son</a> <a href="https://twitter.com/kargo113">@kargo</a> です。02020/06/09 - 2020/06/11 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital">Google Cloud Day: Digital</a> に 弊社2名で「Multi Cloud」「ML」というテーマでそれぞれ登壇してきました。
こちらのブログでもその内容を簡単にまとめておきます。
<h1>「Google Cloud Day: Digital 基調講演」</h1>
カスタマー エンジニア 技術部長の佐藤 聖規さんから、Container Based MultiCloud を実現する手段として、我々がAnthos GKE on AWS を利用し始めたことを
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d66e5d06-7109-4834-980c-64e922323ff5/----------2020-06-09-11.14.15-2-------1.png" alt="">
また、Developer Advocate の佐藤 一憲さんからは我々のGCP のML 活用のOverview とKARTE の紹介をして頂きました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b16b0bcb-8ddf-4431-ad58-7ca186d88b42/----------2020-06-09-11.25.17-2------2-1.png" alt="">
そしてKeyNote で取り上げていただいた2つのトピックについて、それぞれ発表してきました。
<h1>「PLAID’s Journey with multi cloud」</h1>
こちらは <a href="https://twitter.com/tikson">@tik-son</a> よりご紹介致しました。1我々が提供するKARTEは2015年にローンチされ、2016年頃からVm Based MultiCloud になり、現在はContainer Based MultiCloud に取り組んでいるのですが、そのローンチから現在に至るまでのアーキテクチャの変遷をご紹介しました。
Container Based MultiCloud を実現する手段として、<a href="https://cloud.google.com/blog/ja/topics/anthos/anthos-for-aws-is-now-ga">2020 /4/23に発表されたAnthos GKE on AWS</a> の利用を開始しており、発表の中でAnthos GKE on AWS を使ってみての話もしております。
発表については <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital/watch?talk=d1-appdev04">YouTube Live</a> でご覧いただけます。2また、<a href="https://speakerdeck.com/tikson/plaids-journey-with-multi-cloud-10128526-d75f-41de-98ec-27025f8d35a9">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。
<script async class="speakerdeck-embed" data-id="bdb90a12b7864ba4b5925e5bf7a52d1d" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「AI Platform で実現する ML Pipeline」</h1>
こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。
私たちが実現するコンセプトは、大量のリアルタイムデータからパターンを発見するMLシステムと人にしかできない思考と発想を継続的に統合するEnd-to-EndのML Platformです。
これを実現するにあたり、以下の3つの課題がありました。
<ul>
<li>パイプラインの実行環境の統一</li>
<li>学習環境のスケーラビリティ</li>
<li>継続的インテグレーション</li>
</ul>
この課題をそれぞれ
<ul>
<li>AI Platform Pipeline</li>
<li>AI Platform Training</li>
<li>Github Actions</li>
</ul>
の導入によって解決しました。 
さらに、今後の展望として
<ul>
<li>リアルタイム基盤</li>
<li>カスタマイズ性</li>
<li>強化学習基盤</li>
</ul>
を構築し、ML Platform の拡充を図ってまいります。
全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital/watch?talk=d3-ml05">YouTube Live</a> よりご覧頂けます。3同様にこちらも <a href="https://speakerdeck.com/kargo113/googleclouddaydigital-plaid-mlpipeline-on-aiplatform">SpeakerDeck</a> に資料をアップロードしているのでお急ぎの方はこちらから是非ご覧ください。
<script async class="speakerdeck-embed" data-id="e730d56572474db6832290df749de1be" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
今回はcovid-19の影響もあり、オンラインでの登壇となりました。4普段と異なる環境であり、初めは少し戸惑いましたが、ふたをあけてみると、5オフラインでの登壇の時よりも効率的に発表に対する時間を使うことが出来たり、6普段よりも多い800名以上の方にリアルタイムにご覧いただいたり、様々なポジティブな点がありました。
そして、オンライン上の顧客体験を向上させるKARTEを提供する我々としても、この現状を前向きに捉え、さらなる価値を今回登壇の機会を頂いたGoogleさんをはじめとする様々なパートナーの方々と共に提供していきたいと強く感じました。
そんな弊社ではスピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！

Google Cloud Day: Digital で「KARTEのMultiCloudアーキテクチャの変遷」と「AI Platform で実現する ML Pipeline」について話してきました

Google Cloud Day: Digital で Anthos と ML について話してきました

Webのプライバシー保護について各社が取り組んでいますが、なかでもGoogleが発表しているのがPrivacy Sandboxです。今回は全体像について読み解きます。

Privacy Sandboxはなにを語るのか - 連載 The Privacy Sandbox | PLAID engineer blog

Privacy Sandboxはなにを語るのか

こんにちは、エンジニアの@tanakoです。
PLAIDでは、CX（顧客体験）プラットフォーム<a href="https://karte.io/">KARTE</a>の機能を iOS / Androidのネイティブアプリから活用できる <a href="https://karte.io/product/app/">KARTE for App</a> のSDK（以降 SDK）をAppチームで開発しています。
さて、Appチームは去る4/7にSDKをOSS化し、ソースコードをGithub上で公開しました 🎉
<ul>
<li><a href="https://github.com/plaidev/karte-ios-sdk">iOSリポジトリ</a></li>
<li><a href="https://github.com/plaidev/karte-android-sdk">Androidリポジトリ</a></li>
</ul>
またOSS化に伴い、SDKをv2（以降 v2）にメジャーアップデートしました。今回は、SDKをOSS化して解決したかった課題や、v2メジャーアップデートの概要、チームとしての取り組みをいくつか紹介します。(この記事は社内勉強会で@wasnotが発表した内容を基に、@tanakoが加筆修正したものです。)
<h2>KARTE for App SDKについて</h2>
前提知識となるSDKについて簡単に説明します。SDKは、イベント送信APIやJavaScriptモジュールを読み込むコンポーネントを内包しており、管理画面で記述されたHTML/CSS/JavaScriptをSDKが管理するWebView（iOSではWKWebView）に読み込むことでアプリ内メッセージを表示できます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24b3914e-72e7-4c6a-a7fe-03abb2acea98/----------0030-12-22-16.27.18-1.png" alt="">
<h2>OSS化の背景</h2>
KARTE SDKは他の一般的な計測SDKと異なり、活用の仕方によっては積極的にアプリのUIに介入できます。また、OSS化以前のv1 SDK（以降v1）はほぼクローズドソースで提供されていたため、自社アプリへの影響を心配する、次のフィードバックがいくつかのクライアントからありました。
<ul>
<li>コードの品質を直接確認できないため導入に不安がある</li>
<li>SDKアップデート時の差分をコードレベルで把握できず影響が読めない</li>
</ul>
これらの不安に対して我々がSDKの品質に問題ないと言ったところで、それを明確に証明する材料はなく説得力も持ちません。
このようなクライアントに安心して利用してもらうためにも、ソースコードの公開が必要と判断しました。
<h2>OSS化によって提供できる価値</h2>
OSS化するにあたり、利用者に提供できる価値を次のように明文化しました。
安心感の向上
<ul>
<li>SDKの品質に問題がないか確認できる安心感</li>
<li>内部挙動を正確に把握できる安心感</li>
</ul>
信頼性の向上
<ul>
<li>第三者が開発に参加することによる信頼性の向上</li>
<li>多数の開発者の目に触れる（問題のあるコードは速やかに報告され修正されやすい）</li>
</ul>
透明性の向上
<ul>
<li>開発プロセスの見える化</li>
<li>コードの変更経緯が追える</li>
</ul>
これらの価値提供でクライアントの不安は払拭できる一方で、単純にOSS化するだけでは、次に挙げる価値を直接提供することはできません。
OSS化だけでは提供できない価値
<ul>
<li>機能性</li>
<li>拡張性</li>
<li>保守性</li>
</ul>
<h2>OSS化にあたり事前に決めたこと</h2>
えいやでソースコードを公開できれば楽ですが、当然OSS化後も開発は続きます。効果的、効率的にOSSを運用するにあたり次の点を決める必要がありました。それぞれどのような観点で決定したかを紹介します。
<ul>
<li>ライセンスの選定</li>
<li>開発・リリースフローの検討</li>
<li>バージョニングポリシーの変更</li>
</ul>
<h3>ライセンスの選定</h3>
OSSとしてソースコードを公開するにあたり、コードのライセンスについて検討・選定しました。MIT、Apache 2.0、BSDや独自ライセンスなどが候補に挙がりましたが、社内有識者やリーガルチームと相談・議論し、条項の読み合わせを行なった上で、 次の理由で<a href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 License</a>を採用しました。
<ul>
<li><a href="https://opensource.org/">OSI</a>の承認ライセンス</li>
<li>利用率の高さ（非コピーレフトだとMITの次点）</li>
<li>特許紛争に関する特記事項の存在</li>
</ul>
特に特許紛争に関する特記事項が記載されていることはクライアントに安心して利用して頂く上で重要なポイントです。
ライセンスの検討にあたっては、「<a href="https://www.amazon.co.jp/OSS%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%E4%B8%8A%E7%94%B0-%E7%90%86/dp/4297100355">OSSライセンスの教科書</a>」を参考にしました。「OSSマトリョーシカ問題（OSS内で利用するOSSが競合するライセンスを持っている状態）」という言葉を知り、事前にSDKが依存するOSSについて精査できたのもこの本のおかげです。
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f5ef028-d97b-4d82-ac79-be19ea1ba4cd/----------2020-04-23-20.04.44.png" /><figcaption>上田 理 (2018)．　OSSライセンスの教科書，図9.2 OSSマトリョーシカ（OSSの中にOSSが入っている）</figcaption></figure>
<h3>開発・リリースフローの検討</h3>
開発中の新機能や特定クライアントのissue等の開示は難しいため、当面はそれらの開発プロセスはPrivateにすることにしています。適切に公開範囲をコントロールするため、開発・リリースフローを次のリポジトリ・CI構成で行うことにしました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/27bdb86e-1762-44f1-8243-e5927af06ea7/----------2020-05-08-18.45.29.png" alt="">
Publicリポジトリではソースコードの公開だけでなく、issueやPRの公開・受付も行います。また、OSS化することを優先したため、当初PRの受付はバグ修正に限定しています。機能追加のPRは受け入れ体制が整い次第少しづつ受け付ける方針としています。体制が整った段階で<a href="https://github.com/plaidev/karte-ios-sdk/blob/master/CONTRIBUTING.md">CONTRIBUTING.md</a>を更新する予定です。
<h3>バージョニングポリシーの変更</h3>
v1では次の運用でバージョンアップを行っていましたが、この運用ではIFに破壊的な変更があるかどうか利用者側から影響範囲が分かりません。
<ul>
<li>微修正はpatchバージョン</li>
<li>機能追加などはminorバージョン</li>
<li>iOS/Android SDKのバージョンは揃える</li>
</ul>
OSS化するv2からは、バージョンアップがアプリケーションに与える影響を把握できるように、セマンティック バージョニング 2.0.0（以降 SemVer）に従うことにしました。これにより、バージョンアップが後方互換性を保った変更なのか、破壊的な変更なのか利用者からわかりやすくなります。
また、SemVerでメジャーバージョンの更新条件は自明となりますが、<a href="https://semver.org/lang/ja/#spec-item-7">マイナーレベルのバージョニング</a>の解釈に曖昧な点が残っていました。
<blockquote>
マイナーバージョン Y （x.Y.z | x &gt; 0）は...プライベートコード内での新しい機能の追加や改善を取り込んだ場合は、上げてもよいです（MAY）。その際にパッチレベルの変更も含めてもよいです（MAY）。
</blockquote>
これについては、<a href="https://ja.reactjs.org/docs/faq-versioning.html#minors-versus-patches">Reactのバージョニングポリシー</a>などを参考にチームで議論し次のように決定しています。
緊急性の高い不具合 
即修正してリリースしなければならない問題については、patchバージョンを上げてリリースする。この場合は master ブランチから hotfix ブランチを切ってリリースする流れとなる。
緊急性の低い不具合（考慮漏れ・仕様バグなど） 
minorバージョンを上げてリリースする。2通常のリリースフローでリリースする流れとなる。
バージョニングポリシーを明確化することで、迷いが減り迅速なリリースが期待できます。
<h2>v2 SDK（メジャーアップデート）で実施したこと</h2>
v1 SDKは、モノリシックなモジュールに多くの機能が詰め込まれており技術的負債が溜まっていました。また、利用者にとっての機能拡張性も十分に提供できているとは言えない状態でした。そのため、OSS化を良い機会と捉え、公開インターフェース及び内部実装の再設計を行い、保守性、拡張性などを高め長期的なSDKの品質維持が容易になるようにv1 SDKに対して非互換なアップデート（v2へのメジャーアップデート）を行う判断をしました。
<h3>モジュール化</h3>
v1では複数の機能が一つのモノリシックなモジュール内に詰め込まれていましたが、v2では各機能単位にモジュールを分割しました。
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2c4b3d6-3f24-464a-b598-409c1ff5f353/----------2020-04-23-15.14.22.png" /><figcaption>モノリシックなv1、機能毎にモジュール分割したv2</figcaption></figure>
モジュール化には次のメリット・デメリットがあると考えましたが、デメリットを加味しても利用者が要件に応じた必要最低限のモジュールを選択できること、SDKの機能追加や拡張がしやすい状態に保つことは非常に重要だと考えました。
モジュール化のメリット
<ul>
<li>要件に必要な機能だけをリンクして利用可能</li>
<li>可読性の向上</li>
<li>バグやデグレの影響範囲分離・回避</li>
<li>機能追加が容易（サードパーティによるモジュール追加も可能）</li>
</ul>
モジュール化のデメリット
<ul>
<li>一部モジュール間連携用のAPI公開が必要</li>
<li>クライアントがどのモジュールをimportするか判断が必要</li>
<li>全モジュール利用時のバイナリサイズは拡大する傾向</li>
<li>リリース等の作業が煩雑化</li>
</ul>
連携の方法について
モジュール分割により、モジュールが完全に独立して動くようになったわけではありません。各機能のモジュールはCoreモジュールに依存しており、Coreとその他のモジュールを連携させるための作業が必要になります。
この連携作業において、ツールによっては明示的な連携コードの実装が必要です。v2では、より簡単にSDKを導入できるようにモジュールがリンクされていれば自動的に連携するようになります。具体的にはCoreモジュールに各モジュールをlistenerとして登録し、各イベントを受け取る方式となります。尚、モジュールの自動登録には、各プラットフォームごとの機能を使用しています。
iOSでのモジュール連携内部実装
iOSではクラスがランタイムに追加された時に呼ばれるメソッド(<a href="https://developer.apple.com/documentation/objectivec/nsobject/1418815-load">load</a>)があり、各モジュールのクラスがロードされたタイミングで、Coreモジュールにクラスを登録できます。リンクされたクラスは基本的に全てロードされます。
<pre><code class="language-obj-c">@implementation KRTInAppMessagingLoader

+ (void)load
{
 [KRTInAppMessaging _krt_load];
}

@end

</code></pre>
<a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessagingLoader.m#L24-L31">Objective-CのloadからSwiftのload用関数を呼び出す</a>
<pre><code class="language-Swift">@objc(KRTInAppMessaging)
public class InAppMessaging: NSObject {
 ...
 @objc
 public class func _krt_load() {
 KarteApp.register(library: self)
 }
 ...
 }
</code></pre>
<a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessaging.swift#L48-L53">Swift側でのモジュールの登録</a>
Android (JVM)でのモジュール連携内部実装
JVMは基本的に初期状態ではリンクされたクラスはロードされず、呼び出し時に初めてロードされるため、iOSと同じアプローチは使えません（lazy load）。
JVMのClassLoaderにはリンクしたjar内の決められたファイルを参照する仕組みがあり、そちらを利用することで動的にリンクされたモジュールのロード・登録が可能です。
<pre><code class="language-kotlin">val libraries = ServiceLoader.load(Library::class.java)
libraries.forEach { library -&gt;
 register(library)
 library.configure(self)
}
</code></pre>
<a href="https://github.com/plaidev/karte-android-sdk/blob/0e74ddf40b17d253e658ea69b337a5ee1f74f937/core/src/main/java/io/karte/android/KarteApp.kt#L238-L243">ServiceLoaderを使用したモジュールの登録</a>
<h3>開発言語の変更</h3>
iOS / Android共に、メインの実装言語を各プラットフォームのよりモダンな言語に変更しました。iOSは Objective-C から Swiftへ、Androidは JavaからKotlinに変更しています。
言語変更のメリットを次のように考えています。
<ul>
<li>可読性の向上</li>
<li>言語の安全性向上</li>
<li>メンテナンス性の向上</li>
<li>言語背景が（ある程度）似ているため、今までよりもプラットフォーム間の共通点が多い</li>
</ul>
一方デメリットは次の通りです。
<ul>
<li>自由度の低下（安全性とトレードオフ）</li>
<li>バイナリサイズの膨張や呼び出しコスト増大</li>
<li>レガシーな開発環境のアプリでは、余計なものが増えてしまう</li>
</ul>
デメリットはレガシーな開発環境に限定されており、近年では完全にレガシーな環境のアプリは少ないと判断しました。
また、PLAIDではチームやプラットフォームの垣根なくコードを書くことが多いため、言語仕様が（ある程度）近いことによるメリットは大きいと感じています。
<h3>リファレンス自動生成</h3>
v1では、Developer Portal（Karteを利用する開発者向けのドキュメント置き場）のAPIリファレンスを、手動でメンテナンスしていました。
この方式は更新漏れでコードとドキュメントに乖離が生じやすい上に、バージョン毎の対応関係もわからずメンテナンスコストが高い状態でした。
v2からは、ドキュメンテーションコメントをソースコード内に記載し、リファレンスを自動生成することで、コードとドキュメントの乖離が起きにくくしました。iOSは<a href="https://github.com/realm/jazzy">realm/jazzy</a>、Androidは<a href="https://github.com/Kotlin/dokka">Kotlin/dokka</a>でドキュメントを生成しています。
また、バージョン毎にリファレンスが生成されるようになり、対応関係がより明確になりました。リファレンスは<a href="https://github.com/plaidev/karte-sdk-docs">GitHubのリポジトリ</a>にPushして、<a href="https://plaidev.github.io/karte-sdk-docs/ios/latest/KarteCore/">iOS</a> / <a href="https://plaidev.github.io/karte-sdk-docs/android/core/latest/">Android</a>ともにGithub Pagesを利用して公開しています。
v2では、ここで紹介した他にも、<a href="https://developers.karte.io/docs/support-policy-ios-sdk-v2">サポートポリシー</a>の刷新や新機能追加などを多く盛り込みました。興味があるかたは、ぜひ<a href="https://developers.karte.io/docs/release-notes-ios-sdk-v2">リリースノート</a>をご覧ください
<h2>OSS化とv2リリースを同時進行したことによる効果</h2>
v2へのメジャーアップデートとOSS化を同時にリリースしたことで、結果として「OSS化だけでは提供できない価値」である「機能性」「拡張性」「保守性」を付与できました。
これにより「SDK利用者の開発体験」全体を向上させることができインパクトのあるリリースになったのではないかと考えています。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24a49205-2570-45b6-97ae-57a40d569e89/----------2020-04-23-23.38.32.png" alt="">
<h2>おわりに</h2>
簡単にSDKをOSS化した背景、v2アップデートの概要、チームで取り組んだことを紹介しました。
まだまだ、OSS運用のノウハウは溜まっておらず、英語のみでのメンテナンスや、他開発者とのコラボレーション方法の整備に関してもスタート地点であり、その他にも多くの課題が残っています。
引き続き、透明性が高く開発者が安心して使えるSDKを提供するために改善を続けていきたいと思います。

OSSのライセンス、バージョニング、リリースフローの検討と背景、v2メジャーアップデート

KARTE for App SDKのOSS化によるDeveloper Experience向上への取り組み

BigQueryのリソース配分最適化のため、プロジェクトへのコミットメントの割り当てパターンや、スロット消費の多いクエリの見つけ方などについて調査した結果をまとめてみました