Amazon Driveを前提として

Amazon Driveが容量無制限プランを出したので見てみたが、少し心許ないことが分かった。大容量ファイルのアップロード、ダウンロードが遅すぎ、また不安定すぎるのだ。また暗号化についても特に言及がなく、第三者やAmazon自身に覗き見されたり、検閲されていきなり削除されたり漏れたりという懸念も払拭できない。

この問題に対応するシステムとして有名なものに、電子割符がある。クラシックなものでは、①二つに分割して別々に保管し、両方揃わなければ復元できないもの、②三つに分割し、そのうち任意の二つが揃えば復元できるもの、があった。だが原理的に考えれば、この数値は任意に変えることができる。分割数と復元要数が4/3、4/2、5/4、5/3、・・・などの組み合わせだ。また、サイズを均等にする必然性もない。大2／小2としておき、大2と小1が必要、なども考えられる。

個人で使えるネットワークドライブを想定した場合、有料だが無制限で使えるAmazon Drive、無料でそこそこの容量を持つGoogle DriveとOneDriveを使うものとして、仮想的に無限のドライブを使え、ローカルにはキャッシュだけ持ち、更にはローカル機器の破損を想定した対策ができていてほしい。こうした想定に対応するシステム構成を考えてみる。

ファイルサイズが小さいものに関しては、割符は均等3分割、復元数2のものを使用する。これをAmazon Drive、Google Drive、OneDriveに置く。また、ファイルサイズが大きいもの及びバックアップに関しては、大2/小2、復元数大2/小1の分割を用いる。つまり、Amazon Driveに大2、Google DriveとOneDriveに各々小1を分散する。

小さいものに関しては3つのうち2つが生きていれば復元できる。大きいものとバックアップは、Amazonは必須で、他1つはどちらかが生きている必要がある。ここでAmazonが必須なのにわざわざ分割するのは、Amazon単体では復元できないようにするためだ。Amazon内のファイルが1つだと、割符というよりは暗号化ファイルと復号キーのようになってしまうため、相対的に復号が容易になるのだ。

また、分割後の個々のファイルに関しても、更に適当な容量に分割する。これは割符ではなくブツ切りで構わない。細切れにする理由は、ネット帯域の制限や、大容量ファイルにして一気に送るとエラー率が高くなり、再送の無駄が大きくなるためだ。

これらのファイルのアップロード・ダウンロード・分割・結合の状態は常にモニタされ、必要に応じて再送や復元、ゴミ処理(ガーベージコレクション)を行う。これはローカルで行ってもよいし、AWS Lambdaのようなもので行ってもよい。

大容量ファイルと小容量ファイルでは復元強度(障害耐性)に違いがあるが、これは大きさだけでなく重要度で分けるのもよい。フォルダで特性を分けるなどすれば簡単にできる。

3社ともにアメリカの企業である点がリスク管理上は問題になるので、企業が使う際には他国のサービスやローカルNASなども組み合わせてやるとよい。

自分で作る技量はないが、需要はあると思うので検討いただきたいものだ。