Engineer Blog

Taira Ouchi

Yuta Azumi

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>この記事は、社内の生成AI LT会（<a href="https://tech.plaid.co.jp/plaid-generative-ai-lt-report">LT会に関するブログ</a>）で「誰でもできるvibe-coding」と題した発表内容を基に、AIに執筆させています。</p>
<h2>はじめに</h2>
<p>こんにちは、プレイドのKARTE Messageチームでエンジニアをしている大内です。</p>
<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>や、<a href="https://tech.plaid.co.jp/complex_logic_to_dynamically_generate_sql">機能改善により開発スピードが向上したことを紹介した記事</a>がありますので、そちらも併せてご覧ください。</p>
<p>私たちMessageチームでは、開発の生産性をさらに高めるために、エンジニア以外のメンバーもAIを活用して開発を行う取り組みを進めています。この試みは多くの可能性を秘めている一方で、「レビュワーの負担が増えすぎる」という課題も明らかになりました。</p>
<p>この記事では、その課題にどのように取り組み、改善を進めているかご紹介します。</p>
<h2><strong>AI開発の幕開けと、見えてきた課題</strong></h2>
<p>チームのプロダクトマネージャー（以下、PMとします）が生成AIを使い、次々と実装を始めたのがことの始まりでした。AIによってコードが効率的に生み出され、ローカル環境で動作確認ができれば、機能が形になるという事実は、開発のスピード感に大きなインパクトを与えました。</p>
<p>その結果、PMは多くのPRを作成。この1ヶ月だけでも、<strong>レポート機能の改善、AI連携機能の強化、リスト表示のUI刷新、多岐にわたる機能改善</strong>に関するPRがマージされました。</p>
<p>一方で、この新しい開発スタイルは、いくつかの運用上の課題も浮き彫りにしました。</p>
<ul>
<li><strong>エンジニアのレビュー負荷増大</strong>：エンジニアから見ると、「開発の意図や目的が必ずしも明確でない大量のコード」をレビューする必要が生じた。</li>
<li><strong>AI生成コードの品質</strong>：AIは既存のコードベースを完全に理解しているわけではないため、「動作はするものの、品質面では改善の余地がある」コードを生成してしまうことがあった。例えば、既存コードの再利用が不十分であったり、実装方針の変更時に古いコードが残ってしまったりするケースがある。</li>
</ul>
<p>レビュワーからは、特に以下の点が負担増の原因として挙げられました。</p>
<ul>
<li>PRにおける差分量の増加があった。</li>
<li>「まず実装してみる」という進め方だったため、設計やセキュリティリスクに関する検討がコードレビュー段階に集中し、レビューの負担が増した。</li>
<li>AIが生成したコードの意図を読み解くのに時間がかかることがあった。</li>
</ul>
<h2><strong>課題解決への道のり：プロセスの見直しと改善</strong></h2>
<p>これらの課題に対応するため、私たちは以下の改善策に取り組んでいます。</p>
<ol>
<li><strong>「仕様ドキュメント」の事前作成とレビュー</strong>：開発着手前に「仕様ドキュメント」を作成し、エンジニアがレビューするフローを導入。これにより、設計段階で問題点を洗い出し、セキュリティ懸念を事前に検討できるため、コードレビュー時には実装そのものに集中できるようになった。</li>
<li><strong>AIによる実装意図のコメント記載</strong>：AIが生成したコードには、可能な限り実装意図をコメントとして記述。これにより、レビュワーがコードの意図を理解しやすくなることが狙い。</li>
<li><strong>PRの適切な分割</strong>：AIによる大量のコード生成に対応するため、PRを機能単位や意味のある変更単位で細かく分割するルールを設けた。仕様ドキュメントで事前に粒度を決めておくことで、レビューの負荷軽減を図っている。</li>
</ol>
<h2><strong>レビュワーから見たAI開発：評価と今後の期待</strong></h2>
<p>AIが生成したコードをレビューする中で、その可能性と課題の両方が見えてきました。</p>
<p><strong>評価できる点</strong></p>
<ul>
<li>既存の複雑な実装がある中でも、動作するコードを生成できる点は注目に値する。特にテストコードの生成精度は高く、品質向上に貢献する可能性がある。</li>
<li>既存の制約がない新規開発の場合、AIが生成するコードは比較的標準的で読みやすい傾向にある。</li>
<li>コードを記述する速度は非常に速く、人間によるレビューがボトルネックになる場合もあるほどである。</li>
</ul>
<p><strong>今後の改善に期待する点</strong></p>
<ul>
<li>既存実装が複雑な場合や、多くの背景情報を理解する必要がある場合、生成されるコードの質がまだ高くないことがある。これは事前の設計ドキュメント作成である程度カバーできると考える。</li>
<li>PRの粒度調整や補足コメントの追加など、実装以外の部分では、まだ人間によるコントロールが必要である。</li>
<li>既存のコードアーキテクチャが一般的でない場合、AIの知識外となり精度が低下する可能性がある。AIを有効活用するには、既存コードも一般的なアーキテクチャに準拠している方が望ましいかもしれない。</li>
</ul>
<p>総じて、AIに開発を完全に任せるのはまだ難しい点が多いものの、工夫次第で品質を向上させることは十分に可能だと感じています。チームとしてこの新しい取り組みに前向きに関わり、改善を続けていくことが重要だと考えています。</p>
<h2><strong>現在の取り組みと、そこから得られた学び</strong></h2>
<p>現在、私たちは以下の対策を中心に進めています。</p>
<p>それは、<strong>「仕様ドキュメント」を事前に作成し、エンジニアのレビューを経たうえで開発に進むフローを確立すること</strong>です。</p>
<p><strong>具体的なフローのイメージ</strong></p>
<ol>
<li>PMが仕様ドキュメントに「背景」「期待する機能」「懸念点」を記述し、「実装方針」についてはAIの支援も受けつつ草案を作成。
<ul>
<li>この時点で、PM自身も実装の概要を把握。</li>
</ul>
</li>
<li>エンジニアが「仕様ドキュメント」をレビュー。
<ul>
<li>これにより、コードレビュー時に仕様の全体像が共有され、手戻りを削減。既存コードの活用など、エンジニアの知見を早期に反映する。</li>
</ul>
</li>
<li>レビュー結果を元に「仕様ドキュメント」を修正し、関係者間で合意。</li>
<li>修正された「仕様ドキュメント」を設計書としてAIに入力し実装。
<ul>
<li>より正確な仕様に基づいてAIがコードを書くことで、誤りを減らす。</li>
</ul>
</li>
</ol>
<p><strong>AI運用の工夫</strong></p>
<ul>
<li>作成した仕様ドキュメントをCursorやCopilotに一時的にルールとして登録し、開発中の参照を容易にしている。</li>
<li>PR作成前に必須のチェックリストを作成し、レビューの負担軽減に努めている。</li>
</ul>
<p>これらの取り組みにより、エンジニアからは「レビューの負担が軽減された」という声も聞かれるようになってきました。（もちろん、まだ改善の余地はあります。）</p>
<p><strong>得られた学び</strong></p>
<p>この経験から、ビジネスサイドとエンジニアが共同で仕様を定義し、開発を進めていくプロセスが、AIの登場によって大きく変わる可能性を感じています。</p>
<p>現在のAIの進化を見ると、いずれ「仕様書＝実装」という未来も現実のものとなるかもしれません。私たちMessageチームは、今後もこの新しい開発スタイルに積極的に取り組み、知見を深めていきたいと考えています。</p>


生成AIで書いたコードをどうレビューしていくか。AIと共存しながら開発しているMessageチームの取り組みを紹介します。

「生成AIで書いたコード、どうレビューする？」Vibe codingと共存する開発プロセス

<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の紹介

<h2>はじめに</h2>
<hr>
<p>こんにちは。プレイドのKARTE Datahubチームでエンジニアをしている安海です。</p>
<p>この記事は「<a href="https://tech.plaid.co.jp/multi-product-audit-log-collection">マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装　- 収集編</a>」の続編です。<br>
前回は監査ログの収集基盤について解説しましたが、今回は収集した監査ログをどのように抽出し、ユーザーに提供しているのか、そのアーキテクチャと技術的な工夫について詳しく解説します。<br>
監査ログの抽出基盤を設計・運用する際に直面した課題と、それに対する解決策を共有することで、同様の課題に取り組むエンジニアの一助となれば幸いです。</p>
<h2>抽出基盤のアーキテクチャ</h2>
<hr>
<p>監査ログの抽出基盤は、「他プロジェクトのデータが混在しない安全性」と「開発者の実装のしやすさ」を両立することを目指して設計されています。具体的には、以下のようなアーキテクチャを採用しています。</p>
<p><img src="https://ik.imagekit.io/plaid/ffa4aa6f-b680-42f2-ace3-661e65c9dfa1/auditlog_table_function_architecture.png" alt="auditlog_table_function_architecture.png"></p>
<h3>なぜテーブル関数を採用したのか</h3>
<p>まず、監査ログの抽出基盤でなぜ <a href="https://cloud.google.com/bigquery/docs/table-functions?hl=ja">BigQueryのテーブル関数</a> を採用したのかについて説明したいと思います。テーブル関数は、SQLクエリをカプセル化し、関数として再利用できるBigQueryの機能です。通常のテーブルと同様にクエリ内で参照でき、さらに引数を受け取れる点が大きな特徴です。<a href="https://cloud.google.com/bigquery/docs/views-intro?hl=ja">ビュー</a>と異なり、実行時にパラメータを渡せるため、同一のロジックを様々な条件で使い回すことができます。</p>
<p>例えば、以下のようにシンプルなテーブル関数を定義できます。</p>
<pre><code class="language-sql">CREATE OR REPLACE TABLE FUNCTION project_dataset.get_project_logs(project_id STRING, start_date DATE, end_date DATE)
AS (
  SELECT *
  FROM `logs.audit_logs`
  WHERE project_id = project_id
    AND DATE(timestamp) BETWEEN start_date AND end_date
);

</code></pre>
<p>このテーブル関数は、クエリから次のように参照できます。</p>
<pre><code class="language-sql">SELECT *
FROM project_dataset.get_project_logs('project-123', DATE('2023-01-01'), DATE('2023-01-31'))
WHERE severity = 'ERROR'
ORDER BY timestamp DESC
LIMIT 100;

</code></pre>
<p>テーブル関数を採用した主な理由は、クエリ実行時にパラメータを受け取れる柔軟性にあります。特に監査ログでは、ユーザーが任意の期間のログを抽出できることが重要な要件でした。テーブル関数を使用することで、日付範囲などのパラメータを実行時に指定でき、ユーザーは必要なデータだけを効率的に取得できます。</p>
<p>さらに、生ログは日時でパーティショニングされているため、日付範囲を指定することでパーティションプルーニングが働きます。この仕組みにより、不要なデータスキャンを最小限に抑え、クエリのパフォーマンスを向上させることが可能です。</p>
<p>また、SQLのロジックをテーブル関数内にカプセル化できるため、クエリの再利用性が高まることもメリットです。これにより、複雑なロジックを一箇所に集約し、メンテナンス性を向上させることができます。</p>
<h3>テーブル関数の役割と設計</h3>
<p>抽出基盤の中核となるのは3種類のテーブル関数です。これらの役割と設計思想について解説します。</p>
<h4>1. プロジェクトログ抽出テーブル関数</h4>
<p>この基盤層のテーブル関数は、引数で指定されたプロジェクトIDに対応するログだけを抽出する役割を担っています。他プロジェクトのログが露出するリスクを最小化するため、この関数は変更頻度が低くなるような設計としています。</p>
<p>単一の責務に特化することで、SQLの複雑性を抑制し、堅牢性を高めています。この層がセキュリティの要となるため、変更する際にはGithubで指定された <code>CODE_OWNER</code> のコードレビュープロセスを経る必要があります。</p>
<h4>2. プロダクト別変換テーブル関数</h4>
<p>プレイドでは複数のプロダクトを展開しており、各プロダクトでクライアント向け監査ログへの変換方法が異なります。そこで、プロダクトごとに専用の変換テーブル関数を用意し、それぞれのデータ構造に合わせた変換ロジックを定義できるようにしています。</p>
<p>実際のデータ変換の例はこのような感じです。例えば、以下のような生ログのJSON構造があるとします：</p>
<pre><code class="language-json">{
  &quot;jsonPayload&quot;: {
    &quot;user&quot;: {
      &quot;id&quot;: &quot;user_12345&quot;,
      &quot;name&quot;: &quot;山田太郎&quot;,
      &quot;email&quot;: &quot;yamada@example.com&quot;
    },
    &quot;http_request_meta&quot;: {
      &quot;ip&quot;: &quot;192.168.1.1&quot;,
      &quot;user_agent&quot;: &quot;Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...&quot;
    },
    &quot;resource&quot;: {
      &quot;type&quot;: &quot;dataset&quot;,
      &quot;id&quot;: &quot;dataset_789&quot;,
      &quot;action_type&quot;: &quot;update&quot;
    },
    &quot;detail&quot;: [
      {
        &quot;detailType&quot;: &quot;diff&quot;,
        &quot;new&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット2023&quot;},
        &quot;old&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット&quot;}
      },
      {
        &quot;detailType&quot;: &quot;fields&quot;,
        &quot;value&quot;: {&quot;created_at&quot;: &quot;2023-05-01T09:00:00Z&quot;}
      }
    ],
    &quot;timestamp&quot;: &quot;2023-05-01T10:15:30Z&quot;
  }
}

</code></pre>
<p>このような生ログから、ユーザーに見せる監査ログとして以下のような形式に変換したいとします：</p>
<table>
<thead>
<tr>
<th>user_id</th>
<th>ip_address</th>
<th>action</th>
<th>resource_type</th>
<th>resource_id</th>
<th>timestamp</th>
<th>before_edit</th>
<th>after_edit</th>
</tr>
</thead>
<tbody>
<tr>
<td>user_12345</td>
<td>192.168.1.1</td>
<td>update</td>
<td>dataset</td>
<td>dataset_789</td>
<td>2023-05-01T10:15:30Z</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット&quot; }</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット2023&quot; }</td>
</tr>
</tbody>
</table>
<p>このような変換を行うために、各プロダクトチームはどのフィールドをどのように抽出・変換するかをマッピング定義として記述します。これにより、生ログの複雑なネスト構造から必要な情報だけを取り出し、ユーザーにとって理解しやすい形式に整形できます。</p>
<p>この層では宣言的なアプローチを採用しており、各プロダクトチームは変換マッピングを定義するだけで、自動的にSQL文(テーブル関数)が生成される仕組みを整えています。これにより、SQLを意識しなくても監査ログの変換ロジックを実装できます。</p>
<p><strong>マッピングの仕様：</strong></p>
<ul>
<li><strong>基本構造</strong>
<ul>
<li><code>map</code> 内の key は整形後の監査ログのカラム名を指定します</li>
<li><code>columnName</code> には生ログのデータパスを指定します</li>
<li><code>type</code> にはデータ型（STRING, JSON など）を指定します</li>
</ul>
</li>
<li><strong>detail フィールドの処理</strong>
<ul>
<li><code>detail</code> フィールドには比較的自由な形式のデータが格納されるため、特殊なマッピングを指定できます：
<ul>
<li><code>detailType</code> - 処理対象のデータタイプ（<code>diff</code>/<code>fields</code>/<code>error</code> など）</li>
<li><code>detailFieldsKey</code> - オブジェクト内の抽出したいキー名</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>実際に <code>detail</code> に格納されるデータの例<br>
※ 同一 detailType のオブジェクトが複数入らないようにしています</p>
<pre><code class="language-jsx">[
  {detailType: &quot;diff&quot;, new: {dataset_name: &quot;hoge&quot;} old: { dataset_name: &quot;fuga&quot; }},
  {detailType: &quot;fields&quot;, value: { hoge: 1, fuga: &quot;piyo&quot; }},
  {detailType: &quot;error&quot;, message: &quot;this is error&quot; }
]

</code></pre>
<p>以下は変換マッピングの例です。このマッピングでは、ユーザーID、IPアドレス、編集前の値などを抽出する方法を定義しています。</p>
<p>また、より柔軟なデータ抽出が必要な場合には、<code>custom</code>セクションを利用してカスタムの<code>SELECT</code>文を記述できます。これにより、既存のパターンでは対応できない特殊な要件にも対応可能です。例えば、特定の条件に基づいてデータを加工したり、集約した結果を取得することができます。</p>
<pre><code class="language-jsx">{
  map: {
    user_id: { columnName: 'user.id', type: 'STRING' },
    ip_address: { columnName: 'http_request_meta.ip', type: 'STRING' },
    before_edit: {
      columnName: detail,
      type: 'JSON',
      detailType: 'diff',
      detailFieldsKey: 'old',
    },
  },
  custom: {
    selectQueries: [
      `TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value`,
    ],
  },
  version: '1'
};

</code></pre>
<p>このマッピング定義から、以下のようなSQLが自動生成されます。</p>
<pre><code>SELECT
  CAST(jsonPayload.user.id AS STRING) AS user_id,
  CAST(jsonPayload.http_request_meta.ip AS STRING) AS ip_address,
  TO_JSON(ANY_VALUE(IF(detail.detailType = 'diff', detail.old, NULL))) AS before_edit,
  TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value
FROM
  sampleTableFunction(api_key, start_date, end_date)
  ...

</code></pre>
<h4>3. プロジェクト別テーブル関数</h4>
<p>最終的なデータ提供層として、プロジェクトごとにデータセットを分け、その中にプロダクトごとのテーブル関数を配置しています。この設計には二つの利点があります。</p>
<ol>
<li>将来的に<a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction?hl=en">BigQuery sharing</a>経由などでデータセットごとユーザーに提供する可能性への対応</li>
<li>マッピング変更時の影響範囲の局所化</li>
</ol>
<p>このテーブル関数は基本的に中間層（プロダクト別変換テーブル関数）を参照するだけの構造になっています。そのため、中間層の変換ロジックが変更された場合でも、すべてのプロジェクトデータセット内のテーブル関数を更新する必要がなく、運用負荷を大幅に削減できます。</p>
<h3>テーブル関数の自動生成と管理</h3>
<p>続いて、テーブル関数の作成・更新プロセスについて説明していきます。構成としては、以下のようになっており、基本的に自動化されています。</p>
<p><img src="https://ik.imagekit.io/plaid/47096b33-1545-48e9-aa3d-2269ef407723/auditlog_table_function_automation.png" alt="auditlog_table_function_automation.png"></p>
<h4>プロジェクトログ抽出テーブル関数の管理</h4>
<p>基盤層のテーブル関数は、リポジトリ内のコード変更をトリガーにGitHub Actionsを通じて更新されます。(構成図の左側参照) この重要なコンポーネントはCODE_OWNERで厳格に管理されており、特定のレビュアーの承認がなければ変更できない仕組みになっています。</p>
<h4>プロダクト別テーブル関数の自動生成</h4>
<p>各プロダクトチームは、マッピング定義を更新するだけで、GitHub Actions経由でSQLが自動生成され、対応するテーブル関数が更新されます。(構成図の左側参照)</p>
<h4>プロジェクト別データセット・テーブル関数の自動生成</h4>
<p>新しいプロジェクトのデータが生ログに追加された場合、自動的に対応するデータセットとテーブル関数が作成される仕組みを実装しています。(構成図の右側参照) 具体的には、Cloud Schedulerで定期的にCloud Run関数を起動し、直近の生ログをスキャンして新規プロジェクトを検出します。</p>
<p>検出された新しいプロジェクトに対しては、データセットの作成とテーブル関数の生成が自動的に行われます。データセット・テーブル関数が作成済みのプロジェクトに関する情報は、BigQueryの簡易的なテーブルを使い以下のように管理しています。</p>
<table>
<thead>
<tr>
<th>project_id</th>
<th>product</th>
<th>version</th>
<th>created_at</th>
</tr>
</thead>
<tbody>
<tr>
<td>xxx</td>
<td>talk</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>1</td>
<td>2025-04-30 02:51:19.420000 UTC</td>
</tr>
</tbody>
</table>
<h2>保守運用の工夫</h2>
<hr>
<p>監査ログ基盤の運用には、データの安全性確保と長期的な保守性の両立が求められます。ここでは、その課題に対応するための技術的な工夫を紹介します。</p>
<h3>効率的なデータダウンロード機構</h3>
<p>監査ログは大量のデータを扱うため、効率的なダウンロード機構が必要です。そこで、BigQueryのストリーミング機能を活用し、データを10MBごとに圧縮してクライアントに送信する仕組みを実装しています。</p>
<p>また、ユーザビリティ向上のための工夫として、生ログに含まれる<code>projectId</code>などの単なる識別子を、ストリーミング処理中にアプリケーションのデータベースから取得したプロジェクト情報と結合し、 <code>株式会社プレイド検証環境</code> のようなユーザーが理解しやすい表記に変換しています。</p>
<p>この仕組みは現状は十分に対応できていますが、予期せぬ大量データなどによりエラーが発生した場合は、Datadogにエラーを通知するようにしているため、迅速に対応できるようになっています。</p>
<h3>多層的なセーフティネット</h3>
<p>他プロジェクトのデータが混入するリスクを最小化するため、複数のセーフティネットを設けています。</p>
<p>まず、テーブル関数のセキュリティ監視として、Cloud Scheduler と Cloud Run 関数を組み合わせ、定期的にテーブル関数にアクセスして返されるデータを検証しています。他プロジェクトのデータが検出された場合は、即時 Datadog のアラートが発報される仕組みです。</p>
<p>さらに、ユーザーがデータをダウンロードするストーリミング処理にも、BigQueryで二重チェックを行い、他プロジェクトのログが含まれていないことを確認しています。万一の混入が検出された場合は、ダウンロード処理を中止する安全機構を導入しています。</p>
<h3>継続的なサービス監視</h3>
<p>監査ログは機能的な性質上、月に一回ダウンロードされるなど、日常的に頻繁に使用される機能ではありません。そのため、問題が長期間気づかれず放置されてしまうリスクがあります。この課題に対応するため、<a href="https://www.datadoghq.com/ja/dg/apm/synthetics/synthetic-monitoring/">Datadog Synthetics (外形監視ツール)</a>を活用して、画面から定期的にダウンロードを行い実際にファイルがダウンロードできるかのチェックしています。</p>
<p>これにより、実際のユーザーが機能を使用する前に問題を発見し、迅速に対応することができる体制を整えています。</p>
<h3>テーブル関数のバージョン管理</h3>
<p>監査ログのカラム構成や形式は、プロダクトの進化に合わせて変更される可能性があります。変更があった場合でも、既存のシステムやユーザーの利用を妨げないために、テーブル関数にはバージョン管理機能を導入しています。</p>
<p>マッピング定義に<code>version</code>パラメータを指定することで、新しいバージョンのテーブル関数を追加しつつ、既存のバージョンも並行して維持できます。これにより、ユーザーは自身のニーズに合わせたバージョンを選択できるようになり、互換性を保ちながら監査ログを変更させることができるようになっています。</p>
<h2>まとめ</h2>
<hr>
<p>監査ログの抽出基盤は、セキュリティとユーザビリティのバランスを取りながら、開発者が容易に実装・拡張できる設計を目指しています。多層構造のテーブル関数、自動生成の仕組み、複数のセーフティネットにより、安全かつ柔軟な監査ログ提供を実現しています。</p>
<p>マルチプロダクト環境では、新しいプロダクトの追加や既存プロダクトの変更が頻繁に発生しますが、この基盤により、各プロダクトチームは複雑なセキュリティ実装をほとんど意識せずに、安全に監査ログを拡張できます。プロダクト間の監査ログの一貫性を保ちながらも、それぞれのプロダクト特有の情報を柔軟に取り込める設計が、マルチプロダクト戦略を支える重要な要素となっています。</p>
<p>今後も新たな要件やプロダクトの追加に対応しながら、監査ログ基盤の進化を続けていく予定です。また、さらなる活用方法として、機密情報を適切に除去した上で社内の調査・分析用途に監査ログを活用することも検討しています。例えば、長期間使用されていないアカウントの洗い出しやプロダクト使用状況分析などを通じて、セキュリティの強化やサービス改善に繋げていくことが可能です。このように監査ログは単なる記録としてだけでなく、データドリブンな意思決定を支える貴重な情報源となる可能性を秘めています。</p>


マルチプロダクト環境における監査ログ抽出基盤のアーキテクチャと技術的な工夫を解説。BigQueryのテーブル関数を活用し、「安全性」と「開発のしやすさ」を両立する設計思想、自動生成の仕組み、運用時の工夫を紹介します。

監査ログ抽出基盤の設計と実装：BigQueryテーブル関数による安全性と柔軟性の両立

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

<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会で活用のヒントを探ってみた！

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a>  です。02021/05/25 - 2021/05/27 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21">Google Cloud Day: Digital</a> に 弊社3名で「Analytics」「Datahub」「ML」というテーマでそれぞれ登壇してきました。</p>
<p>こちらのブログでもその内容を簡単にまとめておきます。</p>
<h1>「100億人のユーザー行動からインサイトを得るための大規模分析基盤〜BigQueryを活用して〜」</h1>
<p>こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。</p>
<p>我々が提供するKARTEはついに累計解析ユーザー数が100億人を超えるまでに成長しました。KARTEには「顧客の解像度を上げることで事業成長へ」というコンセプトがあります。</p>
<p>これを実現するソリューションとして</p>
<p>といったユーザー行動からインサイトを得るためのプロダクトをご提供しております。1これらのプロダクトを支える大規模な分析基盤はBigQueryを主軸に構築されています。2月間で約200PB近くも蓄積される大規模のデータを素早く分析するには様々な工夫が必要です。今回のセッションでは具体的に3点</p>
<p>についてお話ししております。</p>
<p>他にもたくさんの工夫がなされており、弊社内でも分析基盤のアップデートは日々行われています。特にBigQueryはアップデートが早いプロダクトなので、最新情報をキャッチアップしつつ、運用改善を常に回せる体制が重要だと思います。そうすることにより、データ分析をビジネス上の価値へと繋げやすくなるはずです。</p>
<p>発表については <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d1-da-05">YouTube Live</a> でご覧いただけます。3また、<a href="https://speakerdeck.com/kargo113/10billion-user-analytics-architecture-using-bigquery">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="3855f3cfe4c547238af631a827001843" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「これからの環境の変化に強いデータ基盤をつくるためには」</h1>
<p>こちらは <a href="https://twitter.com/everydaycompman">@moto</a> より以下の内容をご紹介致しました。</p>
<p>近年プロダクトのライフサイクルは短く、顧客のデータ量は増加する中で短期間で大量のデータを扱う必要性が生じています。4しかし多くの企業のデータ活用はプロダクトと人の分断により進んでいない状況です。</p>
<p>KARTE DatahubはBigQueryやDataFlowを活用してデータの収集から活用までをワンストップで実現するプロダクトを提供しています。5データに関わる誰もが自分の得意な方法でデータ活用できるプロダクトを目指し、今後も機能を拡充していきます。</p>
<p>全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d3-pl-21">YouTube Live</a> よりご覧頂けます。</p>
<p>資料は追ってアップロード致します。</p>
<h1>「 GKE Autopilot で Ops レスなリアルタイム ML を実現 」</h1>
<p>こちらは @nichimuより、以下の２つのことをご紹介いたしました。</p>
<p>「GKE Autopilot を使用したリアルタイム推論基盤の構成」 では、リアルタイム推論基盤の内部用推論用APIとしてCloud Runを使用していましたが、「VPC内にデプロイ不可」「コンピュータリソースの永続性」の課題があり、今年の3月にローンチしたGKE Autopilotに置き換えることで、これらの課題を解決いたしました。</p>
<p>「Google Cloud の Professional Service (PSO) を活用したMLプロジェクトの遂行」では、もともと弊社で遂行していたMLプロジェクトが少なかった時期からPSOを活用することにより、Google Cloudが世界で培ってきた ML プロジェクトの進め方のノウハウを上手に活用することができました。</p>
<p>全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21/watch?talk=d3-ml-05">YouTube Live</a> よりご覧頂けます。</p>
<p>また、<a href="https://speakerdeck.com/nichimu/gke-autopilot-de-ops-resunariarutaimu-ml-woshi-xian">SpeakerDeck</a> に @nichimu 発表分の資料をアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="103959147e954d99b4d29113d4cccb3c" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
<p>今回も昨年に引き続きオンラインでの登壇となりました。6今年はなんと弊社だけで3セッションも登壇させて頂き、Googleさんには大変感謝致します。</p>
<p>全体を通して、基調講演含め他社様の事例や製品の最新情報などを知ることができ、非常に勉強になりました。ご紹介したように、弊社は「データによって人の価値を最大化する」というミッションのもと、様々なプロダクトを迅速に開発していっているので、来年も新たな情報を踏まえて登壇できたら良いなと思っています。</p>
<p>そんな弊社ではスピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


Google Cloud Day: Digital 2021 で「100億人のユーザー行動からインサイトを得るための大規模分析基盤」等、3セッション登壇しました

Google Cloud Day: Digital 2021 にて Analytics/ML/Datahub について3セッション登壇しました

<p>ごきげんよう、エンジニアの @tik-son です。02021/05/11 - 2021/05/12 に行われた <a href="https://aws.amazon.com/jp/events/summits/online/japan/">AWS Summit Online 2021 </a>で登壇してきましたので、このブログでもその内容を簡単にまとめておきます。</p>
<h1>「 基調講演： ビジネス変革に必要な柔軟性」</h1>
<p>まず、今回のAWS Summit Online 2021 では<a href="https://www.youtube.com/watch?v=RccC1gPGj2Q&amp;t=1130s">CEOの倉橋より「AWS活用による事業と組織のAgility強化」</a>というテーマでお話をさせていただきました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/50ea3466-de8d-407b-bb02-4a51229d8a89/image.png" alt=""></p>
<p>「<strong>数字への仕事から人への仕事に戻す</strong>」がPLAID の一つの野望でありまして、その実現においては、AWSやKARTEを上手く組み合わせることは有効であるということをお伝えしました。</p>
<p>そして、AWSとKARTEを組み合わせた一つの例として @tik-son より「AWS と KARTE で作る User State Driven System」についてお話しました。</p>
<h1>「AWS と KARTE で作る User State Driven System」</h1>
<p>1我々が提供するKARTEはAWSとGCPのマルチクラウドでインフラが構成されているのですが、アプリケーションレイヤーにおいてもAmazon Eventbridge やAmazon S3 などを介してお客様の AWS 環境と密な連携が可能です。</p>
<p>またKARTEの特徴の一つとして、人の状態(User State)の変化をトリガーに駆動するUser State Driven Systemといった概念があるのですが、この連携を通じて、サイト上のポップアップなどだけではなく、AWSのサービスを活用して、人の状態の変化をリアルタイムに捉えた様々なシステムを作ることができます。</p>
<p>本セッションでは、AWSとKARTEを組み合わせることでどのようにUser State Driven Systemを作ることが出来るのが具体例を含めてお話をしています。</p>
<p>発表については<a href="https://www.youtube.com/watch?v=FHFHsIVFaxI">アーカイブ配信</a>にてご覧いただけます。2また、<a href="https://speakerdeck.com/tikson/user-state-driven-system-with-aws-and-karte">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="14f427f918da4cf2b79d63728727fde8" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>また、このAWS Summit Onlineにあわせて、</p>
<ul>
<li><a href="https://integrations.solutions.karte.dev/aws/eventbridge">Amazon Eventbridge 連携</a></li>
<li><a href="https://developers.karte.io/reference#karte-datahub">Datahub Api V2</a></li>
</ul>
<p>がGAになっているので是非、そちらもご覧いただければと思います。</p>
<h1>最後に</h1>
<p>この記事を読んでお気づきの方もいらっしゃるかもしれませんが、PLAIDではKARTE単体だけでなく、AWSなど外部のサービスと組み合わせることで新たな価値を生み出すことが出来ないかという検証も始めています。</p>
<p>ですので 、KARTE自体の開発に興味がある！というエンジニアはもちろんのこと、KARTEとAWSなどの外部サービスを組み合わせて新たなシステム/価値を創出したい！というBiz/Devのメンバーも絶賛募集しています！3詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


AWS Summit Online 2021 にて「AWS と KARTE で作る User State Driven System」について話してきました

<p>エンジニアの大矢です。<br>
本日、Google Cloud Japan Blog で「<a href="https://cloud.google.com/blog/ja/topics/customers/plaid-anthos-clusters-on-aws">Anthos clusters on AWS を活用し、マルチクラウドでもGKE 由来の高度なマネージド環境を享受</a>」というタイトルで弊社の事例が紹介されました。<br>
私たちがどのような背景でマルチクラウド構成を採用するに至ったか、どのような狙いで <a href="https://cloud.google.com/anthos/clusters/docs/aws/concepts?hl=ja">Anthos clusters on AWS</a> を導入したかについて書かれていますので、ぜひ読んでみてください。また、細かいアーキテクチャの変遷について気になった方は<a href="/google-cloud-day-digital-2020/">こちら</a>の記事にある動画も合わせて見ていただけると幸いです。</p>
<p>この記事ではもう少し細かく、実際どう運用しているかや注意するポイントなどを書いています。</p>
<h1>Anthos clusters on AWS を活用したアーキテクチャ</h1>
<p>まずはじめに、Anthos clusters on AWS を導入することでどのようなアーキテクチャになったかを簡単に説明します。<br>
KARTE には大きく分けて2つのサーバ群があり、解析基盤（Track/Analyze）と管理画面（Admin）に分かれています。下図のように今回 Anthos clusters on AWS を採用したのは Admin の方で、Route53 Traffic Flow を利用してアクセスを振り分けています。通常時には、ほぼ全てのリクエストが GKE<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> 側にルーティングされるようになっており、AWS 側では GKE で動いてるものと同じワークロードがデプロイされ、停止した状態になっています。<br>
また Anthos clusters on AWS には、専用の VPC 内にクラスタを作成する方法と、既存の VPC にクラスタを作成する方法がありますが、図のように既存の VPC 内にある EC2 で動く mongoDB にアクセスできる必要があったため、既存の VPC に作成しました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b543e5a8-7c49-4de0-a173-09de140534d6/image6-2.jpeg" alt="image6-2"></p>
<p>また、管理画面で発生するほぼ全てのリクエストは GKE 側にルーティングされると書いたのですが、実は管理画面のコンポーネントのいくつかは Anthos clusters on AWS がメインとして動いており、その一つは KARTE 管理画面上で接客を編集する際にプレビューするための Proxy サーバになります。<br>
この Proxy サーバは元々 EC2 で動いており、サブドメインが動的に作られるため、AWS Certificate Manager（ACM） のワイルドカード証明書を利用していました。管理画面が GKE で動くようになった後、Proxy サーバも GKE に移行したかったのですが、GCP ではマネージドなワイルドカード証明書が利用できず、移行するにはセルフマネージド証明書の管理が必要でした。そのため、Proxy サーバを Anthos clusters on AWS 上でのみ動かすことにして、ACM のワイルドカード証明書をそのまま利用しています。<br>
このように AWS の機能を利用した方が管理が楽になったり、AWS にしかないような特徴を持つサービスを使いたい、となったときに簡単に AWS 上で Kubernetes を動かすことができます。</p>
<h1>マルチクラウド Kubernetes 運用のポイント</h1>
<p>今回 Anthos clusters on AWS を導入しマルチクラウド運用にする際に考慮したポイントは、運用にかかるコストを極力減らすことです。Anthos clusters on AWS では、<a href="https://cloud.google.com/anthos/multicluster-management/connect/overview?hl=ja">Connect</a> という機能を使うことで GKE の管理画面で AWS 上にあるクラスタを同じように管理できるなど、AWS 上のクラスタも同じように扱える仕組みがあります。<br>
しかし、いくつか注意点もあります。secret の管理もその 1 つですが、既に記事を書いてる<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>のでここには書きません。下記の 4 つについて、どのようにして運用しているかを説明します。</p>
<ul>
<li>デプロイ</li>
<li>manifest の管理</li>
<li>Ingress</li>
<li>監視</li>
</ul>
<h2>pull 型のデプロイ</h2>
<p><a href="https://www.weave.works/technologies/gitops/">GitOps</a> では push 型と pull 型の 2 つのパターンがあります。push 型は kubernetes クラスタ外にある CI システム上で スクリプトを実行することによりデプロイします。pull 型は kubernetes operator がクラスタの内部からデプロイをします。<br>
Anthos clusters on AWS はプライベートクラスタを構成するため、VPC 内のインスタンスからでないとデプロイを実行できません。<br>
push 型のデプロイシステムを採用していた場合は VPC 内に CI システムを置くか、VPC 内にある踏み台サーバに対して ssh tunnel を貼る必要がありました（現在はベータ版の <a href="https://cloud.google.com/anthos/multicluster-management/gateway/using?hl=ja">Connect Gateway</a>  を使うことで VPC の外からでも kubectl を使うことができます）。<br>
私たちは pull 型のデプロイツールである <a href="https://argoproj.github.io/argo-cd/">ArgoCD</a> を採用していたため、GKE にデプロイするのと同じように AWS にもデプロイすることができます。具体的には、ArgoCD の Application の設定ファイルを1つ書き加えるだけで、AWS のデプロイフローを整えることができました。</p>
<h2>Kustomize を利用した manifest の管理</h2>
<p>マルチクラウドに限った話ではないですが、複数環境の差分を管理するためのツールとして Kustomize はとても便利です。<br>
冒頭に書いたように、Active/Standby 構成のため AWS にも GKE と同じものデプロイしていますが、ほとんどのワークロードは停止しています。また、GKE で利用してる一部のリソースやワークロード（BackendConfig や <a href="https://cloud.google.com/kubernetes-engine/docs/tutorials/custom-metrics-autoscaling?hl=ja">custom-metrics-stackdriver-adapter</a>）はそのまま使うことはできません。<br>
共通の部分は同じ manifest を使いつつ、環境ごとにパラメータを変えたり Active/Standby 構成を実現するために、Kustomize を利用しています。<br>
例えば、全ての Deployment と CronJob を止めるために、下記のようなパッチを使っています。</p>
<pre><code class="language-yml">- op: replace
  path: /spec/suspend
  value: true
</code></pre>
<pre><code class="language-yml">- op: replace
  path: /spec/replicas
  value: 0
</code></pre>
<pre><code class="language-yaml">patches:
  - path: path/to/cronjob-suspend.yml
    target:
      kind: CronJob
  - path: path/to/replicas-zero.yml
    target:
      kind: Deployment
</code></pre>
<p>このようにすることで、新しく追加したワークロードが AWS 上で意図せず動いてしまう心配もないですし、仮に GCP 側で障害が起こり待機系に切り替えなければいけなくなった際には、このパッチを外してデプロイするだけで GKE と同じように全てのワークロードが立ち上がります。</p>
<h2>Ingress</h2>
<p>Anthos clusters on AWS では Classic Load Balancer, Network Load Balancer および Application Load Balancer（ALB）が利用できます。私たちは L7 Load Balancer を使う必要があったので ALB を利用しました。<br>
ALB を利用するためには AWS Ingress Controller をインストールしたり、サブネットにタグをつけたりする必要がありましたが、ドキュメントに手順が詳しく書いていたため導入まではスムーズに進むことができました。<br>
注意する必要があるのは、GCP の Cloud Load Balancer と ALB ではパスベースルーティングにおけるルールの評価方法が異なることです。Cloud Load Balancer ではワイルドカードが指定でき、複数のルールにマッチする場合はより限定されたルールの方に従います。ルールの定義順はルーティングに影響しません。例えば下記のような spec を持つ Ingress によって生成された Cloud Load Balancer があり、<code>http://example.com/hoge/123</code> にリクエストを送ると、2番目のルールが適用されて hoge service にルーティングされます。</p>
<pre><code class="language-yaml">spec:
  rules:
    - host: example.com
      http:
        - path: /*
          backend:
            serviceName: default
            servicePort: 80
        - path: /hoge/*
          backend:
            serviceName: hoge
            servicePort: 80
        - path: /huga/*
          backend:
            serviceName: huga
            servicePort: 80
</code></pre>
<p>しかし、上記の spec の Ingress から生成された ALB では <code>http://example.com/hoge/123</code> にリクエストを送ると default service にルーティングされます。<br>
これは、ALB ではルールの評価が上に定義されたものから順に行われ、マッチした時点でそのルールが適用されるためです。下記のように<code>/*</code> のルールを一番下に書くことでこの問題を回避し、GKE と AWS で同じ Ingress の manifest を利用できました。</p>
<pre><code class="language-yaml">spec:
  rules:
    - host: example.com
      http:
        - path: /hoge/*
          backend:
            serviceName: hoge
            servicePort: 80
        - path: /fuga/*
          backend:
            serviceName: fuga
            servicePort: 80
        - path: /*
          backend:
            serviceName: default
            servicePort: 80
</code></pre>
<h2>監視</h2>
<p>監視についてもいくつか選択肢があります。オープンソースの Logging Agent および Monitoring Agent を追加でインストールすることで、Cloud Logging, Cloud Monitoring が利用できます<sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>。<br>
私たちは元々マルチクラウドを構成を採用していたため、全ての監視を Datadog に集約していました<sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup>。そのため、Anthos clusters on AWS の監視についても Datadog を採用しました。既に GKE でも Datadog を利用していたため、同じように datadog-agent などのコンポーネントをデプロイする<sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup>だけで簡単にロギング・モニタリングを実現できました。</p>
<h1>最後に</h1>
<p>Anthos clusters on AWS を利用することで、運用コストを余計にかけすぎることなく、高可用性や AWS サービスの活用を実現しました。<br>
今後はさらにマルチクラウドの特性を活かして、新たな価値を生み出していきたいです。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>Anthos clusters on AWS も GKE ではありますが、この記事では Google Cloud 側の GKE のことを単に GKE、AWS 側の GKE のことを on AWS と書いています。 <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p><a href="/nayanda-kubernetes-secret-management/">悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由 | PLAID engineer blog</a> を読んでいただけると幸いです。 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p><a href="https://cloud.google.com/anthos/clusters/docs/aws/how-to/logging-and-monitoring?hl=ja">AWS 上の Anthos クラスタのロギングとモニタリング  |  Google Cloud</a> <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>私たちが Datadog をどのように活用しているかより詳しく知りたい場合は<a href="/datadog-summit-tokyo/">こちら</a>の記事を是非読んでみてください。 <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p>詳しい手順は<a href="https://cloud.google.com/solutions/partners/monitoring-anthos-with-datadog?hl=ja">公式ドキュメント</a>に書いてあります。 <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


エンジニアの大矢です。本日、Google Cloud Japan Blog で「Anthos clusters on AWS を活用し、マルチクラウドでもGKE 由来の高度なマネージド環境を享受」というタイトルで弊社の事例が紹介されました。

Google Cloud Japan Blog で Anthos clusters on AWS を活用した事例が紹介されました | PLAID engineer blog

Google Cloud Japan Blog で Anthos clusters on AWS を活用した事例が紹介されました

<p>こんにちは！エンジニアの@tik-son, @ikemonnとMLエンジニアの@nichimuです。</p>
<p>本日ついに待望の<a href="https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot">GKE Autopilotがリリース</a>されましたね！<br>
この記事では、GKE Autopilot上で動いているリアルタイム推論基盤でなぜ我々がGKE Autopilotを利用することにしたのかについてお話しします。</p>
<h1>MLリアルタイム推論基盤とは</h1>
<p>リアルタイム推論基盤とは、機械学習のモデルを使用して、リアルタイムに推論が行える基盤のことです。<br>
このリアルタイム推論基盤を用いることで、</p>
<ul>
<li>エンドユーザーがsession内で電話するかを予測する</li>
<li>エンドユーザーが会員登録を行ったsession内で資料請求をするか予測する</li>
</ul>
<p>のように数秒-数分後にエンドユーザーがどんな状態であるかなどを予測することが実現可能になります。<br>
この基盤はまだ絶賛開発中で誰もが簡単に使える状態になっていないのですが、このブログを読んで何かビジネス課題を解決したい！という方がいましたら、ぜひ、弊社までお問い合わせください！という宣伝はさておき、さっそく本題に入っていきます。</p>
<p>リアルタイム推論基盤のデータの流れとしては、以下のようになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f4c8102-da2d-4ba7-987f-339b82717b88/realtime_inference.png" alt="realtime_inference"></p>
<ol>
<li>エンドユーザーがwebやapp上で何かしらの行動を行い、Event DataをKARTEのリアルタイム解析/アクション基盤 (Not ML) に送信する</li>
<li>リアルタイム解析/アクション基盤に送られたEvent Dataをリアルタイム推論基盤 (ML) にCloud Pub/Subを通じて送信する</li>
<li>Cloud Dataflow上でEvent Dataに関する以下の処理を行う
<ol>
<li>Event Dataを整形して、生ログとしてCloud Spanner<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>に保存する</li>
<li>Event Dataをfilterして、推論用APIへの推論トリガーをCloud Pub/Subを通じて投げる</li>
</ol>
</li>
<li>推論用API (Cloud Run) で、機械学習モデル<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>を用いた推論を行い、推論結果をCloud Bigtableに書き込む</li>
<li>Cloud Bigtableに書き込まれた推論結果をコア基盤から読み込み、クーポンなどのActionを配信する</li>
</ol>
<p>今回、GKE Autopilotを使用した部分としては、図の赤枠で囲ってある推論用内部API componentになります。<br>
GKE Autopilotがローンチされるまでは、compute resourceとしてCloud Runを使用しており、以下でどのようにしてGKE Autopilotを使うようになったかをお話してまいります。</p>
<h1>推論用内部API の要件と抱える課題</h1>
<p>さて、推論用内部API として、Cloud Runを使用していると記述しましたが、推論用内部API の要件としては以下になります。</p>
<ol>
<li>以下を実現するため、自由度高くコードを書くことができるDocker Imageベースでデプロイできること
<ul>
<li>Cloud Pub/Subから推論トリガーを受け取り、予測を開始する</li>
<li>生ログデータをCloud Spannerから取得する</li>
<li>Pythonで書かれた機械学習のモデルを使って、予測を行う</li>
<li>Cloud Bigtableに予測結果を書き込む</li>
</ul>
</li>
<li>リアルタイム解析/アクション基盤に組み込んで使用するため、システムとして高スケーラビリティや高可用性などのシステムとしての強さがあること</li>
<li>基盤における運用/開発ではなく、モデルの作成やデータの活用など、MLエンジニアが本質的な価値にフォーカスする状態を作れること</li>
</ol>
<p>当初、これらの要件を満たすために、色々とベンチマークをした結果Cloud Runを使用していましたが、以下の課題がありました。</p>
<ul>
<li>Service Accountでの制御はかけているものの、CloudRunの仕様でCloudRun自体に外部IPを持たせないといけないため、セキリュティ的に綺麗な設計ではない</li>
<li>Cloud Pub/Subで推論トリガーを受け取るときにPush型を使用するが、Push型でのError Handlingが難しいので、なるべくPull型で扱いたい</li>
</ul>
<p>この課題はGKEを利用することで解決できるのですが、</p>
<blockquote>
<ol start="3">
<li>基盤における運用/開発ではなく、モデルの作成やデータの活用など、MLエンジニアが本質的な価値にフォーカスする状態を作れること</li>
</ol>
</blockquote>
<p>この要件と先程述べた課題とのバランスが難しく、最終的にはMLエンジニアがGKEのインフラレイヤーを管理/運用する大変さを鑑みて、課題に目をつぶりCloud Runを利用している状況でした。</p>
<h1>GKE Autopilotとは？</h1>
<p>そういった課題をかかえたところ、我々にとってちょうどいい塩梅のProductが発表されました。それが<a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview">GKE Autopilot</a>です。<br>
GKE Autopilotとは、GKEの新しいmodeです。(従来のGKEはGKE Standard)<br>
Control Planeに加えて、Nodeの管理もGoogleのSREが行ってくれるので、クラスター管理の運用コストを下げることができます。さらに、SLAも提供されているので、Nodeの可用性やサイジング、スケーリングなどを気にすることなく、GKEを利用することができます。GKE Autopilotでは、ワークロードに応じて自動で裏側のHWをプロビジョニングするので、サービスやアプリケーションの開発に専念することができます。</p>
<p>特徴は下記です。</p>
<ul>
<li>NodeもGoogleが管理してくれる</li>
<li>ユーザーのワークロードにもとづいてリソースがプロビジョニングされる</li>
<li>Podに対してもSLAが設定されている</li>
<li>Podレベルで課金される</li>
<li>ユーザーのプロジェクト内でclusterが構築される(他のユーザとリソースを共有しない)</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b23f1257-08bb-44af-833f-ab67e42db6da/gkeauto.png" alt="gkeauto"><br>
<a href="https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot">https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot</a></p>
<p>また、GKE Autopilotでは下記のようなよく使われるワークロードやツールがサポートされており(一部今後サポート予定)で、様々なユースケースで活用できます。</p>
<ul>
<li>Stateless web app</li>
<li>Custom Database (StatefulSet)</li>
<li>Long-running batch job (Job)</li>
<li>DaemonSets that don’t violate GKE Autopilot rules</li>
<li>Add-ons: Cloud Run for Anthos, Istio</li>
<li>Machine Learning (GPU, TPU)</li>
<li>Tools and ecosystem - for example, Helm charts that don’t violates GKE Autopilot rules</li>
</ul>
<p>さらに、下記のような設定も利用できるため、使い勝手としても限りなくGKEに近い自由度があります。</p>
<ul>
<li>高可用性: Regional, Regular Release Channel, Auto-Update, Auto-Repair, Surge Upgrade</li>
<li>スケーリング: HPA, VPA, NAP</li>
<li>ネットワーク: Private clusters, VPC Native (alias IP), IP-friendly (limit cluster size/ pods per node), setup Cloud NAT</li>
<li>セキュリティー: Workload Identity, Shielded Nodes, Secure-boot-disk, etc</li>
</ul>
<p>以下のように、manifestの書き方もGKEのmanifestとほぼ同様に書くことができます。</p>
<pre><code class="language-yaml">apiVersion: &quot;apps/v1&quot;
kind: &quot;Deployment&quot;
metadata:
  name: &quot;plaid-test&quot;
  namespace: &quot;plaid&quot;
  labels:
    app: &quot;plaid-test&quot;
spec:
  replicas: 3
  selector:
    matchLabels:
      app: &quot;plaid-test&quot;
  template:
    metadata:
      labels:
        app: &quot;plaid-test&quot;
    spec:
      serviceAccountName: gke-auto
      containers:
      - name: &quot;realtime-inference&quot;
        image: &quot;gcr.io/plaid-test/realtime-inference:latest&quot;
        resources:
          requests:
            memory: &quot;6Gi&quot;
            cpu: &quot;2&quot;
          limits:
            memory: &quot;6Gi&quot;
            cpu: &quot;2&quot;
</code></pre>
<p>くわしくは<a href="https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#limits">GKE Autopilotのドキュメント</a>をご確認ください。</p>
<h1>GKE Autopilotの導入</h1>
<p>GKE Autopilot導入は、KARTEのリアルタイム解析/アクション基盤を作っているエンジニア、MLリアルタイム推論基盤を作っているエンジニアの両方で検証をしながら進めていきました。<br>
<code>推論用内部APIの要件と抱える課題</code> でお話した要件と課題をほぼ満たせることとなり、productionのworkloadで現在稼働しているのですが、その中で以下のようなPros/Consを感じました。</p>
<h2>リアルタイム解析/アクション基盤を作っているインフラエンジニアが感じたこと</h2>
<ul>
<li>Pros
<ul>
<li>クラスタのインフラレイヤーをGoogleが管理してくれるので運用が楽そう。(productionの運用は本日から始めるので、実際の恩恵を受けるのはこれからだと思っている)</li>
</ul>
</li>
<li>Cons
<ul>
<li>vpc native cluser前提なので、正しく設計/構築するには、利用するip range/NAT等のNWインフラの知識が必要になり、アプリケーションエンジニアだけでは現状難しそう。(privateなNW通信を行わない、vpc NWはdefaultでcloud pubsubでコンポーネント間を通信するというようなシステムであれば、NWを意識しなくていいので構築は楽かもしれない)</li>
<li>preemptible vmに対応していない</li>
<li>基本GKEなので、GKEで出来ないことはできない。例えば、clusterレベルのスケールアウトがGKEより速いなどはない。(厳密にはこれはConsではないとは思うが、マネージドサービスである期待をこめて、一応書いておく)</li>
</ul>
</li>
</ul>
<h2>MLリアルタイム推論基盤を作っているMLエンジニアが感じたこと</h2>
<ul>
<li>Pros
<ul>
<li>manifestにresourcesのlimitsとrequestsを記述するだけで、MLエンジニアが欲しいマシンリソースが簡単に用意でき、運用まで期待できる</li>
<li>リソースはCloudRunと異なり、動き続ける前提なのでPub/SubのPull型を簡単に扱うことができる</li>
<li>インフラの柔軟性を担保しつつ、運用を考えなくていいのはいい。開発が捗る。</li>
</ul>
</li>
<li>Cons
<ul>
<li>MLリアルタイム推論基盤で今後利用したい、GPUがまだサポートされていない</li>
</ul>
</li>
</ul>
<h1>まとめ</h1>
<p>GKE Autopilotは銀の弾丸ではないので、インフラエンジニアからすると微妙な部分が少し多めに見えてしまうのですが、このProductのポイントはそこではなく、 <code>ある程度柔軟なインフラが必要だけど運用までは面倒見きれないようなユースケースに絶妙にハマる</code> ということだと実際使ってみて強く感じました。<br>
(くわしくは<a href="https://medium.com/google-cloud-jp/gke-autopilot-87f8458ccf74">Google CloudのKazuuさんのブログ</a>をご確認ください)</p>
<p>Consで書いたことはGCPのことなので、GA後にすぐに対応してもらえるだろうと勝手に期待しています(笑)<br>
また、privateなvpc内通信が必要にならないよう、cloud pubsubなどでシステム間を疎にして設計していけば、GKE Autopilotの恩恵をより受けやすくなるのではないかとも感じました。もちろん、システム間のやり取りが大量なものはprivateなvpc通信前提で作る方がコストが安くなるとは思いますが、このあたりはトレードオフになると思うので上手く見極めながら設計していくといいと思われます。<br>
我々も今後はこのあたりを意識しながら上手くGKE Autopilotなどを駆使し、システムを作っていきたいと思います。</p>
<h1>最後に</h1>
<p>プレイドではGKE Autopilotのような新しい技術をうまく使い、面白いProductを開発していきたいエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<p><a href=""></a></p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>Cloud SpannerにEvent Dataを書き込んでいる理由としては、以下の２つの理由があります。(1. 機械学習のモデルを使用した推論ではエンドユーザーの過去の情報も必要だが、Event Dataには過去の情報はあまり含まれていないため、過去の情報も保持しておく必要がある, 2. 機械学習のモデルを作成する際にはBigQueryにSQLを投げて特徴量作成の試行錯誤をするため、推論時もSQLがかけるDBだと相性がよい) <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p>機械学習のモデルの作成やデプロイなどは、AI Platform NotebookやAI Platform Pipelinesを使用して行っています。 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


本日ついに待望のGKE Autopilotがリリースされましたね！
この記事では、GKE Autopilot上で動いているリアルタイム推論基盤でなぜ我々がGKE Autopilotを利用することにしたのかについてお話しします。

GKE Autopilotで作るMLリアルタイム推論基盤 | PLAID engineer blog

GKE Autopilotで作るMLリアルタイム推論基盤

<p>PLAIDでエンジニアをしている@kantetsuです。</p>
<p>現在はKARTEの<a href="https://cxclip.karte.io/product/userstory_renewal/">ユーザーを知る</a>画面のリニューアルや改善を主に行なっています👨‍💻</p>
<p>PLAIDでは、ここ数年デザイナーとエンジニアが一緒のチームとなり、デザイナーも機能公開に携わるようになって、機能を公開するプロセスが仕組み化されてきました🤖</p>
<p>例えば、シナリオテストやユーザビリティテストもここ最近では定着してきました（以前に書いた<a href="/release_survey_form/">KARTEのアンケートフォーム（β版）公開までの道のり</a>でも一部触れています）。</p>
<p>このような王道のテストをやりつつも、実は機能を公開するまでの手順でKARTEや社内ツールを用いたユニークな改善方法があるので、今回この場を借りて共有したいと思い、執筆しました✍️</p>
<h1>KARTEとは</h1>
<p>どのような改善方法があるのかを紹介する前に「KARTEって何なのか？」を説明させてください。ここをすっ飛ばしちゃうと、あとでよく分からないことになりそうなので🙏</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/86be2ac0-77b2-41a5-a4a0-8d449ad32ee6/insight.png" /><figcaption>https://karte.io をチェック！</figcaption></figure>
<p><a href="https://karte.io/">KARTE</a>では、サイトに計測タグを貼ることによって、ユーザーの行動解析をします。そのサイトでのエンドユーザーの一つ一つの行動（これをKARTEの中ではイベントと言う）をクライアントさんはKARTEの管理画面内で見ることができます。その中でエンドユーザーの行動を見れるのはもちろん、エンドユーザーに配信するアクションの編集やライブ・レポートの閲覧などができます。</p>
<h2>KARTEでイベントを発火させてユーザーを観察する</h2>
<p>KARTEでクライアントさんがどの画面でどのような行動をしているか見るために、実はKARTEの管理画面ではKARTEのタグを入れています。</p>
<p>で、これをどう開発で利用しているかというと、画面のリニューアルや改善をした際に「この週にどのくらいの人が保存ボタンを押したのか」「この日にどのくらいモーダルが開かれたのか」をKARTEのイベントを発火させることで観測しています📊</p>
<p>私たちのチームでは開発後にデザイナーがどの機能が使われているかを下記のようにリストアップして、それらを計測できるようにソースコードに計測のコードを入れていきます👨‍💻</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/387a6d83-2aed-46c0-b95f-27cdcd023eca/----------2020-11-02-23.03.02.png" /><figcaption>取りたい指標をリストアップしています</figcaption></figure>
<p>そして、実際にイベントが発火すると、KARTEのイベント画面やストーリー画面に表示され、「誰がどのタイミングで、どのくらいの人が〇〇ボタンを押したのか」などがKARTEで見ることができました👏</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e2546b14-22f4-427d-81a6-b115a5c86575/event.png" /><figcaption>計測されるとイベント画面に発生数と発生したユーザーと時刻が表示されます</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6b8bb35e-5289-431b-893c-7ff5600489e5/story.png" /><figcaption>もっと解像度高く見たい場合はストーリー画面で見ることもあります</figcaption></figure>
<p>一部のメンバーは<a href="https://mode.com/">Mode</a>を使って、SQLを書くことでこれらのイベントをより細かく集計もして、定期的にslackに通知してチームにシェアしています。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cecae12e-cadf-4a1b-a8f2-a719fc540693/mode.png" /><figcaption>実際に発生したイベントをModeで集計したレポート</figcaption></figure>
<h2>KARTE Liveで管理画面をどのように利用しているか見てみる</h2>
<p>KARTEの管理画面ではKARTE Liveによって可視化しているので、クライアントさんがどのように管理画面を使っているのかを視覚的に見ています。</p>
<p>例えば、新画面をリリースした場合にその新画面にクライアントさんがアクセスしたら、社内のSlackに「〇〇さんがこの画面にアクセスしました」っていう通知を飛ばして、その人のストーリーに飛んで、<a href="https://karte.io/product/live/">KARTE Live</a>を開いて見てみます👀</p>
<p>これによって、自分たちの新画面で想定された使い方をされているのか、画面上で戸惑っている部分はあるのかを実際の画面を通して見ることができます。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/060017a7-e3f4-4ae3-9263-8d9bf68f23f7/image.png" /><figcaption>KARTEを使った通知の仕組み</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76db6004-25b1-438a-8ba5-b98d7ef10777/s_DE66FBEA70BB0CBF23B9F0B5499DD68BB499403C478D678EB3C5F0DE92B2B6F9_1604482900676_slack.png" /><figcaption>該当ユーザーが通知され、チーム内で会話しています</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c01c4e69-a9eb-4a1e-b2f9-75d68921cadd/----------2020-11-04-19.30.33.png" /><figcaption>KARTE Liveでユーザーの動きをもっと強烈に見て、改善に繋げています</figcaption></figure>
<p>自分たちのチームはユーザーを知る画面をKARTEを使ってまさに「ユーザーを知る」ことで改善しています！</p>
<p>手前味噌ですが、KARTEは画面の改善にも強力なサービスでもあると思っています🚀</p>
<h2>KARTEの管理画面にコメントして、Issueに起票する</h2>
<p>今までのはKARTEを利用したKARTEの管理画面の改善方法を紹介しましたが、社内ツールもKARTEを進化させています💪</p>
<p>下記の二つのアプリを使っています。（これら二つはPLAIDの社内アプリなので外部公開していないので悪しからず…🙇‍♂️）</p>
<p>自分たちのチームではチーム内で自分たちの開発した画面を触って、バグのある箇所やユーザビリティが低い箇所にP Appでコメントしていくぽちぽち会を実施しました👨‍💻</p>
<p>P Appを使うことでブラウザ上でどこに誰がコメントしているのかを簡単に見ることができ、また簡単に投稿もできます。そして、Slack上でもその要素の画像も添えて投稿されるので、Slackにフィードバックを集約もすることができます。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1b643170-3092-4e50-8bdb-1550744fc9b7/slack2-2.png" /><figcaption>P AppにコメントされるとSlackにも同期される</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/679a0414-0e56-40bf-9477-be8b20167734/image-1.png" /><figcaption>サイト上の要素にコメントできるP App</figcaption></figure>
<p>そして、PLAIDでは基本的にはGitHubのIssueに起票してから開発するので、先ほどP Appで投稿されたSlackの投稿をS Appを使ってIssueにします。</p>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e9de211c-2f3b-4ac0-a912-96f3debb8a91/image-2.png" /><figcaption>さっきP Appで投稿された投稿をSlack上でIssue化するS App</figcaption></figure>
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fd9d488b-b897-4959-8295-857d0a4dd161/----------2020-11-04-18.51.33.png" /><figcaption>Issueのタイトルを記入して、Issueを作るボタンを押すと該当のレポジトリにIssueが起票される</figcaption></figure>
<p>これによって、画面でおかしいと思った箇所を逐一スクショしてSlackやGitHubに共有する手間がなく、シームレスにIssueにあげることにできました👏</p>
<h2>最後に</h2>
<p>今回はKARTEの開発ではPLAIDだからこそ、KARTEだからこそできる管理画面の観察方法や改善方法を紹介しました😊</p>
<p>もし他のチームで使われている改善方法があったり、新しい改善術があれば、別の機会で紹介したいと思います！</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。0詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


PLAIDでは機能公開する際にユーザビリティテストなどを行なっていますが、それとは別にKARTEの機能や社内ツールを用いたユニークな改善方法を行なっているので、それらをご紹介します！

PLAID流プロダクト改善術をお見せします！

<p>みなさんごきげんよう、Engineerの @tik-son です。02020-10-28に開催された<a href="https://pages.awscloud.com/SaaS_Svrless_EventBridge_seminar.html">&quot;ビジネスにアジリティーをもたらす「SaaS + サーバーレス」&quot;</a>というイベントに<br>
<strong>&quot;User State Driven System with Amazon EventBridge &amp; KARTE&quot;</strong> というテーマで登壇してきました。</p>
<p>PLAIDは2020年1月ごろから<a href="https://aws.amazon.com/jp/blogs/news/new-jp-eventbridge-partners/">EventBridgeのSaaS Partner</a>であり、KARTEのActionの一つとしてEventBridgeが選択できます。<br>
今回のセミナーではEventBridgeを活用したUser State Driven Systemということで、３つの連携例などについてお話しました。</p>
<ul>
<li>ユーザの状態に応じた電話サポート(KARTE × Amazon Connect)</li>
<li>自由記述アンケート分析 (KARTE × Amazon Comprehend)</li>
<li>プロアクティブCall (KARTE × Amazon Connect × shopify)</li>
</ul>
<p>詳細についてはスライドをご覧いただければと思います。</p>
<script async class="speakerdeck-embed" data-id="ac3b373bbd2a47e6b084eb9e90a98a70" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<p>このセミナーではPLAIDの他には以下のS(P)aaS Providerが、それぞれ異なる切り口でEventBridgeについて話をされておりました。<br>
我々はEventBridgeのユーザでもあるのでそういう観点でも色々と勉強になったとともに、これからのEventBridgeのさらなる盛り上がりも感じ取ることできるセミナーでした。</p>
<ul>
<li>Auth0 株式会社</li>
<li>Datadog Japan 合同会社</li>
<li>Game Server Services 株式会社</li>
<li>株式会社はてな</li>
<li>Shopify Japan 株式会社</li>
</ul>
<p>*2020/11/17 追記 AWS Blogにも取り上げていただいたので他の方の発表内容などの詳細を知りたい方はぜひここちらもご覧ください。<a href="https://aws.amazon.com/jp/blogs/news/saas_serverless_eventbridge_seminar/">https://aws.amazon.com/jp/blogs/news/saas_serverless_eventbridge_seminar/</a></p>
<h2>最後に</h2>
<p>発表の中でも話しましたが、KARTEとEventBridge(AWS)で出来ること / 可能性というのはまだまだ未探索なので、面白いことを思いついたり何かフィードバック等ある方は是非コメントなどをいただければと思います。<br>
また、このような連携を通じて、KARTEの新たな価値を作り上げていく仲間も募集しています。興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


"User State Driven System with Amazon EventBridge & KARTE" というテーマで、"ビジネスにアジリティーをもたらす「SaaS + サーバーレス」"というイベントに登壇してきました

User State Driven System with Amazon EventBridge & KARTE について話してきました | PLAID engineer blog

User State Driven System with Amazon EventBridge & KARTE について話してきました

<p>フロントエンド/Node.js エンジニアの mizchi です。plaid では新しい分析エンジンのフロントエンド側の技術的な仕様を考えたり、それを実装したりしています。趣味として社内の他のプロダクトのパフォーマンスを勝手に測って、貼り付けていくこともあります。</p>
<p>plaid のエンジニア組織には「組」という制度があって、メインとなるプロダクト以外にも、そのテーマで会社横断で活動するグループがあり、最低一つ所属することが奨励されています。例えばセキュリティ組、バグトリアージ組、Tech 勉強会組などがあります。</p>
<p>最近になって パフォーマンス組を新設しました。これは主にフロントエンドのパフォーマンスを調査して、各プロダクトにその改善を促すグループです。</p>
<p>plaid のフロントエンドは PaaS としての外向けのサードパーティスクリプトと、その管理画面があるのですが、サードパーティの方はパフォーマンスも計測しているのですが、管理画面の方は歴史が長く設計変更も多々あり、富豪的な感じになってしまっています。</p>
<p>これを改善するためにいくつか調査を行い、実際にいくつかは修正したのですが、本質的には「組織的なパフォーマンス意識」を向上させる必要がある、という結論になりました。組織としてのパフォーマンスを意識できないと、目の前の問題を解決したとして、いずれ再発します。(これはセキュリティなどでも同様ですね)</p>
<p>そこで、その文化の改善のために、まず社内のプロダクトをテーマにハッカソンの開催を開催してみよう、という話になりました。</p>
<h2>開催の経緯</h2>
<p>とある日の slack のスレッドの自分とデザイナーの高橋さんの会話。</p>
<p>mizchi 「ところで Baisu (社内の CSS ガイドライン兼モック) むちゃくちゃ重くないですか」</p>
<p>高橋「めちゃ重いですよね」</p>
<p>mizchi 「なんで重いんだろう… JS でした」</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a087da95-c435-4fd2-abfd-38e3a72107b2/hev.png" alt=""></p>
<p>高橋「モック環境だから色んなライブラリとか試すのにいれまくってるからか！なるほど」</p>
<p>mizchi 「ここパフォチュのお題によさそう。lighthouse で高得点出した人が優勝」</p>
<p>mizchi 「壊しても悲しむのが高橋さんだけってのがパフォチュ向き」</p>
<p>見ていた同僚が突然テザーサイトを作成</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1a3f2fe0-1e1b-444a-abd2-752765626970/aaf620d4154ddc6357cdb16485c6987a.png" alt=""></p>
<p>開催決定！</p>
<p>mizchi「業務時間使って開催しますね」</p>
<p>nashibao(CPO)「どんどんやっていけ」</p>
<h2>真面目な話</h2>
<p>社内のワークフローでは、社内のモノレポの一部の baisu というプロダクトで vue.js のモックページを作成し、それを元に各プロダクトで実装が行われています。</p>
<p>このワークフローの抱える問題として、 baisu の抱えるパフォーマンス上の問題は、そのままプロダクトに引き継がれてしまいます。実際いくつかパフォーマンス上の問題として表出していました。</p>
<p>ここでの改善は、そのまま管理画面やその他のページの改修にそのまま活かせます。プロダクトに直接コミットするより、まず同じ問題を抱えたモックページをチューニングすることで、心理的な負荷を減らしつつ大胆なアプローチを取れるはずだ、と考えました。</p>
<h2>まず自分で解いてみた</h2>
<p>前提として、この baisu というのは、基本的に vue.js + vue-router で構築された SPA です。html-webpack-plugin と webpack, webpack-dev-server で起動し、本番は静的サイトとして superstatic 上で動作します。</p>
<p><a href="https://github.com/firebase/superstatic">firebase/superstatic: Superstatic: a static file server for fancy apps.</a></p>
<p>そもそも問題として適当かどうかを測るため、自分でまず自分がチューニングしつつ問題を洗い出しました。</p>
<ul>
<li>チャンク分割の前に面倒だったのが、babel6 =&gt; 7 のアップグレードだったので、ここで詰まっては本質的ではないので babel 7 へ更新</li>
<li>webpack も dynamic import が使いづらいバージョンだったのを最新版に更新</li>
</ul>
<p>その上で発生している問題の洗い出し。</p>
<ul>
<li>大量のルーティングあるにも関わらず、チャンク分割がなされずに、単一の js として出力されてる</li>
<li>moment の locale をすべて読みこんでいる</li>
<li>vue 用のビューライブラリで、 element-ui というライブラリのコンポーネントを、使うかどうかに関わらず全部読み込んでいる</li>
<li>apexcharts という重いチャートライブラリを全画面で読み込んでいる</li>
<li>fontawesome の全アイコンフォントを読み込んでいる</li>
</ul>
<p>これによって、適当なお題だと判断。あえて放置して本番を迎えました。</p>
<h2>開催告知</h2>
<ul>
<li>社内勉強会で他社のハッカソンのお題に対する解法を解説 <a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a></li>
<li><a href="https://www.amazon.co.jp/dp/B07JJ344WK/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1">超速本の布教</a></li>
</ul>
<p>弊社は 2 ヶ月に一回チームを入れ替えるのですが、その入れ替え期で比較的締め切りなどがない余裕があるタイミングで開催しました。事前に「業務時間を使って参加していいよ、ただしチームの同意はとってね」という周知をしました。</p>
<h2>レギュレーションとスコアサーバーの実装</h2>
<ul>
<li>baisu/app のビルド結果を競う</li>
<li>npm run bundleAnalyze した後の npm run evaluation で localhost:8080 にサーバーを起動</li>
<li>計測サーバーの実装を clone して localhost:8080 のスコアを計測</li>
<li>UI が大幅に壊れている場合は計測対象外とする</li>
</ul>
<p>周知した方向性として、「計測対象となるページの個別の最適化は避けて、できるだけ一般的な、マージしたいと思えるような実装で解いてね(それでもスコアは十分伸びるので)」という感じに。</p>
<p>計測用スクリプトはこんな感じ。</p>
<pre><code class="language-js">const fs = require('fs');
const path = require('path');
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');

const TARGET_URLS = [
    &quot;http://localhost:8080/&quot;,
    &quot;http://localhost:8080/user/story/&quot;,
    &quot;http://localhost:8080/karte/wizard/&quot;,
    &quot;http://localhost:8080/organization/&quot;,
    &quot;http://localhost:8080/account/register/&quot;,
];
const metricsLighthouse = async (chrome, url) =&gt; {
    const options = { logLevel: 'error', output: 'html', onlyCategories: ['performance'], port: chrome.port };
    const runnerResult = await lighthouse(url, options);
    const filename = url.replace(&quot;http://localhost:8080/&quot;, &quot;&quot;).replace(/\//g, &quot;_&quot;);
    const reportHtml = runnerResult.report;
    fs.writeFileSync(`report_${filename}.html`, reportHtml);
    return {
        url,
        score: runnerResult.lhr.categories.performance.score * 100,
        totalByte: runnerResult.lhr.audits[&quot;total-byte-weight&quot;].numericValue
    }
};

(async () =&gt; {
    const chrome = await chromeLauncher.launch({ chromeFlags: ['--headless'] });
    try {
        const results = [];
        for (const url of TARGET_URLS) {
            const result = await metricsLighthouse(chrome, url);
            results.push(result);
        }
        const totalScore = results.reduce((total, result) =&gt; {
            return total + result.score;
        }, 0);
        const totalByte = results.reduce((total, result) =&gt; {
            return total + result.totalByte;
        }, 0);
        console.log(`Total score: ${totalScore}`);
        console.log(`Total bytes: ${totalByte} bytes`);
        console.table(results);
    } finally {
        await chrome.kill();
    }
})();

</code></pre>
<p>要は lighthouse の Performance のスコアです。</p>
<h2>開催</h2>
<ul>
<li>カレンダーで 14:00~19:30 を確保</li>
<li>14:00 に zoom のオンラインミーティングでレギュレーションの説明</li>
<li>18:30 に終了。最終ビルドのスコアを自己申告してもらう。</li>
<li>参加者一人ずつ、PullRequest を見ながらやったことの紹介。全員で講評。</li>
</ul>
<h2>結果</h2>
<ul>
<li>事前の周知の甲斐あって、ほぼ全員が router の lazy load の実装を完了 80mb =&gt; 16mb</li>
<li>ほぼ全員が momment の未使用 locale を削除</li>
<li>半数が element-ui をなんらかの形で未使用コードのドロップを実装</li>
<li>ほぼ全員が fontawesome の最適化に挑むも、削れた人は一部だけ</li>
<li>apexcharts を問題視した人はいたが、アプリケーションコードに手を入れないといけないので放置</li>
</ul>
<p>ほぼ全員が 80mb を 10mb 付近まで削っていたのですが、最終的に優勝したのは、 html-webpack-plugin の吐くコードを書き換えた人で defer にしたことで、lighthouse のスコアが上がった、新卒一年目の <a href="https://github.com/kosukeoya">kosukeoya</a> でした。</p>
<p>kosukeoya 曰く、「自分はフロントエンドのパフォーマンスチューニングは初めてだったが、事前資料として共有されたサイバーエージェントのハッカソンでの最適化を上から順になぞった」ということで、あの資料やっぱ有効だったんだなぁという感じに。</p>
<p><a href="https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-%E5%87%BA%E9%A1%8C%E3%81%AE%E3%81%AD%E3%82%89%E3%81%84%E3%81%A8%E8%A7%A3%E8%AA%AC">https://github.com/CyberAgentHack/web-speed-hackathon-online/wiki/Web-Speed-Hackathon-Online-出題のねらいと解説</a></p>
<h2>参加者の声</h2>
<ul>
<li>webpack-bundle-analyzer がリポジトリに組み込まれていたので、普段は意識しないものを意識できた</li>
<li>やってよかった。いろいろなテクニックにふれる機会があった</li>
<li>フロントエンドの経験値が少なく、直し方はまだ難しく感じるが、問題の見つけ方がわかるようになったのが大きい</li>
<li>最適化ははじめてだったが、コスパよくできる場所があるのがわかった</li>
<li>ベストプラクティスはそんなに難しくなく、知ってれば日常的に採用できるコードが多い</li>
<li>競プロ的な感じ(小難しい解法)かと思ったら普通に一番いいコードが一番効く</li>
<li>(baisu そのものの感想) そもそもうちにこんな数のモックページがあったのか</li>
</ul>
<p><a href="https://www.npmjs.com/package/webpack-bundle-analyzer">webpack-bundle-analyzer - npm</a></p>
<h2>技術的な感想 / 得られた教訓</h2>
<ul>
<li>vue.use 使ってしまうと最適化が難しい</li>
<li>fontawesome が強敵</li>
<li>jquery 消そうとして時間がかかった</li>
<li>chunk に名前つけた方がデバッグしやすい</li>
<li>chunk いっぱい吐くとグラデーションが綺麗</li>
<li>高橋さんの PC のメモリ節約できて嬉しい！</li>
</ul>
<p>きれいな webpack chunk の様子です</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f241e3fb-755b-42c1-9736-9870c2b0a1bc/a11849230c29ee02f649700750dfcae1.jpg" alt="baisu [11 Sep 2020 at 18:25] - Gyazo"></p>
<h2>講評中に見つかった、プロダクトに活かせそうなものの</h2>
<ul>
<li>superstatic の compression(gzip) を有効にする(なってなかった)</li>
<li>JS によって挿入される css で呼ばれる webfont を &lt;link rel=preload ...&gt; で先読みすると、 適用時のガタツキがなくなり、layout junk が減って LCP のスコアがよくなる</li>
</ul>
<p>この辺やらないとわからなかった気がします。</p>
<h2>運営してみての感想 / 反省</h2>
<p>プロダクトと同じ構成のモックの読み込み改善というお題がよかったと思います。そのまま業務にフィードバックできるので、明日からやっていけそう、みたいな声が多かったです。</p>
<p>そもそもルーティングのチャンク分割、 lazyload にたどり着いてくれないとその後の改善がないのが心配だったんですが、参加者全員、そこはたどり着いていました。ハッカソン中に時間経過でヒントを小出ししたのも、何もできない人が出なくてよかったかなと思います。</p>
<p>反省として、最終的な script の defer 属性によるスコア差については、今回のお題ではやや評価が難しいところがあります。なぜなら、baisu は js を読み込まないと画面に何も表示されない、SSR なしの SPA なので、エントリポイントの同期/非同期は、結果的なユーザー体験にあまり影響がありません。</p>
<p>まあ、スコアサーバーの機嫌を読むのもコンテストの一部ということだと思うので、これはこれで良いと思います。ただ html-webpack-plugin の吐くコードに手を入れる、というのは気づきづらかったですね。</p>
<p>人が集まりやすい事前準備をして、告知の反応も多かったんですが、やはり業務時間を使う心理的な抵抗からか人が集まりづらく、想定の半分ぐらいでした。ここは次にもっと工夫したいと思います。</p>
<p>社内プロダクトの改善という他社で再現性があるか微妙なテーマではあり、これも外に出せないのが申し訳ないんですが、似たようなモックと課題をもつような会社では開催できるのではないでしょうか。そもそも実プロダクトを対象にしてもいいと思います。</p>
<h2>Hiring</h2>
<p>plaid では webpack chunk を 1byte でも絞り込みたいという人を募集しています。</p>
<h2>参考にした先行事例</h2>
<ul>
<li><a href="https://www.cyberagent.co.jp/careers/students/career_event/detail/id=24500">https://www.cyberagent.co.jp/careers/students/career_event/detail/id=24500</a></li>
<li><a href="https://techkondo.com/2020/03/13/recuruit-speed-hackathon/">https://techkondo.com/2020/03/13/recuruit-speed-hackathon/</a></li>
</ul>


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

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


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

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

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

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

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


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

Engineer Blog

Recent Article

Google Cloud Day: Digital 2021 で「100億人のユーザー行動からインサイトを得るための大規模分析基盤」等、3セッション登壇しました

AWS Summit Online 2021 にて「AWS と KARTE で作る User State Driven System」について話してきました

Google Cloud Japan Blog で Anthos clusters on AWS を活用した事例が紹介されました

GKE Autopilotで作るMLリアルタイム推論基盤

PLAID流プロダクト改善術をお見せします！

User State Driven System with Amazon EventBridge & KARTE について話してきました

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

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

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

Datadog Summit Tokyoに登壇しました！

Popular Articles

Popular Tags

Archives

Writers