クラウドのインフラストラクチャを利用する場合、適正なバックアップが確実に行われるようにしっかり監視する必要があります。誤ってインフラストラクチャが削除されたり、クラウドプロバイダ側でハードウェアがダウングレードされたりしないとも限りません。その場合、インスタンスが停止状態になり、データが不完全になったり、その後の処理が不能になったりします。インフラストラクチャをAmazonで稼働させているなら、EC2(Elastic Compute Cloud)データを正しくバックアップするいちばん良い方法はEBS(Elastic Block Store)ボリュームのスナップショットを取ることです。
Amazonは2018年7月にAmazon Data Lifecycle Manager(Amazon DLM)というサービスをリリースし、EBSボリュームのバックアップ自動化やデータ保持ならびに削除をより簡単に行えるようにしました。本稿では、Amazon DLMの機能や利用法を解説し、その長所と短所を考察します。また、Amazonインフラストラクチャのバックアップのためのサードパーティーソリューションも紹介します。
Amazon Data Lifecycle Managerとは?
Amazon DLMは、EBSボリュームのバックアップ、保存、削除を自動化するツールです。Amazon DLMが利用可能になる以前、EBSボリュームのバックアップには、AWS LambdaかEC2インスタンスから実行するスクリプトを特別に用意しなければなりませんでした。スナップショットの保存と削除も同様にスクリプトから実行されました。
Amazon DLMは、EBSスナップショットを基本としています。EBSスナップショットは増分バックアップなので、前回のスナップショットに加えられた、あるいは修正されたデータのみが含まれます。したがって、たとえスナップショットが削除されても、そのスナップショットに含まれる分のデータが削除されるだけです。このようなバックアップ方法はコスト削減の効果も期待できます。
Amazon DLMがEBSボリュームのバックアップを実行するには、まずタグ付けが必要になります。そして、Amazon DLMポリシーを通じてバックアップのタイミングが指示されます。1つのEBSボリュームに複数のタグを付けることができるので、複数ポリシーの適用が可能です。
Amazon Data Lifecycleポリシーによって、どのリソースをいつバックアップすべきかが制御されます。下記の3項目の設定が、このポリシーの中核を成します。
- Resource Type(リソースタイプ):バックアップするリソースのタイプを記述します。現在のところ、サポートされる値はVOLUMEのみです。
- Target Tag(ターゲットタグ):バックアップが必要なボリュームを識別するキーとその値です。
- Schedule(スケジュール):ボリュームがバックアップされるインターバルを示します。
ポリシーはJSON形式のコンフィギュレーションファイルで構成されます。以下はポリシー例の一部です。
{ “ResourceTypes”: [ “VOLUME” ], “TargetTags”: [ { “Key”: “SnapshotVolume”, “Value”: “true” } ], “Schedules”:[ { “Name”: “DailySnapshots”, “TagsToAdd”: [ { “Key”: “type”, “Value”: “DailySnapshot” } ], “CreateRule”: { “Interval”: 24, “IntervalUnit”: “HOURS”, “Times”: [ “05:00” ] }, “RetainRule”: { “Count”:7 }, “CopyTags”: false } ] } |
上記の例では、タグキーがSnapshotVolumeで、タグ値がtrueのすべてのボリュームがバックアップのターゲットとなります。毎日5:00AMに実行され、7件のバックアップが保持されます。最新のスナップショットには、キー=type、値=DailySnapshotとタグ付けされます。Amazon DLM lifecycleポリシーを作成するには、特定のスクリプトを実行します。(詳しくはお問合せください。)
Amazon DLMを利用する際は、下記の制限事項に留意する必要があります。
- ポリシー数はリージョンごとに最大100件まで
- 各ポリシーに設定できるスケジュールは1件のみ
- リソースごとに設定できるタグは最大50まで
Amazon Data Lifecycle Managerの長所と短所
Amazon DLMを使い始める前に、その長所と短所を整理してみましょう。
長所
- コンフィギュレーションが簡単:Amazon DLMポリシーを実装するために必要なのは、前述の3項目(Resource Type、Target Tag、Schedule)を設定するJSONファイルと適切なIAMユーザーだけです。IAMユーザーには、Amazon DLMでスナップショットを作成・削除する権限が必要です。
- 増分バックアップを利用:EBSボリュームのスナップショットを作成することによって、変更データのみがバックアップされます。
- モニタリング機能:Amazon CloudWatchを利用し、スナップショットの作成とAmazon DLMポリシーの状態を監視するルールが作成できます。
短所
- コンフィギュレーションの変更に、旧スナップショットは考慮されない:ターゲットととなるボリュームのタグが変更されると、それ以前に作成されたボリュームにはポリシーが一切適用されません。スケジュール名も同様の扱いになります。スケジュール名が変更されると、それ以前に処理されたスナップショットに新ポリシーは適用されません。したがって、以前のボリュームとスナップショットは管理されないまま放置されます。それを補うには余計なコストがかかる可能性があります。
- バックアップの時間指定が不正確:スナップショット作成で指定できる時刻はあくまで相対的な時間指定です。Amazon DLMは指定された時刻から1時間以内にスナップショットを作成します。つまりTimeプロパティを5:00に設定したら、スナップショット作成は遅くとも5:59に開始されます。
- アベイラビリティゾーンをまたがるバックアップは不可:EBSボリュームはそれが作成されたAZ(アベイラビリティゾーン)内でのみ有効です。DR(災害復旧)プラン用には、ボリュームやスナップショットを他のAZに自動的にコピーする特別なスクリプトを用意しなければなりません。
- ポリシー数制限に抵触する可能性:1件のEBSボリュームに複数のバックアップを実行する場合、複数のAmazon DLMポリシーを作成しなければなりません。これは設定を複雑化するばかりか、リージョンごとのポリシー件数の制限に抵触する可能性を生みます。
N2WS Backup & Recoveryの活用
Amazonインフラストラクチャにおけるバックアップとリカバリには、N2WSが提供するツール、N2WS Backup & Recoveryを活用することもできます。このツールの主な特長は以下の通りです。
- Amazon Aurora、EC2インスタンス、Amazon EBS、Amazon RDSデータベース、Amazon Redshiftクラスタを自動的にバックアップ
- 複数リージョンにまたがるDR
- 重要データをファイルごとにコピー可能
- 単一ファイルか環境全体を処理するかにかかわらず、1クリックで手軽に高速リカバリ(30秒以内)
- 使いやすいウェブUIでモニタリング、ダッシュボード、アラートが利用でき、他のサービスとの統合も可能
N2WS Backup & RecoveryはすべてのバックアップをAmazon S3に保存するので、可用性が高く、他のリージョンや他のアカウントからもアクセスが容易になります。
Amazonリソースに対するポリシーやスケジュールが、N2WS Backup & RecoveryのウェブUIから作成できます。N2WS Backup & Recoveryのスケジュールでバックアップをいつ実行するかが指定でき、ポリシーによって、適用すべきスケジュールとデータの保持期間が指定できます。
スケジュールを作成したら、ポリシーを適用してリソースのバックアップを開始することができます。また、ポリシー内のオプションで、そのポリシーがDR用のバックアップを作成すべきかどうかを選択することができます。DRオプションをクリックしてDRを有効にしたら、バックアップを保存すべき他のリージョン(複数可)を指定し、ApplyボタンをクリックするだけでDR対策が完成です。また、複数アカウントにまたがるDRも可能です。
ポリシーとスケジュールの準備ができたら、バックアップすべきリソースを選びます。ウェブUIで、ポリシーに対してBackup targetsを選択し、対象となるリソースを選びます。リソースは、EC2インスタンス、Amazon Auroraクラスタ、EBSボリューム、Amazon Redshiftクラスタから選択することができます。
インスタンスやボリュームのリストアは非常に簡単に実行できます。ファイル単位のリストアでも問題ありません。Backup Monitorタブからバックアップを選び、Recoverをクリックするだけです。それによって、データを同じアカウントにリストアすることも、他のリージョン、あるいは他のアカウントにリストアすることも可能です。すべてはポリシーに設定した通りに実行されます。
N2WS Backup & Recoveryの使用を開始するには、AWSアカウントにログインし、EC2インスタンスをN2WS Backup & Recoveryの30日間トライアルAMIで起動します。N2WS Backup & Recoveryのセットアップ手順については、お問合せください。
まとめ
Amazon DLMはかなり新しいサービスですが、基本的な機能が備わっており、これまでAmazon EBSボリュームをバックアップするのに必要だった各種スクリプトを省略することができます。しかし、重要な機能がいくつか不足しているのも事実です。例えば、ファイル単位でのバックアップからのリストアやDRへの対応が不十分です。将来Amazon DLMの機能が増強されることは期待できます。
Amazon DLMに不足している機能は、N2WS Backup & Recoveryのようなサードパーティーのソリューションで補うことができます。N2WS Backup & Recoveryでバックアップできるリソースは非常に幅広く、使いやすいウェブUIのおかげで、数回のクリックでバックアップの作成やリストアが完了します。
関連トピックス
- CloudBerry BackupにおけるAmazon S3 Glacier Deep Archive のサポート
- VMimportロールの設定方法:CloudBerry Backup
- N2WS Backup & Recoveryが提供する3つのリストア手法
- Amazon S3へのバックアップに必要な権限【CloudBerry(MSP360)】
- 【Veeam Backup for AWS 3.0新機能】Amazon RDSのバックアップ対応
- N2WS Backup & Recoveryのバックアップポリシー作成方法
- インディペンデント・ボリューム・コピー: N2WS ハウツー・ガイド
- 豊富なアクセス制御でBYODのセキュリティリスクを解決 [Accops]
- ファイル・レベル・リストア : N2WS ハウツー・ガイド
- バックアップジョブの長期保存ポリシー(GFS)[Veeam Backup & Replication]