はじめに
個人開発しているTaskLinkをAWS EC2上で運用しています。
本番環境を構築した後、
- EC2が故障したら？
- 誤ってデータを削除したら？
- PostgreSQLが壊れたら？
という不安がありました。
そこで、
- PostgreSQLバックアップ自動化
- AWS S3への保存
- 復元テスト
まで実施したのでまとめます。
構成
今回構築した構成は以下です。
PostgreSQL
↓
pg_dump
↓
cron
↓
S3
↓
90日後自動削除（Lifecycle）
また、アクセスキーを利用せず、EC2にIAM Roleを付与する構成にしました。
バックアップスクリプト
pg_dumpを利用してバックアップを取得します。
#!/bin/bash
DB_NAME="tasklink_production"
BACKUP_DIR="./backups"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
FILE_NAME="tasklink_backup_$DATE.sql"
mkdir -p $BACKUP_DIR
sudo -u postgres pg_dump $DB_NAME > $BACKUP_DIR/$FILE_NAME
gzip $BACKUP_DIR/$FILE_NAME
aws s3 cp \
$BACKUP_DIR/$FILE_NAME.gz \
s3://tasklink-backups/
echo "Backup created and uploaded: $FILE_NAME.gz"
cronで自動化
毎日3:00にバックアップが実行されるよう設定しました。
crontab -e
0 3 * * * /home/ubuntu/tasklink/backup.sh >> /home/ubuntu/tasklink/backup.log 2>&1
IAM Roleを利用
当初はAccess Keyの利用を考えていましたが、
- キー管理が必要
- 漏洩リスクがある
ため、EC2にIAM Roleを付与する構成へ変更しました。
これによりAWS CLIから自動的に認証されるため、アクセスキーをサーバへ保存する必要がありません。
S3ライフサイクル設定
バックアップが増え続けることを防ぐため、
- 90日後に自動削除
するライフサイクルルールを設定しました。
復元テスト
バックアップは取るだけでは意味がないため、実際に復元できるか確認しました。
まずS3からダウンロードします。
aws s3 cp \
s3://tasklink-backups/backup.sql.gz \
.
解凍後、
gunzip backup.sql.gz
テスト用DBを作成して復元します。
sudo -u postgres createdb tasklink_restore_test
sudo -u postgres psql \
tasklink_restore_test \
-f backup.sql
復元後にテーブルとデータ件数を確認しました。
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM tasks;
SELECT COUNT(*) FROM teams;
結果
- users: 5件
- tasks: 23件
- teams: 4件
本番データが正常に復元されることを確認できました。
学んだこと
今回の作業で、
「バックアップは取るだけではなく、復元できることを確認して初めて意味がある」
ということを学びました。
また、
- cronによる自動化
- IAM Roleによる安全な認証
- S3ライフサイクルによる運用管理
など、アプリ開発だけでは得られない運用面の知識も学ぶことができました。
おわりに
個人開発でも本番運用を意識すると、アプリ開発以外にも学ぶことが多くあります。
今後はCloudWatchによる監視や障害通知も導入して、より実運用に近い構成を目指したいと思います。