クラウドのフェイルオーバー・ポリシーを作成する

ユーザーが制御できる要素とユーザーに許可されるタスクについて詳述したクラウド固有の付帯条項を含むフェイルオーバー・ポリシーを作成する

今後数年以内に、ほとんどの組織や機関はデータの一部をクラウドに移行済みであるか、クラウドに移行している最中であるか、あるいは、ある程度クラウドを使用することを真剣に検討しているかのいずれかの状態であると思いますが、彼らにとって最大の懸念は今と変わらず信頼性とセキュリティーだと思います。信頼性の点では、組織はなお最低限 99.5 パーセントのアップタイムを要求します。残念ながら、多くの組織は相変わらず、障害が発生すると「反応的な」対応をします。反応的ではなく、先を見越した賢明な対策を講じるには、クラウドのフェイルオーバー・ポリシーを作成する必要があり、そのポリシーの中にクラウド固有の付帯条項を含め、ユーザーが制御できる要素とユーザーに許可されるタスクを詳述する必要があります。この記事では、そうしたポリシーを作成するためのロードマップを示し、ポリシーの付帯条項と、障害が発生したときのシナリオのなかで先を見越してどのようなアクションを取ることができるかについて説明します。

Judith M. Myerson, Systems Engineer and Architect

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


developerWorks 貢献著者レベル

2012年 5月 10日

クラウドのフェイルオーバー・ポリシーの目標は、クラウド・サービスの可用性として 99.5 パーセント以上を保証することです。このポリシーの焦点は、クラウド・サービスで実行される SaaS (Software as a Service) アプリケーション、PaaS (Platform as a Service) プラットフォーム、IaaS (Infrastructure as a Service) 仮想マシンを、どのようにして障害の発生したデータ・センターから正常に稼働しているデータ・センターへと移行し、ほとんど中断のないクラウド・サービスを顧客に提供するか、という点です。

クラウド・ユーザーはクラウド・サービスに壊滅的な障害が発生して欲しくないと考えています。壊滅的な障害の例として、以下のように少なくとも 2 回、Amazon の米国 (北バージニア) 地域でネットワーク障害によってサービスを利用できなくなったことがあります。

  • 2007年、Amazon の EC2 (Elastic Compute Cloud) サービスが影響を受けました。
  • 2011年、Amazon のクラウド・コンピューティング PaaS ソリューション、EC2、リレーショナル・データベース・サービスが影響を受けました。

米国内の他の地域にある Amazon の 2 つのデータ・センターは正常に動作を続けました。

この北バージニア地域での障害では、Amazon の EC2 サービスで使用するストレージ・ボリュームのバックアップが自動的に作成されてストレージ容量が一杯になり、ストレージ容量の最大限界値を超えてバックアップを格納しようとした時に障害が発生しました。ネットワークには、それ以上バックアップを格納する場所がなくなったのです。

この種の障害により、顧客は何千時間もかけて蓄積したデータを失う可能性があります。この記事では、この種のデータ損失を防ぐ方法について説明します。そしてクラウドの各サービス形態 (SaaS、PaaS、IaaS) に関して、クラウドのフェイルオーバー・ポリシーとクラウド固有の付帯条項について説明し、その後で障害発生時に損害の拡大防止、問題の修復、システムのリストア、顧客への通知を行うシナリオについて説明します。

SaaS 固有の付帯条項

このセクションでは、クラウドのフェイルオーバー・ポリシーに付帯する SaaS 固有の条項にどのような要素とタスクを含めるべきか、その一例を紹介します。

要素

SaaS ユーザーが制御できる要素は限られているため、SaaS 固有の付帯条項に含める必要のある要素は以下の 3 つのみです。

  • ユーザーによる制御
  • ユーザー・ライセンス
  • フェイルオーバー・プラン

SaaS ユーザーが制御できるのは、ビジネス機能を実行するために行う SaaS アプリケーションへのアクセスのみです。プロバイダーとの交渉によって決まるユーザー・ライセンスの条項では、以下の数値を規定する必要があります。

  • アクセス対象の SaaS アプリケーションの最大数
  • 1 つのアプリケーションに同時にアクセスできる最大ユーザー数
  • 各ユーザーに割り当てられるリクエストの最大数

また、ユーザーがアクセスを許可される SaaS アプリケーションのタイプもユーザー・ライセンスの条項で規定する必要があります (例えば会計、プロジェクト管理、顧客関係管理、小売管理、さらには IBM Rational AppScan による脆弱性スキャナーなど)。

フェイルオーバー・プランの条項では、SaaS アプリケーションのインスタンスをホストするデータ・センターを、障害の発生したデータ・センターから別のデータ・センターにフェイルオーバーできるように規定する必要があります。また、プロバイダーがバックアップ・サービスとサービス・レベル・アグリーメント (SLA) の両方を提供することや、Federal Privacy Act (米国のプライバシー法) や Personal Information Protection and Electronic Documents Act (カナダの個人情報保護及び電子文書法) などのデータ・プライバシー法に準拠していることを示す必要があります。

タスク

SaaS ユーザーには少なくとも以下のタスクが許可されている必要があります。

  • ユーザーごとに許可された最大アクセス数まで SaaS アプリケーションにアクセスする。
  • ユーザーに割り当てられたロールをベースにレコードを更新する。
  • セキュリティー・アラートを受信する。

以下のタスクを実行できるのはプロバイダーのみです。

  • ソフトウェアのアップグレード・ライセンスを購入する。
  • SaaS アプリケーションに対するパッチを管理する。
  • システム・アプリケーションと仮想マシンにアクセスする。
  • 仮想マシンが稼働している従来のコンピューティング・インフラストラクチャーにアクセスする。

プロバイダーは、SaaS アプリケーションをホストするデータ・センターに障害が発生した場合に、その障害が発生したデータ・センターから正常に稼働しているデータ・センターに SaaS アプリケーションを可能な限り短時間 (時間は 5 分以下) でフェイルオーバーする方法と、問題修復後にそのアプリケーションをリストアする方法を規定する必要があります。

以上の内容を説明するために、SaaS で障害が発生したときのシナリオを見てみましょう。


SaaS で障害が発生したときのシナリオ

ある企業のオンプレミスで稼働中の CRM アプリケーションが、SaaS アプリケーションとして、米国地域内のデータ・センターでマルチテナンシー環境をホストする外部プロバイダー環境へと正常にマイグレーションされました。ところが、あるデータ・センターで発生した発生したネットワーク障害により、2、3 日間システムがダウンしました。ストレージ・データの自動バックアップによってストレージ容量が一杯になり、世界中で発生する 2 億トランザクションもの処理結果を格納する場所がネットワーク上になくなってしまったのです。これにより、苦情が殺到しました (ご想像のとおりです)。

  • このアプリケーションを利用している営業マンからは、怒りのクレームが上がってきました。
  • ヘルプ・コール・センターの電話は、大きな音で鳴り続けました (これは何日間も続きました)。
  • プロバイダーは (SaaS ユーザーとの交渉による SLA で保証しているにもかかわらず、障害発生後 2 分以内に SaaS CRM アプリケーションが復旧しないことが明らかになり) 頭を抱えました。

プロバイダーは大慌てで手っ取り早いソリューションを求め、「しばらくお待ちください。システムは間もなく復旧します。」という通知を Web サイトに掲示しました。しかし、「間もなく」復旧することはありませんでした。

プロバイダーは SaaS アプリケーションを復旧させるまで、2、3 日かかりました。プロバイダーは効果的なフェイルオーバーを提供することができませんでした。ではこれから、損害の拡大防止、問題の修復、システムのリストア、そして顧客への通知のためにプロバイダーが実行できる、先を見越したアクションについて説明します。

損害の拡大防止

損害の拡大を防止するためには、事前に計画を立て、自動的にフェイルオーバーを行うインスタンスとして SaaS アプリケーションを準備する必要があります。SaaS の契約者とプロバイダーは交渉して SLA を作成する必要があります。そしてサービスの可用性がその SLA の保証レベル (99.9 パーセント) を大幅に下回る可能性が生じた場合には、プロバイダーにその旨のアラートが送信されるようにする必要があります。ネットワークのトラフィックの状況によっては、サービスが停止してもほとんど瞬時に復帰して、可用性の保証レベルが維持される場合もあります。

一方、プロバイダーが問題を修復している間、サービスは別のデータ・センターで継続的に提供されるという通知が SaaS クライアントに送信されます。プロバイダーは元のデータ・センターでのサービスがリストアされると、SaaS クライアントに通知します。

(これらのポリシーで説明している、先を見越したアクションにはすべて、通知という重要な要素があることに注意してください。懸念を感じている関係者に対し、運用上どんなことが発生しているかを知らせることで、多くの場合に問題解決のための時間を稼ぐことができます。説明できる状況であるにもかかわらず、顧客に状況を知らせずにおくことは、皆さんにとって必ず不利に働きます。)

問題の修復

プロバイダーはあらかじめ、クラウドのフェイルオーバー対策として、以下のようなフェイルオーバー・ポリシーを作成することができます。

  • 障害が発生したデータ・センターから別のデータ・センターにフェイルオーバーできるように SaaS アプリケーションのインスタンスをインストールする。
  • バックアップ・テープが適切に機能していて欠陥がないかどうかを定期的にチェックする。
  • ネットワーク・ソフトウェアが想定どおりに問題を修復できるかどうかをテストする。

システムのリストア

次のステップは、システム・ダウンが発生したデータ・センターでシステムのリストアを開始することです。プロバイダーは、リストアされたシステムのレジリエンシーをテストする環境を構築し、別のデータ・センターへのフェイルオーバーが比較的スムーズに行えるかどうかを確認します。例えば、プロバイダーはリソースやサービスをランダムに停止させ、その結果を記録します。

テストが完了すると、プロバイダーはリストアされたシステムのバックアップをとってから、そのシステムを本番環境に移行します。

顧客への通知

シスタム・ダウンが発生したデータ・センターで SaaS アプリケーションがリストアされると、プロバイダーは顧客に対して即座に、リストアが完了したこと、そして SLA の条項 (割引、返金、解約の権利) が履行されることを通知します。


PaaS 固有の付帯条項

このセクションでは、クラウドのフェイルオーバー・ポリシーに付帯する PaaS 固有の条項にどのような要素とタスクを含めるべきかを紹介します。

要素

PaaS 開発者は SaaS ユーザーよりも多くの要素を制御することができるため、PaaS 固有の付帯条項には SaaS 固有の付帯条項よりも少なくとも 1 つ多くの要素、つまりアプリケーションの開発機能を含める必要があります (PaaS 開発者にとって制御可能な要素は、ユーザーによる制御、開発者ライセンス、アプリケーション開発 (SaaS ユーザーにはありません)、フェイルオーバー・プランです)。

PaaS 開発者は、SaaS アプリケーションの開発と、ビジネスのライフ・サイクル全体の中にあるすべてのアプリケーション (スプレッドシート、ワード・プロセッサー、バックアップなど) の開発を制御します。

プロバイダーとの交渉によって決まる開発者ライセンスの条項では、以下の数値を規定する必要があります。

  • 開発対象のアプリケーションの最大数
  • 同時に PaaS を利用できるアプリケーション開発者の最大数
  • PaaS 上のアプリケーションに同時にアクセスできる SaaS ユーザーの最大数

アプリケーション開発の条項では、開発対象のアプリケーションのタイプを規定する必要があります。アプリケーションには以下のようなタイプがあります。

  • SaaS アプリケーション
  • Web サイト
  • CRM アプリケーション
  • モバイル・アプリケーション
  • 課金アプリケーションや給与アプリケーション
  • サービス配信プラットフォーム・アプリケーション (モバイル TV など)
  • コンテンツ配信管理アプリケーション

フェイルオーバー・プランの条項では、PaaS アプリケーションのインスタンスをホストするデータ・センターを、障害の発生したデータ・センターから別のデータ・センターにフェイルオーバーできるように規定する必要があります。また、PaaS 開発者が自ら作成したフェイルオーバー・アプリケーションを使用するのか、それともプロバイダーによるフェイルオーバー・アプリケーションを使用するのか、またロード・バランシングなどのタスクにサードパーティーのツールを使用できるのかどうかも、この条項で規定する必要があります。さらには、プロバイダーがバックアップ・サービスと SLA の両方を提供するのかどうか、プロバイダーがデータ・プライバシー法令を遵守しているかどうかも規定する必要があります。

タスク

PaaS 開発者に許可されるタスクは以下のとおりです。

  • アプリケーションを作成、デプロイ、実行する。
  • パッチやアップグレードを管理する。
  • PaaS 上に共存する SaaS アプリケーションにアクセスできる SaaS ユーザーを決定する。
  • 現地市場の条件に合わせて開発者のプラットフォームを柔軟にカスタマイズする。

また PaaS 開発者には以下のタスクも許可されています。

  • アプリケーションをスキャンして脆弱性を確認する。
  • アプリケーションのファイアウォールを構成する。
  • セキュリティー・アラートを作成、監視する。
  • バックアップ処理を実行する。

プロバイダーのみが実行できるタスクには、少なくとも以下のようなものがあります。

  • システム・アプリケーションを実行する。
  • 仮想マシンを実行する。
  • 仮想マシンが稼働している従来のコンピューティング・インフラストラクチャーにアクセスする。

以上の内容を説明するために、PaaS で障害が発生したときのシナリオを見てみましょう。


PaaS で障害が発生したときのシナリオ

PaaS 開発者の「リソース最適化」アプリケーションに障害が発生しました。この障害により、このプラットフォームと、同じプロバイダーがホストする他の PaaS プラットフォームが完全に停止しました。この障害は、ホストの障害に耐えるためのサービス・インスタンスの複製を作成できなかったために発生した可能性がありました。残念なことに、「リソース最適化」アプリケーションは障害を検出しなかったばかりか、短時間でタイムアウトさせて迅速にリトライする処理も実装していませんでした。

プロバイダーは PaaS 固有の付帯条項を履行することで、以下のような先を見越したアクションを実行することができます。この付帯条項はプロバイダーとの交渉で作成され、損害の拡大防止、問題の修復、システムのリストア、顧客への通知について規定します。

損害の拡大防止

PaaS 開発者は損害の拡大を防止するために、複数ホストには依存せず 1 つのホストで構成される単純なサービスを作成します。こうすることで PaaS 開発者は、ホストの障害に耐えられるようにするために、サービス・インスタンスの複製を作成することができます。

問題の修復

障害が発生すると、開発者のソフトウェアはそれらの障害を即座に検出し、フェイルオーバー・プロセスを開始します。

ここで仮に、開発者がビジネス・ロジック・コンポーネント A、B、C で構成される課金アプリケーションを開発しているとすると、開発者はサービス・グループを以下のように構成する可能性があります。

(A1, B1, C1), (A2, B2, C2) ... (An, Bn, Cn)

Where n is the number of component type representing the number of a 
service group category

        for service category 1, 
                A1 is the logic to find service code
                B1 is the logic to insert service category into the bill
                C1 is the logic to check the accuracy of zip codes
				
        for service category 2, 
                A2 is the logic to find service code
                B2 is the logic to insert service category into the bill
                C2 is the logic to check the accuracy of zip codes
				
        for service category n, 
                An is the logic to find service code
                Bn is the logic to insert service category into the bill
                Cn is the logic to check the accuracy of zip codes

PaaS を実行する 1 つの仮想マシンに障害が発生すると、その障害によってシステム・グループ全体が失われることになります。これはつまり、1 つのシステム・グループでコンポーネント A1 に障害が発生すると、他の 2 つのコンポーネント (B1C1) も動作しなくなるということです。サービス・グループが複数ある場合には、システム全体に障害が発生します。

この問題を解決するために、開発者はこれらのコンポーネントを以下のような独立したプールに分割します。

(A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn)

こうすることで、正常に稼働しているデータ・センターにサービスの冗長コピーを複数作成することができます。これはつまり、コンポーネント A1 で障害が発生または処理速度が低下しても、同じ独立プール内にある他のコンポーネント (A2, ... An) に障害が発生するわけではないということです。独立した 2 番目のコンポーネント・プールの B1, B2, ... Bn や 3 番目のコンポーネント・プールの C1, C2, ... Cn も動作を停止しません。

課金アプリケーションの独立サービス・プールすべてに対してフェイルオーバー・プロセスが実行される間、開発者は速度が低下したサービスを短時間でタイムアウトさせてリトライします。速度が低下したサービスや障害が発生したサービスからの応答を待つことで、すべてのリソースを使い切ってしまい、システムがロックすることがないように、開発者はタイムアウトさせてリトライする処理をいつ停止するのかを判断する必要があります。

システムのリストア

次のステップは、システム・ダウンが発生したデータ・センターで PaaS プラットフォームのリストアを開始することです。テスト環境で、プロバイダーは PaaS で使用しているリソースとサービスをランダムに停止します。開発者はさまざまな条件下でアプリケーションをテストし、PaaS のレジリエンシーをテストします。テストが完了すると、プロバイダーはリストアされたシステムのバックアップをとってから、そのシステムを本番環境に移行します。

顧客への通知

リストアされたデータ・センターで PaaS アプリケーションが実行を開始するとすぐに、プロバイダーはリストアされたシステムを利用している PaaS 開発者に通知を行うとともに、SLA の条項が履行されます。


IaaS 固有の付帯条項

このセクションでは、クラウドのフェイルオーバー・ポリシーに付帯する IaaS 固有の条項にどのような要素とタスクを含めるべきかを紹介します。

要素

IaaS は PaaS レベルにとっての基礎であるため、IaaS 固有の付帯条項には別の一連の要素を含める必要があります。ユーザーによる制御、エンタープライズ・ライセンス、フェイルオーバー・プランの他に、仮想マシン用の要素があることがわかります。

IaaS 専門家は仮想マシンを制御しますが、PaaS 開発者と SaaS ユーザーは仮想マシンを制御しません。

エンタープライズ・ライセンスは以下の数値を規定する必要があります。

  • 開発、実行、保守対象の仮想マシンの最大数
  • 仮想マシンに同時にアクセスする IaaS のスペシャリストの最大数
  • IaaS 仮想マシン上で作業する PaaS 開発者の最大数

フェイルオーバー・プランでは、IaaS 仮想マシンをホストするデータ・センターを、障害の発生したデータ・センターから別のデータ・センターにフェイルオーバーできるように規定する必要があります。また、IaaS のインフラストラクチャー・スペシャリストとネットワーク・スペシャリストが PaaS 開発者と協力してフェイルオーバー用の仮想マシンをセットアップできるように規定する必要があります。

タスク

IaaS のスペシャリストが実行可能なタスクは以下のとおりです。

  • 仮想マシンを開発、管理し、仮想マシンにアクセスする。
  • 仮想マシンでアプリケーションを開発できるように PaaS 開発者に許可を与える。
  • サードパーティーのツールを使用してパフォーマンスを向上させたり (例えばロード・バランサーなど)、システムを保護したりする。
  • 仮想マシンの脆弱性スキャンを実行する。

また IaaS のスペシャリストには以下のタスクも許可されています。

  • 仮想マシンのファイアウォールを構成する。
  • セキュリティー・アラートを作成、監視する。
  • 仮想マシンをバックアップする。

仮想マシンが稼働している従来のコンピューティング・インフラストラクチャーにアクセスできるのは、プロバイダーのみです。IaaS のスペシャリストはそうしたインフラストラクチャーにアクセスすることはできません。

以上の内容を説明するために、IaaS で障害が発生したときのシナリオを見てみましょう。


IaaS で障害が発生したときのシナリオ

I/O 処理が多く行われるポイントで必要な追加リソースが不足しているため、仮想マシンに障害が発生します。つまり、正常に稼働しているデータ・センターにフェイルオーバーできるような仮想インスタンスがありません。

プロバイダーは、先を見越して以下のようなアクションを実行することができます。

損害の拡大防止

損害の拡大を防止するために、I/O 処理が多く行われるポイントで仮想マシンを実行するためにどの程度のリソースが必要なのか計画を立てます。この作業は、例えばキャパシティー・プラニングやしきい値ポリシーの作成などを通じて行うことができます (しきい値ポリシーとキャパシティー・プラニングについて詳細に解説した他の記事を「参考文献」セクションに挙げてあります)。

問題の修復

問題を修復するためには、パフォーマンスのしきい値ポリシーを確立します。このポリシーにより、I/O 処理が多い場合に必要な仮想マシンをいつプロビジョニングするのか、またすべてのサービス・アクティベーション・ポイントをどのようにして満たすのかを決定します。データ・センターの仮想マシンには必ずホスト・コントロールを用意します。

また、障害が発生した場合にそれらの障害を素早く検出し、プロバイダーが IaaS ベースの仮想マシン・インスタンスを別のデータ・センターに移せるように計画を立てます。

システムのリストア

次のステップは、システム・ダウンが発生したデータ・センターで IaaS プラットフォームのリストアを開始することです。テスト環境で、プロバイダーは IaaS が稼働しているリソースとサービスをランダムに停止することができます。テストが完了すると、プロバイダーはリストアされたシステムのバックアップをとってから、そのシステムを本番環境に移行します。

顧客への通知

リストアされたデータ・センターで仮想マシンが実行を開始するとすぐに、プロバイダーはそのデータ・センターで仮想マシンのリストアが完了したことを IaaS のスペシャリストに通知します。


まとめ

クラウドに対する効果的なフェイルオーバー・ポリシーを作成するには、以下のことを行うために先を見越したポリシー計画が必要になります。

  • なぜクラウドに障害が発生したかを判断する。
  • 発生した障害を特定する。
  • クラウド固有の付帯条項をポリシーの中に用意し、発生した障害の多様な要因に先を見越して対応する。

開発者、ユーザー、プロバイダーのチームが協力して、ポリシーと付帯条項を作成する必要があります。どんな要素とタスクを含めるかという問題を解決すると、チームにとってポリシーの作成作業が非常に容易になるはずです。

この記事では、SaaS、PaaS、IaaS という各クラウド・コンピューティング・モデルのフェイルオーバー・ポリシーの一部として、考慮が必要な基本的な要素とタスクについて説明しました。また各モデルにおいて、損害の拡大防止、問題の修復、システムのリストア、そしてもちろん、顧客への通知のために、プロバイダーがどのようにするべきかについても提言しました。

他の記事 (「参考文献」を参照) では、目的、スコープ、背景、アクション、制限事項といったポリシーの要素を定義する方法について詳細に説明しています。これらの記事は、しきい値、ワークロード・バランシング、一般的なセキュリティー、モバイル・アクセス、アプリケーションのマイグレーション、サービスのリスク管理、パフォーマンス・メトリクスなどを扱ったクラウド・コンピューティングのポリシーの原案を作成する上で役立ちます。これまでに私が行ったポリシーに関する説明の中で、基礎となる重要要素として必ず挙げてきたものは、信頼性とセキュリティーです。

参考文献

学ぶために

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

  • 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, SOA and web services
ArticleID=812241
ArticleTitle=クラウドのフェイルオーバー・ポリシーを作成する
publish-date=05102012