ボクココ

個人開発に関するテックブログ

データベースの移設をやって感じた大事なこと

ども、@kimihom です。

今回は運用ネタ。API で使っていたデータベース (Compose MongoDB) の無料プランがなくなるという告知が終了の2週間前にメールで届くっていう事態になった。てことで慌てて他のデータベースを探し、移設することになった。もちろん、その指示通りにお金払ってアップグレードするっていう方法もあったけど、それで毎月結構な金額を支払うよりは他のに移した方がコスパが良かったと判断した。

その API でのデータベースは MongoDB を使っていた。当時の自分は MongoDB がブームで、実際に使ってみるとなかなか手に馴染んで良い技術だったので積極的に使っていた。その MongoDB の IaaS 的なサービスは、Compose MongoDBmLab MongoDB ってのがあった。どちらも無料プランがあったけど、より無料プランの制限が甘い Compose MongoDBを利用していた。

それがなくなるってんで、慌てて mLab MongoDB を調べてみたんだけども、こっちはまさかのコレクション辺り 1000 ドキュメントまでしか保存できないという制約があり、断念。これはもう MongoDB から離れるしかないな、と判断した次第である。

今回の記事では MongoDB -> PostgreSQL への移設でやったことについてまとめる。 Heroku Postgres は、やっぱり素晴らしい。

バージョンアップ

そもそも MongoDB を触ることも久々だったので、当然諸々のバージョンが古かった。ってのでまずはそれぞれを最新にアップデートして動くことを確認した。これ自体は特に問題になることはなかった。ついでに Rails も 4.0.0 だったのを 4.2.6 へ上げておいた。

これでひとまず最新版としてデプロイした。

テストを整備

今回の話だとテストコードはめちゃめちゃ重要になる。現在も呼び出されている API であるということ、そして DB を切り替えても影響が出ないようにすることが要件となる。だからテストコードを書いて、コードを修正し、その上で書いたテストが全部パスしていれば切り替えても問題がないってことが保証できる。これをいちいち API で呼び出して確認するなんてことをしていたら日が暮れてしまう。

趣味で立ててた Rails API プロジェクトなので、当然(?)テストを書いていない。諸々のテスト環境を揃えて、Request Spec の正常系だけ書いた(40個くらい)。本気で運営しているサービスなら、当然もっとテストを書かないと安心はできないだろう。

んで、ここで自分がミスったのは、Request Spec で満足してしまって、 Active Model Serializers のことを考慮していなかった。これはコントローラで渡した JSON を整形するために、app/serializers の中にJSONを整理してくれる Gem だ。

一応使った test と development の Gemを挙げておく。ここら辺のは毎回使ってるのでコピペしてる。

group :test, :development do
  gem 'sqlite3'
  gem 'pry-rails'
  gem 'pry-doc'
  gem 'pry-stack_explorer'

  gem 'pry-byebug'
  gem 'pry-remote'
  gem 'pry-nav'

  gem 'better_errors'
  gem 'binding_of_caller'

  gem 'tapp'
  gem 'awesome_print'
  gem 'quiet_assets'
  gem 'rspec-rails'
  gem "factory_girl_rails", "~> 4.0"

  gem 'spring-commands-rspec'
  gem 'guard-rspec', require: false
  gem 'dotenv-rails'
end

コード修正

ようやくここまで来てコード修正ができる。裏のデータベースを変えて、テストが通るように修正すれば良いだけだ。今回は趣味プロジェクトなので大した量もないし、ロジックもシンプルだったので特に詰まるようなことはなかった。

いくつか Mongoid と ActiveRecord で書き方が違うため、そこを修正するだけだし、案外すぐに終わった。

おわりに

今回の記事で一番言いたかったのは、 こういう時のテストコードマジ大事ってこと。いつこういう移設が必要になるかはわからないので、普段から大きな変更のない Model のところ辺りから、テストを書くようにしておこう。

私は TDD 信者とかではないし、カバレッジを100%にしないととかそういう人でもない。ほどよくテストを書き、ほどよくコードを修正できるような環境が一番いいのではないかと思う。