Engineer Blog

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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でコメントが引用されました

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a>  です。<br>
2022/04/19 - 2021/04/21 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-22">Google Cloud Day: Digital '22</a> に 弊社2名で「機械学習」「データベース」の2テーマでそれぞれ登壇してきました。</p>
<p>こちらのブログでもその内容を簡単にまとめておきます。</p>
<h1>「MLOps 再入門！ Vertex AI で広がる MLOps の世界と実践例」</h1>
<p>こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。</p>
<p>これまではKubeflow Pipelineなどを用いてエンジニアとデータサイエンティストの協業で開発・運用してきたML基盤を、Vertex Workbenchを用いることでデータサイエンティストのみで開発・運用できるようにした点が今回のポイントです。</p>
<p>エンジニア工数ゼロで迅速にMLOpsができるようになるこの仕組みを「Light MLOps」と名付けました。</p>
<p><a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-22/watch?talk=d1-ml-10">セッション動画</a>ではさらに具体的にVertex Workbenchの使い方も含めて紹介しているので、ご覧いただければ幸いです。</p>
<p><a href="https://speakerdeck.com/kargo113/lightmlops-using-vertex-workbench">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="fe1fdf90e424490f8007a6d81708db4d" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「Bigtable を使いこなす！KARTE で秒間 13 万イベントを 0.x 秒以内に捌く秘訣」</h1>
<p>こちらは<a href="">@kusahana</a>よりご紹介致しました。</p>
<p>今まで多くのエンドユーザー（累計145億UU）のエンドユーザーの行動データをリアルタイム（0.x秒）で解析するために、どう私たちがBigtableを活用しているかを紹介しました。<br>
特にリアルタイム解析基盤の刷新に伴い、Bigtableの使い方を見直した結果を具体的な数値交えて共有しています。<br>
スキーマ変更によるパフォーマンスやコスト上の改善効果、Bigtableをスケーラブルなキューとして使う新たなユースケースなど、是非紹介したいのでご覧いただければ幸いです。</p>
<p><a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-22/watch?talk=d2-db-02">セッション動画</a></p>
<p><a href="https://speakerdeck.com/kusahana/cloud-bigtable-woshi-ikonasumi-jue-2022">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-slide="1" data-id="078fbb8e1eea42229f06723d4a28878e" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
<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 '22 で「MLOps 再入門！ Vertex AI で広がる MLOps の世界と実践例」等、2セッション登壇しました

Google Cloud Day: Digital '22 にて 機械学習/データベース について2セッション登壇しました

PLAIDのインターンを振り返って ~ 開発環境の改善がもたらす新機能リリースの効率化 ~