OLTA TECH BLOG

テクノロジーと好奇心で事業を成長させる

TECH BLOG

INVOYにおけるリアーキテクチャの取り組みとその記録

こんにちは。OLTA (オルタ) プロダクトグループの柴田です。主にINVOYの開発を担当しています。

INVOYでは、2021年7月から9月にかけて、リアーキテクチャを行いました。変化が激しいスタートアップのなかで、ソフトウェアのアーキテクチャ変更を行った事例として参考になればうれしいです。

(この記事内の画像は社内向けに共有を行った資料を流用してます。時間削減!)

きっかけ

INVOYは、請求書発行ツールではなく、入出金管理プラットフォームとして発展させていくという意思決定が行われました。(最近更新されたCulture Deckにも記載があります)

しかし、INVOYのコードベースは、請求書発行ツールを少人数で開発、運用していくための設計になっていたので、今後を見据えると機能開発の手を一旦止めてでもリアーキテクチャを行うべきという判断をしました。

解決したかった課題

INVOYの開発効率で問題になっていたのは主にwebフロントエンドでした。

INVOYではサーバーサイドのフレームワークDjangoを、フロントエンドにはVueを採用していますが、サーバーサイドとフロントエンドの分離がうまく出来ておらず、開発速度があまり出ないのが課題でした。

DjangoのテンプレートからVueを利用していたのですが、フロントエンドとサーバーサイドが密結合しており、画面の仕様が変わるたびにサーバー側の変更も必要でした。一部のページではAPI経由で取得していたり、サーバーとフロントエンドの通信方法に一貫性がなく、実装者に委ねられていました。結果的に学習コストが高くなり、サーバーサイドのコンポーネントを理解しないと画面開発ができず、画面を1つ追加するのも大変な状態でした。

また、フロントエンド・バックエンドが密結合になっているため、リリースする単位が大きくなってしまうのも課題でした。具体的にはボタンの文字を1文字変更するだけでも、全部入りの1GB近いコンテナを差し替える必要があり、時間がかかっていました。

そこで、フロントエンドとバックエンドを分離し、それぞれ別でデプロイできるようにし、フロントエンドはOSSフレームワークを採用することで開発者が決めないといけないことを減らすことで、開発チームが増えても高い開発速度を保つことができると考えました。

事前準備

フロントエンドの有識者に副業で参加してもらいアーキテクチャの壁打ちをしてもらいました。 Nuxtを利用したプロトタイプを作成し、画面ごとの移植方針、ユーザー認証などを検証しました。 それと並行して、最初にやるべきことを整理しました。

  • フロントエンド、バックエンドの分離
  • フロントエンドのリライト(Nuxtへの移行)
  • デプロイ方法の刷新

を今回のスコープにすることにしました。 デプロイ方法の刷新については、既存のデプロイ方法は全てのコードが一つのレポジトリ、Helm Chart に存在している前提で構築されていたため、アプリケーションが複数のレポジトリに分かれていても動作する仕組みに刷新する必要がありました。

逆にいうと、ここに書いてないことは今回のスコープ外とすることにしました。特にバックエンドのリファクタリング、サービス分割には手を出さないことにしました。 ここまで進めて、現在の課題と、リアーキテクチャで実現したいことを整理して社内に共有。3ヶ月時間を使えることになりました。

開発準備

まずリリース戦略を決めました。バックエンドについては、画面表示時に行われていたサーバー側の処理を、フロントエンド用のAPIとして移植していくのが主な作業になります。ここについては、あえてブランチを作成せず、都度メインラインに取り込んでリリースしていくことにしました。一部、ユーザー認証用エンドポイントのようなものはフィーチャーフラグで隠した状態でデプロイしました。フロントエンドは新規でレポジトリ を作り、そのレポジトリ 上で開発を進めます。

3ヶ月間なるべく機能開発は行わないという決めでしたが、予想通り細かい修正依頼は発生しました。ブランチ戦略のおかげで、大きな混乱は発生することなく進めることができました。

テスト戦略

次に、テストの戦略を決めました。

今回バックエンドには手を入れないですが、フロントエンドはほぼリライトするため、影響範囲が全てになってしまう問題がありました。リリース前にテスト期間をとりますが、それだけでは品質を担保できるか不安でした。継続的にテストを行うため、Autifyを導入し、旧環境で作成したテストがそのまま新環境で通るかどうかを確認しながら進めることにしました。(AutifyについてはSeleniumを使ったE2Eテストのメンテが非常に重いという課題もあって、その文脈でも導入検討していました)

進め方

ここまで決めればあとはやるだけです。3ヶ月で3名でやり切ることができました。

結果

無事リリースを行うことができました。 

フロントエンドのリライトによる学習コストの低下、開発速度の向上の効果は実感できています。

現在新しいアーキテクチャでどんどん開発を進めていますし、リアーキテクチャもまだフェーズ1が終わったばかりです。今後は認証基盤の切り出しなどを予定しています。 今後も事業を先に進めるための新規機能の開発も進めつつ、それを支える開発基盤の改善にも力を入れていきます。

フロントエンド、デプロイ、テストなど詳細はもっと書きたいと思ったのですが、概要編ということでいったんここまでにして、気が向いたら追加しようと思います。

最後に

OLTAではTech Visionの元、一緒にユーザーに価値を提供し、その結果事業を成長させるサービス作り続けるための仲間を募集しています。 もし、この投稿にご興味を持っていただいたら、是非カジュアルにお話しさせてください。

corp.olta.co.jp