Amazon RDS は AWS 環境に用意された RDBMS のマネージドサービスです。大規模災害にも耐えうる Multi AZ や、 MySQL, PostgreSQL に独自の拡張を行った Amaozn Aurora 等が人気で、2009年のローンチ以降、AWS のもっともよく利用されているサービスのひとつだと思います。
10年以上の歴史を持ち進化し続けてきた RDS ですが、それでもなお EC2 インスタンスに RDBMS をインストールして利用するケースがあります。そこでどのようなケースにおいて RDS を利用しない場合があったかについてまとめてみました。
RDS を使うなという記事ではありません
この記事は RDS を利用するより EC2 を利用した方が良いという結論の記事ではありません。むしろ RDS を利用する事が多いので、そうならなかったケースを紹介する記事です。
オールインワンで済む場合
ごく小さな規模のアプリケーションなら、アプリケーションサーバーとデータベースサーバーを小さなインスタンスにひとつにまとめてしまった方がコスパが良いですね。RDS への移行は利用者やアプリケーションの規模が大きくなってからでも良いでしょう。
オンプレ環境のリードレプリカ（スレーブDB）として利用したい
RDS の MySQL インスタンスは、RDS 以外のサーバーをマスタとする、リードレプリカを作る事が可能です。しかし、マスタ・スレーブ同期の通信で SSL/TLS を利用可能なのは Aurora だけです（2020年2月現在）。このため、安全な通信経路を確保できない場合、RDS を利用するのは難しくなります。VPN等、別の安全な通信手段があれば、もちろん可能です。
パフォーマンスを求めていて、かつ Aurora が利用できない
RDBMS ではすべてのデータとインデックスがオンメオリである事が理想です。しかし、実際には膨大なデータがメモリに収まり切れないケースも多々あり、そんな時はストライピングボリュームで劇的に高速化できる場合があります。クラウド環境だと単価が容量に比例するため、費用対効果も高いですね。しかし、ストライピングは RDS では選択できません。このため同価格ぐらいで性能を比較すると、EC2 で構築した MySQL の方が RDS よりはるかに速いというケースが存在します。
なお、Aurora は必要に応じてストライピングする機能が備わっているため、Aurora の方がパフォーマンスが優れているケースになる場合が多いそうです。
スポットインスタンスを利用したい場合
EC2 のスポットインスタンスは最大でオンデマンドインスタンスの8割引きから9割引き程度で利用できる魅力的なサービスです。突然落とされるリスクが上がる事は無視できないデメリットですが、状況によってはそれを補ってあまりあるメリットがあります。データベースも一時的に利用したい場合にはスポットインスタンスが便利なのですが、RDSにはスポットインスタンスがありません。
その他
以上は実際に私が遭遇したケースですが、以下のようなケースも RDS を利用しにくいかも知れません。
- 標準搭載されていないプラグインを利用したい場合
-
SELECT INTO...等を多用し、サーバーのファイルシステムに直接アクセスしたい場合 - PaceMaker 等で他のリソースと連動するような HA クラスタを構築したい場合
- 利用したいバージョンが対応していない場合
- 少しでもいいから安くしたい場合
まとめ
RDS は優れたサービスですが、「AWS なら RDS」と決めてかかるのではなく、ケースによっては EC2 で地道に構築した方がより良い選択肢になる場合もあります。もっともそういう手間を一切合切引き受けてくれるためのサービスが RDS なのですから、可能な限り利用しましょう。
また、改めて書いてみると私が扱ってきたケースは Aurora で解決できる問題が多そうです。色々な事情で利用できなかったのですが、Aurora も積極的に利用していきたいと思ってます。