はじめに
P5バージョン7では、クラウドストレージへのバックアップおよびアーカイブ用の新しいコンテナストレージフォーマットが導入されました。この新しいフォーマットにより、送信元と送信先間の転送オーバーヘッドを削減し、クラウドストレージをより効率的に利用することが可能になります。
この新しいコンテナ・ストレージ・フォーマットが必要な理由は2つです：
1つ目は、クラウドオブジェクトストレージへの書き込み効率が向上すること、2つ目は、バックアップ保持期間が過ぎて不要になったデータをより効率的に削除できることです。
クラウド・オブジェクトストアとの連携
この意味をさらに詳しく見ていきましょう。クラウドオブジェクトストレージへの書き込みは、ローカルハードディスクへの書き込みと何が違うのでしょうか？これを理解するには、クラウドストレージへのデータの書き込み方法をより詳しく理解する必要があります。
すべてのクラウドストレージベンダーは、「オブジェクト」という概念を採用しています。これは、クラウドサービス内のストレージ単位です。オブジェクトは、非常に小さいものから巨大なものまで、ほぼあらゆるサイズにすることができ、PDF、画像、動画、データベースなど、あらゆる種類のデータを含めることができます。オブジェクト内には、あらゆるものを保存できます。ここでは、さまざまなファイルがバックアップされているフォルダをオブジェクトストレージに保存する2つの方法を考えてみましょう。
オプション1：フォルダとそのファイルを個別にアップロードする。各ファイル = 1 オブジェクト
オプション2：フォルダとそのすべてのファイルを圧縮し、1 つのオブジェクトとして zip をアップロード
それぞれの選択肢には長所と短所があります。
オプション1は実装が簡単で、ユーザーの観点からも透明性が確保されています。そのために必要なソフトウェアはそれほど複雑である必要はありません。
オプション2は、追加の圧縮処理が必要となるため、より複雑です。この処理は、データの書き込み時と復元／読み込み時の両方で計算負荷を伴います。圧縮処理中は、追加のストレージ容量が必要になる場合があります。
複雑さが増す代わりに、メリットも得られます。クラウドに保存されるデータの総量が削減され、書き込まれるデータが圧縮に適している場合は、大幅に削減される可能性があります。データ量が少なくなれば、ストレージコストとアップロード／ダウンロードコストの両方が削減されます。
オプション2の大きな利点は、ファイルを個別に送信しないことで、送信するオブジェクトごとに発生する送信オーバーヘッドを回避できる点です。このようなオーバーヘッドは、保存されるオブジェクトごとに発生し、かなりの量になる場合があります。これは非常に大きなメリットです。1,000個のファイルが1つの圧縮オブジェクトに収まる場合、クラウドには1,000個のオブジェクトではなく、1つのオブジェクトを保存するだけで済みます。これにより、従来は現実的ではなかったバックアップが可能になります。
クラウドにファイルを転送する速度は、利用可能なインターネット・スピード（帯域幅）に大きく依存します。
しかし、このような速度制限に加えて、クラウドストレージに対して行われる操作ごとにオーバーヘッドが発生します。
操作のたびに新しい接続が行われ、認証が行われ、ストレージのバケットがチェックされ、チェックサムが計算されます。
一連のhttpリクエストが行われ、さらにネットワークの待ち時間がパフォーマンスに影響します。
多くの点で、私たちはクラウド・ベンダーのインフラに翻弄されています。彼らのシステムは利益を最大化するために最適化されており、時には私たちが経験するパフォーマンスを犠牲にしています。
パフォーマンスに関する公言と、経験した現実を照らし合わせるのは難しいでしょう。ファイルが1キロバイトであろうと、数百ギガバイトであろうと、オーバーヘッドは同じです。
つまり、小さなファイルをたくさん転送しても、クラウドストレージへの接続を最大限に活用できないことは明らかです。実際、非常に非効率的であり、絶対に避けるべきです！
ファイルの保存に必要な一般的な時間は、50～500ミリ秒の範囲です。バックアップ/リストアは、複数のファイルを並行してアップロード/ダウンロードすることで高速化できます。
この方法で4-8倍のデータを転送することは現実的ですが、より多くのトランザクション＝より多くのレイテンシ／オーバーヘッドを必要とします。
数字を見る
実際の例を見てみましょう。
ある顧客は約300TBのデータを持っています。そのほとんどは大きな動画ファイルですが、約50KBの小さなファイルも約85万個あります。インターネット接続は100Mbpsで、実際のアップロード速度は約10MB/秒です。この顧客の場合、1つのファイルをアップロードするのに約0.5秒かかります。
- 所要時間：85万×0.5/3600＝約118時間または5日
- (並列アップロードの場合、この時間は5分の1、つまり24時間/1日に短縮できる)
- データ量 850,000 x 50kb = 42.5GB
- データサイズ：850,000 x 50kb = 42.5GB
つまり、わずか40GB程度のデータであれば、アップロードには24時間（1日）かかり、復元／ダウンロードにも同じくらいの時間がかかるということです。
はっきり言って、P5コンテナストレージ形式では、同じバックアップがわずか45分で完了します。これは32倍も速いのです。まさに雲泥の差です！
中間的な結論： 各ファイルを個別のオブジェクトとしてアップロードするバックアップ方法は、時間がかかりすぎるため、プロフェッショナルな業務分野では使用できません。したがって、アップロード前にデータを圧縮することが必須です。
P5の新しいコンテナ・ストレージ・フォーマット
その名の通り、ファイルは「コンテナ」と呼ばれるグループにまとめられます。これらのコンテナの最小サイズは（デフォルトでは）256MBです。そのため、小さなファイルはこれらのコンテナにまとめられ、大きなファイルはコンテナ全体を占有します。さらに、すべてのコンテナは圧縮されます。
この新しい方法を用いることで、バックアップ時の遅延は無視できるほど小さくなります。データ構造に関する知識がなくてもP5を使用している企業は、インターネット帯域幅に基づいて、バックアップおよび復元に必要な容量を計算できます。
既存のP5ユーザーは、以前のバージョンでもデータが「チャンク」にグループ化されていたことに気づくでしょう。バージョン6では、仮想テープライブラリ（VTL）用のディスクドライバが既にこれを行っています。これらのチャンクファイルは、仮想テープライブラリとして管理されるディスクボリュームの一部です。このようにして、P5内の実績のある操作を変更することなく、テープのようなバックアップをハードディスクに再現できます。しかし、これは既に複雑に聞こえますが、実際その通りです。
Archiware社は、クラウドベースのバックアップは、セットアップや操作方法においてテープの仕組みを再現することなく、よりシンプルな方法で解決できるべきだと考えました。そのため、P5バージョン7向けに新しいストレージフォーマットを開発する必要があると判断しました。
P5バージョン6における期限切れデータのリサイクル
バックアップを実行するときのことを考えてみましょう。ファイル・セットのコピーを作成します。
各ファイルのコピーは、少なくともオリジナルがディスク上に存在する限り保持されます。
オリジナルが削除された後、各ファイルの保持期間を指定することができます（30日間など）。
こうすることで、オリジナルがしばらく前に、おそらく誤って削除されたとしても、オリジナル・ファイルを復元するオプションがあります。
あるファイルの保存期間を過ぎたら、容量を節約するためにバックアップデータから削除し、クラウドストレージのコストを削減することができます。
このようなストレージ領域を解放するプロセスは、ある程度、現在の「チャンク」実装の問題点です。
既存のシステムでは、「ボリューム」レベルで行われる「リサイクル」と呼ばれるプロセスがあります。
「ボリューム」という用語は、P5ではLTOテープ全体を表すのにも使われます。クラウドへのバックアップの場合、ボリュームはサイズが決まっており、多くのチャンクを含んでいます。
不要になった（期限切れの）データが50%含まれるボリュームをリサイクルするには、まずディスク（オンライン）に残っている50%を再度バックアップして保存し、ボリューム全体を削除する必要があります。
絶対数では、2TBのボリュームのうち1TBをクラウドにバックアップする必要があります。
「プログレッシブ」バックアップを取ることで、P5はボリュームのリサイクルとデータの再保存を自動的に行います。
また、「フル」バックアップをスケジュールすることで、すべてのデータを再保存し、古いボリュームを再利用することもできます。
ただし、クラウドストレージに対してバックアップを実行する場合は、フルバックアップの繰り返しは避けた方がよいでしょう。
十分な帯域幅と適切なサイズのバックアップウィンドウを持つ多くのお客様にとって、これは十分に機能します。
しかし、残念なことに、大量のデータをクラウドに随時アップロードする必要があるため、この方法では拡張性がありません。
バージョン7における期限切れデータのリサイクル
これらの理由から、クラウド・ストレージに書き込む際のP5内のリサイクル・メカニズムを最適化する必要が生じました。
そのため、P5バージョン7では新しいコンテナ形式を採用しました。新しいバージョンでは、ボリューム全体ではなく、「コンテナ」のリサイクルを対象としています。
コンテナ内に保存されているすべてのデータが不要になった場合（1つのファイルでもよい）、コンテナ全体を削除することができます。
コンテナ内に期限切れでないファイルがある場合、P5は比較的少量のデータを再保存するだけで、コンテナを削除できます。これは256MBのチャンクサイズに比べれば小さなデータ量です。
コンテナの有効期限切れと少量のデータの再保存のこのプロセスは、バックアップウィンドウ全体に分散されるため、大量の追加データの再保存が必要なピークが発生することはありません。
結論
新しいP5コンテナ・ストレージ・フォーマットは、クラウドへのバックアップやアーカイブに最適化されたストレージ処理を提供します。
顧客データ内のファイルサイズの分布に完璧に適応し、小さなファイルをまとめてレイテンシーを最大限に活用する一方、大きなファイルは独自のコンテナ内に保存されます。
複数の並列アップロードを同時に利用することで、パフォーマンスはさらに向上します。
これにより、顧客が負担するクラウドストレージのコストが削減され、空き容量がより迅速に解放され、保存する必要があるオブジェクトの数が大幅に削減されます。
オブジェクトの数が少なければ、ロケーション間でオブジェクトを複製する際のコストも低くなります。
さらに、新しいフォーマットには、ファイル・ブロックとコンテナ・レベルでチェックサムが生成されるというセキュリティ上の利点もあります。
P5サーバーに障害が発生した場合、P5コンフィギュレーション全体とバックアップ・インデックスをクラウド・オブジェクトストアから直接リカバリできます。
