例えば、大規模なOracle Databaseを採用していて、多くのコピーデータがあり、開発者の数も多いという場合には、最初にマスターコピーをとり各開発者にそのバーチャルイメージが渡されるような形にします。変更が加えられたイメージは物理ストレージに戻されます。開発者は、それぞれが担当するビジネスアプリケーション領域のみを担当し、でき上がったアプリケーションの機能をマスターコピーデータに反映させます。一方で、ビジネスにかかわらないシステム的な機能は、別のIT担当者が開発、運用します。これにより、開発者は、自分が担当するビジネスロジックに集中できるわけです。
クラウド事業者の事例もあります。この企業は拡張ストレージを選ぶ際に、ベンダーを問わず、その時点で最も低コストのものを選ぶというポリシーを持っていました。ポリシーによりエンドユーザーがディスクを拡張した場合、そこに記録されるデータが複数のストレージベンダーのストレージに細切れで保存されていきます。このためシステムが複雑になり、管理やバックアップが難しい状態でした。そこで生かせるサービスは、われわれのものしかなかったわけです。
--バックアップにかかる時間はどの程度短くできるか。
例えば1時間単位のバックアップは、転送まで含めると10~15分かかるため、かなりタイトにすることが可能です。現実的には、使用したいバックアップデータは3日前までのものが9割以上を占めるため、そこまでは差分を取ってすぐにバックアップデータを取り出せるようにしています。それ以前のデータについては、重複排除した上で圧縮し、時系列で数年単位のデータを格納していきます。
--特にサービスのニーズの高い業界は。
コピーデータの問題はあらゆる業界、テクノロジで共通のものと思いますが、特にサービスプロバイダーや金融サービス、製造、ヘルスケアといった業界です。それに政府、官公庁系ですね。そういった顧客から「今後のロードマップはこういう風にしたらいいんじゃないか」といったフィードバックをいただくこともあります。意見を参考にしながら、ロードマップを作成するイメージです。
--5年後の展望は。
われわれはこのマーケットで、競合がどうかではなく顧客がどのように成長していくのかにフォーカスしています。5年後の顧客の状況を想像してみると、2つの選択肢が浮かびます。1つは、データセンターを仮想化し、全てを自社で所有する形式。もう1つは、大半のアプリケーションをクラウドに移している形式です。パブリック、プライベート、もしくは2つを組み合わせたハイブリッドクラウドを、仮想化技術を取り入れながら利用していると思います。