JDSF | ストレージ管理ソリューション部会 | データ・ストレージに関する総合情報サイト

HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

100%クラウド

オンサイトストレージの全てを、あるいは大部分を
いかにクラウドストレージに置き換えるか

Howard Marks
Storage Magazine 2014年4月号より

クラウドにデータを移行すればコストは安くあがり、拡張は無制限、手間もほとんど掛からない。しかし、実際のところ企業はどの程度までデータをクラウドストレージに置けるのだろう？

とうとうこの日がやってきた。CIOが、お気に入りのアナリスト会社が主催するゴルフコンペつきの年次クラウド会議から戻るやいなや、「当社はアーカイブデータだけでなく、全てのデータをパブリッククラウドストレージに移行する」と宣言したのだ。クラウドこそコンピューターの未来であり、自社のデータセンターにデータを保存する者は、今後数年以内にラッダイト（訳註：技術革新を否定する者）とみなされるだろう、というアナリストの意見に、CIOは心酔している。

クラウドに移行すれば、ベンダーのスケールメリットによって、クラウドストレージを安価に利用できるだけでなく、企業はストレージシステムの購入、使用試験、設置、保守といった雑用から解放される。しかも、クラウドストレージが無限に拡張できるのなら、社内ストレージであれば必要となる、入念な容量管理などの作業もいらない。これでもまだ、納得できないなら、クラウドストレージ・プロバイダーが、我々のデータを保護するために複数のデータセンターにデータをレプリケートしている、と謳っている事をよく考えてもらいたい。

データはいいだろうが、アプリはどうなのか？

クラウドへの移行がどんなものであっても、それがユーザーとアプリケーションにどのような影響を与えるのかを、まず考えなくてはならない。ほとんどの場合、データの大半はクラウドに移行できそうだ。しかし、主要なアプリケーションの多くは、データが社内にないと困るかもしれない。

それでも、データがクラウドにあれば、ローカルキャッシュやデータのコピーを必要に応じて確保し使うことができる。ただし、データのタイプ、およびそのデータにアクセスするアプリケーションの評価は、慎重に行うべきだ。評価のポイントは、データをクラウドに移行する際、どのようなオプションが使えるかという点。さらに個々のオプションが以下の項目にどのような影響を与えるのかを評価しなければならない：

・ユーザーの使い勝手
・データ保護処理
・データにアクセスする場所ごとに必要とされる帯域幅
・（もちろん！）コスト

SaaSへの移行で手っ取り早く成果を上げる

移行が最も簡単なデータは、Software-as-a-Service (SaaS)で置き換え可能なアプリに所属しているデータである。GmailやSalesforce.comなどの名のあるSaaSにおいて、時折サービス停止が発生している事が広く報道されてはいるが、いくつかの社内のアプリをSaaSモデルに移行するのは理にかなっている。例えば、ある会社の社内Exchange基盤が信頼性の問題を抱えており、しかもユーザーは、メールボックスに割り当てられた容量を超えないようにemailを削除することに多大な時間を使い、あまり前向きな仕事ができないでいるとする。この環境を、例えばRackspaceやIntermediaが提供しているホスト型Exchangeに移行するのは、あまり手間をかけずに可能だろう。ユーザーは、10GBまたは100 GBの追加のアーカイブスペース付きメールボックスを手に入れ、さらにはExchange 2010からExchange 2013への高価で連続性のないアップグレードも回避できるかもしれない。

Microsoftやそのパートナー（IntermediaやRackspace）のホスト型Exchange製品に移行すれば、社内のExchangeが実装していたのと全く同じ使い勝手が保障される。ユーザーはクラウドサーバーからデータを取り出すことになるので、多少ネットワークトラフィックが増えるかもしれないが、Exchangeを運用する費用は、プロバイダーが一人当たりに課金する料金、わずか10ドル程ですんでしまう。

同様に、現在使っている顧客関係管理（Customer Relationship Management: CRM）システムをアプリケーションごとごっそり移行してクラウドに置くのも、多くの場合メリットがある。WebベースのCRMアプリは営業部隊やその他のモバイル戦士の仕事をずっと楽にしてくれる。これに対して、社内のCRMはノートPCにアプリケーションをインストールし、本社とVPN接続を張らなければならないのだ。

ファイルの移行

大半の企業において、インストールされたストレージ容量のほとんどは、様々な種類のファイルシステムによって使われている。これらのファイルは通常、専用のNASアプライアンスに保存され、遠隔地では数台のWindowsファイルサーバーに保存される。すべてのファイルをAmazon Simple Storage Service (S3)や他のクラウドストレージ・サービスに移動するだけで、データは効率的にクラウドの中に置かれる。その一方でS3や同様のサービスは、オブジェクトストレージのインターフェース経由でデータを提供するため、ユーザーは基本的にデータにアクセスできなくなる。

この問題に対してはいくつかのソリューションがある。ホステッド（管理型）SharePointを経由してファイルアクセスを可能にするのもその一つだが、この方法だとユーザーは、これまでの仕事のやり方を変えなければならない。

ファイル同期・共有製品とストレージゲートウェイは、より現実的な選択だ。まず、これらの製品の良いところは、基本的に既存のNASシステムを使っているのと、パフォーマンスを含め同じ使い勝手が保たれるという点だ。さらに、ユーザーは、どんな場所からも今までより簡単にかつより多くの種類の共有ファイルにアクセスできる。

ファイルの同期と共有

DropboxやSugarSyncのような消費者向けファイル同期・共有製品は、様々な場所から多様な機器で自分のファイルへのアクセスを必要とするユーザーに、明快なソリューションを提供している。しかし、これらの商用サービスのいくつかは、エンタープライズで必要とされるレベルのデータアクセス・コントロール、セキュリティ、拡張性のツールが不足している。

EMC社Syncplicity、Egnyte、Soonrのようなエンタープライズ向け同期・共有ソリューションや、BoxやDropboxから出ている製品と同様に、企業のアクティブ・ディレクトリと連携し、アクセス・リストを適用し、いつ誰がどのファイルにアクセスしたかを追跡するオーディット・トレール機能を持つことで、エンタープライズの管理問題に対処している。これはとても大きな改善であり、移動中に自分のデータを必要とするヘビーなモバイル・ユーザーや企業の外にいる人々にとっては、これらの製品は非常に便利だが、だからといって大半の企業が同期・共有をひいきにするあまり、従来のファイルサービスを手放すことはありえないだろう。また、ユーザーがクラウドに登録したフォルダー内の全てのファイルを同期するとなると、ネットワークの帯域幅も問題になってくるかもしれない。

クラウド統合ストレージ

クラウドにファイルを移行しても、ユーザーが他の場所からそれらのファイルへのアクセスを続けられる最も良い方法は、それぞれの場所に統合クラウド・ストレージアプライアンスを設置することだ。これらのクラウド・ストレージゲートウェイ製品は、AmazonWeb Services、Avere Systems、Nasuni、Panzura、Twin-Strataなどのベンダーから出ている。半導体ドライブも内蔵できるローカルストレージは、キャッシュとして使われ、Server Message Block (SMB)とNFSの両方、あるいはどちらか片方経由でデータを提供するため、ユーザーはローカルのNASを持つような感覚で自分のデータにアクセスでき、同時にデータの正式なコピーはクラウドに保存される。

これらのゲートウェイは、クラウドプロバイダーが使っているブロックストレージの様式に合わせてマッピングし、多くの場合、同時にデータの重複排除も行ってくれる。そのため、例えばユーザーのホームディレクトリーにごまんとある営業のプレゼンテーション資料の保存がたった1回ですんでしまう場合もある。データはまた、通常は暗号化された後にクラウドに送られる。

また、これらのソリューションのほとんどが、実質的に無限の数のスナップショットを保存するためにクラウドを使っている。このようなスナップショットとクラウドストレージ・プロバイダーによる複数地点へのデータ・レプリケーションの陰に隠れて、従来のバックアップは過去のものになっていくかもしれない。

これらの製品の最も優れているところは、会社の全データがどの地点にあるどのゲートウェイからでも、アクセスできる点だ。同一ファイルを複数のユーザーが同時に修正する際の処理については、ゲートウェイ製品ごとに出来具合は異なるものの、どの製品も複数拠点間の共有ファイルアクセスの仕組みは従来のNASアプライアンスより優れている。

データベースをどう扱うか

最大の難問は、データベース・アプリケーションサービスを提供してくれるソリューションを見つけ出すことだ。Amazon's Elastic Block Store(EBS)にアクセスしてAmazon Elastic Compute Cloud(EC2)のインスタンスでMicrosoft SQL ServerやOracleを稼動させるのは可能かもしれない。しかし、ユーザーのPC上で稼動しているアプリケーションとデータベース・サーバーに20msから200msのレイテンシが加わることによって、パフォーマンスや使い勝手に悪い影響が出そうだ。

あなたが大型のRISCサーバーと全半導体ストレージを必要とする巨大なOracleデータベースのようなものを持っていないとすれば、データベース・アプリケーション用のクラウド型ソリューションという選択肢がある。仮想Windowsや仮想Linuxマシン上で稼動しているデータベースにとっては、ファイルストレージがクラウド・ストレージゲートウェイ経由で供給されることも可能だ。最大の違いは、ゲートウェイのリソースにアクセスするためにSMBの替わりにiSCSIを使う点だ。もうひとつの違いは、ゲートウェイの使い方だ。ゲートウェイのローカルストレージをキャッシュとして使わずに、データベースが配置されているボリューム全体をそのローカルストレージに固定してしまうのだ。この方法には2つの大きな利点がある。ひとつは、この方法でパフォーマンスが改善されることだ。クラウド・ゲートウェイ上でキャッシュミスが1回発生すると、レイテンシが20msから200ms増加する。数回キャッシュミスが起こると、大きなパフォーマンス低下につながる。

ゲートウェイのローカルストレージへのボリューム固定のもうひとつの利点は、リモートサイトとクラウドストレージ・プロバイダー間のインターネット通信が落ちても、アプリケーションは稼動し続ける点だ。大半の拠点では、信頼性が高く高帯域幅のインターネット接続を備えているか、備えようとすれば可能だとしても、営業所や遠隔地にとっては、質の良い接続は高嶺の花か、単に入手不可能だったりする。

データ保護のために、ゲートウェイは定期的にデータベースのボリュームのスナップショットを取り、クラウドプロバイダーに送信する。災害時にはEC2または他のクラウドコンピューティング・プロバイダーに仮想バージョンのゲートウェイを立て、スナップショットからアプリをマウントすることができる。

真の100%クラウドとまではいかないかもしれないが

会社の全てのデータをクラウドストレージ・サービスに移行するのは、現時点ではやや非現実的だ。しかし、全データのコピーをクラウドに移行するツールであれば、現在でも入手可能だ。アプリケーションの中にはEmailのように、いたって簡単にクラウドに移行できるものもある。また、それ以外のアプリケーションの中にも、同等の機能を提供するクラウドベースのアプリと置き換えることができるものもある。このどちらの方式も、データを社内からクラウドの中へと移してくれる。その他のアプリケーションで、クラウドによって発生するレイテンシによって悪影響が出てしまうものは、データはパフォーマンス優先でローカルに保存し、最終的にクラウドに収まるハイブリッド方式がベストかも知れない。

Howard Marksは、DeepStorage LLC.の創立者兼主任研究員である。
SearchStorage.comや他サイトに連載コーナーを持ち、TechTargetセミナーや他の会議の常連講師でもある。