HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

コスト効率の高いスナップショット管理のヒントと方法

Storage Magazine 2021年2月号より
Dan Sullivan

スナップショットはデータをコピーし保護するのに最適な方法かも知れないが、時として思わぬ結果を招くことがある。その結果とはどんなことなのか、それをどのように回避するのかを見ていこう。

スナップショットにも、それなりの長所と短所がある。スナップショットは、データを保護し、迅速にデータベースのインスタンスをレプリケートする、コスト効率の高い方法になりうる。しかし、予想外のクラウド費用の原因にもなりうるのだ。後者のケースを回避するには、効率的なスナップショット管理方法の実装が特に重要になってくる。

この重宝なツールを効果的に使うには、スナップショットがどのように実装されているかを理解することが重要だ。データベースのスナップショットが最初に生成される時は、ソース・ディスクの全てのデータがスナップショットにコピーされる。次に同じディスクのスナップショットが作られる時は、最初のコピー以降そのディスクに起こった変化だけが移される。

ユーザーは、すでにバックアップとして保存されているデータを冗長化したものにお金を払うのではなく、個々のスナップショットに保存されたデータに対してのみお金を払えばよいので、この仕組みは理想的だ。スナップショットをリストアする時は、完全な形のスナップショットと増分スナップショットがコピーされ、スナップショットが最後に作られた時点のディスクの状態を再生成する。

しかし、データをコピーする最適なソリューションが、以下のような予想外の結果をもたらすことがある。

スナップショットを削除しても、あまり大きな空きができない。
個々の環境ごとにスナップショット・ライフサイクル・ポリシー管理をカストマイズできない。
複数のリージョン（配送先の地域）をまたいでスナップショットをコピーすると、イグレス（クラウドからのデータ退出）料金が課金される。

だが、以下に述べるスナップショット管理戦略を用いれば、これらの落とし穴にはまる危険を回避する手助けをしてくれる。

不必要なスナップショットを削除する

多くの企業では、予想を上回るストレージの請求書がきっかけとなって、不必要なデータ削除が始まる。例えば、開発サーバー用に最新5世代のスナップショットを保持していた開発チームが、保持のポリシーを変更してスナップショットを3世代のみ保存することにしたとする。

多くの人が、この変更によって2世代分のスナップショット、即ちスナップショット全体のサイズの40%が節約される、と考えるかもしれない。しかし、スナップショットはインクリメンタル更新を使用しているために、節約される容量は40%よりはるかに少ないものになる。

最も古いスナップショットが、ディスク1台のフルコピーで、その次に作成されたスナップショットから参照されているのであれば、最も古いスナップショットが削除された時、そこに含まれていたデータは次のスナップショットにコピーされる。データ損失がないので、これはデータ保護の観点からは理想的だが、コストカットが目標になっているのであれば、それにはほとんど貢献しない。

環境に合わせてスナップショット・ポリシーをカストマイズする

スナップショットのストレージコストを節約する方法の一つは、システム開発、開発側テスト、受け入れテスト、本番、など特定の環境に合わせてスナップショット管理ポリシーをカストマイズすることだ。当然、ユーザーは本番データに万全の保護を掛けたいだろうが、これは多くの場合頻繁なスナップショットを取ることにつながる。しかし開発環境は、これとはだいぶ話が違ってくる。

多くの場合、開発者は定期的に再構築や再デプロイが行われているアプリケーション用の共有コードベースを使って仕事をする。これは、今人気上昇中の継続的インテグレーション/継続的デリバリ作業の一部だが、これにより開発環境におけるスナップショットの必要性を抑えることができるようになった。

開発者によるテスト環境とユーザー受け入れテスト環境は、どちらも一般的に最新の変更を掛けられたアプリケーションをテストするために、その環境が使われるというところが似ている。どちらのテスト環境においても、サーバー上でデータが失われても、本番環境でのデータ損失よりもずっと簡単にデータを再生できるので、本番データに比べてスナップショットの必要性がはるかに少ない。

データベース依存関係要素

スナップショット管理において検討すべきもう一つの要素が、データベース上でスナップショットが生成されるときに使われる依存関係だ。

データベースのスナップショットは、そのスナップショットの作成時に使われたバージョンと互換性があるバージョンのデータベースに戻さなければならない。一般的に、誤ってデータを削除して、急いでそれを戻すときなど、短期間のデータ復旧にスナップショットを使うときは、これは特に問題にはならない。

しかし、スナップショットが長期間保存されると、その間にソースのデータベースがアップグレードされる可能性が高まる。これが、スナップショットが長期間のストレージ・アーカイブとして、今一つ魅力に欠ける原因になっている。

この問題を回避する方法は、スナップショットをエクスポートして、Amazon S3に保存することにより、ソース・データベースから独立したバックアップを作ることだ。エクスポートされると、データはApache ParquetフォーマットというHadoopエコシステムの一部として作られ、広く使われているカラムナフォーマットに保存される。Parquetをサポートしていれば、どのアプリケーションでもこれらのファイルをインポートできる。

もっと多くのデータを保存するには、低頻度アクセスS3ストレージクラスバケットにエクスポートしたデータを保存するのが良い。

スナップショットを複数のリージョン間をまたいでコピーすると、イグレス料金が課金されるので、そのことを頭に入れておくのが大事だ。ネットワーク課金を最小化するために、単一のリージョンでスナップショットを生成し保存するようにしよう。

AWS Relational Database Serviceのようなデータベース・サービスは、データベースのスナップショットを提供している。このサービスは、特に本番のバックアップに便利だが、長期間のバックアップとしては最善の選択肢ではない。あなたの会社の異なる環境を深く知ることは、あなたの会社が必要とするものに見合ったスナップショット管理ポリシーを実装し、過剰なイグレス課金などの落とし穴を回避する上で大いに役立つだろう。

著者略歴：Dan Sullivan（理学修士）は、IT業界で20年以上の経験を持つ著者、システムアーキテクト、コンサルタント。先進解析、システムアーキテクチャー、データベース設計、エンタープライズ・セキュリティ、ビジネス・インテリジェンスに造詣が深い。