Engineer Blog

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

プレイドでエンジニアをしている田宮です。今回は Cloud Logging と BigQuery 用いて開発した 監査ログ の紹介をします。

マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装 - 収集編

<h1>はじめに</h1>
<p>こんにちはプレイドの<a href="https://cxclip.karte.io/products/info/message-beta/">KARTE Message</a>チームでエンジニアをしている<a href="https://x.com/prooooograming">土谷</a>です。</p>
<p>今回は大量メール配信を実現するためにKARTE Messageで取っている仕組みを紹介していきます。</p>
<h1>KARTE Messageについて</h1>
<p>本題に入る前に、まずKARTE Messageについて説明します。</p>
<p>KARTE Messageはマルチチャネル(Mail/アプリPush/LINE *)での大量配信を行えるMAツールとなっており、主に以下の機能を備えています。</p>
<ul>
<li>配信の管理
<ul>
<li>配信対象抽出の設定</li>
<li>配信コンテンツの設定・コンテンツへの埋め込み</li>
<li>配信速度・頻度の管理</li>
</ul>
</li>
<li>配信対象の管理
<ul>
<li>誰に配信するのかを取り扱うための配信対象を管理するためのリスト機能</li>
<li>リストに対するフィルタリング機能</li>
<li>リスト同士を組み合わせて配信対象を絞り込む機能</li>
</ul>
</li>
<li>配信コンテンツの管理
<ul>
<li>配信コンテンツをテンプレートとして管理</li>
</ul>
</li>
</ul>
<p>これらの機能に加えてKARTEの特有の機能を利用した配信対象の抽出などもできるようになっています。</p>
<p>* LINEとの連携機能は現状β版として提供しています。</p>
<h1>このブログで出てくる用語</h1>
<p>まずメール配信においてよく使われる用語の説明をします。理解している人は読み飛ばしてください。</p>
<p><code>Eメール</code> : 一般的にEメールはマーケティングメールとトランザクションメールに大別できます。</p>
<p><code>マーケティングメール</code> : 受信者がアクションをしていなくても送信者側が能動的に送信するメールです。メルマガ配信やクーポンメールなど。</p>
<p><code>トランザクションメール</code> :  受信者が何かしらのアクションを起こした時に受等的に送信するメールです。ログインメールやパスワードリセットメールなど。</p>
<p><code>メールバウンス</code> : 送信したメールが何らかの理由で相手のメールサーバーに拒否されて、送信者に戻ることです。メールバウンスはハードバウンスとソフトバウンスに大別できます。</p>
<p><code>ハードバウンス</code> : メールの拒否理由が恒久的な問題の場合のメールバウンスのことです。メールアドレスが存在しないなど。</p>
<p><code>ソフトバウンス</code> : メールの拒否理由が一時的な問題の場合のメールバウンスのことです。受信者のメールボックスがいっぱいなど。</p>
<p><code>IP/ドメインレビュテーション</code> : メール送信時に利用するサーバーのIPアドレスやFromドメインに対して付けられる評価をレピュテーションと呼びます。スパムメールのようなメールをたくさん配信しているとレピュテーションが下がり、メールプロバイダー(GmailやYahoo!メールなど)から受信を拒否される場合があります。レピュテーションの管理はメールプロバイダーがやっていたり、第三者機関がやっていたり、さまざまなパターンがあります。</p>
<p><code>SPF</code> : SPFレコードというDNSレコードを利用して、送信されたメールの送信元IPを確認することで送信者がなりすましをしていないかを確認する仕組みです。</p>
<p><code>DKIM</code> : DKIMレコードというDNSレコードを利用して、送信されたメールの内容が第三者に改竄されていないことを確認する仕組みです。</p>
<p><code>DMARC</code> : SPF/DKIMの確認に引っかかった時に、どのように対応すべきかを送信元のサーバーが表明しておく仕組みです。</p>
<h1>大量メール配信の運用における課題</h1>
<p>マーケティングメールが大量に送信されている現在の環境では、同様に大量のスパムメールも送信されています。メールプロバイダーはメールの大量送信に対して、スパムメールかどうか・送信者がスパマーではないかという判定を厳しく行なっています。</p>
<p>そのためマーケティングメールをエンドユーザーに届けるためには、送信したメールがスパムメールでないことを証明する必要があります。</p>
<p>メールプロバイダーは送信されたメールがスパムメールでないことを確認するために、以下のような項目を確認しています。</p>
<ul>
<li>SPF/DKIM/DMARCの設定確認
<ul>
<li>これらのDNSレコードの設定がされていないとスパムメールと判断される場合があります。</li>
</ul>
</li>
<li>IPレピュテーション・ドメインレピュテーションの確認
<ul>
<li>送信元のIPレピュテーションやドメインレピュテーションが低いと、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メールコンテンツの正当性の確認
<ul>
<li>メール内のコンテンツにhttpのセキュアではないリンクがあったり、不審なスクリプトなどが含まれていたりすると、スパムメールと判断される場合があります。</li>
</ul>
</li>
<li>メール配信量の急増の検知
<ul>
<li>特定IPからのメールの配信量が急増すると、スパムメールと判断される場合があります。</li>
</ul>
</li>
</ul>
<p>上記のようなスパムメールかどうかの大量のチェックが各メールプロバイダーごとで設定されているため、マーケティングメールをエンドユーザーに届けることが簡単ではないことが課題となっています。</p>
<h1>KARTE Messageにおける大量のメールをエンドユーザーに届けるための仕組み</h1>
<p>ここからは、KARTE Messageで行なっているマーケティングメールを正常にエンドユーザーに届けるための仕組みを紹介します。</p>
<h2>AWS SESを利用したマルチテナント構成</h2>
<p>大量メール配信においてIPレピュテーションを高く保つことは、上述した通り非常に重要です。これを実現するには、スパムメールと判定される可能性のある質の低いメールの送信を極力避け、メールプロバイダーに確実に受信される質の高いメールを送信する必要があります。</p>
<p>そのため、質の高いメールの配信量を最大限に増やすことが有効なアプローチの一つです。これにより、仮に少量の質の低いメールが送信されたとしても、全体におけるその割合を低く抑えることができ、結果としてIPレピュテーションを高く維持することにつながります。</p>
<p><img src="https://ik.imagekit.io/plaid/913abcd7-570a-481a-bc9b-b9cb0c8ff3e4/blog_image1.png" alt="blog_image1.png"></p>
<p>KARTE Messageでは、それを実現する仕組みとしてマルチテナントなメール配信を行なっており、KARTE Messageが所有しているIPアドレスをクライアントごとに固定せず、全てのIPに均等に振り分けて送信しています。</p>
<p><img src="https://ik.imagekit.io/plaid/c3e46daa-6c2d-4f66-b27e-b7a349813334/blog_image2.png" alt="blog_image2.png"></p>
<p>結果として冒頭で述べた通り、KARTE Messageを利用しているクライアント全配信量が母数となるので、特定のクライアントで質の低いメールが多少送信されても影響を小さくすることができます。</p>
<p>また、複数のクライアントの配信をKARTE MessageのIPで送信しているため、配信はほぼ24時間常に行われています。そのため、1クライアントが急な大量配信をしたとしてもKARTE Message全体では配信量の急増にはなりにくく、メール配信量の急増によるIPレピュテーションの低下を防ぐことができ、送信されたメールもスパムメールと判定されづらくなります。</p>
<p>こういったIPレピュテーションの運用は、1クライアントでやろうとすると配信量や配信時間の問題で運用が難しくなる場合があります。KARTE Messageではマルチテナント配信にすることで、その運用負荷をクライアントから取り除いています。</p>
<h2>まとめ</h2>
<p>マルチテナント配信以外にも、KARTE Messageではメール配信の細かなモニタリングを行ったり、SPF/DKIM/DMARCの設定の補助機能なども提供することで、なるべくマーケティングメールの運用負荷を下げるような機能提供を行なっています。</p>
<p>KARTE Messageでは、メールという長年コミュニケーションツールとして中心になっている技術であるからこそ難しくなっている部分を管理することで、価値を届けるプロダクトを作っています。</p>
<p>興味がある方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。お待ちしております！</p>


KARTE MessageというMAツールでメールの大量配信を安定的に行うためのシステム設計やIP運用の考え方などを説明

KARTE Messageで採用している大量配信を実現するためのアーキテクチャ

KARTE Messageの大量メール配信を支える技術

こんにちは！10月初旬から4月末までの7ヶ月間、ソフトウェア開発のインターンとしてプレイドで働いていた[上野海吏](https://x.com/kairi_noel)(@kairi_noel)です。

プレイドで7ヶ月間の開発インターンで体験したことと得られた学び

AIエージェントによるセキュリティレビューの試みを紹介します。

AIエージェントによるセキュリティレビューことはじめ

この記事では、MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーションシステムについて解説します。

MongoDB Atlas Stream Processing を使った BigQuery へのレプリケーション

Rollupのビルド時間を10倍高速化することでプレビュー表示を改善した話

プレイドインターン体験記：インターンを通じて得た技術力と開発力の学び

<h1>はじめに</h1>
<p>この記事は <a href="https://qiita.com/advent-calendar/2024/datadog">Datadog Advent Calendar 2024</a> の 18 日目の記事です。<br>
こんにちは、プレイドの 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 の CI Visibility は CI のパフォーマンスを可視化できるプロダクトです。 GitHub Actions や CircleCI など多くのインテグレーションがサポートされていますが、GCP の CloudBuild はサポートされていません。また、CloudBuild には継続的にパフォーマンスを可視化できるような機能がありません。</p>
<p>そこで、CloudBuild のパフォーマンスを <a href="https://docs.datadoghq.com/api/latest/ci-visibility-pipelines/">CI Visibility の API</a> を活用して計測することにしました。</p>
<h1>CI Visibility とは</h1>
<p>CI Pipeline のパフォーマンスを可視化します。APM のように、Pipeline トレースを可視化できるところが大きな利点だと思っていて、他にもさまざまな機能がサポートされています。サポートされる機能は、プロバイダごとに異なり、<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#supported-features">こちら</a>で確認することができます。弊社では主に GitHub Actions と CircleCI を利用していますが、GitHub Actions では Step spans や Queue time、Infrastructure metric correlation がサポートされているのに対して、CircleCI ではそれらがサポートされておらず、ボトルネックの特定が難しかったりします。GitHub Actions や CircleCI 自体にもこのような Insight の機能は備わっているのですが、Datadog では使い慣れたクエリで柔軟に集計したり、Dashboard や Monitor との連携もできるので、なるべく Datadog を使うようにしています。</p>
<p>ちなみに CloudBuild は Integration はサポートされていないので OTHER CI PROVIDER というところに書いてある機能が使えます。</p>
<h1>CI Visibility Event の Level について</h1>
<p>CI Visibility には Event という形でデータを送ります。Event には Pipeline, Stage, Job, Step の4段階の Level があります。</p>
<p>Pipeline は Stage をまとめたもの、Stage は Job をまとめたもの、Job は Step をまとめたもの、というように階層構造になっています。<a href="https://docs.datadoghq.com/continuous_integration/pipelines/?tab=githubactions#terminology">こちら</a>にプロバイダごとの対応づけが書かれています。例えば GitHub Actions であれば下記の対応になります。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>GitHub Actions</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Workflow</td>
</tr>
<tr>
<td>Job</td>
<td>Job</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>CloudBuild のパフォーマンスを可視化するにあたっては、下記のように Level を対応づけました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>CloudBuild</th>
</tr>
</thead>
<tbody>
<tr>
<td>Pipeline</td>
<td>Build</td>
</tr>
<tr>
<td>Stage</td>
<td>キューに格納・ソースの取得・全てのビルドステップ・（ある場合は）イメージの PUSHの4つのステージ</td>
</tr>
<tr>
<td>Step</td>
<td>Step</td>
</tr>
</tbody>
</table>
<p>Pipeline や Step に関しては議論の余地はあまりなさそうです。Stage という単位は別に使わなくても良いのですが、実際に可視化してみると最初の Step が実行されるまでにかなり時間がかかっていて、その内訳も知れた方が良いと感じたので導入しました。</p>
<p>また、階層構造さえあっていれば可視化はできるので、Stage ではなく Job としてこれらを表現してもよかったのですが、CircleCI や GitHub Actions における Job とはかなり別物という感覚があったので Stage として表現しました。</p>
<p>CircleCI や GitHub Actions では Job は1つのコンテナ（もしくは VM）実行環境という単位になっています。そのため異なる Job 間ではボリュームの永続化などは明示的に書く必要があります。CloudBuild においては、1つの Build 内で複数の実行環境を立ち上げることはなく、前の Step で書き込まれたディスクには後続の Step でアクセスすることができます。</p>
<p>Stage がしっくりくるかというとわからないのですが、消去法で決めました。</p>
<h1>実装</h1>
<p>各所要時間をどの Level として送るかが決まったので、実装のステップに入ります。</p>
<p>CloudBuild は、実行の各タイミングで Cloud PubSub にイベントを送っています。PubSub イベントをトリガーに Cloud Run Functions を実行することができるので、今回は Cloud Run Functions で実行することにしました。他の方法としては、定期実行して特定の期間内に実行された CI Pipeline の結果を送るというやり方もありそうですが、パフォーマンス改善タスクに取り組む際にはなるべく早く結果が可視化できた方が良いというのもあり、上記の手法にしました。</p>
<h2>Queue Time</h2>
<p>Queue Time は startTime から createTime を差し引いた時間としています。また、Pipeline の attribute にも queueTime がありますが、GitHub Actions のような良い感じの可視化がされなかったので、Stage としても実装しました。</p>
<p>GitHub Actions の Queue time の良い感じの可視化:<br>
<img src="https://ik.imagekit.io/plaid/97e233cd-f4e8-4928-8c08-220bed39e581/github-actions-queue.png" alt="github-actions-queue.png"></p>
<h2>Status</h2>
<p>Cloud Build における Status と、CI Visibility Pipeline で定義されている Status はちょっと違うので、注意が必要です。</p>
<p>Ci Visibility Pipeline で定義されている status は下記になります。</p>
<table>
<thead>
<tr>
<th>Level</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>Step</td>
<td>success, error</td>
</tr>
<tr>
<td>Stage, Job</td>
<td>success, error, canceled, skipped</td>
</tr>
<tr>
<td>Pipeline</td>
<td>success, error, canceled, skipped, blocked, running</td>
</tr>
</tbody>
</table>
<p>Cloud Build の場合、 <code>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED, EXPIRED</code> があります。</p>
<p>今回のユースケースとしては実行中の Pipeline に関しては対象外としても良いかなと思ったので、完了後のステータス（ <code>SUCCESS, FAILURE, INTERNAL_ERROR, TIMEOUT, CANCELLED</code> ）のイベントが来た時だけ処理を実行するようにしました。</p>
<table>
<thead>
<tr>
<th>Datadog</th>
<th>Cloud Build</th>
</tr>
</thead>
<tbody>
<tr>
<td>success</td>
<td>SUCCESS</td>
</tr>
<tr>
<td>error</td>
<td>FAILURE, INTERNAL_ERROR, TIMEOUT</td>
</tr>
<tr>
<td>canceled</td>
<td>CANCELED</td>
</tr>
<tr>
<td>処理しない</td>
<td>STATUS_UNKNOWN, PENDING, QUEUE, WORKING, EXPIRED</td>
</tr>
</tbody>
</table>
<h2>Git</h2>
<p>CI Visibility Pipeline では git というフィールドに git repository の url や commit sha、authorEmail などを入れることができます。sha や repo url は Cloud Build のイベントに入ってるのですが、authorEmail は取り出せなかったので適当に入れました。GitHub API を叩いて commit sha から authorEmail を取得する方法もあると思いますが、実行者が気になったら commit のページに飛べば良いのでそこまでしなくても良いと判断しました。</p>
<h2>ソースコード</h2>
<p>最終的なソースコードは下記のようになります。依存ライブラリをインストールしてビルドすれば別の環境でも動くと思うので、ぜひ試してみてください。注意点としては <code>DD_API_KEY</code> と <code>DD_APP_KEY</code> を secret として Cloud Run Functions で読み込めるようにする必要があるのと、Datadog で us1 以外のリージョンを使っている場合には <code>DD_SITE</code> 環境変数を指定する必要があります。</p>
<pre><code class="language-typescript">/**
 * Cloud Build 終了後に Datadog にイベントを送る
 */

import { PubsubMessage } from '@google-cloud/pubsub/build/src/publisher';
import { google } from '@google-cloud/cloudbuild/build/protos/protos';
import { client, v2 } from '@datadog/datadog-api-client';

type Build = google.devtools.cloudbuild.v1.Build;
type Status = keyof typeof google.devtools.cloudbuild.v1.Build.Status;

export async function main(event: PubsubMessage): Promise&lt;void&gt; {
  const jsonstr = Buffer.from(event.data as string, 'base64').toString();

  const data = JSON.parse(jsonstr) as Build;

  if (!isFinishedStatus(data.status as Status)) {
    console.log('event does not meet conditions.');
    return;
  }

  // pipeline
  const { status, createTime, startTime, finishTime, id, logUrl } = data;
  const triggerName = data.substitutions['TRIGGER_NAME'];
  const commitSha = data.substitutions['COMMIT_SHA'];
  const repositoryUrl = data.substitutions['REPO_FULL_NAME'];
  const queueTime = startTime
    ? new Date(startTime as string).getTime() - new Date(createTime as string).getTime()
    : undefined;

  const configuration = client.createConfiguration();
  configuration.unstableOperations['v2.createCIAppPipelineEvent'] = true;
  const apiInstance = new v2.CIVisibilityPipelinesApi(configuration);
  const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
    body: {
      data: {
        attributes: {
          resource: {
            end: finishTime ? new Date(finishTime as string) : new Date(),
            start: new Date(createTime as string),
            name: triggerName,
            status: getDatadogPipelineStatus(status as Status),
            level: 'pipeline',
            uniqueId: id,
            url: logUrl,
            git: {
              sha: commitSha,
              repositoryUrl,
              authorEmail: 'unknown@example.com',
            },
            partialRetry: false,
            queueTime,
          },
          service: 'cloud-build',
        },
        type: 'cipipeline_resource_request',
      },
    },
  };
  const result = await apiInstance.createCIAppPipelineEvent(params);

  // stage
  const stages = Object.entries(data.timing).map(([key, timing]) =&gt; {
    return {
      id: key,
      startTime: timing.startTime,
      endTime: timing.endTime,
    };
  });

  const stagesIncludeQueueTime = [
    ...stages,
    {
      id: 'QUEUE',
      startTime: createTime,
      endTime: startTime,
    },
  ];

  for (const stage of stagesIncludeQueueTime) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: stage.endTime ? new Date(stage.endTime as string) : new Date(),
              start: new Date(stage.startTime as string),
              name: stage.id,
              status: 'success',
              level: 'stage',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              id: stage.id,
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // step
  for (const step of data.steps) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: step.timing?.endTime ? new Date(step.timing.endTime as string) : new Date(),
              start: new Date(step.timing!.startTime as string),
              name: step.id!,
              status: getDatadogStepStatus(step.status as Status),
              level: 'step',
              id: step.id!,
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'BUILD',
              stageName: 'BUILD',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }

  // image
  for (const image of data.results?.images ?? []) {
    const params: v2.CIVisibilityPipelinesApiCreateCIAppPipelineEventRequest = {
      body: {
        data: {
          attributes: {
            resource: {
              end: image.pushTiming?.endTime ? new Date(image.pushTiming.endTime as string) : new Date(),
              start: new Date(image.pushTiming!.startTime as string),
              name: image.name!,
              id: image.name!,
              status: 'success',
              level: 'step',
              pipelineUniqueId: id,
              pipelineName: triggerName,
              url: logUrl,
              stageId: 'PUSH',
              stageName: 'PUSH',
            },
            service: 'cloud-build',
          },
          type: 'cipipeline_resource_request',
        },
      },
    };
    const result = await apiInstance.createCIAppPipelineEvent(params);
  }
}

function isFinishedStatus(status: Status): boolean {
  return ['SUCCESS', 'FAILURE', 'INTERNAL_ERROR', 'TIMEOUT', 'CANCELLED'].includes(status);
}

function getDatadogPipelineStatus(status: Status): 'success' | 'error' | 'canceled' {
  if (status === 'SUCCESS') {
    return 'success';
  } else if (status === 'CANCELLED') {
    return 'canceled';
  } else {
    return 'error';
  }
}

function getDatadogStepStatus(status: Status): 'success' | 'error' {
  if (status === 'SUCCESS') {
    return 'success';
  } else {
    return 'error';
  }
}

</code></pre>
<h1>Datadog CI Visibility でみてみる</h1>
<p>こんな感じで Cloud Build のパフォーマンスを可視化することができました。Critical Path を特定し、最もボトルネックになっている step を効率的に改善することができるようになりました！</p>
<p><img src="https://ik.imagekit.io/plaid/56474a37-da8b-423f-bbf9-965d86aee2c3/datadog-ci-visibility.png" alt="datadog-ci-visibility.png"></p>
<p>具体的な改善ポイントとしては下記のようなものがありそうです。Stage を可視化することで、よりパフォーマンス改善の選択肢が増えると思います。</p>
<table>
<thead>
<tr>
<th>時間がかかっている Stage</th>
<th>改善手段の例</th>
</tr>
</thead>
<tbody>
<tr>
<td>QUEUE</td>
<td>Cloud Build の同時実行数を増やす、Private Pool を使う</td>
</tr>
<tr>
<td>FETCH_SOURCE</td>
<td>リポジトリを分割する</td>
</tr>
<tr>
<td>BUILD</td>
<td>キャッシュを使う、並列化する</td>
</tr>
<tr>
<td>PUSH</td>
<td>イメージサイズを小さくする、Artifact Registry と Cloud Build の実行のリージョンを合わせる</td>
</tr>
</tbody>
</table>
<h1>最後に</h1>
<p>Cloud Build のパフォーマンスを Datadog CI Visibility で可視化する方法を紹介しました。</p>
<p>Datadog は各種 Integration 対応が充実していると思いますが、未対応であってもこんな感じで提供されてる API を使って気軽に実装できるのが嬉しいところです。</p>
<p>Cloud Build と Datadog を使っていて、パフォーマンスの改善をしたいと考えている方がいたら参考にしていただけると幸いです！</p>


この記事は Datadog Advent Calendar 2024 の 18 日目の記事です。 こんにちは、プレイドの Developer Experience & Performance チームでエンジニアをしている大矢です。Datadog の好きな機能は CI Visibility と Split Graphです。

Datadog CI Visibility で Cloud Build のパフォーマンスを可視化する

プレイドでエンジニアをしている塩澤です。今回は MongoDB から BigQuery へのリアルタイムレプリケーションシステムをマネージドサービスのみを用いて開発したので紹介します。

MongoDB to BigQuery: フルマネージドなリアルタイムレプリケーションの実現

<h1>はじめに</h1>
<p>初めまして、<a href="https://github.com/jdkfx">田添春樹</a>と申します。2024年9月から12月までの3ヶ月間、KARTE Webチームでエンジニアとしてインターンシップを行なっておりました。</p>
<p>インターンシップに参加する以前、趣味で関わっていたOSSプロジェクトにおいて、Vueを用いた開発を行なっておりました。その際の開発経験が楽しかったことと、これからもVueを用いて開発を行いたいことなどを、プレイドに勤務している親友と話した際に、このインターンシップに誘っていただきました。</p>
<p>私はどちらかと言えば、縁の下の力持ちとして物事に取り組むことが多く、開発においても、開発者が今後の開発をストレスなく、より良い環境で行えるようにリファクタリングなどを行なってきました。面談の際に、その旨を伝え、インターンシップとして開発体験を向上させるための業務をすることとなりました。</p>
<p>このインターンシップで行った内容は以下のようになっております。</p>
<ul>
<li>KARTEのエレメントビルダーのViteバージョンアップ</li>
<li>KARTEのユーザーリストや行動チェーン、ユーザーストーリーといった機能（以下、これらの機能をまとめてinsight-frontと呼称します。）における、開発体験向上を目的としたViteへの移行と、Vueのバージョンアップやそれらに伴う依存パッケージのバージョンアップ</li>
</ul>
<p>本記事ではインターンシップで行ってきたことの内容について、上記の二点をお伝えします。</p>
<h1>エレメントビルダーのViteバージョンアップ</h1>
<h2>課題</h2>
<p>KARTEの<a href="https://support.karte.io/post/67aMq2qoqXQMw6WaDL22Vl">エレメントビルダー</a>は、顧客⼀⼈ひとりに合わせて、最適なコミュニケーションができるように、顧客の行動に基づいてポップアップ表示などのアクションを作成・カスタマイズできる機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/f1201e44-6886-48d6-ba49-83231770813a/action-editor.png" alt="action-editor.png"></p>
<p>しかし、これまでのエレメントビルダーには以下のような課題がありました。</p>
<ul>
<li>開発環境がメンテナンスされていないため、ここ最近のフロントエンド環境と乖離が生じてきて、開発しにくい状況になってきていた</li>
<li>Viteのバージョンが古いため、KARTEのデザインシステムの導入に特別な対応が必要になる</li>
</ul>
<p>特に、一点目の課題が大きく、これまでのエレメントビルダーの開発環境におけるViteやVitestなどのパッケージはエレメントビルダーが開発されていた当時の状態のままになっておりました。これまでの開発環境のままでも開発はすることができますが、フロントエンド周りの環境は日々変わっていきます。今後新たな機能を実装する際、または新たなパッケージを導入する際、開発環境の遅れによって、それらの新しい機能の実装やパッケージの導入により多くの時間をかけてしまうことになります。</p>
<p>これらの課題を解決するために、エレメントビルダーのViteのバージョンを上げることになりました。</p>
<p>これまでエレメントビルダーで使用していたViteのバージョンは<code>3.2.5</code>で、今回のバージョンアップで<code>4.5.3</code>になりました。これまで使用していたVite 3系から一気にViteの最新バージョンへ上げるのではなく、小さくアップデートを行いたかったため、今回は4系へアップデートしました。</p>
<p><a href="https://v4.vite.dev/">https://v4.vite.dev/</a></p>
<p>また、それに伴って、Vitestのバージョンも上げることとなり、<code>0.24.3</code>から<code>0.34.6</code>にアップデートしました。</p>
<p>これまで使用していたVitest 0系から1系に上げるには、Vite 5系が必要となっており、先述のVite 4系を使う方針のために、1系ではなく0系の最新バージョンへアップデートしました。</p>
<p><a href="https://v0.vitest.dev/">https://v0.vitest.dev/</a></p>
<h2>テストが動かない</h2>
<p>ViteとVitestのバージョンアップを行ったことで、テストが動かなくなってしまったため、関連するパッケージのバージョンアップも行っていきました。</p>
<p>エレメントビルダーは細分化されたモジュールで作られており、それぞれに対応するパッケージの管理が複雑になっています。バージョンを上げたパッケージが他のパッケージのバージョンをサポートしていないことや、メンテナンスされていないパッケージを使用していることなど、複数の要因でテストが動かなくなってしまいました。</p>
<p>たとえば、<code>@testing-library/react-hooks</code>というパッケージでは、React 18で<code>renderHook</code>APIが<code>react-testing-library</code>と<code>react-native-testing-library</code>の両方に追加されたことにより、<code>@testing-library/react-hooks</code>を<code>@testing-library/react</code>に書き換える必要があります。</p>
<p><a href="https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support">https://github.com/testing-library/react-hooks-testing-library?tab=readme-ov-file#a-note-about-react-18-support</a></p>
<p>他にも、<code>@sveltejs/vite-plugin-svelte</code>というパッケージにおいて、Vitest は基本的に<code>node_modules</code>配下にあるモジュールは<code>alias</code>で設定していなくても、モジュール依存を解決してくれるのですが、テスト内でコンポーネントをレンダーした際に<code>onMount</code>が実行されないというバグを解決するために、以下のように明示的に設定しないといけませんでした。</p>
<pre><code class="language-js">import { defineConfig } from 'vitest/config';
import { svelte } from '@sveltejs/vite-plugin-svelte';
import { dirname, resolve } from 'node:path';

export default defineConfig({
  // ...
  resolve: process.env.TEST ? {
    alias: [{
      find: /^svelte$/,
      replacement: resolve(__dirname, &quot;node_modules/svelte/index.mjs&quot;) 
     }]
  } : {
    alias: {
      '@plaidev/karte-action-sdk/templates': resolve(__dirname, './src/templates.ts'),
    },
  },
  // ...
});
</code></pre>
<p><a href="https://github.com/testing-library/svelte-testing-library/issues/222">https://github.com/testing-library/svelte-testing-library/issues/222</a></p>
<p><a href="https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components">https://testing-library.com/docs/svelte-testing-library/faq#why-isnt-onmount-called-when-rendering-components</a></p>
<h2>小さく解決する</h2>
<p>先述の通り、エレメントビルダーは細分化されたモジュールで作られており、それぞれにテストが用意されています。（以下は一部抜粋）</p>
<pre><code class="language-text">.
├── api
├── asset-builder
├── core
│   ├── action-compiler
│   ├── action-sdk
│   └── action-utils
├── front
└── internal
</code></pre>
<p>これらのテストのほとんどが動かなくなってしまったので、それぞれのモジュールごとに小さくテストが通るよう修正を行い、最終的に全てのテストが通るようにパッケージのバージョンアップやパッケージの置き換えを行いました。</p>
<p>パッケージのバージョンアップを行った結果、パッケージの破壊的変更によってテストコードの修正を行う必要がありました。修正を行うためには、どこに問題があるのか探す必要があり、使用しているパッケージのソースコードを実際に動かしてみて、意図的にエラーを発生させ、エレメントビルダーのテストにおける問題のある箇所を発見することができました。</p>
<h1>insight-front開発体験改善</h1>
<h2>課題</h2>
<p>insight-frontを開発する際、他のシステムからイベントを飛ばしてデータを作る必要があり、フロントエンドのデバッグに時間を要するという課題がありました。</p>
<p><img src="https://ik.imagekit.io/plaid/a1d7ef2d-33b6-475a-b520-5a8df50adac6/insight-front.png" alt="insight-front.png"></p>
<p>この部分の課題を解決することで、今後新たな機能を開発する際や修正を行う際に素早く対応できるため、これまで使用されていたWebpackからViteへ移行することになりました。</p>
<p>Viteに移行することによって具体的にどんな点がより良くなるのかというと、開発サーバーの立ち上がりがWebpackよりも早くなるのでデバッグに要する時間が少なくなります。</p>
<p><a href="https://vite.dev/guide/why.html#slow-server-start">https://vite.dev/guide/why.html#slow-server-start</a></p>
<h2>Vite移行に向けて</h2>
<p>WebpackからViteへ移行するために、以下のような手順を踏んでいきます。</p>
<h3>Vue 2.7へアップデート</h3>
<p>insight-frontはVue 2で開発されており、ViteではVueアプリケーションのバンドルをするために、Vueの単一ファイルコンポーネントのサポートを提供している<code>@vitejs/plugin-vue2</code>を導入する必要があります。</p>
<p>insight-frontで使用されていたVueのバージョンは<code>2.6.12</code>だったため、<code>@vitejs/plugin-vue2</code>が要求するVue 2の最新バージョンであるVue 2.7へアップデートする必要がありました。</p>
<p>また、Vue 2はすでにサポートが終了しているため、セキュリティパッチを当てたVue 2を使用しています。</p>
<p><a href="https://v2.vuejs.org/v2/guide/migration-vue-2-7.html">https://v2.vuejs.org/v2/guide/migration-vue-2-7.html</a></p>
<h3>ES ModulesとCommonJSによるデュアルパッケージ化</h3>
<p><code>localDependencies</code>というプレイド独自の依存関係の解決機構を使用しており、ここに使用される社内の共通パッケージはCommonJSでビルドされていました。これまではWebpackを使用してバンドルしていたので、CommonJSで書かれた共通パッケージも問題なくバンドルし、アプリケーションを動作させることが出来ました。（Webpackを用いてバンドルしている場合でも、使用しているパッケージがNode.js依存である場合、手動でpolyfillを挿入するように設定する必要があります。）</p>
<p>しかし、この<code>localDependencies</code>の解決機構を使っていることにより、Viteで共通パッケージのCommonJSの依存解決ができずバンドル出来ないため、これらの共通パッケージをES ModulesとCommonJSでバンドルする必要がありました。</p>
<pre><code class="language-json">&quot;localDependencies&quot;: {
  &quot;@plaidev/xxx-common&quot;: &quot;../../../common&quot;,
  &quot;@xxx/insight-front-common&quot;: &quot;../front-common&quot;
},
</code></pre>
<p>insight-frontにおいて、<code>localDependencies</code>という解決機構で依存解決を行なっている共通パッケージ内には大量のコードが存在しており、その中からinsight-frontを動かすために必要なコードを調査する時間や、それらのコードをES ModulesとCommonJSでデュアルパッケージ化するための時間、実際にES ModulesとCommonJSでデュアルパッケージ化した後に、関連するシステムが動くかどうか確認するための時間など、多くの時間を費やすことになるだろうと予想しました。</p>
<p>ES ModulesとCommonJSによる共通パッケージのデュアルパッケージ化をするには多くの時間がかかってしまうため、Viteの機能を利用してES ModulesとCommonJSでバンドル出来ないか試してみることにしました。</p>
<p><a href="https://vite.dev/config/build-options#build-lib">https://vite.dev/config/build-options#build-lib</a></p>
<h3>Viteでビルドする</h3>
<p>上記に書いた通り、insight-frontを取り巻く依存関係の問題は大きく、それらを解決するために大量に時間を要することが予想されました。また、私自身がフロントエンドについての知識がまだまだ浅く、一気にこれらを解決させようとしてどこに問題が発生しているのか調査すること自体にも多くの時間を使ってしまいました。</p>
<p>この失敗を受けて、小さく小さく課題に取り組むことを意識し、最初からアプリケーションのソースコード全体をビルドさせることは考えないようにしました。まずは、小さなHTMLファイルのビルドから行い、実際にアプリケーションを動かした際に問題がないことを確かめることから始めました。そこにVue 2で書かれた小さなコードを追加するような形で、必要なプラグインなどを細かく追加していくなど、インクリメンタルな実装を行なっていくことで自身のViteに対する解像度も上がってきました。</p>
<p>しかし、ここでインターンシップ期間が終わってしまい、insight-frontをWebpackからViteに移行することが出来ませんでした。複雑な問題が絡み合い、この課題を解くのは難しかったのですが、自身が普段のめり込むことが無いような部分にのめり込み、様々なことを学ぶことが出来ました。</p>
<h1>インターンシップを終えて</h1>
<h2>総括</h2>
<p>インターンシップとして主に二つの内容に取り組んできました。</p>
<p>開発環境をメンテナンスをしないまま、放置してしまうことにより、今後のバージョンアップで大きな障壁となってしまうことを避けるためにも、日頃からメンテナンスを怠らないようにしたいです。</p>
<p>しかし、プロダクトの開発において、メンテナンスをすることにより、本来先に実装したかった内容に遅れが生じてしまうことがあります。その実装の遅れとメンテナンスをすることによる恩恵を考えて、両方を天秤にかけ、どちらがプロダクトにより大きなインパクトを与えられるのか考え続けなければなりません。</p>
<p>そして、目の前の難しい課題に対して、直線的に解決策を取ろうとするのではなく、回り道をしつつ、小さく小さく問題を区切りながら解決に向かうことを意識していきたいです。</p>
<h2>成長</h2>
<p>これまでは、主にPHPを用いたバックエンドの開発を行なっており、フロントエンドの開発は自作のブログや先述のOSSプロジェクトの小さな機能の開発以外ではほとんど触ったことがなく、こんなにもガッツリとフロントエンドの領域にのめりこむのは初めてでした。</p>
<p>フロントエンドの技術について、あまり知識がない状態からキャッチアップを行いつつ、大きな成果を出すことが出来て、とても学びのあるインターンシップだったと感じております。</p>
<p>もちろん、一人では抱えきれない悩みや課題などが生じた際に一緒に解決してくださったメンターの方やKARTE Webチームの方々のおかげだと感じております。</p>
<p>KARTEの強みを理解し、どうすればその強みをプロダクトに機能として実装できるのか。そして、顧客に大きなインパクトを与えられるか、という思考のサイクルを止めることなくプロダクトに向き合っているプレイドの方々の姿勢に感銘を受けました。</p>
<p>そして、インターンシップを行なっていく中で自分に何が足りないのか、プロダクト開発やその会社に属する人間としてどんな視点を持てば良いのか、深く考えることのできたインターンシップでした。</p>
<h2>最後に</h2>
<p>インターンシップ期間中は広島からフルリモートでの勤務をしていました。フルリモートでなかなか顔を合わせてお話しする機会がない中、広島から東京のオフィスに出社した際には、他のインターンシップ生とのランチに誘っていただいたり、多くの方々とお話しさせていただく機会に参加させていただいたりと、社内の雰囲気もとても良かったです。</p>
<p>3ヶ月という短い間でしたが、メンターの方やKARTE Webチームの方々など、多くの方々のおかげで濃密な3ヶ月を過ごすことが出来ました。本当にありがとうございました。</p>
<hr>
<p>プレイドでは開発インターンを募集しています。興味のある方はぜひ下記のリンクからご応募ください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

プレイドインターン体験記：開発体験の向上を目指し行なったこと

Developer Experience & Performance チームでエンジニアをしている大矢です。今回は JavaScript の非同期処理で使われている callback を Promise に移行する手法について、具体的な事例をもとに紹介します。

Mongoose の callback を Promise に移行する手法

KARTEの複数のシステム間で共有する定数ファイルを、これまで社内向けのnpmパッケージとして配布していたところから、代わりとなる独自の仕組みを構築して管理する方式に切り替えたことと、その移行プロセスについて。

npmパッケージの代わりに独自の仕組みを構築して定数ファイルを配布する運用に切り替えた経緯と移行プロセス

<h1>はじめに</h1>
<p>こんにちは、桂田一輝と申します。2024年8月から10月の3ヶ月間、プレイドのEcosystemチームでソフトウェアエンジニアとしてインターンシップを行いました。インターンを通じて、Ecosystemチームが開発しているKARTE Craftというプロダクトの改善業務に携わってきました。そこで得られた学びについてお伝えします。</p>
<h1>EcosystemチームとKARTE Craftについて</h1>
<p>私が配属されたEcosystemチームは、KARTEと外部サービスを繋ぐ連携機能のオーナーを務めています。Ecosystemチームがオーナーとなっているプロダクトの一つに、<strong>KARTE Craft</strong>があります。</p>
<p>KARTE Craftはアプリケーション開発機能を提供するPaaSです。KARTEの機能拡張や独自のカスタマードリブンなサイト、アプリケーションを作成することができるため、KARTEの特徴であるユーザーの状態変化に応じた適切なアプリケーションの開発が可能になります。</p>
<p><a href="https://craft.developers.karte.io/get-started/about-karte-craft/">https://craft.developers.karte.io/get-started/about-karte-craft/</a></p>
<p>今回のインターンで私が担当したのは、KARTE Craftの <strong>Craft Functions</strong> という機能の改善でした。</p>
<h2>Craft Functionsとは</h2>
<p>Craft Functionsは、KARTE内外で発生するユーザーの状態変化に関するイベントをトリガーにして、任意のバックエンドプログラムを実行する機能です。外部サービスや自社システムとの連携、シンプルな連携から複雑な作り込みまで、あらゆるカスタマードリブンな独自のアプリケーションを作成できます。</p>
<p><a href="https://craft.developers.karte.io/get-started/about-karte-craft/#craft-functions%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF">https://craft.developers.karte.io/get-started/about-karte-craft/#craft-functionsの仕組み</a></p>
<p>Craft Functionsで実行するプログラムを<strong>ファンクション</strong>と呼びます。ファンクションの作成時には、インフラの構築・運用は不要で、AIによるサポートも搭載されているため、手軽に作成することができます。</p>
<h1>インターンで行ったタスク</h1>
<p>インターン期間中は、大きく3つのタスクに取り組みました。配属後の初めのタスクとして、KARTEのサーバーインフラを理解するための設定変更を行いました。その後は、Craft Functionsの改善として、次の2つのタスクを担当しました。</p>
<ul>
<li>ファンクションが意図せず操作不能となる事象を回避するためのジョブ機能の構築</li>
<li>ファンクション一覧をタイプ別に取得するサービス間APIの作成</li>
</ul>
<p>今回は、上記の2つのタスクを紹介し、そこから得られた学びを説明します。</p>
<h2>タスク1: ファンクションが意図せず操作不能となる事象を回避するためのジョブ機能の構築</h2>
<p>最初のタスクは、作成したファンクションの状態管理に関する課題を解決するものです。ファンクションの作成処理の流れ、課題、そして解決方法を説明します。</p>
<h3>課題</h3>
<p>Craft Functionsでファンクションを作成する際のシステム概要図は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/b48943b2-5706-4e92-9a4e-97345c8f456e/image.png" alt="image.png"></p>
<p>KARTEは複数のマイクロサービスで構成されており、サービス間通信にはAPIやqueueが使われています。図のwebサービスはKARTE Craftの管理画面を提供しています。workerサービスではファンクション用のコンピューティングリソース作成、更新、削除などの時間のかかる処理を非同期で行っています。</p>
<p>ファンクションの作成順序は次のとおりです。</p>
<ol>
<li>webサービスはファンクション作成リクエストを受け取り、MongoDBにstatus: <code>IN_PROGRESS</code> でファンクションの設定情報を保存し、workerサービスにファンクション作成メッセージを送信します。</li>
<li>workerサービスはファンクションを実行するためのコンピューティングリソースを作成します。</li>
<li>workerサービスはコンピューティングリソースの作成結果に基づき、ファンクションの設定情報を更新します。
<ul>
<li>リソース作成に成功した場合は設定情報のstatusを<code>SUCCESS</code>に変更します。</li>
<li>何らかのエラーで失敗した場合は<code>FAILED</code>に変更します。</li>
</ul>
</li>
</ol>
<p>KARTE Craftのアプリケーション上で予期しない不具合が発生した場合、ファンクションのstatusが <code>IN_PROGRESS</code> のままで操作ができなくなるという課題がありました。ユーザー自身でできる解決手段がないため、問題になっていました。</p>
<h3>解決策</h3>
<p>この課題の解決策として、ファンクションの設定情報を確認し、「最終更新から1時間以上経過」かつ「status: <code>IN_PROGRESS</code> 」なファンクションを作成失敗したとみなして <code>FAILED</code> に更新する仕組みを考えました。</p>
<p>実装方法として、以下の2つの方法を検討し、それぞれの長所と短所を比較しました。</p>
<ol>
<li>KubernetesのCronJobリソースを使用する。
<ul>
<li>メリット: 構成がシンプルで直感的に理解しやすい</li>
<li>デメリット: 新しいインフラの設定を追加する必要があり構成が複雑化する</li>
</ul>
</li>
<li>フロントエンドからファンクションに対するAPIを投げる
<ul>
<li>メリット: サーバーサイドの計算負荷が少ない</li>
<li>デメリット: フロントエンドの計算負荷が増える。APIの露出が増える。</li>
</ul>
</li>
</ol>
<p>今回はフロントエンドに対する余計な計算負荷やAPIの露出を避けることを優先し、方法1を選択しました。方法1を用いた際の構成図は次のとおりです。</p>
<p><img src="https://ik.imagekit.io/plaid/d206cc8d-2e89-4677-b5b5-a669d2a9eee4/image(1).png" alt="image(1).png"></p>
<p>cron-jobというサービスをKubernetesのCronJobとして作成し、定期的にMongoDBにクエリを実行することで、上記で説明した状態のファンクションを<code>FAILED</code>に更新します。</p>
<h3>実装</h3>
<p>実装において工夫した点を3点説明します。</p>
<ul>
<li>汎用的なジョブ実行コンテナの整備</li>
<li>ファンクション設定の更新方法</li>
<li>テストの実装</li>
</ul>
<p><strong>汎用的なジョブ実行コンテナの整備</strong></p>
<p>今回の実装時点で、KARTE Craft上でスケジュール実行しているのはこのCronJobリソースのみでした。そのため、プログラムを単純に実装して実行すれば十分でした。しかし、他のKARTEプロダクトのコードを見ると、より汎用的にジョブを起動できる構造になっていたので、それを参考に実装しました。</p>
<p>次のコードは、その実装を抜粋し、説明用に改変したものです。</p>
<pre><code class="language-jsx">const argv = minimist(process.argv.slice(2));
const { jobname } = argv;

import(`./path/to/${jobname}`)
  .then(async cronjob =&gt; {
    await cronjob.default(argv);
  })
  .catch(err =&gt; {
    logger.error(err);
    process.exit(1);
  });
</code></pre>
<p><code>jobname</code>は引数としてプログラムを実行する際に渡します。今回はCronJobリソースの <code>command</code> 属性でコンテナ起動時に渡すようにしました。これにより、スケジュールの異なる複数のプログラムを1つのコンテナイメージで呼び出すことが可能になりました。</p>
<p><strong>ファンクション設定の更新方法</strong></p>
<p>CronJobで定期的に実行する関数では、「最終更新から1時間以上が経過」かつ「statusが<code>IN_PROGRESS</code>」という条件を満たすファンクションのドキュメントを全件取得し、それらを<code>FAILED</code>に更新します。</p>
<p>当初はMongooseの<code>updateMany()</code>メソッドで一括更新しようとしましたが、このメソッドでは更新したドキュメントの内容が確認できないことがわかりました。ジョブでは更新したドキュメントをログ出力したいので、今回は条件を満たすドキュメント一式を <code>find()</code> メソッドで取得し、 <code>findOneAndUpdate()</code>メソッドで1件ずつ更新しました。</p>
<p><strong>テストの実装</strong></p>
<p>作成した処理が正常に動作することを確かめるため、テストコードも実装しました。テストでは、更新日時が異なる複数のドキュメントを作成し、当該処理の結果を想定の値と比較しました。</p>
<h2>得られた学び</h2>
<p>このタスクでは、KARTE Craft上にジョブシステムを作成しました。タスクを通じて次の学びを得られました。</p>
<ul>
<li>インフラ〜バックエンドを跨いだ機能の実装
<ul>
<li>ジョブ用のプログラムを記述し、それをKubernetesのワークロードとして動かす方法がわかりました。</li>
</ul>
</li>
<li>設計・実装レベルでの取捨選択の方法
<ul>
<li>構成や実装を検討する際に、候補を挙げてその良し悪しを検討することで、より説得力のある設計・実装になることがわかりました。</li>
</ul>
</li>
</ul>
<h2>タスク2: ファンクション一覧をタイプ別に取得するサービス間APIの作成</h2>
<p>次に取り組んだのが、KARTEのHook機能経由でファンクションを起動する設定をする際に必要となる、ファンクション一覧APIの改善タスクでした。マイクロサービス間の通信に必要なAPIを作成し、サービス間通信の実装を行いました。</p>
<h3>Hook v2</h3>
<p>Hook v2は、KARTE内で発生した特定の変更や追加などの変化をトリガーとして、そのデータをリアルタイムで外部のシステムに送信する機能です。</p>
<p><a href="https://developers.karte.io/reference/about-hook-v2">https://developers.karte.io/reference/about-Hook-v2</a></p>
<p>Hook v2を使うことで、KARTE内で起きた出来事をトリガーとして、外部システムで処理を行うことができます。例えば、ユーザーからメッセージが送信された際にそれをトリガーとして特定のファンクションを実行させることができ、顧客のリアルタイムな行動に合わせたアクションを提供することができます。参考として、以下の記事では汎用のWebhookリクエストを行う方法を説明しています。</p>
<p><a href="https://solution.karte.io/blog/2023/06/craft-webhook/index.html">https://solution.karte.io/blog/2023/06/craft-webhook/index.html</a></p>
<h3>課題</h3>
<p>次の図はHook v2の設定画面です。この画面では、トリガーとなるイベントと、そのトリガーで起動するファンクションを指定します。</p>
<p><img src="https://ik.imagekit.io/plaid/80d8a018-8062-4657-8928-5f4da923980c/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-10-2316.14.09.png" alt="スクリーンショット2024-10-2316.14.09.png"></p>
<p>Craft Functionsのファンクションには、2種類のタイプがあります。HTTPタイプとイベント駆動タイプです。</p>
<div class="iframely-embed" data-embedded-url="https://craft.developers.karte.io/craft-functions/craft-functions-types/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://craft.developers.karte.io/craft-functions/craft-functions-types/" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Fcraft.developers.karte.io%2Fcraft-functions%2Fcraft-functions-types%2F&key=878c5bef402f0b2911bf6d4ce6261abd">ファンクションのタイプ</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>Hook v2において指定できるファンクションはイベント駆動タイプのみです。しかし、管理画面上はHTTPタイプ、イベント駆動タイプの両方が指定できるようになっていました。この相違を解決するため、管理画面上において指定できるファンクションからHTTPタイプを除き、イベント駆動タイプのみを表示する必要がありました。</p>
<h3>解決策と実装</h3>
<p>Hook v2機能はKARTE Craftとは異なるサービスで動作するため、マイクロサービス間でAPI通信を行いファンクション一覧を取得しています。今回はAPIの改善を行いました。具体的には、ファンクション一覧取得のリクエスト時に、タイプを指定できるAPIを追加し、それを利用するように変更しました。</p>
<p>Hook v2の管理画面においてファンクションの取得を行う際の構成図は次のとおりです。赤字で示すように、タイプを指定できるAPIへの切り替えを行いました。</p>
<p><img src="https://ik.imagekit.io/plaid/4745c925-fff4-4836-bda8-0a42cb293e9b/image(2).png" alt="image(2).png"></p>
<p>具体的な実装として、次の作業を行いました。</p>
<ul>
<li>Craft側にサービス間通信用のAPIを追加し、バックエンドを実装しました。</li>
<li>クライアントをOpenAPI Specから自動生成する仕組みを使って、サービス間通信用のクライアントを生成しました。</li>
<li>Hook v2のバックエンド処理で、新たに作成したサービス間通信用APIを利用するように変更しました。</li>
</ul>
<h2>得られた学び</h2>
<p>このタスクでは、マイクロサービス間の通信を行う仕組みを理解し、その改善を実施しました。タスクを通じて、次の学びが得られました。</p>
<ul>
<li>本番稼働するシステム上で、どのようにマイクロサービスが稼働しているかの全体像が掴めました。</li>
<li>インターフェース仕様（OpenAPI Spec）を活用してクライアントを自動生成することで、良い開発体験を提供できることがわかりました。</li>
</ul>
<h1>あとがき</h1>
<p>3ヶ月に渡って参加したインターンシップの感想を端的に言えば、非常に充実した経験でした。</p>
<p>今回のインターンシップを通して、次のような学びが得られました。</p>
<ul>
<li>実際に社員が担当するレベルのタスクを担当することで、本番稼働するプロダクトを開発する際に必要なレベル感を実感しました。</li>
<li>タスクを通じて、PaaSのインフラからバックエンドまで、一気通貫の開発を経験できました。</li>
<li>システム特性の面でも、Webシステムだけではなく、ジョブシステムを新たに作成する経験を通じて、開発の幅を広げることができました。</li>
</ul>
<p>これまでの私の開発経験は個人的なプロジェクトに限られており、実際のプロダクトに対する開発は初めてでした。今回のインターンシップで、実際に世の中に出ているシステムの開発に携わることで、多くの刺激を受けることができました。KARTEというアプリケーションの裏側の設計や動作原理を知った時の感動、そこで発生している課題に対して解決策を考え、技術選定をし、実装する楽しさ、そして自分が開発したものが実際にデプロイされる喜びを強く感じました。これらの経験を通じて、エンジニアリングそのものへの好奇心が大いに高まりました。また、この過程でコードを読み解き構造を把握する能力や、未知の技術を調査して組み込む力を養うことができたと考えています。</p>
<p>さらに、インターンシップの環境は非常に学びやすいものでした。メンターの方はいつ質問しても丁寧に答えてくださり、質問しやすい雰囲気が整っていました。加えて、インターンシップ期間中は他のチームの方々も交えたランチに頻繁に誘っていただき、様々なチームや職種の方々の話を聞くことで、多様な視点を知ることができました。</p>
<p>お世話になった社員の皆様に心から感謝申し上げます。本当にありがとうございました。</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>

こんにちは、桂田一輝と申します。2024年8月から10月の3ヶ月間、プレイドのEcosystemチームでソフトウェアエンジニアとしてインターンシップを行いました。インターンを通じて、Ecosystemチームが開発しているKARTE Craftというプロダクトの改善業務に携わってきました。そこで得られた学びについてお伝えします。

プレイドインターン体験記：プロダクトの改善活動から得た学び_プレイドエンジニアブログ

プレイドインターン体験記：プロダクトの改善活動から得た学び

<h1>自己紹介</h1>
<p>初めまして、プレイドでエンジニアインターンをしている小林雅史と申します。プレイド内ではあだ名である<a href="https://x.com/mercy34mercy">mercy</a>(マーシー)で呼ばれています。</p>
<p>立命館大学の修士1年生で、大学は情報理工学部、大学院は情報理工学研究科とコンピュータやプログラミングについて学び、研究しています。プログラミングは大学入学と同時に授業で取り組んできました。プログラミングに関しては授業だけでなく、ハッカソンなどでさまざまなアプリケーションを作成しました。特に<a href="https://cup.hackz.team/">ハックツハッカソン</a>が大好きで2度優勝しています。また<a href="https://ritsumeikanunivpress.com/07/11/4430/">大学生向けのバス時刻表アプリ</a>を先輩から引き継ぎ運用していたりもしています。3年生の時には学生IT団体<a href="http://www.watnow.jp/">watnow</a>の代表として<a href="http://www.watnow.jp/2022/10/20/%E9%96%A2%E8%A5%BF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%AB%E3%83%B3%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B92022%E3%82%92%E9%96%8B%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/">企業様とのイベント</a>や<a href="http://www.watnow.jp/2022/08/24/watnow%e3%83%8f%e3%83%83%e3%82%ab%e3%82%bd%e3%83%b3-beginners-cup%e3%82%92%e9%96%8b%e5%82%ac%e3%81%97%e3%81%be%e3%81%97%e3%81%9f%ef%bc%81/">団体内ハッカソン</a>を立ち上げたりとコミュニティの運営も行いました。</p>
<p>プレイドでは2023年の4月からインターンとして勤務していて、最初は<a href="https://tech.plaid.co.jp/platform-engineering-kaigi-2024-report">認証基盤の開発</a>を行いました。その後Redisの監視を簡単にDatadogで行うための社内向けツールを開発し、2023年10月ごろから<a href="https://karte.io/package/message/">KARTE Message</a>というプロダクトの開発を行うチームに加わり、開発を行っています。</p>
<h1>KARTE Messageについて</h1>
<p>KARTE Messageは、データを元にメールやプッシュ通知、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<div class="iframely-embed" data-embedded-url="https://karte.io/package/message/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://karte.io/package/message/" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fkarte.io%2Fpackage%2Fmessage%2F&key=878c5bef402f0b2911bf6d4ce6261abd">KARTE Message（マーケティングオートメーション/MA）｜顧客体験を磨きこみ、自動化のその先へ【KARTE（カルテ）】</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script> 
<h1>課題</h1>
<p>KARTE Messageの機能であるスマホアプリ向けのプッシュ通知配信では月間1億通を超える規模の配信を行っています。</p>
<p>今回、プッシュ通知に利用しているFCMの<a href="https://firebase.google.com/docs/reference/admin/node/firebase-admin.messaging.messaging.md?hl=ja#messagingsendall">sendAll API</a>が2024年の6月20日に廃止されることが決定し、この期日までに今後も引き続き使用できるAPIに乗り換える必要がありました。</p>
<p>また、これまで使用していたsendAll APIでは、最大500件の通知をバッチ的に送信することができましたが、これと完全に互換性のあるAPIは現在用意されておらず、1通1通を個別に送信する必要があります。</p>
<p>今回私はこのリプレース作業を担当することになりました。</p>
<h1>テスト送信の実装・切り替え</h1>
<p>最初に、移行時のリスクが小さいテスト送信から置き換えることとなりました。本番送信もテスト送信も1通1通を個別に送信するロジックは同じであり、違いは送信数です。そのため、テスト送信の実装を先に行いリリースすることで、バグがあった際の影響範囲をテスト送信のみに抑えつつ新しい実装の信頼性を検証することができます。テスト送信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>既存のコードとドキュメントを読み理解する</li>
<li>テスト送信の実装</li>
<li>テスト送信の実装の置き換え</li>
</ol>
<h3>1. 既存のコードとドキュメントを読み理解する</h3>
<p>既に動いているシステムをリプレースするため、まずは既存のコードを理解する必要がありました。コードを読むだけではなかなかコードの振る舞いを把握するのが難しいので、単体テストを新たに追加しました。</p>
<h3>2. テスト送信の実装</h3>
<p>リプレースする際のリスクを最小にするために、新規実装では既存の実装と同じケースの単体テストを書き、既存実装、新規実装ともにテストケースと結果が同じになることを確認することで、実装ミスがないかを検証しました。また、新規実装では、Goの実装が約1200行なのに対してテストコードは約5600行あります。テストはローカル環境で実行することができ、キャッシュがない状態でも30秒ほどで終了します。また、これらのテストはGithubActionsで自動で実行されており、生産性向上につながっています。</p>
<h3>3. テスト送信の実装の置き換え</h3>
<p>無事に実装が終わりテストも通ったら本番環境のテスト送信をリプレースしました。これまでの業務でバグの修正や新機能の実装をした事はあったものの、今正常に動いているものを全く新しいコードで作成されたシステムに置き換える経験は初めてでとても緊張しました。リリースの実行は社員さんに行ってもらい、検証環境で最終動作確認を行いました。テスト送信のリプレース後には、ユーザ企業様からバグ報告が数件ありました。その中でもGoへのリクエストのJSONのフィールドにnullがあった場合、Goのjson packageではnilに変換されるという仕様があり、nilのハンドリングがうまくできていないコードでバグが発生したのが印象的です。いくつかのバグを修正し、無事テスト送信の実装をsendAll APIからsend APIに切り替えることができました。</p>
<h1>本番配信の実装・負荷試験・切り替え</h1>
<p>テスト送信の置き換えが終了しバグの修正も終わると、本番配信も新しいAPIに置き換えます。本番配信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>本番送信の実装</li>
<li>負荷試験</li>
<li>カナリアリリース</li>
</ol>
<h3>1. 本番送信の実装</h3>
<p>本番送信の実装に関しては本番送信とテスト送信のロジックを共通化したため、基本的にテスト送信の実装を流用する形で実装しました。</p>
<h3>2.  負荷試験</h3>
<p>本番配信では、KARTE Messageを使用されている企業様が大量のアプリユーザに向けてプッシュ通知を送信します。また、お客様が設定した速度で正しく配信する必要があります。そのため、アプリケーションに負荷がかかっても正常に動作することを検証する必要がありました。KARTE MessageはインフラにGCPのGKEを使用しているため、正しい速度で負荷がかかっても送信できる適切なk8sのスケーリング設定を見つける必要がありました。</p>
<p>負荷試験の環境には本番環境とは完全に切り離された検証環境を使用しました。検証環境は本番環境と同じシステムが動作しており、スケーリングの設定などが違うだけで本番環境と同じようにシステムが動作します。</p>
<p>負荷試験に関しては、社員さんからは時間かかってもいいからとりあえずやってみよう！といった感じで言われたので、ほぼ初めてGKEとその設定が書かれたk8s用のyamlファイルと戦うこととなりました。本番配信は、データベース、配信サーバ(今回作成したもの)、配信準備サーバなどさまざまなシステムが連携して動くことで実行されます。サーバやデータベースの状況はリアルタイムでdatadogで確認しました。</p>
<p>負荷試験の目標値は16667rps(時速6000万)となりました。これはAPI置き換え前のシステムで過去に負荷試験をした際の最大値となっています。</p>
<p>最初はスケーリングの設定を何も変えずに、2.7prs、277rps、1667rps、5555rpsと上げて行きました。すると、時速5555rpsの試験では設定した速度で配信されず1100rpsほどでしか配信できませんでした。ここから数時間悩んで色々設定を見ているうちに、配信サーバのスケーリング設定が問題になっていることに気づきました。最大node数とpod数が非常に小さい数に設定されていて、一定以上の負荷に耐えられないようになっていました。そこで、podの最大数を500、nodeの最大数を250に設定し再度負荷試験を行ったところ、16667rpsを達成できました。この時、配信サーバのpod数は100台ほどにスケーリングしていました。</p>
<p>目標値をクリアしたので、次に最適な設定を探します。KARTE Messageではサービスの性質上、リクエストのスパイクが発生しやすいです。また、深夜帯などは配信がなくサーバに負荷がかからない状態になります。そのため、スパイクに耐えられる最小pod数と、最大負荷に耐えられる最大pod数を見つける必要があります。そこで、1podあたりどれくらいの配信数を捌けるのかを調査しました。調査するために、pod数を20台固定にし少しづつ少ない配信数から負荷試験を行い、限界の配信速度を見つけ出しました。20台のpodで2700万/hの配信を行うことができました。pod1台で約135万/hの配信が可能です。そこで、6000万/hの配信に耐えられるpod数より少し余裕を持たせた50を、最大pod数としました。</p>
<p>負荷試験だけで10営業日ほどかかりました、負荷試験の勘所やk8sの特性を理解するのに時間を要しました。初めてやることは、手探りで頑張ってみることも大事ですが、社員さんなど経験がある人にある程度、勘所を先に教わっておくともっと効率良くできたかなと感じました。学生が簡単に経験することができない、k8sを用いたシステムの負荷試験ができたことは非常に良い経験となりました。</p>
<h3>3. カナリアリリース</h3>
<p>負荷試験も終わり、ついに本番配信を新しいAPIに置き換えます。全ユーザに一斉に適用してしまうと、もしもバグなどがあった場合に影響範囲が広くなってしまうため、一部のお客様から順次新しいAPIを適用しました。APIの切り替えは環境変数で指定した特定のお客様の時のみ新しいAPIが実行されるように実装を行いました。環境変数で切り替えを行うことで、もし新しいAPIの実装に問題があった際に、修正やロールバックしたアプリケーションをデプロイすることなく、環境変数を切り替えるだけで既存のAPIの実装に戻せるため、環境変数を活用したカナリアリリースを行いました。カナリアリリースは、置き換え前と比べて、悪化している指標がないか確認しながら約1ヶ月かけて全てのお客様の配信APIを新しいAPIに切り替えました。</p>
<h1>リプレース結果</h1>
<p>リプレースは実装を始めてから約5ヶ月で終了しました。結果として、新しいAPIに切り替えたことによる大きな障害はありませんでした。そして、既存実装よりもエラー率も下がりました。</p>
<h1>最後に</h1>
<p>今回のプッシュ通知配信で使用するAPIのリプレースの実装、試験、移行は全て自分の手で行いました。もちろん社員さんの助けなしではできなかったです。今回のプロジェクトを通して長期インターンでしか体験できない貴重な経験ができました。また、自分は京都に住んでいるのでリモート勤務だったですが、地方に住んでいる学生についてはリモートでも受け入れてくれる環境は非常にありがたかったです。他のインターン生が行ったことについては、ぜひプレイドのエンジニアブログをご覧ください[1][2][3][4][5]。このような経験をしてみたい方、プレイドに興味を持った方は下記からプレイドのエンジニアインターンに応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>[1] <a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a></p>
<p>[2] <a href="https://tech.plaid.co.jp/intern-at-plaid-calloc">プレイドインターン体験記: はじめての開発インターンを通じて得た学び</a></p>
<p>[3] <a href="https://tech.plaid.co.jp/intern-at-plaid-kenshin">プレイドでの開発インターン: 3ヶ月のフルタイムエンジニアとしての挑戦を経て</a></p>
<p>[4] <a href="https://tech.plaid.co.jp/intern-at-plaid-shohei-shiraki">プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び</a></p>
<p>[5] <a href="https://tech.plaid.co.jp/mongo-atlas-to-bigquery">MongoDB AtlasからBigQueryへのリアルタイムレプリケーション</a></p>


KARTE Messageで使用しているFCMのsendAll APIが廃止となるため、APIの置き換えを行った後負荷試験を行なった。

FCMのSendAll API廃止対応

KARTE MessageにおけるFCMのSendAll API廃止対応について

カラムナフォーマットの利点を最大限活かすために書き込み処理、特にリアルタイムの書き込み処理における技術的な課題とOSS DBの具体的なアプローチを紹介しています

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 - PLAID engineer blog

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 

Engineer Blog

Recent Article