本記事は、私たちメルカリのDBRE（Database Reliability Engineering）チームが先日公開した TiDB Cloudのオートスケール改善 – 時間帯別制御、TiKVへの拡張、運用の自動化 の後続記事です。 この記事では TiKV の水平スケールに焦点を当て、PD(Placement Driver。TiDB クラスタのデータの配置を管理するコンポーネント)がリージョンを移動させる仕組みと、その速さを左右するパラメータを整理します。そのうえで、実際の運用で直面した 3 つの課題と、私たち DBRE チームがそれぞれにどのように対処したかを共有します。 本記事で紹介する 3 つの課題とその対処は、9月11日に開催された 第10回 TiDB User Group Meetup での 発表「TiDB Cloud のカスタムコントローラによるオートスケール対応」 でお話しした内容です。 何をしようとしたか TiKV はデータを保持するため、ノードを追加しただけでは負荷は分散されません。既存のノードからデータやリーダーが移動して初めて、追加したノードの処理能力を活用できます。移動に時間がかかるほど、負荷のピークより早くスケールアウトする必要があり、余分なコストが発生します。スケールインでも、データの退避が終わるまでノードを削除できません。 1 枚目の図は、リージョン移動が遅いほど、追加したノードの処理能力を活用するまでに時間がかかることを示しています。2 枚目の図の斜線部分は、その遅れを見込んで早めにスケールアウトすることで発生する余分なコストです。 そこで私たちは、アプリケーションへの影響を抑えながらリージョンをできるだけ早く移動させ、ノード間の負荷を均衡させることを目指しました。ただし、リージョンの移動自体も CPU やディスク I/O、ネットワーク帯域を使います。同時に大量のデータを移動すると、通常のリクエスト処理を圧迫し、レイテンシの悪化につながります。 リージョンの配置や移動は、PD が 基本戦略 に沿って自律的に制御します。以降では TiKV ノード 1 台を store と呼びます。各リージョンは複数の store にレプリカ(peer)を持ち、そのうち 1 つがリーダーを担います。私たちが主に調整したのは、配置の基本戦略ではなく、移動の並列度や流量に関わるパラメータです。 データの移動は、大きく 3 つの段階で捉えられます。PD が移動の指示である operator を作り、store ごとの制限(store limit)で移動量を絞り、TiKV がスナップショットを送受信・適用します。それぞれの段階に上限があるため、移動を速めるには、どこが律速になっているかを見極める必要があります。律速ではない段階の上限を緩めても、移動は速くなりません。 私たちは、パラメータを 1 つずつ変更し、メトリクスで効果とアプリケーションへの影響を確認しながら調整しました。TiDB Cloud では PD の設定を直接変更できないため、変更はサポートチケットを通じて依頼しました。各段階に関わるパラメータの詳細は、末尾の「補足：リージョン移動に関わるパラメータ」にまとめています。 こうした調整を進める中で、移動速度の設定だけでは解決しない問題も見えてきました。ここからは、実際に直面した 3 つの課題と、その対処を紹介します。 TiKVの水平スケールの課題1. 負荷の偏り 最初に紹介するのは、PD が何を基準にリージョンを動かすかという基本戦略に起因する課題です。移動の速さを調整するだけでは解決できず、負荷の偏りを生む原因から調べる必要がありました。 最初に直面した問題は、TiKV ノードごとの負荷の偏りです。水平スケールで実データを移動させると、ノード間の負荷の偏りがそれまで以上に顕在化しました。具体的には特定の TiKV ノードに CPU 負荷が集中し、サービスへの影響を防ぐために目標 CPU 利用率を低めに設定せざるを得なくなり、コスト効率が悪化しました。 私たちはまず、どのテーブルのどのクエリが偏りを引き起こしているかを調査しました。暫定的な対処として、該当テーブルのリージョンが自動でノード間を移動しないように設定したうえで、負荷が均等になるようリージョンをノードに分散して配置しました。この操作は TiDB Cloud の標準機能では提供されていないため、サポートチケット経由のイレギュラーなオペレーションとして PingCAP社に対応いただきました。 しかし、特定のデータの配置を固定し続けることは恒久的な対策にはなりません。あるタイミングで固定化を解除したところ、再び同じような負荷の偏りが発生しました。負荷が特に高い箇所はホットリージョンと呼ばれ、私たちはリージョンやリーダーと同じようにホットリージョンも自動でバランスされることを期待していましたが、実際の挙動はそうなりませんでした。 そこで、ホットリージョンがどのように判定され、どのように負荷が分散されるのかを調査しました。その結果、当時のバージョンでは通信帯域やリクエスト数はホットかどうかの指標として考慮される一方、CPU のコストは考慮されないことが分かりました。つまり PD はそもそも CPU 使用率の偏りを解消する方向には動かないため、CPU 使用率の偏りは必然的に発生していたのです。 メルカリでは、データサイズは小さい一方で CPU 使用率の高いクエリが集中する特定のテーブルがあり、そのデータを持つ TiKV ノードの CPU 負荷が高くなっていました。現時点ではこの偏りを解消するのが難しいため、バージョンアップを行うまでの間は、該当テーブルの書き込みは TiDB で受けつつ、読み取りは MySQL で処理することにしました。 この判定基準は v8.5.7 で改善されます。v8.5.7 では TiKV がホットリージョンの読み取りの CPU 使用率を PD に報告し、PD はそれを読み取りのホットリージョンのスケジューリングの指標として使えるようになります( v8.5.7 リリースノート )。私たちは v8.5.7 へのバージョンアップ後に、この暫定的な対処を見直す予定です。 TiKVの水平スケールの課題2. 一括でスケールするか、小刻みにスケールするか 負荷の偏りに加え、スケールの刻み方にも課題がありました。負荷の変化に細かく追従させるなら、ノードを少しずつ追加・削除するのが理想です。しかし TiDB Cloud ではクラスタの状態に関する制約があり、小刻みなスケールがかえってクラスタ全体のスケールを妨げることが分かりました。結論として、私たちはスケールアウトは一度にまとめて、スケールインは一段階ずつ行う方針を取っています。 前提となるのは、 前回の記事 でも紹介した TiDB Cloud のステータス遷移の制約です。TiDB または TiKV のノード数を変更すると、クラスタは modifying 状態になり、再び available 状態に戻るまで次の変更を受け付けません。TiDB と TiKV は同じクラスタに属しているため、どちらか一方を変更している間は、もう一方もスケールできなくなります。 スケールアウトでは、TiKV のノードを追加すると通常はすぐに available に戻ります。しかし TiDB Cloud の内部実装上、直前の変更によるリーダーの移動などが続いている間は、modifying から available へのステータスの更新がブロックされます。そのため TiKV を小刻みにスケールアウトすると、クラスタが modifying のまま留まる時間が長くなり、その間は TiDB をスケールアウトできなくなってしまいます。そこで私たちは、必要になる TiKV のリソースを数時間前にまとめてスケールアウトし、負荷が増える時間帯にはクラスタを available に保って TiDB をいつでもスケールアウトできるようにしました。TiKV のスケールの前に TiDB をバッファーとして先に追加する「2 段階スケール」については、前回の記事で詳しく紹介しています。 スケールインは、そもそも時間のかかる操作です。TiKV のノードを削除するには、そのノードが持つすべてのリージョンを他の store へ退避させる必要があり、その間クラスタは modifying 状態のままになります。負荷が下がる時間帯には TiDB もスケールインしたいのですが、TiKV のスケールイン中は TiDB のスケールインがブロックされてしまいます。そのため、スケールインは一度に大きく減らすのではなく一段階ずつ実施し、段階の合間に TiDB と TiKV のどちらも操作できる機会を作るようにしました。その合間に TiDB と TiKV のどちらをスケールインするかは、前回の記事で紹介した優先順位の仕組み(合計 CPU 数をより多く減らせる方を選ぶ)でカスタムコントローラーが判断しています。 なぜ水平スケールと垂直スケールを併用しないのか 前回の記事 では、TiDB Cloud のスケール操作が tidb-operator v1 ベースであることを踏まえて、TiKV の水平スケールと垂直スケールはどちらか一方のみを有効にすることを推奨し、その理由は別の記事で説明すると書きました。ここでは、OSS の tidb-operator v1( release-1.6 )の実装をもとに、その理由と、この章で紹介した制約との関係を整理します。ただし、TiDB Cloud が内部で使っている版や独自の制御によって、細かな挙動は異なる可能性があります。 tidb-operator v1 は、TiDB クラスタ全体を 1 つの TidbCluster リソースとして管理し、PD、TiKV、TiDB といった各コンポーネントを決まった順番で同期します。いずれかのコンポーネントが「まだ完了していない」という結果を返すと、その回の同期はそこで終わり、後続のコンポーネントは処理されません( tidb_cluster_control.go )。TiKV のスケールインでは、削除対象の store がすべてのリージョンを退避し終えて Tombstone になるまで「完了していない」が返り続けるため( tikv_scaler.go )、その間は TiKV より後に処理される TiDB のスケールが進みません。また、スケールインは既定で 1 台ずつ、番号の大きい Pod から順に行われます。上で述べた「TiKV のスケールイン中は TiDB のスケールインがブロックされる」という制約は、この仕組みと一致します。 一方、TiKV の垂直スケール(インスタンスクラスの変更)は、v1 では StatefulSet のローリングアップデートとして処理されます( tikv_upgrader.go )。Pod を番号の大きいものから 1 台ずつ、再起動の前にリーダーを退避させ、再起動の後にリーダーが戻るのを待ちながら進めます。この待ちの間も同期は TiKV で止まるため、垂直スケール中も TiDB のスケールは進みません。 さらに、v1 ではノード数の変更(水平スケール)がローリングアップデートより優先されます。ここでいうローリングアップデートは、バージョンアップに限らず、インスタンスクラスの変更などで Pod の定義が変わったときに Pod を順に作り直す処理のことで、前段で述べた垂直スケールもこれにあたります。そしてローリングアップデートは、すべての store が Up(または Tombstone)になるまで始まりません( tikv_member_manager.go )。そのため、水平スケールインで退避中の store がある間は垂直スケールが始まらず、垂直スケールの途中に水平スケールが入るとそちらが先に処理されます。両方を有効にすると、互いの完了を待ち合う時間が長くなり、その間ずっと TiDB もスケールできない状態が続きます。これが、私たちがどちらか一方のみを有効にしている理由です。 こうした制約は、tidb-operator v2 で緩和される見込みです。v2 では StatefulSet への依存をなくし、 TidbCluster をコンポーネントごとの独立したリソースに分割したうえで、インスタンス単位での管理や、リーダーの移動が繰り返されにくいローリングアップデートの順序をサポートしています( TiDB Operator v2 と v1 の比較 )。TiDB Cloud が v2 ベースに移行すれば、TiDB と TiKV のスケールをより独立して行えるようになることを期待しています。 TiKVの水平スケールの課題3. 負荷分散が遅い スケールの刻み方を工夫しても、スケールアウト後の負荷分散には時間がかかりました。読み取りが中心のワークロードでは、リーダーが新しい store へ移れば読み取りも分散されるため、実データの移動を伴わないリーダーの移動が終われば負荷は早めに均衡すると期待していました。しかし実際には、リーダーの移動、リージョンの移動、ホットリージョンの移動の順に進み、リージョンの移動がすべて終わるまで負荷は均衡しませんでした。 原因を探るため、私たちはまず PD の実装を確認し、スケールアウト時にリージョンを動かす 2 つのスケジューラがどのように operator を作り、実行に至るのかを整理しました。新しい store へリージョンを分散させる balance-region は store 間のリージョンの合計サイズを均等にし、負荷を分散させるのは balance-hot-region の役割です。両者は独立して動きますが、作られた operator は共通の待機キューと、冒頭で紹介した store limit を通って実行されます。 待機キューでは、balance-hot-region の operator は優先度 High、balance-region の operator は Medium として扱われ、優先度に応じた重み付きのランダムで取り出されます。そのため本来はホットリージョンの移動が優先されるはずですが、実際には、エンキューされたホットリージョンの operator が store limit によってキャンセルされ、移動が妨げられていました。balance-region が大量の operator を投入して store limit を使い切ってしまう一方で、balance-hot-region は呼び出し間隔が長く、一度に動かせる数も少ないためです。デフォルトの store-limit-version: v1 は、store ごとに 1 分間あたりに追加(add-peer)・削除(remove-peer)できる peer の量を固定値で制限します。この制限は優先度を区別しないので、待機キューで得た優位が実行の直前で失われてしまいます。 この仮説を確かめるため、TiDB Cloud のサポートに依頼して balance-region-scheduler だけを一時的に停止し、各種メトリクスの変化を観察しました。TiDB Cloud では PD の統計情報のダッシュボードが公開されていないため、特定の時間帯の PD の統計もチケットで依頼して提供してもらいました。こうした観察を通じて、ホットリージョンの移動が store limit に阻まれていることを裏付けました。 対策として有効だったのは、store limit の方式を store-limit-version: v2 に切り替えることです。v2 では operator の個数ではなく、スナップショットを送る側の store が同時に扱う量を制限し、その上限も優先度ごとに予備の枠を持ちます。そのため balance-region の operator が多くても、優先度の高いホットリージョンの移動は store limit にブロックされず、v2 の設定でホットリージョンの移動を早められることを確認できました( Principles of Store Limit v2 )。 この課題から分かるのは、「どのスケジューラを優先するか」が優先度の設定だけでは決まらないということです。operator が実行されるまでの待機キューと、冒頭で整理した 2 段階目の store limit のどちらで絞られているかによって、優先度が有効に働くかどうかが変わります。パラメータはそれぞれ役割が異なるため、仕組みを理解したうえで組み合わせを調整する必要があります。 まとめ 本記事では、TiDB Cloud 上で TiKV を水平スケールさせるにあたり、アプリケーションへの影響を抑えながらリージョンをできるだけ早く移動させ、負荷を均衡させるために私たちが取り組んだ内容を紹介しました。TiKV はデータを持つノードであるため、リージョン移動の速さがそのままオートスケールの効果を左右します。 リージョンの移動は PD の基本戦略に沿って自律的に行われ、私たちが制御できるのは主にその速度です。移動は「PD が operator を作る」「store ごとに流量を絞る」「TiKV がスナップショットを送受信・適用する」という 3 段階で進み、速さはそのどこかで必ず頭打ちになります。律速ではない段階のパラメータを緩めても移動は速くならず、アプリケーションへの影響のリスクだけが増えるため、私たちはパラメータを 1 つずつ変更しては効果を測り、律速になっている箇所を見極めながら進めました。 実際の運用では 3 つの課題に直面しました。1 つ目の負荷の偏りは、ホットリージョンの判定に CPU のコストが考慮されないという PD の判断基準に起因するもので、パラメータでは解決できないため、該当テーブルの読み取りを MySQL で処理することで対処しました。2 つ目のスケールの刻み方は、TiDB Cloud のステータス遷移の制約と tidb-operator v1 の仕組みにより、TiDB と TiKV が互いの変更を待たされることが原因で、スケールアウトはまとめて、スケールインは一段階ずつ行う方針で対処しました。3 つ目の負荷分散の遅さは、優先度の高いホットリージョンの移動が store limit でキャンセルされていたことが原因で、 store-limit-version: v2 によってホットリージョンの移動を早められることを確認しました。 これらの取り組みを通じて分かったのは、パラメータの値そのものよりも、そのパラメータがどこでどのように効くのかという仕組みを理解することが重要だということです。こうした理解は、ドキュメントだけでなく PD や tidb-operator の実装を読み、メトリクスで裏付けることで得られました。また TiDB Cloud では PD の設定を直接変更できないため、PingCAP のサポートと協力しながら検証を重ねたことも、解決に欠かせない要素でした。パラメータの変更やスケジューラの一時停止といったイレギュラーな依頼、検証のための PD の統計の提供などに丁寧に対応していただいた TiDB Cloud のサポートチームの皆さまに、この場を借りて感謝いたします。 今後は、読み取りの CPU 負荷をホットリージョンの判定に考慮する v8.5.7 へのバージョンアップで負荷の偏りを解消することや、TiDB Cloud の tidb-operator v2 への移行によって TiDB と TiKV のスケールをより独立して行えるようになることを期待しています。私たちは引き続き、TiDB をより効率よく、安定して運用できるよう取り組んでいきます。 お知らせ 現在メルカリでは、筆者が所属するDBREチームのEM（Engineering Manager）およびIC（Individual Contributor）を募集しています。 本記事へのご感想をSNSなどで共有していただけると嬉しく思います。また、本記事をきっかけにご応募いただく際は、応募時や面談の際に「この記事を読んだ」とお伝えください。 募集の詳細は、以下のリンクをご覧ください。 EM https://apply.workable.com/mercari/j/7AD4EF9218/ IC https://apply.workable.com/mercari/j/ACD2689E9E/ 補足：リージョン移動に関わるパラメータ 本文で紹介した 3 段階に沿って、リージョン移動に関わるパラメータを整理します。設定を確認する際のリファレンスとして、デフォルト値と制御対象を以下にまとめます。 1. PD の operator の同時実行数 PD がクラスタ全体で同時にどれだけの operator を走らせるかを決める部分です。 region-schedule-limit や leader-schedule-limit 、 hot-region-schedule-limit 、 replica-schedule-limit といった *-schedule-limit がこれにあたり、operator の種類ごとに同時実行数の上限を定めます。たとえばスケールアウト時に新しいノードへリージョンを分散させる balance-region は region-schedule-limit の、スケールイン時に削除するノードからリージョンを退避させる処理は replica-schedule-limit の制約を受けます。 パラメータ デフォルト 制御するもの region-schedule-limit 2048 balance-region の同時数。scale-out 時に新ノードへ region を分散する並列度 replica-schedule-limit 64 checker(rule / replica checker)が作る operator の同時数。scale-in で offline になった store からの退避や、欠けた replica の補充 leader-schedule-limit 4 leader 移動の同時数 hot-region-schedule-limit 4 ホットリージョンの同時スケジュール数 merge-schedule-limit 8 Region Merge の同時数(0 で無効) 2. store ごとの移動量の制限 個々の store に負荷が集中しすぎないようにするための制限です。PD は operator を登録するときに store limit と照らし合わせ、上限を超える operator は受け付けずにキャンセルします。v1 と v2 の違いが負荷分散に与えた影響は、「TiKVの水平スケールの課題3. 負荷分散が遅い」で紹介したとおりです。 パラメータ デフォルト 制御するもの store limit add-peer 15 / 分 1 store へ peer を追加できる量(1 分あたり)。新ノードの充填の上限(v1) store limit remove-peer 15 / 分 1 store から peer を削除できる量(1 分あたり)。scale-in の drain や送り元の負荷(v1) store-limit-version v1 v1 は固定値、v2 は TiKV の snapshot 処理能力に応じて自動調整( v2 の仕組み ) max-snapshot-count / max-pending-peer-count 64 / 64 1 store あたりの同時 snapshot 数 / pending peer 数の上限 store limit は既定ではすべての store に同じ値が適用されますが、特定の store だけに個別の値を設定することもできます。pd-ctl では store limit all <rate> add-peer のように全 store を対象にするほか、 store limit <store_id> <rate> add-peer のように store を指定でき、たとえばスケールアウトで追加した store だけ add-peer の上限を引き上げるといった使い方ができます( Set limit for a single store )。なお、この add-peer / remove-peer の値が使われるのは v1 の場合で、TiDB Cloud では pd-ctl を利用できないため、この設定もサポートチケットで依頼します。 3. TiKV のスナップショット処理 TiKV がリージョンのデータを実際に運ぶ部分です。リージョンのリーダーを持つ store がスナップショットを生成して新しい store へ送り、受け取った store がそれを適用します。スナップショット処理のディスク帯域を制限する snap-io-max-bytes-per-sec や、同時に送受信するスナップショット数を制限する concurrent-send-snap-limit / concurrent-recv-snap-limit などがこの段階の速さを決めます。 パラメータ デフォルト 制御するもの server.snap-io-max-bytes-per-sec 100MiB snapshot 処理のディスク帯域 server.concurrent-send-snap-limit / concurrent-recv-snap-limit 32 / 32 同時に送受信する snapshot の数 raftstore.snap-generator-pool-size 2 snapshot を生成するスレッド数(送り元) raftstore.apply-pool-size / store-pool-size 2 / 2 Raft log の適用 / 処理のスレッド数 各パラメータのデフォルト値や詳しい意味は、公式ドキュメントの PD Configuration File 、 Store Limit 、 TiKV Configuration File を参照してください。

はじめに 検索基盤チームの mrkm4ntr です。以前、 CPU 使用率による Elasticsearch の autoscaling について書きました。ピーク時間帯に合わせて確保していたリソースを、トラフィックに合わせて増減することで、Elasticsearch のコストを約 40% 削減できました。 この autoscaling には、まだコストを削る余地が残っていました。この記事では、そのために行った 2 つの改善を紹介します。 scale-out の高速化 : shard のコピー待ちをなくすために、PVC に shard を事前に同期しておく仕組みを作りました。 HPA の tolerance の調整 : 1 のおかげで HPA の CPU threshold を高くできるようになった結果、tolerance が新しい問題になりました。これを HPA ごとの設定と CronJob で解消しました。 課題 scale-out が間に合わない Elasticsearch のノードを増やすと、新しいノードには他のノードから shard が複製されます。これが Peer Recovery で、大きく 2 つのステップに分かれます。 ファイルコピー : primaryが持つ segment ファイルを、ネットワーク越しに新しいノードへ丸ごとコピーします。 差分の追い付き : コピーしている間にも更新は続くので、その間に発生した変更を translog から再生して追い付きます。 時間がかかるのはほとんどが 1 です。私たちのクラスタは 1 shard が大きく、コピーが終わるまで 10 分以上かかります。その間、新しいノードは検索を処理できません。 threshold を下げて凌いでいた HPA は、負荷が上がったことを検知してから台数を増やします。ノードが使えるようになるまで 10 分以上待つことになると、急なトラフィック増には間に合いません。 そこで、HPA の CPU 使用率の threshold をあえて 65% 前後と低めに設定し、まだ余裕があるうちに早めに scale-out を始めるようにしていました。scale-out の遅さを、平常時の余裕で補っていたことになります。 安全ではありますが、その余裕のぶん、autoscaling で得られるコスト削減は小さくなります。 改善 1: PVC 事前同期で scale-out を高速化する アイデア Peer Recovery が遅いのは、新しいノードのディスクにデータがなく、ステップ 1 のファイルコピーが避けられないからです。それなら、あらかじめデータを持ったディスクを用意しておけばよいはずです。 そこで Replicator という Pod を常駐させます。Replicator は次のような役割の Pod です。 通常のノードと同じように shard の replica を持ち、PVC にデータを同期し続ける。 検索リクエストは受けない。 scale-out するときは、Replicator を通常ノードに昇格させます。PVC にはすでに shard の実体があるので、ファイルコピーは不要です。起動後は、同期が止まっていた間の更新を取り込むだけの Local Recovery で済みます。 回復方法 ファイルコピー 差分の追い付き Peer Recovery（従来） 必要（shard 全量） 必要 Local Recovery（今回） 不要 必要 Replicator の数は shard 数と同じです。各 Replicator が、ちょうど 1 つの shard を持つ構成（1 ノードあたり 1 shard）を前提にしています。つまり Replicator 全体で、インデックスの全 shard を 1 セット余分に持ち、いつでも通常ノードに昇格できる状態で待機することになります。 ただし通常ノードより小さいリソースで動かすので、常駐させるコストは抑えられます。ところが、この「小さいリソースで動かす」という点で、Kubernetes の制約にぶつかります。 壁: StatefulSet の Pod は全部同じサイズ 通常ノードと同じサイズで Replicator を常駐させてしまうと、インデックスのコピー 1 セット分のリソースを丸ごと余分に確保することになり、コスト削減になりません。Replicator は検索を処理しないので、本来 CPU も memory も少なくて済みます。 ところが、Elasticsearch を StatefulSet で動かしていると、これが簡単ではありません。StatefulSet 配下の Pod は、すべて同じ Pod テンプレートから作られるため、サイズも同じになります。Replicator だけ小さくする方法がありません。別の StatefulSet に分ける方法もありますが、PVC の名前が StatefulSet ごとに決まるため、昇格のたびに PVC の付け替えが必要になります。 そこで、Replicator と通常ノードを 同じ StatefulSet に置いたまま 、Pod の作成時に MutatingWebhook でサイズを書き換えることにしました。StatefulSet のテンプレートは通常ノードのサイズのままで、特定の Pod だけ、作られる瞬間に Replicator 用の設定に差し替えます。 アーキテクチャ StatefulSet の Pod には、 es-data-0 、 es-data-1 、… のように、名前の末尾に 0 からの連番が付きます（この番号を ordinal と呼びます）。この番号を使って、通常ノードと Replicator を見分けます。 shard が 12 個で、1 ノードに 1 shard の構成を例にします。 es-data-0 〜 es-data-11 : 通常ノード（各 1 shard） es-data-12 〜 es-data-23 : Replicator（各 1 shard の replica） StatefulSet の replicas は 24 になります。番号が小さい方から通常ノード、それ以降が Replicator、という分け方です。 【図 1: 定常状態。通常ノード 12 台と Replicator 12 台が同じ StatefulSet に並び、それぞれ PVC を持つ】 Webhook は、Pod の番号が通常ノードの台数以上であれば、その Pod を Replicator として次のように書き換えます。 対象 変更内容 ラベル Replicator であることを示す role ラベルを付与 リソース Elasticsearch コンテナと、ECK が注入する initContainer の request / limit を縮小 ES_JAVA_OPTS heap サイズを、縮小した memory に合わせて再計算 ノード属性 検索から除外する属性を付与 initContainer のリソースも書き換えているのは、Pod 全体の実効的な request が、initContainer の request の影響も受けるためです。ここを残すと、Pod のサイズが小さくならないことがあります。 通常ノードの台数は、controller が ScalableElasticsearchNodeSet に記録し、Webhook はそれを見て境界を判断します。HPA が指定する台数と、実際の通常ノード数は、shard 数との兼ね合いで切り上げられてずれることがあるためです。 Replicator に配置される shard と、検索の除外については、Elasticsearch 側にも手を入れています。 shard の配置（plugin） : Pod 名の末尾の番号から、どの shard を持つかが決まるようにする plugin を作りました（番号を shard 数で割った余りが shard ID です）。たとえば es-data-12 は shard 0 を持ちます。これにより、各 Replicator は必ず 1 つの shard を持ち、他の Replicator と重複しません。 検索の除外（patch） : 検索リクエストの宛先から、先ほどのノード属性を持つノードを外すよう、Elasticsearch 本体にパッチを当てています。 昇格・降格のフロー scale-out（通常ノード 12 台 → 24 台） controller が、通常ノードの台数を 24 に更新する。 es-data-12 〜 es-data-23 の Replicator の Pod を削除する。 StatefulSet が Pod を再作成する。このとき Webhook は、通常ノードの設定（元の大きなサイズ）を適用する。 PVC には shard のデータが残っているので、Local Recovery だけで検索を受けられるようになる。 続いて、StatefulSet の replicas を 24 から 36 に増やす。新しく作られる es-data-24 〜 es-data-35 は、新しい Replicator として起動する。 index の replica 数を増やす。 この順序は入れ替えられません。先に replicas を増やしてしまうと、新しい Pod が古い台数の情報を読んでしまい、Webhook が誤った設定を適用します。 新しい Replicator は Peer Recovery でデータを全量コピーしますが、検索を受けないので、新しい Replicator のコピー完了を待たずに、昇格した通常ノードで検索を提供できます。コピーの待ち時間が、検索を受ける経路から外れたことになります。 ノードに空きがない場合 昇格のときは、Pod を大きなサイズで作り直します。元のノードに空きがあれば、同じノードにそのまま再作成されます。空きがなければ、別のノードに Pod がスケジュールされ、Kubernetes の Attach/Detach controller が PV を新しいノードに付け替えます 。 どちらの場合も、shard のコピーは発生しません。コピーされるのではなく、PV そのものが移動します。PV の detach から attach までにかかる時間は 1 分程度で、shard を丸ごとコピーするのに比べれば、はるかに短く済みます。 scale-in（通常ノード 24 台 → 12 台） scale-out の逆の順序で戻します。 index の replica 数を減らし、shard の再配置が終わるのを待つ。 通常ノードの台数を 12 に更新する。 es-data-12 〜 es-data-23 の Pod を削除する。再作成されるとき、Webhook は Replicator の設定（小さなサイズ）を適用する。 StatefulSet の replicas を 36 から 24 に減らし、 es-data-24 〜 es-data-35 を削除する。 降格した Pod は、PVC のデータを持ったまま Replicator になります。そのため、次の scale-out に向けた準備が、そのまま整った状態になります。 HPA との連携 HPA は、 ScalableElasticsearchNodeSet の scale subresource を見て、台数と CPU 使用率を判断します。Replicator は検索を受けず、リソースのサイズも通常ノードとは違うので、これを一緒に数えたり平均に混ぜたりすると、scale の判断が狂います。 そこで、HPA に見せる値からは Replicator を除きます。 台数（ status.count ）と ready な台数（ status.readyCount ）から、Replicator を引く。 Pod を選択するセレクタに、Replicator ではないことを条件として加える。 これで、HPA は通常ノードだけを見て判断できます。 改善 2: HPA の tolerance をピークに合わせて切り替える threshold を上げると tolerance が効いてくる 改善 1 で scale-out の待ち時間が短くなったので、HPA の CPU 使用率の threshold を、65% 前後から 80% 前後まで引き上げられるようになりました。threshold を上げれば、同じトラフィックを少ない台数でさばけます。 ところが、threshold を上げると、新しい問題が出てきました。HPA の tolerance です。 HPA は、現在の指標が target に対してどれだけ離れているかを比で計算し、その比が 1 ± tolerance の範囲内であれば、何もしません。小さな変動のたびに台数が増減するのを防ぐための仕組みで、デフォルトは 0.1（10%）です。 target が 65% のとき、scale-out が始まるのは、約 71.5% を超えたときです。target との差は 6.5 ポイントです。target が 80% のときは、88% を超えるまで scale-out しません。差は 8 ポイントで、target を上げるほど、tolerance が作る不感帯の幅（ポイント換算）は広がります。scale-in も同様に、72% を下回るまで起きません。 さらに、HPA には stabilizationWindow があります。短時間の揺れで台数が増減しないよう、一定期間の推奨台数を見てから判断する仕組みです。私たちはスラッシング防止のために、もともとこの窓を設けていました。tolerance を超えてからさらにこの窓の分だけ待つことになり、遅れが二重に積み重なります。threshold を上げて余裕を削ったぶん、この遅れの影響が大きくなりました。 かといって、tolerance や窓を単純に小さくすると、今度は台数が頻繁に増減するスラッシングが起きます。私たちが絶対に避けたいのはこれで、台数が増減するたびに shard の再配置や昇格・降格が走るためです。 HPA ごと・方向ごとに tolerance を設定できるようになった tolerance は、以前は kube-controller-manager の --horizontal-pod-autoscaler-tolerance フラグで指定する、クラスタ全体に一律の値でした。特定の HPA だけ変える方法がありません。 これが KEP-4951 で変わりました。 HPAConfigurableTolerance という feature gate として Kubernetes v1.33 で alpha、v1.35 で beta となり、v1.37 で GA になっています。 これにより、HPA の spec.behavior.scaleUp.tolerance と spec.behavior.scaleDown.tolerance で、HPA ごと、さらに scale-out と scale-in の方向ごとに tolerance を指定できます。beta になった v1.35 以降であれば、デフォルトで有効です。 CronJob で切り替える 反応の速さとスラッシングの回避は、一律の設定では両立しません。そこで、トラフィックの向きに合わせて、tolerance と stabilizationWindow を 1 日のなかで切り替えることにしました。 トラフィックには、ピークに向かって上昇する時間帯と、ピークを過ぎて下降する時間帯があります。考え方は、 今のトレンドと逆向きの操作を抑える ことです。 ピークに向かう間 : scale-out はしやすくする（ scaleUp.tolerance を小さく、 scaleUp.stabilizationWindowSeconds を短く）。scale-in はしにくくする（ scaleDown.tolerance を大きく、 scaleDown.stabilizationWindowSeconds を長く）。上昇中に scale-in すると、すぐに scale-out が必要になるため。 ピークを過ぎた後 : scale-in はしやすくする。scale-out はしにくくする。再び上昇傾向に入るまでは、下降中に scale-out しても、すぐ scale-in が必要になるため。 切り替えは、決まった時刻に CronJob が HPA の behavior を patch することで行っています。 効果 2 つの改善の結果、次のようになりました。 項目 改善前 改善後 scale-out の所要時間 12 分 2 分 HPA の CPU threshold 65% 80% ファイルコピーの待ちがなくなったことで、scale-out は 2 分で終わるようになりました。その結果 threshold を引き上げられるようになり、同じトラフィックをより少ない台数でさばけています。 tolerance と stabilizationWindow の切り替えにより、threshold を上げても、スラッシングは起きていません。 まとめ この記事では、Elasticsearch の autoscaling を改善するために行った 2 つの取り組みを紹介しました。 StatefulSet の Pod は全部同じサイズ、という制約を MutatingWebhook で回避し、PVC に事前に shard を同期した Replicator を常駐させることで、scale-out から shard のコピー待ちをなくしました。 その結果 HPA の threshold を引き上げられるようになり、顕在化した tolerance の問題を、HPA ごと・方向ごとの tolerance と stabilizationWindow の設定、および CronJob による切り替えで解消しました。 Kubernetes 側の Pod 制御と、Elasticsearch 側の shard 配置・検索対象の制御を組み合わせることで、検索を提供するまでの経路から全量コピーの待ち時間を切り離しました。同じように、StatefulSet の制約や HPA の挙動に悩んでいる方の参考になれば幸いです。

2026年9月16日(水)「Merpay Tech Talk 〜メルカリグループ全体を支える決済基盤の全容［会計編］〜」をオンラインで開催しました。 決済と会計をつなぐ基盤はどのように発展してきたのか、そして、その過程でどのような技術的・組織的課題に向き合ってきたのか。その舞台裏をお届けします。詳細は、アーカイブ動画もあわせてご覧ください。 <div style="aspect-ratio: 16 / 9; width: 100%;"> <iframe src=" https://www.youtube.com/embed/IgW7Vy2Nal0 " style="width: 100%; height: 100%;" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen> </iframe> </div> 登壇者 今回の登壇者は、Payment & Customer Platformチームでバックエンド開発に携わる以下の3名です。 @mewuto / 株式会社メルペイ Product Engineer（Accounting Team） @kobaryo / 株式会社メルペイ Product Engineer（Balance Team） @komatsu / 株式会社メルペイ Engineering Manager（Payment Core / Payment Solution / PCP Foundation Team） 会計システムの概要と歴史 上場企業には、投資家に届く財務情報を守るための会計要件があります。期限内の書類提出、内部統制、外部監査という3つの制度で、メルカリ・メルペイに限らず、日本の上場企業に共通するものです。いずれかを守らなければ罰金や懲役が科されることもあり、どこに見せても問題のない開発プロセスで会計データを作るシステムが欠かせません。 私たちの会計システムが扱うのは、1取引ごとの明細を記録し、監査時に取引の発生経緯を追跡できる「サブレジャー」と呼ばれる領域です。 ここで鍵になるのが、複式簿記という考え方です。単式簿記は家計簿のように残高の増減だけを記録しますが、複式簿記では「借方」と「貸方」の両方を記録し、その合計をシステムが検証します。金融・フィンテック領域で複式簿記が標準とされるのは、記帳ミスの自動検知、書き込みの原子性、因果関係の追跡性をスキーマレベルで担保できるためです。 メルペイの会計システムは、これまで3つの世代を経てきました。 第1世代は本番データベースを直接参照する方式で、過去時点の残高を再計算できないという課題がありました。第2世代では業務データと会計データを分離しましたが、決済と会計それぞれのイベント送信が非同期かつ独立していたため、どちらかが失敗した際に人の手で突合・修正する必要がありました。 第3世代では、残高管理サービスが残高移動と会計イベントの送信をセットで行う構造に刷新し、アトミックな書き込みを実現しています。 3世代のマイクロサービスを並行運用すること自体が、コストになっています。 第1世代から第2世代への移行では、上流にある20以上のマイクロサービスそれぞれに、移行・新規導入を呼びかける必要がありました。「安定して正確な会計データを出したい」という要請と、各事業側の対応リソースとの間で足並みをそろえるのに時間がかかったといいます。 なかには、担当者自らが該当のマイクロサービスに直接入り込み、移行作業を行ったケースもあったそうです。第1世代は今後約1年で廃止予定とのことで、その後は第2世代の縮退に向けた取り組みが控えています。 残高管理から台帳サービスへの進化 残高管理サービスは、この過程で「台帳サービス」へと進化しました。 従来は、お客さまの残高や加盟店の売上金といった実態のある残高だけを管理していましたが、現在はお金の流れ全体を記帳する責務を持つようになっています。内部的には、あらゆる価値の移動を「Exchange」という単一のエンドポイントに抽象化しています。 さらに、残高種別ごとの振る舞いを宣言的に定義する「Account spec」という仕組みにより、新しい残高種別の追加にも最小限の変更で対応できる設計になっています。 この進化によって、実際のお金の流れと会計情報の間の信頼性が向上しました。また、フロー情報（取引の記録）だけでなく、ある時点での資産額を示すストック情報も出しやすくなり、新規ビジネスや新しい会計要件への対応スピードも上がりました。 セッション後半の質疑応答では、この台帳サービスに関する質問が寄せられました。 「決済サービスが会計の知識をどこまで持つべきか」という質問に対して、現在は残高管理、つまり台帳サービス側が会計との整合性を担う設計になっていると説明しました。プロダクト側や決済サービス側が会計ドメインと密結合する必要はなくなってきています。 一方で、会計コード以外の会計知識は会計帳簿サービスが引き続き保持しています。そのため、台帳サービスは会計の知識と疎結合になっているとのことです。 また、「加盟店の残高もホットスポット（頻繁に更新される箇所）になり得るか」という質問に対しては、実際にホットスポットになっているため、非同期で更新していると説明しました。非同期で更新する口座についても、ストック情報を出せるように工夫しています。 決済基盤と会計をつなぐ仕組みづくり 会計や残高管理はドメインとして深く、エンジニア、経理、プロダクトマネージャー（以下、PdM）が、それぞれ異なる言葉で同じ取引を理解していることが課題でした。 同じ取引を見ても、PdMは「体験」、エンジニアは「API」、経理は「仕訳」という異なる関心で捉えています。そのため、認識をすり合わせるためのコミュニケーションコストが、組織的なボトルネックになっていました。 この壁を越えるために作られたのが、取引を1つの図として表現する「MoneyFlow」という共通言語と、それを作成・検証するための社内ツール「mfgen」です。 開発の初期段階でMoneyFlowを作成するプロセスを組み込むことで、デザインや仕様書を用意するのと同じタイミングで、お金の流れを可視化できるようになりました。また、AIも活用しながら、金額の整合性や仕様とのずれを自動検証できるようにしています。 さらに、同時編集・共同レビュー機能により、経理とエンジニアが同じ図を見ながら議論できる状態を作り出しました。これによって、エンジニアは経理ドメインへの理解を深め、経理側もAPIなどの技術用語に触れやすくなるという、双方向の歩み寄りが生まれているといいます。 最後に 今後の課題として、まだ単式で管理されている部分を複式へ移行することが挙げられました。加えて、現状は会計サービスと1つ上流のマイクロサービスの間でしか行われていないリコンサイル（突合）を、すべての接続点へ広げていく必要があります。 また、現在のアーキテクチャは、経理側にシステムへの一定の理解を求める設計になっています。そのため、経理業務の改善も継続的なテーマです。 この領域では、プロダクトエンジニアリング（PdE）的な働き方が今後ますます求められるといいます。決済と会計をつなぐ基盤づくりは、組織の壁を越えながら、現在も進化を続けています。 今回紹介した内容の詳細や、登壇者による質疑応答は、 ぜひ配信アーカイブ動画 でご覧ください。 また、Merpay Tech Talkでは、定期的にエンジニア向けのイベントを開催しています。イベントの開催案内を受け取りたい方は、ぜひconnpassグループのメンバーになってください。 メルカリconnpassグループページ 関連記事 決済プラットフォームと経理を繋ぐ MoneyFlow 関連求人 メルペイでは、決済基盤や会計システムの開発に一緒に取り組む仲間を募集しています。採用情報について、詳しくは以下のエントリーをご覧ください。 Product Engineer, Backend – Merpay Senior Product Engineer, Backend – Merpay

TiDB クラスタ統合の取り組み メルカリでは、CoreDB と呼ばれる中核データベースを、オンプレミス環境のMySQL から TiDB Cloud へと移行しました。MySQL から TiDB への移行に至った背景や移行全体の概要については、 メルカリのCoreDBをMySQLからTiDBへ移行した振り返り で詳しく紹介しています。 本エントリーでは、TiDB Cloud 移行後に実施した、TiDB クラスタの統合について、その背景や進め方、得られた知見について共有します。 クラスタ統合の背景 メルカリのCoreDBをMySQLからTiDBへ移行した振り返り でも説明されているように、CoreDB はサービスの成長に合わせて、垂直シャーディングを繰り返してきました。 柔軟性に乏しいオンプレミス環境では、データ量やトラフィックの増加に対応するため、シャーディングによってデータベースを分割し、十分なキャパシティを常に確保しておくことが重要でした。 一方で、シャーディングには以下のようなデメリットがあります。 開発の複雑性の増加 クラスタをまたいだトランザクションが行えない データ不整合の検出・解消をアプリケーション側で実装する必要がある、など 運用コストの増加 クラスタごとに監視や設定、メンテナンス作業が発生 障害対応時の確認対象の増加 小規模クラスタの最低維持コスト 最小構成でも余剰リソースが発生 TiDB Cloud へ移行したことで、書き込み性能を含めたスケーラビリティが向上し、シャーディングによるキャパシティ確保を行う必要性が低下しました。移行後の TiDB 環境ではクラスタ（シャード）を統合できる可能性が出てきました。 統合対象クラスタの選定 今回の環境では「テーブル間の依存関係により分割が難しい」「機能・サービスの廃止によって利用が減った」etc… というような背景でクラスタごとの規模には大きな差がありました。以下のようなイメージです。 小規模クラスタは、TiDB Cloud の最小構成でもリソースに余剰がありました。そのため、統合によるコスト削減が見込めました。一方、検討時点では、超大規模クラスタはまだ移行途中だったこと、初めての統合作業となることを考慮し、今回は3つの「小規模クラスタ」を１つの「中規模クラスタ」へ統合することにしました。 統合方法の検討 まず、２つのクラスタを１つのクラスタへ統合し、これを繰り返すことで、最終的に、３つの小規模クラスタを中規模クラスタへと統合することとしました。２つのクラスタを統合する方法は大きくわけて２つのアプローチが考えられました。それぞれの方式の大まかな作業の流れは以下になります。 方式１：新規統合クラスタ方式 ①新しいTiDB クラスタをつくり、そこに統合する２つのクラスタのデータをインポートします ②それぞれの統合元クラスタから、新規統合クラスタへとレプリケーションを設定し、データを同期するようにします ③それぞれのクラスタへ接続しているアプリケーションの接続先を順次切り替えます メリット データのインポート作業において、サービスへ影響を与えるリスクがほとんどない デメリット 統合作業中はクラスタ数が増えるため、コストが一時的に増加する 統合元と統合先の双方で、アプリケーションの接続先変更が必要 方式２：既存クラスタ追記方式 ①既存の統合先クラスタ（中規模クラスタ）へ、統合元のデータをインポートします ②統合元クラスタから、統合先クラスタへとレプリケーションを設定し、データを同期するようにします ③最後に統合元クラスタへ接続しているアプリケーションの接続先を切り替えます メリット 新規のクラスタが不要なため、コストの増加が抑えられる 統合元のアプリケーションのみ接続先を変更すれば良い デメリット 稼働中のクラスタへデータのインポートを行う必要がある。インポート作業において、サービスへ影響を与えないよう考慮が必要 私たちは、「方式２：既存クラスタ追記方式」を採用することにしました（このことが、後ほどトラブルを引き起こす要因の１つになります・・・）。中規模クラスタを利用しているサービスの停止は影響範囲は比較的大きく、ダウンタイムを伴うメンテナンスの調整に手間がかかることが主な選択理由です。 発生した課題 TiCDC によるインポート制限の回避 統合先クラスタでは、TiDB Change Data Capture (TiCDC) を利用して、他システムへリアルタイムデータ連携を行っていました。TiCDC 動作中の物理インポートはサポートされていません（物理インポートは TiKV に直接データを書き込み、TiCDC が利用する変更ログを生成しないため、インポートしたデータが連携先に反映されない。詳細は 公式ドキュメント を参照）。TiDB Cloud では TiCDC が設定してあると、インポートが使えないように制限されています。 PingCAP のサポートへ依頼し、この制限を解除してもらいました。 その上で、念のため、インポートが TiCDC に予期しない影響を与えないよう、 TiCDC の対象外のテンポラリのスキーマに対してインポートすることとしました。 エクスポートには dumpling （詳細は 公式ドキュメント を参照）を利用しました。dumpling はファイル名にスキーマ名を記載するフォーマットになっています。ファイル名を変更するだけでインポート先のスキーマ名を変更できました。 出力ファイル名 内容 {schema}.{table}-schema.sql CREATE TABLE 文（テーブル名にスキーマは付かない） {schema}.{table}.{連番}.csv データ本体 {schema}.{view}-schema-view.sql ビューの定義 インポート後に、ALTER TABLE で各テーブルを元のスキーマに移動します。 ALTER TABLE temporary.table_name RENAME TO original.table_name なお、データ連携先へは、統合元クラスタからデータが既に連携されているため、インポートで統合先クラスタへ追加したデータを改めて、連携しなおす必要はありませんでした。 AUTO_INCREMENT の重複エラー問題 接続を統合先クラスタに切り替えたところ、AUTO_INCREMENT を利用しているテーブルでプライマリキーの重複エラーが発生してしまいました。 調査の結果、原因はTiDB の バグ#64561 によるものでした（このバグは TiDB v8.5.5 で修正 されています）。このバグでは、テーブルを別のスキーマへ RENAME した際、AUTO_INCREMENT (Auto ID allocator) がRENAME 前の スキーマ (database ID) を参照し続けます。一方、TiDB ノードを追加したり、再起動したりすると、そのノードの Auto ID allocator はRENAME後のスキーマを参照します。結果、ノード間で異なるAuto ID allocator から重複したIDが払い出されてしまいました。 障害発生時は、手動で AUTO_INCREMENT の値 をリセットすることで復旧しました。 ALTER TABLE テーブル名 AUTO_INCREMENT = 最大値+1 その後の統合作業では、事前に以下を行うことで再発防止としました。 TiDB ノード をローリングリスタートし、AUTO_INCREMENT が正しくRENAME後のスキーマに紐づいた状態にする 全ての TiDB ノード で AUTO_INCREMENT の進み具合 が一致（SHOW CREATE TABLE の AUTO_INCREMENT の値に差分がないこと）していることを確認する インポートによる影響 「統合方法の検討」で説明したように、今回の手順では、稼働中のサービスに利用されているクラスタに対して、インポートを行います。そのため、インポートの負荷によってサービスに影響が出ないよう、対策をした上でインポートを行いました。具体的には以下の対応を行いました。 TiKV を事前に十分にスケールアップする インポート速度の調整 (import.num-threads を下げる) しかし、このような対策をしても、あるクラスタの統合作業時に、影響が出てしまいました。インポートによって多くのデータファイル（SSTファイル）が TiKV に作成された結果、コンパクション処理が遅延し、TiKVサーバが「Server is busy」エラー状態になってしまいました。 再発防止として TiKV へデータを取り込む速度を直接制限するパラメータを設定し、インポートを行うこととしました。 [tikv-importer] range-concurrency = 1 store-write-bwlimit = "20MiB" また、ANALYZE についても、インポート時には行わず、念の為、負荷の低い時間帯に手動で実行するように手順を見直しました。 [post-restore] analyze = "off" まとめ TiDB Cloud への移行によってスケーラビリティが向上したことで、従来はキャパシティ確保のために分割していたクラスタを統合できるようになりました。今回、3つの小規模クラスタを既存の中規模クラスタへ段階的に統合し、運用コストとインフラコストの削減を進めました。完全に１つに統合されたわけではありませんが、それでも、管理対象が減り、管理の手間が大きく減ったと実感しています。 今回は、コストとメンテナンス調整の負担を抑えるために「方式2：既存クラスタ追記方式」を選びました。しかし、その選択が、複雑なインポート手順やそれに起因する AUTO_INCREMENT の問題、さらには稼働中のクラスタへのインポートによる影響といった問題につながりました。今振り返ると、「方式1：新規統合クラスタ方式」にしておけば避けられた問題もあったかもしれません。ただ、方式1 には別のコストや切り替えの大変さがあります。どちらを選んでも悩ましいところがあり、こうした方式選びの難しさをあらためて感じました。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM（Engineering Manager）および IC（individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは以下をご覧ください。 EM: https://apply.workable.com/mercari/j/7AD4EF9218/ IC: https://apply.workable.com/mercari/j/ACD2689E9E/

TiDB Cloudのオートスケール改善 – 時間帯別制御、TiKVへの拡張、運用の自動化 本記事は、私たちメルカリのDBRE（Database Reliability Engineering）チームが今年4月に公開した TiDBのオートスケールに関する記事 の続編で、9月11日に開催された 第10回 TiDB User Group Meetup の 発表 のフォローアップとなります。 この記事では、TiDBの時間帯別オートスケール制御の改善、TiKVへのオートスケールの拡張、そして稼働状況の診断や日次レポートなどの運用の自動化について、メルカリのDBREチームの取り組みを紹介します。 TiDBのオートスケールの改善 前回の記事 では、メルカリではTiDB CloudのTiDBのオートスケールをカスタムコントローラーを利用し、CPU利用率などのメトリクスを元にノード数の増減数を決め、TiDB CloudのAPIにてオートスケールを実現していることを紹介しました。 オートスケールはk8s nativeのオートスケーラーを参考に、オートスケールで1回に増減可能なノード数、ノード数増減の間隔、また、スケールインとスケールアウトを繰り返してしまわないよう、意思決定を行うための安定化のウィンドウなどを実装していました。 最初に発生した課題は、「日中はスケールインを特に慎重に実施したい。一方で夜間のある一定の時刻をすぎると、トラフィックの減少傾向は顕著になる一方で、スケールイン速度が不十分」というもので、この対応として、次の章で説明するパラメータ群のタイムウィンドウに対するオーバーライドを定義する機能を実装しました。 タイムウィンドウによるパラメータオーバーライド 実際のカスタムリソース定義は下記のようなイメージで定義されます。この実装は非常に汎用性が高く、多くのシナリオで活躍しています。 nodeGroups: [ { name: "default" id: "<node id>" minReplicas: 3 maxReplicas: 99 targetCPUPercentage: 50 cpuCriticalPercentage: 80 hpaDdMetricsQuery: "avg:tidb_cloud.node_cpu_seconds_total{cluster_name:<cluster name>,project_name:\(_tidbCloudProjectName),component:tidb}.as_rate().rollup(sum, 120) / avg:tidb_cloud.node_cpu_capacity_cores{cluster_name:<cluster name>,project_name:\(_tidbCloudProjectName),component:tidb} * 100" maxSurge: 2 maxUnavailable: 1 cooldownOutSeconds: 420 cooldownInSeconds: 3600 stabilizationWindowSecondsScaleDown: 900 aggressiveScaleInPeriods: [ { daysOfWeek: ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"] startTime: "00:30" endTime: "02:30" timezone: "Asia/Tokyo" cooldownRatioPercent: 25 maxUnavailable: "20%" // スケールインの基準の上書き }, ] aggressiveScaleOutPeriods: [ { daysOfWeek: ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"] startTime: "13:00" endTime: "17:00" timezone: "Asia/Tokyo" targetCPUPercentage: 60 // 目標CPU利用率の上書き maxUnavailable: 0 }, { daysOfWeek: ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"] startTime: "17:00" endTime: "20:00" timezone: "Asia/Tokyo" maxUnavailable: 0 // スケールインの禁止 }, // ... ] }, ] この機能では、時間帯や曜日ごとにオートスケールの制御パラメータを上書きします。基本となるのは、あくまでも観測したメトリクスに基づくスケール判断です。そのうえで、日々のトラフィックやキャンペーンなど、あらかじめ分かっている負荷傾向に合わせて、スケールのしやすさを調整します。 例えば、日中と夜間では、スケールインに求める挙動が異なります。日中は負荷が再び増える可能性を考慮して慎重にノードを減らす一方、夜間の一定時刻以降は、顕著な負荷の減少に合わせて積極的にノードを減らしたいと考えました。そこで、夜間の対象時間帯ではクールダウンを短縮し、1回に削減できるノード数を増やすことで、不要になったリソースをより速く削減できるようにしました。 キャンペーンの開始時刻が分かっている場合には、負荷の増加に対応しやすい設定へ切り替えます。目標CPU利用率を下げる、クールダウンを短縮する、1回に追加できるノード数の上限を増やすといった調整により、観測した負荷の増加に対して、通常よりも積極的にスケールアウトできるようにします。 一方、負荷の変動が小さい時間帯では、細かな変動に反応してスケールインとスケールアウトを繰り返す必要はありません。こうした時間帯では、スケール判断の安定化ウィンドウを長くし、フラッピングを抑制します。また、安定性を優先したい特定の時間帯には、スケールインを禁止することもできます。 曜日による負荷傾向の違いにも、同じ仕組みで対応できます。メルカリでは、平日は12時ごろから負荷が増えやすい一方、休日には同じ時間帯の目立った変化が見られません。このような違いを踏まえ、曜日と時間帯を組み合わせて制御パラメータを調整することで、それぞれの負荷特性に合ったスケールの挙動を設定できます。 その他の実装の選択肢としては、例えば「1週間前や、1日前の負荷傾向を元にスケールさせる」という選択肢もありましたが、運用上の分かりやすさ（設定に対する挙動を予測しやすくする）を優先するというポリシーの元、時間別にパラメータをオーバーライドする実装となりました。 この実装の導入により例えば平均CPU利用率の目標が50%のクラスターに対して、平均CPU利用率44%、かつ、個々のCPU利用率が80%を超えることはない、といったような状態が達成されひとまずステートレスなTiDBに対しては、一定のリソース需要に応じて、必要なリソースを確保するという目標は概ね達成しました。 TiKVのオートスケールの実現 TiDBのオートスケールの改善に続き、私たちはデータを保持するTiKVにもオートスケールの対象を広げました。 前回の記事 では垂直スケールの導入を目指すと紹介しましたが、その後、キャンペーン時の観測結果を踏まえ、水平スケールを優先して導入しました。 ここからは、 第10回 TiDB User Group Meetupでの発表資料 をもとに、TiKVの水平スケールと垂直スケールの動作の違いを整理します。そのうえで、メルカリが水平スケールを選んだ背景と、オートスケールの実装にあたって考慮した点を説明します。 これらの判断を理解するには、スケール操作がクラスター全体に及ぼす制約を把握する必要があります。まずはTiDB Cloudの状態と操作の制約を確認し、その後、各スケール方式の特徴を見ていきます。なお、発表で紹介した個別の課題の詳細や、それに関連するTiDB内部の技術的な仕組みについては、別の記事で掘り下げる予定です。 前提：TiDB Cloudの制約 TiKVのスケール方式を検討するうえでは、スケール操作中にクラスター全体でどのような制約が生じるかを理解することが重要です。 発表資料でも紹介したとおり 、TiDB Cloudでは、クラスターの状態によって追加のスケール操作が制限されます。 スケールイン・スケールアウト・スケールアップ・スケールダウンなどの操作を開始すると、クラスターはmodifying（変更処理中）状態になります。再びavailable（追加の操作が可能な状態）に戻るまでは、別のスケール操作を実行できません。ここでいう「変更処理中」は、クラスターがサービスを提供できないことを意味するものではなく、追加の操作を受け付けない状態を指します。 この制約は、TiKVだけでなくTiDBのオートスケールにも影響します。例えば、TiKVのスケール操作によってmodifying状態が長く続くと、その間に負荷が増えてもTiDBをスケールアウトできません。そのため、各スケール方式でmodifying状態がどの程度続くかを把握することが、方式の選択や制御の設計において重要になります。 TiKVの水平スケールの動作 前述の前提の元、まずはTiKVのノード数を増減させる水平スケールについてどのような動作をするかを確認します。 水平スケールのスケールアウト（ノード追加）では、ノード追加時はデータがない空のノードを追加することになるため、ノード追加が完了するとクラスターはすぐにavailable状態になります。 TiDBでは、TiKV間でデータが均一に分布するように常に調整が行われており、空のノードを追加した後、実データの移動が行われます。実データの移動の単位はリージョンと呼ばれ、各ノードでリージョン数が均一になるよう、リージョンの移動が発生します。 一方で、負荷が均一になるよう、リーダー(leader)数も各ノードで均一になるようリーダー移動が発生します。リーダー移動は、実データの移動に比べると高速に終わりますので、最初はリーダーが移動しているように見えます。 一方、TiDBは標準では3つのデータコピーを持ちますので、リージョン数の均衡には、リーダー数の均衡にかかる約3倍の時間がかかります。また、標準ではデータの読取りはリーダー(leader)ノードに対して実施されますので、読み取り負荷の分散はリージョンの均衡の3分の1の時間で終わることが期待できます。 一方、水平スケールのスケールイン（ノード削除）では、最終目標はノードを削除することでありますが、事前に、削除するノードのすべてのデータを他のノードに退避完了させる必要があります。データの物理移動は時間がかかり、ノード削除するまでmodifyingが継続するため、一般的には長い時間modifyingが継続します。 TiKVの垂直スケールの動作 続いては垂直スケール（スケールアップ/スケールダウン）について説明します。 TiKVの水平スケールが実データの移動を伴っていたのに対し、垂直スケールでは実データの移動を伴わず、リーダーを一時的に他のノードに退避して、インスタンスクラス（CPU/Memoryサイズなど）の変更を行います。1ノードあたりのスケール時間は数分程度になることが期待できます。 一方で、既存ノードの負荷はリーダーの退避により一時的に増えるリスクがあります。TiDB Cloudでは、これに加えTiKVをスケールする際に、PDのスケールが必要になることがあることを考慮する必要があります。 TiKVの水平スケールと垂直スケールの選び方 水平スケール/垂直スケールは論理的にはどちらかを選ばなければならないものではありませんが、TiDB Cloudのスケール操作が現状tidb-operator v1ベースであることを踏まえると、現時点ではどちらかのみを有効にすることが強く推奨されます。この理由については別の記事で別途説明しますが、どちらか一方を選択するという前提で、どのようなケースでどちらを選ぶべきかについて、私たちの見解を述べます。 両者を比較する要素としては次のスライド記載の要素が主なものではないかと考えます。 最も重要なものの1つは、スケールにかかる時間です。これはクラスターの環境に大きく依存します。 垂直スケールは、TiKVは1台ずつスケールが行われるのでノード数が増えるとそれなりの時間がかかります(modifyingの時間が長くなります)。一方実データ移動がない利点があります。 水平スケールは、スケールアウトのノード追加は複数台まとめて実施され、modifyingの時間は短いです。一方スケールイン時は実データの退避が必要で、一般には時間がかかりますが、ノード数がCPUリソースを確保するために多くなっているケースでは、垂直スケールに比べて高速にスケール操作ができる場合があります。 つまり、垂直スケールはスケール速度が、台数に依存しデータ量に依存しないため、データ量が多く、ノード数が少ない場合に有利。水平スケールはスケール速度がデータ量に依存し、かつデータの移動先が多いほど高速にスケールできる可能性があるため、データ量が少なく、ノード数が多い場合に有利。 スケールの粒度は垂直スケールは一般的には2倍、4倍といった粒度でしか変更できないため、コントロールの粒度が粗くなります。オートスケールでは細かい粒度でスケールできた方が基本的には様々なケースで有利となるでしょう。 また、水平スケール、垂直スケールどちらも一時的な性能低下のリスクはあるものの、垂直スケールでは、コントロールの難しい性能低下の可能性がある点を考慮する必要があります。 ここまで、TiKVのスケールイン・アウト/スケールアップ・ダウンが どのように動作するか どちらかしか利用できない場合どのような場合にどちらが向いているか についてのメルカリのDBREチームの考えを述べました。 次に、メルカリでTiKVの水平スケールを優先した判断の背景と、オートスケールの実装にあたって考慮した点を紹介します。 メルカリで水平スケールを優先した理由 コスト削減効果が最もあるクラスターでは、水平スケールに適している「台数が多い」状況でした。ここで気になるのはスケールを行った際にどの程度の性能影響が発生するのか、実際にどの程度の時間でスケールが完了するのか、といった点です。 大規模キャンペーン時にTiKVオートスケールが実装されていない状態で、GUIからスケールアウト(水平スケール)操作を実施した際の観測結果から、スケール中の性能影響が想定より少なく、かつスケール所要時間が想定より短かったため、水平スケールを優先することにしました。 当初は実データ移動があるため、スケールに時間がかかるだろう、とスケール所要時間を実測せずに垂直スケールを優先しようとしており、垂直スケールも実装が終わり、導入しようとしていたところでしたが、急遽水平スケールを優先することにしました。 TiKVのオートスケール実装における考慮事項 本章は今後同様の取り組みをされる方に向けて、メルカリでどのような考慮を実装として組み込んだかについて説明します。 基本はTiDBのオートスケールに近い実装を行いタイムウィンドウにおけるオーバーライドも合わせて実装しました。TiKVのオートスケール実装時の固有/追加の考慮事項は下記でした。 2段階スケール TiDBのスケール操作は、通常、長期間modifyingになるということはありません。一方でTiKVのスケールは長期間modifyingになることがある前提で実装をする必要があります。 TiDB Cloudの制約上、modifyingになっているときには(TiDBの)追加のスケール操作ができなくなるため、例えばmodifyingが長い時間継続し、かつその間に(TiDBの)負荷の増加が予想される際は、事前にTiDBのノード数を増やしておく必要があります。 また、TiKVスケール時に常にTiDBノード数を事前に増やせば良いわけではなく、本当に必要な時だけ無駄なくTiDBノードを増やす必要があり、多少の工夫が必要です。例えば、負荷減少傾向の際にTiKVノードを減らす操作が発生します。TiKVノードを減らす操作は長時間modifyingが継続する、というケースに該当しますが、このときにTiDBノードのリソース需要が減少傾向であれば、TiDBノード数を増やさない方が良い、ということになります。 TiDBとTiKVのスケールの優先順位 TiDB/TiKVのスケールは独立には実施できず、かつステータスの制約をうけるので、どのタイミングで何を判断するか、どのように優先するかの考慮が必要です。 メルカリでは最初のステップとして、TiDB/TiKVのうち、固定でTiKVのスケールを優先するように実装し、利用を開始しました。 その後、次のステップとして、スケールインの際にはTiDB/TiKVそれぞれの各時刻の目標値(desiredReplica)を計算し、どちらを減らすと合計CPU数をより多く減らせるかを評価するようにしました。コスト削減効果に近い指標として合計CPU数の削減量を用い、効果がある方を減らす、という優先順位を実装しています。 その他の改善 ここまでは、TiKVのオートスケールについての基本的な動作と実装時の考慮事項などについて確認してきました。 この章では、運用に関する改善事項の取り組みを2つ紹介します。 オートスケール状況の診断とSlack連携 問題の予兆を検知した際に適切に動いているか、どうなるかを答える CPU利用率が想定以上に利用されアラートが発生した際に、現在オートスケールは発動しているのか、どういう判断をしようとしているのかを理解する オートスケール自体の自己改善の余地を探す 前日のオートスケールが、適正に動いていたかを評価する こういった判断を属人化せず実施可能なように、下記のようなデータを参照し、オートスケールの動作を評価できるようにしました。 オートスケールのコントローラーのログ 最新のCRD(Custom Resource Definition) 各種メトリック 現在のノード数、望ましいノード数 CPU利用率 スケールの変更の所要時間 … 現在は、1日1回、オートスケールの動作状況のレポートがslackに自動投稿されるほか、slack botに特定のキーワードを与えるとオートスケールの稼働状況を確認することができるようになっています。 オートスケールの動作状況のレポートの出力としては、 制御目標に対するCriticalアラートの発生はあったか リソースの利用率が適正なレンジにおさまっているか おさまっていない場合は何をどのように変更すると良いか といったことが評価されます。 目標リソース利用率の見直しの自動化 「 TiDB Cloudにおけるオートスケールの実現 」の記事では、オートスケールの制御目標値と、アラート閾値の間に猶予を設け運用をしていく、そして制御目標値の実態に応じて目標値を引き上げていく、ということを述べました。 オートスケール目標値と閾値設定の運用例 これに対して、次の1手を事前に考慮し、次の1手の打ち手を速くできるよう事前に準備をする、ということを心がけ、自動化を行なっています。 例えば、上図のようにCPU制御目標値を50%を超えない範囲で最小のリソースで運用する、という目標だったとしましょう。 オートスケールの実装や、運用上の設定値、そして様々な外的要因で、制御目標値に対する実態が日々変化します。例えば、運用開始の初日は、目標値を20%上回る時間帯が1日のうち10分発生するかもしれません。しかし、日々の改善により、次第にこれが洗練され、目標を上ぶれる要因が洗い出され、上振れの頻度、幅、共に減っていくはずです。こういった際に、今度は、制御目標値を上方修正する余地が発生するはずです。 これに対して現状大雑把には、① オートスケールが成功裡に運用できたかを日々判断し、② これが一定期間継続したら見直しを行えるようにする、という運用をしています。エラーバジェットを監視し、余裕があれば積極的な運用を促す、といった具合です。 オートスケールの制御目標の見直し基準の評価 まとめ 本記事では、メルカリのDBREチームが取り組んだTiDBオートスケールの改善と、TiKV水平オートスケールの導入について紹介しました。TiDBでは、時間帯や曜日に応じて制御パラメータを上書きすることで、日中の慎重なスケールインと、夜間の負荷減少に合わせた積極的なスケールインを両立しました。観測したメトリクスを基本としながら、既知の負荷傾向に合わせて制御を調整することで、必要なリソースを確保しつつ、リソース利用の効率化を進めています。 TiKVでは、当初予定していた垂直スケールよりも、水平スケールを優先して導入しました。この判断の根拠となったのは、対象クラスターのノード数が多く水平スケールに適していたことと、キャンペーン時の実測で、スケールアウトによる性能影響や所要時間が想定より小さいと確認できたことです。また、TiDB Cloudのスケール操作中は追加の操作ができないという制約を踏まえ、必要に応じてTiDBを事前にスケールアウトする2段階スケールや、リソース削減効果に応じたスケールインの優先順位を実装しました。スケール方式の選択には、仕組みの理解に加え、実際のワークロードでの観測が重要だと実感しています。 オートスケールは、導入して終わりではありません。私たちは、ログやメトリクスに基づく稼働状況の診断と日次レポートの自動化を進め、制御の妥当性や改善の余地を継続的に評価しています。今後も、安定した運用実績を確認しながら目標リソース利用率や制御パラメータを見直し、信頼性とリソース効率の両立を目指します。 TiKV水平スケールを思い通りにコントロールするためにはどのパラメータをどのように調整すれば良いか、また水平スケール導入で取り組んだ個別の課題や、それに関わるTiDBの技術的な詳細について、別の記事で紹介する予定です。 お知らせ 最後に、現在メルカリでは、この記事の発行者の所属する DBREチーム の EM(Engineering Manager) および、IC(Individual Contributor)を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは EM https://apply.workable.com/mercari/j/7AD4EF9218/ IC https://apply.workable.com/mercari/j/ACD2689E9E/ をご覧ください。

こんにちは！　Mercari Adsチームのインターン生の @uta です。 本記事では、フロントエンドを中心に経験してきた私が、AIを活用しながらバックエンドを含む機能開発に挑戦した3ヶ月間を振り返ります。インターン中に取り組んだ機能開発を通じて、複数のサービスにまたがる開発の難しさや、AIを活用するなかで得た学びを紹介します。 はじめに 私は2026年7月から9月末までの3ヶ月間、フロントエンドエンジニアとしてメルカリのインターンに参加しました。以前にもメルペイでインターンを経験しましたが、その後、AIの普及によって開発の進め方や日々の業務は大きく変化しました。そうした変化のなかで、メルカリの開発がどのように進められているのかを改めて知りたいと考え、今回の参加を決めました。 これまでの開発経験は主にフロントエンドでしたが、今回はバックエンドを含む機能開発に本格的に取り組みました。以前から、技術領域にとらわれずサービスに必要な開発へ取り組めるようになりたいと考えていたことに加え、AIによって未経験の技術やコードベースを理解するハードルが下がった今なら、経験の少ない領域にも挑戦できるのではないかと考えたためです。 この記事では、主に次の内容を紹介します。 商品グループへの価格条件追加 課題と実装方針 難しかった点 そのほかに取り組んだこと インターンを振り返って AIと取り組んだバックエンド開発 経験して初めて分かったこと 挑戦を支えてくれたチーム この記事が、メルカリのインターンに挑戦しようと考えている方や、AIを活用した未経験領域への挑戦に関心がある方の参考になれば幸いです！ 商品グループへの価格条件追加 私が所属したAds Operationチームでは、広告主が広告の設定や運用を行うためのAds Managerを開発しています。Ads Managerでは、広告グループ作成、クリエイティブ入稿、商品情報をまとめたデータフィードの登録、配信状況や成果の確認、レポート作成など、広告運用に必要な作業を行えます。 今回のインターンでは、その中でも商品グループに価格条件を追加する機能をメインタスクとして担当しました（図1.1）。 図1.1 商品グループの価格条件設定画面 課題 Ads Managerには、商品名や価格などの商品情報をまとめた「データフィード」を登録する機能があります。商品グループは、そのデータフィード内の商品を条件に応じてまとめ、広告として配信する商品を決めるための仕組みです。 これまでは、広告主が商品に付けたカスタムラベルで商品を絞り込めましたが、価格帯では絞り込めませんでした。そこで今回、価格の下限と上限を指定し、その範囲に含まれる商品からグループを作成できるようにしました。一見すると画面に価格の入力欄を追加するだけの機能に見えますが、入力された条件を保存し、対象となる商品を判定して広告へ反映するまでの仕組み全体を変更する必要がありました。 実装方針 実装範囲は、フロントエンド、データベースのスキーマとマイグレーション、GraphQL API、広告を生成するworker、広告を更新するloaderにまたがりました。画面で入力された価格条件は、GraphQL APIを通じてデータベースへ保存されます。広告グループを作成すると、workerが保存された条件を評価して広告を生成します。その後、データフィードによって商品の情報が更新された場合は、loaderが条件を再評価して広告へ反映します（図1.2）。 図1.2 価格条件が保存され、広告へ反映されるまでの流れ データベースは、既存のカスタムラベル条件を保存する構造を拡張し、条件の種類と価格の下限・上限を保存できるようにしました。価格条件ではカスタムラベルの値を使わないため、既存カラムについて、NULLを許容する定義へ変更しました。また、workerやloaderを含む各サービスでは、条件の種類に応じて商品が商品グループに属するかを判定できるよう、ロジックを変更しました。 難しかった点 難しかったのは、価格を比較するロジックそのものよりも、既存の仕組みをどのように拡張し、複数のサービスへ安全に反映するかを考えることでした。 実装の影響範囲を確認するなかで、ログや監視、パフォーマンス、既存の挙動を含めた動作確認の範囲など、実装時に考慮すべき観点が次々に見つかりました。データ分析用途のBigQueryへのデータ同期のように、追加で必要になる作業もありました。当初は、自分がまだ認識できていない観点や作業まで想像できず、必要な工数を十分に見積もれていませんでした。実装を進めるなかで想定外の作業が次々に見つかり、当初の見積もりが甘かったことを実感しました。リリースとロールバックの設計も、その一つです。 価格条件では、カスタムラベル条件で必須だった値がNULLになります。そのため、価格条件のデータが作成された後にworkerやloaderを以前のバージョンへロールバックすると、値が必ず存在することを前提とした処理でエラーが発生する可能性がありました。そこで、まずNULLを読み取っても処理が失敗しないよう防御的な変更を加えたworkerとloaderを先行して公開し、その後に価格条件へ対応した機能を公開する手順を検討しました。実際に利用されているサービスへ機能を追加する際は、公開までの手順だけでなく、問題が起きた場合のロールバックまで考えて準備する必要があると学びました。 実装やリリースの準備を進めるなかで、最初のデータベース設計が後段の処理に与える影響に気づきました。既存カラムをNULL許容にしたことで、値が必ず存在することを前提にしていた複数のサービスにとっては、その前提を崩す実質的に破壊的な変更になりました。バックエンドやデータベース設計の経験が少なかった私は、設計時点では既存の処理を再利用できることに注目し、後段の処理や動作確認、リリース、ロールバックへの影響まで見通せていませんでした。今振り返ると、既存構造を全面的に作り直さなくても、価格の値だけを専用テーブルへ分ける選択肢を、より慎重に検討すべきだったと思います。この経験から、データベース設計ではコード上の変更量だけでなく、既存データや各サービスが持つ前提、動作確認、デプロイ、ロールバックまで含めて影響を考える必要があると学びました。 そのほかに取り組んだこと 価格条件の追加を進める一方で、インターン期間中には、Ads Managerの利便性や開発環境を改善するタスクにも取り組みました。 広告主による計測タグの導入の手間を減らすため、Ads Managerに「計測タグ」タブを追加しました。これまではガイドを確認しながらパラメータやアカウントIDを設定する必要があり、設定ミスが問い合わせにつながることもありました。今回の対応では、ログイン中のアカウントIDを反映した導入用スクリプトと、商品詳細の表示・カートへの追加・購入といったイベントごとのコードを画面上に表示し、そのままコピー＆ペーストできるようにしました（図2.1）。 実装自体は短期間でしたが、リリース後にはSales teamへの共有、広告主への案内メールの配信、管理画面マニュアルの更新まで進みました。画面の実装だけでなく、複数のチームを通じて広告主へ機能を届けるまでの流れを見ることができました。 図2.1 Ads Managerに追加した計測タグ画面 社内の管理ツールからAds Managerへ移動するリンクを追加した際には、Ads Managerへアクセスできない場合に表示する専用画面がないことに気づき、別のチケットとしてアクセス拒否画面も追加しました。また、リリースノートの作成を支援するツールで著者情報が正しく表示されないケースを見つけ、原因を調査して修正しました。 Ads Managerのテーブル画面では、自動ルール一覧への作成日時の追加、クリエイティブ一覧への入稿日時の追加、横スクロールバーの追従表示など、広告運用時の操作性を高める改善に取り組みました。また、画面遷移や再読み込み後もテーブル画面のソート設定を維持できるよう、設定をsessionStorageへ保存し、画面へ戻ったときに復元する対応も行いました。 そのほか、インターン期間中にSales teamからProduct Managerを通じて届いた要望をもとに、テーブルのカラムに、その指標の意味を補足するツールチップを追加しました。実際の利用者に近いところから上がった要望が、Product Managerによって仕様に整理され、すぐに開発タスクとなって画面へ反映されるまでの一連の流れを経験できたことが印象に残っています。 メインタスクから日々の改善まで、規模や領域の異なる開発を経験できました。ここからは、それらの経験を通じて得た学びを振り返ります。 インターンを振り返って AIと取り組んだバックエンド開発 今回は、既存コードの調査から実装計画の作成、コードの実装、テストケースの検討まで、開発のさまざまな場面でAIを活用しました。これにより、経験の少なかったバックエンド領域を含む機能開発も進めやすくなりました。 また、複数のサービスの役割を調べるなかで、ORMやデータベースマイグレーション、GraphQL、Pub/Sub、ポーリングなど、分からない概念や処理はその都度AIを使って確認しました。説明を実際のコードと結びつけることで、実装を進めながらバックエンドへの理解も深められました。 今回のように経験の少ないバックエンド領域へ取り組むことは、AIがなければ私には難しかったと思います。AIが実装の大部分を担い、分からない概念や処理の理解にも役立ったことで、経験の少ない技術領域へ踏み出すハードルは大きく下がったと感じました。 経験して初めて分かったこと 一方で、AIを使って実装を進められることと、その変更が十分かを自分で判断できることは別でした。実際の開発では一般的な技術知識だけでなく、既存の設計や過去の経緯、チームで共有されている前提を踏まえた判断も必要でした。価格条件の追加でも、ログ、監視、データ同期、パフォーマンス、リリースなど、チームメンバーとの会話を通じて初めて気づいた観点が多くありました。 振り返ってみると、AIを使って自分で調査を続けられるからこそ、ある程度理解を整理してから相談しようとして、相談のタイミングが遅くなることもありました。この経験から、AIで理解を深めることと、チームメンバーに方向性を確認することは、どちらか一方を選ぶものではなく、状況に応じてバランスよく組み合わせることが大切だと学びました。時間のかかる作業に入る前に方向性を確認したり、調査する時間をあらかじめ決めたりすることも、今後は意識したいです。 今回、バックエンドを含む機能開発に取り組み、実装だけでなく、影響範囲の確認やリリースまでを考える一連の流れを経験できました。この経験を通じて、次にバックエンド開発へ取り組む際は、必要な作業や確認事項を以前より早い段階で想像し、より見通しを持って進められると思います。技術的な判断の基準は、このような経験を重ねるなかで身につくものだと感じました。これからもAIを活用しながら、実装やレビュー、チームとの対話を一つずつ経験として積み重ね、少しずつ自分で判断できる範囲を広げていきたいです。 挑戦を支えてくれたチーム 今回、経験の少ない領域に挑戦できたのは、分からないことを相談したときに、丁寧に支えていただける環境があったからです。相談への回答だけでなく、同じ問題で次に困る人が出ないよう、仕組みそのものも改善してくださいました。 CIでE2Eテストが失敗した際、レポートの見方が分からず相談したところ、確認方法のドキュメントを作成していただいたうえ、失敗時のレポートを自動で公開し、Pull Requestから確認できるようCI自体も改善してくださいました。また、Datadogを使った調査がうまくいかず相談した際には、個人が持っていた知識を整理し、AIが参照できる手順書（Skill）として共有できる形に整えていただきました。 特に印象に残ったのは、困りごとを曖昧なままにせず、すぐに向き合い、個人の経験で終わらせずにチーム全体が使える改善へつなげてくださったことです。そうした姿勢から、Be a Pro、Move Fast、All for Oneが日々の開発に根づいていることを実感しました。私自身が経験の少ないバックエンド領域に挑戦できたことはもちろん、メルカリがGo Boldを実践し続けられる背景にも、互いの挑戦を支える文化があるのだと感じました。 おわりに 本記事では、Mercari Adsチームでのインターンで取り組んだ、商品グループへの価格条件追加やAds Managerの改善、そこから得た学びを紹介しました。フロントエンドを中心に経験してきた私にとって、複数のサービスにまたがるバックエンド開発へ挑戦し、実装だけでなく設計、監視、リリースまで考えた経験は、大きな学びになりました。 このような経験ができたのは、メンターの@dwjさんをはじめ、設計や実装のレビューだけでなく、日々の疑問に向き合い、学びやすい仕組みまで整えてくださったチームのみなさんのおかげです。経験の少ない領域への挑戦を支えてくださったことに、この場を借りて改めて感謝します。ありがとうございました！ 現在、メルカリでは複数のインターンを募集しています。この記事を通じて、メルカリでのインターンに少しでも興味を持っていただけたらうれしいです。気になる方は、以下の募集要項もチェックしてみてください！ Class of 2028, 28卒対象 / Software Engineer Internship Class of 2028, 28卒対象 / Security Engineer Internship Build Internship Plus, Software Engineer (Internship)

2026年8月12日に、「Merpay Tech Talk 〜3年で50ヵ国へ。メルカリ決済基盤アーキテクチャ刷新の舞台裏〜」をオンラインで開催しました。 この記事はイベントレポートです。配信当日の内容を簡単に紹介します。詳しくは、YouTubeで公開している配信アーカイブ動画をご視聴ください。 イベント概要 メルカリは、日本に出品された商品を海外のお客さまが購入できる「メルカリグローバルアプリ」を提供しています。2025年に台湾でサービスを開始し、2026年春には米国でも展開しました。今後は 3年以内に50ヵ国以上へ拡大することを目指しています 。 サービスを多くの国へ展開するには、多通貨への対応だけでなく、国ごとに異なる決済手段や決済事業者との接続、言語や商習慣に合わせた決済画面、会計システムとの連携など、幅広い課題を解決する必要があります。 今回のイベントでは、グローバル展開を決済面から支えるPaymentチームのエンジニアが登壇し、決済画面と決済基盤のアーキテクチャをどのように刷新したのか、開発を通じて得られた成果や新たな課題とともに紹介しました。 登壇者 今回の登壇者は、Paymentチームでバックエンド開発に携わる以下の3名です。 tanaka0325 / 株式会社メルペイ Backend Engineer ryuyama / 株式会社メルペイ Backend Engineer tomo / 株式会社メルペイ Backend Engineer 3年で50ヵ国へ向けたPaymentチームの取り組み メルカリグローバルアプリの拡大に向けてPaymentチームのミッションには、多通貨や各国の決済手段への対応、決済画面のカスタマイズ、決済事業者との接続、会計システムとの連携などがあります。 今回のセッションでは、そのなかでも「決済画面」と「決済基盤」という2つの領域に焦点を当てました。新しい国や決済手段への展開を速めながら、プロダクトごとの柔軟性と、決済プラットフォームとしての一貫性・安全性をどのように両立したのかを説明しました。 決済画面を共通化するCheckout Solution 決済画面では、Paymentチームが提供する共通基盤「Checkout Solution」を活用しています。Checkout Solutionは、メルカリのさまざまなサービスが同じ仕組みの上で決済画面を提供できるようにするもので、2024年から国内向けに稼働しています。グローバルアプリでも、この仕組みを土台にしました。 以前は、新しいサービスを立ち上げるたびに各プロダクトチームが決済画面をゼロから実装していました。特に、3Dセキュアのような複雑な非同期フローをプロダクトごとに実装する必要があり、開発コストが大きくなるという課題がありました。 Checkout Solutionの考え方は、決済画面を「どのサービスでも同じ部分」と「サービスごとに違う部分」に分けることです。例えば、支払い方法を選ぶ欄や、購入ボタンを押したあとに支払いを確定する処理は、どのサービスでもほぼ同じです。一方で、配送方法の選択やクーポンの適用は、商品を発送するサービスと配送が不要なサービスとでは大きく異なります。 Checkout Solutionでは、前者を「Core Elements」、後者を「Flex Elements」と呼び、開発する担当も分けています。Core ElementsはPaymentチームが一度つくりすべてのサービスで共通利用し、複雑な決済処理をここに集約しています。Flex Elementsは各プロダクトチームが、自分たちのサービスに必要な要素だけを実装します。 この分け方により、新しいサービスの決済画面をつくるときは、プロダクトチームはFlex Elementsのデザインと設定を追加するだけで済み、内部の決済処理に手を入れる必要がありません。逆に、新しい決済手段を追加するときは、PaymentチームがCore Elementsを一度更新すれば、すべてのサービスの決済画面に反映されます。 グローバル展開に向けた決済基盤の刷新 決済基盤では、外部の決済事業者との接続と、残高・売上・会計イベントの管理方法を見直しました。 1つ目は、外部の決済事業者とのつなぎ方です。クレジットカード会社や各国の決済サービスなど、実際にお金を動かす事業者はPayment Service Provider（PSP）と呼ばれ、決済手段や国ごとに接続の仕方が異なります。 従来の決済サービスは日本国内向けに発展してきたため、こうしたPSPごとの接続ロジックが決済の中核サービスである Payment Service に直接組み込まれていました。その結果、新しい決済手段や通貨を1つ追加するだけでPayment Serviceに手を入れる必要があり、展開する国が増えるほど開発が難しくなる構造になっていました。 そこで、PSPとのやり取りだけを担当する「Payment Provider Service」に切り出しました。PSPごとの違いはすべてこのサービスのなかで吸収し、Payment Serviceは「どのPSPを使っているか」を意識せずに、注文から支払い完了までの流れを管理することに集中できるようにしています。 この分離によって、新しい国や決済手段を追加するときの変更範囲を、Payment Provider Serviceのなかに限定できるようになりました。 2つ目は、残高・売上・会計記録の管理方法です。決済が1件成立すると、お客さまの残高の増減、事業としての売上、そして会計上の記録という3種類の記録が発生します。従来はこれらを別々のサービスが管理し、その整合性を決済サービスが調整していたため、仕組みが複雑になり、記録どうしのずれを防ぐことが難しくなっていました。 新しい「Balance V2 + Bookkeeper」では、会計で使われる複式簿記の考え方を取り入れています。「今いくら残っているか」という残高と、「なぜ残高が変わったのか」という理由を必ずセットにし、1つのトランザクションとして同時に記録します。片方だけが記録される状態を許さないことで、決済と会計のずれを構造的に防いでいます。 刷新後の決済基盤は、グローバルアプリ向けにリリースし、クレジットカード、Apple Pay、Google Payをサポートしています。Apple PayとGoogle Payを追加した際は、上で紹介した仕組みにより、バックエンドの開発から品質保証までを約1カ月で完了できました。 最後に 3年で50ヵ国という目標に向けて、Paymentチームは決済画面と決済基盤の両面から、グローバル展開を支えるプラットフォームづくりを続けています。 今回紹介した内容の詳細や、登壇者による質疑応答は、ぜひ 配信アーカイブ動画 でご覧ください。 また、Merpay Tech Talkは、定期的にエンジニア向けのイベントを開催しています。イベント開催案内を受け取りたい方は、connpassグループのメンバーになってくださいね！ メルカリconnpassグループページ 関連記事 Checkout Solutionの詳細（決済画面基盤の設計） Building a Flexible Checkout Solution: Frontend Architecture for Multi-Service Integration メルカリのグローバル展開を支えるPayment Platformの進化 グローバル展開にむけたアプリと基盤の再構築 関連求人 Merpayでは、グローバル展開を支える決済画面・決済基盤の開発に一緒に取り組む仲間を募集しています。採用情報について、詳しくは以下のエントリーをご覧ください。 Software Engineer, Backend – Merpay Product Engineer, Backend – Merpay Senior Software Engineer, Backend – Merpay Senior Product Engineer, Backend – Merpay

本記事は、私たちDBRE（Database Reliability Engineering）チームが2026年3月末までに行った改善を紹介する3つの記事の3つ目（最終回）です。 1つ目の記事「 メルカリにおけるTiDB改善の取り組み：IN句内100万件クエリへの対応 」では、IN句に多数の要素を含むクエリがTiDBクラスタ全体のレイテンシを悪化させた事例を紹介しました。2つ目の記事「 メルカリにおけるTiDB改善の取り組み：リソース制御・リージョンサイズ・プランキャッシュ編 」では、リソースグループの不具合対応、リージョンサイズの調整、プランキャッシュの検討、In Memory Engineの導入という、パラメータや機能面の改善を紹介しました。 最終回となる本記事の中心は、TiDBとMySQLにおけるインデックス挙動の非互換への対応です。クラスタ化された複合主キーや非整数主キーを持つテーブルにおいて、主キーのORDER BYがインデックス順として認識されないという挙動の違いと、インデックス追加による対処を、実行計画を交えて詳しく解説します。 あわせて、移行と並行して実施したより一般的な改善として、N+1問題の改善とヒント句による実行計画の制御にもふれます。これらはTiDBに限らずデータベース一般に見られるごく一般的な問題ですが、分散データベースへの移行を境に顕在化しやすいテーマです。MySQLからTiDBへの移行を検討している方の参考になれば幸いです。 インデックス非互換への対応（インデックス追加） まず、本記事の中心であるインデックス非互換への対応を紹介します。対処自体はインデックス追加というよくある手段ですが、その背景にはTiDBの実行計画に関する固有の挙動がありました。 TiDB移行にあたり、特定のクエリではTiDBとMySQLで同一のインデックスに対する挙動の違いを確認したため、追加のインデックスを作成する必要がありました。 条件: クラスタ化された複合キーまたは非整数の主キー（common handle）を持つテーブルで、非ユニークなセカンダリインデックスを使ったとき 発生事象: 主キーカラムのORDER BYがインデックスの順として認識されずTopNになる 必要な対応: 主キー順のソートが必要な場合、インデックスの末尾に主キーを含める 本件は直感に反する挙動であったため、コントリビュートして修正しようと調査していたところ、すでに最新のmasterでは改修されていました（ pingcap/tidb#66645 ）。なお、8.5系への取り込み（ pingcap/tidb#67107 ）は本記事執筆時点ではまだマージされておらず、LTS（Long-Term Support）の最新バージョンであるv8.5.7には含まれていません。 本事象の再現例は下記のissueにまとめられています。 https://github.com/pingcap/tidb/issues/66644 この挙動が実行計画にどう現れるかを、上記issueに記載されている再現例を用いて補足します。主キーの型だけが異なる2つのテーブルを比較すると差がはっきりします。 CREATE TABLE t1 ( a int, b int, c int, PRIMARY KEY (a), -- int 1カラム → int handle KEY ic (c) ); -- こちらのケースで非互換になる CREATE TABLE t2 ( a1 varchar(64), a2 int, b int, c int, PRIMARY KEY (a1, a2), -- 複合キー → common handle KEY ic (c) ); SELECT * FROM t1 WHERE c = 0 ORDER BY a LIMIT 100; SELECT * FROM t2 USE INDEX (ic) WHERE c = 0 ORDER BY a1, a2 LIMIT 100; ここで出てくるcommon handleについて簡単に補足します。TiDBは行のIDとしてhandleと呼ばれる値を持ち、テーブルの実データはこのhandleをキーとして格納されます。主キーが単一のint型カラムであれば、その値がそのまま64bit整数のhandleとなり、これをint handleと呼びます。一方、複合主キーや文字列の主キーでは、主キーの全カラムをエンコードしたバイト列がhandleとなり、こちらをcommon handleと呼びます。どちらの場合もセカンダリインデックスのエントリに主キーカラムが含まれる点は共通で、InnoDBのクラスタ化インデックスに相当する仕組みです。なおこの使い分けは主キーがクラスタ化されている場合の話で、TiDBの既定ではクラスタ化されます。 https://docs.pingcap.com/tidb/stable/clustered-indexes/ やりたいことはどちらも「 c = 0 の行を主キー順に並べて先頭100行」です。インデックス ic の物理的な並びはどちらのテーブルでも（ c , 主キーカラム）なので、 c = 0 に絞ればその中は主キー順に並んでいます。つまり本来はどちらも「インデックスを順に読んで100行で止める」だけで済みます。 int主キー（int handle）の t1 では、実際にその計画が選ばれます。 IndexLookUp_37 estRows=100 root limit embedded(offset:0, count:100) ├─Limit_36(Build) estRows=100 cop[tikv] offset:0, count:100 │ └─IndexRangeScan_34 estRows=100 cop[tikv] index:ic(c) range:[0,0], keep order:true └─TableRowIDScan_35(Probe) estRows=100 cop[tikv] keep order:false IndexRangeScan の keep order:true は、この演算子が出力順を保証することを示します。インデックスの物理順（ c , a ）がそのまま ORDER BY a を満たすため、後段でソートする必要がありません。coprocessor側の Limit が100件で読み取りを打ち切り、それが IndexLookUp に limit embedded として埋め込まれるので、インデックススキャン自体が100件で停止します。テーブル本体を引く TableRowIDScan も、その100行に対してだけ実行されます。ソート演算子は1つも現れません。 一方、int以外の主キー（common handle）の t2 では改修前は次の計画になります。 TopN_10 estRows=100 root t2.a1, t2.a2, offset:0, count:100 └─IndexLookUp_19 estRows=100 root ├─TopN_18(Build) estRows=100 cop[tikv] t2.a1, t2.a2, offset:0, count:100 │ └─IndexRangeScan_16 estRows=100100.60 cop[tikv] index:ic(c) range:[0,0], keep order:false └─TableRowIDScan_17(Probe) estRows=100 cop[tikv] keep order:false こちらは keep order:false となっており、オプティマイザが「このインデックスは a1 , a2 の順序を提供しない」と判断しています。順序を使えないため LIMIT で読み取りを早期に打ち切る根拠がなくなり、 c = 0 に一致するインデックスエントリを全件読むことになります。 estRows=100100.60 がその見積りです。読み終わったあとに TopN で（ a1 , a2 ）でソートして上位100件を残す形になります。 TopN が2段あるのは、coprocessorのタスクがリージョン単位で並列実行されるため、 TopN_18 の結果が「リージョンごとの上位100件」という部分結果にとどまり、それらをTiDB側の TopN_10 で束ねて全体の上位100件を確定させる必要があるからです。 差は次の3点に整理できます。 int主キー（int handle, t1） / MySQL 改修前のint以外の主キー（common handle, t2） 1. インデックススキャンの順序保証 keep order:true 。インデックスの物理順をそのまま結果順として使う keep order:false 。順序を使えないため後段でソートが必須になる 2. LIMITの扱い Limit がcoprocessorにpush downされ、さらに IndexLookUp に埋め込まれる。100件で読み取り自体が止まる Limit が単独で残らず TopN に吸収される。 TopN は全件読んでから上位Nを取るため、読み取りを早期に止められない 3. 読み取りインデックスエントリ数 100 c = 0 の一致行すべて。この例では見積り100,100 本質的なコストは3点目です。この差は LIMIT の値ではなく WHERE 条件に一致する行数に比例するため、条件に合致する行が多いテーブルほど大きくなります。逆に一致行が数百件程度しかないテーブルではほとんど差が出ません。加えて t2 側には、 t1 に存在しないソートのコストが追加されます。この例では a1 が varchar なので、比較はcollationを考慮したものになります。 MySQLでは、InnoDBのセカンダリインデックスが主キーの型に関係なく（ c , a1 , a2 ）順に並び、オプティマイザがそれを認識するため、 c = 0 にシークしてインデックスを順方向に読み、100行で止まります。 t1 の計画と等価な実行になり、ソートは発生しません。つまり改修前のTiDBは、MySQLから主キーを複合キーや文字列キーに変えて移してきた場合に、同じSQL・同じインデックス構成でも実行の形が変わる状態でした。インデックスの末尾に主キーカラムを明示的に含め、この順序をオプティマイザに認識させることでMySQLと同等に動作します。 端的にこの問題をまとめると、メルカリでは「 ORDER BY 狙いのインデックス」戦略が一定程度とられており、あるケースではTiDBとMySQLで主キーのソート処理が非互換のため、末尾に主キーを含めたインデックス作成という形でこれに対する対応を行いました。この対処は相当数のテーブルで必要になりました。同様のインデックス戦略をとっている場合、 ORDER BY 主キー LIMIT を伴うクエリで本事象に遭遇する可能性があります。 本対処については、次の理由から対処は比較的容易な部類でしょう。 DDL（Data Definition Language）がオンラインで高速 Invisible Index が利用できる SQL Plan Management （SQL binding）が利用できる その他の一般的な改善（N+1・ヒント句） ここからは、インデックス非互換のようなTiDB固有の話題ではなく、データベース一般に広く見られる問題への対応を2点紹介します。N+1問題もヒント句による実行計画の制御も、それ自体はごく一般的な内容ですが、いずれもMySQLからTiDBへの移行を境に対応の必要性が顕在化しやすいため、あわせて共有します。 N+1の改善 N+1問題とは、1件の親データを取得したあと、関連するN件のデータを1件ずつ個別のクエリで取得してしまうアクセスパターンを指します。単一のAPI呼び出しの中で数百、数千回のデータベースアクセスが発生するため、クエリ1回あたりのレイテンシがそのまま応答時間に積み上がります。 MySQLと比較すると、TiDBは分散データベースである都合上、クエリ1回あたりのベースレイテンシがやや高くなります。このため、MySQLでは許容範囲に収まっていたN+1パターンが、TiDBへの切り替えを境に問題として顕在化することがあります。 このパターンについては、複数件をまとめて取得する形にクエリを集約するなど、開発チームと連携して一定数の改修を実施しました。 ヒント句による実行計画の制御 TiDBはMySQLと同様にオプティマイザヒントをサポートしており、 /*+ ... */ 形式のコメントで結合アルゴリズムや使用インデックスなどを明示的に指定できます（ Optimizer Hints ）。統計情報に基づく自動選択が期待通りにならないクエリに対して、実行計画を安定させる手段として利用できます。 大量のデータを保持するテーブルを、複数回結合しているクエリでは、個別にヒント句をつけ、クエリを改善する必要がありました。全体の改善の中では、対象は少数のクエリに限られました。 可能であればそもそもMySQL（TiDB）で処理をするのではなく、BigQueryなどで動的にリソースを確保して処理をした方が望ましいケースが多くありましたが、アプリケーションの改修の都合でMySQL（TiDB）での処理を継続する必要があり、SQLの調整で対応しました。 なお、本記事で扱った内容より前の時期に実施した初期のパラメータ調整や検討については、下記の発表資料もあわせてご覧ください。 https://speakerdeck.com/pingcap0315/tidb-cloud-niokeruda-gui-mo-poc-nohua-db-tech-showcase-2023-tokyo まとめ 本記事では、TiDBとMySQLのインデックス非互換への対応を中心に、N+1問題の改善やヒント句による実行計画の制御といった一般的なクエリ改善もあわせて紹介しました。最後に、それぞれの経験から得られた教訓を整理します。 中心トピックであるインデックス非互換への対応では、common handleを持つテーブルで主キー順のORDER BYがインデックス順として認識されないという、TiDBとMySQLの挙動の違いに対して、インデックスの末尾に主キーカラムを含めることで対応しました。TiDBはオンラインDDLが高速で、Invisible IndexやSQL Plan Managementといった機能も利用できるため、対処自体は比較的容易な部類です。なお本挙動は最新のmasterではすでに改修されています。 一般的な改善として紹介したN+1問題は、分散データベースであるTiDBではクエリ1回あたりのベースレイテンシがMySQLよりやや高いため、移行を境に顕在化しやすいパターンです。移行前に該当のアクセスパターンを洗い出し、複数件をまとめて取得する形にクエリを集約しておくことをおすすめします。 同じく一般的な手法であるヒント句は、統計情報に基づく実行計画の自動選択が期待通りにならないクエリに対して、実行計画を安定させる有効な手段です。ただし対象となるクエリは限られており、大量データの複雑な結合処理については、そもそもBigQueryなどの分析基盤へ処理を移すことも含めて検討する価値があります。 3つの記事を通じて、私たちDBREチームが2026年3月末までに行ったTiDBの改善の取り組みを紹介してきました。MySQLからTiDBへの移行や、TiDBの運用改善に取り組む方の参考になれば幸いです。 2026年4月以降もいくつかのアプリケーションの改修を含む改善をしており、こちらも別途ブログ記事で紹介します。ご期待ください。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属するDBREチームのEM（Engineering Manager）および、IC（Individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは以下をご覧ください。 EM: https://apply.workable.com/mercari/j/7AD4EF9218/ IC: https://apply.workable.com/mercari/j/ACD2689E9E/ また、メルカリにおけるTiDBやデータベース関連の取り組みについては、 TiDB関連の記事一覧 や データベース関連の記事一覧 もあわせてご覧ください。

本記事は、私たちDBRE（Database Reliability Engineering）チームが2026年3月末までに行った改善を紹介する3つの記事の2つ目です。 1つ目のブログ記事の「 メルカリにおけるTiDB改善の取り組み：IN句内100万件クエリへの対応 」では、IN句に多数の要素を含むクエリがTiDBクラスタ全体のレイテンシを悪化させた事例を紹介しました。 本記事では、下記の4点の対応や改善についてお伝えします。 リソースグループの不具合に対する対応 リージョンサイズ (coprocessor.region-split-size) の調整 プランキャッシュの検討 In Memory Engineの導入 これらの取り組みのうち、リージョンサイズの調整ではクラスタ全体のリージョン数を約10%削減し、TiKVのCPU負荷を最大約20%改善しました。また、In Memory Engineの導入では、0.5〜1.5秒かかっていたクエリのレイテンシを0.1秒程度まで短縮しています。一方で、プランキャッシュのようにワークロードによっては期待した効果が得られず、設定を見直した事例もありました。本記事では成果だけでなく、その判断に至る過程もあわせて紹介します。 リソースグループの不具合対応 まず、1つ目の取り組みとして、リソースグループの不具合への対応を紹介します。メルカリでは各ユーザーのリソース利用量の把握および、リソース利用量の制限を目的として、リソースグループの機能を利用しています。 https://engineering.mercari.com/blog/entry/20251211-3846ed440d/ このリソースグループの利用時に想定外にリソース利用量が制限され、高負荷になる、という事象に遭遇しました。私たちが観測した事象は、TiKVのCPUが高負荷になり、このとき Task Wait QPS by Priority というメトリックにて、リソースコントロールがクエリの動作を制限していた形跡を確認しました。 https://github.com/tikv/tikv/issues/18939 この不具合を理解するために、TiKVにおけるリソースグループの動作を簡単に説明します。TiDBのリソースコントロールでは、リソースグループごとにRU（Request Unit）にもとづく流量制御と、優先度（HIGH/MEDIUM/LOW）に基づく実行制御が行われます。TiKV側では優先度ごとにタスクの実行キューとCPUクォータ（priority quota limiter）を持ち、CPU使用率が閾値を超える混雑時には、低い優先度のタスクに割り当てるCPU時間を絞ることで高い優先度のタスクの実行を確保する実装になっています。さらにこのクォータは固定値ではなく、実際の利用状況をもとに、優先度ごとの割当量を自動調整する仕組みになっていました。 今回は、この自動調整ロジックの問題により、実際には制限する必要がない場合でも、MEDIUM/LOW優先度に割り当てられるクォータが最小値まで絞り込まれていました。その結果、TiKV全体のCPUには十分な余裕があるにもかかわらず、Priority: MIDDLEで動作しているワークロードが待たされる、という事象が発生します。 この不具合に遭遇するまでは、デフォルトのワークロードをPriority: MIDDLE、負荷を隔離して制限すべきワークロードをPriority: LOW にて運用を行っており、Priority: HIGH は将来のために利用していなかったため、通常通り動作するならば、Priority: MIDDLEのクエリが制限を受ける理由はありませんでした。不具合はTiDB 8.5.5で自動調整そのものの無効化という形で改修されていますが、それまでのワークアラウンドとしては、このバグにヒットしないためには、Priority: HIGHを設定する、という対処をとりました。 リソースグループをご利用の方は、OLTP（Online Transaction Processing）トラフィックには、Priority: HIGHを割り当ててご利用ください。 リージョンサイズ (coprocessor.region-split-size) 調整 続いて、2つ目の取り組みであるリージョンサイズの調整を紹介します。前提として、リージョンとは、TiKVがデータを一定のキー範囲ごとに区切って管理・複製する単位であり、負荷分散や障害復旧の実施単位です。 リージョン数を減らす（リージョンサイズを増やす）と、TiKVのKvBatchGet/Coprocessorといった取得処理のRPC（Remote Procedure Call）数が減り効率化されます。一方でリージョンサイズを増やすと、負荷分散がされにくくなったり、負荷分散のためにリージョンを移動する際の処理が大変になったり、というトレードオフが発生します。下記のドキュメントなどを確認し、調整を進めていく必要があります。本パラメータは、クラスタグローバルの設定値であり、基本的には特定のテーブルだけリージョンを小さくしたりする、ということはできません。下記の記事の後者の記事は、特に詳しい記載があるのでそれをよく参照してください。 https://docs.pingcap.com/tidb/stable/tune-region-performance/ https://www.pingcap.com/blog/understanding-raft-region-size-tidb-performance-recovery/ なお、リージョンサイズの目安である region-split-size のデフォルト値は、v8.4.0（LTS系列ではv8.5系）で96MiBから256MiBに変更されています（※）。 また、このregion-split-sizeに関連して、どのリージョンがどのサイズ以下になったら統合するか、といった付随するパラメータも存在し、これに対しても合わせて考慮が必要です。 本パラメータの調整により効果が期待できるケースとしては、大量のデータを保持しており、複数行のデータを一括取得するワークロードがある場合が挙げられます。逆に単一行の取得が多かったり、そもそもデータ量が少ない場合に効果は見込めません。 メルカリでregion-split-sizeを96MiBから256MiBに調整したタイミングでは、クラスタ全体でのリージョン数としては10%程度減少し、TiKVのCPU負荷ベースで最大約20パーセントの改善が見られた例がありました。 最新のデフォルト値より小さいサイズで運用している方は、この値の変更を積極的に検討するとよいと思います。 ※ v8.5.0〜v8.5.2にはアップグレード時に実効値が意図せず256MiBへ切り替わる問題があり、v8.5.3で修正されています（ tikv#18503 ）。 プランキャッシュ／インスタンスプランキャッシュの検討 3つ目の取り組みは、プランキャッシュの検討です。この章では、プランキャッシュとは何か、TiDBのプランキャッシュはどのような設定があるか、メルカリでどのように導入し効果はどうだったか、効果はどのように確認できるかについて説明します。キャッシュの効果はワークロード依存ですので、この記事を参考に設定の有効化を検討してみてください。 プランキャッシュとは リレーショナルデータベースがSQLを実行するとき、内部では受け取ったSQL文字列の構文解析、参照先テーブルやインデックスの解決を経て、どのインデックスを使い、どの順序・アルゴリズムでテーブルを結合するかといった「実行計画」を統計情報にもとづいて選択し、そのうえで初めて実際のデータの読み書きを行います。この実行計画の選択（最適化）は、候補となる計画の列挙とコスト評価を伴うため、相応のCPUコストがかかる処理です。 OLTPワークロードでは、パラメータの値だけが異なる同じ形のクエリが大量に実行されます。1回あたりの実行時間が短いクエリほど、処理全体に占める最適化コストの比率は相対的に大きくなります。そこで「同じ形のクエリに対して一度選択した実行計画を保存しておき、次回以降は最適化を省略して再利用する」という発想が自然に出てきます。これがプランキャッシュの基本的な考え方であり、多くのRDBMSが何らかの形でこの仕組みを実装しています。プランをキャッシュすることで実行プランの生成コストが抑えられる可能性がある一方で、キャッシュを検索したりあるいはキャッシュに保存したりという処理にもオーバーヘッドがあり、導入に効果があるかどうかを見極めて利用する必要があります。 TiDBにおけるプランキャッシュ TiDBのプランキャッシュについて、知っておくべきは下記のようにまとめられます。 プリペアードステートメントと、その他（ノンプリペアードステートメント）でキャッシュの扱いが異なる https://docs.pingcap.com/tidb/stable/sql-prepared-plan-cache/ https://docs.pingcap.com/tidb/stable/sql-non-prepared-plan-cache/ 従来（8.4より前）はキャッシュの単位がセッション単位だった 8.4から インスタンスプランキャッシュ という、TiDBノードでプランキャッシュを共有する機能が利用可能になった セッション単位のキャッシュよりもメモリ効率よくキャッシュできますが、キャッシュの共有範囲はTiDB Cluster全体ではありません インスタンスプランキャッシュは、通常のプランキャッシュが有効である前提での追加機能 プリペアードステートメントでない、 通常のDML（Data Manipulation Language）に対するキャッシュ は現状デフォルトオフである ここまでは、TiDBの機能そのものについての一般的なまとめになります。ここから本機能の利用におけるメルカリでの事例について紹介します。 メルカリでのプランキャッシュの導入 メルカリでは順次移行切り替え済みのTiDBに対して、最初はプランキャッシュを有効にして運用してきました。これらのクラスターは8.1系から8.5系へバージョンアップをする機会がありました。この際にプランキャッシュのヒット率が大幅に低下するといったことを経験したり、また期待していたインスタンスプランキャッシュを一度有効化するものの、有効化によるオーバーヘッドの方が大きく設定を再度無効化するケースがありました。運用しているクラスタのワークロードにより、キャッシュヒット率は大きく異なり、記事執筆時点では1つのクラスタでのみプランキャッシュ／インスタンスプランキャッシュを有効化し、残りのクラスタでは無効化しています。 ヒット率が想定ほど伸びない要因の1つは、数値リテラルの扱いでした。non-prepared plan cacheでは、数値カラムに対して ‘123’ のような文字列リテラルで比較しているクエリはキャッシュの対象外となります。メルカリではアプリケーションの一部が数値を文字列として埋め込むクエリを発行しており、これがヒット率を下げる一因となっていました。 また、8.5系へのバージョンアップ後にヒット率が大幅に低下した事象には、オプティマイザのpredicate simplificationにOR条件の枝刈りを追加した下記の変更が関係していました。 https://github.com/pingcap/tidb/pull/56136 この枝刈りが発動したクエリは「OR predicate simplification is triggered」という理由でプランキャッシュの対象外となるため、OR条件を含む一部のクエリがバージョンアップを境にキャッシュされなくなりました。このような対象外の理由は、後述するSTATEMENTS_SUMMARYのPLAN_CACHE_UNQUALIFIED_LAST_REASONカラムでクエリごとに確認できます。 計画段階では下記のUsage Restrictionをよく確認し、実際のクエリにどの程度効果があるかを確認すると良いでしょう。 https://docs.pingcap.com/tidb/stable/sql-non-prepared-plan-cache/#usage-restrictions プランキャッシュの効果の確認 プランキャッシュが実際に効いているか、あるいはなぜ効かないかは、TiDBの機能で確認できます。クエリ（digest）単位の集計は INFORMATION_SCHEMA.STATEMENTS_SUMMARY で確認でき、累計ヒット回数の PLAN_CACHE_HITS 、直近実行がヒットしたかを示す PLAN_IN_CACHE に加えて、キャッシュ対象外と判定された回数（ PLAN_CACHE_UNQUALIFIED ）とその理由（ PLAN_CACHE_UNQUALIFIED_LAST_REASON ）も取得できます。ヒット率が想定より低い場合は、まずこの理由カラムを確認するのが近道です。 個別のクエリについては、 EXPLAIN FORMAT='plan_cache' と SHOW WARNINGS で「そのクエリがnon-prepared plan cacheの対象になれるか、なれない場合の理由」を事前に診断できます（FORMAT指定のない通常のEXPLAINはキャッシュを利用しない仕様のため、診断にはこの形式が必要です）。また、直前に実行したクエリが実際にキャッシュを利用したかどうかは、セッション変数 last_plan_from_cache で確認できます。 -- 対象になれるかの事前診断（なれない場合は理由がwarningに出る） EXPLAIN FORMAT='plan_cache' SELECT ...; SHOW WARNINGS; -- 直前の実行がキャッシュを利用したかの確認（1ならヒット） SELECT @@last_plan_from_cache; 診断方法の詳細は下記のドキュメントを参照してください。 https://docs.pingcap.com/tidb/stable/sql-non-prepared-plan-cache/#diagnostics In Memory Engineの活用 最後に、4つ目の取り組みを紹介します。メルカリでは一部のクエリで In Memory Engine （IME）を活用しています。In Memory Engineは、更新や削除が頻繁なテーブルにおいて、読み取り時に大量のMVCC（Multi Version Concurrency Control）履歴バージョンを走査せざるを得なくなる問題を緩和する機能です。ホットデータをメモリにキャッシュして読み取りを高速化する機能ではない点に注意が必要です（その役割は従来からブロックキャッシュが担っています）。IMEは対象RegionのMVCCバージョンをメモリ上で管理し、ディスク上のGC（Garbage Collection）よりも積極的に古いバージョンを整理することで、クエリが読み飛ばす不要なバージョンの数そのものを削減します。このため効果が見込めるのは、MVCCバージョンが増えることにより読み取り性能を劣化させているワークロードに限られます。 私たちの環境はいわゆるキューのような使われ方をしているテーブルがあり、データの総量は小さい一方、非常に多くの挿入削除が発生するユースケースで、IME導入前に0.5〜1.5sのレイテンシだったクエリが0.1s程度に改善されました。 性能上一定の効果を確認できた一方、運用上の複雑さが増えたり、この機能の不具合で全体影響を受けるなど、ダウンサイドも多く経験しました。詳細な適用条件やチューニングは本記事の範囲を超えるため割愛しますが、導入は慎重な検証の上で行う必要があります。 まとめ 本記事では、リソースグループの不具合対応、リージョンサイズの調整、プランキャッシュの検討、In Memory Engineの導入という4つの取り組みを紹介しました。最後に、それぞれの経験から得られた教訓と推奨事項を整理します。 リソースグループについては、CPUクォータの自動調整の不具合により、Priority: MEDIUM以下のワークロードが想定外の制限を受ける可能性があります。改修が入ったTiDB 8.5.5より前のバージョンを利用している場合は、OLTPトラフィックにPriority: HIGHを割り当てることをおすすめします。 リージョンサイズについては、大量のデータを保持し、複数行を一括取得するワークロードで効果が期待できます。最新のデフォルト値（256MiB）より小さいサイズで運用している場合は、負荷分散とのトレードオフを理解した上で、変更を積極的に検討する価値があります。 プランキャッシュの効果はワークロードに強く依存し、バージョンアップを契機にヒット率が大きく変わることもあります。導入前にUsage Restrictionsを確認するだけでなく、STATEMENTS_SUMMARYなどを用いて効果を継続的に観測し、オーバーヘッドが効果を上回る場合には無効化する判断も必要です。 In Memory Engineは、MVCCバージョンの累積が読み取り性能を劣化させているワークロードに限って効果を発揮します。私たちの環境では大きなレイテンシ改善を得られた一方で運用上の複雑さも増えたため、導入は慎重な検証の上で判断することをおすすめします。 本記事の内容は、メルカリが2026年3月末までに行ってきた改善を3つに分けた2つ目の記事でした。残る1回の記事では、MySQL/TiDBにおけるインデックス非互換への対応についてお伝えします。ご期待ください。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBREチーム の EM（Engineering Manager） および、IC（Individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは EM https://apply.workable.com/mercari/j/7AD4EF9218/ IC https://apply.workable.com/mercari/j/ACD2689E9E/ をご覧ください。 また、メルカリにおけるTiDBやデータベース関連の取り組みについては、 TiDB関連の記事一覧 や データベース関連の記事一覧 もあわせてご覧ください。

先日、 メルカリのCoreDBをMySQLからTiDBへ移行した振り返り という記事で、MySQLからTiDBへの移行完了に関する報告と、大枠の振り返りについてお伝えしました。これから3つの記事にわたって、私たちDBRE（Database Reliability Engineering）チームが、2026年3月末までに行った改善について紹介します。 1つ目の本記事では、メルカリの最も大きなクラスタ切り替え直前に発覚した、IN句に多数の要素を含むクエリがTiDBクラスタ全体のレイテンシを悪化させた事例を紹介します。この事例は、MySQLとTiDBを並行運用し、一部のクエリに対して先行してエンドポイントをTiDBへ切り替えていた期間に発生しました。 私たちDBREチームは、ProxySQLによる一時的な切り戻し、TiDB Cloudサポートとの原因調査、Temporaryテーブルを使ったアプリケーション改修を通じて、この問題に対処しました。本記事では、巨大なIN句が分散データベースに与えた影響、リプレイ検証で事前に検出できなかった理由、そしてTemporaryテーブルを導入する際に注意すべきポイントを共有します。 問題発生時の状況 様々な事前の動作確認を終え、全体として下記の順序で順にMySQLからTiDBへ切り替えを行う計画でした。 読み取りエンドポイント（OLAP: Online Analytical Processing トラフィック）の切り替え 読み取りエンドポイント（OLTP: Online Transaction Processing トラフィック）の切り替え 書き込みエンドポイントの切り替え 問題が発生した時点では、私たちは手順1を実施していました。具体的には、読み取りエンドポイントのうち、比較的高負荷なトラフィックを含むエンドポイント(バッチエンドポイントと呼びます)をMySQLからTiDBへ切り替えていました。切り替えの前には、ProxySQL経由でMySQLに流通するトラフィックを内製ツールによるクエリリプレイによりTiDBへ発行し、OLAPエンドポイントに関してもクエリの互換性の問題や、TiDBの負荷のチェックを事前に行い必要な問題には対処していました。 また、同時にMySQLからTiDBへ切り替える前に、 別のブログ記事で紹介した大量のデータ削除ツール を利用して、1日1億件以上のデータ削除を実行していました。 発生した問題 – クラスタ全体の遅延 バッチエンドポイントをMySQLからTiDBへ切り替えた後、毎時クエリ速度が著しく低下する時間が発生しました。 また、MySQLからTiDBへの同期遅延が、このレイテンシ拡大と同じタイミングで定期的に発生していることを観測しました。あわせて、更新のCommit所要時間も同時に上昇していることを確認しました。 この事象の特筆すべきことはクエリの速度の低下が、特定のクエリにとどまっておらず、クラスタ全体に波及していることです。 通常、特定のクエリに問題がある場合、その影響は当該クエリや関連する処理に閉じることを期待します。しかし今回の事象では、原因となったクエリ以外の読み書きにも遅延が波及していました。この点が、単なるクエリチューニングではなく、クラスタ全体の安定性に関わる問題として扱う必要があった理由です。 初期の対応 – 原因となっているクエリの特定/特定クエリの切戻し 遅延の発生にデータ削除は関係ないと考えられた一方で、まずはそれを一時的に停止した後、何がこの事象を発生させているのかの調査を行いました。 スロークエリのリスト精査により、原因となるクエリを直ちに特定し、まずは影響を一時的に抑えるためにProxySQLで「当該クエリのみ」再度MySQLへルーティングするように変更することとしました。この「問題あるクエリを特定し、そのクエリ（クエリダイジェスト）のみ実行先を変更する」オペレーションは、移行の計画の中である程度想定されていたオペレーションで、現在も有効に活用されています。 この一部のクエリに対して、実行先のホストを変更する処理は、ProxySQLの mysql_query_rules というテーブルに対して所定のルールを記述することで実現できます。 なお、この機能でトランザクション中のあるクエリだけ実行先ホストを変える、ということはできません。 また余談となりますが、ここで利用しているクエリダイジェストとは、SQL文からリテラル値（数値や文字列などの具体的な値）をプレースホルダに置き換え、空白やコメントを正規化した「クエリの型」と、それをもとに計算されるハッシュ値のことです。たとえば SELECT * FROM items WHERE id = 123 と SELECT * FROM items WHERE id = 456 は、正規化するとどちらも SELECT * FROM items WHERE id = ? となり、同一クエリ（同一クエリダイジェスト）とみなせます。値だけが異なる同型のクエリを1つのグループとして扱えるため、同じ種類のクエリの実行状況の集計や、クエリのルーティングの単位として利用できます。このProxySQLで利用するダイジェストは、 pt-query-digest といった他のツールで生成されるダイジェストやTiDBで生成されるものと互換がないものとなります。ProxySQL内でクエリがどのようなダイジェストで表現されているかを確認し、ルールを設定する必要があります。ProxySQLが認識しているダイジェストは、Adminインターフェースの統計テーブル stats_mysql_query_digest から取得できます。 digest_text （正規化後のクエリ文字列）で対象のクエリを探し、対応する digest カラムの値を mysql_query_rules に設定する、という流れになります。 根本原因の調査 – Protobufのデシリアライズが問題と特定 特定のクエリをMySQLで処理するように切り戻したことで、ユーザー影響を抑えながら調査を継続できる状態になりました。しかし、特定クエリをMySQLへ戻すだけではTiDB移行を完了できませんので、続いてTiDB Cloudのサポートと連携し、このクエリがなぜクラスタ全体に影響したのかを調査しました。 最初はどのクエリが問題かに対する認識をメルカリとPingCAP社で合わせ、「当該クエリの実行時に Index Join の内部処理で生成される IN リストが 100 万件近くに達している」という事実を確認しました。また、当該クエリは結合条件を含む大量の行を処理するものだったため、あわせてPingCAP社からは、クラスタ全体がダウンするリスクを抑えるとともに、当該クエリの並列度を下げて処理を平滑化する1次対処の提案を受けました。具体的には、スキャン範囲のメモリ上限を制御する tidb_opt_range_max_size と、Index Joinの並列度を制御する tidb_index_lookup_join_concurrency の調整です。（現時点ではdeprecatedで tidb_executor_concurrency を代わりに利用することが推奨されています） -- クラスタの安定性の確保 SET GLOBAL tidb_opt_range_max_size = 1048576; -- 並列度抑制 SET SESSION tidb_index_lookup_join_concurrency = 2; 続いて調査が進み、根本原因はTiKVのgRPCスレッドにおけるProtobufデシリアライズ処理にあることが分かりました。 https://github.com/pingcap/tidb/issues/55845 大きなIN句の発行により、gRPC スレッドが Protobufのデシリアライズ処理に過度に占有され、その結果、 同じ gRPCスレッドを使用する後続のすべてのリクエスト（他の読み書き操作）に待ち状態が発生し 、クラスター全体のレイテンシが急上昇する結果となっていたのです。 問題解決への対処 – Temporaryテーブルの活用 根本原因の特定に至るまでの間、私たちは下記に記載したアプリケーションの改修が不要な対処候補を事前に検討していました。 リソースコントロールにより該当クエリの優先度を下げる TiKVをスケールアップする TiDBのシステム変数を調整する（tidb_opt_range_max_size, tidb_index_lookup_join_concurrency） 一方、根本対処としてはPingCAP社から「100万件のIN句の要素を Temporaryテーブル に保存し、SQLとして渡さないようにする」方法の提示を受けました。gRPCスレッド経由で実際の100万件のIDが渡されなくなる、ということで、根本的かつ実効性が見込める改修手段です。 しかし、SQLの修正やロジック修正を含むアプリケーション改修は、開発チームの現行の優先度に割り込んで変更を実施する必要があり、直ちに完了する保証がなかったため、その他のワークアラウンドに対しても、実際にどの程度の効果が見積もれるかを、検証・確認しました（結果的には1-3のアプリケーション改修を行わない暫定対処の緩和策は問題解決への寄与は限定的という結論でした）。 この問題に対処しないままMySQLからTiDBへ切り替えることは困難でした。TiDB Cloudのサポートチームには、調査と対策の検討において多大な協力をいただきました。 再現環境の構築と改修 本番と同じようなクエリが流れている状況で再現・改修確認を行うため、本番のクラスタとは独立した同じデータが流通するクラスタを作成することにしました。 この再現環境の構築では、次のような問題が発生しました。 リソース枯渇問題がありクラスタが作成できない クラスタ作成後のリストア処理で、帯域のQuota制限などでリストア処理が何回も失敗 リストア後のデータが最新データに追いつく際にデータパイプラインに遅延が発生 特に3のデータパイプライン遅延については大きな問題でした。新規にTiCDC（TiDBの変更データをダウンストリームへ同期するコンポーネント）の同期タスクであるChangefeed 2を作成し、データを下流のTiDBに伝播させようとしたところ、データパイプラインの負荷が隔離されないケースがあり、結果として既存の運用中であるChangefeed 1の同期に影響が発生しました。本事象の詳細とその解決については、TiDB関連のデータパイプラインをまとめたブログ記事を別途作成し、そこで紹介する予定です。 改修確認 – 消えたクエリ 実環境でクエリの修正により問題が解消したことを確認する際には、前提条件として事前に改修前後のクエリを新しい検証用のクラスタで実行し改善を確認していました。しかし、開発環境でリリースし、いざ本番環境でリリースしたところ、当初クエリの存在が確認できませんでした。 旧MySQLのバッチエンドポイントにクエリが発行されている可能性、などを調査しましたが、見つからず… 検証用TiDB、切り替え用TiDBにも見つからず、最終的には、書き込みエンドポイント向けにクエリが発行されていることが確認できました。これは、クエリ改修時に、Temporaryテーブルの作成およびTemporaryテーブルへの挿入、といった処理がアプリケーションで読み取りエンドポイントへの発行が禁止されており、結果として意図せぬ発行先に（MySQLのWriterへ）クエリが発行されることとなっていました。これは、アプリケーションがReplicaに書き込みを行うとデータ不整合を起こす可能性があるため、ReplicaへのINSERTを禁止するテストが存在していたためです。検証用に独立したクラスタを準備したにもかかわらず、結果的に本番環境への影響リスクを十分に排除できていませんでした。 開発環境と、本番環境でエンドポイントの構成に差分があったこともこの事象が発覚しなかった原因の一つでした。 最終的には、再度アプリケーションを改修し、バッチエンドポイントに対して、Temporaryテーブルの処理をするようになり、TiDBで問題なく動作することが確認できました。 なお、このIN句の要素をTemporaryテーブルとして渡すようアプリケーションを改修する対処が必要になったのはメルカリではこのケースを含めて2件のみです。 事後振り返り – リプレイで検出できなかったクエリ 本バッチエンドポイントに対しても切り替え前に、事前にクエリリプレイによる負荷の再現検証を行なっていました。このエンドポイントに対しては、数時間に数個の取りこぼしがあったものの、ほぼ100%のクエリはリプレイできていました。しかしながら当該クエリについては、切り替え前の検証時点では、（a）ツールが「取りこぼし」として検知・報告した漏れに含まれていたのか、あるいは（b）そもそもツールが取りこぼしとしても検知できない形で漏れていたのかが判別できませんでした。結果として、実際にエンドポイントを切り替えるまで、このクエリがもたらすリスクを検出できませんでした。 本問題対処完了後に、パケットのキャプチャサイズの上限や、パケットのフラグメンテーションなどの扱い、その他の可能性を事後に検討し、なぜリプレイできなかったか、振り返りを行いましたが、解明には至りませんでした。再現は容易なので解決できない問題ではないと思うのですが、一定の時間をかけて解決しなかったので、現時点では追加調査を保留しています。 Temporaryテーブル導入時のポイント 最後にTemporaryテーブルを導入する際の細かいポイントをいくつかまとめます。実際に類似事例に対処が必要になった際に、考慮すべき事項としてご活用ください。 Temporaryテーブルへのデータ挿入は大胆に TiDBのTemporaryテーブル は、メモリ上で処理が完結します。 通常は、データの更新は大量の更新を一括で行うと、データ同期の遅延などの可能性があるため、少しずつ更新/挿入したり、トランザクションサイズの制約があります。しかし、 ローカルTemporaryテーブル を利用すると接続しているTiDBのメモリ上に全データが格納されるため、100万件のデータ挿入であっても遅延発生の心配はなく、データを過度に分割して挿入したり挿入の間にsleepを入れたりする必要はありません。 Temporaryテーブル作成権限付与忘れに注意 Temporaryテーブルの作成には、当該ユーザーに所定の権限（CREATE TEMPORARY TABLE 権限）が必要です。MySQLでもTiDBでも同じ権限が必要です。 https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_create-temporary-tables Temporaryテーブルのサイズ制限を確認する すべてのデータをメモリで扱うという都合上、サイズの制約を通常より気にする必要があります。 idのみを一時的に保持するというユースケースでは、100万件レベルでは通常特に問題にならないことが多いと思われます。TiDBではTemporaryテーブルサイズの上限はデフォルトでは64MBで tidb_tmp_table_max_size 変数でセッション単位でも変更可能ですので必要に合わせて設定をしてご利用ください。 Temporaryテーブルへの読み書きが読み取りノードでできるかに注意 Temporaryテーブルの作成、Temporaryテーブルへのレコード挿入は一種の書き込みクエリですが、読み取りノードに対しても発行可能です。一方で、アプリケーションやライブラリの作りにより、読み取りノードにはTemporaryテーブルを含めた書き込みクエリを発行できない、書き込みエンドポイントへクエリを自動的に発行するといった挙動になっていることがあります。このような制約の影響でクエリ発行先が予期せず変わらないように注意が必要です。 MySQL / TiDB間の互換についての考慮 MySQLからTiDBへの移行期間中であれば、MySQLとTiDBの両方のデータベースで動作させる可能性があり、双方で動作するように互換性を考慮する必要があります。 下記の場合に、SQLレベルで非互換となりアプリケーションによりロジックを分岐する必要が発生する場合があります。 MySQLにおいて binlog_format =STATEMENT で運用している場合 Temporaryテーブルへの操作によってGTID（Global Transaction Identifier）と呼ばれるIDが発行され、これにより不整合の可能性として記録されます。 一時テーブルのサイズが個別に指定が必要な場合 tidb_tmp_table_max_size 変数はヒント句での指定が不可能(Applies to hint SET_VAR : No)です。 まとめ 本記事では、MySQLからTiDBへの切り替え前に取り組んだIN句に100万件の要素を含むクエリがクラスタ全体に影響を与えた問題とTemporaryテーブルによる根本対処の方法、そして実際にTemporaryテーブルを利用しアプリケーションを改修する際の注意点についてお伝えしました。TiDBのリリース予定日は、外部に切り替え日を連絡済みだったり、万が一のためCXOの予定を押さえたりしている中で、再現試験環境を作成するための比較的時間のかかるリストアが繰り返し失敗するなどといったこともあり、とても印象深い事例でした。クエリリプレイなどを行っていたにもかかわらず、リプレイでは事前の問題抽出ができませんでしたが、バッチエンドポイントの先行切り替えにより、若干早く問題を発見できたため結果的に当初予定通りの切り替えが達成できました。 本記事ではメルカリが2026年3月末までに行ってきた改善を3つに分けた1つ目を紹介しました。続いて2つ記事を公開しますので、引き続きご期待ください。 IN句内に多数の要素を含むSQLで全体影響が発生した事例共有（本記事） 次の改善事例の共有 リソースグループの不具合に対する対応 リージョン数の調整 プランキャッシュの導入/調整 In Memory Engineの導入 MySQL/TiDBにおけるインデックス非互換への対応 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBREチーム の EM（Engineering Manager）および、IC（Individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは EM https://apply.workable.com/mercari/j/7AD4EF9218/ IC https://apply.workable.com/mercari/j/ACD2689E9E/ をご覧ください。 また、メルカリにおけるTiDBやデータベース関連の取り組みについては、 TiDB関連の記事一覧 や データベース関連の記事一覧 もぜひご覧ください。

概要 メルカリでは、CoreDB と呼ばれる中核データベースを長年オンプレミス上の MySQL で運用してきました。本記事では、2026 年 4 月に完了した MySQL から TiDB への移行を振り返り、長期的なスケーラビリティの改善、弾力的なリソース確保、クラウド化による運用負荷の軽減といった成果を紹介します。また、移行フローや ProxySQL を活用した段階的な切り替えでうまくいった点、実トラフィックを用いた検証やコスト見積もりで直面した課題、移行後に見えてきた改善テーマについても整理します。 TL;DR 中核データベースであるCoreDBを 2026/04 にオンプレミスMySQLからTiDBへ移行完了 移行により下記の当初目的を達成 長期的スケーラビリティの改善 トラフィック変動に応じたリソース調整 オンプレミス運用からの脱却 DBREのEM/ICを募集中 もう少し詳しい内容が知りたい方へのポイントまとめ 移行は問題があればMySQLに切り戻し可能な構成を維持しながら実施 ProxySQLを活用し段階的にTiDBに本番トラフィックを移行 切り替えを中央管理し、アプリケーションから透過的な切替を実現 バッチ(OLAP)エンドポイントの先行移行、切り替え前の実トラフィックの9回のテストで問題を事前に検出 クエリリプレイによるテストを心がけるも80%負荷再現が当時の限界 事前のベンチマークには問題があり、不正確なコスト見積もりに TiDB DDLはオンライン化/分散実行による高速化を達成 DDL運用負荷が減り、「あるべきテーブル定義」ベースに 上記の内容を、記事内で順に説明していきます。 背景 メルカリには、商品・取引・ユーザーなどのクリティカルなビジネスデータを扱う中核データベースとして CoreDB と呼ばれるデータベースがあります。これは、メルカリのサービス開始当初から利用されていたモノリスアプリケーションのデータを格納してきたものです。下記の記事でもある通り、マイクロサービス化とともに、新規のドメインの独立したマイクロサービスに関しては、各々の独立したデータベースを持ち開発チームがデータベースを持つ運用を想定して、データベースも可能なものは分割してきました。しかし、現在でもなお多くのデータが CoreDB に格納されています。 https://www.publickey1.jp/blog/18/mercari_tech_conf_2018.html この CoreDB は、長らくオンプレミスサーバー上の MySQL で運用してきました。以前は石狩のデータセンターで稼働していましたが、多くのアプリケーションが Google Cloud の東京リージョンへ移行したことを受け、主にアプリケーションとの通信レイテンシを削減する目的で、東京のオンプレミスサーバー上の MySQL へ移行しました。 また、スケールアウト、つまり Read Replica を増やすことで、メルカリのトラフィックの大多数を占める読み取りトラフィックのスケールを実現しながら、同時にスケールアップも行い、運用に収まる現実的な台数を維持しながら運用を行っていました。 https://engineering.mercari.com/blog/entry/20220218-3c7faca4cc/ (Stateful なレガシー MySQL server の章) また、このスケールアップおよびスケールアウトとともに、必要なデータ保存量やトラフィックの増加に伴い、垂直シャーディングを繰り返してきました。すなわち、データの性質が異なり、結合クエリの発行が必要ない範囲に関しては、ソースおよびレプリカのセット、以後クラスタと呼びます、を分け、複数のクラスタで運用をしてきました。 垂直シャーディング( 他のブログ記事 より画像を引用) 今回、2026 年 4 月に全ての MySQL サーバーの書き込みトラフィックを TiDB に移行完了しました。それにあたり、当初何を解決したかったか、それがどのようになったかについて簡単に振り返りたいと思います。 移行にあたって、個別の事象としては、数々の解決してきた課題があり、これについては別のブログ記事で紹介します。 TiDB 移行で何を解決したかったか まずは、移行当初の目的について振り返ります。TiDB 移行により、主に次の 3 つの課題を解決しようと考えていました。 長期のスケーラビリティーの改善 MySQL は Write ノードが単一であるため、書き込み性能を上げるためには、基本的により高性能なサーバーへ置き換えるスケールアップが主な選択肢になります。読み取り性能は Read Replica を増やすことで伸ばしやすい一方、書き込み性能は同じようには水平に伸ばしにくく、大規模なサービスでは長期的な制約になりやすい領域です。 TiDBはMulti Writer, 実データを保存するTiKVもスケール メルカリではスケールアウトとスケールアップを繰り返してきた結果、クラウドなどへの移行を検討する際に、必要なスペックのサーバー、つまりインスタンスクラスがない、あるいは性能が不足する、といったことが発生してきました。また、オンプレミス環境でスケールアップの対応を行うには、非連続なコスト、特にハードウェア調達時に多額のキャッシュアウトが発生し、特異なスペックのサーバーを運用することのリスクなどを含め、限界を迎えつつありました。 トラフィックの増減に対する弾力的なリソース確保 トラフィック増への対応は、物理サーバーの調達、設置など含め、数ヶ月の時間がかかります。また、物理サーバーがある状態でも、スケールアウトを行おうとした場合に、トラフィックの増加に合わせて新規のサーバーをサービスで利用可能にするまでは時間がかかりました。 主に多量のデータを複製する必要があるところに時間がかかったのですが、 XtraBackup と呼ばれるオンラインバックアップ取得ツールで一貫性のあるバックアップを取得しながら、データを新規サーバーにストリームで転送し、その後リカバリ、そして遅延の解消といった工程が必要で、最終的に利用可能になるまで全作業で 2 日ほどかかりました。 オンプレミス運用からの脱却 自社のデータセンターで物理サーバーをホスティングしている以上、維持、運用にも一定のエンジニアリングが求められます。一方で、自社データセンターでは何千、何万台以上といった規模のサーバーを運用しているわけではないため、該当スキルを全面に押し出して積極採用するわけにもいきません。さらに、世の中全体としてクラウド化が進んできた現在、オンプレミス環境の運用に関する経験を有するエンジニアの採用自体が難しくなりつつあります。 また、現状の自社のサーバー運用規模においては、OS / MySQL のデプロイといったことからは解放された上で、性能問題などを解決し、高効率化したい要望がありました。 移行によりどうなったか 今回、TiDB への移行が完了し、それぞれどうなったかを振り返ります。 長期スケーラビリティーの改善 書き込み性能に関してもスケールアウトにて対応可能になったことで、書き込みキャパシティーが大幅に向上しました。 TiDB 移行とともに、大量の不要なデータを削除していたのですが、この際に削除を含めた書き込みのボトルネックが MySQL 側、つまり高いハードウェアスペックのサーバーにあり、TiDB 側は十分な余力がある状態でした。 弾力的なリソース確保 物理サーバーの調達の時間が必要なくなったのは当然ながら、物理サーバーでのリストアは 1 日を超える時間がかかっていたところ、1 日の中で負荷に合わせてリソースをスケールできるようになりました。 https://engineering.mercari.com/blog/entry/20260421-7b2dff6bce/ このスケールの速度の変化により、より効率的な、具体的には高いリソース利用率目標での運用が可能になりました。また、必要なリソース量に対して、細かい粒度でのリソース利用量の調整が可能になりました。 弾力的なリソース確保 オンプレミス運用からの脱却 必要があれば、オンプレミスの MySQL への依存をなくす目処がたち、採用の問題についての懸念事項解消へ大きく前進しました。 また、OS や MySQL のセットアップ、OS への Security Patch 適用、といった問題への対処からも解放されました。 移行全体の振り返り ここまで、当初の大きな目論見に対して、実際にどうだったかを振り返りました。 ここからは、移行全体でのプロセスとしてうまくいったこと、うまくいかなかったことの振り返りを行います。 うまくいったこと：移行のフロー全体 https://pingcap.co.jp/case-study/mercari-tidb-cloud/ TiDB User Day 2025 でも紹介した上記の切り替えに関する大雑把なフローは、手のかかるものでしたが、事前に多くの課題を抽出可能とし、かつ、仮に問題に直面した場合にも、MySQL に再度トラフィックを戻すことができるシステム構成を整えました。 このような、システムの更新・切り替えに問題があった際に元に戻せるようにすることは、変更の適用における基本事項の 1 つではありますが、愚直にやり切りました。これにより移行の是非の意思決定をスムーズに行うこともでき、移行全体を成功に導きました。 うまくいったこと：バッチエンドポイントの先行リリース データベースには複数のエンドポイントがあり、また、データベースは複数のマイクロサービスから利用されている状況でした。切り替えを段階的に行う方法は複数考えられ、例えば、マイクロサービス毎に読み取りを切り替えていく、などの方法も考えられました。 その中で、マイクロサービス毎の切り替えは行わず、アプリケーションとデータベースの間に ProxySQL とよばれる Proxy を配置し、Reader エンドポイントに対しては、徐々に TiDB にトラフィックをシフトしていくことにしました。 ProxySQL を活用した目的は、大きく 2 つありました。1 つは、多くのマイクロサービスに対して、接続先データベースの切り替えを透過的に行えるようにすることです。もう 1 つは、切り替え主体である DBRE（DataBase Reliability Engineering）チームがトラフィックの切り替えを一元的に管理し、問題発生時に迅速に対応できるようにすることです。 一方で、Reader エンドポイントの中でも、OLAP（Online Analytical Processing）に近いよりリスクの高いクエリを含むエンドポイント（バッチエンドポイントと呼ぶ）へのトラフィックを先行して切り替えることにし、複数の問題を事前に発見し対処することができました。 バッチエンドポイント切り替えは、その他の Reader エンドポイント切り替えの 5 日前に実施しました。その前に、前提となる MySQL から DM（Data Migration）を通じた TiDB へのデータ同期の遅延の問題を先に解消したり、万が一一定の遅延が発生した際に、TiDB から自動的に MySQL に参照先が戻るような実装を行いました。 https://docs.pingcap.com/tidb/stable/dm-overview/ うまくいかなかったこと：クエリリプレイの限界 TiDB クラスタの移行は、大体トラフィックの少ない順に移行を行い、多くのクラスタは予定通りに進行したものの、一番最後に残った最大のトラフィックをかかえるクラスタで、複数回の予定延伸が発生しました。 移行のフローに記載していないこととして、クエリリプレイを行った上で、一定期間、読み取りの実トラフィックを TiDB に流す、という予行演習・テストを複数回実施しました。 実トラフィックを流すことによるテストは、もちろん一定のリスクがありますが、最終的に全てのトラフィックを TiDB で処理しようとしている、ということから、切替えの必要条件として少なくとも一定時間、実際のトラフィックを切り替え後の構成で処理できている必要があります。 最後の最大のトラフィック流量を持つクラスタでは、永続運用を目指す本番の切り替え前に、9 回実トラフィックを一時的に試験的に実際のサービスに切り替えました。日中のトラフィックがあまり変わらない時間帯で短時間テストを行い、最終的にはピークタイムで問題なく処理できることの確認を行なっています。 この 9 回の中には最終的な本番切り替え成功に導くための、多くの失敗、つまり学びが含まれていました。負荷を増やすと明らかになった不具合事象の発見もあれば、象徴的な事象として、100% の負荷を流したところ、必要なノード数が多くなった結果、TiDB Cloud の監視サーバーが想定していない負荷となり、メトリックが何も見えなくなった、といったことも発生しました。 最終的な動作確認は、実トラフィックで必要なものの、例えば、上記であげたハイトラフィックの状態で監視が正常通り稼働するかなど、できるだけ多くの観点を実際のトラフィックに影響を与えずに確認できるのが望ましいです。実トラフィックの 100% を移行先の環境にミラーして比較ができることが理想的です。 これに対して、メルカリではリプレイツールなどを利用してそれに対応していたものの、一定以上のトラフィック量だと、リプレイによる「取りこぼし」がありました。実際のユーザートラフィックに影響を与えず、できるだけ取りこぼさず本番に近い負荷をかけることが目標で、これに対して独自ツールは当初、最大トラフィックの 50% 程度のリプレイが実現できていました。様々なボトルネックの解析などを経て、最終的にはメルカリの負荷の 80% 程度はリプレイ可能になりました。 しかし、この 80% 以上はリプレイでは負荷再現ができず、ピークトラフィックとのギャップを埋めた上で検証を行うため、実トラフィックによる試験を行いました。この 20% の負荷の差分に対しても、いくつかの問題へ直面するポイントがありました。 うまくいかなかったこと：コスト見積もり 規模の小さいクラスタは予想通りのコストに概ね収まっていましたが、大きなクラスタになるにつれ、予想していたコストとの乖離が大きくなり、予想コスト超過になりました。 予想コストとの乖離の最も支配的な要因は、自社のトラフィックを模擬したベンチマークにおいて、実トラフィックのうち最も負荷割合の高い、複数の行の同時取得の SELECT ... FROM xxx WHERE id IN (...) という SQL に対するベンチマークシナリオの再現度が低かったため、と推測しています。 この問題が発生した経緯としては、ベンチマークデータに対して、大量の IN 句の要素を妥当な数用意するところに一定の難しさがありました。id は、かなりの数を用意しないと、短期間で id の候補がなくなってしまう一方で、id の払い出しが性能ネックになったりベンチマークに影響を与えても困ります。実装上の都合からこれを簡易化した結果、ベンチマークにおいて、負荷の期待値を実際よりも低く見積もる結果となりました。 一方で分散データベースにおいては、データが複数ノードに分散している状態での取得の再現度は極めて重要であり、これに失敗した結果、実際に多くのコンピュートリソースが必要となりました。 移行後に得られた想定以上の効果 全ての DDL（Data Definition Language）に対する運用上の負荷が大きく下がりました。 以前はオンラインスキーマ変更のツールである gh-ost を利用しており、概ね変更の安定性については満足していたものの、次のような問題がありました。 一部のケースでは gh-ost が使えない 大規模なテーブルの変更は時間がかかる、数週間かかることもある TiDB では、DDL がオンラインで行われることはもちろん、分散データベースにおける分散実行、DXF（TiDB Distributed eXecution Framework）がとても効いており、基本的には全ての DDL が、MySQL に比べて非常に短期間で完了します。具体的には、数週間かかるものが数時間になる、などのケースがいくつか観測されました。 https://docs.pingcap.com/tidb/stable/tidb-distributed-execution-framework/ このように、DDL に対する運用負荷が下がった結果、一部の非常に大規模なテーブルについては、そのテーブルに関わる設計変更を検討した際に、大規模テーブルの定義の変更を見送るような設計をしがちだったのに対し、どちらのテーブル定義であるべきか、というあるべき論に基づき変更が検討しやすくなりました。 この変化により、テーブル設計の修正を含む最適化などがとてもしやすくなりました。 なお、下記の記事のように、稀なケースで TiDB で DDL にとても時間がかかるケースも観測しましたが、最新のバージョンでは改善されております。 https://engineering.mercari.com/blog/entry/20260304-b782487108/ 現在の課題 ここまでで、移行のプロセスでうまくいった点、うまくいかなかった点、移行後に思ったより良かったことについて振り返りました。 最後に、TiDB の移行完了後に対応した、あるいは現在対応している課題についてお知らせします。 分散データベースへの適応 TiDB 切り替え後に、TiDB が分散データベースであることに関連するいくつかの問題への対処を行いました。こちらも追加のブログ記事の公開を予定しております。 コストの問題・安定性の向上 現在のところ、TiDB は全体として非常に安定して稼働しております。 しかし、コスト見積もりが当初予測より上振れたことから、コストの最適化を積極的に行なっております。コストの最適化は、安定性と相反するところであり、最適化を行うことで明らかになる質的な問題を 1 つずつ解消していっております。 ストックアウト問題への対応 クラウドへの移行により、基本的には弾力的なリソース確保ができるようになった一方で、近日のクラウドリソース需要の高まりにより時折発生している、ストック不足のリスクにどのように対応するか、といった検討・検証をしています。 バージョンアップへの対応 TiDB は機能追加や改善の速度が非常に速く、かつ、バージョンアップもオンラインで可能です。 そのため、バージョンアップに迅速に追従し、バージョンアップの恩恵を受けることは TiDB を運用する上では重要です。 一方で、TiDB Cloud では、現状、ダウングレードへのサポートがないため、万が一問題に直面した際に、元のバージョンへ戻せるような仕組みでバージョンアップを行う必要があります。このための手順を確立したり、バージョンアップに対する検証を簡易化するためのツールを開発しています。 TiDB への移行によって多くの課題は解消されましたが、移行完了はゴールではなく、新しい運用フェーズの始まりでもあります。分散データベースやクラウド環境を前提とした運用に適応しながら、コスト、安定性、バージョンアップ対応などを継続的に改善していく必要があります。 まとめ この記事では、メルカリの中核データベースである CoreDB を MySQL から TiDB へ移行した取り組みを振り返りました。TiDB への移行により、当初の目的であった長期的なスケーラビリティの改善、トラフィックの増減に対する弾力的なリソース確保、そしてクラウド化による運用負荷の軽減について、大きな前進がありました。 移行プロセスでは、事前に設計した移行フローが有効に機能し、ProxySQL を活用したトラフィック切り替えの一元管理や、リスクの高いエンドポイントの先行切り替えによって、問題を段階的に発見・解消できました。一方で、実トラフィックを用いた予行演習では多くの学びがあり、トラフィックリプレイの再現性やコスト見積もりには課題も残りました。 移行後には、DDL の運用負荷が想定以上に下がるなど、TiDB の利点も見えてきました。同時に、分散データベースやクラウド環境を前提とした運用では、コスト、安定性、リソース確保、バージョンアップ対応など、継続的に向き合うべきテーマもあります。今回の移行で得た学びを活かしながら、今後も CoreDB の運用をより安定的で持続可能なものに改善していきます。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM（Engineering Manager）および IC（individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは以下をご覧ください。 EM: https://apply.workable.com/mercari/j/7AD4EF9218/ IC: https://apply.workable.com/mercari/j/ACD2689E9E/

こんにちは。メルペイ Director の @abcdefuji です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の 20日目の記事です。 はじめに 私たちは、決済プラットフォームチームに Slack メンションで起動し Google Compute Engine（GCE） 上に常駐する AI エージェント pcp-agent を作り、本番運用しています。狙いは「人間が AI をキックする」ツールではなく、トリガーベースで自律実行する Ambient Agent を作ることでした。 本記事では、この取り組みで本当に難しかった2点、決済ドメインで自律エージェントを安全に動かすセキュリティと、その効果を計測する仕組みについて実コードと図で解説します。さらに、これが単一のbotではなく、SREやn8nなど複数ドメインへ展開する再利用可能なエージェント基盤（remote-claude）であることも紹介します。 背景：なぜ「常駐エージェント」なのか PCP（Payment & Customer Platform）は数十のマイクロサービスを抱え、社内の大量のユースケースを支えています。障害調査、アラートのトリアージ、システム間の金額検証、問い合わせ対応。これらはいずれも「決まった手順だが人手を食う」作業です。私たちはこうした運用を AI に肩代わりさせたいと考えました。 掲げたビジョンはシンプルです。AI があらゆるオペレーションをトリガーベースで自律実行し、人間のアクションを必要としない Platform 体制を構築する、というものです。「人間が AI をキックする」世界観は前提から外しました。 だからこそ私たちは、チャット UI に個人が質問を投げるツールではなく、チームに常駐し、トリガーで自律的に動く Ambient Agent として pcp-agent を位置づけました。人で言えば「決済プラットフォームチームに運用担当が常駐している」イメージです。 全体アーキテクチャ pcp-agent は Slack 統合型の Claude Code bot で、隔離された Docker コンテナ内で動きます。セッションごとに copy-on-write ファイルシステムで独立したコンテナが立ち上がり、影響範囲をセッション単位に閉じ込めます。共通インフラ（server / scheduler / auth-proxy）が Slack メンションやスケジューラーからの起動を受け、コンテナを起動します。 エージェントの権限管理関しては、決定的な層を導入しています。書き込み可能なリポジトリは、社内の集中管理された ACL と、そこから発行される scope を絞った短命の GitHub token によって リポジトリ単位で機械的に制限しています。それ以外はすべて read-only（調査・参照用）です。CLAUDE.md には writable repo を明示してエージェントの振る舞いを誘導しますが、強制するのは上記の決定的な層です。リスクが高い領域への書き込みはエージェントに許さない、という境界をまず引きました。 仕組み：Claude Code を核に remote-claude で包む 中身を一段掘り下げます。pcp-agent の心臓部は Claude Code そのものです。私たちは Claude Code を「コマンドラインで動くエージェントランタイム」として使い、その周りを remote-claude という薄いラッパーで包んでいます。remote-claude は Slack やスケジューラーからのトリガーを受け取り、セッションごとに Docker コンテナを立て、その中で Claude Code を起動し、標準出力を Slack に橋渡しする役割を担います。 Claude Code は単体では汎用のコーディングエージェントです。これを「決済プラットフォームドメインの運用担当」に仕立てているのは、ワークスペースに置いた .claude ディレクトリの中身です。ここには振る舞いを決める CLAUDE.md、ドメイン知識と手順をコード化した Skill / Plugin、そして実行のたびに介入する Hook が含まれます。能力を増やしたいときはモデルを差し替えるのではなく、スキルやルールを足す、つまり「プロンプトとファイル」で拡張するのが設計の基本方針です。 一回の実行（セッション）の流れはこうです。トリガーが来ると remote-claude が新しいコンテナを copy-on-write で起こし、その中の Claude Code が Slack メッセージやスケジュールされたプロンプトを入力として受け取ります。エージェントがツールを呼ぶたびに、まず PreToolUse hook がセキュリティ検査をかけて危険なら止め、ツール実行後に PostToolUse hook が 開発者体験の計測プラットフォームであるDX へ利用イベントを送ります。同じセッション（Slack スレッド）への追加リクエストは、起動中の Claude Code プロセスを再利用するため高速で、コールドスタート約30秒に対してウォームは約2〜3秒です。セッションはアイドルが約30分続くとクライアントを切断し、約1週間（session_ttl）で破棄します。各セッションは copy-on-write で独立した workspace を持つので、影響範囲をセッション単位に閉じ込めつつ再現性を確保できます。 設計上の要点は「LLM を信用しすぎない」ことです。エージェントの判断（自然言語）は本質的に非決定的なので、安全性や監査が要る部分は決定的な Hook、ネットワークレベルの auth-proxy、コンテナ隔離、IaC 管理のシークレットなど、LLMの外側に寄せています。LLM には「何をやりたいか」を任せ、「やってよいか」「どう繋ぐか」はコードと基盤で固める、という責務分離です。 認証設計：auth-proxy でクレデンシャル注入を一点集中 エージェントは Notion / Jira / DX / PagerDuty / Datadog / Slack など多数の外部 API を横断します。認証方式はサービスごとにバラバラで、これを LLM に直接持たせるのは危険です。そこで私たちは auth-proxy をネットワークレベル（iptables DNAT）に置き、宛先ごとに適切な認証情報を自動注入する構成にしました。注入するヘッダや取得方法はサービスごとに異なり（環境変数、keyless な GitHub トークン、GCP サービスアカウントのインパーソネーションなど）、その差異を auth-proxy が吸収します。エージェント側の curl はトークンを一切知りません。 この設計のもう一つの利点は、シークレットをエージェントのコードから完全に分離できることです。実トークンはすべて IaC（microservices-terraform）で管理し、auth-proxy 側にだけ環境変数として渡します。ランナー（エージェント実行コンテナ）に埋め込まれるのは非機能のダミー値だけで、万が一漏れても無効です。エージェントのワークスペースにクレデンシャルは存在しません。 セキュリティ：決済ドメインで自律エージェントを動かすための多層防御 決済ドメインで本番権限を持つ自律エージェントは、最高レベルの安全要求を満たす必要があります。pcp-agent はdeny rules、PreToolUse hook、behavioral rules、auth-proxy、コンテナ隔離の5層で防御しています。重要なのは、単一の層に依存しないことです。どれか一つが破られても、別の層が止める設計にしています。 主防御線に据えたのは PreToolUse hook です。個々のツールごとの許可・拒否設定に頬り切るのではなく、どのツール経由でも危険な操作を止められる決定的なフックを最終的な強制層に置く方が確実だと考えたからです。後述するように、このフックは想定外の終了コードで落ちた場合に「黙って許可」ではなく「ブロック」を返す fail-closed 設計にしてあります。フックがクラッシュした隙にコマンドが通る事故を防ぐためです。 シークレットファイルの検出には現実的な難しさがあります。jq のフィールドアクセスをしてissue key を取得するような正当な操作と、秘密ファイルの読み取りを区別しなければなりません。私たちのパターンはファイルパスとして現れる鍵ファイルのみを止め、クエリ構文は通すよう練られています。 この手の防御は「イタチごっこ」です。セキュリティレビューを重ねるたびに想定外の抜け道が見つかり、その都度検出パターンを強化してきました。正当な操作は通しつつ、秘密情報の読み取りだけを確実に止める。その考え方を、次の小節でコード例とともに示します。 設計判断（ADR）も明文化しています。たとえば WebSearch と WebFetch はドメイン許可リストの対象外としました。許可リストは「LLM が Bash コマンドで URL をハルシネートする」ことを防ぐためのもので、Web 閲覧（読み取り）とは脅威モデルが異なるからです。ただし取得 URL は秘密パターンをスキャンし、クエリ経由のデータ漏洩を防いでいます。また Codex MCP は本エージェントでは有効化していません。Codex は独自のシェル実行エンジンを持ち Claude Code の deny rule を迂回するため、human-in-the-loop のない Slack bot では受け入れ不可と判断し、フックでブロックしています。 PreToolUse hook：fail-closed の安全網 #!/usr/bin/env bash # PreToolUse security hook — deterministic enforcement layer # Exit codes: 0 = allow, 2 = block set -euo pipefail # 0=allow / 2=block 以外で落ちたら block を返す（クラッシュ時に許可しない） trap 'ec=$?; if [[ $ec -ne 0 && $ec -ne 2 ]]; then echo "{ decision: block, reason: hook failed (exit $ec) — blocking for safety }" exit 2 fi' EXIT 注：上記の echo は可読性のため簡略表記にしています。実装では decision / reason を含む JSON を出力します。 シークレットファイル検出のパターン 正当な jq フィールドアクセスは通しつつ、鍵ファイルの読み取りだけを止めます（一部のパスは可読性のため簡略表記）。 secret_file_patterns=( '.env(boundary)' '.env.' '<pathchar>.pem(boundary)' '<pathchar>.key(boundary)' 'credentials.*.json' '/proc/<pid>/environ' ) # .env.example / process.env.X / jq の .fields.parent.key は許可（ファイル読みではない） ポイントは boundary（境界）と pathchar（パス文字）の条件で「ファイルパスとして現れる鍵ファイル」だけを対象にし、 { key: .key } のようなオブジェクトアクセスを誤検知しないことです。 計測：PostToolUse hook × DX で効果を測る 「導入したが効果は？」に答えられなければ本番運用は続きません。私たちは、エージェントのツール実行を PostToolUse hook で捕捉し、DX にイベント送信しています。これにより「どのスキルやツールが、誰に、どれだけ使われたか」を継続的に計測できます。 設計には三つのポイントがあります。第一に fail-open です。計測はエージェントの動作を妨げてはいけないので、どんなエラーでも黙って正常終了します。セキュリティの PreToolUse が fail-closed なのとちょうど対照的で、層ごとに設計思想を逆にしているのが要点です。第二にセッション内重複排除で、同じイベント型は1セッションに1回だけ送ります。第三にメール解決で、Slack コンテキストからユーザーを特定し、bot やスケジュール実行ではフォールバックの共通アドレスに振り替えます。 興味深いのは、送信するだけでなくエージェント自身が DX のメトリクスを読むことです。チームスコアは MCP 経由で直接クエリし、Core4（Effectiveness / Impact / Quality / Speed）や sentiment を参照します。これにより、エージェントが自分の置かれたチームの開発者体験データを踏まえて振る舞える素地ができます。なお、コメント API は個人のメールを含むため、リポジトリに保存せず Slack にも出さず、必要時にオンデマンドで取得して 1on1 準備などの参照にのみ使う、という PII 取り扱いを徹底しています。 フロー：PostToolUse hook の処理 これによりダッシュボード側でスキル別・ツール別の利用状況を集計できます。 エージェントに「記憶」を持たせる：ナレッジの自動メンテナンス ドメイン知識は Slack と Notion に散在し、放置すればエージェントは古い情報で答えてしまいます。私たちはこれをスケジュールジョブで継続的に更新しています。日次のチャンネルナレッジ抽出ジョブ（対象チャンネルの整備後に本格有効化予定）は、前日の人間同士の会話を読み、ドメインに関わる知識をスキルやナレッジとして抽出・提案します。 さらに、エージェントが対応した Slack スレッドを見直して有用な知識を登録し、既存エントリの更新・削除を整理する LangMem ベースの自動メンテナンスも回しています。RAG で都度検索するだけでなく、記憶そのものを継続的に手入れする発想です。 加えて「AI が読みやすいドキュメント構造」への投資も行いました。リポジトリ一覧や監視チャンネル一覧を機械可読な形で同期し、エージェントが参照しやすくしています。PCPにはリポジトリだけで約50個ほどあるのでこのような情報を整理することがスタートでした。知識の鮮度・ノイズ・ハルシネーションは依然として課題ですが、人手の更新に頼らない仕組みを基盤として持てたことが大きな前進でした。 自律スケジューラー：何が毎日・毎週動いているか pcp-agent は Slack メンションでの起動だけでなく、cron ベースのスケジューラーで自律的にも動きます。これが「トリガーベースで人間のアクションを必要としない」というビジョンの実装そのものです。週次のダッシュボード要約やアラートダイジェストは、誰かが依頼しなくても毎週決まった時刻に投稿されます。 ジョブ定義は宣言的な YAML で、タイムゾーン・タイムアウト（active_deadline_seconds）・リトライ（backoff_limit）・多重起動抑止（concurrency_policy: forbid）・出力先 Slack チャンネルを指定できます。中心は「PCP Daily Schedule」で、平日毎朝9時(JST)に４つのルーティンを順番に実行し、各完了後に中間結果を Slack に投稿、最後に「本日のまとめ」を出します。当初は別々のジョブだったものを、一つの統合ワークフローに集約しました。このループを回すこと自体で、日々の会話からナレッジが溜まり、スキルも更新されていく、そうした自己更新的なループとして設計しています。 スケジュール例: ジョブ スケジュール 内容 pcp-daily-schedule 平日 9:00 ４タスク統合：①リリースノート生成 ②対象リポジトリ追跡（新スキル取込提案）③既存スキル改善提案 ④LangMem ナレッジ前日分メンテ xxxx-weekly-dashboard-summary 毎週月 10:30 各チームダッシュボードの週次サマリ yyyy-weekly-alert-digest 毎週月 11:00 各チームアラートの週次ダイジェスト - name: xxxx-weekly-alert-digest enabled: true cron: "0 11 * * 1" # Every Monday 11:00 (JST) prompt_file: "config/prompts/xxxx-weekly-alert-digest.md" timezone: "Asia/Tokyo" active_deadline_seconds: 600 # 10分でタイムアウト backoff_limit: 1 # 失敗時に1回リトライ concurrency_policy: forbid # 前回実行中ならスキップ ポイントは、スケジューラーが単なる cron 以上であることです。タイムアウト、リトライ、多重起動抑止といったジョブ制御を持たせることで、自律実行を本番で安全に回せるようにしています。 実際のユースケース pcp-agent の能力はスキルとしてファイル化され、実運用で次のようなユースケースに使われています。いずれも「決まった手順だが人手を食う」調査・集計・トリアージ作業です。 ユースケース スキル 内容 障害・アラート調査 investigate-alert アラートを起点に関連ログ・メトリクスをたどり一次切り分け 日次トリアージ xxxx-daily-triage XXXXチームの毎日の異常検知とトリアージ 問い合わせ調査 investigate-inquiry 問い合わせをドメイン知識付きで調査 週次サマリ yyyy-weekly-alert-digest 各チームのアラート・ダッシュボードの週次要約 PR監視・Issue起票 watch-pr / issue / jira レビュー補助と起票 この中でも最初のわかりやすいユースケースは調査のユースケースでした。 参考例として、Alert（トリガー） → Datadog（データ集約） → Slack / Notion等 (データ可視化・レポート) という流れです。すでに多くのエンジニアのローカル環境にはデータ調査スキルが存在すると思います。そのスキルをリモートに持ってきてトリガーさせるだけで一定の時間削減が実現でき、そしてローカルに存在するスキル（属人性）をリモートに持ってくることで誰でも同じ体験を実現することができます。 そして、これらのユースケースが「実際にどれだけ使われているか」を DX で可視化しています。どのユースケース（スキル）が、どのチームで、どれくらい使われたかをダッシュボードで追跡できます。エージェントの価値を「何ができるか（能力）」ではなく「何に使われているか（採用）」で測るのが狙いです。 プラットフォームとしての強み：1つのbotではなく、エージェント基盤 ここまで pcp-agent という1つのエージェントを見てきましたが、本当の狙いは個別のbotを作ることではありません。私たちが作ったのは remote-claude という再利用可能なプラットフォームで、pcp-agent はその上で動く1テナントにすぎません。同じ基盤の上に、SRE 向けの remote-claude-sre、ワークフロー自動化(n8n)向けの remote-claude-n8n が並んで動いており、data platform 領域へも展開しています。 プラットフォームと各エージェントの責務は明確に分かれています。共有基盤(remote-claude)が提供するのは、Slack統合、セッション隔離(copy-on-write)、cronスケジューラー、auth-proxy、PreToolUse/PostToolUseフックの仕組み、PIIリダクション、ランナーのリソース制限(メモリ・PID・CPU)といった「どのエージェントにも共通して必要な土台」です。各テナントが持つのは、自分のドメインに固有の workspace/.claude、つまりCLAUDE.md、スキル、ルールだけです。 この設計の効きどころは、新しいエージェントを立ち上げるコストの小ささです。共有設定は base.yaml に集約され、各エージェントは差分だけを上書きします。テンプレート(remote-claude/template)をコピーし、ドメイン知識をスキルとして足せば、Slack起動・隔離・スケジューラー・セキュリティ・計測がすべて最初から揃った状態で新しいテナントが立ち上がります。「決済の常駐エージェント」で作った仕組みが、そのまま他のチームにも転用できるわけです。 # remote-claude/config/base.yaml （全エージェント共通、各エージェントが上書き） default_model: sonnet use_proxy_network: true # ランナーに権限を与えずオーバーレイで経路制御 session_policy: session_ttl_minutes: 10080 # 7 days runner_memory_limit: "4g" runner_pids_limit: 256 runner_idle_timeout_minutes: 30 slack_output_redaction: false # PIIリダクションをデプロイ単位でONにできる セキュリティや計測のような「外側で固める」部分をプラットフォーム側に持たせることで、各チームはドメイン知識の記述に集中でき、かつ全社的に一貫した安全性・可観測性を担保できます。これがエージェントを「点」ではなく「基盤」として広げる強みです。ちなみに remote-claude はもともと SRE 向け（cc-sre）に生まれ、そこから複数ドメインをホストする汎用プラットフォームへと一般化されていきました。 まとめ 半年運用して、いくつか確かな手応えがありました。まずスキル化は効きます。ドメイン知識を SKILL.md としてコード管理すると、エージェントの振る舞いが再現可能になり、レビューやテストの対象にできます。エージェント自身に新しいスキルを作らせるループも回り始めました。 もっとも、正直なところ最大の課題はユースケースの深掘りだと感じています。問い合わせのための調査のように、各所のパーツは AI に代替できる部分が出てきましたが、まだ人間がトリガーしている場面が多く、真に AI を軸に置いたフローになっているとは言えません。エージェントが受け取れるトリガーをさらに増やし、ユースケース全体を「AI 前提」のプロセスへ置き換えていきたいと考えています。 今後は、このエージェントを一つに統合するか、ドメインごとに分散させるかをユースケース次第で見極めていきます。LLM のコンテキストは有限なので、独自のワークフローが必要なユースケースが増えれば分散させる方針です。 加えて、社内でこうしたエージェントが増えていくほど、個々の精度以上に「フリート全体をどう統治し、どう観測するか」が重要になります。エージェントごとに権限・ポリシー・監査がバラバラだと、事故も非効率も増えていきます。そこで、ガバナンスと各エージェントの振る舞い・コスト・利用状況などを横断的に把握する仕組みを、今後プラットフォーム側で整えていきたいと考えています。 「AI エージェントを作ってみた」記事は数多くありますが、決済ドメインの本番チームに常駐させ、セキュリティを多層で固め、効果を計測しながら回すところまでやると、考えるべきことは一気に増えます。私たちが半年で取り組んだのは、その「面倒な部分」を実コードで埋めてきた記録です。そして、その面倒な部分を共有基盤（remote-claude）に寄せたことで、決済で作った仕組みを SRE や n8n へ横展開できる「エージェント基盤」に育ちつつあります。これから業務にエージェントを組み込む方にとって、安全性と計測をプラットフォーム側でどう設計するかの一例になれば幸いです。

こんにちは becosuke です。メルカリ NFT と、その上で立ち上げている新規サービスの Backend を担当しています。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の 20日目の記事です。 この記事では、私たちメルカリ NFT チームがこの4ヶ月ほどで取り組んできた AI-Native な開発について書きます。1月末から、開発のやり方そのものを大きく作り変えてきていて、最終的には人の手をできるだけ介さずにサービスを作り続けられる状態を目指しています。その過程で得た学びを、似たことに取り組もうとしている方に持ち帰ってもらえたらと思っています。 先に結論だけ書いておきます。私たちがリソースを集中させるべきだと判断したのは「正解」そのものではなく、何が正しく何が誤りかの「判断基準」( 注1 )でした。AI を動かすための機構は、これからどんどん外から手に入るようになります。けれど判断基準だけは、その案件ならではの価値観そのものなので、外注できません。だから私たちは、機構を作ることよりも、その上に載せる判断基準を残すことに時間をかけました。なぜそう考えたのか、そして実際に何をやったのかを、順を追って書いていきます。 この案件の位置付け 私たちは、Non-Fungible Token（NFT）の売買を行うマーケットプレイスである メルカリ NFT を既存サービスとして運営しています。いま新しく立ち上げているのは、この既存の メルカリ NFT のコードベースを土台にした新規サービスです。 この案件には、2つの顔があります。1つは、新しいプロダクトの立ち上げであること。もうひとつは、AI-Native な開発のあり方そのものを試す Proof of Concept（PoC）の場であることです。 メルカリには会社全体として AI-Native 化を進める方針があり、社内基盤もすでにしっかり整っています。その方向性には私たちも強く共感しているのですが、今回はあえて一度そこを離れて、前提から組み直すとどうなるかを試してみることにしました。理由は3つあります。 1つ目は、AI に spec から開発を駆動させるには、その spec を解釈するための価値基準や判断の根拠が前提として必要だと考えたからです。これがいちばん大きな理由でした。社内基盤の上に乗ったとしても、AI が「何を基準に判断すべきか」を持たないうちは自走できません。基盤の良し悪しの問題ではなく、その手前で価値基準と過去の判断の根拠を溜める前工程が、私たちにはまだ必要だったということです。だからまずはそこを溜め込む段階を踏んでから、成熟した先で既存の仕組みに接続する、という順序を選びました。 2つ目は、既存の正解の上に乗ると、その枠内での最適化しかできないからです。この案件は新しいプロダクトの立ち上げであると同時に AI-Native 開発の PoC でもあるので、いったん既成の枠を外して前提から組み直すことに意味があります。AI-Native として本当は何が必要なのかを検証したかったので、別のアプローチで組み立て直すことで見えてくるものを優先しました。社内基盤を使うプロジェクトと、別解を試すプロジェクトが並走すれば、会社全体として AI-Native 開発の幅も広がります。 3つ目は、Claude Code 本体の進化に身軽についていきたかったからです。Claude Code には plugin や Agent Teams のような、開発の組み立て方そのものに関わる機能追加が数ヶ月単位で入っていて、AI に開発をさせる足場の作り方が次々に変わっていきます。こうした新機能をすぐ取り込めるよう、 CLAUDE.md と rules、skill、hooks だけの軽い構成で試したかったという事情もあります。標準機能だけで素朴に組むことで、何が効果を生んでいるのかの切り分けもしやすくなります。 念のため書いておくと、この独自路線は社内基盤と対立するものではありません。あくまで今の段階での選択であって、蓄積が成熟したら、社内基盤の考え方を取り込んだり、逆にこの案件で得たやり方を社内のほかの案件でも使えるようにしたり、という双方向の合流を視野に入れています。 この記事でいちばん伝えたいこと：機構は外から、判断基準は自前で 具体例に入る前に、この記事を貫く中心の考え方から書きます。 AI agent は、モデルと、その周りを取り囲む機構（ハーネス）でできていると言われています（Agent = Model + Harness）。このモデルを取り囲む環境・制約・フィードバックを設計する規律は、2026年2月に Mitchell Hashimoto 氏がブログ( 注2 )で "engineer the harness" と名付けて以降、ハーネスエンジニアリングと呼ばれて急速に広まりました。prompt engineering から context engineering、そして harness engineering へ、という発展の系譜です。 ハーネスにはさらに、モデル提供元が出荷する内側ハーネス（Agent SDK など）と、その上に私たちが組み立てる外側ハーネスがあります。Thoughtworks の Birgitta Böckeler は、外側ハーネスを agent の前に指針や制約を渡す Guide / Guardrail（feed-forward）と、agent の出力を観測してフィードバックを返す Sensor（feedback）に分けたうえで、ハーネスの議論は禁止やガードレールの側に偏りがちで、観測の側はむしろ手薄になりやすいと指摘しています。 ハーネスには大きく3つの役割があります。 正解を示す こと 結果を観測する こと 危ない操作を止める こと このどれもが、AI に安心して任せるために欠かせません。私たちはこの偏りに違和感を持ち、3つの役割を等しく支える機構がどこにあるのかを考えました。 ここで私たちが立てた仮説はこうです。この3つを支える機構は、これからプラットフォーム側が整えてくれる。評価ループ、hooks、権限のプロンプト、サンドボックスといった機構は、汎用部品として外から提供される方向に向かっている。実際、危ない操作を事前に止める hooks や権限のプロンプトは Claude Code 本体に組み込まれていて、自前で実装するものから既製品として使うものへと、徐々に移ってきています。だとすれば、その機構づくりは私たちのチームでは「できるだけやらない部分」として切り分けてよい、と考えました。 一方で、3つの役割すべてに共通して必要になるものがあります。何を正解とし、どこからを合格とし、何を危険とするか、それぞれの判断基準です。これは、この案件ならではの価値観そのものなので、外からは提供されません。観測エンジンや停止機構は買えても、その基準は各案件固有の判断の産物で、外注できない。整理すると、三本柱のすべてについて「機構は買える／判断は自前」という構図になります。 機構 判断基準 正解を示す context を供給する足場 何を正解とするか 結果を観測する 評価ループ・eval 基盤 どこからを合格とするか 危険を止める hooks・権限・サンドボックス 何を危険とするか 出どころ プラットフォームが提供（買える） 案件固有（自前で持つしかない） なぜ「判断基準」を集めるのか 個別の正解を一つひとつ集めていくより、判断基準を与えるほうが、応用が効きます。1つの正解は点にすぎませんが、判断基準はその点を生み出す規則です。だから、まだ出会っていない状況に遭遇しても、基準さえあれば AI は自ら考えることができます。 例えばデータの書き換えについて、私たちは「InsertOrUpdate（UPSERT）は使わず、Read で存在を確かめてから INSERT か UPDATE に分岐する」という方針を残しています。UPSERT は全カラムを指定しないと意図しないリセットが起きるためです。この1つの方針が、AI が新しい書き込み処理を書くときの指針にもなり、reviewer が UPSERT の紛れ込みを一次チェックする観点にもなります。Anthropic の言葉を借りれば( 注3 )、正解を示すというのは「モデルの望ましい挙動を最も生みやすいコンテキストを与えること」で、観測するときの基準もそこから派生します。同じ判断基準が、正解を示す側にも、結果を観測する側にも、両方の基盤になっているわけです。 機構と判断基準には、もうひとつ大事な違いがあります。「寿命」が違うということです。Anthropic 自身も、ハーネスの各構成要素は「いまのモデルにこれができない」という前提のうえに置かれているので、その前提は stress test して、要らなくなったら外していく対象だと述べています。( 注4 )実際、ある世代のモデルで必要だった構成要素が、次の世代では不要になったり、別の組合せに置き換わったりしていく例も出てきています。もちろん、test のようにモデルがどれだけ進化しても外せない観測の機構もあるので、すべての機構が一律に失効していくわけではありません。それでも、機構の側には入れ替わりがある一方で、目標と正しい判断基準を与える側は廃れずに残ります。だからこそ判断基準は、特定のツールの設定ファイルに埋め込むのではなく、自分たちのリポジトリに、可搬な形で持っておくべきだと考えました。 ここからは、この考え方を実際の開発でどう形にしたのか、4つの具体例と、それによる変化、それらを社内のほかの案件で共有する方法について書いていきます。どの取り組みも、機構を作り込むことよりも、その上流にある判断基準を残すことに重点を置いた話として読んでもらえると、つながりが見えてくると思います。 1. コードの一貫性：言葉の意味や正しいやり方を1つに固定する 1つ目は、コードの一貫性です。 既存のコードベースを途中から AI-Native に切り替えるために、最初にやったことは大量のリファクタリングでした。人間ならあまり気にしないようなちょっとした言葉のゆれが、AI の判断を狂わせてしまうので、意味を1つに揃えておく必要があります。同じ概念が場所によって違う名前で呼ばれていたり、書き方が場所ごとに違ったりすると、AI はそのたびに周辺から「この案件ではどう書いているか」を推測することになり、出力がぶれます。 そこで、二段階で揃えました。 まず、同じ言葉が複数の意味を指している状態や、その逆をなくして、「1つの概念には1つの名前、1つの名前には1つの意味」というところまで徹底しました。命名は AI がコードベースの全体像を掴むときに最初に頼る手がかりなので、ここがぶれていると、その先のどんな指示や設計書を渡しても精度が落ちてしまいます( 注5 )。 次に、正しいやり方が何通りもあるものについて、どれでやるかを決めてルールとして書き残しました。例えばエラーの扱い、ページネーションの実装、enum の持ち方のように、「正解は複数あるが、案件としてはこの形に揃える」というものをルール化しておく。こうしておくと、今後同じような課題にぶつかったとき、AI は解決の方法を迷わず選べます。前の章で書いた「1つの正解（点）」ではなく「判断基準（規則）」を残す、というのを地でいく作業でした。 この期間、構造を整えながら、差し引きで万単位の行数のコードを減らしました。機能を削ったのではなく、重複や不要な抽象を整理して、同じことをより少ないコードで表すようにした結果です。AI が読まされる量が減り、1つの概念にあたる場所が一箇所に集まることで、AI に渡す文脈はノイズの少ないものになります。コードベースを整えること、それ自体が、AI のための環境整備の土台になる作業だったと考えています。 2. 判断を残す仕組み：spec / design と RDR / ADR 2つ目は、判断を残す仕組みです。 私たちは、仕様書（spec）には「いまどうなっているか」だけを書いて、「なぜそう決めたのか」「どの案を捨てたのか」という判断は別のファイルに分けて残しています。判断の経緯を残しておかないと、しばらく経ってから「なぜここをこう決めたんだっけ」と人も agent も何度も悩み直すことになります。一度悩んだことを文字にしておけば、次の人や AI はその上から考え始められます。 設計（design）の判断には、もともと ADR（Architecture Decision Records）という考え方があり、社内基盤でも使われています。私たちはこれを仕様の側にも持ち込んで、なぜその仕様にしたのかという判断を RDR（Requirements Decision Records）という専用のファイルに残す方針にしました。spec 本体は「現時点の仕様」を表し、RDR は「そこに至るまでの判断の積み重ね」を表す、という役割分担です。 ADR や RDR を「どう書くか」「どんなときに新しいレコードを作るか」といった作法は、 decision-record という skill にまとめてあります。記録そのものは各案件に固有のものなので持ち運べませんが、「記録の作り方」のほうは共通の手順として配ることができます。 判断の経緯や却下した代替案を本文に混ぜると、「今の仕様はどれか」を読み取りにくくなってしまいます。現時点の要求だけを spec に残し、判断の層を RDR に切り出すことで、レビュー対象をノイズから守っています。 AI 側から見ても、この分離には意味があります。エージェントは普段は現状（spec / design）だけを読み、仕様を変えるときにだけ、紐づく RDR / ADR を必要に応じて引きにいきます。こうすると、AI に渡す context には「いまどうあるか」だけが入り、過去の議論や却下案がノイズとして混ざらない状態を保てます。 Git を origin に、Notion を読む場所に ドキュメントの原本はすべて Git に置いていて、Notion には自動で同期したコピーを置いて、読む場所やコメントをつける場所として使っています。 Notion をそのまま origin にすると、ドキュメントがチームの同意なしに誰でも編集できる状態になり、設計や実装との整合性が破綻します。逆に Git を origin にすると、Product Manager（PdM）や Designer に GitHub の Pull Request（PR）レビューを強いることになり、レビュー参加の敷居が上がってしまう。そこで、origin は Git に固定したうえで、Notion 側は「読む場所」「コメントをつける場所」と割り切りました。これで、非エンジニアのレビュアーは使い慣れた Notion でレビューに参加できますし、変更履歴は git log に残ります。 Git から Notion への同期は私たちでスクリプトを書いていますが、両者をつなぐ構成自体はありふれたもので、技術的には難しい話ではありません。むしろ難しかったのは、どちらを origin にするかという方針を最初に決めて、運用のなかでぶれずに守ることのほうでした。 レビューを skill に蓄積する そして、集まったコメントは職種ごとのレビュー用 skill に反映していきます。プロダクトの観点もデザインの観点も、一度もらった指摘によって、次からは AI による一次チェックができるようになります。 コメントを集めるところには、1つ実装上の落とし穴がありました。Notion のコメントは、解決済み（resolved）にするとコメント API からは取得できなくなります。レビューのコメントは指摘が反映されれば解決済みにしていくものなので、コメント API だけを見ていると、いちばん学びになる「対応済みの指摘」がごっそり抜け落ちてしまう。そこで私たちは、コメントを集めるときはコメント API ではなく履歴 API のほうから取得するようにしています。 例えばプロダクトのレビュー用 skill は、いつも的確な指摘をくれるメンバーのコメントから育てています。他の案件からはなかなかレビューをお願いしづらい立場の方でも、その観点を AI がいつでも一次チェックとして返してくれるようになるので、価値が大きいと感じています。レビューがその場限りで消えずに AI の中へ積み上がっていくのも、判断基準を残すことの1つの形です。 spec → design → plan → issue のパイプライン ここまで書いてきた仕様書や設計書、それにレビューの skill は、つなげて連続的に動かすこともできます。一つひとつを手で進めても十分機能しますが、つなげておくと、仕様書の変更がトリガーとなって実装まで自走させることもできます。 私たちは3つのドキュメントを使い分けています。 ドキュメント 役割 対応する skill spec 仕様書 spec-review design 設計書 design plan 手順書 plan それぞれに専用の skill があって、新しい仕様書が入ってくると、まず spec-review skill がその内容をレビューします。良さそうだと判断されたら、次に design skill で設計書をつくり、そこから plan skill で実装計画を立てます。plan skill は、もともとある plan モードを少し拡張したもので、立てた計画をファイルとしてリポジトリの中に残し、その手順の一つひとつに進捗のチェックがつくようになっています。リポジトリにファイルとして残しておくことで、session をまたいでも、別のメンバーが見ても、その計画と進捗をそのまま読める状態になります。 最後の issue skill だけは少し毛色が違っていて、ドキュメントというより、できあがった計画を実装処理へ渡すための受け渡し役です。issue skill で GitHub issue を用意し、そこに plan ファイルへの参照を入れておくと、GitHub Actions がそれを拾って実装を進め、終わると PR を出してくれます。つまり、仕様書の変更がトリガーとなって、ここまで一気通貫で進められるというわけです。 このパイプラインの土台になっているのは、それぞれの skill のなかに書き留めてきた判断基準です。spec-review が見るべき観点も、design や plan の組み立て方も、すべて私たちが少しずつ言葉にしてきたものです。パイプラインの組み立て自体は Claude Code の標準機能と GitHub Actions の組み合わせなので、目新しさはありません。新しいのは、機構の側ではなく、その上に積み上げた基準のほうです。 3. 検証ループ：推論ではなく、決定論を用意する 3つ目は、テストの話です。AI に開発を任せるとき、「ちゃんと動いていることをどう確かめるか」は、前章で挙げた三本柱のうち観測の役割にあたります。 ブラウザを動かして操作をひと通り確かめる、通しの End-to-End（E2E）テストを思い浮かべてください。AI にこれをやらせる方法として、Claude のように、その場でブラウザを直接操作してもらうやり方があります。ただし、この方法は毎回 AI の推論が入るので、結果がゆれますし、実行のたびにトークンも消費します。テストの本来の目的は「同じ入力なら同じ結果になること」を確かめることなのに、確かめる側がゆれてしまうと、本末転倒です。 そこで私たちは、AI を活用するのはテストの定義を作るところまでにして、実行のほうは推論を挟まない確定的なやり方にしました。AI に新しい機能の操作手順と期待される結果を書いてもらい、書き終わったら、その後の実行ループからは AI を抜く、という分け方です。こうすると、ゆれる可能性のある推論から決定論に変わって、同じ入力なら必ず同じ結果になります。Continuous Integration（CI）でも手元でも同じスクリプトが同じように走るので、差分が出れば、それは AI のゆらぎではなく、プロダクトに本当の変化があったサインだと、はっきり切り分けられます。 実際に、メルカリ NFT の主要なフローを Playwright で組みました。出品、購入、オファー、承諾、買取、配送といった一連の流れを、売り手と買い手を切り替えながら通しで実行します。これを「regression test を実施して」の一言で AI が全シナリオを走らせる状態にしてあるので、コマンドを覚える必要はありません。 確かめ方そのものを「正解」として固定するというのも、判断基準を残すことの1つの形です。AI に任せる範囲を広げるほど、人の代わりに結果を観測する機構は大事になります。そのときに、観測する側まで AI に任せきってしまうと、ゆらぐ判定でゆらぐ実装を確かめるという不安定な構造になってしまいます。確定的に動く部品を観測の側に据えることで、AI に任せる範囲を安心して広げることができるようになりました。 4. 個人情報（PII）の多層防御 4つ目は、セキュリティ、とくに個人情報の扱いです。社内でも注目されているテーマです。 commit や PR にうっかり個人情報が混入することは、人でも AI でも起こりえます。私たちは commit も PR も、それに Jira チケットの作成も AI にやってもらっているので、AI に開発を広く任せるのであれば、個人情報の保護にも AI を活用するのは自然な流れだと考えました。 そこで、一連の流れに対して個人情報を保護する機構を、三段の防御として載せることにしました。 三段にした意図は、どこか一段が落ちても別の段がカバーする構成にしたかったからです。一段目をすり抜けても二段目で止まり、それも越えてしまったら三段目で後始末できる。完全にミスをなくすことを期待するのではなく、ミスは起こる前提で複数の網を重ねる、というスタンスです。 もうひとつ、skill によるコメントなどで個人情報を引用するときは、先頭の数文字だけ残してあとはマスキングするルールにしています。AI のコメントは、PR の本文に残ったり、コミットメッセージや別ドキュメントに引用されたりと、思わぬ場所に流れていきます。該当箇所が特定できる程度に頭を残してそれ以外を伏せておけば、AI があとでどこかに書き残すときにも、本物の個人情報が混入することはありません。 この例では、機構（hooks や CI のスキャン、復旧手順）も判断基準（何を個人情報とみなすか）も、どちらもプラットフォームでなく私たち側で用意したものです。それでも、機構と判断基準を別物として扱い、判断基準を機構の上流に置く、という構図は変わりません。両者を区別して別々に扱う、という構図自体は崩れないということを、この例はあらためて思い出させてくれました。 どれくらい変わったか ここまでに紹介した4つの取り組みは、実際にチームの開発にどんな変化をもたらしたのか。指標としては定量的に見られるものと、日々の運用感覚として感じる定性的なものの両面で、いくつかわかりやすい変化が出てきました。 コードの一貫性を整え、開発の効率を上げる skill を入れていった結果、チーム全体の PR の数そのものが増えました。しかも、この案件は1月末にいったん開発チームを解散していて、それ以降はエンジニアが2人、プロダクトとデザインが1人ずつ、という少人数の体制です。チーム全体の流量が増えているうえに人数が少ないので、1人あたりで見れば何倍にもなっている計算です。 これは AI を導入したから自動的に増えた、というよりは、AI が力を出せるようにコードや判断基準を先に整えてきた結果だと考えています。漫然と AI を導入するだけでは、同じ結果にはならなかったはずです。 もうひとつ、PR の中身についても触れておきます。開発全体の PR 流量が増えている一方で、修正系の PR の割合は抑えられています。新機能や改善の PR の伸びが、修正系の伸びを上回っている、ということです。これは PR の乱造ではなく、品質を上げた上で流量も増えているという、非常に大きな成果だと思っています。 それとは別に、アラートの調査を AI に任せるための skill（監視基盤を直接触れるようにしたもの）も整備しました。アラートの URL を渡すだけで原因を調べて修正までまとめてやってくれるようになりました。日々の運用感覚としても大きい変化でした。 共通と固有を分ける：ほかの案件に持っていくために ここまで積み上げてきた仕組みは、この案件だけで閉じてしまうのはもったいないので、社内のほかの案件でも使えるようにしておきたいと考えました。そのためにやったのは、どこが共通で、どこがこの案件固有のものかを、はっきり分けておくことです。 この「共通と固有を分ける」やり方は、たった1つの小さな判断から始まりました。社内共通のフレームワークである monorail をアップグレードしたときのことです。monorail のチームは、アップグレードの共通手順を monorail-upgrade という skill で提供してくれています。ただ、私たちの案件には、それだけでは足りない固有の手順がありました。そこで、その名前のうしろに -local をつけた monorail-upgrade-local という skill を作って、固有の手順をそちらに置きました。この小さな切り分けが、いまの形の原型になりました。 私たちのプロダクトは、Backend と Frontend が別々のリポジトリに分かれていますが、共通で使える skill は、1つの plugin にまとめて配っています。そして、それぞれのリポジトリに固有の部分は、その plugin を上書きする -local な skill に入れています。こうしておくと、片方のリポジトリで skill を改善するともう片方にも横展開しやすくなりますし、skill の名前を見ただけで「どこからが共通で、どこからが案件固有か」が判別できます。 このやり方は、Claude Code の CLAUDE.md と CLAUDE.local.md の考え方を応用したものです。plugin を案件ごとに上書きする仕組みは、Claude Code に機能として用意されているわけではなく、Feature Request として GitHub に issue が出ている段階です。そこで私たちは、 -local という名前のつけ方を決めて、その規約だけで共通と固有の境界を表すことにしました。人によってはすでに自然にやっていることかもしれませんが、これを暗黙のままにせず、命名ルールとして明示しています。 大きな仕組みを最初から設計する必要はありませんでした。小さな判断を、次の人がそのまま使える形で残していけば、それが積み重なって、いつでも広げられる土台になります。 補：個人的な思想 ここからの話は、これまでの章とは少し性質が違います。この案件の特性から導かれた話というよりは、私個人の運用観の話だと思って読んでもらえると、はずれが少ないと思います。同じことをやろうとしている人が、これと違うやり方を選んでもなんら問題ありません。今回の記事に紛れ込ませているのは、この4ヶ月のなかで自分の中にまとまってきた考え方を、せっかくなので書き残しておきたかったからです。 専門知識は skill に集め、agent は薄いラッパーに保つ Claude Code には、知識や手順をまとめておく skill と、独立した context を持って動かせる subagent という2つの仕組みがあります。コミュニティの best practice を眺めていると、機能領域ごとに専用の subagent を作って、そこに専門知識を持たせていくやり方をよく見かけます。私が選んでいるのはこれとは違うルートで、専門知識は skill にまとめて、agent はそれを呼ぶための薄いラッパーに留める という分け方です。 agent と skill は対立する選択肢ではないと思っています。agent を作ってもよいのですが、agent には「この場面ではこの skill を、次にこの skill を呼ぶ」というルーティング情報だけ書く、と考えています。判断基準や手順、ドメイン知識といった本体は、すべて skill 側に書く。こうしておくと、同じ判断基準が複数の agent に重複して埋め込まれることがなくなりますし、skill を更新すれば、それを呼ぶすべての経路に反映されます。 例えば Anthropic は、長時間動く agent harness の設計について、実装する generator agent とテストする evaluator agent を別の agent として分離することを推奨(注4)しています。生成する agent に自分の仕事を批判させるよりも、別の agent を評価役として厳しくチューンするほうがやりやすい、という理屈です。agent を切るとしたら、こういうメイン context からの隔離と独立した判断、それに伴う権限スコープが単独で必要なときが良さそうです。その場合も専門知識を埋め込まずに、必要な skill 群を呼ぶ薄いラッパーとして組みます。agent の固有価値は隔離・独立した判断・権限スコープであって専門知識そのものではない、というのが私の見立てです。専門知識は skill 側に集めたほうが、再利用しやすく、知識の重複も起こりません。 rewind ではなく、新しい session を fork する Claude Code には、過去のやり取りを巻き戻して途中の状態から再開できる rewind という機能があります。便利な機能なのですが、私は意識的にあまり使わないようにしています。理由は単純で、rewind は context の rebase に近いところがあって、やってきた流れの一部が history から消える形になるからです。 これは好みの問題で、git の rebase が悪いと言いたいわけではありません。git log がきれいになるメリットと、流れがそのまま残るメリットには、どちらにも価値があると思います。ただ私自身は流れを残しておきたいほうで、後から「あのとき何を試して、何で失敗したか」を辿れるほうに価値を感じます。 やり直したいときは、rewind の代わりに新しい session を fork するようにしています。レビューしたいときも、進捗の区切りごとに分けたいときも、その都度別 session を立てます。session を分けたほうが、それぞれの context を小さく保てるので、結果的に動きも安定すると感じています。 plan ファイルと TODO.local.md が session 間のバトンになる session を多めに切る運用には、1つ前提があります。進捗を別 session に渡せる形で残しておく必要があるということです。これを担っているのが plan ファイルと、それからもうひとつ、 TODO.local.md というファイルです。 plan ファイルのほうは、前章で書いた spec → design → plan → issue のパイプラインで出てくる、あの plan です。手順の一つひとつに進捗のチェックがついていて、ファイルとしてリポジトリに残っているので、別の session を立てても、最後にどこまで終わっていたかをそのファイル 1 枚で引き継げます( 注6 )。同じことが git worktree を切って並列で動かしているときにも当てはまります。worktree A で進めていた作業を worktree B から続けることもできますし、agent 間でタスクを引き渡すときも、plan ファイルの該当箇所を指せば、お互いのなかで同じ進捗の理解が再現できます。 TODO.local.md のほうは、個人レベルの todo を扱うためのファイルです。チケット化するほどではない、あるいはチケット化する前段階のもの、例えば「あとで気が向いたら直したい」「明日の朝いちで手を付ける」といったレベルの個人 todo を、ここに置いています。これを管理するための todo skill も用意していて、追加、完了マーク、一覧表示、コード内 TODO の集約( 注7 )などができます。チケットほど重くなく、その場の独り言で消えてしまわない、中間地点のタスク管理に意味があります。 plan ファイルと TODO.local.md の2つで、チケットに上げるほどではない作業の進捗が、session や worktree、agent をまたいで運べるようになっています。これが、session を多めに切る私の運用を支える土台です。 中心の軸とのつながり ここまで書いたのは私の運用観なので、章の頭で断ったとおり、違うやり方を選んでもなんら問題ありません。ただ、最初の章で書いた「機構は外から、判断基準は自前で」という軸を頭に置きながら振り返ると、1つ気付くことがあります。 skill と plan ファイルと TODO.local.md は、判断基準が宿る側にあるということです。判断基準や手順、進捗の文脈を、可搬なファイルとして残しているからです。一方の agent や rewind、session の制御は機構の側で、判断基準そのものを抱え込ませる対象ではない、と私は考えています。 機構と判断基準を分けて、判断基準を機構の上流に置く、という構図を貫こうとすると、自然にこういう運用に寄っていくのではないかと思います。 まとめ AI を動かす機構はこれからどんどん外から手に入るようになるので、私たちの仕組み化は、その上に載せる判断基準を残すことに集中してきました。 何を正解とし、どこからを合格とし、何を危険とするか コードの一貫性も、判断の記録も、テストの固定も、個人情報の保護も、すべて「判断基準を、価値観と理由ごと残していく」という同じ考え方でつながっている 観測や停止の機構はモデルが進化するにつれて入れ替わったり、外せたりする部分がある。一方、判断基準は廃れにくい資産なので、特定のツールの設定ファイルに埋めるのではなく、自分たちのリポジトリに可搬な形で持っておく これらが、この4ヶ月の試行錯誤から得た学びでした。 結果が出るに越したことはないのですが、まだ誰も正解が分かっていない領域なので、いまは結果そのものよりも、改善していける過程に重きを置く段階だと思っています。同じようなことに取り組んでいる方、真似してみたい方がいれば、ぜひお話ししたいです。最後まで読んでいただき、ありがとうございました。 脚注 注1 ここでいう「判断基準」とは、ドメイン知識と開発ルールを併せたものに近いと、いまは捉えています。ドメイン知識のほうには、その業務を成り立たせるための知識だけでなく、そのドメインで何に重きを置くかという価値観も含まれます。 注2 Mitchell Hashimoto, "My AI Adoption Journey"（2026-02） https://mitchellh.com/writing/my-ai-adoption-journey 注3 Anthropic, "Effective context engineering for AI agents"（2025-09） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 注4 Anthropic, "Harness design for long-running application development"（2026-03, Prithvi Rajasekaran） https://www.anthropic.com/engineering/harness-design-long-running-apps 注5 これは人間も間違える原因になるので、AI を使わないとしても徹底したほうが良いと思っています。今回は AI-Native の話なので、本筋ではありませんが。 注6 Justin Young, "Effective harnesses for long-running agents"（2025-11） https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents session をまたぐ継続性を artifact（この場合はテキストファイル）で確保するという趣旨が該当します。 注7 これは案件内で共通のものなので TODO.md にまとめられています。IDE を常に開いていた頃なら、こういった TODO は自動的に収集してきてくれましたが、最近は Claude Code だけで済んでしまうので、こういったものが必要になりました。

こんにちは。メルペイ Growth Platform チームでエンジニアリングマネージャーをしている @yo-gawa です。この記事は Merpay & Mercoin Tech Openness Month 2026 の 19 日目の記事です。 私は 2018 年にメルペイに入社し、メルペイクーポンや決済に応じたポイント還元の仕組みなど、メルペイのキャンペーンを支える基盤の開発・運用に携わってきました。 【書き起こし】メルペイのキャンペーンの舞台裏 〜Growthを支える仕組み〜 – 小川 芳樹【Merpay Tech Fest 2021】 | メルカリエンジニアリング 現在は、メルカリグループ全体のグロース基盤のエンジニアリングを統括しています。 本記事では、私の視点からメルカリグループのグロース基盤の歴史と、どのようにチームが拡大してきたのかをお伝えします。 Growth Platform の立ち上げ メルカリグループでは、ポイントやクーポンを用いたマーケティング／キャンペーンが非常に活発に行われています。既存のお客さま向けの施策に加え、メルカリハロやメルカリモバイルといった新規事業のグロースにも活用されています。また、お客さまとのコミュニケーションチャネルとして、アプリ内バナー、メール、Push 通知、「あなたへのお知らせ」等も併せて使われています。Growth Platform チームは、こうしたグロース活動を支える基盤・仕組みづくりを担うチームとして機能しています。 「Growth Platform」というチーム名称が生まれたのは、ちょうど 5 年前の 2021 年 7 月でした。 「Growth UXチーム」が「Growth Platformチーム」に名称変更！　組織改編で見えたPMの役割やチームの変化 | mercan (メルカン) 上記の記事にもある通り、「共通する機能・基盤を横断的に見て、システム開発や運用の観点から下支えする」というミッションのもと、さまざまな取り組みを進めてきました。 Growth Platform というチームが生まれる前、2019 年のメルペイサービス開始直後は、より多くのお客さまにメルペイを使っていただくため、決済に絡めたクーポンやポイント還元キャンペーン施策を次々と打ち出していました。そのスピード感を支えるべく、独自にキャンペーン基盤を開発してきました。 一方で、マーケットプレイス事業にも同様にキャンペーンや Customer Relationship Management（CRM）を実行する基盤が存在していましたが、長いメルカリの歴史の中で生み出されてきた PHP 製ツールには多くの負債があり、メンテナンス性の観点からも、オペレーション事故が起きやすい構造になっていました。メルペイ側でも、それらのツールを利用することにリスクを感じていました。 そこで、メルカリとメルペイのエンジニア間で実務的なコラボレーションをスタートし、古いツールを廃止して、新たに Engagement Platform (EGP) という内製マーケティングエンジンを共同開発する方向性で合意しました。 その後、2023 年 1 月よりメルペイ内に統合組織を作り、「JR (Japan Region) Growth Platform」として、一丸となった開発体制をスタートさせました。詳細は当時のエンジニアリング統括であった keigoand の記事にまとまっています。 Merging Teams for a Growth Platform | Mercari Engineering 記事にもありますが、当初はそれぞれのチームで開発の進め方が大きく異なりました。メルペイが比較的小規模で立ち上げを進めた背景もあり、独自のオペレーションツールやミドルウェアがあり、エンジニアリングカルチャーも異なっていました。また、メルペイは金融事業を担っていることもあり、システム品質の担保も重要です。リリースプロセスの厳格化や、QAなどの各種基準への準拠などについて認識を合わせながら開発を進めることは苦労も伴いましたが、チームのケイパビリティは格段に向上しました。 グループの拡大とともに 先述した通り、Growth Platform チームはメルペイに所属しながらも、メルカリグループ全体を支えるチームです。 この数年、メルカリでは複数の新規事業が立ち上がりました。 メルカリShops メルコイン メルカリNFT メルカリハロ メルカリモバイル 越境ビジネス メルカリグローバルアプリ etc これらのビジネスやプロダクトの Product-Market Fit を支えるべく、Growth Platform ではさまざまな開発を行ってきました。例えば、新しいサービス画面上でのキャンペーンバナー表示や訴求、新規のお客さまへのクーポン／ポイント進呈、利用実績に応じたロイヤリティプログラムなどは、一見共通でありつつも、それぞれのサービスのデータを基盤に統合し、マーケティングチームが柔軟かつ高速にキャンペーンを打ち出せる仕組みが必要です。また、グローバル展開においては、各地域の言語や、クーポンにおける通貨の違いへの対応などもスコープになります。 さらに（一部例外はありますが）、メルカリのサービスは 1 つのメルカリアプリ上で動いています。起動直後に表示される「ホーム画面」や、マーケットプレイスにおける「商品詳細画面」「取引画面」でのキャンペーン訴求は、お客さまにサービス認知を獲得するうえで非常に重要です。そのような訴求エリアが限られる中で、どのサービスがそれぞれのお客さまにとって有用なキャンペーンであるのか、コミュニケーションチャネルがノイジーになりすぎないのか、といった最適化にも Machine Learning チームが取り組んでいます。 組織の拡大 事業の拡大に対応するため、Growth Platform 組織も拡大を続けてきました。 2022 年 6 月にインド・ベンガルールに開発拠点として Mercari India を設立して以降、設立当初から一緒に開発を進めています。当初はクーポンドメインを共同で開発するところからスタートしました。新たなビジネスに対応したクーポン機能の開発を進めながら、mercari-api という PHP 製モノリスからマイクロサービスへのマイグレーションという大規模プロジェクトも自律的に推進しています。 Migrating Coupons from Monolith to Microservice – Mercari India 近年ではクーポンドメインだけでなく CRM ドメインでも開発体制を拡大し、Backend、Frontend、Mobileのエンジニアが一体となってインド拠点のみで機能開発を完結するような事例も出てきています。 現在は日本とインドのエンジニアが約2:1の割合で協働しています。また、日本とインドのエンジニアリングマネージャー同士、密に連携しながら開発を推進しています。 Growth Platform の全体ミーティングでは、知見共有を含めた交流をエンジニア同士で積極的に行っています。加えて、定期的にインドオフィスへ出張したり、インドのエンジニアが東京オフィスを訪問するタイミングに合わせて交流を深めたりしています。 (インドオフィスに設置されているオブジェへのサイン) 一方で、使用言語の壁は依然として課題です。メルペイは従来、日本語中心でコミュニケーションしてきましたが、元マーケットプレイスのメンバーやインドオフィスのメンバーは英語中心です。Growth Platform チームの全体ミーティングは英語で行う一方、メルペイ全体のミーティングは日本語で実施しているといった状況下で、GOT（通訳）チームのサポートも借りながら、日本語話者・英語話者の双方が歩み寄ってコミュニケーションを進めています。 次なるチャレンジへ Growth Platform チームの成熟は、メルカリグループのグロースとともにありました。 EGP は、さまざまな機能開発を経て大きな進化を遂げています。 EGP – Mercari’s CRM Platform: Built Once, Powering Many | mercari GEARS 2025 AI と作る HTML ベースの LP エディタ EGP Code を内製した理由 | メルカリエンジニアリング また、メルペイに特化した基盤である Santa サービスも進化を続けています。 メルペイのキャンペーン基盤をルールベース汎用システムに書き直し、Otoku Revolutionするまでの話 | メルカリエンジニアリング 基盤開発フェーズは一巡したと捉えていますが、ビジネスを支える基盤としてはまだ道半ばにあります。特に、ビジネスの要求に対するアジリティとシステムの信頼性向上は継続的な課題です。 そこで今後は、グループそれぞれのビジネスグロースをより直接的に支えつつ、守りも固められる開発体制をつくるために、Growth Platform 体制としては一区切りとし、組織を CRMチーム と Incentiveチーム に分け、それぞれのミッションを担っていきます。 CRM チームは、マーケットプレイスをはじめとする各事業の成長を後押しするため、プロダクトと密に連携しながら、EGP を活用したお客さま向けコミュニケーション機能の開発・改善を進めていきます。 Incentive チームは、メルペイ Payment & Customer Platform の一員として、インセンティブを汎用的かつ安全に取り扱える仕組みづくりを推進していきます。 チームは分かれますが、メルカリグループ全体で活用される共通 Foundation として、連携は継続していきます。 まとめ ここまで、Growth Platform のプロダクトやチームの拡大について簡単にご紹介しました。プロダクトや技術の詳細は、本エンジニアリングブログやカンファレンスでメンバーが紹介していますので、そちらもぜひご覧ください。 これからもメルカリグループの可能性を広げるための仕組みづくりを追求していきます。 次の記事は abcdefujiさん と becosukeさんです。引き続きお楽しみください。

こんにちは。メルペイの Balance Team で Tech Lead をしている @kobaryo です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の18日目の記事です。 はじめに Balance Team では お客さまの残高やポイントを扱うマイクロサービスをはじめ、債権を取り扱う Debt Service も管理しています。先日公開された @imamu さんの「 事業者請求払いのための与信管理マイクロサービスの設計 」で、与信を扱う Credit Service を中心に事業者請求払いの設計が紹介されましたが、本記事ではその中で取り上げられた「債権を任意の軸で集計する仕組み」を Debt Service 上でどのように表現したのかについて紹介します。 事業者請求払いでは、与信管理のために「与信枠ごとの未返済債権」を高速に取り出したい、また請求のために「請求先ごとの債権の一覧」を把握したい、という2つのニーズが生まれます。お客さまや事業者ごとの残債を管理する既存のテーブル DebtAccount はお客さまや事業者を表す ID という単一の軸に縛られており、この2つの独立した軸を同時に管理できませんでした。この壁を越えるために、「DebtAccount は債権の操作ログ DebtLog を集計したビューである」という発想から DebtAccountView を設計しました。1つの DebtLog を異なる軸で集計された複数のビューに畳み込むことで、与信枠軸と請求先軸を独立して管理でき、将来の新しい集計軸も最小限の変更で追加できます。 Debt Service が管理する「債権」とはなにか 事業者請求払いでは、我々が取引のたびに代金を立て替え、後からまとめて事業者に請求します。この立替金の記録が 債権（Debt） です。Debt Service はメルペイの中で債権を一元管理するマイクロサービスで、事業者向けのみでなくお客さま向けのメルペイのクレジットなど、複数のサービスから呼ばれる下位レイヤーとして機能します。 各 Debt は「誰の（CustomerId）」「何の種別の（DebtType）」「いくらの（Amount）」立て替えかを保持します。DebtType は決済の種別や精算方法を区別するための分類で、お客さま向けの月次清算を表すものや事業者向けの請求書払いを表すものなど複数の種別が存在します。 個別の Debt が増えていくと、「ある事業者の現時点での残債はいくらか」を素早く知りたい場面が増えます。Debt を1件ずつスキャンして合算するアプローチは、Debt の件数に比例して計算コストが大きくなるため、取引のたびに現在の残債が与信上限を超えないかをリアルタイムで確認するには向きません。そのために DebtAccount というテーブルでお客さまや事業者ごと、かつ種別ごとに残債を保持しています。Debt の作成や返済が発生するたびに DebtLog （債権の操作ログ）が記録され、それに応じて DebtAccount の Amount が更新される仕組みです。 「1口座1軸」という壁 DebtAccount の設計はシンプルです。Unique key (CustomerId, DebtType) によって、「この事業者の、この種別の残債はいくらか」という問いに即座に答えられます。お客さま向けのメルペイのクレジットなど既存のユースケースではこれで十分対応できました。 請求書払いプロジェクトでは、この設計に2つの新しい要件が加わりました。1つは与信管理の要件です。詳細な説明は上述の @imamu さんの記事 に委ねるのですが、今回店舗や部門ごとなど1事業者が複数の与信枠を持てる設計を目指しています。そのため、与信枠を扱う Credit Service は決済フローの中で「ある与信枠に紐づく残債」をリアルタイムに取得できなければなりません。もう1つは請求の要件です。Invoice Service は請求先の軸でまとめた債権から請求書を発行するため、「ある請求先に紐づく債権の一覧」を取得できなければなりません。与信の軸（与信枠）と請求の軸（請求先）は完全に独立しており、1つの債権が両方に同時に紐づきます。またこれらの軸はどちらも CustomerId すなわち既存の事業者IDと独立しているため、既存の DebtAccount を用いて集計することはできません。 2つの要件はそれぞれ性質が異なります。与信計算は決済フローの中でリアルタイムで行われ、応答時間が Debt の件数に依存してはならないため、与信枠の軸でも既存の DebtAccount と同じ「1行参照で残債がわかる」事前集計が必要です。請求の要件は残債の集計ではなく、明細の作成や債権の返済のためにどの債権がどの請求先に属するかという紐づけを保持しておくことです。ただし後々事業者向けに請求額を確認できるダッシュボードを提供したいなど、請求先軸でも事前集計する必要が出てくるかもしれません。またこれらに追加して3軸目がこの先登場しないとも限りません。このように考えた場合、我々に必要なものは多軸で残債を集計でき、かつその軸と債権を紐付けておく汎用的な仕組みでした。 1つの操作を複数の軸で同時に集計する DebtAccountView この仕組みを実現するヒントは、DebtAccount の性質そのものにありました。DebtAccount は「口座」という名前のとおり実体を持つ台帳のように見えます。しかし、すべての事実は DebtLog に記録されており、DebtAccount はその DebtLog を (CustomerId, DebtType) 軸で集計し、現時点の残債を1行に集約したビューです。この捉え方に立つと、「同じ DebtLog を別の軸で畳み込んだビューが複数あってもよい」という発想が生まれます。これが DebtAccountView の設計の直感的な出発点です。 口座を分割するのではなく、集計の軸を並列に増やすというのが、設計の方向です。DebtLog は従来 DebtAccount という1つの集計ビューだけを更新していました。ここで、1つの DebtLog が既存の DebtAccount に加えて任意の数のビューを同時に更新できるようにしました。 各 DebtAccountView は既存の DebtAccount と同じ物理構造を持つ集計テーブルです。DebtAccount の設計思想をそのまま踏襲しているため、DebtAccountView 専用の新しい運用パターンを考える必要はありません。従来「1 DebtLog が1 DebtAccount を更新する」ところを「1 DebtLog が1 DebtAccount + N 個の DebtAccountView を更新する」に拡張した形です。 3つのテーブルが作る台帳の構造 この仕組みを支えるのが3つのテーブルです。 DebtAccountViews （集計した残債）、 DebtAccountViewItems （Debt と DebtAccountView の所属関係）、 DebtAccountViewLogs （Debt Account View の変動履歴）がそれぞれの役割を担います。この機能に関わる主要な3テーブルのスキーマを示します。 -- 集計した現在の残債 CREATE TABLE DebtAccountViews ( DebtAccountViewId STRING(100) NOT NULL, ViewKeyType INT64 NOT NULL, -- 1=請求先 ID, 2=与信付与先 ID, ... ViewKeyId STRING(MAX) NOT NULL, -- 指定した ViewKeyType の中の ID CustomerId INT64 NOT NULL, DebtType INT64 NOT NULL, Amount INT64 NOT NULL, ) PRIMARY KEY(DebtAccountViewId); CREATE UNIQUE INDEX DebtAccountViewsByViewKey ON DebtAccountViews(ViewKeyType, ViewKeyId, DebtType, CustomerId); -- どの Debt がどの DebtAccountView に属するか（請求書作成時に使用） CREATE TABLE DebtAccountViewItems ( DebtAccountViewId STRING(100) NOT NULL, DebtId STRING(100) NOT NULL, ) PRIMARY KEY(DebtAccountViewId, DebtId); -- 残高変動の履歴 CREATE TABLE DebtAccountViewLogs ( DebtAccountViewLogId STRING(100) NOT NULL, DebtAccountViewId STRING(100) NOT NULL, DebtAccountLogId STRING(100) NOT NULL, -- DebtLog に対応する DebtAccountLog（DebtAccount の変動ログ）を DebtAccountView に紐付けることで、間接的に DebtLog と紐付けている ) PRIMARY KEY(DebtAccountViewLogId); 上流マイクロサービスは、債権を作成する際に ViewKeyType （集計の軸）と ViewKeyId （ある集計軸における集計ID）を指定すれば、あとはその債権が返済・取消など操作されるたびに自動的に DebtAccountView が更新されます。また軸の種類を増やす際は単に ViewKeyType の種類を増やすだけで十分です。 今後の展望 現状の実装では、一度の債権の操作で更新する DebtAccountView が多くなる、すなわち集計軸が増えていくと、債権操作のレイテンシが上昇してしまいます。そこで考えられる拡張が ViewKeyType ごとに更新の同期・非同期を切り替えられる設計です。初期実装では全 ViewKeyType をデータ書き込みと同じトランザクションで同期的に更新していますが、将来同期的に反映しなければならない与信枠などの軸は同期的に、債権の変動と集計する間にタイムラグがある請求先の軸は非同期で反映するという拡張を予定しています。 また今回事業者請求払いのために DebtAccountView を設計しましたが、toB toC 問わず与信を分割したり与信を付ける先と請求する先が異なる任意のビジネスに適用できます。また、設計の本質は変動ログをピックアップし集計する汎用的なものであるため、債権に限らず残高やポイントを管理する Balance Service に導入して利用することも考えられます。 おわりに DebtAccountView は、「1つの債権に複数の集計軸を持たせたい」という要件から生まれた機能です。既存の DebtAccount 設計をベースに、「1 DebtLog → N View を更新する」という拡張を汎用的かつシンプルに実現することにこだわりました。また将来のユースケースや拡張も考え抜けたことは、実装を通じて得た達成感の一つです。 事業者請求払いはメルペイの Payment Platform としてまだ進化の途中にあります。与信管理、債権管理、請求、精算という一気通貫のプラットフォームを、各サービスの責務を保ちながら積み上げていくことは、技術的にもドメイン的にも自信を持って面白いと言えます。もしこうした課題に興味を持っていただけたら、ぜひ Balance Team やメルペイの採用・インターン情報も覗いてみてください。この記事が、Fintech や決済基盤のドメイン設計に興味を持つエンジニアにとって何らかのヒントになれば幸いです。 次の記事は yogawaさん と haoyuさん です。引き続きお楽しみください。 Appendix: 採用しなかったその他の選択肢 既存の事業者IDのみでなく与信枠軸や請求先軸など任意の単位での集計を実現する手段として、DebtAccountView 以外にもいくつかの案を検討しました。 1つ目は与信枠ごとに DebtAccount を分割し、請求先の情報は Debt に持たせる方法です。現状のスキーマの延長線上で実装することができとてもシンプルですが、請求先情報という Debt ドメインに関わりが深くない情報を列に直接追加するのはあまりに汎用的でありません。 2つ目は DebtAccount を親子関係で分割する案です。事業者全体の DebtAccount を親として、その子は与信枠の軸で分割、さらにその子は請求先の軸で分割するといったものです。DebtAccount を分割するための軸という概念を追加しそこに与信枠軸や請求先軸を入れるので、1つ目の案よりは汎用的です。しかし与信枠の軸と請求先の軸は互いに独立しているので、与信枠の軸での集計は効率よく行えるものの、請求先の軸での集計は依然効率よく行えません。加えて、与信枠軸や請求先軸のみでなく効率良く集計する必要のある3軸目が登場した場合に、1つ目の案とこの2つ目の案は対応することができません。 3つ目は Debt Service 内でなく、上流サービス側で集計を持つ方法です。Credit Service が与信枠ごとの残債を管理し、Invoice Service が請求先ごとの集計を管理する設計です。しかし Debt Service を使うサービスが増えるたびに、同じ集計ロジックを各サービスが個別に実装することになります。Debt Service 内で集計済みの情報を管理すれば、債権の元データを唯一の情報源として、各サービスへの変更通知なしに信頼性の高い集計を一元的に提供できます。この仕組みを Debt Service に置くことは、将来債権を取り扱う新しいビジネスが高パフォーマンスな集計を必要としたとき、プラットフォームとして即座に応えられる基盤への投資でもあります。

はじめに こんにちは。メルペイの @yutaro です。 「 Merpay & Mercoin Tech Openness Month 2026 」17日目として、メルペイの決済をもっと楽しく、繰り返し使いたくなる体験にするための取り組み（Otoku Revolution）について紹介します。 私は普段、Payment Platform の Balance Team で、メルペイ残高やポイントの状態管理、債権管理、会計連携、法定帳簿（法律上必要な帳簿）等の開発・運用をおこなっています。 この記事でシェアしたいのは、新鮮な体験を作るときほど、早い段階で「決済では何が起きるか」「返金や失効ではどう扱うか」「お金の流れはどうなるか」のような具体的な部分のイメージも煮詰めておくと、実装も追加施策も速く進められる、という実例です。 Otoku Revolution とは Otoku Revolution は、一言でいうと「決済するほど次の決済がおトクになる」体験を、メルペイの既存の決済基盤の上で実現するプロジェクトです。 実際の施策は、コード決済するたびにスタンプが貯まり、3回決済すると値引き特典を受け取り、次回決済時に自動で値引きされる新しい還元プログラムになりました。 (実際の決済後の画面) 決済する、スタンプがたまる、値引き特典を受け取る、受け取った特典が次回の決済で自動的に使われる。というような流れで、クーポンを選んだり、後日ポイントを受け取ったりするのではなく、次の決済で自然におトクになる体験を目指しました。 2026年5月中旬から、メルペイをご利用のお客さまの約半数を対象に試験的な導入を進めています。 決済基盤の上でこの体験（即時値引き）を作るには、キャンペーン条件、値引きを実現するリワード、決済処理、履歴、会計上の扱いを矛盾なくつなぐ必要があります。 構想初期には、周辺リポジトリをすべてcloneし、Claude Codeに読ませながら、関係しそうなサービスとデータの流れを図に起こしていました。 次のスクリーンショットは、そのときの初期アーキテクチャ図です。細部はその後整理していますが、議論のたたき台としては十分に現実に近く、どのサービスで何を扱うべきかを早い段階でそろえる助けになりました。 ここからは、この還元プログラムを実現するために値引きポイント DISCOUNT_POINT をなぜ選んだのかを紹介します。 なぜ DISCOUNT_POINT を作ったのか 最初の大きな判断は、この特典をどのような形で実現するかでした。 検討した選択肢は、大きく3つありました。 ポイントバック: 既存のポイント付与の仕組みで実現しやすい。一方、即時ではなく後日ポイントを受け取る体験になる クーポン: 特典として理解しやすい。一方、お客さまが選んで使うものになりやすく、既存の仕組みで即時反映を実現しにくかった 値引き専用の残高（DISCOUNT POINT）: 完全に新しい即時値引き専用の残高を作成し、対象の決済で最優先で使われるようにする 3つ比較した結果、即時値引きという体験を実現するためには、値引き専用の残高を作成する必要があるという判断になりました。 これは通常のポイントとは別の、値引きにだけ使えるお客さま向けの残高です。 内部的には残高のように扱えますが、お客さま向けにはすぐに次の決済に使えるクーポンのように振る舞います。次回の決済の値引きを実現したいので、決済金額が値引き額より小さい場合は、使い切れなかった分を失効させます。 DISCOUNT_POINT をスピーディーに実装するために役立ったのが、約1年半前から稼働している新しい残高管理システムである Balance V2 です。 Balance V2 では、残高の種類を後から柔軟に追加できる設計になっており、種類ごとに使われ方や会計連携を宣言的に定義できます。また、残高の付与や消費、失効に伴う変動があった場合に自動で会計連携されるようになっています。 このプロジェクトではその汎用性を活かし、施策専用のサービスを立ち上げるのではなく、 DISCOUNT_POINT という新しい残高の一種として即時値引き特典を扱う設計にしました。 結果的に、全く新しい種類のクーポンであるはずの即時値引き特典を、決済基盤上では残高の延長線上で扱い実装できるようになりました。 DISCOUNT_POINT の全体像 DISCOUNT_POINT は、決済完了後にスタンプが３回溜まっていれば付与されます。付与後、次の決済前に利用可能な残高として参照され、決済手段に最優先で使われる残高として組み込まれ、通常の残高やポイント・メルペイのクレジットより先に使われます。 例えば、 DISCOUNT_POINT を100円分もっているお客さまが300円分の商品を購入しようとすると、100円分が優先的に DISCOUNT_POINT から消費され、他の残高等の決済手段から200円分が消費されます。 このように、お客さま目線では200円分の負担で300円分の決済ができた。という値引き体験を実現できています。 このような体験を実現するために、このプロジェクトではサービスの役割を分けました。冒頭の初期アーキテクチャ図は細かい実装寄りの図なので、ここでは大きく「決済前」「決済時」「決済後」の3つに整理しています。実際の構成にはさらに細かい処理や例外がありますが、大きな役割だけに絞ると次のようになります。括弧内は、社内で使っているサービス名です。 service 主な役割 特典付与サービス (santa-service) スタンプの管理、付与額の決定 支払い方法設定サービス (payment-config-service) お客さまの設定や状況ごとの決済手段を決定 決済サービス（payment-service） 渡された決済手段どおりに支払いを実施する 残高管理サービス（balance-service） DISCOUNT_POINT の残高管理、消費、失効、会計連携 このように役割を分けると、santa-serviceは条件判定、balance-serviceは残高の増減、payment-serviceは渡された内訳どおりに決済を成立させることに集中できます。 お客さまにはひとつの施策に見えるものを、裏側ではスタンプ、決済に使う残高やポイント、履歴表示、会計上の記録に分けて考えられるようになり、それぞれの影響範囲について議論や意思決定がしやすくなりました。 実際のキャンペーンの条件や例外の多くは、santa-serviceで扱っています。@hasegway さんの「 メルペイのキャンペーン基盤をルールベース汎用システムに書き直し、Otoku Revolutionするまでの話 」 では、このような複雑なキャンペーンをルール組み合わせとして扱えるようにした Rulebase 移行について紹介されています。 次の章から、付与、利用、返金・失効、会計 についての詳細をそれぞれ紹介していきます。 付与: 還元で決済を止めない Otoku Revolution、は決済完了後のスタンプ更新から始まります。 決済が完了すると、payment-serviceから非同期のeventが発行されます。santa-serviceはそのeventを受け取り、キャンペーンの対象のユーザーかどうかを確認してスタンプの付与を行います。ここで、スタンプが３回分に到達した場合は特典額を決め、balance-serviceに DISCOUNT_POINT の付与を行います。 ここで大事だったのは、 スタンプ更新や値引きポイント付与を、決済そのものの成功条件にしないこと です。 この還元プログラムの体験としては「決済後に即時でスタンプ・ DISCOUNT_POINT の付与が行われる」が理想です。一方で、スタンプ更新や DISCOUNT_POINT の付与までを決済処理の中で完了させようとすると、キャンペーン側の遅延や障害が決済成功率に影響してしまいます。 決済基盤では、決済そのものをキャンペーン側の都合で不安定にしないことが最優先です。そのため、決済完了後にあとからスタンプを更新し、条件達成時に DISCOUNT_POINT を付与する設計にしました。 利用: 最優先で使われるポイントとしてのDISCOUNT POINT 付与された DISCOUNT_POINT は、次の決済で自動的に使われます。 ここで設計上大事だったのは、payment-serviceの役割を広げすぎないことです。 直感的には、payment-serviceが残高を見て「 DISCOUNT_POINT があるなら使う」と決める設計も考えられます。この形にすると、値引きの判断を1か所に集めやすいという良さがあります。 しかし、payment-serviceは単に外部向けの決済を担当しているだけではなく、社内のありとあらゆるお金の流れに関与しており、できるだけ DISCOUNT_POINT に関係する専用のロジックは入りこまないようにしたいです。 そのため、決済前に支払い方法と金額を組み立てる payment-config-serviceが、支払い方法と DISCOUNT_POINT 残高を見て、 DISCOUNT_POINT を優先的に消費する決済内訳を作る設計にしました。payment-serviceはその内訳どおりに決済を進め、残高管理サービスが実際の残高消費を担います。 このような責務分担にすることで、コード決済等の決済手段ごとに値引きを適用するかどうかのルールを段階的決めることができるようにもなります。 返金・失効: クーポンとして振る舞うように設計 DISCOUNT_POINT は、通常のポイントのように貯め続けるものではなく、「スタンプがたまった次の決済で使える特典」です。 返金時や、決済金額が値引きポイントより小さいときも、不正対策やユーザービリティの観点でクーポンに近い挙動になるようにしました。 返金・失効では、主に次のように扱います。 返金時に、スタンプの数は戻さない 返金時に、使用済みの値引きポイントは再付与しない 決済金額より値引きポイントが大きい場合、使い切れなかった分は失効させる 例えば、1,000円の決済で100円分の値引きポイントを使ったあとに返金された場合でも、通常の返金処理の中でスタンプや値引きポイントの状態までは巻き戻しません。巻き戻す設計にすると、「再付与した値引きポイントをもう一度使えるのか」「スタンプも取り消すのか」「会計上は何を取り消すのか」を追加で扱う必要があり、スタンプカードとしてのルールも複雑になります。 また、500円分の値引きポイントを持っているお客さまが300円の決済をした場合は、300円分を消費し、残り200円は失効します。 DISCOUNT_POINT は残高として管理しつつ、次の決済だけで使われる特典に近い性質を持たせたかったためです。 このように整理することで、クーポンのような挙動のポイントである DISCOUNT_POINT を実現しています。 会計: お金の流れを先にデザイン DISCOUNT_POINT を新しい残高として扱う以上、アプリに表示して決済で使えるだけでは不十分です。付与された時点、使われた時点、失効した時点で会計上どう記録されるのかを説明できないまま進めると、後から設計を大きく見直すことになります。 そこで、まだ設計が固まりきる前に、プロジェクト全体の MoneyFlow、つまりお金がどう動くかを図にして、経理チームに相談しに行きました。 この図では、 DISCOUNT_POINT の付与・消費・失効が、会計上の記録につながることを描いています。全体ではなく一部だけを載せています。このプロジェクトでは早い段階からお金の流れを具体的な図にして議論していました。 実装が本格化する前に、お金の流れと会計上の意味を一緒に確認できたことは、後から振り返っても大きかったと思います。MoneyFlow そのものについては、@komatsu さんの 「 決済プラットフォームと経理を繋ぐ MoneyFlow 」に詳しくまとまっています。 Otoku Revolutionではこのように整理したうえで、 DISCOUNT_POINT の付与・消費・失効をbalance-serviceで扱い、会計連携までつなげて、会計レポートを作成できるようにしました。 リリース後、事前付与施策で効いた設計 リリース後には、多くのお客さまにこの還元プログラムを知ってもらうための施策も必要になりました。 そこで、対象のお客さまにあらかじめ DISCOUNT_POINT を付与する施策を追加で開始することにしました。キャンペーン開始直後のタイトなスケジュールの中、スピーディーに付与実施までもっていくことができました。 このような柔軟な追加施策を実施できたのは、単に実装が早かったからではありません。 DISCOUNT_POINT が残高管理サービスで管理される残高として扱われ、付与、消費、失効、会計上の記録の意味がすでに整理されていたことが効きました。 追加施策でも、付与する残高の種類、決済時の使われ方、使い切れなかった分の扱い、履歴での見え方、会計上の記録を新しく考え直す必要はありませんでした。「誰に、いくら、どの条件で付与するか」に集中できたことが、速度を出せたポイントかなと思います。 振り返り Otoku Revolutionでは、最初から「値引きポイントをどう見せるか」だけでなく、「決済では何が起きるか」「返金ではどう扱うか」「会計ではどう記録するか」をまとめて確認できたことが大きかったです。そのおかげで、 DISCOUNT_POINT を残高として付与し、決済で優先的に使うといアイディアで最後まで手戻りなくリリースまで実現できました。 個人的には、プロジェクトの構想段階から体験面の議論に混ぜてもらいながら、エンジニアとして実現性や整理が必要になりそうな点を少し先回りして確認しにいけたことは、私にとっても学びの多い進め方でした。体験を決めたあとに会計や法務、返金のルールに合わせて作り直すのではなく、最初からそれらを含めて設計できたことは大きかったと思います。普段 Balance Team で扱っている残高・会計・帳簿の知識が、お客さまに届く体験につながったことも印象に残っています。 決済基盤の仕事をしていると正しさや安全性を守る場面が多いですが、その知識の延長線上で新しい体験を実現できたことは、素直にうれしかったです。 次の記事は @kobaryo さんの「任意の単位での債権の色付けと与信の分割を実現する Debt View」です。私がこのプロジェクトに多くの時間を割いていた間、Balance Team の日々の業務を @kobaryo さんに大きく支えてもらっていました。次の記事もぜひ読んでみてください。

本記事は「 Merpay & Mercoin Tech Openness Month 2026 」の17日目の記事です。 この記事は新しいロールであるPdE (Product Engineer)というClient / Backend の境界をまたぐ「越境開発」ロールの取り組みについて、@anzai, @victoria Li, @ninnin, @panoramaの4名でお送りします。記事本文は、そのうちの1人である anzai が、自分の体験を一人称で振り返る形で書いています。 はじめに 「Client エンジニアが Backend を書き、Backend エンジニアが Client を書く」——そんな体制は実際に成立するのか。Q4 に試した小さな実験を紹介します。 ひとことでまとめると、Android エンジニアが Postgres のデータベース（DB）設計とサーバー実装を書き、Backend エンジニアが iOS/Android の画面を作りました。やってみて成立はしたものの、楽な道ではありません。何が効いて、どこで詰まったのか。本記事では「越境開発」というテーマに絞って、その実際を共有します。 越境開発の背景 私は普段メルペイでClient（Android / iOS）のチームを見ている Engineering Manager です。今回はManagerとしてではなく、自分の手でコードを書く一員として KYC（本人確認）領域のAI pod (小規模な開発チーム)に参加しました。 このチームでは、Product Manager（PdM）を置かず、エンジニアが1人で1プロジェクトを仕様策定からデリバリーまで一気通貫に持つ（1 Person 1 Release）、という体制を試しています。 そしてこの体制を回そうとすると、避けて通れない課題が1つ出てきます。それは「1人で End-to-End（E2E）に持つなら、Clientも Backend も自分で書くことになる」ということです。 KYC のプロジェクトは、ほとんどの場合 iOS / Android のClientと、サーバー側の API・DB の両方に手を入れます。従来はここをクライアント担当とサーバー担当で分けていました。1人1プロジェクトにするなら、その境界をまたぐ必要があります。E2Eで開発する中で「Client エンジニアが Backend も、Backend エンジニアが Client も開発できるか」を、実プロジェクトで検証することにしました。 いくつかのプロジェクトで Client-Backend を一気通貫で開発した結果、今期はどちらも成立しました。Client エンジニアがサーバーの DB と API を書いてリリースし、Backend エンジニアがモバイルの画面を出す。これ自体が、まず確かめたかったことです。 以下では、私がどう開発を進めたかを時系列で振り返り、そのあとで、どこで詰まったかを共有します。 AI を活用した越境開発の進め方 私はClientエンジニアです。今回担当したプロジェクトで最終的に必要としていたアウトプットは、具体的には2つでした。1つはお客さまに見せる UI/UX、もう1つは、その後の業務報告に使うレポートです。この2つの具体的なアウトプットから逆算して、「では、その裏側でどんな仕組みを実装しなければならないか」を決めていく必要がありました。そしてその仕組みの大部分が、私にとって初めてのサーバーサイド（Go / Postgres）です。 そこでまず、既存の実装を AI Agent に読み込ませ、「この2つのアウトプットを満たすには、どんな設計・実装が必要か」を AI に検討してもらうところから始めました。要件は手元にあるので、あとはそれを初めての言語と環境にどう落とすか。 この記事のここから先は、その道のりを時系列でたどります。 AI の説明もコードも、最初はわからない 最初にぶつかったのは、コードを書く以前の問題でした。AI Agent が返してくる説明そのものが、何を言っているのかわからないのです。 たとえば「Postgres を起動して、goose で既存の migration を流して、psql で確認して」と AI に言われても、最初は何を指しているのか、まったく理解できませんでした。goose とは何か、psql で何を確かめればいいのか ── そのひとつひとつが、Client 開発しかしてこなかった私には初めての言葉です。AI は正しいことを言っているのかもしれないけれど、こちらにそれを受け取る前提知識がない、という状態からのスタートでした。 ここでやったのは、ひたすら AI に問い返すことです。「それはどういう意味か」「図にして説明してくれ」と、いろいろなパターンで噛み砕いてもらう。そして自分が納得できたら、その理解を「こういうことですよね」と、今度は別のBackendエンジニアに確認しに行く。これを繰り返すことで、環境がどう動いていて、何をすればテストが回るのか、開発の前提条件をまず頭に入れていきました。 前提が見えてきたところで、いよいよ実装です。さきほどの要件をもとに「設計して実装してみて」と AI Agent にお願いし、コードを書いてもらいます。すると今度は、出てきたコードそのものが読めません。 なぜここで defer を呼んでいるのか。なぜ cancel() しなければならないのか。ここで context を受け取っているのは、つまりどういうことなのか。Go のイディオムが、ことごとくわからないのです。 そこで最初は、作ってもらったコードを一行一行、すべて AI に解説してもらいました。 context のキャンセルでリソースを解放しないと goroutine が漏れる、だからこの位置で defer cancel() する。そうした説明を1つずつ受けながら、文法書ではなく目の前の実コードを教材にして読み解いていきます。 なお、DB についてはまったくのゼロからではありませんでした。モバイルでも端末上の SQLite でテーブルを設計し、クエリを書く機会はあります。正規化やインデックスといった基礎概念そのものは持っていたので、サーバーの Postgres は「知っている概念を別のコンテキストに翻訳する」作業に近く、そこは助けになりました。 チャンクごとの並走型にたどり着く ただ、「全部書いてもらってから一行ずつ解説」では、どうしても効率が良くありません。これを変えたのが、チームのふりかえりでした。 私たちは週に1回レトロスペクティブを開き、チームの進め方を少しずつ改善していました。その中で、メンバーの一人が「チャンク（意味のある塊）ごとの並走型」というやり方を持ち込みます。AI に一気に全部を生成させるのではなく、意味のあるコードブロック単位で実装させる。そのブロックが「なぜ必要なのか」を自分が理解できればそのまま進め、理解できなければきちんと問い返す。「ここは A と B のやり方がありそうだけれど、なぜ A を選んだのか」と都度たずねていくことで、コードの一行ずつの意図を理解しながら前に進みます。 このやり方だと、巨大な生成物を上から順に読み下す必要がなくなり、開発の流れを「意味のある順序」で理解できます。機械的な行順ではなく、設計の意図に沿った順序で頭に入っていく感覚です。質問と回答はログとして残し、読み返せば「今日は何を学んだか」の復習にもなりました。 選んだ理由を残し、AI のコードを自分で理解する この進め方には、思わぬ副産物もありました。「いくつかの選択肢のなかで、なぜこの A を選んだのか」を開発の過程ですでに言語化しているので、それをそのまま Pull Request（PR）の説明に書けるのです。結果として、レビューはそれほど詰まることなく得られました。初めての領域でも、選択の根拠を添えられればレビュアーは判断しやすいですし、「ここまで考えた上でのPRなんだな」という信頼も得られます。ビギナーのPRを読むことはコードオーナーにとって大変な負担ですので、このような越境開発において信頼を作るための調査は必要な工程だったと思います。 ここで1つ、立ち止まって考えるべき論点があります。AI が書いたコードを、人間がわざわざ読んで理解する必要はあるのか。生成して、テストが通って、動けばよいのではないか。これはこれから重要になる議論だと思います。 私の現時点の答えは「理解すべき」です。 これからの生産性は、書いたコード量ではなく、意思決定の回数と質でほぼ決まっていくと考えています。そして意思決定の質と回数を上げるには、ドメインの理解が必要です。「このバックエンドの設計は、これで本当に正しいのか」を判断する場面で、いまのところ最終的な判断は人間がしています。その判断を下せるだけの理解を持っていないと、意思決定の回数も質も上がっていきません。だからこそ、AI が書いたコードでも中身を理解しておく価値がある、というのが今の立場です。 またAIの仕組み的に、永遠にそのPRに対して改善ポイントを考え出すことができます。たとえば、あるPRについて1回目のセッションでAIに聞くと A・B・C の3点を直すよう言われ、その修正結果を別のセッションで聞くと、今度は E・F・G の3点を直すよう言われる、ということが起こります。それを全部反映すると、最終的にはオーバーエンジニアリングした膨大なPRになりがちなので、現状は「どこまでが適切か」を人が判断する必要があるでしょう。 もしこの「理解する」のに2〜3年かかる長期投資なら、学ぶ理由はもっと厳しく問われるでしょう。ですが実際はそうではありませんでした。いまの AI Agent によるオンボーディングは本当にしやすく、いわば優秀な指導役が隣について、いつでもペアプロに付き合ってくれるような状況です。この環境であれば、3ヶ月もあれば、いま開発している領域の一通りの知識は得られるという手応えがありました。もちろん、もともとシニアエンジニアとしての経験がある、という条件付きではあります。投資回収が数年ではなく数ヶ月の単位に縮んでいるのなら、理解する側を選ぶのが合理的だと考えています。 設計の最終確認はシニアエンジニアと とはいえ、AI に聞けばそのまま採用、とはしませんでした。象徴的だったのがインデックスの設計です。 「このカラムにインデックスを張るべきか」を、AI の提案を鵜呑みにするのではなく、なぜ必要なのか／不要なのかを自分で根拠を持って調べました。どんなクエリパターンで引かれるのか、カーディナリティはどうか、読み取りが速くなるぶん書き込みコストとのトレードオフはどうなるのか。こうした観点を1つずつ確かめて、「この設計にはこういう理由がある」と説明できる状態にします。 それでも、最後はシニアエンジニアと一緒にレビューしました。正直に言えば、これは自分の自信のなさを埋めるためでもありました。AI が生成したものが本当に正しいのか、その最終的な判断が、私一人ではどうしてもつかなかったからです。 このレビューには、不安を消す以上の価値がありました。シニアエンジニアが、考え得るパターンをいくつも挙げてくれたうえで「では、この方法でいきましょう」と意思決定でき、いくつかの改善点も見つかりました。よりベターな やり方にたどり着くうえで、人と一緒に見てもらう工程はやはり必要だったように思います。こちらは Backend エンジニアが Client 開発をする場合も同様でした。 AI で下書きと理解を加速し、自分で根拠を固め、最終的には人とレビューする。この3段構えが、初めての領域で品質を担保し、かつ自分が安心して前に進むうえで、現実的なやり方でした。AI は出発点と伴走者としては非常に強力でしたが、設計の最終的な妥当性を見極め、選択肢を広げてくれるのは、まだ人間のレビューだった、というのが実感です。 なお、今回書いた DB 設計は2テーブルだけのシンプルな構成で、本格的な分散やシャーディングの考慮までは要りませんでした。テーブルが増え、複雑なインデックス設計が絡む規模で、AI とこの3段構えがどこまで通用するのかは、まだ検証できていません。「シンプルだったから回った」可能性は十分にあります。 最後に補足すると、こうして進められた背景には、組織図上で「越境させた」のではなく、同じチームの中で互いの領域をペアプロで教え合える環境があったことが大きいです。AI に聞いてもわからないこと、そもそも何を聞けばいいかわからないことは、隣にいる詳しいメンバーにその場で聞く。AI と人、両方に頼れる相手がいたことが、越境のコストを最も下げました。 つまずいたポイントと対策 ここまでは「どう乗り越えたか」を中心に書いてきましたが、実際には数多くの詰まりどころがありました。そしてその多くは設計や実装の難しさではなく、環境・ツール・運用、つまりコードを書く以外の全部にありました。Client しか書いてこなかった人間が Backend に入ると、ここでことごとく足を取られます。代表的なものを課題ごとに紹介します。 現状の開発スタイルがわからない 最初の壁は、開発スタイルそのものの違いでした。 Clientエンジニアの感覚として、まずローカルでビルドして動作を確認しようとしました。ところが、このコードをもともとメンテナンスしていたチームは、開発環境（dev）にまずデプロイしてから動かす、というスタイルを取っていました。つまり、ローカルの docker compose は、実のところほとんど使われていなかったのです。 私はそれを知らないまま、ローカルの docker compose を立ち上げようとして、「Postgres のバージョンが合わない」「環境変数が無効だ」と、動かない環境を前に四苦八苦しました。結果ローカルでテストできるようになったので良かったのですが、リポジトリ固有のこうした暗黙知は、AI ではどうにもならない部分です。 enum を一つ増やしたら、芋づる式にバージョンが上がる 次につまずいたのは、依存関係の更新でした。やりたかったのは、protobuf の定義に enum を一つ増やし、新しく追加された定数を参照することだけです。ところが、その定義を取り込もうと go mod tidy を実行したとたん、直接は触っていないはずのライブラリのバージョンが一斉に上がってしまいました。gRPC まわりから、最終的には Go 本体の要求バージョンまで動いてしまう。たった一つの enum のために、なぜここまで広がるのか、最初はまったく見当がつきませんでした。 やっかいだったのは、その「なぜ」に対して、もっともらしい説明がいくつも出てきて、しかもそれが間違っていたことです。AI に理由を聞くと、それらしい仮説、たとえば「余計な更新を巻き込んでいるだけだから、最小限に戻せる」といった答えを返してきます。ですが、その通りに戻そうとしても差分は収まりませんでした。 ひたすらAIと問答し、ようやく分かりました。原因は依存が構造的に噛み合っていたことでした。新しい生成ライブラリが新しい gRPC 系を要求し、それがさらに別の基盤ライブラリを引き、最終的に Go 本体の下限まで押し上げている構造だったのです。本当にそうなのかの依存関係のグラフを図示し、それでも自信が持てなかったのでPR Reviewでシニアエンジニアにレビューいただきました。 ローカルでのテストと Lint DB アクセス層（DAO: Data Access Object）のテストをローカルで回そうとすると、ただ実行するだけでは通りませんでした。テスト用の Postgres を専用ポートで立て、 PGPORT を明示的に指定する、といった、チームでは当たり前すぎて誰もドキュメントに書かない作法を、1つずつ踏みながら知っていきます。 たとえば DAO テストは、 5556 のような専用ポートでテスト用の Postgres を立て、 PGPORT でそこを向けて初めて通ります。これを知らないと、テストはローカルの既定のデータベースに接続しようとして、原因の見えないまま失敗し続けます。どこにも書かれていないこの一手にたどり着くまで、エラーメッセージとにらめっこする時間が続きました。 Lint も同様でした。ローカルで走らせると、設定のバージョン差（v1 系と v2 系の非互換）でうまく通らず、CI（Continuous Integration）に任せるという割り切りに落ち着きました。「ローカルで全部緑にしてから push する」という前提が、まず崩れます。 E2E 開発のマシン要件 1人で Client も Backend も1台で回すと、マシンへの負荷が一気に上がります。実際、Android ビルド＋エミュレータ、iOS ビルド＋シミュレータ、Docker コンテナ3つを同時に動かして、メモリを90GB使う場面がありました。スワップなしで E2E 開発をするなら、96GB は欲しいところです。 特にBackendのEngineerは元々高いスペックのPCを持っておらず、Client開発でまず最初のローカルビルドを試す段階で躓いてしまいました。ここからローカルビルドに耐えるPCを支給してもらうまでClient開発に着手できないということが起きてしまっていました。 越境して E2E を1人で持つということは、ツールチェーンも全部抱えるということでもあります。ハードウェアは目立ちませんが、無視できない条件でした。チーム内でも「越境する人ほどマシン要件が上がる」という前提を共有し、開発機の選定では多めのメモリを見込んでおく必要がある、という話になりました。 振り返って これらの課題に共通していたのは、詰まったポイントのほとんどが、設計や実装の難しさではなく、環境・ツール・運用の暗黙知だったことです。コードを書く力そのものよりも、その手前のところで足を取られていた、というのが実感でした。 ここで効いてくるのが、もともと人間のオンボーディングでも重要だった条件です。「DX（Developer Experience）が整っている」「オンボーディング資料や開発ドキュメントが整備されている」という、人にとっての整備状況が、そのまま AI にとっての整備状況でもありました。ドキュメントが薄く暗黙知に頼っている領域では、人も AI も同じように迷います。 今のところは、やってみて初めてわかる問題を踏んでは1つずつ潰していく、いわば「悲鳴駆動」で進めるしかなく、チームを立ち上げてから数ヶ月は生産性を上げるのが難しいのが正直なところです。逆に言えば、ここをドキュメントとセットアップスクリプトであらかじめ潰しておけば、越境のコストは大きく下げられる、という改善の的もはっきり見えました。次に越境に挑むなら、最初に着手するのはこの整備だろうと考えています。 まとめ KYC で試した範囲では、Client ⇄ Backend の越境開発は成立しました。Client エンジニアがサーバーを書き、Backend エンジニアが iOS/Android を出せています。 それを支えたのは、いくつかの条件でした。まず、小規模な開発チームとして一体で動き、ペアプロやオンボーディングセッションをしながら互いの領域を学べたこと。次に、AI Agent が初見の言語やコードを一文ずつ理解する伴走者になってくれたこと。ただし、設計の最終的な妥当性を見極め、そして開発者の不安を払拭するのは、いまも人間のシニアレビューでした。環境構築やツールのバージョン、ローカルテストといった暗黙知を埋めるには、オンボーディング環境とドキュメントが要ります。一方で、選択の根拠を開発の過程で言語化し、それを残しておけば、専門外の領域でもレビューは回りました。そして最後に、これらすべてを1台で回すには、メモリ96GB級の開発機が現実的に必要でした。 そして、これらが揃っていても、最初の数ヶ月は生産性が落ちます。越境は成長痛とセットでやってくる、というのが一番の学びでした。逆に言えば、その成長痛をチームとして引き受ける覚悟と、AI を含めたオンボーディングの仕組みがあれば、「クライアントエンジニア」「サーバーエンジニア」という肩書きの境界は、思っていたより動かせます。 次は、もっと複雑な DB 設計を含むプロジェクトで、AI がどこまで越境を支えられるのかを確かめていきます。エンジニア一人ひとりが領域をまたいで動けるようになることは、巡り巡って、より早く・より確かな価値をお客さまに届けることにつながると考えています。これからもこういった挑戦を続けていきたいと思います。 次の記事は yutaroさんです。引き続きお楽しみください。

こんにちは。Data Ingestion チームでData Engineerをしている @orfeon です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の14日目の記事です。 はじめに Data Ingestion(旧Data Platform)チームでは、多数のマイクロサービスが管理する データベース・テーブル から、大量のデータを継続的にDWH（データウェアハウス）へ同期する必要があります。同期対象には数億〜 数百億件 に達する大規模なテーブルも含まれ、これらをいかに速く・安全に・一貫性を保ったまま抽出するかが、DWHの鮮度や安定性にとって大事になります。 これまで  Cloud Spanner  からのデータ取得では、Spannerの分散DB特有の機能（後述）を活用することで、大規模テーブルでも高いスループットでの取得を実現できていました。 一方、社内にはTiDBやAlloyDBといったSpanner以外のデータベースも多く利用されており、その中には数百億件以上に達するテーブルもあります。 これらのテーブルは従来、主キーなどで シーク方式 で取得していましたが、単一コネクションでの シーケンシャルなデータ取得 になるため、大規模テーブルでは取得に非常に時間がかかっていました。 そこで今回、Spannerと同じように、 それぞれのDBに特有の機能を活用して並列取得などでスループットを上げる よう工夫しました。 具体的には、 TiDB  と  AlloyDB  の大規模テーブルをDWHへ同期する仕組みを  Cloud Dataflow（Apache Beam）  上に構築しました。 本記事では、その中核となる2つのSourceモジュール   TiDBSource  と  PostgresSource   について、高いスループットを実現するための工夫を解説します。 なぜ汎用JDBCではなく専用モジュールなのか Beam/Dataflowには汎用的な  JdbcIO  が既に存在します。 しかし汎用JDBCは「 SELECT を実行して結果を1行ずつ読む」という標準的な経路をたどるため、大規模テーブルでは以下のボトルネックが発生します。 1行ごとのSQL処理オーバーヘッド : 通常のクエリ実行では、サーバ側でのタプルのテキスト/プロトコル変換などが行ごとに発生する。 並列化の難しさ : テーブルを並列に読むには「どこで分割するか」を決める必要があるが、 OFFSET ベースの分割はオフセットが大きくなるほど遅くなり、フルスキャンを誘発する。 一貫性の確保 : 並列に複数コネクションから読む場合、各コネクションが別々の時点を読むと整合性が崩れる。 そこで今回のモジュールでは、 それぞれのデータベースが持つネイティブなバルク転送機構と物理的なデータ配置情報を活用 し、汎用JDBCのボトルネックを回避する設計にしました。 加えて運用上の大きなメリットとして  分割キー（フィルタ条件）の自動抽出  があります。 マイクロサービスごとに膨大なテーブルを扱う環境では、テーブル1つひとつに対して「どのカラムで分割するか」を人手で指定するのは現実的ではありません。 両モジュールはテーブルのメタデータから 主キー（PK）や暗黙の行ID、物理ブロック位置を自動で見つけ出し 、分割範囲の絞り込み条件を組み立てます。 利用者は接続先とテーブル名を指定するだけで、同じ設定が多数のテーブルに横展開することができます。 なぜCloud Spannerでは高いスループットでデータ取得が可能なのか 今回の設計の発想は、既にうまくいっていたSpannerからの取得方法を、TiDBやAlloyDBにも持ち込むことにありました。 そこでまずSpannerが大規模テーブルでも高いスループットを出せている理由を説明します。 Spannerは分散データベースとして、以下の機能を組み合わせています。 PartitionQuery / PartitionRead（Splitベースの自動分割） : Spannerはデータを内部的に  Split （キー範囲＋負荷ベース）へ分割して保持しています。 PartitionQuery  はこのSplit境界に基づいてクエリを複数のパーティションに自動分割します。クライアントはキー範囲などSplitの内部構造を意識する必要がありません。 BatchReadOnlyTransaction（スナップショット一貫性） : 全パーティションの読み取りが、 TimestampBound  で指定した同一スナップショットを参照することを保証します。ロックを取らずに一貫した読み取りができます。 Partition Tokenの分散・並列実行 : 分割結果は シリアライズ可能なPartition Token として返されるため、複数プロセス・複数マシン、そして Beam Worker に配布してそのまま並列実行できます。Apache Beamの  SpannerIO  も内部でこの仕組みを使っています。 Partition Tokenによる自動バージョン保持 : Tokenが有効な間は対象バージョンがGCされないことが保証されるため、クライアント側で明示的なバージョン保護（SafePoint管理）が不要です。 Data Boost（Spanner固有） : Google管理の独立した計算リソースで読み取るオプションで、 本番ワークロードへの影響をほぼゼロ にしつつ弾力的にスケールできます。 これらは「 物理的なデータ配置に沿った自動分割 」「 スナップショット一貫性 」「 分割単位の分散ワーカーへの配布と並列実行 」という構図で成り立っています。Spannerではこれらが高度に抽象化されたAPIとして提供されていますが、 TiDBやAlloyDB(PostgreSQL)にもそれに近いDB固有の機能が存在します 。 このSpannerの機能とTiDBやPostgreSQLの機能は以下のように対応します。 Spanner TiDB（dumpling相当） AlloyDB（PostgreSQL） PartitionQuery（Split境界で自動分割） TABLESAMPLE REGIONS() （TiKV Region境界） ctid 物理ブロック範囲（ pg_relation_size ） BatchReadOnlyTransaction（スナップショット） tidb_snapshot MVCC(Multi-Version Concurrency Control) + TSO(Timestamp Oracle） バッチ読み取り（ ctid スナップショットのズレは許容） Partition Tokenの分散実行 Range条件の分散実行（本記事の設計） Range条件の分散実行（本記事の設計） Partition Tokenによる自動GC保護 tidb_gc_life_time  の引き上げで代替 （該当なし） SpannerのSpannerIOで提供されている「分割 → 配布 → 並列スナップショット読み取り」を、TiDB/AlloyDBではDB固有の機能を組み合わせて自前で構築する、というのが本記事のモジュールの狙いです。 以降その共通の仕組みと各DB向けの実装を見ていきます。 共通アーキテクチャ 両モジュールに共通する基本戦略は次の3ステップです。  TiDBSource / PostgresSource はCloud Dataflow バッチジョブとして実行され、以下3つのステップで役割が分かれます。 テーブルの範囲分割 : 1本のコネクションでメタデータだけを取得し、テーブルを物理的な分割単位（Range）のリストに列挙する 再分配 : 分割単位をPCollectionの「種」として撒き、 Reshuffle でワーカーに再分配する 並列読み込み : 各ワーカーが担当Rangeをネイティブのバルク転送機構で並列に読み取る 以降、TiDBとPostgreSQLそれぞれについて、この3ステップの中身を掘り下げます。まずTiDBから、この3つのステップがどのように実装されるかを見ていきます。 TiDBテーブルからのデータ抽出 TiDB公式ツール dumpling に学ぶ TiDBには  dumpling  という高速なエクスポートツールが公式に提供されています。 TiDBSource の設計は、このdumplingが高スループットを実現している仕組みを参考にしています。 まずはdumpling側の要点を整理します。 テーブルのチャンク分割と並列読み取り dumplingは、1テーブルを丸ごと1クエリで読むのではなく、テーブルをチャンク（範囲）に分割し、各チャンクを独立したSELECTクエリとして並列実行します。 チャンク分割は3段階のフォールバック構造になっています。 戦略 方式 概要 A（最優先） TiKV Regionベース分割 TABLESAMPLE REGIONS()  でRegion境界をチャンク境界にする B（フォールバック） 数値インデックスベース分割 数値型PK/インデックスのMIN/MAXから均等分割 C（最終） テーブル全体ダンプ 分割可能なフィールドがない場合は1クエリ 特に重要なのが戦略Aです。 TiDBではデータがTiKV上で Region（デフォルト96MB単位） に分散配置されます。 dumplingはこのRegion境界をそのままチャンク境界として利用するため、各チャンクが異なるTiKVノードへの読み取りリクエストに分散され、クラスタ全体のI/O帯域を引き出せます。 dumplingの並列実行の仕組み: Producer-Consumer 分割したチャンクを並列に読み出すために、dumplingは内部で Producer-Consumer という構造をとります。登場人物は次の3つです（いずれもdumplingの実装に出てくる用語です）。 Producer（プロデューサ） : テーブルをチャンクに分割し、「このチャンクを読め」というタスクを作り続ける係。dumplingではメインのgoroutineが担当します。先ほどのRegion境界などをもとにタスクを生成します。 Writer（ライター） : 生成されたタスクを受け取り、実際にSELECTを発行してデータを読み出す係。 --threads で指定した数だけ並列に動き、それぞれが独立したDB接続を持ちます。タスクを消費するConsumer側にあたります。 infiniteChan（無制限チャネル） : ProducerとWriterの間をつなぐ、容量に上限のないキュー（待ち行列）。Writerの処理が詰まってもProducerがブロックされず、生成済みのタスクをいくらでも貯めておけます。 このように、タスクを作成する人（Producer）とタスクを実行する人（Writer）を分離し、その間を待ち行列（infiniteChan）でつなぐことで、分割と読み取りを互いに待たせずに並列で回す基本構造です。後述のTiDBSourceは、この役割分担をそのままDataflowの分散モデルに置き換えています。 Snapshot読み取り dumplingはTiDBのMVCC (Multi-Version Concurrency Control)機構を利用し、特定のTSO（Timestamp Oracle）時点の  スナップショット  から一貫したデータを読み取ります。 ロック不要 :  FLUSH TABLES WITH READ LOCK  のような排他ロックが不要で、書き込みをブロックしない。 一貫性保証 : 全Writerが同一時点のデータを読むため整合性が保たれる。 高スループット : ロック競合がないため並列度を上げられる。 加えてdumplingは、長時間のダンプ中にTiDBのGC（Garbage Collection）がスナップショット時点の古いバージョンを回収しないよう、PD（Placement Driver）に対してGC SafePointを登録します。 TiDBの機能を活用したDataflowでの実装 TiDBSource は、dumplingのこれらのアイデアを Apache Beam / Dataflowのモデルに移植 したものです。dumplingがgoroutineで実現していた並列性を、Dataflowの分散ワーカーによる並列性に置き換えています。対応関係は次の通りです。 dumpling TiDBSource (Dataflow) Producerがチャンクタスクを生成 パイプライン構築時に Range のリストを生成 infiniteChan  + 複数Writer goroutine Reshuffle  +  ParDo による分散ワーカー並列処理 各Writerが独立DB接続でSELECT 各ワーカーが @Setup で独自コネクションを確立 TSOスナップショット読み取り TSOを一度取得し全ワーカーに配布 ステップ1: 分割キーの決定とRangeの列挙 パイプラインの初期起動時に1本のコネクションを張り、出力スキーマの確定・スナップショットTSOの取得・テーブルの分割を行います。 ここではメタデータと境界値だけを読み、実データのスキャンは行いません。 分割キーの自動解決  は次の優先順位で行われます。利用者がカラムを指定しなくても、テーブルのメタデータから自動的に決定されます。 利用者が  splitField  を明示指定していればそれを使う なければ 単一カラムの主キー（PK） それもなければ 暗黙の行ID  _tidb_rowid （クラスタードキーを持たないテーブル向け） _tidb_rowid  は、明示的な主キーを持たないテーブルでTiDBが内部的に振る暗黙の行IDです。 これを分割キーに使えるため、主キー設計に依存せず、どんなテーブルでも分割の足がかりを得られます。 Rangeの列挙  は、先述のdumplingの戦略A→B→Cと同じ3段階フォールバックで行います。 戦略Aは、次のSQLでTiKVのRegion境界を取り出します。 SELECT `pk` FROM table TABLESAMPLE REGIONS() ORDER BY `pk` TABLESAMPLE REGIONS() は各Regionの先頭行を返すため、結果の各値が「次のチャンクの下限」になります。 境界値の列 b[1], b[2], …, b[n] から、隣り合う境界で挟まれた半開区間を生成します。 取りこぼしを防ぐため、最初の区間は下側を、最後の区間は上側を開いておきます。 chunk[ -∞, b[1] ), chunk[ b[1], b[2] ), …, chunk[ b[n], +∞ ) TABLESAMPLE REGIONS() はTiDB v5.0以降の構文です。 非TiDBのMySQLや古いTiDBではこのクエリが失敗するため、自動的に戦略B（数値MIN/MAX均等分割）へフォールバックします。 戦略Bは、SELECT MIN(pk), MAX(pk) で取得した範囲を、推定行数とチャンクあたりの目標行数 splitSize から決めた個数で等分します。 chunks = ⌈ 推定行数 / splitSize ⌉ step = (max − min) / chunks + 1 区間 = [min, min+step), [min+step, min+2·step), … , [ …, max] (stepの計算では厳密な切り上げ ⌈(max−min)/chunks⌉ ではなく+1 としています。半開区間 [cutoff, cutoff+step) で走査するため、割り切れるケースでもmax が最終チャンクに確実に含まれるようstep を 1 大きく取っており、実際のチャンク数は chunks 以下になります) ステップ2: Rangeの再分配（Reshuffle） 範囲が決まったら次にワーカーに範囲ごとの処理を並列にさせる必要があります。列挙した Range のリストを並列実行するよう明示的に指定するためにPCollection化した Range の後に、 Reshuffle.viaRandomKey()  を挟みます。  Reshuffle  には2つの重要な役割があります。 fusionの分断 : Dataflowは連続する処理を一つの処理Stageとして結合してしまうことがあります。これがないとDataflowは Create と後続の読み取り ParDo を融合し、Rangeが1ワーカーに偏って並列性が出ません。 ランダムキーによる再分配 : 全Rangeが利用可能なワーカーへ均等にばらまかれ、クラスタ全体に読み取り負荷が分散されます。 これがdumplingの「 infiniteChan から複数Writerがタスクを取り出す」構造に相当します。 ステップ3: 各ワーカーでのスナップショット並列読み取り 各ワーカーは処理開始時（ @Setup ）に自前のコネクションを確立し、パイプライン構築時に取得・配布されたTSOで  tidb_snapshot  をセットします。  全ワーカーが同一TSOを使うことで、分散読み取りでも単一時点の一貫したスナップショットになります 。 TSOの取得は、一貫スナップショットを開始してその時点の論理時刻を読むだけで完了します（トランザクション自体はすぐロールバックします）。 START TRANSACTION WITH CONSISTENT SNAPSHOT;SELECT @@tidb_current_ts; -- ← この値（TSO）を全ワーカーに配布 各ワーカー側では、読み取り前にセッション変数を設定します。 SET @@tidb_snapshot = '<配布されたTSO>'; -- ロックなしで同一MVCC版を読む SET @@session.tidb_enable_paging = ON; -- 大量スキャン時のメモリ使用量を抑制 tidb_enable_paging  はCoprocessorリクエストのメモリ使用量を抑える設定です（TiDB v6.2.0以降はデフォルト有効。変数を知らないDBではスキップ）。 実際の読み取りでは、担当Rangeを分割キーへの 値の範囲条件 に変換してSELECTに組み込みます。 SELECT * FROM table WHERE `pk` >= 1000 AND `pk` < 2000 ここで重要なのは、この条件が 主キー（インデックス）に対する値の比較 である点です。 データベースはこの行値比較を使ってインデックスを シーク し、該当範囲の先頭へ直接ジャンプして必要な行だけを読みます。  OFFSET のように先頭から数え直す必要がないため、どのチャンクも一定コストで読み出せます。 また、読み取りはMySQL Connector/Jの 行単位ストリーミングモード （ fetchSize = Integer.MIN_VALUE ）で行います。 これは結果セット全体をワーカー側メモリにバッファせず1行ずつ取り出す特別な設定で、巨大チャンクでもワーカーのメモリ消費が一定に保たれます。 dumplingがgo-sql-driver/mysqlのストリーミング動作で実現しているのと同じ効果を、JDBC側で引き出している形です。 制約: GC SafePoint dumplingはPDクライアント経由でGC SafePointを登録しますが、これは JDBCコネクションからは到達できません。 そのためTiDBSourceではSafePoint登録を行わず、長時間の読み取りに対しては運用側でクラスタの tidb_gc_life_time を引き上げ、読み取り中にGCがスナップショットのバージョンを回収しないようにする運用方針としています。 AlloyDB（PostgreSQL）テーブルからのデータ抽出 AlloyDBとPostgreSQL互換性 AlloyDBは、Google CloudがPostgreSQL互換で提供するフルマネージドのデータベースサービスです。  ワイヤプロトコルもSQLの方言もPostgreSQLと互換 であるため、クライアントから見ればPostgreSQLそのものとして扱え、標準のPostgreSQL JDBCドライバがそのまま使えます。 さらに  ctid （物理行位置）や  COPY 、 pg_relation_size  といったPostgreSQLの内部機能・システムカタログも利用できます。 したがって、AlloyDBからのデータ抽出は  PostgreSQLの機能を前提に設計できます 。 以下では PostgresSource がPostgreSQLのどの機能を使っているかを説明しますが、その内容は基本的にAlloyDBにも当てはまります。 通常のJDBCクエリ取得との違い PostgresSource も「物理的な分割 → 並列読み取り」という骨格はTiDBと同じですが、データ転送経路とテーブル分割の方式 がPostgreSQL固有の機能に最適化されています。 まず、通常のJDBC経由のクエリ取得との違いを整理します。 観点 通常のJDBC ( SELECT ) PostgresSource ( COPY ... TO STDOUT BINARY ) 転送経路 拡張クエリプロトコル COPYプロトコル（バルク転送専用） 行ごとの処理 パース/プラン/結果整形が走りうる クエリは1回プラン。あとはタプルを連続送出 データ形式 テキスト or バイナリのフィールド単位 バイナリのタプルストリームを直接デコード 並列分割 OFFSET / LIMIT 等（大きいほど低速） ctid 物理ブロック範囲（フルスキャン不要） PostgreSQLの COPY は、もともと大量データのインポート/エクスポートのために用意された専用経路で、通常のクエリ実行に伴う1行ごとのオーバーヘッドを回避できます。 PostgresSource はJDBCドライバの CopyManager API（PGCopyInputStream）を使い、COPY (SELECT …) TO STDOUT (FORMAT BINARY) のバイナリ出力ストリームを受け取って、Avroのレコードへ直接デコードします。 中間のテキスト変換を挟まないぶん、CPU負荷とアロケーションを抑えられます。 PostgreSQLの機能を活用したDataflowでの実装 ステップ1: ctidブロック範囲の列挙 PostgreSQLの全タプルには ctid（物理的な行ロケーション = (ブロック番号, ブロック内オフセット)）が付与されています。 PostgresSource はテーブルを 物理ブロック範囲 で分割し、各範囲を TID range scan で読みます。 分割の計画には実データのスキャンが一切不要です。 ブロック数は、テーブルの実ディスクサイズをブロックサイズで割って求めます。 SELECT pg_relation_size('table'::regclass) / current_setting('block_size')::bigint pg_relation_size  は実ディスクサイズを返すため、統計情報の  pg_class.relpages  推定値よりも正確で、しかもstat呼び出し1回で済みます。 1ブロックあたりの行密度は推定行数（ pg_class.reltuples ）から求め、目標行数  splitSize  に対応するブロック幅を機械的に算出します。  [0, blockCount)  をこの幅で割っていくだけなので、 フルスキャンも OFFSET も不要 です。 行密度 = 推定行数 / ブロック数1範囲のブロック幅 = max(1, round( splitSize / 行密度 )) 範囲 = [0, w), [w, 2w), … , [kw, blockCount) ※最後の範囲は上限を開く 最後の範囲を上限なし（オープンエンド）にしておくことで、分割を計画した後に追記された行も読み取れます。各範囲は ctid の半開区間条件に変換されます。 WHERE ctid >= '(0,0)'::tid AND ctid < '(3,0)'::tid この条件も、TiDBの主キー範囲と同様に物理位置の値による範囲比較です。 PostgreSQL 14以降ではこれが TID range scan として処理され、該当ブロックへ直接シークして必要な範囲だけを読みます。 注意点 :  ctid  は物理的な行位置なので、読み取り中にINSERT/UPDATE（別ページへの移動）/VACUUMが起きると、同じ行を二重に読んだり取りこぼしたりする可能性があります。同期中に更新されないテーブルに対して使うか、バッチ読み取りで一般的なスナップショットのズレを許容する前提で利用します。また、TID range scanはPostgreSQL 14以降のサポートで、それ以前のバージョンでは各範囲がシーケンシャルスキャンにフォールバックします。 ステップ2: Rangeの再分配 TiDBと同様、RangeのリストをCreateで撒き、Reshuffle.viaRandomKey()でワーカーへ再分配します。fusion分断と負荷分散の狙いは同じです。 ステップ3: 各ワーカーでのバイナリCOPY並列読み取り 各ワーカーは、担当Rangeのctid条件を組み込んだSELECTを COPY (…) TO STDOUT (FORMAT BINARY) でラップし、バイナリストリームを受け取ります。 COPY (SELECT * FROM table WHERE ctid >= '(0,0)'::tid AND ctid < '(3,0)'::tid)TO STDOUT (FORMAT BINARY) 返ってくるのはPostgreSQLのCOPYバイナリフォーマットです。 PostgresSource はこれを直接パースします。 先頭の固定シグネチャ（ PGCOPY\n\377\r\n\0 ）とヘッダを読み飛ばし、以降はタプルを1件ずつ読みます。 各タプルは「フィールド数」に続いて、フィールドごとに「長さ（ -1 はNULL）＋値のバイト列」が並ぶ構造で、終端は番兵値（フィールド数 =  -1 ）で示されます。 値のデコードは、PostgreSQLのバイナリ表現をAvroの値へ型ごとに変換します。たとえば次のような処理です。 整数・浮動小数: ビッグエンディアンでそのまま読む numeric : base-10000 のdigit配列から十進数を復元 date  /  timestamp : PostgreSQLエポック（2000-01-01）基準の値をUnixエポック基準へ補正 uuid  /  json  /  jsonb  /  bytea : それぞれの専用処理 これらをドライバのテキスト変換を介さず自前でデコードすることで、転送経路を最短化しています。 なお、IAM認証（Cloud SQL / AlloyDB）にも対応しており、 user 未指定時はワーカーのサービスアカウントをDBユーザとして使い、接続URLに  enableIamAuth=true  を自動付与します。 検証用の12つのカラムを持つ6億件のダミーテーブルデータをAvroファイルとしてGCSに出力するタスクで、6コア並列で8分で処理完了するようになりました。 制約: なぜTiDBSourceのようにワーカー間の一貫性を担保できないのか TiDBSource では tidb_snapshot によって全ワーカーが同一時点を読み、ワーカー間の一貫性を担保していました。一方の PostgresSource では、各 ctid レンジが それぞれ独立したトランザクションで読まれる ため、レンジ間（別接続・別時刻）での一貫性は保証されません。読み取り中にINSERT/UPDATE（ ctid が別ページへ移動）/VACUUMが起きると、レンジをまたいで行の重複や欠落が起こりえます。 PostgreSQLにも一見すると同等の仕組みがあります。 pg_dump の並列モードは、 pg_export_snapshot() でスナップショットをエクスポートし、各ワーカーが SET TRANSACTION SNAPSHOT でそれを取り込むことで、ワーカー間の一貫性を担保しています。 PostgresSource で同じことを今回実現できなかった理由は スナップショットの「寿命」の違い にあります。 TiDB（ tidb_snapshot ） PostgreSQL( pg_export_snapshot() ) 実体 TSO（論理タイムスタンプ＝ただの数値） エクスポート元トランザクションに紐づくスナップショットID 寿命 永続的 （GCされるまで。トランザクション非依存） 一時的 （エクスポート元トランザクションが開いている間だけ有効） 共有方法 数値を渡し、各セッションが独立に SET 元トランザクションが生存中に各セッションが SET TRANSACTION SNAPSHOT で取り込む PostgreSQLのエクスポートされたスナップショットは、 それをエクスポートしたトランザクションが終了するまでしかインポートできません 。 pg_dump の並列モードが成立するのは、単一プロセスのリーダーがダンプ全体の間ずっとエクスポート元トランザクションを開いたまま保持し、自身でワーカーを起動するからです。 PostgresSource が動くCloud Dataflowの実行モデルでは、元トランザクションを 並列読み取りの全期間にわたって保持する場所を確保するのが難しかったのです 。TiDBSourceではランチャーでTSO（数値）がトランザクションと無関係に有効だったためワーカーに配るだけで済みました。 そのため PostgresSource では各レンジ独立読み取りを前提とし、「同期中に更新されないテーブルに対して使う／バッチ読み取りで一般的なスナップショットのズレを許容する」という運用方針にしています。 まとめ: 高スループットを支える設計要素 両モジュールでは、 「テーブルの物理的なデータ配置に沿って分割し、その分割単位を分散ワーカーで並列に読み取る」  という共通する設計思想で実装しました。 以下  SpannerSource （SpannerのPartitionQuery等を活用したモジュール）も加えた各設計要素の比較表です。すでにいずれかのDBに親しんでいる人は別のDBの機能と比較することで関心・理解が深まるかもしれません。 要素 SpannerSource TiDBSource PostgresSource 物理分割の基準 Split境界（ PartitionQuery ） TiKV Region境界（ TABLESAMPLE REGIONS() ） ctid 物理ブロック範囲（ pg_relation_size ） 分割キーの自動抽出 Spannerが自動分割（指定不要） PK /  _tidb_rowid  を自動解決 ctid （全テーブル共通） 分割計画のコスト API呼び出しのみ（フルスキャン不要） 境界キーの列挙のみ（フルスキャン不要） stat呼び出しのみ（フルスキャン・ OFFSET 不要） 範囲の読み取り Partition Tokenを実行 PK値の範囲比較でインデックスをシーク ctid の範囲比較でTID range scan 転送機構 gRPCストリーミング（ executeStreamingSql ） ストリーミングResultSet（ fetchSize=MIN_VALUE ） バイナリCOPY（ COPY ... TO STDOUT BINARY ） 一貫性 BatchReadOnlyTransaction （ TimestampBound ） tidb_snapshot によるMVCCスナップショット バッチ読み取り（ ctid スナップショットのズレは許容） 並列化 Partition Tokenを Reshuffle  +  ParDo で分散 Reshuffle  +  ParDo （dumplingのWriter並列に相当） Reshuffle  +  ParDo バージョン保護 Partition Tokenで自動保持 tidb_gc_life_time  の引き上げで代替 （該当なし） フォールバック Partition Query → 通常Query Region → 数値MIN/MAX → 全体 TID range scan → シーケンシャルスキャン（PG14未満） 汎用JDBCに対する優位性は、(1) 分割キーを自動抽出でき、分割計画も安価なので並列度を素直に上げられること、(2) 各ワーカーの転送がネイティブ機構でCPU/メモリ効率が高いこと、(3) DB固有のスナップショット機構で一貫性を担保できること(TiDB) の3点に整理できます。これらはもともとSpannerSourceがSpannerの機能で実現していた特性を、今回 TiDB / PostgreSQL 固有の機能を組み合わせて再現したものになります。 おわりに 多数のマイクロサービスが抱える大量のテーブルをDWHへ同期するという要件に対し、汎用的なJDBC経路ではなく、TiDBとPostgreSQL（AlloyDB）それぞれの  分散ストレージアーキテクチャや物理データ配置を活かした専用Sourceモジュール  をCloud Dataflow上に実装しました。これは、すでにSpannerからの取得で高スループットを実現できていた「分割 → 配布 → 並列スナップショット読み取り」というパターンを、他のDBにも横展開した取り組みと言えます。 今回は各DBが公式ツール（ dumpling  / pg_dump ）で利用されている高速化のノウハウを参考にさせてもらい、Dataflowの分散実行モデルに取り込みました。「分割キーの自動抽出」「物理配置に沿った安価な分割」「ネイティブなバルク転送」「DB固有のスナップショット」という要素の組み合わせが、大規模テーブルでも高いスループットと一貫性を両立させる助けになりました。 次の記事は cyan さんの「Scaling Myself: How I Run 22 Claude Code Sessions for DS4 Migration」です。引き続きお楽しみください。

p.fontbold{ font-weight: bold; } p.codeboxbefore{ margin-bottom:-70px; } @media screen and (max-width: 575px) { p.codeboxbefore{ margin-bottom:-13.4vw; } } この記事は Merpay & Mercoin Tech Openness Month 2026 の 13 日目の記事です。 こんにちは。Growth Platform Team でメルペイのポイント還元キャンペーン基盤である Santa サービスの開発を担当している @hasegway です。 なお、タイトルに登場する「Otoku Revolution」とは、コード決済を一定回数使うたびに必ず値引き体験が届く新企画のキャンペーン (本記事では「コード決済の回数連動キャンペーン」と呼びます) の社内呼称です。詳しくは本連載 17 日目の @yutaro の記事を楽しみにしていてください。本記事では、長く運用してきた Santa サービスをルールベースの汎用基盤 (以降「Rulebase 基盤」と呼びます) として書き直したリファクタリングの話と、新基盤の最初のキャンペーンとして「コード決済の回数連動キャンペーン」を立ち上げた話を取り上げます。順を追ってお話しする前に、まず Santa という基幹サービスがどのような歴史を経て、どんな負債を抱えるに至ったかについてお話しさせてください。 Santa の歴史 Santa という名前は、初期に 「使った翌日にバッチ処理でポイントを付与する」 サービスだったところから来ています。夜のうちに溜まったイベントを翌朝まとめて配って回る、シンプルな仕組みでした (初期の仕組みについては メルペイのキャンペーンを支えるサンタの秘密 が詳しいです)。 それから何年も経て、今では 1 日数百万イベントを処理し、メルカリ / メルペイのさまざまな利用シーンでポイント付与を行う基幹サービスへと成長しました。この成長の過程で一貫していたのは、 「キャンペーンの種別ごとに専用のイベントパイプラインを実装する」 スタイルで機能を積み重ねてきたことです。それぞれ独自のテーブル、独自のイベントハンドラ、独自の Cap (上限) ロジック、独自のポイント付与フローを持っていました。 2021 年のフィルタリング機能 は「複数の条件を AND/OR で組み合わせる」 発想を Santa に持ち込んだ、汎用化の最初の一歩でした。 2022 年のメルカード常時還元 は、その上に「メルカードステージ別の還元率」「複数月にまたがる Provision (引当金) 管理」 といった精緻なロジックを乗せた大規模なパイプラインで、現在でも Santa 最大のパイプラインです。それでも、キャンペーン本体のコードは CampaignType ごとに別物のままでした。 この構造は当初の要件においては合理的でした。しかしキャンペーン要件の複雑化とともに、コードの再利用性が低い設計による開発速度の低下、バグのキャンペーン別対応による運用負荷の増大といった課題が積み重なっていきました。2025年夏の時点では、Santa エンジニアチーム内でこれら課題への共通理解ができており、次世代キャンペーン構造のラフ設計まで進んでいました。ただし当時はスケジュール上の制約で本格着手を見送り、2025年10月にローンチしたメルカリモバイル向け特典キャンペーンは既存システムを拡張する形で実装しました。 その後、PoCを進め、2025年12月にチーム向けに成果を発表。2026年春にかけて、汎用キャンペーンテーブルにルール評価とアクション実行モジュールを組み合わせた Rulebase 基盤を新規に構築しました。現時点では「コード決済の回数連動キャンペーン」を1件稼働させている段階で、既存のキャンペーン群は引き続き従来の専用パイプラインで動いています。これら既存キャンペーンの段階的な移行は、これから先のフェーズです。 専用パイプラインが抱えた負債 Rulebase 基盤を作る前の Santa は、キャンペーンの種別(CampaignType) ごとに「専用パイプライン」を実装する、というスタイルで成長してきました。代表的なキャンペーン種別と、各種別の代表的なキャンペーン企画は次のとおりです。 キャンペーン種別 主なキャンペーン企画 購入時還元 「買ってお得!dポイント」など メルペイの定額払いの還元 「はじめての定額払いキャンペーン」など メルペイスマートマネーの還元 「初回利用」「カムバックキャンペーン」など メルカード還元 「メルカード常時還元」など これらの種別はそれぞれが、専用のテーブル群、決済や返済を受け取る Pub/Sub の入り口、ビジネスロジックを担う Interactor、ポイント付与履歴テーブルへの書き込みパス、付与上限の計算ロジックを抱えています。また、企画ごとの細かい要件の実現のため、基本のパイプラインの中にさまざまな分岐処理が加えられています。新たにキャンペーン企画を 1 本立てるたびに、これらのさまざまなレイヤーを個別に調査・変更しなければならない、というのが Santa の標準作業でした。 そして、長年運用するなかでこの構造がいくつかの負債を生んでいました。 累積した運用負債 まず、専用パイプラインを実装するスタイルでは、新たなキャンペーン要件のための追加開発が横展開して再利用しづらい問題がありました。また、当初に想定していたキャンペーン要件では考えられなかった新たな要件は、個別実装で対応せざるを得ないこともありました。これらは徐々に開発速度の低下やリグレッションテストの複雑化を招いていきました。特に MercardCampaignType ではこの問題が顕著で、リファクタリングに踏み切る直接的な引き金になりました。 MercardCampaignType が「なんでも置き場」化していった 2022 年にローンチした MercardCampaign パイプラインは、当初「利用ステージ別の還元率」と「清算起点のリアルタイムのポイント付与」を素直に扱うことを想定した、シンプルな常時還元キャンペーン向けの設計でした。 その後、メルカードまわりのキャンペーン要件は急速に広がっていきます。累計購入額連動キャンペーン、メルカリ NFT 決済への対応、メルカード ゴールド、メルカリモバイル契約者向けの特典など、どれも「メルカード保有者・利用者」という共通の文脈はあるものの、設計当時の想定にはなかった要件ばかりです。それでも置き場としては MercardCampaignType が最も適切だったため、これらの新要件は順次 MercardCampaignType の上に実装されていきます。本来シンプルに設計されていた入れ物に想定外の機能が次々と追加され、還元率算出や会計コード指定などの仕組みが本来の用途を超えて流用されるようになっていきました。 ここでは、特に歪みが目に見える形で表面化した3 つの事例 — 累計購入型 (2024 年 9 月)、メルカリ NFT 会計コード差し替え対応 (2025 年 12 月)、メルカリモバイル向け特典キャンペーン (2025 年 10 月) — を順に見ていきます。 累計購入型 と メルカリ NFT 会計コード差し替え 累計購入額連動キャンペーンでは、購入金額が複数のしきい値を順に超えるたびに段階的にポイントが付与されます (例: 累計購入額に応じて最大 P1,500 もらえる)。このキャンペーンが MercardCampaignType に投入され、本来の還元率スキーマに「購入累積トラッカー」型の挙動が乗りました。メルカリ NFT 会計コード差し替え対応では「キャンペーンの各種条件は他と共通にしつつNFT取引のみ会計コードを差し替える」という要件のため、コード内に分岐処理が追加され、キャンペーン設定値が複雑化しました。どちらもメルカード保有者向けの施策ではあるものの、当初想定の責務範囲を超えた要件です。 そして3 例目の、もっとも歪みが大きく出たケースが、メルカリモバイル向け特典キャンペーンです。 メルカリモバイル向け特典キャンペーン (2025 年 10 月) メルカリモバイル向け特典キャンペーンの要件は、 3 種類のメルカードステータス (保有無し / 通常版 / ゴールド) × 4 種類のモバイルデータプラン (4GB / 10GB / 20GB / 40GB) = 12 の独立したキャンペーンパターンが毎月必要、というものでした。 実装上は、本来メルカードステージ別の還元レートを保持するDBフィールドが「データプラン別のレート」の入れ物として流用されました。3 ステータス ×4 データプランの 12 組み合わせを、メルカード用テーブルの行として毎月生成する運用です。 また、お客さまのメルカードステータスやモバイルデータプランは日々変わりうるため変化に合わせて還元レートや月々の上限を計算し直す必要があります。そして、同じお客さまが同月内で別の組み合わせ向けキャンペーンにも二重にマッチして重複付与が起こりうる、というリスクも残ります。後者の重複付与を防ぐために、コード側にはこんな雰囲気のハードコードマップが入りました (簡略化したイメージ)。 // ポイント重複付与防止のため、キャンペーンIDをコードに埋め込み TemporaryCampaignIDMapping = map[string]string{ "202510": "campaign-id-1", "202511": "campaign-id-2", // 毎月追加が必要... そして各所に、データプラン別ステージを判定する if 文が散らばりました。 こうして、毎月 12 パターン分のデータ追加運用が必要な「Temporary」ハードコードマップが本番に居続け（Temporaryとは・・）、モバイル専用ステージを分岐させる if 文がポイント計算・フィルタ評価・API レスポンスに散在し、将来データプランが1つ増えるたびにコード変更とデプロイが必要になり、MercardCampaignType 全体のリグレッションテストも巻き込む、という構造が出来上がっていきます。当初は 「モバイルキャンペーンをアーキテクチャ刷新のきっかけにして抜本対応する」 計画もありましたが、ローンチ期日との両立が難しく、最終的に既存パイプラインを拡張する判断を取りました。当時の制約下では合理的な選択ですが、根本的な構造課題は持ち越し、運用負荷は増えています。 3 事例ともビジネス文脈では筋が通っている一方、「メルカード還元の入れ物」が「メルカード周辺キャンペーン全般の入れ物」として使われ、MercardCampaignType のスキーマと責務範囲が押し広げられてきたのが当時の状態で、そのひずみは無視できない大きさになっていました。 Rulebase 基盤の設計 このリファクタリングそのものは前から検討していたものの、ローンチ責任との両立が難しく、本格着手は半年寝かせています。その間も内部で PoC は進め、本実装で固めた方針は「キャンペーンの挙動を、専用コードから設定データへ」というシンプルなものです。 より具体的には、 「どのようなきっかけで動くか」 (TriggerType)、 「どのような条件でマッチさせるか」 (RuleCondition と、その評価を担う RuleEvaluator)、 「何をするか」 (ActionExecutor) という3 つの軸を、できるだけ atomic な (再利用可能なサイズの) 部品として定義し、その組み合わせで多様なキャンペーン要件に対応する、というのが基本的な発想です。従来のように「メルカードキャンペーン専用のロジックを書き下ろす」のではなく、Trigger / Condition / Action を小さな部品として用意し、キャンペーン定義はその組み合わせとして書く、という発想です。専用パイプライン時代との根本的な違いはここにあります。一度実装した Condition や Action を別の CampaignType から設定値だけで呼び出せたり、動的な条件分岐や繰り返し条件を1 つのキャンペーン定義の中で表現できたりする能力も、ここから生まれます。 全体像 チーム内発表でも、次の対比を使って説明しました。 As-Is (メルカード専用ハンドラの内部に if が積まれている) func (h *MercardCampaignHandler) Execute(event Event) { if user.Stage == StageA { if user.Status == "Active" { if !h.HasReward(user.ID, event.ID) { points = amount * 0.03 h.RewriteRewardHistory(user.ID, event.ID) } } } else if user.Stage == StageB { if user.Status == "Gold" { points = amount * 0.10 if h.HasReward(user.ID, event.ID) { h.RewriteReward(user.ID, event.ID, points) } } } } To-Be (キャンペーン定義は JSON データ、評価エンジンは汎用) { "rule_id": "mobile-std-4gb", "conditions": [ {"type": "user_attribute", "params": {"stage": "Standard", "plan": "4GB"}}, {"type": "period", "params": {"start": "2025-10-01", "end": "2025-10-31"}}, {"type": "payment_attribute", "params": {"transaction_type": "code_payment"}} ], "action": { "type": "ADD_POINTS", "params": {"rate": 0.05, "currency_points": 60, "monthly_cap": 200} } } この JSON を Spanner に永続化したスキーマが次の3 テーブルです。Campaigns 配下に CampaignRules、その配下に RuleConditions を INTERLEAVE IN PARENT で並べる構造になっています。 -- 大枠の宣言: 期間・CampaignType・キャンペーン固有設定 (JSON) Campaigns( CampaignID, CampaignType, StartAt, EndAt, Metadata, ... ) -- 1 キャンペーン内の複数ルール: 何をトリガに、どう集計し、どんなアクションを取るか CampaignRules( CampaignID, RuleID, TriggerType, CalculationType, ActionType, ActionParams (JSON), Priority, Enabled ) INTERLEAVE IN PARENT Campaigns -- 1 ルール内の複数条件: AND/OR グループで合成 RuleConditions( CampaignID, RuleID, ConditionID, ConditionType, ConditionParams (JSON), ConditionGroup ) INTERLEAVE IN PARENT CampaignRules これに対応する評価エンジン (Rule Evaluation Engine) を新設し、以下のような4 層構造の EvaluationData を入力として走らせます。 Layer 内容 Event Data 受信した Pub/Sub イベント Rule & Campaign DB から読んだ CampaignRule + RuleConditions User Data お客さまの属性 (カード種類、利用履歴など) Providers 外部サービスへの DI ハンドル イベントが届いてから付与までの流れは次のとおりです。 Condition/Rule と Action は、新しい種別が必要になったときに対応する実装を追加しておくことで、以降のあらゆるキャンペーン定義から再利用できる仕組みになっています。新規キャンペーンの立ち上げ自体は、すでにカタログに揃っているものの組み合わせで実現できるものであれば、コード変更を伴わずに SQL の INSERT で反映できます。 3 つの軸の中身 ここからは、前述した3 つの軸が Rulebase 基盤の中でそれぞれどう設計されているかを順に見ていきます。 TriggerType — どのようなきっかけで動くか CampaignRules テーブルの TriggerType 列が、各ルールが「どのイベントに反応するか」 を表します。 TriggerType は外部イベントと1対1になるよう定義しており、Pub/Sub から届いたメッセージを内部ドメインのモデルに正規化したうえで、合致する TriggerType を持つルール群を CampaignRules から引き当て、条件マッチングを担う2 段目のハンドラ層に引き渡すところまでが、この軸の責任範囲です。条件評価や副作用はここでは扱わず、後段に切り出しています。 RuleCondition と RuleEvaluator — どのような条件でマッチさせるか CampaignRules に紐づく RuleConditions テーブルには、評価したい条件が1行1 件 並んでいます。各レコードは次の3 つで構成されます。 ConditionType は、その条件がどんな種類の判定をするかを示す分類で、後段でどの ConditionEvaluator にディスパッチするかを決めます。 ConditionParams は、その ConditionType に渡す具体的なパラメータで、種別ごとに必要な引数が違うため、固定スキーマではなく JSON で柔軟に保持しています。 ConditionGroup は、複数の条件を AND と OR で組み合わせるためのグルーピングラベルで、これを使うことで A AND (B OR C) のような複合的な論理式を、フラットな行データで表現できるようにしています。 たとえば「ある期間内で、お客さま属性 B か C のいずれかにマッチしたら成立」 という A AND (B OR C) の条件は、RuleConditions テーブルに次のように 3 行で並びます。 ConditionID ConditionType ConditionGroup グループの意味 A period NULL 単独で AND B user_attribute g1 グループ g1 内で OR C payment_attribute g1 グループ g1 内で OR 評価エンジンの入力は、先に挙げた4 つのレイヤーの情報を1つに束ねた EvaluationData です。ConditionEvaluator 側からは「これさえ読めば判定に必要な値はそろっている」 状態で参照できるようにしてあります。PoC ではここにキャンペーン固有の計算結果も持たせる案を検討していましたが、本実装では「条件評価のフェーズとアクション実行のフェーズで責務を分けるべき」と判断し、 EvaluationData は条件評価に必要な情報だけに絞っています。 評価エンジン本体は、ConditionType ごとの個別判定を担う ConditionEvaluator と、ルール 1 件分の真偽をまとめる RuleEvaluator の 2 段構成です。 下段の ConditionEvaluator は、ConditionType ごとに 1 つずつ実装が用意されており、 EvaluationData を読み取ってその条件 1 件分の真偽を返します。判定は副作用を持たず、外部 API 呼び出しや DB 書き込みは起こりません。 上段の RuleEvaluator は、その上に乗ってルール 1 件分の評価を組み立てます。具体的には、(1) RuleCondition の各行をその ConditionType に応じた ConditionEvaluator に振り分け、(2) 各行が返した真偽を ConditionGroup のセマンティクス (NULL は単独 AND、同じ値どうしは OR、別の値どうしは AND) で AND/OR 合成し、(3) ルール 1 件分の最終的な真偽と、どの条件がどう寄与したかの内訳を返します。返るのは真偽と内訳だけで、計算結果や副作用は含めません。 新しい評価軸が必要になったときは、対応する ConditionEvaluator を実装して ConditionType の enum に登録します。一度カタログに加われば、以降のキャンペーン定義は RuleConditions の 1 行としてその軸を設定値ベースで呼び出せます。 ActionExecutor — 何をするか マッチしたルールに対応する Action を、 ActionType ごとの Executor が実行します。上限計算、ポイント付与ステータスの遷移、ポイント台帳への書き込み、外部へのイベント発行といった副作用は、ここで起こります。Condition / Rule 側は副作用を持たない設計なので、外部に作用するロジックはこの層に集約されます。新しい Action 種別が必要になったときは、対応する Executor を実装して ActionType の enum に登録します。一度カタログに加われば、以降のキャンペーン定義は CampaignRules.ActionType と ActionParams を指定する形で、その Action を汎用的に呼び出せます。 3 軸を支える共通ヘルパー Executor の責務は、Action ごとの副作用そのもの (DB 書き込み、外部 API 呼び出し、PointStatus の遷移など) です。一方で、ポイント計算と Cap (上限) 適用、PointStatus / ProvisionStatus のライフサイクル管理、外部マイクロサービスに渡す冪等キーの生成、設定値テンプレートの展開といった「Action 種別をまたいで毎回必要になる横断的な処理」は、3 軸とは別レイヤーの共通ヘルパーに切り出しています。各 Executor は、自分の Action に応じて必要なヘルパーだけを必要なときに呼び出す形にしてあります。実装したヘルパーはいくつかありますが、代表例を 2 つ挙げます。 PointLifecycleManager (PointStatus / ProvisionStatus のオーケストレーション) ポイント付与にまつわるライフサイクルをまとめて扱うヘルパーです。 お客さまへのポイント付与状態 (PointStatus) と、 会計上の引当状態 (ProvisionStatus) は、それぞれ独立したステートマシンとして表現しています。 上が PointStatus で、 planned で台帳に予定を立て、外部の付与 API が成功すると confirmed 、後処理まで終わると completed に進みます。 planned 直後にキャンセルされた場合は cancelled 、外部呼び出しが失敗した場合は failed に倒れる、というのが主な遷移です。下が ProvisionStatus で、引当が立っていない not_linked から、引当が紐づいた linked を経て、最終的に revoked (引当処理が確定した状態) に遷移するのが主軸です。 旧メルカードパイプラインでは、PointStatus の遷移と ProvisionStatus の遷移がそれぞれポイント付与処理側と引当処理側に分散して実装されていて、両者がどう連動しているかの見通しが悪くなっていました。Rulebase 基盤では、両方のステートマシンを PointLifecycleManager 配下に切り出し、 CompletePoint / ReversePoint / CreateProvision / UpdateProvision / RevokeProvision の各 Action から必要なときに呼び出す形にしてあります。これによって、複数月にまたがる引当が必要なメルカード系のキャンペーンも、引当が不要なシンプルなキャンペーンも、同じ部品の組み合わせでライフサイクルを表現できます。 TemplateExpander (設定値テンプレートの展開) 旧システムには汎用的な文字列テンプレートの仕組みがなく、たとえば会計コードを決済種別ごとに分けて積むような要件が出てくると、会計コードのパターン数だけキャンペーンレコードを別に切るしかありませんでした。本来 1 つのキャンペーンとして扱いたいものをパターン数だけ重複登録する必要があり、運用負荷の原因として積み上がっていた部分です。 これを汎用化するために用意したのが TemplateExpander です。キャンペーン定義のなかに {user_id} / {campaign_id} / {payment_count} といったプレースホルダーを書いておくと、実行時に EvaluationData から取り出した実値に置き換えます。会計コード (たとえば merpay_xxx_campaign-{campaign_id}-{user_status} ) や、ハッシュのシード文字列 ( {user_id}:{campaign_id}:{payment_count} ) などがその利用例です。新しいパターンが必要になったときも、設定マスタ側のテンプレート文字列を差し替えれば、コード変更や追加レコードなしに同一キャンペーンの中で扱えます。 最初の実装事例: コード決済の回数連動キャンペーン ここまでに作った汎用基盤の「入れ物」を使った最初の移行ですが、感覚的には「リスクが低く、運用負荷の高いところ」 から始めたくなります。新しめで蓄積データの少ないものほど移行リスクが下がり、運用負荷が高いほど移行の効果が出やすいからです。当初はメルカリモバイル向けキャンペーンを最初の移行対象に据える予定でした。元々これをアーキテクチャ刷新のきっかけにする案も挙がっていましたし、稼働開始から日が浅く蓄積データが少ない一方で 12 パターンの毎月運用で運用負荷が高い、というまさにスイートスポットの条件に当てはまっていたためです。 ただ、ちょうどそのタイミングで、新規企画として「コード決済の回数連動キャンペーン」 の話が立ち上がります。新規企画であれば、常時稼働している既存パイプラインを止めずに載せ替える、というコストを払わずに、最小構成で「設定値ベースでキャンペーンを組み立てる」 ことの検証ができます。結果として、最初の事例は移行ではなくゼロからの立ち上げに振り直し、本企画のキャンペーンを Rulebase 上で直接立ち上げる形で進めました。既存のメルカリモバイルなどの移行は、先のフェーズに持ち越しています。 この新規企画は、N 回利用するごとに付与が発火するシンプルな仕組みで、お客さまから見ると「使い続けるほど、確実に値引きが返ってくる」体験になります。 これをRulebase上で組むにあたって必要だったのは 累計カウントと周期報酬を扱う ActionType （ COUNT_AND_REWARD ）を 1 つだけ追加することだけでした。あとは 既存の ConditionType (期間 / お客さま属性 / 決済属性) の組み合わせで実装できた点です。Rulebase 上で「ルール評価とアクション実行を最大限再利用し、なるべく設定値だけで組み立てる」形を、最初に検証できたケースになりました。 仕組み自体はシンプルです。お客さまのエントリ状況を「お客さま属性条件」で見て、対象決済を「決済属性条件」で絞り込んだうえで、 COUNT_AND_REWARD Executor がカウンタをインクリメントします。カウンタが規定回数に達するとポイントを付与してカウンタをリセットし、これをキャンペーン期間中ずっと繰り返す、という流れです。データとしては、Campaigns 1 行、CampaignRules 1 行、RuleConditions 数行、というシンプルな構造で表現できます (簡略化したイメージ)。 // Campaigns { "campaign_id": "...", "campaign_type": 9, // InfinitePayment "start_at": "2026-04-01", "end_at": "2026-09-30", "metadata": { ... } } // CampaignRules (1 件) { "trigger_type": "PaymentCharge", "action_type": "COUNT_AND_REWARD", "action_params": { "trigger_count": 3, "reward_currency_points": 100 } } // RuleConditions (3 件: 期間 / エントリ状況 / 決済種別) { "condition_type": "period", "params": { ... } } { "condition_type": "user_attribute", "params": { "attribute": "entry_status", "promotion_key": "..." } } { "condition_type": "payment_attribute", "params": { "attribute": "transaction_type", "value": "code_payment" } } 実装上の新規追加は COUNT_AND_REWARD Executor と、カウンタを保持する 2 つのテーブル (現在のカウントとログ) くらいです。他は基盤の汎用部品をそのまま組み合わせて完結しました。 補足として、この回数連動キャンペーンの意義は「単純なキャンペーン派生がやりやすくなった」ことではありません。SQL INSERT で似たキャンペーンを増やすこと自体は、従来の専用パイプライン時代でもそれなりにできていました。Rulebase 基盤で新しく可能になったのは、CampaignType をまたいだ Rule・Action の設定ベース再利用です。一度実装した Condition や Action は、別の CampaignType のキャンペーンからも設定値の組み合わせで呼び出せます。回数連動キャンペーンで使った COUNT_AND_REWARD も、他のキャンペーンが「累積回数で発火する」要件を持てば、コードを書き足さずに設定だけで使い回せます。 同じ仕組みは、動的な条件分岐を 1 つのキャンペーン設定で表現することにも転用できます。たとえばメルカリモバイル向けキャンペーンでは「3 ステータス × 4 データプラン」を 12 個の独立キャンペーン定義として毎月準備していましたが、Rulebase なら属性条件・繰り返し条件・上限条件を組み合わせて 1 つのキャンペーン設定の中で表現できます。「N 回ごとに発火」のような周期的な振る舞いも、 COUNT_AND_REWARD を Executor 側に持つことで汎用パーツとして扱えます。今後の新企画では、既存のルール・アクションの組み合わせで表現できる範囲が広がっているかぎり、ゼロからの実装ではなく「設定値だけで作って試す」ところから入れる、というのが新基盤の最大のメリットです。 余談: ランダムなのに、何度引いても同じ金額 仕様としては 「規定回数に到達したら、複数の候補金額から重み付きランダムで 1 つを引き当てる」 という要件があります。素直に math/rand で抽選してしまうと、Pub/Sub の at-least-once 配信下では同じ PaymentCharge が再配信されたときに 1 回目と 2 回目で別の金額が選ばれてしまうことがあります。PointID ベースの冪等性チェックは通っているのに、2 回目の試行から見える金額が初回付与額とずれる、というケースが起きうる構造です。 そこで抽選は乱数ではなく決定論的ハッシュで行いました。 user_id ・キャンペーン識別子・ payment_count を組み合わせた文字列をシードに、SHA-256 でハッシュ化したものから重み付きで候補を 1 つ選びます。アルゴリズムの概略は次のとおりです (簡略化したイメージ)。 // seed の例: "12345:campaign-abc:3" (user_id : campaign_id : payment_count) seed, _ := expander.Expand(params.DeterministicReward.SeedFormat) h := sha256.Sum256([]byte(seed)) v := binary.BigEndian.Uint64(h[0:8]) // 先頭 8 バイトを uint64 として取り出す var totalWeight uint64 for _, rv := range variations { totalWeight += rv.Weight } target := v % totalWeight // 重みの合計で割った余り (これが候補選択用の値) var cumulative uint64 for i, rv := range variations { cumulative += rv.Weight if target < cumulative { return rv, i // 累積重みで当たった候補を選択 } } お客さまから見た「使うたびに違う金額が返ってくる」体験はそのままに、同じ (user_id, campaign_id, payment_count) の組み合わせに対しては何度 retry が走っても、別プロセスから読まれても、同じ金額が一意に確定します。 そして、シードさえ揃えば抽選結果は確定値なので、Pub/Sub のイベント処理完了を待たずに「今回付与される金額」を計算できます。決済成功直後の API レスポンスやフロントエンド側で「今回は ○ ポイントです」と確定表示を返すことができ、後段で UserPoints が書かれたあとに金額が変わって見える、といった不整合の心配もありません。at-least-once と weighted random を両立させるための仕組みが、お客さまへの早い表示にもそのまま使える形になっています。 QA 環境の改善に助けられた話 今回の QAではいくつかの環境パターンを切り替えて実施する必要があり、工数ボリュームに不安を感じていました。ちょうど良いタイミングで今まで Santa サービスでは実現できていなかった「イベント駆動部分専用の QA 複製環境」をチームメンバーが作りきってくれたことで、並行して QA を実施できるようになり、大変助かりました。その詳細は本連載 8 日目の @mikupo の記事 で詳しく解説されています。 おわりに 今回のリファクタリングでは、「キャンペーン定義をコードからデータへ」 という方針のもと、3 テーブル + 評価エンジンに再構成しました。ローンチ責任との両立で半年寝かせていたリファクタリングの機会を諦めずに掴んで「入れ物」を作り切って本番でキャンペーンをひとつ稼働させたことで、システムに今後の新要件についての受け皿を作ることができました。 ただし、回数連動キャンペーン自体は本記事執筆時点ではローンチしたばかりで、まだ派生キャンペーンの実例はありません。設定だけで派生が立ち上がる世界の本格検証は、これからの新企画を通じて行っていくフェーズです。加えて、メルカード常時還元などの既存のパイプラインもまだ稼働しており、Temporary マップも本番に残ったままです。常時稼働するキャンペーンシステムでは、入れ物を作る難しさよりも、止めずに載せ替えるタイミングと手順の設計こそが、ここから先の本題になります。 今回の記事は以上になります。なにか参考になることがあれば幸いです。 次の記事は orfeon さんの「TiDB / AlloyDB の大規模テーブルを高速にBigQueryni同期するための工夫」です。引き続きお楽しみください。

DBRE(DataBase Reliability Engineering)チームの@coyamaとIDP(IDentity Platform)チームの@taskです。 メルカリでは2026年5月14日から2026年5月15日まで開催されたクラウドネイティブ会議にスポンサーとしてブース出展しました。2日間で125名にクイズへ参加いただき、想定以上に“認証”や“マイクロサービス規模”といった話題で多くの議論が生まれました。本記事では、ブースの展示内容やクイズやアンケートの結果に加えて、来場者とのやり取りや感想を紹介します。 メルカリブースの展示 メルカリの技術面の取り組みを参加者に認識いただくために、有志のエンジニアが中心となりブースを設計しました。メルカリのブースでは主に以下を展示しました。 メルカリの技術スタックのクイズ/アンケート メルカリのアーキテクチャ変遷やKubernetesクラスタでのパケットキャプチャに関するポスター AI SecurityのLLM Key Serverに関するスライド クイズ/アンケートに回答いただいた方には、メルカリのストラップやボールペン、マスキングテープをプレゼントしました。メルカリのストラップは、参加者から「メルカリらしいノベルティ」というコメントもあり好評でした。 メルカリのアーキテクチャ変遷のポスターでは、以下の転換点について展示をしていました。 データセンターからパブリッククラウドへの移行 アプリケーションのKubernetesへのデプロイ モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行 マイクロサービスアーキテクチャの課題とモジュラーモノリスの取り組み 「モノリシックアーキテクチャからマイクロサービスアーキテクチャに移行する際に、どうシステムを分割すべきか」や「マイクロサービスアーキテクチャの課題は何か」といった議論ができました。また、他社でもメルカリと類似した課題に直面していることを改めて認識しました。 ブースの展示内容に関連した資料は以下に公開されています。 SRE視点で振り返るメルカリのアーキテクチャ変遷と普遍的な考え – Speaker Deck It’s Not Always the Network (But Here’s How to Prove It): Kubernetes Packet Capture for SREs | USENIX LLM Key ServerによるLLM APIへの安全で便利なアクセス提供 | メルカリエンジニアリング メルカリのテックスタックに関するクイズ 今回のクイズは、メルカリが日々向き合っているサービス全体やテックスタックについて興味を持ってもらうべく、全4問で構成しました。特定のディープなインフラ技術に寄るのではなく、広めのプラットフォームエンジニアリングに関する話題について広くカバーしつつ、ユーザが実際に目にするプロダクト寄りの問題も含めてみました。　その結果、広めのテックスタックをカバーした中〜高程度の問題セットになりました。 そして、クラウドネイティブ会議中にて2日間で125名の回答をいただき、分布は以下の通りでした。中央値は2点で、4点満点を取ったのはわずか9名のみだったため、なかなか手応えのあるクイズになっていたと思います。 また、それぞれの回答の分布は以下の通りでした。 出題した問題の中で、特に注目を集めたのが以下のログイン認証方法に関する問題です。 メルカリで利用されているログイン認証方法の上位3つを使用頻度の高い順にあげてください。 What are the top three login authentication methods used in Mercari, ranked from most to least used? Google+SMS > Password+SMS > Facebook Password+SMS > Passkeys > Google+SMS Password+SMS > Apple > Passkeys Passkeys > Password+SMS > Email Link これはクイズ作成時の情報なのですが、この回答について「一般的な Web サービスをイメージすると、パスワードやソーシャルログインが上位を占めると思いがちなので意外だった」「パスキーの普及率が意外と高いのが面白い」といったコメントが多かったです。普通はこうだろうという先入観で答えると間違えてしまう問題だったので、メルカリが技術で攻めた良い事例なのかもしれません。 また、こちらのログイン認証方法について、メルカリは 2023 年からパスキーログインの普及率拡大を推進しているため、最新のメトリクスによると Passkeys > Password+SMS > Google+SMS に順位が変わっています。 メルカリ、すべてのログインに 生体認証「パスキー」を導入 | 株式会社メルカリ また、他にも管理されているマイクロサービス数に関する問題についてもコメントをいただくことが多かったです。 メルカリの microservices-terraform リポジトリでは、多数のサービス群がInfrastructure-as-Codeとして管理されています。その管理下にあるサービスの総数はいくつでしょうか？ The microservices-terraform repo manages Infrastructure-as-Code for a large portfolio of services. What is the total number of services managed in this repo? 100 – 250 services 250 – 500 services 501 – 1000 services more than 1000 services 特に、「想定よりも多くのマイクロサービスを抱えているのに驚いた」「多くのマイクロサービスを抱える上での新たな課題は何か」と言ったコメントが多かったです。こちらの変遷については SRE視点で振り返るメルカリのアーキテクチャ変遷と普遍的な考え – Speaker Deck でも触れられている通りで、こちらの資料を肴にブースにおけるディスカッションが起きたのが面白い点でした。 いずれにせよ、どのクイズにおいても新しいディスカッションや雑談のネタになったため、このようなメルカリ独自のトピックにおける広めのクイズ設定は狙い通りでした。 Cloud Native Kaigiでのブース出展を終えて 今回のクラウドネイティブ会議では、本当に多くの方にメルカリブースへお立ち寄りいただきました。セッションの合間の休憩時間にはブース前が熱気に包まれる場面もあり、運営メンバー一同、クラウドネイティブ・コミュニティの圧倒的な熱量を直接肌で感じることができました。 (coyama) メルカリからもプラットフォームエンジニアリングに関わる複数のチームのメンバーが参加していました。そのため、参加者から寄せられた幅広い質問に対応できる体制で、2日間を終えることができました。例えば、DBREに関する質問では、「メルカリのテックブログでTiDB Auto Scalerの記事を読んで参考になった」という声をきっかけに、トラフィックパターンについて議論することができました。また、セキュリティに関する質問については、セキュリティエンジニアに回答してもらうことで、うまく役割分担ができていました。複数のチームからメンバーが集まることでプラットフォームエンジニアリングやSREに関する幅広いコンテンツを提供できたのは良かったと思います。 (task) ブース運営を通して特に印象的だったのは、今回の「テックスタッククイズ」が単なるエンタメで終わらず、 そこからディープな技術的ディスカッションへと発展したこと です。 例えば、正答率が低かったTerraformのMonorepoに関する問題をきっかけに、「実際、数百のサービスが相乗りしている状態で、CIの実行速度やデプロイの安全性はどう担保しているんですか？」「うちの会社でもプラットフォーム基盤をどう切り出すかで悩んでいて……」といった、現場のエンジニアならではのリアルな悩みや知見の交換が、ブースのあちこちで自然発生していました。 問題の難易度に「うわっ、ガチなやつだ…（笑）」と頭を抱えつつも楽しんでくださる参加者の皆さんの姿や、「メルカリのプラットフォームって、ここまでプロダクトの体験（パスキー等）に踏み込んで作り込まれてるんですね！」という驚きの声は、日々大規模なシステム基盤と向き合っている私たちにとって、何よりのモチベーションになりました。 社外の優秀なエンジニアの方々と直接お話しし、フィードバックをいただけたことは、チームにとっても非常に大きな刺激となりました。 改めて、ブースに足を運んでくださった皆様、そして難問クイズに挑戦してくださった125名の猛者の皆様、本当にありがとうございました！ メルカリでは、今回出題したような「プラットフォームからプロダクトまで」を跨ぐような大規模で複雑な技術課題に、一緒に立ち向かってくれる仲間を絶賛募集しています。 「今回のクイズの内容、もっと詳しく聞いてみたい！」「自分ならもっと良いアーキテクチャにできる！」と興味を持ってくださった方、ぜひ以下のリンクからカジュアルにお話ししましょう！お待ちしています！ 株式会社メルカリ 採用情報 7/8(水)14:00- Mercari AI Career Fes 2026 – connpass