うちの技術負債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 小さな負債の返し方 気になったものをシュッと直せる空気、文化が大事 

スモールビジネスを、世界の主役に。