しかしIT部門は、クラウドアーカイビングへの全面的な移行を決める前に、クラウドを利用するメリットを、自社でアーカイビングを行う場合と比較検討する必要がある。クラウドプロバイダーは技術的に、企業が自前で実装できない機能は提供できない。このため企業は、例えば、1Gバイト当たりの平均保存コストを低減する目的で、大容量SATAディスクを3ティア（3階層）とする階層型ストレージインフラを導入することを選択するかもしれない。一般的に、企業が自前のソリューションを好むのは、遠隔地との接続が失われるリスクを避けなければならない場合や、規制により厳格なデータセキュリティ管理が要求される場合、通信遅延が認められない状況でデータを取り出す必要がある場合だ。これらの条件からすると、選択の余地はかなり狭いが、それでもさまざまなアプリケーションのデータがクラウドベースアーカイビングの対象候補になる。

　また、IT部門は、クラウドへの移行に伴う作業量を見積もれるが、クラウドに移行するには、実務作業だけでなく技術中心の視点からサービスレベル管理の視点に考え方を転換することも必要になる。こうした考え方の転換は、クラウド利用において当たり前のことであり、この課題を見過ごしてはならない。技術の選択と配備を行うことに慣れたITスタッフはしばしば、クラウドベンダーのアーキテクチャを詳しく調査し、製品や技術の具体的な導入について提案したがる。しかし、そうした形での要望はめったに通らない。ベンダーがクラウドインフラ管理に全面的な責任を負っているからだ。IT部門は、契約で定められたサービスレベルが提供されていれば、どのような技術が使われているかは気に掛けるべきではない。実際、大抵の場合、クラウドの利用経験を積むと同時に、スタッフの注意は低レベルの細かい事柄からより高いレベルの管理へと徐々に移っていく。

サービス：クラウドベースアーカイビングの重要な要素

　サービスレベル管理は、クラウドベースのアーカイビング導入時の判断と実運用において極めて重要な要素だ。クラウドアーカイビングベンダーの選定に当たっては、サービスレベルについて以下のような事項を検討するとよい。

1．アップタイム

　ほとんどのアプリケーションは、スリーナイン（99.9％）かフォーナイン（99.99％）の可用性を確保すれば、ビジネス要件を十分満たせる。ファイブナイン（99.999％）の可用性が必要な場合、あるアーカイブの階層（アーカイブティア）にそぐわないデータアクセス要件が設定されているといえるだろう。アーカイブティアに置かれるデータは、定義上クリティカルではないからだ。こうしたアップタイム要件は、ベンダーからプロビジョニングを受ける必要があるインフラの規模を大きく左右する。このため、ホスティングコストへの影響が大きい。アップタイム要件を設定するに当たっては、推測に頼ることなく、データが実際にアクセスされる時刻、アクセスパターン、ダウンタイムコストを調べて割り出す必要がある。これらを踏まえて各種のアップタイム保証のコストを検討すれば、コストを正当化できる保証とそうでないものを簡単に分けることができる。ベンダーは、クラウドストレージのサービスレベル契約（SLA）に違反した場合、ホスティング料金の割り戻しなどによって補償を行うことが多い。ただし、契約書にはただし書きが記載されており、それらに目を通しておく必要がある。

2．アクセス性

　アクセス性とアップタイムは、必ずしも同じではない。ストレージが動いていても、サブコンポーネントのせいでアプリケーションが使えなくなるかもしれない。例えば、データリンクの冗長性や多重冗長化が必要な場合、これらを確保するために費用をかけなければならない。さもないと、アプリケーション停止という許されない事態を招く恐れがある。サービスレベル保証の対象にエンドツーエンドのデータ可用性も含まれるようにする必要がある。

3．パフォーマンス

　アプリケーションに必要なIOPS（1秒間当たりに処理できるI/Oスループット数）を算出し、その値をSLAに含める。IOPSの必要値は、平均値として計算するか、あるいはピーク稼働時に必要な値として計算することができる。ピーク稼働時に必要なIOPSの保証を求める場合、ベンダーがそのために行うプロビジョニングに対する対価を支払わなければならない。一部のベンダーはIOPSについて従量課金制を採用しているかもしれないが、この従量課金制では、要求が急激に増加した場合、問題なく処理が行われる半面、コストが予算を超過する恐れがあり、多くの企業はこの点を嫌う。ほとんどの企業は、ベンダーから提供される性能に上限を設定し、ある程度の量のオペレーション（特に、アーカイブティアに対する）については制約を受け入れるのと引き換えに、コストを予算内に抑えようとするだろう。この場合、SLAで一定のIOPSは保証されるが、エンドユーザーが経験するパフォーマンスは保証されない。アプリケーションの要求が、契約に定められたIOPS性能を上回る場合は、当然のことながらIT部門が対処しなければならない。費用を追加して、より高いIOPSを提供する構成に変更することが常に可能だ。

4．データのリカバリ性

　IT部門は自社アプリケーションの場合と同様に、クラウドベースアーカイブについても、RPO（Recovery Point Objective：目標復旧時点）とRTO（Recovery Time Objective：目標復旧時間）の要件を明確にする必要がある。これはアップタイムに関係する。また、全体的なアップタイムへの影響はないものの、個々のアプリケーションに影響するデータ破損やコンポーネント障害といった不測の事態への対応にも役立つ。ベンダーは、RPOとRTOのデフォルト値を用意しているだろうし、それらはアーカイブティアに十分かもしれない。だが、この分野でも推測は禁物だ。どのようなデータ損失やアプリケーション停止に対しビジネス部門が財務的に耐えられるかを把握しなければならない。多くの場合、その種類は直感的な予想よりもはるかに多い。

5．ディザスタリカバリ（DR）

　クラウドアーカイブを、データの冗長性要件を満たす目的で、ストレージのオフサイトレプリケーション先として使う場合は、このティア（階層）のDR方式を検討する必要はないかもしれない。しかし、注意しなければならないのは、ほとんどのホステッドストレージサービスにはDR対策が含まれていないことだ。ホステッドストレージでホストされるデータが、ハイブリッドクラウドストレージの運用の一環としてプロビジョニングされる「ライブ」データである場合は、DRプランが必要かもしれない。ホスティングプロバイダーは、定期的にデータをバックアップするかもしれないが、一般的に、バックアップデータをオフサイトに移動しない。移動するとしても（月1回など）その頻度は少ない。SAS-70（受託業務に関する内部統制を評価するための米国の監査基準）に準拠したデータセンターでは、大規模な障害が発生する可能性は低いが、発生することはあり得る。ホスティング会社がDR機能を提供している場合、多額の追加費用が必要なオプションであることが多く、これを採用すると、ホスティング利用の採算性が一気に低下する恐れがある。いずれにしても、データが脆弱な状態に置かれないようにしなければならない。

6．バックアップとリカバリ

　ホスティングベンダーがデータを定期的にバックアップし、頻繁にオフサイトに移動する場合でも、IT部門は安心していられないかもしれない。ホスティングベンダーは通常、限られた数のバックアップソフトウェアオプションやテープ技術しか用意していない。そのため、これらのベンダーのバックアップのフォーマット（ハードウェア／ソフトウェア、あるいはその両方）は、自社のITシステムと互換性がないかもしれない。これでは、IT部門がベンダーのテープからリカバリを行わなければならなくなった場合、必要なインフラの調達にかなり手間取る恐れがある。最悪の事態を想定した対応策を立てておかなければならない。

7．コンプライアンス

　コンプライアンス上、特別な取り扱いが必要なアーカイブデータが、クラウドホスティングの対象候補になるかもしれない。必要があれば、改ざん不能なメディアにデータが保存されるように手配しなければならない。また、厳格なアクセスガイドラインが順守されていて、その順守状況が監査可能であるという保証を得ることも必要になる。SAS-70に準拠したプロバイダーであれば、そうしたプロセスを実施しているはずだ。

8．コストの確実性と小刻みな変動

　アーカイビングのために自社インフラではなくクラウドストレージホスティングを利用する主なメリットの1つは、ストレージを使った分だけ料金を支払えば済むことだ。従量課金制のサービスは、使用量に応じて料金が小刻みに増減する他、利用企業は機器の設置スペースを最小限に抑えられる可能性がある。

　後編「テープからクラウドアーカイビングへの移行は現実的？」ではテープからクラウドアーカイブへの移行を検討する。