Engineer Blog

Takuma Shibuya

plaidinc

Hideyuki Okada

Daikichi Sasamori

Kazuto Kojima

Atsushi Kobayashi

Kenichi Suzuki

Wataru Ikarashi

Nobuhiro Ito

Kei Tamiya

Shinnosuke Ozawa

Hiroto Harada

kazushi oohira

Tatsuya Monoi

Naoki Shibayama

daigo.isamatsu

Ryosuke Suzuki

Jumpei Ikegami

Takuya Ogawa

Yohei Meguro

Tomoki Koga

Rei Ishikawa

Naoto Kato

koichi tanaka

Masahiro Yamauchi

Yoshiyuki Komazaki

Yuki Makino

Takaaki Nakama

kantetsu

akira.kasuga

kazupon

Shinji Eto

Yu Nishimura

Arnaud Avondet

Atsushi Fujikawa

Yuta Nishimura

mizchi

Takumi Katayama

Kohei Kadowaki

Kosuke Oya

Blocks Team

Yohei Noda

Takami Yamada

Daiki Matsui

Jun Kusahana

Naohiko Takemura

Takahiro Tokunaga

Security Team

Makoto Kataigi

AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術

インクリメンタルに新しい技術を取り入れる方法。TypeScriptへの移行を例にしたプロセス

CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方

2021年9月14日に正式リリースしたKARTE Blocksの裏側を紹介する連載の第一弾です。
KARTE Blocksを支える技術とその技術を選んだ理由について紹介します。

KARTE Blocksを支える技術

リリース後に落ちないように、新規サービスで備えておいたこと

<p>こんにちは、エンジニアの oga です。</p>
<p>5/12(日本時間)にGoogle I/Oで <a href="https://cloud.google.com/alloydb/">AlloyDB</a> と呼ばれる新しいデータベースプロダクトがアナウンスされました。<br>
アナウンスブログ: <a href="https://cloud.google.com/blog/ja/products/databases/introducing-alloydb-for-postgresql">AlloyDB for PostgreSQL を発表：高額なレガシー データベースからの解放 | Google Cloud Blog</a></p>
<p>PLAIDでは、Private previewの段階で紹介をして頂き非常に興味深いものだったのでpreviewに参加して検証を行なっていて、以下の様なコメントを寄稿させて頂きました。<br>
<img src="https://ik.imagekit.io/plaid/3108b9ec-ad62-483a-ab17-f622e7b0522c/1000x1000/alloydb_plaid_quote.png" alt="alloydb_plaid_quote.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>以下和訳</p>
<blockquote>
<p>「PLAID では CX (顧客体験) プラットフォーム KARTE を企業向けに開発・提供しています。KARTE は膨大な行動ログから深い洞察を得る先進的なリアルタイム分析機能を持ち、顧客に合わせた最適なコミュニケーションを可能にしています。AlloyDB は PostgreSQL と完全互換であり、透過的に列方向処理を行うことができます。私たちはこれが新しく強力なオプションであると捉えており、OLTP・OLAP・HTAP と分断されたワークロードを統合したシステムデザインを最小限の追加知識で実現する、ユニークな技術的アプローチであると考えています。将来的には Google Cloud の他の強力なデータベース サービスとの連携も強化され、私たちのKARTEが提供する分析機能において、より優れたパフォーマンス、スケーラビリティ、拡張性をもたらすことを期待しています。」</p>
</blockquote>
<p>この記事では、AlloyDBの特徴とPLAIDで今後どの様に使っていきたいかをご紹介します。</p>
<hr>
<section class="widget widget-text">
	<div id="toc"></div>
</section>
<style>
    div#toc ol {
        margin: 0 0 0 25px;
    }
    div#toc ol li {
        margin: 0;
        padding: 1px;
        list-style-type: disc;
    }
</style>
<hr>
<h2>はじめに</h2>
<p>AlloyDBはPreviewフェーズである為、今後の機能追加や仕様変更も多く発生すると思われます。<br>
この記事では、現時点の仕様情報とそれに基づく見解を記載しています。<br>
<strong>最新の情報は必ず<a href="https://cloud.google.com/alloydb/docs/overview">GCPの公式ドキュメント</a>をご確認下さい。</strong></p>
<h2>AlloyDBの特徴</h2>
<ul>
<li>PostgreSQLとの完全互換</li>
<li>高パフォーマンス</li>
<li>columnar engine（高速なOLAP）</li>
<li>柔軟で高い可用性を持った構成</li>
<li>機械学習による自動化されたリソース管理</li>
<li>シンプルな料金体系</li>
</ul>
<h3>PostgreSQLとの完全互換</h3>
<p>文字通り、PostgreSQLを使用するアプリケーションやエコシステムはAlloyDBで変更する必要無くそのまま適用することができます。<br>
弊社ではそういったアプリケーションは無かったものの、検証においてCLI,GUIツールなど今まで培われてきたPostgreSQLのものをそのまま使用でき、<br>
開発や運用に関わるベストプラクティスも大部分は同じ様に適用できそうなので非常に効率良く移行ができると感じました。</p>
<p>サポートされるパラメータや拡張は決まっている為、既存のPostgreSQLインスタンスを移行する場合や実現したい機能に必要な拡張があるかは事前に以下のドキュメントで確認することができます。</p>
<ul>
<li><a href="https://cloud.google.com/alloydb/docs/reference/database-flags">Supported database flags  |  AlloyDB for PostgreSQL  |  Google Cloud</a></li>
<li><a href="https://cloud.google.com/alloydb/docs/reference/extensions">Supported database extensions  |  AlloyDB for PostgreSQL  |  Google Cloud</a></li>
</ul>
<p>マイグレーションに関しては、<a href="https://cloud.google.com/database-migration">Database Migration Service</a>でサポートされることになると思われます。また、異なるDBを使用しているなど複雑で支援が必要な場合では<a href="https://cloud.google.com/resources/database-migration-program">Database Migration Program</a>で移行支援も受ける事ができます。</p>
<h3>高パフォーマンス</h3>
<p>パフォーマンス面は大きく優位性があるとのことで、標準のPostgreSQLと比較してOLTPが4倍、OLAPでは100倍のパフォーマンスであると発表されています。</p>
<table>
<thead>
<tr>
<th>OLTP</th>
<th>OLAP</th>
</tr>
</thead>
<tbody>
<tr>
<td><img src="https://ik.imagekit.io/plaid/f5bcca91-4418-4b25-beb3-5d149f7f47c5/1000x1000/alloydb_4x.png" alt="alloydb_4x.png"></td>
<td><img src="https://ik.imagekit.io/plaid/26e2432e-5fec-4770-8e22-dd65f9599daf/1000x1000/alloydb_100x.png" alt="alloydb_100x.png"></td>
</tr>
</tbody>
</table>
<p><a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>PostgreSQLと互換性を保ちながら、内部のストレージやキャッシュシステム等は独自的なものに変更されている様です。<br>
特にストレージについては別のブログポストで解説されていますが、ストレージを分離することでストレージのスケーラビリティを向上させつつI/Oによるブロック時間を極力低減させる構造を作り、トランザクション処理の高速化やレプリケーションの低遅延などを実現している様です。<br>
<a href="https://cloud.google.com/blog/products/databases/alloydb-for-postgresql-intelligent-scalable-storage">AlloyDB for PostgreSQL intelligent scalable storage | Google Cloud Blog</a></p>
<p>実際にはそれぞれのワークロードの特性やコストバランスに依るところが大きいにしても、<br>
既に運用しているPostgreSQLをそのまま置き換えることを検証する価値はあると感じます。</p>
<h3>columnar engine（高速なOLAP）</h3>
<p><img src="https://ik.imagekit.io/plaid/e6d50050-ec77-42d4-a034-486461dd600d/1000x1000/alloydb_columnar_engine.png" alt="alloydb_columnar_engine.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>PLAIDでも最も注目し検証している機能が、この<a href="https://cloud.google.com/alloydb/docs/columnar-engine/about">columnar engine</a>です。<br>
OLAPの100倍高速化、という特徴はこのcolumnar engineにより実現されています。</p>
<p>本来行指向データベースであるPostgreSQLに列指向データベースとしての特性を<strong>透過的</strong>に加えることができ、<a href="https://cloud.google.com/alloydb/docs/columnar-engine/quickstart">セットアップ</a>を行うとインメモリ上でカラムデータを保持する様になり、クエリ側は特殊な記法などは無く列指向のスキャンが行えるかは内部で自動判断されます。<br>
また、完全にcolumnar engineで列指向スキャンされるカラムに対してはindexが不要になる為、削除することで負荷削減に繋がります。</p>
<p>インメモリに対してどのテーブルのどのカラムを保持するべきか、実行されたクエリに基づき判断する<a href="https://cloud.google.com/alloydb/docs/columnar-engine/quickstart#auto-populate">レコメンデーション機能</a>が用意されているので、既存のデータとワークロードを移行しつつ、強く意識せずにOLAP処理を高速化するという導入の仕方も可能かと思います。（弊社では検証の特性上、<a href="https://cloud.google.com/alloydb/docs/columnar-engine/manage-content-manually">手動での管理</a>で行なっていました）</p>
<p>列指向はより巨大なデータを扱うDWHで特に採用されることが多く、大量データの分析処理に適しています。<br>
つまりAlloyDBで従来の行指向データベースとしての適所であるOLTPのワークロードをカバーしつつ、<br>
列指向の特性を加えてOLAPのワークロードも同データベースでカバーできる可能性があるということです。<br>
マスターとして使用するRDBMSから主にデータ分析用途などでDWHにデータをロードするという流れは良くに行われていると思いますが、<br>
統合されたシンプルなアーキテクチャを実現しつつ同時に高速化を狙う選択肢が持てるのは魅力的です。</p>
<h3>柔軟で高い可用性を持った構成</h3>
<p>AlloyDBではClusterという単位毎に1つのPrimaryとオプショナルで複数のRead poolインスタンスを構成することができます。<br>
<img src="https://ik.imagekit.io/plaid/28c94b66-45b9-41c2-b3b0-91a38d0c5593/1000x1000/adb-resource-tree.png" alt="adb-resource-tree.png"><br>
<a href="https://cloud.google.com/alloydb/docs/overview#hierarchical_resource_structure">Hierarchical resource structure</a> より引用</p>
<p>PrimaryはHAを選択すれば自動フェイルオーバーするStand-byが構成されます。<br>
Read poolは読み取り専用のレプリカとして使用でき、特にリソースを多く使う分析クエリはRead pool側に流すという構成を取ることで書き込み処理に影響を与えず処理を載せることができます。複数構成することができるので、例えば負荷特性の異なる機能に応じてRead poolを分け、マシンスペックやノード数、パラメータをそれぞれで調整するといったことも簡単に行えます。<br>
ただし、Read poolは非常に短時間ながらPrimaryに対してラグがある為、完全な一貫性が必要で無い機能で使用することになります。</p>
<h3>機械学習による自動化されたリソース管理</h3>
<p><img src="https://ik.imagekit.io/plaid/df5df673-52a6-4c10-9271-afa9a6eb150e/1000x1000/alloydb_autopilot.png" alt="alloydb_autopilot.png"><br>
<a href="https://www.youtube.com/watch?v=o5pKfH0Tonw">Introducing AlloyDB, a PostgreSQL-compatible cloud database service</a>　より引用</p>
<p>詳細な仕様についてはまだ情報が無い様ですがコストやパフォーマンスに関わるDB管理の自動化が行われる機能があり、経験値と手間が必要なベーシックなチューニング作業は任せることもできそうです。</p>
<h3>シンプルな料金体系</h3>
<p><a href="https://cloud.google.com/alloydb/pricing">https://cloud.google.com/alloydb/pricing</a></p>
<p>現状は非常にシンプルで、CPU・メモリ/ストレージ/NWによりテーブルが決まります。NWはEgressのみが課金です。<br>
プレビュー期間中はFair Usage Limitsに基づき無料で試すことができます。</p>
<h2>PLAIDで行なっていた検証と今後どの様に使っていきたいか</h2>
<p>上記の通りAlloyDBはPostgreSQLとの完全な互換性があり、すでにPostgreSQLを使用しているアプリケーションを変更すること無く移行が可能なことが特徴の一つですが、弊社では既存システムで使っている訳では無いので、分かりやすい検証事例はまだありません。</p>
<p>PLAIDでは OLTP/HTAP/OLAP 様々なデータ処理においてBigtableやSpanner、BigQueryといったGoogle Cloudのデータベースプロダクトを使い倒していますが（<a href="https://tech.plaid.co.jp/google-cloud-day-digital-2022">ご参考</a>）、<br>
その上でもcolumnar engineをはじめとしてして分析機能での活用で大きなパフォーマンス改善につながるポテンシャルを持っていると考え特にOLAPの拡張の観点を中心に検証を行なっています。</p>
<p>その為、上に挙げた様な他のGoogle Cloudのデータベースとのインテグレーション機能の追加にも強く期待しており、今後の機能拡張もウォッチしながら引き続き検証を進めていく予定ですので、また折々でご紹介できればと思います。</p>
<h2>最後に</h2>
<p>弊社では <a href="https://karte.io/">KARTE</a> をはじめ、事業においてデータを中心におき展開しています。<br>
より大量のデータを、より早く、柔軟に処理する為に様々なデータベースを活用しており、今後もよりもっと多くのデータベースを試し導入しながら良いプロダクトを作っていきたいと考えています。<br>
データベースが好きな方にとってはとても楽しい環境だと思うので、ぜひ興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>
<script>
    /**
     * For displaying a table of contents - pass the entire document (DOM) to getTocMarkup
     */

    function getHeaderLevel(header) {
        return Number(header.nodeName.slice(-1));
    }

    function createTocMarkup(headers) {
        var prevLevel = 1;
        var output = "";

        headers.forEach(function(h) {
            var currLevel = getHeaderLevel(h);
            if (currLevel > prevLevel) {
                var ranOnce = false;
                while (currLevel > prevLevel) {
                    if (ranOnce) {
                        output += "&nbsp;";
                    }
                    output += "<ol style=\"margin-bottom:0px\"><li>";
                    prevLevel += 1;
                    ranOnce = true;
                }
            } else if (currLevel == prevLevel) {
                output += "</li><li>";
            } else if (currLevel < prevLevel) {
                while (currLevel < prevLevel) {
                    output += "</li></ol>";
                    prevLevel -= 1;
                }
                output += "<li>";
            }

            output += `<a href="#${h.id}">${h.innerText}</a>`;
        });

        if (output != "") {
            // Change 2 to the max header level you want in the TOC; in my case, H2
            while (prevLevel >= 2) {
                output += "</li></ol>";
                prevLevel -= 1;
            }
            output = `<h2 class="widget-title">目次</h2>${output}`;
        }

        return output;
    }

    function getTocMarkup(document) {
        // I was only interested in the headers within the element that had the .post-content class,
        // which is specific to the Ghost blog. If you're using this elsewhere, or are interested in
        // the entire document, delete this line and use document.querySelectorAll(...) on the next line.
        var body = document.getElementsByClassName('Article_Body_JS')[0];

        // Add or remove header tags you do (or don't) want to include in the TOC
        var headers = body.querySelectorAll('h2, h3, h4, h5, h6');

        // Change the number to 1 if you want headers no matter what.
        // Or if you want at least 3 headers before generating a TOC, change it to 3.
        if (headers.length >= 2) {
            return createTocMarkup(headers);
        } else {
            return "";
        }
    }
</script>
<script type="text/javascript">
    document.getElementById('toc').innerHTML = getTocMarkup(document);
</script>


5/12(日本時間)にGoogle I/Oで AlloyDB と呼ばれる新しいデータベースプロダクトがアナウンスされ、弊社のコメントもイベント内で引用して頂きました。この記事では、AlloyDBの特徴とPLAIDで今後どの様に使っていきたいかをご紹介します。

AlloyDBのPrivate previewに参加し、Google I/Oでコメントが引用されました

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a>  です。<br>
2022/04/19 - 2021/04/21 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-22">Google Cloud Day: Digital '22</a> に 弊社2名で「機械学習」「データベース」の2テーマでそれぞれ登壇してきました。</p>
<p>こちらのブログでもその内容を簡単にまとめておきます。</p>
<h1>「MLOps 再入門！ Vertex AI で広がる MLOps の世界と実践例」</h1>
<p>こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。</p>
<p>これまではKubeflow Pipelineなどを用いてエンジニアとデータサイエンティストの協業で開発・運用してきたML基盤を、Vertex Workbenchを用いることでデータサイエンティストのみで開発・運用できるようにした点が今回のポイントです。</p>
<p>エンジニア工数ゼロで迅速にMLOpsができるようになるこの仕組みを「Light MLOps」と名付けました。</p>
<p><a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-22/watch?talk=d1-ml-10">セッション動画</a>ではさらに具体的にVertex Workbenchの使い方も含めて紹介しているので、ご覧いただければ幸いです。</p>
<p><a href="https://speakerdeck.com/kargo113/lightmlops-using-vertex-workbench">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-id="fe1fdf90e424490f8007a6d81708db4d" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「Bigtable を使いこなす！KARTE で秒間 13 万イベントを 0.x 秒以内に捌く秘訣」</h1>
<p>こちらは<a href="">@kusahana</a>よりご紹介致しました。</p>
<p>今まで多くのエンドユーザー（累計145億UU）のエンドユーザーの行動データをリアルタイム（0.x秒）で解析するために、どう私たちがBigtableを活用しているかを紹介しました。<br>
特にリアルタイム解析基盤の刷新に伴い、Bigtableの使い方を見直した結果を具体的な数値交えて共有しています。<br>
スキーマ変更によるパフォーマンスやコスト上の改善効果、Bigtableをスケーラブルなキューとして使う新たなユースケースなど、是非紹介したいのでご覧いただければ幸いです。</p>
<p><a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital-22/watch?talk=d2-db-02">セッション動画</a></p>
<p><a href="https://speakerdeck.com/kusahana/cloud-bigtable-woshi-ikonasumi-jue-2022">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。</p>
<script async class="speakerdeck-embed" data-slide="1" data-id="078fbb8e1eea42229f06723d4a28878e" data-ratio="1.77725118483412" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
<p>全体を通して、基調講演含め他社様の事例や製品の最新情報などを知ることができ、非常に勉強になりました。ご紹介したように、弊社は「データによって人の価値を最大化する」というミッションのもと、様々なプロダクトを迅速に開発しているので、来年も新たな情報を踏まえて登壇できたら良いなと思っています。</p>
<p>そんな弊社ではスピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>


Google Cloud Day: Digital '22 で「MLOps 再入門！ Vertex AI で広がる MLOps の世界と実践例」等、2セッション登壇しました

Google Cloud Day: Digital '22 にて 機械学習/データベース について2セッション登壇しました

PLAIDのインターンを振り返って ~ 開発環境の改善がもたらす新機能リリースの効率化 ~

<p>こんにちは、エンジニアのmkataigiです。</p>
<p>突然ですが、PLAIDエンジニアブログをリニューアルしていました！</p>
<p>このブログは2016年4月から、プレイドのエンジニアが日々の開発業務のなかで得たさまざまな知見を、社内外の皆さんへと共有する場として運営されてきました。おかげさまで公開済みの記事は100件を超え、各記事を通じてたくさんの方々に私たちのパーソナリティについて知ってもらうことができたのではないかと感じています。</p>
<p>今回は、そんなPLAIDエンジニアブログを（なんとフルスクラッチで！）リニューアルしたので、その経緯や感想について簡単にまとめてみたいと思います🚀</p>
<h2>リニューアルの動機</h2>
<h3>ページビューや採用ページへの流入数が思った以上に多いことが判明</h3>
<p>このブログは、「社外の人にプレイドの中のエンジニアのユニークなパーソナリティを知ってもらうこと」を目的として運営されてきました。（参考: <a href="https://tech.plaid.co.jp/start-engineerblog">プレイドのエンジニアブログを始めました！</a>）</p>
<p>そのため（？）当ブログは、基本的にはエンジニアが書きたいことを自由に書くという風土のもと、良くも悪くもなんとなく運営されていたところがあります。</p>
<p>そんな中で、最近あらためて調べてみると、どうやら思った以上に当ブログからの採用ページをみに来てくれる人が多いということが判明しました。また、社内メンバー数名に話を聞いてみたところ「入社前にブログを見てエンジニアチームの雰囲気を知れたことでプレイドに興味を持った」という声もあがってきました。</p>
<p>こうしたことから、エンジニアが書きたいことを自由に書くというスタンスは活かしながら、ブログ本体の読みやすさや体験を改善することで、このブログのポテンシャルをもっと活かせるのでは？という認識を持つようになりました。</p>
<h3>旧ブログは実質メンテナンス不可能で入稿以外では放置状態だった</h3>
<p>旧ブログは、<a href="https://ghost.org/">Ghost</a> というブログサービスを使って作りました。プレイドでは、Ghostをセルフホストする形で運用しており、デザインは<a href="https://themeforest.net/item/cedar-responsive-ghost-theme/13127587">良い感じのサードパーティ製テーマ</a>を購入して適用しました。こうすることで、時間と手間をかけずにクオリティの高いオリジナルのブログを立ち上げることができました。</p>
<p>ただ、時間が経つにつれてデザイン面やパフォーマンス面での課題感も目立ち始めていました。具体的には、「文字や画像のサイズ感がおかしい」「記事の一覧性が悪い」「記事の表示速度が遅い」など、いくつかの課題が出てきたのです。</p>
<p>しかし、これを改善しようにもそれをできる人が社内に誰もいないという問題がありました。社内にGhostテーマの書き方を知っているエンジニアはいませんし、これからそれを学びたいと思うエンジニアもいませんでした。</p>
<p>こうして旧ブログはある種の放置状態へと陥っていきました。</p>
<h3>プレイドの元同僚チームが、ヘッドレスCMS「Newt（ニュート）」を立ち上げた！</h3>
<p>そんな状況のなか、昨年4月にプレイドから独立し新たな会社を創業していた元同僚のチームから、新たな国産ヘッドレスCMS「Newt（ニュート）」がリリースされました。Newtは、従来のヘッドレスCMSをより使いやすく、誰にでも不自由なく扱えるものにしようというコンセプトで開発をしているようです。ヘッドレスCMSという枠を飛び越えていろいろと挑戦していこうと思っているみたいなので、今後にも期待ですね。</p>
<p><a href="https://prtimes.jp/main/html/rd/p/000000002.000095676.html">国産ヘッドレスCMS「Newt（ニュート）」3月8日より無料プランの提供開始</a></p>
<p>彼らが今後何に挑戦しようとしているのかについての記事も公開されていました。WordPressを置き換えるという目標は壮大だなwとも思いましたが、そういうチャレンジ精神はプレイド社で育まれたものなのでしょう笑。頑張ってもらいたいなと思っています。</p>
<p><a href="https://www.newt.so/blog/creating-the-next-wordpress">WordPressの次を担うサービスを作る</a></p>
<p>プレイドとして（私個人として..？）は、こういう元同僚のチャレンジは応援していきたいと思っていたので、エンジニアブログをリニューアルするのであればNewtを使ってやってみようと思っていました。そして、去年末に先行ユーザーを募集していたので、このブログ改善にNewtを活用してみることにしました。</p>
<h2>Jamstack構成でブログを実装する</h2>
<p>そんな経緯でスタートしたエンジニアブログ刷新プロジェクトですが、まずはどんな技術構成で作っていくのかを決めなくてはいけません。今回は、最近フロントエンド界隈でよく耳にするJamstackと呼ばれる構成で作ることにしました。</p>
<h3>Jamstackとは？</h3>
<p>Jamstackとは、 <code>JavaScript/API/Markup</code> の頭文字をとったアーキテクチャパターンです。</p>
<p>ポイントは、フロントエンドとバックエンドを分離してAPIを通じてデータ通信を行うということです。Jamstackはあくまで考え方のようなものなので、これが正解！といった作り方はないようですが、多くは静的サイトレンダリング（SSR）や静的サイト生成（SSG）などの文脈で使われることが多いようです。</p>
<p>詳細は割愛しますが、詳しくは知りたい方は <a href="https://jamstack.org/">jamstack.org</a> を確認してみると良いと思います。</p>
<p>せっかく新しい技術を試すなら、本業として開発しているKARTEでも活用できる技術を使いたいなと思い、このJamstackは今後重要になってくる技術だと思っているため、実際に使ってみて、使い所をキャッチアップしてみることにしました。</p>
<h3>フロントエンドはNext.jsで実装</h3>
<p>次に決めなくてはいけないのは、フロントエンドを何で作るかということです。今回は次のような要件に沿って考え、Next.jsを選択しました。</p>
<ol>
<li>静的サイトレンダリング（SSG）が可能であること</li>
<li>本業のプロダクト開発に活かせること</li>
<li>（個人的にキャッチアップしたい技術であること）</li>
</ol>
<p><a href="https://jamstack.org/generators">https://jamstack.org/generators</a> に大量の静的サイトジェネレータが紹介されているので、これから検討を始める方はこの中からご自身のニーズに合ったジェネレータを探してみてください。</p>
<p><img src="https://ik.imagekit.io/plaid/61ab4b07-262b-473d-a715-5372692f1398/1000x1000/%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%882022-03-1419.18.05.png" alt="スクリーンショット2022-03-1419.18.05.png"></p>
<h3>Newtを使って記事データを管理</h3>
<p>記事管理はNewtを使って行います。</p>
<p>Newtでは、1つのスペースの中にAppというコンテンツ管理のユニットを何個でも追加していくことができます。今回は<code>PLAID, Inc.</code> スペースを作成して、その中に<code>Engineer Blog</code>Appを作ることにしました。</p>
<p>また、リニューアル後のブログはパフォーマンスにもこだわったものにしたく、特に重たい画像の最適化にもこだわりたかったため、専用のGCSバケットを作成しNewtの外部ストレージ機能を使い、ImageKitと連携させて利用することにしました。Newtでは外部ストレージ機能を使うことで、<a href="https://imagekit.io/">ImageKit</a>や<a href="https://imgix.com/">imgix</a>のような画像最適化のツールを入れられます。今回はより管理画面が軽快だったImageKitを選択しました。</p>
<p><img src="https://ik.imagekit.io/plaid/f8de7fec-546c-407f-a72b-353d02faeddf/1000x1000/%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%882022-03-1419.15.46.png" alt="スクリーンショット2022-03-1419.15.46.png"></p>
<h3>Netlifyを使ってホスティング</h3>
<p>フロントエンドをNext.jsで作ることにしたため、当初はNext.jsの開発元であるVercelを利用することにしていたのですが、ブログ公開の直前に後述する問題が発生したため、Netlifyでのホスティングに切り替えました。現状では、特に大きな問題はなくホスティングすることができています。</p>
<p>NetlifyでもVercelでも、静的サイトのホスティングサービスにそのまま連携することで、めちゃくちゃ簡単にWebサイトをホスティングすることができたので感動しました。</p>
<p><img src="https://ik.imagekit.io/plaid/67d2b891-5bf8-4b64-aa8e-c76a55963f3a/1000x1000/%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%882022-03-1422.00.41.jpg" alt="スクリーンショット2022-03-1422.00.41.jpg"></p>
<h2>大変だったこと・課題</h2>
<h3>記事データの移行作業が大変だった..</h3>
<p>一番大変だったのは、Ghostからの記事の移行作業です。Ghostからエクスポートした記事データを、1件ずつ手作業でNewtに移していく必要がありました。</p>
<p>Newt社のメンバーに聞いたところ、コンテンツのPOST APIやCSVインポート機能は提供予定とのことだったので、今後はこのような辛い作業を行わなくても良くなっていくのだろうと思います。今回に限ってはデータ移行が一番大変でした。。</p>
<h3>Superの影響で、Vercelを使うことができなかった</h3>
<p>これはあまり一般的な問題ではありませんが、Notionのホスティングサービスである<a href="https://super.so/">Super</a>を社内の別プロジェクトで利用していたことで、Vercelでホスティングできなくなるという問題が発生しました。</p>
<p>SuperはNotionから静的なWebページをホスティングすることのサービスです。プレイドではSuperを使って <code>recruit.plaid.co.jp</code> というドメインのWebサイトを立ち上げていました。そして、これが原因でVercel上で <code>tech.plaid.co.jp</code> というドメインのWebサイトをホスティングすることができなくなってしまいました。</p>
<p>これは、下記のような原因によるものだと思われます。</p>
<ol>
<li>SuperがVercelを使ってホスティングを行なっていること</li>
<li>Vercelでは、同じドメイン配下の違うサブドメインを、別々のプロジェクトで使用することができないということ</li>
</ol>
<p>つまり、SuperのインフラとVercelのドメイン扱いに関する仕様が、コンフリクトを起こしてしまったような状況にあるのだと思います。</p>
<p>今回のケースでは、単にVercelからNetlifyへと置き換えることで回避することができました。これもいずれVercelで改善されるかと思いますが、Vercelを前提に実装等を行う場合は注意が必要だと思います。</p>
<h3>ビルド時間への慣れが少し必要</h3>
<p>Ghostをはじめとする一般的なブログサービスを利用する場合、記事を保存すればWebサイト側に即反映されるのが当たり前でした。ですが、今回のようにCMSをバックエンドにSSGで構築する場合は、記事を保存してからCMSのデータを元に静的ファイルへのビルドが実行され、ビルド結果が新たにホスティングされるため、Webサイトとしてみえるようになるまでにタイムラグが生じてしまいます。</p>
<p>このタイムラグへの慣れというのは少し必要になるかなという感覚を得ました。個人的には、保存ボタンを押すタイミングをちょっと考えてしまいました。</p>
<p>ただ、そうしたビルドによる事前レンダリングによってWebサイトのパフォーマンスがかなり改善されるので、よほどのことがない限りはタイムラグの方に自分を慣らしてしまうのが賢明なのではないかなと思います。</p>
<h2>良かったこと</h2>
<h3>Appテンプレートとスターターで開発工程をスキップできた</h3>
<p>Newtでは、モデル設定とサンプルコンテンツのプリセット（Appテンプレート）をインストールしてコンテンツ管理をスタートすることができます。AppテンプレートにはそれぞれNext.jsとNuxt.jsのスターターキットが用意されているため、今回はこれをベースに実装とデザイン（デザイナーさんにも協力してもらいました）を行うことにしました。</p>
<p>モデル設計やヘッドレスCMSとの繋ぎ込み、ブログの基本機能の実装といった作業は、思いのほか手間のかかる作業だと思うので、そうした作業をスキップすることができたのは良い体験でした。</p>
<p><a href="https://www.newt.so/docs/app-template">Appテンプレートについて</a>はこちらのドキュメントをご参考ください。</p>
<p><img src="https://ik.imagekit.io/plaid/67bd8d81-449f-4822-a40b-5dee031f0522/1000x1000/Group2.png" alt="Group2.png"></p>
<h3>パフォーマンスが大幅に改善</h3>
<p>一番良かったと思えたのは、体感値としても計測値としても、ブログのパフォーマンスが大きく改善されたことです。今この記事を書きながらLighthouseを使って測定してみたところ、全ての項目で90点を超える結果になっていました。</p>
<p>社員からも「爆速！」「dev.toかと思った」などと表示速度に関するポジティブな感想が多く出てきました。</p>
<p><img src="https://ik.imagekit.io/plaid/d4fbb069-edc5-4be4-bc01-dbd43aa013bf/1000x1000/%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%88_2022-03-11_15.17.10.png" alt="スクリーンショット_2022-03-11_15.17.10.png"></p>
<h3>エンジニアやデザイナーがコードを書いてメンテナンス可能に</h3>
<p>ヘッドレスCMSを使って、フロントエンドを自前で実装したことによって、不具合などがあった場合に社内のエンジニアがPull Requestを作成して修正できるようになりました。</p>
<p>以前のブログだと、何かを修正したくても修正の仕方が分からないという状態でしたが、リニューアル後は普段から仕事で利用しているReact.jsのコードを書くことによって簡単に修正を行うことができます。Pull Requestをマージすれば、即座にデプロイが実行され、普段の開発と同じフローでブログの修正をできるのもかなり楽です。</p>
<p>このように自分達のブログを自分達でメンテナンスできるようになったことで、今後何かしらの改善点が出てきた時にそれを放置してしまわずに済みます。</p>
<p><img src="https://ik.imagekit.io/plaid/3ff6a693-75f5-4403-908a-36a9dbbece84/1000x1000/%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%88_2022-03-11_17.09.35.png" alt="スクリーンショット_2022-03-11_17.09.35.png"></p>
<h3>飛び火的に社内の別プロジェクトで採用され始めた</h3>
<p>Newtでは、1つのスペースにAppというコンテンツ管理ユニットを何個も作っていくことで、組織内のあらゆるコンテンツや情報を集約していくことができると謳っています。そして、プレイド社において実際にそういう現象が起きています。</p>
<p>最初はエンジニアブログだけのために作成したNewtスペースですが、少し時間が経つと風の噂を聞いた他チームの社員が何人も参加してきて新たなAppが次々と作られています。</p>
<p>スペースへの参加者は3月11日現在で20名近くになっていて、次々に横展開が進んでいるような状況になっています。個人的にも、今まであまり知ることができなかった他のチームの動きを知ることができて面白いなーと思って眺めています。</p>
<p><img src="https://ik.imagekit.io/plaid/a837ec80-b95a-46c2-ae56-7ac2b24a7e20/1000x1000/mosaic_20220311154807.png" alt="mosaic_20220311154807.png"></p>
<h3>最近のフロントエンド技術のキャッチアップができた</h3>
<p>個人的には、最近のモダンなフロントエンド開発についてキャッチアップできたことが良かったなと思っています。</p>
<p>どうしてもメインの仕事としてとなると、自分のパフォーマンスが出やすい領域に集中してしまいがちですが、こういった機会を利用して今後重要になるけどまだ詳しくない領域にも手を出していくと良いのではないかなと感じました。</p>
<h2>終わりに</h2>
<p>今回は、PLAIDエンジニアブログのリニューアルプロジェクトについてご紹介しました。</p>
<p>PLAIDエンジニアブログでは、今後もより一層、社内外のエンジニアに面白いと思ってもらえるような記事を公開していきたいと思っています！</p>
<p>プレイドでは（普段はバリバリと開発しながらも）新しくなったエンジニアブログに面白い記事を公開してくれるエンジニア（インターンも！）を募集しています。詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。</p>


PLAIDエンジニアブログをJamstackでリニューアルしました🚀

「KARTE Blocksリリースの裏側」はKARTE Blocksが2021年9月14日に正式リリースされたことを記念して開始した連載シリーズです。 2021年11月8日に公開した「KARTE Blocksを支える技術」から11月19日に公開した「KARTE Blocksにおけるポジショニングの考え方とその狙い」まで10本の記事を公開しました。  このように複数人での連載記事を書く場合にどのように進めるべきか、「KARTE Blocksリリースの裏側」という連載ではどのように進めていったのかについて紹介します。

「KARTE Blocksリリースの裏側」の裏側 - 複数人で連載記事を書く方法

爆速で価値あるプロダクトをリリースするためのチームビルディング

セカンドパーティコンテンツをもつサードパーティスクリプトの作り方