モノリスの限界を示す3つの兆候

判断基準は？　企業がマイクロサービスを検討すべきタイミング

モノリシックなアーキテクチャはあるときを境に限界を迎え、企業はマイクロサービスへの移行に迫られる。モノリスの限界を示す3つの兆候について紹介する。

　デジタルトランスフォーメーションを迫られている企業の間では、分散アーキテクチャへの移行、中でも特にマイクロサービスアーキテクチャへの移行がますます人気を博している。ただし、Amazon.comやeBayといった大手企業は、モノリスを小さく分割する作業に既に取り掛かっているが、大半の企業は依然としてマイクロサービスアーキテクチャが自社にもたらす価値を検討している段階だ。

　米国で開催されたソフトウェア開発カンファレンス「2017 QCon」で、オンラインパーソナルスタイリングサービスを提供するStitch Fixのランディ・シャウプ氏にインタビューし、マイクロサービスの簡単な定義、マイクロサービス導入の実態、モノリスが限界に達していることを示す決定的な兆候について話を聞いた。

――マイクロサービスを簡潔に定義するとどのようになりますか。

ランディ・シャウプ氏　マイクロサービスの「マイクロ」はインタフェースのスコープを表している。コードの行数や開発時間の長さを表しているわけではない。つまりマイクロサービスとは、しっかりと定義されたシンプルなインタフェースを持つサービスだと考えている。また、組み立てが可能であることも必要だ。要するに十分汎用化されている必要がある。例えば「請求」のマイクロサービスがあるとする。多種多様なクライアントがこのマイクロサービスをニーズに合わせてさまざまな方法で組み立てることができなければならない。

　ソフトウェアの観点では、やや細分化の度合いが高いことを除けば、優れたクラスを構築することに他ならない。カプセル化されるクラスを構築し、データは内部に含める。インタフェースはシンプルに保ち、簡単に使用でき、理解しやすいものにする。こうした設計原則は、プロセスやサービスのレベルに適用されるものと全く同じだ。

――マイクロサービスの導入実態はどのようになっていますか。モノリスから脱却しようと考えても、依然モノリスに縛られている企業はどれくらいありますか。

シャウプ氏　まず言えることは、eBay、Amazon.com、Netflix、Twitterなど、多くの企業に話を聞いたが、恐らく想像している通り、どの企業も最初はモノリスだったということだ。だが、今挙げた企業は全て、いわゆるマイクロサービスアーキテクチャに変わっている。

　ポイントは2つある。1つは、どの企業も最初からマイクロサービスアーキテクチャだったのではなく、モノリスから始まっていることだ。もう1つは、時間をかけて自社のアーキテクチャを進化させていることだ。eBayの場合5世代をかけて進化させている。Twitterも、Amazon.comも、Netflixも同じだ。

　どの企業も、規模が小さいときにはマイクロサービスに手を付けていない。その理由を聞いてみると、事業の拡大には時間をかけたが、テクノロジーの構築には時間を割かなかったという。こんな話がある。1995年、eBayには競合会社があった。この企業は全ての時間を分散型システムの構築に費やしていたという。私たちがこの企業のことを知らないのには訳がある。同社が全力を傾けたのがサービスではなく、システムの構築だったためだ。

　では、実態はどうだろう。マイクロサービスは進化の途上にある。そのため、その進化途上のどの位置にいるかは企業によって異なる。先ほど述べた企業は着手も非常に早く、既に移行を終えている。Amazon.comは全てをマイクロサービスアーキテクチャに移行し、さらに新たなサービスを生み出しながら進化を続けている。

　だが、私の現在の勤務先、Stitch Fixでは、社内の特定のモノリスを分割して、マイクロサービスに移行しているさなかだ。つまり両方使っている。あるところではモノリスを使い、別のところではマイクロサービスへの移行を完了している。当社は、進化途上の中央に位置している。同じような位置にいる企業は多いと考える。

――モノリスが有用性の限界に達していて、マイクロサービスの導入を検討するタイミングにあることを示す兆候にはどのようなものがありますか。

この記事の著者

関連記事

• 

  ハイパーバイザーとの違いは？　「コンテナ技術」を活用する5つのメリット／デメリット

• 

  「コンテナ」の“誇大広告”にだまされないために確認すべきチェックポイント

• 

  マイクロサービスは小さく作ろうとすると失敗する

• 

  マイクロサービスで構築できる「成功するクラウドWebサービス」

• 

  AWSの最大の魅力はAPI、キヤノンのサービス開発部隊がクラウドで実現したこと

新着ホワイトペーパー PR

• 製品資料
  [株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる
• 製品資料
  [株式会社キーエンス] なぜRPA導入は頓挫する？　シナリオ作成の壁を乗り越える解決策とは
• 製品資料
  [株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？　PLMとの融合で実現する高速開発
• 事例
  [日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？　「新たな働き手」を支える3要素とは
• 製品資料
  [日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣