De-dupeの俗説

  インラインとポストプロセス
  ハッシュ方式のリスク
  重複排除比率
  重複排除導入のポイント

多様な方式のDe-dupe製品がリリースされているため、状況によって得意、不得意が発生している中で、特定状況にマッチする考え方を記述した内容が、あたかも全ての状況を満足する方式のように解釈されるケースが出てきます。
このような「De-dupeの俗説」となりうる話をJDSFが提携している SearchStorage.com の Storage Magazine Sep.2008 からピックアップしてご紹介します。

インラインとポストプロセス
型インライン型はポストプロセス型より優れているの?
De-dupe処理方式のインライン型とポストプロセス型。バックアップツールがバックアップデータを格納する際にどちらが優れているのでしょうか。実際は何を重視して優劣を決めるかの基準を明確にした上で判断する必要があります。ポストプロセス型はDe-dupe処理前のデータを一度ディスク上に格納するためのワーク領域が必要になる場合があります。どのタイミングでDe-dupe処理が開始されるかによって必要なワーク領域の容量が変わってきます。一日一回のスケジュールでDe-dupe処理が開始される場合は、一日分のバックアップデータを蓄えるワーク領域が必要です。しかし、これよりも細かい単位で開始される場合はより少ないワーク領域でも運用可能となります。

一方、バックアップ取得時間を考えた場合、インライン型では、同時に実行されるDe-dupe処理のオーバヘッド少なからず影響します。これがバックアップ処理時間に加わり、何も加工しないバックアップ処理時間よりも長い時間を必要とします。

これが、ポストプロセス型ではどうでしょう。De-dupe処理が完全に終了するまではインライン型より長い時間を必要とするかもしれませんが、ワーク領域にデータを格納するだけなら、通常のバックアップと同等の時間で完了できます。

バックアップツール側では、ワーク領域に格納を終えた時点でジョブが終了し、次のジョブに進むことが可能となります。

運用者にとっては、バックアップジョブが早く終わってくれることが最大の関心事かもしれません。

インラインとポストプロセス

このように、データの性質や環境、装置の処理能力などで、モノサシをどこにおくかによって優劣が大きく変わります。
何を優先事項とするかを明確にして製品の得意、不得意を見極めなければ正しい判断は出来ません。

ハッシュ方式のリスク
環境が大きくなるとハッシュコリジョンによりデータロスする?
ハッシュ方式はデータをより小さいサイズのキーに置き換えて比較するため、キーのケタ数以上のブロックの管理が出来なくなります。例えば128ビットのキーを生成するMD5を利用する場合、2の128乗通り以上のブロックが存在した場合、異なるデータで同じキーをもつことになります。これがハッシュコリジョンと呼ばれます。

では、ハッシュコリジョンが発生するリスクがあるため、MD5を利用したDe-dupe製品の信頼性は低いのでしょうか?

実際、2の128通りというのどのぐらいの数でしょう。 計算すると340x10の36乗。

・10の12乗 : テラ (これはよく耳にする単位ですね。)

・10の15乗: ペタ (データセンター規模で時々聞く単位です。)

・10の18乗: エクサ(数の単位として経験したことはありません。)

・10の21乗: ゼタ

・10の24乗: ヨタ

調べた範囲でこれ以上の単位の言葉が出てきませんでした。

1ブロックを1Byteで区切ったとしても、340エクサバイトの2乗でMD5のハッシュキーは飽和します。

JDSFが愛読するSearchStorage.comのStorage Magazine の記事によれば、「格納データが95エクサバイトより少ない環境であれば、ハッシュコリジョン発生の確率は小数点50桁以下」といわれています。

実際のブロックサイズは数KB~数百KBとなっており、ハッシュ方式も128ビットのMD5から256ビットのSHA-1が主流になってきているので、ハッシュコリジョン発生によるデータのロストの確立はさらに低いものとなっています。

それでも、やっぱり100%でなければダメでしょうか。ディスクやテープや、各ソフトウェアも100%はないと思います。

ハッシュ方式のリスク
重複排除比率
メーカーの主張する重複排除比率は異常に高い?
De-dupe製品の紹介資料には重複排除率やその効果を表す数値が用いられることがありますが、極端に高い値で記述されているものも中には存在します。

極端に高い数値は、毎回フルバックアップを行なっているデータ量を基準に計算されているものもあります。データの保持の仕方としては、フルのデータを管理するため間違いではないのですが、通常のバックアップ運用で毎日フルバックアップを実施しているケースは特殊なデータ状況での運用であるケースが多いでしょう。たいてい、週末にフルバックアップを取り、毎日は差分バックアップを行なっていることと思います。日々の差分バックアップで取得するデータがどれぐらい重複排除されるかが実際の運用効果を表していると考えられます。

どのような想定で計算されているかによって、値は大きく変わります。

重複排除比率
重複排除導入のポイント
データをよく知る 保存期間、バックアップポリシー
アプリをよく知る データの性質、更新部分の理解 DBデータ? イメージ?
圧縮、暗号化の有無 バックアップ時に暗号化が必要?
安易な導入は避ける 1台あたりの能力、データ移行 De-dupe機器台数追加
導入効果の予測 評価テストの実施は必須

製品を選定する場合、De-dupeに限りませんが、製品の特性や機能を十分理解し、判断を行なっていただきたいと思います。特にDe-dupe製品では扱うデータによって効果がまちまちです。実データを使用して評価、検証したり、メーカやSIerのアセスメントサービスを利用するなどして効果を確認してから導入することをお勧めします。