クラウドのサービス・レベル・アグリーメントについてのレビューと要約

「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」バージョン 4.0 より

この記事では、「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」バージョン 4.0 (Cloud Computing Use Cases Discussion Group による投稿) のサービス・レベル・アグリーメントに関するセクションを概説し、アーキテクトと開発者がクラウドに移行する際に考慮しなければならない SLA 問題に焦点を当てます。

developerWorks cloud computing editors, developerWorks Editors, IBM

developerWorks Cloud computing のエディターたちは、アプリケーションをより簡単に、より効率的にクラウドに移動するために皆さんが必要としている技術リソースのタイプについてのご意見を心待ちにしています。



2010年 8月 04日

この記事では、Cloud Computing Use Case Discussion Group による「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」バージョン 4.0 の内容を見ていきます。このホワイト・ペーパーは、1,400 人を超える参加者 (バージョン 3.0 の当時は 900 人の参加者) で構成されるオープンな Web コミュニティーの知識を集めて作成されたものです。Open Cloud Manifesto のサポーター・グループから始まった Cloud Computing Use Case Discussion Group は、今では大企業および中小企業、政府機関、コンサルタント、およびベンダーの代表者も参加するまでに成長しました。

「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」で取り上げている話題は広範囲に及ぶため、1 回の記事で文書全体を網羅するつもりはありません。この記事では概要を説明しますが、特にクラウドでのサービス・レベル・アグリーメント (SLA) 問題に対する Cloud Computing Use Case Discussion Group の評価に焦点を絞ります。SLA はクラウド・プロバイダーとクラウド・コンシューマーとの関係を説明すること、そして基本的に、クラウドのインフラストラクチャー・サービスを提供するクラウド・プロバイダーの能力に対するクラウド・コンシューマーの信頼基盤を定義することから、SLA 問題に対する評価は検討すべき重要な事項です。

このホワイト・ペーパーを完成させたコントリビューター

「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」バージョン 4.0 のコントリビューター: Dustin Amrhein、Patrick Anderson、Andrew de Andrade、Joe Armstrong、Ezhil Arasan B、James Bartlett、Richard Bruklis、Ken Cameron、Reuven Cohen、Tim M. Crawford、Vikas Deolaliker、Andrew Easton、Rodrigo Flores、Gaston Fourcade、Thomas Freund、Valery Herrington、Babak Hosseinzadeh、Steve Hughes、William Jay Huie、Nguyen Quang Hung、Pam Isom、Sam Johnston、Ravi Kulkarni、Anil Kunjunny、Thomas Lukasik、Bob Marcus、Gary Mazzaferro、Craig McClanahan、Meredith Medley、Walt Melo、Andres Monroy-Hernandez、Dirk Nicol、Lisa Noon、Santosh Padhy、Greg Pfister、Thomas Plunkett、Ling Qian、Balu Ramachandran、Jason Reed、German Retana、Bhaskar Prasad Rimal、Dave Russell、Matt F. Rutkowski、Clark Sanford、Krishna Sankar、Alfonso Olias Sanz、Mark B. Sigler、Wil Sinclair、Erik Sliman、Patrick Stingley、Robert Syputa、Doug Tidwell、Kris Walker、Kurt Williams、John M Willis、Yutaka Sasaki、Michael Vesace、Eric Windisch、Pavan Yara、Fred Zappert

SLA とは何か

SLA に含まれるべき内容として、このホワイト・ペーパーの著者たちが同意しているのは以下の 4 つです。

  • プロバイダーが提供するサービスの一覧と各サービスの完全な定義
  • プロバイダーがその約束どおりにサービスを提供しているかどうかを判断するための基準、およびサービスを監視するための監査メカニズム
  • プロバイダーとコンシューマーの責任、および SLA の条件が満たされない場合にプロバイダーとコンシューマーの双方が採りうる対応策
  • SLA が時間とともにどのように変化していくかの説明

このホワイト・ペーパーで検討している SLA のタイプは、既製のアグリーメント、交渉によってカスタマイズされるアグリーメントの 2 つです。カスタマーが扱うデータが極めて重要な場合、既製のアグリーメントでは必要を満たせません。そのため、クラウドに移行する前に、最初のステップとしてデータおよびアプリケーションの重要性を判断する必要があるとホワイト・ペーパーでは指摘しています。

パブリック・クラウドではよく、交渉の余地のない SLA を提示していますが、ミッション・クリティカルなアプリケーションやデータを使用するカスタマーにとって、そのような SLA は容認できない場合があります。

SLO とは何か

SLA には、客観的に測定可能なサービスの状態を定義するサービス・レベル・オブジェクティブ (SLO) が含まれます。SLO の例としては、スループットおよびデータ・ストリーミングの頻度と時間のパラメーター、VM やその他のリソースとインスタンスの可用率、さまざまな SLO の重要度に優先順位を付けるための緊急性の格付け (例えば、「応答時間よりも可用性を重要とする」など) が挙げられます。

SLO に期待される内容は、アプリケーションとそのアプリケーションがアクセスするデータが同じクラウドでホストされるのか、あるいはアプリケーションとデータがそれぞれ別のクラウドでホストされるのかによって変わってきます。

監視と測定

SLO に基づくサービス・レベル・マネジメント (SLM) とは、クラウドでのパフォーマンス情報をどのように収集し、処理するかということです。SLM は以下のように使用されます。

  • クラウド・プロバイダーは、そのインフラストラクチャーを決定するために SLM を使用します。例えば、スループットが常にカスタマーの要件を満たすわけではない場合、プロバイダーは帯域幅を割り当て直すか、ハードウェアを増設するという方法を採ることができます。あるいは、他のカスタマーを犠牲にして、ある特定のカスタマーを満足させるという決定もあり得ます。プロバイダーにとって、SLM はビジネス目標および技術的な現実に基づいて最善の決定を行えるように作成されます。
  • クラウド・コンシューマーは、クラウド・サービスをどのように使用するかを決定するために SLM を使用します。例えば、仮想マシンを増やすかどうか、そして仮想マシンを増やした場合はそれによるメリットが価格に見合った妥当なものと言える上限価格はいくらなのか、を決定するために SLM を使用します。コンシューマーにとって、SLM はクラウドをどのように使用するかを決定する上で有用です。また、場合によっては、このような決定を自動化するための手段となります。

SLA の条件に関して考慮すべき要因とは

SLA の条件を定義する際に考慮すべき要因として、このホワイト・ペーパーでは以下の 10 項目を挙げています。

  1. ビジネス・レベル・オブジェクティブ: 組織がどのクラウド・サービスを使用するのか決めるには、まずその前に、クラウド・サービスを利用する理由を明らかにしなければなりません。この部分は技術に関する考慮事項というよりも、組織の政策に関わってきます。一部のグループは財源を削減されたり、インフラストラクチャーに関する制御権を失ったりする場合もあります。
  2. 両当事者の責任: プロバイダーとコンシューマーとの間での責任の分担を定義することが重要です。例えば、プロバイダーが SaaS (Software-as-a-Service) の側面に責任を持つとしても、ライセンス付与されたソフトウェアが含まれ、機密データを扱う VM (Virtual Machine) については、主にコンシューマーが責任を持つこともあり得ます。
  3. ビジネス継続性/障害回復: コンシューマーは、プロバイダーが災害に対して常に十分な保護対策を講じていることを確実にしなければなりません。例として思い当たるのは、重要なデータをバックアップとしてクラウドに保管することと、クラウド・バースティング (社内データ・センターが負荷を処理しきれなくなった場合にクラウドに切り替えること) です。
  4. 冗長性: プロバイダーのシステムがどの程度冗長化されているかを考慮してください。
  5. 保守: クラウドを使用する上で最も嬉しいことの 1 つは、プロバイダーが保守を引き受けてくれることです。ただし、コンシューマーは、プロバイダーがいつ保守タスクを行うのか、そして以下の点を把握する必要があります。
    • 保守タスクが行われている間、サービスは利用できなくなるのか?
    • サービスは利用できても、スループットが大幅に低下するのか?
    • コンシューマーが更新後のサービスに対してアプリケーションをテストする機会があるのかどうか?
  6. データのロケーション: データのタイプによってそのデータを保管する物理ロケーションを制約する規則があります。プロバイダーは、コンシューマーのデータがある特定のロケーションにのみ保管されることと、そのことを監査する能力について保証することによって、これらの要件に対応することができます。
  7. データの押収: 法の執行により、特定のコンシューマーに属するデータおよびアプリケーションを保存するためのプロバイダーの装置が押収された場合、そのプロバイダーを利用している他のコンシューマーにも影響する可能性があります。サード・パーティーで別途バックアップを行うことを検討してください。
  8. プロバイダーの破綻: プロバイダーの経営状態を考慮に入れた危機管理計画を立ててください。
  9. 法的管轄: プロバイダーに適用される地域ごとの法律ならびにご自分に適用される法律を理解してください。
  10. ブローカーおよび再販業者: 利用しているプロバイダーがクラウド・サービスのブローカーまたは再販業者である場合、プロバイダーと実際のプロバイダー両方のポリシーを理解する必要があります。

SLA の要件

このホワイト・ペーパーでは、SLA を検討する際に以下の 14 の項目についての責任を考慮する必要があるとしています。

  1. セキュリティー: コンシューマーは、セキュリティー要件を理解するとともに、該当するセキュリティー要件を満たすために必要な制御とフェデレーション・パターンを理解する必要があります。一方プロバイダーは、適切な制御とフェデレーション・パターンを可能にするためにはコンシューマーに何を提供する必要があるのかを理解しなければなりません。
  2. データ暗号化: データは送受信中および保管中は暗号化されていなければなりません。したがって、暗号化アルゴリズムおよびアクセス制御ポリシーの詳細が指定されていなければなりません。
  3. 機密性: 機密性に関する基本的な懸念に対処するための手段は、データ暗号化、保存、削除などの要件です。SLA では、クラウド・プロバイダーがマルチテナント環境でデータとアプリケーションを分離する方法を明確にする必要があります。
  4. データの保存、削除: データの保存に関する法律および削除ポリシーに準拠していることをプロバイダーがどのように証明するかを明確にしてください。
  5. ハードウェアの消去、破棄: 上記の 4 と同じです。
  6. 規制順守: 規制に従わなければならないようなデータのタイプの場合には、クラウド・プロバイダーはその規制に順守していることを証明できなければなりません。
  7. 透過性: 重要なデータおよびアプリケーションについては、SLA の条件に対する違反があった場合、プロバイダーは自ら進んでコンシューマーにその旨を通知しなければなりません。これには、機能停止やパフォーマンスの問題などのインフラストラクチャーに関する問題、そしてセキュリティーに関する事故も含まれます。
  8. 認定: プロバイダーは、必要な認定を受けていることを証明し、常に最新の認定を受けているようにする責任があります。
  9. パフォーマンスの定義: 例えば、アップタイムとは、各地域のすべてのサーバーが使用できる状態を言うのか、それとも 1 台でもサーバーが使用できる状態を言うのか、こうした言葉の定義を明確にしておくと有益です。(ホワイト・ペーパーでは、定義を容易にするためにパフォーマンス関連の用語を標準化するように提案しています。)
  10. 監視: 起こり得る条件不履行の問題に対し、プロバイダーのパフォーマンスを監視する中立的なサード・パーティーの組織を指定することが推奨されます。
  11. 監査能力: データ損失または可用性に関する不履行があった場合には、常にコンシューマーがその責任を取らなければなりません。そのため、コンシューマーがプロバイダーのシステムおよび手順を監査可能であることが不可欠です。SLA では、監査を行う方法および時期を明確にする必要があります。プロバイダーにとっては、監査によって混乱が生じ、コストがかかる可能性があります。
  12. 評価基準: 評価基準とは、その発生をモニターし、事後に監査することが可能な具体的な事象です。SLA の評価基準は、客観的かつ曖昧さを残さずに定義する必要があります。SLA の評価基準を記載した後に、一般的な評価基準を記載します。
  13. コンピューターで解読できる SLA の提供: コンピューターで解読できる SLA を提供することにより、クラウド・ブローカーによる自動的かつ動的な選択が可能になります。つまり、ブローカーが一部のタスクには最もコストの低いプロバイダーを使用し、別のタスクには最もセキュアなプロバイダーを使用するように SLA で規定した場合、コンピューターで解読できる SLA を使用することで、自動的なプロバイダーの選択が可能になります。(今のところ、このようなサービスがすぐに利用できるような状況ではありませんが、クラウド SLA 標準化のディスカッションに貢献する際には念頭に置いておくべき点です。)
  14. 人間との対話: オンデマンド・セルフサービスはクラウド・コンピューティングの基本的な特徴の 1 つですが、SLA では人間と対話する必要があるときにはそうできるように考慮しなければなりません。

一般的なパフォーマンスの評価基準 (12 番の考慮事項) には以下の項目が挙げられます。

  • スループット: システムの応答速度
  • 信頼性: システムの可用性
  • ロード・バランシング: エラスティック性が作用するタイミング
  • 耐久性: データを損失する可能性の高さ
  • エラスティック性: 対応可能なリソース増加量
  • 線形性: 負荷の増加に応じたシステムのパフォーマンス
  • アジリティー: プロバイダーが負荷の変化に対応する速度
  • 自動化: 人間の介入なしで処理されるリクエストの比率
  • カスタマー・サービス応答時間

信頼性に関する経験則

ホワイト・ペーパーでは、クラウド・パフォーマンスに関する信頼性の実用的な定義について、以下のように簡潔に説明しています。

  • 9 の法則。信頼性に関する一般的な基準は、プロバイダーが提供する 9 の数です (例えば、サービスを 99.999 パーセント (ファイブ・ナイン) の時間利用できた場合、システムの合計停止時間は 1 年間で約 5 分ということになります)。問題は、停止時間がどのように定義されるかです (プロバイダーが停止時間の定義を決めることになった場合、最悪の状況になる可能性があります)。
  • クラウドの階層。多くのクラウド・オファリングは、別のクラウド・オファリングをベースとしています。これは柔軟性および能力という点では非常に有効ですが、プロバイダーの数が多ければ多いほど、システムの信頼性は低下していきます (例えば、各プロバイダーのオファリングの稼働率がファイブ・ナインという自己評価の場合、システム全体の稼働率はファイブ・ナインよりも低くなります)。
  • アプリケーションとデータとの間にある距離。プロバイダーの数が増えると、別の要因も信頼性に影響してきます。それは、いずれかのプロバイダーのシステムが停止しただけで影響を受けるだけでなく、システム間のネットワークがダウンした場合にも影響を受けるということです。

以上に記載した信頼性の定義は、クラウド・コンシューマーを脅かすためのものではなく、単にプロバイダーを選択する際に考慮しなければならない構造に関する現実にすぎません。

要件とデリバリー・モデルおよびユース・ケース

ホワイト・ペーパーには、以下の 2 つの表が記載されています。

  • 表 8.7: SLA Requirements and Cloud Delivery Models (SLA の要件とクラウドのデリバリー・モデル)。この記事で説明した SLA の要件 (データ暗号化、機密性、認定など) と PaaS、IaaS、および SaaS という 3 つのデリバリー・モデル (ホワイト・ペーパーで説明) を相互参照している表です。
  • 表 8.8: SLA Requirements and Use Case Scenarios (SLA の要件とユース・ケース・シナリオ)。SLA の要件と以下の 7 つのユース・ケース・シナリオを相互参照している表です。
    1. エンド・ユーザーとクラウド
    2. 企業とクラウドとエンド・ユーザー
    3. 企業とクラウド
    4. 企業とクラウドと企業
    5. プライベート (社内) クラウド
    6. クラウド・ベンダーの変更
    7. ハイブリッド・クラウド

まとめ

クラウドのサービス・レベル・アグリーメントに関して「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」バージョン 4.0 が出している結論は以下に示すように明らかです。

  • クラウド・コンピューティングは、サービスの管理、ガバナンス、測定、監視、およびフェデレーション ID、SLA とベンチマーク、データとアプリケーションのフェデレーション、デプロイメント、そしてライフサイクルの管理なくしては実現できません。
  • クラウド・プロバイダーによる意義深い透過性と情報の開示が不可欠です。
  • 既存の標準で要件を満たせる場合、クラウド・ユーザーはプロバイダーにその標準を使用するように求めなければなりません。そのような標準がない場合には、コミュニティーに要件を満たす標準を作成するように求める必要があります。

このホワイト・ペーパーの著者たちは、以下のように述べています。

組織がクラウド・サービスを使用するときには、コンシューマーとプロバイダー両方の責任をサービス・レベル・アグリーメントに明確に定義する必要があります。SLA は、コンシューマーがサービスをどのように使用するか、そしてこれらのサービスをプロバイダーがどのように提供するかを定義します。クラウド・サービスのコンシューマーは、プロバイダーが提示する SLA の条件をすべて十分に理解すること、そしてどの契約に署名するにも、まずは自分の組織のニーズを考慮することが重要です。

このレビューと要約は、クラウドのサービス・レベル・アグリーメントに関する懸念と考慮すべき事項を理解する上で、クラウド・サービスのコンシューマーとプロバイダーの両方にとっての基礎資料となります。ぜひとも、この記事がベースとしている「クラウド・コンピューティング・ユース・ケース ホワイト・ペーパー」バージョン 4.0 をひと通り読んでください。このホワイト・ペーパーでは Cloud Computing Use Case Discussion Group が、開発者と計画者が重要なデータとアプリケーションのための信頼性の高い環境を実現する上でクラウド・プロバイダーに求めるべき要件を分析しています。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

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=Cloud computing, Open source
ArticleID=516891
ArticleTitle=クラウドのサービス・レベル・アグリーメントについてのレビューと要約
publish-date=08042010