サービスレベルアグリーメント

8 分

このコースでは、ここまでのところ、クラウドコンピューティングと、クラウドコンピューティング方法論の下で登場したいくつかのサービスモデルの背後にある基本的な考えについて説明しました。ある組織がそのインフラストラクチャやサービスをクラウドプロバイダーに移行するとき、いくつかの疑問が浮上します。たとえば、組織は次のことをどのように行いますか。

クラウドサービスプロバイダーに要求するサービスという観点でその要件を定義する。
組織が必要とするサービスの種類と数量を特定する。
クラウドプロバイダーに求めるサービスとサポートのレベルを定義する。
クラウドサービスプロバイダーが保証したサービスの種類と品質を監視し、評価する。

組織は、ビジネスおよび法的な用語でサービス要件を正式に記述する必要がある場合、 サービスレベルの目標の観点からこれらの要件を定義します。これは次のように定義されます。

サービスレベル目標

(定義) サービスレベルの目標は、サービスプロバイダーから期待されるサービスの一部の側面を定義する重要な要素として定義されます。

クラウドサービスプロバイダーの一般的なサービスレベル目標には、たとえば、アップタイム保証があります。通常の運用要因内で、サービスを利用できる時間が指定の時間 (%) だけ保証されます。

通常、サービスレベルの目標は、次のように定義されるサービス レベルアグリーメント (SLA) と呼ばれるより大きなコントラクトで、クライアントとサービスプロバイダーの間で合意されます。

サービスレベルアグリーメント

(定義) サービスレベルアグリーメント (SLA) は、サービスプロバイダー (内部または外部) と、サービスプロバイダーから期待されるサービスレベルを定義するクライアントとの間のコントラクトです

サービスレベルアグリーメントは、サプライヤーが定期的に顧客に提供するサービスに対してサプライヤー/顧客関係が存在するさまざまな業界に存在します。情報テクノロジの現在の形の SLA は、1980 年代の後半から、固定電話の事業者が法人顧客と契約を締結するときに使われてきました。

一般的な SLA は通常、次の要素で構成されています。

サービスプロバイダーが顧客に提供するサービスの定義
パフォーマンスを測定する方法
問題を管理するためのプロトコル
顧客義務の一覧
サービスプロバイダーが順守すべき保証
障害復旧に関する手順
契約の終了に関するプロセスとポリシー

クラウドコンピューティング業界では、長い間、SLA の基準となってきた原則が特に関連します。クラウドサービスプロバイダーが保証することと保証しないことを組織が理解することが重要です。

クラウドコンピューティングの SLA

SLA は長年にわたり、各種 IT サービスに対応するように進化してきました。クラウドなど、共有インフラストラクチャサービスが進化した結果、厳密な SLA の使用が必要になりました。定義上、SLA は任意のレベルのサービスを定義できますが、適切に構造化された SLA は理想的なものであるべきです¹:

サービスの各要素に必要な具体的なパラメーターと最小レベルに加え、それらの要件を満たせなかった場合の救済策が体系的にまとめられている。
サービスプロバイダーのシステムに格納される顧客のデータが顧客の所有物であることが確認されており、それを取り戻す顧客の権利が明記されています。
サービスプロバイダーが保守管理するシステムインフラストラクチャとセキュリティの基準に加え、それが順守されている様子を顧客が監査する権利が説明されています。
クラウドサービスプロバイダーのサービスの使用を続行または中止することに関する顧客の権利とコストが明記されています。

クラウドユーザーの場合、SLA の最も重要な要素は通常、保証されたアップタイムです。これはサービスとプロバイダーによって異なります。アップタイムの数値は通常、"9" で示されます。たとえば、9 が 3 つであれば 99.9% を意味し、4 つであれば 99.99% を意味します。プロバイダーは多くの場合、SLA が満たされなかったとき、サービスクレジットを進呈します。たとえば、Amazon では、Elastic Beanstalk インスタンスの月間アップタイムが 99.99% を下回った場合に 10% のサービスクレジットが、99% を下回った場合に 30% のクレジットが進呈されます。 99% などの数値は高い数値のように思われますが、1 年間で 3.5 日間サービスが利用できなかったことを意味します。 Amazon や Expedia など、顧客とは主に Web を介して接触する (そして収益を上げる) 企業にとってそれは長時間です。

アップタイム保証はまた、構成やサービスレベルによって変わることがあります。たとえば、Microsoft では、Azure 仮想マシンとの接続率を 99.99% 以上保証していますが、Azure リージョンを同じくする 2 つ以上の可用性ゾーンをまたいで 2 つ以上の仮想マシンインスタンスをデプロイしている場合に限定しています。また、一部のクラウドサービスでは、複数のサービスレベルから選択できるようになっています。レベルが高ければ、保証されたアップタイムが長くなります。一般に、保証時間が長くなるほどコストが高くなります。

クラウドコンピューティングでの監査

クラウドコンピューティングにはさまざまな長所がありますが、大きな課題として、クラウドサービスの信頼性を確保し、検証することが挙げられます。ある顧客が特定レベルの可用性を保証するサービス契約に署名した場合、その顧客は、プロバイダーが契約の条項を順守しているか、どうすれば確認できるでしょうか。その点については、クラウドプロバイダーはどのような方法で確認するでしょうか。

Amazon、Microsoft、Google など、大手のクラウドプロバイダーはサードパーティの監査役を雇い、自社のプラットフォームの可用性や、データセキュリティや機密性など、その他の要因を監視しています。監査人は、米国公認会計士協会 (AICPA) サービス組織管理 (SOC) 標準に準拠した SOC レポート を作成します。 SOC レポートは、次の 3 つのカテゴリに分類されます。

SOC 1 レポート (財務報告について)
SOC 2 レポート (セキュリティ、可用性、プライバシーについて)
SOC 3 レポート (これもセキュリティ、可用性、プライバシーについて)

SOC 1 レポートと SOC 2 レポートは一般に機密であり、クラウドプロバイダーとの守秘義務契約 (NDA) に署名している顧客だけが利用できます。 SOC 3 レポートは一般公開されます。

クラウドプロバイダー大手も顧客に監視サービスを提供しています。そのようなサービスは IaaS、PaaS、SaaS サービスと共にデプロイし、たとえば、Web サイトが停止したときや VM が利用できなくなったときにほぼリアルタイムで顧客に警告できます。 SLA の条件を満たす責任の大部分はクラウドプロバイダーにありますが、顧客も可用性を最大化する目的で展開するソリューションを設計できます。たとえば、利用できなくなったデータベースまたは VM へのトラフィックが別のリージョンにあるそのデータベースまたは VM のコピーにリダイレクトされるよう、クラウドプロバイダーから提供されたフェールオーバーメカニズムを導入します。

クラウドサービスの性質上、監査と監視が必要になります。これには、クライアントのサービスと評判を守るため、対応を迅速に始動する目的で、リアルタイムの監視と評価が必要になります。パブリッククラウドではこれを、顧客のデータが他のクラウド顧客に漏れることを防ぎながら達成する必要があります。ほぼリアルタイムの監査は急速に進化しており、サービス、パフォーマンス、セキュリティメトリックスなどの監査証跡と監視を必要とする、信頼できるクラウドコンピューティングサービスにとって必須になりつつあります。

参考資料

Thomas Trappler。 クラウド内にある場合は、クラウドコンピューティング契約に関する問題を紙に書き込みます。 https://www.educause.edu/ero/article/if-its-cloud-get-it-paper-cloud-computing-contract-issues

フィードバック

このページはお役に立ちましたか?

サービスレベル アグリーメント

自分の知識をチェックする

フィードバック

サービスレベルアグリーメント