web-services - Web サービス ベースのアーキテクチャは実際にどの程度スケーラブルなのでしょうか?

Question

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

Answer 1

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

ネットワークのオーバーヘッドが、構築したいシステムの取引を妨げるものである場合、SOA は明らかに間違った選択です。HTTP 経由でサービスにアクセスする必要があるわけではないことに注意してください。一部のプロトコル ( など) の速さに驚かれると思いますnet.tcp。

Answer 2

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

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

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

スケーラビリティに向けた 1 つの大きなステップは、基本的な同期のクエリ/応答型サービス (SOAP RPC など) から離れて、非同期サービスに移行することです。Hohpe and Woolf の「Enterprise Integration Patterns」を参照してください。

Answer 3

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

ただし、SOA はすべてのソリューションに適しているわけではないため、特定のケースで明確な利点が見られない場合は、何もない可能性があります。

Answer 4

REST 愛好家は、REST はプロトコルではなく、アーキテクチャ スタイルであることを思い出させるでしょう。REST は、SOAP が使用するラッパーを使用せずに、HTTP を直接使用してサービス モデルを提供する方法です。REST は、SOAP よりもはるかにワイヤーに近いものです。それだけでどちらか一方が優れているわけではなく、どちらにもそれぞれの役割があります。

サービス モデルのスケーラビリティは、"サービス" (大文字の W と大文字の S を持つ Web サービスのように) に直接関係しているわけではなく、これらのサービスのステートレスな性質に関係しています。適切に構築された Web アプリはスケーラブルでもあり、サービス駆動型アーキテクチャと同じくらいスケーラブルであると主張できます。

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

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

Answer 5

では、まず「スケーラビリティ」を定義しましょう。ほとんどのものはスケーリングします。より多くの容量が必要な場合は、最初の概算で、ハードウェアを追加するだけです。しかし、一部のアーキテクチャは「よりスケーラブル」です — それはどういう意味ですか? それはコストと関係があります。追加された容量の単位あたりのコストが低いほど、アーキテクチャは「よりスケーラブル」になります。

一般に、スケーラビリティにはどのアーキテクチャにも 3 つの範囲があります。最初の部分には固定コストがあるため、ある間隔では勾配が 0 の直線的です。その時点を過ぎると勾配が増し、通常、ある時点で容量を追加すると非常にコストがかかります。

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

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

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

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

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

古い CGI ベースのアーキテクチャで見られたような限定的なケースは、各ユーザー セッションが完全な重量プロセスを必要とするケースです。fork/exec が負荷の 40 ～ 50% を占め、セッションを保持しているマシンにリクエストが常に到達するように複雑なソフトウェア負荷分散装置が必要なシステムを見てきました。単純にプロセス スロットが不足することが大きな問題でした。そのようなシステムの 1 つでは、容量を追加するためにまったく新しいハイエンドの Starfire サーバーを購入する必要がありました。