の続きです。
この検証をしていて気づいたことをいくつか挙げてみます。
※Aurora Serverless GA 化については、こちらで紹介されています。
- Aurora Serverless MySQL の一般利用が開始（Amazon Web Services ブログ／Randall Hunt さん）
- Aurora Serverlessが一般利用可能になったので試してみた（Developers.IO／大栗さん）
一時停止→復帰・スケールが生じるとバッファプール（バッファキャッシュ）が初期化される
先の記事に書きました。
（一時停止後復帰のほうは別として）スケール時に初期化されるのは仕組み上仕方がないと思いますが、スケールアップ型をやめて（同一リージョンマルチマスタ Aurora の技術を使って）スケールアウト型に変えれば何とかなる…かも？（メモリの退避は必要ですが）。
但し、1 インスタンスが 2 キャパシティユニット（メモリ 4GB）だと、1 インスタンス当たりのバッファプール（バッファキャッシュ）が小さくなりすぎて効率が悪そう…。
有効なパラメータグループ項目が少ない
これは、先に挙げた 2 つの記事にも触れられているのですが、これを書いている 2018/08/23 現在、キャラクタセット・照合順序・タイムゾーンなどごく一部の DB クラスターのパラメータグループ以外の指定は無効です。
DB のパラメータグループは指定すること自体できません。
これによる影響はかなり広範囲にわたりますが、例えば、以下のようなものがあります。
バイナリログが出力できない
バイナリログのフォーマットも ON / OFF も指定できません。
結果、外部の MySQL にレプリケーションができません。
innodb_file_format・innodb_large_prefixが指定できない
デフォルトでinnodb_file_per_tableはONですが、innodb_file_formatはAntelope、innodb_large_prefixはOFFがデフォルトです。
結果、長いインデックスを付けられないなどの制約が生じています。
※上記項目とインデックス長の関係については、以下の記事を参照してください。
- 第32回 InnoDBインデックスの最大キー長について（MySQL道普請便り／北川健太郎さん）
クライアントから接続している（コネクションが張られている）間は一時停止（pause）しない
コネクションプーリングを使っていると、普通に止まらない Aurora になってしまう可能性が高いので、一時停止（pause）させたい場合はコネクションプーリングを使わないようにしたほうが良いでしょう。
なお、コネクションが張られている状態でも、スケールイン／アウトは実行されます。
デフォルト設定で負荷が低い状態が約 15 分続くとスケールイン（キャパシティユニットが減少）する
設定によってこの時間が変化するかどうかは未検証です。
個人的な感想など
色々と制約があるため、自社の開発環境として使うにはまだ難しそうです。
復帰（resume）やスケールに 10 ～ 30 秒掛かってしまうのも若干気になるところ。さすがに瞬時にはならないと思いますが、5 秒程度になればコネクションタイムアウトに引っかかりにくくなるでしょうし、もう少し利用シーンが増えるでしょうね。
今後の展開に期待、です（プレビュー発表当初に「コレ使えねぇ」と酷評されていたことを考えると、現状でも意外とマトモな気はしますが）。