トクバイにおけるレガシーシステム改善への取り組み

こんにちは。CTOの前田です。 ロコガイドでは生産性を高め、より良いサービスを生み出すために「ユーザーファースト」「チャレンジ・スピード」「自立・自律」の3つの行動指針を定めています。
この行動指針を体現しやすい環境をハード(技術/アーキテクチャ)・ソフト(文化/制度)両面で整えることが、開発者の生産性、さらには事業生産性を最大限高めるために重要となり、結果としてよりよいサービスを生み出すことにつながると考えています。
この記事では、そんな「行動指針を体現しやすい環境を整える」ために行っている、トクバイのシステム改善戦略についてお話しします。

抱える問題

サービスが成長し、開発が長期間継続すると、レガシーシステムとの付き合いは切っても切り離せない重要な問題になります。
ロコガイドは創業後4年が経過し、5期目に差し掛かる会社ですが、運営している主力のサービスであるトクバイの前身の事業は創業以前から運営されており、システムとしては8年の歴史が積み重なったシステムです。
システムや事業の性質、辿った歴史によってレガシーシステムが引き起こす問題の内容は千差万別ですが、トクバイにおいても例外なくその成長を阻害する要因のひとつになっています。

この8年間で技術的な環境は大きく変化しています。

• スマートフォンの普及によるWebAPIを中心とした開発
• フロントエンドJavaScriptフレームワークの隆盛
• マイクロサービスアーキテクチャの隆盛
• クラウドサービスを中心としたソフトウェア開発
• 機械学習技術の発達に伴った利用ハードルの低下
• etc..

このように、Web業界はここでは書ききれないほどの沢山の変化が起こっています。価値あるサービスを迅速に提供するためには、世の中で生み出されたベストプラクティスを取り入れ、システム自身を変化させ続けなければなりません。

トクバイのバックエンド/WebサーバーはRuby on Railsで開発されていますが、実行環境こそフルコンテナ化されているものの、アプリケーションとしては1つのモノリシックなRailsアプリケーションです。
モノリシックアプリケーションで生産性が高い状態を維持できていれば問題はありませんが、現実的にはそうもいきません。
マイクロサービスアーキテクチャ等に代表される複数のサービスが連携して動くシステムと比較をすると、モノリシックアプリケーションは密結合になりやすく「変更した箇所と関連がないように見える箇所が壊れた」「簡単な変更をするためにあちこちの変更をしないといけない」等の問題が発生しやすいという問題があります。
この問題についてトクバイも例外ではなく、アプリケーション内の複雑性がボトルネックになり「ぱっと見はすぐにリリースできそうな機能だが、設計/見積を実施してみると思いの外時間がかかる」というシーンが散見され、スループットが出ないケースも発生してしまっています。
いわゆる生産性が下がってしまっている状態ですが、技術から生産性を高め、より良いサービスを生み出すために、2020年の下半期からレガシーシステム改善のためのプロジェクトを開始しました。
幾つかのプロジェクトに取り組んでいますが、本記事でご紹介するアプリケーションの再設計に取り組むプロジェクトでは「新しく入ったメンバーが即戦力化出来るコードベース」を目標に掲げ、素早くチャレンジしやすい環境の実現を目指しています。

改善戦略

現在のトクバイに携わるエンジニアチームの人員規模は15名ほどです。1つのモノリシックアプリケーションをメンテナンスし続けるための人数として無理な人数ではありませんが、変更箇所のコンフリクト頻度も上がり始めています。 そのため前述した複雑性の問題が解消されるような開発体制を整えなければいけませんが、一方でサービスの分割を行うと管理コストが上昇し、チームの規模に見合わないものになってしまうリスクがあります。

ロコガイドではこれからも継続的にエンジニア採用を続けていくため、エンジニアチームの規模拡大も拡大していくことになります。こちらに備えるためにも、開発生産性を維持、向上できるよう、縦と横でそれぞれ分割方針を建てることが肝要だと考えています。

まず、横の分割が指しているものは共通基盤機能の分割です。IdPやOAuth2.0サーバー、商品名文字列のカテゴリ推定機能等がこれに当たります。
例えばIdP機能はサービスの多角展開戦略を取る場合には様々なサービスから認証できることが求められるでしょうし、商品名文字列のカテゴリ推定機能もトクバイだけではなく、商品情報を取り扱う他サービスから呼び出したいケースは増えるでしょう。
上記ユースケースに代表されるように、共通基盤機能はサービス内からの呼び出しに限らず外部サービスからも高頻度で呼び出しが想定されます。そのため横の機能に関しては、コードベースから完全に分離した、アプリケーション単位での分離を目指しています。
横の機能は要求される要件も大きくは変わらず「枯れている」事が多い領域です。そのため、単体のアプリケーションへ分割を行ったとしても、管理/運用コストが大きな問題になることは少ないのではないかと考えています。

次に縦の分割です。縦の分割が指すものは、アプリケーション内の機能群を指します。トクバイにおいてはチラシや店舗情報の管理配信機能がこれに当たります。
これらのアプリケーション内機能は頻繁に変更が加えられ、要求される要件も変わりゆくことが多い領域です。これらの領域をアプリケーション単位での分離を行うと、現状の人員数で考えれば逆に変更コストを重くしてしまう結果に繋がりかねません。
しかし、今後の人員拡大時に各チームや機能領域ごとに最大限生産的に開発が行われるように道筋は引いておかなければなりません。そのため、縦の分割はアプリケーション内部で境界設計を進め、例えばShopify等で採用されているモジュラーモノリスと呼ばれる手法などを採用して、モジュールごとの独立性を担保する方針で考えています。
このようなケースでは改善戦略としてマイクロサービスによるシステムの分割が候補に上がりますが、マイクロサービスではシステム全体の管理形態が大きく変わるために、素朴に運用されているモノリスアプリケーションからの移行では変更すべき設計が多岐に渡り、運用も大きく見直す必要があります。
一方でこのモジュラーモノリスのアプローチは、アプリケーション内部で独立性を高めることで、複雑性が不必要に増大していくことを防ぐというもので、デプロイメントやインフラストラクチャの管理形態、アプリケーションの開発プロセスは全く変える必要は有りません。
ただし、マイクロサービスのアプローチと違いあくまで「１つのアプリケーション」であるため、境界を適切に維持し続ける力学が働きにくいことや、テストの実行時間の増大などいくつかの問題には対処できず、解消できないデメリットも存在します。
このようにメリット・デメリットはありますが、現在のチームサイズや今後のチームのスケーラビリティを双方見据えた上で、現実的なコスト感でアプリケーション単位での分離に繋げられるのはモジュラーモノリスの形態であると判断しました。これが完遂された後には、マイクロサービスへ化の現実的な道筋をも作ることができるのではないかと考えています。

最後に

これらの取り組みはまだ開始したばかりで、現在計画を引き、PoCレベルの実装を開始したばかりのフェーズです。
2020年下半期にはこの領域だけではなく様々な技術的な改善をスタートしました。2021年にはこれらの改善の進捗状況を皆さんに沢山ご紹介できればと思います。

ロコガイドでは、レガシーシステムの改善にともに取り組んでいただけるエンジニアを絶賛募集中です！
共に生産性の高いシステムを模索していただける方のご応募をお待ちしています:-)