統合アーカイブ

データのアーカイブには主に2つのアプローチがある。アプリケーションごとに個別のアーキテクチャを適用するか、全アーカイブを1つのプラットフォームに統合する単一アーキテクチャを採用するか、だ。両者の賛否両論を検証する。

データアーカイブはストレージの世界の吸血鬼だ。残骸を吸い取って企業のストレージシステムを若返らせ、膨大なファイルの負荷に苦しむ前の姿に戻すことを約束してくれる。だが、アーカイブのメリットの裏側には、隠された筋書きがある。アーカイブを始めることで、最終的な実装コストに恐れおののくことになるかもしれない。

だが時代は変わりつつある。アーカイブの利点もより一層魅力的になっている。昔のアーカイブはデータのライフサイクル（高価なディスクドライブから安価なテープへの移動）しかできなかったものだが、今やまったく違うものに変わっている。法令遵守や法律の要請から、アーカイブはデータの長期保存用倉庫的な役割を担うことが多くなっている。旧式の手法である、スタブと削除による階層型ストレージ管理は、実装ではほとんど捨て去られている。

もはやアーカイブは、あちこちに散らばった個別のデータではなく、組織を守るためになくてはならないツールになった。アーカイブ化の作業はほとんどの場合単一のアプリケーションから始まるが、複数のデータタイプや種類の異なるシステムも取り込んですぐに大きくなっていく。肝心なのは、1つのアーカイブシステムを拡張してヘテロなデータを取り込むようにするのか、単一アプリケーション用のアーカイブシステムを複数使うのか、である。だがそれ以外の方法で統合アーカイブを構築することもできる。1つのストレージプラットフォームで複数のアーカイブシステムを構築したり、業務用検索技術にて雑多なシステムに見かけ上統一性を持たせることが可能となっている。

多くの場合電子メールから始まる

アーカイブのほとんどは小規模な状態から始まり、ほとんどのデータタイプは（電子メールなど）1つだけだ。IT部門はデータの増大を抑止しようとして、添付を削除したり、データをExchangeサーバから移動したりできるシステムを探すことになる。法務部門は訴訟に関連した検索ができるよう、電子メールメッセージ一式すべての保存を要請する。今後は、サーベンス・オクスリー(SOX)法や産業規制を遵守するため、所定のメッセージを保存することが記録管理に求められてくる。

元々の意図とは関係なく、こうしたポイントごとのソリューションの適用範囲は時間とともに広がっていく傾向にある。電子メールシステムにはアドレス帳もあり、日程表もあり、未処理業務リストもメモもある。こういうものは最初のうちは考慮の外にあるものだ。添付ファイルはどうする？ 会社の記録保存方針ではほとんどの場合文書の保存が求められているが、ファイルサーバか文書管理システムに同じものがあるかもしれない。法務部門は単純な検索と旧メールメッセージ抽出機能に慣れると、電子メールだけでなく、ファイルサーバ、文書管理システム、構造的データシステムなどを横断してさまざまなデータタイプをアーカイブして検索できるようにしたくなる。

こうした出来事が統合アーカイブの実装プロセスにおいて重要なターニングポイントになることがある。現在のシステムを拡張して他の記録データタイプも入れられるようにするのか、それとも新規アプリケーションごとに縦割りにソリューションを導入していくのか。

既存のアーカイブシステムの拡張にあたって、主目的となるのが、標準化と単純化である。米国フロリダ州ジャクソンビルにあるペイフォーマンスのIT部門ディレクター、ジェイソン・ベッカム氏は単一のプラットフォームにこだわるメリットを次のように語る。「現在当社が使っている日立のアーカイブプラットフォームは、すでに整っていて、中身もしっかりと把握しています。既存のHCAP（Hitachi Content Archive Platform）を拡張して電子メールをアーカイブに加える予定です。その方が実装も簡単ですし、管理業務やトレーニングが少なくて済みます。」

アーカイブの３つの要点

統合アーカイブや一元アーカイブはどうあるべきか、考え方はたくさんある。こういうソリューションを構築しようとして、固定観念が崩れることがあるかもしれない。アーカイブシステムには不可欠な要素が3つある。

ただし、こういう整然とした分類にそのまま当てはまるアプリケーションはほとんどない。メーカーが製品を開発して市場が成熟するにしたがって、メーカーは電子情報開示のサポートや検索、データ移動などの機能をどんどん追加していき、その影響でストレージ、アーカイブ、管理の境界が曖昧になってきている。多種多様な要素や重複する機能が、元々シンプルだったはずのアーカイブをどんどん複雑にしていく。

アーカイブ市場の探索はアーカイブの目的を評価するところから始まる。目的が社内での電子情報開示や規制遵守のための保存など、業務上の必要からであれば、データ管理機能を考慮して製品を選ぶのがよい。だが、IT部門でデータ量制御やライフサイクル管理ができるシステムが必要なら、検索や電子情報開示などの高度な機能はあまり関係がない。元々の目的に関わりなく、アーカイブはたいてい、最終的に業務部門とIT部門双方の要求に対応することになる。

どんなアーカイブも上記の3要素をすべて備えているというわけではない。データをカスタムのアプリケーションから直接アーカイブに送っている組織もあれば、専用のデバイスに投資せず、アーカイブ先に従来のストレージシステムを流用しているところもある。

シカゴを拠点にするIT戦略コンサルタントのブライアン・グリーンバーグ氏は、アーカイブ環境を拡張する前に戦略を立てる必要があると説く。「大組織は、特に規制の厳しい業界では連携検索や複数のデータタイプ管理などができるものを求めますが、規模の小さい、規制の厳しくない業界の組織なら、データを倉庫に入れておくだけでもいいかもしれません。要は求められる全体管理の水準です。」

アーカイブの連携

雑多なデータアーカイブのタイプを整理する現実的なソリューションとして、連携管理ソフトウェアがある。これは、電子メール、データベース、コンテンツ管理システム、ファイルサーバのそれぞれに最適なソリューションをユーザが選んでから、それら複数のアーカイブに単一のインタフェースをかぶせて煩雑さが表面に出ないようにするというものだ。容量管理よりも検索がアーカイブの主目的となる場合に相応しいソリューションである。

今のアーカイブプラットフォームは検索機能や電子情報開示をすでに持っているが、どちらも法務専用のデータ管理ツールには及ばない。単純なブール論理によるテキスト検索は、アテネックスのPatterns、クリアウェルの電子情報開示 Platform、i365のMetaLincsなどの製品が持つ概念クラスタリングやファジー検索機能などにはかなわない。これらのツールはレビューや注釈機能などを含む複雑な電子情報開示機能など、IT専用のアーカイブアプリケーションにはない機能を備えている。

これらツールの一部はアーカイブされていないデータも検索できる。オートミーとオープンテキストは作業データとアーカイブのデータの両方を1つのインタフェースで管理できる業務用検索プラットフォームを販売しており、他の業務アプリケーションと統合して複雑な環境を構築することもできる。CommVaultはアーカイブと検索を一元化したプラットフォームにバックアップとリモートサイト・レプリケーションも盛り込むことで、ワンストップデータ保護・管理スイートを実現している。

プラットフォームのゲーム

企業の中には、アーカイブの統合という複雑な問題をボトムアップの手法で解決しようとして、一元的なストレージプラットフォームを研究しているところも多い。このアプローチは、検索よりも容量管理を重視する場合にもっとも相応しいものとなる。ストレージの一元化にはメリットが多い。

統合アーカイブには、それほど高い技術が必要なわけではない。EMCのCentera APIやストレージネットワーキング・インダストリ・アソシエーションの新しいeXtensible Access Method（XAM）仕様などの専用プロトコルは、アーカイブを特に考慮して開発されている。だがNetAppのデータ保持製品マーケティング・シニアマネージャ、トーマス・サヴェジ氏は、「アーカイブアプリケーションの大部分は、標準のCIFSやNFSを介して多種多様なストレージデバイスをサポートしている。」と指摘する。ストレージデバイスはほぼすべてがアーカイブデータの着地点として機能する。

ただ、EMC、日立、HP、NetAppなどのアーカイブ専用プラットフォームはアーカイブデータの保存で使える特別な機能を用意している（原文「POPULAR ARCHIVING PLATFORMS」を参照）。大部分がファイルだけでなく「オブジェクト」をネイティブでサポートしており、それらをカスタムのメタデータで管理できる。自律的に保存指針を実施できるものもあり、データが「失効」したら確実に削除することもできる。全文のインデックス化と検索をサポートするものもある。高度なアーカイブソフトウェアは、機能的にはストレージデバイスと重複している部分があるのはほぼ確実だが、最下層の共通レイヤに適用することで、そうした機能の設定や一貫性のある指針の実施がシンプルになる。

データ保護は極めて重大事である。「ベルトとサスペンダー」式の二重防御の仕組みはITマネージャの安心材料となるかもしれない。アーカイブソフトウェアは一部のデータにアクセス禁止ポリシーの設定ができるが、アーカイブのターゲットとなる基本的なストレージシステムは保護されない状態に置かれる。標準的なNASシステムで使われている伝統的なセキュリティやアクセス管理を注意深く適用することで、このリスクはかなり軽減できる。しかし専用アーカイブシステムの機能はその上を行くように強化されている。

アーカイブ専用に設計されたストレージプラットフォームは修正や削除に対する保護機能が強化されている。これはWrite Once Read Many（WORM）ストレージと呼ばれることもある。一般にそう思われがちだが、実のところ、WORMストレージを使わなければならないと特にさだめた規制や法律はほとんどない。だが、アクセス制御は保存期間や分類においても同様に、長期データ管理でも中核となる概念であり、法律による開示では基本的にデータがアクセスも修正もされていないことの証明が必要である。そのため、合法・法令を遵守したアーカイブはWORM機能がなければ実現しない。数学的検査でデータが修正されていないことを認証する機能を持つシステムもあるが、こうしたものを使ったということが示された訴訟事例はまだない。最後に述べておくと、システムではすべてのアクセス試行のログと記録を必ず取るようにしなければならない。文書化の法令を遵守するには必ずこのデータが必要である。

アーカイブ用に設計されたストレージシステムの多くは、シングルインスタンス・ストレージ（SIS）による圧縮機能から高度な重複削除機能に至るまで、データ削減技術を採り入れつつある。これにはさまざまな技術があるが手法は似通っていて、アルゴリズムを駆使してデータ量削減とデータ損失回避を同時に実現する。シングルインスタンス・ストレージはファイルまたはオブジェクトを既存の内容すべてと比較し、重複しているものは1個のコピーだけを保存する。伝統的なデータ圧縮はファイルやオブジェクトを符号化し、繰り返されるパターンの「辞書」を作成してそれらを短縮する。最後の重複削除技術は、重複があるかどうかオブジェクト内部と蓄積データ全体を検索するもので、複雑な計算が伴うが、必要なストレージ容量を大きく削減できる可能性がある。どの手法でも、ストレージ削減と必要な計算能力のバランスを取っている。

こうした専用アーカイブシステムには、スケーラビリティ、ハイアベイラビリティ（HA）、データレプリケーションなどの標準的な業務用ストレージ機能もある。アーキテクチャは製品ごとに異なり、従来のストレージアレイ技術を用いるものから冗長ノードのクラスタからなるものもある。差別化要因の1つは、アーカイブシステムに、アーカイブでないデータをどの程度まで入れられるか、また入れるべきか、という点である。

アーカイブシステムを普通のストレージと比較する場合、考慮する事項に価格も入ってくる。ペイフォーマンスのベッカム氏はコストの差を認めているが、これは追加されたメタデータとWORM機能に見合ったものだという。同氏は、「当社はストレージシステムを買ったのではありません。高度なアーカイブプラットフォームから得られる業務上の価値に投資したのです。」と語る。アーカイブを考えてストレージプラットフォームを評価するときには、アーカイブシステムの高度な機能が必要かどうか考えるべきだ。既存のストレージデバイスでも保存に問題はないとしても、こうした機能は追加費用に見合うかもしれない。重複削除のスケーラビリティやNFSなどのプロトコルがオフラインのファイルを扱う方法などの技術的問題が急に持ち上がることもある。その場合は、専用のアーカイブプラットフォームしか対応できないだろう。

最後になるが、アーカイブソフトウェアは前述した機能を直接統合しているため、専用のストレージシステムは基本的なストレージデバイスよりも正確な設定ができる可能性がずっと高い。アーカイブハードウェアやソフトウェアを購入する場合は、管理のリスクや悩みの種が減らせるよう、高度な連携ができるソリューションを探すべきである。

グローバルアーカイブ

統合アーカイブを考えるとき、どこから始めればよいだろうか？ ITに関する決定と同じように、そのシステムが満たすべきビジネスの目的をまず考えるべきである。ゴールから考えよう。アーカイブは容量管理を行うのか、法令遵守に対応するのか、業務生産性を高めるか、法務支援機能があるか、こうした機能を連携させるのか？ その上で、特別な機能的要求のリストをまとめよう。これには要求の実現方法ではなく、システムでやらなければならないことを並べていく。このような準備をして初めて、複雑なストレージ市場の製品の比較ができる。

All Rights Reserved, Copyright 2000 - 2009, TechTarget
*この翻訳記事の著作権はJDSFが所有しています。
このページに掲載されている記事・写真・図表などの無断転載を禁じます。