GMO Developers Day 2022｜18年目を迎えたレガシーな大規模ECシステムをリプレースする話 / 開発者向けブログ・イベント

GMOメイクショップ株式会社は、2004年からASP型のECシステム「MakeShop by GMO」を提供しています。サービススタートから18年目を迎え、現在法人で10,000社以上に利用されるなど順調に成長を続けていますが、規模が増大することによっていわゆるレガシーシステムとしての課題が浮き彫りになってきました。「サービスとして成功はしているけど、システムとしてはとても厄介な状態」から、GMOメイクショップはどうやって脱しようとしているのか。GMOインターネットグループが12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催したテックカンファレンス「GMO Developers Day 2022」で、GMOメイクショップの大森康充氏と森健太氏は、レガシーシステムの課題、レガシーシステムを安全に移行する方法と感想について紹介しました。

登壇者

GMOメイクショップ株式会社事業推進部

マネージャー　大森康充（左）
森健太（右）

システムのレガシー化が引き起こす3つの課題

MakeShop by GMOの最重要指標であるGMV（流通取引総額）は、リリース以来18年連続で成長してきました。また、ここ数年ではコロナ禍の影響でEC市場が活性化し、流通総額も倍近く増加しています。しかし、こうした成長の裏では、システムの規模が増大することによるさまざまな課題が発生していました。

1つめは、技術的負債の蓄積です。大森氏は「技術的負債とはジェンガのようなもの。開発初期は順調に進められていたが、開発が進むにつれてシステムの要素が影響しあいバランスをとることが難しくなる。単純にエンジニアの数を増やしても開発のスピードが上がらなくなる」と説明します。

2つめは、パフォーマンスの問題です。フロントエンドとバックエンドが分離されていないモノリシックなアプリケーションが構築されていたため、スケールが困難に。また、当初の設計思想と乖離している、開発スピードを重視し継ぎ足しで作られた機能をはじめデータとロジックが増加するなど、パフォーマンスは悪化の一途をたどっていました。

3つめは、エンジニアのモチベーションの低下です。エンジニアは「レガシーなシステムの保守をしたくない」「技術的に新しいことをしたい」「キラキラしたことをやりたい」「勉強した内容を活用したい」などといった思いを持っているため採用が進まず、システム開発に大きな影響を与えていました。

リプレースは「テセウスの船のように」少しずつ移行

開発スピードが悪化するにつれて経営層をはじめ非エンジニアも課題を認識するようになったことで、経営層自らが強い危機感を持って率先してシステム課題の解決に向けて動き始め、リプレースプロジェクトがスタートしました。リプレースプロジェクトでは、「システムを止めないこと」「ショップ様に注文データや商品データ、会員データなどの移行の手間を発生させないこと」という2つの方針が定められました。

リプレースで目指したのは、複雑なシステムをシンプルで新しい技術スタックにすることです。大森氏は「システムは、アプリケーション、インフラ、データベース、ネットワークなどさまざまな要素で構成されており、複雑な形をしている。それをシンプルな形にして、パフォーマンスを上げ、エンジニアが開発しやすいようにしていくことを考えていた」とリプレースプロジェクトの目的について話します。

そうはいっても、システムのリプレースは簡単ではありません。特に一度にすべてを変えようとすると、リプレースの失敗に備えて切り戻しの手順を考えたり、さまざまなバックアップを取得してデータやリソースを移行し大きなテストを行ったりする必要があります。

そこで、GMOメイクショップでは、「テセウスの船のように」というギリシャ神話から着想を得たキャッチコピーを用いて、少しずつ移行する方法を採用することにしました。大森氏は「ただでさえ難易度の高いリプレースなので、少しずつ形を変えてリリースすることでリプレースの難易度を下げようと考えた。細かくリプレースすることでよりよいシステムをつくっていければ」とその狙いを説明します。

テセウスの船とは、物事を構成するパーツがすべて置き換えられても、それは過去のものとまったく同じものであるかどうかという問題を表現したものです。このプロジェクトでは、老朽化した船を補修するため劣化した部品を少しずつ修理・交換していくと、やがて最初に使われていた部品は1つもなくなり、まったく新しい船へと生まれ変わるテセウスの船を理想とし、インフラやアーキテクチャなど、システムを構成するパーツを1つひとつ入れ替えながら、「気がついたらリニューアルされていた状態」を目指しているといいます。

段階的に既存システムへの依存を減らすシステム構成

こうした方向性で、現在では段階的なリリースが進められています。既存システムは下図のような構成になっています。

アプリケーションはPHPで構成されており、数十台のアプリケーションサーバーとデータベースが稼働しています。図は簡略化されており、実際にはさまざまな外部アプリケーションやシステムと関連しています。

新システムの構成は下図のとおりです。

フロントエンドとバックエンドを分離し、フロントエンドには、Vue.jsを採用しています。バックエンドは、BFFとgRPCという2つのコンテナ群に分かれているのが特長です。BFFはフロントエンドからのリクエストをGraphQLで受付け、その裏のマイクロサービス群のgRPCにリクエストを投げます。これにより、フロントエンドからは柔軟なリクエストを受付けることができ、バックエンドは互いに独立して開発できるため、スケールが容易となります。

データベースは既存システムと共有することで、新システムからもデータの定義を変えることなく利用できる形になっています。また、一部APIや画面についてはiframeで呼び出すなど、既存システムで活用できる資源を極力活用し、リリースまでの期間を短くするよう工夫しています。また今回の構成では、GitHub Actionsを利用してビルト、テスト、デプロイなどの操作を自動化し、開発エンジニアがより開発に専念できる形にしています。

さらに、次の段階の構成としては、iframeおよびAPIの呼出を削除して既存システムへの依存関係を少しずつ減らし、最終的には、既存システムへの依存をゼロにすることを目指しています。データベースは既存システムと分割して、新システムで構築することを考えています。これにより、gRPCがそれぞれ独立したデータベースを持つことになります。さらに、互いのシステムが疎結合になるため、独立して開発できる要素が増えていきます。

技術的負債、パフォーマンスの改善を実現

リプレースプロジェクトによって、実際に技術的負債は改善されつつあります。まずは、フロントエンドとバックエンドを分離することによって、エンジニアはより専門性の高い開発ができるようになりました。また、マイクロサービス構成にしたことで、各サービスを独立して開発でき、開発スピードがスケールできるようになりました。そして、定期的にプロジェクトメンバー全員でリファクタリングを議論したことで、コードの均質化・見通しの良さの向上につながりました。

パフォーマンスも改善しています。バックエンドシステムの言語をPHPからGoに変更することで、アプリケーションサーバーのパフォーマンスが改善できています。また、DDD・クリーンアーキテクチャを採用し、複雑なロジックを極力疎結合で書くことで、余分な処理を減らしています。再利用性を高めることで、開発スピードも向上しました。マイクロサービス構成とすることで、負荷が高いサービスへのリソースの割当も可能となりました。

エンジニアのモチベーションはどう変わったか？

最後に大森氏は、エンジニアのモチベーション低下というレガシーシステムの課題について、リプレースのフロントエンド開発を担当する新卒2年目の森氏と振り返りました。

大森

プロジェクトにアサインされたときの気持ちはいかがでしたか。

一番新しい業務、技術に触れるということで、楽しみという気持ちが大きかったです。それと同時に自分にとっては初めての大型のチーム開発でしたので、ベテランのチームメンバーのなかプレッシャーも大きかったです。

森

大森

良かったと感じる点はありましたか。

入社当初は主に既存システムの保守や調査を行っており実務経験は皆無でした。メンバー内でエンジニアとしての経験値の差がかなりありましたが、技術自体の知識のスタートラインは皆同じだったので、お互いに勉強しながら教えあっていくことでチームとしてより強くなれたと感じています。

森

大森

逆に悪かったと思う点はありましたか。

エンジニアにとって自由度が高いということが災いして、全体像が見づらくなってしまっていました。それにより、途中で方向性を修正する必要がありました。

森

大森

どんなことに苦労しましたか。

レガシーで大規模なシステムとなっていたため、既存システムの仕様を細かく調査していくのに苦労しました。大まかな機能はわかっていても、他の機能との細かな連携を1つひとつ調べるのは大変です。

森

大森

新しいシステムが、現行のシステムのように苦労しないためにはどういうことが必要でしょうか。

シンプルに1つひとつの機能を分離していくという考え方です。また、この開発のなかできちんと記録を残していくということも大切になっていくと思います。

森

大森

ドキュメントはまだまだできていないので、そこは進めたいですね。また構成も、依存関係を少なくしてシンプルにしていきたいです。これから頑張りたいことには、どんなことがありますか。

ユーザビリティにより注力していきたいです。リプレース版のリリースが近づいていますが、リリース後お客様が使い始めてからは大きな変更は難しくなると思うので、今がよりよくする最後のチャンスだと思っています。既存システムを踏襲するだけでなくより進化させたものになるよう、ユーザビリティを考えた開発をしていきたいです。

森

大森

リプレースによって実際にモチベーションはあがりましたか？

上がりました。新しい技術に触れること自体も楽しいですし、どんな技術を使って何をつくるか提案したり議論したりしながら進められるので、エンジニアにとって良い環境で開発ができていると感じています。

森

大森

フレームワークやライブラリの選定などもチームメンバーで気軽に話し合って決められているので、私も楽しくやらせていただいていると感じます。

大森氏は「変化を楽しもう。あなたは必ず変化する。人は気持ちで変化する。」というGMOインターネットグループスピリットベンチャー宣言のなかの言葉を紹介し、講演を締めくくりました。ソフトウェアの技術は常に変化を続けています。初期の技術選択が正解である保証はありません。GMOメイクショップでは、新しい技術の導入をカジュアルに検討し、変化を楽しんで開発を進めていこうというカルチャーをまさに造成しているところです。