Engineer Blog

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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


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

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

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


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

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

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


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

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

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

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

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


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

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

<p>デザインエンジニアの安田（<a href="https://x.com/_yuheiy">@_yuheiy</a>）です。</p>
<p>プレイドの多くのシステムでは、サーバーサイドの実行環境としてNode.jsを採用しています。そのため、サーバーサイドもクライアントサイドもまとめてnpmを使って依存パッケージ（dependencies）を管理している場合がほとんどです。</p>
<p>システムのメンテナンスにおいては、このような依存パッケージのバージョンを継続的にアップデートし続けることが重要です。そこで今回は、社内向けに実施した、依存パッケージのバージョンアップをテーマにした発表を一部再編集してご紹介します。</p>
<h2>なぜ依存パッケージのアップデートが必要か</h2>
<p>筆者が所属するDeveloper Experience &amp; Performanceチーム（通称: DXチーム）では、その活動の一つとして、さまざまなシステムの依存パッケージのバージョンをアップデートして回るような作業をする機会がよくあります。DXチームでは、現在アクティブに開発が行われていない一部システムのメンテナンスを担当したり、既存のチームの開発をヘルプしたりする場面があり、その一環として併せてこのような作業を行っています。</p>
<p>依存パッケージをアップデートすることには、おもに次のような理由があります。</p>
<p>まず最初は、Node.jsのバージョンアップに対応するためです。Node.jsのバージョンアップにともなって古いバージョンの依存パッケージが動作しなくなることがあるので、Node.jsに追従するために必要な作業です。</p>
<p>次は、一般的なソフトウェア品質や開発効率の向上のためです。多くのパッケージはバージョンアップにともなって、動作上のバグの修正やパフォーマンスの改善、セキュリティ上の問題の解決が行われているほか、便利な新機能が追加されたりしています。これによってソフトウェアの外部品質が改善したり、余計な実装が不要になって設計がシンプルになったりする可能性があります。また、古いバージョンのパッケージを使い続けていることで、それに携わる開発者が古いバージョンの使い方を調べたり覚えたりといった無駄な学習コストを払わなければならないという問題もあります。</p>
<h2>デザインシステムの最新化のために</h2>
<p>もう一つの理由は、利用されているデザインシステムを最新化するためです。社内向けのデザインシステムであるSourが多くのシステムに導入されていますが、Sour自体の内容は日々アップデートされ続けている一方、各システムで利用されているSourのバージョンはアップデートされずに古いものが使い続けられていることが少なくありません。</p>
<p>参考までに、<a href="https://karte.io/">KARTE</a>のリポジトリにおいて使用されているSourのバージョンは次の通りです（件数は発表時のもの）。</p>
<ul>
<li>4.x: 5件（うち3件はDXチームが管理するシステム）</li>
<li>3.x: 5件</li>
<li>2.x: 11件</li>
<li>1.x: 2件</li>
<li>0.x: 1件</li>
</ul>
<p>筆者の本務はSourの開発ですが、ユーザー側でのバージョンアップが行われなければ開発している意味がありません。そのため私自身がそのアップデート作業を担当することもありますが、それに併せてその周辺環境を整備しなければならない場面もあります。というのも、Sour自身が依存しているパッケージのアップデートにともなって、ユーザー側の関連するライブラリのアップデートをしなければならなくなったり、もしくは、そのようなアップデートにともなう問題が発生しないかをテストするための環境が必要になったりすることもあるからです。</p>
<h2>タイミングが遅れるほどアップデート作業が難しくなる</h2>
<p>一般的に、依存パッケージが古くなればなるほど対処が必要な問題が増えて複雑化し、作業が難しくなる傾向にあります。特に古いシステムをメンテナンスしていると、複数の古い依存パッケージ同士が絡み合う問題が発生してデバッグが難しくなったり、古いバージョンで想定されていなかった環境依存の問題が発生して解決のために余計な手間を取られたりすることがよくあります。</p>
<p>また、関連する機能を担当した当時の開発者がチームや会社を離れたりしていることもあります。アップデートにともなう動作確認が必要になることがありますが、そのような場合、期待される正しい仕様や動作確認の方法がわからなくなる可能性もあります。あるいは、当時の担当者にしか意図を理解できないトリッキーな実装が行われているような場合もあります。</p>
<h2>「システムのメンテナンスは天下の回りもの」</h2>
<p>これは昔から個人的に唱えている理論です。システム開発の仕事をしていると、知らない誰かが作ったシステムを回り回って自分が引き継ぐというような場面は珍しくありません。そして、自分が作ったシステムもいずれまた別の誰かに引き継がれていくことになります。</p>
<p>システムの出来の良し悪しにかかわらず、引き継いだ人にはそのすべてを引き受ける責任が生じます。だからこそ、後任の誰かのために、自分が今担当しているシステムはできるだけ良い状態にしておくという心づもりでいることが大事だと思います。</p>
<h2>作業の進め方</h2>
<p>具体的な話に移ります。</p>
<p>まず、これから説明するような作業にあたっては、さまざまな観点でのソースコードの変更をしなければならない場合があります。そのため、必ずしも1つのpull requestで一気に対応しようとするのではなく、適切な粒度に分解しながら作業を進めてください。これについては普段の機能開発と同じです。</p>
<p>次に、CIが不十分だと感じる場合はあらかじめ整備しておくのがよいです。作業を細かく分割するほど、人力ではチェックの抜け漏れが発生しがちです。変更にともなうテストを効率的に行うために、できるかぎり自動化してしまいましょう。</p>
<h3>不要な依存パッケージを削除する</h3>
<p>アップデートの前に、不要な依存パッケージがあればあらかじめ削除しておきます。使わないものをアップデートしても仕方がないからです。</p>
<p><a href="https://knip.dev/">Knip</a>を導入することで、未使用の依存パッケージやデッドコードの検出ができます。これらを削除することで余計な要素を削れます。さらに、KnipをCIに組み込むことで、今後余計なものが追加されないように予防することもできます。</p>
<p>また、そのほかにも不要な機能などが残っていれば削除しておきます。</p>
<h3>言語の標準機能に置き換える</h3>
<p>Node.jsのアップデートにともなって、これまでサードパーティのパッケージが必要だったことが、Node.jsのコアの機能として実現できるようになっていることがあります。「<a href="https://zenn.dev/morinokami/articles/npm-uninstall">Node.js の進化に伴い不要となったかもしれないパッケージたち</a>」などを参考にして置き換えてください。</p>
<p>また、ECMAScriptやDOM仕様のアップデートにともなって、同じくサードパーティのパッケージが不要になることもあります。「<a href="https://github.com/you-dont-need/You-Dont-Need">You-Dont-Need</a>」などが参考になります。</p>
<p>依存パッケージを減らしてコアの機能に置き換えていくことで、将来的なメンテナンスコストを削減できることになります。</p>
<h3>package.jsonのアップデート</h3>
<p><code>package.json</code>に記述されている<code>dependencies</code>や<code>devDependencies</code>のバージョンをアップデートする際には、次のようなコマンドを使用すると一気に書き換えができて便利です。<code>--interactive</code>オプションを指定することで、アップデートする対象をチェックボックス方式で選択できます。</p>
<p>npmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
npx npm-check-updates --workspaces --root --interactive
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/9266d5fd-ceff-47f0-a94e-7d78bcfe707e/ncu.png" alt="新しいバージョンが存在するdependenciesのうち、必要なものを選択式でアップデートできる。パッケージごとに現在のバージョンとアップデート後のバーションが表示される。"></p>
<p>出典: <a href="https://github.com/raineorshine/npm-check-updates">raineorshine/npm-check-updates: Find newer versions of package dependencies than what your package.json allows</a></p>
<p>pnpmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
pnpm update --latest --recursive --interactive
</code></pre>
<p>pnpm 10.12以降であれば、catalogsで管理しているバージョンもいっしょにアップデートできます。</p>
<p>またロックファイルは壊れやすいので、インストールに際して問題が発生した場合は再生成してみるとよいです。</p>
<pre><code class="language-bash">rm -rf package-lock.json **/node_modules &amp;&amp; npm install
</code></pre>
<h3>破壊的変更への対応</h3>
<p>セマンティックバージョニングにおいては、メジャーバージョンが上がるか、もしくは1.0.0に満たない場合のバージョンアップでは、常に破壊的変更の可能性があります。そのためアップデートをする前には、ざっとでもいいのでパッケージのCHANGELOGに目を通しておくことをおすすめします。</p>
<p>また、最新版よりもいくつも古いバージョンを使っている場合は、破壊的変更が積み重なって簡単にアップデートできないことがあります。そのような場合、バージョンは一気に上げるのではなく、ある程度の区切りに分けて段階的にアップデートしたほうが作業が簡単になります。</p>
<h3>後継のライブラリに置き換える</h3>
<p>場合によっては、あるパッケージの代わりとなる後継のパッケージ（ライブラリ）が登場しているがあります。既存のパッケージがメンテナンスされなくなったり、アーキテクチャが古くなって根本的な刷新が必要になったりしたときに、それを置き換えるために別のものが開発されて、コミュニティでもそちらが主流になっていくというパターンです。</p>
<p>KARTEでよく使われているところで言えば、次のような後継のパッケージがあります。</p>
<ul>
<li>Jade → <a href="https://pugjs.org/api/getting-started.html">Pug</a>（参考: <a href="https://github.com/pugjs/pug/issues/2184">Renaming jade -&gt; pug · Issue #2184 · pugjs/pug</a>）</li>
<li><a href="https://github.com/TypeStrong/ts-node">ts-node</a> → <a href="https://tsx.is/">tsx</a>（もしくは、<a href="https://nodejs.org/api/typescript.html#type-stripping">Node.jsのtype stripping</a>を使う）</li>
<li><a href="https://jestjs.io/">Jest</a> → <a href="https://vitest.dev/">Vitest</a></li>
<li><a href="https://recoiljs.org/">Recoil</a> → <a href="https://jotai.org/">Jotai</a></li>
<li><a href="https://lodash.com/">Lodash</a> → <a href="https://es-toolkit.dev/">es-toolkit</a></li>
<li><a href="https://github.com/raineorshine/npm-check-updates">npm-check-update</a> + <a href="https://github.com/ds300/patch-package">patch-package</a> + <a href="https://github.com/open-cli-tools/concurrently">concurrently</a> → <a href="https://pnpm.io/">pnpm</a> CLI（同等の機能がpnpmに組み込まれている）</li>
</ul>
<p>既存パッケージのアップデートと併せて、後継のパッケージへの移行も行いましょう。</p>
<h3>気になる部分はついでに改善しながら進める</h3>
<p>パッケージのアップデート作業をしていると、それに関係するほかの部分が気になることもあります。気になった部分についても、そのままにしておかず、せっかくなのでついでに改善してしまうのがよいです。たとえば次のようなものです。</p>
<ul>
<li>CIの構成をきれいにする</li>
<li>いらないnpm scriptsを消す</li>
<li>冗長な設定ファイルをクリーンアップする</li>
<li>deprecatedなメソッドの使用箇所を直す</li>
<li>破壊的変更がある箇所の周辺のコードをリファクタリングする</li>
</ul>
<p>このようなメンテナンス作業は普段は軽視されがちで、ともすれば老朽化した仕組みがそのまま何年も動き続けていることになりがちです。だからこそ、みなさんにはぜひ<a href="https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html">ボーイスカウト・ルール</a>を意識してもらいたいです。</p>
<blockquote>
<p>ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです（このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています）。</p>
<p>これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュールを改善する努力を続けたとしたら、その結果どういうことが起きると思いますか?</p>
</blockquote>
<p>出典: Kevlin Henney編、和田卓人監修『プログラマが知るべき97のこと』、オライリージャパン、2010年</p>
<h2>こまめなアップデートを習慣化する</h2>
<p>アップデート作業は後回しにするほど面倒な問題を引き起こしがちです。善は急げと思って、まずは今日からやってみましょう。</p>
<p>いったんひと通りのアップデートができたら、それ以降も定期的にアップデートを続けられるように、次に作業する日を決めてしまいましょう。月に1回程度が目安です。もしくは、<a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot">Dependabot</a>などの自動化ツールを使って作業を自動化するのもよいと思います。</p>


Node.jsやフロントエンドのプロジェクトにおけるdependenciesをアップデートするうえでのよくある問題やうまく進めるためのコツなど。

package.jsonのdependenciesをアップデートする技術

<p>こんにちは。プレイドの@sdaikichiです。現在のトレーナーレベルは28、捕まえたポケモンは183種です。</p>
<p>突然ですが、皆さん、お酒は好きですよね？僕も大好きです。</p>
<p>最近はビールが美味しい季節になってきました。</p>
<p>さて、エンジニアには半ば都市伝説のような通説があるのをご存知でしょうか。</p>
<p><a href="http://isononami.blogspot.jp/2013/01/ballmer-peak.html">バルマーピーク</a>です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/53f62989-6978-49d9-8cf1-f9d443480f7f/ballmer_peak-1.png" alt="ballmerpeak"></p>
<p>この説は、「血中アルコール濃度が0.129~0.138%のときに超人的なプログラミング能力を発揮できる」というものです。（このマンガだとWindows MEを引き合いに出してディスられていますが）</p>
<p>エンジニア同士の飲み会では一度は話の種になったことがあるのではないでしょうか。</p>
<p>バルマーピーク、もし本当だったらアツくないすか？</p>
<p>このグラフ（と呼んでいいかわかりませんが）では、ピーク時には平常時の倍ほどのプログラミング能力になると書かれています。</p>
<p>生産性の追求はエンジニアの至上命題です。「お酒を飲みながら仕事なんて！」という固定概念を取り払い、試せるものは試すのがエンジニアとしての矜持ではないでしょうか。</p>
<p>日本の労働生産性は先進国で最低と言われています。さらにIT分野では諸外国に遅れを取っていると言わざるを得ません。<br>
もしバルマーピークの有用性が認められれば、日本のエンジニア達は酒を片手に以前とは比較にならない速度でアウトプットを出し続けることでしょう。ということは、ITはいまや日本の主要産業ですから、国内の生産性も一気に上昇します。ひいては日本のGDP増加、世界でのプレゼンスを再び得ることができるに違いありません。<strong>絶対成功させよう東京オリンピック！！</strong></p>
<p>さて、始めましょう。</p>
<h1>ルール</h1>
<h2>プログラミング能力の計測</h2>
<p>生産性を比べるという点からすると弊社プロダクトのコードを使うのが一番ですが、酒を飲みながらプロダクションにコミットしていることが露見するとワンチャン解雇まであるので、ここは控えます。</p>
<p>「コーディング能力とは何か」を考え出すとキリがないため、いったんここは粒度の自由さとコーディング能力の客観的指標を兼ね備えている、<a href="https://paiza.jp/">paiza</a>を使って結果を比べてみることにします。</p>
<p>時間を計測してくれたり、テストケースによる採点も行ってくれるため、飲酒時・素面時の客観的比較が可能です。<br>
paizaスキルチェックのレベルですが、B~Cあたりの難易度で比較するのが普段の業務に近そうなので、ここを使います。<br>
A以上になると数学的な設計能力も問われ、酔っ払った状態では明らかに不利そうなので、今回は避けます。普通に難しくて心が折れたというのもある。</p>
<h2>濃度の計測</h2>
<p>血中アルコール濃度が基準なので常に血液を取って測定できると良いのですが、さすがに機材が用意できないので、<a href="http://amzn.asia/1X3MO4L">呼気で計測するもの</a>を利用します。<br>
（余談ですが本当は国内メーカーのものを使いたかったのですが、おそらく車の運転可否の判定に主眼を置いているのか、濃度の測定範囲が今回のピークより低かったため、この製品を利用します。）</p>
<p>説によると、血中アルコール濃度0.129~0.138%、呼気中アルコール濃度に換算すると0.64~0.69mg/Lがピークとなります。お酒を飲み続け、この範囲までアルコール濃度が上がったのを確認してから、paizaの問題に取り掛かることにします。</p>
<h2>濃度の維持</h2>
<p>生産性が上がるのはかなり狭い範囲なので、アルコール濃度を維持する必要があります。<br>
自分の体重だとアルコール分解の速さは1時間あたり(血中濃度の低下が)およそ 0.012% なので、維持するためにはビールだったら60分で200mlのペースで飲み続けながらコーディングしていきます。ちびちびと言った感じですね。</p>
<h1>検証開始</h1>
<p>まずはアルコール濃度をピーク範囲まで上げる必要があります。</p>
<img width="300px" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/283f8ef4-2396-4319-a748-d969f7f6292a/IMG_2600-1.JPG.jpg"/>
<p>近くの居酒屋さんからテイクアウトしてきたもつ煮込みと焼鳥でおっぱじめます。</p>
<h2>20分後</h2>
<p>そろそろ濃度を計測してみましょう。</p>
<img width="300px" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0e5bf0da-a6da-407f-bc4f-a8c379d827da/IMG_0737-1.JPG.jpg"/>
<p>ピークの濃度をオーバーしてしまいました。<br>
お酒を飲まずにアルコール濃度が下がるのを待ちます。20分ほどマンガでも読んでましょう。</p>
<h2>さらに20分後</h2>
<p>富田流のそれは左鉤突きから始まる、それとは即ちーーー<strong>ピピピッ</strong><br>
おっと、タイマーが鳴りました。濃度を計測しましょう。</p>
<p>&lt;0.23%&gt;(写真撮るのを忘れてしまいました・・・)</p>
<p>今度は下がりすぎてしまいました。<br>
再度ビールで濃度を上げていきます。</p>
<h2>そのまたさらに20分後</h2>
<img width="300px" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/caf144fb-2908-4a2b-82e3-f139763a473d/IMG_2674.JPG.jpg">
<p>**よっしゃ来た！**コーディング開始です。<br>
ちなみにこのときの体感酔っぱらい度は微妙にほろ酔いといった感じで、人と喋りながらだったら自分が酔ってることに気付かないんじゃないかな、といったレベルです。</p>
<h1>結果</h1>
<p>こんなことを繰り返しつつ問題を解いていき、また後日素面の状態で別の問題を解きました。<br><br>
点数・回答時間は以下のような結果に。</p>
<h2>素面の結果</h2>
<table>
<tr><th>ランク</th><th>かかった時間</th><th>受験者の平均時間</th><th>点数</th><th>平均との乖離</th></tr>
<tr><td>B</td><td>17:40</td><td>31:03</td><td>100</td><td>-45.0%</td></tr>
<tr><td> B </td><td>19:02  </td><td> 29:25 </td><td> 100 </td><td>-35.3%</td></tr>
<tr><td> C </td><td>9:52  </td><td> 21:40 </td><td> 100 </td><td>-54.5%</td></tr>
<tr><td> C </td><td> 23:54 </td><td>25:57  </td><td> 100 </td><td>-7.9%</td></tr>
<tr><td> C </td><td>11:42  </td><td>17:38  </td><td> 100 </td><td>-33.7%</td></tr>
<tr><td>平均</td><td></td><td></td><td></td><td><b>-35.28%</b></td></tr>
</table>
<h2>お酒を飲んだ結果</h2>
<table>
<tr><th> ランク </th><th> かかった時間 </th><th> 受験者の平均時間 </th><th> 点数 </th><th>平均との乖離</th></tr>
<tr><td> B </td><td> 25:20 </td><td> 58:56</td><td> 100  </td><td>-57.0%</td></tr>
<tr><td> B </td><td>17:29  </td><td>31:36  </td><td>100  </td><td>-44.7%</td></tr>
<tr><td> C </td><td> 14:44 </td><td>27:35  </td><td><b>60</b></td><td>-46.6%</td></tr>
<tr><td> C </td><td> 9:09 </td><td> 20:56 </td><td> 100 </td><td>-56.3%</td></tr>
<tr><td> C </td><td> 8:23 </td><td> 13:40 </td><td> 100 </td><td>-38.7%</td></tr>
<tr><td> 平均 </td><td>  </td><td>  </td><td>  </td><td> <b>-48.66%</b> </td></tr>
</table>
<p><strong>うーん・・・・</strong></p>
<p>平均に対する速さでいうと微妙に早くはなっていますが、先述のグラフほどの生産性向上は見られませんでした。<br><br>
また、飲んだ方では1度凡ミス（採点時後すぐ原因箇所は判明）によりテストケース採点で60点を出しており、注意力の低下が見られます。<br>
<br>ちなみに後々両者のコードを読み返してみて読みやすさ等を比較してみましたが、そこまで違いはありませんでした。というか、提出時間を最優先した結果有り体に言って両方共クソコードでした。</p>
<p>結局「バルマーピークはあります！」と言えるほどの結果にならず残念です。<br>
とはいえ、そもそも「酒なんか飲んだら仕事にならない」という固定観念からすると、速度の向上が見られている時点で有意義な結果になったと言ってもいいのではないでしょうか。</p>
<p>読者諸兄におかれましては、是非この記事を片手にチームのマネージャーに飲酒コーディングの許可を直訴してみてはいかがでしょうか。私は責任を一切負いません。</p>
<p>ただやはり注意力の低下は避けられなさそうなので、もし不安な場合はテストを書いて<a href="/multi-browesr-test/">BrowserStackで実行</a>しましょう。</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、生産性の向上に余念のないエンジニアを募集しています！</p>
<p>詳しくは<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>


お酒を飲むとプログラミングスキルが爆発的に上がるって本当？検証してみました。

バルマーピークは本当にあるのか 検証してみた | PLAID engineer blog

【エンジニアの】バルマーピークは本当にあるのか 検証してみた【夢？】

<p>こんにちは。エンジニアの藤川です。<br><br>
この頃は穏やかで過ごしやすい季節となりましたが、皆さんいかがお過ごしでしょうか。</p>
<p>今回はプレイドのエンジニア、デザイナー、インターンの皆で山梨県は河口湖にある <a href="http://www.c-ban.com/">河口湖カントリーコテージ</a> さんにお邪魔して、開発合宿を行ってきましたのでその様子をご紹介していこうと思います。</p>
<h1>出発の地は新宿</h1>
<p>今回の出発の地は新宿です。観光バスを貸し切って山梨県河口湖を目指します。<br>
<br>なんだか遠足みたいでワクワクしますね。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cd45da35-81aa-4821-a550-48cbdeb94419/_P5256874.jpg">
<h1>河口湖カントリーコテージに到着</h1>
<p>途中、渋滞に巻き込まれてしまうなど軽いハプニングはありましたが、無事に河口湖カントリーコテージへ到着しました。<br>
<br>美しい森林に囲まれながら河口湖を見下ろす景観はなかなかのものです。都会の喧騒を忘れて開発に集中するには絶好の環境ですね。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b361a2fa-07ef-42c9-abd1-1b06f2d8406b/_P5256934.jpg">
<p>そして今回、私たちが宿泊する場所がこちら。<br><br>
なんと35名まで宿泊可能という <a href="http://www.c-ban.com/cottage_type35.php">エクストラコテージ</a> にメンバーのテンションも上がります！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7fded079-e977-4432-b471-662fad51fd35/_P5256942.jpg">
<p>リビングエリアは吹き抜けになっています。<br>
快適！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/99f3253b-99e4-4c04-9ea5-4b14c561bd84/_P5256979.jpg">
<h1>さっそくCTO柴山から企画説明</h1>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4f8bda3e-280c-4390-87e4-5fa6839bdb22/_P5267117.jpg">
<p>実はこれまでエンジニアメンバーで行ってきた合宿では、基本的にディスカッションをメインに行ってきました。以前の合宿については<a href="http://blog-plaid.com/event/2772/">こちらの記事</a>をご参照ください。</p>
<p>しかし今回の合宿は少し毛色が違うようです。<br><br>
今回はハッカソンを行います。テーマは<strong>日常業務ではなかなか作れない、自分が作りたいと思っているもの</strong>です。</p>
<h1>開発開始</h1>
<p>企画説明が終わると皆さっそく開発に入ります。<br>
<br>どんなものが出来上がるのでしょうか。合宿の最後に１人３分間でプレゼンテーションを行います。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ed7f6f3-99e7-4efe-9902-5cffa7eeeeb0/_P5257008.jpg">
<p>ついさっきまで河口湖の景色や大きなコテージにテンションが上がりっぱなしだったメンバーですが、いざ開発を始めるとみんな物凄い集中力でコードを書き始めました。<br><br>
この辺りはさすがだなと、感心してしまいます。</p>
<p>麦わら帽子をかぶったまま開発するメンバーも！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bdc58c15-aa3c-4afb-ab6c-1a68e1838f0d/_P5257012.jpg">
<h1>どうやら優勝賞品があるらしい...</h1>
<p>しばらくするとSlack上でnaokiさんがつぶやきます。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7849e609-b5a8-4668-a7b6-77aabd4aae43/----------2017-06-09-2.41.01.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/98f2197b-872a-4c22-a2d9-7dc687654fa3/----------2017-06-09-2.38.08.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/876eefc6-477b-4ccc-9eeb-e87f4a837fe2/----------2017-06-09-2.38.36.png">
<p>どうやら最も良いものを作り上げた人には優勝賞品が与えられるそうです。<br>
そして頑なにharibo１年分を推している。。</p>
<p>優勝賞品は一体何になるのか。<br><br>
すべてnaokiさんの独断と偏見に委ねられることになりました。</p>
<h1>夜はBBQ、そして温泉</h1>
<p>さて、開発に集中しているとあっという間に日が暮れてしまい夕食の時間になりました。<br><br>
今回の合宿の夕食はバーベキューです！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1d7749cc-4ffb-4191-b579-acf58d167b6c/_P5257040.jpg">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/637bc15f-1f7b-424f-bcdc-1790153119e2/_P5257045.jpg">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df949c4d-61d2-407b-adc6-812f1a69d785/_P5257082.jpg">
<p>こうして仕事を忘れて肉を囲みながらワイワイするのも良いものですね！<br><br>
みんな本当に楽しそうにしていました。</p>
<p>そして夕食のあとはコテージのすぐそばにある温泉で疲れた体を癒します。<br>
銭湯部に所属する私にとっては、この上なく幸せな時間でした。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f2f4da4-170b-4511-9dc1-bdedc2b382ca/bath_main4.jpg">
（画像は[公式サイト](http://www.c-ban.com/bath.php)より転載）
<h1>翌日</h1>
<p>さて、日付は変わり２日目の朝です。<br><br>
この日は、まず午前中の１時間ほどを使って社内コミュニケーションの課題感と対策についてディスカッションをしました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/555050dc-fb54-469a-b344-8cf08320cb34/_P5267103.jpg">
<p>社内コミュニケーション、とりわけエンジニアメンバーとフロントメンバー間のコミュニケーションというものは常に課題感を持って取り組まなければならないテーマです。<br><br>
なかなか完璧な解を見つけることは難しいですが、少しずつより良い方向に変化していけるように努力していきたいところです。</p>
<p>そんなディスカッションが終わると、成果発表までの残りの時間は各自開発をしたり、昼食をとったりと自由に過ごしました。</p>
<p>ほうとううまい。すごいうまい。</p>
<h1>いよいよ成果発表</h1>
<p>さて、いよいよ成果発表のプレゼンテーションの時間です。<br><br>
ここでは数ある中から、いくつかの発表を紹介していきたいと思います。</p>
<h2>採用周りの業務効率化</h2>
<p>今まで手付かずだった採用周りの業務の効率化を試みたのは、nodaさん、kadoppeさん、nitoさん、そしてインターンのtanakaくん。<br><br>
プレイドの採用周りの情報はGoogleスプレッドシート・カレンダー、Trello、FormStack、Wantedlyなど他にも複数のサービス上で管理していますが、多くのものが手動で管理されていて効率が悪かったり、これらの情報へのアクセシビリティも良くないなど、いろいろな課題を抱えていました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a91e7a8-99e5-4f03-8ef7-f59381351e42/_P5267137.jpg">
<p>そこで彼らはZapierを用いたAPI連携や、スクレイピングなどの技術を使って採用周りの業務を一部自動化することに成功していました。</p>
<p>また採用関連情報へのアクセシビリティという観点では、Trello上で管理されている採用候補者のステータスが変わるとSlack上でメンバー全員に周知してくれる「さいよーぼっと」君を作ることで、採用に直接関わっていないメンバーでも早い段階で次にどんな人が、プレイドの仲間に加わるのかを知ることができるようになりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b58f73e7-2555-49f0-9fb7-c4b58faf258c/----------2017-06-06-17.27.13.png" alt=""></p>
<h2>KARTEで計測したユーザー行動情報を学習</h2>
<p>makinoyさんはKARTEで実際に計測されたユーザーの行動ログから、ユーザーの行動パターンを学習させた結果や、それによって得られた知見を共有していました。<br>
KARTEによって集まった大量の行動ログデータを、どのようにしてKARTEを使っていただいているクライアントや、さらにはその先のエンドユーザーの価値にまで還元させることができるか、というのは我々にとって非常に重要なテーマです。<br>
簡単なことではありませんが、妥協することなく考え抜き、着実に前に進めていきたいところです。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/4a867335-f0b0-4c73-961c-efeca2e9a513/_P5267157.jpg">
<h2>Slackによるデプロイ自動化機能の強化</h2>
<p>ikemonさんは、すでに実際に現場で運用されているSlackを使ったデプロイ自動化機能をさらに使いやすいものへとアップデートしていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aab39af9-4bc4-4bcc-ab58-14ee9af9d77c/slackdemo-1.gif" alt=""></p>
<p>なんとボタンをポチポチ押していくだけでワンストップでデプロイ〜リリースまでを完了することができてしまいます。<br>
いま実際に運用されているHubotを用いたデプロイの自動化機能も十分に便利なものなのですが、さらに使い勝手がよくなりそうです。</p>
<h2>KARTEソースコードエディタの再デザイン</h2>
<p>デザイナーのkazutoさんは、現在KARTEに実装されているソースコードエディタを０ベースで再デザインしていました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0ad1fc79-7a1d-4af0-b8d3-dabffe07b2fe/_P5267187.jpg">
<p>KARTEを運用するユーザーが、「Atomicデザインという考え方をベースに直感的にコードを組み立てられるようなエディタ」をテーマにしてデザインをされていたのですが、なぜこのデザインなのか？というポイントが非常にロジカルに考えられていて個人的には目からウロコの発表でした。</p>
<h2>労務Bot「鳥場はる子」さんのアップデート</h2>
<p>otoanさん、yukkeさん、daikichiさん、monoiさんによる「はる子チーム」は労務 Bot「鳥場はる子」さんのアップデートに取り組んでいました。<br>
構文解析周りの強化や新機能の追加が行われた上、デザイナーのyukkeさんによって正式にキャラクターデザインも作られました。</p>
<img width="30%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a750f51-43cf-49b9-a9ab-0ac6055d161a/image.png">
<p>ここだけの話、今までの鳥場はる子さんは少々そっけない回答が多く、アイコン画像もいかにも素材ですという雰囲気の女性の画像だったので、なかなか愛着が湧いてくることはありませんでした。<br><br>
しかし、今回のアップデートでより賢く、より可愛くなった「鳥場はる子」さん。とても人気者になりそうな予感がしてきます。</p>
<h2>サポート業務を効率化するChrome拡張機能</h2>
<p>普段、クライアントのテクニカルな問い合わせのサポートを行っているgamiさんは、そのサポート業務を劇的に効率化するChrome拡張を作っていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1d28862f-49d0-47be-90e8-e649dd672400/4e45e4b8-3678-11e7-9e49-760e71a1a66a.png" alt=""></p>
<p>KARTEのサポート業務を行うためには、クライアントのサイト上でKARTEのタグが正常に動作しているか、正しくデータが送信されているかなどを素早く把握する必要があります。</p>
<p>このChrome拡張を使えばそういった情報をサポートメンバーが素早く把握することができるようになり、結果的にサポートの質を格段に上げることに繋がります。<br><br>
こういった視点からプロダクトの質を上げることができるのは素晴らしいですね。</p>
<h1>そして栄えある優勝は..</h1>
<p>全員の発表が終了すると、１人１票を各々が最も良いものを作ったと思う人に投票しました。<br>
そこで栄えある優勝に輝いたのは、グロッチさんことmeguroさん。</p>
<p>USB Type-Cのアダプタを用意していなかったため、PCの画面を直接見せながらの発表となりました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d8b577df-daa5-4fae-a7ce-85f9f4c2fa11/_P5267169.jpg">
<h2>画像付きQRコード発行機能</h2>
<p>meguroさんが作ったのは、KARTE上でQRコードを発行できる機能です。<br>
例えば画像をアップロードして設定するだけで、簡単にこんなQRコードを作れてしまいます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/659e56dd-e0c0-432f-a446-5d783c454325/qr____________.png" alt=""></p>
<p>おもしろいですね。</p>
<p>ちなみに色付きのQRコードも発行できます。<br>
このQRコードからのアクセスはKARTE上で計測されるので、興味を惹くQRコードを作って印刷物に掲載→サイトへ流入→コンバージョンUP！なんてシナリオも考えられそうです。</p>
<p>meguroさんのユーモアを交えた発表にはみんな興味津々で、一番の盛り上がりを見せていました。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/17f33358-75b0-464d-b2ad-eb28951d9e12/_P5267158.jpg">
<p>この機能がKARTEに搭載される日を楽しみに待ちたいと思います。</p>
<h1>開発合宿 終了</h1>
<p>さて、そんなこんなで楽しかった開発合宿もお開きの時間です。<br><br>
最後に集合写真をパシャり。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a94f7cbe-f5df-4ea7-a427-e080b13b211b/_P5267192.jpg">
<p>こうして開発合宿２０１７春は無事に全ての工程を終えました。<br><br>
プレイドのエンジニア陣にとって今回のように実際に手を動かしてモノを作る合宿というのは初めての試みでしたが、２日間という短い時間のなかで良いアウトプットがたくさん生まれ、とても収穫のある合宿だったのではないでしょうか。</p>
<h1>そして後日</h1>
<p>いつものように出社してきたグロッチことmeguroさん。<br>
自分のデスクの様子がいつもと違うことに気がつきます。</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/8b8d93e2-e4cd-4b06-93cf-2b427359fd11/meguro1.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/01893b36-caf0-4e85-a082-dbddb055e985/meguro2.png">
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/20381e69-dca7-4a5f-989b-6aed63840235/DSC08683.JPG.jpg">
<p>なんとそこに置いてあったのは大量のharibo！<br><br>
そして、さりげなくApple Watchも置いてあります！</p>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5cb7df6-cc7b-4089-9aa8-0c63742355f7/DSC08686.JPG.jpg">
<p>どうやら優勝賞品はharibo１年分とApple Watchに決まったみたいですね。<br><br>
おめでとうございます！！</p>
<p>と、ここでmeguroさん。</p>
<p>meguroさん「そうそう、これをこうして・・・」<br>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dd9ba188-df16-49af-83bd-4a33eced1737/DSC08694.JPG.jpg"></p>
<p>meguroさん「こうして・・・」<br>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/58b368bf-819b-4f1b-8351-0733785c47ed/DSC08703.JPG.jpg"></p>
<p>meguroさん「・・・」<br><br>
<img width="100%" src="https://ik.imagekit.io/newt/61b151f921640c0018173598/52b6bdfb-df46-471c-968f-4eb2ffdde0ad/DSC08713.JPG.jpg"></p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、こんな開発合宿に参加してharibo１年分が欲しいエンジニアを募集しています！</p>
<p>詳しくは<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>


山梨県河口湖に開発合宿へ行ってきました！プレイドのエンジニア陣にとっては初めてのハッカソンスタイルの開発合宿です。

山梨県河口湖に開発合宿へ行ってきました！ | PLAID engineer blog

山梨県河口湖に開発合宿へ行ってきました！

<p>プレイドの @nashibao です。</p>
<p>弊社は<strong>大量のログデータを収集し、人軸で解析するサービス</strong>を展開しています。収集したデータの利用方法には様々な目的と様々な手法がありますが、そのうちの大きな一つに、<strong>中・大規模のデータに対して、アドホックなクエリをインタラクティブにかけアグリゲーション結果を得る</strong> というものがあります。</p>
<p>このようなアグリゲーションの問題において、<code>クエリの自由度</code> x <code>データ規模</code> x <code>レイテンシー</code>を共存するのはなかなか難しい問題になります。(1)</p>
<p>元ネタは結構有名かと思いますが、<code>Square</code> が開発している、<code>Crossfilter</code><a href="https://github.com/crossfilter/crossfilter">GitHub - crossfilter/crossfilter: Fast n-dimensional filtering and grouping of records.</a>というものです。<code>Crossfilter</code>を内部に使ったビジュアライゼーションとして <a href="https://dc-js.github.io/dc.js/">dc.js - Dimensional Charting Javascript Library</a> というものもありますが、こちらの方が有名かもしれません。</p>
<p>というわけで、このエントリは、bit matrixやbit twiddlingといったテクニックで効率的なフィルタリングとアグリゲーションを実現することで、数百万レコード程度であれば、数十msで結果を出すといった優れものについてのお話になります。(2)</p>
<p>（1 余談ですが、こんなエンジニアリングの課題と市場の要望の乖離があるフィールドはプロダクトアウトなビジネスを始める良い条件が揃っていると考えられるかもしれません。たぶん。）</p>
<p>（2 本来は数百万レコード程度であれば大規模とは言えないと思いますが、中・大規模と書いたのは、<strong>出来るだけ盛って描きたい、という気持ちがあったというのは前提ですが</strong> 前処理として1段aggregationしてからインタラクティブな環境に持ってくれば、それで十分という場合が意外と多いと思うからです）</p>
<h1>ポイント</h1>
<p>jsでブラウザで動かしてここまでパフォーマンスが出るのは目からウロコ感があります。その肝は色々あると思いますが、僕個人としては次の3点が面白いところじゃないかと考えています。</p>
<ol>
<li>問題を制限する（<code>filtering</code> x <code>reduceによるaggregation</code>に制限）</li>
<li>BitMatrixとBit演算による高速なフィルタリング</li>
<li>Sorted Arrayを使った効率的な差分更新</li>
</ol>
<p>以下、この3点についてまとめてみます。</p>
<h1>問題を制限する</h1>
<p>上に書いたように、<code>クエリの自由度</code> x <code>データ規模</code> x <code>レイテンシー</code>全てを同時に満たすのは難しい問題です。そのため、ここではクエリに対してある程度の制限をかけることで、データの圧縮と高速な取出しを可能にしています。</p>
<ol>
<li>クエリ = フィルタリング  x アグリゲーション のみ</li>
<li>アグリゲーションは<code>reduce</code>（データの追加/削除による値の変化が、追加/削除されるデータにのみ左右される）のみ</li>
</ol>
<p><code>SQL</code>のように何でもかんでもという感じで複雑な処理は書くことはできませんが、1. <code>WHERE</code>と<code>GROUP BY</code>、2. 集計関数としても<code>Max|Min|Sum|Count|Average</code>など<code>reduce</code>処理として書けるものだけ、これを一段階だけ、に制限しているイメージです。ある程度 <code>前処理すること</code>を前提とすれば、上記のような制限をかけても、大体のことはできそうなイメージはあるんじゃないでしょうか。</p>
<p>このような制限をかけることで、やりたいことは制限しすぎずに → 効率的なデータ表現を使って → 高速なアグリゲーションを、というシナリオです。</p>
<h1>全体構造/概念</h1>
<p>crossfilterの簡単なコードを下記に表します。コードを読めばなんとなくやろうとしていることはわかるかな、と思いますが、詳しくは <a href="https://github.com/square/crossfilter/wiki/API-Reference">API Reference · square/crossfilter Wiki · GitHub</a> を参照してください。</p>
<ol>
<li>dimension作成（フィルタリング/Aggregateする軸を決める）</li>
<li>group作成（グルーピング単位を決める）</li>
<li>reducer作成（aggregateの関数を設定）</li>
<li>最後にfiltering x aggregation</li>
</ol>
<pre><code>data = [{fld1: 'type1', fld2: 10},...]
cf = crossfilter(data)

# create dimension
dim1 = cf.dimension (d) -&gt; return d.fld1
dim2 = cf.dimension (d) -&gt; return d.fld2

# create group
group = dim2.group (fld2) -&gt; return fld2 % 5

# creaate reducer
sumAdd = (p, v) -&gt; return p + v
sumReduce = (p, v) -&gt; return p - v
reducer = group.reduce sumAdd, sumRemove, 0

# filtering
dim1.filter('type1')

# get result
console.log reducer.top(3)
</code></pre>
<p>これらの概念は内部的には</p>
<ol>
<li>filters:データ数 x フィルタ数のBitMatrix</li>
<li>dimension: sort済みArray x lower/upper bounds</li>
</ol>
<p>で表現されています。</p>
<h1>BitMatrixによるフィルタリング</h1>
<p>さて一つ目のテクニックはBitMatrixによるフィルタリング行列の実装です。<br>
<code>N</code>（データ数）x <code>D</code>（Dimension数）のBitMatrixは、Javascriptだと<code>Uint8Array</code>などの<code>TypedArray</code>で表現されます。例えば、<code>30</code>行のデータ x <code>8</code>Dimension の場合、<code>new Uint8Array(30)</code>（30 x 8 = 240 bit) が実態になり、一つのデータが<code>Uint</code>一つで表されます。もしDimension数が8に満たない場合は、使わない部分はできますが<code>Uint8Array</code>で、16までであれば<code>Uint16Array</code>で、32までなら<code>Uint32Array</code>で表現する、といった具合です。（それ以上であれば<code>TypedArray</code>を並べて表現します、が、パフォーマンスは落ちるはずです。）</p>
<p>また、一つのbitは</p>
<ul>
<li><code>0</code>: フィルタリング<code>されてない</code>状態</li>
<li><code>1</code>: フィルタリング<code>されている</code>状態</li>
</ul>
<p>を表します。下図の例で言えば、データ(1)がフィルタ(2)で弾かれた場合、XOR演算で<code>0^32=32</code>になり、さらにフィルタ(5)で弾かれると<code>32^4=36</code>になります。そして、<code>0</code>と比較すればデータ(1)が弾かれているかどうかチェックすることができます。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/b86087dc-7aad-4b91-988b-af38c925e7e8/58e9dcea6ec63b0bbac5853c.png" alt="58e9dcea6ec63b0bbac5853c.png"></p>
<p>このように<code>O(N)</code>なメモリスペースを比較的高速な演算のみで利用することでfilteringを実現しています。</p>
<h1>Sorted Arrayを使った差分更新</h1>
<p>二つ目の面白ポイントはaggregationの差分更新の部分です。</p>
<p>上のコードに書いたように、reducerは常に<code>reduceAdd</code>, <code>reduceRemove</code>の両方を定義する必要があり差分更新を効率的に対応します。それに加えて、dimensionは、値をソートした配列 x 元データのindex配列 x 現在のlower/upper bound を持ち、BitMatrixも差分更新することができます（旧lower/upper boundと新lower/upper boundの差分indexだけXORで更新する）。</p>
<p>ちょっと端折って書いていますが、下記に例を書きました。sortされた配列からbinary searchでboundsを更新し、次に上記で説明したBitMatrixを更新し、更新のあったデータ行のみreducerを差分更新する、といった具合です。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/5e3a0d79-b8ff-40b1-828c-9325f21b2bff/58e9dcee6ec63b0bbac5853d.png" alt="58e9dcee6ec63b0bbac5853d.png"></p>
<p>ちなみに、上記のトリックはequalやrangeでのフィルタリングの話ですが、<code>crossfilter</code>は<a href="https://github.com/square/crossfilter/wiki/API-Reference#dimension_filterFunction">関数を定義したフィルタリング</a>もかけることができます。</p>
<pre><code>dim.filter([100, 200]) # range
dim.filter(120) # equal
dim.filter((d) -&gt; return d % 2) # function
</code></pre>
<p>その場合は上記のトリックは効かないため、若干パフォーマンスが落ちると考えられます。そのため、できれば<code>dimension</code>の時点で前処理をしておいて、<code>filter</code>はequalやrangeでかける方がパフォーマンスが良いと考えられます。</p>
<h1>感想</h1>
<p>さて、とりあえず3つほど<code>Crossfilter</code>のキモっぽいポイントを紹介しましたが、実際のパフォーマンスのインパクトの割にはなんだか地味だな、、と書いていて思ったのと、自分には絵を書いているうちに力尽きる傾向があることに気がつきました。<code>Crossfilter</code>自体には他にもbit演算を駆使した高速化（ <a href="https://graphics.stanford.edu/~seander/bithacks.html">Bit Twiddling Hacks</a>）が散らばっていて  <s>ぶっちゃけかなり読みづらい</s> 結構面白いので興味があったらコードリーディングしてみると良いかもしれません。</p>
<p>また、filter|reducer共に並列化可能な形式であったり、tree上のcacheを使えばaggregationをさらに高速化できそうな所、サーバーとしての利用など、随所にupdateできそうな部分があります。ここら辺も詳しい人|知らないけど議論してみたい人など募集しています。是非とも気軽に五反田まで遊びに来てください。やけに安いけれど美味しくない焼肉屋とか奢ります！</p>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit.html">プレイドの採用ページ</a>か、<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


このエントリは、bit matrixやbit twiddlingといったテクニックで効率的なフィルタリングとアグリゲーションを実現することで、数百万レコード程度であ

Bit Matrixを使って超高速にアグリゲーションする | PLAID engineer blog

Bit Matrixを使って超高速にアグリゲーションする

<p>こんにちは！プレイドの@ikemonnです。<br>
<a href="/aws_gcp_multicloud_2/">前回</a>はAWSとGCPをVPNで接続した話をしました。<br>
今回はGCPでの検証を行った際の進め方について説明していきます。</p>
<p>インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気づくことができ、予定していなかったインフラ構成の変更が必要であることが確認できました。</p>
<p>マルチクラウドインフラを構築する際には「小さく始めて、検証できる環境を作る」ことがポイントになります。</p>
<h2>目次</h2>
<ul>
<li>小さく始める</li>
<li>検証する</li>
<li>まとめ</li>
</ul>
<h2>小さく始める</h2>
<h3>最初に検証するサーバの選定</h3>
<p>今回は下記の3点を基準にどのサーバをまずGCPへ移行するかを選定しました。</p>
<ol>
<li>お客様への影響が少ないサーバ</li>
<li>GCPへ移行のメリットが大きいサーバ(パフォーマンス向上等)</li>
<li>関連するコンポーネントが少ないサーバ</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dcbce60b-6fbf-42b7-b5d1-9ccb6c54698c/131d4ecd-a618-4ae8-bc0a-4426f98ed44d.png" alt=""></p>
<p>KARTEでは処理の内容毎にサーバ群が分かれており、大きく分けると「エンドユーザからのアクセスを受けるWebサーバ群」と「タスクキューからタスクを取得して処理していくサーバ群」の2種類があります。</p>
<ol>
<li><a href="https://cloud.google.com/bigtable/">Cloud BigTable</a>を一番使用していて移行のメリットが大きい</li>
<li>LB等の関連するコンポーネントが少ないので構築が楽</li>
</ol>
<p>という特性の「タスクキューからタスクを取得して処理していくサーバ群」から移行を始めることにしました。</p>
<h3>検証用サーバの構築</h3>
<p>構築の際には下記の点を意識しながら構築を進めていきました。</p>
<ol>
<li>GCPの操作に慣れ、特徴をつかむためにまずWebコンソールから手動でサーバを立てる</li>
<li>GCPに慣れた後は今後のことを考えて使いまわせるようにする</li>
</ol>
<h3>Webコンソールからサーバを構築する</h3>
<p>まずはWebコンソールから手動でサーバを構築することから始めました。</p>
<p>もともとAWS上のサーバはTerraformを用いて構築していました。<br>
しかし、いきなりGCPもTerraformで構築しても設定すべきパラメータや各コンポーネントとの関連が理解できておらず効率が悪いです。<br>
まず最初は手動で作るのがオススメです。</p>
<p>Webコンソールから構築をすることで、「AWSとGCPではブロックデバイスの扱いが異なっている(GCPではImageにブロックデバイスの情報は付与されていない)」ことや「AutoScaling Groupで設定すべき項目が大きく異なる」ことなど、プラットフォームの違いが分かり、後のTerraform化作業がスムーズに行えました。</p>
<p>下記がTerraformでのlaunch config/instance templateコードです。<br>
disk周りの設定が異なっていることがわかります。</p>
<pre><code># GCPのinstance template (Imageにdisk情報が含まれていないので指定する必要がある)
resource &quot;google_compute_instance_template&quot; &quot;foobar&quot; {
  name        = &quot;terraform-test&quot;
  machine_type         = &quot;n1-standard-1&quot;

  // Create a new boot disk from an image
  disk {
    source_image = &quot;debian-cloud/debian-8&quot;
    auto_delete  = true
    boot         = true
  }

  // Use an existing disk resource
  disk {
    source      = &quot;foo_existing_disk&quot;
    auto_delete = false
    boot        = false
  }
...(中略)
}
</code></pre>
<pre><code># AWSのlaunch config (AMIにdisk情報も含まれているので指定する必要が無い)
resource &quot;aws_launch_configuration&quot; &quot;as_conf&quot; {
  name_prefix   = &quot;terraform-lc-example-&quot;
  image_id      = &quot;${data.aws_ami.ubuntu.id}&quot;
  instance_type = &quot;t2.micro&quot;

  lifecycle {
    create_before_destroy = true
  }
}
</code></pre>
<p>「この部分はAWSでいう〇〇だ」というようなことを考えながら構築するのがオススメです。</p>
<h3>最低限使いまわせるようにする</h3>
<p>手動でサーバを構築することで、設定すべき項目のあたりがつくようになりました。<br>
今後のことを考えると、手動構築ではサーバをスケールさせてパフォーマンスを見たい時や、他の役割のサーバ群を立てる時に大変です。<br>
そこで、後々使いまわせるようにサーバの構成管理とImage作成に関しては、再利用できるようにすることにしました。</p>
<p>様々なツールがでているのですが、「マルチプラットフォームで使用できる」という点を踏まえて下記のツールを選びました。</p>
<ul>
<li>サーバの構成管理: <a href="https://www.terraform.io/">Terraform</a></li>
<li>Image作成: <a href="https://www.packer.io/">Packer</a></li>
</ul>
<p>AWSでもサーバの構成管理はTerraformで行っていたので引き続き使うことにしました。<br>
問題はImageを作成する部分でした。<br>
もともと、<a href="https://aws.amazon.com/jp/cloudformation/">AWS CloudFormation</a>で作っていたのですが、CloudFormationではGCEのイメージは作成できません。</p>
<p>また、Googleのサービス<a href="https://cloud.google.com/deployment-manager/">Google Cloud Deployment Manager</a> もありますが、CloudFront/Deployment Managerの双方を使いコードを2重管理するのは面倒です。</p>
<p>「マルチプラットフォームのimageを簡単に作れる」「コードを2重管理しなくて良い」という点を考えてツールを探した結果、<a href="https://www.packer.io/">Packer</a>を使用することにしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5ebd17e-6cc9-41e3-9bd8-ffd2a602c4e1/f83816eb-c62b-48c3-9eb8-37036d0125c4.png" alt=""></p>
<p>PackerとはTerraformや<a href="https://www.vagrantup.com/">Vagrant</a>を作っている<a href="https://www.hashicorp.com/">HashiCorp</a>社の製品で、ユーザが準備した設定ファイルに従って、仮想マシン等のイメージ作成とプロビジョニングを行ってくれるツールです。<br>
Packerを使うことでAWS/GCP両方のイメージを作成することができます。</p>
<p>下記のように、AWSとGCPのサーバの設定をそれぞれ指定して書いていきます。</p>
<pre><code>{
  &quot;variables&quot;: {
     &quot;node_ver&quot;: &quot;6.9.2&quot;,
     &quot;npm_ver&quot;: &quot;3.8.8&quot;,
     ...
     },
  &quot;builders&quot;: [
    {
      &quot;type&quot;: &quot;googlecompute&quot;,
      &quot;instance_name&quot;: &quot;{{user `environment`}}-node-{{isotime \&quot;2006-01-02-1504\&quot;}}&quot;,
      &quot;image_name&quot;: &quot;{{user `environment`}}-node-{{isotime \&quot;2006-01-02-1504\&quot;}}&quot;,
      &quot;account_file&quot;: &quot;{{user `gcp_account_file`}}&quot;,
      &quot;project_id&quot;: &quot;{{user `gcp_project_id`}}&quot;,
      &quot;disk_type&quot;: &quot;pd-ssd&quot;,
      &quot;machine_type&quot;: &quot;n1-standard-2&quot;,
      &quot;disk_size&quot;: &quot;{{user `root_volume_size`}}&quot;,
      &quot;ssh_username&quot;: &quot;root&quot;,
      &quot;source_image&quot;: &quot;{{user `gcp_source_image`}}&quot;,
      &quot;zone&quot;: &quot;asia-east1-a&quot;
    },
    {
      &quot;type&quot;: &quot;amazon-ebs&quot;,
      &quot;access_key&quot;: &quot;{{user `aws_access_key`}}&quot;,
      &quot;secret_key&quot;: &quot;{{user `aws_secret_key`}}&quot;,
      &quot;region&quot;: &quot;{{user `aws_region`}}&quot;,
      &quot;iam_instance_profile&quot;: &quot;{{user `aws_iam_instance_profile`}}&quot;,
      &quot;source_ami&quot;: &quot;{{user `aws_source_image`}}&quot;,
      &quot;instance_type&quot;: &quot;c4.large&quot;,
      &quot;ssh_username&quot;: &quot;ubuntu&quot;,
      &quot;associate_public_ip_address&quot;: &quot;true&quot;,
      &quot;ami_name&quot;: &quot;{{user `environment`}}_nodeami_{{isotime \&quot;2006-01-02-1504\&quot;}}&quot;,
      &quot;enhanced_networking&quot;: &quot;true&quot;,
      &quot;launch_block_device_mappings&quot;:[
        {
          &quot;device_name&quot;: &quot;/dev/sda1&quot;,
          &quot;volume_size&quot;: &quot;{{user `root_volume_size`}}&quot;,
          &quot;volume_type&quot;: &quot;gp2&quot;,
          &quot;delete_on_termination&quot;: &quot;true&quot;
        },
        {
          &quot;device_name&quot;: &quot;/dev/sdf&quot;,
          &quot;volume_size&quot;: &quot;10&quot;,
          &quot;volume_type&quot;: &quot;gp2&quot;,
          &quot;delete_on_termination&quot;: &quot;true&quot;
        }
      ],
      &quot;vpc_id&quot;:&quot;{{user `vpc_id`}}&quot;,
      &quot;subnet_id&quot;:&quot;{{user `subnet_id`}}&quot;,
      &quot;communicator&quot;: &quot;ssh&quot;,
      &quot;user_data_file&quot;: &quot;common/aws_user_data.sh&quot;
    }
  ],
  &quot;provisioners&quot;: [
    {
      &quot;only&quot;: [&quot;amazon-ebs&quot;],
      &quot;type&quot;: &quot;shell&quot;,
      &quot;script&quot;: &quot;common/init_for_aws.sh&quot;,
      &quot;execute_command&quot;: &quot;{{ .Vars }} sudo -E sh '{{ .Path }}'&quot;
    },
    {
      &quot;only&quot;: [&quot;googlecompute&quot;],
      &quot;type&quot;: &quot;shell&quot;,
      &quot;script&quot;: &quot;common/init_for_gcp.sh&quot;,
      &quot;execute_command&quot;: &quot;{{ .Vars }} sudo -E sh '{{ .Path }}'&quot;
    },
    {
      &quot;type&quot;: &quot;shell&quot;,
      &quot;scripts&quot;: [&quot;common/exec_serverspec.sh&quot;],
      &quot;execute_command&quot;: &quot;{{ .Vars }} sudo -E sh '{{ .Path }}'&quot;
    }
  ]
</code></pre>
<p>Packerの良い点は、コマンドを実行するだけでイメージを作成できるところです。<br>
CloudFormationを使っていた時はインスタンスを立てた後、AMIを作成する &amp; image作成後のインスタンス削除は手動で行っていました。<br>
Packerに変えることで、image作成&amp;インスタンス削除が全てコマンドラインだけで行えるので作業効率化につながりました。</p>
<p>また、下記のようにimage作成処理は並列で実行されるところも良い点です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c9968569-4555-4b10-81ce-10137fe0c725/b1a72c54-1a15-46ff-a49f-d9bdcc2e4877.png" alt=""></p>
<p>実際にイメージを作ってみたところ、GCPのimageの方がAWSよりも2~3分早く作成されました。<br>
弊社はNode.jsを使用しており、Node.jsのinstallまではAWSの方が1.5分ほど早いのですが、node_moduleのinstallになるとGCPが逆転していました。<br>
処理内容を見てみると、EBSへのファイル書き込みで時間がかかっているようなので、GCPの方がそのあたりは速いようです。</p>
<h2>検証する</h2>
<p>Packer + Terraformでサーバを構築できたので検証に移ります。</p>
<p>弊社では<a href="https://www.datadoghq.com/">Datadog</a>というモニタリングツールを使い、インフラ&amp;アプリケーションの監視を行っています。(詳しくはこちら→ <a href="/freee-plaid-monitoring-meetup/">【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！</a>)<br>
今回もAWSとGCPのパフォーマンスをDatadogで可視化し、どの処理に時間がかかっているかを調べました。</p>
<p>弊社の @makinoy が作成した<a href="https://github.com/makinoy/libs-dogstatsd">makinoy/libs-dogstatsd</a>という、処理の実行時間や処理回数をDatadogに送信できるラッパーを使用して実行時間を計測しました。</p>
<pre><code>var dogstatsd = require('libs-dogstatsd')

const stats = dogstatsd.start();
// some method
stats.tick(‘test’, 1, 1, [pid:1234]);
</code></pre>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0e4b0ffd-24f9-4be0-a211-f5ea4828e038/9bd9a590-407d-4da6-9d2d-33393c00efb9.png" alt=""></p>
<p>この時点では、上記のような構成でGCP上のサーバからAWSのDBを見に行くようになっているので、VPN越しのDBへの接続がボトルネックになっていることが分かりました。</p>
<p>一方、BigTableへの接続は同じGCP上にあることで、AWS環境で動かしていた時よりも早いということも分かりました。</p>
<p>また、一気に大量のインスタンスを立てて検証していた時に、想定外のボトルネックが見つかりました。<br>
一定台数以上のインタンスを立てるとパフォーマンスが出なくなったのです。<br>
よくよく調べてみると、ドキュメントには明記されていなかったのですが、どうもVPNの帯域に上限があるようでした。<br>
このままではGCP上でサーバをスケールできないので、DBの配置を変更してVPN経由の通信を減らす必要があることが分かりました。</p>
<p>このような想定外のボトルネックも早めに検証することで確認できたのが大きかったです。</p>
<p>DB構成については、次回以降の記事でどのように改善したのかお伝えしていきます！</p>
<h2>まとめ</h2>
<p>マルチプラットフォームでの検証を進める際には、下記を意識して進めていくと良いと思います。</p>
<ul>
<li>まずは手動でサーバを立ててみて、そのプラットフォームに慣れる</li>
<li>初めは極力作り込まずにサーバを立てて検証を始める</li>
</ul>
<p>「頑張りすぎずに小さく始めて、検証していく」ことでマルチプラットフォーム化を効率よく進めていきましょう！</p>
<h2>関連リンク</h2>
<ul>
<li><a href="/aws_gcp_multicloud_1/">AWSとGCPでマルチクラウドインフラを構築した話とそのポイント| PLAID engineer blog</a></li>
<li><a href="/aws_gcp_multicloud_2/">AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント| PLAID engineer blog</a></li>
</ul>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、マルチクラウドインフラを成長させたい、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>


今回はGCPでの検証を行った際の進め方について説明していきます。インフラを作り込みすぎずに検証したことで、早めに想定外のボトルネックに気

AWSとGCPのマルチクラウドインフラ検証の進め方

<p>みなさん、ごきげんよう。プレイドの@tik-sonと申します。</p>
<p><a href="http://tech.plaid.co.jp/aws_gcp_multicloud_1/">前回のエントリー</a>では、<br>
弊社の<a href="https://karte.io">KARTE</a>で、インフラには<a href="https://aws.amazon.com">AWS</a>と<a href="https://cloud.google.com/">GCP</a>の２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しているというお話をいたしました。<br>
今回のエントリーではその中から、「AWSとGCPをVPNで接続した」内容についてフォーカスして</p>
<ul>
<li>各クラウドプラットフォームでのVPNの仕様</li>
<li>KARTEではどのようなVPN設計にしているのか</li>
</ul>
<p>等をお話したいと思います。</p>
<h1>目次</h1>
<ul>
<li>VPNを用いる理由</li>
<li>AWSとGCPのSubnetの違い</li>
<li>VPNを接続する</li>
<li>可用性を考える</li>
<li>パフォーマンスを考える</li>
<li>VPN周りの設計について</li>
<li>悩まされたこと</li>
<li>最後に</li>
</ul>
<h1>VPNを用いる理由</h1>
<p><a href="http://tech.plaid.co.jp/aws_gcp_multicloud_1/">前回のエントリー</a>で、マルチクラウドインフラの要件として <strong>「各クラウドプラットフォームのサーバが相互に通信できる」</strong> と記載しましたが、私達はその実現方法としてVPNを選択しました。<br>
VPNであればプライベートネットワークを拡張する形になるので<br>
既存のAWSのネットワーク構成変更を少なく、GCPのサーバとセキュアに通信ができるようにすることができるからです。</p>
<p>もちろんサーバにグローバルIPアドレスを持たせて直接通信させる案も考えましたが、</p>
<ul>
<li>外部に対して通信できるように新たにポートを空けなければならない</li>
<li>通信を暗号化しなければならない</li>
</ul>
<p>など考慮しなければいけないポイントが多くでてきてしまい、実装まで時間がかかりそうだったため、今回は選択しませんでした。</p>
<h1>AWSとGCPのSubnetの違い</h1>
<p>はじめにVPNにて利用するSubnetにおけるAWSとGCPの違いについて軽くお話をします。</p>
<h2>AWSのSubnet</h2>
<p>AWSでプライベートなネットワークを作る時は<a href="https://aws.amazon.com/vpc/">VPC</a>という機能を使います。1つのVPCの中に最大 <code>/16</code> のネットマスクのプライベートネットワークを定義でき、そのプライベートネットワークの中で更にSubnetを切っていくことができます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/a72f0973-8348-4b17-b040-ae9458865846/1-1.png" /></div>
`https://cloud.google.com/compute/docs/networking#subnet_network`
<h2>GCPのSubnet</h2>
<p>GCPではAWSのVPCのようなサービスとして定義はされていないのですが、以下の図のように1つのGCP Networkという単位の中に様々なSubnetを作成することができます。<br>
例えば、<code>10.240.0.0/24</code> と <code>192.168.1.0/24</code> を１つのGCP Networkを共存させることができ、それぞれのSubnetは特に設定不要で相互通信が可能になります。<br>
GCPの方がAWSより柔軟にSubnetを作れるようです。<br>
ただし、Subnetは柔軟に作れますが、 GCP Network上で稼働させるインスタンスの<a href="https://cloud.google.com/compute/docs/networking#quotas_and_limits">台数制限はデフォルトだと7000台</a> だということ は注意しなければなりません。(なかなかその上限に引っかかることは無いと思いますが)</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/33ed5504-df40-4ef3-ab1f-a51109c43da4/2-1.png" /></div>
<p><code>https://cloud.google.com/compute/docs/networking#subnet_network</code></p>
<h1>VPNを接続する</h1>
<p>VPNには色々な種類がありますが、今回使用するVPNはAWS、GCPが共にサポートしているIPsecVPNになります。</p>
<p>AWSとGCPをVPN接続する際の詳細な手順については<br>
<a href="http://dev.classmethod.jp/cloud/vpn-interconnect-amazon-vpc-and-gce/">クラスメソッドさんの記事</a>に記載されているので参考にさせていだきました。少し古い記事になりますが、流れとしてはほとんど変わっていないので、こちらとあわせて<br>
<a href="http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html">AWSのドキュメント</a>と<br>
<a href="https://cloud.google.com/compute/docs/vpn/creating-vpns">GCPのドキュメント</a><br>
を参考にしていただければ、特につまることなくVPN接続が出来るかと思います。<br>
記事内でも紹介されていますが、VPN接続の設定順番が重要になってきます。<br>
また、この記事の記載後にGCEのネットワークの機能が拡張されたことで、現在はVPN接続を定義したリージョン以外のインスタンスからもVPN接続を利用できるようになっています。</p>
<h1>可用性を考える</h1>
<p>本番環境で運用する上で可用性を考えないわけにはいきません。<br>
VPNトンネルが１つしかない状態でそのVPNトンネルが切断されてしまうとどうなるでしょうか？<br>
答えは簡単でAWS、GCP間で通信ができなくなるというクリティカルな問題が発生してしまいます。<br>
したがって<code>VPNを冗長化</code> することはとても大切です。</p>
<p>AWSでは1VPN設定に対して、2VPNトンネル、GCPでは1VPN設定に対して1VPNトンネルが提供されます。<br>
GCP、AWS共に2VPN設定ずつ用意し、以下の図のように構成を組むことで、冗長構成を取ることができます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/14be069b-2a93-43b1-b569-f7c034014df7/3-2.png" /></div>
<p><code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html#VPNConnections</code></p>
<p>尚、どちらのプラットフォームにおいても、それぞれのゲートウェイで同じルーティングを設定しておけば、片方のトンネルが落ちてしまった時に残りのトンネルを利用してくれるようになります。</p>
<p><strong>GCP</strong></p>
<blockquote>
<p>Cloud VPN ゲートウェイは、ピア VPN ゲートウェイが停止して一方の VPN トンネルが使用できなくなっても、もう一方の VPN トンネルを使用し続けます。停止した VPN トンネルが復帰すると、また自動的に両方のトンネルを使用します<code>https://cloud.google.com/compute/docs/vpn/advanced#redundancy_and_failover</code></p>
</blockquote>
<p><strong>AWS</strong></p>
<blockquote>
<p>AWS はときどき、仮想プライベートゲートウェイに対して定期的にメンテナンスを実行します。このメンテナンスによって VPN の 2 つのトンネルのうち 1 つが短時間無効になることがあります。このメンテナンスの実行中、VPN 接続は自動的に 2 番目のトンネルにフェイルオーバーします。サービスが中断されないようにするために、両方のトンネルを設定することが重要です。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#CustomerGateway</code></p>
</blockquote>
<blockquote>
<p>カスタマーゲートウェイが使用できなくなった場合に接続が失われるのを防ぐために、2 番目のカスタマーゲートウェイを使用して、VPC および仮想プライベートゲートウェイへの 2 番目の VPN 接続を設定できます。冗長な VPN 接続とカスタマーゲートウェイを使用すれば、1 つのカスタマーゲートウェイでメンテナンスを実行しながら、2 番目のカスタマーゲートウェイの VPN 接続を通してトラフィックの送信を継続することができます。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_VPN.html#VPNConnections</code></p>
</blockquote>
<p>ちなみに<a href="https://cloud.google.com/vpn/sla">GCPはVPNのSLA</a>が定義されていますが、AWSにはSLAの記述がないようです。<br>
また、GCPにもSLAはありますがGoogleのコントロール外の部分(インターネット等)による問題については保証されていない点については意識しておかなくてはいけません。</p>
<h1>パフォーマンスを考える</h1>
<p>もちろん本番環境で運用する上では可用性だけではなくパフォーマンスも考えないわけにはいきませんよね。ということで話をします。</p>
<h2>VPNのスループット</h2>
<p>各プラットフォームは以下の通りスループットについて説明があり、まとめると以下の通りです。</p>
<ul>
<li>AWSでは仕様上、スループットの制限は特にない</li>
<li>GCPは仕様上、VPN ゲートウェイごとに1.5 Gbpsまでのスループットのサポートはしている</li>
<li>スループットは利用環境によって変わるので実質、保証はされない</li>
</ul>
<p><strong>AWS</strong></p>
<blockquote>
<p>Q: VPN 接続のスループット制限はありますか?<br>
VPN のスループットについて、Amazon はいかなる制限も実施していません。ただし、その他の要因、例えばカスタマーゲートウェイの暗号化能力や、お客様側のインターネット接続速度、平均パケットサイズ、使用されているプロトコル（TCP か UDP か）、カスタマーゲートウェイと仮想プライベートゲートウェイの間のネットワークレイテンシーなどが、スループットに影響を与える可能性があります。<br>
<code>https://aws.amazon.com/jp/vpc/faqs/</code></p>
</blockquote>
<p><strong>GCP</strong></p>
<blockquote>
<p>各 Cloud VPN ゲートウェイでは、すべてのトンネルで最大 1.5 Gbps のスループットがサポートされています。スループットを最大にするには、トンネルごとに Cloud VPN ゲートウェイを作成します。 実際のパフォーマンスは次の要因によって変動します。</p>
</blockquote>
<ul>
<li>2 つの VPN ピア間のネットワーク容量。</li>
<li>ピアデバイスの機能。詳しくは、デバイスのドキュメントをご覧ください。</li>
<li>パケットサイズ。パケット単位で処理が発生するため、小さなパケットの割合が高いと全体的なスループットが低下します。</li>
<li>RTT やパケット損失率の値が高いと、TCP のスループットが大幅に低下します。<br>
<code>https://cloud.google.com/compute/docs/vpn/advanced#vpn_throughput</code></li>
</ul>
<h2>VPNトンネルへのトラフィックをコントロール</h2>
<p>スループットについてお話しましたが、仕様上においても1VPNトンネルだけだとスループットに限界があるため、複数のVPNトンネルを組み合わせることが大切だということが分かると思います。<br>
AWS、GCP共に、トラフィックを流すVPNトンネルをコントロールすることができるので、その仕様について紹介します。両クラウドプラットフォームともにトラフィックをコントロールすることはできるものの出来ることが少し異なっています。</p>
<p><strong>GCP</strong></p>
<ul>
<li>各VPNトンネルへのルーティング、Priorityを同じにすると、トラフィックをそれぞれのトンネルにバランシングしてくれます。</li>
<li>各VPNトンネルへのルーティングを同じにし、Priorityに差をつけると、Priorityが高いVPNトンネルがプライマリーのVPNトンネルとして利用されるようになります。<br>
<code>https://cloud.google.com/compute/docs/vpn/advanced#redundancy_and_failover</code></li>
</ul>
<p><strong>AWS</strong></p>
<ul>
<li>
<p>VPCのVPNでは Multi Path でのルーティングには未対応なので、バランシングはしてくれません。AWS側で定められたロジックによって、必ずVPNトンネルのどれかを利用することになります。<br>
<code>http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#MultipleVPNConnections</code></p>
</li>
<li>
<p>静的ルーティングの場合は最も具体的な IP プレフィックスが優先されます。<br>
例を示します。(参考: <a href="http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html#route-tables-priority">ルーティングの優先度について</a>)</p>
<p>IP プレフィックスについて少しややこしいと思うので以下の静的ルーティングが設定されたVPN1、VPN2という2つのVPN接続を例に説明してみます。</p>
  <table>
  <tr>
  <th> </th>
  <th>VPN1</th>
  <th>VPN2</th>
  </tr>
  <tr>
  <td>設定された静的ルーティング</td>
  <td>10.1.0.0/18,  10.1.64.0/18,  10.1.128.0/17</td>
  <td>10.1.0.0/17, 10.1.128.0/18, 10.1.192.0/18</td>
  </tr>
  </table>
  この場合
  - 全VPNが正常な場合はそれぞれ `/18` を設定したVPNが優先になります。
  - 片方のVPN切断時には `/18` で設定されたルーティングを包括する `/17` のルーティングが別のVPNに設定されているのでそちらの経路が使って迂回されることになります。
</li>
</ul>
<h1>VPN周りの設計について</h1>
<p>可用性やパフォーマンスについて記載してきましたが、それらを踏まえてVPN周りは以下のように設計にしています。</p>
<ul>
<li>VPNトンネルは複数作成する。</li>
<li>特定のVPNトンネルにトラフィックが偏らないように、
<ul>
<li>GCP側のサーバは複数のSubnetにサーバを分散させて配置する。</li>
<li>AWS側のルーティングは特定のSubnetへの通信が特定のVPNトンネルを利用するよう設定する。</li>
<li>GCP側のルーティングは全VPNトンネルでバランシングされるように同じプライオリティで同じ内容を設定する。</li>
</ul>
</li>
<li>VPNトンネルが切断された時に別トンネルで迂回できるよう、
<ul>
<li>AWS側のルーティングでは全VPNトンネルに対して別VPNトンネルのルーティングを包括するルーティングを記載しておく。</li>
<li>GCP側のルーティングでは全VPNトンネルに対して、同じルーティングを設定しておく。</li>
</ul>
</li>
</ul>
<p>イメージとしては以下の図のようになります</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/976999df-225b-4dbb-9f5c-d01a2270601c/4-1.png" /></div>
<p>ちなみにKARTEではシンプルなネットワーク構成にしているので、静的ルーティングを利用し<br>
ています。</p>
<h1>悩まされたこと</h1>
<h2>VPNのDropパケットの増加問題</h2>
<p>AWSとGCPをVPNで接続して運用していたある日、GCPのサーバのパフォーマンスが悪化することがありました。<br>
GCPは<a href="https://www.stackdriver.com/">StackDriver</a>でVPNの様々なメトリックををモニタリングできるので確認してみたところ、特定のVPNトンネルでDropパケットの増加が見受けられました。<br>
VPNトンネルが切断されてしまえば別のVPNトンネルを利用するようにしていたのですが、そのVPNトンネルは劣化した状態で生き続けていました。<br>
対応としては、特定のVPNトンネルの問題として判断し、劣化したVPNトンネルを切断し正常なVPNトンネルのみを利用するようにしたところ現象が改善しました。</p>
<p>後々、GCP、AWS両方のサポートなどに問い合わせて原因を突き詰めていったところ、AWSにおけるネットワークの劣化が原因で、VPNトンネルは落ちないがパケットがDropされているという状況でした。<br>
ネットワーク周りの問題は切り分けが難しいですが、モニタリングツールが存在することで切り分け、対応が迅速に行うことが出来ました。<br>
この件以降、VPNトンネルに対し、DropパケットなどのMetricでアラートを仕掛けるようにしています。</p>
<h2>VPNのスループット問題</h2>
<p>元々単一クラウドプラットフォーム内のプライベートネットワーク内で通信していたものをVPN越しで通信させようとすると、想定した以上にアプリケーションの性能が出ませんでした。<br>
その主な理由としては、DBとの通信の多くがVPN経由になっていたことでした。</p>
<p>VPNトンネルを増やしていけば暫定的には解決できる話になりますが、そもそも元々のアーキテクチャがマルチクラウドインフラに最適なアーキテクチャになっているとは言えなかったので、その部分について考え直しました。このあたりの話はまた別エントリーでお話しようと思うので乞うご期待を。</p>
<h1>今後について</h1>
<p>AWSとGCPの周りにはまだまだ改善の余地はあるので、今後以下を考えていきたいと思っています。</p>
<ul>
<li>特定の条件でVPNトンネル切断→接続する等のVPN運用周りでの自動化の仕組み</li>
<li>VPNトンネルのAutoscalingの仕組み</li>
<li>VPN経由ではないサーバ間通信の仕組み</li>
</ul>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、マルチクラウドインフラを成長させたい、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>


AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイントを説明します。
マルチクラウドインフラ連載の第二回。

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント| PLAID engineer blog

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

<p>ごきげんよう。プレイドの@tik-sonと申します。<br>
みなさんはクラウドプラットフォームを利用していますか？</p>
<p>弊社の<a href="https://karte.io">KARTE</a>は</p>
<ul>
<li>秒間3000イベントをリアルタイムで解析</li>
<li>累計解析ユーザがリリースから2年で12.5億<br>
https://karte.io/infographic/2017.html</li>
</ul>
<p>という規模のサービスになっています。<br>
そこで動いているインフラもそれなりに大規模になっており、インフラをいかに改善していくかが事業進捗に大きく関わってきます。</p>
<p>そのインフラを改善する試みとして半年ぐらい前から、<a href="https://aws.amazon.com">AWS</a>と<a href="https://cloud.google.com/">GCP</a>の２つのクラウドプラットフォームを組み合わせ、マルチクラウドインフラとして利用しています。<br>
<a href="http://tech.plaid.co.jp/">PLAID Enginner Blog</a>では複数回に渡ってマルチクラウドインフラを作る上で試行錯誤したポイントなどを紹介していこうと思います。<br>
今回は初回ということで概要部分について記載し、次回以降のエントリーで深掘りをしていきます。<br>
興味を持たれた方は本ブログをブックマーク等をしていただけば幸いです。</p>
<h1>目次</h1>
<ul>
<li>マルチクラウドインフラとは？</li>
<li>なぜマルチクラウドインフラを作るのか？</li>
<li>マルチクラウドインフラの構成</li>
<li>マルチクラウドインフラへの移行手順</li>
<li>まとめ</li>
<li>最後に</li>
</ul>
<h1>マルチクラウドインフラとは？</h1>
<p>私達がお話するマルチクラウドインフラとは、<br>
複数のクラウドプラットフォームを組み合わせ、それぞれのサーバが相互通信でき、あたかも１つのプラットフォームのように稼働させることができるインフラのことです。<br>
イメージにすると以下の図のようになります。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/77d17f92-74f7-4789-8e80-a0fd89074a1b/1.png" /></div>
<h1>なぜマルチクラウドインフラを作るのか？</h1>
<h2>可用性の向上</h2>
<p>各クラウドプラットフォームではそれぞれのサービスごとにSLAが定義されていますが、100%の稼働を保証するものではありません。<br>
<a href="https://cloudharmony.com/">CloudHarmony</a>というサービスで過去の稼働率を確認することが出来るのですが、例えば、<a href="https://aws.amazon.com/ec2">EC2</a>、<a href="https://cloud.google.com/compute/">GCE</a>においてもDowntimeはそこそこ発生しているようです。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/9361312a-04fd-445e-9c56-3a01eb3aa8e3/2.png" /></div>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/b3efb0ce-00bb-4ac6-afd9-a4ea45e23788/2.5.png" /></div>
<p>また、各クラウドプラットフォーム内にてMultiAZやMultiRegionの構成を取ることで可用性を高めることは可能ですが、クラウドプラットフォームの共通部分で問題が起きてしまうと、MultiAZやMultiRegion構成を取っていてもサービスダウンを避けることは出来ません。<br>
実際、GCPで<a href="https://status.cloud.google.com/incident/compute/16020#5177473553661952">LoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害</a>が発生したこともあります。<br>
複数の異なるクラウドプラットフォームで稼働させることは、単一クラウドプラットフォームの障害の影響を抑えることができ、可用性を高めることができます。</p>
<h2>パフォーマンスの向上</h2>
<p><a href="https://aws.amazon.com/products/">AWS</a>、<a href="https://cloud.google.com/products/">GCP</a>共に様々な特色のサービスを提供しています。<br>
それぞれのサービスには得意、不得意な部分があり、適材適所で使うことでアプリケーションのパフォーマンスを向上させることができます。<br>
KARTEにおいても処理の一部をGCPの<a href="https://cloud.google.com/bigtable/">Cloud Bigtable</a>に置き換えたことにより、パフォーマンスが大きく改善しました。</p>
<p>ただ、「AWSのEC2からGCPのCloud Bigtableを利用する」といったようなクラウドプラットフォームをまたいでサービスを利用する際は、以下の要素がパフォーマンスを悪化させることがあり、無視することはできません。</p>
<ul>
<li>同じクラウドプラットフォーム内からの通信に比べて Latencyが大きくなる</li>
<li>各クラウドプラットフォーム管理外のネットワークが間に挟まってしまうので、問題が起きやすくなる</li>
</ul>
<p>当然ですが、Cloud BigtableのSLAにも <code>(c) errors: (i) caused by factors outside of Google's reasonable control; </code> というようにGoogleのコントロール外の部分でのエラーはSLA適用外と明記されています。<br>
https://cloud.google.com/bigtable/sla</p>
<p>サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることで、各サービスの恩恵をより多く受け、アプリケーションのパフォーマンスを向上させることができます。</p>
<h2>コストの低減</h2>
<p>各クラウドプラットフォームのサービスを適材適所に利用するだけでコストの低減が期待できるように思えますが、何も考えずに他クラウドプラットフォームのサービスを使用してしまうと、パフォーマンスは向上はする一方で、膨大なコストがかかってしまうことがあります。<br>
Cloud Bigtableを例に考えてみます。<br>
Cloud BigtableはGCPのサービスですが、もちろんAWSからも利用することができます。しかしAWS側から利用するとなると、インターネット経由でCloud Bigtableと通信することになるので、以下の図のように <strong>データ転送コストが有料</strong>になってしまいます。</p>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/2a5a6ab0-6f8d-4e7a-8864-0ad5c52b6392/3.png" /></div>
<ul>
<li>EC2でのCloud Bigtableからのread(①)はCloud BigtableのInternet EgressとしてGCP側で課金</li>
<li>EC2からCloud Bigtableへのwrite(②)はEC2のInternet EgressとしてAWS側で課金</li>
<li>Cloud Bigtableと同RegionのGCEであればread(③)、write(④)共に無料</li>
</ul>
<p>少量のデータを扱う際には対して気にならないかもしれませんが、大量のデータを扱うサービスは注意が必要です。請求を見て寿命が縮むことになります。<br>
実際に私達もCloud Bigtableの請求を見て寿命が縮んだ経験があります。<br>
私達がCloud Bigtableを導入しようと検証していた際にはインターネット経由のデータ転送コストが <strong>無料</strong> だったのですが、あるタイミングから有料に変更になり、気がついた時には <strong>サービス使用量全体の約30%</strong> をCloud Bigtableデータ転送コストが占めていたこともありました。。コストのアラートは適切に設定しておくことをおすすめします。<br>
パフォーマンスの話と同様にコストにおいても、サーバを手軽にそれぞれのプラットフォームに配置できる状態を作り、利用サービスの近くにサーバを配置させることは重要です。</p>
<h2>そこに新しくて良い技術があったから</h2>
<p>新しいサービス/技術はどんどん触りたいし、良いものはどんどん導入したいというモチベーションが煮えたぎっていました。**「そこに新しくて良い技術があったから」**というのはプレイドのエンジニア文化として根付いています。</p>
<h1>マルチクラウドインフラの構成</h1>
<p>上記のモチベーションを元に作ってみたマルチクラウドインフラの構成概要図を掲載します。<br>
詳細は別のエントリーでお話することになると思いますが、ポイントとしては以下の通りです。</p>
<ul>
<li>AWS、GCPのPrivateNetworkをVPNで接続する。</li>
<li>Cloud Bigtableや<a href="https://cloud.google.com/bigquery/">Bigquery</a>などGCPのサービスを多く使うサーバは主にGCPで、<a href="https://aws.amazon.com/jp/dynamodb/">DynamoDB</a>などAWSのサービスを多く使うサーバは主にAWSで稼働させる。</li>
<li>特定のクラウドプラットフォームで何か問題があっても片方のクラウドプラットフォームで動くようにする。</li>
</ul>
<div style="text-align:center"><img src ="https://ik.imagekit.io/newt/61b151f921640c0018173598/11449304-378e-4495-b7d0-9e0a5a173e88/4.png" /></div>
<p>また、運用周りのツール/サービスは基本的マルチクラウド対応しているものを利用しています。以下に一部を記載します。</p>
<table>
<tr>
<th>用途</th>
<th>ツール名</th>
</tr>
<tr>
<td>インフラの構成管理</td>
<td><a href="https://www.terraform.io/">Terraform</a></td>
</tr>
<tr>
<td>マシンイメージの作成</td>
<td><a href="https://www.packer.io/">Packer</a></td>
</tr>
<tr>
<td>マシンイメージのテスト</td>
<td><a href="http://serverspec.org/">Serverspec</a></td>
</tr>
<tr>
<td>メトリックの監視/アラート</td>
<td><a href="https://www.datadoghq.com/">Datadog</a></td>
</tr>
</table>
<h1>マルチクラウドインフラへの移行手順</h1>
<p>KARTEは元々はAWS上でのみで稼働していたので、既存のAWSで作っていた仕組みをベースに以下のステップでマルチクラウドインフラへと移行していきました。<br>
ちなみに移行作業はKARTE利用ユーザに影響が出ないよう、サービス停止を伴うメンテナンス作業は実施せずに進めていきました。<br>
本エントリーでは概要を説明するにとどまりますが、各ステップで試行錯誤したポイントについては次回以降のエントリーで記載していこうと考えています。</p>
<ol>
<li>AWSとGCPをVPNで接続する</li>
<li>GCPでAWSと同じようにリソースを立てれるようにする</li>
<li>GCPでリソースを一部稼働させパフォーマンスを計測する</li>
<li>計測したパフォーマンスを元にマルチクラウドを意識した構成/コードに修正する</li>
<li>修正完了後、GCPの割合を徐々に増やしていく</li>
<li>運用を整える</li>
</ol>
<p>*3,4,5のステップは一度ではなく何度も繰り返し、構成/コードを洗練させていきました。</p>
<h1>まとめ</h1>
<h2>良かった点</h2>
<h3>可用性の向上</h3>
<p>前述したようにGCPで<a href="https://status.cloud.google.com/incident/compute/16020#5177473553661952">LoadBalancerがリクエストをサーバにフォワード出来ず、502のreponseを返すという障害</a>が発生したのですが、AWS/GCPのマルチクラウドインフラを作った後だったため、AWSに寄せて稼働させることができ、その影響を抑えることができました。</p>
<h3>パフォーマンスの向上</h3>
<p>Cloud Bigtableなど適材適所にサービスを導入し、GCPとAWSで双方で問題なく動かせるよう構成/コードを見直した結果、マルチクラウドインフラ構築前に比べ、パフォーマンスが格段に向上しました。<br>
またAWS/GCPそれぞれのサービスを導入しやすくなり、マルチクラウドインフラ構築後においても、日々パフォーマンスは改善しています。</p>
<h3>コストが 約40%低減</h3>
<p>データ転送コストを抑えつつ、パフォーマンスを向上させた結果、コストが約40%低減しました。</p>
<h3>エンジニアとしてのレベルアップ</h3>
<p>まとまった情報があまりない取り組みだったので、自分で考え抜く力、もがいて結果を出すという力が向上しました。</p>
<h2>意識しておかなければいけない点</h2>
<h3>利用サービスが増えることによって、学習コストも増える</h3>
<p>プレイドでは「新しいサービス/技術はどんどん触って、いいものはどんどん導入しようという」絶対的な文化があるので本項目は基本的には歓迎なのですが、企業文化やステージによっては考える必要があると思います。</p>
<h3>移行コストについて</h3>
<p>やってみないと分からない部分はありますが、移行に伴う以下のコストをある程度見積もっておくことは重要です。</p>
<ul>
<li>インフラのコスト：検証時、移行作業時にリソースを追加で立てる必要があるので</li>
<li>人のコスト：インフラの改修だけではなく、サービスのアーキテクチャを把握した上でコードの改修等の作業も必要になってくると思うので、それなりに覚悟は必要になります。折れない心が大切でした。プレイドではインフラ、アプリケーション、opsまで一通り修正をエンジニア2.5人×3ヶ月で実施しました</li>
</ul>
<h1>最後に</h1>
<p>私達のマルチクラウドインフラはまだ始まったばかりで、随時、拡張/改善していきたいと思っています。<br>
プレイドでは、マルチクラウドインフラをもっと成長させたい、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<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>


AWSとGCPでマルチクラウドインフラを始めた話。複数回連載予定の第一回です！

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント| PLAID engineer blog

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

<p>こんにちは、プレイドの@wikrshです。</p>
<p>弊社の<a href="https://karte.io/">KARTE</a> では属性データやサイト上での行動情報など様々なデータを元に来訪したユーザーの状況をリアルタイムに可視化しており、どのような情報の見せ方をすればよりユーザーへの理解を深められるのか、社内では日々議論・改良を重ねています。</p>
<p>今回は現在KARTEで行っているものとは異なる表現を実験してみたい + アニメーションを作るのが面白そうという動機で、「各ユーザーがサイト内の各ページを遷移している様子」の可視化に取り組んでみましたので紹介いたします。</p>
<h1>作成するアニメーションのイメージ</h1>
<p>各ページをノードとして表し、ユーザーを表すノードが各ページのノードを移っていく形で表現することを考えました。</p>
<p><code>/page1</code>を見ていたあるユーザーが<code>/page2</code>にアクセスした場合は、<code>/page1</code>を表すノードから<code>/page2</code>を表すノードへユーザーを表すノードが移動するイメージです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/890d6805-9a38-4b41-b9b8-4fd9fc66baeb/blog.001.jpeg" alt=""></p>
<p>このノードを各ページ・各ユーザーについて表示して、時刻を変化させる（再生する）ことで、各時刻でユーザーがどのように移動しているかを可視化することが今回の目標です。<br>
実装にはチュートリアルや例が豊富でありアニメーションも容易な <a href="https://d3js.org/">D3.js</a> を使用し、ブラウザ上にSVGで表示を行うことにしました。</p>
<h1>ページの表現</h1>
<p>サイト内の各ページの配置方法は様々考えられますが、今回はサイト間のページ構造に依らずに適用でき、かつ実装も容易であるため環状に配置することを考えました。</p>
<p>各ページ間の遷移についてはこれらのノード間を移動させることで表現できますが、セッションの初回アクセスは表現できません。<br>
そのため、中心にノードを一つ配置し初回アクセス時は中心のノードからアクセスページへ移動するものとします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/faccdde3-0d1f-4e0e-8ede-6d39c2355504/blog.002.jpeg" alt=""></p>
<p>また、各ページを閲覧しているユーザー数はページのノードの大きさで表現することにしました。<br>
SVGの<code>circle</code>の大きさは半径で指定しますが、面積をユーザー数に比例させたいので半径はユーザー数の平方根に比例させるようにします。</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/a4owsx0d/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h1>閲覧中のユーザーの取得</h1>
<p>今回は一般的なアクセスログを想定し、一つのレコードが、</p>
<ul>
<li>アクセス日時</li>
<li>ユーザーID</li>
<li>アクセスしたページ</li>
</ul>
<p>の情報からなるデータを使用します。</p>
<p>このデータに従ってある時刻<code>t</code>で発生したページアクセスを表示すれば良いのですが、このデータからはユーザーがいつページの閲覧を止めたか（離脱したか）は分かりません。<br>
ページアクセス以外のデータを組み合わせればより正確な離脱の計測も可能ですが、今回は簡単のためページアクセスから一定時間<code>T</code>経ったら閲覧を止めたとみなすことにします。</p>
<p>この条件の元である時刻<code>t</code>でサイトを閲覧中のユーザーを考えると、ページアクセスの時系列データの内、時刻<code>t-T</code>〜<code>t</code>でページアクセスをしたユーザーになります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a19b9522-01e0-464c-8e71-9d1dd7378a1b/blog.003.jpeg" alt=""></p>
<p>アニメーションの再生時は、この時刻<code>t</code>を進める→閲覧中のユーザーを更新という流れを繰り返して表示を行います。</p>
<h1>ユーザーのページ遷移アニメーション</h1>
<p>ユーザーがページ間を遷移するアニメーションはD3.jsの <a href="https://github.com/d3/d3-transition">transition</a>で実装します。<br>
詳細については多くのチュートリアルや例があるので割愛しますが、D3.jsを使用するとシンプルにアニメーションを実装できます。</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/hbgb5v3v/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>注意点としては、ユーザーとノードを対応させるためにユーザーIDをキーとして渡す必要があります。<br>
これを行わないと、異なるユーザーのノードが使われてしまう可能性があります。</p>
<p>キー指定無し：</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/bjzkmnfe/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>キー指定有り：</p>
<iframe width="100%" height="200" src="//jsfiddle.net/wikrsh2/sdcuzkxp/embedded/result,js/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p>上の例ではデータ上は2人のユーザーがページを遷移していますが、キー指定無しの場合はノードとユーザーの紐付けが行われないため、遷移が起こっていないように見えてしまいます。</p>
<h1>作成したアニメーション</h1>
<p>弊社の運営する<a href="http://shopping-tribe.com/">Shopping Tribe</a>へのある日のアクセスデータをサンプリングした上で抽出してアニメーションを作成してみました。<br>
ノード数を抑えるためにアクセス数の上位49ページをそれぞれ一つのノードで表し、残りのページへのアクセスは一つのノード（<code>others</code>）にまとめて表現しました。</p>
<iframe src="https://player.vimeo.com/video/207268708" width="640" height="668" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
<p>作成したアニメーションを眺めていると、</p>
<ul>
<li>各ページへのアクセスのほとんどはサイト外からの流入で行われており、トップページ等サイト内での遷移からのアクセスの割合は多くない</li>
<li>アクセスの集中しているページとその他のページ間の遷移が多いわけではなく、決まった遷移の流れにはなっていない</li>
<li>アクセス数が上位49ページに入っていないページへのアクセス割合が比較的大きく、幅広くアクセスが発生している</li>
</ul>
<p>といった大まかな傾向は見てとれますが、新しい知見を得るためにはまだまだ改良が必要そうです。</p>
<h1>最後に</h1>
<p>今回行ってみたユーザー行動の可視化では、大まかなユーザーの動きの傾向や時間帯ごとの動きの違い程度の傾向はつかめるように思いますが、データから新しい知見を得るという点までは達しておらず、サイトに来訪したユーザーについての理解を深めるためには改良が必要そうです。</p>
<p>ここから意義のある知見を得られるレベルまで改良するには、</p>
<ul>
<li>個々のユーザーをどのように表現するか</li>
<li>各ページのノードをどのように配置するのが良いか</li>
</ul>
<p>が主なポイントになるかと思います。</p>
<p>特に、個々のユーザーの表現方法については、KARTEに取り込まれたユーザー情報やセグメント情報と合わせればより多くの知見を得られるのではなかと思いますので、より良い表現を考えたいところです。<br>
また、今回は閲覧データのみを使用しましたが、KARTE上には購入や会員登録を含む様々な行動データが存在するため、閲覧よりもより細かい行動の遷移を見るのも面白そうです。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<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>


D3.jsを使ってユーザーがサイト内の各ページを遷移している様子をアクセスログから可視化してみました。

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた | PLAID engineer blog

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ab738df8-3e11-4248-b37b-c8b4f16dfd83/16196179_1291472420896304_1281133783_o--1-.png" alt=""></p>
<p>こんにちは！<br>
プレイド エンジニアの@ikemonnです。</p>
<p>2/22(水)に開催しました「<a href="https://plaidtech.connpass.com/event/49170/">【KUFU×プレイド】Tech Meetup ~Docker編~</a>」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ECS を使って PR ごとに検証環境を用意した話</li>
<li>CIにWerckerを使うべき5つの理由</li>
<li>Building Minimal Docker Containers</li>
<li>Docker社が買った会社</li>
<li>効率的なdocker build用directory構造について</li>
</ul>
<h2>ECS を使って PR ごとに検証環境を用意した話</h2>
<p>まず<a href="http://kufuinc.com/">KUFU</a> <a href="http://twitter.com/elbowroomer">@elbowroomer</a>さんから「ECS を使って PR ごとに検証環境を用意した話」というテーマで発表がありました。</p>
<p>もともと検証環境が1台だったところを、ECS &amp; Dockerを使ってPRごとに検証できるようにされたとのことでした！</p>
<p>修正内容を、文字やスクリーンショットベースではなく、実際に触って試せるのは良いですね！</p>
<iframe src="//www.slideshare.net/slideshow/embed_code/key/gZ4hajTEanBRb" width="100%" height="533" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/AtsushiYoshinari1/ecs-pr-72456169" title="ECS を使って PR ごとに検証環境を用意した話" target="_blank">ECS を使って PR ごとに検証環境を用意した話</a> </strong> from <strong><a target="_blank" href="//www.slideshare.net/AtsushiYoshinari1">Atsushi Yoshinari</a></strong> </div>
</div>
<p>詳細はブログに書いてくださっているので、併せてお読みください！</p>
<p><a href="http://tech.smarthr.jp/tech/466">「ECS を使って PR ごとに検証環境を用意した話」というテーマで登壇しました！ | SmartHR Tech Blog</a></p>
<h2>CIにWerckerを使うべき5つの理由</h2>
<p>次に<a href="https://plaid.co.jp/">PLAID</a> <a href="https://twitter.com/algas">@algas</a>から<a href="https://algas.github.io/plaid-meetup-20170222/#1">CIにWerckerを使うべき5つの理由</a>というテーマで発表がありました。</p>
<p>CIをしていると</p>
<ul>
<li>CIが何をしているのか把握できない</li>
<li>CIと同じ環境を構築できない</li>
<li>CIで起こった問題が再現できない</li>
</ul>
<p>という部分でハマりがちです。</p>
<p>「ローカルでは動くのにCIでコケた」のような状況を、<a href="http://www.wercker.com/">Wercker</a> というDockerネイティブなCIサービスを使えば解決できるという話でした！</p>
<p>弊社ではお客様に配布するJSファイルをbuildする部分からWerckerを取り入れ始めています！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/01a66a0e-7bfc-4347-a54e-762f53ce81d1/----------2017-03-01-14.47.46-1.png" alt=""></p>
<p><a href="https://algas.github.io/plaid-meetup-20170222/#1">スライドはこちら！</a></p>
<h2>Building Minimal Docker Containers</h2>
<p>続いて<a href="https://twitter.com/yepn">@gavinzhm</a> さんから「Building Minimal Docker Containers」というテーマで発表がありました。</p>
<p>軽量なLinuxディストリビューションである<a href="https://www.alpinelinux.org/">alpine Linux</a>を用いてイメージを作ったり、必要なレイヤーだけを注意深く選ぶことでビルド時間を短縮したりと実践的な内容でした！</p>
<script async class="speakerdeck-embed" data-id="bd98fa070456443096f8ebffc688b9c5" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>Docker社が買った会社</h2>
<p>次にPLAID <a href="https://twitter.com/otoan52">@otolab</a>から「Docker社が買った会社」というテーマで発表がありました。</p>
<p>Docker社が今まで買収した会社と、その買収によってどのような機能が実装されてきたか &amp; 今後どのような機能が実装されそうかということを発表してもらいました！</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bbc96057-b5ad-48cc-a922-cf38fa68f556/----------2017-03-02-11.09.23.png" alt=""></p>
<p><a href="https://otolab.github.io/plaid-meetup-20170222/#1">スライドはこちら！</a></p>
<h2>効率的なdocker build用directory構造について</h2>
<p>最後に<a href="https://twitter.com/negabaro">@kimsehwa</a>さんから「効率的なdocker build用directory構造について<br>
」というテーマで発表がありました。</p>
<p><code>Git push -&gt; CI -&gt; Docker build, run, push</code> といったフローを行いたい時に、どのようなディレクトリ構成にするのが効率的かという内容でした！</p>
<script async class="speakerdeck-embed" data-id="f12a99e526614ad58a2cf5dadf610191" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを支えるマルチプラットフォームインフラに興味がある！KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<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>


2/22(水)に開催しました【KUFU×プレイド】Tech Meetup ~Docker編~のレポートです。
「ECS を使って PR ごとに検証環境を用意した話」「CIにWerckerを使うべき5

【KUFU×プレイド】Tech Meetup ~Docker編~を開催しました！

エディタ、ターミナル、UNIXシェルについて、PLAIDのエンジニアが何を使っているのか、アンケート形式で訊いてみた。果たして、1位のエディタは？

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの開発ツール調べてみた〜 | PLAID engineer blog

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの使っている開発ツール調べてみた〜

<p>こんにちは。プレイドの＠etoです。<br>
プレイドではバックエンド全般から外部API連携までを担当しています。</p>
<p>うちの妻がBot作りたいとか言ってたので、自分で作れるようにサポートしてみました。<br>
妻はエンジニアではありませんのでコード書いたりとか一切なしです。</p>
<p>設定して動作確認するところまでで、簡単につくれるLINE BOTの話になります。</p>
<h2>目次</h2>
<ol>
<li>BOT作りたい</li>
<li>事前準備編</li>
<li>動作確認編</li>
<li>その他できそうなこと</li>
<li>まとめ</li>
</ol>
<h2>BOT作りたい</h2>
<p>妻「チャットボット作りたい。作って。」</p>
<p>わし「えっ、自分（の会社）でやればいいじゃん。」</p>
<p>妻「無理。何とかして。」</p>
<p>わし（なんとかしてって言われても・・・）</p>
<p>(注)実話を元にしたフィクションです。</p>
<p>という感じで、<s>妻の機嫌が悪くならないように</s>簡単にBOT作れないか考えていたところ、<br>
登録したけど全く使ってなかった<code>docomo Developer support</code>からちょうどいい感じのメールが届きました。</p>
<p><code>Repl-AIに「LINE連携用シナリオ」のテンプレートが追加されました。（中略）Repl-AIであればLINEを簡単に自動応答させることができます。（後略）</code>とあるではないですか。<br>
折しもプレイドで LINE Messenger API をやったばかりということもあり、LINEとこれで妻<s>をちょろまかす</s>に LINE BOT 作らせてみればよくないかと思ったわけで、実際にやってもらってみました。</p>
<p>本稿とは一切関係ありませんが、プレイドには有能なBOTがいっぱいあります。<br>
こちらで紹介してありますのでどうぞ。<br>
/making-slack-bot-with-lambda/</p>
<h2>事前準備編</h2>
<p>まずは Repl-AI に登録します。<br>
アカウント自体はdocomo Developer support(dDs)なのでこっちに登録すればログインできるようになります。<br>
Repl-AI にログインしてクレジットカード情報を登録すれば使えるようになります。</p>
<p>LINEと連携する方法ですが、ドキュメントがあるのでこちらを参考にすれば簡単にできます。<br>
https://repl-ai.jp/#docs/tutorial/line<br>
基本的にはLINEとRepl-AIのアカウントがあればできる感じです。</p>
<ol>
<li>LINE BUSINESS CENTER に LINE のアカウントでログインしビジネスアカウントを作成</li>
<li>LINE@MANAGER のアカウント設定からBot設定に行きAPIを利用する</li>
<li>同じようにWebhook送信を利用する</li>
<li>LINE Developers で必要な情報の確認する</li>
</ol>
<p>わかりにくいのは LINE  側の設定が LINE@MANAGER と LINE Developers にわかれているあたりでしょうか。</p>
<p>前準備はこれで完了です。</p>
<h2>動作確認編</h2>
<p>次は Repl-AI でBOTを作ってLINEと連携させます。</p>
<h3>1.新規プロジェクト作成</h3>
<p>プロジェクト名を入れでプランを選択して保存します。<br>
とりあえずなので Light で問題ありません。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/26707329-b553-401c-a410-f2807c3e1795/----------2017-01-30-13.07.10.png" alt=""></p>
<p>無料期間を過ぎると自動で課金されてしまいますので注意が必要です。<br>
退会しなくてもプロジェクトを削除してしまえば問題ないかと思います。</p>
<h3>2. 新規ボット作成</h3>
<p>ボットIDとボット名を入れるだけです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cd472223-bec9-45ea-aa7a-5fd27f25b976/----------2017-01-30-13.10.05.png" alt=""></p>
<h3>3. 新規シナリオ作成</h3>
<p>シナリオIDとシナリオ名を入れて、連携ボットシナリオを選択しましょう。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/32947865-2e29-41f7-b631-f712dc50235e/----------2017-01-30-12.23.06.png" alt=""></p>
<h3>4. LINE連携</h3>
<p>LINE Developers から各種情報を入力<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5e2fde64-9dca-4c85-b94f-74e9a397168a/----------2017-01-30-13.12.53.png" alt=""></p>
<p>LINE Developers に Repl-AI から発行されるWebhook URL をコピペしましょう。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/eb56e28d-aae7-490c-80b1-f7e528767bed/----------2017-01-30-10.23.30.png" alt=""></p>
<h3>5. LINE Developers のQRコードからLINEで友達になる</h3>
<p>これで動作確認できます。<br>
Repl-AI 単体でもシミュレータから動作確認できたりするので便利です。</p>
<p>連携ボットシナリオ中身は以下のようになってます。</p>
<ul>
<li>「教えて」が含まれる発言に対して「知識Q&amp;Aボット」</li>
<li>「ニュース」が含まれている発言に対して「トレンド記事ボット」</li>
<li>その他は「雑談対話ボット」</li>
</ul>
<p>LINE上で話しかけて反応を楽しみましょう。</p>
<p>妻「なんかできてる。でも会話成立してなくない？」</p>
<p>わし「何もしてないしそんなもんよ。」</p>
<p>妻「思ってたのと違うんだけど、どうやったらちゃんと作れるの？」</p>
<p>わし（ネタにしかならんかったか・・・）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/52f0a22f-451f-41c6-8cb3-9b0ac86f0b86/----------2017-01-30-18.44.35.png" alt=""></p>
<h2>その他できそうなこと</h2>
<p>ここまでは簡単に誰にでもできると思います。<br>
次はシナリオに対応したBOTを作るためにはどうすればいいかですが、ある程度まではRepl-AIで簡単にできそうです。</p>
<p>上の手順の新規シナリオ作成の部分で「LINE連携シナリオ」を選択します。<br>
LINE Messenger API の内 Imagemap を除くAPI の雛形が用意されています。<br>
以下の文字を入力すると対応する応答が用意されていますので、好きにカスタマイズしてみてください。<br>
()内はLINE Message API での呼称です。</p>
<ul>
<li>テキスト (Text)</li>
<li>画像 (Image)</li>
<li>動画 (Video)</li>
<li>音楽 (Audio)</li>
<li>位置 (Location)</li>
<li>スタンプ (Sticker)</li>
<li>ボタン (Template Button)</li>
<li>確認 (Template Confirm)</li>
<li>カルーセル (Template Carousel)</li>
</ul>
<p>LINE BOT の中身として使用するのであれば結構有力な候補になると思います。<br>
お値段はそれなりですが、サーバーが不要なのとエンジニアでなくても作れそうなのでいいと思います。</p>
<p>こんな感じのが欲しいらしい。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/675eefaf-eebe-40cd-bd3a-188acafc9699/----------2017-01-30-18.35.19.png" alt=""></p>
<p>青い東京タワーの写真を表示するの図</p>
<h2>最後に</h2>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a></p>
<p>または<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>


ある日突然チャットボット欲しいと言われ、楽にLINEでBOTを作る方法を模索し、実際に5分で作れるか試してみました

Engineer Blog

Recent Article

【エンジニアの】バルマーピークは本当にあるのか検証してみた【夢？】

山梨県河口湖に開発合宿へ行ってきました！

Bit Matrixを使って超高速にアグリゲーションする

AWSとGCPのマルチクラウドインフラ検証の進め方

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた

【KUFU×プレイド】Tech Meetup ~Docker編~を開催しました！

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの使っている開発ツール調べてみた〜

誰でも5分で作れるLINE BOTを試してみた

Popular Articles

Popular Tags

Archives

Writers

Recent Article

【エンジニアの】バルマーピークは本当にあるのか 検証してみた【夢？】

山梨県河口湖に開発合宿へ行ってきました！

Bit Matrixを使って超高速にアグリゲーションする

AWSとGCPのマルチクラウドインフラ検証の進め方

AWSとGCPのマルチクラウドインフラにおけるVPN設計のポイント

AWSとGCPでマルチクラウドインフラを構築した話とそのポイント

データの可視化に使えるD3.jsでユーザーのページ遷移を表現してみた

【KUFU×プレイド】Tech Meetup ~Docker編~を開催しました！

最強のエディタ、ターミナル環境はこれだ！〜PLAIDエンジニアの使っている開発ツール調べてみた〜

誰でも5分で作れるLINE BOTを試してみた

Popular Articles

Popular Tags

Archives

Writers

【エンジニアの】バルマーピークは本当にあるのか検証してみた【夢？】