目次
AWSのサービス縛りでコスト最適で弾力性のあるLaravelアプリケーションのインフラを作ろうという企画の5日目です。
今回は、AWS Backupというサービスを活用して、EFSとRDSのバックアップを取得してリストアする所までやってみたいと思います。
ちなみにやりたい事の一覧は以下の通り(破線は完了した物)
アプリケーションサーバの構築(1日目)ビルド・デプロイの自動化(1日目)RDBに接続できる(2日目)cronを使える様にする(Laravelのタスクスケジュールのトリガー)(2日目)HTTPS対応(3日目)storageフォルダにシンボリックリンクを作成する(3日目)storageをEFSに置き換える(3日目)フロントのリソースの自動ビルド(node, npm)に対応(4日目)アプリケーションサーバのオートスケール(4日目)- ストレージ(EFS)のバックアップ/リストア
- RDSのバックアップ/リストア
- テストの自動化
- Redisに接続できる
- リソースをCDNから配信する
- RDSの容量のオートスケール
- ビルド完了時のslack通知
- System Managerでシステムを可視化してみたい
- Inspectorで脆弱性チェックを受けてみたい
EFSのバックアップ/リストア
EC2のインスタンスはBeanstalkによって作成&破棄されるのでEBSのバックアップについては触れません。
第3回で/storage
フォルダのみEFSに逃したので、EFSのバックアップ/リストアをやってみます。
AWS Backupというサービスを利用してバックアップできるらしい
バックアッププランを作成する
分からない言葉がいくつかあるので意味を調べる🧐
- バックアップウィンドウ
- バックアップが開始される時間帯。
- バックアップに時間が掛かる場合、バックアップウィンドウに割り当てられた時間を超えてバックアップが継続するケースもある。
- ライフサイクル
- 作成から経過した日数に応じて、低コストのストレージに移したり削除したりする機能
- バックアップボールト
- バックアップボールトはバックアップを整理するためのコンテナ
- バックアップボールト単位で暗号化キーやアクセスポリシーを付与できる
バックアッププランが作成できた。
リソースを割り当てる
1つのバックアッププランで複数のリソース(EBSやRDS、EFS)のバックアップができるらしい。
ここではEFSのインスタンスを対象にする
任意のタイミングでトリガーできないのか?
「バックアッププラン」と「オンデマンドバックアップ」があり、後者が任意のタイミングでのバックアップらしい
さっそく試してみる
バックアップの履歴を確認する方法は?
「ジョブ」ページで確認できる。
バックアップが取得できている事がわかる🤘
試しにリストアしてみる
EFS上に適当にデータを作成する。
リストアしてtest.txt
が消えていればリストアが成功している
「保護されたリソース」からリストアを実行する
リストアの進捗は「ジョブ」の「ジョブを復元」タブで確認できる
リストアが終わったので/storage
フォルダを確認してみる👀
新しいフォルダが作成されて、その中にバックアップしたファイルが展開されていた。
今あるファイルがまるっと入れ替わる訳ではないらしい。
なのでtest.txt
ファイルは消えずに残っている
フォルダの中にリストアされるらしい。
「新しいファイルシステムに復元する」とは?
バックアップをリストアする時のオプションで「新しいファイルシステムに復元する」という選択肢がある
これを試してみる
EFSに新しくインスタンスが作成された。
新しいEFSインスタンスをマウントしてみる。.ebextensions/storage-efs-mountfilesystem.config
のファイルシステムIDを書き換えてプッシュする
option_settings:
aws:elasticbeanstalk:application:environment:
FILE_SYSTEM_ID: '[ファイルシステムID]'
MOUNT_DIRECTORY: '/efs/storage'
EFSのマウントに関してはBeanstalkのインスタンスを再起動しないと反映されないので再起動する
マウントされたEFSインスタンスの内容を見てみる。
あぁ、新規インスタンスを作成した場合もフォルダに入っちゃうんですね・・・。
新規インスタンスの場合は、フォルダに入れずに直接展開してくれた方がマウントを切り替えるだけでリストアできるので復旧の手間が減るのだが・・・🤔
ところで、リストアされたフォルダの中にあるaws-backup-lost+found_...
というフォルダは何なのだろう?
調べてみた所、ドキュメントに以下の記述があった。
適切なディレクトリに復元できないファイルと、バックアップ中に変更されたファイルがここに入るという事だろうか・・・?
適切なディレクトリに復元できないデータフラグメントは、
https://docs.aws.amazon.com/ja_jp/efs/latest/ug/awsbackup.html#restoring-backup-efsaws-backup-lost+found
ディレクトリに配置されます。バックアップの実行中にファイルシステムに変更が加えられると、フラグメントがこのディレクトリに移動される場合があります。
EFSのバックアップ&リストアはこんなもんかなー。
RDSのバックアップ/リストア
RDSの場合も前章と同じようにAWS Backupを活用する
RDSのバックアップを取得してみる
RDS特有の設定などは特にないらしい。
バックアップが取得できた。
リストアしてみる
RDSの場合、インスタンスが新規作成されて、そこにリストアされるらしい
実際にやってみる
インスタンスが作成された
リストアが成功しているか確認するためにアプリケーション上から画像を差し替えた(犬→人)
正しくリストアできていれば犬の画像が表示されるはず。
Beanstalkの環境変数を変更する(参照先のDBインスタンスを切り替える)DB_HOST
を新しいRDSインスタンスのホスト名に変更した
アプリケーションを開いてリストア出来ているか確認する
ちゃんと犬の画像が表示された
以上!
所感
AWS Backupを使えば、バックアップを一括管理できるのが最高にクールですね〜〜!🙆
リストアも簡単なのが嬉しすぎますね!
欲を言えばEFSを新規インスタンスとしてリストアした時にファイルを展開しておいて欲しいぐらいですかね〜
まぁでもEFSを全リストアする事はあまりなさそうだから問題ないのかも。
Webエンジニアをやっています
UX/UIデザインからプログラミング、DB設計、SEO、インフラ構築など幅広く対応してます
PHP/PHPUnit/Laravel/Vue/Nuxt/Docker/Terraform
ご連絡はTwitterのDMまで。