Webサービスベースのアーキテクチャは実際にどれだけスケーラブルですか？

Question

誰かがサービスベースのアーキテクチャについて話すときはいつでも、しばしば同じことを言ってスケーラビリティについて言及します。ただし、サービスを使用すると、SOAPやRESTなどのプロトコルが関与するため、サービスを削減するのではなくオーバーヘッドが増えるようです。では、Webサービスベースのアーキテクチャは、たとえばWebアプリケーションのユーザー数がおそらく桁違いに増加するので、実際にパフォーマンス上の利点が追加されますか？または、スケーラビリティ要件は、コアアプリケーションではなく、サービスに単純にオフロードされますか？

Answer 1

スケーラビリティとパフォーマンスは2つの別個のものです。はい、サービスベースのアプローチはネットワークプロトコルのオーバーヘッドを追加しますが、これはドメイン上のアプリケーションで十分にテストされたサービスを迅速に採用できるという利点に対する最小限の犠牲です。

ネットワークのオーバーヘッドが、構築したいシステムにとって重大な問題である場合、明らかにSOAは間違った選択です。 HTTP経由でサービスにアクセスする必要はありません。一部のプロトコル（ net.tcp など）がどれほど高速であるかに驚かれると思います。

Answer 2

Webサービスをスケールアウトして、クライアントに影響を与えることなく、複数のサーバーで実行できることを忘れないでください。密結合システムではうまく機能しません。

Answer 3

適切に設計されたSOAにより、システム内の各コンポーネントは他のすべてのコンポーネントとは独立して動作し、非同期で並行して実行できるため、パフォーマンスとスケーラビリティ（2つの異なる点）の両方がシステムで最も低速/最小のスケーラブルな部分によってのみ制限されます、すべてのコンポーネントのシリアル実行にかかる合計時間ではなく、

SOAはすべてのソリューションに適しているわけではありません。そのため、特定のケースで明確なメリットが見当たらない場合は、まったくない可能性があります。

Answer 4

Webサービスは、スケーラビリティを無料で提供しません。実際、スケーリングしない サービスを構築するのは非常に簡単です。

それらが提供するのは、スケーラビリティを構築する機会です。また、明確に定義されたサービスインターフェイスを使用することにより、必要に応じてサービスの迅速でダーティな非スケーラブルな実装をより適切な実装に交換できます。

重要なことは、「SOA」の「A」を忘れないことです。たくさんのサービスを作成するだけで巨大な混乱を作ることができます。アーキテクチャがあることを確認してください。

スケーラビリティに向けた1つの大きなステップは、基本的な同期クエリ/応答タイプのサービス（SOAP RPCなど）から非同期サービスに移行することです。 HohpeとWoolfの「エンタープライズ統合パターン」を参照してください

Answer 5

RESTafariansは、RESTはプロトタイプではないことを思い出させます。これはアーキテクチャスタイルです。 RESTは、SOAPが使用するラッパーなしでHTTPを直接使用して、サービスモデルを提供する方法です。 RESTは、SOAPのワイヤにはるかに近いものです。それだけでは、一方が他方よりも良くなることはありません。両方ともそれぞれの場所を持っています。

サービスモデルのスケーラビリティは、「サービス」にそれほど直接関係していません。 （大文字のWと大文字のSを使用したWebサービスの場合）、これらのサービスのステートレスな性質に対するものです。適切に構築されたWebアプリもスケーラブルであり、サービス駆動型アーキテクチャと同様にスケーラブルであると主張できます。

2つのモデルの違いの1つは、「サービス」なしのWebアプリバイナリレベルで同じプロセスに存在する参照モジュールと対話しています。シリアル化は不要です。 Webサービス（SOAPまたはREST）は、オーバーヘッドを追加する何らかのレベルのシリアル化を導入します。ただし、このオーバーヘッドは、それが提供する再利用を考えると価値があると見なされることがよくあります（つまり、アプリを内部的に駆動する同じWebサービスを使用してビジネスパートナーを満足させることもできます）。

1つの優れたアーキテクチャは、サービスクラス（Webサービスではなく、すぐに混乱する可能性があります！このコンテキストのサービスは、低レベルのビジネスプロセスを提供するクラスを意味します）をプロセスでローカルアプリに直接公開することです-このサービスとバイナリで通信する能力。ただし、ビジネスパートナーやその他のサービスで使用する場合は、これらの既にテスト済みのサービスクラスの上に薄いWebサービスレイヤーを配置して、Webサービスとして使用可能な同じサービスレイヤーを提供します。

Answer 6

さて、「スケーラビリティ」を定義しましょう。最初。ほとんどの場合、 スケールします。より多くの容量が必要な場合、最初の概算では、より多くのハードウェアを使用できます。ただし、一部のアーキテクチャは「よりスケーラブル」です。 ＆＃8212;どういう意味ですか？コストに関係しています。アーキテクチャは「よりスケーラブル」です。追加容量の単位あたりのコストが小さい場合。

一般に、拡張性にはどのアーキテクチャでも3つの範囲があります。最初の部分には固定コストがあるため、一定の期間にわたって勾配は0で線形になります。その時点を過ぎると勾配が大きくなり、通常、ある時点で容量を追加するのは非常に高価です。

システムは「線形に拡張可能」であると言います。追加された容量の単位あたりのコストを記述する関数が、広範囲にわたってほぼ線形である場合。明らかに、その勾配は小さいことが望ましいです。

つまり、今、誰かが「スケーラビリティ」について尋ねると、 SOA、SOAP、REST、その他何であれ、それが彼らが話していることです。

サービス指向アーキテクチャは「よりスケーラブル」であると言われています。あなたが言うように、単一のユーザーにサービスを提供するためにより多くの容量を必要とするオーバーヘッドがあるかもしれませんが、容量を追加することは比較的安価です。これは、大きなシステムを管理するコストと複雑さの大部分が、セッション状態を維持する必要性、つまり、呼び出し間で行われていることを追跡する必要性に起因するためです。サービス指向アーキテクチャは、RESTfulアーキテクチャが制限事項であるため、各呼び出しを次の呼び出しから比較的独立させることでそれを回避します。すべてのセッション状態は表現でエンコードされるため、システムの残りはそれについて知る必要はありません。容量を追加する場合、必要なことは別のサーバーを追加することだけです。メッセージを新しいメッセージにルーティングするには、単純な負荷分散で十分です。

（これは本質的にフォールトトレラントでもあることに注意してください。サーバーが停止した場合、他のサーバーは多かれ少なかれ自動的にリクエストを取得し、失われるセッションはありません。）

一部のJ2EEシステムのように、多くのセッション状態を必要とするアーキテクチャは、セッション状態を管理するために多くの余分な複雑さを必要とするため、スケーラビリティが低下する傾向があります。

古いCGIベースのアーキテクチャで見たような制限的なケースは、各ユーザーセッションが完全なヘビーウェイトプロセスを必要とするケースです。 fork / execが負荷の40〜50％であり、要求が常にセッションを保持しているマシンに届くように複雑なソフトウェアロードバランシングリグが必要なフィールドでシステムを見てきました。単にプロセススロットが不足することが大きな問題でした。そのようなシステムの1つでは、容量を追加するためにまったく新しいハイエンドのStarfireサーバーを購入する必要がありました。