リアーキテクチャのアンチパターンとその対策 〜ラクスルの場合〜

Transcript

1. リアーキテクチャのアンチパターンとその対策 〜ラクスルの場合〜 ラクスル株式会社 ラクスル事業本部 CTO 岸野 友輔 2024.06.18 Ver.1.0.0
2. © 2021 RAKSUL, inc. All rights reserved. 社外秘 Confidential これまでの経歴 
 • 2017年:東京工業大学卒
 • 2017-2020年: ラクスル サーバーサイドエンジニア
 • 2021-2023年: ダンボールワン サーバーサイドエンジニア/CTO
 • 2023年-現在: ラクスル事業本部CTO 
 ◦ 共通基盤プロダクト構築の推進など
 これまでやってきた技術 
 • Ruby/Go/PHP
 岸野 友輔（Kishino Yusuke） 
 
 
 サーバーサイドエンジニア 
 
 趣味：ゲーム, 自転車, 料理 

3. © RAKSUL, inc. All rights reserved. 今日のテーマ 3 本日のイベントの前身となる 5/22に行われたイベントで語りきれなかったことを中心に、ラクスル のアーキテクチャの変遷と踏んでしまったアンチパターンについてお話しします 前回のイベントレポートはこちら！
4. © RAKSUL, inc. All rights reserved. ラクスルってどんなサービス？ 4
5. © RAKSUL, inc. All rights reserved. 5 ラクスル事業について 印刷EC事業に始まり『広告（集客支援）事業』『ノベルティ・グッズ事業』 『ダンボール・梱包材事業』『アパレル・ユニフォーム事業』などを展開している事業体 ダンボール・梱包資材の 受発注プラットフォーム ノベルティ・グッズの 受発注プラットフォーム +非公開の事業群 アパレル・ユニフォームの 受発注プラットフォーム
6. © RAKSUL, inc. All rights reserved. ラクスル事業のサービス・アーキテクチャの変遷 6
7. © RAKSUL, inc. All rights reserved. 印刷のラクスルの始まり - 1サービス・ 1プロダクト サービス 2013年 印刷ECである「ラクスル 」リリース 7 アーキテクチャ PHPで作られたモノリシックなシステム DB
8. © RAKSUL, inc. All rights reserved. 複数サービスの始まり - 複数サービス・ 1プロダクト サービス 2015年 印刷ECサイトのラクスルを拡張 する形で集 客支援サービス (新聞折込やポスティング )開始 8 アーキテクチャ モノリスを拡張 しながらサービスを拡大 設計が苦しく なり始めマイクロサービス化を検討 DB New
9. © RAKSUL, inc. All rights reserved. マイクロサービス化の始まり - 複数サービス・ 1プロダクト サービス 2015年 印刷ECサイトのラクスルを拡張 する形で集 客支援サービス (新聞折込やポスティング )開始 9 アーキテクチャ 一部マイクロサービス化 を開始(DBを共有するアン チパターンを踏む) DB New
10. © RAKSUL, inc. All rights reserved. マルチプロダクトの始まり - 複数サービス・複数プロダクト サービス 紙への印刷から大きく異なる「 ノベルティ 」や「アパレ ル」のECを展開 10 アーキテクチャ 印刷ECが拡張の限界 を迎えたため新規でのサービス を別プロダクト として構築していく方針へ 共通基盤 として決済基盤 が構築される 共通の認証機能 は印刷ECにくっついたまま 認証 決済基盤 認証 New New New
11. © RAKSUL, inc. All rights reserved. M&Aの発生 - 複数サービス・複数プロダクト・ M&A サービス 梱包材ECの「ダンボールワン 」と ハンコECの「ハンコヤドットコム 」がM&Aによりグ ループイン シナジーの創出 が求められる アーキテクチャ M&Aを想定していなかった アーキテクチャに対してシナ ジー創出の戦略の元に ID連携や決済の連携 が求めら れる このままでは耐えられない ... 11 認証 決済基盤 認証 New New IDはどうする？ 決済は繋げられる？
12. © RAKSUL, inc. All rights reserved. ラクスル事業のサービス・アンチパターン 12
13. © RAKSUL, inc. All rights reserved. マイクロサービス化の始まり - 複数サービス・ 1プロダクト サービス 2015年 印刷ECサイトのラクスルを拡張 する形で集 客支援サービス (新聞折込やポスティング )開始 13 アーキテクチャ 一部マイクロサービス化 を開始(DBを共有するアン チパターンを踏む) DB New
14. © RAKSUL, inc. All rights reserved. もう少し詳細に 14 EC DB EC機能本体 旧 新 印刷発注 API 印刷原価 計算 原価 DB 切り出し 切り出し
15. © RAKSUL, inc. All rights reserved. 抱えている課題 15 EC DB EC機能本体 旧 新 印刷発注 API 印刷原価 計算 原価 DB DBを共有 同一テーブルを複数 のアプリケーションか ら参照 実際に切り出せたのは 一部商材のみ
16. © RAKSUL, inc. All rights reserved. モノリスからマイクロサービス化へのパターン 16 DB アプリケーションを先に分ける モノリス 新 DB DBを先に分ける モノリス 新DB DB 同時に分ける モノリス 新DB 新 メリット ・短期的にはマイクロサービス化の恩恵を 受けやすい デメリット ・DBを共有したままにすると徐々に辛くなる 　・テーブルスキーマの変更に複数のアプリ ケーションが追従しなくてはならない メリット ・データを軸に切り分け方を探索し易い ・比較的切り戻しし易い デメリット ・短期的なメリットは薄い メリット ・切り分け方が明確であれば一度に理想状 態に移行できる デメリット ・難易度が高い 　・一発できれいに切り分けられない ・設計・開発に時間がかかるので最初に恩恵 を受けられるまでの時間軸が長い
17. © RAKSUL, inc. All rights reserved. 課題にどう向き合っているか 17 EC DB EC機能本体 旧 新 印刷発注 API 印刷原価 計算 原価 DB 印刷発注基盤 DB 印刷発注 基盤 廃止する方針 一定辛みを伴うが再度責務を切り直し印刷のラクスルだけでなく他サービスからも利用できるような形でリアーキテクチャ 以前のマイクロサービス化で得られた知見を元にあるべき姿で作り直し中 　→ もともとのマイクロサービス化は無駄では無かった 移行のやりきり
18. © RAKSUL, inc. All rights reserved. まとめ・学び • 当時の判断としては必ずしも間違っているわけではなかった ◦ 拡張の難しいレガシーコードに変更を加えるより、コードを切り出したほうが短期的にはリリー スが速かった ◦ ベンチャーにおいて速さは重要 • アンチパターンとしては共有DBをそのままにし続けてしまったこと ◦ 2重メンテ、3重メンテが頻発する結果に • マイクロサービス化を進めるのであればゴール設定は重要 ◦ 中途半端になってしまうと事態は悪化する ◦ あるべき姿を描き、あるべきに向けたステップを明確化してからスタートすべし 18
19. © RAKSUL, inc. All rights reserved. WE ARE HIRING!