Engineer Blog

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

プレイドでの開発インターン: 3ヶ月のフルタイムエンジニアとしての挑戦を経て

<p>Developers Summit 2023 Summerにて「ユーザー体験と編集体験を支えるビルドアーキテクチャ」について話をしてきました。</p>
<div class="iframely-embed" data-embedded-url="https://event.shoeisha.jp/devsumi/20230727"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://event.shoeisha.jp/devsumi/20230727" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fevent.shoeisha.jp%2Fdevsumi%2F20230727&key=878c5bef402f0b2911bf6d4ce6261abd"></a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>関係者各位には、登壇機会いただけましてありがとうございます！</p>
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/b435db5d640740349140fc91bb704fa9" title="ユーザー体験と編集体験を支えるビルドアーキテクチャ" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>
<p>内容自体は後日記事にしてあげてくださるかと思いますので、この記事では発表に付随する内容をちょっと書こうかと思います。</p>
<h3>フロントエンドアーキテクチャ</h3>
<p>まずタイトルにある「ビルドアーキテクチャ」という言葉ですが、多分聞いたことないかと思います。実際Googleで検索してもヒットしません。今回の発表で使った造語です。<br>
アーキテクチャと言われるとどうしてもインフラ構成とかバックエンドシステムなど、いわゆる「システムアーキテクチャ」の話がされることが多いかと思います。</p>
<p>ただ、我々がエディタというシステムを開発して感じたこととして、「フロントエンドのアーキテクチャ」もかなり複雑でかつ重要なものに進化してきている、ということです。<br>
例えば、ReactやVue.jsなどでフロントエンドの各パーツが連動して動く仕組み、今回のビルドのようにフロントエンドで複数プロセス（Worker）が連携して動く処理、サーバサイドレンダリングなどサーバでの処理自体もフロントエンドから見て１プロセスのように動く仕組み、など、多くの「フロントエンドアーキテクチャ」と呼んで良い構成が見られます。<br>
今回の発表チャレンジしたかったこととして、アーキテクチャと言った時に、バックエンドの大規模システムだけではなく、フロントエンドのブラウザ内アーキテクチャにも興味持ってもらえる人が増えると良いなと思って発表をしました。</p>
<h3>We are hiring!</h3>
<p>というわけで、大規模トラフィックを捌くシステムアーキテクチャを作りたい人ももちろん募集しておりますが、フロントエンドのアーキテクチャにこだわって、より良いユーザー体験のために技術に投資していける人材もガンガン募集しております！</p>


発表した内容の補足などを記載しました。

アクションをビルドするためのアーキテクチャについて、Developers Summit 2023 Summerで発表してきました

<p>一般社団法人 日本CTO協会(本社：東京都渋谷区／代表理事：松岡剛志)により発表された「<a href="https://dxd2023.cto-a.org/dxaward">Developer eXperience AWARD 2023</a>」にて、26位で去年に引き続きランクインさせていただきました。去年の29位よりランクアップです！</p>
<p>そのため、今回はどのようにしてプレイドでは開発者体験を向上させているか、そのために行なっていることをいくつかピックアップしてみました。</p>
<h2>開発環境改善への投資</h2>
<p>プレイドでは開発体験を向上させるために、継続的に開発環境やその環境の改善を行なっています。例えば本番環境でkubernetesを使っているのですが、開発環境でもそのkubernetesを活かすべく仕組みを導入して試しています。<br>
<a href="https://tech.plaid.co.jp/our-seeking-to-stable-k8s-deployment">Our seeking to stable k8s deployment.</a><br>
<a href="https://tech.plaid.co.jp/intern_qualt_environment">PLAIDのインターンを振り返って ~ 開発環境の改善がもたらす新機能リリースの効率化 ~</a></p>
<p>また、開発者の生産性向上のためにコストもかけており、例えば好きに経費を使えるProPayという制度などもあります。CPOも「環境投資は死ぬほど安い！！」と言っており、モニタ・キーボード・椅子etcなどのすぐできる環境投資も積極的に行っています。</p>
<h2>開発プロセスの改善</h2>
<p>開発体験の大きな要素である開発プロセス自体も改善の対象にしており、毎Quarterごとに進め方のトライを行なって、プロセス自体のアップデートを行なっています。<br>
<a href="https://speakerdeck.com/kadoppe/wei-zhi-falsegu-ke-nitotutemojia-zhi-arupurodakutowosheng-michu-su-cbf6e740-66f8-4056-a1a7-08b0c7bbfe57">未知の顧客にとっても価値あるプロダクトを生み出す</a></p>
<p>そんな環境のため、エンジニアもプロダクトや課題解決にフォーカスして、目的思考で開発できる環境ができています。<br>
<a href="https://www.wantedly.com/hiringeek/interview/rc_ttb9/">プレイドが自律・分散型チームをつくる上で大切にしたコト｜#9 プレイドCPO柴山氏｜TECH TEAM BUILDERS</a><br>
<a href="https://tech.plaid.co.jp/plaid-engineer-culture-from-new-employee">入社4ヶ月で感じたプレイドエンジニアの組織文化</a></p>
<h1>募集しています</h1>
<p>プレイドでは現在エンジニアを積極採用中です！少しでもご興味ある方がいましたらぜひお話を聞きにきてください。もっと具体的なお話もできるかと思いますので、少しでも気になった方はぜひ聞きにきてください！</p>
<p><a href="https://recruit.plaid.co.jp/engineer">Engineering at PLAID</a></p>


日本CTO協会のDeveloper eXperience AWARD 2023で去年に引き続き、26位にランクインさせていただきました。この記事ではプレイドでどんなDXのためにどんな考え方で開発者環境を作っているか、ざっくりとまとめてみました。

Developer eXperience AWARD 2023の上位30にランクインしました！

<h1>Introduction</h1>
<p><a href="https://tech.plaid.co.jp/blits_pre_aggregation">前編</a>の記事では、Personalizationに特化したリアルタイムユーザー解析エンジン（Blitz）のコンセプトとPre-Aggregation手法を説明しました。</p>
<p>今回は刷新された解析エンジンのコア要素である「強整合な解析」を実現するアーキテクチャのポイントを紹介します。</p>
<h2>強整合な解析とは何か？</h2>
<p>プレイドの新しい解析エンジンでは、とあるユーザーのイベントが発生した際、過去も含めたイベント履歴やユーザーごとの統計値を元にフィルタリングを行うことができます。</p>
<p>強整合な解析とは、フィルタリングを行うユーザーの統計値が必ず最新の状態であること、つまり過去全てのイベント履歴が反映されていることを指します。</p>
<p>やりたいことはとてもシンプルですが、秒間最大13.4万イベントが発生する高トラフィック、かつ数百ms内の低レイテンシーが求められる状況下で、ユーザーの統計値を常に最新に保つことは技術的に難しい問題です。</p>
<p>これからその技術的課題とどういうアーキテクチャを元に解決したのかを話していきます。</p>
<pre><code class="language-js">{
  $meta: {
    name: &quot;nashibao&quot;,
    isMember: 1
  },
  $buy: {
    items: [{
			sku: &quot;xxx&quot;,
			price: 1000,
    }]
  }
}
</code></pre>
<p>[図1: イベントデータ]</p>
<pre><code class="language-js">match(&quot;userId-xxx&quot;,
  DAY.Current('$meta.isMember', 'last') = 1,
  ALL.Current('$buy.items.price', 'avg') &gt;= 10000,
  WEEK.Previous('$buy.items.price', 'sum') &lt;= 100,
  WEEK.Previous('$session', 'count') &gt; 10,
  ...
)
</code></pre>
<p>[図2: ルール定義の擬似コード]</p>
<p><em>これは “userId-xxx” が “会員” であり、1年間では購買単価が1万円以上で、先週のセッション数が10以上に関わらずほとんど買い物に繋がらなかったユーザー なのかどうかを検証するルールを示した疑似コードです。</em></p>
<h2>刷新前の解析エンジンのアーキテクチャとその課題</h2>
<p>今回刷新される前の解析エンジンのアーキテクチャとその当時の課題をまずお話しします。</p>
<p>以前はリアルタイム解析を行うコンポーネント（Track）と非同期にでユーザーの統計値を更新するコンポーネント（Analyze）の二つで構成されていました。</p>
<p><img src="https://ik.imagekit.io/plaid/2bfde737-4163-435f-baba-37ec7bf299d9/Track_Architecture.png" alt="Track_Architecture.png"></p>
<p>[図3: 刷新前の解析エンジンのアーキテクチャ]</p>
<p>このアーキテクチャのポイントは</p>
<ul>
<li>リアルタイム側（Track）では、事前に生成されたユーザーの統計値をKey-Value Storeから読み込みするのみで書き込みは行わない</li>
<li>非同期側（Analyze）でキューに積まれたイベントをまとめて処理する</li>
</ul>
<p>です。</p>
<p>高速なKey-Value Storeからの読み込みによってリアルタイム解析を1秒以内に抑えつつ、非同期側で効率良く処理し、Key-Value Storeの書き込みの負荷を抑えていました。</p>
<p>ただ、タイミングによっては非同期側（Analyze）で処理中のイベントがユーザーの統計値に反映されない状態が発生しえます。そのため、リアルタイム側では常にユーザーの統計値を一貫した状態に保つことが難しい状況でした（結果整合な解析）。</p>
<h2>結果整合 → 強整合な解析にするためのアーキテクチャ</h2>
<p>上で説明した技術的な課題を踏まえ、図4が刷新後のアーキテクチャです。既存からの変更点としては、</p>
<ul>
<li>リアルタイム側のサーバーを二つに分割し、まずフロントエンドサーバーは分散キューにイベントを書き込む</li>
<li>リアルタイム側のバックエンドサーバーは、イベントを分散キューから読み込み、解析を行う</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/65e3e998-8b4a-484c-bf51-9638556e3f25/Blitz_Architecture.png" alt="Blitz_Architecture.png"></p>
<p>[図4: 刷新後の解析エンジンのアーキテクチャ）</p>
<p>この変更によって、ユーザーの統計値に未反映のイベントが存在したとしても、リアルタイム解析のバックエンドサーバー側で分散キューを読み込むことで、常にユーザーの統計値を最新の状態に保つことができるようになりました。</p>
<p>つまり分散キューを前段に置くことで強整合な解析を実現しました。</p>
<p>ただ、解析を数百ms以内に行うという解析エンジンの制約があるため、この分散キューに求められる性能要件はとても厳しいものとなります。</p>
<p>次にどうこの分散キューを実現したのかの話をしていきます。</p>
<h2>高スケーラビリティかつ低レイテンシな分散キューの実現方法</h2>
<p>この分散キューには以下の通り、厳しい性能要件があります。</p>
<ul>
<li>高スケーラビリティ
<ul>
<li>高トラフィックなイベント数に対してスケールできる</li>
<li>参考値：日中のピーク時に書き込みリクエストが30,000 ops、書き込みデータ量が300MiB/s</li>
</ul>
</li>
<li>低レイテンシー
<ul>
<li>書き込み、読み込み共に10ms以内</li>
</ul>
</li>
</ul>
<p>既存のメッセージング系のサービスだと、高スケーラビリティと低レイテンシーを同時に満たすものがありませんでした。</p>
<table>
<thead>
<tr>
<th>サービス</th>
<th>高スケーラビリティ</th>
<th>低レイテンシー（10ms以内）</th>
</tr>
</thead>
<tbody>
<tr>
<td>Redis Queue</td>
<td>×</td>
<td>◯</td>
</tr>
<tr>
<td>Cloud PubSub</td>
<td></td>
<td></td>
</tr>
<tr>
<td>(with Ordering)</td>
<td>◯</td>
<td>×</td>
</tr>
<tr>
<td>Kafka</td>
<td>△</td>
<td>△</td>
</tr>
</tbody>
</table>
<p>そこで僕らは、低レイテンシーなKey-Value Storeと知られたCloud Bigtableを用いて分散キューを実現しました。これからその具体の方法を紹介していきます。</p>
<p>Cloud Bigtableは主にKey-Valueストアとして知られ、一桁ミリ秒単位の低レイテンシーかつ水平スケールすることができます。僕らが着目したのは、行キーの開始と終了を指定したレンジスキャンも同じく高速であるという点です。</p>
<p>具体的な分散キューのスキーマを説明すると以下のような形になります。</p>
<pre><code>行キー = ${プレフィックス}_${ユーザーID}_${イベントのtimestamp}
バリュー = イベントデータ
</code></pre>
<p>ポイントは末尾につけたイベントのtimestampです。これによって、イベントのtimestampの開始・終了を指定してレンジスキャンすることができるようになります。</p>
<p>また、Cloud Bigtableの<a href="https://cloud.google.com/bigtable/docs/garbage-collection?hl=ja">ガベージコレクション機能</a>を用いてTTLを設定することでキューとして古いデータを削除する機能を簡単に実現することができました。</p>
<p>まとめると、Cloud Bigtableの行キーのスキーマ設計やガベージコレクション機能を工夫することで、水平スケール可能かつ10ms以内のレイテンシーで収まる分散キューを作ることができました。</p>
<h2>最後に</h2>
<p>今回はリアルタイムユーザー解析エンジン（Blitz）のコアである強整合な解析を実現するためのアーキテクチャ・具体の実装方法を紹介しました。</p>
<p>解析エンジンの中には高いパフォーマンス（低レイテンシーや安定的な高スループット）を出すための技術的な工夫がまだまだいっぱい施されています。</p>
<p>特に低レイテンシーを実現するためのキャッシュ戦略について、他のエンジニアから今後話してもらう予定です。是非楽しみにしていてください。</p>


PLAIDではPersonalizationに特化したリアルタイムユーザー解析エンジン（Blitz）を自分達で開発し、KARTEの基盤として使ってきました。今回新たに刷新した解析エンジンのコア要素である「強整合な解析」を実現する具体的なアーキテクチャ、技術選定の内容を紹介します。

Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術（強整合な解析） - PLAID engineer blog

Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 - 

<h2>Introduction</h2>
<p>PLAIDでは9年ほど前から、大規模ストリーミングデータから高速に、Aggregation/Filteringをするモジュールを育ててきて、KARTEというプロダクトの基盤としてきています。Personalizeのようなタスクをツールにガシガシ組み込むために必要なモジュールで、かなりニッチな情報ということもあって外部にあまり発信する機会がありませんでした。（決して面倒だったからではありません。決して。。）</p>
<p>ただ、少し前にそのエンジンの刷新プロジェクトが終わったところで、そのプロジェクトの発信と併せて、初期コンセプト上の面白み（コード上は2度3度と刷新されていますが、初期コンセプトの面白い部分は踏襲されつつ新しいものが加わっています）もそれなりにあるし、発信してみようと思って書き始めました。</p>
<h2>要求されること</h2>
<p>現在は コードネーム “Blitz” と呼ばれる分析モジュールは、Personalizationに特化したもので、スキーマが固定されないJson形式での次のようなイベントストリーム</p>
<pre><code class="language-jsx">{
  $meta: {
    name: &quot;nashibao&quot;,
    isMember: 1
  },
  $buy: {
    items: [{
			sku: &quot;xxx&quot;,
			price: 1000,
    }]
  }
}
</code></pre>
<p>[図1: イベントデータ]</p>
<p>がuserIdに紐づいて飛んできた時に、次のようなフィルタリングを高速に処理することができるものです。</p>
<pre><code class="language-jsx">match(&quot;userId-xxx&quot;,
  DAY.Current('$meta.isMember', 'last') = 1,
  ALL.Current('$buy.items.price', 'avg') &gt;= 10000,
  WEEK.Previous('$buy.items.price', 'sum') &lt;= 100,
  WEEK.Previous('$session', 'count') &gt; 10,
  ...
)
</code></pre>
<p>[図2: ルール定義の疑似コード]</p>
<p>これは “userId-xxx” が “会員” であり、1年間では購買単価が1万円以上で、先週のセッション数が10以上に関わらずほとんど買い物に繋がらなかったユーザー なのかどうかを検証するルールを示した疑似コードです。</p>
<p>この時に、厳しい性能要件をクリアするように作られています。</p>
<table>
<thead>
<tr>
<th>種類</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr>
<td>スケーラビリティ</td>
<td>- High Trafficなユーザー数やイベント数に対してスケールする<br>- 時間経過と共に性能が劣化しない<br>- 時間経過と共にストレージコストが爆発しない</td>
</tr>
<tr>
<td>低レイテンシ</td>
<td>- 数百ms以内にレスポンスする</td>
</tr>
<tr>
<td>新鮮性</td>
<td>- 計算にラグが発生しない = 数秒前のイベントも考慮される<br>（初期ver: 結果整合性 → 現在: 強整合性)</td>
</tr>
<tr>
<td>スキーマレス</td>
<td>- 送信されるイベントは、スキーマが固定されない<br>- 多様なデータ型（Nest / Array含む）が送信される</td>
</tr>
<tr>
<td>即時更新性</td>
<td>- 検証ルールの変更は、数分でデプロイされる<br>- 過去データを遡って考慮する</td>
</tr>
<tr>
<td>自由度</td>
<td>- 多種多様なタイムウィンドウ、演算子に対応している</td>
</tr>
</tbody>
</table>
<p>特にルールやイベントの自由度を高く維持する割に、過去データの再集計などでラグが発生せずにルールの変更を反映し、数百ms以内にレスポンスを返せる状態に持っていくことが非常に <s>めんどくさい</s> 難しい要件になります。</p>
<p>既存の基盤やフレームワークをカスタムして作る方針で初期は検討しましたが、なかなか要件に見合わなかったため、ストレージレイヤーより上部に関しては主に自社で構築しています。</p>
<table>
<thead>
<tr>
<th>Name</th>
<th>スケーラビリティ</th>
<th>低レイテンシ</th>
<th>新鮮性</th>
<th>スキーマレス</th>
<th>即時更新性</th>
<th>自由度</th>
</tr>
</thead>
<tbody>
<tr>
<td>Embed (単純に事前に処理を組み込んだもの)</td>
<td>◉</td>
<td>◉</td>
<td>◉</td>
<td>x</td>
<td>◉</td>
<td>x</td>
</tr>
<tr>
<td>Batch Processing (ex: MapReduce)</td>
<td>◉</td>
<td>x</td>
<td>x</td>
<td>◉</td>
<td>-</td>
<td>◉</td>
</tr>
<tr>
<td>Stream Processing (ex: Beam)</td>
<td>- (過去データは捨てられる)</td>
<td>◉</td>
<td>◉</td>
<td>◉</td>
<td>x</td>
<td>◉</td>
</tr>
<tr>
<td>Lambda Architecture</td>
<td>◉</td>
<td>▲ (x 1sec未満)</td>
<td>◉</td>
<td>◉</td>
<td>x</td>
<td>◉</td>
</tr>
<tr>
<td>Blitz</td>
<td>◉</td>
<td>◉</td>
<td>◉</td>
<td>◉</td>
<td>◉</td>
<td>▲</td>
</tr>
</tbody>
</table>
<p>SQLほどの自由度は持たせない代わりに、他の要件を満たすように作られています。考え方としては、Aggregation処理を事前処理と事後処理の2つの処理に分解しているという意味で、Lambda Architectureや一部のOLAPに非常に近く、それらをStream処理向けに実装したものと理解するのが近いかもしれません。</p>
<h2>ストレージ&amp;計算コスト</h2>
<pre><code class="language-jsx">Space Complexity ∝ Time Complexity = O(T)
</code></pre>
<p>通常、ルールを変更した上で過去データも含めて計算し直すためには、時系列データをスキャンする必要があるため、必要なストレージは経過時間(<code>T</code>)に比例して増えていきます。また処理によっては分散も可能ですが、計算コストもそのストレージサイズに比例して増えるので、結果的に時間に比例して増えていきます。</p>
<p>これに対してBlitzでは</p>
<pre><code class="language-jsx">Space Complexity ∝ Time Complexity = O(D)
</code></pre>
<p>時系列でのデータを、後続処理での自由度を減らさないように送信イベントのスキーマのフィールド数(<code>D</code>)ごとに最小単位の統計値の集合に圧縮し（Pre-Aggregation処理）（この最小単位の統計値の計算の種類は実は大きいですが、固定値）、これらを検証ルールへの適合時にもう一度組み合わせる (Post-Aggregation処理) ことで、ストレージコスト、計算コスト共に、時間(<code>T</code>)ではなくイベントスキーマのフィールド数(<code>D</code>)に比例するように変更しています。</p>
<p><img src="https://ik.imagekit.io/plaid/ba74a798-8f73-4a03-8aa6-8199e7c74bf8/image.png" alt="image.png"></p>
<p>様々なタイムウィンドウと演算子を念頭に置き、多様な統計量を用意するために、事前にある程度大きな空間をAggregate軸（この場合ユーザー)ごとに用意して置く必要があります。そのため経過時間に対して、実は初期は過大に空間を食いますが、経過時間と共に処理後の方が空間・計算コスト共に効率的になっていく想定です。</p>
<p><img src="https://ik.imagekit.io/plaid/e56ce33a-4ad3-423d-b408-4d41e655955d/image(1).png" alt="image(1).png"></p>
<h2>Pre-Aggregation処理</h2>
<p>処理のフローやアーキテクチャの考え方には面白いところがたくさんありますが、ここではストレージサイズに話を絞ることにし、Pre-Aggregation処理によるデータ変換をどのように行なっているかを簡単に紹介します。</p>
<p>統計的な圧縮処理（Pre-Aggregation）のデータフローの簡易的な図は以下です。BlitzではMapReduceのReduce処理と同じように、Tree構造で分解可能な処理のみを許しています。そうすることで処理の分散性を保つと共に、下に示すような統計値同士のRollupも可能にするため、さらにストレージサイズを下げることができます（たとえば、日のデータを7つ持っていれば週のデータを作れます）。</p>
<p><img src="https://ik.imagekit.io/plaid/af418988-bcb7-4dfa-a4d7-951c9bfd8d0e/image(2).png" alt="image(2).png"></p>
<p>Aggregationの自由度や新鮮性を達成するために、Reduce処理の実態は非常に複雑で、CAS操作のようにEventそのものと様々なTimewindowの統計値を読み出し結合した上で、上書き(Swap)する操作を含んでいます。</p>
<p>どのようにRollupを計画するのか、競合をどのように排除するかも非常に面白い部分ですが、ここでは紹介しません。</p>
<p>このようにすることでRead時に消費したEventや古くなったSlotはどんどん破棄していくことができます。</p>
<p><img src="https://ik.imagekit.io/plaid/e4456103-e9bb-4305-906a-d9f64810dac8/image(3).png" alt="image(3).png"></p>
<h2>最後に</h2>
<p>さて前編はここまでにします。紹介した通り、この初期コンセプトの考え方は至ってシンプルなものです。しかし、机上ではシンプルですが、実際の実装上においては、Hight Trafficを裁くための技術やHot Spotを避けるための技術、強整合を保つための技術などなど、様々な面白さが詰まっています。</p>
<p><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">後編</a>ではBlitzの開発メンバーがその実装に入り込んだ面白さを紹介します。</p>


database, analytics, karte, algorithm, aggregation, blitz

Blitz（前編）：自由度と即時更新性を担保したAggregation - PLAID engineer blog

Blitz（前編）: 自由度と即時更新性を担保したAggregation

Engineer Blog

Recent Article