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