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

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

アーカイブはクラウドストレージにとって「キラー・アプリ」と言われるが、あなたのデータをイーサネットで送信する前に検討すべきいくつかの問題がある。

パブリッククラウド・ストレージの最も優れた機能のひとつは、大量のデータをストレージ基盤に置いてその管理に悩まされることなく、簡単に保存できる機能であった。ほとんどの企業では幾何級数的にデータが増え続けており、データの増加と基盤のリフレッシュに取り組みながら行わなければならないストレージの管理は、ややもすれば無秩序で退屈な仕事になりがちだ。基盤を管理する単調な仕事から開放されたいと思っているIT部門にとって、クラウドストレージは救いの神となって、データそのものに集中できるようになるかも知れない。しかし、クラウドアーカイブは本当に他の方法では得られない優れたサービスなのだろうか、またクラウドアーカイブから得られる恩恵よりもそれに掛ける労力の方が大きいなどということはないのだろうか？

なぜアーカイブすべきなのか

クラウドベースのアーカイブの技術的な特徴を見ていく前に、そもそも何故データをアーカイブする必要があるのかを論じるのは無駄ではないだろう。最も明白な理由はコストだ。本番のシステム(データベース、ファイル、非構造化データ)のなかには、不活発で滅多にアクセスされないデータが大量に含まれている。これら全てが高価なプライマリ・ストレージに常駐しているのだ。企業は、データの中身が将来価値を持つかもしれない、という想定に基づいて、データを「永遠に」というか、少なくとも非常に長い期間保管しようとしている。いくつかのケースでは、規則により強制的にデータを長期間（数十年）保持しなければならない。医療記録のデータの場合、最低でも患者が生きている間はデータを保持しなければならない。データを本番環境から移行することは、生産コスト削減に良い意味で大きな影響を与えるかも知れない。例えば、データベースのライセンス節約や、データ容量でライセンスが課金されている仮想マシンあるいは物理ホストの規模縮小化などが考えられるだろう。

大量のデータをプライマリ・システムに保存することは、運用上でも次のような側面がある。システムが大きくなればなるほど、バックアップや戻し・復旧処理の時間が長くなる。さらにバックアップデータも大きくなる。決して変更がかからないデータを、プライマリ・システムからアーカイブに移して、保存、保護できる方法が別にあるのなら、それを毎回バックアップするメリットはどこにもない。本番システムのパフォーマンスにも影響は出る。例えば、1億行のデータベースにあるデータにアクセスしたり保存したりするのは、50万行のデータベースにそれを行うのに比べて、はるかにオーバーヘッドが大きい。

何故クラウドアーカイブを検討すべきなのか

アーカイブの必要性ははっきり理解できただろう。では、クラウドをデータの送り先として選択するのは何故なのか。クラウドサービスを使う事によって得られるクラウドならではの運用上のメリットがいくつかあり、これによってクラウドはデータの送り先として魅力的なものになっている。そのメリットを以下に挙げる。

■ 弾力性

クラウドストレージ・プロバイダーは、アーカイブの容量が常に足りているかを確認する責任とそれに伴う煩わしさを引き受けてくれる。ユーザーは、容量は無限に使えるという前提で、リソースを消費すれば良いだけだ。データセンターのスペース、電力、冷却、その他物理的な事項を考える必要はない。

■ 抽象化

ユーザーはデータがどのように保存されるかを知ることも気にすることもない。クラウド・プロバイダーが契約したサービスレベルでサービスが提供されていることだけを知っていればよい。このことは、データはディスク、テープ、光ディスク、あるいはこれらの組み合わせのいずれかで保存されていることを意味する。ストレージメディアやそれに関連する基盤を管理し、長い期間の中で技術が陳腐化し置き換えが必要になれば、リフレッシュする責任は、クラウド・プロバイダーが引き受けてくれる。

■ 耐久性

プライマリ・ストレージの復元力は、可用性即ちシステムがどれだけのアップタイム(使用可能時間)を提供したかで測られる。よく見るのは5個、6個、あるいはこの頃は7個の9だ。これはアップタイムが99.999%以上であることを意味している。アーカイブの世界では、測定は耐久性がベースとなり可用性のレベルはプライマリ・ストレージより低くなる。データがアクセスされる頻度は少ないが、5年、10年、20年、50年の間存在し続ける必要があるというのが前提になっている。例えば、Amazon Web Servicesの S3サービスは99.999999999%即ち「11個の9」の耐久性を謳っている。

■ コスト

クラウドストレージのコストは予測可能であり、アクセスプロファイルと保存されたデータの大きさ（これについては後述）に基づいているため、課金や会計処理が簡単だ。

かくして、クラウドアーカイブは利用価値があることが分かった。問題はIT運用チームがいかに運用の要求に合った形でデータを出し入れするか、という点だ。

クラウドアーカイブの留意点

クラウドアーカイブにおいて、最大の懸念はおそらくセキュリティに関するものだろう。私のデータは、ネットワークを通過するときも、サービスプロバイダーのデータセンターに到着して保存されるときも、どのように保護されているのだろうか？　ネットワーク通過中の問題は簡単に解決する。クラウドアーカイブへのデータの出し入れは信頼性の高いHTTPSプロトコル（SSL）で管理されるからだ。そのため、データは公衆回線を通過しているときでも安全だ。

今ではほとんどのプロバイダーが自社のクラウド内に保存するデータを暗号化する機能を提供している。セキュリティ・レベルのオプションとして、プロバイダーがユーザーの代わりに、ユーザー独自の暗号化キーを使うサービスもある。

別なやり方として、データをクラウドに送る前に暗号化してしまう方法もある。暗号化オプションの選択は、ユーザーのリスク特性によって決定される。プロバイダーが提供する暗号化で充分かもしれないが、コンプライアンス・ルールがある場合やセキュリティに異常にうるさい人がいる場合はパーソナル暗号化キーを使うことになるかもしれない。
その場合、ユーザーは将来のデータ戻しのためにキーを保管しなければならない。もしデータを長期間保存するのであれば、これには相当な手間がかかる。

セキュリティの次に検討しなければならない項目は、パフォーマンスだ。つまり、どれだけ早くデータをクラウドに保存し、また取り出せるか、ということだ。接続形態によってまちまちだが、クラウドにデータを書き込むときのレイテンシ、即ちラウンドトリップ・タイムは、最大で20～30ミリ秒になることがある。データを順繰りに伝送するのであれば、この応答時間でも構わないが、「ランダム」アクセスには決して理想的な数字とは言えない。実際のところ、ほとんどのアーカイブ処理において、大容量のデータの保存と取り出しを行う分には、レイテンシは問題とならないだろう。だが、メタデータがクラウドベースで更新されていると、問題になる可能性がある。

上記のほかに、データアクセスのパフォーマンスに影響を与える項目が二つある。一番目は、プロバイダー自身がアクセス制限をかけるということだ。たとえば、Amazon Web Servicesの GlacierはS3 (Simple Storage Service)の廉価版サービスだが、データを取り出すために行われるステージング処理に3時間から5時間かかり、取り出したデータは24時間まで使うことができる。（それ以降は、再びデータを取り出さなければならない。）またGlacierでは、データのアクセスは１GBまでは無料だが、それ以上は伝送コストがかかる。これについては後述する。すべてのベンダーが、データアクセスについてパフォーマンス制限をかけているわけではない。
例えば、Google Cloud Storage Nearlineは長期間アーカイブされているデータへの応答時間（そのデータの1バイト目へのアクセス）を約3秒で提供している。サービスの適正価格とサービスのパフォーマンスの間には明らかにトレードオフが存在する、

クラウドを使う時のもう一つの懸念事項が、アクセス性とデータのフォーマットだ。アーカイブのプラットフォームは、一般的にオブジェクト・ストアであり、Webベースのプロトコルでアクセスするようになっている。
しかし、社内にあるデータは、（データベースのように）構造型データの形だったり、（emailのように）準構造型データだったり、（ファイルのように）非構造型のデータだったりする。これら各データフォーマットは、データの内容を記述するのに使われているメタデータに紐づけられている。では、このデータはどのように一般的なオブジェクト・フォーマットに変換されるのだろうか？一つの答えは、ゲートウェイまたはアーカイブ・プラットフォームとして働き、ローカルとアーカイブフォーマット間のブリッジ機能を提供する製品を使うことだ。例として、AWS Storage Gateway、EMC CloudBoost、Microsoft Azure’s StorSimple、Nasuni Cloud NAS、NetAppの AltaVaultなどがある。これらの製品のほとんどは、クラウドストレージへのパイプとして機能し、特定のアプリケーションと直接連携する機能は持っていない。とはいえ、これらの製品は、アーカイブデータ用により一般的なプロトコルを提供している。また、コンテンツの一部をキャッシュしておき、データをアクセスする時に、いちいちクラウドストレージにデータを取りに行かなければならない手間を軽減する機能も備えている。それでも、アプリケーションとの連携作業は必要になるかも知れないが、基本的にはデータが社内にあるか社外にあるかというところがポイントになるだろう。

最後に、コストのことを考えなければならない。社内のアーカイブシステムのコストは、一般的に基盤そのものに基づいているのに対し、クラウドベースのアーカイブは、保存しているデータの量とアクセスプロファイルによって決まってくる。アーカイブに保存するデータとそこから取り出すデータが増えれば、月々のコストも増える。IT部門はこのコストを（適切と思われる）エンドユーザーに課金する用意をしなければならない。これは以下のことを意味する。データの保存と取り出しについてのポリシーの作成。それと同時にアーカイブを（保管庫のような）論理的リポジトリに分割して個別にレポートできるようにする事だ。大容量のデータを単一のプロバイダーに置いている所では、クラウドストレージの使用が現実的な問題になる可能性がある。データを複数のアーカイブ（およびプロバイダー）間で移動するのは、冗長性とリスク低減の観点からみれば望ましいが、これには途方もないコストがかかるからだ。

コストを減らす方法のひとつとして、重複排除や圧縮などのデータ縮小技術の実装を検討してみるのも良いかもしれない。これらの技術はデータがアーカイブされる前にアプリケーションに実装するか、クラウドゲートウェイに展開して置くことができる。このような製品がStorReduceという製品名で会社名もそれと同じ新興企業から出ている。StorReduceアプライアンスは、パブリッククラウドの中に置かれ、データをS3フォーマットで受け取る。データは重複排除したフォーマットでAWS S3に書き戻す。この会社は、最大で95％保存データを縮小することにより、巨大アーカイブの大幅なコスト低減を実現する、と謳っている。

クラウドアーカイブ：福音？それとも呪い？

アーカイブはクラウドだけで動くアプリケーションで処理できる。それにはここで挙げたいくつかの項目についての検討が必要だ。セキュリティ、パフォーマンス、アクセス性、コスト、である。クラウドがアーカイブデータを置くのに最適な場所かどうかを決める際、オブジェクトストレージ互換フォーマットにデータを変換する機能を、社内システムに実装する必要がある。これに対して、社内の課金システムがどこまで柔軟性を持てるか管理面からこの問題を検討しなければならない。

最後に検討しなければならないポイントは、将来どのようにアーカイブデータがアクセスされるか、という点だ。クラウドの中にすでにデータがあれば、そのアーカイブに対してクラウドベースの解析ができる。仮想インスタンスとして稼働するクラウドベースのアプリケーションからクラウド内にあるデータのアクセスには、一般的にはアクセスについての追加コストはかからない。これによって、クラウドは（アクセスが無くなった）コールドデータを、現実的に活用しうる機能を持っていると証明されるかも知れない。

著者略歴：Chris EvansはLangton Blueをベースに活動する独立系コンサルタント。