カスタマーサクセス部の山﨑です。
今回は、AWSでのEC2インスタンスのバックアップを自動化する方法のひとつ、Amazon Data Lifecycle Manager (DLM) に注目します。DLMを利用すると、バックアップ作業を効率化し、手動作業によるミスを防ぎながら、システムの信頼性を向上させることが可能です。
この記事では、DLMの設定方法や具体的な活用シーンについて、実際の手順を交えながら詳しくご紹介します。バックアップの自動化に興味がある方や、バックアップ作業を簡便化したい方に役立つ内容ですので、ぜひ最後までご覧ください。
はじめに
バックアップとリストア
みなさんはプライベートでとても大切にしている写真、仕事で利用する書類データをうっかり削除してしまってめちゃくちゃ焦った経験はありませんか?
このような万が一が起こった時のために、データをコピー・保存しておくとこでデータが完全に失われることを回避することができます。このようにデータの紛失や損失、破損などに備えて予めデータを別の保管場所に保存しておくことを「バックアップ」と呼び、バックアップから復元することを「リストア」と呼びます。
データの紛失や損失、破損は人によるミスだけではなく、機器の故障やシステムのバグ、ウイルス感染等が原因となることがあります。
- ヒューマンエラー:誤操作によって、重要なファイルを削除してしまった際、バックアップがあれば迅速に復旧させることができます。
- データの保護:何らかの理由で重要なデータが消えてしまったらめちゃくちゃ焦ります。昨今ではウイルスやランサムウェアによってデータが消失する危険もあります。しかし、バックアップがあれば、データの喪失を最小限(RPOの範囲内)に抑えることができます。
- 復旧時間の短縮:問題が発生しても、バックアップからすぐに復旧できれば、サービスのダウンタイムを短くできます。
- コンプライアンス対応:業界業種によっては、データの保存期間やバックアップの取得が法律や標準で定められている場合もあります。
こういったとき、最新のバックアップがあれば、迅速にシステムを復旧できます。
AWSにおいても例外ではなく、EC2インスタンスやRDS DBインスタンス等のリソースのバックアップも、災害や障害からの速やかな復旧に不可欠です。
Amazon Data LifeCycle Manager について
機能概要
Amazon Data Lifecycle Managerを使用すると、EBSスナップショットおよびAMIの作成、保持、削除の自動化に特化しており、以下のようなメリットを享受することができます。
- 定期的なバックアップ・スケジュールを実施することで、データを保護する。
- 監査または内部コンプライアンスによって要求されるバックアップを保持する。
- 古いバックアップを自動削除することで、コストを削減する。
- 別のAWSリージョンまたはAWSアカウントにバックアップをコピーすることで、災害発生時のシステム復旧に備える。
EC2 インスタンスや EBS ボリュームのバックアップを手軽に、コスト効率良く自動化したい場合に利用するのがオススメです
デフォルトポリシーとカスタムポリシー
デフォルトポリシー
デフォルトポリシーは、AWSリージョン内の全ての EBS ボリュームと EC2 インスタンスを対象にしてバックアップを自動的に取得します。ユーザー側で取得対象を指定する必要がないので、漏れなくバックアップを取得可能です。仮にバックアップ取得が不要なリソースがあった場合は除外条件を設定することが可能です。
例えば、テスト環境や一時的なリソースを除外することで、不要なバックアップを避け、コストを削減することができます。また、デフォルトポリシーは、最近のバックアップがない場合のみ新しいバックアップを作成し、重複したバックアップを防ぐためコスト最適化が可能です。
カスタムポリシー
カスタムポリシーは、特定のタグに基づいてバックアップ対象を選定できるため、より柔軟な管理が可能です。ユーザーは、バックアップの作成頻度や保持期間を細かく設定できるほか、高度な機能(アプリケーション整合性やクロスアカウントコピーなど)も利用できます。このため、大規模な環境や特定の要件がある場合にはカスタムポリシーが適しています
機能比較
機能 | デフォルトポリシー | カスタムポリシー |
---|---|---|
対象リソース | アカウント内のすべての EBS ボリュームおよび EC2 インスタンス | タグに基づいて特定の EBS ボリュームまたはインスタンスを指定 |
バックアップ作成頻度 | 1日(Daily)~7日(Weekly) | 毎日、毎週、毎月、毎年、またはcron 式を使用した柔軟なスケジュール設定が可能 |
保持期間 | 2日間〜14 日間 | 最大 100 年間、最大1,000個 |
除外パラメータ | あり | なし |
AMI作成前のインスタンスの再起動 | なし | あり |
複数スケジュールのサポート | なし | 最大 4 つのスケジュールを設定可能 |
その他詳細はAWS公式ドキュメントをご覧ください
いざ実装
EC2のコンソール画面から「Lifecycle Manager」を選択して、ポリシーを作成します。
ポリシーの選択
今回は手軽に作成できるデフォルトポリシーを作成します。
IAMロールの選択
IAMロールはデフォルトロールを利用します。
AMI作成頻度と保持期間の設定
「作成頻度」で、ポリシーを実行してインスタンスから AMI を作成する頻度を指定します。このポリシーは、指定した作成頻度内にバックアップされていないインスタンスからのみAMIを作成します。
たとえば、作成頻度を 1 日間に指定した場合、ポリシーは、過去 1 日以内にバックアップされていないインスタンスからのみAMI を作成します。バックアップ取得の開始時刻は指定できません。今回は作成頻度を1日としておきます。
「保存期間」で、ポリシーが作成した AMI を保持する期間を指定します。この期間を経過すると、AMIは自動的に登録解除され、関連するスナップショットは削除されます。今回は7日としておきます。
AMI取得が不要なEC2インスタンスがあった場合は必要に応じて除外パラメータを設定します。今回はそのまま先へ進みます。
オプション設定
詳細オプションは必要に応じて設定しますが、今回は「インスタンスからタグをコピー」にチェックを入れておきます。
最後に「デフォルトポリシーを作成」をクリックして完了です。このようにData LifeCycle Managerのデフォルトポリシーは簡単な設定で実装可能です!
動作確認
1日後、AMIのコンソール画面を見ると、デフォルトポリシーの実行によってAMIが作成されていました
AMI作成の成功/失敗、AMIの登録解除の成功/失敗については、Data LifeCycle Manager のポリシー詳細画面からCloudWatchメトリクスで確認できます。
まとめ
以上、Amazon Data Lifecycle Managerを利用したEC2インスタンスのバックアップ自動化の手順について解説しました。
DLMを活用することで、バックアップ作業がシンプルになり、システムの信頼性も高まります。頻繁なバックアップや複数リソースの管理が必要な方には、DLMの導入が非常に効果的です。これを機に、バックアップの自動化を始めてみましょう!
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
2019/12〜2023/2までクラウドインテグレーション部でお客様のAWS導入支援を行っていました。現在はIE(インターナルエデュケーション)課にて採用周りのお手伝いや新卒/中途オンボーディングの業務をしています。2023 Japan AWS Top Engineers/2023 Japan AWS Ambassadors