複数のDBにまたがるRailsの運用方法まとめ #Rails

Railsはデフォルトでは一つのアプリケーションに対して一つのデータベースが対になってますが、サービスを運用している過程で他のサービスで使われているDBに跨った実装をしたくなります(APIを生やせばいいじゃんというツッコミは無しで)。

今回はそんな場合にどうRailsで対応するかについてまとめてみました。

どうやるか

以下ではデフォルトのDBをMainDB、他のサービスで使われているDBをSubDBとし、
database.ymlに定義された設定は下記とします。

default: &default
  adapter: mysql2
  encoding: utf8
  pool: 5

development:
  <<: *default
  host: hoge
  database: hoge
  username: hoge
  password: hoge

development_sub:
  <<: *default
  host: fuga
  database: fuga
  username: fuga
  password: fuga

test:
  <<: *default
  host: foo
  database: foo
  username: foo
  password: foo

test_sub:
  <<: *default
  host: bar
  database: bar
  username: bar
  password: bar

~production, stagingも同様

DBの生成

SubDBからdumpしたsqlテーブル定義ファイルをdbディレクトリの下に置きます。

rails_app
├─ app
├─ db ── migrate
│  ├──── schema.rb
│  ├──── seeds.rb
│  ├──── sub_db.sql

そしてlib/tasksの下にsb_db.sqlを実行するためのrakeタスクを設定します。

namespace :sub do
  task :set_sub_config do
    require 'active_record'
    @config = YAML.load_file(Rails.root.join('config', 'database.yml'))
    @structure_path = Rails.root.join('db', 'sub_db.sql')
    @db = ActiveRecord::Tasks::MySQLDatabaseTasks.new(@config["development_sub"])
  end

  namespace :db do
    task create: :set_sub_config do
      @db.create
    end

    task structure_load: :set_sub_config do
      @db.structure_load(@structure_path, nil)
    end

    task drop: :set_sub_config do
      @db.drop
    end
  end
end

set_sub_configは何をしているかというと、active_recordにdatabse.ymlの中の必要な設定を渡す操作をしています。set_sub_configにdevelopmentかtestといった引数を渡して@config["#{arg}_sub"]といった分岐処理を書いてもいいかもしれません。

active-recordに設定を渡したあとは、dbの名前空間でデータベースの操作をします。
rails sub:db:createでSubDBのデータベースを作成し、
rails sub:db:structure_loadでテーブルを作成し、
rails sub:db:dropでデータベースを削除します。

今回はMySQLが接続先として想定しているためMySQLDatabaseTasksからDB操作メソッドを呼んでいますが、PostgreSQLが接続先の場合は、PostgreSQLDatabaseTasksを指定してください。

modelとの連携

class Sub < ActiveRecord::Base
  self.abstract_class = true
  establish_connection("#{Rails.env}_sub".to_sym)
end

class Sub::Account < Sub
end

modelに接続先DBをSubDBに切り替えたクラスSubを作り、接続先がSubDBのmodelは全てこのSubを継承するようにして作成します。

テスト環境のための設定

主にFactoryGirlとDatabaseCleanerについての設定です。
MainDBにつなぐAccountモデルと、SubDBにつなぐSub::Accountモデルがあるとします。

FactoryGirl.define do
  factory :account do
  end
end

FactoryGirl.define do
  factory :sub_account, class: Sub::Account do
  end
end

通常はクラス名＝ファクトリ名なのでaccountモデルに対応するファクトリ名は:accountとなるのですが、上記のようにSubDBにつなぐ側には明示的にclass名を指定してあげてください。

また、SubDB側にマスターデータがある場合、毎テスト毎にマスターデータを再構築するのは効率が悪いので、DatabaseCleanerの操作をスキップする必要があります。

以下のコードははSubDBのaccountsテーブルにマスターデータがあるという想定のもとでDatabaseCleanerの設定をしています。

config.before(:suite) do
  DatabaseCleaner.strategy = :truncation
  DatabaseCleaner[:active_record, connection: :sub_test].strategy =
    :truncation, { except: [:accounts] }
  FactoryGirl.reload
end

config.around(:each) do |example|
  DatabaseCleaner.cleaning do
    example.run
  end
end

まとめ

開発環境で気軽にDBを再構築できるようになったり、E2Eでテスト管理できるようになり、開発上の負担が大変減りました。
また、こちらの方々のように

といった方法も検討して良いかもしれません（自分の場合は他サービスのDBのほんの一部のみ使うことを想定していたため大味すぎると判断し見送りました）。