レベル: 中級 Judith Myerson (jmyerson@bellatlantic.net), Systems engineer and architect, Freelance writer
2007年 8月 28日 効率的な処理を行える Ajax アプリケーションをデプロイしたからといって、SLA (Service Level Agreement) のサービス・レベルを高く維持できるとは限りません。効率的な処理を行えるようにどんなにうまく Ajax 形式のコードを変更したとしても、リスクと脆弱性は常に存在します。そのため、そのリスクと脆弱性を監視して軽減することも必要となるのです。この記事では developerWorks でお馴染みの著者、Judith Myerson が簡単に Ajax を復習し、Web サービスの脆弱性とは何か、そしてなぜ SLA が重要なのかを説明し、Ajax アプリケーションの速度を上げるためのソリューションをいくつか提案します。
はじめに
developerWorks の連載「Web サービスのコンテキストにて SLA を使用する」では、複数の Web サービスに対するセキュリティー保護、Web サービスのファイアウォール設定、そして脆弱性のリスク軽減を、いずれも SLA の保証付きで実現する方法について説明しました。その連載では、パフォーマンスと標準のさまざまな基準があるなかで、サービス・コンシューマーに対してサービスの作成者が実現する高可用性サービスの重要性に重点を置きました。
この記事ではまず Ajax (Asynchronous JavaScript + XML) を復習し、続いて脆弱性の問題、SLA の影響を取り上げ、そして効率的な処理を行える Ajax アプリケーションが脆弱性のリスクを軽減あるいは排除することにはならない理由を説明します。さらに、Web サービスの脆弱性を回避しながら Ajax アプリケーションの速度を向上させる方法を紹介します。
 | |
Ajax がブラウザー・アプリケーションからインターネット上のサーバー・ポータルに移行したことにより、Ajax アプリケーションのセキュリティーの脆弱性が新しく浮かび上がってきました。この記事では、Ajax アプリケーションの速度を上げると同時に Web サービスの脆弱性も回避するための実用的アドバイスを提言します。
|
|
Ajax の復習
Ajax はユーザーのブラウザー・エクスペリエンス (企業間取引など) を XML ベースの Web サービス・ポータル (企業と顧客間の取引など) に変換することによって、応答性の高い対話型 Web サービスを可能にします。Ajax がこれを実現するために使用するのは、Web ページとサーバーとの間で HTTP プロトコル上に処理層を追加で構築するという方法です。この層はユーザーからのリクエストをインターセプトし、バックグラウンドでサーバーと密かに非同期で通信を行い HTTP プロトコルの必要なコンテンツを取得します。これにより、データベース・レコードの更新リクエストや更新が成功したというレスポンスなど、サーバーのリクエストとレスポンスをユーザー・アクションと同調させる必要がなくなります。
Web サービスの脆弱性
この追加処理層についての問題に目を向けてみましょう。問題の 1 つは、リクエストとレスポンスのペイロードのコンテンツ・タイプは XML でなければならないため、送信される XML トラフィックの量が Ajax によって増加することです。Ajax アプリケーションが大量に使用されると、ネットワーク・トラフィックを停滞させることにもなりかねません。さらに重要な問題として、大量のトラフィックは Ajax アプリケーションを Web サービスの脆弱性という危険にさらします。このような脆弱性が悪用されると、システムやアプリケーションのパフォーマンスが劣化することとなります。
このセクションでは、以下の 4 つの脆弱性の事例を取り上げます。
- 過剰な帯域幅
- 破損データ
- 頻繁に行われる小さな HTTP リクエスト
- メモリー・リーク
過剰な帯域幅
テキスト・フォーマットの XML メッセージは、バイナリー・データの帯域幅の 2 倍以上になる可能性があります。XML メッセージを送信するのに必要な帯域幅が増えれば増えるほど、システムやアプリケーションが他のタスク (例えば、目的の結果を得るために複雑なアルゴリズムを実行するなど) に使用するためのリソースが少なくなってしまいます。過剰な帯域幅は、システム過負荷によるパフォーマンスの劣化という結果になりかねません。
破損データ
過剰な帯域幅は、Ajax アプリケーションの出力データを破損させる一因にもなります。なぜなら、過剰な帯域幅によって正常なデータを作成するためのリソースが不足するからです。このため、Ajax アプリケーションを含む Web サービス・ポータルのなかで、Ajax アプリケーション以外のアプリケーションに破損したデータをさらすことになり、不正な形式のメッセージが作成され、不必要に解析されてしまうということになりかねません。この脆弱性が悪用された場合、ブラウザーがクラッシュする恐れもあります。
頻繁に行われる小さなリクエスト
Ajax の欠点は、1 回で大きなやり取りをする代わりに小さなリクエストを何回もできてしまうことです。頻繁に行われる小さな HTTP リクエストはバックエンド・サーバー、ロード・バランサー、そしてファイアウォールの負担になるだけでなく帯域幅も過剰に大きくするため、パフォーマンスを劣化させます。ブラウザーの制限やネットワーク接続の速度がこれらのリクエストに対応しきれないと、ネットワークのボトルネックが生じる場合もあります。
メモリー・リーク
一般的な Web アプリケーションでは頻繁に、該当する Web ページのメモリーが消去され、クリーンな状態からページがリロードされます。一方、Ajax では、Web サービス・ポータルにコンテンツの次の部分が表示されるのを待つ間、ページをリロードする必要はありません。このように Ajaxでは単一ページのアプリケーションを何日もブラウザーに維持できるため、メモリー・リークやその他のリソースのリークが発生した場合の問題も大きくなります。過剰な帯域幅、小さな数々の HTTP リクエストだけでなく、メモリー・リークが多くなりすぎても Web ポータルのデータを破損させる原因となるため、ハッカーがインターネットからシステムの脆弱性を悪用する機会を増やすことにつながります。
リスク評価
以上のすべての事例について、脅威の存在がシステムおよびサーバーの脆弱性を悪用するリスクの程度、そして脆弱性が悪用された場合のビジネスへの影響を判断する必要があります。リスクが高い場合は、予防手段を講じて Ajax アプリケーションの高速化を図らなければなりません。この予防手段の一例が、SLA が保証されたサービス実行可能時間を拡大することです。
サービス・レベル・アグリーメント
どんなにうまく Ajax アプリケーションのコードを変更して効率的な処理を行えるようにしても、監視して軽減する必要があるリスクと脆弱性は常に存在します。効率的な処理を行えるアプリケーションをデプロイすることによって、SLA のサービル・レベルを高く、あるいは指定されたパフォーマンスしきい値以上 (99.9 や 99.999% など) に常に維持できると保障しているわけではありません。アプリケーションがブラウザー・アプリケーションからインターネット上の Ajax アプリケーションのサーバー・ポータルに移行するにつれ、その脆弱性は高くなります。特に、パケット損失などのパフォーマンス問題を検出する Web サービスの構築に使用されている XML の部分では、脆弱性がなおさら増すことになります。
サービス実行可能時間を拡大するには、3 つの事項を検討する必要があります。まず 1 つ目は、Ajax アプリケーションの高速化です。それには、帯域幅を最適化する以外にパフォーマンスを改善させる手段 (XML コンテンツ・フィルタリングや XML アクセラレーション機能など) を検討しなければなりません。2 つ目は、Ajax アプリケーションをセキュアにするための WSS (WS-Security)、AVDL (Application Vulnerability Description Language) をはじめとする多数の Web セキュリティー標準です。そして最後に、パフォーマンスの測定手段の 1 つとしてアプリケーションのトラフィック監視を検討します。
改善その 1. アプリケーションの高速化
Ajax アプリケーションを高速にするための以下のオプションについて検討します。
- 特殊なハードウェア・アクセラレーター
- 最適化ソフトウェア
- コードの冗長性排除
- XML アクセラレーション機能
- 相互運用性問題の解決
特殊なハードウェア・アクセラレーター
XML トラフィックを高速にするには、ハードウェア・アクセラレーターを使用します。アクセラレーターなしでは、目的の結果を得るには複雑な計算が必要となる暗号化、複雑なグラフィック、そして音声認識のアルゴリズムによってアプリケーション、そして関連リソースが占有されてしまうことがあります。アクセラレーターは通常、サーバー・サイドのスクリプト用ではありません。そのため、ハードウェア・アクセラレーターを最適化されたソフトウェアと組み合わせることで対処します。
最適化ソフトウェア
最適化ソフトウェアを使用して、アプリケーションがより迅速に実行できるように、あるいはより少ない量のメモリーやその他のリソースで動作できるようにシステムを変更および圧縮します。ポータブル・コンピューターでは、最適化ソフトウェアによってバッテリー電源消費量が少なくなります。サーバーからのダウンロードのサイズと時間を削減するためのプロセスには、次の 2 つのステップがあります。
- ASP.Net または JavaScript 技術を使用して、Ajax アプリケーションのペイロードを分析します。
- ペイロード分析に基づいて最適化ソフトウェアを開発します。
コードの冗長性排除
コードの冗長性を排除するには、例えば Ajax コールバックの数とそれぞれのコールバックのペイロードを減らすという方法があります。コールバック間に複雑な相互関係がある場合は、重複するコードを見つけて簡潔にしてください。Ajax アプリケーションを複数のモジュールに分割し、これらのモジュールを同様の機能と組み合わせることで冗長性を減らすという方法もあります。
XMLアクセラレーション機能
アプリケーションがどれだけ複雑かによりますが、テキスト・ベースの大規模な XML ファイルの構文解析を処理する際のオーバーヘッド・コストが高いと、ハードウェア・アクセラレーターと最適化ソフトウェアによってコードの冗長性が排除されても、そのメリットが相殺されてしまいます。テキスト・ベースの XML Web サービス・アプリケーションは大規模で膨大になる傾向があるため、ネットワーク、プロセッサー、そしてストレージのパフォーマンスという点から見ると、効率的な処理が行われているとは言えません。このような Web サービスは、大規模なファイルが大量に使用された場合にはネットワーク・トラフィックを停滞させ、システム過負荷という結果になることが考えられます。
Web サービス・パフォーマンスにとって大きな障害の 1 つとなるのは、XML に関連したネットワークと処理のオーバーヘッドです。そのため、業界では XML のバイナリー・エンコード方式の標準化に向けた活動が行われてきました。その一例が、 XOL (XML-binary Optimized Packaging Specification) パッケージです。エンタープライズ規模のサービス指向アーキテクチャー (SOA) における Web サービスの取り扱いに関して、連載「Use SLAs in a Web services context」のパート 7 で説明したように、このパッケージはバイナリー形式の大規模なファイルの処理においては、テキスト・ベースのファイルを対象とした XML パーサーよりも効率的です。
相互運用性問題の解決
Ajax アプリケーションがどれほど有効に最適化されていようと、どのハードウェア・アクセラレーターを使用していようと、あるいはコードの冗長性が削減または排除されていようと、相互運用性の問題を解決しなければならないことに変わりはありません。例えば、Ajax アプリケーションが組織の管理が及ばない Web サービスに変換される場合、これらの Web サービスが共有セマンティクスおよび契約上の義務という点で相互運用可能であることを確実にする必要があります。セマンティックスの誤った解釈 (独自仕様のセマンティクスなど) や契約の抜け穴 (マルチプラットフォームの違い) は、Ajax アプリケーションとレガシー・システムを統合する際などに相互運用性の問題をもたらします。
改善その 2. Web サービス標準
ここでは、以下にリストした Ajax アプリケーション向けの OASIS Web サービス標準を取り上げます (OASIS とは Organization for the Advancement of Structured Information Standards の略で、International Open Standards Consortium によって管理されています。このサイトへのリンクは、「参考文献」を参照してください)。
- WS-SX (WS-Security Extensions)
- SAML (Security Access Markup Language)
- SPML (Service Provisioning Markup Language)
- DSS (Digital Signature Services)
- AVDL (Application Vulnerability Description Language)
上記の標準はいずれも、Ajax がブラウザー・アプリケーションからインターネット上のサーバー・ポータルに移行したことによって拡大した脆弱性のリスクを軽減することを目的としています。これらの標準は、XOL パッケージまたはその他のバイナリー XML スキーマが適用された場合にのみ、一層効果的に機能します。
WS-SX
この標準は、上位レベルの Ajax Web サービス・アプリケーションを実装する際にメッセージの完全性や機密性などのセキュリティー機能を実装するための技術的基礎となります。単一のメッセージ交換を重点としている WSS に代わって拡張された WS-SX は、複数のメッセージ交換を伴った信頼性ある SOAP メッセージ交換を実現し、これらのメッセージのフォーマットとトークンを規定するセキュリティー・ポリシーを定義します。WS-SX の開発に貢献したのは、WS-SecureConversation、WS-SecurityPolicy、WS-Trust 仕様です。
SAML
このマークアップ言語が定義および管理するのは、オンライン・パートナー間のセキュリティー情報を作成および交換するための標準 XML ベースのフレームワークです。SAML は Web シングル・サインオン、つまり属性ベースの許可として、そして Web サービスのセキュリティー保護に使用されています。
SPML
この標準は、組織内および組織間での ID 情報とシステム・リソースのプロビジョニング、そして割り当てを管理するための XML フレームワークとなります。さらに、SPML 1.0 仕様は WSS、XML Digital Signatures、XML Encryption の使用に対応するように設計されています。
DSS
この標準が定義するのは、Web サービスやその他のアプリケーションのデジタル署名を処理するための XML インターフェースです。アプリケーションを交換し、ストレージから取得する際に Web データの信頼性を保証する DSS は、電子商取引やその他の Web アプリケーションのセキュリティーで重要な役割を果たしています。DSS 仕様には、署名の作成、署名の検証、タイム・スタンプ、そしてこれらの機能の組み合わせに対するサービスも含まれています。
AVDL
AVDL の目標は、アプリケーションを保護するために使用される情報を記述する言語を定義することです。この情報には、脆弱性情報、既知の正当な用途についての情報などを含むことができますが、それだけには限られません。Web サービスのコンテキストにおける SLA の使用方法に関して、連載「Use SLAs in a Web services context」のパート 7 では、AVDL の枠を超えて、割り込みしきい値の問題を取り上げました。例えば、HTTP で脆弱性情報のリクエストに対するレスポンス・タスクを完了していない Web サービスなどに対する割り込みしきい値です。
リクエストとそのリクエストへのレスポンスとの間に大きな時間差がある場合、割り込みしきい値が、実行可能時間についての SLA 保証に悪影響を及ぼす可能性があります。このような悪影響の可能性を小さくするため、その記事では異種のサービス指向アーキテクチャー (SOA) において Web サービスの脆弱性が露呈されるリスクを抑える方法について説明しました。割り込みしきい値による影響は、XOL パッケージによってさらに軽減することができます。しかし、これによって SLA の保証を実現できるという意味ではありません。
改善その 3. トラフィック監視
アクティブなトラフィック監視は、Ajax アプリケーションのネットワーク・トラフィックのパフォーマンスを継続的に測定する 1 つの手段です。トラフィック監視では、ネットワーク・データと IP サービスをシミュレートし、Ajax アプリケーションのネットワーク・パフォーマンス情報をリアルタイムで収集することができます。この収集に含まれるデータは、応答時間、帯域幅、片方向待ち時間、ジッター、パケット損失、そしてサーバー応答時間などです。
同じ接続で異なるクラスのトラフィック (高、中、低の優先順位など) を対象にパフォーマンスを監視することが可能です。データをリアルタイム・ログに書き込むことで、過剰なパケット損失とジッターが発生した場所と時間、応答が遅くなった理由、そしてアプリケーションの優先順位変更によるトラフィック・パフォーマンス改善の可能性を判断することができます。
まとめ
Ajax アプリケーションを高速にするとともに Web サービスの脆弱性を避けるには、開発者、テスター、システム管理者、そして想定されるユーザーで構成するチームが必要です。冗長性とメモリー・リークを排除し、帯域幅の量と小さな HTTP リクエストの数を減らすためには、Ajax パフォーマンス改善プロジェクトの作成、テスト、そしてデプロイを前もって計画しておかなければなりません。これらの問題が解決されれば、Ajax アプリケーションの高速化は実現しやすくなります。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | | | Judith M. Myersonは、システム・アーキテクト兼エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、そしてプロジェクト管理を含む数多くの分野を得意としています。著者とのコンタクトは、jmyerson@bellatlantic.netでお願いします。 |
記事の評価
| 
