企業にとって、クラウドの活用はもはや避けて通れないテーマになっていますが、いまだその活用方法やリスク回避について、明確な指針を持つには至らない状況にある場合も多いのではないでしょうか。
本稿では、クラウドの高可用性と災害復旧について、アプリケーションとデータの保護に関するよくある誤解を紐解くことで、クラウド環境ならではの注意点を考えてみたいと思います。
重要なアプリケーションがクラウドに移行する
企業が、アプリケーションのクラウド移行をより一層進めつつあることは、すでに周知の事実です。2016年までの新しいIT支出の大部分が、クラウドコンピューティングの基盤とアプリケーションを対象とし、大企業の半分近くが2017年の終わりまでにクラウド展開を行うとGartnerは予測しています。1
クラウドの恩恵は、短時間のダウンタイムを許容できるアプリケーションには明確かもしれませんが、高可用性と災害復旧保護を必要とするSQLサーバー、OracleやSAPのようなビジネスに不可欠なアプリケーションには、そこまで明確ではありません。
クラウド活用における高可用性と災害復旧の事実と神話を判別することが、経費の節約と、ダウンタイムとデータ損失のリスクを減らすことにつながります。
クラウド環境にアプリケーションを移行する利点は、最近の
“disruptive technologies”（破壊的技術）
に関するマッキンゼーの報告書で要約されています。
「クラウド技術は、グローバル企業のIT支出の3兆ドル市場において生産性を改善するだけでなく、数十億の消費者や数百万の企業向けに、新しいオンライン製品、サービスの創造を可能にする可能性を秘めいている。」2
神話１ 「クラウドは災害復旧環境である」
神話： （特に主要なクラウドプロバイダーが提供する）パブリッククラウド環境なら、それ自体が高可用性環境になっており、アプリケーションのダウンタイムはごくわずかである。
真実： ユーザーが自分で高可用性の保護機能を追加しない限り、クラウドは高可用性環境ではありません。実際に、最近の研究によれば
2013年のクラウドの停止4
|
「クラウドサービスの平均的な利用不能時間は、年間10時間以上であり、平均の利用可能時間は99.9%（9時間または1日以上のダウンタイム）と推定されている。これはビジネスに不可欠なアプリケーションが期待される可用性には全く及んでいない。」3
つまり、冗長性は十分ではないのです。
Microsoft Azureのような一部のクラウドソリューションは、冗長性を通してアプリケーションの保護手段を提供しています。また、IISのようなウェブサーバーに関しては、異なる障害ドメインにそれらを配置し、ロードバランシングを使って、いくらか可用性の保護機能を追加できます。それでも、SQL Serverおよびファイルサーバーのようなアプリケーションに対しては、高可用性および災害復旧のために、さらに追加の構成が必要になります。
神話２ 「クラウドでは、クラスタリングによる保護はできない」
神話： パブリックまたはプライベートクラウド上では、クラスター環境を構成することができず、ビジネスに不可欠なアプリケーションを保護することはできない。
真実： 物理環境で高可用性を実現するには、一般的にはWindows Server Failover Clustering（WSFC）とSANに代表される共有ストレージを使用します。しかし、Amazon EC2およびMicrosoft Azureのようなパブリッククラウドには、クラスター対応（cluster-aware）共有ストレージの概念はなく、通常は共有ストレージを設定すること自体ができません。
でも、サイオスの”SANLess Clusters”ソフトウェアを使えば、WSFC構成を設定し、クラウドでWindowsアプリケーションに対する高可用性保護を実現できます。
SANLess Clustersソフトウェアは、リアルタイム、ブロックレベルレプリケーションでクラウド内のローカルストレージを常に同期しますので、フェールオーバー発生時にも、アプリケーションは最新データにアクセスできます。つまりWindows環境でSQL、Oracle、SAP、その他のビジネス上重要不可欠なアプリケーションをダウンタイムやデータの消失から守るための、簡単で費用効率が良い方法なのです。
神話３ 「災害復旧のために遠隔地レプリケーションは必要ない」
神話: アプリケーションとそのデータは、クラウドであれば追加の構成なしで、災害から保護される。
真実: クラウドプロバイダーも他の大規模な組織と同様に、ダウンタイムや地域災害を経験しています。クラウド内での高可用性の提供により、アベイラビリティゾーン（Amazon）または障害ドメイン（Azure）内で起こる通常のハードウェア障害やその他の予想外の機能停止からは保護されますが、それでも地域災害に対する保護は必要です。
最も簡単な解決方法は、地理的に分離されたマルチサイト・クラスターを設定することです。まずクラウド内に ”SANLess Clusters”でクラスターを構築し、代替のデータセンターまたは異なる地域に追加のノードを加えることで、それを拡張します。単に第三の地理的に分離されたノードを” SANLess Clusters”に追加することで、ほぼゼロに近いデータ損失の目標復旧時点（RPO）と、わずか1分間の目標復旧時間（RTO）を実現できるのです。
神話４ 「クラウドの利用は『総取りか無しか』の決断だ」
神話: アプリケーション運用は、クラウドまたはオンプレミス（社内運用）のデータセンターのいずれか片方しか選べない。
真実: オンプレミスのデータセンターをプライマリ・データセンターとして、クラウド環境をホットスタンバイの災害復旧サイトとして使用できます。これは、自社所有の災害復旧サイトの増築や事業継続施設にラックスペースを借りたりするより、かなりコスト・パフォーマンスの良い代案です。
この場合、オンプレミスのサーバーは、従来の共有ストレージ（SAN）ベースのクラスターをそのまま利用できますし、 ”SANLess Clusters”でクラスターを組むことも、現在クラスターに加わっていない単一サーバーにすることもできます。
神話 ５ 「クラウド環境の高可用性は費用がかかり複雑だ」
神話: クラウド環境に高可用性環境を作成するには、複雑なスクリプト記述や特殊な技能が必要で、さらなる複雑性がある。
真実: サイオスの”SANLess Clusters”ソフトウェアなら、簡単な3ステップで、クラウド内に高可用性クラスターを組むことができます。直観的な設定インタフェースが提供されているので、特殊なスキルがなくても、数分でクラウド環境に標準のWSFCを作成可能です。
また、高可用性と災害保護機能を追加するために、高価なエンタープライズ版のWindowsアプリケーションを購入することをやめたり、神話4で説明したように、わざわざ遠隔復旧サイトを構築することをやめたりすることも可能になります。
さらに、（よりコストがかかるEnterprise Editionの代わりに）SQL Server Standard EditionをDataKeeper Cluster Editionと一緒に使えば、費用効率の良い災害保護を実現する、第3のノードをクラウド外に複製できます。
出典
1“Gartner Says Cloud Computing Will Become the Bulk of New IT Spend by 2016.”
http://www.gartner.com/newsroom/id/2613015
2 Manyika, James and Michael Chui, et al, “Disruptive technologies: Advances that will transform life, business, and the global economy,”
McKinsey Global Institute (May 2013) http://www.mckinsey.com/insights/business_technology/disruptive_technologies
3Whittaker, Josh, “Amazon Web Services Suffers Outage, Takes Out Vine, Instagram, Others with it,” ZDNet,
(August 26, 2013) http://www.zdnet.com/amazon-web-services-suffers-outage-takes-down-vine-instagram-flipboard-with-it-7000019842/
4Mackay, Martin, “Downtime Report: Top Ten Outages in 2013,” Business2Community.com, (December 2013)
http://www.business2community.com/tech-gadgets/downtime-report-top-ten-outages-2013-0720582#Z2xCkBHqs5SrECkO.99
