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
930
うちの技術負債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
23k
requireの循環参照
waka
0
1.3k
Other Decks in Technology
See All in Technology
皆がすなるカオスエンジアリングといふものを、ネットワークオペレーションでもしてみむとてするなり
tjmtrhs
0
120
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
soudai
20
5k
OCI Data Science Service 製品概要
oracle4engineer
PRO
0
110
Server-Side Kotlin + Spring Boot + Exposedでやったこと
ikefukurou777
0
110
Webエンジニアのためのデータエンジニアリング概説
mtoriyama000
5
400
App Runnerでパラメーターストアの値を使ってみた
miura55
0
230
SSMエージェントはIAMロールの夢を見るか/ Do SSM Agents Dream Of IAM Roles?
yukihirochiba
0
1.4k
【Cyber-sec+】ログの森で出会ったCloudTrail との奇妙な旅
hssh2_bin
1
220
Node-AI のリッチな WEB フロントエンドを支える技術
nenonaninu
2
970
layerx-0-to-1-product-development-in-compound-startups
shnjtk
1
520
最速思考でバクラク品質を! スタートアップのリアルな課題とQAの実践
nakanao
1
440
君はApplication Composerというサービスを知っているか
tsukuboshi
1
520
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
501
110k
VelocityConf: Rendering Performance Case Studies
addyosmani
319
23k
Designing for Performance
lara
601
67k
Bash Introduction
62gerente
604
210k
The World Runs on Bad Software
bkeepers
PRO
60
6.6k
WebSockets: Embracing the real-time Web
robhawkes
59
6.9k
Facilitating Awesome Meetings
lara
39
5.5k
YesSQL, Process and Tooling at Scale
rocio
160
13k
The Invisible Customer
myddelton
114
12k
Raft: Consensus for Rubyists
vanstee
130
6.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.2k
Faster Mobile Websites
deanohume
296
30k
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なんとか