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
25k
requireの循環参照
waka
0
1.4k
Other Decks in Technology
See All in Technology
どちらかだけじゃもったいないかも? ECSとEKSを適材適所で併用するメリット、運用課題とそれらの対応について
tk3fftk
2
310
エンジニアのキャリアパスと、 その中で自分が大切にしていること
noteinc
3
1.3k
4th place solution Eedi - Mining Misconceptions in Mathematics
rist
0
150
MLflowはどのようにLLMOpsの課題を解決するのか
taka_aki
0
150
手を動かしてレベルアップしよう!
maruto
0
260
Snowflakeの開発・運用コストをApache Icebergで効率化しよう!~機能と活用例のご紹介~
sagara
1
550
OCI Success Journey OCIの何が評価されてる?疑問に答える事例セミナー(2025年2月実施)
oracle4engineer
PRO
2
240
Log Analytics を使った実際の運用 - Sansan Data Hub での取り組み
sansantech
PRO
0
150
困難を「一般解」で解く
fujiwara3
8
2.4k
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
10
2k
20250307_エンジニアじゃないけどAzureはじめてみた
ponponmikankan
2
230
データモデルYANGの処理系を再発明した話
tjmtrhs
0
380
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
The Language of Interfaces
destraynor
156
24k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
A Tale of Four Properties
chriscoyier
158
23k
Thoughts on Productivity
jonyablonski
69
4.5k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Designing for humans not robots
tammielis
250
25k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Product Roadmaps are Hard
iamctodd
PRO
51
11k
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なんとか