BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース インクリメンタルなアーキテクチャアプローチ

インクリメンタルなアーキテクチャアプローチ

ブックマーク

原文(投稿日:2019/01/18)へのリンク

世界中のアプリケーションのほとんどのうち、おそらく90%は、モノリシックなアプローチで動いている。オーバーエンジニアリングを避けるために、私たちはシンプルなアーキテクチャから始めて、必要に応じて進化させなくてはならない、Randy Shoup氏はReactive Summit 2018でこう語った。彼は最近発表したプレゼンテーションで、小さく始まり、やがて大規模でグローバルなインターネット会社に成長した企業での経験、その期間にアーキテクチャがどのように進化したのか、そして、新しい会社や新製品を始める時のIT観点からの提案について説明した。

Shoup氏はeBay、Google、Stitch Fixで働いた経験があり、現在はWeWorkのエンジニアリング担当VPを務めている。彼が取り上げた最初の事例はeBayだった。1995年の3日間の週末プロジェクトとして始まり、ビジネスの概念実証(PoC)ではなく、ウェブで面白いことができないか確かめるのが目的であった。現在では、インフラストラクチャの5度目の完全な書き直しを行っているという。Shoup氏はeBayを多言語のマイクロサービスの集合体だと説明し、TwitterとAmazonも同じような進化を遂げてきたと述べた。

ある種のモノリスから始めてマイクロサービスの集合体で終わるのは、大企業によくあるパターンであり、このパターンには2つの要素があるという。誰もマイクロサービスから始めないこと、そして、ある規模を越えると、結局はみなマイクロサービスで終わることだ。

ここで言及した会社はすべて非常に大きい会社だ。その規模で動かすアーキテクチャは、ほとんどの会社にとっては適切でない、Shoup氏は指摘した。ほとんどのアプリケーションはモノリシックなアプローチで動いている。新しいアプリケーションやシステムを構築する時、シンプルに始めて必要に応じてアーキテクチャを進化させることを彼は推奨する。彼は次のように言い換えるのが好みだ。

もし初期の技術判断を後悔せずに終わるなら、あなたはおそらくオーバーエンジニアリングをしています。

Shoup氏によると、ほとんどの会社や製品に共通する成長曲線には、アイデアと開始のフェーズ、分散システムが関係するかもしれないスケーリングフェーズ、そして通常は最適化フェーズが含まれるという。

Architecture progression

アイデアフェーズでは、派手なアーキテクチャはまったく必要ない。ただプロトタイピングしているだけだ。オーバーエンジニアリングを避けるために、「自分たちはどんな問題を解決しようとしているのか?」と絶えず自問しなくてはならない。このフェーズの目標は、できるだけ迅速かつ最低限のコストで、ソリューション空間を探索することだ。

  • ビジネスモデルを見つける
  • 製品/市場フィットを見つける
  • 最初の顧客を獲得する

たとえば、Google広告を使ってクリックしてくれるか調べたり、ペーパープロトタイプやExcelスプレッドシートを使うなどして、可能であれば、あらゆるテクノロジから離れることを試みようと彼は提案する。

開始フェーズに移行した時、目標は近い将来の顧客のニーズを満たすこと、それをできるだけ安価にすることだ。通常このステージでは、4〜6名で構成されるチーム1つしかない。彼らは非常に短期間、おそらく3〜4ヶ月作業する。その理由の一つは、たいていの場合、どの機能を作るか先を見通すのが難しいためだ。先へ進むのに十分なだけの、最小限のアーキテクチャがあればよい。まだスケーリングは必要ない。シンプルで馴染みの技術を使うべきだ。それは間違いなくモノリシックなアーキテクチャ(単一のアプリケーション、単一のデータベース)だ。インフラストラクチャは最小限で、自分で構築してはいけない。彼は代わりに、PaaSや同等の技術を使うことを提案する。

この時点でモノリシックなアーキテクチャを使う利点は以下の通り。

  • シンプルである
  • プロセス内の遅延しかないため高速である
  • ビルド・デプロイメントの単位が1つになる
  • 小規模で非常にリソース効率が良い

モノリスの主な欠点は、スケーリングの欠如と単一障害点のほか、モジュール化が貧弱であることだ。モジュール化は可能だが、それにはプログラミングとチームの規律を必要とする。しかし、このフェーズではどれも心配はいらないとShoup氏は指摘する。とはいえ、スケーリングの準備をする必要はあるだろう。モノリス内のコンポーネントやモジュールを使うことで、モジュール化の規律を守ることには価値がある。これにより、将来の修正や外部サービスへの置き換えが容易になるだろう。

このモノリスをいつ再設計する必要があるか、彼が気づいた警告となる指標は以下の通り。

  • ベロシティ: 結合ならびに分離の欠如により、デリバリー能力が低下する
  • スケーリング: 垂直方向のスケーリングが機能しなくなる、あるいはシステムの各部を個別にスケールする必要がある
  • デプロイメント: 異なる部分は異なるスピードで進化するので、独立したデプロイメントが必要になる

スケーリングフェーズに入った時、目標は急成長するビジネスに先んじること、そしてアプリケーションを稼働させ続けることだ。組織的には通常、チームの数を増やして、より長期にわたって取り組む。反復可能なプロセスを導入する必要もあるだろう。

技術的には、たいていの場合、スケーリングフェーズはスケールする技術への移行を意味する。通常、モノリスからサービスを分離していくことになる。非常によくあるのは、例えば、一部データについて読み出し専用のレプリカを作成することで、単一のデータベースに対する負荷を軽減させることだ。支払いや請求など特別なサービスを分離したり、イベントキューやメッセージバスを導入することから始めるのもよく見られる。

Shoup氏にとって、これは通常、モノリスを小さな独立したコンポーネント、今日のマイクロサービスと呼ばれるものに移行すべきか、検討するタイミングでもある。また、現在使っている単一のプライマリストレージが、依然としてデータを格納するのに適切な方法なのかどうかも検討する必要がある。QCon New York 2017で、彼はモノリシックなアプリケーションからマイクロサービスへインクリメンタルに移行する方法と、ドメインごとに独立したストレージメカニズムについて紹介した。

The Art of Scalability』という本では、スケーラビリティモデルの3つの軸(AKF Scale Cube)について書かれている。3つの軸はスケーリングの異なるタイプを示している。

  • X: 水平方向の重複と複製
  • Y: 機能の分解と分離(マイクロサービス)
  • Z: 水平方向のデータ分割(シャード)

最後のステップは最適化フェーズだ。それが達成できれば、成功のサインだ。目標は一連の機能を維持しながら、より少ないリソース、おそらくより少ないチームを使うことだ。これはより長期にわたり、おそらく2〜5年かかるだろう。

Shoup氏は最後に、このコンテキストで再設計する理由はポジティブなものだと述べた。

システムを再設計することは成功のサインです、失敗のサインではありません。

ビジネスは順調に進んでおり、あなたにはそのためのリソースがある。再設計を必要としているのではなく、むしろ再設計をする状態になったということだ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT