6月18日、ファインディ株式会社主催のオフラインイベント「リアーキテクチャにおけるアンチパターンへの向き合い方と次なる挑戦」が開催されました。ラクスル株式会社が協賛し、ラクスル事業本部CTO岸野・ソフトウェアエンジニア吉原が登壇しました。
本記事では、その内容をレポートします！
登壇者
ラクスル株式会社 ラクスル事業本部CTO 岸野 友輔
ラクスル株式会社 ラクスル事業本部ソフトウェアエンジニア 吉原 哲
オープニング
RAKSULについて
会の冒頭、ご挨拶を兼ねて、RAKSULグループCTO竹内より会社紹介をいたしました。
竹内：
RAKSULは印刷事業から出発し、現在はECマーケットプレイス、SaaS、BPO（ビジネスプロセスオペレーション）など、さまざまなサービスを展開する、「産業構造の変革者」です。今後は主にBtoB受発注のプラットフォーマーとして、さらなる事業領域の拡大を計画しています。
RAKSULの技術文化は、「Go Beyond」「Think Architecturally」「Make it Scalable」の3つの理念に基づいています。
これらの理念のもと、ベトナムにも開発拠点を持ち、グローバル展開も進めています。各事業の自由な発展を重視しつつ、スケーラブルな仕組みを作ることを目指しています。また、毎年社内でハッカソンイベントを開催するなど、テクノロジーを重視する文化も根付いています。
今後もテックの側面から、「テクノロジーでどのように会社・ビジネスをドライブしていくのか」を考え、事業成長を続けていく文化を大切にしながら、さらなる発展を目指していきます。
LT
ラクスルからは2名が登壇し、リアーキテクチャの取り組みについて発表しました。
LT1 岸野
「リアーキテクチャのアンチパターンとその対策〜ラクスルの場合〜」
自己紹介
岸野：
私は新卒でラクスル株式会社に入社し、長らく印刷事業の開発に携わってきました。M&Aでグループインした事業「ダンボールワン」の開発組織の立ち上げも経験し、昨年の8月頃からは、ラクスル事業本部CTOとして、共通基盤プロダクトの構築を推進しています。
岸野：
本日は、前回5月22日に開催されたオンラインイベントで話しきれなかった「ラクスルが踏んでしまったアンチパターン」についてお話します。
（前回の内容はこちらのイベントレポートをご覧ください）
ラクスル事業について
岸野：
ラクスルは、印刷EC事業からスタートしました。現在は印刷にとどまらず、ノベルティ、ダンボール、アパレルなど多角的にサービスを展開しています。
アーキテクチャの変遷について
岸野：
2013年に印刷EC「ラクスル」をリリースしました。当初はPHPで作られたモノリシックなシステムとデータベースがあるだけといった、シンプルなアーキテクチャでした。
2015年に既存の印刷ECサイトを拡張する形で、集客支援サービスを開始しました。コンテキストが大きく異なる商品を、既存のシステム・同一のオペレーションシステムで無理矢理寄せて進めていくことで、開発の限界が露呈し始めたのはこの頃になります。そこで、将来的なシステムの拡張性を見越して機能の切り出しとして一部マイクロサービス化を開始しました。
この状況に加えて、「ノベルティ」や「アパレル」など、既存の印刷サービスのコンテクストから離れたサービスやシステム開発の要望が上がってきました。しかし、ラクスルの商品は商品特有のカスタマイズ性が高く、これ以上は、印刷ECの基盤ではシステム拡張は難しい状況でした。そのため、新しいサービスを別プロダクトとして構築していくことを決めました。
結果、新規プロダクトの立ち上げ速度や改善速度の向上に寄与したことから、現在はこの進め方がスタンダードになっています。
さらに、「ダンボールワン」「ハンコヤドットコム」のグループインが続きます。当初、M&Aを想定した設計にはなっていなかったため、各事業間のシナジー創出の土台として、基盤システムをしっかり独立させていくことが重要でした。
まだ道半ばですが、共通基盤として決済機能や認証機能を共通化する開発を進めることで、結果として、高いレベルでシステムの拡張性を保つことができています。
モノリスからマイクロサービス化への落とし穴
岸野：
マイクロサービス化の過程で経験した、データベース共有というアンチパターンについてお話しします。
前提として、モノリシックなシステムからマイクロサービス化を進める際には、アプリケーションを先に分けるパターンやデータベースを先に分けるパターンなどがあります。
ラクスルは、アプリケーションを先に分けるパターンを選択しました。この方法は、短期的には効率的でマイクロサービス化の恩恵を受けやすい一方、データベースを共有したままにすると、テーブルスキーマを変更する際に、すべてのアプリケーションで同期的にリリースする必要があるなどのデメリットがあります。
岸野：
ラクスルは、初期段階において、PHPで作られた旧システムを、Rubyで作られた新システムに切り出して、マイクロサービス化を進めてきました。この過程で、EC機能本体は新旧システムが混在する状態になりました。また、印刷発注APIや印刷コスト計算システムをそれぞれ本体から切り出してはいたものの、それらも同じデータベースを共有していました。
これらの複数のシステムが同じテーブルを参照してしまうなど、システムの切り出し方が不完全であることによる課題が生じました。
課題への向き合い方
岸野：
課題克服への取り組みとして、責務分割を再考し、各マイクロサービスが担うべき機能を明確に定義しました。具体的には、印刷発注に関わる機能を基盤システムとして切り出すリアーキテクチャを進めました。これにより、本体の印刷ECサイトだけでなく、集客支援など他のサービスでも、共通の印刷発注機能を利用できるようになりました。
この取り組みは、ラクスルが過去に行った「印刷発注API」や「印刷原価計算機能」などを切り出した経験を踏まえ、より効率的で効果的な方法を検討したものです。こういったマイクロサービス化で得られた知見を活かし、システム全体の理解と運用効率の向上を目指しています。
まとめ
岸野：
当時、拡張が難しいレガシーコードではなく、新しいコードベースでマイクロサービス化を進めた判断は正しかったと考えています。短期的なリリースを可能にし、特にベンチャー企業にとって重要なスピード感を担保できたことは大きな成果です。
しかし、データベースを共有したままにしてしまったことは、マイクロサービス化の落とし穴となりました。これにより、多重メンテナンスの発生など多くの問題を引き起こすことになりました。これは、マイクロサービス化のゴールを明確に設定せず、段階的なステップを踏まずに進めてしまったことが原因です。
したがって、マイクロサービス化を進める際には、ゴール設定が重要であり、あるべき姿を描いてステップを明確にすることが必要だという教訓を得ました。
これはほんの一例ではありますが、マイクロサービス化を検討している企業の皆さまにとって、私たちの取り組みが参考になれば幸いです。
LT2 吉原
「ラクスルのマイクロサービス移行：アンチパターンとその対策」
自己紹介
吉原：
私は、18年間にわたりアプリケーション開発やプラットフォーム開発に携わってきました。2024年1月にラクスル株式会社に入社し、現在は開発基盤部のプラットフォーム開発・SREを担当しています。
事業環境の変化について
吉原：
ラクスルは、印刷事業を中核に、内製での立ち上げとM&Aを通じてさまざまな領域で事業・サービスを展開しています。近年はそれらに加え、PoCでの新サービス検証、海外展開など、事業の多角化が加速しています。
そうした事業環境の変化に対応するため、システムの繋ぎこみやすさや既存プラットフォームの再利用性が求められています。
システムが抱える課題について
吉原：
現在、システムが抱える課題は大きく二つあります。
一つ目は、技術的負債です。システムが完全にモノリシックな構造から移行できておらず、旧技術スタックであるPHPやその他のレガシーな技術で構築されたコアシステムが多数残存していることです。さらに、複数のアプリケーションが同じデータベースを共有しているため、同じ処理が重複して実装されています。これらの問題が複合的に作用し、印刷ECシステムへの依存が、分散モノリス状態に陥っています。
二つ目は、メンテナンスの不足です。例えば、Kafkaのメンテナーが不在であるため、システムの維持管理や問題発生時の迅速な対応が難しくなっています。Kafkaの必要性について再評価し、もし必要がなければよりシンプルなRPCなどに移行を検討することが求められます。また、特定のエンドポイントのパフォーマンス不足も課題であり、アクセスが集中した際に全体的な影響を及ぼす可能性があります。
課題へのアプローチ
吉原：
それらの課題に対する私たちのアプローチは次の4つです。
まず第一に、コア部分のリファクタリングです。技術的負債を解消するために、負債解消の計画を立て、コアシステムの移行をPJ化し、徹底的に進めています。次に、開発基盤チームによる足回りの整備です。オブザーバビリティを向上させるため、開発基盤の整備に力を入れています。
さらに、プラットフォーム化とマイクロサービス化を進めています。決済や認証などの共通機能を切り出し、各サービスでの重複を排除することで、システム全体の効率性を高めています。最後に、アーキテクチャレビューです。全体最適の観点からシステム設計を見直し、将来の拡張性と持続可能性を確保しています。
吉原：
リアーキテクチャは「だるま落とし」のようなものだと考えています。最初から完璧なレイヤー構造でシステムが構築されていることは稀であり、多くの場合、段階的にレイヤーを構築し、抽象化していくことで、必要なロジックを切り出していく必要があります。
最初はシンプルな構造から始め、徐々に複雑なレイヤーを追加していくことで、システム全体を理解しやすくなり、必要な機能を効率的に実装できるようになります。
そして、各レイヤーが完成したら、リファクタリングを行い、不要な部分や非効率な部分を削ぎ落としていきます。これは、まさにだるま落としを倒していく過程に例えられます。不要な部分を的確に除去することで、システム全体のバランスが整い、より安定した構造へと進化していくのです。
個々のサービスを独立して改善するだけでなく、システム全体のアーキテクチャを俯瞰的に捉え、各サービス間の連携や依存関係を整理することで、より効率的で安定したシステム基盤構築を目指しています。
システムの繋ぎこみやすさ
吉原：
マイクロサービス化は重要な取り組みです。システムの密結合・モノリシックな実装の分解は、リアーキテクチャを進める中で、実装が難しい特徴を持っています。しかし、その実行によるメリットは大きいです。一番のメリットは、各コンポーネントが独立して、並行して開発ができることです。これにより、お互いが疎結合となり、チームがリニアにスケールしていく可能性が生まれます。
正しく切り出すことができれば、同じコンポーネントを他のサービスでも再利用でき、重複した開発を排除できます。例えば、素早く新しいサービスを立ち上げたり、M&A時に他のシステムとの統合を迅速化し、既存のシステムとのシームレスな連携をしたりすることが可能となります。
既存プラットフォームの再利用性
吉原：
各サービスはそれぞれ独立した状態で、再利用が可能です。それが、マイクロサービスとプログラミングのクラスが似ている点です。
正しく設計されたマイクロサービスは、そのサービス専用のデータベースを持ち、他のサービスへの依存性が少なくなります。これにより、汎用的にさまざまな場面で再利用できるという利点があります。また、インターフェースの定義も重要で、適切に設計されたインターフェースを通じて、他のサービスやシステムと効果的に連携することができます。
このようにして、マイクロサービスは中長期の運用で大きなコスト差を生む可能性があります。正しい設計により、運用コストを抑えつつ、柔軟性と再利用性を高めることができるのです。
最後に
吉原：
最後に、アーキテクチャレビューではどのような点を見ているかについてお話しします。
まず、システム全体をよく理解することが重要です。そのドメイン境界と切り方が適切か、各コンポーネントやサービスの責務が明確に分かれているかどうか、依存関係が適切に管理されているかを確認します。また、データが分離されているか、データの一貫性と整合性が保たれているかも確認します。
スパゲッティ建築の防止という点では、依存関係が複雑になりすぎていないか、保守性が高い状態を維持できるかを確認します。これらの確認を通じて得られた知見は、システム設計のナレッジとしてチーム全体でシェアしています。分散トランザクションの管理は複雑で難しいですが、そこをしっかりとサポートし、アーキテクチャ全体の設計に責任を持つことが重要です。
このようなアプローチにより、技術的な柔軟性とビジネスの成長を両立させるシステムを構築しています。
おわりに
最後までお読みいただきありがとうございました。
ラクスルは、テックカンパニーとして様々なイベントを開催しています。ぜひ今後のイベントにもご参加ください！
connpassグループのメンバー登録、Xフォローもよろしくお願いします！
