[アップデート] Aurora Serverless の最小キャパシティが 1 から指定可能になりました！＆キャパシティ変更の強制オプションが追加されました

平成最後の日、いかがお過ごしでしょうか？私は人混みが苦手なので、どこにも行かず、こうやってブログを書いてるわけですね。

本日 Aurora Serverless に以下 2つ のアップデートがありました。

• 最小キャパシティ(ACU)が 1 から指定可能になりました
• キャパシティ変更の強制オプションがサポートされました

『Announcement: Amazon Aurora Serverless Now Supports a Minimum Capacity of 1 Unit and a New Scaling Option』

最小キャパシティ

Aurora Serverless は負荷によってコンピューティングリソースが動的にスケーリングしますが、スケーリング単位として Aurora Capacity Unit (ACU) が設定されています。1ACU は 2GB のメモリとそれに対応する CPU とネットワークを備えています。料金は東京リージョンで $0.10/ACUです。

従来は 2ACU(4GB) 〜 256ACU(488GB) の範囲となっておりましたが、今回のアップデートで 1ACU(2GB) からの指定が可能となり、低負荷時の最小コストがより抑えることが可能となりました。

キャパシティ変更の強制オプション

Aurora Serverless ではリソース変動の際に、安全にスケーリングするためのスケーリングポイントを探っています。ただし、以下のような場合には、スケーリングポイントが特定できず、タイムアウトになることがあります。

• 進行中の長期のクエリやトランザクションがある場合
• 一時テーブルやテーブルロックを使用している場合

Q: Aurora Serverless の料金はどのように請求されますか? Aurora Serverless では、データベース容量は Aurora Capacity Unit (ACU) で測定されます。ACU 使用量に応じた毎秒固定レートで、データベースがアクティブになるたびに最低 5 分間使用されます。ストレージと I/O の料金は、プロビジョン構成もサーバーレス構成も同じです。Aurora Serverless の料金の例を確認してください。(Amazon Aurora のよくある質問)

今回のアップデートは、上記のような使用状況でスケーリングポイントを特定できずタイムアウトした場合に、強制的にスケーリングさせるか否かを選択することが可能になった、ということです。

やってみよう

それでは、実際の動作を確認してみましょう。

今回、強制オプションを ON と OFF 2つの Aurora Serverless インスタンスを作成しました。アイドル時のインスタンス停止は、検証動作がわかりにくくなるため無効としました。

インスタンス名	エンジンバージョン	最小ACU	最大ACU	強制オプション	アイドル時停止
aurora-sls1	MySQL 5.6 互換	1	64	有効	無効
aurora-sls2	MySQL 5.6 互換	1	64	無効	無効

設定画面は下記のとおりです。キャパシティーの設定で ACU:1 が指定できるようになっています。また、スケーリングの追加設定に Force scaling the capacity to the specified values when the timeout is reached が追加されています。こちらにチェックを入れると、タイムアウト時にスケーリングを強制することが可能です。

動作確認

今回は LOCK TABLES で動作を確認しました。Aurora Serverless の作成直後は 8ACU で稼働していましたので、検証用に作成したテーブルに対して、それぞれ LOCK TABLES を実施しました。その後、何も操作せずにしばらく放置した状態が以下のグラフになります。

aurora-sls2（オレンジ）は、UNLOCK TABLES を実施する矢印2の時点まで、8ACU の状態が継続しています。

対して、aurora-sls1（青）は、しばらく 8ACU で動作したあと、8→4→2→1 と段階的に ACU が下がっていることが確認できます。矢印1の時点では、UNLOCK TABLES は実施していませんので、強制オプションが機能していることが確認できましたね！

注意点

公式ガイドに記載がありますが、強制オプションにてスケーリングさせる場合、スケーリングポイントの妨げになっている接続が切断される可能性があるため、利用においては十分な検証を行ってください。

Important If you force the capacity change, connections that prevent Aurora Serverless from finding a scaling point might be dropped.

さいごに

スケーリングポイントのタイムアウトを懸念して Aurora Serverless の導入を見送った環境でも、利用できる可能性が広がりました。また、「アイドル時の停止はさせたくないけど、最小 2ACU(4GBメモリ) のコストがねぇ・・」と見送った環境も、1ACU の指定によって最小コストを下げることが可能になりました。

上記のような理由で、Aurora Serverless を見送った方は、ぜひ再検討してみましょう！

以上！大阪オフィスの丸毛（@marumo1981）、平成最後の投稿でした！