Engineer Blog

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<p>こんにちは。プレイドでエンジニアをしている、とさです。</p>
<p>今回は、2025年6月13日(金)に開催した、社内のAI Agent開発ハッカソンのレポートをお届けします。</p>
<h3>1. はじめに</h3>
<h3>開催の背景と目的</h3>
<p>現在プレイドでは、提供するプロダクト上にAI機能を組み込むためのプロジェクト進めていて、mastraを用いた開発環境の整備やPOC（概念実証）を通して、組み込みの方向性を模索しています。</p>
<p>このプロジェクトの一環として、私たちは「動くAI Agentを作る実践の場」として、社内ハッカソンを企画しました。</p>
<p>このイベントは、単なる開発コンテストではありません。</p>
<ul>
<li><strong>技術の筋トレ:</strong> 最新のAI技術に触れ、実践的な開発スキルを磨く。</li>
<li><strong>チーム横断開発の種まき:</strong> 部署の垣根を越えたコラボレーションを生み出し、組織全体の開発力を底上げする。</li>
</ul>
<p>これらを同時に達成し、プロダクトへのAI組み込みの速度と質を向上させることが、私たちの大きな狙いです。</p>
<p>今回のAI Agent開発は、実際にAI機能開発でも利用されているプラットフォーム「mastra」上で行われました。参加者は普段の業務に近い本格的な環境で、実践的な開発に挑戦しました。</p>
<p><a href="https://mastra.ai/blog/plaid-jpn-gcp-agents">Why PLAID Japan builds agents on their Google Cloud infrastructure with Mastra</a></p>
<p>Mastra社の技術ブログでもプレイドのことを取り上げてくださいました。</p>
<h3>イベントの概要</h3>
<ul>
<li><strong>日時:</strong> 2025年6月13日(金) 13:00 - 19:00</li>
<li><strong>場所:</strong> オフィス（芝生エリア）。</li>
<li><strong>参加者:</strong> エンジニアを中心に約20名。</li>
<li><strong>開発テーマ:</strong> プロダクトのAPIを活用した、便利なAI Agentを開発する。</li>
</ul>
<p>半日という短い時間で、ローカル環境に「ミニマム」で「動く」AI Agentを開発することを目指しました。</p>
<h3>2. 当日の様子</h3>
<p>当日は、オフィス内の開放的な芝生エリアにメンバーが集結。午後1時のキックオフから開始しました。</p>
<p><img src="https://ik.imagekit.io/plaid/216860f9-1624-475d-9802-ca4769139972/image1.png" alt="image1.png"></p>
<p>最初のアイデア出しでは、「どのような課題を解決しようか」「どのようなAgentが便利か」と、多くのチームが議論に苦戦している様子も見られました。しかし、そこからがエンジニアの腕の見せ所です。徐々にアイデアが固まると、各々が猛烈な勢いでコーディングに集中し始めました。</p>
<p><img src="https://ik.imagekit.io/plaid/1fa28090-0a1d-4d79-856b-69e67bce2b34/image2.png" alt="image2.png"></p>
<p>真剣な表情でモニターに向かう姿、チームメンバーと活発に意見を交わす姿、そして時折見せる笑顔。限られた時間の中で、ものづくりを楽しむ参加者のエネルギーが会場全体に満ちていました。</p>
<p>さらに驚くべきは、今回のハッカソンには開発経験が必ずしも多くない新卒メンバーやカスタマーエンジニアも参加し、開発環境のセットアップから始めたにもかかわらず、発表までの短い時間で全員がAI Agentを完成させたことでした。これも、開発をサポートするAI Coding Agent自体の進化が後押しした結果と言えるでしょう。</p>
<p><img src="https://ik.imagekit.io/plaid/d3dcf93a-55e0-4a01-a316-9f74d5d2e32d/image3.png" alt="image3.png"><br>
<img src="https://ik.imagekit.io/plaid/d3dcf93a-55e0-4a01-a316-9f74d5d2e32d/image3.png" alt="image1.pngimage2.pngimage3.png"></p>
<h3>3. チームと成果物の紹介</h3>
<p>夕方からは、いよいよ成果発表会です。短時間でAI Agentが次々と生み出されました。ここで参加者が作成したAI Agentたちをいくつかご紹介します。</p>
<h3>実際に開発されたAI Agentの一例</h3>
<ul>
<li>クエリGUIの「ノード説明Agent」</li>
<li>面倒な入力を一瞬で終わらせる「フォーム自動入力ツール」</li>
<li>クエリGUIの「エラー解説＆ノード名提案Agent」</li>
<li>ローカルクラスタ用の「自然言語データ検索Agent」</li>
<li>30分で実装した「記事要約＆関連記事提示Agent」</li>
<li>営業の強い味方となる「業界別・事例検索Agent」</li>
<li>企業情報への「自動タグ付けAgent」（への道）</li>
</ul>
<p>実際のプロダクトのローカル環境に組み込んでデモしてくれたチームもありました。</p>
<h3>4. 参加者の声</h3>
<p>イベント後、参加者から多くのフィードバックが寄せられました。その一部をご紹介します。</p>
<h3>良かったこと・新たな発見</h3>
<p>最も多くの参加者が口にしたのは、**「AI Coding Agentの発達の凄さ」と「チームで開発する楽しさ」**でした。「数時間でみんなが成果物を作れていた」「普段関わりのないメンバーと機能開発の面で交流できたのが貴重だった」といった声が上がりました。</p>
<p>また、「mastraやKARTEの中身も軽く知ることができ、KARTEそのものの理解も深まった」という副次的な効果を実感した参加者もいました。</p>
<h3>改善点・今後の期待</h3>
<p>一方で、**「アイデア出しの難しさ」**も浮き彫りになりました。「アイデアソンの前にmastraへの理解を深めていれば、もっと良いアイデアが出せたかも」といった声や、「まずmastraを触ってからアイデアを出す方がやりやすかった」という意見が多く聞かれました。中には、「事前にアイデア出しのフェーズを設け、アイデアを出す人と作る人が分かれて参加できる形式も良いのでは」といった具体的な提案もありました。</p>
<p>また、「KARTE上での実装を楽にしてくれるツールが欲しい」という声が多数寄せられました。特に、以下のような実践的な開発をサポートする機能への期待が高まっています。</p>
<ul>
<li>複雑な接客作成をサポートする、社内ナレッジを学習したエージェント</li>
<li>PdMやデザイナーが開発セットアップなしで簡単に動作確認できる環境</li>
<li>本格導入に向けたエージェントの評価の仕組み</li>
</ul>
<h3>5. ハッカソンを終えて</h3>
<p>最後に、参加者から寄せられた「今回感じたこと」が、今回のハッカソンのリアルな学びを象徴していたのでご紹介します。</p>
<ul>
<li><strong>Vibe codingの限界:</strong> 本当に知識がないと、投げるプロンプトが曖昧になり、痒い所に手が届かない。</li>
<li><strong>Agent化の必要性:</strong> 今やっている作業は、本当にAgentにする必要があるのか、と作りながら考えさせられた。</li>
<li><strong>AIとの対話の難しさ:</strong> なぜAIがWebサイトをしっかり調べにいかないのか、プロンプトが細かすぎるのかなど、AIの挙動をコントロールする難しさを感じた。</li>
</ul>
<p>ツールを使えば誰でも簡単に作れるように見えて、実は深いドメイン知識やプロンプトエンジニアリングの技術が求められます。AI開発のリアルな手触り感を得られたことも、大きな収穫でした。</p>
<h3>6. 謝辞</h3>
<p>このハッカソンの成功は、参加者の皆さんの情熱と創造性、そして企画・運営に奔走してくださった運営・サポートメンバーの尽力のおかげです。</p>
<p>この場を借りて、イベントに関わったすべての方々に心から感謝申し上げます。ありがとうございました。</p>
<h3>7. おわりに</h3>
<p>今回のハッカソンは、社内に眠る技術力と創造性を再発見する、素晴らしい機会でした。半日という短い時間で、これだけ多様なAI Agentが生まれたことに驚きました。</p>
<p>そして、早くも第2回の開催が決定しました。次回は、より多くの職種のメンバーが参加できるよう「アイデアソン」形式での開催を予定しています。</p>
<p>このハッカソンをきっかけに生まれた熱量を、今後のプロダクト開発、そして組織全体の力へと繋げていきます。</p>
<p>今後のプレイドのプロダクトとAIの進化にご期待ください。</p>


社内AI Agent開発ハッカソンレポート｜半日で20名が挑んだ“動くAI”づくり

<h2>はじめに</h2>
<p>はじめまして、プレイドにて8月の1ヶ月間エンジニアインターンに参加しておりました、中村天晴と申します。プレイドではJourneyチームで、定期実行基盤に関するタスクに取り組んでいました。</p>
<p>本ブログでは自分がプレイドにて行った仕事を紹介しつつ、プレイドでの働き方やインターンの魅力をお伝えできればと思います。</p>
<h2>Journeyとは</h2>
<p>具体的な仕事内容をご紹介する前に、KARTEが持つ「Journey」という機能を紹介させていただきます。</p>
<p>JourneyとはKARTEで得られたユーザ行動を元に、シーンやシナリオに合わせてより1人ひとりの行動にあわせたアクションを実行する機能です *1</p>
<p>*1: <a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>例えば、「商品をカートに入れたままサイトを離れたユーザに、翌日プッシュ通知でクーポンを送る」といった複雑なシナリオを、管理画面で簡単に作成・配信することができます。</p>
<p>内部の仕組みとしては「定期実行基盤」と呼ばれるバッチジョブが存在し、このジョブが定期的に実行されることでユーザがシナリオ上のステップからステップに移動しています。</p>
<p>Journeyは現在ベータ版の機能として提供しており、今後より多くのニーズに応えられるよう定期実行基盤の改善を進めています。</p>
<h2>分岐ノードのデバッグ</h2>
<p>ここからは、実際に自分が担当した仕事を紹介していきます。</p>
<p>Journeyではユーザの各ステップを「ノード」という形で表現しており、管理画面上でノードを繋ぎ合わせることで複雑なシナリオを設定します。</p>
<p>今回自分は「分岐ノード」と呼ばれる、ユーザを属性によって異なるノードへと進めるためのノードを作り直す作業に取り組みました。</p>
<p><img src="https://ik.imagekit.io/plaid/7a976b2d-f83a-4e51-b5a8-15225c04d78b/mermaid-diagram-2025-08-28-123417.png" alt="mermaid-diagram-2025-08-28-123417.png"></p>
<p>定期実行基盤には、大きく2つの要件があります。1つは数百万規模のユーザを遅延なく処理できること、もう1つは「カートに入れたが購入しなかった」といったユーザごとの複雑な条件を計算できることです。</p>
<p>この要件を満たすため、アーキテクチャは工夫されており、「次にシナリオを進めるべきユーザを計算・抽出するコンポーネント」と、「実際にそのユーザの状態を次のステップに移動させるコンポーネント」というように、役割が明確に分割されています。</p>
<p>自分が開発に関わり始めた時点で新しい分岐ノードに対応する実装は完了していたのですが、一連の処理が正しく実行できる状態になっていませんでした。自分は、一連の処理が正しく実行されない原因を究明し、処理が完了できるようにするため様々な修正を行いました。</p>
<ul>
<li>コンポーネント間で参照しているデータベースが異なっていたため修正</li>
<li>コンポーネント間でハッシュの生成方法に差異があったため修正</li>
<li>分岐判定の誤り原因を調査するためデバッガーを導入</li>
<li>分岐ノードで分岐条件を正しく判定できても、実際に分岐先にユーザが移動しない問題の修正</li>
<li>評価環境と開発環境の差分をなくすためのマイグレーションの実施</li>
</ul>
<p>動かない間はひたすらクラウドサービスのコンソールを眺める時間が続き大変でしたが、分岐ノードのテストが正しく動作した時は本当に嬉しく感じました。</p>
<h2>BigQueryのオプションジョブ作成モードの適用</h2>
<p>Journeyでは一部でBigQueryを利用しています。インターンではパフォーマンス向上とコスト効率化を目指し、BigQueryの改善にも取り組みました。</p>
<p>BigQueryには8月からクエリが短い場合にジョブを作成せずにジョブを実行することができる昨日「オプションジョブ作成モード」が追加されました。*2</p>
<p>*2: <a href="https://cloud.google.com/bigquery/docs/running-queries?hl=ja#optional-job-creation">オプションジョブ作成モード</a></p>
<p>この機能がベータとしてリリースされた当初からJourneyではこのモードを利用するために、当時ドキュメントに記載されていた <code>QUERY_PREVIEW_ENABLED</code> という環境変数を適用していました。しかし、調査してみるとこの環境変数が設定されていてもジョブが常に作成されていることがわかりました。</p>
<p>さらにクライアントライブラリの実装 *3 を調べると、有効化の方法が環境変数での設定からクライアントのオプションとして設定するように変更されていることがわかりました。</p>
<p>*3: <a href="https://github.com/googleapis/nodejs-bigquery/pull/1480">クライアントの実装PullRequest</a></p>
<p>そのため、調査結果を元にオプションジョブ作成モードをクライアント側で明示的に指定するよう変更し、短いクエリの場合にジョブが作成されなくなったことを確認しました。</p>
<h2>プレイドでのインターン生活</h2>
<p>最後にプレイドでのインターン生活で特に印象に残った部分をご紹介します。</p>
<p>Journeyチームでは週次で全体のミーティングがあり、プロダクトの方向性などについての議論が交わされています。自分もそのような会議に基本的に出席するなかで、顧客から求められていることと技術的な制約の間を垣間見ることができました。</p>
<p>そのなかで毎度なぜ技術的な制約があるのかに立ち返りながら、ステークホルダー全員が理解できる形での説明が繰り返されている点から、単なる開発ではなく「仕事」として開発するということを学ぶことができました。</p>
<p>また技術的にも、今ある技術的課題がどこにあるのか、何が原因なのか、短期・長期でどのように解決していくのかといった議論にインターンという身でありながら参加することができたのも非常に面白かったです。</p>
<p>このように単なる開発ではなく、仕事としての開発を感じることができることがプレイドのインターンの一つの魅力だと感じました。</p>
<h2>終わりに</h2>
<p>Journeyは大量の入力があった場合にも問題なく処理できるようにするため、非常に複雑なアーキテクチャとなっています。</p>
<p>今回のインターンでは初回の1on1の際にメンターの方に分からないことを全て質問する機会をいただいたおかげで、期間を通して複雑なアーキテクチャであってもすんなりと理解することができました。 *4</p>
<p>*4: 利用されているマネージドサービスはほとんど触れたことのないものでしたが、期間を通じてそれぞれの強みと利用されている理由を理解することができました。</p>
<p>プレイドでは与えられた仕事だけでなく、自分が「ここはこうした方が良いのではないか」といった提案がインターン生であっても積極的に採用されるフラットな文化があり楽しく過ごすことができました。</p>
<p>実際にはこの記事の中ではなかなかご紹介できない様々な課題に取り組んだため、ぜひプレイドに入社して確かめてみてください！1ヶ月間お世話になりました！</p>


はじめまして、プレイドにて8月の1ヶ月間エンジニアインターンに参加しておりました、中村天晴と申します。プレイドではJourneyチームで、定期実行基盤に関するタスクに取り組んでいました。  本ブログでは自分がプレイドにて行った仕事を紹介しつつ、プレイドでの働き方やインターンの魅力をお伝えできればと思います。

プレイドインターン体験記：大規模ユーザデータを処理する裏側を覗く

<h1>自己紹介</h1>
<p>こんにちは！8月1日からプレイドでインターンをしている<a href="https://my-portfolio-kh49.vercel.app/">櫻井絵理香</a>です。<br>
普段は京都の大学に通っています。</p>
<p>これまでiOS開発をメイン（正直、iOS開発しかほとんどしたことがありませんでした...）でやってきましたが、今回のプレイドでのインターンでは初めてフルスタックで開発をしました。私は今回のプレイドのインターンでは、「モバイルアプリのNative UI構築に関する課題を解決する」新規事業・プロダクト開発のチームに配属されました。</p>
<p>Webのフロントエンド、バックエンド、インフラアーキテクチャ、そしてiOS SDKまで、超フルスタックな体験をさせていただき、自分にとって大きな挑戦となりました。普段慣れ親しんだiOS開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。<br>
この記事では、そんな貴重な体験について詳しくお話ししたいと思います。</p>
<h1>インターンでの内容</h1>
<h2>デモアプリの実装</h2>
<p>SDKの機能や使用感を実際に体験してプロダクトの理解を深めるために、Figmaのデザインに沿ったデモアプリの実装を行いました。インターン開始時に「やりたいことはあるか？」と聞かれた際、CI構築とテスト実装への挑戦を希望していたため、デモアプリでこれらの技術要素を組み込むことになりました。アプリ開発では実際にSDKをコードベースに統合し、その動作を確認しました。SDKの内部実装を詳細に調査するのは初めての経験でした。<br>
<img src="https://ik.imagekit.io/plaid/01cb494a-cd74-4d5f-9919-7b345945c420/Group1759.png" alt="Group1759.png"><br>
画像はデモアプリのもの</p>
<h2>CIとテスト実装の実践的学習</h2>
<h3>GitHub Actionsによる継続的インテグレーション</h3>
<p>初めてGitHub Actionsを使用し、プルリクエスト時の自動テスト実行環境を構築しました。ワークフローファイルの設定からテスト結果の可視化まで、継続的インテグレーションの仕組みを実践的に学習できました。</p>
<h3><strong>段階的なテスト戦略の確立</strong></h3>
<p>プロジェクトIDの変更をテキストで手動入力することの煩わしさを解決するため、管理画面側でプロジェクトIDをQRコード化し、SDK側で読み取って即座にプロジェクトIDを反映する機能を実装しました。この新機能の品質を保証するため、QRコード読み込み機能を中心としたユニットテストを実装し、Swift Testingフレームワークを使用してViewModelの状態管理をテストしました。</p>
<p>具体的には、QRコード検出時の状態変化、スキャン開始/停止の制御、カメラ権限拒否時のエラーハンドリングなど、ユーザーの実際の使用パターンを想定したテストケースを作成しました。</p>
<p>テスト実装を通じて「何を保証すべきか」という設計思想の重要性を学びました。単純な動作確認だけでなく、スキャン中でない場合のQRコード無視処理や、複数回の検出処理など、境界条件や異常系も含めた包括的な品質保証の考え方を身につけることができました。</p>
<p>一方でUIテストでは従来手法の限界を実感しました。要素特定の困難さ、UI変更への脆弱性、環境依存による不安定性、そして工数の大きさが課題となりました。この解決策として<strong>MagicPod</strong>を導入し、ノーコードでの効率的なUIテスト自動化を実現しました。</p>
<h2>グラデーションカラーの実装</h2>
<p>デモアプリ実装を通じて実際のプロダクトの機能や使用感を掴むことができたため、次のステップとして実際のプロダクトへ新機能を追加しました。プロダクトの管理画面でグラデーションカラーを指定し、それがSDKに反映される機能を実装しました。この実装を通じて、フルスタック開発における問題解決力やスキーマ設計の重要性について多くの学びを得ることができました。特に印象的だったのは、スキーマを定義してmake generateコマンドでコードと型が自動生成される体験と、GraphQLを初めて触ることでプロダクトの根幹部分に関わることの責任感でした。</p>
<h3>実装の全体像</h3>
<p>アーキテクチャは以下のような流れになっています</p>
<ol>
<li>管理画面でグラデーションカラーを指定</li>
<li>データベースとGCSに保存</li>
<li>iOS SDK側でGCSからJSONを読み取り</li>
<li>JSONをパースしてレンダリング</li>
</ol>
<p>以下に動作の流れのイメージ図を記載します。</p>
<p><img src="https://ik.imagekit.io/plaid/e66702ba-fdf2-4f80-932d-e5c1184adc86/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2911.20.06.png" alt="スクリーンショット2025-08-2911.20.06.png"></p>
<h2>フルスタック開発における問題解決力</h2>
<h3><strong>長い連携チェーンでのデバッグの難しさ</strong></h3>
<p>管理画面（フロント）→ バックエンド → GCS → SDK → アプリという長い連携チェーンで開発を進める中で、最も困ったのは「どこで問題が起きているか分からない」状況でした。</p>
<ul>
<li>フロントからバックエンドにJSONが正しく読み込めているか</li>
<li>GCSに正しく送信できているか</li>
<li>SDK側でJSONが正しくパースできているか</li>
</ul>
<p>これらを一つずつ確認していく作業は想像以上に大変でした。</p>
<h3><strong>問題を小さく分割する習慣</strong></h3>
<p>この経験を通じて、問題を小さく絞って解決していく方法が身につきました。各段階でのデータ整合性を確認し、どの部分で失敗しているかを特定する習慣は、今後のフルスタック開発でも必須のスキルだと感じています。</p>
<h2>GraphQLスキーマ設計の責任と互換性管理</h2>
<h3><strong>プロダクトの核となるデータ構造への責任</strong></h3>
<p>GraphQLを触ること自体が初めてで、特にJSONがプロダクトの大事な部分であることを理解した時、その定義から関わることの重大さを実感しました。スキーマの変更がプロダクト全体に与える影響の大きさは、新規プロダクトならではの貴重な体験でした。</p>
<h3><strong>互換性を考慮した設計の重要性</strong></h3>
<p>最も頭を悩ませたのは互換性の問題でした</p>
<ul>
<li><strong>後方互換性</strong>: 古いJSONで新しいSDKが正常に動作するか</li>
<li><strong>前方互換性</strong>: 古いSDKで新しいJSONが処理できるか</li>
</ul>
<p>これらの両方を考慮しながらスキーマを設計することで、将来的な変更に柔軟に対応できる基盤を作ることの重要性を学びました。</p>
<h3>インターンシップで学んだコーディングの基本</h3>
<p>インターン期間中に最も重要だと実感したのは、レイヤー構造を意識したコード設計です。各層の役割を明確に分離し、適切な抽象化レベルを維持することの重要性を学びました。<br>
単一のモジュールで複数の概念を同時に定義してしまうと、コードの保守性が著しく低下することを実際の開発で経験しました。プレゼンテーション層、ビジネスロジック層、データアクセス層といった責務の分離により、システム全体の理解しやすさと拡張性が大幅に向上することを実感できました。</p>
<h3>Claude Codeでの限界</h3>
<p>Claude Codeは非常に有効なツールですが、その限界についても理解を深めました。新規のiOSアプリ開発のような、ゼロから構築する慣れ親しんだ技術領域では優秀な開発パートナーとして機能しました。<br>
しかし、既存のWebアプリケーションなど、触ったことのない技術スタックでは期待通りの結果を得ることが困難でした。コードが動作するだけでは不十分で、なぜそのような実装を選択したのかという設計思想の理解が不可欠であることを学びました。ツールに依存するのではなく、各コードの抽象化レベルを正確に把握し、システム全体の中での位置づけを理解することの重要性を実感しました。あと、めっちゃ重複でコード書いてくる。差分だけ見ててもダメ、既存のアプリだとすでに実装済みのものがあるかもしれないので、そこを注意しなければならないと感じました。</p>
<h3>まとめ</h3>
<p>今回のグラデーションカラー機能の実装は、単なる機能追加を超えて、フルスタック開発における多くの重要な概念を学ぶ機会となりました。特に以下の点は今後の開発でも大切にしていきたいと思います</p>
<ul>
<li><strong>問題を小さく分割し、段階的にデバッグする習慣</strong></li>
<li><strong>スキーマ設計における互換性への配慮</strong></li>
<li><strong>自動生成ツールを活用した開発効率の向上</strong></li>
<li><strong>プロダクト全体のアーキテクチャを意識した設計</strong></li>
</ul>
<p>フルスタック開発は確かに複雑で困難な面もありますが、プロダクト全体を俯瞰し、エンドユーザーまでの一連の流れを自分の手で作り上げることができる魅力的な野だと改めて感じました。今回の経験を活かして、より良いプロダクト開発に貢献していきたいと思います。</p>
<h1>プレイドで働いてみての感想</h1>
<p>これまでの私の開発経験は主にiOSアプリ開発に限定されており、SwiftとFirebaseを中心とした比較的狭い技術スタックでの開発が中心でした。しかし、今回のインターンでは初めてフルスタック開発に挑戦し、フロントエンドからバックエンドまでの一連の開発フローを体験することができました。この経験は、技術者としての視野を大きく広げる貴重な機会となりました。</p>
<p>他のインターン先で既存アプリケーションの保守・運用は経験したことはあるのですが、今回は新規プロダクトの機能開発に携わることができました。ゼロから機能を設計・実装していく過程は新鮮で、プロダクトが成長していく様子を間近で見ることができたのは非常に貴重な体験でした。スタートアップフェーズのプロダクト開発に関わることで、技術的な判断だけでなく、ビジネス観点も含めた総合的な開発プロセスを学ぶことができました。</p>
<p>プレイドでは、オンライン・オフライン問わず、チームメンバーとのコミュニケーションが非常に取りやすく、疑問点があれば気軽に相談できる雰囲気がありました。そのため、インターン期間を通じて楽しみながら多くのことを学ぶことができ、充実した時間を過ごすことができました！<br>
<img src="https://ik.imagekit.io/plaid/6c2d4724-8115-4a53-8de3-b095626aa231/IMG_0619.jpg" alt="IMG_0619.jpg"></p>


こんにちは！8月1日からプレイドでインターンをしている櫻井絵理香です。今回のプレイドのインターンでは、Webのフロントエンド、バックエンド、インフラアーキテクチャ、そしてiOS SDKまで、超フルスタックな体験をさせていただき、自分にとって大きな挑戦となりました。普段慣れ親しんだiOS開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。 この記事では、そんな貴重な体験について詳しくお話ししたいと思います。

プレイドインターン体験記：初めてフルスタックでの開発

<h2>はじめに</h2>
<p>こんにちは！8月からの1ヶ月間サマーインターンとしてプレイドで働いていた蜂須賀大智です。個人でWebアプリケーションを開発したり、他社で少し開発経験を積んだりする中で、自身のフロントエンドの技術力をさらに高めたいという思いがありました。そんな中、サポーターズの1on1イベントでプレイドという会社を知り、面談を重ねるうちに事業の面白さに惹かれ、インターンとして働くことになりました。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。</p>
<h2>KARTE messageについて</h2>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、クライアント企業が保有するデータをもとに、メールやプッシュ通知、LINEのメッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h2>取り組んだタスク</h2>
<p>今回のサマーインターンで取り組んだタスクは、キャンペーン編集画面における未保存の変更に対する警告機能の実装です。<br>
KARTE Messageにおけるキャンペーンとは、特定のターゲットユーザーに対してメール、アプリプッシュ、LINEなどのマーケティング施策を一括で設定し、実行するための機能です。キャンペーンの設定は「配信タイプ」「対象ユーザー」「アクション」「スケジュール」　の4つの要素で構成されています。すべての設定が完了し、キャンペーンを「実行」すると、指定したチャネルを通じてクリエイティブをターゲットユーザーに届けることができます。<br>
今回、解決したかった課題は、「キャンペーンの新規作成・編集中に、入力・変更した内容を保存せずに他のページへ移動すると、その内容がすべて失われてしまうこと」　でした。</p>
<p>※以下の画像は、実装した警告機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/08d05abc-a607-4fbf-b180-ce7ba2578fbe/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2615.37.32.png" alt="変更検知"></p>
<p><img src="https://ik.imagekit.io/plaid/4a6a1e4b-265f-4252-8906-58fadf93c9dd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2615.38.46.png" alt="変更検知"></p>
<h2>実装について</h2>
<p>実装は、以下の図のようになっています。</p>
<p><img src="https://ik.imagekit.io/plaid/a4cde3d8-441d-4fc6-bdaf-08b8a272f1fb/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-08-2715.06.47.png" alt="変更検知"></p>
<h3>変更検知の基本ロジック</h3>
<p>機能の核となるのは、状態の差分検知です。初期状態と現在の状態と比較し、両者に差分が生じた場合に「未保存の変更あり」と判定する仕組みです。</p>
<h3>編集後の離脱防止アラート機能</h3>
<p>未保存の変更があるかどうかを最終的に判定する関数がtrueの場合、beforeunloadイベントでe.preventDefault()を実行します。アプリケーション内の画面遷移はVue Routerのナビゲーションガードで画面遷移時の確認ダイアログを表示されるよう制御しています。</p>
<h3>異なる画面間のデータの自動同期と偽陽性防止</h3>
<p>5秒毎に実行されるタブ間データの自動更新処理については、スナップショットも同時更新するようにしました。そして、デフォルト値の初期反映で新規作成時の偽陽性を回避しています。</p>
<h3>保存成功時の状態リセット</h3>
<p>データの保存処理において、API 呼び出しが成功したタイミングで、状態を保存後の最新の状態にリセットします。</p>
<h2>苦労したこと、工夫した点</h2>
<p>今回のタスクに対して、苦労したこと、工夫した点が多く分けて３つあります。</p>
<p>一つ目は、システム的な値の変更と、ユーザーの入力値による値の変更を切り分けるのが課題でした。サーバーに最新のデータをポーリングしにいって値が変わる実装があり、その更新をユーザーによる変更と区別する仕組みが必要だったからです。また、新規作成時にデフォルト値がセットされ、これをユーザーの入力値と誤って判定する箇所もありました。デフォルト値であれば警告が出ないように、そしてユーザーによる変更があった場合も検知できるよう実装しました。</p>
<p>二つ目は、実行時の画面遷移(配信実行中など)でも未保存の警告が出ないように工夫しました。</p>
<p>三つ目は、KARTE Messageの契約プランによって初期で入ってる値が違うところがあり、初期スナップショット(initialSnapshot)を作る時に調整することで、新規作成時の偽陽性を回避できるようにしています。</p>
<h2>インターンで得られたこと</h2>
<h3>反省点</h3>
<p>これまで、コードベースが大きく、かつ多くのユーザーに利用されているプロダクトの開発経験がなかったため、自分の変更が予期せぬデグレを引き起こさないよう、常に意識して開発に取り組んでいました。具体的には、変更検知の箇所を事前に調査してチェックリストを作成し、動作確認時にチェックしていました。プロダクトが非常に巨大であるため、どこに何が書かれているのかを特定するだけでも一苦労でした。当初想定していたよりも広範囲に影響が及ぶことに気づかず、手戻りが発生してしまったこともあります。特に今回のタスクを通して反省しているのは、分からない部分を一旦後回しにしてしまった結果、それが設計時の考慮漏れに繋がってしまった点です。</p>
<h3>学び</h3>
<p>この経験から、変更に着手する前に、関連する機能を広く深く理解し、影響範囲を正確に見極めることの重要性を痛感しました。この広大なコードベースをキャッチアップするために、AIを活用したり、ディレクトリ構造から関連コードを推測して読み進めたりと、様々な工夫をしました。自分の変更が関わる全ての機能を把握するまでには時間がかかりましたが、このインターンを通して、複雑で大規模なシステムについて慎重に開発を進める力が身についたと感じています。</p>
<h2>最後に</h2>
<p>プレイドでのインターンを終えて、一つのタスクをやったこと以外にも、チーム内の輪読会の参加<br>
や、インターンの最後にあるdemodayでの発表などたくさんの刺激があり、とても成長できたと感じていますし、楽しかったです。チームメンバーの皆さんや、一緒に開発してくれた方々をはじめ、プレイドの社員の方々、インターン生のみんな、ありがとうございました。とても充実した時間を過ごすことができました。</p>


こんにちは！8月からの1ヶ月間サマーインターンとしてプレイドで働いていた蜂須賀大智です。個人でWebアプリケーションを開発したり、他社で少し開発経験を積んだりする中で、自身のフロントエンドの技術力をさらに高めたいという思いがありました。そんな中、サポーターズの1on1イベントでプレイドという会社を知り、面談を重ねるうちに事業の面白さに惹かれ、インターンとして働くことになりました。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：一ヶ月のインターンで体験した技術と学び

<h2>Introduction</h2>
<p>I'm @kazupon from the Developer Experience team.</p>
<p>PLAID offers a product called KARTE that enables continuous improvement by providing popup dialogs to users visiting their website through campaigns, analyzing visualized user behavior, and implementing measures. We provide an editor called &quot;Flex Editor&quot; for editing these campaigns.</p>
<p>We've achieved a massive performance improvement in KARTE's no-code editor Flex Editor by accelerating action build times up to 87x, dramatically enhancing the user experience. In this post, I'll walk you through our journey of migrating from Rollup to Rolldown for server-side build optimization.</p>
<p>This article is a follow-up to our previous post:</p>
<p><a href="https://tech.plaid.co.jp/rollup-perf">How We Made Rollup Build Times 10x Faster to Improve Preview Display</a></p>
<p>Actions are applications that allow editing action templates (internally called &quot;campaign templates&quot;) through KARTE's admin panel. They're edited using &quot;Flex Editor&quot;, a no-code editor that builds JavaScript code server-side for execution as marketing campaigns on websites.</p>
<h2>The Challenge: Build Times Hurting UX</h2>
<p>When users save edited actions in Flex Editor, they're built server-side for web delivery. However, lengthy build times were causing slow server responses, forcing users to wait and degrading the overall experience.</p>
<p>According to our DataDog metrics, action-compiler build times ranged from <strong>5-10 seconds</strong>, sometimes exceeding 20 seconds.</p>
<p><img src="https://ik.imagekit.io/plaid/c1113f81-799b-4227-bb09-16658d3ffd0e/asset-builder-bad-perf.png" alt="DataDog metrics showing server-side build times ranging from 5-10 seconds"></p>
<p>The primary culprit? JavaScript-based bundlers running server-side.</p>
<p>As mentioned in our previous article, action-compiler internally uses Rollup, a JavaScript-based module bundler. Module bundling is inherently CPU-intensive. While modern JavaScript engines like V8 and SpiderMonkey can achieve near-native performance through internal optimizations, they're not ideal for CPU-heavy tasks.</p>
<p>Bundlers like Rollup, which parse massive amounts of JavaScript code and perform tree-shaking on module graphs, suffer from JavaScript's event-loop-based single-threaded architecture when it comes to CPU-intensive operations.</p>
<p>While Web Workers or Node.js worker threads (<code>node:worker_thread</code>) can provide parallelization, Rollup's architecture wasn't designed with parallel bundling optimization in mind.</p>
<p>Additionally, to maximize action performance on websites, we use Terser (a code minifier) for minification. Since minification involves static code analysis followed by compression, it adds even more CPU overhead on top of Rollup's bundling process.</p>
<h2>The Solution: Migrating to Rolldown</h2>
<p>To tackle server-side action build times, we decided to migrate from Rollup to Rolldown.</p>
<p><a href="https://rolldown.rs/">Rolldown</a> is a high-performance JavaScript bundler written in Rust with Rollup API compatibility, promising significant bundling performance improvements.</p>
<p>Rolldown addresses Rollup's performance challenges through several innovations. Bundler operations like JavaScript module parsing and module graph tree-shaking are accelerated using crates from the Oxc project and Rust-side multi-threaded parallelization.</p>
<p>While maintaining API compatibility for existing Rollup plugins, Rolldown's architecture enables plugins to run in parallel on the JavaScript side through Workers, coordinating with the Rust side.</p>
<p>At the time of writing, Rolldown is at v1.0.0 beta.32. When we evaluated migration (January 2025), we found:</p>
<ul>
<li>Core bundler implementation was nearly complete, with only edge cases and bug fixes remaining, indicating <strong>stability</strong></li>
<li>Major <a href="https://github.com/rolldown/rolldown/issues/819">Rollup plugins were compatible with Rolldown</a>, maintaining <strong>compatibility</strong></li>
<li>I <a href="https://github.com/intlify/vue-i18n/pull/2067">verified bundling behavior</a> in my OSS projects, confirming <strong>proper operation and faster bundling than Rollup</strong></li>
<li><a href="https://github.com/intlify/vue-i18n/actions/runs/12644519450">E2E tests</a> confirmed <strong>bundled JavaScript modules worked correctly</strong></li>
</ul>
<p>These factors and verification results led us to adopt Rolldown for the Flex Editor project.</p>
<h3>Migration Approach</h3>
<p>Thanks to Rolldown's Rollup API compatibility, migrating my OSS projects and packages within Flex Editor was straightforward. However, action-compiler presented unique challenges.</p>
<p>As explained in our previous article, we have two types of action-compiler:</p>
<ul>
<li>For Browser: Used for action preview functionality in Flex Editor's GUI application</li>
<li>For Server (Node.js): Used server-side to build actions for deployment as campaign applications on websites</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/a217bf9c-89f5-4ad8-84ae-1d71e26f51dd/asset-builder-action-compiler.png" alt="Architecture diagram showing action-compiler for both browser and server environments"></p>
<p>Both environments use Rollup to build actions into JavaScript code. It's a single-source package optimized for performance in each environment.</p>
<p>The browser-oriented action-compiler pre-bundles JavaScript modules that actions depend on to improve editor preview UX, as mentioned in our previous article. It even bundles Rollup itself into action-compiler for optimized build speed.</p>
<p>The server-oriented action-compiler bundles with Rollup and minifies with Terser (via Rollup plugin) to maximize action performance. Like the browser version, action-compiler itself is bundled, but unlike the browser version, it simply imports Rollup from node_modules rather than bundling Rollup into action-compiler.</p>
<p>While each environment uses Rollup appropriately with environment-specific configurations, maintaining a single source while using Rolldown only server-side required careful planning. We wanted to avoid code complexity and increased maintenance cognitive load from implementing Rolldown-specific code.</p>
<h3>Leveraging API Compatibility for Rolldown Migration</h3>
<p>We achieved server-side action-compiler Rolldown migration by leveraging API compatibility and using a bundler to rewrite Rollup imports in server-side implementation code.</p>
<p>Specifically, we implemented a Rollup plugin that replaces <code>import { rollup } from 'rollup'</code> with <code>import { rolldown as rollup } from 'rolldown'</code>.</p>
<p>This gets a bit complex, but action-compiler is a JavaScript package that compiles (bundles) actions into JavaScript code using Rollup. As mentioned, we bundle action-compiler itself for browser and server optimization. (In other words, we're bundling a bundler with a bundler!)</p>
<p>Here's the relevant excerpt from action-compiler's bundler configuration file (rolldown.config.js) - note that action-compiler's bundler is now Rolldown:</p>
<pre><code class="language-js">// ...

/**
 * Replace import syntax with rolldown when using in Node.js environment
 */
if (isNode &amp;&amp; useRolldown) {
  plugins.push({
    name: 'replace-import-syntax',
    transform(code, id) {
      if (id.endsWith('src/prod.ts') || id.endsWith('src/dev.ts')) {
        return code.replace(/import\s+{\s+rollup\s+}\s+from\s+['&quot;]rollup['&quot;]\s*;?/gm, () =&gt; {
          return `import { rolldown as rollup } from 'rolldown';`
        })
      }
    }
  })
}

// ...
</code></pre>
<p>That's it!<br>
(The implementation uses simple regex string replacement rather than AST-based static analysis since we're only transforming two files.)</p>
<p><code>isNode</code> determines if the bundle target is Node.js - <code>true</code> for Node.js (server-side), <code>false</code> for browser. <code>useRolldown</code> determines whether to use Rolldown server-side - <code>true</code> uses Rolldown, <code>false</code> continues using Rollup.</p>
<p>When both <code>isNode</code> and <code>useRolldown</code> are <code>true</code>, the bundler registers a plugin that rewrites <code>import { rollup } from 'rollup'</code> to <code>import { rolldown as rollup } from 'rolldown'</code> in action-compiler's code.</p>
<p>By setting these flags appropriately (both <code>true</code>) when bundling action-compiler for server use, the code is transformed to use Rolldown. Using the bundler eliminated the need for Rolldown-specific code in action-compiler itself.</p>
<h2>Rolldown Server-Side Build Performance</h2>
<p>With Rollup successfully replaced by Rolldown in server-side action-compiler, we measured build performance using the following configurations and environment.</p>
<h3>Metrics</h3>
<ol>
<li>Rollup<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> (no minification)</li>
<li>Rolldown<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup> (no minification)</li>
<li>Rollup + Terser (<code>@rollup/plugin-terser</code><sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>)</li>
<li>Rolldown + SWC (<code>rollup-plugin-swc3</code><sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup>)</li>
<li>Rolldown + built-in minifier (<code>oxc-minify</code><sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup>)</li>
</ol>
<p>For comparison, we included cases without minification and the Rollup + Terser combination. Since <code>oxc-minify</code> was in WIP status during our implementation and might not function correctly for actions in the Flex Editor beta production environment, we also measured performance with Terser and SWC available as Rollup plugins.</p>
<h3>Environment</h3>
<p>Performance measurements were conducted on:</p>
<ul>
<li>Machine specs:
<ul>
<li>Model: MacBook Pro 14-inch, 2021</li>
<li>Chipset: Apple M1 Max</li>
<li>Memory: 64GB</li>
</ul>
</li>
</ul>
<p>The action structure for build performance testing:</p>
<ul>
<li>Build target action structure:
<ul>
<li>index.tsx</li>
<li>App.svelte</li>
<li>gen.ts</li>
<li>customScript.ts</li>
<li>karte-template.json</li>
<li>props.json</li>
<li>variablesQuery.json</li>
<li>localVariablesQuery.json</li>
</ul>
</li>
</ul>
<p>The action UI represents a campaign like this:</p>
<p><img src="https://ik.imagekit.io/plaid/a7f21d69-6f5b-45d6-a980-3b1a0e31ae0e/asset-builder-target-action.png" alt="Example campaign UI created with the action in Flex Editor"></p>
<p>While we'll skip the detailed file contents, when editing and saving in the editor, action file code is serialized into JSON with this structure and sent server-side for building:</p>
<p><img src="https://ik.imagekit.io/plaid/1c02f655-95ec-4206-8822-4cff3a4821b2/asset-builder-action-codes.webp" alt="JSON structure showing serialized action file codes sent to server for building"></p>
<p>For these performance measurements, we used server-oriented action-compiler to build this action code.</p>
<h2>Build Performance Results</h2>
<p>Here are our performance measurement results:</p>
<h3>Build Times</h3>
<table>
<thead>
<tr>
<th>Configuration</th>
<th>Max Build Time</th>
<th>Min Build Time</th>
<th>Average Build Time</th>
</tr>
</thead>
<tbody>
<tr>
<td>Rollup (no minification)</td>
<td><strong>560.596119 ms</strong></td>
<td>205.13774 ms</td>
<td>236.0695421 ms</td>
</tr>
<tr>
<td>Rolldown (no minification)</td>
<td>112.801283 ms</td>
<td><strong>23.01124 ms</strong></td>
<td>33.42461761 ms</td>
</tr>
<tr>
<td>Rollup + Terser (<code>@rollup/plugin-terser</code>)</td>
<td><strong>2424.394387 ms</strong></td>
<td>959.403731 ms</td>
<td>1149.732976 ms</td>
</tr>
<tr>
<td>Rolldown + SWC (<code>rollup-plugin-swc3</code>)</td>
<td>235.093658 ms</td>
<td>106.845099 ms</td>
<td>125.2551525 ms</td>
</tr>
<tr>
<td>Rolldown + built-in (<code>oxc-minify</code>)</td>
<td>143.829239 ms</td>
<td><strong>28.230994 ms</strong></td>
<td>40.44968284 ms</td>
</tr>
</tbody>
</table>
<p>Without minification, Rolldown clearly outperforms Rollup. Comparing Rolldown's minimum build time to Rollup's maximum shows approximately 24x improvement, with an average 9x performance boost. These results confirm Rolldown's acceleration benefits for action builds.</p>
<p>With minification, Rolldown builds still outperform Rollup + Terser. Comparing Rolldown + SWC's minimum build time to Rollup + Terser's maximum shows about 23x improvement, averaging 9x faster. With Rolldown's built-in minifier, we achieved an incredible <strong>87x</strong> improvement at minimum and <strong>29x</strong> on average.</p>
<p>These results demonstrate that while the SWC minifier via <code>rollup-plugin-swc3</code> provides acceleration, using Rolldown's built-in <code>oxc-minifier</code> delivers overwhelming build performance gains.<sup class="footnote-ref"><a href="#fn6" id="fnref6">[6]</a></sup></p>
<h3>File Sizes</h3>
<table>
<thead>
<tr>
<th>Configuration</th>
<th>Minified Size</th>
<th>Gzipped Size</th>
</tr>
</thead>
<tbody>
<tr>
<td>Rollup + Terser</td>
<td>92.15 kb</td>
<td>31.38 kb</td>
</tr>
<tr>
<td>Rolldown + SWC</td>
<td>114.73 kb</td>
<td>39.11 kb</td>
</tr>
<tr>
<td>Rolldown + built-in minifier</td>
<td>122.09 kb</td>
<td>40.35 kb</td>
</tr>
</tbody>
</table>
<p>File size results revealed interesting insights for action builds.</p>
<p>Various Rolldown minification configurations resulted in approximately 20-25% larger bundle sizes compared to Rollup + Terser. This is because Svelte runtime code used by actions is pre-bundled with Rolldown during action-compiler bundling.</p>
<p>Rolldown's built-in minifier <code>oxc-minify</code> has <a href="https://github.com/vitejs/rolldown-vite/issues/155#issuecomment-2856998564">several open issues</a> regarding minification optimization. Our analysis of the built code confirmed issues matching these reported problems.</p>
<p>The reason for pre-bundling Svelte runtime code is to accelerate Flex Editor preview display, as explained in our previous article.</p>
<p>Comparing minification performance between SWC (<code>rollup-plugin-swc3</code>) and <code>oxc-minify</code>, SWC showed higher compression rates.</p>
<h2>Trade-offs with Rolldown Adoption</h2>
<p>Performance measurements of Rolldown-powered server-side action-compiler showed build times exceeded expectations, while bundled action JavaScript file sizes increased 20-27% compared to Rollup + Terser.</p>
<p>Our goal was to accelerate server-side action build times and improve the save experience in Flex Editor. After team discussion, we decided to adopt Rolldown with its built-in minifier (<code>oxc-minifier</code>) for server-side build acceleration.</p>
<p>The trade-off: JavaScript action files delivered will be larger than Rollup-bundled versions. However, new actions from Flex Editor have been reduced to 1/10th the size of current production actions through architecture renewal. Server-side build acceleration with Rolldown not only improves DX through reduced server infrastructure costs but also enhances end-user UX when saving in Flex Editor. The dual benefits of DX and UX improvements drove our decision to adopt Rolldown with built-in <code>oxc-minifier</code>.</p>
<h2>Production Build Performance</h2>
<p>At the time of writing, we've deployed Rolldown-powered server-side action-compiler to production as a beta for select customers using Flex Editor. We continuously monitor server-side action-compiler performance with DataDog. Here's the graph after introducing Rolldown-powered action-compiler to production:</p>
<p><img src="https://ik.imagekit.io/plaid/8d78539a-e84b-475b-8447-90b789e8c97f/asset-builder-rolldown.png" alt="DataDog graph showing dramatic reduction in build times after Rolldown deployment"></p>
<p>In production, the system runs in a Kubernetes (k8s) container environment. Pre-migration action-compiler build times of 5-10 seconds have dramatically reduced to hundreds of milliseconds. The accelerated server-side build times when editing and saving actions in Flex Editor result in faster server responses and noticeably improved editor UX.</p>
<h2>Future Outlook</h2>
<h3>Towards Rolldown's Official Release</h3>
<p>While Flex Editor currently uses Rolldown beta, we'll continue updating toward the official release. We hope the file size issues mentioned earlier will be resolved by Rolldown's official release. Vite is also progressing with Rolldown integration through <a href="https://github.com/vitejs/rolldown-vite">rolldown-vite</a>, and we've verified <a href="https://voidzero.dev/posts/announcing-rolldown-vite#real-world-impact">up to 16x acceleration</a> in the Flex Editor project.</p>
<h3>Technical Future Prospects</h3>
<p>With Rolldown adoption, we've dramatically improved build time challenges. Our next step involves exploring AST-based editor generalization. While currently using Svelte-based AST, we're considering migration to Vapor's AST/IR base using <a href="https://github.com/kazupon/inclusion-vapor">inclusion-vapor</a> and expansion to other products.</p>
<h2>Conclusion</h2>
<p>This article detailed our journey migrating from Rollup to Rolldown, dramatically improving server-side build times and enhancing product UX.</p>
<p>Despite being in beta, Rolldown's core functionality is nearly complete and ready for production use. JavaScript/TypeScript projects can especially benefit from significant build time reductions, improving DX and accelerating CI/CD deployment cycles.</p>
<p>I hope this article inspires you to consider Rolldown for your own projects.</p>
<p>If you're interested in working on projects while contributing to OSS, please check out our <a href="https://recruit.plaid.co.jp/product">careers page</a>.</p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>v4.35.0 <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p>v1.0.0-beta.32 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p>v0.4.4 <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>v0.12.1, using minify feature <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p>Minifier provided by the oxc project <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn6" class="footnote-item"><p>This performance measurement compares only SWC and Rolldown's minifier under Rolldown. As shown in various <a href="https://github.com/privatenumber/minification-benchmarks">minification benchmarks</a>, performance varies depending on the code being minified. <a href="#fnref6" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


We've achieved a massive performance improvement in KARTE's no-code editor "Flex Editor" by accelerating action build times up to 87x, dramatically enhancing the user experience. In this post, I'll walk you through our journey of migrating from Rollup to Rolldown for server-side build optimization.

Achieving 87x Faster Server-Side Action Builds: Migrating from Rollup to Rolldown

<p>こんにちは。プレイドの野田(<a href="https://twitter.com/positiveflat">@positiveflat</a>)です。<br>
弊社株式会社プレイドでは、ウェブ接客プラットフォームの<a href="https://karte.io/">KARTE</a>というサービスを開発・提供しています。今回は、私たちのチームの開発方針に触れ、その方針を実現するための取り組みの一部として行っている、我々の製品の品質を維持するGUIテストの仕組みについてご紹介いたします。</p>
<h2>目次</h2>
<ul>
<li>プレイドの開発方針とGUIテストの位置付け</li>
<li>GUIテストの自動化が進むにつれて起こる問題</li>
<li>CircleCI上でのテストの並列実行による総実行時間の短縮</li>
<li>CircleCI Enterpriseの導入によるテストの高速化</li>
<li>Ghost Inspectorを使ったGUIテストスクリプト開発の高速化</li>
<li>課題</li>
<li>最後に</li>
</ul>
<h2>プレイドの開発方針とGUIテストの位置付け</h2>
<p>弊社の開発チームでは、以下の方針のもと、フラットな組織でスピード感のある開発を目指しています。</p>
<ul>
<li>全員が自分で判断する</li>
<li>全員がゼロベースで考える</li>
<li>全員が成長する</li>
</ul>
<p>これらの実現のために、あえてマネジメントを置かずに自由でフラットなチーム体制で開発を行っています。</p>
<p>スピードを重視したまま各メンバーが自走するには、失敗を許容し、トライアンドエラーを許容する文化が必要であると考えています。とにかく試してみて、失敗したら考え直します。</p>
<p>一方で、お客様に安心して使っていただくために、当然品質は担保しなければなりません。KARTEは現在、大企業から中小企業、地方の商店まで、多数のお客様に導入いただいております。</p>
<p>私たちは日々KARTEの新機能の追加や既存機能の改善を行っており、ほぼ毎日本番環境に変更を反映させています。</p>
<p>本番環境に反映させた変更に問題があると、直接お客様の業務に影響を与える可能性があります。また、接客サービスの配信に関わる箇所に関しては、お客様のサイトを閲覧している来訪者にも正しく接客ができなくなる可能性があります。</p>
<p>ユーザーに安定的にサービスを提供し、一方で開発のスピードを高速化するためには、トライアンドエラーのサイクルの中に品質を保証する仕組みを導入していく必要があります。</p>
<p>そこで、我々は重要なシナリオに関してはGUIテストの自動化を行い、正しくアプリケーションの操作が行えることを自動でテストできるような仕組みを作っています。</p>
<h2>GUIテストの自動化が進むにつれて起こる問題</h2>
<p>日々の開発の中で、追加した変更が生む欠陥をできるだけ早期に発見できるようにするために、リモートブランチに変更がpushされる度にCIツールのプロセスが回り、ユニットテスト（UT）や自動化されたGUIテストが流れるようにしています。</p>
<p>ちなみに、GUIテストはSelenium webdriverを使用してテストスクリプトを書いています。リリース時にはCircleCI上でproduction buildを作成したりもしていますが、これについての説明は本記事の主題と外れるので割愛します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eba4a7e4-148a-4033-8ab6-6e3a02ecfff2/flow-1.png" alt=""></p>
<p>自動化されたGUIテストを流すことには、以下のようなメリットがあります。</p>
<ul>
<li>人手よりも短時間でテストを実行することができる</li>
<li>人手では気が付きにくいバグも発見することができる</li>
<li>regressionの早期発見ができる</li>
</ul>
<p>一方で、GUIテストの自動化が進むにつれて、以下のような問題も起きます。</p>
<ul>
<li>テストコードが長くなると、テストを流すのに時間がかかり、テスト待ちが起きる</li>
<li>UIを変更した際に、テストコードのメンテナンスに時間がかかる</li>
</ul>
<p>弊社では、上記の課題を解決するために、様々な取り組みをしてきましたので、ここからはその取り組みを紹介します。</p>
<h2>CircleCI上でのテストの並列実行による総実行時間の短縮</h2>
<p>弊社では、上でも触れたように、githubのブランチへのpushごとにCircleCIのプロセスが走るようにしています。その中でGUIテストとUTが流れ、そのブランチを紐付けたPull Request上にテストの結果を表示して、レビュー前に確認できるようにしています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/045c0a75-c978-42fa-974a-191da5603361/CIProcess-1.png" alt=""></p>
<p>CircleCIの並列化は、CircleCIの管理画面でコンテナ数を増やした後に、circle.ymlで並列実行したいコマンドに以下のようにオプションを渡すだけで簡単にできます。</p>
<pre><code class="language-yml">test:
    override:
        [並列実行したいコマンド]:
           parallel: true
</code></pre>
<p>(参考: https://circleci.com/docs/parallel-manual-setup/ )</p>
<h2>CircleCI Enterpriseの導入によるテストの高速化</h2>
<p>テストやビルド、デプロイのためのCIツールとして、<a href="https://circleci.com/enterprise/">CircleCI Enterprise</a>を使用しています。当初はCircleCIのコンテナ数ごとの課金の通常プランを使用していましたが、テストの実行時間に課題がありました。</p>
<p><a href="https://codeship.com/">codeship</a>や<a href="https://travis-ci.org/">Travis CI</a>などの他のCIツールも試してみましたが、現在はマシンスペックをコントロールすることができるCircleCI Enterpriseを導入しています。</p>
<p>CircleCI Enterpriseですと、コンテナは独自にインスタンスを立てて管理する必要がありますが、pushが少ない深夜はインスタンス数を減らすなど、独自に工夫して管理しています。</p>
<h2>Ghost Inspectorを使ったGUIテストスクリプト開発の高速化</h2>
<p>新しい機能が頻繁に追加されたり、既存の機能が頻繁にアップデートされたりすると、更新すべきGUIテストのスクリプトが多くなり、更新が追いつかなくなります。</p>
<p>そこで、Ghost Inspectorというサービスを使い、テストスクリプト作成を簡易化する取り組みにもチャレンジしています。Ghost InspectorはSelenium IDEベースのウェブサービスで、実際の画面操作をレコーディングして、テストケースに落とし込むことができます。</p>
<p>Ghost Inspectorでは、下図のようにChromeの拡張機能を使ってレコーディングをスタートすることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/da4a6914-c5dc-4801-8574-5d4a589bf0f7/GI1-2.png" alt=""></p>
<p>レコーディングしたテストはAPI経由で実行可能なので、CircleCIなどのCIツールからも呼び出すことが可能です。  また、テスト結果はビデオで録画されているため、テストが失敗した場合はどこでテストが失敗したかを確認することができます。</p>
<p>ただし、CircleCIで使用しているインスタンスはプライベートネットワーク上にあるため、Ghost Inspectorからそのままアクセスすることはできません。</p>
<p>通常プランのCircleCIのインスタンスを使用する場合は、<a href="https://ngrok.com/">ngrok</a>などを利用してトンネルを掘り、外からアクセスを可能にする方法が便利です。CircleCIから実行する場合のcircle.ymlは、大まかに以下のようになります。</p>
<pre><code class="language-yml">test:
  override:
    - [環境変数の設定やビルドの設定コマンド];
    - [KARTE(テスト対象サービス)の起動コマンド];
          background: true
    - npm install ngrok -g #ngrokのインストール
    - ngrok authtoken &lt;auth_token&gt; #authtokenの設定
    - ngrok http -subdomain=&lt;testhostname&gt; 8020;
          background: true
    - sleep 120
    - curl &quot;https://api.ghostinspector.com/v1/suites/&lt;suite name&gt;/execute/?apiKey=&lt;api_key&gt;&amp;startUrl=https://&lt;testhostname&gt;.ngrok.io/&quot; &gt; ghostinspector.json
    - if [ $(grep -c '&quot;passing&quot;:false' ghostinspector.json) -ne 0 ]; then exit 1; fi
      fi
</code></pre>
<p>このサービスの便利なところは、レコーディングを使ってテストを追加するGUI操作ができれば誰でもテストを作ることができるようになるところです（ただし、実際はUIの更新の待ち時間の調整など、微調整が必要でした。）。</p>
<p>最終的にはテストコードを書いた方が良い場合でも、新しい機能や変更があった機能に対してGUIのテストをまず早い段階で用意しておくことは、回帰テストとしては有効だと考えられます。</p>
<h2>課題</h2>
<p>以上のように、プレイドでは攻めの開発方針を実現するために、CIによるテストの自動化など様々なことに取り組んでおります。</p>
<p>しかし、テストカバレッジは今後も上げていかなければならないですし、それと共にテストの実行時間は長くなるので、依然として課題は残ります。レコーディングによるテスト自動化も、レコーディング後に継続的に実行できるように微調整が必要なため、なかなかうまくフローに組み込めないなどの課題もあります。</p>
<p>今後もこれらの課題の解決の解決に取り組みつつ、開発方針を維持できるような仕組みづくりをしていきたいと考えています。</p>
<h2>最後に</h2>
<p>テスト自動化に関しては、この他にもPCやスマートフォンなどの複数端末上でのテストを自動化し、並列実行する取り組みなども行っていますが、それについても後日このブログで紹介させていただきます。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</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>


スピード重視の開発体制を実現するために、KARTEの開発で取り組んでいるテスト自動化について紹介します。Selenium webdriver, CircleCI, Ghost Inspector

スピード重視の開発体制を実現するためのUIテスト自動化 | PLAID engineer blog

スピード重視の開発体制を実現するためのUIテスト自動化

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b1a2c506-1fcb-4018-910c-f4b365481cf1/80eb8949-86ff-4ffd-a522-c5fb93ff2926.jpg" alt="DSC00055.jpg (1.4 MB)"></p>
<p>本日は8/3(水) に開催しました「【FiNC×プレイド】Machine Learning Meetup #1」のレポートをお届けしたいと思います！<br>
機械学習を用いた画像認識の話、チャットBotの話等、面白い内容でした！</p>
<h2>発表内容</h2>
<ul>
<li>食事指導を機械学習技術で助ける話 (FiNC 小林さん)</li>
<li>ちゃんと使えるBotについて考える (プレイド CTO 柴山)</li>
<li>いまさら聞けない機械学習の評価指標 (dr_paradi さん)</li>
<li>データマイニングやってて思うこと (おおとや さん)</li>
</ul>
<h2>食事指導を機械学習技術で助ける話</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f98743bb-41f3-4d72-9645-8c34d8558cf8/9d316b23-3cda-4231-adef-862ccc5a06d9.jpg" alt="DSC00030.jpg (895.4 kB)"></p>
<p>まずFiNC 小林さんから「食事指導を機械学習技術で助ける話」についてお話頂きました。<br>
FiNCさんでは機械学習に力を入れておられ、<a href="http://www.nikkei.com/article/DGKKZO06187280X10C16A8TI5000/">ＡＩ特化の研究所を新設</a>されるそうです！</p>
<div style="width: 100%;">
<script async class="speakerdeck-embed" data-id="287f253add1f423496e837716ddf9d48" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>FiNCさんは、アプリを通じてダイエットのマンツーマン指導を受けることができるサービスを提供されています。その中で、機械学習を用いてユーザーが送った食事の写真の内容を自動で認識したり、食事の内容の偏りや睡眠、体重の時系列変化に異常があったりした際に自動でそれを検知するという取り組みをされているそうです。</p>
<p>どのような食べ物が写っているかに関しては、畳み込みニューラルネットワーク(CNN; Convolutional Neural Network)を用いて行っているそうです。また、Faster R-CNN; Faster Regions with Convolutional Neural Networkを用いて一つの写真の中に何種類の食べ物が写っているかを認識させ、食事内容をより高度に認識させることを検討されているそうです。</p>
<p>今後はさらに、Mechanical Turkを使って教師データを作成したり、自動で食事指導の文書を生成することも視野に入れられているとのことでした。</p>
<p>近年フィットネストラッカー等で日々の生活の記録を取ることができますが、健康を考える上で重要な食事の記録を、写真を撮影するだけで行えるようになれば便利そうですね！</p>
<h2>ちゃんと使えるBotについて考える</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/720be3c5-d846-47f5-8bbb-96bb8a926bd4/8d8f51e5-35e5-4e80-b116-7c52e5a854f1.jpg" alt="DSC00048.jpg (1.3 MB)"></p>
<p>次にプレイドCTOの柴山から「ちゃんと使えるBotについて考える」についての発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="a86a7e669718491db72207aa96633c11" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>Botを使ってコミュニケーションさせようとすると、大量のデータが必要になってきます。<br>
しかし、シナリオ/ビジネスロジックを覚えるには現状ではデータが足りないので、先人たちのアプローチとしては下記をとっているとのことでした。</p>
<ul>
<li>シナリオベース(Google/Facebook/Softbank/Apple)</li>
<li>自然言語から定型化されたクエリにして処理 (Google/Facebook)</li>
<li>Outputは定型化したUI(Google)
<ul>
<li>検索結果</li>
</ul>
</li>
<li>対応できなかった時の次善策(Facebook/Google)
<ul>
<li>人が対応する等</li>
</ul>
</li>
</ul>
<p>こう考えてみると結局検索の延長線上でしか、Botを活かしきれていないことがわかります。</p>
<p>柴山の持論だと、このような定型化された作業の中で最もシステムがレバレッジを効かせられる部分はDBだとのことです。</p>
<p>ですので、Botのストロングポイントである、<code>検索/DB</code> を活かして一次回答をしながら、拾えないところは人間が返すという形がわかりやすいのではないかとのことです。</p>
<p>一次回答でBotが解釈できるシナリオを拡大するのに <a href="http://superscriptjs.com/">superscritpt</a>が面白そうなので興味のある方は見てみてはいかがでしょうか！</p>
<h2>いまさら聞けない機械学習の評価指標</h2>
<p>続いて <a href="https://twitter.com/dr_paradi">@dr_paradi</a>さんから「いまさら聞けない機械学習の評価指標 」についてお話頂きました。</p>
<p><strong> <a href="//www.slideshare.net/keisukeosone/ss-64685474" title="いまさら聞けない機械学習の評価指標" target="_blank">いまさら聞けない機械学習の評価指標</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/keisukeosone">圭輔 大曽根</a></strong></p>
<iframe src="////www.slideshare.net/slideshow/embed_code/key/um9FdtijcinP9B" width="100%" height="533" 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">  </div>
<p>最近は機械学習が流行り周辺ツールやライブラリ、データが充実してきており、機械学習を試しやすくなっている一方で「どのような指標を設定すればよいか」「指標を評価する関数をどう選ぶか」がポイントになってきています。</p>
<p><a href="https://twitter.com/dr_paradi">@dr_paradi</a>さんの発表では、代表的な評価関数を説明してくださいました！</p>
<p><a href="http://data.gunosy.io/entry/2016/08/05/115345">Gunosyデータ分析ブログ</a>に詳しい説明を書いてくださっていますので興味のある方はぜひ御覧ください！</p>
<h2>データマイニングやってて思うこと</h2>
<p>最後におおとやさんから「データマイニングやってて思うこと」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="07f6770726dd4f24836ddfb65c369684" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>機械学習のツールを盲目的に信じてデータ解析しても意味がなく、「解析の目的」「データの種類」「データの分布」「解析方法」をしっかり考えてPDCAサイクルをまわしながらデータ解析をしていこうというお話でした！</p>
<h2>次回</h2>
<p>次回は<strong>9月下旬</strong>にFiNCさんのオフィスで**【FiNC×プレイド】Machine Learning Meetup #2**を開催します！<br>
<a href="http://plaidtech.connpass.com/">Connpass</a>でイベントの募集を行いますので、ご興味のある方は是非ご参加ください！</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。<br>
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！</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>


機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました！

機械学習&チャットBotについて語る！【FiNC×プレイド】機械学習の勉強会を開催しました！| PLAID engineer blog

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

Service Workerの全体像の解説と、それがもたらすWebの未来を考察します。今後の動向を左右しそうなService worker meeting notesについても解説します。

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来 | PLAID Engineer Blog 

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

<p>こんにちは、プレイドの@wikrshです。</p>
<p>プレイドが提供している<a href="https://karte.io/">KARTE</a>では、サイトに来訪するユーザに応じて様々な接客アクションを行う機能を提供しています。</p>
<p>接客アクションのようなウェブサイト上の施作の効果を検証する方法としてはA/Bテストが有名だと思いますが、今回のエントリーではA/Bテスト以外の手法としてバンディットアルゴリズムをざっくりと紹介したいと思います。</p>
<h3>A/Bテストとバンディットアルゴリズム</h3>
<p>バンディットアルゴリズムは、いくつかの施作を実験しながら実験中に得られる効果もできるだけ大きくしたい、という目的のためのアルゴリズムです。</p>
<p>例えばECサイトの商品画像としてAとBの2つの画像の内どちらを表示した方が購入確率が上がるかということを知りたい場合、ユーザによって画像をランダムに表示してどちらの画像を表示した方が購入確率が高いか(もしくは有意差がないか)を検証しますが、ある画像を表示した方が購入確率が高いのであればできるだけ多くその画像を表示した方が全体の購入確率は高くなります。</p>
<p>A/Bテストでは十分なサンプル数を集めるまであらかじめ決めた割合(例えば1:1)でランダムに表示することを繰り返すため劣っている案も一定数表示することが必要となりますが、劣っている案を表示することは結果的に（優れた案を表示するのと比較して）コストを払っているとも考えられます。<br>
バンディットアルゴリズムで対象としている問題はこのコストを小さくすることであり、その時点までに得られた結果の利用の仕方・次の案の表示のさせ方のアルゴリズムになっています。</p>
<h3>Epsilon-Greedyアルゴリズム</h3>
<p>ここでは具体的なアルゴリズムの例として、Epsilon-Greedyアルゴリズムを紹介します。</p>
<p>Epsilon-Greedyアルゴリズムは単純な動作のアルゴリズムになっていて以下のような動作となります。</p>
<ul>
<li>ある割合(0 &lt; ε &lt; 1)で選択肢からランダムに選択する</li>
<li>1-εの割合でこれまでの結果が最も良い選択肢を選択する</li>
</ul>
<p>例えばε=0.3とした場合、先の画像の例では以下のような動作となります。</p>
<ul>
<li>画像A、Bをそれぞれ15%ずつの割合で表示</li>
<li>残り70%はその時点での結果が良い画像を表示</li>
</ul>
<p>各画像は最低でも15%の確率で表示されるため、十分な回数繰り返せば各選択肢の効果を検証することが可能です。<br>
また、70%はその時点で最も良い結果の画像を表示するため、優れた案（最適な案）が正しく選択されれば全体の結果も向上する可能性があります。</p>
<p>このアルゴリズムについて簡易的な実装をしたのが以下のコードです。</p>
<pre><code class="language-coffeescript">_ = require 'lodash'

class EpsilonGreedyAlgorithm
  # @params {Number} nChoices 選択肢の数
  # @params {Number} epsilon ランダムに選択を行う割合
  constructor: (@nChoices, @epsilon) -&gt;
    @initialize()

  initialize: -&gt;
    @averages = _.fill Array(@nChoices), 0 # 選択肢ごとの得られた結果の平均値
    @counts = _.fill Array(@nChoices), 0 # 選択肢ごとの選択回数
    @nBest = 0 # 現状の最良の選択肢

  # 選択肢から一つ選択する
  select: () -&gt;
    if Math.random() &lt; @epsilon
      # 全ての選択肢からランダムに選択
      return Math.floor(Math.random() * @nChoices)
    else
      # その時点で最も良い結果の選択肢を選択
      return @nBest

  # 結果を受け取って状態を更新する
  # @params {Number} n 選択肢の番号(0..nChoices-1)
  # @params {Number} reward 得られた結果(報酬)
  update: (n, reward) -&gt;
    @counts[n] += 1
    c = @counts[n]
    @averages[n] = ((c - 1) / c) * @averages[n] + (reward / c)

    @nBest = n if @averages[n] &gt; @averages[@nBest]
</code></pre>
<p>バンディットアルゴリズムはその時点の結果を元にいずれかの選択肢を選択するという動作となっているため、結果を受け取るためのメソッド(コード上の<code>update()</code>)と選択したものを返すメソッド(コード上の<code>select()</code>)を実装しています。</p>
<p>以下のような形で動作します。（A案を0、B案を1としています。）</p>
<pre><code class="language-coffeescript"># A案,B案の2つのみ、e = 0.3
ega = new EpsilonGreedyAlgorithm 2, 0.3
ega.select() # =&gt; 1 (B案を選択)
... # B案を表示して結果(例えばユーザが購入したかどうか)を得る
ega.update(1, 1) # B案を選択した結果、ユーザが購入を行った
ega.select() # =&gt; 0 (A案を選択)
... # A案を表示...
</code></pre>
<h3>動作の検証</h3>
<p>バンディットアルゴリズムでは選んだ選択肢に対するフィードバックを受けて次の動作が決まっていくため、動作の検証のためにはシミュレーションが必要となります。</p>
<p>ここでは<a href="http://www.oreilly.co.jp/books/9784873116273/">「バンディットアルゴリズムによる最適化手法」</a>を参考に、一回の試行の結果はランダムに決定し、シミュレーションを繰り返すことで動作を検証するという形でどのような動作になるのかを見ていきたいと思います。</p>
<p>例えばあるA案、B案の2つをコンバージョンレートで比較したい場合は、ある一回の試行の結果を0（コンバージョンしなかった）、1（コンバージョンした）で表すことでシミュレーションが行えます。</p>
<pre><code class="language-coffeescript">class ConversionSimulator
  constructor: (@cvr) -&gt;

  # 設定したコンバージョンレートでランダムに0 or 1の結果を返す
  get_result: () -&gt;
    if Math.random() &lt; @cvr
      return 1
    else
      return 0
</code></pre>
<p>コンバージョンレートではなく購入金額で比較したい場合は、0/1ではなく購入金額を返すようにすればよさそうです。</p>
<pre><code class="language-coffeescript">class PurchasePriceSimulator
  constructor: (@cvr, @minPrice, @maxPrice) -&gt;

  get_result: () -&gt;
    if Math.random() &lt; @cvr
      return _.random @minPrice, @maxPrice
    else
      return 0
</code></pre>
<p>コンバージョンレートでの比較を行う場合のシミュレーションとして、A案を提示した場合は5%のCVR、B案を提示した場合は10%のCVRが得られる状況のシミュレーションを行ってみます。</p>
<pre><code class="language-coffeescript"># A案は5%のCVR、B案は10%のCVR
cvrs = [0.05, 0.10]
choices = cvrs.map (cvr) -&gt;
  new ConversionSimulator(cvr)

algo = new EpsilonGreedyAlgorithm 2, 0.3
algo.initialize()

# 1000回A/B案の選択・提示を繰り返す
results = _.times 1000, -&gt;
  n = algo.select()
  reward = choices[n].get_result()
  algo.update(n, reward)
  return n
</code></pre>
<p>このシミュレーションを1000回繰り返して、最適な案（B案)を提示した割合をプロットした結果が下の図です。（ε=0.3）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/75d53380-c2f0-4cb4-80a9-bdc0130e0eda/test-1.png" alt=""></p>
<p>コンバージョンレートの低いA案を最適と予想して始めているため、始めの方は最適な案を選んだ割合は低いですが、回数を増すごとに最適な案を選ぶ割合が増加していることがわかると思います。<br>
一方でEpsilon-Greedyアルゴリズムでは一定の割合でランダムに案を選びに行くため、回数が増加しても最適な手を選ぶ割合は85%付近で収束しています。</p>
<h3>その他の方法</h3>
<p>バンディットアルゴリズムは上で紹介したEpsilon-Greedyアルゴリズム以外にも多種多様なものが提案されており、詳細については割愛しますが代表的なものには</p>
<ul>
<li>Softmaxアルゴリズム</li>
<li>UCBアルゴリズム</li>
<li>Randomized Probability Matching</li>
</ul>
<p>などがあります。<br>
Epsilon-Greedyアルゴリズムよりは探索・活用を単純な動作で行っていますが、これらのアルゴリズムはこれまでの結果から優位性の程度を算出して探索・活用を行ったり、サンプル数の増加に合わせて活用の割合を下げていくなどの工夫が入っています。<br>
また、Epsilon-Greedyアルゴリズムのεのようなパラメータを試行回数に応じて切り替えていくことで、最適な案に最終的に収束させるような方法もあります。</p>
<h3>所感</h3>
<p>バンディットアルゴリズムはA/Bテストと比較して魅力的な点がある反面、<br>
実際の導入時に考慮する必要がある点は多いと感じました。<br>
今回はバンディットアルゴリズムの中でも最も単純なEpsilon-Greedyアルゴリズムを紹介しましたが、実際に導入する場合は</p>
<ul>
<li>結果として使用する値（コンバージョンや購入金額等）に対してどのような動作になるか</li>
<li>パフォーマンスの面から逐次更新ではなくバッチ更新とした場合にはどのような挙動となるか</li>
<li>パラメータの設定やテスト期間をどのように設定するか</li>
</ul>
<p>などを検討していく必要があると思います。<br>
バッチでの更新方法については実際の導入例もあるようですので、今後はこの辺りを検討していきたいと思います。</p>
<h3>最後に</h3>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。<br>
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！</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>


今回のエントリーではA/Bテスト以外の手法としてバンディットアルゴリズムをざっくりと紹介したいと思います。

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた / PLAID Engineer  Blog

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

<p>こんにちは！プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>7/5(火)に<a href="http://plaidtech.connpass.com/event/33511/">【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 </a>を開催しました！</p>
<img width="100%" alt="DSC09468.JPG (2.1 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fc9574b8-7728-4ae0-8e17-9586da3f4a38/79d8af47-57eb-4b5f-a566-f4b5f117b497.JPG.jpg">
<h2>TechBlog Deep Dive Meetup とは</h2>
<p>色々な会社で書かれているTechBlogの人気記事の内容を深掘りしていく勉強会です！</p>
<p>実際にブログを書いたエンジニアに登壇してもらい、記事の内容+α(ブログに書ききれなかったこと、ブログを書いた後に行ったこと等)を発表してもらいます。</p>
<p>今回は、<a href="https://toreta.in/jp/">トレタ</a>さんと一緒に開催させていただきました！</p>
<p>トレタさんからは、<a href="http://tech.toreta.in/entry/2016/06/16/114919">EngineyardからAWSに移設してAuroraの運用を開始した</a>や<a href="http://tech.toreta.in/entry/2016/04/14/143248">トレタのインフラ運用、支えている道具(Packer, Terraform, Serverspec, Ansible, Roadworker, Circle CI)、考え方</a>を書かれた佐野氏に登壇して頂きました。</p>
<p>プレイドからは、<a href="http://tech.plaid.co.jp/autoscaling-ec2/">1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン</a>を書いた@tik-son が登壇しました。</p>
<img width="100%" alt="DSC09506.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8c104bf9-0e02-4714-8bdd-d25e4cbda26c/78916cc8-85a5-4c44-b80e-b7741cc565a2.JPG.jpg">
<ul>
<li><a href="http://tech.toreta.in/">トレタ開発者ブログ</a></li>
<li><a href="http://tech.plaid.co.jp/">PLAID TechBlog</a></li>
</ul>
<h2>発表内容</h2>
<h3>トレタのインフラ運用</h3>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/e3b4f649-f78c-43af-9fb5-38628244bf99/fc540804-45bb-425c-a2c2-1450070b8c29.JPG.webp" alt="fc540804-45bb-425c-a2c2-1450070b8c29.JPG.webp"></p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="14b8185b93b947d8891888a9b7323372" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>トレタのインフラ運用について具体的に「どのようなツールを使って」「どのように運用しているか」を話していただきました。</p>
<p>Terraform, Packer, Ansible等、導入理由と運用上押さえておくべきポイントが上手くまとまっており、大変勉強になりました。</p>
<p>弊社でもTerraformを利用しており、お話にあった<code>tfstateファイルの扱い</code>や<code>すべてをterraform管理下には置かない</code>という部分は気をつけて運用しております。</p>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">「すべてをterraform管理下に置かない」ほんとこれ <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a></p>&mdash; 謎の音 (@onigra_) <a href="https://twitter.com/onigra_/status/750294797047304192">2016年7月5日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>「この発表をTerraformを使い始める前に聞きたかった…」となるプレゼンでした！</p>
<h3>KARTEを支えるAutoScaling~SpotInstance編</h3>
<img width="100%" alt="DSC09536.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/141a12e6-f165-4baf-9726-3852c6a0d86c/6dbf2a11-f9b2-42a4-9dc1-6f50a6cd2280.JPG.jpg">
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="c05b6b27593443b29aef55eb4b58c24c" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>いかにAutoScalingとSpotInstanceを上手く活用して運用しているかを話してもらいました。</p>
<p>SpotInstanceと聞くと「一時的なバッチ処理に使う」「テスト環境に使う」というイメージがあるかもしれないのですが、弊社では本番環境のステートレスなサーバ全てに使用しています。(管理画面用サーバ、解析サーバ等)</p>
<p>この発表では、SpotInstanceの価格変更にあわせて自動的にondemand⇔spotを切り替える仕組みを実装した話をしてもらいました。</p>
<p>ポイントは、<code>ondemand, spot, static</code>の3種類のサーバ群を用意すること。</p>
<p>「どのようなフローで切り替えを行っているのか」「実装する時に気をつけないといけない点」が詳しく書かれております。</p>
<p>実際に運用にのせたところ、サーバコストが1/2ほどになっているので、「サーバコスト減らしてよ！」と言われているインフラエンジニアの方必見です！</p>
<h3>対談</h3>
<img width="100%" alt="DSC09597.JPG (2.2 MB)" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58866921-6538-4c73-a736-d5a7042aa481/36b32a79-67bb-4922-a011-c1e63d176994.JPG.jpg">
<p>以下の3つのテーマで対談を行いました！</p>
<ul>
<li>HashiCorp製品の何をどうやって使っている？</li>
<li>AWSで辛いところは？</li>
<li>今後の展望</li>
</ul>
<h4>HashiCorp製品の何をどうやって使っている?</h4>
<p>トレタさんではTerraform,Vagrant,Packerを、プレイドではTerraformを使っています。</p>
<ul>
<li>Terraform
<ul>
<li>トレタ
<ul>
<li>VPC</li>
<li>Security Group</li>
<li>EC2</li>
</ul>
</li>
<li>PLAID
<ul>
<li>AutoScaling Group</li>
<li>EC2</li>
<li>ELB</li>
<li>CodeDeploy等</li>
</ul>
</li>
</ul>
</li>
<li>Vagrant
<ul>
<li>トレタ
<ul>
<li>開発環境構築</li>
</ul>
</li>
</ul>
</li>
<li>Packer
<ul>
<li>トレタ
<ul>
<li>AMI作成</li>
<li>Vagrant box作成</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>AWSで辛いところは？</h3>
<ul>
<li>ELBのIPを固定できないのが辛い</li>
<li>ELBのスケールが遅い</li>
<li>AutoScaleのAPIの上限が低くてすぐRateExceededになる</li>
</ul>
<h3>今後の展望</h3>
<ul>
<li>その時点での最適で柔軟なインフラ構成にしたい</li>
<li>AWSやGCPのどちらか一方を使うのではなく、両方の良いサービスを取り入れたハイブリッドなインフラ構成にしたい</li>
</ul>
<h3>Railsアプリケーション郡の構成管理、デプロイ等の話</h3>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="80d97567b26a4ed3aded1d163c2458a4" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>サーバの構成管理とデプロイをどのように行っているのかを話していただきました。</p>
<p>構成管理で使っているのはTerraform。<br>
<a href="https://speakerdeck.com/hiroakis/toretafalseinhurayun-yong">トレタのインフラ運用</a>でもお話がありましたが、Terraformには<code>管理に向くリソースと向かないリソース</code>があります。<br>
具体的に<code>どのリソースを継続的に管理していて、どのリソースは構築時のみ使うのか</code>ということに触れられているので、何に使うべきか迷っている方は一読を！</p>
<p><code>AMI作成まで</code>や<code>LaunchConfig作るまで</code>等を調整出来る、独自Packerクローンを作られたとのこと。すごい…！</p>
<p><strong> <a href="//www.slideshare.net/AkiraMiki/dockerize" title="Dockerizeして 大変だった話、幸せになった話" target="_blank">Dockerizeして 大変だった話、幸せになった話</a> </strong> from <strong><a href="//www.slideshare.net/AkiraMiki" target="_blank">Akira Miki</a></strong></p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/W6DcWT9VRF9I3" width="100%" height="533" 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">  </div>
<p>Docker導入して大変だったことと、その後に訪れた幸せについて話していただきました。</p>
<p>どんなことが大変だったのかの話では、運用に乗せてみないとなかなか想像しづらかった部分について話しておられたので勉強になりました！</p>
<p>苦労を乗り越えた後の幸せの話では、<code>リソースの有効活用とデプロイ時間の短縮</code>など「よーし、明日からDocker入れるぞ！」という気にさせられました！<br>
次回はLTではなく、20分枠で是非！</p>
<h3>2つのAuroraクラスタを同期したお話</h3>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="4d8d787993894ddca228419997c9b6ba" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>暗号化対応していない時期から使っていたAuroraを、リードレプリカを作ることで暗号化させた話をしていただきました。</p>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">暗号化されてないAuroraから暗号化されたAuroraへの移行、つらそう <a href="https://twitter.com/hashtag/plaidtech?src=hash">#plaidtech</a></p>&mdash; sue445 (@sue445) <a href="https://twitter.com/sue445/status/750312797397848064">2016年7月5日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>ぱっと聞いただけで大変そうな話で、工夫して<code>Binary Log</code>の位置を書き出されたりすることでレプリカセットを組み、無事暗号化されたとのことでした！</p>
<h2>まとめ</h2>
<p>AWS, Terraform, Docker等、サーバ構築からプロビジョニング、運用まで幅広く各社の取り組みを聞くことができた勉強会でした！<br>
使用しているツールや、実運用の際にハマっていたり気をつけている部分が似通っていたこともあり、定期的にこのような会を開いて「上手くいったこと」「失敗したこと」の共有をしていければ良いなと思いました！</p>
<p>一緒に勉強会を開催してくださる企業さまも絶賛募集中です！<br>
<a href="https://plaid.co.jp/#contact">弊社HPのお問い合わせフォーム</a>からご連絡いただくか、Twitterで #plaidtech をつけてツイートしてください！</p>
<h2>次回</h2>
<p>プレイドでは今後も色々なテーマで定期的に勉強会を開催する予定です！<br>
次回は「機械学習」に関する勉強会を8月頃に開催する予定ですので、是非ご参加ください。<br>
今回もイベント募集開催日に募集人数がオーバーしてしまいましたので、ご興味がある方は<a href="http://plaidtech.connpass.com/">connpassのPLAID tech</a>でメンバー登録を！</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）募集一覧をご覧ください。</p>


7/5(火)に開催した【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 の開催レポートです。


【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 を開催しました！

ウェブ接客プラットフォームKARTEの解析周りのアルゴリズムの利用検討の一環として、ストリーミングアルゴリズムについて検討したので、ストリー

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

<p>みなさん、ごきげんよう。プレイドの@tik-sonと申します。</p>
<p>私たちは<a href="https://karte.io/">KARTE</a>というリアルタイムでウェブ接客ができるサービスを提供しており、<br>
KARTEの売りであるリアルタイム性を保てるように、日々インフラを磨きこんでいます。</p>
<p>このエントリーでは、そのインフラの仕組みについて一部を紹介していきます。<br>
今回は「1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン」です。<br>
現在KARTEは主に<a href="https://aws.amazon.com">AWS</a>上で稼働しているので、このエントリーはAWSでのAutoScalingの紹介になります。</p>
<p>改めて説明は不要と思いますが、AutoScalingとは特定の条件をトリガーにリソースを自動的に増減させる仕組みのことです。</p>
<p>KARTEは</p>
<ul>
<li>リアルタイムなウェブ接客を売りにしているので、リソースの枯渇でリアルタイムに接客ができないということがあってはいけない</li>
<li>時間帯によって大きく負荷が変わるためリソースを負荷のピークにあわせて用意しておくと無駄にコストがかかってしまう</li>
</ul>
<p>のでAutoScalingはとても重要な要素の１つになっています。</p>
<h1>EC2でのAutoScaling</h1>
<p>KARTEではサーバリソースとしてEC2を利用していて、その一部でAutoScalingを導入しています。<br>
AutoScalingの構成パターンはざっくり言うと3種類あり、それぞれ紹介していきます。</p>
<h2>1. Autoscaling+CloudWatch+ELB</h2>
<p>一番標準的なパターンです。<br>
AWSでは<a href="https://aws.amazon.com/autoscaling/">Autoscaling</a>という、サービス名の通りEC2の能力を自動的に縮小、拡張することができるサービスが存在するので、EC2でAutoscalingさせたい時はこのサービスを利用するのが標準です。<br>
また、AutoScalingではサーバをScaleOutさせるだけでなく、ScaleOutしたサーバに対して処理を割り振らないといけないので、ロードバランサーと共に利用するのが一般的です。<br>
このパターンではロードバランサーとしてAWSで提供されている<a href="https://aws.amazon.com/elasticloadbalancing/">Elastic Load Balancing(ELB)</a>を利用しています。ELBを使えばScaleOut時のロードバランサーへのインスタンスの紐付けも比較的に容易に実行できます。<br>
AutoScalingのトリガーとしては<a href="https://aws.amazon.com/cloudwatch/">CloudWatch</a>を利用しています。CloudWatchはAWSのモニタリングサービスでAWSの各サービスにおける基本的な監視ができ、AutoScalingのトリガーとして簡単に設定することが出来ます。<br>
ちなみに<a href="http://aws.clouddesignpattern.org/index.php/CDP:Scale_Out%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3">CDP:Scale Outパターン</a>が本パターンに該当すると思います。</p>
<ul>
<li>CloudWatchでAutoscalingGroupのMetricを監視</li>
<li>Metricが設定した閾値を超えた時にAlarmを発行</li>
<li>AutoScalingがAlarmを受け取り、サーバを起動/停止</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/84aeceee-8d1f-4285-b0b2-e05542e5cc4c/c1ee3e57-2afd-4bf2-b898-9f0b30790c18.png" alt="image.png (70.2 kB)"></p>
<h2>2. Autoscaling+CloudWatch+CustomMetric+ELB</h2>
<p>CloudWatchで用意されている標準のMetricだけだと、適切なタイミングでスケールアウト/インが実行されないことがあるので、独自のMetric(CustomMetric)を利用してスケールさせるパターンです。<br>
CustomMeticを利用する以外は基本的には「1. Autoscaling+CloudWatch+ELB」と同じです。KARTEではこのパターンを解析サーバのAutoScalingで利用していて、解析状況をCustomMetricとして送付して利用しています。<br>
AWSには<a href="https://aws.amazon.com/jp/tools/">色々な言語でのSDK</a>が用意されているのでCustomMetricの送付はこれを利用すると便利です。<br>
ちなみにNode.js(coffeescript)でMetricを送ろうとするとこんな感じになります。</p>
<pre><code class="language-coffee">AWS = require('aws-sdk')
cloudwatch = new AWS.CloudWatch()
params =
  MetricData: [ {
    MetricName: 'YOUR_METRIC_NAME'
    Dimensions: [ {
      Name: 'YOUR_DIMENSIONS_NAME'
      Value: YOUR_DIMENSIONS_VALUES
    } ]
    Timestamp: new Date
    Unit: 'YOUR_UNIT'
    Value: YOUR_VALUE
  } ]
  Namespace: 'YOUR_NAMESPACE'
cloudwatch.putMetricData params, (err, data) -&gt;
  if err
    console.log err, err.stack
  else
    console.log data
</code></pre>
<p>まとめると以下の通りです。</p>
<ul>
<li>AutoscalingのトリガーになるMetricを取得し、CustomMetricとしてCloudWatchに送信</li>
<li>CloudWatchでCustomMetricを監視</li>
<li>Metricが設定した閾値を超えた時にAlarmを発行</li>
<li>AutoScalingがAlarmを受け取り、サーバを起動/停止</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/51774bd8-b6b0-41b2-8b27-551a073bad6a/1a31b8c7-5207-42b1-a634-1b588eeeadc3.png" alt="image.png (82.4 kB)"></p>
<h2>3. Autoscaling+CloudWatch+ELB+Route53+NginxPlus</h2>
<p>KARTEではSocket.IOを利用している部分があるのですが、Socket.IOはELBとは相性が悪く、<br>
(HTTPモードの場合だとHTTPヘッダが書き換えられて、HTTPUpgradeができない、TCPモードだと接続ごとに別のサーバが応答するのでハンドシェイクが失敗する等)<br>
nginxをSocket.IOを利用するサーバのロードバランサーとして利用しています。<br>
nginxはWebSocketProxyのサポートを1.3.13より開始しており、それによりSocket.IOもnginxで利用できるようになっているためです。<br>
詳細な設定方法は<a href="https://www.nginx.com/blog/nginx-nodejs-websockets-socketio/">nginxのブログ</a>に記載されているのでこちらをご覧いただければと思います。<br>
<a href="http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash">ip___hash</a>という方法で分散することがポイントで、これにより同じクライアントからのアクセスは一意になります。<br>
ちなみにこのip_hash、IPv4の場合は初めの3オクテットがhashing keyとして利用されるので、注意が必要です。</p>
<blockquote>
<p>Specifies that a group should use a load balancing method where requests are distributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well.</p>
</blockquote>
<p>nginxを利用することでSocket.IOの負荷分散ができるようになりましたが、最終的に実施したいことはAutoScalingです。<br>
ELB利用時にはAutoscalingで新しく起動してくるインスタンスはAWS側でELBに紐付けてもらえますが、nginxを利用する場合はもちろんAWS側は何もしてくれないので、この仕組みを作る必要があります。<br>
実現方法は色々とあると思いますが、この仕組みはRoute53とnginxPlusで実現可能です。</p>
<p>nginxのupstreamにはIPアドレスではなく名前であらかじめ利用予定のサーバ名を記載しておき、<br>
インスタンスの起動時にインスタンス自身がRoute53に自分のIPアドレスをAレコードに登録するという方法です。</p>
<p>この方法では既存のレコードに影響をおよぼさないように</p>
<ul>
<li>既に利用されているAレコードで登録しないようにするために「ping/ncコマンドで存在を確認」</li>
<li>自分のIPアドレスがAレコードに登録されている場合は登録の処理をとりやめるために、「digコマンドと<a href="http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html">EC2のインスタンスメタデータ</a>を利用して確認」</li>
</ul>
<p>のような工夫が大切になります。</p>
<p>また、この仕組みには標準のnginxではなく、nginxPlusを利用します。<br>
nginxPlusとはnginxのエンタープライズ向けのプロダクトで、nginxの機能に加え様々な機能が利用できます。<br>
今回の仕組みの中でnginxPlusを利用するのは、サービスの再起動なしにupstream内のserverのAレコードの変更を追従してくれる機能があるためです。<br>
https://www.nginx.com/resources/admin-guide/load-balancer/</p>
<blockquote>
<p>NGINX Plus can monitor changes of IP addresses that correspond to a domain name of the server and automatically apply these changes to NGINX without its restart.</p>
</blockquote>
<p>nginxPlusはAWSだと<a href="https://aws.amazon.com/marketplace/search/results/ref=gtw_navgno_search_box?page=1&amp;searchTerms=nginx+plus">AmazonMarketPlace</a>でAMIとして購入できるので、EC2インスタンス同様に従量課金で利用することが可能です。</p>
<p>このパターンについてまとめます。</p>
<ul>
<li>nginxPlusのupstreamに利用予定のサーバ名をあらかじめ登録(s3にupstreamファイルを置いておいて、起動時に取ってくるとか)</li>
<li>CloudWatchでAutoscalingGroupのMetricを監視</li>
<li>Metricが設定した閾値を超えた時にAlarmを発行</li>
<li>AutoScalingがAlarmを受け取り、サーバを起動/停止</li>
</ul>
<p>[以下、サーバ起動時の処理]</p>
<ul>
<li>サーバ起動時にサーバは自分のIPアドレスをRoute53のAレコード(nginxPlusに登録されていて、現在で利用されていないレコード)に登録する</li>
<li>nginxPlusから先程Aレコード登録された名前のサーバへのhealthcheckが成功する</li>
<li>nginxPlusが新しく上がってきたサーバへ処理を振り分ける</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ce445bfc-9670-4e9d-aecf-a67853e6bcd6/a326770a-a7bc-40fc-9a7c-ac31fe1231c7.png" alt="image.png (92.5 kB)"></p>
<p>以下のようなことも諸々と考慮しないといけないのですが、今回のエントリーでは割愛させていただきます。</p>
<ul>
<li>serverのhealthcheckの間隔</li>
<li>同じレコードに登録しにいかないようにする仕組み(ランダムな時間待つ、チケット発行するなど)</li>
<li>nginxの冗長化</li>
</ul>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、<br>
KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）募集一覧をご覧ください。<br>
もしくはこちらのボタンよりお気軽に「話を聞きに行きたい」と押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script> 
<p></p>


1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン

ArduinoとDatadogでオフィスの温度と湿度を可視化する

<p>株式会社プレイドのCTOシバヤマです。</p>
<p>この度、エンジニアブログを開設することにしました。<br>
背景には、<code>社外の人にプレイドの中のエンジニアのユニークなパーソナリティを知ってもらいたい</code>、というのがあります。</p>
<p>弊社のエンジニアには多様なメンバーがいて、言語解析や動画解析をやっていたメンバー、制御・ロボティクスをやっていたメンバー、並列言語コンパイラをやっていたメンバー、大手ゲーム会社出身、検索エンジンの会社出身、長くDSP畑のメンバーなどなど、ここでは書ききれないほど経験値が多種多様です。</p>
<p>年齢も23歳~38歳（平均31歳？）というレンジで、研究畑の人もいれば、文系の人もいるし、大手からベンチャーを渡ってきた人も、新卒もいます。</p>
<p>社内でミーティングをしていると、他のメンバーの意見に気づかされることが多いので（若干の悔しさは覚えますが）、このユニークなメンバーの知識や経験を社外にも還元していけるといいなぁと思っています。</p>
<p>出来る限り、<code>他では得られないユニークな経験もしくは深い洞察・知識</code>が書いている場所になるといいなぁと思っています。<br>
が、若干ハードルを上げすぎないでくれぃとメンバーには言われそうなので、このくらいにしておきますw</p>
<p>他にも開発合宿の様子とか新メンバーの紹介とか、ライトなコンテンツも用意していくかもしれません。</p>
<p>それではよろしくお願いいたします。</p>


プレイドのエンジニアブログを開設することになりました。CTOのシバヤマから、エンジニアブログを始めるにあたってのメッセージです。

プレイドのエンジニアブログを始めました！

Engineer Blog

Recent Article

スピード重視の開発体制を実現するためのUIテスト自動化

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜を開催しました！

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン

ArduinoとDatadogでオフィスの温度と湿度を可視化する

プレイドのエンジニアブログを始めました！

Popular Articles

Popular Tags

Archives

Writers

Recent Article

スピード重視の開発体制を実現するためのUIテスト自動化

機械学習&チャットBotについて語る！【FiNC×プレイド】Machine Learning Meetup #1 を開催しました

従来のWebアプリの常識を変える! Service WorkerがもたらすWebの未来

A/Bテストより無駄なく最適化できる？バンディットアルゴリズムを試してみた

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜 を開催しました！

大規模データを解析するストリーミングアルゴリズムをサクッと見てみる

機械学習 x PySparkでアルゴリズム開発をサクサクやる検証

1年で4億UUを解析したKARTEを支えるAutoscaling 3パターン

ArduinoとDatadogでオフィスの温度と湿度を可視化する

プレイドのエンジニアブログを始めました！

Popular Articles

Popular Tags

Archives

Writers

【トレタ×プレイド】TechBlog Deep Dive Meetup #1 〜インフラ編〜を開催しました！