Engineer Blog

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

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

<p>プレイドが提供する<a href="https://karte.io/">KARTE</a>では、オンライン上のエンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。<br>
その中で非常によくある集計がユニークユーザのカウントです。SQLで言うところのCOUNT(DISTINCT user_id)です。KARTEはMAU約8億の膨大な量のユーザを扱っていて、ユニークユーザ数を効率的に集計することは重要なテーマです。<br>
最適化のためにこのアルゴリズムについて深掘りする機会があったので、調べたことを説明していきます。</p>
<h1>HashTable</h1>
<p>最も一般的なのは、HashTable にキーを追加してカウントしていく方法でしょう。<br>
擬似コードは以下です(Linear Probing)</p>
<pre><code class="language-bash">initialize table
count = 0

insert(key):
  h = hash(key)
  bucket = h mod capacity;
  while table[bucket] is occupied:
    if table[bucket] == key:
      break
    bucket = (bucket + 1) mod capacity
  
  table[bucket] = key
  count = count + 1
  if load_factor() &gt; threshold:
    resize()
</code></pre>
<p>挿入の計算量はO(1)ですが、擬似コードからもわかる通り実際には以下のようなオーバヘッドが乗ります。</p>
<ul>
<li>ハッシュ計算</li>
<li>キーの一致判定</li>
<li>リサイズ(テーブルが埋まってきたら、大きくして作り直す)</li>
</ul>
<p>全体的にキーが長いほど、またテーブルが埋まっていくほど遅くなります。固定長で短いキーと比べて、可変長で長いキーの方が一致判定は遅くなりがちです。</p>
<p>使う側でできる最適化の余地としては以下のようなものがあります。</p>
<ul>
<li>リサイズの発生を抑えるために初期サイズを賢く設定する</li>
<li>データの特性に合わせて適切なアルゴリズムを選択する
<ul>
<li>主に別々のキーでバケットが衝突した時に代わりのバケットを選ぶ方法について、Robin hoodやQuadratic probingなどさまざまな手法があります。</li>
<li><a href="https://thenumb.at/Hashtables/">Optimizing Open Addressing</a></li>
</ul>
</li>
</ul>
<h1>Sketch</h1>
<p>結果が近似値で良ければ Sketch が使えます。<br>
HyperLogLog が有名ですが、すでに多くの記事で紹介されてるので代わりに KMV（K-Minimum Values）Sketchを紹介します。HyperLogLogも面白いので知らない方はぜひ調べてみてください。</p>
<p>KMV ではハッシュ関数をキーに適用して、得られた値のうち小さい順に k 個だけを保持します。<br>
ユニークなキーが多ければ多いほど小さい数字(と大きい数字)もたくさん現れるわけですから、保持するk個の値はより小さい値で埋まっていくことになります。<br>
言い換えると、k に含まれる値が小さいほどユニーク数が多そうだと言えます。</p>
<p>KMV ではこの k 個の中の最大の値 R を使って、ユニーク数を推定します。</p>
<pre><code class="language-bash">推定値 = k / R
</code></pre>
<p>たとえば、 ハッシュ関数の出力が[0, 1)、 k=3 、R=0.5であれば、6個のユニークなキーがあると推定されます。</p>
<p><img src="https://ik.imagekit.io/plaid/9d6a250e-5997-42ce-93fd-a3102b6cb6e6/%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%882025-04-0415.36.59.png" alt="スクリーンショット2025-04-0514.30.38.pngスクリーンショット2025-04-0415.36.59.png"><br>
挿入の計算量はO(log k)で他の手法に劣りますが、メモリはかなり小さく保てます。</p>
<p>分散システムで顕著ですが、集計処理ではノード間での中間集計結果の受け渡しにコストがかかりがちです。そのコストが減らせるのも大きいメリットでしょう。</p>
<p>HyperLogLogより良いところとして、KMVはintersectionができます。実際の要素を保持していて、複数のSketchの共通要素を割り出せるためです。<br>
HyperLogLogでもunionはできるため包除原理で共通要素数の推定ができますが(|A ∩ B| = |A| + |B| - |A ∪ B|)、以下のように、対象のSketchが増えるほど非効率になっていきます。<br>
∣A∩B∩C∣=∣A∪B∪C∣−(∣A∣+∣B∣+∣C∣)+(∣A∩B∣+∣A∩C∣+∣B∩C∣)<br>
https://agkn.wordpress.com/2012/07/09/sketch-of-the-day-k-minimum-values/</p>
<h1>Bitmap</h1>
<p>入力が小さな整数であれば、Bitmap が使えます。キーに対応する位置のビットを立てていきます。たとえば入力のキーが42であればビット列の42番目を1にします。</p>
<p>挿入処理が軽いことと、最大値が小さければ小さい容量で表現できるのがメリットです。</p>
<p>以下は挿入処理の擬似コードです。</p>
<pre><code>bitmap = int64[(N + 63) / 64]

insert(key):
  # word(int64)の位置の計算。key &gt;&gt; 6 は key / 64 の意味
  word_index = key &gt;&gt; 6
  # word内でのbit位置の計算。key &amp; 63 は key % 64 の意味
  bit_offset = key &amp; 63
  bitmap[word_index] |= (1 &lt;&lt; bit_offset)
</code></pre>
<p>1キーに1byteを割り当てるシンプルなByteArrayにすれば、メモリを使う代わりにワードとビットの位置の計算も省略できそうです。CPUキャッシュミスが増える分遅くなることもあるので、データの特性によって検討するといいでしょう。</p>
<p>全てのキーを挿入したあと、立ってるビットを数えるにはCPU命令のpopcntを使うのが最も速いです。</p>
<p>古い言語や環境で動いていてpopcntが使えない場合はビットカウントアルゴリズムの出番です。もはや出番は少なさそうですが、面白いので紹介します。</p>
<p>ビットカウントアルゴリズムでは、ビット演算を駆使してビット列を2bit-&gt;4bit-&gt;8bitずつと小分けにして加算していきます。</p>
<p>以下分かりやすさのため8bitの入力を例にしますが、実際には64bitで処理することがほとんどです。</p>
<pre><code>bit_count(bits):
    bits = (bits &amp; 0b01010101) + (bits &gt;&gt; 1 &amp; 0b01010101);
    bits = (bits &amp; 0b00110011) + (bits &gt;&gt; 2 &amp; 0b00110011);
    bits = (bits &amp; 0b00001111) + (bits &gt;&gt; 4 &amp; 0b00001111);
  return bits
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/f72cdfe2-c328-4d7d-81b5-c53d8806fe53/%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%882025-04-0514.30.38.png" alt="スクリーンショット2025-04-0514.30.38.png"></p>
<p>基本的な演算をいくつか組み合わせるだけで何重にも並列で計算できてしまうのがすごいところです。</p>
<p>また、まとめてカウントするのではなく挿入時にビットのチェックをして都度カウントを増やす方法も取れます。空間に対して入力のキー数が少ないとわかっている場合は、その方が効率が良さそうです。ただしまとめてカウントする方も、分岐がない分CPU内での並列化も効いて速いので、多くの場合はそちらを採用していいと思います。(都度カウントしたいくらい入力が少ないとわかってるなら、そもそもBitmapよりHashTableの方が適してる気もします。最初のメモリ確保が小さく済ませられるため)</p>
<h1>ベンチマーク</h1>
<p>以下の3パターンでベンチマークを取りました。(kmvは良い実装が見つからず、AIもうまく書いてくれなかったので断念)</p>
<ol>
<li>HashTable(key=32byte, <a href="https://github.com/attractivechaos/klib/blob/5c1451caa1ee476624d00eed71810532c89b82d1/khash.h">klibのkhash</a>)
<ol>
<li>ハッシュ関数はdjb2に類似した反復ハッシュ。Open AddressingでQuadratic Probing。初期サイズはデフォルトの16</li>
</ol>
</li>
<li>HashTable(key=4byte, kilibのkhash)
<ol>
<li>ハッシュ関数はThomas Wangハッシュ。他は同上</li>
</ol>
</li>
<li>Bitmap(key=4byte)</li>
</ol>
<p>パターン1だけ入力のキー長が違います。意図としては、HashTableによるナイーブなユニークユーザカウント(UUIDを想定して32bytesのstring)と、最適化を意図してキーをint32にした手法を比較することです。</p>
<p>入力のデータセットは下記で、全てのキーを追加してユニークカウントを取るまでの時間を測りました。</p>
<ul>
<li>トータルのキー数: 10,000,000</li>
<li>ユニークなキー数: 100,000</li>
<li>int32の場合の最大のキー:  10,000,000</li>
</ul>
<p>それぞれ5回実行し、かかった時間の平均をとります。</p>
<p>コード: <a href="https://gist.github.com/takaaki7/5cdcee9cacd5133fde10c7f9edf114a2">uniqueue_count_algorithm_benchmark</a></p>
<h3>ベンチマークの結果</h3>
<p>入力が32bytes stringのHashTableとint32(4bytes)のHashTableで、30倍の差が出ました。</p>
<p><img src="https://ik.imagekit.io/plaid/aea5e11a-689f-4549-a63a-26c775cf601e/hashtablebench.png" alt="hashtablebench.png"><br>
stringの方をperfで見ると、strcmpが特に重いです。キーの一致判定をしてる部分ですね。</p>
<p><img src="https://ik.imagekit.io/plaid/c7bded59-2b26-4903-8479-63cbdbcc865c/hashtableperf.png" alt="hashtableperf.png"><br>
今回はCPU観点だけでの比較ですが、データベース上での扱いを考えると、安くて遅いストレージとの通信を減らして如何にキャッシュに載せるかも肝になります。その観点でもデータを小さくすると圧倒的に速いです。</p>
<p>また、同じint32でもHashTableよりもBitmapの方が6倍速い結果でした。</p>
<p><img src="https://ik.imagekit.io/plaid/fd06c926-424d-4ef8-9d1a-1d2f24316fc6/hashvsbitmap.png" alt="hashvsbitmap.png"></p>
<h1>終わりに</h1>
<p>行動分析に関して言えば、匿名ユーザも含めたデータ活用であればIDを4bytesまで短くすることは簡単ではないです。実際にはユニークユーザのカウントでここまで最適化した手法を使えることは多くないでしょう。</p>
<p>ただ本来は日本の全人口(1.2億)であってもわずか15mbのBitmapで表現できる量であり、空間分割や並列化を駆使しながら前処理をすればIDの短縮やBitmapカウントの適用も現実的なはずです。</p>
<p>この記事の内容はほんの一つに過ぎませんが、人の行動分析に対して、こういったアイデアを適用しながら新しいエンジンを開発中です。採用強化中です。応募待ってます！！</p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/106299"><div class="iframely-responsive" style="padding-bottom: 30.2778%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/106299" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F106299&key=878c5bef402f0b2911bf6d4ce6261abd">Software Engineer, Database Internals / 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>


異なり数を数えるアルゴリズムの概要と、それらのパフォーマンスについて比較しています

異なり数を数えるアルゴリズムとパフォーマンス比較

<h1>Introduction</h1>
<p>KARTEを支えるリアルタイムユーザー解析エンジン（Blitz）のパフォーマンスに関する記事です。解析基盤が抱えていたボトルネックを解消した方法について、新旧のアーキテクチャの違いにフォーカスしながら説明していきます。</p>
<p>以下記事の続編にあたるので、事前に読むのがオススメです。<br>
<a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）：自由度と即時更新性を担保したAggregation</a><br>
<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術（強整合な解析）</a></p>
<h1>課題</h1>
<p>KARTEのエンドユーザー(以下ユーザー)の統計情報は平均でも100kb以上と大きく、取得コストはやや大きいです。統計情報が大きくなる要因として、以下が挙げられます。</p>
<ul>
<li>統計値をフィールドやタイムウインドウごとに複数種類保持</li>
<li>一部の統計値では送信された文字列をそのまま保持</li>
</ul>
<p>下記は統計情報のイメージです。</p>
<pre><code class="language-json">{
  $week: {
    $buy: {
      sku: {
        last: &quot;xxxxxxxxxxxxxxx&quot;,
        first: &quot;yyyyyyyyyyyyyyyyyy&quot;,
        sets: [&quot;xxxxxxxxxxxxxxx&quot;,&quot;yyyyyyyyyyyyyyyyyy&quot;],
        ....
      },
      price: {
        last: 100,
        sum: 2000,
        max: 200,
        ...
      }
    }
  }
}
</code></pre>
<p>統計情報はBigtableに保存しています。</p>
<p>旧アーキテクチャでは、ユーザーのイベントが発生するたびにBigtableからこのユーザー統計情報を取得しており、全体の中で最もコストとレイテンシがかかる処理でした。</p>
<p><img src="https://ik.imagekit.io/plaid/9a8c4407-7e37-4509-8cef-252587a266af/%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%882025-03-0523.31.10.png" alt="スクリーンショット2025-03-0523.31.10.png"></p>
<p>キャッシュの導入は整合性の問題で困難でした。Bigtableから取得した統計情報をそのままキャッシュすると、一部のイベント(まだRealttime Queue上にあってConsumeされてないイベント)が畳み込まれていない統計情報を使い続けることになってしまうからです。</p>
<p>このような要因からアクション配信のレイテンシはp95で1.5秒程度でした。ユーザー体験を損ねているというフィードバックをお客様からいただくこともよくありました。</p>
<p>このボトルネックをBlitzで解消した方法について説明します。</p>
<h1>1. 取得するデータの絞りこみ</h1>
<p>Blitzのバックエンドは、アクションを配信するサーバ(以下アクションサーバ)と、統計情報を永続化するサーバに大きく分かれます。<br>
アクションサーバでは、ユーザーの統計情報を使ってパーソナライズされたアクション(メールやポップアップ)を配信します。</p>
<p>ここで、保存されてる統計情報のうち実際に配信に使われる統計値はごくわずかです。<br>
旧アーキテクチャではほとんど全ての統計情報を取得していましたが、Blitzでは、お客様が設定したアクションの配信設定から必要最小限の統計情報のフィールドと<a href="https://cloud.google.com/bigtable/docs/filters?hl=ja">Bigtableのフィルタ</a>を算出し、データベースから取り出しています。</p>
<p><img src="https://ik.imagekit.io/plaid/8b05e23c-02bb-430c-9c98-6351ca4d0585/%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%882025-03-0415.36.06.png" alt="スクリーンショット2025-03-0415.36.06.png"><br>
一見シンプルに見えますが、以下の点が課題でした。</p>
<ul>
<li>配信設定に関する機能は多岐に渡り、必要な統計値を算出するための対応箇所が多い</li>
<li>統計値間の依存関係がある
<ul>
<li>例：「平均」は「合計と回数」に依存(後述の通り統計情報をキャッシュ上で更新し続けるため、依存する統計値も必要)</li>
</ul>
</li>
<li>統計値のタイムウインドウ間の依存がある
<ul>
<li>例：「前回のセッション」は「最新のセッション」に依存(こちらもキャッシュ上で更新し続けるために必要)</li>
</ul>
</li>
<li>Bigtableのフィルタは細かく設定しすぎるとCPU消費が大きくなり逆効果
<ul>
<li>Bigtableのフィルタだけだと絞り込みきれないから、デシリアライズ時にも余分なフィールドの実体化を省略したい</li>
</ul>
</li>
</ul>
<p>対応として、フィルタの中間表現を定義し、統計値間の依存を考慮して中間表現を算出するモジュールを作ることで、安全かつ簡単に統計値への依存を追加できるようにしました。また、中間表現を挟むことで、Bigtableとデシリアライザのフィルタリングもシンプルに実装できました。この中間表現はMongoDBの機能になぞらえてProjectionと呼んでいます。</p>
<p><img src="https://ik.imagekit.io/plaid/690e6e21-ba66-4be9-a7d6-799464462f66/%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%882025-03-0516.12.02.png" alt="スクリーンショット2025-03-0516.12.02.png"><br>
こちらは全体のフローのイメージです。</p>
<p><img src="https://ik.imagekit.io/plaid/d619202c-7ca2-4106-b63f-6c520087dd6a/%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%882025-03-0416.53.34.png" alt="スクリーンショット2025-03-0416.53.34.png"></p>
<p>またデータフォーマット自体もJSONからMessagePackに変更して、少量化とSerialize/Deserializeの改善をしました。</p>
<p>(厳密にはこれらの最適化自体はリアーキテクチャせずとも実装可能でしたが、改修の難易度が高かったので、リアーキテクチャに伴うコードベースとデータの刷新に混ぜ込む形で実装しました)</p>
<h1>2. キャッシュ</h1>
<p>絞り込みによって一定の改善ができたものの、依然として取得処理は重いです。<br>
更なる改善として、Blitzではユーザーの統計情報をアクションサーバのメモリにキャッシュしています。</p>
<p>キャッシュの整合性と効率に焦点を当てつつ、その仕組みについて説明します。</p>
<p>前記事でも述べた通り、Blitzではアクションサーバの前段にBigtableベースのイベントキューがあります。また、キューにイベントが追加されるとLoadBalancer経由でアクションサーバに通知されます。<br>
<img src="https://ik.imagekit.io/plaid/f58e2d9b-6c30-4e0d-aeef-afe6bbc6cbc9/%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%882025-03-1211.55.47.png" alt="スクリーンショット2025-03-1211.55.47.png"></p>
<p>どのアクションサーバに通知が届いても、そのサーバは、今までに送られた全てのイベントが畳み込まれた最新のユーザー統計情報を扱わないといけません。一見難しく見えますが、強整合性が担保されたキューが前段にあることで、シンプルに実現できました。</p>
<p>キューのチェックポイントも統計情報と一緒に保持し、通知を受けたらそのチェックポイント以降のデータをキューからスキャンすればいいのです。</p>
<p>以下は、アクションサーバの処理フローを示した疑似コードです。</p>
<pre><code class="language-java">handle_notification(user_id):
    user = cache.get(user_id)
    if user is None:
        user = db.get_user(user_id)
    
    # チェックポイント以降のイベントをBigtableからスキャン
    events = scan_events(user_id, user.checkpoint)
    
    for event in events:
        new_user = reduce(user, event)
        deliver_personalized_action(event, new_user)
    
    new_user.checkpoint = events[-1].timestamp
    
    cache.put(user_id, new_user)
</code></pre>
<p>基本的なロジックはこれだけです。</p>
<p>また、LoadBalancerにはGCPのL7 Internal LoadBalancerを採用しました。<a href="https://cloud.google.com/load-balancing/docs/backend-service#session_affinity">Session Affinity</a>のキーにuser_idを指定して同じユーザーのイベントをできるだけ同じサーバに振り分けることで、キャッシュ効率を上げています。<a href="https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy">Consistent Hash</a>を使うことで、バックエンドの台数が増減してもキャッシュミスは少なく収まります。</p>
<p>データをしっかり絞り込んだおかげか、メモリやGC関連で苦戦を強いられることもこれといってありませんでした。machine typeも特別メモリが大きいものではないです。</p>
<p>ここまでの説明だと簡単そうに見えますが、実際には以下のような点について、さらに複雑なロジックを実装しています。</p>
<ul>
<li>アノニマスユーザーがサービスにログインしたときに、サービスのユーザーIDでマージ</li>
<li>イベントの順序性の担保
<ul>
<li>ナイーブにBigtableのキューのキーにタイムスタンプを付与するだけだと、クロックのズレなどの要因で順序担保ができません</li>
</ul>
</li>
<li>Statsを都度作り直すと重いので、スレッド間の競合制御をしながらキャッシュをmutableなobjectとして更新</li>
</ul>
<h1>結果</h1>
<p>他にも様々な改善が加えられた新アーキテクチャに移行して、以下が達成できました。</p>
<ul>
<li>Compute Engineのコストが7割減</li>
<li>アクション配信のレイテンシ(p95)が1500msec -&gt; 200msec
<ul>
<li>配信が遅いという声も聞かなくなりました</li>
</ul>
</li>
<li>Bigtableのコストが数割減(正確なデータが探せませんでした…)</li>
</ul>
<p>裏側としてはなかなかいい成果だったと思います。ただ、2022年の円安が加速している時期に移行してコスト削減の効果が相殺されたことなどもあり、最終的には少し派手さに欠ける結果になったのを覚えています笑</p>
<h1>まとめ</h1>
<p>以前のアーキテクチャでは解析が非同期であるがゆえに、結果整合性しか担保できず、統計情報のキャッシュもできていませんでした。</p>
<p>BlitzではBigtableのキューを前段に置くことで、整合性とパフォーマンスの2つの問題が解決できました。さらに言えば、受信したリクエストをすぐにキューに積むため、データが欠損するリスクへの耐性も上がったと言えます。</p>
<p>1つのアイデアで複数の課題が解けたところは面白い点だと思います。</p>
<p>他にも様々な最適化や運用上の工夫が凝らされているので、今後紹介できればと思います。</p>


KARTEのリアルタイムユーザー解析エンジンのアーキテクチャを刷新し、キャッシュ設計等を工夫してボトルネックを解消した方法を説明します

Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計 - PLAID engineer blog

Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計

<p>こんにちは、株式会社プレイドで内定者アルバイトとしてCore Platform Team でプラットフォームエンジニアをしている小林と申します。プレイドには今春新卒として入社予定です。</p>
<p>今回は福岡で実施された第17回データ工学と情報マネジメントに関するフォーラム <a href="https://pub.confit.atlas.jp/ja/event/deim2025">DEIM2025</a> に参加しましたので、その内容をレポートします！</p>
<h2>プレイドは日本データベース学会(DBSJ)に入会しました</h2>
<p>今年から株式会社プレイドは、データベースやデータ工学分野における最新の研究動向の把握やコミュニティへの貢献を目的に、日本データベース学会(<a href="https://dbsj.org/">DBSJ</a>)に維持会員として入会しました。</p>
<p>その活動の一環として、DBSJが主催する「第17回データ工学と情報マネジメントに関するフォーラム(DEIM2025)」に本年ゴールドスポンサーとして参加し、ブースの出展・技術報告に加え、論文の発表を行いました。</p>
<h1>DEIMについて</h1>
<p>DEIM は日本データベース学会・電子情報通信学会 データ工学研究専門委員会・情報処理学会 データベースシステム研究会が主催している、データ工学と情報マネジメントに関する研究発表や意見交換を目的とした学術集会です。今回は2月27日~3月1日がオンライン、3月3日と4日がオンサイトで福岡国際会議場での開催となりました。</p>
<h1>技術広報活動</h1>
<p>会社として学会に参加し、以下2つを実施しました。</p>
<ol>
<li>ブース出展</li>
<li>技術報告論文の執筆、発表と技術登壇</li>
</ol>
<h2>ブース出展</h2>
<p>株式会社プレイドはDEIM2025に初めてゴールドスポンサーとして参加し、スポンサーブースを出展しました。ブースでは社員が弊社の主要プロジェクトである<a href="https://karte.io/">KARTE</a>や、用いられている技術の説明を行いました。データベースやビッグデータの分析に関連する研究を実施している研究者の方が多く参加されていたので、技術スタックや現状の課題、技術的に難易度の高い部分についてなど様々な質問をいただき、多くの学生や企業の方とお話することができました。また、弊社はロゴ入りのタンブラーやサウナハットなどのグッズと、事業内容とそこで利用している技術についてのパンフレットの配布も行いました。ブースを訪れてくださった皆さん、ありがとうございます！</p>
<p><img src="https://ik.imagekit.io/plaid/30bbfdc3-5b18-4b06-a667-4d50b7145557/756d8989-cdc2-4ffa-9a52-d3e15786a5c9.webp" alt="756d8989-cdc2-4ffa-9a52-d3e15786a5c9.webp"></p>
<h2>技術報告論文の執筆、発表と技術登壇</h2>
<p>「<a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/4D-04">Blitz: データ強整合性を持つリアルタイムエンドユーザー解析エンジンBlitz: データ強整合性を持つリアルタイムエンドユーザー解析エンジン</a>」と題し、メインのプロダクトであるKARTEで開発しているデータ解析基盤についての論文を投稿し発表を行いました。多くのお客様にご利用いただいているKARTEのサーバーは日中平均で秒間7万リクエスト、多いときには秒間13万のリクエストがあり、それぞれに対して強整合性を保ちつつリアルタイムで解析を行い、500ms 以下で結果を返却しています。このような高スループットと強整合性を実現し実際の環境で運用する難易度は高く、興味深い論文になっているのではないかと思います。また、「<a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/2F-05">月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント</a>」という題名で技術登壇も実施しました。こちらでもリアルタイム解析基盤についての紹介や、大規模データを扱うにあたっての工夫などを紹介しています。スライドも公開されているので、ご興味のある方はこちらもぜひご覧ください！</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/a7f1e9a3adba4de2b87e4b5cac50529b" title="月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
<p>DEIMでは他にも技術報告を実施している企業が多くあり、企業ごとの独自の課題に対する様々なアプローチを見ることができとても魅力的でした。</p>
<h1>参加した感想</h1>
<p>私は学会に参加するのが初めてだったので、どんな雰囲気なのかと少し緊張しながら会場へ向かったのですが、会場では参加者同士の交流が盛んに行なわれており非常に楽しい時間を過ごすことができました。</p>
<p>ポスターセッションの時間は1時間半ごとに区切られているのですが、魅力的なポスターや元々興味を持っていた分野に関連するものなど心を惹かれる発表が多くあったため見て回ることに苦労しました。</p>
<p>LLMを活用した商品レビュー分析や分散データベースのトランザクションに関わる研究、さらにはデータサイエンスを活用し周期性を持った天体の周期分析に関わる研究など多様な研究分野の発表があり、初見では理解できないことが多かったのですが、専門外の私に対してどなたもわかりやすく説明してくださいました。学校や会社、年齢の垣根を超えて学術的な交流ができる学会という環境の素晴らしさを実感しました。</p>
<p>また、私は東京在住であり、大学も会社のオフィスも東京にあることから首都圏の学生との交流がどうしても大きな割合を占めてしまうのですが、今回の学会は福岡で開催されており関西や九州の学生の方々とお話することができたのも良かったです。今回はスポンサー企業所属としての参加でしたが、まだ大学にも在籍している学生なので学生目線で参加していた学生の方々とお話することができたかなと思います。</p>
<p>聞き切れていない発表も多くあるのですが、お話を伺ったなかで個人的に興味深かった研究をいくつかご紹介します。</p>
<h2>部分ステートマシンレプリケーションにおける投機的分散トランザクション処理</h2>
<p><a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/7C-03">https://pub.confit.atlas.jp/ja/event/deim2025/presentation/7C-03</a></p>
<p>白石 裕輝1、杉浦 健人2、石川 佳治2 (1. NTT、2. 名古屋大学)</p>
<p>NTTコンピュータ&amp;データサイエンス研究所さんで行われている研究で、分散データベースのトランザクション処理を高速化する新たな手法を提案されています。分散データベースにおいてトランザクションを実施する際、既存のアプローチではトランザクション処理の順序や可否を分散して判定することで高速化を図っていますが、ロジックの実行がトランザクションのコミット後に行われるため複数のトランザクションが存在する場合ロジックの実行が遅延してしまいます。そこで、投機的に読み書きを行うことによってコミット前にロジックを実行し、実行遅延を軽減する手法を提案しています。</p>
<p>具体的な例を考えてみましょう。トランザクションAとBが存在する際に、既存手法ではAでの書き込みを待ってBでの読み取りを行いますが、Bで読み取る行にAによる更新が無い場合はこの待機時間は必要ありません。本手法では、コミット前に投機的な読み取りをし、読み取った後に更新が無い場合はこの待機を行わないという処理を行うことにより処理の高速化を行っているものと解釈しました。</p>
<p>プレイドでは MongoDB や Google Spanner といった分散データベースを積極的に活用しており、社内にはデータベースの内部構造に興味を持つ人も多くいます。こういった手法がデータベースに実装されていくことにより処理の高速化に繋がるので、基盤チームとしては見逃せない研究と言えます。</p>
<h2>局所探索法を用いた実体化ビュー選択によるクエリワークロード処理の高速化</h2>
<p><a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/3C-03">https://pub.confit.atlas.jp/ja/event/deim2025/presentation/3C-03</a></p>
<p>アンダーソン 圭那1、鬼塚 真1、佐々木 勇和1、Yohanes Yohanie Fridelin Panduman1 (1. 大阪大学)</p>
<p>大阪大学に在籍している方の研究で、クエリワークロードの高速化を行う際の実体化ビューの選択手法を提案されています。複雑なクエリワークロードを実行する際は実体化ビューを用いることによりクエリの高速化が可能となりますが、どの部分クエリを実体化するかという選択は実体化ビューの容量や更新処理のコストなど考慮するべき変数が多数あります。既存の手法では確率を用い実体化ビューを選択していますが、本手法では局所探索法を用いて解の探索を行うことで既存手法より効率の良い実体化クエリの選択を可能としています。</p>
<p>プレイドでは多くの行動データを日々解析しており、その活用の際にはクエリの実行時間が問題となってきます。データが多ければ活用の幅も広がりますが、実体化ビューなどを利用しないと実行時間もデータ量に比例して長くなっていってしまいます。このような手法を用いることによりクエリの高速化が実現できれば、データの利活用をより進めることができそうです。</p>
<h2>偏向型テンソルストリームのための多方向特徴自動抽出とリアルタイムサイバー攻撃検出への応用</h2>
<p><a href="https://pub.confit.atlas.jp/ja/event/deim2025/presentation/4D-02">https://pub.confit.atlas.jp/ja/event/deim2025/presentation/4D-02</a></p>
<p>中村 航大1,3、川畑 光希1、田中 駿吾1,2、松原 靖子1、櫻井 保志1 (1. 大阪大学産業科学研究所、2. 大阪大学工学部電子情報工学科 、3. 大阪大学大学院情報科学研究科)</p>
<p>こちらも大阪大学に所属されている方の研究で、サーバーの通信ログなどから潜在的なパターンを抽出しサイバー攻撃を検知することを可能とする手法を提案しています。ログに含まれるポート番号などのカテゴリ属性と、時刻など連続的に変化する量的属性の両方をテンソルストリームとして扱い、一定時間ごとに傾向を分析することにより異常な活動を検知することができます。カテゴリ属性と量的属性を上手く扱い、さらに時系列パターン分析を用いることで既存の手法では検出が難しかった攻撃も異常として捉えることができるそうです。</p>
<p>KARTEでは様々なウェブサイトからの膨大な数のリクエストを処理しており、サイバー攻撃への対策は必須です。このような手法を取り入れることによって、今まで検知が難しかった攻撃を検知できるようになり、よりサイバー攻撃に強いサービスを作りあげることができるのではないかと考えています。</p>
<h1>最後に</h1>
<p>株式会社プレイドはDEIM2025に初めてゴールドスポンサーとして参加し、スポンサーブースを出展しました。</p>
<p>プレイドではデータベースやデータ解析といった分野と関わりが深いプロダクトの開発を行なっており、難易度の高い課題に取り組む機会が多くあります。DEIMにご興味のある方には、面白いと感じるポイントが多くあるのではないかと思います。プレイドの技術や、プレイドで働くことに興味を持たれた方は、是非以下のリンクを覗いてみてください。</p>
<p><a href="https://recruit.plaid.co.jp/product">採用ページ</a></p>
<p><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a></p>
<p><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a></p>


DEIM2025参加レポート：内定者のエンジニアが初めての学会で得た学びと刺激

<h2>はじめに</h2>
<p>プレイドのApp Teamでエンジニアをしている市川です。</p>
<p>App Teamとは『KARTE for App』は分析から施策実行までをワンストップで提供し、モバイルアプリのエンゲージメントをより高めるためのプロダクトを提供するチームです。</p>
<p>今回はApp Teamのエンジニアだけで1日ハッカソンを開催し、KARTE for Appが提供するSDKから送信されるイベントデータをリアルタイムに近い速度で閲覧可能にする新機能を作りました！ 🥳</p>
<h2>なぜハッカソン？</h2>
<p>App Teamの開発は、「大きなIssue＝エピックでチーム対応、小さなIssue＝月1回のスプリントで個人ごとにIssueをアサイン」というスタイルで進めています。ただ、ちょうど中間レベルのIssueで「これがあったら便利だよね」と言われつつ、誰も手をつけられずにいたものが、なかなか実行に移されない課題がありました。そこで、チームビルディング観点も含めて「1日ハッカソンで一気に作ってしまおう！」というでハッカソンを決行しました 😎</p>
<h2>当日の流れ</h2>
<p>1日ハッカソンにはApp Teamのエンジニア4名、デザインエンジニア1名、そしてインターン生1名が参加しました。朝から集まって開発するというのは、なかなかない機会なので学園祭感で面白かったです！</p>
<p><strong>9:00〜</strong></p>
<ul>
<li>ブリーフィングと質問対応</li>
<li>タスク分担やざっくり設計の打ち合わせ</li>
</ul>
<p><strong>12:00〜</strong></p>
<ul>
<li>ランチ（お弁当を食べながら雑談＆進捗共有）</li>
</ul>
<p><strong>16:30〜</strong></p>
<ul>
<li>Pull Request作成・レビュー・動作確認</li>
</ul>
<p><strong>18:00〜</strong></p>
<ul>
<li>チーム内でデモ共有</li>
<li>「早く使いたい」というフィードバックに盛り上がるw</li>
</ul>
<p><strong>18:30</strong></p>
<ul>
<li>解散</li>
</ul>
<h2>作成したかった機能</h2>
<p><strong>概要</strong></p>
<ul>
<li>KARTE for Appが提供するSDKから送信されるイベントデータを、<strong>ほぼリアルタイム</strong>でKARTE管理画面から閲覧できるようにする</li>
</ul>
<p><strong>制約</strong></p>
<ul>
<li>従来の仕組みではイベントデータが送信されてから、KARTE管理画面で閲覧するまでに数秒遅延があるため別の仕組みを考える（詳しくは後述）</li>
<li>社内検証から始めて、将来的にはクライアントにも提供する想定</li>
<li>保守性・拡張性・セキュリティを担保した設計にすること</li>
</ul>
<h2>背景/課題</h2>
<p>KARTE for Appの提供するSDKは、モバイル向けのネイティブアプリ上でのユーザー行動を計測したり、アプリ内メッセージやプッシュ通知でのアクションを行うことが可能にするものです。</p>
<p>実際にアプリを操作すると、そのイベントデータをKARTE管理画面で閲覧できますが、閲覧タイミングには数秒のラグが発生します。プレイドの強みでもあるリアルタイム解析基盤「Blitz」を通し、BigQueryに保存されたデータをKARTE管理画面で参照し表示しているためです。Blitzについて、詳しく知りたい方はこちらをご覧ください！<br>
<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a></p>
<p>実際の運用上、「イベントデータが正しく送信されているかをテストしたいだけ」の場面があり、その数秒が意外と煩わしいという声があがっていました。</p>
<h2>成果物</h2>
<ul>
<li>送信されたイベントデータを閲覧するための画面（React）</li>
<li>SDKから送信されるイベントデータを受け取るエンドポイントとロジック（express）</li>
<li>イベントデータを新しく作成したエンドポイントに送付するモジュールの作成（iOS/Android）</li>
</ul>
<h3>実装の仕組み</h3>
<p><strong>従来のフロー</strong></p>
<p><img src="https://ik.imagekit.io/plaid/85f19485-7f93-4445-bddd-e89169efc517/%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%882025-02-269.56.02.png" alt="スクリーンショット2025-02-269.56.02.png"></p>
<p>従来は、SDKからのイベントデータが「Blitz」で解析され「BigQuery」に保存されてから、KARTE管理画面から参照しています。数秒の遅延が発生する原因でした。</p>
<p><strong>新しく作成したフロー</strong></p>
<p><img src="https://ik.imagekit.io/plaid/7d1276bf-05b1-4afa-959b-28648c07f69a/%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%882025-02-269.56.20.png" alt="スクリーンショット2025-02-269.56.20.png"></p>
<h3>工夫した点</h3>
<ul>
<li>「SSE（Server-Sent Events）」を使い、サーバーがイベントを受け取ったタイミングでフロントエンドに即通知する設計を採用した</li>
<li>「KARTE」はマイクロサービスアーキテクチャを採用しており、イベントデータ受信用サービスとKARTE管理画面は別サービスになっている
<ul>
<li>ここを「Redis」の<a href="https://redis.io/docs/manual/pubsub/">Pub/Sub機能</a>で接続して、リアルタイム通知を実現した</li>
</ul>
</li>
<li>クライアントの本番環境には要らない機能なので、コアのSDKのモジュール群とは別のモジュールとして開発し、コア側はイベントビューワーのモジュールを「知らない」状態を実現した</li>
<li>フロントエンド側は、<a href="https://tech.plaid.co.jp/analyze-internal-ui-library-usage">弊社デザインシステムSourのReactJS用ライブラリである「sour-react」</a>を使うことで、フロントエンジニアだけで綺麗なUIを実現した</li>
</ul>
<h3>デモ</h3>
<p>今回開発したUIでは、アプリ操作（ボタンクリックなど）からリアルタイムにイベントデータがKARTE管理画面で表示され、イベントデータをその場で確認できます。<br>
<img src="https://ik.imagekit.io/plaid/b4b580dc-5ecd-417a-b576-a0d364d0d7bc/ScreenRecording.gif" alt="ScreenRecording.gif"></p>
<p>従来の画面（数秒の遅延があるため、テスト時には待ち時間が発生していました）</p>
<p><img src="https://ik.imagekit.io/plaid/be922b0a-d55f-417d-ba98-da8ba318b9a9/%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%882025-02-0619.30.46.png" alt="スクリーンショット2025-02-0619.30.46.png"></p>
<p>この機能によって「誤ったフィールドを送っている」「イベント自体が飛んでいない」といったミスを即座に発見できるようになりました！この改善によってデバッグやテスト作業が劇的に楽になり、チーム内外のメンバーから「便利になった」と好評です！</p>
<h2>まとめ</h2>
<p>1日ハッカソンという短い時間でしたが、集中力とモチベーションを高められたのも大きな成果です。実際にメンバーからは「丸一日コードに没頭できて最高」「少し重いなと思っていたIssueも意外と完成できた」といった声があがりました。</p>
<p>App Teamでは、クライアントSDKの開発と運用からKARTE管理画面の開発をしています。スタートアップからメガバンクまで、幅広いクライアントが利用できるマーケティング機能を提供するSDKを開発し、日々数千万人を超えるエンドユーザーへの価値提供ができる環境です。<br>
興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


この記事ではMobile SDK発火のKARTEイベントをリアルタイムに閲覧する機能をハッカソンで１日で作った話を掲載します

Mobile SDK発火のKARTEイベントをリアルタイムに閲覧する機能をハッカソンで１日で作った話

<p>こんにちわ、プレイドでエンジニアをしている塩澤（<a href="https://github.com/hshiozawa">@hshiozawa</a>）です。</p>
<p>プレイドはミッションとして「データによって人の価値を最大化する」を掲げています。私たちにとって「データ」は会社のミッションに掲げるほどの重要な存在です。プレイドは多種多様なデータを扱っていますが、データから価値を生み出すためにはその品質（Data Quality）が非常に重要となります。</p>
<p>この記事では Google Cloud Dataplex の<strong>自動データ品質（Auto Data Quality）機能</strong>を使ったデータ品質向上の取り組みについてご紹介します。</p>
<h1>データ品質</h1>
<p>プレイドでは Google Cloud の BigQuery を利用して多種多様な大量のデータを扱っています。データパイプラインやテーブルも数多くあり、マイグレーションも頻繁に行っています。このような大量のデータから価値を生み出すために、データ品質の向上は必要不可欠なものです。</p>
<p>たとえば、ユーザーの Web サイト上での行動データを考えてみます。サイトの運営者はサイトでのユーザー体験をよりよくするためにデータを使ってユーザーを理解しようとします。その時、行動データが次のような状況だとどうなるでしょうか？</p>
<ul>
<li>ユーザー ID が含まれていないレコードが存在する</li>
<li>行動イベントのレコードが一部抜け落ちている</li>
<li>購入イベントのレコードが重複して存在する</li>
</ul>
<p>このような状況ではデータからユーザーを正確に理解することはできませんし、ユーザー体験を向上することもできません。これはあくまで一例ですが、ユーザーのイベントに限らずデータの品質が低い場合には、そこから価値を生み出すことが難しくなります。</p>
<h2>定義</h2>
<p>ここまでは曖昧に「データの品質」という言葉を用いてきましたが、『データマネジメント知識体系ガイド 第二版』（通称 DMBOK）ではデータ品質を次のように定義しています。</p>
<blockquote>
<p>データ品質は、データ品質の各評価軸が要件を満たす度合いとして定義できる。これは要件を、（関連する）それぞれの評価軸ごとに策定する必要があることを意味する。データ品質の定義を簡潔にすると、「目的に適合している」となる。</p>
</blockquote>
<p>このようにデータ品質を考えるためにはデータを評価するための一定の軸を定める必要があります。DMBOK では一般的な合意が得られているデータの評価軸として次のようなものを挙げています（抜粋しています）。</p>
<ul>
<li>有効性（Validity）：定義された領域と一致しているかどうか</li>
<li>完全性（Completeness）：必要なデータが存在するかどうか</li>
<li>一貫性（Consistency）：同じルールで表されているかどうか</li>
<li>適時性（Timeliness）：ユーザーがデータにアクセスできるまでの時間</li>
<li>一意性（Uniqueness）：一意であるべきデータが重複してないかどうか</li>
</ul>
<p>データ品質を向上させるためには、データの特性に応じてこれらがどの程度満たされるべきかの要件を定める必要があります。その後、この評価軸がどれだけ満たされているかを実際に測定し、必要な修正を行います。そして最も重要な点は、この一連の活動を継続して続けていくことです。</p>
<h1>課題</h1>
<p>ここからはプレイドにおけるデータ品質に対しての課題について述べます。話を簡単にするため以下のようなシンプルなパイプラインを想定してみます。</p>
<p><img src="https://ik.imagekit.io/plaid/062cadf1-e172-4bfb-8608-2eea59633cfb/pipelines.png" alt="pipelines.png"></p>
<p>データソースで発生したデータは BigQuery に書き込まれます。その後、解析などのアプリケーションによってデータが変換され、他のテーブルに書き込まれます。このような構成のパイプラインはプレイドに多く存在します。</p>
<p>このようなパイプラインに対していくつかの方法でデータの正しさをチェックしていました。</p>
<p><img src="https://ik.imagekit.io/plaid/de391f90-7578-4620-b522-675d0b19ac9a/checks.png" alt="checks.png"></p>
<ol>
<li>データソースがデータを書き込む際に、書き込む側がデータを確認</li>
<li>データを変換した後に Transformer がデータの正しさを確認</li>
<li>テーブルのチェックジョブが定期的にデータのぬけもれを確認</li>
<li>他のパイプラインがデータを使う前にデータの整合性を確認</li>
</ol>
<p>このようにして様々な箇所で独自のデータのチェックが行われていました。また、これらはすべてのパイプラインで実現されていたわけではなく、それぞれのパイプラインの特性や重要度に応じて実装されていました。</p>
<p>これらの手法は必要に応じて要求に特化したチェックができるのでメリットもありますが、本質的には次のような問題を抱えていました。</p>
<h2>評価軸が不明瞭</h2>
<p>データ品質の定義で述べたように、データ品質には評価軸という考え方があります。しかし、この確認方法では、それぞれがどの評価軸に対応したチェックなのかが不明瞭です。この曖昧さによって問題を正確に捉えることが困難になり、効果的な施策が実行されない要因となっていました。</p>
<p>また、評価軸が不明瞭であることでデータ品質という概念自体をチームに浸透させることが難しいという面もありました。</p>
<h2>要求が分かりづらい</h2>
<p>評価軸の問題に加えて、それぞれのデータに求められている要求が明らかになっていないことは大きな問題でした。これらの方法によって「データに問題がない」ことは確認できています。しかし、データが満たすべき要求が明確になっていません。</p>
<p>これは要求をコード上に手続き的に記述したり、確認用の SQL クエリの実行で実現していることも要因です。手続き的なコードや確認用の長いクエリを見ただけでは、何が満たすべき基準なのかを判断することは難しくなってしまいます。</p>
<h2>観測可能性が低い</h2>
<p>既存の確認方法では「データがテストケースを満たしたかどうか」の単純な事柄しか分かりません。「テストケースは満たしているが品質が徐々に劣化している」ようなケースが把握できません。そのため、問題が起きる前に早めに手を打つことができません。また、過去の履歴を統一的に記録する仕組みがないため昔の品質や、品質の推移を確認できていません。</p>
<h2>仕組みの乱立</h2>
<p>それぞれの部分で独自の仕組みを作ったことで、プロダクトを横断する統一的な基準を作ることが難しくなってます。また、それぞれでデータの確認の実現方法が異なるため、あるチームは SQL クエリとして実現し、あるチームは API を利用して確認する、といったように確認方法が乱立しました。</p>
<p>実現方法が異なることでメンテナンスコストが高くなり、最悪の場合はメンテナンスされなくなり放置される可能性もあります。こうなるとデータ品質を保つことは難しくなります。</p>
<h1>Dataplex 自動データ品質の採用</h1>
<p><a href="https://cloud.google.com/dataplex?hl=ja">Google Cloud Dataplex</a> はデータを管理・統合するためのデータファブリックです。BigQuery に限らず分散したデータを統合・統制するためのデータカタログやデータメッシュなど、様々な機能を提供しています。</p>
<p>自動データ品質はこの Dataplex 内の機能の一つです。BigQuery のテーブルに対してルールを定義し、ルールを満たしているかどうかを確認することができます。</p>
<p>ここからは Google Cloud Dataplex の自動データ品質機能（以下、自動データ品質）を採用した理由について述べます。ここでは自動データ品質の利用の仕方については詳しく書きません。利用方法はドキュメント等を参考にしてください。</p>
<p><a href="https://cloud.google.com/dataplex/docs/auto-data-quality-overview?hl=ja">自動データ品質の概要  |  Dataplex  |  Google Cloud</a></p>
<h2>理由1：ルールを YAML で記述できる</h2>
<p>自動データ品質ではルールを下記のような YAML で記述することができます。</p>
<pre><code class="language-yaml">rules:
- uniquenessExpectation: {}
  column: transaction_id
  dimension: UNIQUENESS
- nonNullExpectation: {}
  column: amount
  dimension: COMPLETENESS
  threshold: 1
- setExpectation :
    values :
    - 'USD'
    - 'JPY'
    - 'INR'
    - 'GBP'
    - 'CAN'
  column : currency_id
  ignoreNull : true
  dimension : VALIDITY
  threshold : 1
</code></pre>
<p>データが満たすべきルールを宣言的な形で記録できるのは大きな利点です。これによってそれぞれのカラムが満たすべき要求を把握することが簡単になります。また、Single Source of Truth となっているので、満たすべき要求を変えたい場合はこの YAML を変えるのみです。</p>
<h2>理由2：スコアリング</h2>
<p>自動データ品質のチェック結果には <code>0~100</code> のスコアが含まれています。これまではテストの成功か失敗しか把握できませんでしたが、ある程度の尺度で品質を評価できるようになりました。また、全体のスコアに加えて YAML で設定した dimension（評価軸）ごとのスコアも取得することができるため、評価軸ごとの品質評価も可能となります。</p>
<h2>理由3：シンプルな仕組み</h2>
<p>BigQuery のデータ品質を確認するツールは自動データ品質以外にもいくつかあります。dbt や dataform などがありますが、これらはデータ管理ツールの一種でテーブル自体をそれらのフレームワーク上で管理するのが一般的です。</p>
<p>その点、自動データ品質は BigQuery のデータ品質を確認する部分だけで利用できることができます。すでにある BigQuery のデータに対して変更を加える必要はありません。また、自分でインスタンス等のリソースを準備する必要もありません。これらは自動でデータ品質を採用した大きな理由です。</p>
<h2>理由4: BigQuery との親和性</h2>
<p>自動データ品質は BigQuery を前提に作成されているので BigQuery との親和性が非常に高いです。弊社は多くのデータを BigQuery で扱っているのでこの点はとても重要です。</p>
<p>具体的にはパーティションごとのインクリメンタルスキャンや、ネイティブテーブル以外にも多く対応しています。また、BigQuery の既存のテーブルをスキャンし、自動でそれを満たすようなルールを作成してくれるような便利な機能もあります。</p>
<h2>理由5：実行履歴の記録</h2>
<p>チェックの結果は Google Cloud コンソールから GUI で確認できます。それ以外にも結果を BigQuery のテーブルに保存することもでき、ほぼ永続的にデータ品質の推移を保持することが可能です。</p>
<p>また、前述したスコアリングに加え、カラムごとの細かいチェック記録も保存されているで、あとからカラムごとの品質推移を追うこともできます。</p>
<h1>アーキテクチャ</h1>
<p>ここからは構築したシステムのアーキテクチャについて説明します。</p>
<p>Dataplex の自動データ品質が持っているマネージドな機能をベースにして、プレイドの状況に合わせて補助的なアプリケーションを作成してシステムを構築しました。構築したアーキテクチャの全体像は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/433c59d4-7c53-4e52-9607-299d0081a796/architecture.png" alt="architecture.png"></p>
<h2>スキャン実行アプリケーション</h2>
<p>自動データ品質を実行するためのアプリケーションは独自に実装しました。このアプリケーションは API を利用して自動データ品質を実行します。自動データ品質はマネージド機能なので実行アプリケーションを作らずとも利用することもできます。ただ、プレイドの状況に合わせるため、下記のような機能を実装して自動データ品質を補完していますました。</p>
<ul>
<li>複数のルールを指定可能にし、同時並行で実行できるようにした</li>
<li>日付を指定可能にして、日付シャーディングテーブルに対応した</li>
<li>リージョンを指定可能にして、同じルールを異なるリージョンでチェックできるようにした</li>
</ul>
<p>このように独自のアプリケーションを作ることで、自動データ品質の機能を補ってより柔軟なチェックが可能になりました。</p>
<h2>ルールの管理</h2>
<p>上述したようにテーブルの満たすべきの仕様は YAML ファイルとして定義しています。この YAML はスキャン実行アプリケーションのソースコードと同一の Git リポジトリでバージョン管理しています。こうすることであるべき仕様とルールの管理が一元的に管理できるようになっています。また、Git を利用するため変更履歴の確認が容易になっています。</p>
<h2>Google Kubernetes Engine で実行</h2>
<p>作成したスキャンアプリケーションは Docker Image としてビルドしたあと Google Kubernetes Engine で実行しています。Docker Image にはルールの YAML も含めて実行に必要な一式がすべて含まれているので再利用が容易になっています。通常、このアプリケーションを CronJob として実行することで定常的な品質チェックに利用しています。</p>
<p>現時点ではチェックアプリケーションは GKE で動作させていますが、Cloud Run などのよりマネージドな環境で動作させることも可能です。また、ルールの更新（コミット＆プッシュ）と、そのデプロイは分離されているため検証環境での検証も容易になっています。</p>
<p>プレイドでは GKE 上で使えるワークフローツールを利用してパイプラインを構築しています。作成したスキャンアプリケーションはこのパイプラインとも連携可能です。こうすることで特定のジョブワークフローの最後にスキャンを実行し、パイプライン実行の結果に対する品質をすぐにチェックすることもできます。</p>
<h2>モニタリングツール</h2>
<p>実行アプリケーションを独自に実行したことで、外部のモニタリングツールと連携することが可能です。プレイドでは横断的なモニタリングツールとして Datadog を用いています。Datadog にすべての結果を送ることは現実的ではないため、結果の一部をカスタムメトリクスとして送信してモニタリングに利用しています。</p>
<h1>成果</h1>
<h2>データ品質の導入</h2>
<p>既存のデータパイプラインを変更せずにデータ品質を観測するための仕組みを導入することができました。これに伴ってデータに対する要求を明確にし YAML 形式で表すことができました。評価軸がきちんと明確になったことでデータ品質に対する精度が高まりました。また、スコアリング値によって以前よりもより品質をより詳細に把握できるようになったことも大きな利点です。</p>
<h2>観測可能性の向上</h2>
<p>品質チェックを定常的で統一的に実行できるようになりました。スキャン結果は Google コンソールや Datadog 上で確認できるようになっています。このような定常的で統一した仕組みがあることでチームでの品質のコミュニケーションが円滑になっています。</p>
<p>また、データ品質の劣化を検知できるようになりました。その結果、問題が発生する前にアクションをとれるようになっています。実際にいくつかのテーブルで品質の劣化は検知することができアクションをとることができました。このように、間違いなく観測可能性が高まりました。</p>
<h2>スケーラブルな仕組み</h2>
<p>これまでばらばらだったデータのチェックの仕組みを統一的な仕組みに変更し、プロダクトの種類が増えた場合にも対応できるようなスケーラブルな仕組みになりました。統一された仕組みを活用することで、チェックの導入コストを大幅に削減し、チェックに一貫性が生まれています。新しい品質チェックの導入と運用の負荷を大幅に削減することができましたし、ルールを作るときは YAML ファイルを作るだけですむため開発者体験も向上しています。</p>
<h1>まとめ</h1>
<p>今回は Google Cloud Dataplex の自動データ品質を用いて、データ品質管理の仕組みを構築しました。Dataplex を活用することで既存のデータパイプラインに影響を与えることなく、アドインの形でデータ品質を測定し、品質改善の仕組みを整えることができました。この仕組みによって、データに対する一貫した品質チェックが可能となり、異常検知・品質の劣化への迅速な対応によって信頼性を向上させることができました。</p>
<p>今後もこうした取り組みをさらに加速させ、プレイドが提供するデータへの信頼を着実に高めるとともに、データによる価値を最大化するように取り組んでいきます。</p>


この記事では Google Cloud Dataplex の自動データ品質（Auto Data Quality）機能を使ったデータ品質向上の取り組みについてご紹介します。

Google Cloud Dataplex を使ったデータ品質の向上

Rollupのビルド時間を10倍高速化することでプレビュー表示を改善した話

プレイドインターン体験記：インターンを通じて得た技術力と開発力の学び

<h1>はじめに</h1>
<p>この記事は <a href="https://qiita.com/advent-calendar/2024/datadog">Datadog Advent Calendar 2024</a> の 18 日目の記事です。<br>
こんにちは、プレイドの Developer Experience &amp; Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は <a href="https://docs.datadoghq.com/continuous_integration/">CI Visibility</a> と <a href="https://docs.datadoghq.com/dashboards/widgets/split_graph/">Split Graph</a> です。</p>
<p>Datadog の CI Visibility は CI のパフォーマンスを可視化できるプロダクトです。 GitHub Actions や CircleCI など多くのインテグレーションがサポートされていますが、GCP の CloudBuild はサポートされていません。また、CloudBuild には継続的にパフォーマンスを可視化できるような機能がありません。</p>
<p>そこで、CloudBuild のパフォーマンスを <a href="https://docs.datadoghq.com/api/latest/ci-visibility-pipelines/">CI Visibility の API</a> を活用して計測することにしました。</p>
<h1>CI Visibility とは</h1>
<p>CI Pipeline のパフォーマンスを可視化します。APM のように、Pipeline トレースを可視化できるところが大きな利点だと思っていて、他にもさまざまな機能がサポートされています。サポートされる機能は、プロバイダごとに異なり、<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#supported-features">こちら</a>で確認することができます。弊社では主に GitHub Actions と CircleCI を利用していますが、GitHub Actions では Step spans や Queue time、Infrastructure metric correlation がサポートされているのに対して、CircleCI ではそれらがサポートされておらず、ボトルネックの特定が難しかったりします。GitHub Actions や CircleCI 自体にもこのような Insight の機能は備わっているのですが、Datadog では使い慣れたクエリで柔軟に集計したり、Dashboard や Monitor との連携もできるので、なるべく Datadog を使うようにしています。</p>
<p>ちなみに CloudBuild は Integration はサポートされていないので OTHER CI PROVIDER というところに書いてある機能が使えます。</p>
<h1>CI Visibility Event の Level について</h1>
<p>CI Visibility には Event という形でデータを送ります。Event には Pipeline, Stage, Job, Step の4段階の Level があります。</p>
<p>Pipeline は Stage をまとめたもの、Stage は Job をまとめたもの、Job は Step をまとめたもの、というように階層構造になっています。<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#terminology">こちら</a>にプロバイダごとの対応づけが書かれています。例えば GitHub Actions であれば下記の対応になります。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>GitHub Actions</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Workflow</td>
</tr>
<tr>
<td>Job</td>
<td>Job</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>CloudBuild のパフォーマンスを可視化するにあたっては、下記のように Level を対応づけました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>CloudBuild</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Build</td>
</tr>
<tr>
<td>Stage</td>
<td>キューに格納・ソースの取得・全てのビルドステップ・（ある場合は）イメージの PUSHの4つのステージ</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>Pipeline や Step に関しては議論の余地はあまりなさそうです。Stage という単位は別に使わなくても良いのですが、実際に可視化してみると最初の Step が実行されるまでにかなり時間がかかっていて、その内訳も知れた方が良いと感じたので導入しました。</p>
<p>また、階層構造さえあっていれば可視化はできるので、Stage ではなく Job としてこれらを表現してもよかったのですが、CircleCI や GitHub Actions における Job とはかなり別物という感覚があったので Stage として表現しました。</p>
<p>CircleCI や GitHub Actions では Job は1つのコンテナ（もしくは VM）実行環境という単位になっています。そのため異なる Job 間ではボリュームの永続化などは明示的に書く必要があります。CloudBuild においては、1つの Build 内で複数の実行環境を立ち上げることはなく、前の Step で書き込まれたディスクには後続の Step でアクセスすることができます。</p>
<p>Stage がしっくりくるかというとわからないのですが、消去法で決めました。</p>
<h1>実装</h1>
<p>各所要時間をどの Level として送るかが決まったので、実装のステップに入ります。</p>
<p>CloudBuild は、実行の各タイミングで Cloud PubSub にイベントを送っています。PubSub イベントをトリガーに Cloud Run Functions を実行することができるので、今回は Cloud Run Functions で実行することにしました。他の方法としては、定期実行して特定の期間内に実行された CI Pipeline の結果を送るというやり方もありそうですが、パフォーマンス改善タスクに取り組む際にはなるべく早く結果が可視化できた方が良いというのもあり、上記の手法にしました。</p>
<h2>Queue Time</h2>
<p>Queue Time は startTime から createTime を差し引いた時間としています。また、Pipeline の attribute にも queueTime がありますが、GitHub Actions のような良い感じの可視化がされなかったので、Stage としても実装しました。</p>
<p>GitHub Actions の Queue time の良い感じの可視化:<br>
<img src="https://ik.imagekit.io/plaid/97e233cd-f4e8-4928-8c08-220bed39e581/github-actions-queue.png" alt="github-actions-queue.png"></p>
<h2>Status</h2>
<p>Cloud Build における Status と、CI Visibility Pipeline で定義されている Status はちょっと違うので、注意が必要です。</p>
<p>Ci Visibility Pipeline で定義されている status は下記になります。</p>
<table>
<thead>
<tr>
<th>Level</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>Step</td>
<td>success, error</td>
</tr>
<tr>
<td>Stage, Job</td>
<td>success, error, canceled, skipped</td>
</tr>
<tr>
<td>Pipeline</td>
<td>success, error, canceled, skipped, blocked, running</td>
</tr>
</tbody>
</table>
<p>Cloud Build の場合、 <code>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED, EXPIRED</code> があります。</p>
<p>今回のユースケースとしては実行中の Pipeline に関しては対象外としても良いかなと思ったので、完了後のステータス（ <code>SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED</code> ）のイベントが来た時だけ処理を実行するようにしました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>Cloud Build</th>
</tr>
</thead>
<tbody>
<tr>
<td>success</td>
<td>SUCCESS</td>
</tr>
<tr>
<td>error</td>
<td>FAILURE, INTERNAL_ERROR, TIMEOUT</td>
</tr>
<tr>
<td>canceled</td>
<td>CANCELED</td>
</tr>
<tr>
<td>処理しない</td>
<td>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, EXPIRED</td>
</tr>
</tbody>
</table>
<h2>Git</h2>
<p>CI Visibility Pipeline では git というフィールドに git repository の url や commit sha、authorEmail などを入れることができます。sha や repo url は Cloud Build のイベントに入ってるのですが、authorEmail は取り出せなかったので適当に入れました。GitHub API を叩いて commit sha から authorEmail を取得する方法もあると思いますが、実行者が気になったら commit のページに飛べば良いのでそこまでしなくても良いと判断しました。</p>
<h2>ソースコード</h2>
<p>最終的なソースコードは下記のようになります。依存ライブラリをインストールしてビルドすれば別の環境でも動くと思うので、ぜひ試してみてください。注意点としては <code>DD_API_KEY</code> と <code>DD_APP_KEY</code> を secret として Cloud Run Functions で読み込めるようにする必要があるのと、Datadog で us1 以外のリージョンを使っている場合には <code>DD_SITE</code> 環境変数を指定する必要があります。</p>
<pre><code class="language-typescript">/**
 * Cloud Build 終了後に Datadog にイベントを送る
 */

import { PubsubMessage } from '@google-cloud/pubsub/build/src/publisher';
import { google } from '@google-cloud/cloudbuild/build/protos/protos';
import { client, v2 } from '@datadog/datadog-api-client';

type Build = google.devtools.cloudbuild.v1.Build;
type Status = keyof typeof google.devtools.cloudbuild.v1.Build.Status;

export async function main(event: PubsubMessage): Promise&lt;void&gt; {
  const jsonstr = Buffer.from(event.data as string, 'base64').toString();

  const data = JSON.parse(jsonstr) as Build;

  if (!isFinishedStatus(data.status as Status)) {
    console.log('event does not meet conditions.');
    return;
  }

  // pipeline
  const { status, createTime, startTime, finishTime, id, logUrl } = data;
  const triggerName = data.substitutions['TRIGGER_NAME'];
  const commitSha = data.substitutions['COMMIT_SHA'];
  const repositoryUrl = data.substitutions['REPO_FULL_NAME'];
  const queueTime = startTime
    ? new Date(startTime as string).getTime() - new Date(createTime as string).getTime()
    : undefined;

  const configuration = client.createConfiguration();
  configuration.unstableOperations['v2.createCIAppPipelineEvent'] = true;
  const apiInstance = new v2.CIVisibilityPipelinesApi(configuration);
  const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
    body: {
      data: {
        attributes: {
          resource: {
            end: finishTime ? new Date(finishTime as string) : new Date(),
            start: new Date(createTime as string),
            name: triggerName,
            status: getDatadogPipelineStatus(status as Status),
            level: 'pipeline',
            uniqueId: id,
            url: logUrl,
            git: {
              sha: commitSha,
              repositoryUrl,
              authorEmail: 'unknown@example.com',
            },
            partialRetry: false,
            queueTime,
          },
          service: 'cloud-build',
        },
        type: 'cipipeline_resource_request',
      },
    },
  };
  const result = await apiInstance.createCIAppPipelineEvent(params);

  // stage
  const stages = Object.entries(data.timing).map(([key, timing]) =&gt; {
    return {
      id: key,
      startTime: timing.startTime,
      endTime: timing.endTime,
    };
  });

  const stagesIncludeQueueTime = [
    ...stages,
    {
      id: 'QUEUE',
      startTime: createTime,
      endTime: startTime,
    },
  ];

  for (const stage of stagesIncludeQueueTime) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: stage.endTime ? new Date(stage.endTime as string) : new Date(),
              start: new Date(stage.startTime as string),
              name: stage.id,
              status: 'success',
              level: 'stage',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              id: stage.id,
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // step
  for (const step of data.steps) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: step.timing?.endTime ? new Date(step.timing.endTime as string) : new Date(),
              start: new Date(step.timing!.startTime as string),
              name: step.id!,
              status: getDatadogStepStatus(step.status as Status),
              level: 'step',
              id: step.id!,
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'BUILD',
              stageName: 'BUILD',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // image
  for (const image of data.results?.images ?? []) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: image.pushTiming?.endTime ? new Date(image.pushTiming.endTime as string) : new Date(),
              start: new Date(image.pushTiming!.startTime as string),
              name: image.name!,
              id: image.name!,
              status: 'success',
              level: 'step',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'PUSH',
              stageName: 'PUSH',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }
}

function isFinishedStatus(status: Status): boolean {
  return ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT', 'CANCELLED'].includes(status);
}

function getDatadogPipelineStatus(status: Status): 'success' | 'error' | 'canceled' {
  if (status === 'SUCCESS') {
    return 'success';
  } else if (status === 'CANCELLED') {
    return 'canceled';
  } else {
    return 'error';
  }
}

function getDatadogStepStatus(status: Status): 'success' | 'error' {
  if (status === 'SUCCESS') {
    return 'success';
  } else {
    return 'error';
  }
}

</code></pre>
<h1>Datadog CI Visibility でみてみる</h1>
<p>こんな感じで Cloud Build のパフォーマンスを可視化することができました。Critical Path を特定し、最もボトルネックになっている step を効率的に改善することができるようになりました！</p>
<p><img src="https://ik.imagekit.io/plaid/56474a37-da8b-423f-bbf9-965d86aee2c3/datadog-ci-visibility.png" alt="datadog-ci-visibility.png"></p>
<p>具体的な改善ポイントとしては下記のようなものがありそうです。Stage を可視化することで、よりパフォーマンス改善の選択肢が増えると思います。</p>
<table>
<thead>
<tr>
<th>時間がかかっている Stage</th>
<th>改善手段の例</th>
</tr>
</thead>
<tbody>
<tr>
<td>QUEUE</td>
<td>Cloud Build の同時実行数を増やす、Private Pool を使う</td>
</tr>
<tr>
<td>FETCH_SOURCE</td>
<td>リポジトリを分割する</td>
</tr>
<tr>
<td>BUILD</td>
<td>キャッシュを使う、並列化する</td>
</tr>
<tr>
<td>PUSH</td>
<td>イメージサイズを小さくする、Artifact Registry と Cloud Build の実行のリージョンを合わせる</td>
</tr>
</tbody>
</table>
<h1>最後に</h1>
<p>Cloud Build のパフォーマンスを Datadog CI Visibility で可視化する方法を紹介しました。</p>
<p>Datadog は各種 Integration 対応が充実していると思いますが、未対応であってもこんな感じで提供されてる API を使って気軽に実装できるのが嬉しいところです。</p>
<p>Cloud Build と Datadog を使っていて、パフォーマンスの改善をしたいと考えている方がいたら参考にしていただけると幸いです！</p>


この記事は Datadog Advent Calendar 2024 の 18 日目の記事です。 こんにちは、プレイドの Developer Experience & Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は CI Visibility と Split Graphです。

Datadog CI Visibility で Cloud Build のパフォーマンスを可視化する

プレイドでエンジニアをしている塩澤です。今回は MongoDB から BigQuery へのリアルタイムレプリケーションシステムをマネージドサービスのみを用いて開発したので紹介します。

MongoDB to BigQuery: フルマネージドなリアルタイムレプリケーションの実現

<h1>はじめに</h1>
<p>初めまして、<a href="https://github.com/jdkfx">田添春樹</a>と申します。2024年9月から12月までの3ヶ月間、KARTE Webチームでエンジニアとしてインターンシップを行なっておりました。</p>
<p>インターンシップに参加する以前、趣味で関わっていたOSSプロジェクトにおいて、Vueを用いた開発を行なっておりました。その際の開発経験が楽しかったことと、これからもVueを用いて開発を行いたいことなどを、プレイドに勤務している親友と話した際に、このインターンシップに誘っていただきました。</p>
<p>私はどちらかと言えば、縁の下の力持ちとして物事に取り組むことが多く、開発においても、開発者が今後の開発をストレスなく、より良い環境で行えるようにリファクタリングなどを行なってきました。面談の際に、その旨を伝え、インターンシップとして開発体験を向上させるための業務をすることとなりました。</p>
<p>このインターンシップで行った内容は以下のようになっております。</p>
<ul>
<li>KARTEのエレメントビルダーのViteバージョンアップ</li>
<li>KARTEのユーザーリストや行動チェーン、ユーザーストーリーといった機能（以下、これらの機能をまとめてinsight-frontと呼称します。）における、開発体験向上を目的としたViteへの移行と、Vueのバージョンアップやそれらに伴う依存パッケージのバージョンアップ</li>
</ul>
<p>本記事ではインターンシップで行ってきたことの内容について、上記の二点をお伝えします。</p>
<h1>エレメントビルダーのViteバージョンアップ</h1>
<h2>課題</h2>
<p>KARTEの<a href="https://support.karte.io/post/67aMq2qoqXQMw6WaDL22Vl">エレメントビルダー</a>は、顧客⼀⼈ひとりに合わせて、最適なコミュニケーションができるように、顧客の行動に基づいてポップアップ表示などのアクションを作成・カスタマイズできる機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/f1201e44-6886-48d6-ba49-83231770813a/action-editor.png" alt="action-editor.png"></p>
<p>しかし、これまでのエレメントビルダーには以下のような課題がありました。</p>
<ul>
<li>開発環境がメンテナンスされていないため、ここ最近のフロントエンド環境と乖離が生じてきて、開発しにくい状況になってきていた</li>
<li>Viteのバージョンが古いため、KARTEのデザインシステムの導入に特別な対応が必要になる</li>
</ul>
<p>特に、一点目の課題が大きく、これまでのエレメントビルダーの開発環境におけるViteやVitestなどのパッケージはエレメントビルダーが開発されていた当時の状態のままになっておりました。これまでの開発環境のままでも開発はすることができますが、フロントエンド周りの環境は日々変わっていきます。今後新たな機能を実装する際、または新たなパッケージを導入する際、開発環境の遅れによって、それらの新しい機能の実装やパッケージの導入により多くの時間をかけてしまうことになります。</p>
<p>これらの課題を解決するために、エレメントビルダーのViteのバージョンを上げることになりました。</p>
<p>これまでエレメントビルダーで使用していたViteのバージョンは<code>3.2.5</code>で、今回のバージョンアップで<code>4.5.3</code>になりました。これまで使用していたVite 3系から一気にViteの最新バージョンへ上げるのではなく、小さくアップデートを行いたかったため、今回は4系へアップデートしました。</p>
<p><a href="https://v4.vite.dev/">https://v4.vite.dev/</a></p>
<p>また、それに伴って、Vitestのバージョンも上げることとなり、<code>0.24.3</code>から<code>0.34.6</code>にアップデートしました。</p>
<p>これまで使用していたVitest 0系から1系に上げるには、Vite 5系が必要となっており、先述のVite 4系を使う方針のために、1系ではなく0系の最新バージョンへアップデートしました。</p>
<p><a href="https://v0.vitest.dev/">https://v0.vitest.dev/</a></p>
<h2>テストが動かない</h2>
<p>ViteとVitestのバージョンアップを行ったことで、テストが動かなくなってしまったため、関連するパッケージのバージョンアップも行っていきました。</p>
<p>エレメントビルダーは細分化されたモジュールで作られており、それぞれに対応するパッケージの管理が複雑になっています。バージョンを上げたパッケージが他のパッケージのバージョンをサポートしていないことや、メンテナンスされていないパッケージを使用していることなど、複数の要因でテストが動かなくなってしまいました。</p>
<p>たとえば、<code>@testing-library/react-hooks</code>というパッケージでは、React 18で<code>renderHook</code>APIが<code>react-testing-library</code>と<code>react-native-testing-library</code>の両方に追加されたことにより、<code>@testing-library/react-hooks</code>を<code>@testing-library/react</code>に書き換える必要があります。</p>
<p><a href="https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support">https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support</a></p>
<p>他にも、<code>@sveltejs/vite-plugin-svelte</code>というパッケージにおいて、Vitest は基本的に<code>node_modules</code>配下にあるモジュールは<code>alias</code>で設定していなくても、モジュール依存を解決してくれるのですが、テスト内でコンポーネントをレンダーした際に<code>onMount</code>が実行されないというバグを解決するために、以下のように明示的に設定しないといけませんでした。</p>
<pre><code class="language-js">import { defineConfig } from 'vitest/config';
import { svelte } from '@sveltejs/vite-plugin-svelte';
import { dirname, resolve } from 'node:path';

export default defineConfig({
  // ...
  resolve: process.env.TEST ? {
    alias: [{
      find: /^svelte$/,
      replacement: resolve(__dirname, &quot;node_modules/svelte/index.mjs&quot;) 
     }]
  } : {
    alias: {
      '@plaidev/karte-action-sdk/templates': resolve(__dirname, './src/templates.ts'),
    },
  },
  // ...
});
</code></pre>
<p><a href="https://github.com/testing-library/svelte-testing-library/issues/222">https://github.com/testing-library/svelte-testing-library/issues/222</a></p>
<p><a href="https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components">https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components</a></p>
<h2>小さく解決する</h2>
<p>先述の通り、エレメントビルダーは細分化されたモジュールで作られており、それぞれにテストが用意されています。（以下は一部抜粋）</p>
<pre><code class="language-text">.
├── api
├── asset-builder
├── core
│   ├── action-compiler
│   ├── action-sdk
│   └── action-utils
├── front
└── internal
</code></pre>
<p>これらのテストのほとんどが動かなくなってしまったので、それぞれのモジュールごとに小さくテストが通るよう修正を行い、最終的に全てのテストが通るようにパッケージのバージョンアップやパッケージの置き換えを行いました。</p>
<p>パッケージのバージョンアップを行った結果、パッケージの破壊的変更によってテストコードの修正を行う必要がありました。修正を行うためには、どこに問題があるのか探す必要があり、使用しているパッケージのソースコードを実際に動かしてみて、意図的にエラーを発生させ、エレメントビルダーのテストにおける問題のある箇所を発見することができました。</p>
<h1>insight-front開発体験改善</h1>
<h2>課題</h2>
<p>insight-frontを開発する際、他のシステムからイベントを飛ばしてデータを作る必要があり、フロントエンドのデバッグに時間を要するという課題がありました。</p>
<p><img src="https://ik.imagekit.io/plaid/a1d7ef2d-33b6-475a-b520-5a8df50adac6/insight-front.png" alt="insight-front.png"></p>
<p>この部分の課題を解決することで、今後新たな機能を開発する際や修正を行う際に素早く対応できるため、これまで使用されていたWebpackからViteへ移行することになりました。</p>
<p>Viteに移行することによって具体的にどんな点がより良くなるのかというと、開発サーバーの立ち上がりがWebpackよりも早くなるのでデバッグに要する時間が少なくなります。</p>
<p><a href="https://vite.dev/guide/why.html#slow-server-start">https://vite.dev/guide/why.html#slow-server-start</a></p>
<h2>Vite移行に向けて</h2>
<p>WebpackからViteへ移行するために、以下のような手順を踏んでいきます。</p>
<h3>Vue 2.7へアップデート</h3>
<p>insight-frontはVue 2で開発されており、ViteではVueアプリケーションのバンドルをするために、Vueの単一ファイルコンポーネントのサポートを提供している<code>@vitejs/plugin-vue2</code>を導入する必要があります。</p>
<p>insight-frontで使用されていたVueのバージョンは<code>2.6.12</code>だったため、<code>@vitejs/plugin-vue2</code>が要求するVue 2の最新バージョンであるVue 2.7へアップデートする必要がありました。</p>
<p>また、Vue 2はすでにサポートが終了しているため、セキュリティパッチを当てたVue 2を使用しています。</p>
<p><a href="https://v2.vuejs.org/v2/guide/migration-vue-2-7.html">https://v2.vuejs.org/v2/guide/migration-vue-2-7.html</a></p>
<h3>ES ModulesとCommonJSによるデュアルパッケージ化</h3>
<p><code>localDependencies</code>というプレイド独自の依存関係の解決機構を使用しており、ここに使用される社内の共通パッケージはCommonJSでビルドされていました。これまではWebpackを使用してバンドルしていたので、CommonJSで書かれた共通パッケージも問題なくバンドルし、アプリケーションを動作させることが出来ました。（Webpackを用いてバンドルしている場合でも、使用しているパッケージがNode.js依存である場合、手動でpolyfillを挿入するように設定する必要があります。）</p>
<p>しかし、この<code>localDependencies</code>の解決機構を使っていることにより、Viteで共通パッケージのCommonJSの依存解決ができずバンドル出来ないため、これらの共通パッケージをES ModulesとCommonJSでバンドルする必要がありました。</p>
<pre><code class="language-json">&quot;localDependencies&quot;: {
  &quot;@plaidev/xxx-common&quot;: &quot;../../../common&quot;,
  &quot;@xxx/insight-front-common&quot;: &quot;../front-common&quot;
},
</code></pre>
<p>insight-frontにおいて、<code>localDependencies</code>という解決機構で依存解決を行なっている共通パッケージ内には大量のコードが存在しており、その中からinsight-frontを動かすために必要なコードを調査する時間や、それらのコードをES ModulesとCommonJSでデュアルパッケージ化するための時間、実際にES ModulesとCommonJSでデュアルパッケージ化した後に、関連するシステムが動くかどうか確認するための時間など、多くの時間を費やすことになるだろうと予想しました。</p>
<p>ES ModulesとCommonJSによる共通パッケージのデュアルパッケージ化をするには多くの時間がかかってしまうため、Viteの機能を利用してES ModulesとCommonJSでバンドル出来ないか試してみることにしました。</p>
<p><a href="https://vite.dev/config/build-options#build-lib">https://vite.dev/config/build-options#build-lib</a></p>
<h3>Viteでビルドする</h3>
<p>上記に書いた通り、insight-frontを取り巻く依存関係の問題は大きく、それらを解決するために大量に時間を要することが予想されました。また、私自身がフロントエンドについての知識がまだまだ浅く、一気にこれらを解決させようとしてどこに問題が発生しているのか調査すること自体にも多くの時間を使ってしまいました。</p>
<p>この失敗を受けて、小さく小さく課題に取り組むことを意識し、最初からアプリケーションのソースコード全体をビルドさせることは考えないようにしました。まずは、小さなHTMLファイルのビルドから行い、実際にアプリケーションを動かした際に問題がないことを確かめることから始めました。そこにVue 2で書かれた小さなコードを追加するような形で、必要なプラグインなどを細かく追加していくなど、インクリメンタルな実装を行なっていくことで自身のViteに対する解像度も上がってきました。</p>
<p>しかし、ここでインターンシップ期間が終わってしまい、insight-frontをWebpackからViteに移行することが出来ませんでした。複雑な問題が絡み合い、この課題を解くのは難しかったのですが、自身が普段のめり込むことが無いような部分にのめり込み、様々なことを学ぶことが出来ました。</p>
<h1>インターンシップを終えて</h1>
<h2>総括</h2>
<p>インターンシップとして主に二つの内容に取り組んできました。</p>
<p>開発環境をメンテナンスをしないまま、放置してしまうことにより、今後のバージョンアップで大きな障壁となってしまうことを避けるためにも、日頃からメンテナンスを怠らないようにしたいです。</p>
<p>しかし、プロダクトの開発において、メンテナンスをすることにより、本来先に実装したかった内容に遅れが生じてしまうことがあります。その実装の遅れとメンテナンスをすることによる恩恵を考えて、両方を天秤にかけ、どちらがプロダクトにより大きなインパクトを与えられるのか考え続けなければなりません。</p>
<p>そして、目の前の難しい課題に対して、直線的に解決策を取ろうとするのではなく、回り道をしつつ、小さく小さく問題を区切りながら解決に向かうことを意識していきたいです。</p>
<h2>成長</h2>
<p>これまでは、主にPHPを用いたバックエンドの開発を行なっており、フロントエンドの開発は自作のブログや先述のOSSプロジェクトの小さな機能の開発以外ではほとんど触ったことがなく、こんなにもガッツリとフロントエンドの領域にのめりこむのは初めてでした。</p>
<p>フロントエンドの技術について、あまり知識がない状態からキャッチアップを行いつつ、大きな成果を出すことが出来て、とても学びのあるインターンシップだったと感じております。</p>
<p>もちろん、一人では抱えきれない悩みや課題などが生じた際に一緒に解決してくださったメンターの方やKARTE Webチームの方々のおかげだと感じております。</p>
<p>KARTEの強みを理解し、どうすればその強みをプロダクトに機能として実装できるのか。そして、顧客に大きなインパクトを与えられるか、という思考のサイクルを止めることなくプロダクトに向き合っているプレイドの方々の姿勢に感銘を受けました。</p>
<p>そして、インターンシップを行なっていく中で自分に何が足りないのか、プロダクト開発やその会社に属する人間としてどんな視点を持てば良いのか、深く考えることのできたインターンシップでした。</p>
<h2>最後に</h2>
<p>インターンシップ期間中は広島からフルリモートでの勤務をしていました。フルリモートでなかなか顔を合わせてお話しする機会がない中、広島から東京のオフィスに出社した際には、他のインターンシップ生とのランチに誘っていただいたり、多くの方々とお話しさせていただく機会に参加させていただいたりと、社内の雰囲気もとても良かったです。</p>
<p>3ヶ月という短い間でしたが、メンターの方やKARTE Webチームの方々など、多くの方々のおかげで濃密な3ヶ月を過ごすことが出来ました。本当にありがとうございました。</p>
<hr>
<p>プレイドでは開発インターンを募集しています。興味のある方はぜひ下記のリンクからご応募ください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドインターン体験記：開発体験の向上を目指し行なったこと