Engineer Blog

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

こんにちは！6月から8月までの3ヶ月間、プレイドでエンジニアインターンとして勤務しておりました伊藤孝太朗です。私は現在、カナダ・バンクーバーにあるブリティッシュコロンビア大学（University of British Columbia, UBC）で学部3年生としてコンピュータサイエンスを専攻しています。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月_プレイドエンジニアブログ

プレイドインターン体験記：エンジニアとしての学びを深めた3ヶ月

長期運用システムにおけるNode.js / npmアップデート工程を紹介します

KARTEの分析システムのNode.jsを16から20にアップデートしました

<p>株式会社プレイドでデザインエンジニアをしている安田です。</p>
<p>この記事では、社内向けに提供しているライブラリの使用状況を把握すべく作成した、プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。</p>
<h2>ライブラリ開発の問題と使用状況の解析</h2>
<p>弊社では、KARTEのプロダクト群全体のデザインシステムである「Sour」を開発しています。その一環として、React製のUIライブラリ「sour-react」を作成し、社内向けのnpmパッケージとして提供しています。現在、sour-reactはKARTEのいくつものプロダクトにおいて採用されており、UI開発に欠かせないものになるほど浸透しています。</p>
<p>作成したライブラリが広く使われるようになるのは喜ばしくもありますが、一方、それに伴って新たな問題が生じることもあります。その一つが、後からの仕様変更、とりわけ破壊的変更が難しくなってしまうことです。</p>
<p>原則的には、できるだけライブラリの破壊的変更を起こさないように開発を進めるべきではあります。しかし、ライブラリの機能が増え続けたり運用期間が長期化したりした結果、いずれその必要に迫られることは多かれ少なかれ避けがたいものです。</p>
<p>もし、ライブラリのユーザー数が少なく、その使用範囲も微々たるものであれば、破壊的変更が発生しても対応は容易です。しかしsour-reactは、数多くのプロダクトのUIにふんだんに組み込まれているため、破壊的変更に伴う影響を軽視できなくなりつつあります。また、破壊的変更に対応するためのユーザー側の労力が大きくなればなるほど、バージョンアップ作業が滞ってしまい、UIの不具合が放置される結果に繋がってしまうこともあります。とはいえ、その影響を必要以上に懸念して、変更すべきものを変更せずに誤魔化し続けるのも不健全です。</p>
<p>そこで、仕様変更に伴う影響範囲を適切に把握すべく、ライブラリの使用状況を解析して可視化する仕組みを作成しました。具体的に言えば、KARTEのすべてのソースコードの中から、sour-reactが読み込まれている箇所を検出して、どのプロダクトからどのモジュールが参照されているかを個別に自動集計するというプログラムを作成しています。これを用いて、マークダウンファイルとして次のような集計結果を出力しています。</p>
<p><img src="https://ik.imagekit.io/plaid/b771e07d-ef2a-4f12-a1cb-05c25b971b8a/1.png" alt="表形式で「Accordion」「AdminLayout」「AutoComplete」などの行が並び、列ごとに数値がそれぞれ表示されている"></p>
<p><img src="https://ik.imagekit.io/plaid/0f570cbc-c10d-414a-9123-a67b638c14e1/2.png" alt="「sour-reactのモジュールごとの集計」という大見出しがあり、「Button (422)」という中見出しに続いて「XXX (140)」という小見出しがある。続いてファイルパスがリストで表示されている"></p>
<p><img src="https://ik.imagekit.io/plaid/02a8f29d-635b-4b2e-99dc-2eb40a111be7/3.png" alt="「sour-reactを利用するパッケージごとの集計」という大見出しがあり、「XXX (1720)」という中見出しに続いて「Button (140)」という小見出しがある。続いてファイルパスがリストで表示されている"></p>
<p>これらの集計はGitHub Actionsによって定期的に自動実行され、毎朝9時になるたび最新の状態にアップデートされるようになっています。</p>
<p>この仕組みによって、実際にモジュールが参照されている箇所や、どのモジュールの使用頻度が高いか、どのプロダクトにおいて積極的に採用されているかなどを、効率的に調査できるようになりました。</p>
<p>一つの活用例としては、不要なモジュールをライブラリから削除するために、この集計結果を参考にして選定したことが挙げられます。Sourにはその歴史的な経緯により、特定のプロダクトでしか使われないような特殊なモジュールや機能が多く含まれていました。それらは本来的には、共有ライブラリとしてではなく、それぞれのプロダクト側のソースコードとして管理されるべきです。とはいえ、すでにライブラリとしての提供を行なってしまっている以上、意図せずそれらが使用されてしまっている可能性もあり、その疑念が晴れない限りは削除してしまうことが必ずしも得策とは言い切れませんでした。そこで、こうした集計結果を参考にすることで、各モジュールの使用状況を正確に把握し、確信を持って安全に変更を行うことができました。</p>
<h2>実装方法の解説</h2>
<p>続いて、先述した仕組みの実装方法について解説します。なお、この記事で紹介する仕組みは、OSSとしてGitHubに公開しています。解説と併せて参照してください。</p>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats">yuheiy/internal-library-reference-stats</a></p>
<p>集計結果の出力形式は次の3種類とします。</p>
<ol>
<li><code>README.md</code>: 横軸がsour-reactのモジュール名、縦軸がプロダクト名になったテーブルを出力する。セルにはそれに対応する参照箇所数を表示する。最終列と最終行には合計値を表示する。</li>
<li><code>by-module-export-name.md</code>: 見出し2がsour-reactのエクスポート名、見出し3がプロダクト名という文書構造になり、参照箇所のファイル一覧がそれに続く。</li>
<li><code>by-user-package.md</code>: 見出し2がプロダクト名、見出し3がsour-reactのエクスポート名という文書構造になり、参照箇所のファイル一覧がそれに続く。</li>
</ol>
<p>処理の流れは主に次のようになります。</p>
<ol>
<li>
<p>KARTEのソースコードを含むGitリポジトリから、拡張子が<code>js,ts,jsx,tsx</code>のいずれかに当たるファイルすべてを読み込む</p>
</li>
<li>
<p>TypeScriptのCompiler APIを使って、sour-reactを読み込むimport文を抽出する</p>
</li>
<li>
<p>import文の形式がnamed importsであれば、そのエクスポートの名前とimport文が出現する行数を取得する</p>
</li>
<li>
<p>named importsの解析結果をフラットな配列としてまとめる</p>
<pre><code class="language-tsx">export type NamedImportsStat = {
  sourcePath: string;
  moduleExportName: string;
  lineRange: LineRange;
};

export function getNamedImportsStats(filePaths: string[]): NamedImportsStats[] {
  // ...
}
</code></pre>
</li>
<li>
<p>解析結果をまとめたものを出力形式に応じて加工して出力する</p>
</li>
</ol>
<p>これらについて、いくつかにポイントを絞って解説します。</p>
<p>まず、ソースコードを解析するに当たって、対象となるソースコードを用意します。この仕組みをGitリポジトリとして管理するのであれば、解析対象のソースコードは<a href="https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E3%82%B5%E3%83%96%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB">サブモジュール</a>として取り込むのがよいでしょう。</p>
<p>それらのソースコードからimport文を抽出するには、ASTを使用するのが最適です。ソースコードからASTを生成するためにはいくつかのやり方がありますが、今回は<a href="https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API">TypeScriptのCompiler API</a>を使用することとします。</p>
<p>sour-reactでは、必要なモジュールを都度named importsによって読み込むことを推奨しています。具体的な使用例は次の通りです。</p>
<pre><code class="language-tsx">import { Button, Tabs } from '@plaidev/sour-react';
</code></pre>
<p>このようなソースコードを解析して、named importsによって読み込まれているエクスポート名と、ソースコード内でimport文が出現する行数を取得します。たとえば次のような実装になります。</p>
<pre><code class="language-tsx">import fs from 'node:fs';
import ts from 'typescript';

type LineRange = {
  start: number;
  end: number;
};

type NamedImports = Record&lt;string, { lineRange: LineRange }&gt;

export function analyzeNamedImports(filePath: string, targetModuleName: string): NamedImports {
  const fileContent = fs.readFileSync(filePath, 'utf8');
  const sourceFile = ts.createSourceFile(filePath, fileContent, ts.ScriptTarget.Latest, true);

  const namedImports: NamedImports = {};

  function visit(node: ts.Node) {
    if (ts.isImportDeclaration(node)) {
      const moduleSpecifier = node.moduleSpecifier.getText().slice(1, -1); // Remove quotes

      if (moduleSpecifier === targetModuleName) {
        const start = sourceFile.getLineAndCharacterOfPosition(node.getStart()).line + 1;
        const end = sourceFile.getLineAndCharacterOfPosition(node.getEnd()).line + 1;
        const lineRange: LineRange = { start, end };

        const importClause = node.importClause;

        if (importClause) {
          if (importClause.namedBindings &amp;&amp; ts.isNamedImports(importClause.namedBindings)) {
            importClause.namedBindings.elements.forEach((element) =&gt; {
              const importName = element.propertyName?.text ?? element.name.text;
              if (!(importName in namedImports)) {
                namedImports[importName] = { lineRange };
              }
            });
          }
        }
      }
    }

    ts.forEachChild(node, visit);
  }

  visit(sourceFile);

  return namedImports;
}
</code></pre>
<p>そして、この結果を後続の処理で扱えるように、フラットな配列としてまとめます。</p>
<pre><code class="language-tsx">import { analyzeNamedImports, type LineRange } from './import-analyzer';

const targetModuleName = '@plaidev/sour-react';

export type NamedImportsStat = {
  sourcePath: string;
  moduleExportName: string;
  lineRange: LineRange;
};

export function getNamedImportsStats(filePaths: string[]) {
  const result: NamedImportsStat[] = [];

  for (const filePath of filePaths) {
    const namedImports = analyzeNamedImports(filePath, targetModuleName);

    for (const [moduleExportName, { lineRange }] of Object.entries(namedImports)) {
      result.push({
        sourcePath: filePath,
        moduleExportName,
        lineRange,
      });
    }
  }

  return result;
}
</code></pre>
<pre><code class="language-tsx">import fg from 'fast-glob';
import { analyzeFiles } from './import-analysis-organizer';

async function main() {
  const filePaths = await fg.glob('internal-library-reference-stats-user-a/**/*.{js,ts,jsx,tsx}');
  const namedImportsStats = getNamedImportsStats(filePaths);
  // ...
}

main().catch((e) =&gt; {
  throw e;
});
</code></pre>
<p>こうして作成した配列を、データの出力形式に応じて分類します。モジュールのエクスポート名とプロダクト名というそれぞれの軸に応じて処理します。</p>
<pre><code class="language-tsx">function groupByModuleExportName(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  // ...
}

function groupByUserPackage(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  // ...
}

const byModuleExportName = groupByModuleExportName(namedImportsStats);
const byUserPackage = groupByUserPackage(namedImportsStats);
</code></pre>
<p>データをプロダクトごとに分類する際には、import文が書かれているファイルがどの<code>package.json</code>に属しているかに基づいて処理します。<a href="https://github.com/sindresorhus/pkg-dir">pkg-dir</a>を使うことで、そのファイルの親に当たる<code>package.json</code>のパスを取得できます。</p>
<pre><code class="language-ts">import path from 'node:path';
import { packageDirectorySync } from 'pkg-dir';

function groupByUserPackage(namedImportsStats: NamedImportsStat[]): Map&lt;string, NamedImportsStat[]&gt; {
  const result = Map.groupBy(namedImportsStats, ({ sourcePath }) =&gt;
    packageDirectorySync({ cwd: path.dirname(sourcePath) })
  );
  // ...
}
</code></pre>
<p>これらのような操作によって、最終的に出力するコンテンツを生成します。実際の処理はやや複雑であるため、説明は割愛します。ご興味があればソースコードを見てみてください。</p>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats/blob/main/scripts/renderers.ts">internal-library-reference-stats/scripts/renderers.ts</a></p>
<p>最後に、これらの処理を定期的に実行させるために、GitHub Actionsのワークフローをセットアップします。ソースコードの解析を行う前に、サブモジュールとsour-reactのバージョンを最新の状態にアップデートするようにします。ワークフローは、日本時間で午前9時になるたび毎日実行されるように設定します。</p>
<pre><code class="language-yaml">name: Auto update

on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

jobs:
  auto-update:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: true
      - name: Update submodules
        run: git submodule update --remote
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: npm
      - name: Install dependencies
        run: |
          npm ci
          npm update @plaidev/sour-react
      - name: Build
        run: npm run build
      - name: Commit changes
        run: |
          git config user.name github-actions[bot]
          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
          git add --all
          git commit -m &quot;Automated build&quot;
          git push
</code></pre>
<h2>internal-library-reference-statsの使い方</h2>
<p><a href="https://github.com/yuheiy/internal-library-reference-stats">internal-library-reference-stats</a>はOSSとして公開されているので、どなたでもご自由に利用することができます。基本的には、次のようにすることで使い始められます。</p>
<ol>
<li>
<p>internal-library-reference-statsをテンプレートリポジトリとして新規リポジトリを作成する</p>
</li>
<li>
<p>作成したGitリポジトリをクローンする。<code>git clone</code>に<code>--recursive</code>フラグを付与するとサブモジュールも併せてクローンできるが、この時点では不要</p>
</li>
<li>
<p>サンプル用のサブモジュールとその設定を削除する</p>
<pre><code class="language-sh">rm -rf user-repositories/*/
rm .gitmodules
git add .
git commit -m &quot;deinit submodules&quot;
</code></pre>
</li>
<li>
<p>解析対象のGitリポジトリをサブモジュールとして追加する</p>
<pre><code class="language-sh">git submodule add https://github.com/&lt;user&gt;/&lt;name&gt; user-repositories/&lt;name&gt;
</code></pre>
</li>
<li>
<p>サブモジュールをクローンするためにトークンが必要であれば、<code>.github/workflows/auto-update.yml</code>でのチェックアウトのステップにトークンを設定する</p>
<pre><code class="language-yml">- name: Checkout
  uses: actions/checkout@v4
  with:
    token: ${{ secrets.GITHUB_ACCESS_TOKEN }}
    submodules: true
</code></pre>
</li>
<li>
<p><code>package.json</code>の<code>name</code>を任意の名前に変更する。これが<code>README.md</code>のタイトルになる</p>
</li>
<li>
<p>解析対象のモジュールをインストールする</p>
<pre><code class="language-sh">npm remove antd
npm install @plaidev/sour-react
</code></pre>
</li>
<li>
<p><code>scripts/config.ts</code>の設定を書き換える</p>
<ul>
<li><code>targetModuleName</code>は解析対象のモジュール名。この記事で言うところの<code>@plaidev/sour-react</code></li>
<li><code>targetModuleTitle</code>は解析対象のモジュールのタイトル。<code>README.md</code>に表示される。<code>targetModuleName</code>と同じでも構わない</li>
<li><code>targetModuleUrl</code>は解析対象のモジュールのURL。<code>README.md</code>からリンクされる</li>
<li><code>userPackageNameMap</code>はプロダクトの表示名。対象となるプロダクトのディレクトリへのパスと、その名前の対応関係を設定する。未設定の場合は、ディレクトリのパスが表示名として出力される。ビルドを実行することで対象ディレクトリを把握できるので、一度ビルドを行ってからの方が設定しやすい</li>
</ul>
</li>
<li>
<p><code>.github/workflows/auto-update.yml</code>でのインストールのステップで、解析対象のモジュールをアップデートするように設定する</p>
<pre><code class="language-yml">- name: Install dependencies
  run: |
    npm ci
    npm install @plaidev/sour-react@latest
</code></pre>
</li>
<li>
<p>依存関係をインストールしてからビルドする。プロダクトの表示名が未設定の場合はディレクトリのパスが出力されるので、別の表示名にしたければ<code>scripts/config.ts</code>で設定する</p>
<pre><code class="language-sh">npm ci
npm run build
</code></pre>
</li>
<li>
<p><code>.github/workflows/auto-update.yml</code>でコメントアウトされた<code>schedule</code>を有効化する</p>
<pre><code class="language-yml">on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:
</code></pre>
</li>
<li>
<p>変更をコミットしてプッシュする</p>
</li>
</ol>
<h2>最後に</h2>
<p>ライブラリの使用状況を解析する仕組みについては、ライブラリを開発するエンジニアであれば一度は考えたことがあるかと思いますが、開発コストや実現可能性などの問題により、実際に作成された例はあまり多くはないのではないでしょうか。</p>
<p>今回作成したこの仕組みをオープンソースとして公開することで、みなさんの開発現場においても、使用状況の可視化を実現するための助けになれば幸いです。</p>


プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。

ソースコードを解析して社内向けUIライブラリの使用状況を自動で集計する

<p>ごきげんよう、@tik-son です。</p>
<p>2024年7月25日(木)に開催された <a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service Dev Day（AOAI Dev Day）</a>にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。<br>
今回はそのレポートをお届けします。</p>
<h2>イベント概要</h2>
<p>AOAI Dev Day は、Azure OpenAI Service を活用する開発者コミュニティの祭典です。<br>
「開発者が実際のプロジェクトから得た経験や教訓を共有する」という趣旨のもと、実践的なセッションが多く見受けられ、オフライン開催限定ならではの一体感と熱気に包まれていました！</p>
<h2>登壇内容サマリー</h2>
<p>今回の私のセッションでは、プレイドが開発する PaaS である「KARTE Craft」の開発を支援する AI アシスタント「Craft Copilot」の仕組みについて、アーキテクチャや技術選定の背景を交えながら解説しました。</p>
<script defer class="speakerdeck-embed" data-id="b43df62d30944212a86f0c5e92c65d8b" data-ratio="1.7772511848341233" src="//speakerdeck.com/assets/embed.js"></script>
<h3>Craft Copilot とは？</h3>
<p>「Craft Copilot」は、KARTE Craft での開発体験を向上させるために生まれた AI アシスタントです。<br>
現在β版として提供中で、将来的には KARTE Craft を利用する開発者の強力なパートナーとなることを目指しています。</p>
<h3>Craft Copilot の機能</h3>
<p>Craft Copilot は、色々あるのですが、今回の登壇では主要機能である以下の2つの機能についてお話しました。</p>
<ol>
<li><strong>AI によるサイト制作支援</strong><br>
Craft Sites Copilot」機能により、HTML や CSS のコードを書かずに、自然言語の指示やイメージ画像から Web ページを自動生成できます。</li>
<li><strong>Craft のルールを踏まえたコード改善</strong><br>
既存のコードを Craft のルールに沿って自動的に修正できます。</li>
</ol>
<h3>技術スタックの裏側</h3>
<p>Craft Copilot は、Microsoft が提供する Azure OpenAI Service を中心に、Azure の様々なサービスを組み合わせて開発されています。</p>
<p><strong>Azure OpenAI Service (GPT-4o, GPT-4o-mini)</strong></p>
<ul>
<li>自然言語処理の中核を担っており、HTML 生成やコード修正の指示理解、回答生成などを実現しています。</li>
</ul>
<p><strong>Azure AI Search</strong></p>
<ul>
<li>Craft Copilot が参照するドキュメントをベクトル化して保存・検索するために利用しています。</li>
<li>セマンティックハイブリッド検索によって、高精度な検索を実現しています。</li>
</ul>
<p><strong>Azure API Management</strong></p>
<ul>
<li>API の可用性、キャパシティ、メンテナビリティを向上させるために利用しています。</li>
<li>Backend Pool やサーキットブレーカーを活用することで、柔軟な API 運用を実現しています。</li>
</ul>
<h2>登壇を終えて</h2>
<p>今回の AOAI Dev Day では、Craft Copilot のアーキテクチャや Azureサービス利用におけるTips などに対して高い関心を寄せていただき、登壇後に、Ask the Speakerで多くの方とお話ししました。</p>
<p>また、他の登壇者の方々との交流を通して、Azure OpenAI Service を活用したサービス開発の最新動向や、AI 開発における課題や展望を共有することができ、<br>
改めて、Azure OpenAI Service は、開発者にとって大きな可能性を秘めていることを実感しました。</p>
<h2>イベント後のアップデート</h2>
<p>実は、今回の登壇時には OpenAI の GPT-4o-mini を利用していたのですが、先日、<a href="https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/openai-s-gpt-4o-mini-now-available-in-api-with-vision/ba-p/4200640">Azure OpenAI Service 版の GPT4o-mini がリリース</a>されたので置き換えました。<br>
このスピード感は開発者としてはありがたいですね。</p>
<p>Craft Copilot はまだβ版ですが、今後も Azure OpenAI Service の最新機能やアップデートを積極的に活用し、より強力な AI アシスタントを目指して、今後も開発を続けていきます。<br>
一緒に改善していきたい人も<a href="https://recruit.plaid.co.jp/requisitions/product-engineer">絶賛募集中</a>です！</p>


2024年7月25日(木)に開催された Azure OpenAI Service Dev Day（AOAI Dev Day）にて、「Microsoft の AI 技術をベースに構成される Craft Copilot」というタイトルで登壇してきました。今回はそのレポートをお届けします。

Azure OpenAI Service Dev Day に登壇しました_プレイドエンジニアブログ

Azure OpenAI Service Dev Day に登壇しました

<h1>はじめに</h1>
<p>こんにちは、プレイドのCore Platformチームに所属している西村です。今回のブログではGCE上でセルフホストしていたMongoDBインスタンスをMongoDB Atlasに移行した際の取り組みについて紹介します。移行に伴う要件や制約を考慮した結果、今回はあえてMongoDB固有の機能を使わずにGKEのJobを使って愚直にデータ移行する方法を採用したので、同じような移行作業を行う場合は参考になれば幸いです。</p>
<h2>背景</h2>
<p>プレイドではDBとして多くの部分で<a href="https://www.mongodb.com/ja-jp/atlas">MongoDB Atlas</a>を使用しています。MongoDB Atlasでは定期的にサポートバージョンが更新され、プレイドでもそれに合わせて適宜バージョンアップ対応を行っています。<a href="https://tech.plaid.co.jp/internship-mongodb-update">前回のバージョンアップ作業</a>は2023年末から2024年3月頃にかけて実施したのですが、そこで長らくGCE上で稼働していた古いバージョンのMongoインスタンスをこの機会にMongoDB Atlasに移行することにしました。</p>
<p>このインスタンスはOplogというKARTEの管理画面の操作履歴を保存しているもの（以降、旧Oplog）で、通常はほとんど参照されないデータなのでこれまでのバージョンアップ作業でも見落とされてしまっていました。しかし今回のバージョンアップでこのインスタンスで稼働しているMongoのバージョン（3.x）と更新後のバージョン（5.x）の互換性がなくなるため、こちらもバージョンアップ対応するかMongoDB Atlasに移行するか選択する必要がありました。今後のバージョンアップ対応や管理の煩雑さを考えて、この機に旧Oplogを廃止してMongoDB Atlas（以降、新Oplog）に移行する判断をしました。</p>
<h2>移行方法の検討</h2>
<p>移行にあたってまず要件を決める必要があります。今回の移行プロジェクトの要件は以下のように定めました。</p>
<ul>
<li>旧Oplogの過去データをすべて新Oplogに移行する</li>
<li>サービスは無停止でデータおよび書き込み先の移行を行う</li>
<li>想定外のトラブルがあってもデータの欠損が極力発生しないようにする</li>
<li>移行完了後に旧Oplogは廃止する</li>
</ul>
<p>上記の要件を満たすために以下の作業を順次実施することにしました。</p>
<ol>
<li>MongoDB Atlasに移行用Clusterを作成する（新Oplog）</li>
<li>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</li>
<li>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</li>
<li>データ移行完了後、旧Oplogへの書き込みを停止しインスタンスを破棄する</li>
</ol>
<p>図にすると以下のようなイメージです。<br>
<img src="https://ik.imagekit.io/plaid/ee37750e-63d1-47ac-9991-552cf0506361/migrate-oplog-2.png" alt="migrate-oplog-2.png"></p>
<p>以下ではそれぞれの手順で実施した内容について要点を解説します。</p>
<h3>旧Oplogの書き込みと同時に新Oplogにもデータを書き込む2重書き込みの仕組みを実装する</h3>
<p>DBの移行にあたって必要な作業は主にデータ移行と接続先の変更の2つです。論理的には旧Oplogに書き込んでいる箇所の書き込み先を新しく作成した新Oplogに変更すれば新規に書き込むデータに関しては移行できるはずですが、いきなり接続先を切り替えると不具合があって書き込みができないなどのトラブルが発生した場合にデータが欠損してしまうため、慎重を期すために従来通り旧Oplogへの書き込みをしつつ新たに新Oplogへも同時に書き込む仕組みを実装し、既存の仕組みに影響を与えないようにしました。</p>
<h3>2重書き込みが問題なくできていることを確認し、旧Oplogのデータを新Oplogに移行する</h3>
<p>2重書き込みについては特に大きな問題もなく実装することができました。これは一部のシステムを除いて旧Oplogを書き込む処理は社内の共通ライブラリ経由で実行されており、書き込み先の設定を変えて新Oplogへの書き込み処理を追加するだけで済んだためです。</p>
<p>あとは旧Oplogのデータを移行すれば必要な作業はほぼ終わりだったのですが、データ移行処理がなかなかうまくいかず試行錯誤が必要でした。その試行錯誤について詳しく見る前に、まずはMongoDBで推奨されているデータ移行方法と、なぜ今回それらの方法を採用しなかったのか簡単に説明します。</p>
<h3>MongoDB標準のデータ移行方法</h3>
<p>MongoDB標準のデータ移行方法としてJSON/CSVでの<a href="https://www.mongodb.com/docs/compass/current/import-export/">Import/Export</a>と<a href="https://www.mongodb.com/ja-jp/products/platform/migrate">Live Migration</a>があります。それぞれについて簡単に説明します。</p>
<h4>Import/Export</h4>
<p>Import/Exportは<a href="https://www.mongodb.com/ja-jp/products/tools/compass">MongoDB Compass</a>での操作もしくはCLIでそれぞれに対応したコマンドを実行することでCollectionのデータを指定したフォーマットでExportおよびImportすることができる機能です。前回のMongoバージョンアップ作業で4.x→5.xでも想定外の微妙な挙動の差異があったが今回は3.x→5.xなので動作差分が読めないこと、本番データ量が膨大（約2.3億レコード、500GB以上）で一括Importに懸念があることなどから今回は採用しないことにしました（とはいえ一度試してみてもよかったかも）。</p>
<h4>Live Migration</h4>
<p>Live MigrationはMongoDB Atlasで提供されている機能で、コンソールから設定するだけでオンプレミスも含めて任意の環境からMongoDB AtlasのClusterにデータ移行できるという機能です。Live Migrationではデータ移行中も移行元DBへの読み取りおよび書き込みが可能ですが、別のチームで試してみたところ断続的に常に書き込みが発生しているシステムだとデータ移行が完了できないという特性があり、完全に無停止でデータを移行しきるのは難しいとのことでした。</p>
<p>上記のようにMongoDBの標準的なデータ移行方法では今回の要件を満たすことが難しそうだったため、旧OplogからCursorでデータを取得し新Oplogに書き戻すという愚直な方針を採用することにしました。</p>
<h3>GKEでデータ移行用のJobを実行する</h3>
<p>プレイドではアプリケーションの実行環境として多くの場所でGKEを使用しています。既存のデプロイの仕組みを流用するため、今回はデータ移行用のスクリプトをGKEのJobで実行することにしました。データ移行にあたっては以下の手順で段階的に進めていきました。</p>
<ol>
<li>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</li>
<li>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</li>
<li>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</li>
</ol>
<p>以下で各手順で試した内容と結果を説明します。</p>
<h4>Dev環境にテスト用Clusterを作成し、少量のデータを移行する</h4>
<p>まずは旧Oplogから取得した任意のデータを新Oplogに書き込めることを確認するため、Dev環境で作成したテスト用ClusterにEvaluation環境の旧Oplogの1日分のデータを書き込んでみることにしました。データ量としては約5000〜6000レコード程度で、以下のような移行スクリプトで問題なく書き込めることが確認できました（サンプル用に簡略化しています）。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行時点以前のデータを抽出する（日付は仮）
  const dateBegin = new Date('2024-04-01T00:00:00.000+00:00');
  const dateEnd = new Date('2024-04-02T00:00:00.000+00:00');
  const cursor = oplogGce.find({ timestamp: { $gte: dateBegin, $lt: dateEnd } }).cursor({ batchSize: 5000 });

  cursor.on('data', (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    oplog.save();
  });

  cursor.on('end', () =&gt; {
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h4>Evaluation環境に移行用Clusterを作成し、Evaluationの旧Oplogのデータを移行する</h4>
<p>テスト用Clusterへの書き込みが問題なく行えたので次はEvaluationの過去データ（約300万件、5GB程度）を移行するために日付の指定と書き込み先を変えて先ほどのJobを動かしたところOOM(Out Of Memory)エラーが発生するようになりました。</p>
<p>お気づきの方も多いかと思いますが、先ほどのコードではCurosrで取得したデータを1件ずつ書き込んでいたためデータ件数が多くなると書き込み処理が追いつかずOOMが発生してしまいます。今回のケースだと数万件程度処理が進んだ段階でOOMが発生しました。OOMを避けるためバッチサイズごとにバルクで書き込むように修正することでOOMの発生を抑えることができました。</p>
<pre><code class="language-typescript">(async () =&gt; {
  console.log('Start: oplog-migration');
  const oplogGce = OperationLog(...);
  const oplogAtlas = OperationLogAtlas(...);

  // 移行対象のデータを抽出する（日付は仮）
  const date = new Date('2024-04-01T00:00:00.000+00:00');
  const batchSize = 5000;
  const cursor = oplogGce.find({ timestamp: { $lte: date } }).cursor({ batchSize });

  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
    }
  });

  cursor.on('end', async () =&gt; {
    if (bulkOps.length &gt; 0) {
      await oplogAtlas.bulkWrite(bulkOps);
    }
    console.log('End: oplog-migration');
  });
})();
</code></pre>
<h5>途中でJobが止まる問題が発生</h5>
<p>前項のようにCurosrで取得したデータをバルクでまとめて処理することで安定的にJobを実行することができるようになりましたが、今度は20万件程度のデータを処理した時点で、残りの処理が完了する前にJob自体が終了してしまうという問題に遭遇しました。ここに至るまでにもOOM対策としてヒープメモリを追加したりCPUスペックの強化、 <code>async/await</code> で新Oplogへの書き込み結果を待つなどの試行錯誤をしてきたのですが、エラーログやGKEのメトリクスを見ても特に問題はなく、Jobとしてはすべての処理が完了して正常終了しているように見えました。</p>
<p>原因を調べるために調査用のログを仕込んで観察してみると、どうやら新Oplogへ書き込んでいる箇所のawaitが効いていなさそうだということがわかりました。つまり新Oplogへの書き込み箇所でawaitすることで書き込み処理の完了を待っているつもりだったのですが、Cursorの <code>on('data', ...)</code> はデータがある限り実行され続けてしまうため、新Oplogへの書き込みが完了する前にCursorの読み込みが終わってしまうという状態になっていそうだということがわかりました。</p>
<p>上記の現象の対策として新Oplogへの書き込み中はCursorの読み込みを一時停止し完了後に再開することで、無事に意図通りの挙動にすることができました。最終的なコードは以下のようになりました。</p>
<pre><code class="language-typescript">  let bulkOps: any[] = [];
  cursor.on('data', async (doc: any) =&gt; {
    const oplog = new oplogAtlas(doc.toObject());
    bulkOps.push({ insertOne: { document: oplog } });

    if (bulkOps.length === batchSize) {
      cursor.pause();  // 書き込み前にCursorの読み込みを中断
      await oplogAtlas.bulkWrite(bulkOps);
      bulkOps = [];
      cursor.resume();  // 書き込み完了後にCursorの読み込みを再開
    }
  });
</code></pre>
<h4>Production環境に移行用Clusterを作成し、Productionの旧Oplogのデータを移行する</h4>
<p>前項まで見てきたようにいろいろな落とし穴にハマりつつ、なんとか安定的にJobを動かしCursorで逐次的にデータを取得しMongoDB AtlasのClusterに大量データを書き込むという一連の処理を実装することができました。最後の仕上げとしてProduction環境の旧Oplogから新Oplogへのデータ移行Jobを実行して無事に全データを移行することができました。ちなみにProductionのデータは5年以上分、500GB程度ありJobの完了までに27時間程度かかりました。</p>
<h2>まとめ</h2>
<p>本ブログではGCE上で稼働しているMongoDBインスタンスを無停止でMongoDB Atlasに移行した取り組みを紹介しました。今回の取り組みではサービス固有の機能に依存しない汎用的な手法で移行を行ったので、似たような作業をされる場合の一つの方法として参考になれば幸いです。</p>


GCE上でセルフホストしていたMongoDBインスタンスをサービス無停止でMongoDB Atlasに移行した取り組みを紹介します

セルフホストしてるMongoDBをMongoDB Atlasに移行した話_プレイドエンジニアブログ

セルフホストしているMongoDBをMongoDB Atlasに移行した話

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

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

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

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

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


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

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

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

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

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

<p>こんにちは、プレイドでCore Platform開発の責任者をしているエンジニアのkusappeです。</p>
<p>プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてブログ化しました。<br>
この記事では、Modern Data Stackとは何か、そのメリットや特徴について解説します。また、具体的な技術要素・主要サービスや重要だと思うトレンドについても紹介します。</p>
<h2>Modern Data Stackとは？</h2>
<p>Modern Data Stackとは、データの収集、処理、分析、可視化などデータ活用に関わる機能を、それぞれに特化したクラウドサービスやSaaSツールを組み合わせて構築するという考え方やその基盤のことを指します。<br>
クラウドサービスやその周辺の技術要素の進化によって、従来のデータ基盤と比べると以下のメリットがあると言われています。</p>
<ul>
<li>高いスケーラビリティや可用性を実現できる</li>
<li>SaaSを組み合わせてスピーディーにデータ基盤の環境を構築できる</li>
<li>簡単にツールを使えるようになり、誰でもデータの利活用ができる状態になる（データの民主化）</li>
</ul>
<p>そして、dbtのCEOは2020年に書いた<a href="https://www.getdbt.com/blog/future-of-the-modern-data-stack">Modern Data Stackの過去・現在・未来のブログ</a>で、「2021〜2025年にかけてさらなるイノベーションが起きるのでは？」と予測しています。<br>
データの活用をより加速させるためにも、具体的な技術要素や主要なSaaSサービスを押さえておくのはとても重要だと思います。それでは見ていきましょう。</p>
<h2>具体的な技術要素・主要なサービス</h2>
<p>個々の技術要素を説明する前に、まずはModern Data Stackの全体像（図1）を見てみましょう。今回紹介する図以外にも全体像の図はいくつかあるため、本記事末の参考資料のところに載せておきます。</p>
<p><img src="https://ik.imagekit.io/plaid/d538514d-1860-4e0c-abc1-5cb49e44b234/ModernDataStack_Overview.png" alt="ModernDataStack_Overview.png"><br>
図1. Modern Data Stack 全体像 ( https://www.moderndatastack.xyz/journal/the-modern-data-stack-ecosystem-spring-2022-edition-5qe )</p>
<p>それでは各カテゴリーと主要サービスを見ていきましょう。データの流れの観点から大きく、データ収集、データ処理、データ活用、その他（横断系）の4つに分類して解説します。</p>
<h3>データ収集</h3>
<ul>
<li>
<p>Data Warehouse<br>
Data Warehouseとは企業内の多種多様な大量データを貯め、様々な分析を行うために特化されたサービスのことです。Warehouse（倉庫）という言葉からも連想されるように、構造化されたデータを扱うイメージが強いです。画像やテキストなどの非構造化データを扱う場合は、Data Lakeという言葉が使われます。<br>
その中で一つ注目したいトレンドとして、ETLからELTへのシフト（図2）があります。<br>
Data Warehouse側の技術進化によって、まずはロードしてその後変換が簡単に実現できるようになりました。ETLと比べた場合のELTは、高速・低メンテナンス・ロードが1回で済むといった利点があります。<br>
ELTが標準になることによって、Data Warehouse内でのData Transformationの管理ニーズが高まってきました。</p>
<p><img src="https://ik.imagekit.io/plaid/10231ec1-5aa6-496b-9c56-9babf6c01ea6/ETL_ELT.png" alt="ETL_ELT.png"><br>
図2. ETLとELT ( https://aws.amazon.com/jp/compare/the-difference-between-etl-and-elt/ )</p>
</li>
<li>
<p>Data Integration<br>
様々なデータソースからデータウェアハウスにデータを集めるための連携ツール（図3）です。<br>
主要なSaaSとして、<a href="https://www.fivetran.com/">Fivetran</a> や <a href="https://airbyte.com/">Airbyte</a> があります。<br>
双方の立場から比較記事が出ているので興味ある方は見てみてください。</p>
<ul>
<li><a href="https://airbyte.com/etl-tools/fivetran-alternative-airbyte">Airbyte側の主張 (Fivetran vs Airbyte)</a></li>
<li><a href="https://www.fivetran.com/blog/fivetran-vs-airbyte-features-pricing-services-and-more">Fivetran側の主張 (Fivetran vs Airbyte)</a></li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/7b0729d6-51e1-437a-b7e4-4c71823c364e/Data_Integration_Overview.png" alt="Data_Integration_Overview.png"><br>
図3. Data Integration ( https://www.fivetran.com/data-movement )</p>
</li>
<li>
<p>Event Tracking<br>
Websiteでのクリック情報など、ユーザーの行動情報を取得するツールのことを指します。<br>
<a href="https://segment.com/">Segment</a>や<a href="https://www.rudderstack.com/">Rudderstack</a>あたりがグローバルでも有名ですね。<a href="https://karte.io/">KARTE</a>もこのリストの仲間に入れるように頑張らなくではと思います。<br>
SegmentとRudderstackに共通する点としては、Customer Dataを軸としてそれをマーケティングに使うだけではなく、データのTransformation機能や他の業務ツールとの連携など多岐にわたって活用していることが挙げられます。</p>
</li>
</ul>
<h3>データ処理</h3>
<ul>
<li>
<p>Data Transformation<br>
Data Warehouseにロードしたデータを使いやすい形に変換するレイヤーです。<br>
Warehouse側の技術進化によってSQLでできることが増え、基本的な処理はSQLで行うのが主流になってきています。<br>
そのデータ変換用のSQLを管理するフレームワークとして、<a href="https://www.getdbt.com/">dbt</a> や <a href="https://cloud.google.com/dataform?hl=ja">Dataform</a>があります。<br>
プレイドでのdbtの活用方法は先日<a href="https://tech.plaid.co.jp/signals_connector_dbt">ブログに記載</a>したのでよかったらみてください。</p>
</li>
<li>
<p>Metric Store<br>
一言でいうと、分析の際に使う指標や数値（メトリクス）の定義を一元管理するツールです。<br>
今までは各BIツールでメトリクス定義を管理していましたが、それによって以下問題が起きていました。<br>
- レポーティングで使う数値の定義が、各チーム・各BIツールによって違っていて何が正解なのかわからない<br>
- 運用管理しようとしても、定義がBIツールごとに散らばり重複しているので管理が大変<br>
メトリクスの定義管理をBIツールとは分離し、再利用可能にするというのがコンセプトです（図4）。Headless BIとも呼ばれます。<br>
SaaSとしては、<a href="https://www.getdbt.com/product/semantic-layer">dbt（semantic layer）</a>、<a href="https://metriql.com/">Metriql</a> 、<a href="https://cube.dev/">cube</a> があります。<br>
<img src="https://ik.imagekit.io/plaid/ee409271-1c44-416c-9b5b-d8c1df2aeab6/Metric_Store.png" alt="Metric_Store.png"><br>
図4. Metric Storeのコンセプト( https://benn.substack.com/p/metrics-layer )</p>
</li>
</ul>
<h3>データ活用</h3>
<ul>
<li>
<p>Data Analytics<br>
この領域はBIツールなど、みなさんご存知だと思うので割愛します</p>
</li>
<li>
<p>Reverse ETL<br>
Reverse ETLとは、Data Warehouseのデータを他のシステム（CRM、Marketing Tool、Operation用のSaaSなど）に連携する手法（図5）を指します。<br>
Data warehouseに入ったデータやその分析を最後アクションに結びつけることから、Data Activationとも呼ばれます。<br>
収集した生データや変換されたデータをビジネス上の価値に繋げるための重要な架け橋の一つだと考えられています。<br>
Reverse ETL / Data ActivationのSaaSは、<a href="https://www.rudderstack.com/">rudderstack</a>, <a href="https://www.getcensus.com/">Census</a> , <a href="https://hightouch.com/">hightouch</a> があります。<br>
<img src="https://ik.imagekit.io/plaid/939a59d5-f580-462b-955f-dd10eadad6c2/Data_Activation.png" alt="Data_Activation.png"><br>
図5. Data Activation ( https://www.getcensus.com/solutions/data-teams )</p>
</li>
</ul>
<h3>その他（横断系）</h3>
<ul>
<li>
<p>Data Governance<br>
ここまで説明したツールの進化によってデータの活用が進むと、今度はデータの運用管理が大変になり、管理ツールへのニーズが高まってきました。<br>
データ運用管理に求められる機能としては以下があります。</p>
<ul>
<li>データカタログ
<ul>
<li>組織内にあるデータを検索・発見する</li>
</ul>
</li>
<li>データリネージ
<ul>
<li>どこからどこへデータが流れたのかを可視化・監視する</li>
</ul>
</li>
<li>データオブザーバビリティ
<ul>
<li>今流れているデータのEnd-to-Endのモニタリングする（可視化、品質チェックetc）</li>
</ul>
</li>
</ul>
<p>各機能についてData Warehouse側でも提供しています。たとえば、<a href="https://www.databricks.com/jp/product/unity-catalog">DatabricksのUnity Catalog</a>、<a href="https://cloud.google.com/data-catalog?hl=ja">GCP Data Catalog</a>などなど。各種サービス跨いだ管理ツールとしては<a href="https://atlan.com/">Atlan</a>や<a href="https://www.montecarlodata.com/">MONTE CARLO</a> があります。</p>
<p>いずれの機能も内部的には各種サービスからメタデータを収集し、それを目的に応じて使用しているという構造になっています（図6）。なので、どれぐらい解像度高くリアルタイムでメタデータを収集できるかがポイントと言えます。<br>
　 <img src="https://ik.imagekit.io/plaid/a6f2dba8-5e18-44f4-aa16-1d066047fb28/Metadata_Lake.png" alt="Metadata_Lake.png"><br>
図6. Metadata管理 ( https://atlan.com/what-is-data-governance/?ref=/modern-data-stack-101/ )</p>
</li>
<li>
<p>Data Orchestration<br>
上で話したようなデータの収集・処理・活用を実行するために、タスクのワークフロー管理を行うツールを指します。<br>
主に<a href="https://airflow.apache.org/">Airflow</a>、<a href="https://www.prefect.io/">Prefect</a>、<a href="https://dagster.io/">dagster</a>あたりが有名です。</p>
</li>
</ul>
<h2>まとめ</h2>
<p>さて、Modern Data Stackとは何かから始めて、カテゴリーごとの技術要素・代表的なサービス・重要だと思うトレンドを解説しました。<br>
あくまで概要を説明しただけなので、実際にデータ基盤を構築しようとした際はいろいろなトピックを深掘りする必要が出てきます。参考資料にも今回調べたリンクを載せたので、みなさんが各トピックの詳細を知る上での手助けになれば幸いです。</p>
<h2>参考資料</h2>
<ul>
<li>Modern Data Stack全体像の図
<ul>
<li><a href="https://twitter.com/ValentinUmbach/status/1418242294952644611">https://twitter.com/ValentinUmbach/status/1418242294952644611</a></li>
<li><a href="https://www.indicative.com/resource/modern-data-infrastructure/">https://www.indicative.com/resource/modern-data-infrastructure/</a></li>
</ul>
</li>
<li>Modern Data Stack概論
<ul>
<li><a href="https://speakerdeck.com/satoshihirose/modandetasutatukugai-lun">https://speakerdeck.com/satoshihirose/modandetasutatukugai-lun</a></li>
</ul>
</li>
<li>Modern Data Stack Repository
<ul>
<li><a href="https://www.moderndatastack.xyz/">https://www.moderndatastack.xyz/</a></li>
</ul>
</li>
</ul>


プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてModern Data Stackの概要、主要サービス、重要だと思うトレンドをまとめました。

社内勉強会「Modern Data Stack入門」の内容をブログ化しました - PLAID engineer blog

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

<p>あけましておめでとうございます。エンジニアの Yui です。</p>
<h2>はじめに</h2>
<p>KARTE では毎年、年越し(1/1 0:00)のタイミングで KARTE を導入している一部のウェブサイトにおける新年のキャンペーンやセール開始によるリクエスト急増が見込まれます。このリクエスト急増に対応する事前のスケールアップやリアルタイムでの対応を一部のエンジニアで行なっています。</p>
<p>通常時はクラウド上のほぼ全てのリソースのスケーリングを自動化しているのですが、コストやコールドスタートに対する対策の観点からこのタイミングのみ一部を手動で対応しています。</p>
<p>この記事では今年どんな対応を行なったのかを記録として残しておきたいと思います。</p>
<h2>今回スケールさせた部分について</h2>
<p>KARTE ではインフラの大部分に Google Cloud を利用しています。今回スケールさせるのは主に Google Cloud のサービス群（Cloud Bigtable（以下 BigTable）, Google Kubernetes Engine（以下 GKE）, Compute Engine（以下 GCE） など）になります。</p>
<p>今回の対応部分である、KARTEのリアルタイム解析基盤についてざっくり説明します。<br>
<img src="https://ik.imagekit.io/plaid/57731d06-9649-41ae-9b82-bece8247f89c/%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-01-1513.13.57.png" alt="スクリーンショット2024-01-1513.13.57.png"><br>
<a href="https://karte.io/feature/core-realtime/">リアルタイムユーザー解析</a></p>
<p>KARTE の JavaScript タグが入っているウェブサイトにユーザーが訪れると、そのユーザーの閲覧やクリックなどのウェブサイト上での行動（ = <strong>イベントデータ</strong>）が KARTE のサーバーに送られます。KARTE のサーバーは受け取ったイベントデータをリアルタイムに解析します。また、事前に設定している施策配信を行うかどうか（このページを閲覧した人にはこのポップアップを出す、など）の判定を行い、結果をウェブサイト側に返します。</p>
<p>この解析や配信判定処理を担当しているのがリアルタイム解析基盤と呼んでいる部分で、レイテンシやサーバー負荷状況がサイト上のユーザー体験にクリティカルに影響します。<br>
（リアルタイム解析基盤のアーキテクチャについて詳しく知りたい方はこちらの記事をご参照ください。 <a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a> ）</p>
<h2>事前準備</h2>
<p>リアルタイム解析基盤はざっくり分けてユーザーの解析や配信判定などリアルタイムに処理する必要がある部分と、イベントデータの永続化など非リアルタイムの処理でよい部分があります。<br>
アーキテクチャや過去の対応実績をもとに特に前者に重点を置き、何をどの程度スケールさせるのかを事前に検討しました。</p>
<p>準備として実際に当日までに行った内容は以下です。</p>
<ul>
<li>
<p>当日の対応内容の読み合わせ（今回は4名で対応しました）</p>
</li>
<li>
<p>誰がどの部分を担当するのかを決める</p>
</li>
<li>
<p>各自担当部分についてスケールさせる値を決める</p>
<ul>
<li>昨年の年明けタイミングや直近1ヶ月の定常時のリクエスト数・インスタンス数の平均・最大値などを確認して判断しました</li>
</ul>
</li>
<li>
<p>Terraform や GKE の manifest など IaC で対応する部分は当日までに PR を作成し、レビューを済ませておく</p>
<ul>
<li>当日はこの PR をマージすることで CI/CD パイプラインが走り、変更が適用されます</li>
</ul>
</li>
<li>
<p>BigTable のスケールアウト検証</p>
<ul>
<li>BigTable は最小ノード数を増やしたからといって必要なリソースが確保できるかを確約していません。そこで、実際の環境で少なくとも数日前の時点で想定量までスケールできるかという点や、当日の作業手順確認の目的で事前検証を行いました。（数日前時点でスケールできたからといって当日に同じリソース量までスケールできることが確約されていない点は注意が必要です）</li>
</ul>
<blockquote>
<p>ノード割り当てとは、各プロジェクトで 1 つのゾーンにプロビジョニングできるノードの最大数です。この割り当て数にまだ達していなくても、クラスタにノードを追加できるとは限りません。ゾーンでこれ以上ノードを利用できない場合、プロジェクトで割り当てが残っていても、そのゾーンのクラスタにノードを追加できないことがあります</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/quotas?hl=ja#availability">割り当てと上限  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
<blockquote>
<p>ゾーンでノードがなくなると、構成した最小ノード数を満たすように追加ノードがプロビジョニングされません。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/autoscaling?hl=ja#determine-min">自動スケーリング  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
</li>
</ul>
<p>作業内容や担当、進捗についてはこんな感じで Notion で管理しました。<br>
<img src="https://ik.imagekit.io/plaid/53d77f2c-8d01-4bb4-9dab-65a83469c146/tasks.jpg" alt="tasks.jpg"></p>
<h2>当日やったこと</h2>
<p>作業当日（2023/12/31）は事前に決定した通りに以下の手順で作業を行いました。</p>
<ul>
<li>
<p>20:30 に Slack に集合</p>
</li>
<li>
<p>通常時に利用している自動スケール設定のモニタリングを OFF にする</p>
</li>
<li>
<p>Datadog のログ量を調整する</p>
<ul>
<li>普段から Datadog への書き込みが多いかつ重要度の低いログを一時的に停止させることで、不要なコストがかかることを防止する目的で行いました。</li>
</ul>
</li>
<li>
<p>BigTable クラスタのノードサイズの最小値を手動で徐々に上げていく</p>
<ul>
<li>
<p>BigTable はノードを増やすと一時的にレイテンシが増加し負荷がかかった状態が続く可能性があり、ユーザー体験に影響を与える可能性があります。一気に上げてレイテンシが高い状態が続くのを避けるため、都度レイテンシを確認しながら手動で徐々に上げるようにしました。</p>
<blockquote>
<p>クラスタ内のノード数が増加した後、クラスタのパフォーマンスが大幅に向上するまでに、負荷のかかった状態が最大 20 分間続く可能性があります。Bigtable は、その負荷に基づいてクラスタ内のノードをスケーリングします。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/performance?hl=ja#slower-perf">パフォーマンスについて  |  Cloud Bigtable ドキュメント  |  Google Cloud</a></p>
</li>
</ul>
</li>
<li>
<p>IaC 対応部分のPRをマージし、変更後の値までスケールすることを確認</p>
</li>
<li>
<p>Datadog のダッシュボードでスケール台数やエラーレート、レイテンシを監視し異常がないかを確認<br>
<img src="https://ik.imagekit.io/plaid/1f2e893a-0a49-4e39-9cce-efb048e06469/datadog.jpg" alt="datadog.jpg"><br>
▲こんな感じで作業と並行してダッシュボードを継続して確認していました</p>
</li>
</ul>
<p>以下は 2023/12/31 23:00 〜 2024/1/1 1:00 までのイベント数や接客数・スループットを Datadog のダッシュボードに描画したグラフです。0:00 のタイミングでリクエストが急増しているのがわかります。<br>
<img src="https://ik.imagekit.io/plaid/eea55fa4-e87e-4582-bea4-9baa1530368c/%E3%82%A4%E3%83%98%E3%82%99%E3%83%B3%E3%83%88%E6%95%B0.jpg" alt="イベント数.jpg"></p>
<p>当日は事前準備した内容の実施に加え、想定よりもリクエスト数が増えそうな兆候があったため追加でインスタンス数を増やすなどの対応を行いました。</p>
<h2>後片付け</h2>
<p>0:00〜0:30ごろをピークにリクエスト数が徐々に落ち着いていくのを確認しました。その後1:00頃からPRのリバートや手動でスケールさせた部分のスケールインを行いました。</p>
<p>スケールイン時も急激に台数を減らすとサーバーの負荷増加や BigTable のレイテンシ増加などでパフォーマンスが低下するおそれがあるため、対応方法に注意する必要があります。</p>
<p>今回対応した部分（BigTable, GKE,  GCE）に関してはスケールインを自動で徐々に行う設定が入ってることを確認し、スケールインを実行しました。</p>
<blockquote>
<p>クラスタ内のノード数を減らしてスケールダウンする場合、10 分間に 10% を超えるクラスタサイズの縮小は行わないようにしてください。スケールダウンが速すぎると、クラスタ内の残りのノードが一時的に過負荷になる場合にレイテンシが増加するなど、パフォーマンス上の問題が発生する可能性があります。</p>
</blockquote>
<p><a href="https://cloud.google.com/bigtable/docs/scaling?hl=ja#scale-down">スケーリング | Cloud Bigtable ドキュメント | Google Cloud</a></p>
<blockquote>
<p>Kubernetes offers features to help you run highly available applications even when you introduce frequent voluntary disruptions.<br>
As an application owner, you can create a PodDisruptionBudget (PDB) for each application. A PDB limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions.</p>
</blockquote>
<p><a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/">Disruptions | Kubernetes</a></p>
<blockquote>
<p>スケールインの速度を制御するには、追跡時間枠内でのオートスケーラーの最大許容削減数を構成します。</p>
<ul>
<li><strong>最大許容削減数</strong>（<code>maxScaledInReplicas</code>: VM インスタンスの数または割合）。指定された追跡時間枠内においてワークロードで（グループのピークサイズから）削除できるインスタンスの数。このパラメータを使用して、グループをどれだけスケールインできるかを制限します。これにより、より多くのインスタンスがサービスを開始するまで、発生しうる負荷スパイクに引き続き対応できます。最大許容削減数が小さいほど、スケールインの速度は遅くなります。</li>
<li><strong>追跡時間枠</strong>（<code>timeWindowSec</code>: 秒）一時的な負荷減少の後に負荷スパイクが発生する可能性が高く、最大許容削減数を超えてグループサイズをスケールインしたくない時間。このパラメータで、オートスケーラーが過去の負荷を処理するのに十分なピークサイズを決定する際の時間枠を定義します。オートスケーラーは、追跡時間枠で観測されたピークサイズから最大許容削減数を差し引いた値よりも小さいサイズには変更されません。追跡時間枠が長いほど、オートスケーラーは過去のピーク負荷を重視します。これにより、より慎重な安定したスケールインが可能になります。</li>
</ul>
</blockquote>
<p><a href="https://cloud.google.com/compute/docs/autoscaler/understanding-autoscaler-decisions?hl=ja">オートスケーラーによる判断の理解 | Compute Engine ドキュメント | Google Cloud</a></p>
<h2>おわりに</h2>
<p>年越しの瞬間はこんな感じで緊張感がありながらもわいわい対応していました。<br>
<img src="https://ik.imagekit.io/plaid/a87d020b-d545-410e-958a-6794e64efeaf/Group1.jpg" alt="Group1.jpg"><br>
普段はなかなかやらないような大幅なスケールアップやリアルタイムでの対応を行い、個人的にもとてもいい経験になりました。</p>
<p>CX（顧客体験）プラットフォーム「KARTE」を運営するPLAIDでは、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


普段からトラフィック量の多いプロダクトであるKARTEにおいて、特にトラフィックが増えることが想定できる年末年始のタイミングにおいて、事前スケールやリアルタイム対応をどのように行ったのかの記録です。

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

<h2>概要</h2>
<p>本記事では <a href="https://www.getdbt.com/">dbt (data build tool)</a> を本番環境のサービスで使った事例を主に Web サービス開発者向けに紹介します。プレイドでは <a href="https://karte.io/package/signals/">KARTE Signals</a> Connector (以下、Signals コネクタ) の SQL を生成するエンジンとして dbt を使っています。dbt を使う前には機能を実現するための SQL が大きく複雑なために機能の追加や変更が困難な状態に陥っていました。dbt を使うことで SQL をシンプルな複数のファイルに分割して、自動テストも導入できるようになりました。機能の変更や保守がしやすくなり、開発速度と品質が向上しました。</p>
<h2>背景</h2>
<h3>dbt を使うに至った背景</h3>
<p>今回の記事の背景として Signals コネクタを紹介します。KARTE Signals にはダッシュボードとコネクタという2つの機能があります。Signals ダッシュボードは広告効果を表示・分析するためのツールですが、今回はスコープ外なので詳しく紹介しません。Signals コネクタは 1st Party Data を使って広告効果を根本的に改善するサービスです。Signals コネクタには主に3つの機能があります。1つ目は失われたコンバージョンの補完です。これまでコンバージョン情報の計測のために使っていた 3rd Party Cookie の利用が Intelligent Tracking Prevention (ITP) により阻害され、広告媒体のコンバージョン情報の欠損が発生します。この欠損したコンバージョンを広告媒体の Conversion API を利用して補完します。2つ目はターゲティングです。KARTE で取得する行動データや自社の CRM データを活用することでより高精度にターゲティングを実現します。3つ目は入札最適化の精度改善です。Value Based Bidding (VBB) という入札最適化によって目的広告費用対効果やコンバージョン値の最大化を目指します。</p>
<h3>広告API用データ作成の問題</h3>
<p>広告配信媒体は、その広告媒体の API ごとに必要なデータの内容やフォーマットが異なります。つまり、広告媒体 API の違いを吸収するように似たような機能の複雑な SQL を複数用意する必要があります。この複雑な SQL の開発と管理を楽にするために dbt を使っています。具体的には「複数の SQL テンプレートファイルと変数から1つの SQL を dbt が合成(compile)」します。Signals コネクタには dbt を使った SQL 合成の機能が組み込んであります。Signals コネクタではクライアントがデータフォーマットの違いを意識することはほとんどありません。管理画面上からいくつかのパラメータ設定をするだけで広告媒体 API に対してデータを送ることが出来ます。</p>
<h2>dbt</h2>
<h3>dbt とは何か？</h3>
<p>dbt はデータレイクもしくはデータウェアハウスと呼ばれるデータプラットフォームに格納されたデータの分析をサポートするツールです。 具体的には、オンラインエディタで SQL を書いてデータプラットフォームで実行したり、Git で SQL ファイルを管理したり、CI/CD でビルドやテスト、デプロイなどができます。</p>
<h3>なぜ dbt を選んだのか？</h3>
<p>dbt も含めて複数の SQL テンプレートファイルから1つの SQL を合成する方法はいくつかあります。たとえば、プログラミング言語と SQL フレームワークを使って SQL を生成したり、単純な SQL テンプレートに書く、ビジュアルエディタや統合開発環境を使うなどの方法があります。Signals チームでは初期に SQL 書くメンバーがプログラマではなかったのでプログラミング言語による SQL 生成は選択しませんでした。また、検証時に作成した SQL 文を活用したいという要望もありました。dbt はこれらの要求を満たしているツールの1つでした。OSS(dbt Core)としてソースコードが提供されているのとSaaSオンラインエディタ(dbt Cloud)を利用できるのが dbt の良いところです。</p>
<h2>開発と運用</h2>
<h3>dbt をどのように使っているか？</h3>
<p>dbt を使う前には KARTE 内のクエリエディタ機能で巨大な BigQuery SQL を書いていました。現在は dbt を使って動的に SQL を生成しています。テンプレートとなる SQL を書くときには dbt Cloud というオンライン開発環境で作業します。エディタ上で SQL のビルドや実行、テストデータを使ったテストもできます。dbt では Git を使ってテンプレートファイルを管理します。Git ブランチ切り替えや GitHub Pull Request 作成も dbt Cloud から操作できます。</p>
<p>dbt を使う前後でどのように SQL 開発環境が変わったのかを説明します。</p>
<table>
<thead>
<tr>
<th></th>
<th>dbt 使用前</th>
<th>dbt 使用後</th>
</tr>
</thead>
<tbody>
<tr>
<td>SQL ファイル数(1機能あたり)</td>
<td>1</td>
<td>5 (平均)</td>
</tr>
<tr>
<td>SQL 行数(1ファイルあたり)</td>
<td>300 - 500</td>
<td>20 - 60</td>
</tr>
<tr>
<td>テストデータ作成</td>
<td>困難</td>
<td>容易</td>
</tr>
<tr>
<td>自動テスト</td>
<td>なし</td>
<td>あり</td>
</tr>
<tr>
<td>SQL クエリ管理</td>
<td>データベース</td>
<td>Git</td>
</tr>
<tr>
<td>クエリエディタ</td>
<td>独自 (機能少)</td>
<td>dbt Cloud (機能多)</td>
</tr>
</tbody>
</table>
<p>SQL ファイルの分割によってコードの見通しが良くなったことで、クエリを改善できて SQL の合計行数も少なくなっています。SQL を実行してエラーが出たときにテストデータに問題があるのかクエリ内容の問題なのか切り分けるのが難しかった問題も、小さな SQL に分割することによって判断しやすくなりました。SQL の自動テストについては後述します。</p>
<h3>dbt 関連サーバ構成</h3>
<p>dbt の SQL 合成は GraphQL API を通じて行うようにしました。dbt Cloud の API (REST API) を使うことも検討したのですが、BigQuery の権限管理の要件を満たすことができずに自前で dbt API を作成して運用しています。</p>
<p>Signals の構成サーバのうち dbt に関係している部分だけを抜き出した構成図<br>
<img src="https://ik.imagekit.io/plaid/24ff250b-49f5-4131-a545-883909e01fe1/dbt_structure.png" alt="dbt_structure.png"></p>
<p>Signals サーバと dbt API サーバが GraphQL で通信します。dbt API サーバ自体はステートレスなのでデータベースを持たず dbt Core を通じて Git Repository (ワーキングディレクトリ)内の SQL ファイルを参照します。</p>
<h3>dbt を使った SQL 合成機能の開発フロー</h3>
<p>Singnals チームにおける SQL 合成機能の開発フローを紹介します。ここでは新しい機能(モデル)を追加する場合のフローを例とします。SQL 開発自体は dbt Cloud のみでほとんど作業が完結します。</p>
<ol>
<li>Git の main ブランチから開発ブランチを作成する</li>
<li>seeds ディレクトリにテストデータ(csvファイル)を入れる(dbt seed で BigQuery にアップロードされる)</li>
<li>models 以下に新しいモデルのディレクトリを作成する</li>
<li>SQL ファイルを書いてビルドする(dbt build で BigQuery を使って SQL を実行する)</li>
<li>SQL が完成したら git commit して Pull Request を作る</li>
<li>CI による自動テストと担当者によるコードレビューを行う</li>
<li>PR をマージ後に GraphQL サーバとクライアントを自動生成して git commit して PR を作成する</li>
<li>CI によるテストとコードレビュー</li>
<li>PR をマージするとクライアントが自動リリースされる</li>
</ol>
<h3>自動ビルドと自動テスト</h3>
<p>CI でビルドを実行して SQL が正しいかどうかを確認します。BigQuery と接続することで合成した SQL が文法として正しいかどうかだけではなく、テストデータ自体のフォーマットや合成した SQL を実行して結果が取得できるかも確認します。テストとして特定の SQL 文を実行して結果の整合性を確認することもできます。</p>
<p>自動でビルドとテストを行えるようになったお陰で CI の時点で SQL の文法ミスや変数設定時の誤植などを減らすことができるようになりました。SQL ファイルを小さいファイルに分割したことによって個々の機能が明確になり、レビューも容易になりました。</p>
<p>自動テストではテストデータや個別の SQL 実行後のスキーマが正しいかどうかを検証します。自動テストによって SQL 修正時に特定の項目を出力してなかったりカラム名を間違っていたりするような単純なミスを見つけやすくなりました。</p>
<h3>GraphQL サーバとクライアントのコード生成スクリプト</h3>
<p>GraphQL サーバ (Python) と GraphQL クライアント (node.js) のコードをそれぞれスクリプトで生成しています。dbt Cloud を使って作成した SQL ファイルが models ディレクトリ以下に置いてあるものとします。コード生成スクリプトを実行すると GraphQL サーバと GraphQL クライアントのコードを生成します。</p>
<p>サーバ側のコード生成のポイントは SQL ファイルを読んで変数名を抽出しているところです。変数を GraphQL の引数として渡せるようにしています。変数を自動抽出することで変数名の間違いや抜け漏れを減らすことができます。</p>
<p>クライアント側のコード生成には <a href="https://the-guild.dev/graphql/codegen">GraphQL Code Generator</a> を使っています。GraphQL Code Generator は GraphQL スキーマと GraphQL ドキュメントから TypeScript などの言語による GraphQL クライアントを生成します。GraphQL スキーマはサーバ側のコードから自動生成します。スクリプトで自動生成した GraphQL ドキュメントと組み合わせると GraphQL クライアントを生成できます。</p>
<p><img src="https://ik.imagekit.io/plaid/5543098d-8f04-4876-91c5-b0a7edb88d4d/dbt_flow.png" alt="dbt_flow.png"></p>
<h2>現状の課題と展望</h2>
<h3>dbt の問題点</h3>
<p>dbt も万能ではなく、いくつか扱いづらいことがありました。使ってみて気づいた課題を共有します。</p>
<ul>
<li>dbt compile が遅い<br>
SQL の生成に使っている dbt compile に数秒程度かかります。複数ファイルをマージして変数展開している部分よりも BigQuery に接続しているところで時間がかかっているようです。頻繁に dbt compile を実行しないようにアプリケーションの実装を工夫することで問題を回避しています。</li>
<li>ファイル名や参照名のユニークネス<br>
dbt ではモデルという概念で生成される SQL を表し、複数のモデルを1つの dbt プロジェクトで扱えます。しかし、ファイル名や参照(ref)名をプロジェクト内でユニークにしなければならないという制限があります。複数のモデルでそれぞれ異なるファイル名をつける必要があります。似たような機能を提供してほぼ同じ内容の SQL ファイルに固有の名前を要求されるので、モデルが増えるたびにファイル名の重複を気にする必要があります。必要に応じて命名規則を定めた方が良いかもしれません。</li>
</ul>
<h3>今後の展望</h3>
<ul>
<li>SQL 合成機能以外も活用する<br>
dbt の本来の使い方である継続的なデータ分析のサポートの機能も使ってみたいと思います。たとえば <a href="https://docs.getdbt.com/reference/resource-properties/freshness">source freshness</a> を設定すると入力データが正しく更新されているか監視することができます。この機能を使えばサービス品質を向上するのに使えるはずです。</li>
<li>他の機能にも dbt を展開する<br>
KARTE やその他のプロダクトでも dbt を使える場所に展開することを検討しています。普及活動の一環として社内の勉強会で dbt の使い方や活用事例を何度か紹介しました。</li>
</ul>
<h2>まとめ</h2>
<p>KARTE Signals コネクタでは dbt Cloud で開発した SQL を独自の dbt GraphQL API を通じて本番環境で利用しています。dbt を導入することで SQL の開発や保守がやりやすくなりました。最大500行以上あった複雑な SQL を数十行のファイル群に分割することで見通しが良くなり、レビューや動作確認、テストデータの作成が容易になりました。また自動ビルドや自動テストを導入することで SQL の記述の問題に早く気付けるので、開発とデバッグの速度も向上しました。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


KARTE Signals コネクタの SQL 生成機能として dbt を活用して SQL 開発の課題を解決して開発効率を上げた具体的な手法を紹介します

KARTE Signals の複雑 SQL を支える dbt の活用

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。</p>
<p>今回は、2023年4月からBigQueryが<strong>Editions</strong>という料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。</p>
<p>BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。</p>
<p>しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり</p>
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
<p>による影響が発生しました。</p>
<p>storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、<strong>Long-Term Physical Storage</strong> という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。</p>
<p>一方で、slotの単価が <strong>$0.024/slothour</strong> から <strong>$0.048/slothour</strong> へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、<strong>Bigquery-Slot-Optimization Team</strong>です！</p>
<p>本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。</p>
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
<p>Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。<br>
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png"></p>
<p>MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。</p>
<p>まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。</p>
<p>時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。<br>
単純には</p>
<pre><code class="language-sql">  SELECT
    job_id,
    period_start,
    period_slot_ms
  FROM
    `{YOUR_PROJECT_NAME}.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
</code></pre>
<p>のようにすれば、簡単に取得できます。</p>
<p><strong>period_slot_ms</strong>とはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。</p>
<p>このテーブルをさらに、<code>INFORMATION_SCHEMA.JOBS</code> というテーブルを用いて、job_idをkeyにjoinすることで、実行されたqueryを取得できます。取得したqueryをさらに、<code>REGEXP_CONTAINS</code> 関数を用いて、正規表現で任意のJobに集約します。例えば、<code>WHEN REGEXP_CONTAINS(query, r'/* JOURNEY') THEN 'journey'</code> という表記により、queryのコメントに<code>/* JOURNEY</code> が含まれているqueryを <a href="https://karte.io/product/journey/">Journey</a> というProductのために使っているQuery Jobという形で集約できます。</p>
<p>集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。</p>
<p>Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。<br>
TypeScriptで書くとこのようになります。（※一部抜粋）</p>
<pre><code class="language-typescript">  const slots: v2.MetricSeries = {
    metric: '${metric_name}',
    type: 2,
    interval: 1,
    points: points,
    tags: [`project:${projectId}`, `task:${task}`],
  };

  const params: v2.MetricsApiSubmitMetricsRequest = {
    body: {
      series: [slots],
    },
  };

  apiInstance
    .submitMetrics(params)
    .then((data: v2.IntakePayloadAccepted) =&gt; {
      console.log('API called successfully. Returned data: ' + JSON.stringify(data));
    })
    .catch((error: any) =&gt; console.error(error));
</code></pre>
<p>この関数をDeployするには</p>
<pre><code class="language-bash">gcloud functions deploy $FUNCTION_NAME \
  --project=$GCP_PROJECT \
  --region=$REGION \
  --runtime nodejs14 \
  --entry-point=index \
  --gen2 \
  --source ./build \
  --trigger-topic=$TOPIC_NAME \
  --trigger-service-account=$TRIGGER_SERVICE_ACCOUNT_ADRESS \
  --service-account=$SERVICE_ACCOUNT_ADRESS \
  --retry \
  --timeout=180s \
  --set-env-vars=DATADOG_APP_KEY=$DATADOG_APP_KEY,DATADOG_API_KEY=$DATADOG_API_KEY
</code></pre>
<p>というgcloudコマンドだけでdeployできます。</p>
<p>さらに、このFunction を Cloud Scheduler で定期的に実行します。<br>
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。</p>
<p>結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。<br>
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png"></p>
<p>これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。<br>
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。</p>
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
<p>BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。</p>
<p>弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。<br>
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。<br>
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。<br>
これを最適化するために導入されたのが、AutoScaleです。</p>
<p>そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。</p>
<p>そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。</p>
<p>これらを考慮した上で、弊社で最適化した結果が以下の通りです。<br>
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png"></p>
<p>いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。<br>
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。<br>
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。<br>
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png"></p>
<p>ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。<br>
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。</p>
<p>最も大事なのは、<strong>Productごとに要件を把握し適切にReservationを配分する</strong>ことであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。</p>
<h2>最終的なコストは...?</h2>
<p><strong>全体で約20%のコスト削減を実現</strong> することができました。<br>
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。</p>
<p>以上のように<br>
① Monitoringの整備によるJobごとのSlot監視と削減<br>
② AutoScaleの導入によるSlotBaseLineの最適化全体</p>
<p>でBigQuery全体として、約20%のコスト削減を実現しました。</p>
<p>BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


BigQuery Editionsにおけるコスト最適化

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内で脆弱性診断を行なっている理由や、どのように診断から修正までを行なっているか、また社内で脆弱性診断をやることでどのような変化が起きたかについて紹介します。

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

今回のブログではプラットフォームチームにて取り組んだ、異なるデータベース間のリアルタイムレプリケーションについて解説いたします。

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

Engineer Blog

Recent Article

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

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

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

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

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

KARTE Signals の複雑 SQL を支える dbt の活用

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

Archives

Writers

Recent Article

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

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

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

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

社内勉強会「Modern Data Stack入門」の内容をブログ化しました

年越しのその瞬間、KARTEのリクエスト急増とスケールアップの裏側

KARTE Signals の複雑 SQL を支える dbt の活用

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

Archives

Writers

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