Rails + SQLServer 航海日誌:実際に運用している編

実際にSQLServerRailsを利用して、アプリケーションを運用した知見をまとめておく。 この記事の続き。

webuilder240.hatenablog.com

いきなりまとめ

  • DB周りで何か問題あったとすればMySQLとの違いはユニーク制約の違いくらい.
  • 逆に言えば他でハマるようなことはなかった。
  • 1年近くこの構成で5〜6個近いアプリケーションを運用しているが、特にDB起因での障害とかで大きなものはいまのところはない*1
  • AzureでMySQL / PostgresqlのRDSっぽいサービスがリリースされたので、AzureからSQLServer一択ということではなくなり旨味がかなり減った。
  • 前回話していたSQLServer for LinuxをDockerで利用すれば開発環境のDBも困らない状態に。
  • 動作スピードについては未検証・未計測だが大きな差異はないと思ってる。
  • MySQLSQLServerを両方をメンテするのは辛いので、事情がなければサポートするRDBMSは1つだけにしたほうがいい。
  • 最近は特に事情がなければ、Azure Database for MySQLを基本的には使ってる。

Azure Database for MySQL / PostgreSQLについて

まずはこの一番大きなトピックからです。 みなさんご存知かと思いますが、かねてから噂されていたサービスがPreviewですがリリースを発表しました。

azure.microsoft.com

こちらもDB無停止でのスケールアップが可能なので、AzureでSQLServerを利用する理由が1つ減ってしまったように感じています。 まぁSQLServerに比べると割高なのは否めないですが… 現状MySQL / PostgreSQLで動かしているようなサービスの場合は、こちらに移行させるのが一番いいと思います。*2

PHPアプリケーションサーバーをWebAppsで幾分ラクラクに運用できることを考えても、 大型WordPressを運用する環境でAzureも検討材料の1つとして候補になるのではないかなーと思っています。

ただし、AWSでいうRDS相当なので性能がAuroraくらいのものかというとそういうわけではないです。

開発DBについて

DockerでSQLServerを運用できるということは前回軽く話していたけど、 実際に試してみて問題なく使えそうなので、現在開発環境のDBとして利用しています。 あとはCIをSQLServerでも回したかったので、そちらでもMSSQL Dockerを使っています。

CircleCIでSQLServerMySQLでテストを回している話

まだCircleCI1.0を利用している勢なのですが、現在開発中のアプリケーションでは両方のRDBMSでテストを回しています。 この辺については少し旬が過ぎてしまった感もあるのですが、また今後ブログにしたいと思います。

そもそも複数のRDBMSをサポートするのしんどい話

弊社ではまだまだプロダクトの中でそこまで分析系のクエリを書いていないので、まだまだマシだと思っているけど、 union allはどうしてもActiveRecordでは使えない(複雑なArelのコードを書くことで実現できるだろうが、どっちにしろメンテコストは高くつく)ので、 基本的には生でSQLを書かなければ行けないと思ってて、そういう箇所が数箇所だけある。

そこに関してはどうしてもSQLServerMySQLでは使用できるSQL文に多少違い・挙動の違いが存在するので、どうしてもコードをMySQLSQLServerで分けて書くということをしなくてはならない。 とは言え、自分は生SQLが得意なエンジニアではないのを自覚しているし、いまのところは2箇所で済んでいるけど、コレが増えるとまずいなぁとも感じている。 そもそもダッシュボードの項目部分だったり、分析クエリに関してはRDBMSではなくTresureDataなどの分析基盤などを別途利用した方が良さそうな感じはしている。

さいごに

  • 複数のRDBMSをサポートするのしんどいし、サービスとしてそこまでメリットがないと思っているので、SQLServerのサポートはすっぱり捨てて全部MySQLにまとめたいですね。

*1:Solidus使っててなにかバグ引いた人はいたっぽいけど...

*2:かなり翻弄されてしまっている感が…