Engineer Blog

Louis Avondet

Sota Sato

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>デザインエンジニアの安田（<a href="https://x.com/_yuheiy">@_yuheiy</a>）です。</p>
<p>プレイドの多くのシステムでは、サーバーサイドの実行環境としてNode.jsを採用しています。そのため、サーバーサイドもクライアントサイドもまとめてnpmを使って依存パッケージ（dependencies）を管理している場合がほとんどです。</p>
<p>システムのメンテナンスにおいては、このような依存パッケージのバージョンを継続的にアップデートし続けることが重要です。そこで今回は、社内向けに実施した、依存パッケージのバージョンアップをテーマにした発表を一部再編集してご紹介します。</p>
<h2>なぜ依存パッケージのアップデートが必要か</h2>
<p>筆者が所属するDeveloper Experience &amp; Performanceチーム（通称: DXチーム）では、その活動の一つとして、さまざまなシステムの依存パッケージのバージョンをアップデートして回るような作業をする機会がよくあります。DXチームでは、現在アクティブに開発が行われていない一部システムのメンテナンスを担当したり、既存のチームの開発をヘルプしたりする場面があり、その一環として併せてこのような作業を行っています。</p>
<p>依存パッケージをアップデートすることには、おもに次のような理由があります。</p>
<p>まず最初は、Node.jsのバージョンアップに対応するためです。Node.jsのバージョンアップにともなって古いバージョンの依存パッケージが動作しなくなることがあるので、Node.jsに追従するために必要な作業です。</p>
<p>次は、一般的なソフトウェア品質や開発効率の向上のためです。多くのパッケージはバージョンアップにともなって、動作上のバグの修正やパフォーマンスの改善、セキュリティ上の問題の解決が行われているほか、便利な新機能が追加されたりしています。これによってソフトウェアの外部品質が改善したり、余計な実装が不要になって設計がシンプルになったりする可能性があります。また、古いバージョンのパッケージを使い続けていることで、それに携わる開発者が古いバージョンの使い方を調べたり覚えたりといった無駄な学習コストを払わなければならないという問題もあります。</p>
<h2>デザインシステムの最新化のために</h2>
<p>もう一つの理由は、利用されているデザインシステムを最新化するためです。社内向けのデザインシステムであるSourが多くのシステムに導入されていますが、Sour自体の内容は日々アップデートされ続けている一方、各システムで利用されているSourのバージョンはアップデートされずに古いものが使い続けられていることが少なくありません。</p>
<p>参考までに、<a href="https://karte.io/">KARTE</a>のリポジトリにおいて使用されているSourのバージョンは次の通りです（件数は発表時のもの）。</p>
<ul>
<li>4.x: 5件（うち3件はDXチームが管理するシステム）</li>
<li>3.x: 5件</li>
<li>2.x: 11件</li>
<li>1.x: 2件</li>
<li>0.x: 1件</li>
</ul>
<p>筆者の本務はSourの開発ですが、ユーザー側でのバージョンアップが行われなければ開発している意味がありません。そのため私自身がそのアップデート作業を担当することもありますが、それに併せてその周辺環境を整備しなければならない場面もあります。というのも、Sour自身が依存しているパッケージのアップデートにともなって、ユーザー側の関連するライブラリのアップデートをしなければならなくなったり、もしくは、そのようなアップデートにともなう問題が発生しないかをテストするための環境が必要になったりすることもあるからです。</p>
<h2>タイミングが遅れるほどアップデート作業が難しくなる</h2>
<p>一般的に、依存パッケージが古くなればなるほど対処が必要な問題が増えて複雑化し、作業が難しくなる傾向にあります。特に古いシステムをメンテナンスしていると、複数の古い依存パッケージ同士が絡み合う問題が発生してデバッグが難しくなったり、古いバージョンで想定されていなかった環境依存の問題が発生して解決のために余計な手間を取られたりすることがよくあります。</p>
<p>また、関連する機能を担当した当時の開発者がチームや会社を離れたりしていることもあります。アップデートにともなう動作確認が必要になることがありますが、そのような場合、期待される正しい仕様や動作確認の方法がわからなくなる可能性もあります。あるいは、当時の担当者にしか意図を理解できないトリッキーな実装が行われているような場合もあります。</p>
<h2>「システムのメンテナンスは天下の回りもの」</h2>
<p>これは昔から個人的に唱えている理論です。システム開発の仕事をしていると、知らない誰かが作ったシステムを回り回って自分が引き継ぐというような場面は珍しくありません。そして、自分が作ったシステムもいずれまた別の誰かに引き継がれていくことになります。</p>
<p>システムの出来の良し悪しにかかわらず、引き継いだ人にはそのすべてを引き受ける責任が生じます。だからこそ、後任の誰かのために、自分が今担当しているシステムはできるだけ良い状態にしておくという心づもりでいることが大事だと思います。</p>
<h2>作業の進め方</h2>
<p>具体的な話に移ります。</p>
<p>まず、これから説明するような作業にあたっては、さまざまな観点でのソースコードの変更をしなければならない場合があります。そのため、必ずしも1つのpull requestで一気に対応しようとするのではなく、適切な粒度に分解しながら作業を進めてください。これについては普段の機能開発と同じです。</p>
<p>次に、CIが不十分だと感じる場合はあらかじめ整備しておくのがよいです。作業を細かく分割するほど、人力ではチェックの抜け漏れが発生しがちです。変更にともなうテストを効率的に行うために、できるかぎり自動化してしまいましょう。</p>
<h3>不要な依存パッケージを削除する</h3>
<p>アップデートの前に、不要な依存パッケージがあればあらかじめ削除しておきます。使わないものをアップデートしても仕方がないからです。</p>
<p><a href="https://knip.dev/">Knip</a>を導入することで、未使用の依存パッケージやデッドコードの検出ができます。これらを削除することで余計な要素を削れます。さらに、KnipをCIに組み込むことで、今後余計なものが追加されないように予防することもできます。</p>
<p>また、そのほかにも不要な機能などが残っていれば削除しておきます。</p>
<h3>言語の標準機能に置き換える</h3>
<p>Node.jsのアップデートにともなって、これまでサードパーティのパッケージが必要だったことが、Node.jsのコアの機能として実現できるようになっていることがあります。「<a href="https://zenn.dev/morinokami/articles/npm-uninstall">Node.js の進化に伴い不要となったかもしれないパッケージたち</a>」などを参考にして置き換えてください。</p>
<p>また、ECMAScriptやDOM仕様のアップデートにともなって、同じくサードパーティのパッケージが不要になることもあります。「<a href="https://github.com/you-dont-need/You-Dont-Need">You-Dont-Need</a>」などが参考になります。</p>
<p>依存パッケージを減らしてコアの機能に置き換えていくことで、将来的なメンテナンスコストを削減できることになります。</p>
<h3>package.jsonのアップデート</h3>
<p><code>package.json</code>に記述されている<code>dependencies</code>や<code>devDependencies</code>のバージョンをアップデートする際には、次のようなコマンドを使用すると一気に書き換えができて便利です。<code>--interactive</code>オプションを指定することで、アップデートする対象をチェックボックス方式で選択できます。</p>
<p>npmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
npx npm-check-updates --workspaces --root --interactive
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/9266d5fd-ceff-47f0-a94e-7d78bcfe707e/ncu.png" alt="新しいバージョンが存在するdependenciesのうち、必要なものを選択式でアップデートできる。パッケージごとに現在のバージョンとアップデート後のバーションが表示される。"></p>
<p>出典: <a href="https://github.com/raineorshine/npm-check-updates">raineorshine/npm-check-updates: Find newer versions of package dependencies than what your package.json allows</a></p>
<p>pnpmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
pnpm update --latest --recursive --interactive
</code></pre>
<p>pnpm 10.12以降であれば、catalogsで管理しているバージョンもいっしょにアップデートできます。</p>
<p>またロックファイルは壊れやすいので、インストールに際して問題が発生した場合は再生成してみるとよいです。</p>
<pre><code class="language-bash">rm -rf package-lock.json **/node_modules &amp;&amp; npm install
</code></pre>
<h3>破壊的変更への対応</h3>
<p>セマンティックバージョニングにおいては、メジャーバージョンが上がるか、もしくは1.0.0に満たない場合のバージョンアップでは、常に破壊的変更の可能性があります。そのためアップデートをする前には、ざっとでもいいのでパッケージのCHANGELOGに目を通しておくことをおすすめします。</p>
<p>また、最新版よりもいくつも古いバージョンを使っている場合は、破壊的変更が積み重なって簡単にアップデートできないことがあります。そのような場合、バージョンは一気に上げるのではなく、ある程度の区切りに分けて段階的にアップデートしたほうが作業が簡単になります。</p>
<h3>後継のライブラリに置き換える</h3>
<p>場合によっては、あるパッケージの代わりとなる後継のパッケージ（ライブラリ）が登場しているがあります。既存のパッケージがメンテナンスされなくなったり、アーキテクチャが古くなって根本的な刷新が必要になったりしたときに、それを置き換えるために別のものが開発されて、コミュニティでもそちらが主流になっていくというパターンです。</p>
<p>KARTEでよく使われているところで言えば、次のような後継のパッケージがあります。</p>
<ul>
<li>Jade → <a href="https://pugjs.org/api/getting-started.html">Pug</a>（参考: <a href="https://github.com/pugjs/pug/issues/2184">Renaming jade -&gt; pug · Issue #2184 · pugjs/pug</a>）</li>
<li><a href="https://github.com/TypeStrong/ts-node">ts-node</a> → <a href="https://tsx.is/">tsx</a>（もしくは、<a href="https://nodejs.org/api/typescript.html#type-stripping">Node.jsのtype stripping</a>を使う）</li>
<li><a href="https://jestjs.io/">Jest</a> → <a href="https://vitest.dev/">Vitest</a></li>
<li><a href="https://recoiljs.org/">Recoil</a> → <a href="https://jotai.org/">Jotai</a></li>
<li><a href="https://lodash.com/">Lodash</a> → <a href="https://es-toolkit.dev/">es-toolkit</a></li>
<li><a href="https://github.com/raineorshine/npm-check-updates">npm-check-update</a> + <a href="https://github.com/ds300/patch-package">patch-package</a> + <a href="https://github.com/open-cli-tools/concurrently">concurrently</a> → <a href="https://pnpm.io/">pnpm</a> CLI（同等の機能がpnpmに組み込まれている）</li>
</ul>
<p>既存パッケージのアップデートと併せて、後継のパッケージへの移行も行いましょう。</p>
<h3>気になる部分はついでに改善しながら進める</h3>
<p>パッケージのアップデート作業をしていると、それに関係するほかの部分が気になることもあります。気になった部分についても、そのままにしておかず、せっかくなのでついでに改善してしまうのがよいです。たとえば次のようなものです。</p>
<ul>
<li>CIの構成をきれいにする</li>
<li>いらないnpm scriptsを消す</li>
<li>冗長な設定ファイルをクリーンアップする</li>
<li>deprecatedなメソッドの使用箇所を直す</li>
<li>破壊的変更がある箇所の周辺のコードをリファクタリングする</li>
</ul>
<p>このようなメンテナンス作業は普段は軽視されがちで、ともすれば老朽化した仕組みがそのまま何年も動き続けていることになりがちです。だからこそ、みなさんにはぜひ<a href="https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html">ボーイスカウト・ルール</a>を意識してもらいたいです。</p>
<blockquote>
<p>ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです（このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています）。</p>
<p>これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュールを改善する努力を続けたとしたら、その結果どういうことが起きると思いますか?</p>
</blockquote>
<p>出典: Kevlin Henney編、和田卓人監修『プログラマが知るべき97のこと』、オライリージャパン、2010年</p>
<h2>こまめなアップデートを習慣化する</h2>
<p>アップデート作業は後回しにするほど面倒な問題を引き起こしがちです。善は急げと思って、まずは今日からやってみましょう。</p>
<p>いったんひと通りのアップデートができたら、それ以降も定期的にアップデートを続けられるように、次に作業する日を決めてしまいましょう。月に1回程度が目安です。もしくは、<a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot">Dependabot</a>などの自動化ツールを使って作業を自動化するのもよいと思います。</p>


Node.jsやフロントエンドのプロジェクトにおけるdependenciesをアップデートするうえでのよくある問題やうまく進めるためのコツなど。

package.jsonのdependenciesをアップデートする技術

Tailwind CSSのバージョンをアップグレードしてTailwind CSS 4に対応する際に作成した、Figmaのstylesをもとにして各種設定ファイルを自動生成する仕組みについての紹介。

Figmaのstylesをもとにして「Tailwind CSSのテーマ」「tailwind-mergeの設定」「Storybookのドキュメント」などの各種ファイルを自動生成する

<h2>はじめに</h2>
<p>こんにちは！</p>
<p>プレイドで６月から７月末までEngineerインターンとして働いていたアボンデットルイです。現在はアメリカのマサチューセッツ工科大学（MIT）でコンピューターサイエンスを専攻している大学生です。</p>
<p>高校でエンジニアリングに興味を持ち、知識を活かして価値のあるものを作り出せることに魅力を感じました。そこからプログラミングを始め、今ではコンピューターサイエンスのさまざまな分野を幅広く探求しています。</p>
<p>同じくCSを学んだ<a href="https://tech.plaid.co.jp/intern-at-plaid-avondet">兄が以前プレイドでインターンをした</a>ことがあり、とてもいい経験だったと聞いたので、僕も挑戦したいと思い今回応募しました。</p>
<p>今回が初めての日本の企業での実務経験で、エンジニアとして働くことの楽しさや難しさを実感しながら、たくさんのことを学ぶことができました。このブログでは、インターンでの経験を振り返りながら、自分が学んだことについて共有したいと思います。</p>
<h2>① UI基礎の習得</h2>
<p>インターンに参加する前から、個人でWebアプリをいくつか作っていたこともあり、特にフロントエンド開発にはある程度慣れていました。その経験を活かして、最初は<a href="https://karte.io/">KARTE</a>のフロントエンドに関わる開発に取り組みました。</p>
<p>インターン開始直後は、Vue.jsやKARTEのコードベースに慣れるため、比較的シンプルなUI改善のIssueをいくつか対応しました。たとえば、検索機能の追加、ツールチップによって長いタイトルを全文表示する対応、ユーザーの入力形式に応じて表示を変えるフォーマット処理など、ユーザー体験を少しずつ向上させるような細かい変更です。</p>
<p>このようなタスクは、一見すると単純で地味に思えるかもしれませんが、実際には多くの工夫が必要でした。どのように既存のコードと整合性を保ちながら変更を加えるか、パフォーマンスに影響がないように注意すること、そしてUIコンポーネントの再利用性を損なわないように設計することなど、意外と奥が深い作業でした。</p>
<p>また、Vue.jsを本格的に使うのは今回が初めてだったため、最初はコンポーネントの設計思想やReactとの違いに戸惑うことが多くありました。特にKARTEのコードベースは大規模で、どこに何が定義されているかを見つけるだけでも最初は時間がかかりました。</p>
<p>とはいえ、こういった小さなIssueを積み重ねる中で、だんだんとVue.jsの書き方にも慣れ、大規模なコードベースのスタイルや構造にも自然に馴染めるようになっていきました。レビューで指摘された内容を意識して、自分なりにルールやベストプラクティスを積み重ねていったことで、次第に自信を持ってコードを書けるようになりました。</p>
<p>この時期は、「まずは手を動かして学ぶ」ことの重要さを実感した期間でもありました。コードを書くこと自体は目的ではなく、ユーザー体験をより良くするための手段であるということを、タスクを通して実感できたと思います。</p>
<h2>② UI刷新の経験</h2>
<p>Vue.jsに慣れてきたころ、管理画面のあるページを新しいデザインに全面的に改修する、大きなUIの仕事を任されました。この仕事は、Figmaで用意されたデザインをもとに、今あるUIを最新の仕様に合わせて見た目を新しくするものでした。</p>
<p>この作業は、画面をゼロから作るのではなく、既存の構造をできるだけ活かしながら新しい条件を満たすという、バランスの難しいものでした。全てを作り直すか、一部だけ変えるか、既存のスタイルや使いやすさを考えて、自分で最適な方法を考えながら進めました。</p>
<p>特に苦労したのは、コードの中でどこにどんな処理やデザインが書かれているのかを見つけることでした。画面は複数のパーツに分かれていて、データのやりとりも複雑だったため、「どこをどう変えれば見た目も動きも正しくなるか」を理解するのに時間がかかりました。</p>
<p>最初は難しさを感じましたが、コードの中にある意図を理解する力が少しずつつき、「なぜこう書かれているのか」「どのパーツが何を担当すべきか」といった視点で実装の方針を決められるようになりました。自分なりに工夫した実装方法を考えながら進める中で、コードの理解が深まり、自信にもつながりました。</p>
<p>最終的にFigmaのデザインとぴったり合う画面が完成したときは、とても達成感がありました。そして何より、自分が作ったものが実際にユーザーに使われるという実感が、エンジニアとしてのやる気をさらに高めてくれました。</p>
<p>具体的なタスクとしては、<a href="https://support.karte.io/post/2lRnr05R5uTA0K8D5fDzBc">行動チェーン(β)</a>のフォルダ機能における改善と、<a href="https://support.karte.io/post/4MxyAWLgEopohX27lnCFjZ">ユーザー構成比</a>の画面改善でした。<br>
<img src="https://ik.imagekit.io/plaid/c59fea1b-53dc-4889-b32c-be2f20d3bdd1/2025-08-0616.49%E3%81%AE%E7%94%BB%E5%83%8F.jpeg" alt="2025-08-0616.49の画像.jpeg"></p>
<p><img src="https://ik.imagekit.io/plaid/075047ba-3bf1-410a-8726-09fa987a7e9a/2025-08-0617.05%E3%81%AE%E7%94%BB%E5%83%8F.jpeg" alt="2025-08-0617.05の画像.jpeg"></p>
<h2>③ バックエンドへの挑戦</h2>
<p>インターン後半では、「バックエンドにも挑戦してみたい」と相談し、データ周りのIssueを対応させていただきました。タスクの内容は、ある管理画面の既存のフィルター機能に新しい条件を追加するため、SQLクエリの生成ロジックを修正し、BigQueryを用いた集計処理に新しいフィルター条件を組み込むというものでした。</p>
<p>このタスクは、技術的にも認知的にも非常に難易度が高かったです。まず、BigQueryもSQLも初めて触る技術であり、構文や最適なクエリの書き方に慣れるまでにかなりの時間がかかりました。また、複数のイベントテーブルをJOINしたり、ユーザー単位で集約したりといった処理が必要で、そもそも「このデータがどうやって構成されているのか」を理解するところからのスタートでした。</p>
<p>特に苦労したのは、巨大なコードベースの中で「どこがボトルネックなのか」「この値はどこからきて、どこで使われているのか」といった、データの流れを追いかける作業です。関数が分散していたり、抽象化されているレイヤーが多かったりと、全体像を把握するには時間と根気が必要でした。</p>
<p>ただ、その分だけ得られる学びも大きく、「なぜデータ処理をこのように設計しているのか」「フィルター条件が一つ増えるだけでも、どのような設計的配慮が必要か」といった、普段の個人開発では触れない視点を身につけることができました。</p>
<p>最初は不安でしたが、バックエンド開発に興味を持てるようになったのは、自分にとって大きな成長の一歩でした。</p>
<h2>プレイドの文化</h2>
<p>今回のインターンで一番印象に残ったのは、プレイドの働きやすさとカルチャーでした。初めての実務経験だったので、最初はもっと簡単な作業ばかり担当するのかと思っていたのですが、実際には自分が関わったタスクはどれもプロダクトにしっかりと関係していて、やりがいのある内容でした。常にメンターの方がサポートしてくださり、困った時には丁寧に説明してくれたので、安心して新しいことに挑戦できました。最初はうまくいかないことも多く、戸惑うこともありましたが、その経験が逆に自分の成長につながったと感じています。</p>
<p>2ヶ月という短い期間だったので、自分が関われた範囲は限られていましたが、それでも多くの方が自分に声をかけてくれて、新しいツールや機能の開発に参加するチャンスを与えてくれました。タスクを進める中でも、自分の興味や学びたいことを考慮してくれる雰囲気があり、インターンとしてとても充実した経験ができたと感じています。</p>
<p>インターンに参加してから、一緒に機能開発を行うチームの定例ミーティングに参加し、他のメンバーがどのような仕事をしているのかを聞くことで、プロダクト全体の流れやチーム間の連携の重要性を学ぶことができました。日々のやりとりを通じて、インターンであっても一人のメンバーとして扱ってもらえる環境にとても感謝しています。</p>
<h2>最後に</h2>
<p>今回のインターンを通して、エンジニアとして働くことの楽しさや難しさをたくさん学びました。最初は不安もありましたが、周りの方がいつも助けてくれて、新しいことにも安心して挑戦できました。</p>
<p>実際にプロダクト開発に関わる中で、自分の書いたコードがプロダクトの一部になる経験はとてもやりがいがありました。うまくいかないこともありましたが、そのたびにサポートしてもらい、少しずつ自信を持てるようになりました。</p>
<p>2ヶ月という短い期間でしたが、いろいろな技術に触れ、チームの一員として働くことができたのはとても貴重な経験でした。今回の経験を通して、エンジニアとしてもっと成長したいという気持ちが強くなりました。これからもプレイドの成長を楽しみにしつつ、自分もこの経験を活かして努力を続けていきたいと思います！</p>
<hr>
<p>プレイドはエンジニアインターンを募集しています！　興味を持った方は是非応募してみてください！</p>
<p><strong>サマーインターン</strong></p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/106581"><div class="iframely-responsive" style="padding-bottom: 56.25%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/106581" data-iframely-url="https://cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F106581&key=878c5bef402f0b2911bf6d4ce6261abd">【26卒/27卒】エンジニアサマーインターン / 株式会社プレイド</a></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p><strong>通期インターン</strong></p>
<div class="iframely-embed" data-embedded-url="https://open.talentio.com/r/1/c/plaid/pages/90783"><div class="iframely-responsive" style="padding-bottom: 30.2778%; padding-top: 120px;"><a href="https://open.talentio.com/r/1/c/plaid/pages/90783" data-iframely-url="https://cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fopen.talentio.com%2Fr%2F1%2Fc%2Fplaid%2Fpages%2F90783&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Engineer) / 株式会社プレイド</a></div></div><script async src="https://cdn.iframe.ly/embed.js" charset="utf-8"></script>


プレイドで2ヶ月間エンジニアインターンに挑戦した学生の体験記。Vue.jsでのUI改善・刷新からBigQueryを活用したバックエンド開発まで、幅広い技術領域で学んだ実務経験と成長の記録を詳しく紹介します。

プレイドインターン体験記：フロントエンドからバックエンドまで挑戦した2ヶ月

<h2>はじめに</h2>
<p>こんにちは、今年4月に新卒でプレイドに入社しエンジニアをしている佐藤と申します！普段は、社内で利用する<a href="https://open.talentio.com/r/1/c/plaid/pages/106299">内製のOLAPデータベースを開発するチーム</a>でお仕事をしています。</p>
<p>この度、プレイドは「<a href="https://sre-next.dev/2025/">SRE NEXT 2025</a>」にゴールドスポンサーとして協賛いたしました。当日はブース出展に加え、エンジニアの土谷が<a href="https://sre-next.dev/2025/schedule/#slot084">「大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化」</a>というテーマでスポンサーセッションに登壇しました。</p>
<p>私自身もイベントに参加し、ブースの運営と多くのセッションを聴講しました。本記事では、当日のプレイドブースの様子や、個人的に特に印象に残ったセッションについてレポートします！</p>
<h2>ブースの紹介</h2>
<p>まずは、プレイドブースの様子からご紹介します。ブースでは、来場者の皆様と多岐にわたる技術的な議論ができるよう、以下の5つのトピックを用意しました。</p>
<ol>
<li>Production Readiness Reviewとは</li>
<li>リアルタイムユーザー解析エンジンのリアーキテクチャ</li>
<li>監査ログとは - なぜ重要なのか</li>
<li>KARTE BlocksのSLO</li>
<li>AIエージェントを用いたセキュリティレビュー</li>
</ol>
<p><img src="https://ik.imagekit.io/plaid/472905ef-0548-4eab-8787-fdf6eaf1ce62/IMG_4624.jpg" alt="IMG_4624.jpg"></p>
<p>ブースでは、来場者の方に興味のあるトピックへシールを貼っていただく企画を実施し、特にAI関連のテーマに多くの関心が集まっているようでした。</p>
<p>私はリアルタイムユーザー解析エンジンについて会話することが多かったので、そちらについて紹介します。プレイドでは、「KARTE」を通じて取得した膨大なデータを処理するために内製のリアルタイムの解析エンジン(「Blitz」と呼んでいます)を置いています。(<a href="https://tech.plaid.co.jp/deim_2025">このエンジンはデータ工学系のフォーラムであるDEIMに論文を投稿して</a>いたりします)。主にその内部の仕組みとリアーキテクチャについて議論させてもらいました。例えば、リアーキテクチャによってレイテンシが1500ms（結果整合性）からp95で200ms（強整合性）へと改善したことをお話しすると、プレイドの技術への投資姿勢とエンジニアの技術力について良い反応をもらうことができて嬉しかったです。</p>
<p>Blitzの詳細に関しては、論文以外にも以下のブログで紹介していますので、よろしければご覧ください。</p>
<ul>
<li><a href="https://tech.plaid.co.jp/blits_pre_aggregation"><strong>Blitz（前編）: 自由度と即時更新性を担保したAggregation</strong></a></li>
<li><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture"><strong>Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</strong></a></li>
<li><a href="https://tech.plaid.co.jp/blitz_performance_user_cache"><strong>Blitz: リアルタイムユーザー解析エンジンのボトルネックを解消したキャッシュ設計</strong></a></li>
</ul>
<p>また、現在私が開発に携わっているユーザー行動分析に特化した内製のOLAPデータベースについても、Kubernetesやコンテナランタイムといった技術を交えながらお話しでき、そちらに対する議論も大変盛り上がりました。</p>
<p>これらの技術的なコンテンツに加え、様々なノベルティ(カフェオレ、ラムネ、うちわ、歯ブラシなど)やSRE NEXT 2025のために作成したパンフレットも大変好評でした！</p>
<p><img src="https://ik.imagekit.io/plaid/47ac9bd5-c960-48a2-b847-6d4c5ec76de1/IMG_4578.jpg" alt="IMG_4578.jpg"></p>
<h2>参加セッションの感想</h2>
<h3><a href="https://sre-next.dev/2025/schedule/#slot044"><strong>Fast by Friday: Making performance analysis fast and easy(Brendan Gregg)</strong></a></h3>
<p>Brendan Gregg氏はフレームグラフを始めとした多くの可視化ツールの発案者であり、<a href="https://www.usenix.org/">USENIX</a>などの著名カンファレンスで基調講演をされており、私自身本セッションをとても楽しみしておりました。</p>
<p>このセッションでは、「Fast by Friday」——つまり、月曜日に発生したパフォーマンス問題をその週の金曜日までに解決するというコンセプトに基づき、システムパフォーマンスを迅速に分析・改善するための方法論が紹介されました。</p>
<p>例えば、「月曜日にはまず問題を定量的に分析する」「水曜日にはフレームグラフやeBPFを用いてプロファイリングを行う」といったように、1週間の各曜日で何をすべきかが具体的に語られました。第一線で活躍するエンジニアのパフォーマンスチューニングの過程を体系的に知ることができ今後の業務に大変活かせると感じました。</p>
<p>(SRE NEXT 2025での発表資料は見つけることができませんでしたが、<a href="https://www.brendangregg.com/Slides/eBPFSummit2023_FastByFriday/">こちらの資料</a>に内容は近いと感じましたので、ご興味ありましたら是非ご覧ください。)</p>
<p>セッション後のAsk the Speakerでは、私たちが開発しているOLAPデータベースのパフォーマンスについて少し相談してきました。特に印象的だったこととして、メモリ使用量の改善についてのアドバイスです。「プロダクション環境でメモリダンプを取得するとJVMのレイテンシが悪化してしまう」という課題に対し、「CPUのフレームグラフを分析してメモリ割り当てが多いコードパスを特定すれば、より低コストで問題の原因を突き止められるかもしれない」という助言をいただきました。また、データベースのような巨大で複雑なシステムのパフォーマンスを改善するためには、まずマイクロベンチマークを整備することが重要であると勧められました。実装には工数がかかりそうですが、コードを大量に生産することにはAIの活用も期待できるため、チームで検討し、整備を進めていこうと思います。</p>
<h3><a href="https://sre-next.dev/2025/schedule/#slot087">Intel SGXをAzureで本番運用するための構成事例と実践知見(株式会社Datachain SRE/テックリード 大久保 俊彦)</a></h3>
<p>TEE（Trusted Execution Environment）は、ハードウェア上の保護された領域でコードやデータを処理し、安全性を確保する技術です。例えば、メモリ上にデータを暗号化して保持し、CPU内部で復号化と処理を行うなどがあり、これにより、メモリを抜かれたとしても暗号が解読されない限りは、データを覗き見ることができなくなります。多くのCPU(ARM, AMD, etc.)がTEEをサポートしていますが、中でも強力なTEEの一つとして、Intel SGXがあります。</p>
<p>その仕組みの複雑さや具体的なユースケースのイメージが湧きづらい点から、私自身これまで深く学習できていませんでしたが、本講演では動作原理とユースケースに対する興味深い話を伺うことができました。(講演の後、大久保さんと2時間ほどお話しする機会をいただき、Intel SGXについてさらに深く学ぶことができ大変良い経験になりました。ありがとうございました。)</p>
<p>Datachain社では、異なるブロックチェーン間で資産やデータを安全に移動させるための「ブリッジ」という仕組みにIntel SGXを活用されています。このブリッジですが、暗号化が施されていない場合、内部の人間が直接メモリを盗み見ると仮想通貨の情報が見れてしまい、ユーザーの暗号資産を不正に操作できてしまうリスクがあります。(実際にブリッジの運用者の内部犯行によってユーザーの仮想通貨が<a href="https://www.chainalysis.com/blog/multichain-exploit-july-2023/">$120M抜き取られたという事件</a>が起きていたりします)。</p>
<p>Datachain社は、Intel SGXを用いることで運用者ですらアクセスできないセキュアな環境を構築し、ユーザーが安心して資産を移動できるサービスを提供しているとのことでした。</p>
<p>秘密計算という先進的な技術が、実社会の課題解決に貢献している様子を知ることができて、大変刺激を受けました。</p>
<h2>プレイドのセッションの紹介</h2>
<h3><a href="https://sre-next.dev/2025/schedule/#slot084">大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化（プレイド 土谷）</a></h3>
<p>弊社エンジニアの土谷からは、「KARTE Message」をテーマに、月間10億通を超える大規模配信の信頼性をどのようにSLOに落とし込み、運用・改善してきたかについてお話ししました。</p>
<p>セッション後、弊社ブースにお立ち寄りいただいた方の中には、これからSLI/SLOを設定するという方も多くいらっしゃいました。技術的な側面に加え、「ビジネスメンバーへの理解をどのように促進したか」といった具体的な実践方法まで踏み込んで質問される方も多く、皆様との対話を通じて、私たち自身も多くの学びを得ることができました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化" src="https://speakerdeck.com/player/6e64b50718624605960a8f215fce51e7" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>SRE NEXT 2025には、SREやインフラ分野に深い知見をお持ちの方が数多く参加されており、弊社の取り組みに興味を持っていただき、活発な議論ができたことを大変嬉しく思います。私たちが知見を提供するだけでなく、皆様からも多くのことを学ばせていただき、非常に貴重な交流をすることができました！</p>
<p>今回、初めてカンファレンスのブース担当を経験しましたが、多様なバックグラウンドを持つ方々と直接技術的なお話しができ、とても楽しかったです。普段チームの中で開発している時には中々得られない刺激と知見を得ることができました。今後もこのような場に参加させていただきたいと思います！</p>
<p>最後に、このような素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！ブース出展では、スタンプラリーなど来場者と話すきっかけを運営の皆様にご用意いただけたおかげで、非常に多くの方々とお話できました。そして、盛り上げていただいた参加者のみなさま、様々な知見をご共有いただいたスピーカー、スポンサー企業の皆様、ありがとうございました！</p>
<p>SRE NEXT 2026も楽しみにしております！</p>


新卒のエンジニアがSRE NEXTに参加しました。プレイドのブースの紹介や聴講したセッションレポートをお伝えします。

新卒エンジニアによるSRE NEXT 2025 イベントレポート　

<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と共存する開発プロセス

<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

KARTEサポートサイトの情報を検索し、質問文とともにChatGPTに入力して回答を生成するbotを作成しました。

KARTEの仕様に詳しいChatGPTを作ってみた

PLAIDには2021年の3月からインターンとして開発に携わり、2022年度にソフトウェアエンジニアとして新卒で入社しました。  この記事では、一年間開発インターンとしてどのような開発を行っていたのかについてお話ししていきたいと思います。

PLAIDのインターンシップで解析基盤の移行に携わった話

PLAIDのインターンシップでリアルタイムユーザー解析基盤の移行に携わった話

意図せずログに出てしまった機密情報を検知し、そのログをすぐ修正できる状態を、Datadogのセンシティブデータスキャナーを使い実装します。

機密情報が間違ってログ出力されたことを検知する仕組みを、Datadogのセンシティブデータスキャナーで作る

<p>不正アクセスの中でも、アカウントへの不正ログインはもっとも基本的な攻撃になります。<br>
なぜならログイン画面はどのサービスでも公開されていることが多く、<br>
最近は外部サイトから流出したパスワードリストを使ったCredential Stuffingといった攻撃も行われます。<br>
そのため、アカウントへの不正ログインは、攻撃者にとってはどのサイトでも共通の攻撃ができる比較的安易な攻撃方法となります。</p>
<p>この問題への根本的な対策は難しいですが、KARTEでも実装している多要素認証やアカウントロック機能といった対応が考えられます。<br>
一方で、このような攻撃が実際に行われているかを監視する仕組みは、直接的な対策とは別途必要になります。</p>
<p>なぜなら、対策に抜け道がある可能性や外的要因で攻撃が突発的に発生する可能性があり、それに気付く仕組みと組み合わせることが重要となるためです。</p>
<p>KARTEではログのモニタリングに<a href="https://www.datadoghq.com/ja/">Datadog</a>を使っているため、Datadogを使い不正ログインなどのモニタリングを実装していくことにしました。</p>
<h2>Datadogで不正ログインのモニタリングの実装方針</h2>
<p>元々部分的に不正ログインのモニタリングの仕組みを実装していましたが、網羅性をもっと強化する方法を検討していました。<br>
そこで、Datadogが用意している不正ログインなどのモンタリングテンプレートをベースにして、あらためて不正ログインのモニタリングの仕組みを作り直すことにしました。</p>
<ul>
<li><a href="https://docs.datadoghq.com/ja/security_platform/guide/monitor-authentication-logs-for-security-threats/">モニター認証ログによるセキュリティ対策</a></li>
</ul>
<p>このテンプレートでは、Datadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>と呼ばれるスキーマにあわせたCustom Attributeをログと一緒に送る必要があります。</p>
<p>たとえば、ログに紐づくユーザーIDは<code>usr.id</code>というフィールドに入れて送るといった命名規則がある程度決まっています。<br>
この名前は独自に決めても問題ないですが、先ほども述べたようにテンプレートを利用するには、スキーマに合わせた方が楽になります。</p>
<p>そのため、今回はDatadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>に合わせる形式でログを送り、そのログを使ってアラートやモニタリング用のダッシュボードを作成することにしました。</p>
<h2>ログイン成功/失敗のログを実装</h2>
<p>ログインの成功時と失敗時に、Datadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>のCustom Attributeを含めるように実装します。<br>
具体的には、次のようなAttributeを実装することにしました。</p>
<ul>
<li><a href="https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/#user-related-attributes">usr.id</a>: 管理画面にログインするアカウントの一意なID</li>
<li><a href="https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/#events">evt.category</a>: &quot;authentication&quot;</li>
<li><a href="https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/#events">evt.name</a>: &quot;authentication&quot; or &quot;Google Login&quot;</li>
<li><a href="https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/#events">evt.outcome</a>: &quot;success&quot; or &quot;failture&quot;</li>
<li><a href="https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/#network">network.client.ip</a>: リクエスト元のIPアドレス</li>
</ul>
<p>詳細は次のドキュメントでも解説されています。</p>
<ul>
<li><a href="https://docs.datadoghq.com/ja/security_platform/guide/monitor-authentication-logs-for-security-threats/">モニター認証ログによるセキュリティ対策</a></li>
</ul>
<p>Datadogへのログの送信方法は色々ありますが、KARTEでは社内で利用する共通のロガーライブラリがあるため、共通のロガー経由で送ることにしました。</p>
<ul>
<li><a href="https://docs.datadoghq.com/ja/logs/log_collection/?tab=%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3">ログの収集とインテグレーション</a></li>
</ul>
<p>たとえば、次のようなイメージでログイン成功と失敗のログをメッセージと一緒にCustom AttributesをDatadogに送っています。</p>
<pre><code class="language-js">// ログイン成功時のログ
logger.info(&quot;_check_and_login: login_successful&quot;, {
  usr: {
    id: user.id
  },
  evt: {
    category: &quot;authentication&quot;,
    name: &quot;authentication&quot;,
    outcome: &quot;success&quot;,
  },
  network: {
    client: {
      ip: req.ip // expressのreq.ip
    }
  }
});
// ログイン失敗時のログ
logger.error(new Error(&quot;_check_and_login: login_failure&quot;), {
  usr: {
    id: user.id
  },
  evt: {
    category: &quot;authentication&quot;,
    name: &quot;authentication&quot;,
    outcome: &quot;failure&quot;,
    reason: &quot;ログイン失敗の理由&quot; // ここはDatadogの標準属性にはないが必要な情報なので入れています
  },
  network: {
    client: {
      ip: req.ip // expressのreq.ip
    }
  }
});
</code></pre>
<p>しかし、社内で利用しているロガーでは、第二引数のCustom Attributesを<code>custom</code>というプロパティにまとめてから送信するという仕組みになっていました。</p>
<p>Datadogに送信されるJSONログは次のようなイメージです。</p>
<pre><code class="language-js">{
  timestamp: &quot;2022-07-22T06:54:48.787Z&quot;,
  status: &quot;info&quot;,
  message: &quot;_check_and_login: login_successful&quot;,
  custom: {
    usr: {
      id: &quot;example@example.com&quot;,
    },
    evt: {
      category: &quot;authentication&quot;,
      name: &quot;authentication&quot;,
      outcome: &quot;success&quot;,
    },
    network: { client: { ip: &quot;127.0.0.1&quot; } },
  }
}
</code></pre>
<p><code>custom</code>プロパティにまとめているのは、DatadogのCustom Attributesには<a href="https://docs.datadoghq.com/logs/log_configuration/attributes_naming_convention/#reserved-attributes">予約語</a>が存在し、名前が衝突してしまうのを避けるためです。<br>
そのため、<code>custom.usr.id</code>として送信したものを<code>usr.id</code>にマッピングする必要があります。</p>
<h3>Datadog PipelineでCustom Attributesのマッピングをする</h3>
<p>Datadogには<a href="https://docs.datadoghq.com/ja/logs/processing/pipelines/">パイプライン</a>という仕組みがあります。<br>
パイプラインでは、ログを取り込む際にCustom Attributesを別の名前にマッピングしたり、不要なログを取り込まないように無視できます。</p>
<p>パイプラインを使い<code>custom</code>プロパティを必要なDatadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>へとマッピングできます。</p>
<p>パイプラインページではStandard Attributesという専用のタブも用意されていて、デフォルトでいくつかのAttributeは登録されています。<br>
今回は、このStandard Attributesに<code>usr.id</code>などを追加し、<code>custom.usr.id</code>を<code>usr.id</code>マップする設定を追加しました。</p>
<p><img src="https://ik.imagekit.io/plaid/df391cce-f710-4680-a58d-d2afaff9d600/datadog-standard-attributes.png" alt="Datadogのstandard-attributesの画面"></p>
<blockquote>
<p>DatadogのStandard Attributesの画面</p>
</blockquote>
<p><img src="https://ik.imagekit.io/plaid/3ada5405-ef68-4b86-a8d3-f653aa51b478/edit-standard-atttribute.png" alt="をにマッピングする設定"></p>
<blockquote>
<p><code>custom.usr.id</code>を<code>usr.id</code>にマッピングする設定]</p>
</blockquote>
<p>これでパイプライン設定後に送られたログに関しては、<code>custom.usr.id</code>を送ったら<code>usr.id</code>へとマッピングされるようになります。</p>
<h2>ログを使った不正ログインのアラートを設定する</h2>
<p>ここまでで、ログインの成功や失敗のログとCustom Attributesが送信されるようになりました。<br>
このログを使い不正ログインに関連するアラートを設定していきます。</p>
<p>Datadogには<a href="https://docs.datadoghq.com/ja/security_platform/explorer/">セキュリティシグナル</a>というセキュリティアラート向けの仕組みが用意されています。<br>
セキュリティシグナルは、複数のログの組み合わせからアラートを設定できたり、ログなどに対してコンテキスト情報を付与(特定のログにSeverity:Highラベルをつけるなど)ができます。</p>
<ul>
<li><a href="https://www.datadoghq.com/ja/blog/announcing-cloud-siem/">Datadog セキュリティモニタリングが新登場 | Datadog</a></li>
</ul>
<p>また、<a href="https://docs.datadoghq.com/ja/security_platform/explorer/">セキュリティシグナル</a>の<a href="https://docs.datadoghq.com/security_platform/default_rules/">検出ルール</a>には、AWSやGCPなどのビルトインのルールが用意されています。<br>
不正ログインに関しても、いくつかのテンプレートとなる検出ルールが用意されています。</p>
<ul>
<li><a href="https://app.datadoghq.com/security/configuration/rules?query=brute%20force%20attack&amp;all=false&amp;sort=rule_name">ブルートフォース攻撃</a>
<ul>
<li>パスワードを総当たり攻撃する手法</li>
</ul>
</li>
<li><a href="https://app.datadoghq.com/security/configuration/rules?query=credential%20stuffing%20attack&amp;sort=rule">クレデンシャルスタッフィング攻撃</a>
<ul>
<li>外部のサービスから流出したアカウント名とパスワードのリストを使って、ログインできるかを試行する攻撃手法</li>
<li>パスワードリスト攻撃とも言われる</li>
</ul>
</li>
</ul>
<p>これらのテンプレートは先ほども紹介していたDatadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>が利用されています。<br>
そのため、送るログもDatadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>の名前に合わせる(マッピングする)ことで、アラートの実装が簡単になります。</p>
<p>これらの用意されたテンプレートなどをベースに、次のようなルールを作成しています。</p>
<ul>
<li>ブルートフォース攻撃(IPアドレス単位)</li>
<li>クレデンシャルスタッフィング攻撃</li>
<li>Annomalyを使った異常検知のアラート
<ul>
<li>Detection methods: Anomaly</li>
<li><code>@evt.category:authentication @evt.outcome:failure</code></li>
<li>普段とはログイン失敗の傾向が異なるなら飛ぶアラート</li>
<li><a href="https://www.datadoghq.com/ja/blog/anomaly-detection-rules-datadog/">Detect Security Threats With Anomaly Detection Rules | Datadog</a></li>
</ul>
</li>
</ul>
<p>たとえば、&quot;ブルートフォース攻撃(IPアドレス単位)&quot;なら次のようなルール設定になります(実際の値とは細かいところは異なります)。</p>
<p><img src="https://ik.imagekit.io/plaid/822eb073-db7f-4366-a9c9-30566cd0f46a/brute-force-attack-grouped-by-user.png" alt="ブルートフォース攻撃(IPアドレス単位)"></p>
<blockquote>
<p>ブルートフォース攻撃(IPアドレス単位) のルール設定</p>
</blockquote>
<p>このルールでは、ログのCustom Attributesを元にログインの成功と失敗を、ログインしようとしたIPアドレスでグルーピングしています。<br>
グルーピングした結果、&quot;5分以内に、特定のIPアドレスからのログイン失敗が5回 かつ ログイン成功1回&quot; を、攻撃の成功として判定し、Severity:Highのラベルをつけてアラートを飛ばしています。<br>
また、攻撃の予兆の検知として &quot;5分以内に、特定のIPアドレスに関するログイン失敗が5回&quot; を検知し、Severity:Infoのラベルをつけています。(成功はしてない)</p>
<p>もちろん、普通に利用しているユーザーがパスワードを何回も入力ミスしてからログインに成功するというケースもあるので、これらの値は実際のアプリケーションに合わせて調整するのが良いです。</p>
<p>どのアラートも目的、対応方法などの何をするべきかという説明を書き、アラートが発生したときに何をするかが明確になっていることが重要です。</p>
<p>これでアラートが設定できましたが、個別のアラートだけ見ても全体でどのような問題が起きてるかは分かりにくいです。<br>
そのため、不正ログインに関連するダッシュボードを作成し、そこで起きているアラート(Signal)を一覧できるようにしています。</p>
<h2>アラートの全体像を掴むダッシュボードを作成する</h2>
<p>Datadogには、今回設定した不正ログインなどのアラートをまとめたダッシュボードのテンプレートが用意されています。</p>
<ul>
<li><a href="https://app.datadoghq.com/dashboard/lists/preset/100">Security and Compliance</a>
<ul>
<li>IP Investigation</li>
</ul>
</li>
</ul>
<p>このダッシュボードのテンプレートを元に、実際に不正ログイン周りの運用をするためのダッシュボードを作成しています。</p>
<p><img src="https://ik.imagekit.io/plaid/1664b19f-ee44-4b15-86bc-eb3f76329ae3/datadog-dashboard.png" alt="Datadog セキュリティダッシュボードのイメージ"></p>
<blockquote>
<p>Datadog セキュリティダッシュボードのイメージ(意図的にアラートを発生させている)</p>
</blockquote>
<p>ダッシュボードでは、発生してるアラートをSeverity別で表示したり、ログイン全体の様子、調査方法などをまとめています。<br>
発生したアラートからログを調査したり、そのアラートが実際に問題なのかを確認できるようにしています。</p>
<p>また、ダッシュボードに関連するアラートのモニターを一覧するには、モニター自体にタグを設定しておくと便利です。<br>
たとえば、<code>category:authentication</code> というタグをつけておけば、<code>tag:&quot;category:authentication&quot;</code> でモニターの一覧を検索できるようになります。</p>
<h2>おわりに</h2>
<p>この記事では、Datadogを使い不正ログインのアラートとダッシュボードといったモニタリング方法について紹介しました。<br>
Datadogの<a href="https://docs.datadoghq.com/ja/logs/log_configuration/attributes_naming_convention/">標準属性</a>に従ったログを出すことで、テンプレートを使ったセットアップが簡単にできるようになっています。<br>
一から仕組みを作ると大変ですが、テンプレートをベースにカスタムしていくことで、ある程度形になったものが簡単に作成できます。</p>
<ul>
<li><a href="https://docs.datadoghq.com/ja/security_platform/guide/monitor-authentication-logs-for-security-threats/">モニター認証ログによるセキュリティ対策</a></li>
</ul>
<p>また、今回はログインの成功と失敗のログを中心にして紹介しましたが、他にもアカウントへの不正アクセスのシグナルとなるものはあります。<br>
たとえば、パスワードリセットや2要素認証などのログも、不正アクセスに関係する攻撃が発生しているかの判断材料として利用できます。<br>
KARTEではこれらのログに対するモニタリングの追加や運用しながらのアラートの調整などを行なっています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、セキュリティのモニタリングの設計から運用までを考えて実装していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>
<ul>
<li><a href="https://recruit.plaid.co.jp/requisitions/security-engineer">セキュリティエンジニア | 募集ポジション | 株式会社プレイド</a></li>
</ul>


Datadogのセキュリティモニタリングを使った不正ログイン検知の実装方法について

Datadogを使った不正ログインのモニタリングの実装

Datadogを使った不正ログインのモニタリング実装

<p>こんにちは、エンジニアの <a href="https://tech.plaid.co.jp/author/takanori_koga">@koga</a> です。<br>
今回は開発でよく使うGitHubとSlackのスレッドを同期する仕組みの取り組みと実装例を紹介します。プレイドでは、社内開発した Slack App 「<a href="https://issit.plaid.co.jp/">issit</a>」を使って、SlackメッセージからGitHub issueを作成し日々のタスク管理などに活用しています。</p>
<p>「issit」とは、Slack上で流れていってしまうやりとりをGitHub issueにすることで、フロー情報をストック情報に変換するためのアプリです。このアプリにより、SlackからGitHub Issueへストックする流れができました。<br>
<img src="https://ik.imagekit.io/plaid/d00392d8-4759-4a64-867d-00fc66afafaa/issit-1.png" alt="issit-1.png"></p>
<p>2022年8月のPLAIDのデータを確認すると、作成されたissueの約5.8%が「issit」からの作成であることが分かりました。<br>
しかし、やっていくうちに課題も出てきました。</p>
<h2>見えてきた課題</h2>
<p>GitHub issueのコメントに気付けないことがある。ということが見えてきました。</p>
<p>issueはclosedにしているけれど、Slackで終わったか確認している会話を見かけたり、issueにコメントを書いた後、Slackで「issueにコメントしました！」という会話も見かけることがありました。<br>
Slackでコメントしている理由は簡単で、GitHubへのコメントでは気づかれないからです。</p>
<h2>解決した方法</h2>
<p>この課題を解決するために、GitHub issueのコメントやステータスをSlackに反映する仕組みを<a href="https://docs.github.com/ja/get-started/customizing-your-github-workflow/exploring-integrations/about-webhooks">GitHub webhook</a>を使って実装しました。<br>
これによって “新しいissitの図” のように、SlackとGitHubで双方向の流れができ、issueのコメントに気づけるような仕組みにすることができます。<br>
<img src="https://ik.imagekit.io/plaid/1d84ef34-c593-464c-8a11-ee4dd7957a18/issit-2.png" alt="issit-2.png"></p>
<h2>解決した実例紹介</h2>
<p>「issit」はSlackのメッセージショートカットからGitHub issueを作成することができます。<br>
メッセージショートカットを実行するとモーダルが表示され、GitHub webhookの設定もモーダルでおこなえます。</p>
<p>GitHub webhookの設定項目は２つあります。</p>
<ul>
<li>issueのcloseをSlackのスレッドへ通知する設定</li>
<li>issueコメントをSlackスレッドへSyncする設定</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/0c63f389-b0a8-4098-b0d6-75ad44dba515/issit-example-1.png" alt="issit-example-1.png"></p>
<p>issue作成したあとにGitHub webhook設定を変更することも可能です。<br>
「issit」の投稿で、Slackのメッセージショートカット「issitのGitHub webhook設定」を実行するとモーダルが表示されます。<br>
<img src="https://ik.imagekit.io/plaid/7cdb2bc4-d46d-460e-861b-9f6248a4020b/issit-example-2.png" alt="issit-example-2.png"></p>
<p>そのモーダル内で各項目を変更し保存することでGitHub wobhook設定を変更することができます。<br>
<img src="https://ik.imagekit.io/plaid/e933315f-a74b-4c2f-ab96-3e3c2146a249/issit-example-3.png" alt="issit-example-3.png"></p>
<p>defaultのGitHub webhookを設定しておくことも可能です。<br>
設定したいチャンネルで <code>/issit</code>とコマンドを実行するとチャンネルで設定したリポジトリ一覧が表示されます。<br>
<img src="https://ik.imagekit.io/plaid/816fb676-7717-4995-9d9e-4a4c4e302045/issit-example-4.png" alt="issit-example-4.png"></p>
<p>リポジトリの「Settings」を押すと、issue作成時のdefault値を設定できるモーダルが表示され設定することができます。<br>
<img src="https://ik.imagekit.io/plaid/16f45527-0f48-431e-ab62-bf7ebd74d4fe/issit-example-5.png" alt="issit-example-5.png"></p>
<h2>実装の紹介</h2>
<p>「issit」は<a href="https://github.com/slackapi/bolt-js">slack/bolt</a>を使用して実装しているため、GitHub webhookを受け付ける実装もboltに対応している必要があります。Expressを使用したサンプルはよく見かけますが、slack/boltでのサンプルはなかなかありませんでした。</p>
<p>ただ、slack/boltには <a href="https://slack.dev/bolt-js/reference#app-options">receiver</a> という機能があり、外部からのアクセスを受け取ることができます。このreceiver機能を使用することでGitHub webhookを受け取るようにしました。</p>
<pre><code class="language-typescript">// Bolt.ts
const receiver = new ExpressReceiver({
  signingSecret: credentials.SLACK_SIGNING_SECRET,
})

export const app = new App({
  authorize: SlackInstaller.authorize,
  signingSecret: credentials.SLACK_SIGNING_SECRET,
  endpoints: '/slack/events',
  receiver,
})
</code></pre>
<pre><code class="language-typescript">// index.ts
import { app } from &quot;./Bolt&quot;
// express router
import github from &quot;./routes/GitHub&quot;

// express routerのように使用できます
app.receiver.app.use('/github', github)
</code></pre>
<p>GitHub webhookの実装には、<a href="https://github.com/octokit/webhooks">octokit/webhooks</a>を使用することにしました。<br>
octokit/webhooksは、受け付けるwebhookのイベントとアクションごとに指定できるためとても便利です。<br>
参考: <a href="https://docs.github.com/ja/developers/webhooks-and-events/webhooks/webhook-events-and-payloads">GitHub Webhook のイベントとペイロード</a></p>
<pre><code class="language-typescript">// index.ts
import { createMiddlewareGitHubWebhooks } from './routes/github'

const middlewareGitHubWebhooks = await createMiddlewareGitHubWebhooks()
app.receiver.app.use(middlewareGitHubWebhooks)
</code></pre>
<pre><code class="language-typescript">// routes/github.ts
import { Webhooks, createNodeMiddleware } from '@octokit/webhooks'

import { IssueClosedUseCase } from './IssueClosedUseCase'
import { IssueCommentCreatedUseCase } from './IssueCommentCreatedUseCase'
import { IssueCommentEditdUseCase } from './IssueCommentEditdUseCase'
import { IssueCommentDeletedUseCase } from './IssueCommentDeletedUseCase'

export const createMiddlewareGitHubWebhooks = async () =&gt; {
  const webhooks = new Webhooks({
    secret: credentials.GITHUB_WEBHOOK_SECRET_TOKEN,
  })

  webhooks.on('issues.closed', IssueClosedUseCase)
  webhooks.on('issue_comment.created', IssueCommentCreatedUseCase)
  webhooks.on('issue_comment.edited', IssueCommentEditdUseCase)
  webhooks.on('issue_comment.deleted', IssueCommentDeletedUseCase)

  return createNodeMiddleware(webhooks, { path: '/github-webhooks' })
}
</code></pre>
<h2>GitHub App の設定</h2>
<p>「Issit」のGitHub連携は、<a href="https://docs.github.com/ja/developers/apps/building-github-apps/creating-a-github-app">GitHub App</a> を作成しGitHub Organizationへインストールすることで実現しています。</p>
<p>GitHub webhookを使用するためにはGitHub Appの設定でwebhookを有効にする必要があります。設定する項目は以下の３つです。</p>
<ul>
<li>App settings画面 「General」でWebhookをActiveにし受け付けるURL を指定する。<br>
<img src="https://ik.imagekit.io/plaid/baa5e133-0c24-4823-9c44-e14157b5048f/github-app-setting-1.png" alt="github-app-setting-1.png"></li>
<li>App settings画面 「Permissions &amp; events」にて、webhookで受け取りたいイベントの権限を付与する
<ul>
<li>Issue: Read and write - Issueの作成、Issueのコメントを取得するため</li>
</ul>
</li>
<li>App settings画面 「Permissions &amp; events」の Subscribe to events で、受け取りたいイベントにチェックを入れる
<ul>
<li>Issues: Issueの変更内容やCloseされたことを検知するため</li>
<li>Issues comment: Issueのコメントの作成・変更・削除を検知するため<br>
<img src="https://ik.imagekit.io/plaid/8cb82e50-5293-468a-b0fb-fbfc77decb11/github-app-setting-2.png" alt="github-app-setting-2.png"></li>
</ul>
</li>
</ul>
<p>Permissionsを指定した状態でGitHub Marketplaceへ公開した場合、Subscribe to eventsの変更はリリース申請なしに変更することができました。「issit」の場合も、issueの作成と読み込みの権限を指定しGitHub Marketplaceへ公開していたため、Subscribe to eventsの変更は申請なしに使用することができました。</p>
<h2>「issit」での動作確認</h2>
<p>Slack App「Issit」をSlackワークスペースへインストールし、GitHub Appの「<a href="https://github.com/apps/issit-app">issit-app</a>」をGitHub Organizationへインストールすることで、SlackとGitHub間で相互に連携できるようになりました。</p>
<p><img src="https://ik.imagekit.io/plaid/68f0b2f5-3b39-4837-8e7d-44b83f4881c2/issit-comment-sync-3.png" alt="issit-comment-sync-3.png"></p>
<h2>まとめ</h2>
<p>SlackからGitHubへの一方向ではなく、GitHubからSlackの双方向にすることで、issueの状態をSlackでも確認しやすくすることができました。GitHubやSlackはAPIやwebhookが充実していますので、職場やプロジェクトの運用にあったAppを実装してみるのも良いのではないでしょうか。</p>
<p>実装が難しい場合は、 「<a href="https://issit.plaid.co.jp/">issit</a>」 の導入も検討していただけたら嬉しいです。</p>


GitHub issueとSlackスレッドを同期する仕組みと「issit」での実装例

PLAIDのインターンを通して ~ KARTE接客におけるユーザ体験の向上 ~

<p>こんにちは、エンジニアの @koga です。<br>
2022/06/27から公開されました <a href="https://cloudopsdays.com/">Cloud Operator Days Tokyo 2022</a> の<a href="https://cloudopsdays.com/ondemand/">オンデマンドセッション</a>に参加しましたので、ブログでもその内容を簡単にまとめておきます。</p>
<script async class="speakerdeck-embed" data-id="7a4edd766e4b448db48cbc7651dd9138" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<p><a href="https://youtu.be/UgcSp-H4eK4">Cloud Operator Days Tokyo 2022 セッション動画</a></p>
<p>セッションでは、PLAIDがすでに取り組んでいるSlackbotを活用した３つの事例を紹介させていただきました。<br>
３つの事例は、あらゆる業務を対象としておりますので、担当しているチームや部署ごとに分けて紹介しています。</p>
<ul>
<li>Dialogflowを使用したお問合せBot</li>
<li>SaaS Admin権限の申請/付与/削除の自動化</li>
<li>Slackメッセージからissueを作成するSlackアプリ</li>
</ul>
<h2>Dialogflowを使用したお問合せBot</h2>
<script async class="speakerdeck-embed" data-slide="8" data-id="7a4edd766e4b448db48cbc7651dd9138" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<p>情シスや社内ITと呼ばれるメンバーにて活用している「Dialogflowを使用したお問合せBot」についてです。</p>
<h3>開発した背景</h3>
<ul>
<li>同じような内容のお問合せがあること
<ul>
<li>お問い合わせしているユーザーは変わるのですが、受ける側としては同じような内容を頻繁に聞かれることがありました。</li>
<li>例えば、Slackの共有チャンネルの作成方法だったり、Notionのページを社外へ共有する方法だったり。このようなお問い合わせがありました。</li>
</ul>
</li>
<li>使用しているSaaSが多く検索に時間がかかる
<ul>
<li>PLAIDでは多くのSaaSを活用していることもあり、Notionやesa、GitHubやSlackなど多くのSaaSに情報が保存されている</li>
<li>欲しい情報を得るためには、１つ１つのSaaSを検索する必要があり時間がかかる</li>
</ul>
</li>
</ul>
<h3>解決方法</h3>
<ul>
<li>Slackbotからお問い合わせできるBotの開発・導入を行いました。
<ul>
<li>Dialogflowを用いて、自然な会話で検索できるようにした</li>
<li>中の人チャンネルを作成し、botで解決できなかった場合は人が対応できる仕組みにした</li>
</ul>
</li>
</ul>
<h2>SaaS Admin権限の申請/付与/削除の自動化</h2>
<script async class="speakerdeck-embed" data-slide="14" data-id="7a4edd766e4b448db48cbc7651dd9138" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<p>DevOps・SREと呼ばれるメンバーにて活用している「SaaS Admin権限の申請/付与/削除の自動化」についてです。</p>
<h3>開発した背景</h3>
<ul>
<li>権限に関するお問合せが増えてきた
<ul>
<li>会社が急成長している時期だったため、権限付与の仕組み化が出来ておらず、お問い合わせが増えていました</li>
</ul>
</li>
<li>エンジニアメンバーの自由度をあげるため
<ul>
<li>権限付与のSTEPが、ボトルネックになってしまう可能性がありました</li>
</ul>
</li>
</ul>
<h3>解決方法</h3>
<ul>
<li>Slackbotから申請できる仕組みを開発・導入しました
<ul>
<li>申請・承認・解除のlog専用のチャンネルを作成し見える化も実現</li>
</ul>
</li>
</ul>
<h2>Slackメッセージからissueを作成するSlackアプリ</h2>
<script async class="speakerdeck-embed" data-slide="18" data-id="7a4edd766e4b448db48cbc7651dd9138" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<p>全てのメンバーにて活用している「Slackメッセージからissueを作成するSlackアプリ」についてです。</p>
<h3>開発した背景</h3>
<ul>
<li>Slackにて活発に議論がされている。</li>
<li>議論した内容が流れてしまい、探すのに時間がかかることがしばしばあった</li>
<li>issueを使ったタスク管理を、全社で行っている</li>
</ul>
<h3>解決方法</h3>
<ul>
<li>SlackからGitHub issueを作成できるSlackApp 「<a href="https://issit.plaid.co.jp/">issit</a>」を開発・導入しました
<ul>
<li>メッセージからissueを作成できるようにした</li>
<li>チャンネルとレポジトリを事前に紐付け、簡単に選択できるようにした</li>
</ul>
</li>
</ul>
<h2>まとめ</h2>
<p>SlackBotであらゆる業務を自動化した事例を３つ紹介させていただきました。</p>
<ul>
<li>Dialogflowを使用したお問合せBot</li>
<li>SaaS Admin権限の申請/付与/削除の自動化</li>
<li>Slackメッセージからissueを作成するSlackアプリ</li>
</ul>
<p>これら３つの事例が、メンバーになぜ使ってもらえるようになったのか。を考えると、コミュニケーションツールとして全員が使っていることが大きな要因ではないかなと思います。</p>
<p>これらを踏まえて、社内コミュニケーションツールであるSlackを活かした 生産性向上の取り組みを継続していきたいと思っています。システムや仕組みが素晴らしいことはもちろん大切なのですが、まず使ってもらえることも同じくらい大切なことではないかなと思います。</p>
<p>最後に、こういった活動をしておりますので、一緒に進める仲間を募集しています。<br>
少しでも興味を持っていただけたら、<a href="https://recruit.plaid.co.jp/">採用ページ</a>もぜひご覧ください。</p>


SlackBotで自動化した事例を紹介。問い合わせ〜DevOpsまで。Dialogflowを使用したお問合せBot・SaaS Admin権限の申請/付与/削除の自動化・Slackメッセージからissueを作成するSlackアプリ

SlackBotであらゆる業務を自動化。問い合わせ〜DevOpsまで

<p>こんにちは、エンジニアの oga  です。</p>
<p>2022/6/7-8 に行われた <a href="https://cloudonair.withgoogle.com/events/solution-data-analytics">Data Analytics/Database OnAir</a> に AlloyDBの分析基盤での活用に関する内容で登壇させて頂きました。</p>
<p>こちらのブログでもその内容を簡単にまとめておきます。</p>
<p>また、AlloyDBのアナウンスに関する各種公式ドキュメントや特徴的な機能のサマリーについて、<a href="https://tech.plaid.co.jp/attended_private_preview_of_alloydb">こちらの記事</a>でもご紹介しているので、良ければ併せてご覧ください。</p>
<h1>「AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？」</h1>
<p>KARTEでは大規模データに対するさまざまな分析機能をご提供しています。<br>
そのデータ基盤としてBigQueryを中心としてGoogle cloudのDB製品を利用していますが、<br>
AlloyDBがさらなる強力なソリューションとなり得るのか、Columnar Engineを中心に特に分析ワークロードに関わる機能に着目し検証・検討を行っています。<br>
パフォーマンス面は非常に優位な結果が得られたことと、運用上の考慮点やアーキテクチャ案、今後特に要望したい機能について発表しています。</p>
<p><a href="https://cloudonair.withgoogle.com/events/solution-data-analytics?talk=0608-3">セッション動画</a></p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/CHaRm91of4Z30t" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/TakuyaOgawa8/whatisthepotentialofalloydbindataanalysisinfrastructurepdf" title="AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？" target="_blank">AlloyDB のデータ分析基盤での活用におけるポテンシャルとは？</a> </strong> from <strong><a href="//www.slideshare.net/TakuyaOgawa8" target="_blank">Takuya Ogawa</a></strong> </div>
<h1>最後に</h1>
<p>今回AlloyDBに関するセッションとして、Google Cloudの江川さんによる <a href="https://cloudonair.withgoogle.com/events/solution-data-analytics?talk=0608-1">AlloyDB for PostgreSQL 概要とアーキテクチャ</a> は機能特徴やアーキテクチャ、他DBとの棲み分けなど全体像を掴むのに非常に学びになりました。また、NRIさんによる <a href="https://cloudonair.withgoogle.com/events/solution-data-analytics?talk=0608-2">サービス比較検証から探る AlloyDB の真価</a>では踏み込んだ非機能面での比較検証結果を中心に発表されていて、優位な面劣勢な面が見えつつ、検証の過程でGoogleのエンジニアにより日々改善されていることが垣間見得たのも面白かったです。</p>
<p>今後もデータを事業の中心とする弊社では、AlloyDBのみならずデータに関しては様々な取り組みをしていきますのでデータが好きな方は是非、<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


2022/6/7-8 に行われた Data Analytics/Database OnAir にAlloyDBの分析基盤での活用に関する内容で登壇させて頂きました。こちらのブログでもその内容を簡単にまとめておきます。

Data Analytics OnAir / Database OnAir でAlloyDBの分析基盤での活用について登壇しました

<p>こんにちは、エンジニアの oga です。</p>
<p>5/12(日本時間)にGoogle I/Oで <a href="https://cloud.google.com/alloydb/">AlloyDB</a> と呼ばれる新しいデータベースプロダクトがアナウンスされました。<br>
アナウンスブログ: <a href="https://cloud.google.com/blog/ja/products/databases/introducing-alloydb-for-postgresql">AlloyDB for PostgreSQL を発表：高額なレガシー データベースからの解放 | Google Cloud Blog</a></p>
<p>PLAIDでは、Private previewの段階で紹介をして頂き非常に興味深いものだったのでpreviewに参加して検証を行なっていて、以下の様なコメントを寄稿させて頂きました。<br>
<img src="https://ik.imagekit.io/plaid/3108b9ec-ad62-483a-ab17-f622e7b0522c/1000x1000/alloydb_plaid_quote.png" alt="alloydb_plaid_quote.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>以下和訳</p>
<blockquote>
<p>「PLAID では CX (顧客体験) プラットフォーム KARTE を企業向けに開発・提供しています。KARTE は膨大な行動ログから深い洞察を得る先進的なリアルタイム分析機能を持ち、顧客に合わせた最適なコミュニケーションを可能にしています。AlloyDB は PostgreSQL と完全互換であり、透過的に列方向処理を行うことができます。私たちはこれが新しく強力なオプションであると捉えており、OLTP・OLAP・HTAP と分断されたワークロードを統合したシステムデザインを最小限の追加知識で実現する、ユニークな技術的アプローチであると考えています。将来的には Google Cloud の他の強力なデータベース サービスとの連携も強化され、私たちのKARTEが提供する分析機能において、より優れたパフォーマンス、スケーラビリティ、拡張性をもたらすことを期待しています。」</p>
</blockquote>
<p>この記事では、AlloyDBの特徴とPLAIDで今後どの様に使っていきたいかをご紹介します。</p>
<hr>
<section class="widget widget-text">
	<div id="toc"></div>
</section>
<style>
    div#toc ol {
        margin: 0 0 0 25px;
    }
    div#toc ol li {
        margin: 0;
        padding: 1px;
        list-style-type: disc;
    }
</style>
<hr>
<h2>はじめに</h2>
<p>AlloyDBはPreviewフェーズである為、今後の機能追加や仕様変更も多く発生すると思われます。<br>
この記事では、現時点の仕様情報とそれに基づく見解を記載しています。<br>
<strong>最新の情報は必ず<a href="https://cloud.google.com/alloydb/docs/overview">GCPの公式ドキュメント</a>をご確認下さい。</strong></p>
<h2>AlloyDBの特徴</h2>
<ul>
<li>PostgreSQLとの完全互換</li>
<li>高パフォーマンス</li>
<li>columnar engine（高速なOLAP）</li>
<li>柔軟で高い可用性を持った構成</li>
<li>機械学習による自動化されたリソース管理</li>
<li>シンプルな料金体系</li>
</ul>
<h3>PostgreSQLとの完全互換</h3>
<p>文字通り、PostgreSQLを使用するアプリケーションやエコシステムはAlloyDBで変更する必要無くそのまま適用することができます。<br>
弊社ではそういったアプリケーションは無かったものの、検証においてCLI,GUIツールなど今まで培われてきたPostgreSQLのものをそのまま使用でき、<br>
開発や運用に関わるベストプラクティスも大部分は同じ様に適用できそうなので非常に効率良く移行ができると感じました。</p>
<p>サポートされるパラメータや拡張は決まっている為、既存のPostgreSQLインスタンスを移行する場合や実現したい機能に必要な拡張があるかは事前に以下のドキュメントで確認することができます。</p>
<ul>
<li><a href="https://cloud.google.com/alloydb/docs/reference/database-flags">Supported database flags  |  AlloyDB for PostgreSQL  |  Google Cloud</a></li>
<li><a href="https://cloud.google.com/alloydb/docs/reference/extensions">Supported database extensions  |  AlloyDB for PostgreSQL  |  Google Cloud</a></li>
</ul>
<p>マイグレーションに関しては、<a href="https://cloud.google.com/database-migration">Database Migration Service</a>でサポートされることになると思われます。また、異なるDBを使用しているなど複雑で支援が必要な場合では<a href="https://cloud.google.com/resources/database-migration-program">Database Migration Program</a>で移行支援も受ける事ができます。</p>
<h3>高パフォーマンス</h3>
<p>パフォーマンス面は大きく優位性があるとのことで、標準のPostgreSQLと比較してOLTPが4倍、OLAPでは100倍のパフォーマンスであると発表されています。</p>
<table>
<thead>
<tr>
<th>OLTP</th>
<th>OLAP</th>
</tr>
</thead>
<tbody>
<tr>
<td><img src="https://ik.imagekit.io/plaid/f5bcca91-4418-4b25-beb3-5d149f7f47c5/1000x1000/alloydb_4x.png" alt="alloydb_4x.png"></td>
<td><img src="https://ik.imagekit.io/plaid/26e2432e-5fec-4770-8e22-dd65f9599daf/1000x1000/alloydb_100x.png" alt="alloydb_100x.png"></td>
</tr>
</tbody>
</table>
<p><a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>PostgreSQLと互換性を保ちながら、内部のストレージやキャッシュシステム等は独自的なものに変更されている様です。<br>
特にストレージについては別のブログポストで解説されていますが、ストレージを分離することでストレージのスケーラビリティを向上させつつI/Oによるブロック時間を極力低減させる構造を作り、トランザクション処理の高速化やレプリケーションの低遅延などを実現している様です。<br>
<a href="https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage">AlloyDB for PostgreSQL intelligent scalable storage | Google Cloud Blog</a></p>
<p>実際にはそれぞれのワークロードの特性やコストバランスに依るところが大きいにしても、<br>
既に運用しているPostgreSQLをそのまま置き換えることを検証する価値はあると感じます。</p>
<h3>columnar engine（高速なOLAP）</h3>
<p><img src="https://ik.imagekit.io/plaid/e6d50050-ec77-42d4-a034-486461dd600d/1000x1000/alloydb_columnar_engine.png" alt="alloydb_columnar_engine.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>PLAIDでも最も注目し検証している機能が、この<a href="https://cloud.google.com/alloydb/docs/columnar-engine/about">columnar engine</a>です。<br>
OLAPの100倍高速化、という特徴はこのcolumnar engineにより実現されています。</p>
<p>本来行指向データベースであるPostgreSQLに列指向データベースとしての特性を<strong>透過的</strong>に加えることができ、<a href="https://cloud.google.com/alloydb/docs/columnar-engine/quickstart">セットアップ</a>を行うとインメモリ上でカラムデータを保持する様になり、クエリ側は特殊な記法などは無く列指向のスキャンが行えるかは内部で自動判断されます。<br>
また、完全にcolumnar engineで列指向スキャンされるカラムに対してはindexが不要になる為、削除することで負荷削減に繋がります。</p>
<p>インメモリに対してどのテーブルのどのカラムを保持するべきか、実行されたクエリに基づき判断する<a href="https://cloud.google.com/alloydb/docs/columnar-engine/quickstart#auto-populate">レコメンデーション機能</a>が用意されているので、既存のデータとワークロードを移行しつつ、強く意識せずにOLAP処理を高速化するという導入の仕方も可能かと思います。（弊社では検証の特性上、<a href="https://cloud.google.com/alloydb/docs/columnar-engine/manage-content-manually">手動での管理</a>で行なっていました）</p>
<p>列指向はより巨大なデータを扱うDWHで特に採用されることが多く、大量データの分析処理に適しています。<br>
つまりAlloyDBで従来の行指向データベースとしての適所であるOLTPのワークロードをカバーしつつ、<br>
列指向の特性を加えてOLAPのワークロードも同データベースでカバーできる可能性があるということです。<br>
マスターとして使用するRDBMSから主にデータ分析用途などでDWHにデータをロードするという流れは良くに行われていると思いますが、<br>
統合されたシンプルなアーキテクチャを実現しつつ同時に高速化を狙う選択肢が持てるのは魅力的です。</p>
<h3>柔軟で高い可用性を持った構成</h3>
<p>AlloyDBではClusterという単位毎に1つのPrimaryとオプショナルで複数のRead poolインスタンスを構成することができます。<br>
<img src="https://ik.imagekit.io/plaid/28c94b66-45b9-41c2-b3b0-91a38d0c5593/1000x1000/adb-resource-tree.png" alt="adb-resource-tree.png"><br>
<a href="https://cloud.google.com/alloydb/docs/overview#hierarchical_resource_structure">Hierarchical resource structure</a> より引用</p>
<p>PrimaryはHAを選択すれば自動フェイルオーバーするStand-byが構成されます。<br>
Read poolは読み取り専用のレプリカとして使用でき、特にリソースを多く使う分析クエリはRead pool側に流すという構成を取ることで書き込み処理に影響を与えず処理を載せることができます。複数構成することができるので、例えば負荷特性の異なる機能に応じてRead poolを分け、マシンスペックやノード数、パラメータをそれぞれで調整するといったことも簡単に行えます。<br>
ただし、Read poolは非常に短時間ながらPrimaryに対してラグがある為、完全な一貫性が必要で無い機能で使用することになります。</p>
<h3>機械学習による自動化されたリソース管理</h3>
<p><img src="https://ik.imagekit.io/plaid/df5df673-52a6-4c10-9271-afa9a6eb150e/1000x1000/alloydb_autopilot.png" alt="alloydb_autopilot.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>詳細な仕様についてはまだ情報が無い様ですがコストやパフォーマンスに関わるDB管理の自動化が行われる機能があり、経験値と手間が必要なベーシックなチューニング作業は任せることもできそうです。</p>
<h3>シンプルな料金体系</h3>
<p><a href="https://cloud.google.com/alloydb/pricing">https://cloud.google.com/alloydb/pricing</a></p>
<p>現状は非常にシンプルで、CPU・メモリ/ストレージ/NWによりテーブルが決まります。NWはEgressのみが課金です。<br>
プレビュー期間中はFair Usage Limitsに基づき無料で試すことができます。</p>
<h2>PLAIDで行なっていた検証と今後どの様に使っていきたいか</h2>
<p>上記の通りAlloyDBはPostgreSQLとの完全な互換性があり、すでにPostgreSQLを使用しているアプリケーションを変更すること無く移行が可能なことが特徴の一つですが、弊社では既存システムで使っている訳では無いので、分かりやすい検証事例はまだありません。</p>
<p>PLAIDでは OLTP/HTAP/OLAP 様々なデータ処理においてBigtableやSpanner、BigQueryといったGoogle Cloudのデータベースプロダクトを使い倒していますが（<a href="https://tech.plaid.co.jp/google-cloud-day-digital-2022">ご参考</a>）、<br>
その上でもcolumnar engineをはじめとしてして分析機能での活用で大きなパフォーマンス改善につながるポテンシャルを持っていると考え特にOLAPの拡張の観点を中心に検証を行なっています。</p>
<p>その為、上に挙げた様な他のGoogle Cloudのデータベースとのインテグレーション機能の追加にも強く期待しており、今後の機能拡張もウォッチしながら引き続き検証を進めていく予定ですので、また折々でご紹介できればと思います。</p>
<h2>最後に</h2>
<p>弊社では <a href="https://karte.io/">KARTE</a> をはじめ、事業においてデータを中心におき展開しています。<br>
より大量のデータを、より早く、柔軟に処理する為に様々なデータベースを活用しており、今後もよりもっと多くのデータベースを試し導入しながら良いプロダクトを作っていきたいと考えています。<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>
<script>
    /**
     * For displaying a table of contents - pass the entire document (DOM) to getTocMarkup
     */

    function getHeaderLevel(header) {
        return Number(header.nodeName.slice(-1));
    }

    function createTocMarkup(headers) {
        var prevLevel = 1;
        var output = "";

        headers.forEach(function(h) {
            var currLevel = getHeaderLevel(h);
            if (currLevel > prevLevel) {
                var ranOnce = false;
                while (currLevel > prevLevel) {
                    if (ranOnce) {
                        output += "&nbsp;";
                    }
                    output += "<ol style=\"margin-bottom:0px\"><li>";
                    prevLevel += 1;
                    ranOnce = true;
                }
            } else if (currLevel == prevLevel) {
                output += "</li><li>";
            } else if (currLevel < prevLevel) {
                while (currLevel < prevLevel) {
                    output += "</li></ol>";
                    prevLevel -= 1;
                }
                output += "<li>";
            }

            output += `<a href="#${h.id}">${h.innerText}</a>`;
        });

        if (output != "") {
            // Change 2 to the max header level you want in the TOC; in my case, H2
            while (prevLevel >= 2) {
                output += "</li></ol>";
                prevLevel -= 1;
            }
            output = `<h2 class="widget-title">目次</h2>${output}`;
        }

        return output;
    }

    function getTocMarkup(document) {
        // I was only interested in the headers within the element that had the .post-content class,
        // which is specific to the Ghost blog. If you're using this elsewhere, or are interested in
        // the entire document, delete this line and use document.querySelectorAll(...) on the next line.
        var body = document.getElementsByClassName('Article_Body_JS')[0];

        // Add or remove header tags you do (or don't) want to include in the TOC
        var headers = body.querySelectorAll('h2, h3, h4, h5, h6');

        // Change the number to 1 if you want headers no matter what.
        // Or if you want at least 3 headers before generating a TOC, change it to 3.
        if (headers.length >= 2) {
            return createTocMarkup(headers);
        } else {
            return "";
        }
    }
</script>
<script type="text/javascript">
    document.getElementById('toc').innerHTML = getTocMarkup(document);
</script>


5/12(日本時間)にGoogle I/Oで AlloyDB と呼ばれる新しいデータベースプロダクトがアナウンスされ、弊社のコメントもイベント内で引用して頂きました。この記事では、AlloyDBの特徴とPLAIDで今後どの様に使っていきたいかをご紹介します。

AlloyDBのPrivate previewに参加し、Google I/Oでコメントが引用されました

Engineer Blog

Recent Article