Engineer Blog

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

<h1>自己紹介</h1>
<p>初めまして、プレイドでエンジニアインターンをしている小林雅史と申します。プレイド内ではあだ名である<a href="https://x.com/mercy34mercy">mercy</a>(マーシー)で呼ばれています。</p>
<p>立命館大学の修士1年生で、大学は情報理工学部、大学院は情報理工学研究科とコンピュータやプログラミングについて学び、研究しています。プログラミングは大学入学と同時に授業で取り組んできました。プログラミングに関しては授業だけでなく、ハッカソンなどでさまざまなアプリケーションを作成しました。特に<a href="https://cup.hackz.team/">ハックツハッカソン</a>が大好きで2度優勝しています。また<a href="https://ritsumeikanunivpress.com/07/11/4430/">大学生向けのバス時刻表アプリ</a>を先輩から引き継ぎ運用していたりもしています。3年生の時には学生IT団体<a href="http://www.watnow.jp/">watnow</a>の代表として<a href="http://www.watnow.jp/2022/10/20/%E9%96%A2%E8%A5%BF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%AB%E3%83%B3%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B92022%E3%82%92%E9%96%8B%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/">企業様とのイベント</a>や<a href="http://www.watnow.jp/2022/08/24/watnow%e3%83%8f%e3%83%83%e3%82%ab%e3%82%bd%e3%83%b3-beginners-cup%e3%82%92%e9%96%8b%e5%82%ac%e3%81%97%e3%81%be%e3%81%97%e3%81%9f%ef%bc%81/">団体内ハッカソン</a>を立ち上げたりとコミュニティの運営も行いました。</p>
<p>プレイドでは2023年の4月からインターンとして勤務していて、最初は<a href="https://tech.plaid.co.jp/platform-engineering-kaigi-2024-report">認証基盤の開発</a>を行いました。その後Redisの監視を簡単にDatadogで行うための社内向けツールを開発し、2023年10月ごろから<a href="https://karte.io/package/message/">KARTE Message</a>というプロダクトの開発を行うチームに加わり、開発を行っています。</p>
<h1>KARTE Messageについて</h1>
<p>KARTE Messageは、データを元にメールやプッシュ通知、LINE メッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<div class="iframely-embed" data-embedded-url="https://karte.io/package/message/"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://karte.io/package/message/" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Fkarte.io%2Fpackage%2Fmessage%2F&key=878c5bef402f0b2911bf6d4ce6261abd">KARTE Message（マーケティングオートメーション/MA）｜顧客体験を磨きこみ、自動化のその先へ【KARTE（カルテ）】</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script> 
<h1>課題</h1>
<p>KARTE Messageの機能であるスマホアプリ向けのプッシュ通知配信では月間1億通を超える規模の配信を行っています。</p>
<p>今回、プッシュ通知に利用しているFCMの<a href="https://firebase.google.com/docs/reference/admin/node/firebase-admin.messaging.messaging.md?hl=ja#messagingsendall">sendAll API</a>が2024年の6月20日に廃止されることが決定し、この期日までに今後も引き続き使用できるAPIに乗り換える必要がありました。</p>
<p>また、これまで使用していたsendAll APIでは、最大500件の通知をバッチ的に送信することができましたが、これと完全に互換性のあるAPIは現在用意されておらず、1通1通を個別に送信する必要があります。</p>
<p>今回私はこのリプレース作業を担当することになりました。</p>
<h1>テスト送信の実装・切り替え</h1>
<p>最初に、移行時のリスクが小さいテスト送信から置き換えることとなりました。本番送信もテスト送信も1通1通を個別に送信するロジックは同じであり、違いは送信数です。そのため、テスト送信の実装を先に行いリリースすることで、バグがあった際の影響範囲をテスト送信のみに抑えつつ新しい実装の信頼性を検証することができます。テスト送信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>既存のコードとドキュメントを読み理解する</li>
<li>テスト送信の実装</li>
<li>テスト送信の実装の置き換え</li>
</ol>
<h3>1. 既存のコードとドキュメントを読み理解する</h3>
<p>既に動いているシステムをリプレースするため、まずは既存のコードを理解する必要がありました。コードを読むだけではなかなかコードの振る舞いを把握するのが難しいので、単体テストを新たに追加しました。</p>
<h3>2. テスト送信の実装</h3>
<p>リプレースする際のリスクを最小にするために、新規実装では既存の実装と同じケースの単体テストを書き、既存実装、新規実装ともにテストケースと結果が同じになることを確認することで、実装ミスがないかを検証しました。また、新規実装では、Goの実装が約1200行なのに対してテストコードは約5600行あります。テストはローカル環境で実行することができ、キャッシュがない状態でも30秒ほどで終了します。また、これらのテストはGithubActionsで自動で実行されており、生産性向上につながっています。</p>
<h3>3. テスト送信の実装の置き換え</h3>
<p>無事に実装が終わりテストも通ったら本番環境のテスト送信をリプレースしました。これまでの業務でバグの修正や新機能の実装をした事はあったものの、今正常に動いているものを全く新しいコードで作成されたシステムに置き換える経験は初めてでとても緊張しました。リリースの実行は社員さんに行ってもらい、検証環境で最終動作確認を行いました。テスト送信のリプレース後には、ユーザ企業様からバグ報告が数件ありました。その中でもGoへのリクエストのJSONのフィールドにnullがあった場合、Goのjson packageではnilに変換されるという仕様があり、nilのハンドリングがうまくできていないコードでバグが発生したのが印象的です。いくつかのバグを修正し、無事テスト送信の実装をsendAll APIからsend APIに切り替えることができました。</p>
<h1>本番配信の実装・負荷試験・切り替え</h1>
<p>テスト送信の置き換えが終了しバグの修正も終わると、本番配信も新しいAPIに置き換えます。本番配信の置き換えで行った作業は次の通りです。</p>
<ol>
<li>本番送信の実装</li>
<li>負荷試験</li>
<li>カナリアリリース</li>
</ol>
<h3>1. 本番送信の実装</h3>
<p>本番送信の実装に関しては本番送信とテスト送信のロジックを共通化したため、基本的にテスト送信の実装を流用する形で実装しました。</p>
<h3>2.  負荷試験</h3>
<p>本番配信では、KARTE Messageを使用されている企業様が大量のアプリユーザに向けてプッシュ通知を送信します。また、お客様が設定した速度で正しく配信する必要があります。そのため、アプリケーションに負荷がかかっても正常に動作することを検証する必要がありました。KARTE MessageはインフラにGCPのGKEを使用しているため、正しい速度で負荷がかかっても送信できる適切なk8sのスケーリング設定を見つける必要がありました。</p>
<p>負荷試験の環境には本番環境とは完全に切り離された検証環境を使用しました。検証環境は本番環境と同じシステムが動作しており、スケーリングの設定などが違うだけで本番環境と同じようにシステムが動作します。</p>
<p>負荷試験に関しては、社員さんからは時間かかってもいいからとりあえずやってみよう！といった感じで言われたので、ほぼ初めてGKEとその設定が書かれたk8s用のyamlファイルと戦うこととなりました。本番配信は、データベース、配信サーバ(今回作成したもの)、配信準備サーバなどさまざまなシステムが連携して動くことで実行されます。サーバやデータベースの状況はリアルタイムでdatadogで確認しました。</p>
<p>負荷試験の目標値は16667rps(時速6000万)となりました。これはAPI置き換え前のシステムで過去に負荷試験をした際の最大値となっています。</p>
<p>最初はスケーリングの設定を何も変えずに、2.7prs、277rps、1667rps、5555rpsと上げて行きました。すると、時速5555rpsの試験では設定した速度で配信されず1100rpsほどでしか配信できませんでした。ここから数時間悩んで色々設定を見ているうちに、配信サーバのスケーリング設定が問題になっていることに気づきました。最大node数とpod数が非常に小さい数に設定されていて、一定以上の負荷に耐えられないようになっていました。そこで、podの最大数を500、nodeの最大数を250に設定し再度負荷試験を行ったところ、16667rpsを達成できました。この時、配信サーバのpod数は100台ほどにスケーリングしていました。</p>
<p>目標値をクリアしたので、次に最適な設定を探します。KARTE Messageではサービスの性質上、リクエストのスパイクが発生しやすいです。また、深夜帯などは配信がなくサーバに負荷がかからない状態になります。そのため、スパイクに耐えられる最小pod数と、最大負荷に耐えられる最大pod数を見つける必要があります。そこで、1podあたりどれくらいの配信数を捌けるのかを調査しました。調査するために、pod数を20台固定にし少しづつ少ない配信数から負荷試験を行い、限界の配信速度を見つけ出しました。20台のpodで2700万/hの配信を行うことができました。pod1台で約135万/hの配信が可能です。そこで、6000万/hの配信に耐えられるpod数より少し余裕を持たせた50を、最大pod数としました。</p>
<p>負荷試験だけで10営業日ほどかかりました、負荷試験の勘所やk8sの特性を理解するのに時間を要しました。初めてやることは、手探りで頑張ってみることも大事ですが、社員さんなど経験がある人にある程度、勘所を先に教わっておくともっと効率良くできたかなと感じました。学生が簡単に経験することができない、k8sを用いたシステムの負荷試験ができたことは非常に良い経験となりました。</p>
<h3>3. カナリアリリース</h3>
<p>負荷試験も終わり、ついに本番配信を新しいAPIに置き換えます。全ユーザに一斉に適用してしまうと、もしもバグなどがあった場合に影響範囲が広くなってしまうため、一部のお客様から順次新しいAPIを適用しました。APIの切り替えは環境変数で指定した特定のお客様の時のみ新しいAPIが実行されるように実装を行いました。環境変数で切り替えを行うことで、もし新しいAPIの実装に問題があった際に、修正やロールバックしたアプリケーションをデプロイすることなく、環境変数を切り替えるだけで既存のAPIの実装に戻せるため、環境変数を活用したカナリアリリースを行いました。カナリアリリースは、置き換え前と比べて、悪化している指標がないか確認しながら約1ヶ月かけて全てのお客様の配信APIを新しいAPIに切り替えました。</p>
<h1>リプレース結果</h1>
<p>リプレースは実装を始めてから約5ヶ月で終了しました。結果として、新しいAPIに切り替えたことによる大きな障害はありませんでした。そして、既存実装よりもエラー率も下がりました。</p>
<h1>最後に</h1>
<p>今回のプッシュ通知配信で使用するAPIのリプレースの実装、試験、移行は全て自分の手で行いました。もちろん社員さんの助けなしではできなかったです。今回のプロジェクトを通して長期インターンでしか体験できない貴重な経験ができました。また、自分は京都に住んでいるのでリモート勤務だったですが、地方に住んでいる学生についてはリモートでも受け入れてくれる環境は非常にありがたかったです。他のインターン生が行ったことについては、ぜひプレイドのエンジニアブログをご覧ください[1][2][3][4][5]。このような経験をしてみたい方、プレイドに興味を持った方は下記からプレイドのエンジニアインターンに応募してみてください！</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer"><div class="iframely-responsive" style="padding-bottom: 28.2577%; padding-top: 120px;"><a href="https://recruit.plaid.co.jp/requisitions/new-graduate-engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?url=https%3A%2F%2Frecruit.plaid.co.jp%2Frequisitions%2Fnew-graduate-engineer&key=878c5bef402f0b2911bf6d4ce6261abd">新卒採用 & インターン (Product) | 募集ポジション | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<p>[1] <a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a></p>
<p>[2] <a href="https://tech.plaid.co.jp/intern-at-plaid-calloc">プレイドインターン体験記: はじめての開発インターンを通じて得た学び</a></p>
<p>[3] <a href="https://tech.plaid.co.jp/intern-at-plaid-kenshin">プレイドでの開発インターン: 3ヶ月のフルタイムエンジニアとしての挑戦を経て</a></p>
<p>[4] <a href="https://tech.plaid.co.jp/intern-at-plaid-shohei-shiraki">プレイドのインターン体験記：分散システムとプロダクト貢献意識の両面からの学び</a></p>
<p>[5] <a href="https://tech.plaid.co.jp/mongo-atlas-to-bigquery">MongoDB AtlasからBigQueryへのリアルタイムレプリケーション</a></p>


KARTE Messageで使用しているFCMのsendAll APIが廃止となるため、APIの置き換えを行った後負荷試験を行なった。

FCMのSendAll API廃止対応

KARTE MessageにおけるFCMのSendAll API廃止対応について

カラムナフォーマットの利点を最大限活かすために書き込み処理、特にリアルタイムの書き込み処理における技術的な課題とOSS DBの具体的なアプローチを紹介しています

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 - PLAID engineer blog

OLAP-DBでのreal-time ingestionをカラムナに最適化する技術 

<h2>はじめに</h2>
<p>こんにちは，プレイドのCore Platformチーム<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>（プレイドで社内の全てのプロダクト基盤やリアルタイム解析基盤<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup><sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>を扱っているチーム）でインターンをしている<a href="https://lapla.dev/about/">lapla</a>といいます．プレイドでは2024年6月より働いており，この度社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います．<br>
データベースのバージョンアップは，データベースを使用しているシステムにとって避け難いタスクであり，それはプレイドも同様です．そこでプレイドでは， 単に公式のアップデートドキュメントを読むだけではなく， MongoDBの内部構造も理解した上で作業することにより，安全なバージョンアップを継続的にかつサービス無停止で行っています．今回はその点について説明しようと思います．<br>
なお，本記事はデータベースのいわゆるHow To記事ではなく， データベースの構造に興味のある方や， 既に他のデータベースを使用していて， 今後MongoDBを使ってみようという方向けに記述を行っているため， 前半にデータベースのバージョンアップに関する一般的な話や，プレイドでの使用状況を述べ，後半にMongoDBの内部構造に触れるという構成を取っています．</p>
<h2>自己紹介</h2>
<p>現在，筑波大学情報学群情報科学類の4年生で，主にシステムプログラミングやクラウドネイティブな技術に興味がありますが，OSから機械学習までレイヤを問わずにプログラムを書きます．<br>
趣味のプログラミングについて触れると，学部1年の頃に手が滑って，主にC++でx86_64向けのTCP/IPプロトコルスタックが搭載されたGUI操作可能なOSを書いた結果，その後も手が滑り続けて学部3，4年の頃にはRustで64bit RISC-V向けのOSを書いていました．他にもRust言語が好きなので，RustでELFのタイムトラベルデバッガを書いたり，ELFバイナリ難読化器（ELFバイナリの実行時の動作を変えずに，解析からの妨害対策がなされたバイナリを作り出す）を作っていたりしました．最近は内部でRISC-VバイナリをエミュレートするようなOCIコンテナランタイムを開発しています．<br>
比較的高いレイヤも好きで，例えば学部2年の頃には文章から音を生成するCGANを研究していたりしました．</p>
<h2>プレイドにおけるMongoDBとその周辺ソフトウェアの利用</h2>
<p>プレイドでは，主力プロダクトであるCXプラットフォーム<a href="https://karte.io/">KARTE</a>の様々な場面で主にMongoDBを使用しています．また，ODM（Object Document Mapper）として<a href="https://github.com/Automattic/mongoose">Mongoose</a>を用いていて，Node.js経由でMongoDBを操作しています．プレイドではサーバーサイドがほとんどNode.jsで書かれており，MongoDBは内部的にデータをBSONで保持している点や非同期処理との相性の良さという点でNode.jsとの親和性が高いため，積極的にMongoDBを使用しています．この辺りについては弊社のgamiが書いた「 <a href="https://tech.plaid.co.jp/plaid_loves_nodejs">PLAIDがNode.jsを採用し、5年間で12万行書いてわかったこと</a>」 をご覧ください．</p>
<h2>データベースのバージョンアップ</h2>
<p>さて， 冒頭にも述べた通り，データベースの定期的なバージョンアップは，多くのソフトウェア企業に付いて回るタスクの1つです．<br>
主にOSSとして公開されているような一般的なRDBをセルフホストしている場合において，バージョンアップなどの作業を行うためには，データの整合性を取るために一旦データベースへの書き込み処理を停止した上でレプリケーションをおこなってから，アプリケーションが参照するデータベースの接続先を変更する手順を踏むのが一般的と思われます．しかし，いわゆるNewSQLに属するMongoDBでは内部で複数同じ状態のデータを持つノードが複数おり、この特性を活用することで，プレイドでは平日の昼間であっても安全にバージョンアップの作業を行うことができています．<br>
なぜMongoDBの場合にはサービスを停止させずに， 安全にバージョンアップできるのかに関しては，本記事後半で紹介する，MongoDBの内部構造を，論文などを元にして理解することにより達成されています．平日昼間など，通常は忌避される時間帯であっても，安全性の根拠を持ってメンテナンスウィンドウなどを設けずにバージョンアップを行うことは，開発速度の向上などの開発者体験の向上に繋がります．また， サービスを停止させる時間が不要なことは，KARTEをご利用いただくユーザー様にとっても大きな恩恵があると考えます．</p>
<h2>今回のバージョンアップ完了までの手順</h2>
<p>ここでは今回行ったバージョンアップの大まかな手順について説明します．大枠としては以前にMongoDBをバージョン4からバージョン5に上げた際のものと同様です．当時の記録については以前インターンされていた方が書いた「<a href="https://tech.plaid.co.jp/internship-mongodb-update">インターンシップで全社のMongoDBをアップデートした話</a>」に詳しく記載されていますので，ぜひご覧ください．</p>
<ol>
<li>アプリケーションコードに影響を与えそうな変更の調査<br>
まずはMongooseやMongoDB Serverの現在のバージョンから，バージョンアップする目標のバージョンまでの変更を確認し，主にプロダクトの動作に影響を与えそうなものをピックアップして調査しました</li>
<li>社内ライブラリのアップデート<br>
プレイド社内には，様々なアプリケーションが共用するライブラリが存在します．その中にはMongoDBのラッパーなども含まれているため，これらの更新を行いました</li>
<li>各アプリケーションのアップデート<br>
新しくなった社内のライブラリを用いて，各アプリケーションが動作するように修正を行います．この作業は基本的に各アプリケーションチームに依頼し，書き換えを行なってもらいました</li>
<li>データベースのアップデート<br>
最初に検証環境のデータベースのバージョンを上げ，問題がなさそうであれば本番環境のデータベースもバージョンアップを行います．この際に，本記事後半で触れる内部構造の理解により，安心感をもったバージョンアップを行えています．</li>
</ol>
<h2>バージョンアップ作業の今後</h2>
<p>現在は，バージョン7へのバージョンアップに必要な調査や実装を行っています．バージョン7へのバージョンアップに伴う，現状の我々のユースケースに大きな影響を与えそうなMongooseでの変更をいくつか紹介すると，次のようなものがあります：</p>
<ul>
<li>callbackを用いた処理を書くことができないようになる（社内のアプリケーションコードには，比較的昔に書かれたものではしばしばcallbackが使われている）</li>
<li>社内実装で多く使われている関数を使用できなくなる（findOneAndRemoveなど）</li>
</ul>
<p>このように，今後に控えているアップデートではより困難なアップグレード作業が予想されますが，今回のアップグレードで得られた経験も積極的に用いて，無事に作業を成功させるべく動いています．</p>
<p>—</p>
<p>ここからはよりMongoDBの内部構造を理解したい方向けに記述します．</p>
<h2>MongoDBの内部構造を想像する</h2>
<p>さて，冒頭でも述べた通り，本記事の後半ではMongoDBの内部構造について見ていきます. ここではあくまでも公開論文などをもとに内部の仕組みなどを想像して書いているため， 間違っている可能性は否定できないことを述べておきます.<br>
MongoDBの内部では，分散合意アルゴリズムとして著名なRaftを独自に改良したアルゴリズムを用いて合意を取っています．この機序を理解するためには次の3つの論文が特に参考になります：</p>
<ul>
<li><a href="https://raft.github.io/raft.pdf">In Search of an Understandable Consensus Algorithm (Extended Version)</a>（以下論文1）: 分散合意アルゴリズムのRaftについて紹介されている論文です</li>
<li><a href="https://www.usenix.org/conference/nsdi21/presentation/zhou">Fault-Tolerant Replication with Pull-Based Consensus in MongoDB</a>（以下論文2）: MongoDBの内部では，純粋なRaftアルゴリズムではなく，後述するPull-Based Consensusと呼ばれるアルゴリズムを用いてノード間での合意を取っています．このアルゴリズムについて解説した論文です</li>
<li><a href="https://dl.acm.org/doi/10.14778/3352063.3352125">Tunable consistency in MongoDB</a>: MongoDBでは，書き込みと読み込みの整合性をある程度自由に設定することができます（Tunable Consistency）．これによりアプリケーション特性に合わせた整合性を取ることができます．この内容についての説明がなされています</li>
</ul>
<p>今回はスペースの都合上，論文1で紹介されている純粋なRaftの動作についての説明はある程度既知のものとし，以降は論文2で提案されているpull-based Raftの動作について説明を行うことにします．</p>
<h3>Pull-Based Consensus</h3>
<p>先に述べた通り，MongoDBの内部では純粋なRaftではなく，動作が改造されたRaftアルゴリズムが用いられていて，これは論文内ではPull-Based Consensusとされています．本記事では，純粋なRaftの改造版であるということを強調するために，Pull-Based Raftと呼ぶことにします．<br>
まず一般的なRaftアルゴリズムは，次の図のように，LeaderノードからFollowerノードに対してログが配信され，Followerノードはそれを個々に有しているという構造を取っています．Leaderノードで何らかの不具合が起きると，クラスターはvotingを行い，新たなLeaderノードを選出します：<br>
<img src="https://ik.imagekit.io/plaid/0bd8ed16-d589-473f-8b78-7f10558ba122/image1.png" alt="image1.png"><sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup><br>
また，次図に示すように，クライアント側からのリクエストに対しては複数のモジュールにログが分散して保存されます：<br>
<img src="https://ik.imagekit.io/plaid/77f8ba01-c659-4897-84a7-0d49418acd13/image3.png" alt="image3.png"><sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup></p>
<p>分散合意を取るという目的であればこれで十分ですが，スケーリングやバージョンアップの際など，クラスター内のノードが増減する場合においては，データの同期を柔軟に行うのが難しいといった課題があります．<br>
これに対して，MongoDBは独自のPull-Based Raftアルゴリズムを実装しており，これはFollowerノードが自律的にLeaderノードに対してログの配信を要求しにいくような構造になっています．<br>
<img src="https://ik.imagekit.io/plaid/72eac0ca-f319-44ab-9df9-46c81ce2ed6b/image2_1.png" alt="image2_1.png"><sup class="footnote-ref"><a href="#fn6" id="fnref6">[6]</a></sup></p>
<p>これはレプリカのデータ同期を任意の2つのレプリカで行うことができるという特徴があり，様々なネットワークトポロジーを取ることができるようになります．また，これによりネットワークの帯域幅を削減できるという特徴も存在します．<br>
また，バージョンアップの作業を行うにあたっては，クラスター内の古いバージョンのノードが1つ，新しいバージョンのものと入れ替わって，問題が無ければ他の古いバージョンのものも順々に取り替えていくという方式を取っているものと思われます．このことは， MongoDBの公式のドキュメントには記述がありませんが，バージョンアップ時のメトリクスを観察した結果得られたヒューリスティックな観測です．この挙動が可能なのは， Pull-Based Raftによって任意のレプリカ間でのデータ同期を柔軟に行えるためだと考えています．このような挙動は，バージョンアップ時に何か不具合が生じてもサービスを停止させることなくロールバックできるという点で利点があります．</p>
<h2>最後に</h2>
<p>ここまで見てきたように，論文などのある程度信頼できるソースを元にした，ソフトウェアの内部構造理解は，より安全なシステム設計・運用につながるものであると言えます．<br>
私自身は今回のバージョンアップ作業に際して，こういった理論面から実装までの理解を一気通貫で行うことができたので，貴重な経験を積めたと思います．<br>
本記事ではその一端をお伝えすることができたと思うのですが，プレイドは計算機的に面白い業務が様々な場所に存在する環境であると思います．プレイドで働くことに興味を持たれた方は，ぜひ次のリンクもご覧ください．</p>
<div class="iframely-embed" data-embedded-url="https://recruit.plaid.co.jp/engineer"><div class="iframely-responsive" style="height: 140px; padding-bottom: 0;"><a href="https://recruit.plaid.co.jp/engineer" data-iframely-url="//cdn.iframe.ly/api/iframe?card=small&url=https%3A%2F%2Frecruit.plaid.co.jp%2Fengineer&key=878c5bef402f0b2911bf6d4ce6261abd">エンジニアについて | 採用情報 | 株式会社プレイド</a></div></div><script async src="//cdn.iframe.ly/embed.js" charset="utf-8"></script>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p><a href="https://blog.plaid.co.jp/n/nfa3642bf9871">“エンドユーザーに露出するプラットフォーム”をつくる。Core Platformチームの仕事はなぜチャレンジングなのか</a> <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p><a href="https://tech.plaid.co.jp/blits_pre_aggregation">Blitz（前編）: 自由度と即時更新性を担保したAggregation</a> <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p><a href="https://tech.plaid.co.jp/blitz_realtime_analytics_architecture">Blitz（後編）：リアルタイムユーザー解析エンジンを実現する技術 - 強整合な解析 -</a> <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>Diego Ongaro and John Ousterhout. 2014. In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX conference on USENIX Annual Technical Conference (USENIX ATC'14). USENIX Association， USA， 305–320. <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p><a href="https://www.yugabyte.com/tech/raft-consensus-algorithm/">What is the Raft Consensus Algorithm?</a> <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn6" class="footnote-item"><p><a href="https://www.usenix.org/system/files/nsdi21_slides_zhou-siyuan.pdf">Fault-Tolerant Replication with Pull-Based Consensus in MongoDB</a> <a href="#fnref6" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います．

MongoDBをサービス無停止で継続的かつ安全にバージョンアップしている話_プレイドエンジニアブログ

MongoDBをサービス無停止で継続的かつ安全にバージョンアップしている話

こんにちは。プレイドでWicleを開発しているchakeです。 Wicleはプロダクトを使うユーザーの行動を分析し、改善するサイクルを助けるプロダクトアナリティクスサービスです。先日パブリックベータ版をリリースし、だれでもオンライン上からサインアップすることができるようになりました。

新進気鋭の認証サービスClerkを実プロダクトで使いこなせ

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

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

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

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

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

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

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

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

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

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

  const namedImports: NamedImports = {};

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

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

        const importClause = node.importClause;

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

    ts.forEachChild(node, visit);
  }

  visit(sourceFile);

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

<p>エンジニアの石井と申します。</p>
<p>プレイドは2024年7月9日 (火) に開催された <a href="https://www.cnia.io/pek2024/">Platform Engineering Kaigi 2024</a> にゴールドスポンサーとして参加いたしました。スポンサーセッションでは「モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫」というタイトルで登壇させていただきました。</p>
<p>かつて <a href="https://karte.io/">KARTE</a> がモノリスだった頃の名残を留めていた認可基盤とその問題点、刷新後のアーキテクチャや安全な移行のために施した工夫などについてお話ししています。</p>
<p>この記事では、発表内容を紹介しつつ、構成上発表に含めなかった内容や当日いただいた質問への返答コメントも一部紹介しています。録画もございますので、発表内容の全体についてはそちらも合わせてご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫" src="https://speakerdeck.com/player/be7d5d49f7104e4196a52f3b72fb25fb" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.25%;"><iframe title="Platform Engineering Kaigi 2024 トラックB" src="https://www.youtube.com/embed/Hsob6TGTAPo?rel=0&start=21735" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no" allow="accelerometer; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share;"></iframe></div>
<h1>概要</h1>
<p>昨今の KARTE ではマルチプロダクト展開が進んでおり、コードやデータベースは分割されていますが、認可基盤だけは全てのプロダクトで共通のコードを利用していました。これはいくつかの問題を抱えていました。</p>
<p><img src="https://ik.imagekit.io/plaid/899c8100-634a-4bc5-8b06-59869a8ec6b1/express-server.png" alt="express-server.png"></p>
<p>そこで、まずは新たな認可基盤のアーキテクチャについて検討しました。認可基盤を一枚岩のものとして構築するか、あるいは分散させて配置するか、どちらも一長一短があり迷いましたが、最終的には分散させる方針に決定しました。アプリケーションが稼働する Pod それぞれに対して、認可のためのコンテナをサイドカーとして配置しています。</p>
<p><img src="https://ik.imagekit.io/plaid/193ea499-4c4e-4eed-bdf8-6c4fe0ba061c/karte-gateway.png" alt="karte-gateway.png"></p>
<p>認可用のコンテナには、アプリケーションごとに異なる認可の設定を施す必要があります。設定をどのように渡すべきかもいくつか選択肢がありましたが、最終的にはコンテナの中に組み込むことにしました。KARTE のデプロイには GitOps が採用されていますが、それに伴うリポジトリ構成なども考慮した上で、このような結論に至りました。</p>
<p><img src="https://ik.imagekit.io/plaid/17cc665e-3b1f-4051-8818-e05f91b80f40/karte-gateway-simplified-config.png" alt="karte-gateway-simplified-config.png"></p>
<p>KARTE にはエンドユーザー、すなわちプレイドにとってのお客様 (企業) のお客様 (ユーザー) の個人情報が蓄積されています。そのため認可基盤のバグ、特に本来拒絶すべきリクエストを誤って許容してしまうケースが生じないように注意を払いました。従来の認可機構と二重で認可を行いつつ、問題があればアラートが鳴るよう仕込んだ上で、徐々に移行を進めました。</p>
<p><img src="https://ik.imagekit.io/plaid/fa702baf-adcd-4b46-aa7c-0bc7a835df82/authentication-migration-2.png" alt="authentication-migration-2.png"></p>
<p>認可基盤の移行はほぼ完了していますが、運用自体はまだ始まって間もない段階です。現在の形に至るまでの意思決定が適切なものであったかどうかは、今後の過程で検証されていくでしょう。</p>
<h1>おまけ</h1>
<p>時間の都合で今回の発表からは省きましたが、アーキテクチャを検討していた時期には、どのように Pod にサイドカーを入れるのかについても議論がありました。</p>
<p>最初に参考にしたのは Istio です。今回お話しした認可基盤はサービスメッシュとは異なりますが、プロキシとして動作するサイドカーを利用するという点では似通っています。そのため、Istio と同じようなサイドカーインジェクションの仕組みが使えるのではないかと考えました。</p>
<p>しかし検討の末、このやり方は見送ることにしました。もしこれを採用する場合、Kubernetes の Admission Webhook を利用してサイドカーを注入する想定でした。しかし</p>
<ul>
<li>Admission Webhook のための追加実装が必要になる</li>
<li>GitOps によって karte-ops リポジトリの Kubernetes マニフェストと GKE 上で稼働するリソースの同期が取られているが、Admission Webhook が介入するとサイドカーがどこで追加されたものなのかわかりにくくなる</li>
</ul>
<p>という懸念が挙げられました。そして最終的には karte-ops リポジトリのマニフェストに直接サイドカーの設定を追加することになりました。</p>
<p>さて、当日いただいた質問の一つに「認可基盤のサイドカーがない状態でデプロイすることを防ぐ仕組みはあるか」というものがあります。上述の通り、認可基盤のサイドカーは自動ではインジェクションされないため、現時点ではそのリスクがあります。しかしマニフェストに対しては conftest を実施しており、事前に定義したルールに沿った設定になっているかを CI でチェックしています。サイドカーなしのデプロイもこれで検知できるのではないかと考え、検討を進めています。</p>
<h1>最後に</h1>
<p>当日のブースにご来場いただいた皆様、セッションをお聞きいただいた皆様、ありがとうございました。個人的には初の登壇でしたが、貴重な経験をさせていただいたことに感謝申し上げます。</p>
<p>そしてイベントのスタッフの皆様、企画ならびに運営のほどありがとうございました。Platform Engineering というテーマに思いを馳せつつ、さまざまな学びを得ることができる良い機会となりました。</p>
<p>今後のプレイドにとっても Platform Engineering は重要なテーマです。今回の参加で得た学びを活かしつつ、日々の開発に取り組んでまいります。</p>


Platform Engineering Kaigi 2024の登壇者によるレポート記事です。「モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫」と題したセッションの発表内容を紹介しています。

Platform Engineering Kaigi 2024登壇レポート_プレイドエンジニアブログ

Platform Engineering Kaigi 2024登壇レポート