Engineer Blog

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<p>この記事は、社内の生成AI LT会（<a href="https://tech.plaid.co.jp/plaid-generative-ai-lt-report">LT会に関するブログ</a>）で「誰でもできるvibe-coding」と題した発表内容を基に、AIに執筆させています。</p>
<h2>はじめに</h2>
<p>こんにちは、プレイドのKARTE Messageチームでエンジニアをしている大内です。</p>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信の運用について紹介した記事</a>や、<a href="https://tech.plaid.co.jp/complex_logic_to_dynamically_generate_sql">機能改善により開発スピードが向上したことを紹介した記事</a>がありますので、そちらも併せてご覧ください。</p>
<p>私たちMessageチームでは、開発の生産性をさらに高めるために、エンジニア以外のメンバーもAIを活用して開発を行う取り組みを進めています。この試みは多くの可能性を秘めている一方で、「レビュワーの負担が増えすぎる」という課題も明らかになりました。</p>
<p>この記事では、その課題にどのように取り組み、改善を進めているかご紹介します。</p>
<h2><strong>AI開発の幕開けと、見えてきた課題</strong></h2>
<p>チームのプロダクトマネージャー（以下、PMとします）が生成AIを使い、次々と実装を始めたのがことの始まりでした。AIによってコードが効率的に生み出され、ローカル環境で動作確認ができれば、機能が形になるという事実は、開発のスピード感に大きなインパクトを与えました。</p>
<p>その結果、PMは多くのPRを作成。この1ヶ月だけでも、<strong>レポート機能の改善、AI連携機能の強化、リスト表示のUI刷新、多岐にわたる機能改善</strong>に関するPRがマージされました。</p>
<p>一方で、この新しい開発スタイルは、いくつかの運用上の課題も浮き彫りにしました。</p>
<ul>
<li><strong>エンジニアのレビュー負荷増大</strong>：エンジニアから見ると、「開発の意図や目的が必ずしも明確でない大量のコード」をレビューする必要が生じた。</li>
<li><strong>AI生成コードの品質</strong>：AIは既存のコードベースを完全に理解しているわけではないため、「動作はするものの、品質面では改善の余地がある」コードを生成してしまうことがあった。例えば、既存コードの再利用が不十分であったり、実装方針の変更時に古いコードが残ってしまったりするケースがある。</li>
</ul>
<p>レビュワーからは、特に以下の点が負担増の原因として挙げられました。</p>
<ul>
<li>PRにおける差分量の増加があった。</li>
<li>「まず実装してみる」という進め方だったため、設計やセキュリティリスクに関する検討がコードレビュー段階に集中し、レビューの負担が増した。</li>
<li>AIが生成したコードの意図を読み解くのに時間がかかることがあった。</li>
</ul>
<h2><strong>課題解決への道のり：プロセスの見直しと改善</strong></h2>
<p>これらの課題に対応するため、私たちは以下の改善策に取り組んでいます。</p>
<ol>
<li><strong>「仕様ドキュメント」の事前作成とレビュー</strong>：開発着手前に「仕様ドキュメント」を作成し、エンジニアがレビューするフローを導入。これにより、設計段階で問題点を洗い出し、セキュリティ懸念を事前に検討できるため、コードレビュー時には実装そのものに集中できるようになった。</li>
<li><strong>AIによる実装意図のコメント記載</strong>：AIが生成したコードには、可能な限り実装意図をコメントとして記述。これにより、レビュワーがコードの意図を理解しやすくなることが狙い。</li>
<li><strong>PRの適切な分割</strong>：AIによる大量のコード生成に対応するため、PRを機能単位や意味のある変更単位で細かく分割するルールを設けた。仕様ドキュメントで事前に粒度を決めておくことで、レビューの負荷軽減を図っている。</li>
</ol>
<h2><strong>レビュワーから見たAI開発：評価と今後の期待</strong></h2>
<p>AIが生成したコードをレビューする中で、その可能性と課題の両方が見えてきました。</p>
<p><strong>評価できる点</strong></p>
<ul>
<li>既存の複雑な実装がある中でも、動作するコードを生成できる点は注目に値する。特にテストコードの生成精度は高く、品質向上に貢献する可能性がある。</li>
<li>既存の制約がない新規開発の場合、AIが生成するコードは比較的標準的で読みやすい傾向にある。</li>
<li>コードを記述する速度は非常に速く、人間によるレビューがボトルネックになる場合もあるほどである。</li>
</ul>
<p><strong>今後の改善に期待する点</strong></p>
<ul>
<li>既存実装が複雑な場合や、多くの背景情報を理解する必要がある場合、生成されるコードの質がまだ高くないことがある。これは事前の設計ドキュメント作成である程度カバーできると考える。</li>
<li>PRの粒度調整や補足コメントの追加など、実装以外の部分では、まだ人間によるコントロールが必要である。</li>
<li>既存のコードアーキテクチャが一般的でない場合、AIの知識外となり精度が低下する可能性がある。AIを有効活用するには、既存コードも一般的なアーキテクチャに準拠している方が望ましいかもしれない。</li>
</ul>
<p>総じて、AIに開発を完全に任せるのはまだ難しい点が多いものの、工夫次第で品質を向上させることは十分に可能だと感じています。チームとしてこの新しい取り組みに前向きに関わり、改善を続けていくことが重要だと考えています。</p>
<h2><strong>現在の取り組みと、そこから得られた学び</strong></h2>
<p>現在、私たちは以下の対策を中心に進めています。</p>
<p>それは、<strong>「仕様ドキュメント」を事前に作成し、エンジニアのレビューを経たうえで開発に進むフローを確立すること</strong>です。</p>
<p><strong>具体的なフローのイメージ</strong></p>
<ol>
<li>PMが仕様ドキュメントに「背景」「期待する機能」「懸念点」を記述し、「実装方針」についてはAIの支援も受けつつ草案を作成。
<ul>
<li>この時点で、PM自身も実装の概要を把握。</li>
</ul>
</li>
<li>エンジニアが「仕様ドキュメント」をレビュー。
<ul>
<li>これにより、コードレビュー時に仕様の全体像が共有され、手戻りを削減。既存コードの活用など、エンジニアの知見を早期に反映する。</li>
</ul>
</li>
<li>レビュー結果を元に「仕様ドキュメント」を修正し、関係者間で合意。</li>
<li>修正された「仕様ドキュメント」を設計書としてAIに入力し実装。
<ul>
<li>より正確な仕様に基づいてAIがコードを書くことで、誤りを減らす。</li>
</ul>
</li>
</ol>
<p><strong>AI運用の工夫</strong></p>
<ul>
<li>作成した仕様ドキュメントをCursorやCopilotに一時的にルールとして登録し、開発中の参照を容易にしている。</li>
<li>PR作成前に必須のチェックリストを作成し、レビューの負担軽減に努めている。</li>
</ul>
<p>これらの取り組みにより、エンジニアからは「レビューの負担が軽減された」という声も聞かれるようになってきました。（もちろん、まだ改善の余地はあります。）</p>
<p><strong>得られた学び</strong></p>
<p>この経験から、ビジネスサイドとエンジニアが共同で仕様を定義し、開発を進めていくプロセスが、AIの登場によって大きく変わる可能性を感じています。</p>
<p>現在のAIの進化を見ると、いずれ「仕様書＝実装」という未来も現実のものとなるかもしれません。私たちMessageチームは、今後もこの新しい開発スタイルに積極的に取り組み、知見を深めていきたいと考えています。</p>


生成AIで書いたコードをどうレビューしていくか。AIと共存しながら開発しているMessageチームの取り組みを紹介します。

「生成AIで書いたコード、どうレビューする？」Vibe codingと共存する開発プロセス

<p>プレイドが提供するKARTEでは、エンドユーザの行動データを活用するためにさまざまな分析機能を提供しています。データベースの裏側を支えるデータ構造も多種多様で、それらを正しく理解し活用していくことは分析サービスを提供する上で非常に重要です。</p>
<p>この記事ではBitmap Indexにフォーカスし、ナイーブなBitmap IndexとRoaring BitmapやBit-Sliced Indexについて解説します。</p>
<p>弊社の記事で手前味噌ですが、分析向けデータベースの技術全般については以下の記事も非常に参考になるのでオススメです。<br>
<a href="https://tech.plaid.co.jp/fundamentals_of_olap_db_technology">OLAP DBの技術要素の基礎</a></p>
<h2>ナイーブなBitmap Index</h2>
<p>最も基本的なBitmap Indexは、カラム内の特定の値ごとに一つのビットマップを持つ構造です。このビットマップでは、各ビットがテーブル内の一つの行（行番号）に対応します。その値を持つ行であればビットを1、持たなければ0とします。</p>
<p>例えば商品テーブルに「商品カテゴリ」というカラムがあり、以下のデータが入っているとします。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>商品カテゴリ</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>トップス</td>
</tr>
<tr>
<td>1</td>
<td>トップス</td>
</tr>
<tr>
<td>2</td>
<td>トップス</td>
</tr>
<tr>
<td>3</td>
<td>ボトムス</td>
</tr>
<tr>
<td>4</td>
<td>ボトムス</td>
</tr>
</tbody>
</table>
<p>この商品カテゴリカラムに対してBitmap Indexを作成すると、以下のようになります。</p>
<ul>
<li>トップス: <code>11100</code> (0, 1, 2番目の行がトップス)</li>
<li>ボトムス: <code>00011</code> (3, 4番目の行がボトムス)</li>
</ul>
<p>最大の利点はANDやORをBit演算で高速に計算できることです。<br>
例えば、「トップスまたはボトムスの商品を抽出する」場合、<code>11100</code> OR <code>00011</code> = <code>11111</code><br>
となり、全ての行が該当することが分かります。</p>
<p>また、該当するエントリ数の算出はpopcntでできてしまいます。</p>
<p>主な弱点は以下です。</p>
<ul>
<li>サイズが大きくなりやすい
<ul>
<li>カーディナリティ(カラム内のユニークな値の数)の分ビットマップを持たなければならず、特にカーディナリティが高い時に大きくなります。</li>
<li>値がスパースな時に非効率です。例えば100万行の商品テーブルで「虹色」の商品が1つだけある場合、「虹色」のビットマップは「00...010...00」のようにほとんどが0で占められます。これなら、単に対応する行番号のリスト（例：<code>[2500]</code>）で持つ方がはるかにコンパクトです。</li>
<li>(基本的にはカーディナリティが高いカラムはスパースな値が多いです。多値型の場合はその限りではありませんが)</li>
</ul>
</li>
<li>範囲検索が非効率
<ul>
<li>例えば商品価格のような値に対してBitmap Indexをそのまま使って「1000円以上の商品」を検索する場合、1000円、1001円、1002円… といった個別の価格に対応する全てのビットマップを取得し、ORを取らなければなりません。</li>
</ul>
</li>
</ul>
<h2>Roaring Bitmap</h2>
<p>Bitmapの良さを活かしつつ弱点を克服するためのフォーマットがいくつかあります。有名なものがWAH (Word Aligned Hybrid), Concise Bitmap, そしてRoaring Bitmapです。<br>
雑にまとめるとどの手法も、決まった方針でBitmapを分割して、1と0が満遍なく混在するパーツは純粋なBitmapとして扱いつつ、スパースなパーツは行IDのリストやRun-Length Encodingで保持する、という仕組みです。</p>
<p>OLAP分野だとRoaring Bitmapが特に人気なようで、IndexにはRoaring Bitmapが優先されることが多いと思います。以下はRoaring Bitmapについて説明します。</p>
<h3><strong>Roaring Bitmapの仕組み</strong></h3>
<p>Roaring Bitmapでは、Bitmapを最大65,536(2^16)個の要素で構成されるコンテナに分けます。コンテナはBitmap / Arrayのどちらかで表現します。</p>
<ul>
<li>Bitmap: スパースではない場合、65,536ビット（8KB）のビットマップとして格納します。</li>
<li>Array: スパースな場合(デフォルトでは1が4096個以下)、要素の値を整数のソート済み配列としてそのまま格納します。</li>
</ul>
<p>(進化版ではRun-Length Encodingという3種類目のコンテナもありますが、今回は割愛します。)</p>
<p>AND/ORなどの論理演算はコンテナ単位で行われ、コンテナの組み合わせごとにアルゴリズムがあります。例えばAND演算は以下です。</p>
<ul>
<li>Bitmap vs Bitmap: 通常のビットワイズAND演算。</li>
<li>Bitmap vs Array: Array内の各要素について、Bitmapの対応するビットを確認。</li>
<li>Array vs Array: ソート済み配列同士のマージ処理に似た方法で共通要素を探索。</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/ddb8044b-db50-493c-9d73-918bafb04060/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-05-2322.50.10.png" alt="Roaring Bitmap"><br>
(int32を扱うとして、実際にはcontainerの要素には下位16bitを入れ、上位16bitはコンテナ毎に持ちます。足し合わせることで元のint32に復元できます。)</p>
<p>Arrayコンテナが関わる演算はBitmapコンテナ同士の演算と比べると非効率ですが、そもそも要素数が少ないため大して問題にならない、というのが良くできているところだと思います。また、WAHやConcise Bitmapではワード単位でBitmapかRun-lengthかを区別しますが、Roaring Bitmapでは大きい固定サイズで分けたことで、オーバヘッドが少なくなったことがポイントだと思います。</p>
<p>余談ですが、OSSのOLAP DBであるApache Druidでは、デフォルトで文字列型の全カラムに対してRoaring Bitmap Indexが作られます。大胆ですね。実際KARTEで扱うような行動データをDruidにロードして試したことがありますが、Bitmap Indexのサイズはカラムナ部分と同程度に収まり、フィルタリングもかなり早くなりました。</p>
<p>また、数値型に対して作らない理由は以下だと思います。</p>
<ul>
<li>カーディナリティが高いことが多い(年齢や会員ランクなど、反例も多そうですが)</li>
<li>固定長で値が小さいためカラムナフォーマットだけでも十分早い(SIMD / CPUキャッシュ / CPUレベルでの並列化が効きやすい)</li>
</ul>
<h2>Bit-Sliced Index</h2>
<p>Bitmap Indexの弱点に対応するフォーマットとして、Bit-Sliced Indexもあります。ざっくり言えば数値型に向いてるIndexです。(Roaring BitmapはBitmap単体のフォーマットですが、Bit-Sliced Indexはindex全体のフォーマットです。組み合わせることもできます。)</p>
<p>Bit-Sliced Indexは、カラムの値を特定の基数で分解（スライス）し、各ビット位置ごとにビットマップを作成します。</p>
<p>以下は商品価格を基数2で表現(=2進数)する例です。B[i]は2進数表現の、i bit目を意味します。</p>
<table>
<thead>
<tr>
<th>行番号</th>
<th>価格</th>
<th>B[7]</th>
<th>B[6]</th>
<th>B[5]</th>
<th>B[4]</th>
<th>B[3]</th>
<th>B[2]</th>
<th>B[1]</th>
<th>B[0]</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>1</td>
<td>230</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>2</td>
<td>130</td>
<td>1</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
</tr>
<tr>
<td>3</td>
<td>5</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
<td>0</td>
<td>1</td>
</tr>
</tbody>
</table>
<p>Bit-Sliced Indexでは、物理的には縦方向のBitmapを持ちます。この例では行数が4で桁数が8(bit)なので、長さ4のBitmapが8個作られます。</p>
<p>ナイーブなBitmap Indexでは行番号を指し示すBitmapが値ごとに作られますが、今回は値自体もBitmapでエンコーディングするのでこんがらがりがちです。上記の表を行列と捉えて、横方向のBitmapは値自体の表現であり、縦方向のBitmapは値の特定の桁が一致する行番号を指し示すBitmapと言えます。</p>
<p>価格が最大で255円だとすると、基数2のBlit-Sliced Indexで必要なビットマップは8個です。ナイーブなBitmap Indexなら最大256個のビットマップが必要になることと比べると、大幅にサイズを抑えられることが分かります。</p>
<h3>Bit-Sliced Indexによる合計計算（基数2の場合）</h3>
<p>応用のアルゴリズムとして、Bit-Sliced Indexでカラムに含まれる値の合計値が計算できます。元々の目的である索引以外にも使えるのが面白いです。</p>
<pre><code class="language-cpp">/**
 * B: 特定カラムCのBit-Sliced Index (B[i]はi番目のビットに対応するビットマップ)
 * Bf: 条件を満たす行を示すビットマップ (Foundset)
 * num_bits: 値を表現するのに必要なビット数(横方向のBitmapのビット数)
**/
int sum = 0;
for (int i = 0; i &lt; num_bits; ++i) {
    // i番目のビットが立っている行だけを対象に、2^i を加算
    sum += 2^i * POPCOUNT(B[i] AND Bf);
}
return sum;

</code></pre>
<h3>基数</h3>
<p>ここまで基数2を例にしてきましたが、他の基数を取ることもできます。例えば基数10とすると、1000未満の整数であれば100,10,1の位の3つの10bitのスライスで表現し、位の値がNならスライスの右からN番目に1を立てます。</p>
<p>例えば230は100の位が2、10の位が3、1の位が0なので、以下のようになります。<br>
<code>0000000100</code>(100の位) <code>0000001000</code>(10の位) <code>0000000001</code>(1の位)</p>
<p>基数は単一である必要はなく、位ごとに変えることもできます。</p>
<p>基数の増減に伴うトレードオフはサイズとクエリ効率にあるようです。基数を増やすサイズは増えますが、例えば等価検索の効率が良くなることは明らかです。</p>
<h3>Encodingと検索</h3>
<p>値のBitmap(横方向)のEncodingのバリエーションとして、Equality EncodingとRange Encodingがあります。</p>
<p>Equality Encodingは値がNならN番目のbitに1を立てるもので、ここまでで説明してきた方法です。<br>
Range Encodingでは、値がNならN番目のbitとその左のbit全てに1を立てます。</p>
<p>例えば基数10で230を表現すると、100の桁が2、10の桁が3、1の桁が0ですから、以下のようになります。<br>
<code>0000000100 0000001000 0000000001</code>(Equality Encoding)<br>
<code>1111111100 1111111000 1111111111</code>(Range Encoding)</p>
<p>Range Encodingはその名の通り範囲検索に強いエンコーディングです。</p>
<p>それぞれのエンコーディングで等価検索と範囲検索のアルゴリズムがあります。複雑なので、範囲検索の大雑把な方針のみ説明します。</p>
<p><strong>Equality Encodingの範囲検索</strong><br>
例えば特定の値より大きいデータを取る場合、位だけを見て対象の値より大きいと分かる行を取るステップと、同じ位の中で対象の値より大きい行を取るステップがあります。</p>
<p>例えば基数2で <code>価格 &gt;= 5 (バイナリ: 00000101)</code> を検索する場合、以下の2つの結果の和集合が結果です。</p>
<ul>
<li>8以上255以下の行
<ul>
<li>B[7]からB[3]までのうちどれか一つでも1が立っている(ORで取得)</li>
</ul>
</li>
<li>5以上7以下の行
<ul>
<li>B[2]が立っていて、B[1]かB[0]のうちどちらか一つでも1が立ってる(ANDとORで取得)</li>
</ul>
</li>
</ul>
<p><strong>Range Encodingの範囲検索</strong><br>
特定の値より大きいデータを取る場合、その値のbitだけをチェックします。例えば基数10で値が200以上のデータを取る場合、100の位のスライスの右から1番目のbitが0である行を取得します。</p>
<h2>まとめ・感想</h2>
<p>Bitmap Indexと言えばデカいイメージがありますが、対策としていろいろなアイデアが提案されています。こんなにアイデアを凝らすほどAND/ORが効率的に処理できるBitmapが魅力的ということですね。</p>
<p>Roaring Bitmapに比べるとBit-Sliced Indexはそこまで流行っていないような気もします。カラムナDBであれば数値型はカラムナだけで十分早いからでしょうか。行指向のDBでは有用な気もしますが、更新が重いからかもしれません。</p>
<p>また、Bit-Sliced Indexの基数とエンコーディングについては、クエリやデータパターンに応じて選ぶのが重要な気がします。それぞれの特性・トレードオフを整理するところまでは今回は辿り着けませんでしたが、興味があれば各種論文を見てみると良いかもしれません。</p>
<h2>参考資料</h2>
<p><a href="https://dl.acm.org/doi/10.1145/253262.253268">Improved query performance with variant indexes | ACM SIGMOD Record</a><br>
<a href="https://dl.acm.org/doi/10.1145/276305.276336">Bitmap index design and evaluation | ACM SIGMOD Record</a><br>
<a href="https://arxiv.org/abs/1004.0403">[1004.0403] CONCISE: Compressed 'n' Composable Integer Set</a><br>
<a href="https://roaringbitmap.org/">Roaring Bitmaps</a></p>


いろいろなBitmap Indexの紹介

<h2>はじめに</h2>
<hr>
<p>こんにちは。プレイドのKARTE Datahubチームでエンジニアをしている安海です。</p>
<p>この記事は「<a href="https://tech.plaid.co.jp/multi-product-audit-log-collection">マルチプロダクトにおける全操作を網羅する監査ログ収集基盤：設計思想と実装　- 収集編</a>」の続編です。<br>
前回は監査ログの収集基盤について解説しましたが、今回は収集した監査ログをどのように抽出し、ユーザーに提供しているのか、そのアーキテクチャと技術的な工夫について詳しく解説します。<br>
監査ログの抽出基盤を設計・運用する際に直面した課題と、それに対する解決策を共有することで、同様の課題に取り組むエンジニアの一助となれば幸いです。</p>
<h2>抽出基盤のアーキテクチャ</h2>
<hr>
<p>監査ログの抽出基盤は、「他プロジェクトのデータが混在しない安全性」と「開発者の実装のしやすさ」を両立することを目指して設計されています。具体的には、以下のようなアーキテクチャを採用しています。</p>
<p><img src="https://ik.imagekit.io/plaid/ffa4aa6f-b680-42f2-ace3-661e65c9dfa1/auditlog_table_function_architecture.png" alt="auditlog_table_function_architecture.png"></p>
<h3>なぜテーブル関数を採用したのか</h3>
<p>まず、監査ログの抽出基盤でなぜ <a href="https://cloud.google.com/bigquery/docs/table-functions?hl=ja">BigQueryのテーブル関数</a> を採用したのかについて説明したいと思います。テーブル関数は、SQLクエリをカプセル化し、関数として再利用できるBigQueryの機能です。通常のテーブルと同様にクエリ内で参照でき、さらに引数を受け取れる点が大きな特徴です。<a href="https://cloud.google.com/bigquery/docs/views-intro?hl=ja">ビュー</a>と異なり、実行時にパラメータを渡せるため、同一のロジックを様々な条件で使い回すことができます。</p>
<p>例えば、以下のようにシンプルなテーブル関数を定義できます。</p>
<pre><code class="language-sql">CREATE OR REPLACE TABLE FUNCTION project_dataset.get_project_logs(project_id STRING, start_date DATE, end_date DATE)
AS (
  SELECT *
  FROM `logs.audit_logs`
  WHERE project_id = project_id
    AND DATE(timestamp) BETWEEN start_date AND end_date
);

</code></pre>
<p>このテーブル関数は、クエリから次のように参照できます。</p>
<pre><code class="language-sql">SELECT *
FROM project_dataset.get_project_logs('project-123', DATE('2023-01-01'), DATE('2023-01-31'))
WHERE severity = 'ERROR'
ORDER BY timestamp DESC
LIMIT 100;

</code></pre>
<p>テーブル関数を採用した主な理由は、クエリ実行時にパラメータを受け取れる柔軟性にあります。特に監査ログでは、ユーザーが任意の期間のログを抽出できることが重要な要件でした。テーブル関数を使用することで、日付範囲などのパラメータを実行時に指定でき、ユーザーは必要なデータだけを効率的に取得できます。</p>
<p>さらに、生ログは日時でパーティショニングされているため、日付範囲を指定することでパーティションプルーニングが働きます。この仕組みにより、不要なデータスキャンを最小限に抑え、クエリのパフォーマンスを向上させることが可能です。</p>
<p>また、SQLのロジックをテーブル関数内にカプセル化できるため、クエリの再利用性が高まることもメリットです。これにより、複雑なロジックを一箇所に集約し、メンテナンス性を向上させることができます。</p>
<h3>テーブル関数の役割と設計</h3>
<p>抽出基盤の中核となるのは3種類のテーブル関数です。これらの役割と設計思想について解説します。</p>
<h4>1. プロジェクトログ抽出テーブル関数</h4>
<p>この基盤層のテーブル関数は、引数で指定されたプロジェクトIDに対応するログだけを抽出する役割を担っています。他プロジェクトのログが露出するリスクを最小化するため、この関数は変更頻度が低くなるような設計としています。</p>
<p>単一の責務に特化することで、SQLの複雑性を抑制し、堅牢性を高めています。この層がセキュリティの要となるため、変更する際にはGithubで指定された <code>CODE_OWNER</code> のコードレビュープロセスを経る必要があります。</p>
<h4>2. プロダクト別変換テーブル関数</h4>
<p>プレイドでは複数のプロダクトを展開しており、各プロダクトでクライアント向け監査ログへの変換方法が異なります。そこで、プロダクトごとに専用の変換テーブル関数を用意し、それぞれのデータ構造に合わせた変換ロジックを定義できるようにしています。</p>
<p>実際のデータ変換の例はこのような感じです。例えば、以下のような生ログのJSON構造があるとします：</p>
<pre><code class="language-json">{
  &quot;jsonPayload&quot;: {
    &quot;user&quot;: {
      &quot;id&quot;: &quot;user_12345&quot;,
      &quot;name&quot;: &quot;山田太郎&quot;,
      &quot;email&quot;: &quot;yamada@example.com&quot;
    },
    &quot;http_request_meta&quot;: {
      &quot;ip&quot;: &quot;192.168.1.1&quot;,
      &quot;user_agent&quot;: &quot;Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...&quot;
    },
    &quot;resource&quot;: {
      &quot;type&quot;: &quot;dataset&quot;,
      &quot;id&quot;: &quot;dataset_789&quot;,
      &quot;action_type&quot;: &quot;update&quot;
    },
    &quot;detail&quot;: [
      {
        &quot;detailType&quot;: &quot;diff&quot;,
        &quot;new&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット2023&quot;},
        &quot;old&quot;: {&quot;dataset_name&quot;: &quot;分析用データセット&quot;}
      },
      {
        &quot;detailType&quot;: &quot;fields&quot;,
        &quot;value&quot;: {&quot;created_at&quot;: &quot;2023-05-01T09:00:00Z&quot;}
      }
    ],
    &quot;timestamp&quot;: &quot;2023-05-01T10:15:30Z&quot;
  }
}

</code></pre>
<p>このような生ログから、ユーザーに見せる監査ログとして以下のような形式に変換したいとします：</p>
<table>
<thead>
<tr>
<th>user_id</th>
<th>ip_address</th>
<th>action</th>
<th>resource_type</th>
<th>resource_id</th>
<th>timestamp</th>
<th>before_edit</th>
<th>after_edit</th>
</tr>
</thead>
<tbody>
<tr>
<td>user_12345</td>
<td>192.168.1.1</td>
<td>update</td>
<td>dataset</td>
<td>dataset_789</td>
<td>2023-05-01T10:15:30Z</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット&quot; }</td>
<td>{ &quot;dataset_name&quot;: &quot;分析用データセット2023&quot; }</td>
</tr>
</tbody>
</table>
<p>このような変換を行うために、各プロダクトチームはどのフィールドをどのように抽出・変換するかをマッピング定義として記述します。これにより、生ログの複雑なネスト構造から必要な情報だけを取り出し、ユーザーにとって理解しやすい形式に整形できます。</p>
<p>この層では宣言的なアプローチを採用しており、各プロダクトチームは変換マッピングを定義するだけで、自動的にSQL文(テーブル関数)が生成される仕組みを整えています。これにより、SQLを意識しなくても監査ログの変換ロジックを実装できます。</p>
<p><strong>マッピングの仕様：</strong></p>
<ul>
<li><strong>基本構造</strong>
<ul>
<li><code>map</code> 内の key は整形後の監査ログのカラム名を指定します</li>
<li><code>columnName</code> には生ログのデータパスを指定します</li>
<li><code>type</code> にはデータ型（STRING, JSON など）を指定します</li>
</ul>
</li>
<li><strong>detail フィールドの処理</strong>
<ul>
<li><code>detail</code> フィールドには比較的自由な形式のデータが格納されるため、特殊なマッピングを指定できます：
<ul>
<li><code>detailType</code> - 処理対象のデータタイプ（<code>diff</code>/<code>fields</code>/<code>error</code> など）</li>
<li><code>detailFieldsKey</code> - オブジェクト内の抽出したいキー名</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>実際に <code>detail</code> に格納されるデータの例<br>
※ 同一 detailType のオブジェクトが複数入らないようにしています</p>
<pre><code class="language-jsx">[
  {detailType: &quot;diff&quot;, new: {dataset_name: &quot;hoge&quot;} old: { dataset_name: &quot;fuga&quot; }},
  {detailType: &quot;fields&quot;, value: { hoge: 1, fuga: &quot;piyo&quot; }},
  {detailType: &quot;error&quot;, message: &quot;this is error&quot; }
]

</code></pre>
<p>以下は変換マッピングの例です。このマッピングでは、ユーザーID、IPアドレス、編集前の値などを抽出する方法を定義しています。</p>
<p>また、より柔軟なデータ抽出が必要な場合には、<code>custom</code>セクションを利用してカスタムの<code>SELECT</code>文を記述できます。これにより、既存のパターンでは対応できない特殊な要件にも対応可能です。例えば、特定の条件に基づいてデータを加工したり、集約した結果を取得することができます。</p>
<pre><code class="language-jsx">{
  map: {
    user_id: { columnName: 'user.id', type: 'STRING' },
    ip_address: { columnName: 'http_request_meta.ip', type: 'STRING' },
    before_edit: {
      columnName: detail,
      type: 'JSON',
      detailType: 'diff',
      detailFieldsKey: 'old',
    },
  },
  custom: {
    selectQueries: [
      `TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value`,
    ],
  },
  version: '1'
};

</code></pre>
<p>このマッピング定義から、以下のようなSQLが自動生成されます。</p>
<pre><code>SELECT
  CAST(jsonPayload.user.id AS STRING) AS user_id,
  CAST(jsonPayload.http_request_meta.ip AS STRING) AS ip_address,
  TO_JSON(ANY_VALUE(IF(detail.detailType = 'diff', detail.old, NULL))) AS before_edit,
  TO_JSON(ANY_VALUE(IF(STRING(detail.detailType) = 'fields' AND CAST(jsonPayload.resource.action_type AS STRING) = 'create', detail.value, NULL))) AS created_value
FROM
  sampleTableFunction(api_key, start_date, end_date)
  ...

</code></pre>
<h4>3. プロジェクト別テーブル関数</h4>
<p>最終的なデータ提供層として、プロジェクトごとにデータセットを分け、その中にプロダクトごとのテーブル関数を配置しています。この設計には二つの利点があります。</p>
<ol>
<li>将来的に<a href="https://cloud.google.com/bigquery/docs/analytics-hub-introduction?hl=en">BigQuery sharing</a>経由などでデータセットごとユーザーに提供する可能性への対応</li>
<li>マッピング変更時の影響範囲の局所化</li>
</ol>
<p>このテーブル関数は基本的に中間層（プロダクト別変換テーブル関数）を参照するだけの構造になっています。そのため、中間層の変換ロジックが変更された場合でも、すべてのプロジェクトデータセット内のテーブル関数を更新する必要がなく、運用負荷を大幅に削減できます。</p>
<h3>テーブル関数の自動生成と管理</h3>
<p>続いて、テーブル関数の作成・更新プロセスについて説明していきます。構成としては、以下のようになっており、基本的に自動化されています。</p>
<p><img src="https://ik.imagekit.io/plaid/47096b33-1545-48e9-aa3d-2269ef407723/auditlog_table_function_automation.png" alt="auditlog_table_function_automation.png"></p>
<h4>プロジェクトログ抽出テーブル関数の管理</h4>
<p>基盤層のテーブル関数は、リポジトリ内のコード変更をトリガーにGitHub Actionsを通じて更新されます。(構成図の左側参照) この重要なコンポーネントはCODE_OWNERで厳格に管理されており、特定のレビュアーの承認がなければ変更できない仕組みになっています。</p>
<h4>プロダクト別テーブル関数の自動生成</h4>
<p>各プロダクトチームは、マッピング定義を更新するだけで、GitHub Actions経由でSQLが自動生成され、対応するテーブル関数が更新されます。(構成図の左側参照)</p>
<h4>プロジェクト別データセット・テーブル関数の自動生成</h4>
<p>新しいプロジェクトのデータが生ログに追加された場合、自動的に対応するデータセットとテーブル関数が作成される仕組みを実装しています。(構成図の右側参照) 具体的には、Cloud Schedulerで定期的にCloud Run関数を起動し、直近の生ログをスキャンして新規プロジェクトを検出します。</p>
<p>検出された新しいプロジェクトに対しては、データセットの作成とテーブル関数の生成が自動的に行われます。データセット・テーブル関数が作成済みのプロジェクトに関する情報は、BigQueryの簡易的なテーブルを使い以下のように管理しています。</p>
<table>
<thead>
<tr>
<th>project_id</th>
<th>product</th>
<th>version</th>
<th>created_at</th>
</tr>
</thead>
<tbody>
<tr>
<td>xxx</td>
<td>talk</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>0</td>
<td>2025-04-30 02:50:19.420000 UTC</td>
</tr>
<tr>
<td>xxx</td>
<td>datahub</td>
<td>1</td>
<td>2025-04-30 02:51:19.420000 UTC</td>
</tr>
</tbody>
</table>
<h2>保守運用の工夫</h2>
<hr>
<p>監査ログ基盤の運用には、データの安全性確保と長期的な保守性の両立が求められます。ここでは、その課題に対応するための技術的な工夫を紹介します。</p>
<h3>効率的なデータダウンロード機構</h3>
<p>監査ログは大量のデータを扱うため、効率的なダウンロード機構が必要です。そこで、BigQueryのストリーミング機能を活用し、データを10MBごとに圧縮してクライアントに送信する仕組みを実装しています。</p>
<p>また、ユーザビリティ向上のための工夫として、生ログに含まれる<code>projectId</code>などの単なる識別子を、ストリーミング処理中にアプリケーションのデータベースから取得したプロジェクト情報と結合し、 <code>株式会社プレイド検証環境</code> のようなユーザーが理解しやすい表記に変換しています。</p>
<p>この仕組みは現状は十分に対応できていますが、予期せぬ大量データなどによりエラーが発生した場合は、Datadogにエラーを通知するようにしているため、迅速に対応できるようになっています。</p>
<h3>多層的なセーフティネット</h3>
<p>他プロジェクトのデータが混入するリスクを最小化するため、複数のセーフティネットを設けています。</p>
<p>まず、テーブル関数のセキュリティ監視として、Cloud Scheduler と Cloud Run 関数を組み合わせ、定期的にテーブル関数にアクセスして返されるデータを検証しています。他プロジェクトのデータが検出された場合は、即時 Datadog のアラートが発報される仕組みです。</p>
<p>さらに、ユーザーがデータをダウンロードするストーリミング処理にも、BigQueryで二重チェックを行い、他プロジェクトのログが含まれていないことを確認しています。万一の混入が検出された場合は、ダウンロード処理を中止する安全機構を導入しています。</p>
<h3>継続的なサービス監視</h3>
<p>監査ログは機能的な性質上、月に一回ダウンロードされるなど、日常的に頻繁に使用される機能ではありません。そのため、問題が長期間気づかれず放置されてしまうリスクがあります。この課題に対応するため、<a href="https://www.datadoghq.com/ja/dg/apm/synthetics/synthetic-monitoring/">Datadog Synthetics (外形監視ツール)</a>を活用して、画面から定期的にダウンロードを行い実際にファイルがダウンロードできるかのチェックしています。</p>
<p>これにより、実際のユーザーが機能を使用する前に問題を発見し、迅速に対応することができる体制を整えています。</p>
<h3>テーブル関数のバージョン管理</h3>
<p>監査ログのカラム構成や形式は、プロダクトの進化に合わせて変更される可能性があります。変更があった場合でも、既存のシステムやユーザーの利用を妨げないために、テーブル関数にはバージョン管理機能を導入しています。</p>
<p>マッピング定義に<code>version</code>パラメータを指定することで、新しいバージョンのテーブル関数を追加しつつ、既存のバージョンも並行して維持できます。これにより、ユーザーは自身のニーズに合わせたバージョンを選択できるようになり、互換性を保ちながら監査ログを変更させることができるようになっています。</p>
<h2>まとめ</h2>
<hr>
<p>監査ログの抽出基盤は、セキュリティとユーザビリティのバランスを取りながら、開発者が容易に実装・拡張できる設計を目指しています。多層構造のテーブル関数、自動生成の仕組み、複数のセーフティネットにより、安全かつ柔軟な監査ログ提供を実現しています。</p>
<p>マルチプロダクト環境では、新しいプロダクトの追加や既存プロダクトの変更が頻繁に発生しますが、この基盤により、各プロダクトチームは複雑なセキュリティ実装をほとんど意識せずに、安全に監査ログを拡張できます。プロダクト間の監査ログの一貫性を保ちながらも、それぞれのプロダクト特有の情報を柔軟に取り込める設計が、マルチプロダクト戦略を支える重要な要素となっています。</p>
<p>今後も新たな要件やプロダクトの追加に対応しながら、監査ログ基盤の進化を続けていく予定です。また、さらなる活用方法として、機密情報を適切に除去した上で社内の調査・分析用途に監査ログを活用することも検討しています。例えば、長期間使用されていないアカウントの洗い出しやプロダクト使用状況分析などを通じて、セキュリティの強化やサービス改善に繋げていくことが可能です。このように監査ログは単なる記録としてだけでなく、データドリブンな意思決定を支える貴重な情報源となる可能性を秘めています。</p>


マルチプロダクト環境における監査ログ抽出基盤のアーキテクチャと技術的な工夫を解説。BigQueryのテーブル関数を活用し、「安全性」と「開発のしやすさ」を両立する設計思想、自動生成の仕組み、運用時の工夫を紹介します。

監査ログ抽出基盤の設計と実装：BigQueryテーブル関数による安全性と柔軟性の両立

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

<h1>はじめに</h1>
<p>こんにちは。プレイドのKARTE Messageチームでエンジニアをしている林(<a href="https://x.com/smoothbronco">Twitter</a>)です。</p>
<p>この記事では、動的にSQLを生成する機能の実装を無事故で改善し、その後の開発スピードを向上させたことについてお話しします。</p>
<h1>KARTE Messageについて</h1>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、メール・アプリプッシュ・LINEなどのチャネルからエンドユーザーにパーソナライズした配信を効率化したMAツールです。</p>
<p><a href="https://tech.plaid.co.jp/karte_message_mass_delivery_architecture">メール配信サービスの運用について紹介している記事</a> があるので、こちらもぜひ併せてご覧ください。</p>
<h2>配信対象抽出機能について</h2>
<p>KARTE Messageでは、SQLが書けないマーケターでもGUIベースでメールやLINEの配信対象を抽出できるための機能を提供しています。</p>
<p>配信対象はデータ統合・利活用プラットフォームである<a href="https://developers.karte.io/docs/about-datahub">KARTE Datahub</a>内のテーブルまたはクエリをベースにしており、「リスト」と呼びます。</p>
<p>リストには配信対象のメールアドレスやユーザーID、クーポンコード等のコンテンツに埋め込むデータが入っています。</p>
<p>たとえば、会員マスタのうちGOLDランクの会員にだけメールを送りたい場合は、以下のような操作で対象を絞り込むことができます。ある対象を除外する、パーソナライズした値をコンテンツに埋め込む、施策内で1ユーザーに対してx回まで配信する、といったこともこの機能で実現しています。</p>
<p>※ データはすべてダミーです。</p>
<p><img src="https://ik.imagekit.io/plaid/ab4a4133-596b-42e1-986a-164fa2a444fb/merge_list.webp" alt="merge_list.webp"></p>
<p>配信対象抽出の裏側では、クライアントの設定した値から動的にSQLを生成しています。</p>
<p>先ほどのGOLD会員の例では、以下のようなSQLを生成します。</p>
<pre><code class="language-sql">WITH result AS (
	WITH master_{list_id} AS (
		-- &quot;【デモ】マスターデータ_メール&quot;のクエリ
		SELECT * FROM demo_master_mail
	),
	subset_{list_id} AS (
		-- &quot;gold会員&quot;のクエリ
		SELECT * FROM demo_master_mail WHERE rank = 'gold'
	),
	merge_list AS (
		WITH master AS (
			SELECT * FROM master_{list_id}
		),
		subset AS (
			SELECT user_id FROM subset_{list_id}
		)
		SELECT
			master.user_id AS user_id,
			master.email AS target
		FROM master
		LEFT JOIN subset ON master.user_id = subset.user_id
		WHERE subset.user_id IS NOT NULL
	)
	-- (中略)
)
SELECT * FROM result;
</code></pre>
<p>このSQLは配信する時とクライアントが対象ユーザーをプレビューする時にKARTE Datahubのテーブルに対してクエリします。</p>
<p>対象抽出のデータ結合に用いるキーはユーザーIDか配信先 (メールアドレスやLINE ID) を使っており、ユーザーIDのカラムがある場合はユーザーIDで結合します。</p>
<p>クライアントの持っているデータによってはユーザーIDカラムのないデータもあるので、その場合は配信先のカラムで結合します。</p>
<p>また、一部のユーザーIDがnullになっていることもあります。</p>
<h2>改善前の課題</h2>
<p>たとえば以下のようなケースだと、メールアドレスが一致していても一部でuser_idがnullになっている場合はパーソナライズする値が落ちてしまいます。</p>
<p><img src="https://ik.imagekit.io/plaid/acd9c458-90cd-404f-a92d-bc3f94f36254/user_id_null.png" alt="user_id_null.png"></p>
<p>このようなケースを含め、配信対象抽出機能を改善する前は以下のような課題がありました。</p>
<ul>
<li>データに関する課題
<ul>
<li>targetやuser_idという一般的な名前が予約語になっており、クライアントの設定次第でカラム名が衝突する</li>
<li>user_idがnullableなので、対象抽出やパーソナライズする値を結合する際にレコードが落ちる場合がある</li>
</ul>
</li>
<li>ロジックに関する課題
<ul>
<li>配信時のクエリとプレビュー時のクエリを返すロジックの共通化ができておらず、出力に差分が生じてしまう</li>
<li>コードが複雑で処理の分割がうまくできておらず、キャッチアップコストが高い</li>
</ul>
</li>
</ul>
<p>配信対象抽出機能はKARTE Messageの中でもコアになる機能であることや、今後も頻繁にアップデートがかかることが想定される機能でした。この状態のまま運用していくと予期せぬバグやインシデントを起こしかねないので、機能全体に手をいれることにしました。</p>
<h2>やったこと</h2>
<p>以下2つのアプローチを取って行いました。</p>
<ol>
<li>リストの元データを view table にし、クエリするときは view table を参照する</li>
<li>既存の仕様からデータモデルを再定義し、コードをまるっと作り替える</li>
</ol>
<p>1つ目に関しては、view tableにすることでクライアントのデータに一定の前提を設けられるので、データに関する課題を解決することができると考えました。</p>
<p>2つ目に関しては、仕様が明確だったこと、既存のコードに対してテストが不十分だったことなどから、改めてデータモデルから作り替えた方がメンテナブルになるだろうと考えました。</p>
<h3>view tableにする対応について</h3>
<p>先に、viewのクエリを示します。</p>
<pre><code class="language-sql">SELECT
  *,
  cast(
    ifnull(
      cast(`user_id` as string),
      concat('null_embedded_', `email`)
    ) as string
  ) as masspush_user_id,
  cast(`mail` as string) as masspush_target,
FROM
  (
    -- リストの元データのクエリ
    SELECT
      *
    FROM
      demo_master_mail
  )
</code></pre>
<p>ポイントは2つです。</p>
<ul>
<li>予約語はクライアントが設定する可能性が限りなく低い命名にする</li>
<li>user_idがnullの時は<code>null_embedded_{配信先}</code> で埋める</li>
</ul>
<p>こうすることで、カラム名が重複することや最終的に配信対象が抜け落ちてしまうことが減りました。リストの元データのクエリは数百〜数千行になることもあるので、最終的なクエリをシンプルに保つことができるようにもなりました。</p>
<p>移行する中で難しかったのが、viewのクエリが参照するデータの鮮度を保つことです。</p>
<p>リストの中には、「先月10,000円以上購入した人」や「30分前にカゴ落ちした人」などの相対日時を条件に含むものがあります。これらは絶対日時に変換してクエリにしているので、配信やプレビューが実行される直前でviewのクエリを更新する必要がありました。</p>
<p>また、KARTE DatahubはBigQuery上にテーブルを保持しています。BigQueryのテーブル更新オペレーションは10秒で最大5つまでというクォータがあるので、都度viewを更新するのは現実的ではありません。</p>
<p>そこで、以下のような実装で更新オペレーションを極力減らすことにしました。</p>
<pre><code class="language-tsx">export const updateListViewQueryIfBaseSQLModified = async (
	baseSQL: string;
	list: List;
) =&gt; {
  const tableName = createTableName(list);
  const cachedQueryHash = await findCachedQueryHash(tableName);
  const newQueryHash = hashQuery(baseSQL);
  // 最新のqueryとcacheしたqueryのhashが一致してれば処理を終える
  if (cachedQueryHash === newQueryHash) {
    return;
  } else {
    // BigQueryに問い合わせてviewのqueryを比較する
    const isEqualBaseSQL = await compareViewToBaseSQL({
      list_id: list.id,
      baseSQL: baseSQL,
    });
    // queryが異なればviewのqueryを更新する
    if (!isEqualBaseSQL) {
      const viewQuery = buildQuery(list, baseSQL);
      await updateView(viewQuery, list.id);
    }
    // table名をkeyに、queryのhashをvalueにしたcacheを保存する
    await cacheQueryHash({ key: tableName, query: baseSQL });
  }
}
</code></pre>
<p>まず、BigQueryにリクエストする手前にcacheを挟むようにしました。同じリストを使い回して同時刻に複数個の配信を実行するクライアントは多いです。このようなケースはcacheのおかげでBigQueryへのリクエストを減らすことができました。</p>
<p>次のステップでは、BigQueryに問い合わせて最新のviewのqueryを取得し、比較するようにしました。テーブル取得のクォータは更新に比べて制約が緩いので、更新前に最終チェックをしています。</p>
<p>このようなステップを踏むことで、配信が集中する時間帯でもクォータを超えることなくviewのクエリを最新の状態に保つことができました。</p>
<h3>コードの作り替えについて</h3>
<p>コードの作り替えはTDDライクに行いました。まず仕様からテストケースを起こし、そのテストケースに従ってテストが通るようにコードを書くようにすることで、仕様の抜け漏れやエッジケースの見落としなどがないかを確認しながら進めることができました。</p>
<p>また、リリースに関してはview table対応とは別で行う、一部のテナントから段階的に行うなど、万が一問題があったときの影響範囲を最小限に抑えながら進めました。</p>
<h2>結果</h2>
<p>かなり大規模かつ問題が起きた時のリスクが大きい修正でしたが、配信に影響なくすべてリリースすることができました。</p>
<p>またこのリリース後、キャッチアップコストが大幅に減り、開発工数がより正確に見積れるようになりました。新しくチームに入ってきたエンジニアの方が新規に機能拡張をすることになった時も、キャッチアップが大変という感覚は無かったそうです。改善前に比べてテストも充実する形になったので、変更を加える際の影響範囲やエッジケースのバグ取りこぼしも見えやすくなりました。</p>
<p>課題の種類をデータとロジックに分けて、それぞれを解決するアプローチにしたことでシンプルになったと個人的には思っています。</p>
<h2>最後に</h2>
<p>私が所属するKARTE Messageチームでは、大量配信を支える配信基盤の改善や、より良いMAツールにしていくための機能開発など、まだまだやりたいことがたくさんあります。</p>
<p>少しでもこのような領域に興味を持ってくださった方は<a href="https://recruit.plaid.co.jp/product">採用ページ</a>をご覧ください。応募待ってます！</p>


非エンジニアでも直感的に動的なSQLを生成できる、GUIのノーコードツールの改善方法の紹介

動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話

<p>こんにちは！プレイドでエンジニアをしている土佐といいます。</p>
<p>先日、社内で「生成AI」をテーマにしたLightning Talk（LT）会が開催されました！🎉プレイドだけでなく、グループ会社のRightTouchメンバーも集結し、総勢なんと約80名が参加する、とっても賑やかなオンラインイベントになりました。</p>
<p>ここ数ヶ月、社内でもCursorやCline、Vertex AI経由のGPTモデルなど、さまざまな生成AIツールの活用がどんどん進んできて、「お、そろそろ各チームで溜まってきた知見や『こんなことやってみた！』をシェアする良いタイミングじゃない？」ということで、今回のLT会が企画されたんです。</p>
<p>この記事では、当日の熱気や発表の面白さ、そして私たちが感じた「これから」の可能性を、少しでも皆さんにお届けできればと思います。LT会の雰囲気や学びが伝わると嬉しいです！</p>
<h2><strong>当日の熱気：オンラインでも伝わる一体感！</strong></h2>
<p>会場はオンライン。それぞれの場所から参加する形でしたが、画面越しにも伝わる熱気…！🔥 発表が始まると、みんな真剣な表情で聞き入り、Slackのスレッドも質問や感想、「なるほど！」「それ面白い！」といったコメントで、めちゃくちゃ盛り上がっていました。</p>
<h2><strong>発表ハイライト 🚀</strong></h2>
<p>今回のLT会では、本当に多種多様なテーマで10件の発表がありました。どれも興味深く、刺激的な内容ばかりでした！すべての発表をダイジェストでご紹介します。</p>
<ul>
<li><strong>「採用面談の日程調整をAIにやってもらうワークフローを構築しました」</strong>
<ul>
<li>候補者と複数面接官の複雑なカレンダー調整を、Zapier AIとDifyを駆使して自動化！ Slackから使える「Google Calendar 日程提案くん」で、面倒な調整業務をスマートに解決する実用的な工夫が光りました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://note.com/kantetsu/n/n00958cea908d">https://note.com/kantetsu/n/n00958cea908d</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「お客さんの商品データを検索するMCPサーバー作ってみた」</strong>
<ul>
<li>通常のキーワード検索だけでなく、ベクトル検索で&quot;似ている商品&quot;も提案できるAPIサーバーを自作。ユーザーの「見つからない…」を減らす、既存技術を組み合わせた価値創造の好例でした。</li>
</ul>
</li>
<li><strong>「Cline + ChatGPT 4o 画像生成を使ったOSS開発をしてみた」</strong>
<ul>
<li>自作OSS「Gunshi」の開発で、Clineによるコーディング支援やドキュメント生成、ChatGPT 4oによるロゴ・OGP画像作成までAIを活用！ 開発プロセス全体でのAI活用スタイルが新鮮でした。</li>
<li><a href="https://gunshi.dev/">https://gunshi.dev/</a></li>
</ul>
</li>
<li><strong>「生成AIにサポートサイトドキュメントを書かせて公開してみた」</strong>
<ul>
<li>Cursor等のAIツールを使い、コードベースからサポートサイトのドキュメントを効率的に生成・公開。人間には手間のかかる表作成などもAIに任せる、実践的なノウハウが共有されました。</li>
</ul>
</li>
<li><strong>「ボランティアのイベント告知サイトの更新をClineを使ってほぼ自動化した件」</strong>
<ul>
<li>ボランティアで運営するWordPressサイトの更新作業を、Cline、RPA、ChatGPT生成HTMLで見事に自動化！ Gutenberg記法を活用することで、ビジュアルエディタとの互換性を持たせる工夫を行い、大幅な効率アップを実現した、技術による社会貢献の素敵な事例でした。</li>
</ul>
</li>
<li><strong>「AI開発基盤を作ってみた」</strong>
<ul>
<li>AI機能をより簡単に開発できる基盤を開発中。AIエージェント開発の知見集約や再利用性を高める土台作りのお話にワクワクしました。</li>
</ul>
</li>
<li><strong>「code-bugsというCLIツールを作った」</strong>
<ul>
<li>複数ファイルにまたがる定型的なコード修正を、AIが自動で行ってくれるCLIツール「code-bugs」を開発。簡単なレシピで面倒な作業を効率化する、開発者の頼もしい味方になりそうです！</li>
</ul>
</li>
<li><strong>「AI Agentにセキュリティレビューをやってもらう」</strong>
<ul>
<li>Copilot AgentやCursorにセキュリティルールを学習させ、コードレビューを補助させる試み。AIをセキュリティチェックの「心強い相棒」として活用する可能性が示されました。</li>
<li>詳細な記事はこちら
<ul>
<li><a href="https://tech.plaid.co.jp/security-review-by-ai-agent-101">https://tech.plaid.co.jp/security-review-by-ai-agent-101</a></li>
</ul>
</li>
</ul>
</li>
<li><strong>「誰でもできるvibe-coding」</strong>
<ul>
<li>エンジニア以外の職種の方がAIで機能を実装！顧客解像度の高い人が直接開発できる可能性と、レビュー負荷軽減のためのプロセス改善（仕様レビュー、PR分割）というリアルな試行錯誤が共有されました。</li>
</ul>
</li>
<li><strong>「Codatumで組織サーベイの分析にLLMによる要約を埋め込んでみた」</strong>
<ul>
<li>BigQueryとVertex AIを連携し、SQL関数 <code>ML.GENERATE_TEXT</code> を活用して従業員サーベイの大量の自由記述回答をグループ別に要約。SQLだけで高度なテキスト分析を実現するパワフルな活用事例でした。</li>
<li>Codatumとは
<ul>
<li><a href="https://codatum.jp/">https://codatum.jp/</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2><strong>LT会を終えて：見えてきた景色と、これからの私たち</strong></h2>
<p>本当に刺激的なLT会でした！</p>
<p>個人的に最も印象的だったのは、「誰でもできるvibe-coding」の発表です。プロダクトやお客様に一番近いメンバーが、AIを使って直接価値を生み出せる。これって、開発のあり方やスピード感を根本から変える可能性を秘めていると感じました。</p>
<p>もちろん、「じゃあ、私たちソフトウェアエンジニアの価値ってどこにあるんだっけ？」という問いも同時に生まれます。AIがコードを書けるようになった今、私たちはより本質的な課題解決や、アーキテクチャ設計、そしてAIを最大限に活用するための環境構築といった領域で、さらに価値を発揮していく必要があるのかもしれません。今回のLT会は、そんなことを考える素晴らしいきっかけになりました。</p>
<p>プレイドでは、**「技術はトレンドを追うためではなく、長期的なインパクトと組織的な再現性を生み出す原動力である」**と考えています。今回のLT会で見られた多様なチャレンジは、まさにその思想を現場レベルで体現しているように感じました。</p>
<p>単に「生成AIが流行っているから使う」のではなく、「<strong>どうすれば顧客への価値提供や、私たちの働き方を本質的に良くできるか？</strong>」という視点で、みんなが主体的にAIと向き合い、試行錯誤を楽しんでいることがわかったイベントでした。</p>
<p>参考</p>
<p><a href="https://blog.plaid.co.jp/n/nb08d947606f3">https://blog.plaid.co.jp/n/nb08d947606f3</a></p>
<h2><strong>おわりに：<strong>プレイド</strong>のAI環境</strong></h2>
<p>実は、あまり大々的には言っていませんが、プレイドでは、エンジニアは <strong>Cursor、Cline、Vertex AI経由の各種モデルといった生成AIツールを、かなり自由に試せる環境</strong>が整っています。これ、個人的にはものすごい「福利厚生」だなと思っていて…（だって、個人で契約したら、日に数万円かかることもありますからね！）</p>
<p><strong>「生産性のための環境投資は死ぬほど安い」</strong> というのがプレイドのエンジニアのマインドセットの一つ。セキュリティには最大限配慮しつつも、これからも価値創出につながる新しい技術は積極的に取り入れていくんだろうな、と感じています。</p>
<p>そんなプレイドでは、一緒に未来のプロダクトを作るソフトウェアエンジニアを絶賛募集中です！</p>
<p>今回のLT会のような、技術への探求心や「やってみよう！」の精神を大切にする環境に興味のある方は、ぜひ採用ページを覗いてみてくださいね。</p>
<p>👉 <strong>プレイド採用ページ：</strong> <a href="https://recruit.plaid.co.jp/product">https://recruit.plaid.co.jp/product</a></p>
<p>最後まで読んでいただき、ありがとうございました！</p>
<p>P.S. このブログ記事も、実はGoogle MeetのGemini議事録とGemini 2.5 Proの力を借りて、構成案から執筆までサポートしてもらいました！</p>


プレイド社内で開催された生成AIのLT会レポート。グループ会社RightTouchも参加し、CursorやVertex AI経由GPT等の活用事例や開発知見を共有。当日の発表をサマリでお伝えします

生成AI、どう使う？ プレイド社内LT会で活用のヒントを探ってみた！

エンジニアである私が、ビジネスチームを加速させる為に取り組んだ4つのアプローチを記載しました。
エンジニア的な思考を使って、どうチームリーディングすることが効果的なのか。私が取り組んだ中から、特に効果が高かったものを紹介させていただきます。

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ | PLAID engineer blog

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ

<p>プレイドのエンジニア兼ハンターの <a href="https://github.com/algas">@algas</a> です。<br>
<a href="https://ramdajs.com">Ramda.js</a> の関数を例にして JavaScript による関数型プログラミングの考え方を紹介します。<br>
本記事では Ramda.js 自体を紹介するのではなく、より深い関数型プログラミングの考え方を学ぶきっかけを作れることを意図しています。</p>
<h2>想定読者</h2>
<ul>
<li>Node.js でアプリケーションを実装したことがある</li>
<li>関数型プログラミングに興味がある</li>
</ul>
<h2>JavaScript でなぜ関数型プログラミングが必要なのか</h2>
<p>JavaScript のモジュールの多くは Mutable で副作用の影響を受けやすい実装になっています。<br>
副作用の影響を受けやすければ、そのモジュールを複数の場所で利用するのが難しくなります。<br>
さらに関数などのインターフェースが適切でなかったり、意図したとおりに機能しなければ再利用するのが難しく冗長なコードが増えてしまうことになります。<br>
冗長なコードは可読性が低く理解するのにも時間がかかります。<br>
それによって不具合を混入しやすくなったり、不具合を解消するのに不要な時間がかかってしまいます。<br>
関数型プログラミングを導入することで、コードを短く保ち素早く実装して不具合を混入しにくくなることが期待できます。<br>
これはもちろん手法の一つであり、すべての問題を解決する万能の魔法ではありません。</p>
<h2>Ramda.js と関数型プログラミング</h2>
<p>Ramda.js は JavaScript の実用的な関数のライブラリです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c88bd433-7b95-48db-a621-3166bd1ad72c/ramdaFilled_200x235.png" alt="ramdaFilled_200x235"><br>
以下のような特徴を持っています。</p>
<ol>
<li>純粋関数型<br>
不変で副作用の影響を受けにくいような設計になっています。</li>
<li>自動カリー化<br>
関数の再利用がしやすくなります。</li>
<li>引数の最適化<br>
基本的には最後の引数にデータが来るようになっています。</li>
</ol>
<p>Ramda.js は便利な関数を数多く揃えていて、このライブラリを使ってアプリケーションを実装するだけでも非常に有益です。</p>
<p>Ramda.js を使うとどのように便利なのかについては、<a href="http://randycoulman.com/blog/2016/05/24/thinking-in-ramda-getting-started/">Thinking in Ramda</a> のブログに良くまとめられています。</p>
<h2>map の定義</h2>
<p>Ramda.js の <a href="https://ramdajs.com/docs/#map">map</a> 関数の定義を見てみましょう。</p>
<pre><code class="language-haskell">map :: Functor f =&gt; (a -&gt; b) -&gt; f a -&gt; f b
</code></pre>
<p>上記は JavaScript の文法ではありません。<br>
特に Haskell に馴染みがない読者向けに上記の定義を詳しく説明します。<br>
ちなみに Haskell では Ramda.js の map が <a href="http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#v:fmap"><code>fmap</code></a> という関数に該当します。</p>
<p>'=&gt;' の左側は関数の型制約です。<br>
<code>Functor f</code> とは f は <code>Functor</code> であることを示しています。<br>
Functor 自体が何かについては後ほど詳しく説明します。</p>
<p><code>-&gt;</code> は関数型コンストラクタです。<br>
<code>a -&gt; b</code> とは型 <code>a</code> の値を引き数に1つ取り、型 <code>b</code> の値を返す関数であることを示しています。<br>
例えば <code>a -&gt; b -&gt; c</code> は第一引数に型 <code>a</code> の値を、第二引数に型 <code>b</code> の値を取り、型 <code>c</code> の値を返す関数です。<br>
a, b のように小文字で書かれた型に特に制約がなければ任意の型であることを表しています。</p>
<p>小文字がスペース区切りで連続している場合には、関数を適用したことを表しています。<br>
つまり <code>f a</code> は関数 f を a に適用した値です。</p>
<p>上記を踏まえてもう一度 <code>map</code> の定義を見直してみます。<br>
<code>map</code> は第一引数に <code>a -&gt; b</code> という値(すなわち関数)、第二引数に <code>f a</code> という値を取り、<code>f b</code> という値を返します。</p>
<p>詳しくは <a href="https://github.com/fantasyland/fantasy-land">Fantasy Land Specification</a> をご参照ください。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3490a2b-51bb-45ed-865b-ca289e6f2314/logo.png" alt="logo"></p>
<h2>Functor とは何か？</h2>
<p>Fantasy Land Specification に記載されている <a href="https://github.com/fantasyland/fantasy-land#functor">Functor</a> の定義を見てみましょう。</p>
<ol>
<li>Identity<br>
<code>map(a =&gt; a, u) == u</code><br>
<code>a =&gt; a</code> という「何もしない」関数を map に適用しても、適用する前と同じです。</li>
<li>Composition<br>
<code>map(x =&gt; f(g(x)), u) == map(f, map(g,  u))</code><br>
これは <code>x =&gt; f(g(x))</code> という x に関数 g と関数 f を map で適用した値は、<br>
関数 g を map した値にさらに関数 f を map した値と同じです。</li>
</ol>
<p>Functor とは上記2つの性質 (Identity, Composition) を示すような型制約のことを指します。<br>
上記の map は Functor の例のために仮においたもので、map 以外の Functor の性質を持つ関数も同様の性質を示すことが期待されます。<br>
また map 関数の定義における f には任意の Functor を適用できます。</p>
<h2>Functor 制約を持つ関数の実装例</h2>
<p><a href="https://github.com/ramda/ramda-fantasy">Ramda Fantasy</a> では Functor として Maybe, Either など8つの実装が紹介されています。<br>
また Array, Object も Functor の性質を満たすことが分かっています。<br>
これらはすべて Functor の性質を満たしているので、Ramda.js の map 関数を適用できます。</p>
<p>以下で map 関数を使った実装例を紹介します。</p>
<pre><code class="language-javascript">const R = require('ramda');
const S = require('sanctuary');

const mapFunc = R.map(R.compose(S.mult(2), S.add(1)));
const a = [1,2,3];
const z = S.Just(42);
const n = S.Nothing;
const w = S.Right(99);
const e = S.Left(&quot;error&quot;);

console.log(mapFunc(a));
console.log(mapFunc(z));
console.log(mapFunc(n));
console.log(mapFunc(w));
console.log(mapFunc(e));
</code></pre>
<p><code>mapFunc</code> は Number を値に持つ Functor の中身に &quot;1 を足して 2 倍する&quot; 関数です。<br>
上記で mapFunc という関数を異なる Functor に適用していることに注目してください。<br>
ここでは List Number, Maybe Number, Either Number のそれぞれの値に全く同じ形式で mapFunc を適用しています。</p>
<p>出力結果は以下のとおりです。</p>
<pre><code>[ 4, 6, 8 ]
Just (86)
Nothing
Right (200)
Left (&quot;error&quot;)
</code></pre>
<p>各値に &quot;1を足して2倍した&quot; 結果が得られていますね。</p>
<h2>そもそも Functor を使うと何がうれしいの？</h2>
<p>Functor 自体は抽象的な存在であり、そのものが実践的な役割を持つわけではありません。<br>
Functor である Maybe などが実際に便利さを示します。<br>
したがって、ここでは Maybe を使うと何が便利になるかということを例に説明します。<br>
<code>Maybe a</code> は <code>Nothing</code> と <code>Just a</code> という2つの値コンストラクタを持ちます。</p>
<pre><code class="language-Haskell">Maybe a = Nothing | Just a
</code></pre>
<p>※ <a href="https://github.com/sanctuary-js/sanctuary">Sanctuary.js</a> の実装では <code>S.Nothing</code> と <code>S.Just(value)</code> という関数がコンストラクタです。<br>
ここで a は Non-Nullable Value になります。null は Nothing に変換されます。<br>
Maybe の世界には null は存在しないので、値が null であるかどうかをチェックする必要はありません。<br>
実装例で示したように Functor (Maybe) であることを前提とした関数を適用した場合には、Nothing か Just かを気にすることなく関数を適用することができます。<br>
Maybe を使う場合に null または Nothing を気にしなければならないのは、以下の2つの時だけです。</p>
<ol>
<li>外界から Maybe の世界に値を変換する時</li>
<li>Maybe の世界から外界に値を変換する時</li>
</ol>
<p>つまり、Maybe を使うと多くのプログラマにとって煩わしい null チェックの回数を大幅に減らすことができます。</p>
<p>本記事では Functor を主な例として説明しましたが、Fantasy Land に記載されているように Functor よりもさらに複雑な条件を持つ Applicative や Monad などの概念も存在します。<br>
これらを詳しくするには余白が足りないので他書にその役割を譲ることにします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2c88e33e-e64f-4f54-88ee-4205b516b80a/dependencies.png" alt="dependencies"></p>
<p>上記は Fantasy Land Specification から引用した図です。</p>
<h2>まとめ</h2>
<p>本記事では Ramda.js, Fantasy-Land を中心に Functor を使った JavaScript による関数型プログラミングに触れる試みをしました。<br>
現実的に現段階において本記事の概念に近づく実装をするためには以下を実践するほうがよいでしょう。</p>
<ul>
<li><a href="https://www.typescriptlang.org/">TypeScript</a> で <a href="https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html">strictNullChecks</a> を有効にする</li>
<li><a href="http://www.purescript.org/">PureScript</a> で実装する</li>
</ul>
<p>また本記事では説明できなかった項目やさらに発展的な内容を知るには Haskell などのプログラミング言語の仕様や実装を学ぶことをオススメします。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://ramdajs.com/">Ramda.js</a></li>
<li><a href="https://github.com/fantasyland/fantasy-land">Fantasy Land Specification</a></li>
<li><a href="https://github.com/ramda/ramda-fantasy">Ramda Fantasy</a></li>
<li><a href="https://github.com/sanctuary-js/sanctuary">Sanctuary.js</a></li>
<li><a href="http://hackage.haskell.org/">Hackage</a></li>
<li><a href="http://randycoulman.com/blog/categories/thinking-in-ramda/">Courageous Software: Thinking In Ramda</a></li>
</ul>
<h2>最後に</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "https://platform.wantedly.com/visit_buttons/script.js";
  fjs.parentNode.insertBefore(js, fjs);
}(document, "script", "wantedly-visit-buttons-wjs"));
</script>


Ramda.jsの関数を例にしてJavaScriptによる関数型プログラミングの考え方を紹介します


JavaScript で体感する関数型プログラミング | PLAID engineer blog

JavaScript で触れる関数型プログラミング

<p>こんにちは、SREの @ikemonnです。<br>
先日開催された <a href="https://builderscon.io/tokyo/2018/">builderscon tokyo 2018</a>で、<a href="https://karte.io/">KARTE</a>にSpinnakerを本番導入して得られた知見について発表させていただきました！</p>
<p>「<a href="https://www.spinnaker.io/">Spinnaker</a>」とは、Netflixが開発したマルチクラウド環境へのCD(Continuous Delivery)ツールです。<br>
利用企業としては、<a href="https://www.waze.com/">Waze</a>や<a href="https://www.mercari.com/jp/">mercari</a>等が有名です。</p>
<ul>
<li>Waze: <a href="/google-cloud-next-18-spinnaker/">Google Cloud Next '18でWazeのSpinnakerのセッションを聞いてきました!</a></li>
<li>mercari: <a href="https://tech.mercari.com/entry/2017/08/21/092743">SpinnakerによるContinuous Delivery</a></li>
</ul>
<p>KARTEでも2018年の1月からSpinnakerを本番環境で導入しており、Spinnakerの<a href="https://www.spinnaker.io/community/">community page</a>にロゴを載せてもらっています！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/fc6f3d32-3193-42e8-b01c-5332fdf0a732/2018-09-11_10_25_27-1.png" alt="2018-09-11_10_25_27-1"></p>
<p>スライド:<a href="https://speakerdeck.com/ikemonn/builderscon-tokyo-2018">Multi-Cloud deploy with Spinnaker</a></p>
<script async class="speakerdeck-embed" data-id="538d3911f1db4e47aa40ad3a676a8853" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
<h2>概要</h2>
<p>Spinnakerの主な特徴は「Multi-Cloud」「Automated Releases」「Built-in Deployment Best Practices」です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dc6f7d76-58e8-44b0-9c91-b9f87e94f4c4/-2018-09-11-10.07.55-1.png" alt="-2018-09-11-10.07.55-1"></p>
<p>KARTEでは、SpinnakerをAWSとGCPのマルチクラウドへのデプロイで利用しています。<br>
(マルチクラウド構成についてはこちら:<a href="/devsumi-2018/">Developers Summit 2018に登壇してきました #devsumi</a>)</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0432da5b-c632-45b2-922b-70ca3ed885bf/-2018-09-11-10.20.09-1.png" alt="-2018-09-11-10.20.09-1"></p>
<p>インフラの負荷としては、秒間最大22,000events/sec、1日10億eventsくらいで、これらを支えるインフラにデプロイしても問題なく稼働しています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ed57ddbf-4de6-4fda-b61f-b2e7fb2438bb/-2018-09-11-10.19.43-1.png" alt="-2018-09-11-10.19.43-1"></p>
<p>Spinnakerは、「マルチクラウド対応」「デプロイ機能が充実」「Immutable Infraを強制する」等といった点で、マルチクラウドへのデプロイにはかなりオススメのツールです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6d614f1c-2327-4fe5-91b5-bb2fb9241cd2/-2018-09-11-10.21.13-1.png" alt="-2018-09-11-10.21.13-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a6e480ef-9b83-4b1f-b45c-c2673dda32dc/-2018-09-11-10.21.31-1.png" alt="-2018-09-11-10.21.31-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f08e5e82-12f4-4289-ae8f-3d062010db3b/-2018-09-11-10.21.46-1.png" alt="-2018-09-11-10.21.46-1"></p>
<p>しかし、Googleで検索しても運用周りの情報が少なく導入/検討しづらいなと感じていました。</p>
<p>そこで、今回の発表では「Spinnakerへの移行のきっかけ」「移行コスト」「運用してみて期待通りだった/期待と違ったこと」等の運用に関する内容を盛り込みました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ac75b9b-9553-48b4-ae9d-263ac4df0c20/-2018-09-11-10.24.09-1.png" alt="-2018-09-11-10.24.09-1"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8e99a1f6-0bf4-49cd-89aa-38583038df87/-2018-09-11-10.22.25-1.png" alt="-2018-09-11-10.22.25-1"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7ccc4733-3151-4df6-bc75-24cf18965a81/-2018-09-11-10.22.51-1.png" alt="-2018-09-11-10.22.51-1"></p>
<p>「期待と違っていたこと」でバグの話をしましたが、Spinnakerも徐々に安定化してきており、現状回避できないバグには遭遇していません。(v1.9)<br>
(導入当時はどうしても回避できないバグがあり、修正してPR出してました…！)</p>
<p>マルチクラウドのCDをやっていくには自信を持ってオススメできるツールなので、ぜひぜひ試してみてください！</p>
<h2>補足</h2>
<p>スライドで紹介したツールやドキュメント等のリンクです。</p>
<ul>
<li><a href="https://www.spinnaker.io/">Spinnaker</a></li>
<li><a href="https://cloudplatform.googleblog.com/2017/06/spinnaker-10-continuous-delivery.html">Spinnaker 1.0: a continuous delivery platform for cloud</a></li>
<li>カナリアデプロイ
<ul>
<li><a href="https://github.com/spinnaker/kayenta">spinnaker/kayenta</a></li>
</ul>
</li>
<li>pipelineをコードで管理する
<ul>
<li><a href="https://blog.spinnaker.io/spin-and-roer-managed-pipeline-templates-4fde2951c648">spin and roer + Managed Pipeline Templates</a></li>
<li><a href="https://github.com/spinnaker/roer">spinnaker/roer</a></li>
<li><a href="https://github.com/spinnaker/dcd-spec">spinnaker/dcd-spec</a></li>
<li><a href="https://github.com/spinnaker/spin">spinnaker/spin</a></li>
<li><a href="https://docs.google.com/document/d/17Ifm562aypjLSHnNJ02COFv_VMv3spicH-7zMYd-oXE/edit#">Spinnaker CLI Design</a></li>
</ul>
</li>
<li><a href="https://join.spinnaker.io/">SpinnnakerのSlackグループ</a></li>
</ul>
<h2>最後に</h2>
<p>リアルタイム解析を実現するCXプラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、マルチクラウド環境の大規模インフラの設計/構築/運用をしていきたい！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


先日開催された builderscon tokyo 2018でスピーカーとして登壇させていただきました！ 概要 「Spinnaker」は、Netflixが開発したマルチクラウド環境へのCDツールです。今回はSpinnakerをKARTEに導入し、半年以上運用して得られた知見についてお話しました。 

Netflix発のOSS"Spinnaker"でマルチクラウドにデプロイしている話 #builderscon

<p>エンジニアチームの mkataigi です。たまには趣向を変えて、エンジニアっぽくないコードの出てこない話を書いてみようかなと思います。以下多分に個人の見解です。</p>
<p>ベンチャーに限らず、あらゆる組織において「最良の結果」を出すことは大事です。「最良の結果」を出せない組織は、一時的には成功したとしても、いずれ「最良の結果」を出した組織に追い抜かれてしまいます。一見着実に進んでるように見えるのに、なぜか競合に差をつけられていく、イノベーションのジレンマというやつですね。</p>
<p>有名な言葉ですが『「最良」の敵は「良」である』と言う言葉があります。人間の時間は有限なので、やったほうがいい（=良）ことをやり続けてしまうと、最大の結果（=最良）を出すための時間がなくなってしまう。つまり、組織が成功し続けるためには、常に「最良の結果」にフォーカスし続けることが必要、ということです。</p>
<p>なお、参考文献は以下になります。</p>
<ul>
<li>イシューからはじめよ―知的生産の「シンプルな本質」
<ul>
<li><a href="https://www.amazon.co.jp/dp/4862760856">https://www.amazon.co.jp/dp/4862760856</a></li>
</ul>
</li>
<li>仮説思考 BCG流 問題発見・解決の発想法
<ul>
<li><a href="https://www.amazon.co.jp/dp/4492555552">https://www.amazon.co.jp/dp/4492555552</a></li>
</ul>
</li>
</ul>
<h1>解くべき課題を考える</h1>
<p>「最良の結果」を出すためには何をすればよいのでしょう。まず「結果を出す」ためのステップを考えて見ます。</p>
<ol>
<li>課題を設定する</li>
<li>課題を解決する</li>
</ol>
<p>このうちどちらをより優先する必要があるのでしょうか。</p>
<p>抽象的でわかりにくくなってきたので、例えば<code>大阪で友達と会う</code>という結果を得ることを考えて見ます。この場合それぞれ次のようになります。</p>
<ol>
<li>課題設定 <code>大阪へ行く</code></li>
<li>解決方法 <code>新幹線で行く</code></li>
</ol>
<p>例えば大阪へ新幹線ではなく鈍行列車で行った場合（課題設定は正しく、解決方法が間違い）はどうなるでしょう。この場合は時間はかかるもののいずれ着くし、途中で間違いに気づけば特急に乗り換えするなどリカバリーをすることもできます。逆に、新幹線に適当に乗った場合（課題設定が間違い、解決方法は正しい）はどうなるでしょう。いくらたっても大阪に着くことはないですし、どこにいるかわからずリカバリーすることも難しくなります。つまり課題設定を正しくするほうが重要ということなります。</p>
<p>エンジニア業界でよくある「顧客が本当に必要だったもの」というやつですね。課題設定が正しくないと、結果が出ないどころか、不要なものを作ってしまいメンテナンスコストだけかかるという、マイナスの効果しか得られません。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c3be8e6e-0e62-437d-98ff-9738cbcc0c8c/----------2018-08-23-17.29.13.jpg" alt="顧客が本当に必要だったもの"><br>
<a href="http://www.projectcartoon.com/">http://www.projectcartoon.com/</a></p>
<h1>最良の課題の条件</h1>
<p>では「最良の結果を出すための課題」を発見するにはどうすれば良いのでしょう。見つける方法を考える前に、まず、自分たちがどんなものを探すのかを明確にするために、どんな課題が最良の課題なのはっきりさせましょう。以下の３点がポイントかなと思います。</p>
<ul>
<li>その課題が解決されることで、将来に大きな影響を与える</li>
</ul>
<p>まず一つ目が、その課題が解決されると将来の展開が大きく変わるもの、になります。その課題が解決されることで別の課題をそもそも解く必要がなくなる課題です。</p>
<pre><code class="language-plaintext">「運転の自動化」という課題が解決されたら、
「大阪への移動経路を探す」「電車内で寝過ごさないようにする」などの課題が、そもそも課題ですら無くなる
</code></pre>
<ul>
<li>その課題は自分だけが解決できる</li>
</ul>
<p>次がなぜ自分がその課題に取り組むか、の部分です。自分以外の人には解決できないけど自分にだけ解決できる課題というのは、自分が解決しないとずっと課題のまま残り続けるため、より解決する重要度が高い問題となります。組織としてもそれがいわゆる競合優位性に繋がるので重要です。</p>
<pre><code class="language-plaintext">「大阪へ直行する路線を作ってしまう」ことができれば、
大阪へ行くための方法を探す必要は無くなる
</code></pre>
<p>（自分にはできないが、世の中にはできる人がいるかもしれない！）</p>
<ul>
<li>その課題に答える方法がある</li>
</ul>
<p>そして当たり前ですが、課題の答えを出せる、出す方法を思いつけることが重要です。結果を出すという観点から考えるとアウトプットが無いと無意味です。</p>
<pre><code class="language-plaintext">「ワープ」する機械を開発できれば大阪へ行くための方法を探す必要はないが、
現代の技術ではできる可能性は非常に薄い
</code></pre>
<h1>最良の課題を見つける方法</h1>
<p>最良の課題をテクニカルに見つける方法を、、、といきたいのですが、課題の定義からもわかる通り、誰にでも同じ方法で見つけられる、というものでは無いようです。とはいえ、それで諦めるのではなく、見つける可能性を高める方法を考えてみたいと思います。</p>
<p>一般的な方法として、最良の課題を探り当てられなくても、「これは良い課題かな？」というところから課題をブラッシュアップして最良に近づけていく思考法を考えてみます。状況によらずに常に成り立つ課題は、将来への影響が大きい可能性が高いと言うことはできそうです。</p>
<ul>
<li>極端な状態を考える</li>
</ul>
<p>状況を極端にしてみることで、状況が変わっても変わらない課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">毎日大阪にいく場合はどうすればいいか
お金を無限に持っている場合にはどうするか
逆にお金がない場合はどうするか
</code></pre>
<ul>
<li>別の人の視点から考える</li>
</ul>
<p>複数の人の視点の重ね合わせることで、誰から見ても重要な、課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">老人が大阪へいきたい場合はどうすればいいか
外国人ならどうするか
</code></pre>
<ul>
<li>抽象化したり具体化したりする</li>
</ul>
<p>課題を抽象的にしてみたり、具体的にしてみたりすることで、普遍的な課題の本質が浮かび上がってきます。</p>
<pre><code class="language-plaintext">抽象的にして別の場所に時間通りに着くにはどうするか
具体的にして大阪に15時に着くにはどうするか
</code></pre>
<h1>さいごに</h1>
<p>以上、最良の課題を見つけるための方法について見てきました。プレイドでも「データによって人の価値を最大化する」ために、日々最良の課題を発見するために奮闘しています。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


組織をより成長させるために、解くべき最良の課題にフォーカスする。そのための解くべき課題の見つけ方を考えてみる。

最良の課題を発見する技術 | PLAID engineer blog

最良の課題を発見する技術

<p>エンジニアの<a href="https://twitter.com/jumpei_ikegami">gami</a>です。<a href="https://twitter.com/search?vertical=default&amp;q=%23%E3%81%97%E3%81%8C%E3%81%AA%E3%81%84%E3%83%A9%E3%82%B8%E3%82%AA&amp;src=tyah">趣味はポッドキャスト配信</a>です。</p>
<p>今回は、「<a href="https://nodejs.org/">Node.js</a>」に焦点を当てた記事です。</p>
<p><a href="https://plaid.co.jp/">PLAID</a>では、約5年前から「<a href="https://karte.io/">KARTE</a>」というサービスを開発しています。そのサーバーサイドの実装は、ほとんどがNode.jsで記述されています。</p>
<p>一方、国内企業の中で、サーバーサイド実装にNode.jsを採用している企業は少ない印象があります。<br>
そこで、以下についてご紹介します。</p>
<ol>
<li>PLAIDがNode.jsで実現しているプロダクト</li>
<li>Node.jsを5年間使ってわかった強みと弱点</li>
<li>Node.jsを使いこなすための工夫</li>
</ol>
<h1>1. PLAIDがNode.jsで実現しているプロダクト</h1>
<p>実際にPLAIDがどのようにNode.jsを使っているかを紹介します。PLAIDでは、「リアルタイムユーザー解析サービス」であるKARTEを主に開発しているので、KARTEの開発について説明します。</p>
<h2>プロダクトの規模</h2>
<p>まずは前提として、KARTEのプロダクトとしての規模がわかるデータを紹介します。</p>
<h3>リクエスト数、イベント数</h3>
<p>KARTEが解析しているデータの規模感は、2018年8月現在の値でおよそ以下の通りです。</p>
<ul>
<li>最大 約20,000 イベント/秒</li>
<li>最大 約10億 イベント/日</li>
</ul>
<p>KARTEが扱うユーザー情報は、「イベント」という単位で連携、解析されます。エンドユーザーのブラウザから飛んでくるリクエストの中に、1つ以上のイベントが含まれています。<br>
1日で10億回ものユーザー解析を処理しているので、かなり「大規模」と言えるかと思います。</p>
<h3>ファイル数</h3>
<p>KARTEのメインのリポジトリのうち、Node.jsで書かれたサーバーサイドの実装に関するファイルの数と行数をカウントすると、以下の結果になりました。</p>
<ul>
<li>ファイル数
<ul>
<li>1,759ファイル</li>
</ul>
</li>
<li>行数
<ul>
<li>126,256行</li>
</ul>
</li>
</ul>
<p>（マイグレーションバッチ、テストコード、空行、コメント行などは除く）</p>
<p>他にも、一部の独自ライブラリはリポジトリを分けて開発しているので、それを加えるともう少し大きくなります。</p>
<h2>実現している機能</h2>
<p>以下の図がKARTEの大まかな構成図です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1e0a1a17-d440-48a9-988a-55b9a5058519/----------2018-08-15-14.41.54-1.png" alt="----------2018-08-15-14.41.54-1"></p>
<p>今後の説明のために、ざっと解説します。</p>
<h3>track/analyze（エンドユーザーの解析とデータ送受信）</h3>
<p>KARTEでは、解析対象のサイトにタグ（ネイティブアプリならSDK）を設置してもらいます。<br>
そこから送られるイベントをリクエストとして受け取り解析をするのが、「track」と「analyze」です。</p>
<ul>
<li>タグやSDKからイベントデータを受信
<ul>
<li>エンドユーザーのセグメントを解析</li>
</ul>
</li>
<li>1秒以内にエンドユーザーにポップアップなどの最適なアクションを送信</li>
<li>レスポンス後の処理も含めて、ユーザーデータを再計算</li>
</ul>
<p>特に、エンドユーザーからのリクエストに対してポップアップなどの最適なアクションを1秒以内に返す必要があり、高いパフォーマンスが求められる部分です。後述するように、NodeのClusterモジュールを使って負荷分散しています。</p>
<p>なお、KARTEではエンドユーザーから送られるイベントデータのスキーマをほとんど決めていないため、大量のスキーマレスなJSONデータを受け取る必要があります。Node.jsはJSONデータの取り回しが楽である反面、大規模なJSONを大量に扱うというCPUインテンシブな処理が苦手なのが悩みです。</p>
<h3>admin（クライアントに管理画面を提供）</h3>
<p>「admin」では、管理画面上でユーザーデータを閲覧できる機能等を提供しています。</p>
<ul>
<li>ルーティング
<ul>
<li>(SPA部分はvue-routerに任せる)</li>
</ul>
</li>
<li>設定値などを保存するMongoDBの操作
<ul>
<li>スキーマ定義</li>
<li>read/write</li>
</ul>
</li>
<li>フロントエンドから叩くRPC APIの提供</li>
</ul>
<p>KARTEではスキーマレスなNoSQL DBである「<a href="https://www.mongodb.com/">MongoDB</a>」を多用しています。MongoDBはほぼJSONライクなドキュメントを扱うので、Node.jsとの相性はかなりよく、DB周りの処理を自然に書くことができます。</p>
<p>主に実現している機能は以上です。</p>
<p>KARTEは「単純なWebサーバーとしての機能」だけではなく、「エンドユーザーの解析機能」をプロダクトのコアとして提供しています。その両方の機能について、特に言語を分けずに全てNode.jsで記述しています。</p>
<p>なお、システムの全体像や解析サービスを実現するGCPの活用方法については、PLAIDのエンジニア陣が執筆した以下の記事をご覧ください。</p>
<p><a href="https://codezine.jp/article/corner/711">大規模解析サービスを支えるGCP活用事例連載一覧：CodeZine</a></p>
<p><a href="https://codezine.jp/article/corner/711"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d31e904e-3650-45c6-9e29-730796f284af/----------2018-08-17-12.09.24.png" alt="----------2018-08-17-12.09.24"></a></p>
<h2>言語（AltJS）</h2>
<p>言語については、場所によって使い分けています。</p>
<ul>
<li>解析部分
<ul>
<li><a href="https://www.typescriptlang.org/">TypeScript</a></li>
</ul>
</li>
<li>その他
<ul>
<li>ES6</li>
<li><a href="https://coffeescript.org/">CoffeeScript</a>（一部）</li>
</ul>
</li>
</ul>
<p>解析エンジン部分だけは、固めに書きたいのでTypeScriptを使っています。大半のソースコードは、開発速度を優先して生のJavaScriptで記述しています。</p>
<p>元々はCoffeeScriptを使っていたのですが、世の多くの会社がそうであるように、Pure JavaScriptの機能強化に伴い、徐々に書き換えを進めています。</p>
<h2>フレームワーク、ライブラリ</h2>
<p>主に以下を使っています。（挙げるとキリがないので、だいぶ削っています）</p>
<ul>
<li><a href="http://expressjs.com/">Express.js</a>
<ul>
<li>薄いので拡張しやすい</li>
</ul>
</li>
<li><a href="https://lodash.com/">Lodash</a>
<ul>
<li>主に複雑なオブジェクトの操作で利用</li>
</ul>
</li>
<li><a href="https://caolan.github.io/async/">async</a>
<ul>
<li>非同期処理を連続/並列で実行するときに便利</li>
</ul>
</li>
<li><a href="http://mongoosejs.com/">Mongoose</a>
<ul>
<li>MongoDB用のODM（Object Document Mapper）</li>
</ul>
</li>
<li><a href="https://www.npmjs.com/package/cron">cron</a>
<ul>
<li>定期バッチの実行</li>
</ul>
</li>
<li><a href="http://plaidev.github.io/bolt-rpc/">bolt-rpc</a>
<ul>
<li>PLAID独自RPCライブラリ
<ul>
<li>OSSとして公開中</li>
</ul>
</li>
<li>内部で<a href="https://socket.io/">socket.io</a>を利用</li>
<li>Node.jsで記述</li>
</ul>
</li>
<li><a href="/webdb-forum-2016/">Brook</a>
<ul>
<li>PLAIDの独自解析エンジン</li>
<li>Node.jsで記述</li>
</ul>
</li>
</ul>
<h1>2. Node.jsを5年間使ってわかった強みと弱点</h1>
<p>上述したKARTEの実装を日々書いているPLAIDのエンジニアに、Node.jsのメリットとデメリットを訊いてみました。カテゴリ別に整理します。</p>
<h2>ノンブロッキング/イベントループ</h2>
<h3>強み</h3>
<p>Node.jsの良く知られたメリットは、KARTEの開発でも享受できています。</p>
<ul>
<li>大量のリクエストが来ても、パフォーマンスが低下しにくい</li>
</ul>
<h3>弱点</h3>
<p>逆に、非同期処理を多用するため、例外発生時やプロファイルをするときに問題の箇所を特定するのが難しかったり、そもそも記述が複雑になりやすかったりします。</p>
<ul>
<li>例外が起こったときのデバッグがキツい</li>
<li>プロファイルむずすぎ</li>
<li>非同期処理がわかりにくい</li>
</ul>
<h2>シングルスレッド</h2>
<h3>強み</h3>
<p>シングルスレッドであることで設計がシンプルになりやすい点は、意外とメリットを感じる点です。</p>
<ul>
<li>コンテキストスイッチによるパフォーマンス低下を防げる</li>
<li>ハードな制約なので、message queueなどを使って綺麗にプロセス分離したシンプルな設計になりやすい</li>
</ul>
<h3>弱点</h3>
<p>やはりCPUバウンドな処理が苦手な点が大きな弱点です。特に弊社の場合は大規模なJSONを扱うことが多く、JSONのパージングが同一スレッドで起きることでブロックされることに悩まされたりしています。</p>
<ul>
<li>シングルスレッド・マルチプロセスの癖/限界</li>
<li>シングルスレッドなのでハングすることがたまにあるし、原因特定が難しい</li>
<li>CPUをゴリゴリ使う処理とは相性が悪い</li>
</ul>
<h2>言語としての性質</h2>
<h3>強み</h3>
<p>特にPLAIDではフロントエンド/サーバーサイドでエンジニアを分けずに開発しているので、どちらも同じ言語で書けるというメリットは大きいです。</p>
<ul>
<li>フロントとサーバーサイドを同じ言語で書けるのでスイッチングコスト低い</li>
<li>JSONをそのまま扱える</li>
<li>非同期処理が簡単に書ける</li>
<li>決まりごとが少なく、用途が自由</li>
</ul>
<h3>弱点</h3>
<p>逆に、Node.js自体が自由すぎて起こる問題もあります。なお、一部では前述のようにTypeScriptを導入しています。</p>
<ul>
<li>シンプル過ぎるので、ファイル構成からコードの書き方まで混乱しがち</li>
<li>typoなどで実行時エラーが起こる</li>
<li>型が弱い</li>
</ul>
<h2>npm/エコシステム</h2>
<h3>強み</h3>
<p>大量のnpmライブラリがOSSとして公開されていて、CTO曰く「センスがいいモジュールが多い」ということです。</p>
<p>また、Node.jsが使っているJavaScriptエンジンであるV8の進化が早く、Node.jsのバージョンを上げただけでパフォーマンスが大幅に向上したことがあります。過去にはKARTEでも、Node.jsのバージョンを6から8に上げたとき、パフォーマンスが2倍以上上がった例がありました。</p>
<ul>
<li>ミニマムでセンスがいいライブラリが多い印象</li>
<li>GoogleがV8をどんどん進化させてくれる</li>
<li>Express.jsがシンプルで良い</li>
</ul>
<h3>弱点</h3>
<p>反面、npm自体のバグや依存性解決の難しさで時間を溶かすことも多かったです。依存性解決については、以前<a href="/npm-to-yarn/">このブログでも紹介</a>しています。ただし、npmのバージョンアップで徐々に解消されつつあります。</p>
<ul>
<li>npmのバグが多い</li>
<li>node_moduleの依存関係周りが辛い</li>
</ul>
<h1>3. Node.jsを使いこなすための工夫</h1>
<p>大規模で高いパフォーマンス要求を求められるプロダクトの実現や、Node.jsの弱点の補完のために実施していることをいくつか紹介します。</p>
<h2>Node.jsのClusterモジュールによる負荷分散</h2>
<p>KARTEでは最大で1秒間に数千リクエストを処理する必要があります。ただし、通常は1つのポートにアクセスできるプロセスは1つだけであり、そこがボトルネックになってしまいます。</p>
<p>そこで、Node.jsのClusterモジュールを使うことで、Cluster内に組み込まれたロードバランサが、リクエスト処理を複数のワーカープロセスに分割してくれます。これにより、CPUのコア数を最大限活かすことができます。</p>
<p>KARTEでは、特にtrackのパフォーマンス向上に役立っています。</p>
<h2>perfコマンドとFlameGraphを使ったCPUプロファイル</h2>
<p>CPU使用率が急上昇したときに、どの処理が重いのかを調べるため、CPUのプロファイリングをすることは多いと思います。しかし一部のプロファイリング用のライブラリは実際にコードの中に組み込むため、アプリケーション自体のパフォーマンスに影響する可能性があります。</p>
<p>そこで、perfコマンドで外側からプロファイルを取ることで、パフォーマンスにほぼ影響を与えずにCPUリソースを無駄に使っている関数を特定できるようにしています。</p>
<p>Node.jsでperfを使ったプロファイルを実現するには、<code>--perf-basic-prof-only-functions</code>などのプロファイル用のオプションを起動時に付ける必要があります。オプションを付けるとperf用の<code>.map</code>ファイルを吐いてくれます。</p>
<p>プロファイル結果は、<a href="https://github.com/brendangregg/FlameGraph">このライブラリ</a>を使ってFlameGraphとして出力しています。FlameGraphというのは、こういうやつです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7b6c3bea-7c5f-4c82-8ce8-d67603d64957/----------2018-08-17-11.23.12.png" alt="----------2018-08-17-11.23.12"></p>
<p>出典: <a href="https://nodejs.org/en/blog/uncategorized/profiling-node-js/">Profiling Node.js | Node.js</a></p>
<p>使いどころとしては、hubotのコマンド経由でいつでも実行できるようにしている他、特定のインスタンスについて自動でプロファイル結果を出力するようにしています。KARTEではDatadogで各インスタンスのパフォーマンスを監視していますが、パフォーマンスが出ないインスタンスは自動で殺すようにしています。後からその原因を追いたい場合に備えて、殺す前に自動でperfコマンドを実行してプロファイルをしています。</p>
<p>なお、KARTEを支える監視サービスと構成については、以下の記事をご覧ください。</p>
<p><a href="https://codezine.jp/article/detail/10674">大規模解析サービスを支える監視サービスと監視構成のポイント | CodeZine（コードジン）</a></p>
<h2>マルチスレッド処理へ</h2>
<p>Node.jsは基本的にシングルスレッドで動作するので、特にCPUインテンシブな処理が苦手です。KARTEではスキーマレスな構造データを大量に行うため、その点がボトルネックになりやすいのが悩みでした。</p>
<p>Node.jsでもマルチスレッド処理がしたいという熱い想いは、弊社エンジニアの牧野が以前ブログで書いています。</p>
<p><a href="https://tech.plaid.co.jp/js_multi_threading/">MicrosoftのNapa.jsでJavaScriptをマルチスレッド化する | PLAID engineer blog</a></p>
<p>Node.js v10.5.0からWorker Threadsが使えるようになったので、今後は一部の処理をそちらに置き換える計画を立てています。</p>
<h1>まとめ</h1>
<p>Node.jsを採用して5年間ほどKARTEの開発に使い続けましたが、特に「リアルタイムユーザー解析サービス」である特性上、その恩恵を受けることが多い。</p>
<p>また、Node.jsやV8の進化も早く、今後の発展が非常に楽しみです。</p>
<p>国内企業がプロダクションでNode.jsを採用する例はまだまだ少ないですが、とても強力な言語なのでぜひ使っていきましょう！</p>
<hr>
<p>リアルタイムユーザー解析プラットフォームの「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


Node.jsをリアルタイム解析サービスの開発で5年間使って知ったメリットやデメリットを紹介します。大規模な解析サービスをNode.jsで記述する上での工夫などについても解説しています。

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと | PLAID engineer blog

PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと

<p>はじめまして。デザイナーの @kazutokojima です。<br>
KARTEを実際に利用されている方の目線でプロダクトの使い勝手や体験を良くしていく「Kaizen」チームとして活動しています。</p>
<p>今回は、昨今よく聞くコンピュテーショナルデザインの考え方とその取り組みについてお話します。</p>
<hr>
<h2>デザインの種類</h2>
<p>「<strong>Design in Tech Report</strong>」については、2015年版の最初のレポートから読まれている方も多いと思います。</p>
<p>最近ではTHE GUILD勉強会「Design in Tech Report 2018 を読み解く」でも取り上げられました。<br>
今回の記事を書く上でとても参考になったのですが、その内容が<a href="https://goodpatch.com/blog/1st-design-in-tech-report-2018-the-guild/">記事として公開</a>されていますので、もしまだお読みでない方はぜひ読んでみてくださいね。</p>
<p>さて、同レポートでは2016年版から「<strong>３つの種類のデザイン</strong>」が提唱されています。</p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/3XJKMfA5UIw6Rw?startSlide=47" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/johnmaeda/design-in-tech-report-2016-59530038" title="Design In Tech Report 2016" target="_blank">Design In Tech Report 2016</a> </strong> from <strong><a href="//www.slideshare.net/johnmaeda" target="_blank">John Maeda</a></strong> </div>
<p>上記のスライドを参考にそれぞれ見てみましょう。</p>
<h4>クラシカルデザイン：</h4>
<p>ロゴやポスターや建築、家具などデザイナー自身の意匠により最終的な完成品を仕上げることを目的としたデザインを指してそう呼んでいるようです。一般的に、他者への影響力や受賞歴など外部的な要因が成果となるようです。</p>
<h4>デザイン思考：</h4>
<p>同レポートではユーザーニーズ（共感）からビジネス上の課題（バイアス）を見つけ出し問題解決するために用いるプロトコル（手順）を指してそう呼んでるように思います。クラシカルデザインとは対象に、複数のステークホルダーとの合意形成など内部的な要因が成果となることが多いです。</p>
<h4>コンピュテーショナルデザイン：</h4>
<p>本来は設計などの知的作業をコンピューターに任せる新しいデザイン手法を指すようですが、同レポートでは利用環境や利用者数などの違いからクラシカルデザインと対比して、永遠に持続することを目的としたデザインというように捉えることができると思います。常に変わり続けて完成しないため、成長を続けていることだけが成果と言えるかもしれません。</p>
<br/>
<br/>
と、同レポートに記載されている内容を書き出してみました。
<p>それぞれのデザインの違いと、コンピュテーショナルデザインをどういう文脈で語ろうとしているかについてはご察しいただけたかと思いますが、これだけでは「コンピュテーショナルデザイン」がどういうものかまだピンと来ないですね。</p>
<p>では、どういう文脈でコンピュテーショナルデザインを語ろうとしているかという前提が共有できたものとして、今回の記事の本題に入っていきたいと思います。</p>
<hr>
<h2>デザインのScaleの関係</h2>
<p>ここから今回の記事の主張に入っていきたいと思います。</p>
<p>さきほどのスライドの図では、よく見ると3つの種類のデザインを「<strong>Scale</strong>」という横軸をとって並べています。<br>
その関係性を知ることで、コンピュテーショナルデザインをより立体的に理解出来るようになります。</p>
<p>では、「クラシカルデザイン」→「デザイン思考」→「コンピュテーショナルデザイン」のScaleの関係を整理してみましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8fcd9593-d113-418d-938e-7571482ff9d2/Untitled---New-frame--2-.jpg" alt="Untitled---New-frame--2-"></p>
<h5>→ クラシカルデザイン</h5>
<p>クラシカルデザインで重要なポイントとして「デザインをモノに定着させること」が挙げられます。<br>
デザイナー自身の意匠により見た人にとって良いと思えるような完成品に仕上げることはデザインにとって最重要と言えます。</p>
<p>まずは、クラシカルデザインのキーワードを「<strong>定着</strong>」としてみます。</p>
<h5>クラシカルデザイン → デザイン思考</h5>
<p>本来の「クラシカルデザイン」は才能ある個人による専門領域と言えますが、徐々にチームで対抗するプロセスが生まれていきます。自身の発想に依るのではなく、他者のニーズから着眼点を得る手法は今日ユーザー中心デザインなどと呼ばれています。</p>
<p>天才でなくともよいデザインが生み出せるようになり製品・サービスのコモディティ化が進むと、クラシカルデザインで言う「定着」作業の前段階においてさらに大きな視点で考えよう、という流れが出てきます。</p>
<p>そして、ユーザー中心にビジネス全体を考える「デザイン思考」が大きく注目されます。<br>
デザイン思考を広めたとされるIDEOのCEOティム・ブラウンは以下のように述べています。</p>
<blockquote>
<p>デザイナーの感性と手法を用いて、顧客価値と市場機会の創出をはかるもの</p>
</blockquote>
<p>デザイン思考は、「定着」作業を除くユーザー中心のクラシカルデザインのプロセスと同じと言えます。<br>
クラシカルデザインとの親和性はもちろん、デザイナーだけでは困難な規模の「発想」が出来るようになった点に「クラシカルデザイン→デザイン思考」のScaleの関係性をとることが出来ます。</p>
<h5>デザイン思考 → コンピュテーショナルデザイン</h5>
<p>クラシカルデザインとデザイン思考が深く結びついたことで、製品やサービスの品質は今まで以上に向上しています。</p>
<p>ただ、近年スマートフォンなどのテクノロジーが急速に発展を遂げながら個人に行き渡り、たくさんの人たちのコンテクストが実データとして得られるようになると、ユーザー中心に課題を捉えて解決策を形にするというプロトコルは、ユーザーからの情報量の増加に対してアウトプットのスピードが足りない、という事態に陥っているように捉えられるようになります。</p>
<p>そうなると、1つのモノに関わる利用者数の増加やテクノロジーの進歩に対して、ユーザーのニーズを満たす製品・サービスを提供するための考え方が必要とされるようになります。</p>
<p>そして、コンピュテーショナルデザインがそれにあたるのではないか、と同レポートからは受け取れるように思います。コンピュテーショナルデザインの核が、完成を求めず常に進化を続けることなら、別の言い方をすると、持続可能性を担保することとも表現できます。</p>
<p>それを「デザイン思考→コンピュテーショナルデザイン」のScaleにあてはめて考えると、デザイン思考で得た「発想」を「持続」して成長させ続けることができる関係が見えてきます。</p>
<br/>
<br/>
こうしてScaleの関係を整理してみると、3つの種類のデザインには密接な関わりがあり、またそれぞれのデザインへの取り組みが製品やサービスを大きく成長させるために必要だと言えることがわかりました。
<p>KARTEという自社のプロダクトに関わり、大きく成長しようとしている今、まさにこのコンピュテーショナルデザインの「持続」という考え方がぴったりとハマるように思います。そうすると、それをどのように実行していくのかが重要になってきます。</p>
<p>では、コンピュテーショナルデザインの取り組みへの第一歩として、KARTEで具体的にどのようなアプローチを進めているのかを見ていきましょう。</p>
<hr>
<h2>コンピュテーショナルデザインの第一歩</h2>
<p>「発想」を「持続」するために何から始めると良さそうか。</p>
<p>デザイン思考のScaleとしてコンピュテーショナルデザインを捉えると、製品やプロダクトのデザイン面だけの成長だけでなく、中期・長期的には組織の成長にも適用していけるように思います。</p>
<p>私個人としては、コンピュテーショナルデザインへの第一歩は将来的には組織・チームとしての持続性の醸成につなげていくためのものと考えています。</p>
<p>少しづつコンピュテーショナルデザイン的な考え方を広げていくために、個人規模で出来ることから探ってみます。<br>
まず、デザイン思考で上手く行かない部分からきっかけを見つけようと思います。</p>
<p>デザイン思考で「発想」し続けることが難しいと思われる理由に、ユーザー中心デザインの核とも言える「ペルソナ」が機能しないと思える点が多いことが挙げられます。</p>
<p>事実、KARTEのプロダクトにおいても業種や役職など多種多様で、チーム内でのブレない人物像を作り上げることは非常に困難なことです。仮に時間をかけて作成したとして、そのペルソナの行動の背後にある状況については推測が多くなるのが実際で、実データを原動力とするコンピュテーショナルデザインにおいては推測する時点ですでに不適合だと感じてしまいます。</p>
<p>ペルソナが上手く機能しづらい「事実」や「スピード」の要素を補完する他の方法はないかと検索していると、<a href="https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/">こちらの記事</a>で「<strong>Job Story</strong>」という手法の存在を知りました。</p>
<p>記事の主旨は、ペルソナを使用するユーザーストーリーの代替として、ユーザーのジョブに着目したJob Storyの利点についての説明になります。ジョブという言葉が示すように、クレイトン・Ｍ・クリステンセン氏のJTBDの考え方をベースとしているようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/550204c1-a2a9-481f-ae28-8f71e07b462e/Untitled---New-frame--1-.jpg" alt="Untitled---New-frame--1-"></p>
<p>ユーザーストーリーは、ユーザーが実現したいことやユーザーにとって価値があることを簡潔にまとめた文章のことで、アジャイル開発などでよく使われるモデリングの手法のようです。短い期間でイテレーションをまわすアジャイル開発において、ユーザーストーリーはそれ自体が機能要件として扱われることもあるようです。</p>
<p>対してジョブストーリーは、アジャイル開発におけるユーザーストーリーの機能的な側面を持ちつつ、ペルソナなどの推測部分を取り除くことで、ストーリーの因果関係をより明確にすることが出来ると説明されています。</p>
<p>両者の違いとして前者は「誰の」視点なのかにフォーカスしているのに対し、後者は「どういう時に」という状況にフォーカスを置いています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3dd5c4a9-5675-428c-9bef-b01326cd5398/Untitled---New-frame--5-.jpg" alt="Untitled---New-frame--5-"></p>
<p>具体的にどういう違いがあるかを書いて比べてみます。</p>
<p><strong>ユーザーストーリー：</strong></p>
<ol>
<li>マーケターとして</li>
<li>ユーザーの個別の行動を知りたい</li>
<li>だからKARTEを使う</li>
</ol>
<p><strong>ジョブストーリー：</strong></p>
<ol>
<li>ユーザー獲得もいよいよ天井が見えてきて、ユーザーごとの売上を伸ばすのが重要になってきた</li>
<li>ユーザーの個別の行動を知りたい</li>
<li>だからユーザーに対して個別にアクションを行え、LTVを高めやすいKARTEを使う</li>
</ol>
<p>あくまで例ですが、フォーカスを置く対象が変わることで、前提条件との因果関係がよりはっきりするように思います。また、同じような規模のサービスが似た状況にあるだろうことも事実に基づいて考えることが出来ます。KARTEで言えば、「似た状況にあるサービスの数」×「LTVを高めるためのアイデアのインパクト」から優先度の決定までスムーズに行えそうです。</p>
<p>「Job Story」であれば、事実に基づき素早く判断して製品やサービスの成長を「持続」させることが出来そうなので、まずは下記の要望・フィードバックフォームを作成するところから始めました。</p>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/65513e5f-0e46-46aa-9f92-148a3924ca2a/----------2018-08-06-22.05.32.png" width="50%">
<p>最初ということもありわりと忠実にJob Storyを再現しています。<br>
当初は本当に和訳に近い形式で制作していたのですが、チームのメンバーにレビューを受ける中で日本語との違いや、文章の理解にブレが生じやすいことがわかったので、何度か修正を繰り返してこのフォーマットにしています。</p>
<p>現在は、このフォームを手始めに、いくつかある要望やフィードバックを受け付ける際のフォーマットを同じようなものに統一していきたいと考えています。また、チーム内でもジョブの考え方が広まってきており、少しづつユーザーの状況にフォーカスする取り組みが増えてきています。</p>
<p>直近は、ユーザーからの要望やフィードバックに細かな粒度で個別に素早く対応することになると思いますが、このようなフォーマットで要望やフィードバックを積み重ねていけば、本質的な改善を事実に基づいてブレのない状態でチームとしてこなせるようになるのではないかと期待しています。</p>
<p>事実に基づいていれば情報や判断に迷いが無くなるので当然スピードも上がります。また、足し算的な修正ではなく、引き算を含めた本来の意味での改善にも根拠を持って取り組めるようになります。</p>
<p>こうして、コンピュテーショナルデザインの言う常に変わり続けることを「持続」し続ける状態を生み出し、さらにこの繰り返しがやがて本来の意味でのコンピュテーショナルデザインに合流できれば良いなと思います。</p>
<h2>終わりに</h2>
<p>というわけで、自分なりの考えでコンピュテーショナルデザインの第一歩に「Job Story」を選び、実際にトライをしてみている、というお話でした。</p>
<p>ネット上では、「ペルソナに変えてJTBDモデルにしよう」という記事もたくさん見かけまし、それがベースとなっている「Job Story」自体は非常に有効なのではないかと思っています。</p>
<p>とはいえ、今回ご紹介した要望やフィードバックの集め方は遅効性の高い取り組みで、コンピュテーショナルデザインに求められるデータ駆動のスピードを獲得するにはまだまだ時間がかかりそうに思います。まだまだ工夫が必要そうです。</p>
<p>この記事を読んで、興味を持つきっかけや何かの助けになりましたら幸いです。</p>
<hr>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体のデザインに興味がある！というデザイナーを募集しています。</p>
<p>詳しくは <a href="https://plaid.co.jp/recruit.html#designer">弊社採用ページ</a><br>
または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a></p>
<p>をご覧ください。</p>
<p>もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<hr>
<p>最後までお読みいただきありがとうございました!</p>


スケールには必要？コンピュテーショナルデザインの考え方とその取り組み

<p>はじめまして。プレイドの @tomoponzoo です。<br>
2018年4月に入社、現在プレイド暦4ヶ月目のエンジニアです。<br>
プレイドでは、今年の3月にローンチした「<a href="https://karte.io/product/app/">KARTE for App</a>」のモバイルSDK開発をメインで担当しております。</p>
<p>開発に携わって4ヶ月が経ちましたが、今でもSDKをリリースする際は緊張してしまいます。それはSDKに非常に高いレベルの品質が求められるからです。</p>
<p>今回は、SDK開発の勘所や品質の重要性、仮にSDKで問題が発生してもアプリを絶対に死なせないための方法について考えていきたいと思います。</p>
<h2>SDK開発の勘所 - 品質の重要性</h2>
<p>冒頭で述べた通り、非常に高いレベルの品質が求められるSDKですが、それはなぜでしょうか？</p>
<p>仮に低品質なSDKを組み込んだ時に起こり得ることについて、想定してみます。</p>
<ul>
<li>アプリがクラッシュするなどの問題が頻発</li>
<li>アプリクラッシュにより、エンドユーザーの体験が悪化</li>
<li>エンドユーザーの体験が悪化することにより、クライアントのビジネスに悪影響を及ぼす</li>
<li>最終的には自らのビジネスも毀損する</li>
</ul>
<p>以上のように考えると、なぜSDKに高い品質が求められるのか理解できると思います。</p>
<p>このように高いレベルの品質が求められるSDKですが、開発するためには、エンジニアの想像力や品質への拘りが重要になります。これは非常に大変ですが奥深く面白い部分でもあります。</p>
<h2>品質維持のためのアプローチ</h2>
<p>では、高い品質の維持、また万が一問題が発生したときに影響を最小限に抑えるためにどんなことができるでしょうか？</p>
<ul>
<li>問題を起こさない仕組みを整える
<ul>
<li>ソースコードレビューの実施</li>
<li>テストの自動化</li>
</ul>
</li>
<li>問題が発生したときに影響を最小限に抑える仕組みを整える
<ul>
<li>確実なエラーハンドル</li>
<li>プロセス分離</li>
</ul>
</li>
</ul>
<p>このように品質維持のためのアプローチは様々ですが、今回は表題にもあるとおり、堅牢なSDKを実現するための方法として「プロセス分離」について考えてみます。</p>
<h2>堅牢なSDKを目指す！</h2>
<p>プロセス分離 - これはアプリケーションのプロセスと、SDKのプロセスを分離することです。<br>
プロセスを分けることで、仮にSDKのプロセスがクラッシュしたとしても、アプリケーションのプロセスには影響を与えず、処理を継続することが可能になります。</p>
<p>なお本質的には、SDKがクラッシュしないように実装すべきです。<br>
ただし人間が作る以上、バグが入り込む可能性は0ではありません。もちろんバグが入り込まないように様々な対策を行うわけですが、それらをすり抜けバグが入り込む可能性は否定できません。<br>
万が一の事態におけるフェイルセーフとしてプロセス分離を活用すべきです。</p>
<p>ちなみに、iOSプラットフォームにおいてプロセス分離を行うのは至難の業です。というのも通常のアプリケーションからはプロセスを自由に生成することができません。そのため今回はその制限の中でどうやってプロセス分離を実現するか試行錯誤しながら考えていきたいと思います。</p>
<h2>マルチプロセス（プロセス分離）を実現するための手段</h2>
<p>では、マルチプロセスを実現する場合にどんな手段があるでしょうか？<br>
パッと思いつくものを列挙してみました。</p>
<ul>
<li>fork</li>
<li>App Extension</li>
</ul>
<h2>forkとは？</h2>
<p>あまりにも有名で説明は不要かと思いますが、forkはUNIXシステムにおけるシステムコールのひとつです。<br>
forkを使うことで、これを呼び出したプロセスのコピーを生成することができます。</p>
<p>iOSは、UNIX系システムのひとつであるため、forkを使うことが可能です。</p>
<h2>forkを試す</h2>
<p>では、早速forkを使ってプロセスの生成ができるか試してみたいと思います。<br>
まずXcodeで適当なプロジェクトを作成、<code>main.c</code> を以下のように修正し、シミュレーターで実行してみます。<br>
うまく行けば、子プロセスが作成されプロセス分離への道が開けます。</p>
<pre><code class="language-obj-c">int main(int argc, char * argv[]) {
  pid_t pid = fork();
  if (pid == -1) {
    NSLog(@&quot;fork() failed&quot;);
  } else if (pid) {
    NSLog(@&quot;[Parent] PID: %d, PPID: %d&quot;, getpid(), getppid());
  } else {
    NSLog(@&quot;[Child]  PID: %d, PPID: %d&quot;, getpid(), getppid());
  }
}
</code></pre>
<pre><code class="language-plaintext">2018-07-28 17:35:45.858546+0900 MultiProc[39705:13798053] [Child]  PID: 39705, PPID: 39702
2018-07-28 17:35:45.858704+0900 MultiProc[39702:13797947] [Parent] PID: 39702, PPID: 39703
</code></pre>
<p>おっ！意外にも、あっさりプロセスの生成ができてしまいました。<br>
子プロセスの親プロセスIDを確認すると、親プロセスのIDと一致しており、親子関係があることが確認できます。</p>
<p>同じことを実機を使ってやってみたいと思います。</p>
<pre><code class="language-plaintext">2018-07-28 18:17:47.617257+0900 MultiProc[4926:1877048] fork() failed
</code></pre>
<p>今度は失敗しました。<br>
iOSでは、アプリケーションの<a href="https://developer.apple.com/jp/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html">バックグラウンド実行</a>にかなりの制限があります。そのため独自にプロセスを生成して動かすこと自体不可能なのでは？と思っていましたが、やはり当初の想定通りダメなようです。</p>
<h2>App Extensionとは</h2>
<p>forkがダメだったので、もうひとつのアプローチについて考えてみます。</p>
<p>App Extensionですが、 <a href="https://developer.apple.com/jp/documentation/General/Conceptual/ExtensibilityPG/index.html">App Extensionプログラミングガイド</a>で説明されている通り。<br>
iOSアプリケーションを拡張する仕組みのひとつです。アプリケーションとは分離された別のプロセスとして動作するのが特徴です。</p>
<p>アプリケーションを拡張するために用意された仕組みであるため、通常はAppleが用意した拡張ポイントに対応するExtensionしか開発できません。<br>
今回は、プロセス分離を実現すべく非公開の拡張ポイントを利用して独自のExtensionを作ってみます。</p>
<h2>App Extensionの仕組み</h2>
<p>独自のExtensionを作る前に、Extensionの仕組みについてみておきます。</p>
<p><strong>Extensionのライフサイクル</strong><br>
通常は停止しています。<br>
アプリケーションからのリクエストに応じて起動し、処理を実行、最後に結果をレスポンスし、終了する流れになります。</p>
<p><strong>Extensionとのやりとり</strong><br>
アプリケーションとExtension間のやりとりには、XPCと呼ばれる仕組みが利用されており、シリアライズしたプロパティリストをやりとりすることでプロセス間通信が実現されています。<br>
なお実際にやりとりを行う際は、XPCをラップしたNSExtensionと呼ばれる非公開クラスを利用して、やりとりを行うことになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1704575d-34af-4e4b-a1da-d28ace594fa2/extension.png" alt="extension"></p>
<h2>App Extensionを作る</h2>
<p><strong>注意！！！<br>
App Extensionの作成過程で非公開APIを利用しています。<br>
非公開APIを利用した場合、審査でリジェクトされる可能性がありますのでご注意ください。</strong></p>
<p>では、Extensionを作っていきましょう。<br>
適当なプロジェクトを1個作成しておきます。</p>
<h4>1. App Extensionを作成</h4>
<p>任意のテンプレートを利用してExtensionを作成します。</p>
<h4>2. App Extensionの設定を修正</h4>
<p>Info.plistにExtensionの拡張ポイントや主要クラスの設定があるので、以下のように修正します。</p>
<pre><code class="language-xml">&lt;key&gt;NSExtension&lt;/key&gt;
&lt;dict&gt;
　&lt;key&gt;NSExtensionPointIdentifier&lt;/key&gt;
　&lt;string&gt;com.apple.app.non-ui-extension&lt;/string&gt;
　&lt;key&gt;NSExtensionPrincipalClass&lt;/key&gt;
　&lt;string&gt;Extension&lt;/string&gt;
&lt;/dict&gt;
</code></pre>
<h4>3. 非公開APIのインターフェースを定義</h4>
<p>NSExtensionは非公開のAPIです。<br>
利用するためには、APIに対応するヘッダーファイルを各々で用意する必要があります。</p>
<p>なお非公開APIのインターフェースを調べるには、<a href="http://stevenygard.com/projects/class-dump/">class-dump</a>などのツールを利用します。</p>
<p>今回は、以下のようなヘッダーファイルを作ります。</p>
<pre><code class="language-obj-c">@interface NSExtension : NSObject
+ (instancetype)extensionWithIdentifier:(NSString *)identifier error:(NSError **)error;

- (void)beginExtensionRequestWithInputItems:(NSArray *)inputItems completion:(void (^)(NSUUID *requestIdentifier))completion;
- (int)pidForRequestIdentifier:(NSUUID *)requestIdentifier;
- (void)cancelExtensionRequestWithIdentifier:(NSUUID *)requestIdentifier;

- (void)setRequestCancellationBlock:(void (^)(NSUUID *uuid, NSError *error))cancellationBlock;
- (void)setRequestCompletionBlock:(void (^)(NSUUID *uuid, NSArray *extensionItems))completionBlock;
- (void)setRequestInterruptionBlock:(void (^)(NSUUID *uuid))interruptionBlock;
@end
</code></pre>
<h4>4. ホストアプリケーションを実装</h4>
<p>Extensionとプロセス間通信を行うために、NSExtensionクラスのインスタンスを生成し、リクエスト処理やレスポンス処理を実装します。</p>
<p><strong>NSExtensionインスタンスの生成</strong></p>
<pre><code class="language-obj-c">NSExtension *extension = [NSExtension extensionWithIdentifier:@&quot;jp.co.plaid.MultiProc.Extension&quot; error:nil];

[extension setRequestCompletionBlock:^(NSUUID *uuid, NSArray *extensionItems) {
　　// リクエスト完了
　　NSLog(@&quot;Request completed: %@&quot;, uuid);
}];
</code></pre>
<p><strong>Extensionにリクエストする</strong></p>
<pre><code class="language-obj-c">NSExtensionItem *item = [[NSExtensionItem alloc] init];
[item setAttachments:@[@&quot;VALUE&quot;]];

[extension beginExtensionRequestWithInputItems:@[item] completion:^(NSUUID *requestIdentifier) {
　　int pid = [extension pidForRequestIdentifier:requestIdentifier];
　　NSLog(@&quot;Began extension request: %@. Extension PID: %i&quot;, requestIdentifier, pid);
}];
</code></pre>
<h4>5. Extensionを実装</h4>
<p>ヘッダーファイルを修正します。<br>
Extensionクラスが<a href="https://developer.apple.com/documentation/foundation/nsextensionrequesthandling?language=objc">NSExtensionRequestHandling</a>プロトコルに適合することを宣言します。</p>
<pre><code class="language-obj-c">@interface Extension : NSObject &lt;NSExtensionRequestHandling&gt;
@end
</code></pre>
<p>実装ファイルを修正し、NSExtensionRequestHandlingプロトコルに適合させます。</p>
<pre><code class="language-obj-c">@implementation Extension
- (void)beginRequestWithExtensionContext:(NSExtensionContext *)context {
　　// レスポンスを返す
　　[context completeRequestReturningItems:@[] completionHandler:^(BOOL expired) {
　　　　NSLog(@&quot;Completed request.&quot;);
　　}];
}
@end
</code></pre>
<h2>App Extensionを動かしてみる</h2>
<p>ここまでできたらシミュレーターで実行してみます。<br>
以下のようなログが出ればOKです。<br>
ホストアプリケーションのプロセスIDが74665、ExtensionのプロセスIDが74671となっており、それぞれ別のプロセスで動作していることが確認できます。</p>
<pre><code class="language-plaintext">2018-07-29 22:19:03.749751+0900 MultiProc[74665:14952372] App PID: 74665
2018-07-29 22:19:12.725051+0900 MultiProc[74665:14952478] Began extension request: 34E68F5B-520A-48EC-93EE-03599A310B24. Extension PID: 74671
2018-07-29 22:19:12.730459+0900 MultiProc[74665:14952478] Received response.
</code></pre>
<h2>App Extensionをクラッシュさせてみる</h2>
<p>さて、ここまで色々試してきましたが、ここで当初の目的である「SDKがクラッシュしても、アプリが絶対に死なない！」ことを確認してみたいと思います。</p>
<p>以下のように、Extensionをクラッシュさせるためのコードを入れて実行してみます。</p>
<pre><code class="language-obj-c">NSExtensionItem *inputItem = context.inputItems[1];
</code></pre>
<p>Extensionでは、NSRangeExceptionが発生しクラッシュしますが、アプリケーションは影響を受けず何事もなかったかのように動作しています。</p>
<h2>まとめ</h2>
<p>今回は「プロセス分離」という手段を用いて、堅牢なSDKを実現する方法とその可能性について探ってみました。</p>
<p>現状はプラットフォームとしての制約が大きく、また非公開APIを利用しないと実現できないなど、実際にプロダクトに適用するのは難しいということが分かりました。<br>
アプリケーションからプロセス生成できない理由として、端末の性能やリソース制約の問題が大きいと考えています。将来端末のリソース制約について考えなくて良くなった時には、このような手段も現実味を帯びてくるのではないかと思いました。</p>
<p>なお今回作成したアプリのソースコードは<a href="https://github.com/tomoponzoo/MultiProc">GitHub</a>で公開していますので、動作や実装が気になる方は、ぜひダウンロードして動かしてみてもらえればと思います。</p>
<h2>最後に</h2>
<p>CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、品質にこだわりたい！想像力をフルに発揮したい！モバイルエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


はじめまして。プレイドの @tomoponzoo です。
今回は、SDK開発の勘所や品質の重要性、仮にSDKで問題が発生してもアプリを絶対に死なせないための方法について考えていきたいと思います。

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法 | PLAID engineer blog

絶対にアプリを死なせない！プロセス分離による堅牢なSDKの実現方法

<p>こんにちは！SREの@ikemonnです。</p>
<p>7/24-26@San Franciscoで行われた<a href="https://cloud.withgoogle.com/next18/sf/">Google Cloud Next '18</a>に参加してきました。</p>
<p>いくつかのセッションを聞いてきたのですが、今回はKARTEのデプロイでも利用している<a href="https://www.spinnaker.io/">Spinnaker</a>のセッション、<a href="https://cloud.withgoogle.com/next18/sf/sessions/session/155951">Large-Scale Continuous Delivery at Netflix and Waze Using Spinnaker (Cloud Next '18)</a> が面白かったのでご紹介します。</p>
<h2>概要</h2>
<ul>
<li>WazeでのSpinnakerの使い方</li>
<li>Googleがリソースを割いてなぜSpinnakerを開発しているのか</li>
<li>Spinnakerのroadmap</li>
<li>まとめ</li>
</ul>
<h3>WazeでのSpinnakerの使い方</h3>
<p>Wazeはmulti-cloud(AWS/GCP)でインフラを構成しています。<br>
サービスが成長するにつれ、サーバが何千台にも増えていき次第にデプロイが大変になっていったそうです。<br>
SREチームがデプロイにかかりっきりになり、batchやbug fixのデプロイやrollbackも気軽にできなくなってきた時にSpinnakerを見つけました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ed5fc9f2-abc7-49e9-ab79-ccb5401b4702/-2018-07-30-9.00.51.png" alt="-2018-07-30-9.00.51"></p>
<p>OSS, multi-cloud対応したツールであることからSpinnakerの導入を決定しました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f513304d-4466-43c9-90c7-1481025c8f7a/-2018-07-30-7.31.36.png" alt="-2018-07-30-7.31.36"></p>
<p>Spinnakerを導入することで下記のメリットがあったそうです。</p>
<ul>
<li>SREチームにデプロイを頼まなくて良くなった</li>
<li>rollbackやデプロイを部分的に行えるので改善サイクルが早くなった</li>
<li>VM, k8s, AppEngine等を意識せずに統合的なインターフェースでデプロイできるようになった</li>
</ul>
<p>しかし、しばらくするとpipeline数が増えすぎて(1000以上!)、UIからの管理が大変になってきました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9d1e8c69-5711-4835-88fb-9aa3dabf4ace/-2018-07-30-7.37.25.png" alt="-2018-07-30-7.37.25"></p>
<p>pipeline自体は個々で大きく異なっているわけではなく、ちょっとした差分があるだけだったのでtemplateを作り、そこからpipelineを作るようにしたそうです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3c6a3b4-598a-4be0-acd0-d4d7231ded33/-2018-07-30-7.41.57.png" alt="-2018-07-30-7.41.57"></p>
<p>まず、<code>bake -&gt; smoke test -&gt; deploy</code> というpipelineのtemplateを作ることからはじめました。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8621dbdf-3479-4810-94bb-7534e12a9fb2/-2018-07-30-7.44.26.png" alt="-2018-07-30-7.44.26"></p>
<p>v1ではまだリスクがあったので、canaryステージを追加し、  <code>bake -&gt; smoke test -&gt; canary -&gt; deploy</code> を作ったりと徐々にpipelineを改善していったそうです。</p>
<p>pipelineをテンプレート化していることにより、1000以上pipelineがあっても変更をすぐに反映できて良かったとおっしゃっていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/81534a64-c683-46d5-8f62-69bcc84f5407/-2018-07-30-7.48.13.png" alt="-2018-07-30-7.48.13"></p>
<p>Wazeではデプロイ以外にもCassandraのデプロイにもSpinnakerを使っているそうです。</p>
<p>今後Wazeでは、SLO/error budget等のSREのコンセプトを考慮した、下記のようなデプロイを行う予定と言っていました。</p>
<ul>
<li>error budgetを超えそうになると自動的にカナリアデプロイの検証時間を長くする</li>
<li>普段は自動でデプロイされるけど、デプロイしてよいかを手動で決定しなければならないようにする</li>
</ul>
<h3>Googleがリソースを割いてなぜSpinnakerを開発しているのか</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f4def9fc-5743-4ef9-9d35-5d2ba7e8e826/-2018-07-30-8.08.05.png" alt="-2018-07-30-8.08.05"></p>
<p>GoogleもSpinnakerの開発にリソースを割いているようで、去年に比べて現在では2倍の人員がいるようです。<br>
Full timeの開発者が13人、PM/TPM/EngMgrが各1人と、かなりリソースを割いているようでした。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/da003478-dd55-4ec3-9cd1-49343ae49df5/-2018-07-30-8.11.36.png" alt="-2018-07-30-8.11.36"></p>
<p>GoogleがSpinnaker開発に力を入れているのは、下記のような理由だそうです。</p>
<ul>
<li>Spinnakerで実現できることが社内のbest practice にマッチしている</li>
<li>デプロイ、ロールバック等が抽象化されているので、multi-cloudなインフラでもそれぞれのcloudの詳細な知識なしにデプロイできる</li>
</ul>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a30cb370-993a-44c2-93a1-2859c30eed48/-2018-07-30-8.19.16.png" alt="-2018-07-30-8.19.16"></p>
<p>Googleとして早い段階からSpinnakerの開発に関わっており、 2014年に20%プロジェクトとして、とあるエンジニアがSpinnakerに関わりだしたのが始まりだそうです。<br>
そして、GCE, GKE, AppEngine等の機能を追加していったと言っていました。</p>
<h3>Spinnakerのroadmap</h3>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/faf1c7da-b7ea-471f-b35d-39f5d093bf5b/-2018-07-30-8.29.56.png" alt="-2018-07-30-8.29.56"></p>
<p>上記がSpinnakerのroadmapです。<br>
個人的に最も気になったのが Configuration as Codeについてでした。<br>
デプロイ内容について宣言的なconfigを書いて、Codeとして管理できるようにしていくとのことです。<br>
KARTEでは <a href="https://github.com/spinnaker/dcd-spec">spinnaker/dcd-spec</a> を使ってpipelineを管理しているので、dcd-specとの違いを後で質問しにいきました。<br>
「dcd-specをより良くしたものをCLI経由で反映できるようにするよ」と教えてもらったのですが、まだ開発中なのか、具体的にどのようなものかは教えてもらえませんでした。<br>
<a href="https://docs.google.com/document/d/17Ifm562aypjLSHnNJ02COFv_VMv3spicH-7zMYd-oXE/edit#">Spinnaker CLI Design Doc</a>を見ると、<a href="https://github.com/spinnaker/spin">spinnaker/spin</a> が上記のCLIのようです。</p>
<p>Spinnakerに関する情報についてはこちら<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a1d3c567-4e16-4810-a5f8-a95fc1591345/-2018-07-30-8.35.43-1.png" alt="-2018-07-30-8.35.43-1"></p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/PLNheBiWOGI" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<h3>まとめ</h3>
<p>Wazeのような大規模マルチクラウドインフラを運用している会社でもSpinnakerを使っていること、Googleも開発にリソースを割いていることから、Spinnakerを今後も継続して利用しておけばしばらく安心だと思いました。<br>
他のセッションでもSpinnaker活用事例がいくつか発表されていたので、良いデプロイツールを探している方は一度触ってみると良いと思います。<br>
KARTEへのSpinnaker導入時にバグを見つけ、PRを出したのですが、それをマージしてくれた <a href="https://github.com/duftler">Matt Duftler</a>に直接質問できたのが個人的に良かったです。</p>
<h2>最後に</h2>
<p>2018/8/3(金)に開催予定の<a href="https://plaidtech.connpass.com/event/92694/">プレイドオフィス移転パーティー ※エンジニア&amp;デザイナー向け</a>でもGCP Nextについて話す予定なので、お時間が空いている方はぜひぜひご参加ください！</p>
<p>また、KARTEでのSpinnakerの使い方は、2018/9/8(土)に行われるbuildersconのセッション:<a href="https://builderscon.io/tokyo/2018/session/e3b9f6e2-7fc8-44fa-bb4f-238144e5cd1b">Multicloud deploy with Spinnaker</a>で発表する予定なので、ご興味のある方はお越しください！</p>
<p>CXプラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、尖ったサービス/ツールを使いつつ大規模分散システムの構築/運用をしたいエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a><br>
または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a><br>
をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


こんにちは！ SREの@ikemonnです。 7/24-26@San Franciscoで行われたGoogle Cloud Next '18に参加してきました。 いくつかのセッションを聞いてきたのですが、KARTEのデプロイで利用しているSpinnakerのセッションが面白かったのでご紹介します。

Google Cloud Next '18でSpinnakerのセッションを聞いてきました! | PLAID engineer blog

Google Cloud Next '18でSpinnakerのセッションを聞いてきました!

「イマドキのDocker力」を0から身につけるための一連のチュートリアルを紹介します。PLAID社内のKARTE開発環境のDocker化に伴い、扱い方を実践的に身につけるための教材として作成されました。

イマドキの「Docker力」を身につけるPLAID式チュートリアル | PLAID engineer blog

イマドキの「Docker力」を身につけるPLAID式チュートリアル

<p>こんにちは、プレイドの @nashibao です。今回は少し前に話題になった <a href="https://metaparticle.io/tutorials/javascript/">Metaparticle</a> というプロジェクトについて紹介します。</p>
<p><code>Metaparticle</code>は <code>a standard library for cloud native applications on Kubernetes.</code>と唄っていますが、要はjava/javascript/goなどのapplication code上にdocker/k8sのInfrastructure/Orchestrationのうち、Applicationとして関心がある部分は組み込んでしまおう、というプロジェクトです。</p>
<p>多機能のサービスを開発していると、様々なところで有限のベストプラクティス（ただし単一では無い）に沿ったDistributed Programmingをして堅牢性や冗長性を高めたり負荷分散をしたくなります。</p>
<p>ただ、これらを実現したいと考えて設計/実装をするのは多くはApplicationエンジニアですが、Infrastructure/Orchestrationの様々なツールがその間に横たわっていて機動性が失われてしまいます。</p>
<h1>CloudのThread/ProcessとしてのContainer</h1>
<p>Threadは扱いやすいです。パフォーマンス等を考えて様々なパターンを駆使して劇的にApplicationのパフォーマンスを上げることができます。</p>
<p>Processは？そこまで隔たりはありません。プレイドで好んで使っているNode.jsでいえば <a href="https://nodejs.org/api/cluster.html">Cluster</a> moduleを使うだけです。</p>
<pre><code>const cluster = require('cluster');
if (cluster.isMaster) {
  // master
  cluster.fork();
} else {
  // worker
}
</code></pre>
<p>ThreadもProcessもどちらもworkerへの分散には色々なパターンがあって、それらを使うと並列性が高いプログラムを容易にかけます。iOSの<code>NSOperationQueue</code>などその代表ですが、各言語に様々なパターンがあります。そしてこれはApplicationエンジニアの手元にあって自由に設計できます。</p>
<p>Containerは？yamlの世界、kubectlの世界です。Applicationエンジニアの手元にあるように見えて遠くに行きがちです。PortとVolumeがコントロールされていて、古き良きPubsub/Queueやmessaging用の各ツール（zeromqは好きだ）を使って自由に協調はできますが、言語が異なる他のPlatformというものが邪魔をします。</p>
<h1>Language idiomatic cloud</h1>
<p>分散性をある程度ラップしつつ、コントローラブルにするアプローチは昔からあって、例えば <code>MapReduce</code> があります。<code>Metaparticle</code>と目的は似ているがPipeline状のData処理に特化している所が異なります。<code>PySpark</code>を使うとlambda関数を単にローカルで動かしているのと同じように見えます。<code>Google Dataflow</code>や<code>Apatch Beam</code>もまま似てる。</p>
<p>Microservice流行りで、<a href="https://aws.amazon.com/jp/lambda/">AWS Lambda</a>や <a href="https://cloud.google.com/functions/">Cloud Functions</a> のような便利なツールが出てきてるので <a href="https://github.com/pywren/pywren">pywren</a>のように、それらをwrapしちゃえば良くね？みたいなアプローチもあります。</p>
<pre><code class="language-python">  def my_function(b):
    x = np.random.normal(0, b, 1024)
    A = np.random.normal(0, b, (1024, 1024))
    return np.dot(A, x)

  pwex = pywren.default_executor()
  res = pwex.map(my_function, np.linspace(0.1, 100, 1000))
</code></pre>
<p>サイトに書いてあるコードそのままだけれど、中が同一スレッドだろうが、別プロセスだろうがAWS Lambdaだろうが同じようなマナーで書けます。</p>
<h1>Metaparticle</h1>
<p><code>Spark</code>や<code>pywren</code>はかなり抽象化されていて、やれることも制限されますが（その代わりパフォーマンスに焦点がある）、<code>Metaparticle</code>はもう少し自由度に焦点があります。つまりdocker/k8sのconfigへcompileするためのメタ言語のようなものです。</p>
<pre><code>const mp = require('@metaparticle/package');

mp.containerize(
	{
        	ports: [8080],
        	replicas: 4,
		    runner: 'metaparticle',
		    repository: 'docker.io/docker-user-goes-here',
		    publish: true,
		    public: true
	},
	() =&gt; {
		// closure for each workers
	}
);

</code></pre>
<p>これだけです。これを素で使っても良いけれど、先ほどいった有限のパターンについては <code>standard library</code>なので当然提供する。sharingなら</p>
<pre><code>const http = require('http');
const os = require('os');
const mp = require('@metaparticle/package');

const port = 8080;

const server = http.createServer((request, response) =&gt; {
	console.log(request.url);
	response.end(`Hello World: hostname: ${os.hostname()}\n`);
});

mp.containerize(
	{
		ports: [8080],
		shardSpec: {
			shards: 3,
			&quot;urlPattern&quot;: &quot;\\/users\\/(.*)[^\\/]&quot;
		},
                repository: 'docker.io/your-docker-user-goes-here',
                publish: true,
                public: true,
		runner: 'metaparticle',
	},
	() =&gt; {
		server.listen(port, (err) =&gt; {
			if (err) {
				return console.log('server startup error: ', err);
			}
			console.log(`server up on ${port}`);
		});
	}
);
</code></pre>
<p>だし、electionなら</p>
<pre><code>var mp = require('@metaparticle/sync');

var election = new mp.Election(
    // Name of the election shard
    'test',
    // Event handler, called when a program becomes the leader.
    () =&gt; {
        console.log('I am the leader');
    },
    // Event handler, called when a program that was leader is no longer leader.
    () =&gt; {
        console.log('I lost the leader');
    });

election.run();
</code></pre>
<p>という感じです。上に書いたように、ここは有限のパターンがそれなりにあるので、それらが今後作られていくのだろうと思うが今の所ほぼ上の二つくらいしか書かれてないw</p>
<h1>感想</h1>
<p>thread/processとのアナロジーなどからContainerが扱いやすくなることについて書きましたが、<code>metaparticle</code>自体はdynamicにcluster/podを変更するわけではありません。scriptでdynamicに変更できるようになると、より上記のアナロジーがハマり、k8sに乗っかったままかなり柔軟に分散プログラムが書けると思ったりします。<br>
プレイドでも下手にクラスタ管理や組込済みの単純なオートスケールを使うより、nodeのgcp/api経由でインスタンス数の増減をさせるやり方をやってみたりしつつ、なんか違うな、と思ったりしていますw</p>
<p>今回は<code>a standard library for cloud native applications on Kubernetes.</code>な<code>Metaparticle</code>を紹介しました。個人的にはこのアプローチの先にDistributed Programmingの桃源郷があるのかもしれないし無いかもしれないと思っています。</p>
<p>CXプラットフォーム「<a href="karte.io">KARTE</a>」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">こちら</a>（Wantedly）をご覧ください。</p>


こんにちは、プレイドの @nashibao です。今回は少し前に話題になった [Metaparticle](https://metaparticle.io/tutorials/javascript/) というプロジェクトについて紹介

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ | PLAID engineer blog

Kubernetes to Metaparticle. 分散プログラミングへの新しいアプローチ

Engineer Blog

Recent Article