Engineer Blog

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

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

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

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


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

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

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

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

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

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

<p>初めまして！エンジニアのとさ (@tosa_now)です！</p>
<p>プレイドは、2023/10/28 (土) に開催された<a href="https://vuefes.jp/2023/">Vue Fes Japan 2023</a>にゴールドスポンサーとして協賛しました。</p>
<p>スポンサーブースの運営をする機会をいただき、参加者の皆さんに<a href="https://karte.io/">KARTE</a>のデモや現在作成中の機能についての説明やお話をすることができました。</p>
<p>今回のブログでは、参加したVue Fes Japanの様子をお伝えできればと思います。</p>
<p>今回スポンサーとして参加した理由は、PLAIDが開発しているKARTEというプロダクト内ではなんとVueが0系の時から利用しており、現状でも管理画面の大部分がVueで書かれておりコミュニティに助けられているので少しでも還元したいという思いから参加しました！</p>
<h2>Vue Fes 当日の様子</h2>
<p><img src="https://ik.imagekit.io/plaid/20f62fe9-7a00-4d55-b0bc-8e3702e7b810/1000002289.jpg" alt="1000002289.jpg"><em>スポンサーブースの準備完了後の写真</em></p>
<p>主にブースではKARTEのプロダクト説明をメインで行っていました。<br>
来訪してくださった方とVue2からVue3への移行をどのように進めているのかなどの技術雑談話でもりあがりました。</p>
<p><img src="https://ik.imagekit.io/plaid/bcbfc85c-7535-4087-a132-75fbb2c890cc/IMG_4361.jpg" alt="IMG_4361.jpg"><em>エンジニアのnichimuさんがスポンサーブースに立っている様子</em></p>
<p>プロダクト説明では、<a href="https://blocks.karte.io/">KARTE Blocks</a>と新機能であるエレメントビルダーを開発しているエンジニアのjunjun (@junish_js) さんによるデモで大いに盛り上がりました！！</p>
<p>エレメントビルダーの開発の裏側は<a href="https://cxclip.karte.io/products/developer/action-editor/">こちら</a>の記事で解説しています</p>
<p><img src="https://ik.imagekit.io/plaid/4a62f6c0-d15d-49ff-a81f-cb11fe87f2d6/IMG_4364.jpg" alt="IMG_4364.jpg"><em>エンジニアのjunjunさんがプロダクト説明をしている様子</em></p>
<p>とさの個人的な趣味でVue Fesの開催二日前に発売されたHHKB Professionalのお試し会も開催しました。興味を持ってくださる方が多くて嬉しかったです。<br>
<img src="https://ik.imagekit.io/plaid/00ea3072-8ce7-4ef7-ad70-6a0cfcf0e2a3/%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%882023-11-0510.53.04.png" alt="スクリーンショット2023-11-0510.53.04.png"></p>
<p>Vue Fesのスポンサーブース全体が賑やかでどの企業さんも回っていてとても楽しかったです。</p>
<h3>参加した開発メンバーの感想</h3>
<p>デザイナーの今西さん<br>
今回、ブース対応を初めて担当し、KARTEの魅力が少しでも伝わっていれば嬉しいなと思います。ひさしぶりのオフラインカンファレンスということで、当日は大いに盛り上がり、とても楽しい1日を過ごすことができました！</p>
<p>エンジニアのjunjunさん<br>
Vue Fesにスポンサーとして参加したのが新鮮でした。また、イベントは参加者と交流するという楽しみかたがあるんだと気づきました。私はVue Fesがきっかけでプレイドを知って入社したので、皆さんも知っていただけたら嬉しいです。またお会いましょう！</p>
<h3>おわりに</h3>
<p>Vue Fesのスタッフの皆さん、準備及びに当日の運営ありがとうございました！<br>
PLAIDはこれからもVue.jsのコミュニティグループの活動を応援しています。</p>
<p><img src="https://ik.imagekit.io/plaid/a0f082ec-3452-4958-a31d-50c506335c07/1000002292.jpg" alt="1000002292.jpg"><em>ブース撤収直後のサインボードの様子</em></p>


株式会社PLAIDはVue Fes Japan 2023にゴールドスポンサーとして参加して、スポンサーブースの運営を行いました！

Vue Fes Japan 2023にゴールドスポンサーとして参加しました！

KARTE 管理画面のパフォーマンスの監視をするにあたって考えたことや Datadog の活用のポイント、改善で取り組んだことについて紹介します。

Datadog を使った KARTE 管理画面パフォーマンス改善の取り組み

<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リリースの裏側」の裏側 - 複数人で連載記事を書く方法

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

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

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

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

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

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