Engineer Blog

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

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

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
<p>こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。</p>
<p>今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。</p>
<h1>KARTE Messageについて</h1>
<p>本題に入る前に、まずKARTE Messageについて説明します。</p>
<p>KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。</p>
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
<p>これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。</p>
<p>* LINEとの連携機能は現状β版として提供しています。</p>
<h1>このブログで出てくる用語</h1>
<p>まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。</p>
<p><code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。</p>
<p><code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。</p>
<p><code>トランザクションメール</code> :  受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。</p>
<p><code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。</p>
<p><code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。</p>
<p><code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。</p>
<p><code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。</p>
<p><code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。</p>
<p><code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。</p>
<p><code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。</p>
<h1>大量メール配信の運用における課題</h1>
<p>マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。</p>
<p>そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。</p>
<p>メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。</p>
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
<p>上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。</p>
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
<p>ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。</p>
<h2>AWS SESを利用したマルチテナント構成</h2>
<p>大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。</p>
<p>そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。</p>
<p><img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png"></p>
<p>KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。</p>
<p><img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png"></p>
<p>結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。</p>
<p>また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。</p>
<p>こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。</p>
<h2>まとめ</h2>
<p>マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。</p>
<p>KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。</p>
<p>興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

<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 を使ったデータ品質の向上

Engineer Blog

Recent Article