BT

マイクロサービスアーキテクチャと異なる選択肢、サービスに基づくアーキテクチャ

| 作者: Matt Fletcher フォローする 0 人のフォロワー , 翻訳者 猪股 健太郎 フォローする 0 人のフォロワー 投稿日 2016年10月17日. 推定読書時間: 4 分 |

原文(投稿日:2016/10/07)へのリンク

ThoughtWorksディレクターのNeal Fordが最近の講演で論じたところによると、組織は一枚岩アーキテクチャからマイクロサービスアーキテクチャに移行するよりも、サービスに基づくアーキテクチャへ移行するほうが容易とのことだ。FordがUberConf 2016で話したサービスに基づくアーキテクチャとは、サービス指向アーキテクチャとマイクロサービスアーキテクチャの中間点である。スライド (PDF) はこちら

マイクロサービスアーキテクチャには多くの利点があり、新規プロジェクトではそれを勧めるとFordは言う。しかしすでに一枚岩アーキテクチャを所有している組織にとっては、マイクロサービスへの転換には何百もの困難がある。コードの分割だけでなく、おそらく一枚岩データベースの分割も必要となるし、DevOpsプラクティスを採用したり、サービスを監視したり、ネットワークや分散トランザクションなども考慮が必要である。サービスに基づくアーキテクチャへ転換するのであればそこまで多くの変更が必要になることはない。一枚岩システムから、大まかにドメイン中心となっている8~15個のコードの塊を削りだすだけである。サービスに基づくアーキテクチャは数十個程度のデプロイ可能なサービスから構成されるもので、マイクロサービスの支持者が提唱するような数百から数千のサービスではない。それらのサービスのデータストアは分離していてもよいが、一枚岩データベースを共有したままでも構わない。Fordはその点を差別化ポイントの鍵としている。大規模なデータベーススキーマを分割することの難しさが、マイクロサービスへ移行するにあたってもっとも複雑な部分のひとつと考えるからである。しかし、マイクロサービスアーキテクチャの利点というものは、個々のサービスが自身のデータの所有権を単独で持った状態、できれば個別のデータストアを持った状態になって初めて得られるものではある。

Fordが指摘したことは、マイクロサービスはある種の複雑さを持ち込んでしまうということである。すべての要求についてそれぞれどのような呼び出しの連鎖が起こりうるか、そして、ネットワークを通る追加の呼び出しすべてが性能に与える影響、これらを把握するのは困難である。単体のマイクロサービスは、ビジネスドメインについても性能についても、小さくて理解しやすいものかもしれない。しかしマイクロサービスが連なったものはそうではない。サービスに基づくアーキテクチャの場合は、コードをドメインごとにもっと大きな塊としてグループ化しているため、ネットワーク呼び出しの数が制限される。その結果としてよりよい性能が得られる。もしマイクロサービスアーキテクチャだったなら十数個の関連するマイクロサービスを呼び出すグラフ構造となっていたかもしれないものが、単独サービスの内部におけるメソッド呼び出しで収まるからである。

この中道的アプローチにはトレードオフがある。マイクロサービスとはデリバリー速度と拡張性を最適化するものであり、DevOpsプラクティスを採用したり、コードをデプロイ可能だが非常に小さな単位に分解したりする。サービスに基づくアーキテクチャは、コードをドメイン中心的な方法で分割することで、一枚岩システムやサービス指向アーキテクチャ(SOA)よりも高いデリバリー速度を達成する。このドメイン中心的な分割は、マイクロサービスとDDDの支持者が提唱する方法である。SOAの場合はドメインではなくレイヤー(論理階層)によってアーキテクチャを分割しようとする。このようにすると、業務観点での小さな変更が複数のレイヤーに影響を及ぼしがちであり、リリースする前に多くのテストが必要となってしまうことがある。ドメイン中心のアーキテクチャは、リリース前に実施するテストの境界面を単一の構成要素に落とし込むことで、一枚岩システムやSOAと比べるとデリバリー速度が向上するだろう。構成要素が小さければ小さいほどテストの境界面も小さくなるので、マイクロサービスはそのように最適化しようとする。しかしサービスに基づくアーキテクチャにおいても動作するソフトウェアのデリバリー速度は向上するはずだ。

Fordの論では、これらの異なるアーキテクチャについてさらに多くの切り口で比較している。氏が推奨したのは、重量級の環境におけるシステム統合にはSOAを使用し、新規プロジェクトならマイクロサービスアーキテクチャを、そして一枚岩アーキテクチャからの移行ではサービスに基づくアーキテクチャを使用することである。最終状態として一枚岩アーキテクチャは推奨しなかった。氏とはまた別に、熟達したエンタープライズアーキテクトであるMark Richardsも、UberConfにてサービスに基づくアーキテクチャについて講演した。そちらのスライド (PDF) はこちら。二人が共同で公開した動画をO'Reillyのサイトで観ることができる。こちらは同じテーマをさらに深く掘り下げている。

この記事に星をつける

おすすめ度
スタイル

こんにちは

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

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

あなたの意見をお聞かせください。

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

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

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

このスレッドのメッセージについてEmailでリプライする

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

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT