クラウド環境内のワークロードを分散させる

しきい値ポリシーを使ってワークロードへの要求を動的に分散させる

多くの企業、政府機関は、クラウド・サービスが常時運用状態を保ち、利用可能であると同時にセキュリティーも維持されていることを要求します。そのようなクラウド・サービスを現実のものにするためには、アプリケーションのテストおよび本番アプリケーションに必要なリソースの管理に関するしきい値ポリシーが必要です。この記事では、しきい値ポリシーとは何であるか、そしてしきい値ポリシーを使ってクラウド環境でのワークロードへの要求を動的に分散させる方法を説明します。

Judith M. Myerson, Systems Engineer and Architect

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


developerWorks 貢献著者レベル

2011年 1月 11日

クラウド環境では、しきい値ポリシーは必要かつ重要な属性です。しきい値ポリシーは、クラウド内のワークロードへの要求があらかじめ決められたしきい値レベルに達し、その要求を動的に分散する必要がある場合に、リソースをチェックおよび管理するために使われます。システムはしきい値ポリシーに従い、ワークロードへの要求がしきい値レベルを超えている分に応じて必要とされるリソース・インスタンスを作成することができます。

このリソース・インスタンスの作成および解放を自動的に行うようにすれば、ワークロードへの要求を動的に分散することができますが、そのためには、しきい値ポリシーを設定および使用する際にいくつかのことを考慮しなければなりません。この記事では、その考慮すべき事項について詳しく説明しますが、まずはその前に、このコンテキストでのしきい値ポリシーとは何かを明確にします。

しきい値ポリシーの概要

まずは、しきい値ポリシーが持つ重要な特性をいくつか取り上げます。

リソース・インスタンス作成までの時間

システムは、ワークロードへの要求がしきい値レベルに達したことを検出したら、ほぼ瞬時に追加のリソース・インスタンスを作成しなければなりません。一方、ワークロードへの要求がしきい値レベルを下回った場合は、システムはリソース・インスタンスの割り当てを解除して、別の用途にそのリソースを使えるようにします。

しきい値ポリシーに影響する要因

しきい値ポリシーに含める必要がある情報は、以下の内容によって左右されます。

  • コンシューマーが借りるクラウド・サービスのタイプ
  • コンシューマーがオペレーティング・システム、ハードウェア、およびソフトウェアに対する制御権をどれだけ持っているか
  • コンシューマーが属している業界のタイプ (例えば、小売業界、エネルギー (電気・ガス・水道など) 業界、金融業界、医療業界、石油化学業界など)

サービス・プロバイダーとポリシー

クラウド・サービス・プロバイダーは、組織が管理するデータ・センターに属している場合もあれば、IBM® などの電気通信および IT 業界の企業によって外部でサービスを提供している場合もあります。いずれにしても、プロバイダーはバックオフィス・システムとの統合を確実にして、注文、プロビジョニング、計量、料金設定と課金、請求、そしてその他の機能がコンシューマーのアクティビティーと取引をサポートするようにしなければなりません。

※訳注: 上記段落の「電気通信および IT 業界」は、原文どおりに訳すと「telecommunications」なので「電気通信業界」ですが、例として IBM が挙げられており、またクラウド・サービス・プロバイダーのことを指していることを考慮すると、「電気通信業界」という表現には違和感があるため、「電気通信および IT 業界」としてあります。

しきい値ポリシーの適用方法

しきい値ポリシーの適用例として、クラウド・サービスを利用する小売業界のコンシューマーの例を紹介します。このコンシューマーがデータ・センターに配置している大規模なアプリケーションは、ワークロードへの要求がしきい値レベルを下回っている間は、クラウド内でクレジット・カードの検証を行っています。クリスマス商戦の時期になると、ワークロードへの要求はしきい値レベルより高くなり、それに応じてシステムは即時にリソースの追加インスタンスを作成して動的にワークロードへの要求を分散します。

商戦期が終わると、ワークロードへの要求はしきい値レベルを下回るため、クラウド内に作成されたリソース・インスタンスは解放されます。この組織はハードウェアに関してある程度の制御権を持っていることから、しきい値ポリシーに設定された条件について、クラウド・サービス・プロバイダーと交渉することができます (商戦期に入る前にポリシーのパラメーターを交渉するのが常に得策です)。

この記事の残りでは、クラウド・サービスのタイプごとの基礎知識を紹介し、クラウドのタイプによってしきい値ポリシーがどのように異なってくるのかを説明します。さらに、アプリケーションのテスト、本番アプリケーション、および容量計画に関するリソース管理のしきい値にポリシーついて説明した後、しきい値ポリシーがサービス・レベル・アグリーメント (SLA) に及ぼす影響など、考慮しなければならない重要な事項を取り上げます。


クラウド・サービスのタイプ

まず、以下のクラウド・サービスの 3 つのタイプのうち、どのクラウド・サービスが自分の要求に合っているかを考えてください。

  • SaaS: Software as a Service
  • PaaS: Platform as a Service
  • IaaS: Infrastructure as a Service

このセクションではまた、最適なクラウド・サービスのタイプがパブリック・クラウドであるか、プライベート・クラウドであるかは、事業の規模によって変わってくることも説明します。

SaaS

例えば小売業界のコンシューマーが、Web でオンデマンド・サービスとして使用するアプリケーションを実行するためのラインセンスを SaaS プロバイダーから取得するとします。コンシューマーは、ハードウェアやソフトウェアを購入、インストール、管理する必要もなければ、アプリケーションを更新する必要もないことから、サブスクリプション方式または従量課金制方式を選びました。

この場合、コンシューマーが制御できるのは、プロバイダーのアプリケーションをコンピューター化された課金・請求タスク、そして人材管理タスクのようなビジネス・タスクとして、デスクトップ機器から使用するか、モバイル機器から使用するかという点だけです。

デプロイされたアプリケーション、オペレーティング・システム、ストレージ、あるいはネットワークを制御することはできませんが、想定内であるか想定外であるかに関わらず、ワークロードへの要求が急増した場合に備え、リソース管理に関するプロバイダーのしきい値ポリシーを確認する必要はあります。

  • SaaS が常時運用状態で利用できることを確実にするために、プロバイダーがしきい値レベルをどのように設定しているかを調べてください。
  • プロバイダーの SLA 条件およびバックアップ・ポリシーの内容を調べてください。
  • プロバイダーが需要の急増に動的に対処することができなかったために、サービスに障害が発生した場合、SLAの規定に従って、割引、返金、一定期間の支払い免除、または SaaS の解約が可能であるかどうかを調べてください。

PaaS

PaaS の場合、小売アプリケーションを作成するところから、アプリケーションをテスト (またはサービスとして本番稼動) するためにデプロイするところまで、コンシューマーがアプリケーションを開発します。

SaaS とは異なり、コンシューマーは、プラットフォームのビジネス・ライフサイクル全体にわたるすべてのアプリケーションを制御することができます (例えば、スプレッドシート、ワード・プロセッサー、バックアップ、課金、給与処理、請求などのアプリケーション)。

プロバイダーが制御するのは、オペレーティング・システム、ハードウェア、またはネットワーク・インフラストラクチャーで、これらの上でアプリケーションを実行することができます。さらに、例えば小売経営アプリケーションのすべての機能のアップグレードおよびパッチをプロバイダーが作成、デプロイ、実行、管理するという場合もあります。

PaaS の場合も当然、プロバイダーのしきい値ポリシーを確認する必要があります。

  • PaaS が常に利用可能であり続けることを確実にするために、プロバイダーがしきい値レベルをどのように設定しているかを調べてください。
  • プロバイダーが需要の急増に動的に対処できなかったことが原因で、サービスに障害が発生した場合、割引、返金、一定期間の支払い免除、またはサービスの解約が可能であるかどうかを調べてください。

IaaS

IaaS ではコンシューマーが、オペレーティング・システム、ネットワーク機器、そしてデプロイされたアプリケーションを仮想マシン・レベルで制御することができます。

  • 仮想サーバーの数やストレージ域のブロック数を増減させることができます。
  • クラウド環境内にある従来のコンピューティング・リソースのインフラストラクチャーを使用し、使用した分だけ支払うことができます。

この場合、IaaS プロバイダーのインフラストラクチャーに関するしきい値ポリシーを調べる必要があります。

  • ワークロードへの要求が急増しても、IaaS が継続してサービスを提供できることを確実にするために、プロバイダーがしきい値レベルをどのように設定しているかを調べてください。
  • しきい値ポリシーに関する条件、および企業との SLA に関する条件について、IaaS プロバイダーと交渉できるようにしてください。
  • コンピューティング・リソースのインフラストラクチャーが需要の急増に動的に対処できなかったことが原因で応答時間が遅くなった場合、SLA の規定に従って、割引、返金、一定期間の支払い免除、またはサービスの解約が可能であるかどうかを調べてください。

事業の規模: パブリックとプライベートの違い

一例として、10 億 US ドルを超える収益を生み出している私の会社では、プライベート・クラウドのほうがパブリック・クラウドよりもコスト効果が高いと判断しています。社内のプライベート・クラウドには、パブリック・クラウドと同様にさまざまなビジネス特性があります。これらの特性を、例えば収益が 100 万 US ドルの小規模な企業での場合と比べてみると、ガバナンス、セキュリティー、可用性、そして復元可能性のレベルについては、私の会社のほうが遥かに高くなっています。

パブリック・クラウドでは、コンシューマーの知らない場所にデータが保管される可能性があるため、保管したデータにアクセスするのが困難になる可能性があります。それとは対照的にプライベート・クラウドでは、データは特定の管轄区域 (例えば、米国など) 内の既知の場所に保管されるため、コンシューマーはいつでもそのデータにアクセスすることができます。コンプライアンスやプライバシーに関わるデータや機密性の高いテスト・データの保管場所が明らかでないのは望ましくありません。さらに、このようなデータが保管されている地域によっては、国によってプライバシーやコンプライアンス関連の規制が異なる可能性もあります。データの輸出管理に関する法律も、国によってさまざまに異なります。

私の会社では、しきい値ポリシーを作成する際の要件として、クラウド環境でワークロードへの要求を分散し始めるレベルを最も高いレベルに設定しています。つまり、ワークロードへの要求がしきい値レベルを超えた時点で、システムは即時にリソースの追加インスタンスを作成できるようでなければならないということです。

私の会社の事業は大規模であることから、トランザクション指向のワークロードは、中小企業での場合よりも多くなります。また、トランザクションの数と種類という点でも中小企業を上回っています。トランザクションのタイプは 2 から 3 ビットの英数字コードで表されるため、大企業でも中小企業でも、それぞれのトランザクションのタイプを企業取引カテゴリーに関連付けなければなりません。企業取引カテゴリーは、大企業 (融資会社など) には役立ちますが、中小企業には適していない可能性があります。


業種

しきい値ポリシーは、業種やクラウド・サービスのタイプによって変わっていきます。また、組織のタイプと規模、市況、季節的なワークロードへの要求、経済状況、要件の変化、新しい技術、そして悪天候の頻発によっても左右されることがあります。

データ・センターの数も、業種によって異なります。例えば、政府部門はデータ・センターのヘビー・ユーザーです。そのため、サービスをオンデマンドで借りることによって、クラウド環境で可用性およびセキュリティーを確保し、コストを削減するという方法を求め続けてきました。

今のところ業界の例として取り上げたのは、小売業界、エネルギー (電気・ガス・水道など) 業界、金融業界、医療業界、電気通信および IT 業界、石油化学業界の 6 つですが、その他にも以下の業界があります。

※訳注: 上記段落の「電気通信および IT 業界」は、原文どおりに訳すと「telecommunications」なので「電気通信業界」ですが、前出の箇所に合わせて「電気通信および IT 業界」としてあります。

  • 航空宇宙・防衛業界
  • 自動車業界
  • 建設業界
  • 消費者製品業界
  • 教育業界
  • エレクトロニクス業界
  • 林業界および製紙業界
  • 政府
  • 保険業界
  • 生命科学業界
  • メディア業界および娯楽業界
  • 金属業界および鉱業界
  • 旅行業界および運送業界
  • 製造業界および組立業界
  • 工業製品業界
  • 造船業界
  • 卸売販売サービス業界

しきい値ポリシーについて検討すべき事項について、小売業界と石油化学業界を比較対照してみましょう。どちらの業界のシステムも、ワークロードへの要求がしきい値レベルを超えていることを検出すると、即座にリソースの追加インスタンスを作成してワークロードへの要求を動的に分散します。ワークロードへの要求がしきい値レベルを下回った時点で、割り当てられたリソースのインスタンスが解放されるのも同じです。

小売業界は、エンド・ユーザーであるコンシューマーへの製品販売に携わる中小企業および大企業からなります。石油化学産業を構成するのは、石油、ガス、化学製品に投資して業界のコンシューマーに販売する大企業および中小企業、そして石油化学プラントです。

小売業界でのワークロードへの要求の急増は、予測可能であるのが通常です (クリスマス商戦など)。一方、石油化学産業でのワークロードへの要求の急増は、一般に、簡単には予測できないさまざまな要因に基づきます。そのため、需要急増の要因となる、経済、サプライ・チェーン最適化の動き、深海石油掘削への投資、そして (ある年は暖冬で、翌年は猛吹雪だったりするなど) 予測不可能な悪天候が追跡されています。

しきい値ポリシーの作成に影響を及ぼすのは、トランザクション・タイプの違い (産業と小売業の違い)、そしてパブリック・クラウド、プライベート・クラウド、あるいはハイブリッド・クラウドのどれを選択するかです。このうち、トランザクション・タイプは、ビジネスまたは製品グループに応じて、収入項目と支出項目を分類するために使用されます。


優れたしきい値ポリシーの内容

優れたリソース管理は、クラウド環境内でリソース使用量のバランスをとる上で重要です。リソース使用量は、しきい値ポリシーによって、アプリケーションのテストおよび本番アプリケーションに対して、動的にバランスがとられるようになります。ただし、アプリケーションのテストに必要となるしきい値は、本番アプリケーションでのしきい値とは異なる可能性があります。前もって容量計画を作成し、それを使用することで、ワークロードへの要求がしきい値レベルに達した時点で追加のリソース・インスタンスが割り当てられるように、システムを準備してください。

IT の専門家は抽象的な言葉で考えることに慣れていますが、しきい値ポリシーの作成に取り組む上で忘れてはならない重要な側面は、ワークロードへの要求に必須のコンポーネントは、実際の物理コンポーネントであるということです。ワイヤレスの部分でさえも、実際の物理コンポーネントの信頼性に依存しているのです。

しきい値ポリシーは、しきい値レベルを何にするかを設定する必要があります。例えば、1 つまたは複数のディスクの 75 パーセント、あるいは 85 パーセントの容量をしきい値レベルとするなどです。そのためには、しきい値ポリシーに、リソース使用量のロギングおよびモニタリング・メカニズムが含まれていなければなりません。

ログには容量だけでなく、しきい値レベルに達したときに割り当てられていたリソース・インスタンスの数、そしてインスタンスが割り当てられるまでの時間も記録します。さらに、以下の情報もログに含める必要があります。

  • アプリケーションのステートフル性
  • レジューム・ポイント
  • フェイルオーバー・メカニズム
  • クラウド・サービスのセキュリティー

ステートフル性

ステートフル性とは、クラウド環境内で、アプリケーションのある機能の状態が、その後のアプリケーションの機能の状態と適切に対応しているかどうかを意味します。かなり単純化したシナリオを例に挙げると、以下のステップで機能の状態が次の状態へと続かなければならないとします。

  1. 利用者がオンラインで、ある小売商品を選択します。
  2. 小売業者は、利用者が選択した商品を買い物かごの中に入れます。
  3. 利用者がクレジット・カード情報を提供します。
  4. 利用者が注文を送信します。
  5. 小売業者はクレジット・カード情報を検証します。
  6. 小売業者は注文番号と配達予定日時を利用者に知らせます。
  7. 小売業者は注文に対する感謝のメッセージを利用者に対して表示します。
  8. 利用者は注文確認の E メールを受け取ります。
  9. 利用者は注文の発送を通知する E メールを受け取ります。

ステップ 2 の機能の状態からステップ 3 に移行しなかったとしたら、その原因には何が考えられるでしょうか。

  • アプリケーションでの新しいビルドによってロジックが壊れた。
  • システムが検出したワークロードへの要求はしきい値レベルを超えていなかったけれども、しきい値レベルの設定が高すぎたため、処理を続行するには残りのリソースでは不十分だった。
  • しきい値レベルは適切に設定されている一方、あるステップの状態を次のステップに確実に進ませるために必要な追加リソース・インスタンスがクラウド内に十分になかった。

アプリケーションがどの状態にあり、状態が正常に完了したのかどうかは、ログに示されている必要があります。

レジューム・ポイント

システムは、システムで問題が発生する以前のさまざまな時点に、レジューム・ポイント (計画的なポイントや、手動によるポイント、異なる環境構成でのポイントなど) を作成する必要があります。

レジューム・ポイントを含めたディスクのスナップショットのバックアップをローカル・システムのディスクに取ると同時に、リモートにある別のディスクにも取ります。ログには、レジューム・ポイントが作成された時刻、そしてシステムのリストに使用したレジューム・ポイントを記録する必要があります。

フェイルオーバー・メカニズム

サービスの可用性を維持するために、システムがフェイルオーバー・メカニズムを起動できることも必要です。

例えば電気通信プロバイダーが誤ってファイバー線を切断してしまったり、コンシューマーの設備資産に接続されたワイヤレス・ネットワークをシャットダウンしてしまったりした場合に備え、代わりとなる有線接続または無線接続もフェイルオーバー・メカニズムとして含まれていなければなりません。フェイルオーバーに使用された機器のタイプとその機器が置かれている場所は、ログに記録します。

フェイルオーバー・メカニズムの例としては、以下のものがあります。

  • 負荷共有冗長構成: 複数のシステムを使用し、各システムがそれぞれ全負荷の 50 パーセント未満を処理します。ある機器に障害が発生した場合、ほとんど、またはまったく中断せずに他の機器が負荷を引き継ぎます。
  • インスタンスのリソース冗長構成: それぞれ全負荷の 50 パーセント未満を処理する複数のリソース・インスタンスを使用します。リソース・インスタンスに障害が発生しても、他のリソース・インスタンスが負荷を引き継ぎます。
  • 代替接続による接続再試行: ネットワーク中断が 2 分を超えた場合、代替接続を介して別のサーバーへの接続を試行します。

クラウド・サービスのセキュリティー

クラウド・サービスのセキュリティーを脅かす原因は、セキュリティーの不十分なクレデンシャル、プロトコルの暴露、そしてリモート管理における実装の不備です。また、IP アドレスを再使用すると、予期せぬ DoS (サービス不能) 攻撃に至る可能性があります。

SaaS はウィルスによる悪意ある攻撃が原因で DoS の被害を受ける可能性があります。また、これまでハッカーが PaaS および IaaS プラットフォームをボットネット (コンピューターのロボット・ネットワーク) の操作を指示する指令室 (CnC) として悪用し、DDoS (分散型サービス不能) 攻撃やマルウェアをクラウドにインストールすることもありました。

ログには、どのクラウド・サービス・タイプでどのようなタイプのセキュリティー問題が発生し、その問題がいつ、どのように解決されたかが記録されている必要があります。


考慮しなければならない事項

通常、クラウド・コンピューティング・システムに責任を持つのはサービス・プロバイダーですが、そのシステムが規制上の要件を満たしていること、システムの運営が十分にセキュアであること、システム管理者が許可なくコンシューマーのデータにアクセスできないこと、そして SLA が規定されていることを確実にするのは、クラウド・サービスのコンシューマーの法的責任です。

コンシューマーは必ず、SLA の仕組み、しきい値ポリシーが SLA に与える影響、そして万が一サービス・プロバイダーへの期待が裏切られた場合の手続きと見込まれる措置について理解しておく必要があります。

SLA の重要な要素は、アップタイム、パフォーマンス標準、緊急時の復旧時間、契約違反に対する措置、セキュリティーです。

しきい値レベルが、SLA にアップタイム用のパフォーマンス標準として指定されている内容と異なってくる可能性を調べてください。しきい値レベルを、アップタイム標準以上に設定するべきではありません。したがって、アップタイム (97 または 99.9 パーセント) を選択してから、ビジネスの要求と予算に最も合ったしきい値レベルを選択する必要があります。

SLA 違反が発生した場合に備え、賠償措置が規定されている必要があります。例えば、サービス・プロバイダーが SLA を満たさなかった場合 (クラウド内でリソースの追加インスタンスを作成するのに要する時間が長いなど)、割引または返金を行うなどの措置です。プロバイダーが 3 ヶ月間に SLA を満たさないことが数回あった場合には、サービスを打ち切れるようになっていなければなりません。SLA に契約解除条項が含まれていることを確認し、その内容を十分注意して読んでください。

SLA に、コンシューマーとプロバイダーとの間でサービス停止期間に関して合意に至らない場合、どこが管轄裁判所となるのかが規定されていることを確認してください。事態が発生してから提訴するまで待たなければならない期間を知る必要があります。また、収益損害、評判低下、データ侵害を含め、保険契約が SLA で扱われていない事項に対処しているかどうかを確認してください。


まとめ

動的にワークロードへの要求を分散するためにしきい値ポリシーを設定するには、事前の計画によって、クラウド環境でリソースの追加インスタンスを作成する際の問題を解決しなければなりません。開発者は、規模の経済性 (パブリック・クラウド対プライベート・クラウド) の問題、そしてアプリケーションのテストおよび本番アプリケーションに対するしきい値ポリシーの作成について、クラウド・サービスのコンシューマーとプロバイダーの双方と話し合う必要があります。容量計画を作成し、それを使用することで、ワークロードへの要求がしきい値レベルに達した時点で追加のリソース・インスタンスが割り当てられるよう、事前にシステムを準備してください。

参考文献

学ぶために

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

議論するために

コメント

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, Industries, SOA and web services
ArticleID=620678
ArticleTitle=クラウド環境内のワークロードを分散させる
publish-date=01112011