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

プライベートクラウド、パブリッククラウドとの接続戦略を策定する

社内のストレージ基盤とプライベートクラウドを、パブリッククラウドのコンピュートやストレージと繋ぐ場合のコツを学ぼう

Storage Magazine 2019年4月号より
George Crump

パブリッククラウドとプライベートクラウドは、もはやほとんどの企業にとって、どちらか一方を選んでおけばすむ選択肢ではなくなった。それに替わって、ハイブリッドクラウドが現在の最も優れたクラウドの使い方だと考えられるようになった。企業はまた、使用するパブリッククラウドが柔軟に選択でき、クラウド間を自由に移動できる機能を求めている。しかし、プライベートクラウドからパブリッククラウドへの接続は、まだ一筋縄ではいかない。

レイテンシ、帯域、クラウド内パフォーマンスは全て、クラウドの中にどのようなデータが置かれ、どのようにアクセスされるかを決めるうえで関わってくる要素だ。だから、ITプロフェッショナルは、企業のニーズを全て満たす完璧なクラウドアプリケーションを探すのではなく、特定のクラウドストレージの使用事例を探すべきだろう。

最も一般的な環境下で、社内のストレージ基盤とプライベートクラウドを複数のクラウドと接続する際の最も効果的な戦略を、この記事を読んで見つけてもらいたい。シナリオとして書かれているのは、クラウド・バースティング、プライマリコンピュートおよびストレージとしてのクラウド、バックアップとディザスタ・リカバリのターゲットとしてのクラウド、データアーカイブとしてのクラウド、である。

クラウド・バースティング

ほとんどの企業は、ピーク時の要求が自社のリソース（ストレージとコンピューティング）に出された最悪のケースを想定して、データセンターを構築している。要求のピークから次のピークまでの間は、大半のリソースは使用されない。ピーク間の遊び状態を無くすようなワークロードが追加されたり、現在のシステム規模がデータセンターの能力の限界に近づいたりした時、企業は一般的に自社のリソースに対して追加投資の予算を計上する。クラウド・バースティングの目的は、常に要求カーブに先回りしなければならず且つ費用のかかる、このサイクルを打破することになる。

確固たるクラウドバースティング戦略があれば、企業はピーク時ではなく平常時を対象として自社のデータセンターを設計できる。要求が現状のデータセンター・リソースを超えたときは、あらかじめ決めておいたアプリケーションやワークロードをクラウドで動かせばよい。

クラウド・バースティングを使った接続がうまくいくかどうかは、次の二点にかかっている。事前計画が十分に行われているか、およびワークロードをクラウドに移行する必要が出る前に、十分な量の通知が企業に届くかどうか、である。事前計画を正しく行えば、多くの場合、標準的な企業向けのインターネット接続があれば十分だ。事前計画では、ピーク時が来る前にデータをクラウドにレプリケートしておく必要がある。レプリケーションは、クラウドのコピーとオンプレミスのコピーの同期のずれが数分以内に収まるように、常時継続する必要がある。先行コピーによるこのアプローチは、ディザスタ・リカバリのためにも価値がある。基幹アプリケーションが事前にクラウドにおかれるからだ。先行コピーの欠点は、バーストを起こす可能性のあるデータをクラウドストレージのリソースとして常駐させるため、費用が嵩む点だ。

企業がもっと動的にワークロードをクラウドに移動したいのであれば、これまでよりずっと高速な接続に投資しなければならないだろう。動的アプローチは追加のクラウドリソースを必要とせず、ピーク要求が発生した直後に、ワークロードを選択してクラウドに移動できるメリットがある。また、一般的なファイル転送ユーティリティよりも、さらに最適化した方法でデータを移動する機能を備えたアプリケーションも存在する。

プライマリストレージとしてのクラウド

将来ブレークする可能性を秘めており、最も面白い（同時に、最も困難な課題を抱えた）クラウドの使い方は、クラウドをプライマリストレージまたはプライマリコンピュートとして使うことだ。クラウドをプライマリストレージとして使うには、レイテンシ問題を解決する必要がある。接続についての懸念事項が、大抵は帯域問題であるクラウドバックアップ＆リカバリと違って、プライマリストレージは一般的にトランザクション処理に使われるため、レイテンシが主要な懸念事項となる。

主なクラウドのプライマリストレージとしての使われ方は、NAS（Network Attached Storage）である。この分野のベンダーが重点的に取り組んでいるのは、最もアクティブなデータを、オンプレミスのアプライアンスやエッジデバイスに自動的にコピーすることができる、クラウドベースのファイルシステムだ。オンプレミスのユーザーがアプライアンスやエッジデバイスのデータを変更・修正した場合、クラウド側のコピーが更新される。そのユーザーが、ローカルのエッジデバイスに存在しないファイルにアクセスした場合、そのファイルはクラウドから取り出される。ファイルが大きくない限りたいてい、取り出し時間はほとんど気づかないほど短い。

データが効率的に一か所にまとまっているので、企業はこれらのエッジアプライアンスを、自社の全てのデータセンターや遠隔オフィスに簡単に置くことができる。この分野のベンダー数社は、グローバル・ファイルロック機能も付けている。あるファイルが１か所で使われている場合、そのファイルにアクセスした他のユーザーは、すべてのロケーションで読み取り専用の通知を見ることになる。

これらのシステムのうちのいくつかは、マルチクラウド使用をサポートしている。ボリュームが作成されたとき、管理者はそれを特定のクラウドアカウントに接続できる。プロバイダー間でデータを移動するには、ボリュームを丸ごと他のボリュームにコピーすることが必要であり、全データがオンプレミスのアプライアンスをいったん経由してコピー先に移動することになる。

プライマリ・ブロックストレージのクラウドインスタンスはファイルストレージよりさらにハードルが高い。第一に、アプリケーションはデータを待っているユーザーのように辛抱強くない。一定のレベル以上に素早くデータにアクセスできないと、アプリケーションはタイムアウトあるいはクラッシュしてしまうだろう。これまでは、アプリケーションの安定性を確保する唯一の方法は、データの不存在が起きる可能性を極小化するために、オンプレミスのアプライアンス容量を充分に大きくすることだった。問題は、この方法ではコストの節約が図れないことだ。

この問題を解決するには、二つの方法がある。一つ目は、現在多くのクラウドプロバイダーが持っているダイレクトコネクトのオプションを使って、標準的な企業のストレージシステムを直接クラウドコンピューティング・リソースに接続する方法である。ベンダーは、高速接続を可能にするため、パブリッククラウド・プロバイダーに隣接したロケーションにあるホスティングプロバイダーと協業するケースが多いようだ。このタイプのシナリオでは、クラウドは主にコンピュートリソースとして使われ、従来型のストレージシステムは、データ保存用に使われる。バックアップ・アプリケーションを使って、この従来型ストレージシステムをバックアップし、そのバックアップデータをクラウドストレージに保存することもできる。接続が高速で至近であるため、ここでもバックアップはかなり速く行われる。

マルチクラウドがデータ転送を容易にする

複数のパブリッククラウド・プロバイダーに対するダイレクトアクセスを持っているマネージド・ホスティング施設が数社ある。これらの施設は、物理的、地理的にパブリッククラウド・プロバイダーのデータセンターのごく近くにあり、クラウドプロバイダーの計算リソースは、自身のデータセンターのストレージと同様のレイテンシでその施設のストレージにアクセスできるほどだ。データは「静止」しているので、移行の手間は必要ない。企業がもっと能力が高く安価な計算機能にアクセスするために、他のプロバイダーを使いたくなったら、IT部門は簡単にプロバイダー間を移動できる。

二つ目は、クラウドにデータを保存する前にデータをセカンダリ・ティアに移す方法だ。このマルチティア方式により、企業はアクティブデータ用に、比較的小さなフラッシュベースのキャッシュをオンプレミスに置けばよいことになる。ウォームと判別されたデータは、地理的に近い場所にあるセカンダリプロバイダーに保存される。データが非常にコールドになった場合、データはクラウドにのみ保存される。その結果、ウォームデータは、わずか数ミリ秒離れたところで、アプリケーションの実行を妨げない状態を保ちつつ、オンプレミスのキャッシュのサイズは、日々のアクティブデータの容量と等しくなる。作成または修正されたデータは全てクラウドにレプリケートされるが、レプリケーションは非同期であるため、本番のパフォーマンスには影響を与えない。このクラウドのコピーは、ディザスタ・リカバリ用のコピーとして使える。これはまた、古くなってプライマリ、セカンダリのティアから出されたデータは、実際はコピーする必要がない、ということも意味している。これらのデータは、すでにクラウドティアにあるため、プライマリ、セカンダリのティアからは削除される。

マルチティアによるプライマリ・クラウドストレージ戦略は、一般的に複数のクラウドをサポートしている。しかし、データは最終的に単一のクラウドのセンター・レポジトリに保存されるため、プロバイダー間の移動はクラウドを移行するのと同じ手間がかかる。オンプレミスにアプライアンスを置く戦略も、複数クラウドを指定できる。しかし、データは、新規のプロバイダーに送られる前に、ほぼ確実に一旦（なんと！）オンプレミスに戻されることになっているのだ。

クラウドバックアップ＆リカバリ

オンプレミスのストレージ基盤とパブリッククラウドを接続した使い方のなかで、最も普及し、クラウド入門ともいえるのが、データバックアップ＆リカバリである。圧縮、重複排除、ブロックレベル・インクリメンタルバックアップのような技術のおかげで、オンプレミスのバックアップ・ストレージシステムとパブリッククラウド・ストレージの間はそれ程高速な接続を必要としなくなった。一般的に、企業向け基本コースの接続で充分だ。

オンプレミスのバックアップストレージの取り扱いは、各社まちまちだ。レガシーのバックアップベンダーは、多くの場合オンプレミスのストレージをプライマリ・バックアップコピー、クラウドコピーをディザスタ・リカバリ専用として考えている。クラウドは、テープの代替として考えられているのだ。最近のバックアップソフトウェアは、パブリッククラウド・ストレージをもっと機能的な資産としてとらえている。オンプレミスのデバイスはキャッシュまたはティアとしてサービスを提供し、古いバックアップデータはアクセスされた時間に基づいて自動的にパブリッククラウド・ティアに移動される。キャッシュ・ティア方式の長所は、オンプレミスへの投資が比較的少額で済むことと、滅多にアップグレードする必要がないことだ。

圧縮、重複排除、ブロックレベル・インクリメンタルバックアップによって、バックアップ処理が要求する帯域は下がったが、バックアップベンダーがリストアの問題をDRaaS（Disaster Recovery as a Service）を利用して解決したのはつい最近のことだ。DRaaSは、アプリケーションのリカバリをクラウドの仮想マシンとして可能にし、一時的にオンプレミスのデータセンターとの接続速度についての懸念を取り払ってくれる。災害発生時には、すべてのデータ移動はクラウドデータセンター内に限られ、インターネット接続を必要としない。ソフトウェアがどのようにクラウドリソースを使うかによって時間の長さは変わってくるが、アプリケーションは災害が宣言されて４時間以内に運用を再開できる。

IT部門がアプリケーションをオンプレミスに戻そうとしたとき、クラウドプロバイダーがデータをバルクで送る機能を持っていない限り、インターネット帯域が懸念されることになる。多くのDRaaSツールが、バックグラウンドでデータをオンプレミスに戻せるが、低帯域の接続でそれを行えば、数週間とは言わないまでも数日はかかってしまう。残念ながら、重複排除とブロックレベル・インクリメンタルバックアップ技術は、リカバリ速度向上には役立たない。

データがクラウドに入ってしまったバックアップデータをどうする？

企業がバックアップしてクラウドにしまったデータを、リカバリ要求が舞い込んできて取り出さなければならない、というのはよくあるケースだろう。他には、クラウドにしまったデータを、クラウドの計算リソースを使って何かしたい、というケースがあるかも知れない。例えば、DRaaSがクラウドストレージだけでなくクラウドの計算リソースを使うので、企業はクラウドのコピーデータをテストや開発、レポート作成や分析に使いたいと思うかも知れない。ここで問題になってくるのは、バックアップのアプリケーションが独自フォーマットでデータを保存しているために、クラウドの計算リソースでは直接そのデータを読めないということだ。つまり、IT部門は、まずデータを戻してフォーマットをネイティブな状態にする必要がある。戻しの時間が膨大にかかるのであれば、ネイティブフォーマットでデータを保存するバックアップ・アプリケーションを探してみることをお勧めする。

古いデータをアーカイブする

クラウドアーカイブは、一般的にネットワーク帯域の変更が不要で、かつ相当な投資対効果を提供するため、実際的に最高のクラウドストレージの使い方と言えるかも知れない。アーカイブ製品は、オンプレミスの本番用ストレージを解析して、ユーザー定義の期間（一般的には１年以上）アクセスされなかったデータを探し出す。これらのファイルは次に、テラバイト単価がより安いセカンダリストレージへと移動される。

従来型のアーカイブ製品の問題は、セカンダリストレージシステムに対して相当な先行投資（一般的に50TB以上）が必要なことだ。ほとんどの会社では、アーカイブに回せる50TBの容量などすぐに出てこない。万が一出てきたとしても、おいそれと渡したくはないだろう。クラウドアーカイブは、徐々にデータをアーカイブすることで（必要ならGBベースで）この問題を解決する。

漸進的（ゆっくり型）アプローチをとることで、より低速な帯域での接続も可能になる。その定義通り、アーカイブはほとんどアクセスされない。そのため、このシナリオでは他のクラウドストレージの使い方のような、データ取り出しに伴う帯域への懸念がない。懸念が出る領域はメタデータだ。ほとんどのストレージI/Oはメタデータに関連している。例えば、ユーザーがクラウドアーカイブ・ディレクトリのリストを出力したいと思ったら、ブロードバンド接続越しに全てのメタデータを送らなければならない。これは時間がかかる。この問題を回避するため、一部のベンダーはローカルとクラウドにメタデータを保存するようにしている。これにより、クエリはローカルのメタデータコピーにアクセスし、ユーザーは迅速なレスポンスを体感する。

ほとんどのクラウドアーカイブ製品がデータを複数クラウドに送信できる。さらに、いくつかの製品は複数クラウドの同時使用もサポートしている。プロバイダーを変更することに伴う難しい問題は、一つのクラウドのロケーションから別なところへデータを移動する費用と時間である。とくに、アーカイブの場合は、これは膨大な量の情報の移動を意味する。

クラウドのレンタル費用が、オンプレミスでオブジェクトストレージを購入するより高くつくという理由から、企業がクラウドからアーカイブを取り出して古いデータをオンプレミスに保存しようとしたときも、同様の問題が出てくる。以前クラウドにアーカイブしたデータをオンプレミスに戻すのは、時間がかかり且つネットワークとクラウド退出費用のために高くつく。

あなたの会社のプライベートクラウドをパブリッククラウドにつなぐのは、かつてない程簡単になった。オンプレミスのストレージとパブリッククラウドのストレージが上手く連携する、クラウドストレージの使い方は様々なものがある。パブリッククラウドに入れ替えてしまうのが良いケースもあるかも知れない。企業は計画を立て徐々に、おそらくは段階的にそれを実行していく必要がある。まずは、特定の使い方に焦点を絞り、それが上手くいき、そのクラウドの地位が固まった時点で、他の使い方に移っていくのが賢いアプローチだろう。

著者略歴：George Crumpは、ストレージと仮想化を専門とするITアナリスト企業Storage Switzerlandの社長である。