こんにちは、エンジニアの森脇です。
弊社では、本番DBを開発環境にコピーして開発をしています。今回は、どのような仕組みで実現しているかを紹介します。
なぜ本番DBを利用するか
cookpad様の記事でも言及されていますが、弊社でも全く同じ認識を持っており、下記理由で本番DBを利用しています。
- ユーザと同等体験での開発
- パフォーマンス問題の早期発見
- データ依存不具合の早期発見
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
当初の運用
元々は、サーバへのログイン権限があるメンバーが、本番DBバックアップファイルを取得し、手動でリストアするという運用でした。工数もかかり、特定メンバーに依存するため、各メンバーが必要なときにすぐ準備できないため、誰でも準備できる仕組みを用意しました。
仕組みの概要
ローカル環境のShellを叩くと、本番DBのバックアップファイルを取得し、ローカル環境にリストアする仕組みです。cookpad様のような常に本番データが同期される仕組みではありません。( 今のところそこまでの必要性は感じていません。)
本番DB ----> バックアップサーバ ----> ローカル環境
各ポイントについて少し詳しく説明します。
DBのバックアップ
PostgreSQLを利用しているため、pg_dumpを利用してバックアップを取得します。 バックアップ取得後に、一度バックアップサーバ上でリストアし、ログデータなどのデータ量が大きいテーブルのレコードを間引く処理をしています。その後再度dumpを取得します。
弊社では今のところ個人情報は扱っていないのですが、個人情報を扱うようになった場合は、ここでマスキング処理を行う予定です。
ローカル環境からバックアップファイル取得
バックアップサーバ上にWebサーバを立てて、ローカルにバックアップファイルを返す簡易アプリケーションを配置しています。 ローカルからwget等のコマンドを叩くと、指定された条件に応じたバックアップファイルを取得できます。
※ 本番DBだけではなく、テスト環境のDBや、特定日付のバックアップも取得できるようにしています。
ローカルDBへのリストア
バックアップファイルを取得すると、以下の処理を行いリストアします。
- ローカルDBに接続しているセッションを全て切断
- ローカルDBをdropする
- ローカルDBをcreateする
- 取得したバックアップファイルをリストアする
なお、pg_restore時には、jobsを渡すと並列でリストアを行うことができ高速化ができます。（適切な値は環境によって変わります)
pg_restore -v -d localdb --jobs=4 /tmp/backup.custom
以上が簡単な仕組みの流れです。バックアップ対象DBにもよりますが、早ければ1,2分でローカルに本番DB環境を準備できます。
まとめ
バックアップはいざ必要になったときに、うまく取得できていなかった・リストアができない(やり方がわからない）等の問題が発生することがあります。 定期的に本番DBのバックアップをリストアすることは、正しくバックアップが取得できているという確認にもなり、精神的にも安心できますので、是非おすすめします。
