先を見越したしきい値ポリシーをクラウドに設定する

しきい値ポリシーに目的、スコープ、背景、コンシューマーによる制御、アクション、制限事項を含める効果について学ぶ

企業や政府機関は、技術上のポリシーや、組織あるいは企業のポリシーを施行することで、ユーザーにそのポリシーに規定された条項を確実に遵守させることがよくあります。つまりクラウド・コンピューティング・サービスのコンシューマーとプロバイダーに対し、彼らが何をすべきかを通知するのです。そのためには注意深くしきい値ポリシーを作成する必要がありますが、このレベルのポリシーは存在していないことが多々あります。この記事ではしきい値ポリシーを作成する方法について、例を示しながら説明します。目的、スコープ、背景、コンシューマーによる制御、アクション、制限事項に対するテンプレートに従いながら、クラウドのリソースしきい値ポリシー、ユーザーしきい値ポリシー、データ・リクエストしきい値ポリシーを作成する方法を学びましょう。

Judith M. Myerson, Systems Engineer and Architect

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



2011年 7月 01日

しきい値ポリシーを注意深く作成し、クラウド・コンピューティング・サービスのコンシューマーとプロバイダーが何をすべきかについての概要を規定しておくと、プロバイダーが管理に要する時間を大幅に節約することができます。作成しておくとよいポリシーには以下のようなものがあります。

  • リソースしきい値ポリシー: クラウド内のアプリケーションによるリソースの使用量がしきい値レベル以下になるように動的にバランスが取られることが保証されます。
  • ユーザーしきい値ポリシー: プロバイダーによるユーザー・ライセンスで規定された最大同時接続ユーザー数のしきい値レベル以下の数のユーザーがアプリケーションに同時アクセスできることが保証されます。
  • データ・リクエストしきい値ポリシー: しきい値レベル以下の数の (アプリケーションへの) データ・リクエストが即座に処理されることが保証されます。

各しきい値ポリシーを決定する要素は主に以下の 3 つです。

  • どのようなクラウド・サービスがプロバイダーによってホストされるのか — それは SaaS (Software as a Service) なのか、PaaS (Platform as a Service) なのか、それとも IaaS (Infrastructure as a Service) なのか。
  • パブリック・クラウドなのかプライベート・クラウドなのか。
  • コンシューマーはオペレーティング・システム、ハードウェア、ソフトウェアをどの程度制御できるのか。

他にも、ポリシーに影響を与える可能性がある要素として、以下の内容を考慮する必要があります。

  • 社内アプリケーションをクラウド内で完璧に動作させるために、先を見越した変更としてアプリケーションの動作をどう変更したか。
  • プロバイダーは組織管轄下のデータ・センターの社内部署なのか、それとも通信業界の企業が外部でホストしているプロバイダーなのか。
  • そのコンシューマーが属する業界の種類は広範にわたっているかどうか (小売業界、電気・ガス・水道などのエネルギー業界、金融業界、医療業界、石油化学業界など)。

しきい値ポリシーを確認したいというコンシューマーの要求を満たすために、すべてのプロバイダーはしきい値ポリシーをコンシューマーに提供する必要があります。プロバイダーはコンシューマーに対し、あるタイプのクラウド・サービスをコンシューマーがレンタルすなわちサブスクライブする前に、解決しておく必要がある、あるいは交渉する必要があると思われることについて、質問を送るように働きかけなければなりません。

この記事ではまず、しきい値ポリシーの使い方の例について説明します。次に、しきい値ポリシーを作成する際に含める必要がある要素として、目的、スコープ、背景、コンシューマーによる制御、アクション、制限事項のチェックリストを使用する例を紹介します。

しきい値ポリシーに関するシミュレーションをする

クラウド・ベースのポリシー作成に関する記事を書くにあたっての主要なテーマの 1 つは、先を見越す必要があるということです。つまり、あるしきい値ポリシーがシステムにどう影響する可能性があるのか、感覚をつかむことが重要になってくるということです。ここで架空のケースとして、小売業界のコンシューマーがクラウド・サービスを利用しているとします。クラウド内ではデータ・センターにある大規模なアプリケーションがクレジットカードの検証を行っていますが、ワークロード要求はリソースしきい値ポリシーに規定されたしきい値レベルを下回っています。ユーザーとデータ・リクエストの数も、ユーザーしきい値ポリシーとデータ・リクエストしきい値ポリシーに規定されたしきい値レベルを下回っています。

クリスマス商戦が訪れると、システムはしきい値レベルを超える高いワークロード要求を検出します。それに対応し、システムは素早くリソースのインスタンスを追加で作成し、ワークロード要求を動的にバランスさせます。それに伴い、対応することが要求されるユーザーおよびデータ・リクエストの数も増大します (どちらも最大で、ユーザー・ライセンスが規定している上限まで)。

クリスマス商戦が終わると、この小売業者のサービスのワークロード要求はしきい値を下回るレベルに低下するため、クラウド内に作成されたリソースのインスタンスも解放されます。それに伴い、ワークロード要求に対処するために、対応することが要求されるユーザーおよびデータ・リクエストの数も減少します。

この組織はハードウェアをある程度制御できるため、しきい値ポリシーに規定される条項に関してクラウド・サービスのプロバイダーと交渉することができます (商戦の前にポリシーのパラメーターを交渉することが重要です)。


チェックリストを作成する

しきい値ポリシーの作成にどこから手を付ければよいのかわからなくても、心配することはありません。ここでは、しきい値ポリシーに何を含めればよいかを確認するためのチェックリストを紹介します。最終的にどのようなタイプのポリシーを作成したいかによらず、ほとんどの場合は以下の要素をポリシーに含める必要があります。

  • 目的: ポリシーの目的を記述してください
  • スコープ: ポリシーの範囲を規定してください
  • 背景: ポリシーの背後にある情報を記述してください
  • コンシューマーによる制御: どの程度制御できるのでしょう?広範でしょうか?わずかでしょうか?
  • アクション: 準備はできていますか?しっかりと準備をしてください
  • 制限事項: 制限事項を扱ってください

リソース、ユーザー、データ・リクエストという 3 つのポリシー・タイプを個々に作成することも、3 つをまとめて 1 つのしきい値ポリシーにすることもできます。ここでは単純なシナリオにするために 3 つを 1 つにまとめる方法を紹介し、チェックリストの各項目の扱い方についてのヒントを説明します。

目的: ポリシーの目的を記述してください

しきい値ポリシーを施行するためには、そのポリシーの目的を簡単に記述します。以下のようなテンプレートを使用すると、目的を記述する方法についての感覚をつかむことができます。

しきい値ポリシーの目的とは、クラウド・サービスのプロバイダーによるサービスの提供を支援することです。以下に 3 つのしきい値ポリシーの目的を記載します。

  • リソースしきい値ポリシー: このポリシーは、クラウド内のアプリケーションによるリソースの使用量がしきい値レベル以下になるように動的にバランスが取られることを保証するためにあります。
  • ユーザーしきい値ポリシー: このポリシーは、プロバイダーによるユーザー・ライセンスで規定された最大同時接続ユーザー数のしきい値レベル以下の数のユーザーがクラウド・アプリケーションに同時アクセスできることを保証するためにあります。
  • データ・リクエストしきい値ポリシー: このポリシーは、複数のユーザーからアプリケーションに対して同時に送信されるデータ・リクエストのうち、しきい値レベル以下の数のデータ・リクエストが即座に処理されることを保証するためにあります。

スコープ: ポリシーの範囲を規定してください

スコープを定義するためには、ポリシーの範囲を設定します。どのタイプのクラウド・サービスをプロバイダーがホストし、コンシューマーがレンタルすなわちサブスクライブするのかを、ポリシーの範囲として規定します。SaaS、PaaS、IaaS のそれぞれ、あるいはそのすべてに関し、プロバイダーが何をする必要があり、コンシューマーがサービスをどう利用できるかを規定します。

例えば、プロバイダーが 3 つのタイプのクラウド・サービスをすべてホストする場合、そのプロバイダーは以下の内容を明記する必要があります。

  • エンド・ユーザーは特定のアプリケーションのみをレンタルするのかどうか。
  • アプリケーション開発者は PaaS のみをレンタルし、PaaS 上で実行される特定の SaaS アプリケーションのパラメーターをカスタマイズまたは変更するのかどうか。
  • アプリケーション開発者と、それらのアプリケーションを SaaS として利用するユーザーは、PaaS 上に併存する SaaS アプリケーションのサブスクリプションを購入できるのかどうか。
  • インフラストラクチャーやネットワークのスペシャリストは、インフラストラクチャー (IaaS) をレンタルして仮想インフラストラクチャー環境を構築し、その IaaS 上で PaaS を実行するのかどうか。

プロバイダーは、コンシューマーがスコープ内にとどまっているかどうか (ポリシーの条項に従っているかどうか) を調べる必要があります。コンシューマーがポリシーの条項に従うことに同意した後にスコープを逸脱した場合、そのコンシューマーはポリシーに違反するというリスクを冒しています。その場合には、プロバイダーはポリシーに従わない場合にどのような結果が待ち受けているかをコンシューマーに示し、コンシューマーを必ずスコープ内にとどまらせる必要があります。

以下のテンプレートを使用すると、スコープを記述する方法についての感覚をつかむことができます。

  • このポリシーは、SaaS を利用するエンド・ユーザー、PaaS を利用するアプリケーション開発者、IaaS を利用するインフラストラクチャーおよびネットワークのアーキテクトのすべてに適用されます。すべてのエンド・ユーザー、開発者、アーキテクトは、このしきい値ポリシーのすべての条項に同意し、このしきい値ポリシーに関するすべての契約条件を遵守することに同意します。このポリシー、あるいは関連する他の IT ポリシーや規制に違反する行為を行ったすべてのエンド・ユーザー、開発者、ネットワーク・アーキテクトは、このプロバイダーによるサービスの制限あるいは打ち切りの対象となります。

背景: ポリシーの背後にある情報を記述してください

コンシューマーが真っ先に知りたいことは、社内のプロバイダーなのか社外のプロバイダーなのか、という点です。次にコンシューマーが知りたいことは、社内アプリケーションのしきい値レベルがクラウド内で適切に機能するために、先を見越した変更としてアプリケーションの動作がどう変更されているか、という点です。

またコンシューマーは、しきい値レベルと、サービス・レベル・アグリーメント (SLA) で規定されるサービス可用性の保証レベルとがどう関係するのかも知りたがります。例えばクリスマス商戦のストーリーに戻ると、この種のイベントによってリソース・インスタンスの使用量はしきい値レベルを超えるまでに急増するため、システムは追加のリソース・インスタンスを作成してワークロード要求のバランスを動的に取ります。その結果、同時に処理することができるユーザー数とデータ・リクエスト数を増やす必要が出てきます。

クリスマス商戦のケースでは、リソース・インスタンスの使用量がしきい値レベルを超えるまでに急増した結果、システムは追加のリソース・インスタンスを作成しました。今度は、これとは別のストーリーについて考えてみましょう。今度のストーリーは、システムに発生した予期せぬ問題によってパフォーマンスが低下していく様子をコンシューマーがダッシュボードで観察しています。コンシューマーは、システムが早期に回復することを要求し、SLA の規定に従い、一定期間の支払い免除、あるいは解約の権利を主張します (もちろん、商戦のピークに解約するのは非現実的で、その可能性は低いはずです)。

以下のようなテンプレートを使用すると、何を含めればよいかの感覚をつかむことができます。

  • クラウド・サービス・プロバイダーは、通信業界の一員である IBM によって外部でホストされています。
  • ワークロード要求や、同時に処理する必要があるユーザー数およびデータ・リクエスト数が、しきい値レベルを超えるまでに急増したことによって、システムのパフォーマンスが保証レベルである 30 日間の可用性よりも低下した場合には、プロバイダーは SLA の規定に従い、コンシューマーに対し、割引、一定期間の支払い免除、サービス解約の権利を与える必要があります。プロバイダーはしきい値ポリシーの例外や制限事項について、コンシューマーに通知しなければなりません。
  • ユーザー・ライセンスには、以下の 3 種類の最大数が規定されています。
    • アプリケーションに同時にアクセスできるユーザーの数
    • 各ユーザーに割り当てられるリソース・インスタンスの数
    • ワークロード要求が急増した際に処理することが可能なデータ・リクエストの数
  • プロバイダーが SaaS アプリケーションに対して先を見越した動作変更を行う場合、プロバイダーはその変更の実効日についてコンシューマーに通知を送ります。

コンシューマーによる制御: どの程度制御できるのでしょう?広範でしょうか?わずかでしょうか?

デプロイされたアプリケーション、オペレーティング・システム、ストレージ、ネットワーキングに対し、コンシューマーはどの程度制御できる必要があるのでしょう。それはコンシューマーの役割に依存します。つまりそのコンシューマーが SaaS を利用するエンド・ユーザーなのか、PaaS を利用するアプリケーション開発者なのか、IaaS を利用するインフラストラクチャーまたはネットワークのスペシャリストなのかによります。

  • SaaS を利用するエンド・ユーザーは、デスクトップ機器またはモバイル機器からプロバイダーのアプリケーションにアクセスし、ビジネス・タスクを処理することができます。エンド・ユーザーが制御できるのは、そこまでです。

    SaaS のプロバイダーは、デプロイされたアプリケーション、オペレーティング・システム、ストレージ、ネットワーキングを制御することができます。

  • PaaS を利用するアプリケーション開発者は、そのプラットフォームのビジネス・ライフサイクル全体の中に存在するすべてのアプリケーション (スプレッドシート、ワード・プロセッサー、バックアップ、課金、給与処理、請求などのアプリケーション) を制御することができます。開発者は、例えば小売管理アプリケーションの、すべての機能に対するアップグレードやパッチをビルド、デプロイ、実行、管理することができます。

    PaaS プロバイダーは、アプリケーションが実行されるベースとなるオペレーティング・システム、ハードウェア、ネットワークのインフラストラクチャーを制御することができます。

  • IaaS を利用するインフラストラクチャー・アーキテクトは、オペレーティング・システム、ネットワーク機器、デプロイされたアプリケーションを仮想マシン・レベルで制御し、仮想サーバーの数やストレージ領域のブロック数を増減させることができます。IaaS を利用するインフラストラクチャーおよびネットワークのスペシャリストは、オペレーティング・システム、ネットワーク機器、デプロイされたアプリケーションを仮想マシン・レベルで制御することができます。IaaS のコンシューマーは、仮想サーバーの数やストレージ領域のブロック数を増減させることができます。

    IaaS のプロバイダーは、クラウド環境内にある従来のコンピューティング・リソースのインフラストラクチャーを制御することができます。

上記の各サブセクションは、制御の属性を定義するためのテンプレートとして使用することができます。

アクション: しっかりと準備をしてください

ここでは、コンシューマーを満足させるために、以下のアクションを行うことを提言します。

  • アクション #1: しきい値ポリシーの内容をコンシューマーに送ります。そうすることで、コンシューマーはクラウド・サービスを契約する前にしきい値ポリシーを確認し、解決しておくべきことを質問することができます。
  • アクション #2: SaaS アプリケーションのユーザー・ライセンスの中に、同時にアクセスできるユーザー数、それらのユーザー用のリソース・インスタンス数、そして同時に処理できるデータ・リクエストの数に関する最大数の制限の変更について明記します。
  • アクション #3: リソース、ユーザー、データ・リクエストに対するしきい値ポリシーのしきい値レベルを設定し、それぞれのしきい値ポリシーではサービス可用性の保証レベルについて触れます。
  • アクション #4: SaaS クラウドで現在実行されているアプリケーションを置き換える目的で、データ・センターで開発されたアプリケーションに対し、先を見越した動作変更が計画されている場合、その変更についての通知をコンシューマーに送ります。
  • アクション #5: PaaS を利用するアプリケーション開発者と、そのアプリケーションを SaaS として使用するユーザーに対し、その PaaS 上に併存する SaaS アプリケーションをサブスクライブすることを許可します。

そして、以下の内容をテンプレートとして使用することができます。

  • リソースしきい値ポリシー: プロバイダーは、利用可能な追加リソースの最大数を下回る値にリソースしきい値レベルを設定します。このポリシーには、リソースしきい値レベルはサービス・レベル・アグリーメント (SLA) に規定されたサービス可用性の保証レベルと同じまたはそれ未満であることを明記する必要があります。
  • ユーザーしきい値ポリシー: プロバイダーは、同時アクセスできる最大ユーザー数を下回る値にユーザーしきい値レベルを設定します。このポリシーには、同時アクセスできるユーザー数と、それらのユーザーが利用できるリソース・インスタンスの数とが比例関係にあることを明記する必要があります。
  • データ・リクエストしきい値ポリシー: プロバイダーは、複数のユーザーから同時に送信されて処理することが可能なデータ・リクエストの最大数と最大サイズを下回る値にデータ・リクエストしきい値レベルを設定します。データ・リクエストの数とサイズは、あるタイプのクラウド・サービスに関するユーザー・ライセンスの規定に依存します。
  • SaaS ユーザー・ライセンス: プロバイダーは以下の数に対して最大値を設定します。
    • アプリケーションに同時にアクセスできるユーザーの数
    • ユーザーがアプリケーションにアクセスして実行する際に使用できるリソース・インスタンスの数
    • 利用可能なリソース・インスタンスを使用してユーザーが同時に送受信できるデータ・リクエストの数

制限事項: 制限事項を扱ってください

ほとんどの場合、何らかの制限事項があるものです。例えば次のような制限事項が考えられます。

  • サービスの優先度の問題: 組織がコンシューマーに割り当てた役割により、コンシューマーのグループが異なると優先度も異なる場合があります。SaaS アプリケーションにアクセスする上で、管理者権限を持つエンド・ユーザーは管理者権限を持たないエンド・ユーザーよりも高い優先度を持ちます。
  • 管理ガバナンス・グループの変更: あらゆる変更を反映するために、しきい値ポリシーと SLA を更新する必要があります。
  • しきい値ポリシーと SLA に対するサービスの例外: 以下にヒントを記載します。例外の例として、プロバイダーが直接制御できる範囲外で光ファイバーが誤って切断された場合や、事前に通知されたメンテナンス (不定期および定期)、アプリケーションを社内からクラウドに移行する場合の (アプリケーションに対する) 先を見越した動作変更、などが挙げられます。
  • しきい値レベルを超えた場合のサービスに関するペナルティー: しきい値レベルを超えた結果、保証されたレベルのサービス可用性よりもシステムのパフォーマンスが大幅に低下する場合があります。保証されたレベルのサービスを提供できなかったことがサービスの例外ではない限り、割引、返金、一定期間の支払い免除を権利としてコンシューマーに提供する必要があります。また、契約の終了に関する条項には、クラウド・サービスを解約する権利をコンシューマーが執行する場合のプロセスについて規定しておく必要があります。

いくつかの制限事項が障害になると思われる場合には、制限事項について扱っておくのが最善の方法です。第 1 に、制限事項を利用することで、しきい値ポリシーに対するセキュリティー体制を強化することできます。第 2 に、ワークロード要求がしきい値レベルを超えるまでに急増した場合には、システムのパフォーマンスがサービス可用性の保証レベルよりも下がる場合に備えて、コンシューマーを保護するための手段を準備する必要があります。

以下のテンプレートを使用することができます。

  • SaaS のユーザー・ライセンスを管理するエンド・ユーザーは、ライセンスされたアプリケーションにアクセスする上で、他のエンド・ユーザーよりも高い優先度を持ちます。
  • 規定された期間の後にコンシューマーが SLA を解約することをプロバイダーが許可した場合には、SLA の契約の終了に関する条項が執行されます。
  • 最近の組織変更により、ポリシー・ガバナンス・グループは ABC 部門から XYZ 部門に異動しました。そのため、しきい値ポリシーと SLA の両方を更新する必要があります。
  • サービスの例外として現在認められている事項は以下のとおりです。
    • プロバイダーが直接制御できる範囲外で、光ファイバーの誤切断や、ネットワークに関するその他の問題が発生した場合
    • プロバイダーのホストが DoS (サービス拒否) 攻撃を受けた場合
    • プロバイダーによる、事前に通知されたメンテナンス
    • プロバイダーのサービスを利用できるのは午前 8 時から午後 5 時まで

まとめ

リソース、ユーザー、データ・リクエストのしきい値レベルに対してしきい値ポリシーを作成する場合、それらのポリシーの目的、スコープ、背景をどう記述するかという問題を解決するために、十分な事前計画が必要です。開発者はクラウド・サービスのコンシューマーとプロバイダーの両方と話し合い、コンシューマーはどの程度まで制御できる必要があるか、プロバイダーはどのようなアクションを実行する必要があるか、ポリシーに対して考えられる制限事項と実際の制限事項にはどのようなものがあるか、といった問題を検討する必要があります。これに限らずあらゆる交渉について言えることですが、クラウドのコンシューマーとして最も重要なことは、プロバイダーからポリシーを入手して内容を確認し、プロバイダーと交渉する前に皆さんが持っている疑問を解決しておくことです。

参考文献

学ぶために

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

  • IBM SmartCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

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
ArticleID=682395
ArticleTitle=先を見越したしきい値ポリシーをクラウドに設定する
publish-date=07012011