Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
freee申告の税額計算を支える技術 / freee tech day 2023
Search
mosa
April 19, 2023
Programming
1
23k
freee申告の税額計算を支える技術 / freee tech day 2023
mosa
April 19, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
エンジニアのための”最低限いい感じ”デザイン入門
shunshobon
0
110
サイトを作ったらNFCタグキーホルダーを爆速で作れ!
yuukis
0
330
Constant integer division faster than compiler-generated code
herumi
2
650
decksh - a little language for decks
ajstarks
4
21k
バイブコーディングの正体——AIエージェントはソフトウェア開発を変えるか?
stakaya
5
930
The state patternの実践 個人開発で培ったpractice集
miyanokomiya
0
100
TROCCO×dbtで実現する人にもAIにもやさしいデータ基盤
nealle
0
190
Portapad紹介プレゼンテーション
gotoumakakeru
1
130
一人でAIプロダクトを作るための工夫 〜技術選定・開発プロセス編〜 / I want AI to work harder
rkaga
12
2.6k
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
10
1.7k
State of CSS 2025
benjaminkott
1
100
GitHub Copilotの全体像と活用のヒント AI駆動開発の最初の一歩
74th
7
2.8k
Featured
See All Featured
A better future with KSS
kneath
239
17k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Music & Morning Musume
bryan
46
6.7k
GitHub's CSS Performance
jonrohan
1031
460k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Agile that works and the tools we love
rasmusluckow
329
21k
Producing Creativity
orderedlist
PRO
347
40k
Adopting Sorbet at Scale
ufuk
77
9.5k
The Pragmatic Product Professional
lauravandoore
36
6.8k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Code Review Best Practice
trishagee
69
19k
Transcript
freee申告の 税額計算を⽀える技術 mosa 2023年4⽉16⽇
ここに円に切り抜いた画像を入れてく ださい mosa Software Engineerとして数社を経て2022年 にfreee⼊社。現在はfreee申告の開発を担 当。 Webアプリケーションエンジニア
freee申告
税額計算とは • [16]と[17]を⼊⼒すると[18]は⾃動で計算されて表⽰される
税額計算とは • 他の帳票にも値は連携され更新先や更新元が複数あることも
項⽬間の依存は⼤量にある... •
どのように税額計算をしているか • RelationalTreeという税額計算をするためのモジュールを作成 • RelationalTreeは名前の通り項⽬間の関係を⽊構造として動的に組み ⽴てながら計算を⾏う
RelationalTreeの動作例 A C D B 下記のような1項⽬を表す
項⽬Aをユーザーが⼿動で⼊⼒ A C D B 未到達 更新対象 差分あり 差分なし
⾊の意味 キュー
A(root node) をキューに詰める A C D B 未到達 更新対象
差分あり 差分なし ⾊の意味 キュー A
キューからAを取り出して計算 A C D B 未到達 更新対象 差分あり 差分なし
⾊の意味 キュー A • 今回はユーザーが A を⼊⼒したとしているのでAはユーザーの⼊⼒値となり、 差分ありになる
Aが差分ありなのでAに依存する項⽬ (B, C) を取得してキューに詰める A C D B 未到達
更新対象 差分あり 差分なし ⾊の意味 キュー A B C
A C D B 未到達 更新対象 差分あり 差分なし ⾊の意味
キュー A B C キューの先頭から B を取り出して計算 • 今回は計算の結果、差分があったとする • Bに依存している項⽬は無いので差分ありでもキューに詰める項⽬は無い
A C D B 未到達 更新対象 差分あり 差分なし ⾊の意味
キュー A B C キューの先頭から C を取り出して計算 • 今回は計算の結果、差分はなかったとする • Cに依存している項⽬はあるが差分は無いためキューに詰めない
A C D B 未到達 更新対象 差分あり 差分なし ⾊の意味
キュー A B C キューが空になったので計算処理を終了してDBに書き込む • 今までの計算によって得られた A, B の差分はメモリ上に保持してある
RelationalTree動作まとめ 1. 根 (root_node) となる項⽬の計算を⾏う 2. 計算前後で差分があるか確認し、差分がなければ終了する 3. その項⽬に依存している項⽬を取得してキューに詰める
4. キューにある先頭の項⽬について計算を⾏う (FIFO) 5. 2.に戻る
RelationalTree作成の背景 • 帳票が増えていく中で「1回のリクエストで税額計算に数⼗秒かか る」というパフォーマンス的な問題が発⽣ • ⼀項⽬ずつ⼿続き的に計算→保存を繰り返すことで DB の read/write
処理が膨⼤な量になってしまい結果として数⼗秒かかってしまった
RelationalTree作成後 • 問題を解決するためにRelationalTree は下記のアプローチをした ◦ メモリ上に計算過程の結果を保持し最後にまとめてwriteする ▪ → write回数の減少
◦ 差分が無い項⽬については依存する項⽬の再計算を⾏わない ▪ → 計算回数の減少 RelationalTreeの導⼊によって数⼗秒かかっていたリクエストが、遅く ても数秒以内に返ってくるようになった!
すごい!!!!
RelationalTreeの課題 • パフォーマンス最適化の余地 ◦ 動的に⽊構造を作成しているため read 処理が多い ◦ 部分⽊の計算が繰り返し⾛ることがある
◦ 同期的な計算が強制されてしまう • 計算結果の品質担保 ◦ 複数ユーザーが同時に触った時の挙動が担保されていない • 依存関係の表現⽅法 ◦ 依存関係が有向⾮巡回グラフであることを強制できていない
RelationalTreeの 改善は続く!
None