バックアップは、理解はできるけど腹落ちしにくい存在です。
その後の影響を直に体験するか、その影響を知識と想像力を以てリスクとして受容することでしか、その重要性に気づくことはできません。
そんなバックアップですが、いざバックアップを取ろうとしても一体どうするのが最適なのか、よくわかりません。
そこで今回はAWS公式のベストプラクティスに従ってバックアップを実装します。
特に、EC2とRDSのバックアップ・復元のハンズオン、そしてAWSにおけるバックアップを自動化するサービスを一部ご紹介します。
■バックアップの意義とユースケース
そもそもですが、バックアップは定例バックアップと非定例バックアップに分けられます。
・定例バックアップ
定例バックアップは例えば日々の業務運用で変化し続けるデータを定期的に保存しておき、データ損失やシステム障害の発生に対して対処できるように取るものです。
定期的で定型的な作業なので、自動化が可能です。
・非定例バックアップ
非定例バックアップはその逆で、システムのアップグレードやデータベースの構造変更など大規模な変更作業を行いたいときに、仮に変更作業で問題が起きた場合や変更結果が期待通りでなかった場合に戻せるように取るものです。
非定期的で非定例的な作業なので、自動化はトリガーを明確に定義できる場合などの条件下に限られるでしょう。
今回のハンズオンは非定例を想定しているため、手動で行なっていきます。
■EC2とRDSのバックアップ・復元方法
EC2とRDSではバックアップの方法が異なります。
・EC2の場合
EC2のバックアップにはAMIを作成する方法と、EBSのスナップショットを利用する方法があります。これはAWS公式ドキュメントで紹介されているものです。
以下にそれぞれの違いを記述しました。
| バックアップ・復元方法 | 具体的なやり方 | バックアップ作成時の挙動 |
|---|---|---|
| AMIを利用 | AMIから新しいインスタンスを起動 | EBS又はインスタンスストアのスナップショットに加え、ブロックデバイスマッピング（ルートデバイスやブロックデバイスの指定設定）などが含まれます。 |
| EBSのスナップショットを利用 | スナップショットからEBSボリュームを作成し、EC2インスタンスにアタッチ | S3バケットに保存される。初回のバックアップではボリュームを完全にコピーし、その後は差分コピーになります。 |
・RDSの場合
RDSのバックアップにはDBスナップショットを利用する方法があります。こちらもAWS公式ドキュメントで紹介されています。
詳しくは以下のハンズオンでご紹介します。
■ハンズオン
下準備
特に重要な設定項目を記載しています。その他は柔軟に対応してください。
VPC作成
EC2とRDSを作成するためのVPCを作成していきます。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| AZの数 | 3 | RDSも作成するので、AZを３つ確保しておきます。 VPCはアクティブなENIに対して課金されます。 VPCを作成しただけでは課金されません。 |
| パブリックサブネットの数 | 3 | AZには最低限１つのサブネットを置く必要があります。 最低限置いておきます。 |
| プライベートサブネットの数 | 3 | AZには最低限１つのサブネットを置く必要があります。 最低限置いておきます。 |
IAM作成
EC2にSSMで接続できるよう設定していきます。
IAMのコンソール画面からロール→ロールを作成をクリック。以下の画面になることを確認します。
以下を設定します。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| 信頼されたエンティティタイプ | AWSのサービス | EC2にアタッチするものなのでAWSのサービスを選択します。 |
| ユースケース | EC2 | EC2にアタッチするため。 |
| 次へ | 右下の次へをクリックしてください |
– |
| 許可ポリシー | AmazonSSMManagedInstanceCore | SSM接続をできるようにするロールです。 |
| 次へ | 右下の次へをクリックしてください |
– |
| ロール名 | 適当な値 | 後で見てわかる名前を設定してください。 |
| 説明 | 適当な値 | 適当な値を入力してください。 |
| ロールを作成 | 右下のロールを作成をクリックしてください |
– |
以上でIAMロール作成完了です。
セキュリティグループ作成
EC2用SG
| タイプ | ソース | 説明 |
|---|---|---|
| SSH | MYIP | SSMで接続できなかった場合に念のため設定しておきます。 |
RDS用SG
| タイプ | ソース | 説明 |
|---|---|---|
| MYSQL/Aurora | EC2用SG | EC2からRDSに接続できるよう設定しておきます。 |
EC2作成
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| AMI | Amazon Linux 2023 | なんでもいいですが、SSM agentがプリインストールされているものだとSSMの設定が楽です。 |
| サブネット | いずれかのパブリックサブネット | |
| パブリックIPの自動割り当て | 有効化 | SSM agentがプリインストールされていれば不要ですが、SSHでのトラブルシュートのために設定しておきます。アクティブなENI１つにつき、0.00027USD/時かかるので注意してください。 |
| セキュリティグループ | EC2用SG | 先ほど作成したものをアタッチしてください。 |
| IAMインスタンスプロフィール | 先ほど作成したIAMロール | 先ほど作成したIAMロールをアタッチしてください。 |
以上設定できたら作成してください。数分待った後、セッションマネージャーで接続できることを確認してください。
RDS作成
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| エンジンタイプ | MySQL | EC2と同様、どれでもいいですが、検証の統一のためMySQLを選択します。 |
| テンプレート | 無料利用枠 | 無料利用枠を選択すると強制的に単一AZでバースト可能のインスタンスクラスが選択されます。 |
| マスターパスワード | 適当な値 | 後でEC2からRDSに接続する際に必要です。 |
| コンピューティングリソース | EC2コンピューティングリソースに接続 | RDSがEC2を認識できるよう設定します。 |
| EC2インスタンス | 先ほど作成したEC2インスタンス | DBサブネットグループに含めるEC2インスタンスの選択です。 |
| DBサブネットグループ | 自動セットアップ | DBサブネットグループを自動で作成してもらいます。 |
| セキュリティグループ | RDS用SG | 先ほど作成したSGをアタッチします。 |
以上が設定できたら作成してください。作成には少し時間がかかります。
・EC2のバックアップ・復元ハンズオン
準備
▼検証用ファイルの作成
SSMで接続して、検証用ファイルを作成します。
接続できたら、以下のコマンドを実行して検証用のファイルを作成します。リストア後にこのファイルが確認できれば、リストアの検証完了とします。
cd /home/ssm-user
sudo mkdir backup_test
sudo chown -R ssm-user:ssm-user ./
sudo echo Success! > backup_test/bk_test.txt
以下を入力し、
sudo cat /home/ssm-user/backup_test/bk_test.txt以下が表示されれば検証ファイルの作成完了です。
Success!AMIバックアップでの検証
▼バックアップの取得
マネジメントコンソール画面で、「EC2」の画面を開き、ナビゲーションから「インスタンス」を開きます。
先ほど作成したインスタンスを選択し、「アクション」→「イメージとテンプレート」→「イメージを作成」と順にクリックしていきます。
「イメージを作成」画面では以下の項目を設定します。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| イメージ名 | 適当な値 | 名前を入力してください。 |
| イメージの説明 | 適当な値 | オプションなので、不要であれば空白で構いません。 |
| 再起動しない | □有効化 | チェックをしていない状態だと、AMI作成の際に再起動をします。 AWSからの自動再起動で都合が悪ければ手動で停止しても大丈夫です(※)。 |
| サイズ | 適当な値 | ストレージのサイズです。 |
| 終了時に削除 | ■有効化 | チェックをすると、インスタンスを終了した際にボリュームを削除します。 |
※チェックをつけて停止せずに行うこともできますが、その場合は、実行されているプロセスに一貫性が失われ、ファイルシステムの整合性が保証されないので、ご注意ください。
最後に、ナビゲーションから「AMI」を開いて、作成したAMIがあることを確認します。
こちらのAWS公式ドキュメントを参照しました。
▼リストア
ナビゲーションから「AMI」を開き、目的のAMIを選択してください。
AMIを選択すると、「AMIからインスタンスを起動」とオレンジ色の背景に黒字のボタンが表示されるのでクリックします。
後は、通常のEC2インスタンス作成と同様です。
▼ファイルの確認
AMIからインスタンスを起動したら、SSMで接続してください。
接続出来たら以下を入力し、
sudo cat /home/ssm-user/backup_test/bk_test.txt以下が表示されれば検証完了です。
Success!スナップショットバックアップでの検証
先ほどのAMIによるバックアップより複雑なので構成図を載せておきます。
▼バックアップの取得
マネジメントコンソール画面で、「EC2」の画面を開き、ナビゲーションから「ボリューム」を開きます。
「アタッチされたインスタンス」列から自身のインスタンスを探します。
該当するボリュームを選択し、「アクション」→「スナップショットの作成」の順にクリックします。
以下を設定して、「スナップショットの作成」をクリックします。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| 説明 | 適当な値 | オプションなので、不要であれば空白で構いません。 |
ナビゲーションから「スナップショット」を開き、スナップショットが作成されていることを確認します。
▼リストア
下準備で作成したEC2インスタンスと同じ設定で、もうひとつEC2インスタンスを作成しておいてください。EC2インスタンスbとします。
ナビゲーションから「スナップショット」を開き、目的のスナップショットを選択してください。
「アクション」→「スナップショットからボリュームを作成」又は「スナップショットからイメージを作成」を選択してください。
「スナップショットからボリュームを作成」を選択した場合、以下を設定し、「ボリュームの作成」をクリックしてください。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| サイズ | 30 | 無料利用枠で設定しています。 |
| ボリュームタイプ | 汎用SSD(gp3) | コスト効率のいいgp3を選択しました。 |
| アベイラビリティゾーン | 適当な値 | 配置したいAZを選択してください。 |
| 暗号化 | □このボリュームを暗号化する | 今回はファイルの検証ができればいいので暗号化は不要です。 |
先ほど作成したEC2インスタンスbを停止してください。
ナビゲーションから「ボリューム」を開き、EC2インスタンスbにアタッチされているボリュームを選択して「アクション」から「ボリュームをデタッチ」を選択します。
デタッチできたら、先ほど作成したボリュームを選択して「アクション」から「ボリュームをアタッチ」を選択し、EC2インスタンスbにアタッチします。
「スナップショットからイメージを作成」を選択した場合、以下を設定し、「イメージの作成」をクリックしてください。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| イメージ名 | 適当な値 | 名前を入力してください。 |
| 説明 | 適当な値 | 何らかの説明を入力してください。 |
| アーキテクチャ | x86_64 | EC2作成時と同様です。 |
| ルートデバイス名 | /dev/xvda | ルートボリューム用に予約されているデバイス名です。EC2のデフォルトに合わせて/dev/xvdaにしています。 |
| 仮想化タイプ | ハードウェアアシストの仮想化 | EC2でいうhvmです。 |
| カーネルID | デフォルトを使用 | AMIのデフォルトではカーネルIDは設定されません。 |
| RAMディスクID | デフォルトを使用 | AMIのデフォルトではRAMディスクIDは設定されません。 |
| ブートモード | デフォルトを使用 | AMIのデフォルトではブートモードは設定されません。 |
| ブロックデバイスマッピング-オプション | – | – |
| サイズ | 30 | 無料利用枠で設定しています。 |
| ボリュームタイプ | 汎用SSD(gp3) | コスト効率のいいgp3を選択しました。 |
| 終了時の動作 | ■終了時に削除 | チェックをすると、インスタンスを終了した際にボリュームを削除します。 |
作成できたらナビゲーションから「AMI」を開き、先ほどAMIでリストアをした場合と同様に設定します。
▼ファイルの確認
インスタンスが正常に起動したら、SSMで接続してください。
接続出来たら以下を入力し、
sudo cat /home/ssm-user/backup_test/bk_test.txt以下が表示されれば検証完了です。
Success!・RDSのバックアップ・復元ハンズオン
準備
▼EC2インスタンスにMySQLをインストール
下記を実行してMySQLをインストールしてください。
sudo dnf install mariadb105-server下記を実行して
mysql --version下記のようなバージョンが表示されればインストール完了です。
mysql Ver 15.1 Distrib 10.5.18-MariaDB, for Linux (x86_64) using EditLine wrapper▼テスト用のDB作成
EC2からRDSに以下のコマンドで接続してください。
mysql -h RDSエンドポイント -u ユーザー名 -p以下を順に実行して、データベース、データテーブル、データレコードを作成します。
・データベース作成
CREATE DATABASE test_db;・データベース選択
USE test_db;・データテーブル作成
CREATE TABLE test_tb (
id INT AUTO_INCREMENT,
test VARCHAR(10),
PRIMARY KEY(id)
);・データレコード作成
INSERT INTO test_tb (test) VALUES ('Success!');それでは以下を入力して、データレコードが作成されていることを確認します。
SELECT * from test_tb;以下のような結果が出れば、検証用レコード作成完了です。
検証
▼バックアップ
コンソール画面から、Amazon RDS コンソール を開きます。
「データベース」を開き、先ほど作成したインスタンスを選択してください。
「アクション」→「スナップショットの取得」と順にクリックします。
スナップショット作成の画面が表示されるので、以下を設定してください。
| 設定項目 | 設定値 | 説明 |
|---|---|---|
| DBインスタンス | 先ほど選択したDBインスタンス | 既に選択されているはずです。 |
| スナップショット名 | 適当な値 | 名前を入力してください。 |
設定出来たら「スナップショットの取得」 を選択してください。
▼リストア
ナビゲーションから「スナップショット」を開いてください。
先ほど作成したスナップショットが作成されたら選択して、「アクション」→「スナップショットの復元」をクリックしてください。
作成直後は、「アクション」を選択してもメニューが十分に表示されないかもしれません。その際は5分ほど時間をおいてから再度行ってください。
「スナップショットの復元」をクリック出来たら、通常と同じRDSインスタンス作成画面が表示されます。先ほどインスタンスを作成した時と同様に作成してください。
▼データベースの確認
EC2からRDSに以下のコマンドで接続してください。
mysql -h RDSエンドポイント -u ユーザー名 -p接続出来たら、以下のコマンドを実行して、データベースやレコードが確かに同じであることを確認します。
SELECT * from test_db.test_tb;以下のような結果が出れば、検証完了です。
■バックアップを自動化するサービス
冒頭でバックアップの自動化に軽く触れました。バックアップは適切な手順で行わないと、最悪本体のデータに影響を及ぼす可能性もあります。できれば自動化したいですね。
AWSではバックアップの自動化サービスが多数提供されています。
今回は、Amazon Data Lifycycle Manager, RDS自動バックアップ、AWS Backupという３つのサービスをご紹介します。
・Amazon Data Lifecycle Manager (DLM)
概要
DLMの公式ドキュメントから引用しました。
Amazon Data Lifecycle Manager を使用して、EBS スナップショットと EBS-backed AMI の作成、保持、削除を自動化できます。スナップショットと AMI 管理を自動化すると、次のことができるようになります。
- 定期的なバックアップスケジュールを実施して貴重なデータを保護する。
- 定期的に更新できる標準化された AMI を作成する。
- 監査担当者または社内のコンプライアンスが必要とするバックアップを保持する。
- 古いバックアップを削除してストレージコストを削減する。
- 分離されたアカウントにデータをバックアップする災害対策バックアップポリシーを作成する。
Amazon Data Lifecycle Manager を Amazon CloudWatch Events および AWS CloudTrail のモニタリング機能と組み合わせると、追加コストなしで Amazon EC2 インスタンスと個々の EBS ボリュームを完全にバックアップできます。
引用元：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/snapshot-lifecycle.html
EBSのスナップショットやEBSが使われているインスタンスのAMIを作成したり、監査や社内規定に従ったバックアップルールを運用したりする場合に効果がありそうです。
コスト
DLM自体は無料ですが、作成したスナップショットの保存にはコストが発生します。スナップショットの料金は、保存されるデータの量に基づいています。具体的な料金は、AWSの料金ページまたはEBSスナップショットの料金ページで確認できます。
・RDS自動バックアップ
概要
Amazon RDSの公式ドキュメントから引用しました。
デフォルトで有効になっている Amazon RDS の自動バックアップ機能により、データベースとトランザクションログがバックアップされます。Amazon RDS では DB インスタンスのストレージボリュームのスナップショットを自動的に作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。
このバックアップは、バックアップウィンドウと呼ばれるユーザーが設定可能な 30 分間隔の時間に 1 日 1 回行われます。自動バックアップは、お客様が設定した日数の間、保持されます (バックアップ保持期間と呼ばれます)。自動バックアップの保持期間は、最大 35 日間まで設定できます。
RDSでは自動バックアップがデフォルトで有効になっており、デフォルトだと21時から翌日7時の間からランダムで30分間が選ばれ、その30分間で自動バックアップが行われます。
ちなみにこの30分間のことを「バックアップウィンドウ」と呼び、設定により時間は変更できます。
コスト
自動バックアップもDLMと同様、追加料金は発生しません。ただし、バックアップデータの保存にはストレージが必要で、このストレージの使用量に応じて料金が発生します。バックアップ期間を長く設定すると、それだけ多くのストレージが必要になり、コストが増加します。
・AWS Backup
概要
AWS Backupの公式ドキュメントから引用しました。
AWS Backup はフルマネージド型のバックアップサービスであり、AWS のサービス、クラウド内、およびオンプレミス間で簡単に一元化およびデータ保護を自動化できます。このサービスを使用すると、1 つの場所でバックアップポリシーを設定し、AWS リソースのアクティビティを監視できます。これにより、以前に実行していたバックアップタスクは自動化および統合されるためservice-by-service、カスタムスクリプトや手動プロセスを作成する必要がなくなります。AWS Backup コンソールでの数回のクリックで、データ保護ポリシーとスケジュールを自動化できます。
AWS Backup は AWS Backup 以外の AWS 環境で取るバックアップを管理しません。したがって、ビジネスおよび法規制のコンプライアンス要件に対応する、一元化されたエンドツーエンドのソリューションが必要な場合は、今すぐ AWS Backup の使用を開始してください。
引用元：https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/whatisbackup.html
より幅広いサービスそしてオンプレで使えるバックアップ自動化サービスですね。DLMやRDS自動バックアップの上位互換サービスであり、DLMやRDS自動バックアップよりAWS Backupが推奨されます。
コスト
AWS Backupも、最低料金や初期費用は発生しません。バックアップしたデータの量と保存期間に基づき、バックアップ時やリストア時、リージョン間での転送などで料金が決まります。具体的な料金はAWSの公式ウェブサイトの料金ページを参照してください。
■サービス比較
| 項目 | Amazon Data Lifecycle Manager | RDS自動バックアップ | AWS Backup |
|---|---|---|---|
| 対応サービス | EBS | RDS | EC2, S3, EBS, RDS, DynamoDB, Aurora, EFS, FSx各種, Storage Gateway, DocumentDB, Neptune, Redshift, CloudFormation, 他 |
| バックアップの自動化 | ポリシーに基づく自動バックアップが可能 | デフォルトで有効。設定により自動バックアップのタイミングを変更可能 | リソースにより機能が異なるため、公式ドキュメントを参照 |
| コスト | スナップショットの保存コストが発生 | スナップショットの保存コストが発生 | スナップショットの保存コストが発生 |
まとめ
今回はEC2とRDSのバックアップと復元のハンズオンをメインに、バックアップ自動化サービスについても触れてみました。
記事を書く際に色々調べてみたのですが、思っていたよりも膨大な数のドキュメントが出てきて、正直まだまだ書くことがたくさんあります。
バックアップはストレージに直接関連するため、バックアップについてまとめているうちに、サービス自体についても詳しくなれそうです。
今回はここまで！