Upgrade to Pro — share decks privately, control downloads, hide ads and more …

うちの技術負債2021 freee編

freee
September 14, 2021

うちの技術負債2021 freee編

freee

September 14, 2021
Tweet

More Decks by freee

Other Decks in Technology

Transcript

  1.   2 2013年6月 freee株式会社へ入社 freee会計のエンジニア => freee会計のエンジニアマネージャ => 人事労務含めた既存プロダクト全体のマネージャ という変遷を辿っています

    もともとフロントエンドエンジニアなのでJavaScript関連の 技術を触ったりするのが好きです 今日はプロダクトと会社が大きくなっていく中で対応してき た(せざるを得なかった)技術的負債の話をします! 若原 祥正 freee株式会社 執行役員 プロダクトコア開発本部長 @yo_waka
  2. 6 2021年前年比 +34.2% 2013年 3月 2014年 3月 2015年 3月 2016年

    3月 2018年 3月 2019年 3月 2020年 3月 2021年 3月 2017年 3月 有料課金ユーザー数は28万社を超える
  3. 9 • バックエンド ◦ Railsアプリケーション + いくつかのマイクロサービス(後述) ◦ freee人事労務など他サービスとだいたい連携 ◦

    銀行やクレジットカードの明細を取得するような機能も内包している ▪ これ自体はマイクロサービスへの切り出しが進んでいる • フロントエンド ◦ 基本的にReact + hooksなコンポーネント ◦ 以前のRailsのデフォルトだったCoffeeScriptが一部残っている • データストア ◦ RDBにAurora MySQL、高速化したい箇所はElasticsearchやDynamoDB等も使っています • インフラ ◦ EKS上で運用 freee会計の基本的な構成
  4. 10 freee会計のコード規模感 テーブル数 800くらい Ruby ファイル数 12000くらい JavaScript ファイル数 7000くらい

    エンドポイント数 4000くらい 1ヶ月のコミット数 2000くらい 1ヶ月のプルリクエスト数 1000くらい
  5. 11 • 普通のマルチテナント構成 • 1億レコード以上あるテーブルが23テーブル ◦ 最大レコード数は17億レコードくらい ◦ auto increment

    idはbigintにしないともう動きません ◦ MySQLはすごい • 毎年130%くらいのペースでデータが増える • 読み込みトランザクション以上に書き込みトランザクションが多いのが特徴かもしれません freee会計のデータ規模感
  6. 18 • やりたいこと ◦ モジュール境界を明確にして安心独立した開発を可能にしたい ▪ 機能のI/Fを明示した上でAPIと切り離す ◦ 不必要な結合をなくしたい ▪

    ドメインで必要なものだけが分かるような実装に ◦ DBへの予期しないアクセスをなくしたい ▪ 意図しない任意の場所からActiveRecordのクエリが発火されないように • マイクロサービス化でないの? ◦ 将来的にそうなる可能性はありますが、大事なのは境界線を決めていくこと ▪ 境界線が変わることもありえるし、組織が不要にサイロ化していくのは避けたい ▪ ネットワークとかトランザクションとかCross-cutting concernとか覚悟が必要 ◦ もちろんビジネス的にマイクロサービスで継続開発いける!と判断したらいきます freeeのモジュラモノリスに対する考え方
  7. 21 細かいやつ • タイピングが難しい単語はある ◦ company => comapny, compnay ◦

    params => parms, parmas ◦ walletable => walltable 型があっても無理な問題だったりするので、CIで弾きましょう freeeではdangerを使ってCIチェックかけてます。Rubyで条件書けて便利