重複排除 技術解説(4)重複排除するタイミング − リアルタイムか後処理か

引き続き、ASCII.technologies 2011年1月号に寄稿した「重複排除技術が革新するストレージの世界」の第二章の技術解説です。今回は「重複の判定方法」です。


[2.3節 重複排除するタイミング − リアルタイムか後処理か 序文]
前節では重複判定の方式について説明した。本節では、その重複判定の処理をどのタイミングで行うかということについて、解説していこう。ここでは大きく二つの方式があり、一つはリアルタイムに行う方式で、もう一つは後処理として行う方式だ。
リアルタイムに行う方式は、インライン方式と呼ばれる。インライン方式では、データがディスクに書かれる前に重複判定が行われ、重複データはそのタイミングで削除される。つまり、重複データがディスクに書かれることはない。
後処理として行う方式は、ポストプロセス方式と呼ばれる。ポストプロセス方式では、重複であるかどうかの判定は後回しにしてとりあえずディスクにデータを全て書いてしまう。つまり、重複排除機能が無い場合と同様、全てのデータはディスクにまず書かれる。そして、後々、バックグラウンドタスクとして重複判定処理が走る。重複判定処理がまだ行われていないデータを読み出し、フィンガプリントを比較するなどして重複判定を行い、重複であればそのデータを削除し他の同一データへのリンク処理を行う。例えるなら、ポストプロセス方式ではバッファのようにディスクを使っていると言ってもよいかもしれない。
インライン方式とポストプロセス方式にはそれぞれメリット・デメリットがある。以下ではその違いを説明していこう。

インライン方式は容量効率に優れる

インライン方式の一番の利点は、重複データがディスクに書かれることは無いため、容量を無駄に使わないという点である。ポストプロセス方式では、データが重複かどうかに関わらずディスクに一旦格納されてしまうため、インライン方式に比べて容量を多く使ってしまう。
この差を少し定量的に見てみよう。例として、1.3節のケース(解説1の記事)でフルバックアップ5世代分を保管した場合に、どれぐらい必要容量に差が出てくるか計算してみる。議論を単純化するために、メタデータなどの部分は大勢に影響を与えないとして省略して進める。
インライン方式の場合、一回目のフルバックアップが250GB、二回目以降のフルバックアップが18GBだから、5世代分のフルバックアップを保管するとして250+18x5=340GBの容量が使用されることになる。20%のマージンを積んでシステムを構成したい場合は、340x1.2=408GBのストレージ容量が必要という計算になる。
一方、ポストプロセス方式を使った場合はどうなるか。最後のバックアップに関しては重複排除・圧縮が行われる前のオリジナルの容量が格納されるので、250+18x4+1000=1322GBの容量が使用されることになる。同様に20%のマージンを積むとすれば1322GBx1.2=1586GBのストレージを購入する必要があることになる。
オーバヘッド容量は1586-408=1178GB、割合にすると1178/408=289%もの高率のオーバヘッドになる。このケースでは、ポストプロセス方式を使うとインライン方式の三倍近くの容量が必要になる計算になる。

インライン方式はレプリケーションを早く開始できる

インライン方式にはもう一つアドバンテージがある。それはレプリケーションを早く開始できるということである。前述したように、重複排除製品ではネットワーク転送量が大きく削減されるため、レプリケーションを組み合わせて使う場合が多い。
しかし、このネットワーク転送量削減のメリットは、レプリケーション処理が重複排除処理の後に行われるからこそ出てくる。この順番が、ポストプロセス方式を使う場合に問題になってくる。ポストプロセスでは、重複排除処理を後処理としてバックグラウンドタスクで行うので、その処理が終わるまでレプリケーションを開始できない。レプリケーション処理を重複排除処理の前に行ってしまうと、ネットワーク転送量削減のメリットが得られないからだ。
レプリケーションの開始が遅れるということは、災害が起きたときにデータを復旧することができないリスクが高まるということである。災害対策の重要な要件のひとつとしてRPO (Recovery Point Objective) があるが、レプリケーションを早く開始できる分、インライン方式はポストプロセス方式よりもRPOで優れている。

ポストプロセス方式の利点

では逆にポストプロセス方式の利点とはなんだろうか。
一つは、重複排除するデータ、しないデータを選びやすいということだろう。重複排除は容量削減という面では大きなメリットをもたらすが、性能的に見た場合は必ずしも最適とは言えない。物理的にファイルが複数存在すれば並列で処理できたものが、重複排除をしてしまうとアクセスが一箇所に集中してしまうためである。この特性は、バックアップストレージではあまり問題とならないが、プライマリストレージに重複排除を適用する場合は大きな問題となる可能性がある。頻繁にアクセスが来るファイルに対して重複排除を行うと、システム性能を大幅に低下させてしまうかもしれないためである。
この様な場合、ポストプロセス方式であれば、ファイルへのアクセス頻度を見ながら、ある程度アクセスが減ってきたときに重複排除するということができる。いわゆる階層ストレージのような概念を用いて、アクセスが減ってきたデータにのみ重複排除を適用するというやり方だ。こういった方法はポストプロセスの方が行いやすい。
もう一つの利点は、インライン方式に比べて、より複雑で時間のかかる重複排除・圧縮処理を適用しやすいということだ。インライン方式では、重複排除処理をリアルタイムに行っているので、あまり処理に時間を掛けるわけにはいかない。だが、ポストプロセス方式であれば、重複排除処理を後日じっくりと行うことができるので、より複雑で時間のかかる重複排除・圧縮処理を適用できる可能性がある。
三つ目の利点は、書き込み時に重複排除処理を行わないので書き込み性能へのインパクトをより低減できるということだ。しかし、この強みに関しては、2.2節で述べたように、インライン方式の工夫とCPU・メモリ技術の進化により、あまり大きな差が出ないようになってきている。
開発側から見た利点としては、既存システムに後付けで開発しやすいというのがあるだろう。NetApp、FalconStor、Sepatonなど、既存のストレージ装置に後から重複排除機能を追加した製品はポストプロセス方式が多い。