LCL Engineers' Blog

夜行バス比較なび・格安移動・高速バス比較を運営する 株式会社LCL開発者のブログ

本番DBを開発環境に簡単にコピーする仕組み

こんにちは、エンジニアの森脇です。

弊社では、本番DBを開発環境にコピーして開発をしています。今回は、どのような仕組みで実現しているかを紹介します。

なぜ本番DBを利用するか

cookpad様の記事でも言及されていますが、弊社でも全く同じ認識を持っており、下記理由で本番DBを利用しています。

  • ユーザと同等体験での開発
  • パフォーマンス問題の早期発見
  • データ依存不具合の早期発見

開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ

当初の運用

元々は、サーバへのログイン権限があるメンバーが、本番DBバックアップファイルを取得し、手動でリストアするという運用でした。工数もかかり、特定メンバーに依存するため、各メンバーが必要なときにすぐ準備できないため、誰でも準備できる仕組みを用意しました。

仕組みの概要

ローカル環境のShellを叩くと、本番DBのバックアップファイルを取得し、ローカル環境にリストアする仕組みです。cookpad様のような常に本番データが同期される仕組みではありません。( 今のところそこまでの必要性は感じていません。)

本番DB  ----> バックアップサーバ  ---->  ローカル環境

各ポイントについて少し詳しく説明します。

DBのバックアップ

PostgreSQLを利用しているため、pg_dumpを利用してバックアップを取得します。 バックアップ取得後に、一度バックアップサーバ上でリストアし、ログデータなどのデータ量が大きいテーブルのレコードを間引く処理をしています。その後再度dumpを取得します。

弊社では今のところ個人情報は扱っていないのですが、個人情報を扱うようになった場合は、ここでマスキング処理を行う予定です。

ローカル環境からバックアップファイル取得

バックアップサーバ上にWebサーバを立てて、ローカルにバックアップファイルを返す簡易アプリケーションを配置しています。 ローカルからwget等のコマンドを叩くと、指定された条件に応じたバックアップファイルを取得できます。

※ 本番DBだけではなく、テスト環境のDBや、特定日付のバックアップも取得できるようにしています。

ローカルDBへのリストア

バックアップファイルを取得すると、以下の処理を行いリストアします。

  1. ローカルDBに接続しているセッションを全て切断
  2. ローカルDBをdropする
  3. ローカルDBをcreateする
  4. 取得したバックアップファイルをリストアする

なお、pg_restore時には、jobsを渡すと並列でリストアを行うことができ高速化ができます。(適切な値は環境によって変わります)

pg_restore -v -d localdb --jobs=4 /tmp/backup.custom

以上が簡単な仕組みの流れです。バックアップ対象DBにもよりますが、早ければ1,2分でローカルに本番DB環境を準備できます。

まとめ

バックアップはいざ必要になったときに、うまく取得できていなかった・リストアができない(やり方がわからない)等の問題が発生することがあります。 定期的に本番DBのバックアップをリストアすることは、正しくバックアップが取得できているという確認にもなり、精神的にも安心できますので、是非おすすめします。