稼働中サービスの大規模データをどう移すか。仕訳帳検索のOpenSearch移行

freee 技術の日 2026のセッション資料です。

Transcript

2. 稼働中サービスの⼤規模データをどう移すか。 仕訳帳検索のOpenSearch移⾏ 萩本 康⼼（hagi） 2026年10⽉3⽇
3. 会計申告開発本部 業種特化部 エンジニア 萩本 康心（hagi） 2025年4月に新卒でfreeeに入社。 freeeホームページ の立ち上げ後、 現在までfreee会計の開発に従事。
4. 仕訳帳の検索が 速くなりました
5. 仕訳帳の検索が速くなりました 仕訳帳検索のレイテンシ（p99） 20s 約12秒 15s 10s 約4秒 5s RDB での検索を OpenSearch に移して、p99 が約12秒 → 約4秒
6. ただ、今⽇の主役は 検索ではありません 主役は、動いているサービスの数⼗億件をどう移したか
7. 今⽇のゴール ⽌められないサービスで、数⼗億件をどう移すかを理解する
8. 01 仕訳帳とは？
9. すべての仕訳が記録される、最も件数の多い帳簿 仕訳帳の画⾯（スクリーンショット） 会計データは消えない。過去の仕訳は残り続ける
10. 数⼗億件、100万を超える事業所 数⼗億件 100万超 1⽇20万超 仕訳 事業所 仕訳帳の検索 件数は増え続ける
11. 02 なぜ移⾏したのか？
12. テキスト検索が重く、 データの多い事業所ほど刺さる 部分⼀致検索はインデックスが効かない。 データの多い事業所ほど線形に悪化する 検索結果が返るまで、p99 で 12秒
13. そして、条件を⾜せなかった 承認ステータスは別のマイクロサービスが持つ。JOIN で絞り込めない 詳細な「承認状態で検索したい」に、実装で応えられない
14. 03 どうやって同期しているか？
15. 仕訳は、会計DBに書かれる 会計API / Web 登録 会計DB
16. Outbox パターン ― 同じトランザクションでイベント⾏も書く 会計API / Web 登録 会計DB ＋ outbox テーブル 業務処理と同じコミットに乗せる 業務データとイベントが同⼀トランザクション。at-least-once を保証できる
17. 別プロセスが拾って、OpenSearch に⼊れる 会計API / Web 登録 会計DB ＋ outbox テーブル 読む 登録 Indexer 業務処理と同じコミットに乗せる outbox テーブルをポーリングし、Bulk API で投⼊する Open Search
18. ドキュメント1件に、3つの社内サービスを叩いている 会計API / Web 登録 会計DB ＋ outbox テーブル 読む 登録 Indexer Open Search ファイル基盤 証憑情報 コメント基盤 コメント情報 業務処理と同じコミットに乗せる 承認基盤 申請状態 1ドキュメント = 3リモートコール
19. 04 何が難しかったのか？
20. 過去の分が、空のまま 同期は動き出した。しかし OpenSearch には過去の仕訳が⼊っていない 数⼗億件のバックフィル（初回同期）が要る
21. ⻑くても2週間だと思っていました 根拠は、数年前に社内でやった取引データの移⾏ 仕訳は freee の中でもトップクラスのデータ量。 この規模を移した経験は、社内にもなかった
22. 1 Pod で数時間流して、計算し直した goroutine の並列数を上げながら実測 このペースなら、1年
23. 05 どうやって流し切ったか？
24. goroutine を増やせば済むと思っていた Pod 1つの Pod の中で、ドキュメント⽣成を goroutine の worker pool で並列化
25. ある並列数から、速くならなくなった 並列数を上げても、スループットが伸びない
26. 待っていたのは、CPU ではなくネットワークだった 承認基盤 ドキュメント ⽣成 ファイル基盤 応答を待っている コメント基盤 1件ごとに、依存サービスからの応答を待つ。 待っている間、プロセスは何もしていない
27. Pod を増やすしかなかった Pod Pod Pod 送信元を増やせば、並⾏して待てる ただし増やしすぎると、今度は相⼿がリクエスト過多で倒れる Pod
28. そして、Pod を 1 → 2 → 4 と上げていった Pod 1台 2台 負荷を⾒ながら、段階的に 4台
29. ⾒ていたのは、4つのDBと OpenSearch Pod 1台 2台 4台 負荷を⾒ながら、段階的に ⾒ていたもの 会計DB コメント基盤 承認基盤 認証基盤 CPU‧DBロード‧接続数∕JVMメモリ圧‧エラー率‧IOPS OpenSearch
30. 落ちる前提で作り、 ⽌める⼿段を先に⽤意する 未処理の事業所だけを取り出すカーソル⽅式。処理は冪等 キルスイッチを⽤意し外から⽌められるようにした ループが定期的にフラグを⾒て、安全な位置で⽌まる
31. 1年規模の⾒積もりが、 1ヶ⽉半で終わった
32. 06 結果
33. 仕訳帳の検索が速くなりました 仕訳帳検索のレイテンシ（p99） 20s 15s 10s 約12秒 約4秒 5s RDB での検索を OpenSearch に移して、p99 が約12秒 → 約4秒
34. そして、できなかった検索ができるようになった 仕訳帳の検索フォーム（スクリーンショット） コメント検索‧詳細な承認状態での検索が実装できるようになった
35. 07 まとめ
36. この事例から学べること 1 移⾏のボトルネックは、⾃分のDBではなく他⼈のサービスにある 計画を⽴てる前に、1件あたり誰に何回問い合わせるかを数える 2 並列度は、叩く先の実測で決める ⾃分のDBだけでなく、叩きに⾏く先の負荷を並べて⾒る 3 移⾏バッチは、必ず途中で死ぬ前提で作る ⼀度で流し切る設計にしない。⽌めるスイッチを先に作る