Engineer Blog

Takahiro Hayashi

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

<p>プレイドが提供するKARTEでは、エンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。データベースの裏側を支えるデータ構造も多種多様で、それらを正しく理解し活用していくことは分析サービスを提供する上で非常に重要です。</p>
<p>この記事ではBitmap Indexにフォーカスし、ナイーブなBitmap IndexとRoaring BitmapやBit-Sliced Indexについて解説します。</p>
<p>弊社の記事で手前味噌ですが、分析向けデータベースの技術全般については以下の記事も非常に参考になるのでオススメです。<br>
<a href="https://tech.plaid.co.jp/fundamentals_of_olap_db_technology">OLAP DBの技術要素の基礎</a></p>
<h2>ナイーブなBitmap Index</h2>
<p>最も基本的なBitmap Indexは、カラム内の特定の値ごとに一つのビットマップを持つ構造です。このビットマップでは、各ビットがテーブル内の一つの行（行番号）に対応します。その値を持つ行であればビットを1、持たなければ0とします。</p>
<p>例えば商品テーブルに「商品カテゴリ」というカラムがあり、以下のデータが入っているとします。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>商品カテゴリ</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>トップス</td>
</tr>
<tr>
<td>1</td>
<td>トップス</td>
</tr>
<tr>
<td>2</td>
<td>トップス</td>
</tr>
<tr>
<td>3</td>
<td>ボトムス</td>
</tr>
<tr>
<td>4</td>
<td>ボトムス</td>
</tr>
</tbody>
</table>
<p>この商品カテゴリカラムに対してBitmap Indexを作成すると、以下のようになります。</p>
<ul>
<li>トップス: <code>11100</code> (0, 1, 2番目の行がトップス)</li>
<li>ボトムス: <code>00011</code> (3, 4番目の行がボトムス)</li>
</ul>
<p>最大の利点はANDやORをBit演算で高速に計算できることです。<br>
例えば、「トップスまたはボトムスの商品を抽出する」場合、<code>11100</code> OR <code>00011</code> = <code>11111</code><br>
となり、全ての行が該当することが分かります。</p>
<p>また、該当するエントリ数の算出はpopcntでできてしまいます。</p>
<p>主な弱点は以下です。</p>
<ul>
<li>サイズが大きくなりやすい
<ul>
<li>カーディナリティ(カラム内のユニークな値の数)の分ビットマップを持たなければならず、特にカーディナリティが高い時に大きくなります。</li>
<li>値がスパースな時に非効率です。例えば100万行の商品テーブルで「虹色」の商品が1つだけある場合、「虹色」のビットマップは「00...010...00」のようにほとんどが0で占められます。これなら、単に対応する行番号のリスト（例：<code>[2500]</code>）で持つ方がはるかにコンパクトです。</li>
<li>(基本的にはカーディナリティが高いカラムはスパースな値が多いです。多値型の場合はその限りではありませんが)</li>
</ul>
</li>
<li>範囲検索が非効率
<ul>
<li>例えば商品価格のような値に対してBitmap Indexをそのまま使って「1000円以上の商品」を検索する場合、1000円、1001円、1002円… といった個別の価格に対応する全てのビットマップを取得し、ORを取らなければなりません。</li>
</ul>
</li>
</ul>
<h2>Roaring Bitmap</h2>
<p>Bitmapの良さを活かしつつ弱点を克服するためのフォーマットがいくつかあります。有名なものがWAH (Word Aligned Hybrid), Concise Bitmap, そしてRoaring Bitmapです。<br>
雑にまとめるとどの手法も、決まった方針でBitmapを分割して、1と0が満遍なく混在するパーツは純粋なBitmapとして扱いつつ、スパースなパーツは行IDのリストやRun-Length Encodingで保持する、という仕組みです。</p>
<p>OLAP分野だとRoaring Bitmapが特に人気なようで、IndexにはRoaring Bitmapが優先されることが多いと思います。以下はRoaring Bitmapについて説明します。</p>
<h3><strong>Roaring Bitmapの仕組み</strong></h3>
<p>Roaring Bitmapでは、Bitmapを最大65,536(2^16)個の要素で構成されるコンテナに分けます。コンテナはBitmap / Arrayのどちらかで表現します。</p>
<ul>
<li>Bitmap: スパースではない場合、65,536ビット（8KB）のビットマップとして格納します。</li>
<li>Array: スパースな場合(デフォルトでは1が4096個以下)、要素の値を整数のソート済み配列としてそのまま格納します。</li>
</ul>
<p>(進化版ではRun-Length Encodingという3種類目のコンテナもありますが、今回は割愛します。)</p>
<p>AND/ORなどの論理演算はコンテナ単位で行われ、コンテナの組み合わせごとにアルゴリズムがあります。例えばAND演算は以下です。</p>
<ul>
<li>Bitmap vs Bitmap: 通常のビットワイズAND演算。</li>
<li>Bitmap vs Array: Array内の各要素について、Bitmapの対応するビットを確認。</li>
<li>Array vs Array: ソート済み配列同士のマージ処理に似た方法で共通要素を探索。</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ddb8044b-db50-493c-9d73-918bafb04060/%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-05-2322.50.10.png" alt="Roaring Bitmap"><br>
(int32を扱うとして、実際にはcontainerの要素には下位16bitを入れ、上位16bitはコンテナ毎に持ちます。足し合わせることで元のint32に復元できます。)</p>
<p>Arrayコンテナが関わる演算はBitmapコンテナ同士の演算と比べると非効率ですが、そもそも要素数が少ないため大して問題にならない、というのが良くできているところだと思います。また、WAHやConcise Bitmapではワード単位でBitmapかRun-lengthかを区別しますが、Roaring Bitmapでは大きい固定サイズで分けたことで、オーバヘッドが少なくなったことがポイントだと思います。</p>
<p>余談ですが、OSSのOLAP DBであるApache Druidでは、デフォルトで文字列型の全カラムに対してRoaring Bitmap Indexが作られます。大胆ですね。実際KARTEで扱うような行動データをDruidにロードして試したことがありますが、Bitmap Indexのサイズはカラムナ部分と同程度に収まり、フィルタリングもかなり早くなりました。</p>
<p>また、数値型に対して作らない理由は以下だと思います。</p>
<ul>
<li>カーディナリティが高いことが多い(年齢や会員ランクなど、反例も多そうですが)</li>
<li>固定長で値が小さいためカラムナフォーマットだけでも十分早い(SIMD / CPUキャッシュ / CPUレベルでの並列化が効きやすい)</li>
</ul>
<h2>Bit-Sliced Index</h2>
<p>Bitmap Indexの弱点に対応するフォーマットとして、Bit-Sliced Indexもあります。ざっくり言えば数値型に向いてるIndexです。(Roaring BitmapはBitmap単体のフォーマットですが、Bit-Sliced Indexはindex全体のフォーマットです。組み合わせることもできます。)</p>
<p>Bit-Sliced Indexは、カラムの値を特定の基数で分解（スライス）し、各ビット位置ごとにビットマップを作成します。</p>
<p>以下は商品価格を基数2で表現(=2進数)する例です。B[i]は2進数表現の、i bit目を意味します。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>価格</th>
<th>B[7]</th>
<th>B[6]</th>
<th>B[5]</th>
<th>B[4]</th>
<th>B[3]</th>
<th>B[2]</th>
<th>B[1]</th>
<th>B[0]</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>1</td>
<td>230</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>2</td>
<td>130</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>3</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
</tbody>
</table>
<p>Bit-Sliced Indexでは、物理的には縦方向のBitmapを持ちます。この例では行数が4で桁数が8(bit)なので、長さ4のBitmapが8個作られます。</p>
<p>ナイーブなBitmap Indexでは行番号を指し示すBitmapが値ごとに作られますが、今回は値自体もBitmapでエンコーディングするのでこんがらがりがちです。上記の表を行列と捉えて、横方向のBitmapは値自体の表現であり、縦方向のBitmapは値の特定の桁が一致する行番号を指し示すBitmapと言えます。</p>
<p>価格が最大で255円だとすると、基数2のBlit-Sliced Indexで必要なビットマップは8個です。ナイーブなBitmap Indexなら最大256個のビットマップが必要になることと比べると、大幅にサイズを抑えられることが分かります。</p>
<h3>Bit-Sliced Indexによる合計計算（基数2の場合）</h3>
<p>応用のアルゴリズムとして、Bit-Sliced Indexでカラムに含まれる値の合計値が計算できます。元々の目的である索引以外にも使えるのが面白いです。</p>
<pre><code class="language-cpp">/**
 * B: 特定カラムCのBit-Sliced Index (B[i]はi番目のビットに対応するビットマップ)
 * Bf: 条件を満たす行を示すビットマップ (Foundset)
 * num_bits: 値を表現するのに必要なビット数(横方向のBitmapのビット数)
**/
int sum = 0;
for (int i = 0; i &lt; num_bits; ++i) {
    // i番目のビットが立っている行だけを対象に、2^i を加算
    sum += 2^i * POPCOUNT(B[i] AND Bf);
}
return sum;

</code></pre>
<h3>基数</h3>
<p>ここまで基数2を例にしてきましたが、他の基数を取ることもできます。例えば基数10とすると、1000未満の整数であれば100,10,1の位の3つの10bitのスライスで表現し、位の値がNならスライスの右からN番目に1を立てます。</p>
<p>例えば230は100の位が2、10の位が3、1の位が0なので、以下のようになります。<br>
<code>0000000100</code>(100の位) <code>0000001000</code>(10の位) <code>0000000001</code>(1の位)</p>
<p>基数は単一である必要はなく、位ごとに変えることもできます。</p>
<p>基数の増減に伴うトレードオフはサイズとクエリ効率にあるようです。基数を増やすサイズは増えますが、例えば等価検索の効率が良くなることは明らかです。</p>
<h3>Encodingと検索</h3>
<p>値のBitmap(横方向)のEncodingのバリエーションとして、Equality EncodingとRange Encodingがあります。</p>
<p>Equality Encodingは値がNならN番目のbitに1を立てるもので、ここまでで説明してきた方法です。<br>
Range Encodingでは、値がNならN番目のbitとその左のbit全てに1を立てます。</p>
<p>例えば基数10で230を表現すると、100の桁が2、10の桁が3、1の桁が0ですから、以下のようになります。<br>
<code>0000000100 0000001000 0000000001</code>(Equality Encoding)<br>
<code>1111111100 1111111000 1111111111</code>(Range Encoding)</p>
<p>Range Encodingはその名の通り範囲検索に強いエンコーディングです。</p>
<p>それぞれのエンコーディングで等価検索と範囲検索のアルゴリズムがあります。複雑なので、範囲検索の大雑把な方針のみ説明します。</p>
<p><strong>Equality Encodingの範囲検索</strong><br>
例えば特定の値より大きいデータを取る場合、位だけを見て対象の値より大きいと分かる行を取るステップと、同じ位の中で対象の値より大きい行を取るステップがあります。</p>
<p>例えば基数2で <code>価格 &gt;= 5 (バイナリ: 00000101)</code> を検索する場合、以下の2つの結果の和集合が結果です。</p>
<ul>
<li>8以上255以下の行
<ul>
<li>B[7]からB[3]までのうちどれか一つでも1が立っている(ORで取得)</li>
</ul>
</li>
<li>5以上7以下の行
<ul>
<li>B[2]が立っていて、B[1]かB[0]のうちどちらか一つでも1が立ってる(ANDとORで取得)</li>
</ul>
</li>
</ul>
<p><strong>Range Encodingの範囲検索</strong><br>
特定の値より大きいデータを取る場合、その値のbitだけをチェックします。例えば基数10で値が200以上のデータを取る場合、100の位のスライスの右から1番目のbitが0である行を取得します。</p>
<h2>まとめ・感想</h2>
<p>Bitmap Indexと言えばデカいイメージがありますが、対策としていろいろなアイデアが提案されています。こんなにアイデアを凝らすほどAND/ORが効率的に処理できるBitmapが魅力的ということですね。</p>
<p>Roaring Bitmapに比べるとBit-Sliced Indexはそこまで流行っていないような気もします。カラムナDBであれば数値型はカラムナだけで十分早いからでしょうか。行指向のDBでは有用な気もしますが、更新が重いからかもしれません。</p>
<p>また、Bit-Sliced Indexの基数とエンコーディングについては、クエリやデータパターンに応じて選ぶのが重要な気がします。それぞれの特性・トレードオフを整理するところまでは今回は辿り着けませんでしたが、興味があれば各種論文を見てみると良いかもしれません。</p>
<h2>参考資料</h2>
<p><a href="https://dl.acm.org/doi/10.1145/253262.253268">Improved query performance with variant indexes | ACM SIGMOD Record</a><br>
<a href="https://dl.acm.org/doi/10.1145/276305.276336">Bitmap index design and evaluation | ACM SIGMOD Record</a><br>
<a href="https://arxiv.org/abs/1004.0403">[1004.0403] CONCISE: Compressed 'n' Composable Integer Set</a><br>
<a href="https://roaringbitmap.org/">Roaring Bitmaps</a></p>


いろいろなBitmap Indexの紹介

<h1>はじめに</h1>
<p>こんにちは。プレイドのKARTE Messageチームでエンジニアをしている林(<a href="https://x.com/smoothbronco">Twitter</a>)です。</p>
<p>この記事では、動的にSQLを生成する機能の実装を無事故で改善し、その後の開発スピードを向上させたことについてお話しします。</p>
<h1>KARTE Messageについて</h1>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信サービスの運用について紹介している記事</a> があるので、こちらもぜひ併せてご覧ください。</p>
<h2>配信対象抽出機能について</h2>
<p>KARTE Messageでは、SQLが書けないマーケターでもGUIベースでメールやLINEの配信対象を抽出できるための機能を提供しています。</p>
<p>配信対象はデータ統合・利活用プラットフォームである<a href="https://developers.karte.io/docs/about-datahub">KARTE Datahub</a>内のテーブルまたはクエリをベースにしており、「リスト」と呼びます。</p>
<p>リストには配信対象のメールアドレスやユーザーID、クーポンコード等のコンテンツに埋め込むデータが入っています。</p>
<p>たとえば、会員マスタのうちGOLDランクの会員にだけメールを送りたい場合は、以下のような操作で対象を絞り込むことができます。ある対象を除外する、パーソナライズした値をコンテンツに埋め込む、施策内で1ユーザーに対してx回まで配信する、といったこともこの機能で実現しています。</p>
<p>※ データはすべてダミーです。</p>
<p><img src="https://ik.imagekit.io/plaid/ab4a4133-596b-42e1-986a-164fa2a444fb/merge_list.webp" alt="merge_list.webp"></p>
<p>配信対象抽出の裏側では、クライアントの設定した値から動的にSQLを生成しています。</p>
<p>先ほどのGOLD会員の例では、以下のようなSQLを生成します。</p>
<pre><code class="language-sql">WITH result AS (
	WITH master_{list_id} AS (
		-- &quot;【デモ】マスターデータ_メール&quot;のクエリ
		SELECT * FROM demo_master_mail
	),
	subset_{list_id} AS (
		-- &quot;gold会員&quot;のクエリ
		SELECT * FROM demo_master_mail WHERE rank = 'gold'
	),
	merge_list AS (
		WITH master AS (
			SELECT * FROM master_{list_id}
		),
		subset AS (
			SELECT user_id FROM subset_{list_id}
		)
		SELECT
			master.user_id AS user_id,
			master.email AS target
		FROM master
		LEFT JOIN subset ON master.user_id = subset.user_id
		WHERE subset.user_id IS NOT NULL
	)
	-- (中略)
)
SELECT * FROM result;
</code></pre>
<p>このSQLは配信する時とクライアントが対象ユーザーをプレビューする時にKARTE Datahubのテーブルに対してクエリします。</p>
<p>対象抽出のデータ結合に用いるキーはユーザーIDか配信先 (メールアドレスやLINE ID) を使っており、ユーザーIDのカラムがある場合はユーザーIDで結合します。</p>
<p>クライアントの持っているデータによってはユーザーIDカラムのないデータもあるので、その場合は配信先のカラムで結合します。</p>
<p>また、一部のユーザーIDがnullになっていることもあります。</p>
<h2>改善前の課題</h2>
<p>たとえば以下のようなケースだと、メールアドレスが一致していても一部でuser_idがnullになっている場合はパーソナライズする値が落ちてしまいます。</p>
<p><img src="https://ik.imagekit.io/plaid/acd9c458-90cd-404f-a92d-bc3f94f36254/user_id_null.png" alt="user_id_null.png"></p>
<p>このようなケースを含め、配信対象抽出機能を改善する前は以下のような課題がありました。</p>
<ul>
<li>データに関する課題
<ul>
<li>targetやuser_idという一般的な名前が予約語になっており、クライアントの設定次第でカラム名が衝突する</li>
<li>user_idがnullableなので、対象抽出やパーソナライズする値を結合する際にレコードが落ちる場合がある</li>
</ul>
</li>
<li>ロジックに関する課題
<ul>
<li>配信時のクエリとプレビュー時のクエリを返すロジックの共通化ができておらず、出力に差分が生じてしまう</li>
<li>コードが複雑で処理の分割がうまくできておらず、キャッチアップコストが高い</li>
</ul>
</li>
</ul>
<p>配信対象抽出機能はKARTE Messageの中でもコアになる機能であることや、今後も頻繁にアップデートがかかることが想定される機能でした。この状態のまま運用していくと予期せぬバグやインシデントを起こしかねないので、機能全体に手をいれることにしました。</p>
<h2>やったこと</h2>
<p>以下2つのアプローチを取って行いました。</p>
<ol>
<li>リストの元データを view table にし、クエリするときは view table を参照する</li>
<li>既存の仕様からデータモデルを再定義し、コードをまるっと作り替える</li>
</ol>
<p>1つ目に関しては、view tableにすることでクライアントのデータに一定の前提を設けられるので、データに関する課題を解決することができると考えました。</p>
<p>2つ目に関しては、仕様が明確だったこと、既存のコードに対してテストが不十分だったことなどから、改めてデータモデルから作り替えた方がメンテナブルになるだろうと考えました。</p>
<h3>view tableにする対応について</h3>
<p>先に、viewのクエリを示します。</p>
<pre><code class="language-sql">SELECT
  *,
  cast(
    ifnull(
      cast(`user_id` as string),
      concat('null_embedded_', `email`)
    ) as string
  ) as masspush_user_id,
  cast(`mail` as string) as masspush_target,
FROM
  (
    -- リストの元データのクエリ
    SELECT
      *
    FROM
      demo_master_mail
  )
</code></pre>
<p>ポイントは2つです。</p>
<ul>
<li>予約語はクライアントが設定する可能性が限りなく低い命名にする</li>
<li>user_idがnullの時は<code>null_embedded_{配信先}</code> で埋める</li>
</ul>
<p>こうすることで、カラム名が重複することや最終的に配信対象が抜け落ちてしまうことが減りました。リストの元データのクエリは数百〜数千行になることもあるので、最終的なクエリをシンプルに保つことができるようにもなりました。</p>
<p>移行する中で難しかったのが、viewのクエリが参照するデータの鮮度を保つことです。</p>
<p>リストの中には、「先月10,000円以上購入した人」や「30分前にカゴ落ちした人」などの相対日時を条件に含むものがあります。これらは絶対日時に変換してクエリにしているので、配信やプレビューが実行される直前でviewのクエリを更新する必要がありました。</p>
<p>また、KARTE DatahubはBigQuery上にテーブルを保持しています。BigQueryのテーブル更新オペレーションは10秒で最大5つまでというクォータがあるので、都度viewを更新するのは現実的ではありません。</p>
<p>そこで、以下のような実装で更新オペレーションを極力減らすことにしました。</p>
<pre><code class="language-tsx">export const updateListViewQueryIfBaseSQLModified = async (
	baseSQL: string;
	list: List;
) =&gt; {
  const tableName = createTableName(list);
  const cachedQueryHash = await findCachedQueryHash(tableName);
  const newQueryHash = hashQuery(baseSQL);
  // 最新のqueryとcacheしたqueryのhashが一致してれば処理を終える
  if (cachedQueryHash === newQueryHash) {
    return;
  } else {
    // BigQueryに問い合わせてviewのqueryを比較する
    const isEqualBaseSQL = await compareViewToBaseSQL({
      list_id: list.id,
      baseSQL: baseSQL,
    });
    // queryが異なればviewのqueryを更新する
    if (!isEqualBaseSQL) {
      const viewQuery = buildQuery(list, baseSQL);
      await updateView(viewQuery, list.id);
    }
    // table名をkeyに、queryのhashをvalueにしたcacheを保存する
    await cacheQueryHash({ key: tableName, query: baseSQL });
  }
}
</code></pre>
<p>まず、BigQueryにリクエストする手前にcacheを挟むようにしました。同じリストを使い回して同時刻に複数個の配信を実行するクライアントは多いです。このようなケースはcacheのおかげでBigQueryへのリクエストを減らすことができました。</p>
<p>次のステップでは、BigQueryに問い合わせて最新のviewのqueryを取得し、比較するようにしました。テーブル取得のクォータは更新に比べて制約が緩いので、更新前に最終チェックをしています。</p>
<p>このようなステップを踏むことで、配信が集中する時間帯でもクォータを超えることなくviewのクエリを最新の状態に保つことができました。</p>
<h3>コードの作り替えについて</h3>
<p>コードの作り替えはTDDライクに行いました。まず仕様からテストケースを起こし、そのテストケースに従ってテストが通るようにコードを書くようにすることで、仕様の抜け漏れやエッジケースの見落としなどがないかを確認しながら進めることができました。</p>
<p>また、リリースに関してはview table対応とは別で行う、一部のテナントから段階的に行うなど、万が一問題があったときの影響範囲を最小限に抑えながら進めました。</p>
<h2>結果</h2>
<p>かなり大規模かつ問題が起きた時のリスクが大きい修正でしたが、配信に影響なくすべてリリースすることができました。</p>
<p>またこのリリース後、キャッチアップコストが大幅に減り、開発工数がより正確に見積れるようになりました。新しくチームに入ってきたエンジニアの方が新規に機能拡張をすることになった時も、キャッチアップが大変という感覚は無かったそうです。改善前に比べてテストも充実する形になったので、変更を加える際の影響範囲やエッジケースのバグ取りこぼしも見えやすくなりました。</p>
<p>課題の種類をデータとロジックに分けて、それぞれを解決するアプローチにしたことでシンプルになったと個人的には思っています。</p>
<h2>最後に</h2>
<p>私が所属するKARTE Messageチームでは、大量配信を支える配信基盤の改善や、より良いMAツールにしていくための機能開発など、まだまだやりたいことがたくさんあります。</p>
<p>少しでもこのような領域に興味を持ってくださった方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。応募待ってます！</p>


非エンジニアでも直感的に動的なSQLを生成できる、GUIのノーコードツールの改善方法の紹介

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

<p>こんにちは！プレイドでエンジニアをしている土佐といいます。</p>
<p>先日、社内で「生成AI」をテーマにしたLightning Talk（LT）会が開催されました！🎉プレイドだけでなく、グループ会社のRightTouchメンバーも集結し、総勢なんと約80名が参加する、とっても賑やかなオンラインイベントになりました。</p>
<p>ここ数ヶ月、社内でもCursorやCline、Vertex AI経由のGPTモデルなど、さまざまな生成AIツールの活用がどんどん進んできて、「お、そろそろ各チームで溜まってきた知見や『こんなことやってみた！』をシェアする良いタイミングじゃない？」ということで、今回のLT会が企画されたんです。</p>
<p>この記事では、当日の熱気や発表の面白さ、そして私たちが感じた「これから」の可能性を、少しでも皆さんにお届けできればと思います。LT会の雰囲気や学びが伝わると嬉しいです！</p>
<h2><strong>当日の熱気：オンラインでも伝わる一体感！</strong></h2>
<p>会場はオンライン。それぞれの場所から参加する形でしたが、画面越しにも伝わる熱気…！🔥 発表が始まると、みんな真剣な表情で聞き入り、Slackのスレッドも質問や感想、「なるほど！」「それ面白い！」といったコメントで、めちゃくちゃ盛り上がっていました。</p>
<h2><strong>発表ハイライト 🚀</strong></h2>
<p>今回のLT会では、本当に多種多様なテーマで10件の発表がありました。どれも興味深く、刺激的な内容ばかりでした！すべての発表をダイジェストでご紹介します。</p>
<ul>
<li><strong>「採用面談の日程調整をAIにやってもらうワークフローを構築しました」</strong>
<ul>
<li>候補者と複数面接官の複雑なカレンダー調整を、Zapier AIとDifyを駆使して自動化！ Slackから使える「Google Calendar 日程提案くん」で、面倒な調整業務をスマートに解決する実用的な工夫が光りました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://note.com/kantetsu/n/n00958cea908d">https://note.com/kantetsu/n/n00958cea908d</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「お客さんの商品データを検索するMCPサーバー作ってみた」</strong>
<ul>
<li>通常のキーワード検索だけでなく、ベクトル検索で&quot;似ている商品&quot;も提案できるAPIサーバーを自作。ユーザーの「見つからない…」を減らす、既存技術を組み合わせた価値創造の好例でした。</li>
</ul>
</li>
<li><strong>「Cline + ChatGPT 4o 画像生成を使ったOSS開発をしてみた」</strong>
<ul>
<li>自作OSS「Gunshi」の開発で、Clineによるコーディング支援やドキュメント生成、ChatGPT 4oによるロゴ・OGP画像作成までAIを活用！ 開発プロセス全体でのAI活用スタイルが新鮮でした。</li>
<li><a href="https://gunshi.dev/">https://gunshi.dev/</a></li>
</ul>
</li>
<li><strong>「生成AIにサポートサイトドキュメントを書かせて公開してみた」</strong>
<ul>
<li>Cursor等のAIツールを使い、コードベースからサポートサイトのドキュメントを効率的に生成・公開。人間には手間のかかる表作成などもAIに任せる、実践的なノウハウが共有されました。</li>
</ul>
</li>
<li><strong>「ボランティアのイベント告知サイトの更新をClineを使ってほぼ自動化した件」</strong>
<ul>
<li>ボランティアで運営するWordPressサイトの更新作業を、Cline、RPA、ChatGPT生成HTMLで見事に自動化！ Gutenberg記法を活用することで、ビジュアルエディタとの互換性を持たせる工夫を行い、大幅な効率アップを実現した、技術による社会貢献の素敵な事例でした。</li>
</ul>
</li>
<li><strong>「AI開発基盤を作ってみた」</strong>
<ul>
<li>AI機能をより簡単に開発できる基盤を開発中。AIエージェント開発の知見集約や再利用性を高める土台作りのお話にワクワクしました。</li>
</ul>
</li>
<li><strong>「code-bugsというCLIツールを作った」</strong>
<ul>
<li>複数ファイルにまたがる定型的なコード修正を、AIが自動で行ってくれるCLIツール「code-bugs」を開発。簡単なレシピで面倒な作業を効率化する、開発者の頼もしい味方になりそうです！</li>
</ul>
</li>
<li><strong>「AI Agentにセキュリティレビューをやってもらう」</strong>
<ul>
<li>Copilot AgentやCursorにセキュリティルールを学習させ、コードレビューを補助させる試み。AIをセキュリティチェックの「心強い相棒」として活用する可能性が示されました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://tech.plaid.co.jp/security-review-by-ai-agent-101">https://tech.plaid.co.jp/security-review-by-ai-agent-101</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「誰でもできるvibe-coding」</strong>
<ul>
<li>エンジニア以外の職種の方がAIで機能を実装！顧客解像度の高い人が直接開発できる可能性と、レビュー負荷軽減のためのプロセス改善（仕様レビュー、PR分割）というリアルな試行錯誤が共有されました。</li>
</ul>
</li>
<li><strong>「Codatumで組織サーベイの分析にLLMによる要約を埋め込んでみた」</strong>
<ul>
<li>BigQueryとVertex AIを連携し、SQL関数 <code>ML.GENERATE_TEXT</code> を活用して従業員サーベイの大量の自由記述回答をグループ別に要約。SQLだけで高度なテキスト分析を実現するパワフルな活用事例でした。</li>
<li>Codatumとは
<ul>
<li><a href="https://codatum.jp/">https://codatum.jp/</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2><strong>LT会を終えて：見えてきた景色と、これからの私たち</strong></h2>
<p>本当に刺激的なLT会でした！</p>
<p>個人的に最も印象的だったのは、「誰でもできるvibe-coding」の発表です。プロダクトやお客様に一番近いメンバーが、AIを使って直接価値を生み出せる。これって、開発のあり方やスピード感を根本から変える可能性を秘めていると感じました。</p>
<p>もちろん、「じゃあ、私たちソフトウェアエンジニアの価値ってどこにあるんだっけ？」という問いも同時に生まれます。AIがコードを書けるようになった今、私たちはより本質的な課題解決や、アーキテクチャ設計、そしてAIを最大限に活用するための環境構築といった領域で、さらに価値を発揮していく必要があるのかもしれません。今回のLT会は、そんなことを考える素晴らしいきっかけになりました。</p>
<p>プレイドでは、**「技術はトレンドを追うためではなく、長期的なインパクトと組織的な再現性を生み出す原動力である」**と考えています。今回のLT会で見られた多様なチャレンジは、まさにその思想を現場レベルで体現しているように感じました。</p>
<p>単に「生成AIが流行っているから使う」のではなく、「<strong>どうすれば顧客への価値提供や、私たちの働き方を本質的に良くできるか？</strong>」という視点で、みんなが主体的にAIと向き合い、試行錯誤を楽しんでいることがわかったイベントでした。</p>
<p>参考</p>
<p><a href="https://blog.plaid.co.jp/n/nb08d947606f3">https://blog.plaid.co.jp/n/nb08d947606f3</a></p>
<h2><strong>おわりに：<strong>プレイド</strong>のAI環境</strong></h2>
<p>実は、あまり大々的には言っていませんが、プレイドでは、エンジニアは <strong>Cursor、Cline、Vertex AI経由の各種モデルといった生成AIツールを、かなり自由に試せる環境</strong>が整っています。これ、個人的にはものすごい「福利厚生」だなと思っていて…（だって、個人で契約したら、日に数万円かかることもありますからね！）</p>
<p><strong>「生産性のための環境投資は死ぬほど安い」</strong> というのがプレイドのエンジニアのマインドセットの一つ。セキュリティには最大限配慮しつつも、これからも価値創出につながる新しい技術は積極的に取り入れていくんだろうな、と感じています。</p>
<p>そんなプレイドでは、一緒に未来のプロダクトを作るソフトウェアエンジニアを絶賛募集中です！</p>
<p>今回のLT会のような、技術への探求心や「やってみよう！」の精神を大切にする環境に興味のある方は、ぜひ採用ページを覗いてみてくださいね。</p>
<p>👉 <strong>プレイド採用ページ：</strong> <a href="https://recruit.plaid.co.jp/product">https://recruit.plaid.co.jp/product</a></p>
<p>最後まで読んでいただき、ありがとうございました！</p>
<p>P.S. このブログ記事も、実はGoogle MeetのGemini議事録とGemini 2.5 Proの力を借りて、構成案から執筆までサポートしてもらいました！</p>


プレイド社内で開催された生成AIのLT会レポート。グループ会社RightTouchも参加し、CursorやVertex AI経由GPT等の活用事例や開発知見を共有。当日の発表をサマリでお伝えします

生成AI、どう使う？ プレイド社内LT会で活用のヒントを探ってみた！

文字やアイコンのコントラスト比、focusしたときに表示されないツールチップ、重複する代替テキスト、「アクセシブルな名前」のないリンク、ターゲット領域を広げるための重複するリンク。これらの問題と解決策、その背景にある考え方についての解説。

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説

アクセシビリティの概念的な理解から、取り組むべき理由、ガイドライン、実践方法、その学び方など、幅広いテーマについての概説と、それら各論の参考資料の紹介。

アクセシビリティ学習の手引きとしての入門講座

OLAPデータベースにおける高速化の技術 - PLAID engineer blog

OLAPデータベースにおける高速化の技術

<p>こんにちは、プレイドでCore Platform開発の責任者をしているエンジニアのkusappeです。</p>
<p>プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてブログ化しました。<br>
この記事では、Modern Data Stackとは何か、そのメリットや特徴について解説します。また、具体的な技術要素・主要サービスや重要だと思うトレンドについても紹介します。</p>
<h2>Modern Data Stackとは？</h2>
<p>Modern Data Stackとは、データの収集、処理、分析、可視化などデータ活用に関わる機能を、それぞれに特化したクラウドサービスやSaaSツールを組み合わせて構築するという考え方やその基盤のことを指します。<br>
クラウドサービスやその周辺の技術要素の進化によって、従来のデータ基盤と比べると以下のメリットがあると言われています。</p>
<ul>
<li>高いスケーラビリティや可用性を実現できる</li>
<li>SaaSを組み合わせてスピーディーにデータ基盤の環境を構築できる</li>
<li>簡単にツールを使えるようになり、誰でもデータの利活用ができる状態になる（データの民主化）</li>
</ul>
<p>そして、dbtのCEOは2020年に書いた<a href="https://www.getdbt.com/blog/future-of-the-modern-data-stack">Modern Data Stackの過去・現在・未来のブログ</a>で、「2021〜2025年にかけてさらなるイノベーションが起きるのでは？」と予測しています。<br>
データの活用をより加速させるためにも、具体的な技術要素や主要なSaaSサービスを押さえておくのはとても重要だと思います。それでは見ていきましょう。</p>
<h2>具体的な技術要素・主要なサービス</h2>
<p>個々の技術要素を説明する前に、まずはModern Data Stackの全体像（図1）を見てみましょう。今回紹介する図以外にも全体像の図はいくつかあるため、本記事末の参考資料のところに載せておきます。</p>
<p><img src="https://ik.imagekit.io/plaid/d538514d-1860-4e0c-abc1-5cb49e44b234/ModernDataStack_Overview.png" alt="ModernDataStack_Overview.png"><br>
図1. Modern Data Stack 全体像 ( https://www.moderndatastack.xyz/journal/the-modern-data-stack-ecosystem-spring-2022-edition-5qe )</p>
<p>それでは各カテゴリーと主要サービスを見ていきましょう。データの流れの観点から大きく、データ収集、データ処理、データ活用、その他（横断系）の4つに分類して解説します。</p>
<h3>データ収集</h3>
<ul>
<li>
<p>Data Warehouse<br>
Data Warehouseとは企業内の多種多様な大量データを貯め、様々な分析を行うために特化されたサービスのことです。Warehouse（倉庫）という言葉からも連想されるように、構造化されたデータを扱うイメージが強いです。画像やテキストなどの非構造化データを扱う場合は、Data Lakeという言葉が使われます。<br>
その中で一つ注目したいトレンドとして、ETLからELTへのシフト（図2）があります。<br>
Data Warehouse側の技術進化によって、まずはロードしてその後変換が簡単に実現できるようになりました。ETLと比べた場合のELTは、高速・低メンテナンス・ロードが1回で済むといった利点があります。<br>
ELTが標準になることによって、Data Warehouse内でのData Transformationの管理ニーズが高まってきました。</p>
<p><img src="https://ik.imagekit.io/plaid/10231ec1-5aa6-496b-9c56-9babf6c01ea6/ETL_ELT.png" alt="ETL_ELT.png"><br>
図2. ETLとELT ( https://aws.amazon.com/jp/compare/the-difference-between-etl-and-elt/ )</p>
</li>
<li>
<p>Data Integration<br>
様々なデータソースからデータウェアハウスにデータを集めるための連携ツール（図3）です。<br>
主要なSaaSとして、<a href="https://www.fivetran.com/">Fivetran</a> や <a href="https://airbyte.com/">Airbyte</a> があります。<br>
双方の立場から比較記事が出ているので興味ある方は見てみてください。</p>
<ul>
<li><a href="https://airbyte.com/etl-tools/fivetran-alternative-airbyte">Airbyte側の主張 (Fivetran vs Airbyte)</a></li>
<li><a href="https://www.fivetran.com/blog/fivetran-vs-airbyte-features-pricing-services-and-more">Fivetran側の主張 (Fivetran vs Airbyte)</a></li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/7b0729d6-51e1-437a-b7e4-4c71823c364e/Data_Integration_Overview.png" alt="Data_Integration_Overview.png"><br>
図3. Data Integration ( https://www.fivetran.com/data-movement )</p>
</li>
<li>
<p>Event Tracking<br>
Websiteでのクリック情報など、ユーザーの行動情報を取得するツールのことを指します。<br>
<a href="https://segment.com/">Segment</a>や<a href="https://www.rudderstack.com/">Rudderstack</a>あたりがグローバルでも有名ですね。<a href="https://karte.io/">KARTE</a>もこのリストの仲間に入れるように頑張らなくではと思います。<br>
SegmentとRudderstackに共通する点としては、Customer Dataを軸としてそれをマーケティングに使うだけではなく、データのTransformation機能や他の業務ツールとの連携など多岐にわたって活用していることが挙げられます。</p>
</li>
</ul>
<h3>データ処理</h3>
<ul>
<li>
<p>Data Transformation<br>
Data Warehouseにロードしたデータを使いやすい形に変換するレイヤーです。<br>
Warehouse側の技術進化によってSQLでできることが増え、基本的な処理はSQLで行うのが主流になってきています。<br>
そのデータ変換用のSQLを管理するフレームワークとして、<a href="https://www.getdbt.com/">dbt</a> や <a href="https://cloud.google.com/dataform?hl=ja">Dataform</a>があります。<br>
プレイドでのdbtの活用方法は先日<a href="https://tech.plaid.co.jp/signals_connector_dbt">ブログに記載</a>したのでよかったらみてください。</p>
</li>
<li>
<p>Metric Store<br>
一言でいうと、分析の際に使う指標や数値（メトリクス）の定義を一元管理するツールです。<br>
今までは各BIツールでメトリクス定義を管理していましたが、それによって以下問題が起きていました。<br>
- レポーティングで使う数値の定義が、各チーム・各BIツールによって違っていて何が正解なのかわからない<br>
- 運用管理しようとしても、定義がBIツールごとに散らばり重複しているので管理が大変<br>
メトリクスの定義管理をBIツールとは分離し、再利用可能にするというのがコンセプトです（図4）。Headless BIとも呼ばれます。<br>
SaaSとしては、<a href="https://www.getdbt.com/product/semantic-layer">dbt（semantic layer）</a>、<a href="https://metriql.com/">Metriql</a> 、<a href="https://cube.dev/">cube</a> があります。<br>
<img src="https://ik.imagekit.io/plaid/ee409271-1c44-416c-9b5b-d8c1df2aeab6/Metric_Store.png" alt="Metric_Store.png"><br>
図4. Metric Storeのコンセプト( https://benn.substack.com/p/metrics-layer )</p>
</li>
</ul>
<h3>データ活用</h3>
<ul>
<li>
<p>Data Analytics<br>
この領域はBIツールなど、みなさんご存知だと思うので割愛します</p>
</li>
<li>
<p>Reverse ETL<br>
Reverse ETLとは、Data Warehouseのデータを他のシステム（CRM、Marketing Tool、Operation用のSaaSなど）に連携する手法（図5）を指します。<br>
Data warehouseに入ったデータやその分析を最後アクションに結びつけることから、Data Activationとも呼ばれます。<br>
収集した生データや変換されたデータをビジネス上の価値に繋げるための重要な架け橋の一つだと考えられています。<br>
Reverse ETL / Data ActivationのSaaSは、<a href="https://www.rudderstack.com/">rudderstack</a>, <a href="https://www.getcensus.com/">Census</a> , <a href="https://hightouch.com/">hightouch</a> があります。<br>
<img src="https://ik.imagekit.io/plaid/939a59d5-f580-462b-955f-dd10eadad6c2/Data_Activation.png" alt="Data_Activation.png"><br>
図5. Data Activation ( https://www.getcensus.com/solutions/data-teams )</p>
</li>
</ul>
<h3>その他（横断系）</h3>
<ul>
<li>
<p>Data Governance<br>
ここまで説明したツールの進化によってデータの活用が進むと、今度はデータの運用管理が大変になり、管理ツールへのニーズが高まってきました。<br>
データ運用管理に求められる機能としては以下があります。</p>
<ul>
<li>データカタログ
<ul>
<li>組織内にあるデータを検索・発見する</li>
</ul>
</li>
<li>データリネージ
<ul>
<li>どこからどこへデータが流れたのかを可視化・監視する</li>
</ul>
</li>
<li>データオブザーバビリティ
<ul>
<li>今流れているデータのEnd-to-Endのモニタリングする（可視化、品質チェックetc）</li>
</ul>
</li>
</ul>
<p>各機能についてData Warehouse側でも提供しています。たとえば、<a href="https://www.databricks.com/jp/product/unity-catalog">DatabricksのUnity Catalog</a>、<a href="https://cloud.google.com/data-catalog?hl=ja">GCP Data Catalog</a>などなど。各種サービス跨いだ管理ツールとしては<a href="https://atlan.com/">Atlan</a>や<a href="https://www.montecarlodata.com/">MONTE CARLO</a> があります。</p>
<p>いずれの機能も内部的には各種サービスからメタデータを収集し、それを目的に応じて使用しているという構造になっています（図6）。なので、どれぐらい解像度高くリアルタイムでメタデータを収集できるかがポイントと言えます。<br>
　 <img src="https://ik.imagekit.io/plaid/a6f2dba8-5e18-44f4-aa16-1d066047fb28/Metadata_Lake.png" alt="Metadata_Lake.png"><br>
図6. Metadata管理 ( https://atlan.com/what-is-data-governance/?ref=/modern-data-stack-101/ )</p>
</li>
<li>
<p>Data Orchestration<br>
上で話したようなデータの収集・処理・活用を実行するために、タスクのワークフロー管理を行うツールを指します。<br>
主に<a href="https://airflow.apache.org/">Airflow</a>、<a href="https://www.prefect.io/">Prefect</a>、<a href="https://dagster.io/">dagster</a>あたりが有名です。</p>
</li>
</ul>
<h2>まとめ</h2>
<p>さて、Modern Data Stackとは何かから始めて、カテゴリーごとの技術要素・代表的なサービス・重要だと思うトレンドを解説しました。<br>
あくまで概要を説明しただけなので、実際にデータ基盤を構築しようとした際はいろいろなトピックを深掘りする必要が出てきます。参考資料にも今回調べたリンクを載せたので、みなさんが各トピックの詳細を知る上での手助けになれば幸いです。</p>
<h2>参考資料</h2>
<ul>
<li>Modern Data Stack全体像の図
<ul>
<li><a href="https://twitter.com/ValentinUmbach/status/1418242294952644611">https://twitter.com/ValentinUmbach/status/1418242294952644611</a></li>
<li><a href="https://www.indicative.com/resource/modern-data-infrastructure/">https://www.indicative.com/resource/modern-data-infrastructure/</a></li>
</ul>
</li>
<li>Modern Data Stack概論
<ul>
<li><a href="https://speakerdeck.com/satoshihirose/modandetasutatukugai-lun">https://speakerdeck.com/satoshihirose/modandetasutatukugai-lun</a></li>
</ul>
</li>
<li>Modern Data Stack Repository
<ul>
<li><a href="https://www.moderndatastack.xyz/">https://www.moderndatastack.xyz/</a></li>
</ul>
</li>
</ul>


プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてModern Data Stackの概要、主要サービス、重要だと思うトレンドをまとめました。

社内勉強会「Modern Data Stack入門」の内容をブログ化しました - PLAID engineer blog

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

<p>あけましておめでとうございます。エンジニアの Yui です。</p>
<h2>はじめに</h2>
<p>KARTE では毎年、年越し(1/1 0:00)のタイミングで KARTE を導入している一部のウェブサイトにおける新年のキャンペーンやセール開始によるリクエスト急増が見込まれます。このリクエスト急増に対応する事前のスケールアップやリアルタイムでの対応を一部のエンジニアで行なっています。</p>
<p>通常時はクラウド上のほぼ全てのリソースのスケーリングを自動化しているのですが、コストやコールドスタートに対する対策の観点からこのタイミングのみ一部を手動で対応しています。</p>
<p>この記事では今年どんな対応を行なったのかを記録として残しておきたいと思います。</p>
<h2>今回スケールさせた部分について</h2>
<p>KARTE ではインフラの大部分に Google Cloud を利用しています。今回スケールさせるのは主に Google Cloud のサービス群（Cloud Bigtable（以下 BigTable）, Google Kubernetes Engine（以下 GKE）, Compute Engine（以下 GCE） など）になります。</p>
<p>今回の対応部分である、KARTEのリアルタイム解析基盤についてざっくり説明します。<br>
<img src="https://ik.imagekit.io/plaid/57731d06-9649-41ae-9b82-bece8247f89c/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-01-1513.13.57.png" alt="スクリーンショット2024-01-1513.13.57.png"><br>
<a href="https://karte.io/feature/core-realtime/">リアルタイムユーザー解析</a></p>
<p>KARTE の JavaScript タグが入っているウェブサイトにユーザーが訪れると、そのユーザーの閲覧やクリックなどのウェブサイト上での行動（ = <strong>イベントデータ</strong>）が KARTE のサーバーに送られます。KARTE のサーバーは受け取ったイベントデータをリアルタイムに解析します。また、事前に設定している施策配信を行うかどうか（このページを閲覧した人にはこのポップアップを出す、など）の判定を行い、結果をウェブサイト側に返します。</p>
<p>この解析や配信判定処理を担当しているのがリアルタイム解析基盤と呼んでいる部分で、レイテンシやサーバー負荷状況がサイト上のユーザー体験にクリティカルに影響します。<br>
（リアルタイム解析基盤のアーキテクチャについて詳しく知りたい方はこちらの記事をご参照ください。 <a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a> ）</p>
<h2>事前準備</h2>
<p>リアルタイム解析基盤はざっくり分けてユーザーの解析や配信判定などリアルタイムに処理する必要がある部分と、イベントデータの永続化など非リアルタイムの処理でよい部分があります。<br>
アーキテクチャや過去の対応実績をもとに特に前者に重点を置き、何をどの程度スケールさせるのかを事前に検討しました。</p>
<p>準備として実際に当日までに行った内容は以下です。</p>
<ul>
<li>
<p>当日の対応内容の読み合わせ（今回は4名で対応しました）</p>
</li>
<li>
<p>誰がどの部分を担当するのかを決める</p>
</li>
<li>
<p>各自担当部分についてスケールさせる値を決める</p>
<ul>
<li>昨年の年明けタイミングや直近1ヶ月の定常時のリクエスト数・インスタンス数の平均・最大値などを確認して判断しました</li>
</ul>
</li>
<li>
<p>Terraform や GKE の manifest など IaC で対応する部分は当日までに PR を作成し、レビューを済ませておく</p>
<ul>
<li>当日はこの PR をマージすることで CI/CD パイプラインが走り、変更が適用されます</li>
</ul>
</li>
<li>
<p>BigTable のスケールアウト検証</p>
<ul>
<li>BigTable は最小ノード数を増やしたからといって必要なリソースが確保できるかを確約していません。そこで、実際の環境で少なくとも数日前の時点で想定量までスケールできるかという点や、当日の作業手順確認の目的で事前検証を行いました。（数日前時点でスケールできたからといって当日に同じリソース量までスケールできることが確約されていない点は注意が必要です）</li>
</ul>
<blockquote>
<p>ノード割り当てとは、各プロジェクトで 1 つのゾーンにプロビジョニングできるノードの最大数です。この割り当て数にまだ達していなくても、クラスタにノードを追加できるとは限りません。ゾーンでこれ以上ノードを利用できない場合、プロジェクトで割り当てが残っていても、そのゾーンのクラスタにノードを追加できないことがあります</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/quotas?hl=ja#availability">割り当てと上限  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
<blockquote>
<p>ゾーンでノードがなくなると、構成した最小ノード数を満たすように追加ノードがプロビジョニングされません。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/autoscaling?hl=ja#determine-min">自動スケーリング  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
</li>
</ul>
<p>作業内容や担当、進捗についてはこんな感じで Notion で管理しました。<br>
<img src="https://ik.imagekit.io/plaid/53d77f2c-8d01-4bb4-9dab-65a83469c146/tasks.jpg" alt="tasks.jpg"></p>
<h2>当日やったこと</h2>
<p>作業当日（2023/12/31）は事前に決定した通りに以下の手順で作業を行いました。</p>
<ul>
<li>
<p>20:30 に Slack に集合</p>
</li>
<li>
<p>通常時に利用している自動スケール設定のモニタリングを OFF にする</p>
</li>
<li>
<p>Datadog のログ量を調整する</p>
<ul>
<li>普段から Datadog への書き込みが多いかつ重要度の低いログを一時的に停止させることで、不要なコストがかかることを防止する目的で行いました。</li>
</ul>
</li>
<li>
<p>BigTable クラスタのノードサイズの最小値を手動で徐々に上げていく</p>
<ul>
<li>
<p>BigTable はノードを増やすと一時的にレイテンシが増加し負荷がかかった状態が続く可能性があり、ユーザー体験に影響を与える可能性があります。一気に上げてレイテンシが高い状態が続くのを避けるため、都度レイテンシを確認しながら手動で徐々に上げるようにしました。</p>
<blockquote>
<p>クラスタ内のノード数が増加した後、クラスタのパフォーマンスが大幅に向上するまでに、負荷のかかった状態が最大 20 分間続く可能性があります。Bigtable は、その負荷に基づいてクラスタ内のノードをスケーリングします。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/performance?hl=ja#slower-perf">パフォーマンスについて  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
</li>
</ul>
</li>
<li>
<p>IaC 対応部分のPRをマージし、変更後の値までスケールすることを確認</p>
</li>
<li>
<p>Datadog のダッシュボードでスケール台数やエラーレート、レイテンシを監視し異常がないかを確認<br>
<img src="https://ik.imagekit.io/plaid/1f2e893a-0a49-4e39-9cce-efb048e06469/datadog.jpg" alt="datadog.jpg"><br>
▲こんな感じで作業と並行してダッシュボードを継続して確認していました</p>
</li>
</ul>
<p>以下は 2023/12/31 23:00 〜 2024/1/1 1:00 までのイベント数や接客数・スループットを Datadog のダッシュボードに描画したグラフです。0:00 のタイミングでリクエストが急増しているのがわかります。<br>
<img src="https://ik.imagekit.io/plaid/eea55fa4-e87e-4582-bea4-9baa1530368c/%E3%82%A4%E3%83%98%E3%82%99%E3%83%B3%E3%83%88%E6%95%B0.jpg" alt="イベント数.jpg"></p>
<p>当日は事前準備した内容の実施に加え、想定よりもリクエスト数が増えそうな兆候があったため追加でインスタンス数を増やすなどの対応を行いました。</p>
<h2>後片付け</h2>
<p>0:00〜0:30ごろをピークにリクエスト数が徐々に落ち着いていくのを確認しました。その後1:00頃からPRのリバートや手動でスケールさせた部分のスケールインを行いました。</p>
<p>スケールイン時も急激に台数を減らすとサーバーの負荷増加や BigTable のレイテンシ増加などでパフォーマンスが低下するおそれがあるため、対応方法に注意する必要があります。</p>
<p>今回対応した部分（BigTable, GKE,  GCE）に関してはスケールインを自動で徐々に行う設定が入ってることを確認し、スケールインを実行しました。</p>
<blockquote>
<p>クラスタ内のノード数を減らしてスケールダウンする場合、10 分間に 10% を超えるクラスタサイズの縮小は行わないようにしてください。スケールダウンが速すぎると、クラスタ内の残りのノードが一時的に過負荷になる場合にレイテンシが増加するなど、パフォーマンス上の問題が発生する可能性があります。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/scaling?hl=ja#scale-down">スケーリング | Cloud Bigtable ドキュメント | Google Cloud</a></p>
<blockquote>
<p>Kubernetes offers features to help you run highly available applications even when you introduce frequent voluntary disruptions.<br>
As an application owner, you can create a PodDisruptionBudget (PDB) for each application. A PDB limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions.</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/">Disruptions | Kubernetes</a></p>
<blockquote>
<p>スケールインの速度を制御するには、追跡時間枠内でのオートスケーラーの最大許容削減数を構成します。</p>
<ul>
<li><strong>最大許容削減数</strong>（<code>maxScaledInReplicas</code>: VM インスタンスの数または割合）。指定された追跡時間枠内においてワークロードで（グループのピークサイズから）削除できるインスタンスの数。このパラメータを使用して、グループをどれだけスケールインできるかを制限します。これにより、より多くのインスタンスがサービスを開始するまで、発生しうる負荷スパイクに引き続き対応できます。最大許容削減数が小さいほど、スケールインの速度は遅くなります。</li>
<li><strong>追跡時間枠</strong>（<code>timeWindowSec</code>: 秒）一時的な負荷減少の後に負荷スパイクが発生する可能性が高く、最大許容削減数を超えてグループサイズをスケールインしたくない時間。このパラメータで、オートスケーラーが過去の負荷を処理するのに十分なピークサイズを決定する際の時間枠を定義します。オートスケーラーは、追跡時間枠で観測されたピークサイズから最大許容削減数を差し引いた値よりも小さいサイズには変更されません。追跡時間枠が長いほど、オートスケーラーは過去のピーク負荷を重視します。これにより、より慎重な安定したスケールインが可能になります。</li>
</ul>
</blockquote>
<p><a href="https://cloud.google.com/compute/docs/autoscaler/understanding-autoscaler-decisions?hl=ja">オートスケーラーによる判断の理解 | Compute Engine ドキュメント | Google Cloud</a></p>
<h2>おわりに</h2>
<p>年越しの瞬間はこんな感じで緊張感がありながらもわいわい対応していました。<br>
<img src="https://ik.imagekit.io/plaid/a87d020b-d545-410e-958a-6794e64efeaf/Group1.jpg" alt="Group1.jpg"><br>
普段はなかなかやらないような大幅なスケールアップやリアルタイムでの対応を行い、個人的にもとてもいい経験になりました。</p>
<p>CX（顧客体験）プラットフォーム「KARTE」を運営するPLAIDでは、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


普段からトラフィック量の多いプロダクトであるKARTEにおいて、特にトラフィックが増えることが想定できる年末年始のタイミングにおいて、事前スケールやリアルタイム対応をどのように行ったのかの記録です。

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

<h2>概要</h2>
<p>本記事では <a href="https://www.getdbt.com/">dbt (data build tool)</a> を本番環境のサービスで使った事例を主に Web サービス開発者向けに紹介します。プレイドでは <a href="https://karte.io/package/signals/">KARTE Signals</a> Connector (以下、Signals コネクタ) の SQL を生成するエンジンとして dbt を使っています。dbt を使う前には機能を実現するための SQL が大きく複雑なために機能の追加や変更が困難な状態に陥っていました。dbt を使うことで SQL をシンプルな複数のファイルに分割して、自動テストも導入できるようになりました。機能の変更や保守がしやすくなり、開発速度と品質が向上しました。</p>
<h2>背景</h2>
<h3>dbt を使うに至った背景</h3>
<p>今回の記事の背景として Signals コネクタを紹介します。KARTE Signals にはダッシュボードとコネクタという2つの機能があります。Signals ダッシュボードは広告効果を表示・分析するためのツールですが、今回はスコープ外なので詳しく紹介しません。Signals コネクタは 1st Party Data を使って広告効果を根本的に改善するサービスです。Signals コネクタには主に3つの機能があります。1つ目は失われたコンバージョンの補完です。これまでコンバージョン情報の計測のために使っていた 3rd Party Cookie の利用が Intelligent Tracking Prevention (ITP) により阻害され、広告媒体のコンバージョン情報の欠損が発生します。この欠損したコンバージョンを広告媒体の Conversion API を利用して補完します。2つ目はターゲティングです。KARTE で取得する行動データや自社の CRM データを活用することでより高精度にターゲティングを実現します。3つ目は入札最適化の精度改善です。Value Based Bidding (VBB) という入札最適化によって目的広告費用対効果やコンバージョン値の最大化を目指します。</p>
<h3>広告API用データ作成の問題</h3>
<p>広告配信媒体は、その広告媒体の API ごとに必要なデータの内容やフォーマットが異なります。つまり、広告媒体 API の違いを吸収するように似たような機能の複雑な SQL を複数用意する必要があります。この複雑な SQL の開発と管理を楽にするために dbt を使っています。具体的には「複数の SQL テンプレートファイルと変数から1つの SQL を dbt が合成(compile)」します。Signals コネクタには dbt を使った SQL 合成の機能が組み込んであります。Signals コネクタではクライアントがデータフォーマットの違いを意識することはほとんどありません。管理画面上からいくつかのパラメータ設定をするだけで広告媒体 API に対してデータを送ることが出来ます。</p>
<h2>dbt</h2>
<h3>dbt とは何か？</h3>
<p>dbt はデータレイクもしくはデータウェアハウスと呼ばれるデータプラットフォームに格納されたデータの分析をサポートするツールです。 具体的には、オンラインエディタで SQL を書いてデータプラットフォームで実行したり、Git で SQL ファイルを管理したり、CI/CD でビルドやテスト、デプロイなどができます。</p>
<h3>なぜ dbt を選んだのか？</h3>
<p>dbt も含めて複数の SQL テンプレートファイルから1つの SQL を合成する方法はいくつかあります。たとえば、プログラミング言語と SQL フレームワークを使って SQL を生成したり、単純な SQL テンプレートに書く、ビジュアルエディタや統合開発環境を使うなどの方法があります。Signals チームでは初期に SQL 書くメンバーがプログラマではなかったのでプログラミング言語による SQL 生成は選択しませんでした。また、検証時に作成した SQL 文を活用したいという要望もありました。dbt はこれらの要求を満たしているツールの1つでした。OSS(dbt Core)としてソースコードが提供されているのとSaaSオンラインエディタ(dbt Cloud)を利用できるのが dbt の良いところです。</p>
<h2>開発と運用</h2>
<h3>dbt をどのように使っているか？</h3>
<p>dbt を使う前には KARTE 内のクエリエディタ機能で巨大な BigQuery SQL を書いていました。現在は dbt を使って動的に SQL を生成しています。テンプレートとなる SQL を書くときには dbt Cloud というオンライン開発環境で作業します。エディタ上で SQL のビルドや実行、テストデータを使ったテストもできます。dbt では Git を使ってテンプレートファイルを管理します。Git ブランチ切り替えや GitHub Pull Request 作成も dbt Cloud から操作できます。</p>
<p>dbt を使う前後でどのように SQL 開発環境が変わったのかを説明します。</p>
<table>
<thead>
<tr>
<th></th>
<th>dbt 使用前</th>
<th>dbt 使用後</th>
</tr>
</thead>
<tbody>
<tr>
<td>SQL ファイル数(1機能あたり)</td>
<td>1</td>
<td>5 (平均)</td>
</tr>
<tr>
<td>SQL 行数(1ファイルあたり)</td>
<td>300 - 500</td>
<td>20 - 60</td>
</tr>
<tr>
<td>テストデータ作成</td>
<td>困難</td>
<td>容易</td>
</tr>
<tr>
<td>自動テスト</td>
<td>なし</td>
<td>あり</td>
</tr>
<tr>
<td>SQL クエリ管理</td>
<td>データベース</td>
<td>Git</td>
</tr>
<tr>
<td>クエリエディタ</td>
<td>独自 (機能少)</td>
<td>dbt Cloud (機能多)</td>
</tr>
</tbody>
</table>
<p>SQL ファイルの分割によってコードの見通しが良くなったことで、クエリを改善できて SQL の合計行数も少なくなっています。SQL を実行してエラーが出たときにテストデータに問題があるのかクエリ内容の問題なのか切り分けるのが難しかった問題も、小さな SQL に分割することによって判断しやすくなりました。SQL の自動テストについては後述します。</p>
<h3>dbt 関連サーバ構成</h3>
<p>dbt の SQL 合成は GraphQL API を通じて行うようにしました。dbt Cloud の API (REST API) を使うことも検討したのですが、BigQuery の権限管理の要件を満たすことができずに自前で dbt API を作成して運用しています。</p>
<p>Signals の構成サーバのうち dbt に関係している部分だけを抜き出した構成図<br>
<img src="https://ik.imagekit.io/plaid/24ff250b-49f5-4131-a545-883909e01fe1/dbt_structure.png" alt="dbt_structure.png"></p>
<p>Signals サーバと dbt API サーバが GraphQL で通信します。dbt API サーバ自体はステートレスなのでデータベースを持たず dbt Core を通じて Git Repository (ワーキングディレクトリ)内の SQL ファイルを参照します。</p>
<h3>dbt を使った SQL 合成機能の開発フロー</h3>
<p>Signals チームにおける SQL 合成機能の開発フローを紹介します。ここでは新しい機能(モデル)を追加する場合のフローを例とします。SQL 開発自体は dbt Cloud のみでほとんど作業が完結します。</p>
<ol>
<li>Git の main ブランチから開発ブランチを作成する</li>
<li>seeds ディレクトリにテストデータ(csvファイル)を入れる(dbt seed で BigQuery にアップロードされる)</li>
<li>models 以下に新しいモデルのディレクトリを作成する</li>
<li>SQL ファイルを書いてビルドする(dbt build で BigQuery を使って SQL を実行する)</li>
<li>SQL が完成したら git commit して Pull Request を作る</li>
<li>CI による自動テストと担当者によるコードレビューを行う</li>
<li>PR をマージ後に GraphQL サーバとクライアントを自動生成して git commit して PR を作成する</li>
<li>CI によるテストとコードレビュー</li>
<li>PR をマージするとクライアントが自動リリースされる</li>
</ol>
<h3>自動ビルドと自動テスト</h3>
<p>CI でビルドを実行して SQL が正しいかどうかを確認します。BigQuery と接続することで合成した SQL が文法として正しいかどうかだけではなく、テストデータ自体のフォーマットや合成した SQL を実行して結果が取得できるかも確認します。テストとして特定の SQL 文を実行して結果の整合性を確認することもできます。</p>
<p>自動でビルドとテストを行えるようになったお陰で CI の時点で SQL の文法ミスや変数設定時の誤植などを減らすことができるようになりました。SQL ファイルを小さいファイルに分割したことによって個々の機能が明確になり、レビューも容易になりました。</p>
<p>自動テストではテストデータや個別の SQL 実行後のスキーマが正しいかどうかを検証します。自動テストによって SQL 修正時に特定の項目を出力してなかったりカラム名を間違っていたりするような単純なミスを見つけやすくなりました。</p>
<h3>GraphQL サーバとクライアントのコード生成スクリプト</h3>
<p>GraphQL サーバ (Python) と GraphQL クライアント (node.js) のコードをそれぞれスクリプトで生成しています。dbt Cloud を使って作成した SQL ファイルが models ディレクトリ以下に置いてあるものとします。コード生成スクリプトを実行すると GraphQL サーバと GraphQL クライアントのコードを生成します。</p>
<p>サーバ側のコード生成のポイントは SQL ファイルを読んで変数名を抽出しているところです。変数を GraphQL の引数として渡せるようにしています。変数を自動抽出することで変数名の間違いや抜け漏れを減らすことができます。</p>
<p>クライアント側のコード生成には <a href="https://the-guild.dev/graphql/codegen">GraphQL Code Generator</a> を使っています。GraphQL Code Generator は GraphQL スキーマと GraphQL ドキュメントから TypeScript などの言語による GraphQL クライアントを生成します。GraphQL スキーマはサーバ側のコードから自動生成します。スクリプトで自動生成した GraphQL ドキュメントと組み合わせると GraphQL クライアントを生成できます。</p>
<p><img src="https://ik.imagekit.io/plaid/5543098d-8f04-4876-91c5-b0a7edb88d4d/dbt_flow.png" alt="dbt_flow.png"></p>
<h2>現状の課題と展望</h2>
<h3>dbt の問題点</h3>
<p>dbt も万能ではなく、いくつか扱いづらいことがありました。使ってみて気づいた課題を共有します。</p>
<ul>
<li>dbt compile が遅い<br>
SQL の生成に使っている dbt compile に数秒程度かかります。複数ファイルをマージして変数展開している部分よりも BigQuery に接続しているところで時間がかかっているようです。頻繁に dbt compile を実行しないようにアプリケーションの実装を工夫することで問題を回避しています。</li>
<li>ファイル名や参照名のユニークネス<br>
dbt ではモデルという概念で生成される SQL を表し、複数のモデルを1つの dbt プロジェクトで扱えます。しかし、ファイル名や参照(ref)名をプロジェクト内でユニークにしなければならないという制限があります。複数のモデルでそれぞれ異なるファイル名をつける必要があります。似たような機能を提供してほぼ同じ内容の SQL ファイルに固有の名前を要求されるので、モデルが増えるたびにファイル名の重複を気にする必要があります。必要に応じて命名規則を定めた方が良いかもしれません。</li>
</ul>
<h3>今後の展望</h3>
<ul>
<li>SQL 合成機能以外も活用する<br>
dbt の本来の使い方である継続的なデータ分析のサポートの機能も使ってみたいと思います。たとえば <a href="https://docs.getdbt.com/reference/resource-properties/freshness">source freshness</a> を設定すると入力データが正しく更新されているか監視することができます。この機能を使えばサービス品質を向上するのに使えるはずです。</li>
<li>他の機能にも dbt を展開する<br>
KARTE やその他のプロダクトでも dbt を使える場所に展開することを検討しています。普及活動の一環として社内の勉強会で dbt の使い方や活用事例を何度か紹介しました。</li>
</ul>
<h2>まとめ</h2>
<p>KARTE Signals コネクタでは dbt Cloud で開発した SQL を独自の dbt GraphQL API を通じて本番環境で利用しています。dbt を導入することで SQL の開発や保守がやりやすくなりました。最大500行以上あった複雑な SQL を数十行のファイル群に分割することで見通しが良くなり、レビューや動作確認、テストデータの作成が容易になりました。また自動ビルドや自動テストを導入することで SQL の記述の問題に早く気付けるので、開発とデバッグの速度も向上しました。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


KARTE Signals コネクタの SQL 生成機能として dbt を活用して SQL 開発の課題を解決して開発効率を上げた具体的な手法を紹介します

KARTE Signals の複雑 SQL を支える dbt の活用

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。</p>
<p>今回は、2023年4月からBigQueryが<strong>Editions</strong>という料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。</p>
<p>BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。</p>
<p>しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり</p>
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
<p>による影響が発生しました。</p>
<p>storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、<strong>Long-Term Physical Storage</strong> という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。</p>
<p>一方で、slotの単価が <strong>$0.024/slothour</strong> から <strong>$0.048/slothour</strong> へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、<strong>Bigquery-Slot-Optimization Team</strong>です！</p>
<p>本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。</p>
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
<p>Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。<br>
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png"></p>
<p>MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。</p>
<p>まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。</p>
<p>時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。<br>
単純には</p>
<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>
<p>のようにすれば、簡単に取得できます。</p>
<p><strong>period_slot_ms</strong>とはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。</p>
<p>このテーブルをさらに、<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という形で集約できます。</p>
<p>集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。</p>
<p>Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。<br>
TypeScriptで書くとこのようになります。（※一部抜粋）</p>
<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>
<p>この関数をDeployするには</p>
<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>
<p>というgcloudコマンドだけでdeployできます。</p>
<p>さらに、このFunction を Cloud Scheduler で定期的に実行します。<br>
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。</p>
<p>結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。<br>
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png"></p>
<p>これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。<br>
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。</p>
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
<p>BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。</p>
<p>弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。<br>
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。<br>
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。<br>
これを最適化するために導入されたのが、AutoScaleです。</p>
<p>そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。</p>
<p>そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。</p>
<p>これらを考慮した上で、弊社で最適化した結果が以下の通りです。<br>
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png"></p>
<p>いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。<br>
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。<br>
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。<br>
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png"></p>
<p>ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。<br>
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。</p>
<p>最も大事なのは、<strong>Productごとに要件を把握し適切にReservationを配分する</strong>ことであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。</p>
<h2>最終的なコストは...?</h2>
<p><strong>全体で約20%のコスト削減を実現</strong> することができました。<br>
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。</p>
<p>以上のように<br>
① Monitoringの整備によるJobごとのSlot監視と削減<br>
② AutoScaleの導入によるSlotBaseLineの最適化全体</p>
<p>でBigQuery全体として、約20%のコスト削減を実現しました。</p>
<p>BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


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

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

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

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

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

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

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


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

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

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

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

ABテストのための統計的検定理論というタイトルで、株式会社ユーザベースさんとの共同開催テックイベント「ABテストの理論と実践」に登壇しました

Engineer Blog

Recent Article