CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

SHOPLISTのシステムをモダンなアーキテクチャに変えようとしたら予想以上に闇が深かった話

こんにちは。クルーズ株式会社CTOの鈴木です。

2020年の7月よりCROOZ SHOPLIST株式会社の技術統括部長を兼務しており、日々システムと開発組織の業務改善に現場のエンジニアとともに取り組んでおります。

今回当社が運営しているファッションECサイト『SHOPLIST.com by CROOZ』にて絶賛格闘中のシステム品質改善の話を数回に分けてお話ししたいと思います。

 

SHOPLISTのシステムを改善しようとなったきっかけ

「今のSHOPLISTのシステムってゼロからリニューアルするといくらくらいかかるの?」

SHOPLISTの業務を兼務するようになって、一番初めに社長に聞かれたことです。何をいきなり出だすのかと詳細を聞いていくと、「開発エンジニア数名にヒヤリングしたところ、システムがレガシー過ぎて開発が超しづらい」「もうリニューアルでゼロベースで作り直すしかない」という意見があった。まず現状どんな課題があるのか調べてほしいとのこと。

SHOPLISTについては、CROOZ株式会社から分社化した会社で、もともとのシステムアーキテクチャは把握してましたし、また定期的にエンジニアの定例を行っていたので全く内情を把握していないというわけではなかったのですが、改めてシステム上何が問題なのかについて現状のソースコード、インフラ構成、開発体制などあらゆる面で約1カ月程度かけて調査してみました。

そして以下、具体的に見えてきた問題です。(問題の粒度はバラバラです)

 SHOPLISTの問題その①:仕様の複雑さ+仕様書の無さ+デッドコードの組み合わせで、調査及び実装が昔からいたベテランエンジニアしか効率的に行えない問題。


一番はここだと個人的には思っています。とにかく仕様把握に時間がかかる。入口のControllerから順に読んでいくとDBから何かの値とってその値に応じた分岐が複数あり、分岐を一個一個追っていくと、結局DBの検索結果がnullで、すべての条件分岐を抜け、結局やってることってTOPページにリダイレクトしてるだけじゃん…。それでその話を古くからいたエンジニアに聞いたら、あの人知ってるかもと別のエンジニアに聞くように言われ、そのエンジニアに聞くと実は2年前に終了した機能で、結局Controllerの中の100行の分岐制御でいらないでしょw みたいなことが実際にありました。

他にもDBのCRUDで見るとデータは生成されてるんだけど、参照されてなくない?みたいなものや、このテーブル何?みたいなものがあってとにかくおそらくデッドコードなんだけど、何の目的でその処理があるのかが仕様書としてもソースコメントとしても残ってないのでよくわからない。とはいっても現状だとテストコードなどもなくCICD環境も無いので、処理を消した結果で不具合が起こるリスクに対するリスクヘッジの方法がなく能動的に回収しづらいという話も聞きました。

決してソースコードが汚いわけではないです。CROOZでは過去にSNSソーシャルゲームを運営しておりましたが、よっぽどそっちの方がソースは汚かったです。SHOPLIST固有の問題としては仕様の複雑さ+仕様書の無さ+デッドコードの組み合わせだと考えています。

 

SHOPLISTの問題その②:OS・ミドルウェアが古い(サポート切れ状態)問題

SHOPLISTのインフラは、2014年にオンプレミスからAWS上に移行したのですが、その際OS・ミドルウェアをそのままのバージョンでクラウドに移行しています。なのでEC2を使ってはいるものの、本当にオンプレミスのサーバが仮想サーバに置き換わっただけで、クラウドを意識したプログラム実装にはなっていない部分が多い状況になっていました。

それはそれで問題なのですが、もっと問題なのはOS・ミドルウェアバージョンが古いこと。一例ですがOSはCentOS 6.4系、PHPに至っては5.4系でした。ちなみにPHP5.4系のサポートは2015年に終了しておりセキュリティ面、生産性面で大きな課題がある状況でした。もっともセキュリティの話だけであればApache の設定やAWS WAFなど、複数のサービスやミドルウェアの組み合わせによりリスクヘッジはまだできる部分があるのですが、当然すべてをセキュリティリスクをゼロにはできないですし、生産性の話でいうと当たり前ですが最近ライブラリやSDKはサポート切れのPHPに対応しているわけがないので恩恵が受けれず開発に苦労することになります。

一番の問題での一番の課題は、エンジニアの心理的な負荷が大きいこと。まあcomposerで何か入れようとしてらPHPのバージョンが古くてインストールできない、セキュリティサポートも終わっていて、重大な脆弱性が見つかっても直せない可能性がある状態だと、心理的な負荷は大きいです。

実際にサポート切れバージョンを使い続けることに耐えかねず、やめてしまったエンジニアもいたようです。

その他SHOPLISTが抱えている問題

 SHOPLISTのシステムにはこの他にも数々の問題がありますが、主だったものだけ列挙すると、

・デプロイをrsyncで行っていてリリース直後に不具合が出た際に切り戻しに苦労する問題。

・ローカル開発環境の構築に人によっては1日潰れる問題。

・Gitが重い問題。

PHPのWarning / Notice件数が1リクエストあたり300を超えている問題。

PHPの定数多すぎて管理できなくなっているんじゃないか疑惑(問題というよりは疑惑)。

・超属人化していて、ブラックボックスになっている問題。

・CI/CD環境が存在しない&CI/CDを実践できない問題。

iOSの場合SwiftとObject-C、Androidの場合JavaとKotlinが機能毎に混在している問題。

などなど、いろいろありました。

SHOPLISTの根底にある問題はなにか?

問題をひととおり出したところで、正直な感想を言うとよくある話だなと感じました。

よくあるレガシーシステムの話です。

事業拡大、売上を上げるために継ぎ足し継ぎ足しで開発し続けた結果、ドキュメント作成や終了した機能のプログラムやデータの削除、リポジトリ上からの不要ブランチの削除・ミドルウェアのバージョンアップなど、売上に直結しないことを後回しにせざるを得ない状況となり、そして後回しにしたものが永遠に着手できなくなって技術的負債として蓄積される。

なのでこれだけだったら急成長したサービスではよく聞く話なのですが、やばいなと感じたのはこの問題が前から発生していたのにも関わらず長い間放置されていたため、現場のエンジニアやプランナー(WEBディレクター)や役員の中で正常性バイアスが働いて問題に対して楽観的な見通しになっていたことです。

具体的な話でいうと

ソースコードレベルの課題や工数、移行計画を十分に検討しない段階でリニューアルするしかない、リニューアルすればレガシーシステムから脱却できる。

・DBサーバの容量が大きくなってもプロビジョニングに対応したEBSだから容量の問題はいったん大丈夫。

など、もちろんそれはそうだけどちょっと冷静に考えたときに非現実的だったり、すべての問題がクリアできなかったりいろいろまずくないか?と思うところがあり、はじめのきっかけの話に戻ると社長から質問のあったリニューアルするといくらくらいかかるかの質問については、「超概算でこれくらいかかるけど、現状のドキュメントがなく超属人化している状況下で、そのほかの機能開発を行いながら進めるのは極めて非現実的で、まずはリファクタリングベースでできる部分までレガシーな部分直していきましょう。」という話を提案しました。

 

今回はここまで。

以降、数回に分けてSHOPLISTにおけるレガシーシステム脱却に向けたシステム改善の話を投稿していきますが、この記事を読んでいて今まさに成長しているサービスの開発に携わっているエンジニアがいらっしゃいましたら、本当に今のうちにリファクタリングすべきです。

また既に同じような状況になっている企業の方がおりましたら、(あくまでも一例ですが)当社のレガシーシステム脱却に向け実践したことが参考になれば幸いです。