SLAによるWebサービスの保証

概要、アーキテクチャー、およびテスト・メカニズム

多くの企業は、自分たちが料金を払うITサービスの信頼性を保証するサービス品質保証制度 (service-level agreement : SLA) を求めています。Webサービスが主流になるにしたがって、顧客はその品質を保証するSLAを望むようになるでしょう。この記事では、Judith M. Myerson氏が、Webサービスを対象とするサービス品質保証制度 (SLA) を確立する方法について解説します。SLAに含める必要のある除外条項に触れ、WebサービスをSLAによって保証された公開Webサービスとして実稼働環境に投入する前に、SOAPのインターオペラビリティーについてWebサービスをテストする例を紹介します。

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。



2002年 4月

概要: SLAとは

サービス品質保証制度 (SLA) は、サービス・プロバイダーとクライアントの間の正式な契約であり、定量化可能なネットワーク・パフォーマンスが所定の水準であることを保証します。SLAは、変化が速くて競争の激しい今日の市場において競争相手との差別化を図るための手段を、サービス・プロバイダーに提供します。ここでいうサービス・プロバイダーには、社内のIT組織、アプリケーション・サービス・プロバイダー (ASP)、ネットワーク・サービス・プロバイダー (NSP)、インターネット・サービス・プロバイダー (ISP)、管理サービス・プロバイダー (MSP)、およびその他の種類のサービス・プロバイダーが含まれます。

SLAには、非常に一般的なものから極めて詳細なものまであり、通常は、障害が発生した場合にサービス・プロバイダーとクライアントが実行しなければならない手続きが含まれています。サービス・プロバイダーは、提供するサービスが利用できる時間を一定の割合 (99.9%など) で保証します。また、最大応答時間と平均応答時間に制限を設けたり、SLAのダウン時間またはネットワーク・インターフェースに対する変更を実施する前にはその旨をクライアントに通知したり、インターネット・ベースのワークフローの自動化や分散やレポートの技術を利用したりすることもできます。クライアントは、指定されている期間中に規定されているパフォーマンス水準をプロバイダーが達成できない場合の権利と補償を手に入れます。このような権利、補償、および除外条項は、SLAによって異なります。また、クライアントは、契約の一般条項に対する特定の除外条項を受け入れることにも合意します。

個々のSLAでは、サービス品質を厳密に規定する必要があります。そうでなければ、SLAがどのようなサービスまたはパフォーマンスの条件をどのような水準で測定するのかについて、当事者は合意できません。たとえば、クライアントは合意されたサービス・レベルでNetwork Aおよびそれに接続されているNetwork BとNetwork Cが測定されると考えているのに対し、サービス・プロバイダーはNetwork Aだけを測定するものと考えているかもしれません。また、アップタイム (実行可能時間) の可用性の割合における小数点以下の桁数も重要です。99.9%アップタイムの場合より99.999%アップタイムの方が許容されるダウン時間は短くなります。SLAには、クライアントに対する終了条項を含める必要があります。可用性、信頼性、およびセキュリティーに関する問題について、プロバイダーの解決が不十分なために、クライアントのビジネスの中断が多すぎる場合には、契約をうち切るオプションがあることをクライアントは望みます。


SLAの発展

SLAにはある程度の歴史があります。1960年代においては、メインフレームのマシン・タイムをレンタルする際に、ユーザーの組織とSLAを締結し、そこに盛り込まれたサービス・レベルを達成し、問題が発生したときには対応するというのが、一般的な運用方法でした。big iron(スーパーコンピュータ) はもともとエンタープライズ・システムであり、他のテクノロジーでその処理能力に匹敵するものはありませんでした。

クライアント / サーバー・システムおよびネットワーク化されたデスクトップ・システムがコンピューターの世界に登場すると、分散ネットワーク・システムの概念が生まれました。このようなシステムは、その後、ネットワーク間でエンタープライズ・リソース・プランニング (ERP) システムやサプライ・チェーン・マネージメント (SCM) システムやカスタマー・リレーションシップ・マネージメント (CRM) システムを実行するエンタープライズ規模のシステムへと発展しました。

この発展の過程で、企業がインターネットに依存することにより、企業のアプリケーション群におけるネットワーク遅延の影響が目に見えるようになりました。同時に、ユーザー (つまりクライアント) は、ビジネスが中断されないことを保証する可用性、信頼性、および応答時間を含む一定水準のサービス保証に自ら係わるようになり、アプリケーション、インターネット、ネットワーク、管理、およびその他のサービスを提供する外部のサービス・プロバイダーに依存するようになりました。その結果、SLAは一層複雑かつ広範囲になり、ユーザーは異なるプロバイダーとの複数のSLAを保持するようになりました。一方で、プロバイダーは、他のプロバイダーと独自のSLAを持つ場合があり、各SLAにおいて要件と測定条件と除外条項の組み合わせが異なります。


新しい方向: SLAによるWebサービスの保護

インターネット (および企業のイントラネット) における新しい方向性により、出所が異なる共通点のないシステムをまとめ統合する新しい手段と機会がもたらされています。それがWebサービスです。Webサービスの導入により、拡大を続ける分散ネットワーク・システムの世界におけるプロバイダー同士の関係がさらに複雑化し、SLAもさらに難解なものとなりました。このようなSLAは、ネットワークのパフォーマンスとアップタイムの可用性を保証するだけのものではありません。個々のWebサービスの特性とネットワーク要件が異なるため、SLAはアプリケーションのパフォーマンスを保証するためにも使われます。現在、SLAの中には、パブリックなWebサービスとして公開できるものや、既に公開されているものがあります。

あらゆるWebサービスは、Webを通してシステム・コンポーネントを柔軟に統合したり変更したりすることができます。ユーザーは、このようなWebサービスの特徴を利用することで、特定のトラフィック条件下において、要求を変更することで、ネットワーク・リソースの競合状態に対処できます。ただし、このような柔軟性は、Simple Object Access Protocol (SOAP) およびUniversal Description and Discovery Interface (UDDI) に関係するインターオペラビリティー上の問題によって制限されます。このような問題が発生するのは、これらのプロトコルに対する標準仕様の解釈が、主要なベンダーごとに異なるためです。つまり、Webサービスを実稼働環境に投入し、UDDIまたは他のパブリック・レジストリーにおいてパブリック・サービスとして公開する前に、Webサービスに対するインターオペラビリティーの問題を解決しておく必要があります。これは、スタンドアロンのサービスか、Webサービス群に含まれるサービスの一部であるかにかかわらず、SLAが適用されるWebサービス (SLA Webサービス とも呼ばれます) にも同じように当てはまります。後者のよい例は、インターネットからWebサービス・アプリケーションまでのあらゆるWebインフラストラクチャーに適用される単一のSLAです。


SLA Webサービスのアーキテクチャー

先に進む前に、SLAが適用されるWebサービスのアーキテクチャーを見ておきましょう。下の図1 で示されているように、このアーキテクチャーでは、サービス・プロバイダー、サービス・クライアント、およびサービス・ブローカー という3種類のサービス・ロールが必要です。サービス・プロバイダーは、適切なプラットフォーム上でWebサービスを作成し、サービスに対するWSDLドキュメントと基本SLAを生成することで、SLA適用のWebサービスを公開します。次に、サービスの詳細をサービス・ブローカーに送信して、リポジトリーに保管します。サービス・クライアントは、ブローカーに登録した後、ブローカーのリポジトリーを検索して適切なWebサービスを探し出し、そのサービスに対するWSDLとSLAを入手します。その後、プロバイダーとの交渉を経てSLAを正式なものとして最終的に承認し、WebサービスとSLAを結び付けます。

図1. SLAが適用されるWebサービスのアーキテクチャー
図1

実用のための準備: テスト・メカニズム

SLAが適用されるWebサービスについては、HTTP、HTTPS、SOAP、UDDI、およびWeb Service Description Language (WSDL) が関係する際のスケーラビリティーとパフォーマンスをモニターする必要があります。SLA適用のWebサービスを実稼働環境に投入する前に、SOAP、WSDL、およびその他のインターオペラビリティーに関する問題をすべて解決しておく必要があります。サービスを提供するプロバイダーは、サービスが一定の水準を満たさない場合にはSLAの条件の下で金銭的な責任が発生する場合があるので、このような問題をすべて管理しておくことが特に重要です。

SLA適用のWebサービスをセットアップする前に、PushtoTest (後述の参考文献を参照) のツールやスクリプトのようなテスト・メカニズムを使って、Webサービスのさまざまなプロトコルやコンポーネントをテストする必要があります。サービスを投入した後は、これらのテスト・ツールをSLAモニターとして利用できます。

表1 は、SLAが適用されるサービスをテストする際に開発者が考慮しなければならないチェックリストの例です。

表1. Webサービスを公開する前にテストする必要のある機能
テストの種類確認事項
ステートフルネスSOAPを使ってサーバーの値を設定した場合、それ以降の状態においてサーバーは正しく応答するか。
アクセス管理者だけが使用を許可されている制御機能に対し、無許可のユーザーは正常にアクセスすることができるか。
応答時間Webサービスが応答に要する時間は長すぎないか (たとえば10秒以上)。
タイムアウトWebサービスがタイムアウトになるとどうなるか。
バージョン管理新しいビルドによって、既存のWebサービスの機能を無効にできるか。

ルールに対する除外条項

他の契約や保証と同じように、SLAにおいても、通常は、条件に対する除外条項が規定されます。Webサービスに対するSLAでは、除外条項を詳細に規定する必要があります。筆者の独断で、除外条項を、障害、サービス・プロバイダーの直接的な管理対象範囲に含まれないネットワークの問題、サービス妨害、および定期保守という4つのカテゴリーに分けて考えます。表2 は、これらのカテゴリーに分類し得る特定の状況についての説明です。

クライアント企業がダウン時間に対する妥当な補償を受けることができる限りにおいては、プロバイダーの状況に合わせて他の除外条項を追加してもかまいません。SLAに除外条項を含めることで、プロバイダーは、問題やネットワーク障害における責任からプロバイダー自身を守ることができます。一方で、競合するサービスがさらに除外条項の少ないSLAを提供するならば、クライアントには、よりよいサービス保証でより長いビジネス・アップタイムを提供する契約を選択する余地が与えられます。可用性の保証が99.5%や99.9%や99.999%という程度のアップタイムの違いであっても、SLAの選択に影響を与える可能性があります。

表2. SLAに含まれる可能性のある除外条項
種類除外条項
障害ハードウェア障害 (欠陥のあるハードウェアはまれであることに注意)
通信障害 (プロバイダーが誤ってファイバー回線を切断した場合など)
ソフトウェアのバグ/欠陥
モニター/測定のシステム障害
サービス・プロバイダーの直接的な管理対象範囲に含まれないネットワークの問題バックボーンのピア・ポイントの問題 (カリフォルニアにあるUUnetのルーターがダウンし、西海岸全域に対するインターネット・サービスが拒否される場合など)
サービス・プロバイダーの直接的な管理対象範囲に含まれないDNSの問題
サービス妨害クライアントの不注意または故意による不正行為
ネットワークのはんらん、ハッキング、および攻撃
不可抗力、戦争、通信の利用不能、SLAの提供に必要なサプライ品または装置の入手不能
定期
保守
ハードウェアのアップグレード
ソフトウェアのアップグレード
バックアップ

待ち時間の問題

SLAでは、アップロードの最大限の可用性と保証された帯域幅には焦点が当てられていますが、待ち時間の影響を受けやすいWebサービス・アプリケーションに対して一貫した応答時間を保証することはできません。待ち時間とは、データのパケットがある地点から別の地点に送られてから元の地点に戻ってくるまでの総時間 (通常はミリ秒単位で測定) のことです。パケットの往復にかかる時間が長すぎると、待ち時間の問題が発生します。たとえば、Webサービスによって生成されたオーディオに乱れが生じたり、マウス・カーソルがわずかに揺れ始めたりすることで、この問題の発生がわかります。

SLAでは、一定の期間 (たとえば1か月) における平均の往復待ち時間とパケット損失について規定されていなければなりません。平均往復待ち時間は、ネットワークとその宛先の間の平均往復パケット転送時間として定義し、またパケット損失は、往復データ伝送の過程で失われたパケットの割合として定義する必要があります。契約では、この損失を一定のレベル (1%以下など) に制限し、合意されている時間フレームにおけるパケット損失がこのレベルを超えた場合の補償 (賠償金の支払いや返金を含む) を規定する必要があります。


まとめ

これまで、SLAが適用されるWebサービスの技術的な要因について説明してきました。顧客に対する有料のWebサービス提供を計画している場合、顧客は通常、投資に対して期待される見返りが得られることを保証するSLAを望んでいます。この記事で解説した内容は、SLAの要件に適合するWebサービスの準備に関して役に立つはずです。

この記事では、顧客の期待の測定に使用できるさまざまなツールには触れませんでした。実際のビジネス環境では、提供するサービスが合意されているレベルを満たしていたとしても、技術的なサービスの提供がビジネスの要求に合わないために、顧客がサービスに満足しない場合があります。このような場合は、クライアントとプロバイダーが契約の条件について再度交渉を行って、顧客の満足するレベルを確立する必要があります。開発者は、このことに留意してWebサービスの開発とインプリメントを行うことが重要です。開発者は、顧客のビジネスと技術的な期待の両方を考慮する必要があります。

参考文献

  • Webサービスのテストとモニターに使用するPushToTest についてさらに学習してください。
  • The Complete Book of Middleware を読んでください。この本では、システム設計の重要な原則と優先順位に焦点が当てられており、e-commerceと分散統合システムの成長によってもたらされた新しい要件が強調されています。
  • Enterprise Systems Integration, Second Edition を読むと、システム統合を確実に成功させることのできるビジネスに関する洞察と技術的なノウハウを得ることができます。
  • Anbazhagan ManiとArun Nagarajanによる "Understanding quality of service for Web services" (developerWorks、2002年1月) を読めば、Webサービスのパフォーマンスを改善できます。
  • Domino管理者は、このIBM Redbook を読むことで、サービス品質保証制度の開発の要点がわかります。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=243777
ArticleTitle=SLAによるWebサービスの保証
publish-date=042002