創業してから10年ほど経っているレガシーシステムを運営しているとあるサービス会社に入り私は初めてRuby on Railsを学びました。
それまで私は技術力の低いSIerでC#の基幹システム開発案件を3年ほど転々としていて、今回のWebサービス、他の言語に触れるのはとてもわくわくしました。
サービスは出品者が売りたい物を出品し、それをオークション形式で査定士たちがどんどん査定していくというオークション型の出品買取サービスでした。それで出品者が気に入った取引先が決まればあとはチャットをして送品、入出金されるというシンプルなサービスです。
そのうち商品をヤマトや佐川などで発送し、査定してもらうというシステムもおそらく構築するとメルカリみたいに楽でいいサービスになると思いました。
ですが、開発者にとって大きな問題があり、ビジネスサイドも無視できない問題がありました。
それはシステムがあまりにもレガシーでとてもじゃないけどこれ以上はスケールしないということでした。
あまりに巨大な泥団子状態になっており、もし先ほど言ったような発送機能なども追加しようものなら手を付けられないシステムになっていることでしょう。
Ruby on Railsは初心者でもとっかかりやすい言語、フレームワークとして有名です。
しかし、それゆえ私のようなあまり設計やアーキテクチャに明るくない人でもやりたいことができてしまい、ソースコードを追加に追加した結果、後から入ってきたエンジニアたちはコードが複雑化しすぎていて、仕様が把握しきれないということになっていました。
これ以上Ruby on Railsで開発し続けるならシステムを刷新する必要がありました。
依存関係や結合度を減少させる必要があり、モノリスをモジュラーモノリスか分散型アーキテクチャにして責務を分離させる必要がありました。
そうすることで、スケーラビリティ、パフォーマンスが共にぐっと向上し、より柔軟性の高いシステムになります。
一方で、密結合な方がテストしやすいしバグの原因を特定しやすい。環境を構築しやすいため、開発しやすさはトレードオフになると思います。そこら辺は会社、開発に余裕があるかを見る必要があるでしょう。
組織もRuby/Railsエンジニアを採用するのではなくて、アーキテクチャを変容させると同時にフロントエンドの専門、ソリューション解決の専門など人材を確保することでよりマルチプロダクト化、プロダクトの共通基盤を作ることができるでしょう。
それは今後私もアーキテクチャを学び、書いていくととして、今回言いたいことはRuby on Railsで構築されたモノリスがいかにスケールしないシステムになるかということです。
スタートアップはサービスを立ち上げて早く収益化させないといけません。
なので最初からマイクロサービスで構築してしまうと実装できる要員や開発スピードを確保できず、破綻してしまいます。
最初にRuby on Railsでモノリスを作ることはかなりいい選択だと思います。
経験のないエンジニアでもRuby on Railsに慣れたらどんどん書けるので採用に大金をかけられないスタートアップにとってはRuby on Railsは得策です。
しかし、そうやって書いてきたソースコードはあまりにも読むことが難しく、複雑で誰も把握していない仕様になってしまうので、余裕ができてきたらシステムはインフラ構成、アプリケーション設計、仕様、DB設計等あらゆる仕様・設計を再検討し作り替えていかなければならないです。
いつどのタイミングでリアーキテクチャしていくかは予算をどれくらい開発にかけてくれるかにもよりますし適切な人材をどれくらい確保できるかにもよりますが、モノリスはいつかは限界がくるということが分かりました。
エンジニアは今開発をしているプロダクトや会社、事業がどれくらいのフェーズにいるのか。どれくらいのサービスを求められているのかを考えることが必要でしょう。
特にAIがプログラムを書いてくれるようになったので、アーキテクチャやビジネス、プロダクトマネジメント、ソリューションアーキテクトの役割をどんどんつけていく必要があると思います。その上で役割を分担することでより良い組織になると思っています。
0 件のコメント:
コメントを投稿