Engineer Blog

Takumi Ishii

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


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

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

Platform Engineering Kaigi 2024登壇レポート

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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


database, analytics, karte, algorithm, aggregation, blitz

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

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

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まで