モノリスの限界を示す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では、社内の特定のモノリスを分割して、マイクロサービスに移行しているさなかだ。つまり両方使っている。あるところではモノリスを使い、別のところではマイクロサービスへの移行を完了している。当社は、進化途上の中央に位置している。同じような位置にいる企業は多いと考える。
――モノリスが有用性の限界に達していて、マイクロサービスの導入を検討するタイミングにあることを示す兆候にはどのようなものがありますか。
シャウプ氏 まず、チームを増員できない状況が挙げられる。つまり、チームに人を増やしても、モノリスでは全員のイライラが募り、全員の速度が低下し始める。
次に、パフォーマンスが拡張のボトルネックになるときだ。Twitterは最初のころ、ひっきりなしにダウンしていた。人気の高まりがダウンを引き起こしていたといえる。単純に言えばモノリスではその負荷に耐えられなかったということだ。そのため、Twitterはモノリスを小さなサービスに分割せざるを得なくなった。
もう1つは導入のライフサイクルだ。システムの中には、すぐにリリースしなければならないものと、急ぐ必要のないものがある。Webインタフェースであれば、変更が必要になるたびに、再リリースしなければならないかもしれない。だが、HTMLの一部を調整するだけのために、システム全体を再導入するとしたら、とても面倒だ。
モノリスを批判しているわけではない。モノリスはあるクラスの問題には完全に合理的なソリューションだ。ユーザーの数、チームの規模、導入のライフサイクルのいずれかが原因で、そのクラスを超える問題に発展したら、マイクロサービスのようなものに変える必要がある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[アルプス システム インテグレーション株式会社] 中小企業でも安心して活用できる「手ごろなSOCサービス」とは? -
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは -
市場調査・トレンド
[セコムトラストシステムズ株式会社] EDR導入を成功に導くロードマップ:選定/稟議/運用のつまずきを防ぐコツ
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
「IBM i(AS/400)はクローズドなシステム」という誤解 DXに寄与する一歩
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
5
生データを隠してデータ連携 KDDIが4000万人の顧客情報を安全に分析できた理由
-
6
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
7
「また同じ説明か」 消費者の半数が離脱するAIチャットbotの“記憶喪失”
-
8
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
9
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
10
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー