AmazonAuroraサーバーレスによる自動スケーリング

Amazon Aurora Serverlessは、オンデマンド、自動スケーラブル、高可用性、リレーショナルデータベースを提供します。このデータベースは、使用中の場合にのみ課金されます。これは、頻度が低い、断続的な、または予測できないワークロードに対して、比較的単純で費用効果の高いオプションを提供します。これを可能にするのは、自動的に起動し、アプリケーションの使用状況に合わせて計算能力をスケーリングし、不要になったときにシャットダウンすることです。

次の図は、Auroraサーバーレスの高レベルアーキテクチャを示しています。

Aurora Serverlessを使用すると、1つのエンドポイントを取得できます（標準のAuroraプロビジョニングされたDBの2つのエンドポイントとは対照的です）。これは基本的に、データベースインスタンスの最上位にある一連のプロキシで構成されるDNSレコードです。 MySQLサーバーポイントからは、接続が常にプロキシフリートから来ていることを意味します。

Auroraサーバーレス自動スケーリング

Aurora Serverlessは現在、MySQL5.6でのみ使用できます。基本的に、DBクラスターの最小容量と最大容量の単位を設定する必要があります。各容量ユニットは、特定のコンピューティングおよびメモリ構成に相当します。 Aurora Serverlessは、ワークロードがこれらのしきい値を下回ると、DBクラスターのリソースを削減します。 Aurora Serverlessは、容量を最小容量まで減らすことも、容量を最大容量単位まで増やすこともできます。

次のいずれかの条件が満たされた場合、クラスターは自動的にスケールアップします。

CPU使用率が70％を超えているまたは
接続の90％以上が使用されています

次の両方の条件が満たされた場合、クラスターは自動的にスケールダウンします。

CPU使用率が30％を下回り、
使用されている接続は40％未満です。

Aurora自動スケーリングフローについて知っておくべきいくつかの注目すべき点：

スケールアップによって解決できるパフォーマンスの問題を検出した場合にのみスケールアップします。
スケールアップ後、スケールダウンのクールダウン期間は15分です。
スケールダウン後、次のスケールダウンのクールダウン期間は310秒です。
5分間接続がない場合、容量はゼロになります。

デフォルトでは、Aurora Serverlessは、サーバーへのアクティブなデータベース接続を切断することなく、シームレスに自動スケーリングを実行します。スケーリングポイント（データベースがスケーリング操作を安全に開始できる時点）を決定することができます。ただし、次の条件下では、AuroraServerlessがスケーリングポイントを見つけることができない場合があります。

実行時間の長いクエリまたはトランザクションが進行中です。
一時テーブルまたはテーブルロックが使用されています。

上記のいずれかの場合、Aurora Serverlessはスケーリング操作を開始できるようにスケーリングポイントの検索を続行します（「ForceScaling」が有効になっていない場合）。 DBクラスターをスケーリングする必要があると判断する限り、これを実行します。

オーロラの自動スケーリング動作の観察

Aurora Serverlessでは、変更できるパラメーターはごく少数であり、max_connectionsはそれらの1つではないことに注意してください。他のすべての構成パラメーターについては、AuroraMySQLサーバーレスクラスターはデフォルト値を使用します。 max_connectionsの場合、次の式を使用してAuroraサーバーレスによって動的に制御されます。

max_connections =GREATEST（{log（DBInstanceClassMemory / 805306368）* 45}、{log（DBInstanceClassMemory / 8187281408）* 1000}）

ここで、ログはlog ₂ （log base-2）および「DBInstanceClassMemory」は、現在のDBインスタンスに関連付けられたDBインスタンスクラスに割り当てられたメモリのバイト数から、インスタンスを管理するAmazonRDSプロセスによって使用されるメモリを差し引いたものです。 Auroraが使用する値を事前に決定するのはかなり難しいため、この値がそれに応じてどのようにスケーリングされるかを理解するためにいくつかのテストを行うことをお勧めします。

このテストのAuroraサーバーレス導入の概要は次のとおりです。

この例では、最小1つのAurora容量ユニットを選択しました。これは、最大256容量ユニットで488GBのRAMまでは2GBのRAMに相当します。

テストは、sysbenchを使用して、MySQLデータベース接続の制限に達するまで複数のスレッドを送信するだけで実行されました。一度に128のデータベース接続を同時に送信しようとした最初の試みは、まっすぐな失敗に終わりました：

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=128 \
--delete_inserts=5 \
--time=360 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
run

上記のコマンドは、すぐに「接続が多すぎます」というエラーを返しました：

FATAL: unable to connect to MySQL server on host 'aurora-sysbench.cluster-cdw9q2wnb00s.ap-southeast-1.rds.amazonaws.com', port 3306, aborting...
FATAL: error 1040: Too many connections

max_connection設定を見ると、次のようになりました。

mysql> SELECT @@hostname, @@max_connections;
+----------------+-------------------+
| @@hostname     | @@max_connections |
+----------------+-------------------+
| ip-10-2-56-105 |                90 |
+----------------+-------------------+

1つのDB容量（2GB RAM）を持つAuroraインスタンスのmax_connectionsの開始値は90です。これは、提供された式を使用して計算した場合、実際には予想値よりもはるかに低くなります。 max_connections値：

mysql> SELECT GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000});
+------------------------------------------------------------------------------+
| GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000}) |
+------------------------------------------------------------------------------+
|                                                                     262.2951 |
+------------------------------------------------------------------------------+

これは、DBInstanceClassMemoryがAuroraインスタンスの実際のメモリと等しくないことを意味します。それはずっと低くなければなりません。このディスカッションスレッドによると、変数の値は、OSサービスとRDS管理デーモンですでに使用されているメモリを考慮して調整されます。

それでも、デフォルトのmax_connections値をより高い値に変更しても、この値はAuroraサーバーレスクラスターによって動的に制御されるため、役に立ちません。したがって、Aurora内部スレッドはすでに「rdsadmin」@「localhost」を介して約4〜5の接続を予約しているため、sysbenchの開始スレッドの値を84に減らす必要がありました。さらに、管理と監視の目的で追加の接続も必要です。

そのため、代わりに次のコマンドを実行しました（--threads =84を使用）：

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=84 \
--delete_inserts=5 \
--time=600 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
run

上記のテストが10分（--time =600）で完了した後、同じコマンドを再度実行しました。この時点で、注目すべき変数とステータスの一部が次のように変更されました。

mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+--------------+-----------------+-------------------+--------+
| hostname     | max_connections | threads_connected | uptime |
+--------------+-----------------+-------------------+--------+
| ip-10-2-34-7 |             180 | 179               | 157    |
+--------------+-----------------+-------------------+--------+

max_connectionsが2倍の180になり、ホスト名が異なり、サーバーが開始されたばかりのように稼働時間が短いことに注意してください。アプリケーションの観点からは、別の「より大きなデータベースインスタンス」がエンドポイントを引き継ぎ、別のmax_connections変数で構成されているように見えます。 Auroraイベントを見ると、次のことが発生しています。

Wed, 04 Sep 2019 08:50:56 GMT The DB cluster has scaled from 1 capacity unit to 2 capacity units.

次に、同じsysbenchコマンドを起動して、データベースエンドポイントへの接続をさらに84個作成しました。生成されたストレステストが完了すると、サーバーは次のように自動的に最大4つのDB容量にスケールアップします。

mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname      | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-12-75 |             270 | 6                 | 300    |
+---------------+-----------------+-------------------+--------+

前のものと比較した場合、異なるホスト名、max_connection、および稼働時間の値を確認することでわかります。もう1つの大きなインスタンスは、DB容量が2に等しい前のインスタンスから役割を「引き継いで」います。実際のスケーリングポイントは、サーバーの負荷が低下し、ほぼフロアに達したときです。私たちのテストでは、接続をフルに保ち、データベースの負荷を一貫して高く保つと、自動スケーリングは行われません。

以下の両方のスクリーンショットを見ると、自動スケーリングを実行するのに最も安全なポイントであるため、Sysbenchが600秒間ストレステストを完了した場合にのみスケーリングが発生することがわかります。

サーバーレスDB容量CPU使用率

CPU使用率

Auroraイベントを見ると、次のイベントが発生しました：

Wed, 04 Sep 2019 16:25:00 GMT Scaling DB cluster from 4 capacity units to 2 capacity units for this reason: Autoscaling.
Wed, 04 Sep 2019 16:25:05 GMT The DB cluster has scaled from 4 capacity units to 2 capacity units.

最後に、270近くになるまでさらに多くの接続を生成し、完了するまで待って、8DBの容量に入ります。

mysql> SELECT @@hostname as hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname      | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-72-12 |            1000 | 144               | 230    |
+---------------+-----------------+-------------------+--------+

8容量単位のインスタンスでは、MySQL max_connections値は1000になりました。データベース接続を最大にして256容量単位の制限まで、同様の手順を繰り返しました。次の表は、最大DB容量までのテストにおける全体的なDB容量単位とmax_connections値の関係をまとめたものです。

強制スケーリング

前述のように、Aurora Serverlessは、安全な場合にのみ自動スケーリングを実行します。ただし、ユーザーには、[追加のスケーリング構成]オプションの下にある[スケーリングを強制する]チェックボックスをオンにすることで、DB容量のスケーリングをすぐに実行するオプションがあります。

強制スケーリングが有効になっている場合、タイムアウトが発生するとすぐにスケーリングが行われます。 300秒に達しました。この動作により、アプリケーションからデータベースが中断され、データベースへのアクティブな接続が切断される可能性があります。タイムアウトに達した後に強制自動スケーリングが発生すると、次のエラーが発生しました。

FATAL: mysql_drv_query() returned error 1105 (The last transaction was aborted due to an unknown error. Please retry.) for query 'SELECT c FROM sbtest19 WHERE id=52824'
FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:419: SQL error, errno = 1105, state = 'HY000': The last transaction was aborted due to an unknown error. Please retry.

上記は、スケールアップする適切なタイミングを見つける代わりに、Aurora Serverlessがタイムアウトに達した直後にインスタンスの置き換えを強制することを意味します。これにより、トランザクションが中止され、ロールバックされます。中止されたクエリを2回再試行すると、問題が解決する可能性があります。この構成は、アプリケーションが接続の切断に対して回復力がある場合に使用できます。

概要

Amazon Auroraサーバーレス自動スケーリングは垂直スケーリングソリューションであり、基盤となるAurora共有ストレージテクノロジーを効率的に利用して、より強力なインスタンスが劣ったインスタンスを引き継ぎます。デフォルトでは、自動スケーリング操作はシームレスに実行されます。これにより、Auroraはインスタンスの切り替えを実行するための安全なスケーリングポイントを見つけます。 1つは、アクティブなデータベース接続がドロップされるリスクを伴う自動スケーリングを強制するオプションがあります。