Engineer Blog

Anri Nakamura

Kakemu Fujii

Kento Kaseda

Reo Hakuta

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

<h1>はじめに</h1>
<p>この記事は <a href="https://qiita.com/advent-calendar/2025/datadog">Datadog Advent Calendar 2025</a> の3日目の記事です。</p>
<p>こんにちは、プレイドの Developer Experience &amp; Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は <a href="https://docs.datadoghq.com/continuous_integration/">CI Visibility</a> と <a href="https://docs.datadoghq.com/dashboards/widgets/split_graph/">Split Graph</a> です。</p>
<p>Datadog の <a href="https://docs.datadoghq.com/ja/actions/workflows/">Workflow Automation</a> は Datadog の <a href="https://docs.datadoghq.com/ja/actions/actions_catalog/">Action</a> を組み合わせたワークフローを組むことができる機能です。Datadog の API で提供されているような機能を中心として様々なクラウドプロバイダーや SaaS ツールとも連携できます。</p>
<h1>背景：なぜ Pod を削除するのか</h1>
<p>私たちが運用しているサービス KARTE は GKE 上に構築されています。普通、Pod にはヘルスチェックが設定されており、サービスが応答できない状態になったらコンテナを再起動するようになっています。しかし、うまくコンテナを再起動するようにコントロールできないケースや、Pod を消して作り直した方が早いケースがこれまでに何度かありました。</p>
<p>例えば、GKE の既知の問題として Image Streaming を有効にしている際に、Image Pull のタイミングによってはファイルが存在せずに実行できないということがありました（<a href="">https://docs.cloud.google.com/kubernetes-engine/docs/troubleshooting/known-issues?hl=ja#image-screaming-missing-files</a>）。Image Streaming を有効にしているノードの中で、特定のイメージのファイルが欠落することがあるという状態でした。このケースでは、コンテナは再起動されますが同じノードで再起動しようとするため、何度再起動しても正常に起動することはありません。しかし、Pod を削除してしまえば別のノードに配置されるため、起動できる可能性があります。</p>
<p>このように 「Pod を消せば解決する」パターンはいくつかあり、社内では Pod を削除するマニュアルを作って、既知の問題には Pod を削除して解決することがしばしばありました。しかし、Datadog の画面上から問題の Pod 名を抽出した後に、GCP の管理画面もしくは CLI 上から Pod 削除を実行するというもので、地味に面倒くさいというのと決まりきった作業なのに自動化できていないという問題点がありました。</p>
<h1>Private Action Runner のセットアップ</h1>
<p>今回作成する Workflow では Pod を削除する Action を使用します。Kubernetes Core というカテゴリにあるアクションを使用する場合には Private Action Runner をインストールする必要があります。</p>
<p>App Builder モードと Workflow Automation モードがありますが、今回は Workflow Automation でしか使用しないため Workflow Automation モードを使用します。</p>
<p>https://docs.datadoghq.com/ja/actions/private_actions/#workflow-automation-mode</p>
<p><img src="https://ik.imagekit.io/plaid/5a2399e0-f356-4f82-b242-96f97ded17c9/private_action_runner_-_diagram_workflow.9034fc43fe904c71755911b987a8475e.avif" alt="private_action_runner_-_diagram_workflow.9034fc43fe904c71755911b987a8475e.avif"></p>
<p>Datadog の管理画面上から手順を進めていくと、次のようなコマンドを実行するように指示されます。</p>
<pre><code class="language-bash">docker run \
  -e DD_BASE_URL=https://us5.datadoghq.com \
  -e RUNNER_ENROLLMENT_TOKEN=xxx \
  -e STATSD_ENABLED=true \
    gcr.io/datadoghq/private-action-runner:v1.14.0 \
  --enroll-and-print-config

</code></pre>
<p>これを実行すると Helm charts に設定するべき config が生成されます。Pod を削除するアクションのみを許可した場合の config は次のようになりました。</p>
<pre><code class="language-yaml">actionsAllowlist:
    - com.datadoghq.kubernetes.core.deletePod
allowlist:
    - '*'
allowIMDSEndpoint: false
ddBaseURL: https://us5.datadoghq.com
modes:
    - pull
port: 9016
privateKey: xxx
urn: xxx
reportMetrics: true
</code></pre>
<p>注意点としては3つあります。</p>
<p>まず1つ目は secret の扱いです。Kubernetes を運用する場合 GitOps のように GitHub に Manifest をコミットして管理することが多いと思います。その場合には secret をそのままコミットするわけにはいきません。<a href="https://github.com/DataDog/helm-charts/tree/main/charts/private-action-runner#using-kubernetes-secrets-for-runner-identity">runnerIdentitySecret</a> を使用して Secret リソースを参照するようにし、Secret リソース自体は External Secrets Operator などのツールを使って管理します。</p>
<p>2つ目にスキーマが違う問題がありました。 下記の設定はエラーになります。</p>
<pre><code class="language-yaml"># kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: private-action-runner
  includeCRDs: true
  valuesFile: values.yaml
  releaseName: private-action-runner
  version: v1.18.0
  repo: https://helm.datadoghq.com

# values.yaml
$schema: https://raw.githubusercontent.com/DataDog/helm-charts/private-action-runner-1.18.0/charts/private-action-runner/values.schema.json
runner:
  runnerIdentitySecret: &quot;datadog-runner-identity&quot;
  # Replace this section with the output of the private action runner enrollment process with the `--enroll-and-print-config` flag
  config:
    allowIMDSEndpoint: false
    ddBaseURL: https://us5.datadoghq.com
    modes:
      - pull
    port: 9016
    reportMetrics: true
    actionsAllowlist:
        - com.datadoghq.kubernetes.core.deletePod
    allowlist:
        - '*'
</code></pre>
<pre><code class="language-bash">$ kustomize build .
Error: Error: values don't meet the specifications of the schema(s) in the following chart(s):
private-action-runner:
- runner.config: Additional property reportMetrics is not allowed
- runner.config: Additional property allowlist is not allowed
</code></pre>
<p>allowlist と reportMetrics のパラメータはドキュメントを見る限りすでに許可されていませんでした。そのためこれらのパラメータは消しました。</p>
<p>3つ目に actionsAllowlist についてですが、これを設定するだけでは private action runner が Pod を削除することはできませんでした。理由としては、この Helm charts で作成された Role リソース（private-action-runner に Bind されています）に Pod delete が割り当てられていないからです。</p>
<pre><code class="language-yaml">apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: private-action-runner
rules:
  - apiGroups:
      - &quot;&quot;
    resources:
      - pods
    verbs:
      - get
      - list
</code></pre>
<p>結局、ドキュメントを見ていると kubernetesActions というパラメータがあったのでこれを設定することで Pod を削除する権限を与えることができました。</p>
<pre><code class="language-yaml"># values.yaml
$schema: https://raw.githubusercontent.com/DataDog/helm-charts/private-action-runner-1.18.0/charts/private-action-runner/values.schema.json
runner:
  runnerIdentitySecret: &quot;datadog-runner-identity&quot;
  # Replace this section with the output of the private action runner enrollment process with the `--enroll-and-print-config` flag
  config:
    allowIMDSEndpoint: false
    ddBaseURL: https://us5.datadoghq.com
    modes:
      - pull
    port: 9016
  kubernetesActions:
    pods: [&quot;get&quot;,&quot;list&quot;, &quot;delete&quot;]
</code></pre>
<p>あとは、Private Action Runner 作成の手順に従って、Connection を作成します。Credentials は Service account authentication を選ぶのがスムーズです。</p>
<p><img src="https://ik.imagekit.io/plaid/2fcfbbf1-3bce-4a2f-b353-8c863c557419/%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-12-0122.38.21.png" alt="スクリーンショット2025-12-0122.38.21.png"></p>
<p>Private Action Runner をインストールした際には、シンプルに Pod 削除をするだけの Workflow を作って検証するのが良いと思います。まずは pod 名を指定して削除するだけの Workflow を作り、テスト実行しました。</p>
<p><img src="https://ik.imagekit.io/plaid/b64ff087-5d6f-4eb0-803b-7be10de19e04/%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-12-0122.40.34.png" alt="スクリーンショット2025-12-0122.40.34.png"></p>
<h1>作った Workflow</h1>
<p>最終的には次のようなワークフローを作りました。説明しやすさのために4つのセクションに色分けをしています。</p>
<p><img src="https://ik.imagekit.io/plaid/c318286c-819b-4a47-9045-63103ea9d367/%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-12-0122.55.47.png" alt="スクリーンショット2025-12-0122.55.47.png"></p>
<ol>
<li>トリガーとパラメータの準備</li>
<li>10分以内に同じ Deployment の Pod 削除が実行されていないかのチェック</li>
<li>Ready Pod が Desired Pod よりも少なくないことのチェック</li>
<li>通知と Pod 削除の実行</li>
</ol>
<p>となっています。それぞれ解説していきます。</p>
<h2>1. トリガーとパラメータの準備</h2>
<p>Workflow Automation ではトリガーを設定します。いくつかやり方がありますが、今回のように異常を検知してその異常に対して何かアクションをするようなケースでは Monitor が適しています。Monitor の Mention として Workflow を設定できます。</p>
<p><code>@workflow-pod-delete(pod_name=&quot;{{pod_name.name}}&quot;,slack_channel=&quot;#hogehoge&quot;)</code></p>
<p>Mention にはパラメータを渡すことができます。どの Pod を削除するかというのはどの Pod で問題が起きているかによるので、パラメータとして渡す必要があります。ログやメトリクスのモニターを作る場合には pod_name で Group By して Multi Alert を設定することで、<code>{{ pod_name.name }}</code> を変数展開して渡すことが可能です。他にも、パラメータをうまく活用することで Workflow を汎用化することができます。例えば slack_channel というパラメータを用意していますが、これをすることで様々なチームでこの Workflow を利用することができます。モニターのメンションとして slack チャンネルを指定することもできますが、Workflow のパラメータとして slack_channel を用意している理由については後述します。</p>
<p>トリガーの次に deployment name というステップで Deployment 名を抽出しています。Data Transformation というアクションを使用し、次のような式を書いています。</p>
<p><code>$.Trigger.pod_name.split('-').slice(0, -2).join('-')</code></p>
<p>これだけで、Pod 名から Deployment 名を取得することが可能です。Deployment 名をパラメータとして渡すこともできます（モニターを pod_name と deployment_name の Multi Alert にすれば良い）が、使う側でパラメータが増えるというのと無駄な Group By が増えるのでこのようにちょっとしたパラメータの準備をしています。</p>
<h2>2. 10分以内に同じ Deployment の Pod 削除が実行されていないかのチェック</h2>
<p>Pod を削除する処理が短い時間で何度も行われているということは、何か想定していない事象が起きている可能性が高いです。Workflow や Monitor の設定方法が間違っていた場合、正常に動いているのに Pod を削除し続けてしまい障害になるということもあり得ます。そのような事故を防ぐための予防策として、10分間のクールタイムを設定したいと考えました。</p>
<p>これには <a href="https://docs.datadoghq.com/ja/actions/datastores/">Datastore</a> という機能を利用しています。「Get Timestamp」ステップでは Deployment 名をキーとして、その Deployment に対して Pod 削除が実行された最新のタイムスタンプを取得しています。次の「has 10 min passed」では、そのタイムスタンプから10分以上経過しているかを JavaScript でチェックしています。もし10分以内に Pod 削除を実行していなければ、「Put item」で Deployment 名をキーとして現在のタイムスタンプを保存します。</p>
<h2>3. Ready Pod が Desired Pod よりも少なくないことのチェック</h2>
<p>Desired Pod に対して Running Pod が足りてない場合、Pod 削除を実行することにより Pod が不足し、リクエストを捌ききれなくなる可能性があります。このような場合には Pod 削除を自動で実行することは避けておいた方が無難です。</p>
<p>Desired Pod は Datadog Action の Query scalar data で取得し、Ready Pod は Kubernetes Action の List pod で取得しています。Query scalar data は Datadog の Metrics に対する集計値を取得することができます。Query window の最小値が1分なためどうしてもラグがありますが、 <code>kubernetes_state.deployment.replicas_desired</code> のメトリクスの最大値としています。</p>
<p><img src="https://ik.imagekit.io/plaid/85fbc3df-77d4-465d-9de4-5319d919824a/%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-12-0123.50.02.png" alt="スクリーンショット2025-12-0123.50.02.png"></p>
<p>Kubernetes Action で Deployment の replicas を直接取得する方法もありそうでしたが、Private Action Runner に Deployment の get の権限をつける必要がありそうで、面倒だったのでこのやり方にしています。</p>
<p>Ready Pod の取得では List pod を叩いた後に、status を確認して Ready なものの数を確認します。List pod では pod の状態が取得できるため、次のようなクエリを書いて Ready なものを抽出します。</p>
<p><code>$.Steps.List_pod.items.filter(value =&gt; value.status.containerStatuses.every(s =&gt; s.ready)).length</code></p>
<p>Desired Pod 数の取得と Ready Pod 数の取得を並列で行い、それらを比較することで自動で Pod を削除できるかの判断をします。</p>
<h2>4. 通知と Pod 削除の実行</h2>
<p>2, 3 のそれぞれの条件が True であれば自動的に Pod の削除を実行します。「Send pre delete」のステップでは Pod 削除を実行する前のログとしての通知を slack に送信します。次に「Delete pod」で削除を実行します。Pod がすでに存在しない場合など、「Delete pod」が失敗することもあるので、失敗時にも通知されるようにしています。</p>
<p>また、2, 3 の条件のいずれかが False であれば、Pod を削除することのリスクが高い可能性があります。しかし場合によっては Pod を削除した方が良い可能性もあるので、「Make a decision」というアクションを使って Approve されたら「Delete pod」を実行するというようにしています（単純に「Make a decision」を使ってみたかったというのもあります）。</p>
<h1>まとめ</h1>
<p>この記事では、Datadog の Workflow Automation を使って、安全に Pod を削除する方法を紹介しました。今回作成した Workflow によって問題が起きた Pod を削除するという手間を省くことができるようになりました。</p>
<p>Workflow Automation で使える Action はとても豊富で、他にも色々な活用方法がありそうです。Preview ですが <a href="https://www.datadoghq.com/blog/datadog-agent-builder/">Agent Builder</a> という機能を使うことで AI Agent によるアクションを Workflow に埋め込むこともできそうなので、試してみたいと思います。</p>


DatadogのWorkflow Automationで、再起不能なGKEのPodを安全に自動削除する具体的手順と設計ポイントを紹介します。クールタイム管理、Desired/Readyの健全性チェック、Slack通知と承認で誤作動を防ぎつつ、運用の手間を減らします。Helm設定の注意点や権限付与、メトリクス活用まで実例でまとめました。

Datadog の Workflow Automation を使って再起不能になった Pod を安全に削除する

KARTEの分析システムのレガシーな開発環境を高速にする。pnpm, Rspackの導入で改善できたこと。

<h1><strong>Introduction</strong></h1>
<p>I’m Oya from the Developer Experience &amp; Performance team. On <strong>October 30, 2025</strong>, <a href="https://plaid.co.jp/en/">PLAID, Inc.</a>  announced the direction for AI‑native transformation of <a href="https://karte.io/">the KARTE product series</a>, called <strong>“KARTE AI”(<strong>https://plaid.co.jp/news/20251030/</strong>)</strong>, and released several features in beta. In April 2025, we launched the KARTE AI Project to drive development of these features. I have mainly focused on platform-level work. This article explains how we ran the project, why we chose a “centralized” architecture, and the advantages of using <a href="https://mastra.ai/">Mastra ↗</a>.</p>
<h1><strong>About the KARTE AI Project</strong></h1>
<p>Before the project began, AI integration into KARTE products had barely progressed. Some products did ship AI features, but frameworks varied and we lacked a unified push to share knowledge and improve efficiency across teams. These challenges led us to launch the KARTE AI Project.</p>
<h2><strong>Project Goals</strong></h2>
<p>Based on the issues above, we set two goals:</p>
<ul>
<li>Develop talent who can lead AI development.</li>
<li>Design how to build AI features in a microservices architecture.</li>
</ul>
<p>Releasing AI‑powered features matters, but within this project, releases are a means to the end.</p>
<h2><strong>Project Structure Aligned to the Goals</strong></h2>
<p>Creating a dedicated AI team to build features would not produce the state where “each team has engineers skilled in AI Agent development.” So we adopted a dual‑assignment model. Centered on a Project Owner, Product Engineers embed AI into their respective products, Platform Engineers develop from a platform perspective, and Customer Engineers build an internal bot that answers KARTE questions. The project collaborates closely, with Platform Engineers owning AI service operations.</p>
<p><img src="https://ik.imagekit.io/plaid/0a9e8737-2bbe-4d32-8e0a-58a663f94609/team2.png" alt="team2.png"></p>
<p>Platform Engineers mainly:</p>
<ul>
<li>Keep application implementations simple by shaping the environment.</li>
<li>Aggregate learnings and review effectively.</li>
<li>Fix framework bugs or suboptimal implementations upstream.</li>
<li>Proactively design workarounds for likely pitfalls.</li>
<li>Regularly bump framework versions.</li>
<li>Explore and stay current on libraries/frameworks.</li>
<li>Evaluate what new versions enable.</li>
<li>Prepare systems for operations: observability, tests, evals.</li>
</ul>
<p>While PLAID sometimes prioritizes speed by skipping early reviews and batch‑reviewing around beta releases, for AI features we required reviews for all changes, even small ones. Since training leaders in AI development is a primary goal, code review is a highly effective lever.</p>
<p>Also, Platform Engineers need hands‑on experience to know where Product Engineers struggle. In parallel, we implemented multiple AI features—including chat‑UI agents—to gain practical insight.</p>
<h1><strong>KARTE Microservices</strong></h1>
<p>Before the AI system architecture, here’s KARTE’s microservices setup.</p>
<p>KARTE microservices are split into Web API, Internal API, and Frontend.</p>
<ul>
<li>
<p>Frontend</p>
<p>We build SPA JavaScript files using React.js or Vue.js and distribute them from Web API.</p>
</li>
<li>
<p>Web API</p>
<p>Serves HTML, CSS, JavaScript assets for Frontend and exposes APIs called by the SPA.</p>
</li>
<li>
<p>Internal API</p>
<p>APIs called from other services’ Web or Internal APIs. They assume authentication/authorization has already been handled by the calling Web API and do not implement auth themselves.</p>
</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/bc1f1682-5905-413e-a2d3-6312bd0e39ca/microservice2.png" alt="microservice2.png"></p>
<p>Each service’s owning team develops, operates, and maintains it, keeping independence under these principles:</p>
<ul>
<li>Independent deploys: build and deploy per service.</li>
<li>Independent DBs: dedicated DB per service.</li>
<li>API‑based communication: use Internal APIs between services.</li>
</ul>
<p>Tech choices are largely up to each team. APIs are often TypeScript with MongoDB. Web API, Internal API, and Frontend live in a monorepo (e.g., pnpm workspaces), allowing free codebase dependencies—such as sharing Web API types with Frontend.</p>
<h1><strong>Elements of AI Features and SDKs</strong></h1>
<p>AI features range from simple to advanced. We mostly build AI Agents, so this article focuses on them.</p>
<p>AI Agents execute tasks using Tools and Memory and, as needed, perform multi‑step LLM calls.</p>
<p><a href="https://mastra.ai/ja/docs/agents/overview">https://mastra.ai/ja/docs/agents/overview ↗</a></p>
<p><img src="https://ik.imagekit.io/plaid/44466c30-1040-42ef-9285-dc7945ed1f80/agents-overview.webp" alt="agents-overview.webp"></p>
<p>Tools are common across many LLM SDKs, but Memory in TypeScript is supported by frameworks like LangChain.js, Mastra, and VoltAgent.</p>
<p>These frameworks also include RAG, Workflows, Evals, Observability, and Web APIs. From the start, we planned to use a framework. While frameworks trade off flexibility, when you don’t yet know how to implement AI Agents or what’s possible, not adopting one carries bigger downsides. We chose Mastra, and Memory in particular is far easier than rolling our own.</p>
<h1><strong>Mastra</strong></h1>
<p>Mastra is a framework layered atop Vercel’s AI SDK. The AI SDK provides basics like model routing and tools, while Mastra adds more advanced features such as Memory and Evals.</p>
<p><a href="https://mastra.ai/ja/docs/frameworks/ai-sdk">https://mastra.ai/ja/docs/frameworks/ai-sdk ↗</a></p>
<p><img src="https://ik.imagekit.io/plaid/e3606cb6-e475-4f33-8797-65a85cd5b812/mastra-ai-sdk.webp" alt="mastra-ai-sdk.webp"></p>
<p>There’s Mastra Cloud, a managed environment to deploy Mastra apps more easily, but KARTE embeds into existing apps, so we don’t use it. In this article, “Mastra server” means a KARTE‑side server with Mastra installed, not Mastra Cloud.</p>
<h1><strong>KARTE AI System Architecture</strong></h1>
<p>In our microservices architecture, we created a single KARTE AI microservice using Mastra and have other services call it, i.e., a centralized model. Alternatively, each microservice could install Mastra (decentralized). We saw these trade‑offs:</p>
<h2>Decentralized</h2>
<ul>
<li>Faster if each team has engineers skilled in AI Agent development.</li>
<li>Fewer inter‑service dependencies.
<ul>
<li>Increased system stability.</li>
<li>Easier to roll out version/config changes in stages.</li>
</ul>
</li>
</ul>
<h2>Centralized</h2>
<ul>
<li>Agents inside the AI system can easily interoperate (cross‑product multi‑agent).</li>
<li>Knowledge can be centralized.</li>
</ul>
<p>AI Agent development patterns are still evolving, and not all teams have AI Agent skills. Strategically, KARTE is strengthening multi‑product elements, so we need an architecture amenable to future multi‑agent designs. We judged centralized has bigger near‑term benefits, so we consolidated AI code into one microservice.</p>
<p>Two key architectural questions are where Tools execute and how Storage is designed; we explain those first, then two architectures we’ve actually run.</p>
<h2><strong>Tools</strong></h2>
<p>Tools enable agents to access non‑training data or execute actions (e.g., Claude Code editing or shell execution). With Mastra, execution location leads to three types:</p>
<ul>
<li>
<p>server tool</p>
<p>Runs on the Mastra server. You can debug with Mastra Playground. Define server tools inside Mastra and it executes them.</p>
</li>
<li>
<p>client tool</p>
<p>Runs on the client relative to the Mastra server. You implement the client‑side execution.</p>
<p>With <code>@mastra/client-js</code>, pass a function to clientTools.execute for auto‑execution. With <code>@ai-sdk/react</code> <code>useChat</code>, run your logic via onToolCall.</p>
</li>
<li>
<p>provider tool</p>
<p>Runs in the provider’s environment. For example, Vertex AI provides Google Search or Code Execution.</p>
</li>
</ul>
<p>Choosing server vs client for custom tools depends on the app. Our custom tools typically access KARTE DB data, create KARTE configuration values (e.g., Action config), or call a separate LLM from the main agent. Provider tools fit general tasks like Python numerics or Google search.</p>
<h2><strong>Storage</strong></h2>
<p>We mainly use Memory for chat history and Evals for performance evaluation. With centralized Mastra, Storage is also usually single. Currently, aside from PostgreSQL, indexes aren’t created by default, so without indexes, performance may degrade as agents grow. Another issue is separating data when classification differs (e.g., sensitive data). Memory can switch Storage instances per Memory instance (allowing separate clusters/DBs), but Evals is configured once per Mastra instance and likely cannot be switched. If Evals can’t separate while Memory can, separation has limited value because Evals may include Memory‑like data for evaluation. So we didn’t split. If we build agents that handle highly confidential data in the future, we may reconsider separation.</p>
<h2><strong>Initial Architecture</strong></h2>
<p>We initially implemented KARTE AI as an Internal API. The Frontend could not call it directly; instead, each service’s Web API called the Mastra server.</p>
<p><img src="https://ik.imagekit.io/plaid/b8a5019e-fa86-4627-865e-5024d5a901b2/karte-ai.png" alt="karte-ai.png"></p>
<p>For tool calls that read or update data, we must confirm the user’s access permissions. Authorization lives in Web APIs (requests from Frontend). Internal APIs assume auth is already done and carry that information; they do not implement auth themselves. Since tool call parameters are largely chosen by the LLM, an implementation might attempt to access data the user shouldn’t. Therefore, we planned to run such tools as client tools in the Frontend.</p>
<p>This architecture had several issues:</p>
<ul>
<li>Dependency on the client library: using ‎<code>@mastra/client-js</code> server‑side isn’t well assumed, and upgrades sometimes broke streams or tool execution. It also depends on ‎<code>@mastra/server</code>, so bumping ‎<code>@mastra/server</code> past certain versions can break older <code>‎@mastra/client-js</code>. With Mastra still at major 0, compatibility windows felt short. Practically, tracking Mastra latest sometimes required bumping ‎<code>@mastra/client-js</code> in client services and deploying together.</li>
<li>Frontend coupling: the Frontend ultimately depends on <code>‎@ai-sdk/react</code> ‎<code>useChat</code>, so teams juggle three components: ‎<code>@mastra/server</code>, <code>‎@mastra/client-js</code>, and ‎<code>@ai-sdk/react.</code></li>
<li>Redundant Web APIs: many Web APIs wrapping Mastra server calls looked similar across services.</li>
</ul>
<p>To address this, we adopted the following approach.</p>
<h2><strong>Frontend Direct Requests to the Mastra Server</strong></h2>
<p><img src="https://ik.imagekit.io/plaid/9f135a66-5b99-47d0-8fe5-d367012531a7/front-mastra.png" alt="front-mastra.png"></p>
<p>In this approach, the Frontend calls the Mastra server directly and drops dependence on ‎<code>@mastra/client-js</code>, reducing minor bugs and debugging costs. After major changes in the Vercel AI SDK, this architecture let us focus on migrating Frontend ‎<code>useChat</code>. It also eliminates the need to build redundant Web APIs.</p>
<p>Previously, Frontend could only call its own service’s Web API. We removed that rule here. While it may introduce some confusion, the benefits outweighed the downsides. That rule exists to avoid other services depending on a Web API built for one service’s Frontend, which harms independence. KARTE AI is designed to be called by other services, so independence concerns don’t apply.</p>
<h1><strong>Advantages of Mastra and Usage Examples</strong></h1>
<p>We won’t do a detailed comparison, but initial reasons were: TypeScript‑native framework, released earlier than VoltAgent, and stronger docs and momentum than LangChain.js. In practice, updates are fast with frequent new features, and questions on Discord and PRs get quick reactions—great speed and flexibility, crucial in fast‑moving AI. The codebase is clear and easy to develop against; I’ve had <strong>24 PRs</strong> merged. If rapid updates worry you, <strong>Mastra v1 beta</strong> was just announced, so stability should improve.</p>
<p>Earlier this year in May, Mastra’s CTO visited Japan and our office; we discussed PLAID’s AI, Mastra’s roadmap, and shared our requests.</p>
<p><img src="https://ik.imagekit.io/plaid/495a9b00-b9e9-435b-abd7-4bb394518da2/mastra-plaid.png" alt="mastra-plaid.png"></p>
<p>Mastra is a strong choice for most TypeScript AI Agent development. I’ll focus on two especially valuable features: Memory and Stream.</p>
<h2><strong>Memory</strong></h2>
<p>Building Mastra‑like Memory from scratch would have been unrealistic. Memory is essentially chat history, but with options essential to AI Agents. All AI Agents available in the KARTE admin UI include Memory.</p>
<h3>Resources and Threads</h3>
<p>A thread contains multiple messages; passing past thread messages to the LLM as context reduces prompt writing and prevents repeated mistakes. A resource groups multiple threads. In KARTE, we restrict chat messages viewable per admin user. Even within the same tenant, users cannot access others’ instructions to KARTE AI. We include the authenticated user’s ID as a prefix in resource IDs to prevent viewing others’ histories.</p>
<h3>Processor</h3>
<p>Memory processors modify the message list before adding it to the agent’s context window and sending to the LLM. This helps manage context size, filter content, and optimize performance. KARTE agents use a</p>
<h3>TokenLimiter</h3>
<p>Processor that limits how far back to include past messages so total tokens stay within the LLM’s limit.</p>
<h3>Semantic Recall</h3>
<p>This retrieves semantically similar past history to include as context for a user’s question or instruction. It supports cross‑thread recall, searching across accessible threads. Technically it uses RAG. We tried it once, but a MongoDB bug at the time (quickly fixed) kept us from using it. Having such features available and ready in Mastra is a big plus for future needs.</p>
<h3>Message Conversion</h3>
<p>Vercel AI SDK moved from v4 to v5 with significant message format changes. We needed v4‑saved chat messages to work under v5. Mastra handles this compatibility internally, making the migration smooth.</p>
<h2><strong>Stream</strong></h2>
<p><a href="https://mastra.ai/blog/mastra-streaming">The next evolution of Mastra streaming ↗</a></p>
<p>Mastra implements its own streaming (“Mastra streaming”). With complex setups like multi‑agent or workflows, Frontend needs good visualization. Previously, an agent’s Stream method returned streams defined by the AI SDK stream protocol, which couldn’t stream outputs from LLM calls inside workflows or inside tools. Mastra streaming can handle nested LLM outputs as streams. In KARTE’s admin UI, our multi‑agent setup calls agents from tools, and we stream tool outputs.</p>
<p>Mastra converts Mastra streaming into types compatible with Vercel AI SDK v5’s stream protocol. While the protocol lacks parts for streaming tool outputs, Mastra achieves compatibility using Custom Data.<a href="https://ai-sdk.dev/docs/ai-sdk-ui/streaming-data">Streaming Custom Data ↗</a><br>
Developers can define custom data types, which improves DX.</p>
<p>Mastra will likely support AG‑UI and is developing <code>@mastra/react</code>, making UIs that leverage Mastra’s features easier to build.</p>
<h1><strong>Conclusion</strong></h1>
<p>To continuously develop AI features in KARTE’s microservices environment, we designed and operated an AI foundation using Mastra in a <strong>centralized</strong> model first. Centering the foundation on Mastra brings major advantages: rapid, continuous feature additions and usability improvements without building everything ourselves.</p>
<p>The balance between centralized and decentralized will evolve. As AI development skills spread across the Product org and we learn to build multi‑agent networks quickly and securely across services, we’ll gradually <strong>decentralize</strong>. KARTE’s microservices should also evolve to ease AI development—for example, implementing auth in Internal APIs or offering internal MCP.</p>


Learn how PLAID designed a centralized AI foundation with Mastra in a microservices architecture—covering tools, memory, storage, streaming, and frontend integration.

Designing an AI Foundation with Mastra in a Microservices Architecture

KARTEのマイクロサービス環境でのAI基盤設計を解説。Mastraを核に「まず集中」を採用し、Tool/Storage設計、Memory/Streamingの実践と運用知見を紹介。

マイクロサービスアーキテクチャにおける Mastra を活用した AI 基盤設計

3ヶ月の開発インターンで取り組んだタスクや、そこから得た学びについて紹介します。

プレイドインターン体験記：管理画面から配信基盤までを横断した機能開発

<p>こんにちは。プレイドの@sdaikichiです。現在のトレーナーレベルは22、捕まえたポケモンは103種です。</p>
<p><a href="/2016_08_24_uitest_automation/">前回の@positiveflatの記事</a>ではプレイドにおける自動テスト環境をご紹介しました。</p>
<p>今回は、プレイドが</p>
<ul>
<li>__40通り以上の環境__を対象に</li>
<li>__すべて自動__で</li>
<li>ついでに__CircleCIのコンテナリソースもそんなに使わない__で</li>
</ul>
<p>マルチブラウザテストを実現している環境についてご紹介します。</p>
<h2>目次</h2>
<ul>
<li>なぜマルチブラウザテストが必要なのか</li>
<li>BrowserStackの紹介</li>
<li>運用してみてわかったコツ</li>
<li>まとめ</li>
<li>最後に</li>
</ul>
<h2>なぜマルチブラウザテストが必要なのか</h2>
<p>KARTEをお客様が利用する際には、来訪者をトラッキングしたり接客サービスを表示するためのscriptタグをお客様サイトに埋め込んでいただきます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ae5043c1-f735-4ca2-94e4-98f14d0f5371/2dd29a3e-b556-4503-afe4-04ac37414d8c.png" alt=""><br>
(接客サービス配信のイメージ)</p>
<p>お客様サイトには当然様々な環境(OS,ブラウザ,端末...)の来訪者がいらっしゃいます。</p>
<p>その際に特定のブラウザでのみ意図した挙動をしない、といった事態は当然避ける必要があります。<br>
世のフロントエンドエンジニアの皆様はIE対応というワードを聞いただけで__仕事を放り投げて目黒川にミニリュウを捕りに行きたくなる衝動に駆られる__かと存じますが、KARTEではそうはいきません。</p>
<p>全ての環境をトラッキングや接客サービス配信の対象としているわけではありませんが、どんな環境でもScriptの実行はされるため、古いブラウザとはいえエラーの発生などは防ぐ必要があります。</p>
<p>例えば有名なのがこちら。この構文が紛れ込んでしまうだけでIE6,7でSyntaxErrorが発生してしまいます。</p>
<pre><code>var data = { hoge:1, fuga:2, piyo:3, }; // オブジェクトリテラル末尾のカンマ
</code></pre>
<p>エンジニアが気をつけていても、例えば依存ライブラリの更新などでこういったエラーが入り込む可能性があります。<br>
かといってこういったエラーにエンジニアが過度に敏感になると開発スピードが著しく落ちてしまいます。</p>
<p>そこで、これまであったトラブルや考えうるケースを抽象化し、CircleCI上でマルチブラウザのテストを行おう！ということになりました。</p>
<h2>BrowserStackの紹介</h2>
<p>マルチブラウザテストの実行には<a href="https://www.browserstack.com/">BrowserStack</a>の<a href="https://www.browserstack.com/automate">Automate</a>を利用しています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cf010a08-183d-4aec-b779-074ac181b4e8/afefb92d-4bda-4f9f-a967-8dc6cc9d8c6e.png" alt=""><br>
このサービスの特徴として</p>
<ul>
<li>
<p><a href="https://www.browserstack.com/list-of-browsers-and-platforms?product=automate">かなり自由度の高い組み合わせのOS/ブラウザ/端末が用意されており</a>、設定ファイルに追記するだけで簡単にテスト対象を追加できます。</p>
</li>
<li>
<p>管理画面も非常に充実しており、Selenium testではなんと <strong>実行画面を全て録画し、動画として管理画面上で再生することができます</strong>。<br>
これにより不便になりがちなCI環境のSelenium Testのデバッグが格段に行い易くなりますし、コマンドラインに表示されるテスト結果からはわからない各ブラウザでの細かい表示の違いなどにも気付きやすくなります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/daff3600-92f5-4f18-9a1f-d35592fedcce/1064fcae-374b-4b3e-b823-0c9794020dc4.png" alt=""></p>
</li>
<li>
<p>Javascript Testing(ブラウザ上で行うユニットテスト)、Selenium Testing(Selenium webdriverを利用したUIのテスト)に対応しています。</p>
</li>
</ul>
<p>テスト対象はブラウザ上で動作するJavascriptですが、メソッドごとのユニットテストはJavascript Test、接客サービスの表示・操作などUI的な部分はSelenium Testと、観点によりテストを分けています。</p>
<h2>Javascript Test</h2>
<p>BrowserStackのJavascript Testを利用するにあたり、様々なライブラリが公開されています。<br>
https://www.browserstack.com/javascript-testing-api<br>
プレイドでは<a href="https://github.com/browserstack/browserstack-runner">BrowserStack Runner</a>を利用しています。</p>
<p>BrowserStack Runnerはjsonの設定ファイルに</p>
<ul>
<li>実行するテスト対象ファイル</li>
<li>テストフレームワーク(mocha, jasmine, qunit)</li>
<li>対象ブラウザ</li>
</ul>
<p>などを指定するだけでテストを実行してくれるため、簡単に導入することができます。</p>
<p>jsonの設定ファイルを切り替えれば、たとえばサービスの対象ブラウザ用のテストと非対象ブラウザ用のテストを用意して、それぞれ別に実行することができます。</p>
<p>target.json</p>
<pre><code class="language-json">{
    &quot;username&quot;: &quot;yourusername&quot;,
    &quot;key&quot;: &quot;youraccesskey&quot;,
    &quot;test_path&quot;: &quot;target_browser_test.html&quot;,
    &quot;test_framework&quot;: &quot;mocha&quot;,
    &quot;browsers&quot;:[
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Firefox&quot; , &quot;browser_version&quot;: &quot;47&quot;},
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Chrome&quot;, &quot;browser_version&quot;: &quot;51&quot; },
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;Edge&quot;, &quot;browser_version&quot;: &quot;13&quot; }
    ]
}
</code></pre>
<p>no_target.json</p>
<pre><code class="language-json">{
    &quot;username&quot;: &quot;yourusername&quot;,
    &quot;key&quot;: &quot;youraccesskey&quot;,
    &quot;test_path&quot;: &quot;no_target_browser_test.html&quot;,
    &quot;test_framework&quot;: &quot;mocha&quot;,
    &quot;browsers&quot;:[
        { &quot;os&quot;: &quot;Windows&quot;, &quot;os_version&quot;:&quot;10&quot;, &quot;browser&quot;: &quot;IE&quot; , &quot;browser_version&quot;: &quot;7.0&quot;},
        { &quot;os&quot;: &quot;OS X&quot;, &quot;os_version&quot;:&quot;El Capitan&quot;, &quot;browser&quot;: &quot;Safari&quot;, &quot;browser_version&quot;: &quot;9.1&quot; },
        {&quot;os&quot;: &quot;ios&quot;, &quot;os_version&quot;: &quot;9.3&quot;, &quot;device&quot;: &quot;iPhone 6S&quot;},
    ]
}
</code></pre>
<p>設定ファイルはBROWSERSTACK_JSONという環境変数を読みにいきます。<br>
CircleCIではコマンド実行時の環境変数をcircle.ymlで簡単に指定することができるので、以下のように記述すればOKです。</p>
<pre><code class="language-yml">test:
  override:
    browserstack-runner:
      BROWSERSTACK_JSON: target.json
    browserstack-runner:
      BROWSERSTACK_JSON: no_target.json
</code></pre>
<p>実行すると管理画面にはこのように結果が表示されます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3a74810e-8958-499d-8678-1ea451173cf1/7741e0d3-ab45-4fa2-bebf-7683fde93f07.png" alt=""></p>
<h2>Selenium test</h2>
<p>Selenium testは、自サーバに用意したテストページにアクセスして行っています。<br>
このページにはお客様にサイトに埋め込んでいただくScriptが置かれており、実際の接客サービスの配信やエラーの有無などを確認することができます。</p>
<p>BrowsesrStackからローカル(この場合CircleCIのサーバー)にアクセスさせるために<a href="https://www.browserstack.com/local-testing#command-line">BrowserStack Local</a>をダウンロードし、実行しておきます。</p>
<pre><code class="language-YAML">dependencies:
  pre:
    - cd /usr/local/bin;
    sudo wget &quot;https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip&quot;;
    sudo unzip BrowserStackLocal-linux-x64.zip;
    sudo rm BrowserStackLocal-linux-x64.zip;
test:
  pre:
    - /usr/local/bin/BrowserStackLocal youraccesskey:
      background: true
</code></pre>
<p>テストコードの中でBrowserStackを利用するようにselenium webdriverのcapabilityを指定します。</p>
<pre><code class="language-coffee">CAPABILITIES = [
  { os: 'Windows', os_version:'10', browserName: 'Edge'}
  { os: 'Windows', os_version:'10', browserName: 'IE', browser_version: '11.0' }
  { os: 'OS X', os_version:'El Capitan', browserName: 'Safari' }
  { os: 'OS X', os_version:'El Capitan', browserName: 'Firefox' }
  { browserName: 'iPhone', platform: 'MAC', device: 'iPhone 6S Plus', emulator: true } #emulator: trueの理由は後述
  { browserName: 'iPhone', platform: 'MAC', device: 'iPhone 6S', emulator: true}
]

CAPABILITIES.forEach (capability) -&gt;
  before -&gt;
     @driver = new webdriver.Builder()
        .usingServer('http://hub-cloud.browserstack.com/wd/hub')
        .withCapabilities(capabilities)
        .build()
  #以下テストケースを記述。
  #ローカルへのアクセスが発生する部分のURLはlocalhostでOK
</code></pre>
<h2>運用してみてわかったコツ</h2>
<h3>BrowserStackでのテスト並列化</h3>
<p><a href="/2016_08_24_uitest_automation/">前回の記事</a> ではCircleCIのコンテナ追加による並列化・高速化について触れました。<br>
BrowserStackのSeleniumテストも、ローカルやCIで行う場合と同様、時間がかかります。<br>
しかしながらBrowserStack AutomateのSelenium Testは実行はBrowserStackのサーバ上で行われるため、手元のリソース(CircleCiのコンテナ)は必要ありません。</p>
<p>逆に言いますと、ボトルネックになるのはBrowserstack側の並列上限数です。<br>
1〜25の並列数で<a href="https://www.browserstack.com/pricing">Pricingが用意されています</a> 。サービス規模やリポジトリへのpush頻度にあわせて選ぶと良いでしょう。</p>
<p>プレイドでは契約した並列数に合わせてCircleCI上でテストを__すべてバックグラウンドで実行する__shell scriptを記述し、circle.yml上で実行しています。</p>
<h3>Mobileは自由度低め</h3>
<p>Mobileのテスト環境はPCに比べ、自由度が若干落ちます。<br>
PCがOS/Browser、それらのバージョンを自由に組み合わせて使えるのに対して、Mobileは端末/OS/Browser及びそれらのバージョンは固定です。それでも圧倒的なバリエーションですが。<br>
また、最近エミュレーターではなく実機でのテストがリリースされたようですが、こちらを試してみたところまだ動作が不安定だったため、プレイドでは導入を一旦見送っています。（これがSelenium Testでのemulator:true の理由）</p>
<h3>Retry機構は必要</h3>
<p>BrowserStackではたまにインスタンス・エミュレータの起動に失敗することがあるようで、1ケースも実行されずタイムアウトで落ちることがあります。<br>
そのため、プレイドでは各環境のテストが失敗した際には3回までのRetryを行っています。<br>
ここは開発速度とのトレードオフで現在も試行錯誤中です。</p>
<h2>まとめ</h2>
<p>以上、プレイドにおけるマルチブラウザテストについてご紹介いたしました。<br>
<code>{ os: 'OS X', os_version:'Snow Leopard', browserName: 'Firefox' }</code>  のような、シェアの低さゆえにもし問題が起こるとしたらかなり気付くのが遅れそうな環境でも手軽にテスト対象に加えられるようになったのは大きいと思います。</p>
<p>もちろん、まだまだテストケースをはじめテスト環境も改善を加えていきます。</p>
<p>ウチはこんなことやってるよ！といった事例がございましたらぜひぜひシェア時にコメントくださいませ！</p>
<h2>最後に</h2>
<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>


CircleCI上で、BrowserStackを利用したマルチブラウザJavascript Test,Selenium Test を実現している方法についてご紹介します。Selenium webdriver, CircleCI, BrowserStack

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する| PLAID engineer blog

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

<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でオフィスの温度と湿度を可視化する

Engineer Blog

Recent Article

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

スピード重視の開発体制を実現するための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

40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する

スピード重視の開発体制を実現するための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 〜インフラ編〜を開催しました！