こんにちは、Pythonエンジニアの @kimihiro_n です。 今回はこの前リリースされた PostgreSQLの AWS Aurora Serverless を使ってみたという話を。
TL;DR
- Auroraと比較してだいぶ安い
- オートスケール便利
- 立ち上げは結構遅い
- 開発環境用途には便利
- 本番はキャパシティを0にしない工夫が必要
Aurora Serverless とは
MySQL、PostgreSQL と互換性がある AWS 製のリレーショナルデータベースとして Amazon Aurora というサービスがあります。 通常の MySQL などとと比べて高いパフォーマンスが出るよう独自にチューニングされており、マネージドサービスとしてインスタンスをあまり意識せず利用することができます。 またデータベースのサイズが自動で拡張する ( 64TB まで) ので、ディスク容量を心配せず利用できるのも大きな特徴ですね。
AuroraServerless はこの Aurora をさらに進化させたタイプのデータベースです。 Aurora の場合、マネージドサービスとはいえ起動しておくインスタンスのスペックや個数は自分で管理する必要があります。 利用負荷に応じてインスタンス数が自動で増減するわけではないので、使う量に応じてインスタンスを手動調整したり、オートスケールを設定したりする必要があります。 また Reader、Writer の概念があるため Writer の負荷に注意するなどといったことも大切です。
AuroraServerless では処理能力がキャパシティという単位で抽象化されており、キャパシティ数を変更することで柔軟にスケーリングすることが可能です。 デフォルトでオートスケールが組み込まれており、最低キャパシティと最大キャパシティ、それから利用がないときはキャパシティを0にするかどうかだけを設定すれば利用することが可能です。
この前まで MySQL 版でしか AuroraServerless に対応していなかったのですが、先日 PostgreSQL の Serverless も一般公開され自由に使えるようになりました!
https://aws.amazon.com/jp/rds/aurora/serverless/
PostgreSQL 版 Serverless を使ってみる
現在、開発環境と本番環境で PostgreSQL 版の Aurora データベースを利用しているのですが、Serverless 版が出たので早速使ってみることにしました。 使ってみたかったという動機はもちろんありますが、 Serverless を利用する大きな理由がコストですね。
Aurora データベース、インスタンスの値段が結構高く、開発環境で使うにはコストが嵩んでいました。 特に PostgreSQL 版だと MySQL 版より最低限必要なインスタンスのスペックが大きくつらみがありました。 これを Serverless 版に変更することで、最低ラインの費用を下げたり、利用されない深夜帯・休日の間のコストを0にしたりといったことが可能になります。
Aurora
0.35($/instance/hour) * 1(instance) * 24(hour/day) * 30(day/month) = 252 ($/month)
Aurora Serverless
0.1($/cap/hour) * 2(cap) * 24(hour/day) * 30(day/month) = 144 ($/month)
最低限の状態で24時間・30日動かした場合の費用比較です。どちらも東京リージョンで、Auroraは r5.large の1台構成での費用です。 PostgreSQL を Serverless で動かす場合最低 2 キャパシティとなっていました。 (MySQL 版は 1 キャパシティから)
ずっと動かす前提でも半額くらいになるみたいです。月100ドルの差は結構大きいですね。 開発環境の場合使わない時間帯のほうが大きいのでここから更に安くなりそうです。
Aurora からの移行
移行作業自体はスムーズでした。
- Aurora のデータベースを pg_dump コマンドでバックアップする
- 新しく Serverless でデータベースを起動させる
- ダンプしたデータを流し込む
- データベースの接続先をつなぎ替える
で完了しました。
同じ Aurora ファミリーだから RDS のスナップショットから Serverless 版起動できるかなと思ったのですが、バージョン違いからか Serverless の選択肢がグレーアウトしており、手動でデータを流し込む必要がありました。
特記すべきは Serverless 版には Reader・Writer の区別がないことですね。 アプリケーション側で使い分けの処理入れてましたが、区別ないので同じエンドポイントを両方に指定してます。
動作検証
移行できたようなので動作確認へ。 Django のアプリケーションで利用していて、一通りの機能を試してみましたが問題なさそうでした。 PostGIS のような拡張機能もちゃんと動いています(すんなり動いてしまって逆に怖さがあります)。
未利用時の挙動
一番気になるのが未利用時の挙動ですね。 DBへのリクエストがしばらくない場合、キャパシティを0にすることができます。 この状態であればストレージに対する課金のみでデータベースを維持する事ができます。
アプリケーションサーバーにアクセスしないで放置した状態でのキャパシティの変化。 2キャパシティで動いていたのが自動で0キャパシティに変化してますね。問題なさそうです。
逆にこの状態でアプリケーションサーバーにアクセスするとどうなるでしょうか。 キャパシティが0、つまりDBサーバーが停止している状態でアクセスするので、DB接続エラーになってしまわないかが心配です。
DBへのリクエストによってキャパシティがもとに戻る図。 接続エラーが出ることなくキャパシティが無事に戻りました。 ただやはりキャパシティが0から立ち上がるには少し時間がかかります。 状況にもよりますが10~30秒ほどかかっている気がします。 実際のユーザーがいる環境ではあまり起こってほしくない待ち時間ですね。
キャパシティ0でないときのレスポンスは概ね良好でした。ただ時々詰まったような挙動をすることがあります。 (アプリケーションサーバーを経由しての挙動確認なので、発行するクエリが一時的に多くて、用意していたキャパシティに対する処理が不足していたとかかもしれません。※ 要調査)
Serverless 切り替え前と後の平均レスポンスの変化。
グラフが跳ね始めてるのがちょうど切り替えのタイミングです。 開発環境なのでリクエスト総数がそんなになく、1つ遅い応答時間があると平均も跳ねてしまうという点は留意して見る必要があります。 キャパシティが0になってしまうと待ち時間が多く発生してしまうので、本番環境で Serverless を導入する際はどうキャパシティを制御するかが鍵になりそうですね。 開発環境用であれば多少待つくらいで済むので問題なさそうです。
おわりに
Serverless のおかげでデータベースを安く楽に管理できるのはありがたいですね。 待ち時間を気にしなくてよく、常日頃可動しているわけではないバッチ処理系とも相性が良さそうです。 サーバレスなデータベースの選択肢の一つとして活用してみてはどうでしょうか。