商材単位でマイクロサービス化するECサイトの設計は有り得るか？〜あるECサイトの例で考える

＼スニダンを開発しているSODA inc.の Advent Calendar 2日目の記事です!!!／

背景

あるECサイトの主力商材は「NIKEのスニーカー」と「ポケモンカード」の2点である。

なぜ消費者層の異なりそうなこの2点が主力かというと、このECサイトのコアコンピタンスが「一品ごとに真贋・品質の鑑定を行っていること」だからである。

• 高価で取引される一方その真贋や品質が重要視される商材でもあるスニーカーやトレカが、鑑定というコアコンピタンスでもって主力商材となっている。

筆者はこのECサイトの将来について考えてみた。

• このECサイトはコアコンピタンス（鑑定）を生かせる商材を少しずつ増やしていきたいと考えているかもしれない。例えば「バスキアの絵画」「ジャパニーズウィスキー」など。
• 一方で、こういった商材はいつ人気が下火になるか分からない。その場合は商材の取扱いを縮小・停止し、速やかにリソースを次の商材に回したいと考えるかもしれない。
• また、このコアコンピタンスが生かせる商材は有限であろう。

以上の条件にマッチするような「有限の商材を素早く追加、削除、改修できるような仕組み」を考えた時に、商材ごとにマイクロサービス化してみるのはどうかと思った。

マイクロサービス化は言うは易し行うは難しだが、裏返せば言うだけタダなので、この記事でもって考えてみる。

マイクロサービス化することで得られるメリット

• 商材の入れ替わりが激しい場合、入れ替えていく中で負債が溜まっていくのが目に見える。マイクロサービス化することで商材の増加による複雑度の増加を回避でき、ディスポーサビリティも高まる。
• マイクロサービス化することで、既存の設計に引っ張られないので、各商材について最適化した設計ができ、競争優位を獲得できるチャンスが高まる。

マイクロサービス化した場合に問題となる部分

• マイクロサービスとはいえ0からサービスを構築しなければならない状態ではサービスインが遅くなる。共通機能を提供できる仕組みが求められる。
• 商材間の結合度が大きいならうまみがない。事業がpivotして商材が増えて普通のECのようになった場合は破綻する恐れがある。
• その他マイクロサービスアーキテクチャ自体の難しさ（サービス境界定義、インフラ運用、分散トランザクション等）

高速にサービスインできるか？

新たな商材が流行った時、その流行に一早く乗って、高速にサービスインできることは重要と考える。
「モノリスとマイクロサービス、どちらが高速にサービスインできるか？」を考えると、一概に言うことは出来ないだろうが、ここではどういう条件であればマイクロサービス化のメリットを享受できるかを考えてみる。

• モノリスの場合は、既存機能を使いまわすことを前提に高速にサービスインできると考えられるかもしれない。しかし、フェーズが進むにつれて速度が落ちていくことが考えられる。例えば、商材間の差分を既存設計で吸収できなくなって負債化することや、既存機能の改修が必要になってサービス全体への影響を考慮しなければならなくなることが考えられる。しかも、将来どんな商材がバブルになるかは誰にも分からないので、予め綺麗な設計をしておくことはいささか難しい。
• マイクロサービスはそのような課題から自由になれるが、先述した通り全てを1から作らなければならないとなると明らかに工数が掛かる。ボイラープレートを用意するなり、共通機能を切り出しておくなりする設計が必要である。その設計については上述のモノリスの課題と同じことにならないよう慎重に行う必要がある。

モジュラーモノリスはどうか？

モジュラーモノリスとは、ソフトウェアについてはモジュール分割しつつ、それが動作するインフラは単一とする設計パターンである。モノリスからマイクロサービスへの移行の中間段階として採用されたり、あるいは両者の折衷案として積極的に採用されたりする。
ここまでの殆どの議論では、ソフトウェア設計を分割することについて考えてきた。よって、マイクロサービスよりもむしろモジュラーモノリスに向いているかもしれない。
一方で、インフラすら分離したい場合も考えられる（特定の商材が、非機能要件が厳しかったり、スパイクアクセスが頻繁に来るようなものであったりなど）。
その場合はマイクロサービスが有効となる。

チームビルディングの観点から

マイクロサービスごとのチーム、すなわち商材ごとのチームになる。
各チームは各商材に特化した開発を行っていくことになる。
エンジニアだけでなく、意思決定者やUXデザイナーも、各商材のプロフェッショナルとして体験を設計していく。
ここは商材をモノリスとして扱う場合と大きく変わってくることである。
各商材について最適化したサービスを提供することが競争優位に繋がるのであれば、このチーム分けが適しているかもしれない。

サービス境界を商材とするのは適切か？

ここまで商材単位でモジュール分割することを考えてきたが、他の分割単位についても触れておく。
ECサイトをモジュール分割しようと考えた場合、機能ごとにモジュール化・マイクロサービス化することが一般的には考えられる。例えば、会員、出品、カート、購入決済、発送など。
結論から言うとこの記事はその境界を否定しない。
むしろ、機能ごとの境界は必要に応じて積極的に切るべきであると考える。
ここまでの議論において、マイクロサービスのサービスインまでの速度を上げるためには、マイクロサービス間で共通で利用できる機能を切り出して提供する必要があることを述べた。
それはすなわち「商材モジュール」という縦割りのモジュールと「共通機能モジュール」という横割りのモジュールを共存させることを意味する。
そして、モジュール化する順序としては、「①共通機能のモジュール化→②商材のモジュール化」の順になると思われる。
フェーズが進むにつれて、モジュール分割の粒度が細かくなっていくイメージである。
この際、ある機能を共通機能モジュールと商材モジュールのどちらに寄せるかは、設計において重要な検討事項となる。

筆者のここまでの結論

「商材単位でマイクロサービス化するECサイトの設計は有り得るか？」という冒頭の疑問に回答する上では、「各商材について最適化した設計をすることが競争優位に繋がるかどうか」という点が一番の論点になると考える。
商材単位でマイクロサービス化することで、モノリスでは吸収しにくい商材ごとの柔軟な設計や改修が可能になり、商材単位でチームビルディングすることがしやすくなる。
一方、商材に最適化しなくても、共通機能を最適化することで事業を拡大できるビジネスモデル・フェーズ・規模であれば、商材ごとにマイクロサービス化する必要はなさそうである。

今後の展望

今回は思考実験までしか出来ていないので、このアーキテクチャを各観点からレビューしてもらい、答え合わせをしたい。

---

明日は、 @purple_dog さんから『一人情シス時代に学んだ「敗北条件から考えるシステム開発」（仮）』をお送りします！