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