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
うちの技術負債2021_freee会計編
Search
yo_waka
September 14, 2021
Technology
0
1.1k
うちの技術負債2021_freee会計編
「うちの技術負債2021」 で発表した資料です
https://techplay.jp/event/828672
yo_waka
September 14, 2021
Tweet
Share
More Decks by yo_waka
See All by yo_waka
大きなプロダクトの育て方
waka
10
26k
requireの循環参照
waka
0
1.4k
Other Decks in Technology
See All in Technology
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
6
2.3k
解析の定理証明実践@Lean 4
dec9ue
0
180
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
260
Snowflake Summit 2025 データエンジニアリング関連新機能紹介 / Snowflake Summit 2025 What's New about Data Engineering
tiltmax3
0
310
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
290
TechLION vol.41~MySQLユーザ会のほうから来ました / techlion41_mysql
sakaik
0
190
How Community Opened Global Doors
hiroramos4
PRO
1
120
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
170
~宇宙最速~2025年AWS Summit レポート
satodesu
1
1.9k
“社内”だけで完結していた私が、AWS Community Builder になるまで
nagisa53
1
400
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
220
地図も、未来も、オープンに。 〜OSGeo.JPとFOSS4Gのご紹介〜
wata909
0
110
Featured
See All Featured
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Why Our Code Smells
bkeepers
PRO
337
57k
Unsuck your backbone
ammeep
671
58k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Stop Working from a Prison Cell
hatefulcrawdad
270
20k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Designing for Performance
lara
609
69k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Rails Girls Zürich Keynote
gr2m
94
14k
Gamification - CAS2011
davidbonilla
81
5.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Transcript
うちの技術負債2021 freee編 2021.09.14 freee 株式会社
2 2013年6月 freee株式会社へ入社 freee会計のエンジニア => freee会計のエンジニアマネージャ => 人事労務含めた既存プロダクト全体のマネージャ という変遷を辿っています
もともとフロントエンドエンジニアなのでJavaScript関連の技 術を触ったりするのが好きです 今日はプロダクトと会社が大きくなっていく中で対応してき た(せざるを得なかった)技術的負債の話をします! 若原 祥正 freee株式会社 執行役員 プロダクトコア開発本部長 @yo_waka
3 01 freeeの紹介 02 freee会計について 03 負債代表作 04 改善の様子 アジェンダ
スモールビジネスを、 世界の主役に。
5 freee会計 freee開業 freee福利厚生 freeeアプリストア freee人事労務 freee会社設立 freeeスマート受発注 freeeプロジェクト管理
freee資金調達 freee申告 freeeカード プロダクトラインアップ
6 2021年前年比 +34.2 % 2013年 3月 2014年 3月 2015年 3月
2016年 3月 2018年 3月 2019年 3月 2020年 3月 2021年 3月 2017年 3月 有料課金ユーザー数は28万社を超える
7 01 freeeの紹介 02 freee会計について 03 負債代表作 04 改善の様子 アジェンダ
8 freee会計 会計といいつつ会計に繋がる業務(申請・承認、受発注、資金繰りetc)もいろいろサポート = 非常に機能数が多い
9 • バックエンド ◦ Railsアプリケーション + いくつかのマイクロサービス(後述) ◦ freee人事労務など他サービスとだいたい連携 ◦
銀行やクレジットカードの明細を取得するような機能も内包している ▪ これ自体はマイクロサービスへの切り出しが進んでいる • フロントエンド ◦ 基本的にReact + hooksなコンポーネント ◦ 以前のRailsのデフォルトだったCoffeeScriptが一部残っている • データストア ◦ RDBにAurora MySQL、高速化したい箇所はElasticsearchやDynamoDB等も使っています • インフラ ◦ EKS上で運用 freee会計の基本的な構成
10 freee会計のコード規模感 テーブル数 800くらい Ruby ファイル数 12000くらい JavaScript ファイル数 7000くらい
エンドポイント数 4000くらい 1ヶ月のコミット数 2000くらい 1ヶ月のプルリクエスト数 1000くらい
11 • 普通のマルチテナント構成 • 1億レコード以上あるテーブルが23テーブル ◦ 最大レコード数は17億レコードくらい ◦ auto increment
idはbigintにしないともう動きません ◦ MySQLはすごい • 毎年130%くらいのペースでデータが増える • 読み込みトランザクション以上に書き込みトランザクションが多いのが特徴かもしれません freee会計のデータ規模感
12 01 freeeの紹介 02 freee会計について 03 負債代表作 04 改善の様子 アジェンダ
13 最初は1つのアプリケーションだったが・・ サービスが増えるとまず共通で持ちたい機能があります。そう、認証/認可ですね 同じ会社のサービスはやはり同一アカウントで入れるようにしたい freee会計 freee会計 freee人事労務 認証/認可サービス
14 最初は1つのアプリケーションだったが・・ 期間的に厳しくてデータが残っちゃいました スタートアップ時は早く出さないと会社が死ぬ。実際その後数年はあまり実害はなかった しかしサービスが5つ10つと増えていくとSPOF化が進んでいって死を感じるようになってきます freee会計 freee会計 freee人事労務 認証/認可サービス 会計DB
15 サービスが増えるごとに生産性の観点でも共通で持ちたいサービスは増えてきます ミッションクリティカルなものが多く、最初からパフォーマンスが求められるため、柔軟な技術選定を行うため に専門のチームが必要 認証/認可の真切り出しをやるぞ!というタイミングでアプリケーション基盤チームが社内に誕生 アプリケーション基盤チームを作るきっかけに 会計 人事労務 プロジェクト管理 認証/認可
課金 申請/承認
16 様々な理由で無茶しやがってという箇所が増えていきます • サービスクラスに渡すデータが巨大で中身読んでいかないと構造がわからない • いつの間にかレスポンスの構造が変わってモバイルアプリでエラー • GETでデータを作っている・・ • ドメインロジックにしか見えないヘルパーメソッド(ビューから呼ばれる)が散在
• バリデーションロジックでデータを作っている箇所がある ◦ なければ新規レコードを作る、みたいなやつ • という問題があるため影響範囲を見積もるのが大変 コード量が増えると・・
17 モジュラモノリスを志向していく方向に モノリスなアプリケーション内でも、ドメイン単位のモジュールに分解することで、 モジュールごとの独立性を担保するアーキテクチャにしようねというアイデア Rails wayから外れていく覚悟
18 • やりたいこと ◦ モジュール境界を明確にして安心独立した開発を可能にしたい ▪ 機能のI/Fを明示した上でAPIと切り離す ◦ 不必要な結合をなくしたい ▪
ドメインで必要なものだけが分かるような実装に ◦ DBへの予期しないアクセスをなくしたい ▪ 意図しない任意の場所からActiveRecordのクエリが発火されないように • マイクロサービス化でないの? ◦ 将来的にそうなる可能性はありますが、大事なのは境界線を決めていくこと ▪ 境界線が変わることもありえるし、組織が不要にサイロ化していくのは避けたい ▪ ネットワークとかトランザクションとかCross-cutting concernとか覚悟が必要 ◦ もちろんビジネス的にマイクロサービスで継続開発いける!と判断したらいきます freeeのモジュラモノリスに対する考え方
19 テックリード中心に去年1年くらいかけて設計を固めた freee会計ではBackend APIというものを新しく定義して導入 • Backend APIの内側をモジュラモノリスにおけるモジュールと定義して移行していく • 内部APIはProtobufを採用し、protoファイルで型定義していく いざ長旅へ
freee 会計 Rails App Module Model Service Controller API
20 • ActiveRecordの呼び出しが制限されるため、Rails Wayからは外れる ◦ Backend APIの外側(controller等)ではActiveRecordを前提としたライブラリは不可に • クライアントに返す時点でデータが生成されていないとダメなのでpreload前提のコードがダメ ◦
DTOのような中間データオブジェクトを用意する必要がある とはいえデメリットよりメリットの方がインパクトが大きいので進めています デメリット
21 細かいやつ • タイピングが難しい単語はある ◦ company => comapny, compnay ◦
params => parms, parmas ◦ walletable => walltable 型があっても無理な問題だったりするので、CIで弾きましょう freeeではdangerを使ってCIチェックかけてます。Rubyで条件書けて便利
22 01 freeeの紹介 02 freee会計について 03 負債代表作 04 改善の様子 アジェンダ
23 大きな負債の返し方 個人のパワーでは無理なので組織的に工数を取って取り組むしかない 2018年以降は毎年プロダクトごとにテーマを決めて、技術課題の改善に3ヶ月/年くらい使っています 改善とともに保守運用にかかる工数も減少傾向 2017年までは会社のフェーズ的にもとにかく機能開発に振っていました
24 小さな負債の返し方 気になったものをシュッと直せる空気、文化が大事
スモールビジネスを、世界の主役に。
26 共通サービス化やサービス内のモジュラモノリス化などは今まさに進めているやつになりますし、 他にもRDBのパフォーマンス改善やフロントエンドの負債解決など、やりたいことが山盛りです。 今回の話を聞いて、freeeでのサービス開発(基盤含む)に興味持ってくれた方いませんか!? ちょっと話聞いてみたいくらいの人でもカジュアル面談できます。気軽に応募ください! https://jobs.freee.co.jp/engineers/ One moreなんとか