BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース マイクロサービスの長い歴史

マイクロサービスの長い歴史

ブックマーク

原文(投稿日:2016/11/25)へのリンク

マイクロサービスは非常に長い歴史を持ち、多くの人が思うほど短くはない。SOAも90年代に発明されたものではない。私たちは、50年の間にサービスの背後にある核となるアイデアに取り組んできた。Greg Young氏はロンドンで最近行われたマイクロサービスカンファレンスで、今日のマイクロサービスのアイデアにつながった核となるアイデアについてプレゼンテーションした。

Young氏は、マイクロサービスのいくつかの主要な特徴について、Martin Fowler氏を参照している。最も重要なことはシステム内のサービスを互いに独立して取り替えられる能力、ビジネス機能を中心とした組織化とスマートエンドポイントとダムパイプ(土管)の使用、Young氏の講演は、SOAのアスペクトも正しく扱っている

Young氏は、1970年代の元々のオブジェクト指向のモデルは、オブジェクトはメッセージを送信して実行する小さなコンピュータだったと述べている。同じ時期のアクターモデルは、似たようなコンセプトに基いている。メッセージをメールボックスに送信する小さなコンピュータであった。どちらもマイクロサービスの核となるアスペクトの先駆者である。ツールやメッセージ転送を変遷するかもしれないが、アイデアは同じである。現在、SOAは失敗したと言うが、マイクロサービスは成功するでしょう。しかし、Young氏は、SOAの基本コンセプトにも問題はないと主張する。マイクロサービスの優れたアスペクトは、既にSOAにあった。

私たちが過去50年間に学んだことによれば、Young氏は、分散コンピューティングの第1法則は、本当に必要な場合を除き、システムを分散すべきではないことを参照している。サービスを作り、同じサーバー上に、或いは同じプロセス上に、それらをホスティングするのは間違っていない。彼は、殆どのシステム、特に小規模ビジネスシステムはスケーラビリティのために分散する必要はないが、可用性のために分散されるかもしれないと主張する。

私たちが望むのは、サービス間の分離である。同じサーバー上で各サービスをそれぞれのプロセスで実行するとき、取り決めが守られることが保証される。より分離する方向への1つのステップは、Dockerコンテナ内で各サービスを実行することである。これにより、サービス間で共有されるものが少なくなるため、さらに分離される。もう1つのステップは、マイクロサービス毎にノードを実行することである。

特定の分離レベルを選択する理由の1つは、相関障害(correlated failures)を扱うことである。同じプロセス内で全てのマイクロサービスを実行すると、プロセスが再起動されると全てのサービスが強制終了することになる。別々のプロセスで各サービスを実行すると、そのプロセスが再起動されたら、1つのサービスだけが強制終了する。しかし、サーバーを再起動したら全てのサービスが強制終了される。1つのサーバ上の各サービスか2つのサーバー上の2つのインスタンスを実行することは、各サービスの可用性への影響を小さくしてサーバーを再起動することが出来る。

これらの分離レイヤーの各々にはコストも掛かる。同じサーバーの上でマルチプロセスで実行することは、例えばサービス毎のノードに比べて扱いが簡単である。これらのレベルが正しいのでもなく、他が間違っているのではなく、トレードオフである。分離レベルを大きくするとして、あなたのコストと複雑さも大きくなる。 そして、Young氏はSimon Brown氏に分かりやすく伝える。

単一プロセスの中にモノリス(一枚岩)を構築することが出来ないとしたら、中心にネットワークを置くことが助けになると思うか?

Young氏が言うには、これらの異なる種類の分離の利点の1つは、先々を決める必要がないことである。そして、開発と同じレベルを本番で使う必要はない。これがマイクロサービススタイルのアーキテクチャの主な利点であると指摘する。

ロンドンで行われる来年のマイクロサービスカンファレンスは、2017年11月6・日に予定されている。

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT