レベル: 中級 Judith Myerson (jmyerson@bellatlantic.net), Systems Engineer and Architect
2008年 1月 24日 密結合の Web サービスと疎結合の Web サービス双方の長所と短所、そして密結合することによる規模の変化について調べましょう。この記事では、テスト・プロセスの際に密結合の Web サービスのパフォーマンスを測定するための基準についての例も説明します。
はじめに
私は developerworks のシリーズ「WebサービスのコンテキストにてSLAを使用する」の中で、脆弱性のリスクを軽減し、また SLA (service-level agreement) による保証によって Web サービスを EAI (Enterprise Application Integration) に統合するための方法について解説しました。また developerworks の別のシリーズ「エンタープライズ規模の SOA における Web サービスの取り扱い」では、Web サービスのロード・バランシングと、RFID (radio frequency identification) Web サービスを EAI アプリケーションに統合するための方法を解説しています。また後者のシリーズは、リスク管理 Web サービスの開発と、発見可能な Web サービスとしてのレガシー・サービス・コンポーネントのマイグレーション、そして IBM WebSphere® MQ を使って IBM® DB2® と Oracle に SAP を統合するための Web サービスの開発についても解説しています。
私はそれぞれのシリーズの中で、SOA (Service-Oriented Architecture) が、Web サービスやその他の対話動作を行うソフトウェア・エージェントの間での疎結合にどう関連しているかを示しました。私は一般的な意味で、規模の変化によってリソース不足に陥りつつある場合や、実行スピードが重要な場合には、一部の Web サービスを密結合にする必要がある可能性があることも指摘してきました。
アプリケーションやシステム、そしてネットワークは一般的に、与えられたリソースの能力よりも速い速度で成長し、そうしたリソースの中には Web サービスに対するメッセージ・キューも含まれています。このためセキュリティーとパフォーマンスの懸念が生じます。どのような場合であれ、何らかの原因で最大能力による制限を超えると、メッセージ・ベースの Web サービスにシステムの過負荷が発生します。
この記事では以下の内容について学びます。
- 密結合と疎結合の比較
- なぜ Web サービスを密結合する必要があるのか
- 同期ビジネス機能はどのようにすれば、非同期で疎結合の Web サービスに見えるのか
- Web サービスをどのようにして疎結合から密結合に切り替えるか
- パフォーマンスの測定をするためにどんな基準を使う必要があるのか
- 測定を制限するものは何か
密結合と疎結合の比較
大規模で複雑なシステムの大部分は、独立した小さなサブシステムの大きな集合として構築されるのではなく、大きなサブシステムの小さな集合として構築されます。その理由は、比較的独立した小さな要素にシステムを分離することでは実現できない、パフォーマンスやセキュリティー、経済性、その他の重要な特性を向上させられる可能性があるためです。一般的に、大規模なシステムでの密結合の特性は、全体としての設計を最適化することによる結果と、システムのコンポーネント間の冗長性と非効率性を最小限にする結果から生じています。そのため、システムのコンポーネント間の結合は密になり、重要な相互依存関係が大量に発生します。
システムのコンポーネント間の結合が密になることによる 1 つの欠点が、個々のコンポーネント内の障害によってシステム全体が使用不能になりがちなことです。疎結合の Web サービスは密結合の Web サービスよりも適切なものと考えることができます。つまり (フェイルオーバー用の Web サービス・サーバーが用意されている限り) 1 つの Web サービスの障害によってシステム全体が使用不能になることはありません。
疎結合の Web サービスでは、呼び出される Web サービスの機能に影響を与えない限り、詳細部分を変更することができます。密結合のシステムは維持管理が困難になりがちですが、それはシステムの 1 つのサブコンポーネントを変更すると、通常、他のサブコンポーネントは即座にそれに適応する必要があるからです。
疎結合の Web サービスは、(冗長性を最小限にとどめる) クライアントとサービス間の密結合の場合とは異なり、十分な冗長性が必要になります。リッスンしている側の Web サービスと要求している側の Web サービスは、お互いに相手を信頼しないかもしれません。これはつまり、リッスンしている側と要求している側の双方が相手を信頼できるように、セキュリティーと信頼性を確保するための標準を追加する必要がある、ということを意味しています。一方、密結合で呼び出し、また呼び出されるシステムでは、相手を信頼するために相手が何を要求しているのかを双方が知っていることが前提となっています。
なぜ Web サービスに密結合を使うのか
Web サービスは、リソースが不足しているかどうかによらず、通常はメッセージ・ベースであり、疎結合です。つまり Web サービスは、メッセージ・キューからの応答を待ってから、こうしたメッセージの内容に基づいて、(もし追加のアクションがあれば) 追加のアクションを行います。Web サービスは、メソッドを呼び出すのではなくメッセージを渡す、という利点があり、そのため送信側の Web サービスと受信側の Web サービスとの間に一定の独立性を保つことができます。
大量の Web サービスがある場合、もし Web サービスが全体としてメッセージ・キューイング・システムのリソース能力を超え、またもし新しい機能を持った Web サービスの構築や再利用の計画段階でピーク負荷を処理する能力が考慮されていないと、システム過負荷を引き起こします。そうした場合には、一部の Web サービスを密結合にするための計画を開始する必要があります。
非同期と同期の比較
疎結合の Web サービス・アプリケーションは、非同期型でも同期型でも通信を行うことができます。非同期型の Web サービスは、アプリケーション同士が標準的なメッセージ・ベースの同じインターフェースをサポートしていて、さらに標準的で相互運用可能な言語 (例えば SOAP など) を話す限り、お互いに通信を行います。非同期型の場合に応答を保証してくれるのは、例外処理機構とエラー回復機構です。同期型の Web サービスでは、お互いの通信手段に互換性がなければなりません。
非同期型で疎結合の Web サービスは、応答を待つために時間を費やします。同期型で疎結合の Web サービスは応答を待つことはできず、応答が返ってくるまでプログラムをロックします。同期型の呼び出しをプログラムすることはできますが、タイムアウトを付加する必要があります。そうすることによって、一定時間内に呼び出しから戻れない場合には、呼び出し側の Web サービスのロックを解除してシステムでの動作を終了することができます。
非同期型で疎結合の Web サービスの 1 つの問題は、一部のビジネス機能に対して、メッセージ・キュー・サーバーやシステムのリソース能力を超える可能性があることです。
ビジネス機能
ビジネスは通常、信頼性やスケーラビリティーの理由から非同期型ですが、一部のビジネス機能は同期型のトランザクションを必要とします (例えば在庫に対するクエリーや、スケジュール変更、クレジット・カードによる取引の承認や不承認など)。オンラインで本を扱う Web サービスのシナリオを調べてみましょう。このシナリオでは、疎結合で同期型のビジネス機能が、非同期モードではないのに非同期モードで動作しているように見えます。
非同期モード
ここで取り上げる例は、オンラインの書店と取引を行うプロセスです。まず好きな本を選択したら、それらの本をショッピング・カートに入れます。何冊かを削除したり、他の本を追加したりするかもしれません。しかし最終的に、ショッピング・カートという Web サービスが、買い物の終了を非同期モードで待っています。買い物を終えると、クレジット・カードでの支払いオプションを選択して購入します。
次に、システムは、カード情報の検証のための外部ソースを使ってチェックを開始します。もし、数分間、応答を待つように指示するメッセージが表示された場合には、システムは非同期モードで動作しています。一方、もしシステムがクレジット・カード情報を瞬時に検証して承認する場合には、システムは同期モードで動作しています。
同期モード
同期モードは、瞬時の応答を待つ間、Web サービス・アプリケーションをロックします。もしアプリケーションが数秒でタイムアウトする設定をしている場合には、同期モードは指定された時間で終了し、アプリケーションのロックを解除し、そしてトランザクションを完了するために後で再度操作するようユーザーに指示します。応答を取得できると、クレジット・カード情報が承認されたのか不承認なのかを知ることができます。情報が承認されると、ユーザーはお礼の通知を受け取り、そして本が到着するのを非同期で待ちます。
切り替えモードの欠如
このシナリオの問題は、この Web サービスの一部の非同期機能が、イベント警告機構に応答して疎結合から密結合のモードに切り替える機能を持っていないことです。これは、システムの規模の変化がシステムのリソース能力を超えてしまうことを示しています。
規模の変化
リソースの量は、アプリケーションが実行されている裏で、少ない状態から多い状態へ、あるいはその逆に、変化する可能性があります。理論的には、リソースの量が多い場合には、疎結合の Web サービスはメッセージ・キューイング・サーバーからの応答を待ちます。しかし実際には、メッセージ・キューイングのリソースは、十分ではないか、あるいは Web サービスがメッセージの送信または受信を待っている間は十分であるかのいずれかです。
結合の切り替え
一部の Web サービスを規模の変化に対応させるためには、その Web サービスに対応するリソースが一定レベルに達したときに、イベント警告機構によってトリガーされて、疎結合から密結合に切り替えを行うことのできる Web サービスを検討する必要があります。切り替えを行う際には、そのリソースは、Web サービスが必要とする場合には動的に割り当てられ、必要なくなれば割り当てを解除されます。
WS-Addressing
Web サービスが密結合の場合には、その Web サービスは ReferenceProperties を使って WS-Addressing EndpointReference を有効にし、その一方で WS-Context を無効にする必要があります。WS-Addressing のセッション・モデルによって Web サービスのエンドポイント情報とセッション・データとの間が結合されます。これは分散オブジェクト・システムでのオブジェクト参照に似ています。
WS-Context
Web サービスが疎結合モードに切り替わった場合には、その Web サービスは WS-Context を有効にし、その一方で WS-Addressing を無効にする必要があります。WS-Context はセッション・モデルを提供しますが、これは HTTP サーバーと HTTP トランザクション・システムに見られるセッション・モデルが進化したものです。WS-Context のおかげでサービス・クライアントは、Web サービスとの間に動的かつ一時的な関係をごく自然に結ぶことができるようになっています。
パフォーマンスを測定する
一部の Web サービスを密結合にする計画を立てたり、あるいは既存のWeb サービスの一部をその結合の切り替えができるように再設計したりする場合には、パフォーマンス測定を行う際の目標を設定する必要があります。この目標を設定するためには、ネットワークとアプリケーションの両方のレベルでパフォーマンスにどんな基準を使用するのか、またどんな制約がパフォーマンスに影響するのかを考慮する必要があります。
以下に示すのはパフォーマンスの基準を設定する際に考慮する必要のある事項です。
- 各 Web サービスがメッセージを受信するまでの最長待機時間
- ある一定時間内に、最長待機時間の範囲に入っていた時間と回数
- モード切り替えを開始してからその切り替えプロセスが完了するまでに必要な時間
- 最長待機時間の範囲に入っていた頻度 (例えば、週末の夕食後)
- その Web サービスがデプロイされた最初の月に発生したピークの回数
- SLA で保証された可用性に対する規模の変化の影響
- テスト・プロセス中および実動時に実現する必要のある、保証されたサービス可用性の範囲
こうした推奨事項はどれも、SLA やセキュリティー・ポリシー、テスト・プロセス、会社の方針、そして政府による規制といった制約に影響されます。
まとめ
Web サービスを密結合させることを検討する場合には、開発者とテスター、そしてシステム管理者によるチームが必要です。そして密結合の Web サービスを開発、テスト、デプロイする際の問題や、不足するリソースにシステム過負荷が発生しないようにするために密結合モードに切り替え可能な疎結合の Web サービスを開発、テスト、デプロイする際の問題に対して、あらかじめ計画を立てておかなければなりません。こうした問題を解決しておくと、密結合の Web サービスの設計や開発、そしてデプロイメントの作業に役に立ちます。IBM Rational® ClearQuest® と IBM Rational Functional Tester を使うことによって、エンタープライズ SOA 開発プロジェクトにおけるテスト時間や欠陥追跡時間、そしてテスト作業場所のコストを削減することができ、生産性を高めることができます。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | | | Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。 |
記事の評価
| 
