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

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

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

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

<p>ごきげんよう、@tik-son です。</p>
<p>2024年7月25日(木)に開催された <a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service Dev Day（AOAI Dev Day）</a>にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。<br>
今回はそのレポートをお届けします。</p>
<h2>イベント概要</h2>
<p>AOAI Dev Day は、Azure OpenAI Service を活用する開発者コミュニティの祭典です。<br>
「開発者が実際のプロジェクトから得た経験や教訓を共有する」という趣旨のもと、実践的なセッションが多く見受けられ、オフライン開催限定ならではの一体感と熱気に包まれていました！</p>
<h2>登壇内容サマリー</h2>
<p>今回の私のセッションでは、プレイドが開発する PaaS である「KARTE Craft」の開発を支援する AI アシスタント「Craft Copilot」の仕組みについて、アーキテクチャや技術選定の背景を交えながら解説しました。</p>
<script defer class="speakerdeck-embed" data-id="b43df62d30944212a86f0c5e92c65d8b" data-ratio="1.7772511848341233" src="//speakerdeck.com/assets/embed.js"></script>
<h3>Craft Copilot とは？</h3>
<p>「Craft Copilot」は、KARTE Craft での開発体験を向上させるために生まれた AI アシスタントです。<br>
現在β版として提供中で、将来的には KARTE Craft を利用する開発者の強力なパートナーとなることを目指しています。</p>
<h3>Craft Copilot の機能</h3>
<p>Craft Copilot は、色々あるのですが、今回の登壇では主要機能である以下の2つの機能についてお話しました。</p>
<ol>
<li><strong>AI によるサイト制作支援</strong><br>
Craft Sites Copilot」機能により、HTML や CSS のコードを書かずに、自然言語の指示やイメージ画像から Web ページを自動生成できます。</li>
<li><strong>Craft のルールを踏まえたコード改善</strong><br>
既存のコードを Craft のルールに沿って自動的に修正できます。</li>
</ol>
<h3>技術スタックの裏側</h3>
<p>Craft Copilot は、Microsoft が提供する Azure OpenAI Service を中心に、Azure の様々なサービスを組み合わせて開発されています。</p>
<p><strong>Azure OpenAI Service (GPT-4o, GPT-4o-mini)</strong></p>
<ul>
<li>自然言語処理の中核を担っており、HTML 生成やコード修正の指示理解、回答生成などを実現しています。</li>
</ul>
<p><strong>Azure AI Search</strong></p>
<ul>
<li>Craft Copilot が参照するドキュメントをベクトル化して保存・検索するために利用しています。</li>
<li>セマンティックハイブリッド検索によって、高精度な検索を実現しています。</li>
</ul>
<p><strong>Azure API Management</strong></p>
<ul>
<li>API の可用性、キャパシティ、メンテナビリティを向上させるために利用しています。</li>
<li>Backend Pool やサーキットブレーカーを活用することで、柔軟な API 運用を実現しています。</li>
</ul>
<h2>登壇を終えて</h2>
<p>今回の AOAI Dev Day では、Craft Copilot のアーキテクチャや Azureサービス利用におけるTips などに対して高い関心を寄せていただき、登壇後に、Ask the Speakerで多くの方とお話ししました。</p>
<p>また、他の登壇者の方々との交流を通して、Azure OpenAI Service を活用したサービス開発の最新動向や、AI 開発における課題や展望を共有することができ、<br>
改めて、Azure OpenAI Service は、開発者にとって大きな可能性を秘めていることを実感しました。</p>
<h2>イベント後のアップデート</h2>
<p>実は、今回の登壇時には OpenAI の GPT-4o-mini を利用していたのですが、先日、<a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service 版の GPT4o-mini がリリース</a>されたので置き換えました。<br>
このスピード感は開発者としてはありがたいですね。</p>
<p>Craft Copilot はまだβ版ですが、今後も Azure OpenAI Service の最新機能やアップデートを積極的に活用し、より強力な AI アシスタントを目指して、今後も開発を続けていきます。<br>
一緒に改善していきたい人も<a href="https://recruit.plaid.co.jp/requisitions/product-engineer">絶賛募集中</a>です！</p>


2024年7月25日(木)に開催された Azure OpenAI Service Dev Day（AOAI Dev Day）にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。今回はそのレポートをお届けします。

Azure OpenAI Service Dev Day に登壇しました_プレイドエンジニアブログ

Azure OpenAI Service Dev Day に登壇しました

<h1>はじめに</h1>
<p>こんにちは、プレイドのCore Platformチームに所属している西村です。今回のブログではGCE上でセルフホストしていたMongoDBインスタンスをMongoDB Atlasに移行した際の取り組みについて紹介します。移行に伴う要件や制約を考慮した結果、今回はあえてMongoDB固有の機能を使わずにGKEのJobを使って愚直にデータ移行する方法を採用したので、同じような移行作業を行う場合は参考になれば幸いです。</p>
<h2>背景</h2>
<p>プレイドではDBとして多くの部分で<a href="https://www.mongodb.com/ja-jp/atlas">MongoDB Atlas</a>を使用しています。MongoDB Atlasでは定期的にサポートバージョンが更新され、プレイドでもそれに合わせて適宜バージョンアップ対応を行っています。<a href="https://tech.plaid.co.jp/internship-mongodb-update">前回のバージョンアップ作業</a>は2023年末から2024年3月頃にかけて実施したのですが、そこで長らくGCE上で稼働していた古いバージョンのMongoインスタンスをこの機会にMongoDB Atlasに移行することにしました。</p>
<p>このインスタンスはOplogというKARTEの管理画面の操作履歴を保存しているもの（以降、旧Oplog）で、通常はほとんど参照されないデータなのでこれまでのバージョンアップ作業でも見落とされてしまっていました。しかし今回のバージョンアップでこのインスタンスで稼働しているMongoのバージョン（3.x）と更新後のバージョン（5.x）の互換性がなくなるため、こちらもバージョンアップ対応するかMongoDB Atlasに移行するか選択する必要がありました。今後のバージョンアップ対応や管理の煩雑さを考えて、この機に旧Oplogを廃止してMongoDB Atlas（以降、新Oplog）に移行する判断をしました。</p>
<h2>移行方法の検討</h2>
<p>移行にあたってまず要件を決める必要があります。今回の移行プロジェクトの要件は以下のように定めました。</p>
<ul>
<li>旧Oplogの過去データをすべて新Oplogに移行する</li>
<li>サービスは無停止でデータおよび書き込み先の移行を行う</li>
<li>想定外のトラブルがあってもデータの欠損が極力発生しないようにする</li>
<li>移行完了後に旧Oplogは廃止する</li>
</ul>
<p>上記の要件を満たすために以下の作業を順次実施することにしました。</p>
<ol>
<li>MongoDB Atlasに移行用Clusterを作成する（新Oplog）</li>
<li>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</li>
<li>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</li>
<li>データ移行完了後、旧Oplogへの書き込みを停止しインスタンスを破棄する</li>
</ol>
<p>図にすると以下のようなイメージです。<br>
<img src="https://ik.imagekit.io/plaid/ee37750e-63d1-47ac-9991-552cf0506361/migrate-oplog-2.png" alt="migrate-oplog-2.png"></p>
<p>以下ではそれぞれの手順で実施した内容について要点を解説します。</p>
<h3>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</h3>
<p>DBの移行にあたって必要な作業は主にデータ移行と接続先の変更の2つです。論理的には旧Oplogに書き込んでいる箇所の書き込み先を新しく作成した新Oplogに変更すれば新規に書き込むデータに関しては移行できるはずですが、いきなり接続先を切り替えると不具合があって書き込みができないなどのトラブルが発生した場合にデータが欠損してしまうため、慎重を期すために従来通り旧Oplogへの書き込みをしつつ新たに新Oplogへも同時に書き込む仕組みを実装し、既存の仕組みに影響を与えないようにしました。</p>
<h3>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</h3>
<p>2重書き込みについては特に大きな問題もなく実装することができました。これは一部のシステムを除いて旧Oplogを書き込む処理は社内の共通ライブラリ経由で実行されており、書き込み先の設定を変えて新Oplogへの書き込み処理を追加するだけで済んだためです。</p>
<p>あとは旧Oplogのデータを移行すれば必要な作業はほぼ終わりだったのですが、データ移行処理がなかなかうまくいかず試行錯誤が必要でした。その試行錯誤について詳しく見る前に、まずはMongoDBで推奨されているデータ移行方法と、なぜ今回それらの方法を採用しなかったのか簡単に説明します。</p>
<h3>MongoDB標準のデータ移行方法</h3>
<p>MongoDB標準のデータ移行方法としてJSON/CSVでの<a href="https://www.mongodb.com/docs/compass/current/import-export/">Import/Export</a>と<a href="https://www.mongodb.com/ja-jp/products/platform/migrate">Live Migration</a>があります。それぞれについて簡単に説明します。</p>
<h4>Import/Export</h4>
<p>Import/Exportは<a href="https://www.mongodb.com/ja-jp/products/tools/compass">MongoDB Compass</a>での操作もしくはCLIでそれぞれに対応したコマンドを実行することでCollectionのデータを指定したフォーマットでExportおよびImportすることができる機能です。前回のMongoバージョンアップ作業で4.x→5.xでも想定外の微妙な挙動の差異があったが今回は3.x→5.xなので動作差分が読めないこと、本番データ量が膨大（約2.3億レコード、500GB以上）で一括Importに懸念があることなどから今回は採用しないことにしました（とはいえ一度試してみてもよかったかも）。</p>
<h4>Live Migration</h4>
<p>Live MigrationはMongoDB Atlasで提供されている機能で、コンソールから設定するだけでオンプレミスも含めて任意の環境からMongoDB AtlasのClusterにデータ移行できるという機能です。Live Migrationではデータ移行中も移行元DBへの読み取りおよび書き込みが可能ですが、別のチームで試してみたところ断続的に常に書き込みが発生しているシステムだとデータ移行が完了できないという特性があり、完全に無停止でデータを移行しきるのは難しいとのことでした。</p>
<p>上記のようにMongoDBの標準的なデータ移行方法では今回の要件を満たすことが難しそうだったため、旧OplogからCursorでデータを取得し新Oplogに書き戻すという愚直な方針を採用することにしました。</p>
<h3>GKEでデータ移行用のJobを実行する</h3>
<p>プレイドではアプリケーションの実行環境として多くの場所でGKEを使用しています。既存のデプロイの仕組みを流用するため、今回はデータ移行用のスクリプトをGKEのJobで実行することにしました。データ移行にあたっては以下の手順で段階的に進めていきました。</p>
<ol>
<li>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</li>
<li>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</li>
<li>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</li>
</ol>
<p>以下で各手順で試した内容と結果を説明します。</p>
<h4>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</h4>
<p>まずは旧Oplogから取得した任意のデータを新Oplogに書き込めることを確認するため、Dev環境で作成したテスト用ClusterにEvaluation環境の旧Oplogの1日分のデータを書き込んでみることにしました。データ量としては約5000〜6000レコード程度で、以下のような移行スクリプトで問題なく書き込めることが確認できました（サンプル用に簡略化しています）。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行時点以前のデータを抽出する（日付は仮）
  const dateBegin = new Date('2024-04-01T00:00:00.000+00:00');
  const dateEnd = new Date('2024-04-02T00:00:00.000+00:00');
  const cursor = oplogGce.find({ timestamp: { $gte: dateBegin, $lt: dateEnd } }).cursor({ batchSize: 5000 });

  cursor.on('data', (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    oplog.save();
  });

  cursor.on('end', () =&gt; {
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h4>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</h4>
<p>テスト用Clusterへの書き込みが問題なく行えたので次はEvaluationの過去データ（約300万件、5GB程度）を移行するために日付の指定と書き込み先を変えて先ほどのJobを動かしたところOOM(Out Of Memory)エラーが発生するようになりました。</p>
<p>お気づきの方も多いかと思いますが、先ほどのコードではCurosrで取得したデータを1件ずつ書き込んでいたためデータ件数が多くなると書き込み処理が追いつかずOOMが発生してしまいます。今回のケースだと数万件程度処理が進んだ段階でOOMが発生しました。OOMを避けるためバッチサイズごとにバルクで書き込むように修正することでOOMの発生を抑えることができました。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行対象のデータを抽出する（日付は仮）
  const date = new Date('2024-04-01T00:00:00.000+00:00');
  const batchSize = 5000;
  const cursor = oplogGce.find({ timestamp: { $lte: date } }).cursor({ batchSize });

  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
    }
  });

  cursor.on('end', async () =&gt; {
    if (bulkOps.length &gt; 0) {
      await oplogAtlas.bulkWrite(bulkOps);
    }
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h5>途中でJobが止まる問題が発生</h5>
<p>前項のようにCurosrで取得したデータをバルクでまとめて処理することで安定的にJobを実行することができるようになりましたが、今度は20万件程度のデータを処理した時点で、残りの処理が完了する前にJob自体が終了してしまうという問題に遭遇しました。ここに至るまでにもOOM対策としてヒープメモリを追加したりCPUスペックの強化、 <code>async/await</code> で新Oplogへの書き込み結果を待つなどの試行錯誤をしてきたのですが、エラーログやGKEのメトリクスを見ても特に問題はなく、Jobとしてはすべての処理が完了して正常終了しているように見えました。</p>
<p>原因を調べるために調査用のログを仕込んで観察してみると、どうやら新Oplogへ書き込んでいる箇所のawaitが効いていなさそうだということがわかりました。つまり新Oplogへの書き込み箇所でawaitすることで書き込み処理の完了を待っているつもりだったのですが、Cursorの <code>on('data', ...)</code> はデータがある限り実行され続けてしまうため、新Oplogへの書き込みが完了する前にCursorの読み込みが終わってしまうという状態になっていそうだということがわかりました。</p>
<p>上記の現象の対策として新Oplogへの書き込み中はCursorの読み込みを一時停止し完了後に再開することで、無事に意図通りの挙動にすることができました。最終的なコードは以下のようになりました。</p>
<pre><code class="language-typescript">  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      cursor.pause();  // 書き込み前にCursorの読み込みを中断
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
      cursor.resume();  // 書き込み完了後にCursorの読み込みを再開
    }
  });
</code></pre>
<h4>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</h4>
<p>前項まで見てきたようにいろいろな落とし穴にハマりつつ、なんとか安定的にJobを動かしCursorで逐次的にデータを取得しMongoDB AtlasのClusterに大量データを書き込むという一連の処理を実装することができました。最後の仕上げとしてProduction環境の旧Oplogから新Oplogへのデータ移行Jobを実行して無事に全データを移行することができました。ちなみにProductionのデータは5年以上分、500GB程度ありJobの完了までに27時間程度かかりました。</p>
<h2>まとめ</h2>
<p>本ブログではGCE上で稼働しているMongoDBインスタンスを無停止でMongoDB Atlasに移行した取り組みを紹介しました。今回の取り組みではサービス固有の機能に依存しない汎用的な手法で移行を行ったので、似たような作業をされる場合の一つの方法として参考になれば幸いです。</p>


GCE上でセルフホストしていたMongoDBインスタンスをサービス無停止でMongoDB Atlasに移行した取り組みを紹介します

セルフホストしてるMongoDBをMongoDB Atlasに移行した話_プレイドエンジニアブログ

セルフホストしているMongoDBをMongoDB Atlasに移行した話

<p>エンジニアの石井と申します。</p>
<p>プレイドは2024年7月9日 (火) に開催された <a href="https://www.cnia.io/pek2024/">Platform Engineering Kaigi 2024</a> にゴールドスポンサーとして参加いたしました。スポンサーセッションでは「モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫」というタイトルで登壇させていただきました。</p>
<p>かつて <a href="https://karte.io/">KARTE</a> がモノリスだった頃の名残を留めていた認可基盤とその問題点、刷新後のアーキテクチャや安全な移行のために施した工夫などについてお話ししています。</p>
<p>この記事では、発表内容を紹介しつつ、構成上発表に含めなかった内容や当日いただいた質問への返答コメントも一部紹介しています。録画もございますので、発表内容の全体についてはそちらも合わせてご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫" src="https://speakerdeck.com/player/be7d5d49f7104e4196a52f3b72fb25fb" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="Platform Engineering Kaigi 2024 トラックB" src="https://www.youtube.com/embed/Hsob6TGTAPo?rel=0&start=21735" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share;"></iframe></div>
<h1>概要</h1>
<p>昨今の KARTE ではマルチプロダクト展開が進んでおり、コードやデータベースは分割されていますが、認可基盤だけは全てのプロダクトで共通のコードを利用していました。これはいくつかの問題を抱えていました。</p>
<p><img src="https://ik.imagekit.io/plaid/899c8100-634a-4bc5-8b06-59869a8ec6b1/express-server.png" alt="express-server.png"></p>
<p>そこで、まずは新たな認可基盤のアーキテクチャについて検討しました。認可基盤を一枚岩のものとして構築するか、あるいは分散させて配置するか、どちらも一長一短があり迷いましたが、最終的には分散させる方針に決定しました。アプリケーションが稼働する Pod それぞれに対して、認可のためのコンテナをサイドカーとして配置しています。</p>
<p><img src="https://ik.imagekit.io/plaid/193ea499-4c4e-4eed-bdf8-6c4fe0ba061c/karte-gateway.png" alt="karte-gateway.png"></p>
<p>認可用のコンテナには、アプリケーションごとに異なる認可の設定を施す必要があります。設定をどのように渡すべきかもいくつか選択肢がありましたが、最終的にはコンテナの中に組み込むことにしました。KARTE のデプロイには GitOps が採用されていますが、それに伴うリポジトリ構成なども考慮した上で、このような結論に至りました。</p>
<p><img src="https://ik.imagekit.io/plaid/17cc665e-3b1f-4051-8818-e05f91b80f40/karte-gateway-simplified-config.png" alt="karte-gateway-simplified-config.png"></p>
<p>KARTE にはエンドユーザー、すなわちプレイドにとってのお客様 (企業) のお客様 (ユーザー) の個人情報が蓄積されています。そのため認可基盤のバグ、特に本来拒絶すべきリクエストを誤って許容してしまうケースが生じないように注意を払いました。従来の認可機構と二重で認可を行いつつ、問題があればアラートが鳴るよう仕込んだ上で、徐々に移行を進めました。</p>
<p><img src="https://ik.imagekit.io/plaid/fa702baf-adcd-4b46-aa7c-0bc7a835df82/authentication-migration-2.png" alt="authentication-migration-2.png"></p>
<p>認可基盤の移行はほぼ完了していますが、運用自体はまだ始まって間もない段階です。現在の形に至るまでの意思決定が適切なものであったかどうかは、今後の過程で検証されていくでしょう。</p>
<h1>おまけ</h1>
<p>時間の都合で今回の発表からは省きましたが、アーキテクチャを検討していた時期には、どのように Pod にサイドカーを入れるのかについても議論がありました。</p>
<p>最初に参考にしたのは Istio です。今回お話しした認可基盤はサービスメッシュとは異なりますが、プロキシとして動作するサイドカーを利用するという点では似通っています。そのため、Istio と同じようなサイドカーインジェクションの仕組みが使えるのではないかと考えました。</p>
<p>しかし検討の末、このやり方は見送ることにしました。もしこれを採用する場合、Kubernetes の Admission Webhook を利用してサイドカーを注入する想定でした。しかし</p>
<ul>
<li>Admission Webhook のための追加実装が必要になる</li>
<li>GitOps によって karte-ops リポジトリの Kubernetes マニフェストと GKE 上で稼働するリソースの同期が取られているが、Admission Webhook が介入するとサイドカーがどこで追加されたものなのかわかりにくくなる</li>
</ul>
<p>という懸念が挙げられました。そして最終的には karte-ops リポジトリのマニフェストに直接サイドカーの設定を追加することになりました。</p>
<p>さて、当日いただいた質問の一つに「認可基盤のサイドカーがない状態でデプロイすることを防ぐ仕組みはあるか」というものがあります。上述の通り、認可基盤のサイドカーは自動ではインジェクションされないため、現時点ではそのリスクがあります。しかしマニフェストに対しては conftest を実施しており、事前に定義したルールに沿った設定になっているかを CI でチェックしています。サイドカーなしのデプロイもこれで検知できるのではないかと考え、検討を進めています。</p>
<h1>最後に</h1>
<p>当日のブースにご来場いただいた皆様、セッションをお聞きいただいた皆様、ありがとうございました。個人的には初の登壇でしたが、貴重な経験をさせていただいたことに感謝申し上げます。</p>
<p>そしてイベントのスタッフの皆様、企画ならびに運営のほどありがとうございました。Platform Engineering というテーマに思いを馳せつつ、さまざまな学びを得ることができる良い機会となりました。</p>
<p>今後のプレイドにとっても Platform Engineering は重要なテーマです。今回の参加で得た学びを活かしつつ、日々の開発に取り組んでまいります。</p>


Platform Engineering Kaigi 2024の登壇者によるレポート記事です。「モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫」と題したセッションの発表内容を紹介しています。

Platform Engineering Kaigi 2024登壇レポート_プレイドエンジニアブログ

Platform Engineering Kaigi 2024登壇レポート

インターンシップで全社のMongoDBをアップデートした話

BigQueryを題材にし、大規模なデータベースでの分散処理の仕組みについて紹介します。

BigQueryの分散処理の仕組みを深掘りする_プレイドエンジニアブログ

BigQueryの分散処理の仕組みを深掘りする

<p>こんにちは。プレイドで技術領域の広報などを担当しているmomoki (<a href="https://twitter.com/mmk__106">@mmk__106</a>)です。</p>
<p>プレイドは、2024年5月8日に開催された「<a href="https://gen-ai-conf.org/">生成AIカンファレンス2024</a>」にシルバースポンサーとして参加しました。今回は、当日のイベントの様子やプレイドとして行ったことを紹介します。</p>
<h1>イベントへの参加の経緯</h1>
<blockquote>
<p>生成AIカンファレンスは、この革新的な分野の専門家が集まる、国内最大規模の生成AIイベントの一つです。スタートアップのCEO/CTO、大手企業のリーダー、トップレベルの研究者たちが登壇し、最新の知見と経験を共有します。（<a href="https://gen-ai-conf.org/#:~:text=keyboard_arrow_right-,Concept,-%E7%94%9F%E6%88%90AI%E3%81%AF">生成AIカンファレンス2024 Webサイト</a>より）</p>
</blockquote>
<p>生成AIカンファレンス2024は、その名の通り生成AIの専門家や注力して取り組む企業・団体が参加するイベントです。プレイドにおいても、<a href="https://pdf.irpocket.com/C4165/RzLT/uAgQ/HejY.pdf#page=47">IR資料</a>で中長期成長に向けた主要な取り組みの一つとして「データ分析/活⽤に⼤規模⾔語モデル(LLM)などの新しいAI技術を本格活⽤」を掲げ、さまざまな取り組みを進めています。<br>
<img src="https://ik.imagekit.io/plaid/0b0eaedf-e21e-4d2f-b982-e3cf0b1ca3f4/plaid_ir_24-2_P47(1).png" alt="plaid_ir_24-2_P47(1).png"></p>
<p>ユーザーの行動データの分析と生成AIをかけ合わせて、セグメンテーションの⾼度化・⾃然⾔語によるラベルなどへの活用を進め、またプレイドグループで提供する各プロダクトにおける生成AIの機能的な活用も強化しています。そして、今後のさまざまな活動の加速・拡大に繋げるために、生成AIカンファレンス2024に参加することになりました。</p>
<h2>プレイドの生成AI活用の活動例</h2>
<h3>『生成AIによる次世代のユーザー行動解析』 : Google Cloud主催「Google Cloud Next Tokyo ’23」にて</h3>
<div class="iframely-embed" data-embedded-url="https://cloudonair.withgoogle.com/events/next-tokyo/watch?talk=d2-aiml-03"><div class="iframely-responsive" style="padding-bottom: 52.4126%; padding-top: 120px;"><a href="https://cloudonair.withgoogle.com/events/next-tokyo" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcloudonair.withgoogle.com%2Fevents%2Fnext-tokyo%2Fwatch%3Ftalk%3Dd2-aiml-03&key=878c5bef402f0b2911bf6d4ce6261abd">Google Cloud Next Tokyo ’23</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>PaaSプロダクト「<a href="https://ecosystem.plaid.co.jp/product/karte-craft">KARTE Craft</a>」で作成する汎用プログラムの活用を支援してくれるAIアシスタント「Craft Functions Copilot」</h3>
<div class="iframely-embed" data-embedded-url="https://tech.plaid.co.jp/ms-ai-craft-functions-copilot"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://tech.plaid.co.jp/ms-ai-craft-functions-copilot" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Ftech.plaid.co.jp%2Fms-ai-craft-functions-copilot&key=878c5bef402f0b2911bf6d4ce6261abd">Microsoft の AI 技術 をベースに構成される Craft Functions Copilot</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>『RightTouchのLLM活用のこれまでとこれから』</h3>
<div class="iframely-embed" data-embedded-url="https://blog.righttouch.co.jp/llm"><div class="iframely-responsive" style="padding-bottom: 52.3%; padding-top: 120px;"><a href="https://blog.righttouch.co.jp/llm" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fblog.righttouch.co.jp%2Fllm&key=878c5bef402f0b2911bf6d4ce6261abd">RightTouchのLLM活用のこれまでとこれから</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h1>当日のイベントの様子</h1>
<p>当日は、パネルディスカッションへの登壇とブース出展を行いました。</p>
<h2>パネルディスカッション「日本の生成AIをリードする企業に学ぶ、革新的アプリケーションの創造」</h2>
<p>プレイドからはCTOの牧野 <a href="https://twitter.com/makinoy">@makinoy</a> が参加し、<a href="https://algomatic.jp/">Algomatic</a>の南里 <a href="https://twitter.com/neonankiti">@neonankiti</a> さん・<a href="https://www.ai-shift.co.jp/">AI Shift</a> の青野 <a href="https://twitter.com/brn227">@brn227</a> さんとともに、生成AIカンファレンス運営代表の南野 <a href="https://twitter.com/tentenmitsunori">@tentenmitsunori</a> さんにファシリテートいただきました。LLMを使って世の中にどのように価値を届けていくかについて、「競合との差別化ポイントの作り方」「基盤モデルとの向き合い方」「開発するアプリケーションの決め方」という3つのお題に沿って、プレイドや牧野が考えていることをお話ししました。</p>
<p>参加チケットを購入されている方は、期間限定でアーカイブ動画が視聴できるので、ご参加頂いた方も見逃した方も、改めてぜひご覧ください。</p>
<p><img src="https://ik.imagekit.io/plaid/fdf832ec-69e1-45d7-8e42-ad0b24d17e75/%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-05-1116.01.57.png" alt="スクリーンショット2024-05-1116.01.57.png"></p>
<h2>ブース : 開発中の生成AIを活用したプロダクトデモ紹介</h2>
<p>ブースでは、現在開発中の生成AIを活用したプロダクトデモを複数紹介していました。</p>
<h3>1. Craft Functions Copilot (β版)</h3>
<p>Craft Functions Copilot (β版) は、AIによるプロダクト活用支援機能です。KARTE Craftの使い方や機能開発に関する質問を行うと、その回答やコードの改善提案がリアルタイムで行われます。<br>
<img src="https://ik.imagekit.io/plaid/6de7966d-cb87-4f47-ab5d-a05aacbc6802/s-1280x720_c546f5ab-3a81-47b7-b3bf-3fc04f6defd3.gif" alt="s-1280x720_c546f5ab-3a81-47b7-b3bf-3fc04f6defd3.gif"></p>
<h3>2. RightSupport by KARTEにおける<strong>サポートシナリオの自動生成</strong></h3>
<p>ユーザーのWeb行動から蓄積された統計情報をもとに、特定のページでユーザーに提示すべきFAQ選択肢や、そこに誘導するためのヒアリング項目をLLMを用いて自動生成します。<br>
<img src="https://ik.imagekit.io/plaid/7704dbb6-5f36-4abe-855b-b8a72054ebf5/%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E8%87%AA%E5%8B%95%E7%94%9F%E6%88%90%E7%B0%A1%E6%98%93%E7%89%88002.gif" alt="シナリオ自動生成簡易版002.gif"></p>
<h3>3. 商品閲覧履歴からセッション要約</h3>
<p>ユーザーの商品閲覧履歴からユーザーのそのセッションでの行動を要約したり、そのユーザーに対しての施策アイデアを提供します。<br>
<img src="https://ik.imagekit.io/plaid/6b5b3403-e882-4c04-8a15-6dd90539779c/%E7%94%BB%E9%9D%A2%E5%8F%8E%E9%8C%B2-2024-05-07-21.54.54(1).gif" alt="画面収録-2024-05-07-21.54.54(1).gif"></p>
<h2>ブース運営の工夫</h2>
<p>また、ブース出展においては、イベントに参加されている方に興味持っていただき立ち寄っていただけるような工夫を行いました。<br>
<img src="https://ik.imagekit.io/plaid/0b434906-1342-4729-be95-eaf9d971c6ba/Untitled.jpeg" alt="Untitled.jpeg"><br>
まずは端的に「デモを展示していること」がわかりやすく伝えるために、わかりやすく「生成AIデモ展示中！」と書いたパネルを社内のデザイナーに作成してもらいました。</p>
<p>立ち寄っていただく人が同時に複数いることも想定し、ディスプレイを2台持ち込むことは決めていたので、残りのスペースを最大限活用できる、かつ目立たせられるように、サイズ調整の提案をもらって変形A1サイズで作成しました。<br>
<img src="https://ik.imagekit.io/plaid/65b51dd7-6eda-46a5-8cb8-ed16ad07e20e/Layout.png" alt="Layout.png"><br>
ブースに立ち寄ってくれた方には、今回のために作成したオリジナルキャンディーと、プレイドグループの生成AI関連の除法を集めた<a href="https://recruit.plaid.co.jp/gen-ai-conf-2024">特設ページ</a>のQRコードが入ったカード、ステッカーなどを配布しました。いろいろとアイテムがあることで、イベント参加者の方々と話すきっかけがつくりやすく、とても重宝しました。</p>
<p>カードに記載した「Context Is All We Need.」というメッセージは、『<a href="https://arxiv.org/abs/1706.03762">Attention Is All You Need</a>』をオマージュしてCTOの牧野が考案したものです。立ち寄っていただいた方をはじめ、社内外の評判がとても良かったので、今後プレイドのAI関連のあれこれに使用していくかもしれません。</p>
<p>オリジナルキャンディーはマーケティングチームのノベルティ制作に知見があるメンバーとデザイナーにアイデアを出してもらい、<a href="https://candy-showtime.com/order/">CANDY SHOW TIME</a>さんに制作を依頼しました。見た目の区別はつきませんが、実は1つの袋に2つの味（フレーバー）の飴が入っています。制作段階で2種類選べたので、Apple味とIchigo味を指定したのですが、そのことを完全に忘れたまま、ブースに立つメンバーにも来場された方にも伝えることなくイベントが終わってしまいました。今後どこかの機会で見かけた際には、プレイドのAIキャンディーとして受け取ってください。<br>
<img src="https://ik.imagekit.io/plaid/5fa09b3b-4a4b-4ca7-bb94-95763bd8fcb5/Untitled(1).jpeg" alt="Untitled(1).jpeg"></p>
<p>今回のイベントでは、セッションが行われるメインホール（1箇所）に隣接する形でブースエリアが設けられており、セッション間の5~10分の休憩時間を中心に立ち寄る方が多くいました。ブースを10箇所まわるとプチギフトがもらえる企画が行われていたり、ブースエリアでフリードリンク配布が行われていたり、来場者がブースに立ち寄りやすくなる仕掛けがされていて、とてもありがたかったです。</p>
<p>そのような企画と、ご来場された方々のモチベーション・興味が高かったこと、プレイドメンバーの熱烈な呼び込み、デモを用意・訴求した甲斐もあり、本当にたくさんの方々にブースにお立ち寄りいただけました。「デモ見てみたいです」とお声掛けいただくことも多く、対応したメンバーの話を聞いて「今まで見たデモで一番おもしろかったです」「（学生なんですが）自分の研究がどう社会に活きるのか、少しイメージが湧きました」など言ってくれる方もいて、参加したメンバーやプレイドにとって良い機会にすることができました。</p>
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr"><a href="https://twitter.com/hashtag/gen_ai_conf?src=hash&amp;ref_src=twsrc%5Etfw">#gen_ai_conf</a> 企業ブースではスタンプラリーを実施し、10このブースを回った方にはオリジナルチロルチョコを景品として配布しておりました🍫✨<br><br>いち早くGetされた方々、おめでとうございます🙌 <a href="https://t.co/IfNxPRYnTu">pic.twitter.com/IfNxPRYnTu</a></p>&mdash; 生成AI Conf実行委員会 (@gen_ai_conf) <a href="https://twitter.com/gen_ai_conf/status/1788110926694281322?ref_src=twsrc%5Etfw">May 8, 2024</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<h1>おわりに</h1>
<p>生成AIカンファレンスにご来場いただいた皆さん、セッションを視聴いただいた皆さん、本当にありがとうございました。</p>
<p>そして、イベントの企画・運営をしていただいた皆さん、素晴らしいイベントに関与させていただきありがとうございました。準備段階の相談・質問にも丁寧に対応していただいたおかげもあり、スムーズに準備・参加することができました。何よりも会場全体が熱気溢れていて、スポンサーという立場に限らず楽しく刺激あるイベントで最高でした。</p>
<p>今後もプレイドでは生成AI技術をはじめ、さまざまな領域・シーンで存在感を強めていけるように、面白い開発や企画に取り組んでいきます。Xアカウント (<a href="https://twitter.com/PLAID_Tech">@PLAID_Tech</a>)などで情報発信していきますので、ぜひフォローをお願いします。<br>
<img src="https://ik.imagekit.io/plaid/cc787854-1af3-44a8-8c8c-06727820ea92/Untitled(2).jpeg" alt="Untitled(2).jpeg"></p>
<h2>関連リンク（活動例の続き）</h2>
<h3>『AI時代に人は制約から解き放たれる。その先にある社会像と企業像』</h3>
<div class="iframely-embed" data-embedded-url="https://dhbr.diamond.jp/articles/-/10441"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://dhbr.diamond.jp/articles/-/10441" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fdhbr.diamond.jp%2Farticles%2F-%2F10441&key=878c5bef402f0b2911bf6d4ce6261abd">AI時代に人は制約から解き放たれる。その先にある社会像と企業像 | テクノロジー｜DIAMOND ハーバード・ビジネス・レビュー</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>『効率競争から価値競争の時代へ、人のポテンシャルを解放するAI実装のあり方』</h3>
<div class="iframely-embed" data-embedded-url="https://dhbr.diamond.jp/articles/-/10443"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://dhbr.diamond.jp/articles/-/10443" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fdhbr.diamond.jp%2Farticles%2F-%2F10443&key=878c5bef402f0b2911bf6d4ce6261abd">効率競争から価値競争の時代へ、人のポテンシャルを解放するAI実装のあり方 | A New Era of CX｜DIAMOND ハーバード・ビジネス・レビュー</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>『KARTE CraftにおけるLLM活用~Craft Functions Copilot~』 : 「Microsoftと語る LLM実装の最前線」にて</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="KARTE CraftにおけるLLM活用~Craft Functions Copilot~" src="https://speakerdeck.com/player/d9f4d037b34044e4b688034987891ad2" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h3>『生成AIによるカスタマーサポート変革：ウェブチャットの業務生産性 &amp; CX向上』 : Google Cloud主催 「Generative AI Summit Tokyo '24」にて</h3>
<div class="iframely-embed" data-embedded-url="https://cloudonair.withgoogle.com/events/generative-ai-summit-24q1?talk=24-t1-session4"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://cloudonair.withgoogle.com/events/generative-ai-summit-24q1" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcloudonair.withgoogle.com%2Fevents%2Fgenerative-ai-summit-24q1%3Ftalk%3D24-t1-session4&key=878c5bef402f0b2911bf6d4ce6261abd">Generative AI Summit Tokyo &#39;24：生成 AI の「体験」から「活用」へ！</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<h3>エモーションテックのテキストAI分析サービス「TopicScan︎®︎」</h3>
<div class="iframely-embed" data-embedded-url="https://emotion-tech.co.jp/topicscan/"><div class="iframely-responsive" style="padding-bottom: 52.5%; padding-top: 120px;"><a href="https://emotion-tech.co.jp/topicscan/" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Femotion-tech.co.jp%2Ftopicscan%2F&key=878c5bef402f0b2911bf6d4ce6261abd">TopicScan – テキストAI分析サービス ｜ 株式会社エモーションテック</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドは、2024年5月8日に開催された「[生成AIカンファレンス2024](https://gen-ai-conf.org/)」にシルバースポンサーとして参加しました。今回は、当日のイベントの様子やプレイドとして行ったことを紹介します。

生成AIカンファレンス2024 参加レポート_プレイドエンジニアブログ

生成AIカンファレンス2024 参加レポート

<h1>はじめに</h1>
<p>こんにちは。<a href="https://twitter.com/calloc134">calloc134</a> といいます。<br>
情報工学系の学生で、普段は Web アプリケーション開発について学習しています。</p>
<p>今回、2024年2月から3月の5週間、プレイドでソフトウェアエンジニアとしてインターンシップを行いました。<br>
この記事では、インターンシップの振り返りとともに、学んだことや感じたことをまとめていきたいと思います。</p>
<h1>インターンシップ開始まで</h1>
<p>当インターンシップは、知り合いから紹介をいただいたことがきっかけで始まりました。<br>
自分は今までインターンシップを経験したことがなく、実務経験もありませんでした。<br>
プレイドのインターンでは、任される開発業務に必要な範囲で、社員さんと同じ環境・同じシステムに対して開発・コーディングを行うことができるという特徴がありました。<br>
この特徴は、実際の開発現場でどのように開発が進められているかを知りたい自分にとって、非常に魅力的でした。<br>
そのほか、技術領域が自分の普段の学習と近いことや、エンジニアインターンではフルリモートでも勤務でき、都心住みでない自分でも働きやすいことなどが決め手となりました。</p>
<p>インターン開始前にカジュアル面談を行い、簡単な技術スタックと業務内容について説明を受けました。<br>
プレイドでは、担当するプロダクトによって開発チームが分割されています。<br>
自分はMessageチームに入ることになったので、そのチームでの業務内容について説明を受けました。</p>
<p>Message チームは <a href="https://karte.io/package/message/">KARTE Message</a> というプロダクトを開発しています。<br>
当プロダクトは、データを元にメールやプッシュ配信、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h1>技術スタック</h1>
<p>Message チームの技術スタックについては、同じ Message チームの方が書かれた<a href="https://tech.plaid.co.jp/intern-at-plaid-yurihttps://tech.plaid.co.jp/intern-at-plaid-kenshin">こちら</a>のブログ記事が参考になると思います。</p>
<p>簡単に解説すると、下記のような技術スタックになっています。</p>
<ul>
<li>フロントエンド
<ul>
<li>Vue(メイン)</li>
<li>React (一部メニュー)</li>
</ul>
</li>
<li>バックエンド
<ul>
<li>サーバサイド Node.js / Express.js</li>
<li>Golang</li>
<li>Java</li>
</ul>
</li>
<li>インフラ
<ul>
<li>MongoDB (データベース)</li>
<li>Redis</li>
<li>Cloud Pub/Sub</li>
<li>GKE (Google Kubernetes Engine)
<ul>
<li>ArgoCD (デプロイ)</li>
</ul>
</li>
</ul>
</li>
<li>DevOps
<ul>
<li>GitHub Actions</li>
<li>CircleCI</li>
</ul>
</li>
<li>監視
<ul>
<li>Sentry</li>
<li>Datadog</li>
</ul>
</li>
</ul>
<p>また、開発については、下記の技術を使用していました。</p>
<ul>
<li>Git/ GitHub (コード管理)</li>
<li>Docker Compose (開発環境)</li>
<li>Kind (Kubernetes in Docker)</li>
</ul>
<p>自分にとって、このインターンが初めてのエンジニアとしての実務経験となります。<br>
そのため、技術レベルも含めて最初はインターンで活躍できるかすごく不安でした。</p>
<h1>インターンの内容</h1>
<h2>最初の二日間</h2>
<p>インターン開始してすぐの二日間は、自分の開発環境を整えることから始まりました。</p>
<p>まず開発環境セットアップの資料を確認してインストールを行ったのですが、リポジトリの更新や仕様の変更により、資料と異なる部分がありました。また、資料に存在しないような issue に遭遇することがしばしば起こりました。</p>
<p>そこでSlack に開発環境構築専用のチャンネルが存在したため、そこにスレッドを立てて技術チームに質問を行いながら、一つずつ課題を解決していきました。<br>
フルリモートで意思疎通が難しくなるかもと心配していましたが、チームメンバーの皆さんが迅速に対応してくれたため、スムーズに進めることができました。<br>
また、解決した課題は、times と呼ばれる自分専用のメモ書きチャンネルにまとめていくことで、後から振り返りが容易になるようにしました。</p>
<p>一通り開発環境の構築が完了した後、開発環境構築の手引きとして社内ドキュメントを執筆しました。新しく入ったインターン生が同じような問題に遭遇した際に、自分の経験が役立つことを願っています。</p>
<h2>タスク</h2>
<p>開発環境の構築が完了した後、実際に開発に取り組むことになりました。</p>
<p>5週間という比較短い期間の中でもさまざまなタスクに着手してきましたが、ここでは一番印象に残ったタスクをピックアップし、振り返りたいと思います。</p>
<h3>LINEコンテンツのサムネイル生成機能</h3>
<p>KARTE Messageでは、メール、プッシュ配信、またはLINEを用いてユーザにコンテンツを送信することができます。</p>
<p>コンテンツの保存時に自動的にコンテンツのサムネイル画像を生成し、プレビューすることができる機能が存在するのですが、この機能が実装されているのはメール配信とプッシュ配信のみであり、LINE には実装されていませんでした。</p>
<p>そこで、LINEコンテンツのサムネイル画像を生成する機能を実装することになりました。</p>
<p><img src="https://ik.imagekit.io/plaid/f65747e2-4ff0-4320-ac33-48a8f6cd8c5e/Untitled(1).png" alt="Untitled(1).png"></p>
<p>タスクに取り組むにあたり、はじめに現状のサムネイル生成機能を理解するところから始めました。</p>
<p>まず管理画面上でコンテンツが保存されたタイミングでpubsubのキューにHTML と CSS の情報がメッセージとして登録されます。<br>
サムネイル生成用サービスがそのメッセージをsubscribeしており、メッセージの内容からサムネイル画像を生成する、というシンプルな構成でした。<br>
具体的には、メッセージから取り出した HTML と CSS の情報をpuppeteerでレンダリングし、レンダリング結果のスクリーンショットを生成、S3のsignedURLを用いてS3に保存します。</p>
<p><img src="https://ik.imagekit.io/plaid/b7ded338-bbcd-49b9-a48e-b50fa26298fd/Untitled(2).png" alt="Untitled(2).png"></p>
<p>ではLINEコンテンツのサムネイル生成機能を実装するためにはどのような実装が必要なのでしょうか。</p>
<p>現状の構成では、サムネイル生成用サービスのインターフェースはHTMLとCSSとなっています。</p>
<p>一方で、管理画面で表示しているコンテンツのプレビューはReactやTailwind CSSといったフレームワークを用いて描画しているため、ここからなんとかして等価のHTMLやCSSを生成する必要があります。<br>
あるいは、サムネイル生成用サービスを改修し、Reactコンポーネントを描画する方法もとりえます。<br>
<img src="https://ik.imagekit.io/plaid/3e8f31ec-5a52-4e93-9deb-30b69085fbf7/Untitled(3).png" alt="Untitled(3).png"></p>
<p>上記に加え、さらにいくつか設計の選択肢をリストアップし、メリットとデメリットを比較してみました。<br>
<img src="https://ik.imagekit.io/plaid/4edc16e3-5bc3-45fc-85d7-a02d22801e60/Untitled(4).png" alt="Untitled(4).png"></p>
<p>まず、一番目と二番目の選択肢は実装が難しいと感じたため、採用を見送りました。</p>
<p>そこで三番目の選択肢で実装を進めていましたが、画像がロード中の表示のままサムネイル生成されてしまう可能性があるという問題が発生しました。</p>
<p>これはサーバサイドでのReactコンポーネントのレンダリングの場合、画像の描画に時間がかかってしまうことが原因でした。<br>
従って、最終的に四番目の解決策である、クライアント側の React コンポーネントの HTML を取得してレンダリングする方法を採用しました。</p>
<p>クライアントサイドにおいて、React Componentの描画結果のHTMLはuseRefを利用することで簡単に取得できました。</p>
<pre><code class="language-tsx"> 	const previewHTMLRef = useRef&lt;HTMLDivElement&gt;(null);
 	const previewHTML = previewHTMLRef.current?.innerHTML

  return (
    &lt;&gt;
      &lt;LineEditorPreview controller={controller} previewHTMLRef={previewHTMLRef} /&gt;
    &lt;&gt;
  )
</code></pre>
<p>またスタイリングにはTailwindCSSを用いていたため、プレビューのコンポーネントで適用されているTailWindCSSのクラスをあらかじめビルドしておけば、プレビューに使われているCSS を生成することができます。</p>
<p>TailwindCSS は CLI での呼び出しに対応しており、構成ファイルを指定して手動コンパイルを行いました。</p>
<p>今回は、LINE プレビューに関連するコンポーネントを全て指定した構成ファイルを作成し、TailwindCSS CLI でビルドを行うことで、CSS を生成しました。</p>
<pre><code class="language-tsx">// 構成ファイル

/** @type {import('tailwindcss').Config} */
module.exports = {
  presets: [require('@plaidev/sour-react/tailwind')],
  content: [
    './src/page/template-edit/line-editor/preview.util.tsx',
    './src/page/template-edit/line-editor/preview.tsx',
  ],
  variants: {
    extend: {},
    animation: [],
  },
};
</code></pre>
<pre><code class="language-bash"># TailwindCSS CLI
tailwind -o path/of/output -c path/to/config -m
</code></pre>
<p>最終的にあらかじめ生成しておいたCSSをサーバー側で保持しておき、クライアントサイドから送られてくるHTML情報と合わせてpubsubに登録することで、LINE コンテンツのサムネイル画像を生成することができました。</p>
<p><img src="https://ik.imagekit.io/plaid/ec4733fa-d507-427b-bf8d-1bdd8cbdb5be/Untitled(5).png" alt="Untitled(5).png"></p>
<h1>インターンを振り返って</h1>
<p>社員さんと同じ環境で開発を行っていくことで、自分の中における仕事に対する解像度が上がったと感じています。<br>
これまでは個人的な開発しかしてこなかったため、自身のスキルが社会に出てから実際に活かすことができるのか不安でした。<br>
しかしプレイドのインターンシップを通じて、今まで学習してきたスキルが仕事に活かせることを実感し、また必要なスキルをどのように向上させていけばよいのかを学ぶことができました。</p>
<h2>インターンから得た学び</h2>
<h3>コーディングについての学び</h3>
<p>一例としては、コードの可読性やコメントの重要性を学びました。<br>
これまでの開発では自分がわかりやすいようなコメントや変数名を付けることが多かったのですが、プレイドではロジックの背景を意識したコメントや変数名を付けることが求められ、普段の開発でもこれらの意識を持って開発を行うようになりました。</p>
<h3>ロジックの理解</h3>
<p>また、ロジックを理解する大切さについても学習しました。<br>
挙げられた issue に関して場当たり的な修正は簡単に見えても、その根本的な原因は別のところにあることが多く、ロジックを含めて全体を理解することが重要であると感じました。</p>
<h3>issueの理解</h3>
<p>タスクの内容を深く理解することも重要です。</p>
<p>タスクは基本的に ~ ができない　のような課題形式で書かれているのですが、その解決には様々な方法が考えられます。その中でもどういった仕様が良いのかを正しく導くためには、既存ロジックの理解に加え、ドメインや顧客の理解も非常に重要となってきます。<br>
プレイドでは仕様に関するディスカッションも頻繁に行われるため、こういった能力も養うことができました。<br>
コーディングならAIでもできるようになってきている時代において、仕様設計はますます重要になると考えており、今後も磨いていきたいと思っています。</p>
<h1>インターンの特徴</h1>
<p>プレイドのインターンの特徴を以下にまとめました。</p>
<ul>
<li>実際のエンジニアと同じチームでプロダクト開発を行う</li>
<li>社員と同じ一連の開発フロー(issue アサインと方針の整理、修正とデプロイ、動作確認まで)</li>
<li>技術力に応じてコア開発に近いタスクへのアサインも可能</li>
</ul>
<h2>こんな人におすすめ</h2>
<ul>
<li>実際の開発現場で、開発のサイクルを学びたい</li>
<li>技術力を向上させたい・フルスタックで活躍したい</li>
<li>課題解決力の向上・設計・実装・運用までの幅広い業務経験を積みたい</li>
</ul>
<h1>まとめ</h1>
<p>自分にとって初めてのインターンでしたが、実際の開発を通して色々なことを指導していただき、無事やり遂げることができました。<br>
お世話になった社員さん、インターン生の皆さん、本当にありがとうございました。<br>
今後もこの経験を活かして、さらに活躍できるようなエンジニアを目指していきたいと思います。</p>
<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>

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot の仕組みとその中で利用されている Azure サービスの役割について説明します。

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot

<p>こんにちは、エンジニアの白木です。</p>
<p>2023年4月 - 2024年2月までインターンとして開発に携わりました。</p>
<h2>自己紹介</h2>
<p>分散システム、データベースについて勉強しています。<br>
最近は、NewSQL、MPPデータベース、io_uring に最適化したデータベースの勉強をしています。</p>
<h2>プレイドのインターンに参加した理由</h2>
<p>プレイドの存在を知ったきっかけは<a href="https://bootjp.me/2023/independence_for_next/">ブログ記事</a>で、そこで大規模な分散システムを開発・運用していることを知りました。<br>
今まで分散システムを プロダクトに応用している例を身近で見たことがなかったため、 CX （Customer Experience）プラットフォームである KARTE を提供しているプレイドに興味を持ちました。そのような中、プレイドがインターン募集をしているを知り、是非参加したいと思い応募しました。</p>
<h2>インターンに入る前の前提知識の話</h2>
<p>インターンに入る以前は データ処理に関する知識は深く持っていませんでした。<br>
大規模データにおける分散処理フレームワークの Apache Hadoop、Apache Spark を用いたデータ処理について少しだけ知っていました。そのため、バッチ処理、ストリーム処理に関する 何となくのイメージがついていました。ただ、データ解析基盤を手を動かして作った経験はなく、どういったアーキテクチャで実装しているかのイメージが全くついていませんでした。<br>
データベースに関しては、MySQL、PostgreSQL などのOLTP(Online Transaction Processing) の処理向けのデータベースについては知識はありましたが、BigQueryのようなDWH (Data Warehouse) や OLAP（Online Analytical Processing) 向けのデータベースの知識は持っていませんでした。<br>
そのため、大規模データを処理するためにどのようなアーキテクチャで構築しているのか、大規模な解析用途で使われている データベースを扱えることが非常に楽しみにして参加しました。</p>
<h2>インターンで開発した内容の話</h2>
<p>インターン開発タスクの一つとして、KARTEのリアルタイム解析基盤に関わるAPIの改善を行いました。具体的にいうと、ユーザーの行動解析結果を取得するAPIが常に最新情報を返すようにするというものです。リアルタイム解析基盤の詳細については以下記事を参考にしてください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析</a></li>
</ul>
<p>タスクの説明を受けた際に、該当のAPIについて「強整合性モード」を実現したいという話を聞き、「結果整合性」、「強整合性」という概念を正しく理解するところから始めました。<br>
結果整合性では、データ読み込み時に最終的に全ての更新が反映されることを保証するものの、即時ではないため古いデータを返す可能性があります。強整合性においては、データ読み込み時に全ての更新が反映されたデータが返ってくることを保証します。<br>
今までビッグデータの処理の文脈で見る BASE特性、また、Apache Cassandra が採用している整合性モデルであることから概念自体は理解できました。しかし、どう実装するかについてイメージができていませんでした。<br>
最初はリアルタイム解析基盤の実装部分やインフラの構成図を元にどう実装するかを考えようとしましたが、どう実装するかのイメージはつかないばかりでした。そこでリアルタイム解析基盤の概略について書かれた<a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">こちらの記事</a>を読み直し、大枠のロジックの理解に努めました。</p>
<p><img src="https://ik.imagekit.io/plaid/e52a44f2-f17c-467e-86c4-71e04bdbaeb4/Untitled.png" alt="Untitled.png"><br>
<em>Blitz の強整合を実現している図</em></p>
<p>結果、この図に強整合を実現するロジックが詰め込まれていることが理解できました。Realtime Queue にイベントを書き込んでおき、 Backend Servers で まだユーザーデータに反映されていないイベントを動的に遡求していくことで常に最新のデータを読み込めるという強整合性を実現していました。このアーキテクチャは今まで自分では想像ができなかった部分だったので、すごい仕組みだなと興奮しました。<br>
一度コンセプトを理解してしまえば、APIの実装部分も未反映のイベントを Realtime Queue から取得をして動的にユーザーデータを最新化すればいいという実装イメージが湧き、強整合性モードの実現も無事行うことができました。</p>
<h2>インターンで開発してみて得られた知見・経験</h2>
<h3>分散システムを用いた設計についての知見を得られた</h3>
<p>KARTE では秒間最大 13万4千イベント、月間 180PB を超える解析を行なっています。それを支えるプレイド独自のリアルタイム解析基盤は大規模な分散システムであり、アーキテクチャ上の工夫が随所に見られます。<br>
例を挙げると、リアルタイム解析で結果を同期的に配信するレイテンシー重視な処理と裏側でデータを溜めて一気に更新するスループット重視な処理を完全に分けて考えている点です。ここまで大規模かつシビアなパフォーマンスが求めれる環境だと、目的別にコンポーネントを分離することで、コスト最適化や柔軟なスケーラビリティが可能になっているなと感じました。<br>
分散システムを本で学習していても設計意図を肌で理解できず、中々身につかないなと思っていました。今回、インターンで実務を通じて分散システムに携わることでプロダクトと分散システムが結び付き、理解が深まりました。また、分散システムを通じて価値提供できる面白さを感じることができました。</p>
<h3>プロダクト・ビジネスへの貢献を意識した開発ができる</h3>
<p>プレイドのエンジニアは、技術的にかなり尖っています。しかし、技術だけを見ているだけでなく、プロダクト・ビジネスにも強くフォーカスしています。そのため、日々のタスクに関してもどのようにすれば最もプロダクト・ビジネスに貢献できるかを強く意識しています。例えば、単にプログラムを修正してタスクを完了するのではなく、将来的にどういった構想になっていれば良いかを意識してタスクに取り組んでいます。これによって、アーキテクチャの複雑度を下げています。ただ単にタスクを素早く終わらせる簡単な方法を取るだけでなく、将来までを意識して必要なコストは割いているのは、今後エンジニアとして働く上で学ぶべきことがありました。</p>
<h3>現場のエンジニア・ビジネスの方とディスカッションできる</h3>
<p>プレイドのインターンでは社員と同様の裁量を与えられてタスクに取り組めます。そのため、タスクに関しても現場の社員と同様にディスカッションできます。ディスカッションをすることでプレイドの社員の方の考えが分かり、タスクを進めるにあたりどういったことを意識すればいいのかを知れます。例えば、将来的に見ると価値は高いが直近だと賛否両論が生まれる機能をリリースする攻めの手を打つか、そういった手は打たず保守的な実装をするべきかについて、トレードオフを意識してタスクに取り組むことの重要性、締め切りが迫っている場合にどういったマインドでタスクに取り組むべきかなど、今後のエンジニア人生で大事なことをディスカッションを通じて学べました。</p>
<h3>仕事にやりがいを持っている社員と働ける</h3>
<p>プレイドの社員の方は仕事にやりがいを持っています。社員の方とお昼を一緒にしていると、どの方も楽しそうに仕事に関する話をします。楽しそうにやっている方、事業を本気で成長させようとしている方々と働ける経験は大事です。自分もこのように仕事に対してやりがいを持って働けるようになりたいと思えるようになりました。</p>
<h3>目的達成のためならばどのような技術でも扱う</h3>
<p>手を動かす Web エンジニアは大きく「フロントエンド」、「バックエンド」、「インフラ」などに分かれているところが多いと思います。プレイドでは、プロダクト・ビジネスにインパクトを与えるためならば、エンジニアはこれらの役割に囚われません。どのような領域の技術であっても役割に依らずタスクに取り組みます。役割に囚われずに 貢献していく姿勢は、人にタスクを依頼するコストを減らすことができ、高い生産性を出す上で大事だと感じました。このマインドは私も今後も続けていきたいです。また、どのような技術でも扱うため技術的な刺激を受ける機会がたくさんあります。自身も成長できる素晴らしい環境でインターンできました。</p>
<h2>最後に</h2>
<p>インターンを通じて、分散システムなどの技術的な成長を得られただけでなく、タスクを進めるにあたって考えるべきこと、エンジニアとしてのマインド、モチベーション高く働ける環境への解像度が高くなりました。</p>
<p>プレイドのインターンではエンジニアとして大きく成長できると思います。<br>
興味のある方は下記から応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

<p>株式会社プレイドのCore Platformチームに所属しているBrownです。今回のブログでは2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。</p>
<h1>前提となるプレイド社内でのデータの管理方法</h1>
<p>プレイドでは、CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」の計測タグ経由で収集したイベントデータを元にWeb上のユーザーの行動を分析するサービスに加え、クライアント企業が社内外に保有する多種かつ大量なデータをKARTEに統合・連携して利活用できる<a href="https://karte.io/feature/integration/">KARTE Datahub</a>（以下、Datahub）を提供しています。<br>
KARTEの内外に散らばったサイロ化されたデータをDatahubに集約して、KARTEのプロダクトの中でユーザーのセグメントに活用したり、WidgetやKARTE内のアクション機能から参照したりすることができます。<br>
<img src="https://ik.imagekit.io/plaid/46c800d9-dd3d-4ff1-a605-a2cd7272ace9/datahub_case01_image-1.webp" alt="datahub_case01_image-1.webp"><br>
<em><a href="https://cxclip.karte.io/casestudy/tips/datahub_case01/">「KARTE Datahubに蓄積した様々なデータを活用する｜KARTE Datahub事例集 vol.1</a>」より引用</em></p>
<p>Datahubでは、KARTEに関わらず様々なデータの統合・利活用するプラットフォームであるため、他のKARTEのProductとデータの取り扱いを区別する必要があります。</p>
<h1>プレイドでのデータ共有</h1>
<p>データへのアクセスの安全性を高めるために、Datahub以外のKARTEのプロダクトから、クライアント企業の許諾なく直接Datahubに連携されたデータを参照することはできません。<br>
そのため、クライアント企業から許諾を受けたデータのみを、Datahub以外のプロダクト側に共有することで、イベントデータと組み合わせて使用したり、加工済みデータを生成しています。</p>
<p>また、データ連携の際に使用するBigQueryのDataset（以下、Dataset）やGCPのサービスアカウント（以下、SA）はクライアント企業ごとに分離されており、例えば、企業AのSAではその企業AのDatasetのみが操作でき、それ以外のクライアント企業のDatasetへの権限は一切持ちません。</p>
<h1>従来のDatasetの共有方法の問題点</h1>
<p><img src="https://ik.imagekit.io/plaid/26051d0a-c445-4260-90ff-0c084d3f9bfc/image1.png" alt="image1.png"></p>
<p>従来の仕組みでは、クライアント企業がDatahubを通じてKARTEにインポートしたデータを、Datahub以外のプロダクトから利用する場合には、KARTE Data LayerのSAがDatahub Data Layerに直接アクセスできないため、そのDatasetのデータを含めてKARTE Data Layerにコピーする必要がありました。<br>
この方法では、明示的に必要なDatasetだけをKARTE Data Layerに共有できる反面、以下の二点の問題があります。</p>
<ul>
<li>KARTE Data Layerにコピーされた後のDatasetへのアクセス権限を持つSAの管理・監視が煩雑</li>
<li>Origin DatasetからShared Datasetへ定期的にデータをコピーする必要がある</li>
<li>Origin Dataset・Shared Dataset双方でストレージコストがかかる</li>
</ul>
<h1>Analytics Hubを用いて問題点を改善</h1>
<p>まず前提として、Analytics Hubでは以下の構成によりDatasetを共有することができます。各権限の詳細は<a href="https://cloud.google.com/bigquery/docs/analytics-hub-grant-roles?hl=ja">公式ドキュメント</a>をご覧ください。<br>
<img src="https://ik.imagekit.io/plaid/c0d7cca4-fe2a-4291-90c9-24d0d260a7e4/image3.png" alt="image3.png"><br>
<em><a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction#subscriber_workflow">Introduction to Analytics Hub</a>より引用</em></p>
<ul>
<li>Publisher : 共有元となるDatasetを持つGCP Project</li>
<li>Data Exchange : Publisherが共有対象となるListingを作る場所</li>
<li>Listing : PublisherがData Exchange内に作成した、共有対象となるDatasetのリストで、SubscriberはこのListingへの <code>roles/analyticshub.subscriber</code> 権限を持つ</li>
<li>Subscriber : Analytics Hub経由で共有されたLinked Datasetを使う側を指し、このSubscriberはListingをSubscribeすることでLinked Datasetを自分のGCP Project内に作成する</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ea657c14-c835-4176-8c15-616c4be357dc/image2.png" alt="image2.png"></p>
<p>Analytics Hubを通じてDatasetを共有することで、Datasetのデータ実体はKARTE Data Layerに共有することなく、Origin Datasetの内部にあるデータと同じものをShared Datasetに対してクエリを実行することで取得できます。この時、Origin Datasetに対して権限を持っているGCPのService Accountのみが共有対象のAnalytics HubのListingを作ることができるように権限管理をしているため、Data ExchangeはDatahub Data Layerに置いています。<br>
Analytics HubでDatasetを共有することで、従来のSAで直接共有する形式では見えずらかった、共有先での使用状況や、共有先が明確になりました。<br>
また、データコピーの必要がなく、かつストレージはOrigin Datasetにのみ課金されるため、上記の2点の問題点が両方とも解決できます。</p>
<h1>セキュアなデータガバナンスの取り組み</h1>
<p>KARTE Data Layerに一度共有されたDatasetは、そのクライアント企業がKARTEの他のプロダクトから利用することができます。しかし、一度共有したDatasetであっても、何かの事情がありそのDatasetをKARTEの他のサービスへ共有停止したいというケースもあります。<br>
そのような際には、Analytics HubのPublisher側でそのDatasetのSubscriptionを削除する、Subscriber側で共有されているDatasetを削除するなど、いずれの方法でも瞬時に共有を停止できます。<br>
また、現在共有されているDatasetをListingから取得できるため、共有中のDatasetのListingへ監視を入れておくことで、意図せずDatasetが共有されてしまっているという状態をすぐに検知することも可能です。</p>
<h1>実際にAnalytics Hubを使ってみて</h1>
<p>Analytics Hubでは、一般公開されているDatasetをSubscribeして使うことや、異なる組織間でDatasetをセキュアに共有しつつ、クエリに対する課金も分離するという用途のみならず、同一組織内でもデータガバナンスの観点で、データへのアクセス権限を管理したり、特定のDatasetのみを特定の目的で他のGCPのプロジェクトへ共有して使うという用途でも使いやすい機能だと思いました。<br>
しかし、まだAnalytics Hubも出たばかりの機能ということで、以下の機能に関して改善が行われると、より使いやすい機能になると感じました。</p>
<ul>
<li>Listingを消した時に自動でLinked Datasetも削除されること</li>
<li>共有用URL経由でLinked Datasetを作成できるGCPプロジェクトを限定したい
<ul>
<li>Service Accountの権限で制限をかけることもできるが、Service Accountの権限設定ミスで想定外のGCPプロジェクトのSAが権限を持ってしまった場合に備えて、Listingごとに共有先として許可するGCPプロジェクトを指定したい</li>
</ul>
</li>
<li>Node.js API Clientの拡充</li>
</ul>
<p>上記のように改善点はいくつかあるものの、KARTEのデータガバナンスを強化する機能としては非常に有効な機能なので、今後も使用箇所を増やしていこうと思っています。</p>


2022年頃より使用可能になった、BigQueryのAnalytics Hubを用いた、安全なデータ共有の導入について紹介します。 

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有 - PLAID engineer blog

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

Engineer Blog

Recent Article

Azure OpenAI Service Dev Day に登壇しました

セルフホストしているMongoDBをMongoDB Atlasに移行した話

Platform Engineering Kaigi 2024登壇レポート

インターンシップで全社のMongoDBをアップデートした話

BigQueryの分散処理の仕組みを深掘りする

生成AIカンファレンス2024 参加レポート

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術をベースに構成される Craft Functions Copilot

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

Popular Articles

Popular Tags

Archives

Writers

Recent Article

Azure OpenAI Service Dev Day に登壇しました

セルフホストしているMongoDBをMongoDB Atlasに移行した話

Platform Engineering Kaigi 2024登壇レポート

インターンシップで全社のMongoDBをアップデートした話

BigQueryの分散処理の仕組みを深掘りする

生成AIカンファレンス2024 参加レポート

プレイドインターン体験記: はじめての開発インターンを通じて得た学び

Microsoft の AI 技術 をベースに構成される Craft Functions Copilot

プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び

BigQuery Analytics Hubを使った透明性が高くセキュアなデータ共有

Popular Articles

Popular Tags

Archives

Writers

Microsoft の AI 技術をベースに構成される Craft Functions Copilot