はじめに: パフォーマンスの判断基準

Webアプリケーションのパフォーマンスはしばしば、どれだけ速くURL要求に応答するかによって測定されます。しかしながら、パフォーマンスをより広範囲に評価するためには、同時リクエストの影響、リクエストに対する応答の待ち時間、要求の増大を処理するためのスケーラビリティー、トランザクション負荷の増大に伴う運用効率の低下レベルなども考慮する必要があります。

どのようなプロジェクトにおいても、要求事項を収集するプロセスには運用面を考慮する必要があり、そのソリューションのパフォーマンスがどの程度であれば問題無しとするかを定量的に判断する必要があります。その判断基準は測定可能なパラメーター、例えばサポートできるユーザーの数、同時リクエストの数、一定時間に完了できるトランザクションの数などによって定義する必要があります。また機能とは直接関係しない要求事項、例えば技術の選択、ソリューション・コンポーネントの開発、それにデプロイメントの構成などが、全体的な設計の中で満足されていることも確認する必要があります。

アーキテクチャーはアプリケーションの振る舞いを保証し、またシステムが妥当な測定値の範囲内で運用できることを保証する必要があります。またソリューションの全体的な振る舞いが予測可能であることも保証する必要があります。例えばリクエスト数の増加によってソリューションに対する要求が次第に高まってきた場合、突然リクエストを処理できなくなるのではなく、最悪の場合でも要求の増大と共にリクエストの処理時間が増えるのみ、というようにすべきです。

この記事ではスペースの関係から、全体的な処理時間を改善するために、SOAPリクエストやレスポンス・メッセージ処理でのWebサービス機能の処理時間をいかに減少させるかに焦点を当てることにします。

上に戻る

Webサービスを強化する

この記事は「Webサービスのベスト・プラクティス」シリーズの一部ですので、ここではWebサービスをベースにしたソリューションのパフォーマンスに焦点を合わせます。パフォーマンス上の性能からWebサービスを統合技術として使用する、という決断は（少なくとも当面は）正当化されるものではない、ということをまず認めましょう。Webサービスの価値というのは、相互運用が可能になること、また柔軟性や資産の再利用、開発コストと運用コストの削減、顧客やビジネス・パートナー関係の改善などが図れるという点にあるのです。

このシリーズの最初の記事は、3種類のWebサービスをとりあげました。

• エンタープライズWebサービス ではWSDL記述が使用できますが、その企業独自のアプリケーション・メッセージングまたはトランスポート・プロトコルを使用する可能性もあります。例として、JMSを使用しIBM MQSeriesメッセージング・システムを通してSOAPメッセージを送信するサービスがあります。
• インターネットWebサービス は、オープンなアプリケーション・メッセージまたはトランスポート・プロトコルのみを使用すべきエンタープライズWebサービスです。例として、HTTPでXMLメッセージを送信するサービスが挙げられます。
• XML Webサービス はインターネットWebサービスのうち、ごく小さなサブセットであり、W3Cに採用された（XMLをベースにした）メッセージング・プロトコルを狭い範囲のトランスポート・プロトコルを介して使う必要があります。具体的に言えば、XML Webサービスで送信するのはSOAPメッセージのみであり、しかもHTTP、SMTPまたはTCP/IP直接接続のみで送信します。

どの種類のWebサービスを活用するかを決定するにあたっては、サービス指向アーキテクチャーの価値を最大限に引き出すために、念入りな分析を行うことが望まれます。

Webサービスの使用を検証する

ソリューション・コンポーネント間の境界にてWebサービスを使用『しない』ことが許されるということは重要です。実際、どこでWebサービスを活用するかを考慮した上で判断を下すべきであり、ビジネス・ニーズに対応する技術的な要件を基に判断を下すべきです。場合によってはこれらの決断はトレードオフを伴いますが、要求事項の収集と優先順位付けを適切に行えば、どれを選択すべきかは明白かつ当然なものとなります。例えば、インターネットを介してのビジネス・パートナー・アプリケーションとの相互運用性(interoperability)が最適なパフォーマンス達成よりも優先順位が高いかも知れませんし、そうであればXML Webサービスは正当化されます。同様に、インターネットを介してのメッセージ交換における認証性と機密性の保証にSSLを使用するのはセキュリティーの観点から見て十分だと言え、パフォーマンスに及ぼす影響を考慮すれば、アプリケーションのエンド・ポイント自体の間にXML EncryptionやXML Digital Signaturesを使うようなレベルのセキュリティーは不要と言うことができます。

Webサービスは、それを正当化する要件がある場合にのみ使用すべきです。正当性には定量的なもの（異なるプログラミング・モデルを使用した異なるシステム間で相互運用が可能である）と定性的なもの、つまりビジネス資産を企業方針に適合させることによって将来的には測定可能な利点（例えばレガシー・コードを再利用するなどしてJ2EEや.Net、そしてWebアプリケーションが使用できるようにし、集約サービスを提供するなど）につながる、といった定性的なものが考えられます。現在ではJ2EEランタイムとパーサーによって、RMI/IIOPはSOAP/HTTPよりも大幅に優れたパフォーマンスを提供するため、イントラネットJavaアプリケーション間でエンタープライズWebサービスを使用することは簡単に正当化できます。

サービスのきめ細かさ

要求事項からWebサービスが現実的な統合技術であると分かれば、それをどのように利用して最大限の利益を得るかを判断することが次のステップになります。不必要なメッセージがインターネットを介して交換されるのを避けるために、Webサービスとして公開される機能のきめ細かさのレベルを決めることがこのステップには含まれます。パフォーマンスのルールとして、サービス自体は必要なパラメーターや情報を全て受け付けるように、なるべく粒度の粗いサービス(coarse grain service)を公開するようにします。そうすることにより、サービス・プロバイダーが受け取り側のアプリケーションに代わって、できうる限りのことを達成できるようになります。目標は、一連のビジネス課題を達成するために受け取り側が発行するリクエストの数を最小限にとどめることです。こうすることによって、複数の要求が集中した場合に重大な遅延を引き起こす原因となるネットワーク待ち時間、システムI/O、そしてスレッド/処理の待機状態の影響が、確実に最小限にとどめられるようになります。例えば、消費者が商品SKU番号や数量、クレジット/デビット・カード情報、請求先/発送先の住所情報、それに割引クーポンの指定などを全て１つのリクエストでできるようにした購買注文サービスをサポートすることも考えられます。この要求自体はサービス・プロバイダー側で複数のアトミック・トランザクション（クレジットカード認証、請求提出、在庫確認と更新、配送処理）を引き起こします。こうしたトランザクションは、全体的にはそのビジネス・プロセスをサポートしますが、個々のトランザクションは必要に応じて実行せずとなったり、取り消しとなったりすることがあり得ます。

上に戻る

Webサービスのパフォーマンス・ボトルネック

今日のWebサービス・ベースのソリューションにおける最も一般的な3種類のボトルネックは、まず間違いなく次のようなものでしょう。

• SOAPメッセージの構文解析。メッセージの容量の大型化にともない、構文解析に要する時間も長くなります。
• 「オブジェクトからXML」そして「XMLからオブジェクト」へのマーシャリングとアンマーシャリング。メッセージの構造が複雑になれば、プログラミング・オブジェクトとXML要素間のマッピングに必要な時間もそれだけ長くなります。
• XML EncryptionやXML Digital Signaturesを含むWS-Security機能の処理。アプリケーションのエンド・ポイント間のセキュリティーは代償を伴うものであり、サービス・リクエストの処理に予想外の長い待ち時間を追加することにもなります。

こうした機能を表現したWebサービス・コンポーネントが行うWebサービス・リクエストの処理を図1に示します。

受け取り側とサービス・プロバイダーで下位のスタック機能を取り替えれば、Webサービスのレスポンス処理のためのコンポーネント・スタックになります。

上記の3種類のボトルネックに対して、ソリューション効率を最適化する設計につながる一般的な慣例（プラクティス）を以下に示します。提案の大部分にはパフォーマンス向上のためにトレードオフを伴いますが、こうした提案は全体的な要求事項に基づいて考慮すべきです。

ペイロードのサイズ vs. ペイロードの複雑性

Webサービスのパフォーマンスの最適化を図るために明白なルールはペイロードを小さくそしてシンプルにすることです。しかしながら、実際のビジネス問題を解決することが重要な実世界では、このルールに従い続けると言う贅沢が通るとは限りません。長期間実行するビジネス・プロセスでは、関連するビジネス情報だけではなく、処理状態をも捉えたXML文書の交換を要求するかも知れません。大きなメッセージであれば構文解析の時間も長くなり、ネストした要素を持った複雑なXML構造であれば、マーシャリング(marshalling)やアンマーシャリング(un-marshalling)に時間がかかります。目標とすべきなのは、これらがもたらすインパクトを理解し、XMLメッセージの構造の簡略化とサイズの最小化を目的として、プログラミング・オブジェクトの設計に時間をかけることです。しかしながら、別々に分かれたメッセージ・トランザクションよりも、やや大きく複雑なメッセージを含む単一呼び出しを選ぶように心がけるべきです。ビジネス機能または実行されるタスクが本当に独立しているか、あるいは1つのタスクにすることよって他の複合タスクの処理が大幅に遅れてしまう場合にのみ、複数メッセージを考慮してください。

図2は一般的なSOAPランタイム（Apache SOAP、IBM WebSphere Application Server）のパフォーマンスです（IBMの情報提供源は、Harvey Gunther氏によるパフォーマンス分析です）。この図から単純なビジネス機能の処理時間の20%から35%をXMLメッセージの構文解析が占めていることが分かります。WebSphere Application Server V5.0.2 SOAPランタイムの部分で分かる通り、構文解析の最適化はここ最近でかなりの進歩を遂げたことは注目に値します。ただし構文解析は相変わらず、Webサービスに特化した処理のかなりの部分を占めています。

Document/Literal のエンコーディング vs. RPC/SOAPのエンコーディング

Webサービスには次の２つの理由から、できうる限り Document/Literal のメッセージ・スタイルを使うべきです。まず、Web Service Interoperability (WS-I) Basic Profile 1.0に準拠する相互運用性が高まります。もう一つの理由はパフォーマンスに関連するこの記事に関係してきます。Document/Literal によって、メッセージはより小型、単純になります。SOAPメッセージ本体のXMLデータをメソッド名要素でラップする必要はなく、XMLエレメントにデータ・タイプ属性が挿入されません。もう一つ、Document/Literal のメッセージ・スタイルが有利なのは、今日のIntegrated Development Environment （WebSphere Application Studio Development）とランタイム（WebSphere Application Server）は、オブジェクトとXML要素のマーシャルに、（SOAPエンコーディングと関連したものではなく、WSDLに含まれるXMLスキーマのために特に最適化された）JAX-RPCのシリアライザーとデシリアライザーのルーチンをサポートしているという点です。

SOAPメッセージの構文解析

XMLデータの構文解析を最小化する

内部での消費にも、ビジネス・パートナーによる外部での消費にもSOAPを利用するXML Webサービスとしてビジネス機能が公開されるのであれば、ゲートウェイやサービス・エージェントのような仲介者はSOAP本体の構文解析を最小限にとどめるか、または回避すべきです。Webサービスのインターネットへのアクセスを集中化させるためにゲートウェイ・コンポーネントが使用され、しかも（SOAP/HTTPからRMI/IIOPへののような）メッセージ操作やネットワーク・トランスポートが必要とされていなければ、ゲートウェイはSOAP本体の構文解析を実行すべきではありません。今日では多くのシステム管理ベンダーが、実際のWebサービスにフロントエンドを実行するサービス・エージェントを提供しています。これらのコンポーネントはシステム管理機能を提供する上で、SOAP本体内にあるビジネス・コンテキストの情報（ビジネス・パートナーのID、トランザクション相互関係子、メッセージID、認証コード）に依存しています。サービス・エージェントはサービス品質の要求基準を守るために、ビジネス・コンテキストを使用して、ビジネス・イベントの統計を提供し、ビジネス・ポリシーを強制し、要求の経路を指定します。最近では、WebSphere Application Server V5.1のWeb Services GatewayはSOAPメッセージの部分的な構文解析をサポートしています。同様に、システム管理ベンダーはパフォーマンスへの影響を最小化するためにSOAPメッセージを部分的に構文解析する機能を最近提供しはじめました。こうした機能を活用することは非常に重要です。

DOM構文解析 vs. SAX構文解析

DOM（Document Object Model）とは、W3C（World Wide Web Consortium）により開発されたオブジェクト・ベースのプログラミング・インターフェースです。これによって、XML文書内でノードのツリーとして保管されたデータにアクセスすることができます。一方SAX（Simple API for XML）はXML-DEVメーリング・リストのメンバーにより提供されるイベント・ベースのプログラミング・インターフェースです。SAXにより、プログラマーはイベントのシーケンスとしてXML文書のデータにアクセスできるようになります。Apache Xerces2 Javaパーサーはどちらのプログラミング・モデルをもサポートしますので、どちらも必要に合わせて簡単に選ぶことができます。どちらのインターフェースでもXMLを操作できますが、それぞれの手法はかなり異なります。DOMはXML要素のデータ・タイプに関係なく、メモリー上にツリーを作成します。XML文書全体がメモリー上に表現されることになります。従ってこの手法は大容量のメモリーを必要とし、非常に大きなXML文書を扱う場合には最良とは言えません。対照的にSAXはイベント・ドリブンであり、文書全体がメモリー上に存在する必要はありません。しかしプログラマーは自分でオブジェクト・モデルを作成し、SAXイベントを管理しなくてはなりません。つまり、結果として得られるオブジェクト・モデルがシンプルな場合には、SAXによる構文解析の方が速く、SAXはDOMよりも効率が良いのです。Xercesパーサーを使うのであれば、必ず最新バージョン（V1.4.0ではなく、V2.6.0）を使うことをお勧めします。ここ数年でめざましいパフォーマンス改善が行われています。

図2で見られるWebSphere Application ServerのSOAP構文解析の性能向上は、部分的にはSAX構文解析に移行した結果によることを注記しておきます。

ソリューションがSOAPメッセージの構文解析のために全処理時間の35%も費やしたとしても、驚くべきではありません。Webサービスを使用するのは相互運用を可能にするため、また運用コストや資産再利用を改善するためである、ということを忘れないでください。

オブジェクトとXMLをマーシャリングそしてアンマーシャリング

メッセージに関するオブジェクトやXMLスキーマが複雑になればなるほど、クライアントもサービス・プロバイダーも、より多くの処理を必要とします。クライアントはリクエストを発行する前にプログラミング・オブジェクトをXML要素にする必要があり、サービス・プロバイダーはリクエストを処理するためには、XML要素をプログラミング・オブジェクトにマップする必要があります。メッセージのリクエストとレスポンスの両方で注意深く設計がなされていなければ、配列の配列から構成されたオブジェクト、またはネストされた要素のネストされた要素からなるXML要素は間違いなくボトルネックになり得ます。最近では、多くの会社がOpen Application Group Information System（OAGIS）によるBusiness Object Documents（BOD）の使い方を標準化しています。こうしたXML文書のXMLスキーマには何レベルものネストされたXML要素を含むので、こうしたBODを使用する際には全体的なパフォーマンスにどのような影響があるかを評価することが重要です。自分のソリューションに、どのBODを使用するかをよく選ぶことが勧められます。

また、交換される実際の情報の量を最大化するようにメッセージを設計することも大事です。要素や属性ばかりたくさんあって、データはほとんど無いようなメッセージは普通、複雑なXMLスキーマによるものです。SOAPメッセージの構文解析がWebサービスに関わるパフォーマンスに大きな影響を与えていると思われている場合が非常に多いのですが、複雑なメッセージ構造の結果、処理時間の50%以上もがオブジェクトやXMLエレメントのマーシャリングとアンマーシャリング関連に費やされていることもあるのです。

プログラミング・オブジェクトやXML要素のマーシャリングとアンマーシャリング（シリアライゼーションとデシリアライゼーションとしても知られています）が全体的な処理時間に影響するかの例として図2を参照してください。

セキュリティー・アプローチを選択

実世界でのソリューションにおいては、オープンなインターネットを通して機密情報や市場価値を持った上を送信する場合には充分な保護が必要です。多くの場合、これは情報の送り手と受け手が認証され（両者ともに認証される）、メッセージの確実性と整合性が確保され（メッセージの証明が改変されていない）、メッセージが機密性を保つ（指定された受信者以外の誰もが理解できないように内容を暗号化する）ことを意味します。メッセージのセキュリティーを提供するのはかなり複雑な処理を伴いますが、最近の業界では様々な選択肢があります。IT設計者やIT専門家にとってみれば、どの手法が最も要件を満たすかを判断し、その上でセキュリティー機能を使用可能にするためにミドルウェアや基盤コンポーネントを構成するだけの話です。

インターネットを介するネットワーク・ノード間のセキュリティーは、伝統的にはWebサーバーとアプリケーション・サーバーを介するHTTPS（SSL over HTTP）を使用して提供されます。HTTPSによってメッセージの送受信者の相互認証を実行し、メッセージの機密性を確保することができます。このプロセスには接続の両端に対して構成されたX.509証明書を伴い、通常はネットワーク・ノード（受け取り側とサービス・プロバイダーが展開されたシステム、またはSOAP仲介者(SOAP intermediary)をホストするゲートウェイ・システム）と関係してきます。

エンドツーエンドからアプリケーション・スタックまでセキュリティーが必要な場合、またはネットワーク・プロトコルからセキュリティーが独立している必要がある場合には、別の方法を考慮すべきです。WS-Securityはサービスの両端において、XML Digital Signaturesを介して認証とメッセージ整合性を提供し、X.509証明書を使用したXML暗号化によってメッセージ機密性を提供します。しかし、全体的な要求に照らし合わせて、パフォーマンスのトレードオフをよく検討し、評価する必要があります。WS-Securityの技術を使用してセキュリティーを実現しようとすると、伝統的なHTTPでのSSLを使用して類似の機能を実現するのに比べて少なくとも倍のコストがかかる、と言えば無難でしょう。しかし、リクエストを処理する上で（構文解析やシリアライゼーションの他に）ビジネス・ロジックやデータベースが実行時間の大半を占めるのであれば、2種類のセキュリティーへ手法によるコストの差は懸念するほど大きなものにはならないでしょう。

２つの手法を組み合わせ、SSLを暗号化に使い、アプリケーションのエンド・ポイントの認証とメッセージ統合性の保証にXML Digital Signaturesを使用するのはよく行われることです。SSLでは少なくとも1台、メッセージの送信先であるサーバーの認証が必要であり、そのため多少の冗長性が発生することは頭に置いておいて下さい。ビジネスと技術の要件、そしてトレードオフを評価すれば、この３つの選択肢のうちどれを選ぶべきかが分かると思います。

上に戻る

まとめ

Webサービスのパフォーマンス最適化をうまく行うためには、基準の測定や情報の分析、健全な調整を行う上でシステム的である必要があり、それは一部経験がものを言い、一部には芸術の要素があり、また一部には訓練がものを言います。上記の通り、まず設計の段階で正しい決断を下さなくてはなりません。次に運用可能なソリューションを手にすれば、あとは模擬的な負荷から測定結果を捉え、影響を考慮しながら再度調整を行うという、微調整のための繰り返しのプロセスだけです。

次回の記事では、Webサービスの相互動作に関連したパフォーマンスに関して説明します。

参考文献

• このシリーズの 以前の記事にも目を通してください。
  
  
• パターンの詳細については、IBM Patterns for e-business のWebサイトを参照してください。
  
  
• IBMが提供するPatterns for e-business Redbooks を参照してください。
  
  
• IBM Patterns for e-businessの先端アーキテクトらがWebサービスの及ぼす影響について報告書（英語PDF）にまとめています。
  
  
• IBMのe-businessのパターンに関するその他のプレゼンテーション、白書、および情報はPatterns for e-business resources でご利用いただけます。特に、WebSphere Studio Technical Exchange presentation (ZIP、PDF) では、e-businessのパターンに対して抱くWebサービスの関係が論じられています。
  
  
• Web Services Interoperability Organizationによる関連要求事項がBasic Profile V1.0にて説明されています。
  
  
• Web Services Security（Webサービス・セキュリティー）の情報を入手するのでしたら、Web Services Security のSpecification（仕様）をお読みください。
  
  
• ApacheXercesパーサーに関するより詳細に渡る情報でしたら、こちらからどうぞ。
  
  
• InfoCenterにて、WebSphere Applicationsのパフォーマンスのチューニングに関するより多くの情報を見付けましょう。
  
  
• UDDI.orgのサイトにて、UDDI照会の呼び出しパターンに関する情報を検索できます。
  
  
• Web Services for J2EE (JSR109)の詳細を収集してみてはいかがでしょうか。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに: パフォーマンスの判断基準
• Webサービスを強化する
• Webサービスのパフォーマンス・ボトルネック
• まとめ
• 参考文献
• 著者について
• コメント