ユニクロも導入を決めた！「マイクロサービス」はなぜ必要か？
マイクロサービスが今脚光を浴びています。
米Netflixや米Amazonなど、そうそうたるスタートアップ企業がこのアーキテクチャを採用しています。
日本ではクックパッドの導入が有名で、開発ブログや発表資料でどのように適用しているのかが掲載されています。
このように今まではWebサービスを提供する企業がマイクロサービスを導入していたのですが、今度はデジタル変革を掲げるユニクロが全ての業務領域でマイクロサービス化を進めるなど、大規模企業の基幹システムにも導入されようとしています。
マイクロサービスとは？
そもそもマイクロサービスとは、一言でいうと
「サービスを細かく分けてWeb API駆動によりサービス間を疎結合にする」
ということで、反対にシステム全体が一枚岩になっていることを「モノリシック」と呼びます。マイクロサービスには、巨大なシステムを独立した小さなサービスに分けることで「メンテナンス性をよくしよう」「開発速度を高めよう」という狙いがあります。
Microsoftが解説しているマイクロサービスと従来のシステム構成の比較について見てみましょう。
このようにサービスに分けるというのは業務ロジックだけではなく、データもサービスによって分けることで完全に独立させています。
もっとも、この図のようにサービスもデータも分けるということは今のところは現実的でなく、マイクロサービス化している各社はシステムの特性に応じた独自の定義で開発をしています。
なぜマイクロサービスなのか？
なぜマイクロサービスがクローズアップされてきているかというと、「インターネットによる商構造の変化」があると考えられます。
インターネットは商構造を劇的に変化させました。商品やサービスを提供する側から直接購入することができるようになり、提供する側はより安く、より速く提供できるようになりました。
より速く提供できるようになると、今度はより速く変革や改善をしないと競争力がなくなってくる、つまり、
「より速くサービスを開発する」
そういった時代に突入しています。とにかく短期間で開発しなければならない、となった時に
「メンテナンス性は後回しにして、とりあえず動くものを作ろう！」
ということになるのは致し方ないのかもしれません。
こうしたやり方で時間の経過とともにどんどんソースコードが積みあがってくると、俗にいう「スパゲッティプログラム」となり、第三者がソースコードを見ると何が何だかわからない状態になってしまいます。
技術的負債の足枷とは
こうした状態になることを
「技術的負債」
と言いますが、もしそうした負債を抱えても同じ人がずっと開発を担当するのであれば何ら問題はありません。その人はソースコードを隅々まで理解しているので、システムの改良をしてもどこを直せばよいかがわかるからです。
しかし、提供するサービスが10年、20年と続いたらどうでしょう。継続するサービスは、システムの規模も大きくなります。そうした時には複数の開発者で分担して開発しなければなりません。もしかしたら当時の開発担当者は退職しているかもしれません。その時に改修をした場合、思わぬところで予期しない動作をしてしまう場合があります。
テストをちゃんとすればいいんじゃかないかと思われるかもしれませんが、それもシステムが肥大化するとかなり大変になってきます。たとえ1行のコードを修正するだけでも、モノシリックなシステムであれば極端に言うとシステム全体をテストしデプロイしなければなりません。
つまり、
コード修正がもたらすビジネスのインパクト ＜ 開発工数
となってしまうのです。
マイクロサービスは技術的負債を解消できるか？
マイクロサービスはスパゲッティ構造になることなく、迅速にスケールアウトして開発していけるということで期待されています。
ただし、「互換性がある限り」というところがネックで、インタフェースが変更になった途端、そのサービスを使う全てのサービスに修正が入ります。そして、インタフェースの変更はサービス間の関連が深くなる基幹システムには頻繁に発生すると予想されます。
ユニクロはECサイトやスマホアプリからマイクロサービス化を始めて、将来的には商品管理や在庫管理のマイクロサービス化を視野に入れています。互換性という課題をいかにクリアしてどこまでマイクロサービス化を実現できるか注目です。
