自動一時停止の概要前提条件と制限自動一時停止の有効/無効の切り替え自動一時停止の仕組み自動一時停止と Aurora クラスター設定自動一時停止のモニタリング自動一時停止のトラブルシューティング自動一時停止のアプリケーション設計

Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング

指定した期間内にユーザーアクティビティによって開始された接続がない場合、Aurora Serverless v2 DB インスタンスをゼロ ACU にスケールダウンし、自動的に一時停止するように指定できます。そのためには、DB クラスターの最小 ACU 値を 0 に指定します。インスタンスが一時停止状態にある間は、インスタンス容量に対して課金されません。使用頻度が低い、または長期間非アクティブ状態にある Aurora クラスターで自動一時停止および再開機能 (自動一時停止) を有効にすると、データベース群のコスト管理に役立ちます。

注記

自動一時停止機能は、Aurora PostgreSQL と Aurora MySQL の両方に対応する Aurora Serverless v2 で利用できます。この機能を利用するには、Aurora データベースエンジンのバージョンのアップグレードが必要な場合があります。最小容量 0 ACU が使用可能なエンジンバージョンについては、「Aurora Serverless v2 の容量」を参照してください。

Aurora Serverless v2 自動一時停止機能の概要

Aurora Serverless v2 DB インスタンスは、一定期間ユーザー接続がない場合に自動的に一時停止し、接続リクエストが到着した場合に自動的に再開できます。Aurora Serverless v2 自動一時停止/再開機能は、厳格なサービスレベル目標 (SLO) を持たないシステムのコストを管理するのに役立ちます。例えば、この機能は、開発とテストで使用されるクラスターや、データベースの再開中に短時間の一時停止が許容される内部アプリケーションに対して有効にすることができます。ワークロードに非アクティブな期間があり、インスタンスの再開中に接続のわずかな遅延を許容できる場合は、コスト削減のために Aurora Serverless v2 インスタンスで自動一時停止を使用することを検討してください。

この動作を制御するには、クラスター内の Aurora Serverless v2 DB インスタンスを自動的に一時停止できるかどうか、また、各インスタンスが一時停止する前にアイドル状態になる必要がある時間を指定します。Aurora クラスター内のすべての Aurora Serverless v2 DB インスタンスで自動一時停止動作を有効にするには、クラスターの最小容量値をゼロ ACU に設定します。

以前、一定期間非アクティブ状態が続いた後にゼロ ACU にスケールする Aurora Serverless v1 の機能を利用していた場合は、Aurora Serverless v2 にアップグレードして対応する自動一時停止機能を使用できます。

自動一時停止機能によるコスト削減のメリットは、クラスターの停止/開始機能を使用する場合と似ています。Aurora Serverless v2 の自動一時停止には、停止したクラスターを開始するより速く再開でき、各 DB インスタンスの一時停止と再開のタイミングを決定するプロセスを自動化するという追加のメリットもあります。

自動一時停止機能では、クラスター内のコンピューティングリソースのコストをさらに細かく制御できます。クラスター内のライターインスタンスと他のリーダーが常にアクティブな状態を維持する場合でも、一部のリーダーインスタンスの一時停止を有効にすることができます。これを行うには、他のインスタンスとは独立して一時停止できるリーダーインスタンスに、2～15 の範囲のフェイルオーバー優先順位を割り当てます。

ライターインスタンスと、フェイルオーバー優先順位が 0 と 1 のすべてのリーダーインスタンスは、常に同時に一時停止および再開します。したがって、このグループのインスタンスは、指定された時間間隔の間にいずれのインスタンスにも接続がない場合に一時停止します。

Aurora DB クラスターには、ライター DB インスタンスとリーダー DB インスタンス、プロビジョニング済み DB インスタンスと Aurora Serverless v2 DB インスタンスの組み合わせを含めることができます。そのため、この機能を効果的に使用するには、自動一時停止メカニズムの以下の側面を理解しておくと役立ちます。

DB インスタンスが自動的に一時停止する状況。
DB インスタンスが一時停止できない場合。例えば、一部の Aurora 機能を有効にしたり、クラスターで特定の種類のオペレーションを実行したりすると、それらのインスタンスへの接続がなくても、インスタンスが一時停止できなくなる場合があります。
インスタンスが一時停止中のモニタリングと請求への影響。
DB インスタンスが処理を再開する原因となるアクション。
DB インスタンスの容量が一時停止および再開イベントの前後でどのように変化するか。
DB インスタンスが一時停止する前のアイドル間隔を制御する方法。
DB インスタンスが処理を再開している間の期間を処理するためのアプリケーションロジックをコーディングする方法。

Aurora Serverless v2 自動一時停止機能の前提条件と制限

自動一時停止機能を使用する前に、使用するエンジンバージョンを確認してください。また、自動一時停止が、使用する予定の他の Aurora 機能と組み合わせて機能するかどうかも確認してください。自動一時停止をサポートしていないエンジンバージョンを使用している場合、自動一時停止を有効にすることはできません。互換性のない機能の場合、自動一時停止と組み合わせて使用してもエラーは発生しません。クラスターで互換性のない機能や設定を使用している場合、Aurora Serverless v2 インスタンスは自動的に一時停止しません。

Aurora PostgreSQL を使用している場合、データベースエンジンはバージョン 16.3、15.7、14.12、または 13.15 以降を実行している必要があります。
Aurora MySQL を使用している場合、データベースエンジンはバージョン 3.08.0 以降を実行している必要があります。
この機能が利用可能なエンジンバージョンと AWS リージョンの全一覧については、「Aurora Serverless v2 でサポートされているリージョンと Aurora DB エンジン」を参照してください。
Aurora Serverless v2 インスタンスが再開すると、その容量はインスタンスが一時停止したときよりも低くなる可能性があります。詳細については、「Aurora Serverless v2 と Aurora Serverless v1 の自動一時停止動作の違い」を参照してください。

特定の条件または設定により、Aurora Serverless v2 インスタンスが自動的に一時停止できなくなります。詳細については、「Aurora Serverless v2 が自動一時停止しない状況」を参照してください。

自動一時停止機能の有効/無効の切り替え

自動一時停止機能は、クラスターレベルで有効/無効を切り替えることができます。そのためには、クラスターの最小容量と最大容量を調整する場合と同じ手順を使用します。自動一時停止機能は、最小容量 0 ACU で表されます。

トピック

自動一時停止を有効にする
自動一時停止のタイムアウト間隔
インスタンスの再開
自動一時停止を無効にする

クラスター内の Aurora Serverless v2 インスタンスで自動一時停止を有効にする

「Aurora Serverless v2 クラスターの容量設定」の手順に従います。最小容量に 0 ACU を選択します。最小容量に 0 ACU を選択すると、インスタンスが自動的に一時停止するまでのアイドル時間の長さを指定することもできます。

次の CLI の例は、自動一時停止機能を有効にし、自動一時停止間隔を 10 分 (600 秒) に設定して Aurora クラスターを作成する方法を示しています。


aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

次の CLI の例は、既存の Aurora クラスターで自動一時停止機能を有効にする方法を示しています。この例では、自動一時停止間隔を 1 時間 (3600 秒) に設定します。


aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}

設定可能な Aurora Serverless v2 自動一時停止のタイムアウト間隔

タイムアウト間隔は、Aurora クラスターの ServerlessV2ScalingConfiguration 属性で表されます。最小容量がゼロ ACU に設定されている場合、Aurora クラスターの作成時または変更時に、AWS Management Consoleでこの間隔を指定できます。Aurora クラスターの作成時または変更時に、--serverless-v2-scaling-configuration パラメータを使用して、AWS CLI でこれを指定できます。Aurora クラスターの作成時または変更時に、ServerlessV2ScalingConfiguration パラメータを使用して、RDS API でこれを指定できます。

設定できる最小間隔は 300 秒 (5 分) です。これは、間隔を指定しない場合のデフォルトです。設定できる最大間隔は 86,400 秒 (1 日) です。

クラスターの最小容量をゼロ以外の値に変更して、クラスターの自動一時停止機能を無効にするとします。この場合、間隔のプロパティは ServerlessV2ScalingConfiguration 属性から削除されます。そのプロパティがないことで、そのクラスターの自動一時停止機能が無効になっていることを追加で確認できます。後で自動一時停止を再度有効にする場合、その時点で任意のカスタム間隔を再度指定できます。

自動一時停止した Aurora Serverless v2 インスタンスの再開

一時停止した Aurora Serverless v2 インスタンスに接続すると、インスタンスが自動的に再開し、接続を受け入れます。
有効な認証情報を含まない接続を試みた場合も、DB インスタンスが再開されます。
ライターエンドポイントを介して接続すると、Aurora はライター DB インスタンスが自動一時停止されている場合はこれを再開します。同時に、Aurora はフェイルオーバー優先順位が 0 または 1 の自動一時停止されたリーダーインスタンスを再開します。つまり、その容量はライターインスタンスの容量に関連付けられています。
リーダーエンドポイントを介して接続すると、Aurora はリーダーインスタンスをランダムに選択します。そのリーダーインスタンスが一時停止されている場合、Aurora はそのインスタンスを再開します。また、Aurora は最初にライターインスタンスを再開します。リーダーインスタンスがアクティブな場合は、ライターインスタンスが必ずアクティブである必要があるためです。Aurora がそのライターインスタンスを再開すると、フェイルオーバーの昇格階層が 0 と 1 のすべてのリーダーインスタンスも再開されます。
RDS Data API を介してクラスターにリクエストを送信すると、Aurora はライターインスタンスが一時停止されている場合はこれを再開します。その後、Aurora は Data API リクエストを処理します。
DB クラスターパラメータグループの設定パラメータの値を変更すると、Aurora はそのクラスターパラメータグループを使用するすべてのクラスターで一時停止中の Aurora Serverless v2 インスタンスを自動的に再開します。同様に、DB パラメータグループのパラメータ値を変更すると、Aurora はその DB パラメータグループを使用する一時停止中の Aurora Serverless v2 インスタンスを自動的に再開します。クラスターを変更して別のクラスターパラメータグループを割り当てる場合、またはインスタンスを変更して別の DB パラメータグループを割り当てる場合も、同じ自動再開動作が適用されます。
バックトラックリクエストを実行すると、Aurora Serverless v2 ライターインスタンスが一時停止中の場合は自動的に再開されます。Aurora は、ライターインスタンスの再開後にバックトラックリクエストを処理します。Aurora Serverless v2 インスタンスが一時停止した時点までバックトラックできます。
クラスタースナップショットを作成するかスナップショットを削除しても、Aurora Serverless v2 インスタンスは再開されません。
Aurora クローンを作成すると、Aurora はクローンを作成するクラスターのライターインスタンスを再開します。
一時停止中のインスタンスが再開を完了する前に多数の接続リクエストを受信した場合、一部のセッションが接続できない場合があります。自動一時停止が有効になっている Aurora Serverless v2 インスタンスがある Aurora クラスターへの接続には、再試行ロジックを実装することをお勧めします。例えば、接続に失敗した場合に 3 回再試行するなどです。
Aurora は、インスタンスを起動することなく、一部のタイプのマイナーな内部メンテナンスを実行できます。ただし、クラスターのメンテナンスウィンドウ中に発生する一部のタイプのメンテナンスでは、Aurora がインスタンスを再開する必要があります。メンテナンスが完了すると、指定した間隔後にアクティビティがなくなった場合、インスタンスは自動的に再び一時停止されます。

注記
Aurora は、PostgreSQL pg_cron 拡張機能や MySQL イベントスケジューラなど、エンジン固有のスケジュールされたジョブに対して一時停止中のインスタンスを自動的に再開することはしません。このようなジョブを確実に実行するには、スケジュールされた時刻より前にインスタンスへの接続を手動で開始します。Aurora は、DB インスタンスの一時停止中にスケジュールされた時間が発生するジョブをキューに追加しません。このようなジョブは、インスタンスが後で再開された際にスキップされます。
Aurora Serverless v2 インスタンスの自動一時停止中に Aurora クラスターがフェイルオーバーした場合、Aurora はインスタンスを再開してから、そのインスタンスをライターに昇格させることがあります。インスタンスの一時停止中に 1 つ以上の DB インスタンスがクラスターから削除された場合も、同じことが起こる可能性があります。この場合、インスタンスは再開されるとすぐにライターになります。
クラスターのプロパティを変更するオペレーションによっても、自動一時停止中の Aurora Serverless v2 インスタンスが再開されます。例えば、自動一時停止中のインスタンスは、以下のようなオペレーションのために再開されます。
- クラスターのスケーリング範囲の変更。
- クラスターのエンジンバージョンのアップグレード。
- 一時停止中のインスタンスからのログファイルの記述またはダウンロード。CloudWatch へのログのアップロードを有効にし、CloudWatch を介してログを分析することで、一時停止中のインスタンスの履歴ログデータを調べることができます。

クラスター内の Aurora Serverless v2 インスタンスの自動一時停止を無効にする

「Aurora Serverless v2 クラスターの容量設定」の手順に従います。最小容量には、0.5 以上の値を選択します。自動一時停止機能を無効にすると、インスタンスがアイドル状態になる間隔がリセットされます。自動一時停止を再度有効にする場合は、新しいタイムアウト間隔を指定します。

次の CLI の例は、既存の Aurora クラスターで自動一時停止機能を無効にする方法を示しています。describe-db-clusters 出力は、最小容量がゼロ以外の値に設定されている場合、SecondsUntilAutoPause 属性が削除されることを示しています。


aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}

Aurora Serverless v2 自動一時停止機能の仕組み

次の情報を使用して、自動一時停止機能の使用を計画できます。インスタンスが一時停止、再開、またはアクティブ状態を維持する状況を理解しておくと、可用性、応答性、コスト削減のトレードオフのバランスを図るうえで役立ちます。

トピック

自動一時停止の仕組み
自動再開の仕組み
CPU 請求
自動一時停止を妨げる条件
クラスターの停止/開始との比較
メンテナンスとアップグレード
Aurora Serverless v1 との比較

Aurora Serverless v2 インスタンスが一時停止するときに起こること

Aurora Serverless v2 DB インスタンスが接続がない期間の後に一時停止する場合

Aurora は、インスタンスへの接続がなく指定した間隔が経過した後でインスタンスの一時停止を開始します。その時点でインスタンスが持つ ACU の数は関係ありません。
一時停止メカニズムは即時ではありません。自動一時停止しようとしている Aurora Serverless v2 インスタンスは、Aurora ストレージへのすべての変更が反映されるまで、ほんの短い間待機することがあります。
そのインスタンスの料金は保留状態になります。インスタンスが一時停止している間、ServerlessV2Usage メトリクスの値は 0 です。
インスタンスのステータス値は変わりません。ステータスは「利用可能」として表示されます。
インスタンスはデータベースログファイルへの書き込みを停止します。CPUUtilization と ACUUtilization にゼロパーセントを登録し、ServerlessDatabaseCapacity にゼロを登録することを除き、CloudWatch へのメトリクスの送信を停止します。
Aurora は、Aurora Serverless v2 DB インスタンスが一時停止を開始したとき、一時停止が完了したとき、一時停止メカニズムが中断された場合や失敗した場合にイベントを発行します。これらのイベントの詳細については、「DB インスタンスイベント」を参照してください。

自動一時停止中の Aurora Serverless v2 インスタンスが再開するときに起こること

Aurora Serverless v2 DB インスタンスが自動的に一時停止した後に再開する場合、次の条件が適用されます。

pending-reboot の変更にあるパラメータの変更は、インスタンスの再開時に適用されます。
Aurora は、各 Aurora Serverless v2 DB インスタンスが再開を開始したとき、再開を完了したとき、何らかの理由でインスタンスが再開できない場合に、インスタンスレベルのイベントを発行します。これらのイベントの詳細については、「DB インスタンスイベント」を参照してください。
リクエストされた接続は、DB インスタンスの再開が完了した後に確立されます。通常、再開までの時間は約 15 秒になる可能性があるため、クライアントのタイムアウト設定は 15 秒より長く調整することをお勧めします。例えば、JDBC ドライバー設定で、connectTimeout および sslResponseTimeout 設定の値を 15 秒より長く調整できます。

注記

Aurora Serverless v2 インスタンスが 24 時間以上一時停止したままの場合、Aurora はインスタンスをディープスリープ状態にすることがあるため、再開に時間がかかります。その場合、再開時間は 30 秒以上になることがあり、インスタンスの再起動とほぼ同じになります。データベースの非アクティブ期間が 1 日以上続く場合は、接続タイムアウトを 30 秒以上に設定することをお勧めします。

自動一時停止中の Aurora Serverless v2 クラスターのインスタンス請求の仕組み

Aurora Serverless v2 インスタンスが自動一時停止されている間、インスタンスの料金はかかりません。この期間中、ServerlessV2Usage メトリクスはゼロです。AWS は、Aurora ストレージと、その特定の DB インスタンスに関連しないクラスターのその他の要素に対して引き続き課金します。

Aurora Serverless v2 が自動一時停止しない状況

DB クラスターの最小容量値がゼロ ACU より大きい場合、クラスター内の Aurora Serverless v2 インスタンスは自動的に一時停止しません。自動一時停止機能が使用可能になる前からの Aurora Serverless v2 インスタンスを持つ既存のクラスターの場合、最小容量設定は 0.5 ACU でした。このようなクラスターで自動一時停止機能を使用するには、最小容量設定をゼロ ACU に変更します。
ユーザーが開始した Aurora Serverless v2 インスタンスへの接続が開いている場合、インスタンスは一時停止しません。また、パッチ適用やアップグレードなどのアクティビティが進行中の間も、インスタンスは一時停止しません。Aurora がヘルスチェックに使用する管理接続はアクティビティとしてカウントされず、インスタンスの一時停止も妨げません。
Aurora PostgreSQL クラスターで論理レプリケーションが有効になっている場合、または Aurora MySQL クラスターでバイナリログレプリケーションが有効になっている場合、ライターインスタンスとフェイルオーバー昇格階層が 0 と 1 のすべてのリーダーインスタンスは自動的に一時停止しません。Aurora は、レプリケーション接続の正常性をチェックするために、一定の最小限のアクティビティを実行します。

レプリケーションが有効になっているクラスターの場合、自動一時停止する Aurora リーダーインスタンスをソースクラスターに保持できます。そのためには、フェイルオーバー優先順位を 0 または 1 以外の値に設定します。これにより、ライターインスタンスとは独立して一時停止できます。
Aurora クラスターに RDS プロキシが関連付けられている場合、プロキシはクラスター内の各 DB インスタンスへのオープン接続を維持します。したがって、このようなクラスター内の Aurora Serverless v2 インスタンスは自動的に一時停止しません。
クラスターが Aurora Global Database のプライマリクラスターである場合、Aurora は Aurora Serverless v2 ライターインスタンスを自動的に一時停止しません。これは、グローバルデータベース内の他のクラスターを管理するために、ライターインスタンスで一定レベルのアクティビティが必要なためです。ライターインスタンスはアクティブなままであるため、フェイルオーバー優先順位が 0 または 1 の Aurora Serverless v2 リーダーインスタンスも自動一時停止しません。
Aurora Global Database のセカンダリクラスター内の Aurora Serverless v2 インスタンスは自動的に一時停止しません。DB クラスターがスタンドアロンクラスターに昇格すると、他のすべての条件が満たされている場合は自動一時停止機能が有効になります。
Redshift へのゼロ ETL 統合が関連付けられているクラスターでは、ライターインスタンスとフェイルオーバー昇格階層が 0 と 1 のすべてのリーダーインスタンスは自動的に一時停止しません。
インスタンスのメインデータベースポートでのアクティビティに加えて、Aurora PostgreSQL インスタンスで Babelfish 機能が有効になっている場合、T-SQL ポートでの接続とアクティビティにより、インスタンスの自動一時停止が妨げられます。

クラスターの停止/開始機能と自動一時停止の仕組み

自動一時停止機能が有効になっている場合は、Aurora クラスターを停止および開始できます。一部のインスタンスが一時停止中かどうかは関係ありません。クラスターを再開すると、一時停止中の Aurora Serverless v2 インスタンスは自動的に再開されます。

Aurora クラスターが停止している間、一時停止中の Aurora Serverless v2 インスタンスは、接続の試行に基づいて自動的に再開されません。クラスターが再開されると、Aurora Serverless v2 インスタンスを一時停止および再開するための通常のメカニズムが適用されます。

自動一時停止中の Aurora Serverless v2 クラスターのメンテナンスとアップグレードの仕組み

Aurora Serverless v2 インスタンスが自動一時停止中の間、Aurora クラスターをアップグレードしようとすると、Aurora はインスタンスを再開してアップグレードします。
Aurora は、自動一時停止された Aurora Serverless v2 インスタンスを定期的に再開して、マイナーバージョンアップグレードやパラメータグループなどのプロパティの変更などのメンテナンスを実行します。
Aurora Serverless v2 インスタンスがアップグレードやメンテナンス適用などの管理オペレーションのために起動すると、Aurora はそのインスタンスを再度一時停止するまで少なくとも 20 分待機します。これは、バックグラウンドオペレーションを完了できるようにするためです。また、この 20 分間は、インスタンスで複数の管理オペレーションを連続して実行する場合に、インスタンスが何度も一時停止および再開されるのを防ぐ役割も果たします。

Aurora Serverless v2 と Aurora Serverless v1 の自動一時停止動作の違い

Aurora Serverless v2 では、再開時間が Aurora Serverless v1 と比較して改善されています。インスタンスが 24 時間未満一時停止されていた場合、再開にかかる時間は通常約 15 秒です。インスタンスが 24 時間以上一時停止されている場合、再開時間はそれより長くなる可能性があります。
Aurora Serverless v2 がマルチ AZ クラスターに適用される方法は、クラスター内の一部の DB インスタンスが、他のインスタンスがアクティブな間に一時停止される可能性があることを意味します。ライターインスタンスは、リーダーが実行中の場合に再開されます。これは、クラスター内の特定のアクティビティを調整するためにライターが必要になるためです。Aurora Serverless v1 はリーダーインスタンスを使用しないため、クラスター全体が常に一時停止しているか、アクティブであることになります。
リーダーエンドポイントが接続するリーダーインスタンスをランダムに選択する場合、そのリーダーインスタンスが既にアクティブになっているか、自動一時停止している可能性があります。したがって、リーダーインスタンスにアクセスする時間は変動する可能性があり、予測が難しくなる可能性があります。そのため、Aurora Serverless v2 および自動一時停止を使用するマルチ AZ クラスターでは、すべての読み取り専用セッションをリーダーエンドポイントにルーティングする代わりに、特定の読み取り専用ユースケース用にカスタムエンドポイントを設定するとメリットが得られる場合があります。
Aurora Serverless v2 インスタンスでは、プロビジョンドインスタンスと同じ頻度でメンテナンス操作が実施されます。このようなメンテナンスが必要な場合、Aurora は自動的にインスタンスを再開するため、Aurora Serverless v2 インスタンスが Aurora Serverless v1 クラスターよりも頻繁に再開する可能性があります。

さまざまなタイプの Aurora クラスターでの Aurora Serverless v2 自動一時停止の仕組み

自動一時停止機能に関する考慮事項は、Aurora クラスター内のインスタンスの数、リーダーインスタンスのフェイルオーバー昇格階層、すべてのインスタンスが Aurora Serverless v2 か、Aurora Serverless v2 とプロビジョンドインスタンスの組み合わせであるかによって異なります。

トピック

Aurora クラスターレイアウト
ライターインスタンスの自動一時停止
マルチ AZ クラスターとリーダーインスタンスの自動一時停止
混合クラスターの自動一時停止

自動一時停止を使用する場合に推奨される Aurora クラスターレイアウト

自動一時停止機能が有効になっている場合、Aurora クラスターを、ユースケースに合わせて高可用性、迅速な応答、スケーラビリティのバランスが適切になるよう調整できます。そのためには、クラスター内の DB インスタンスに対して、Aurora Serverless v2 インスタンス、プロビジョンドインスタンス、フェイルオーバー昇格階層の組み合わせを選択します。

次のタイプの設定は、クラスターの高可用性とコスト最適化のさまざまなトレードオフを示しています。

開発およびテストシステムの場合、Aurora Serverless v2 DB インスタンスを使用してシングル AZ DB クラスターを設定できます。単一のインスタンスが、すべての読み取りおよび書き込みリクエストを処理します。クラスターが長時間使用されない場合、DB インスタンスは一時停止します。その時点で、クラスターの DB コンピューティングコストも一時停止されます。
高可用性が優先されるアプリケーションを実行しているシステムで、クラスターが完全にアイドル状態になる期間がある場合は、ライター DB インスタンスとリーダー DB インスタンスの両方が Aurora Serverless v2 であるマルチ AZ クラスターを設定できます。リーダーインスタンスのフェイルオーバー優先順位を 0 または 1 に設定すると、ライターインスタンスとリーダーインスタンスの両方が同時に一時停止および再開されます。これにより、クラスターがアクティブな間に、迅速なフェイルオーバーというメリットを得ることができます。クラスターが自動一時停止のしきい値よりも長い間アイドル状態を維持する場合、両方のインスタンスに対する DB インスタンスの料金は発生しなくなります。クラスターが処理を再開すると、最初のデータベースセッションの接続に少し時間がかかります。
クラスターが最小限のアクティビティで常にアクティブであり、任意の接続に対して迅速な応答が必要であるとします。その場合、複数の Aurora Serverless v2 リーダーインスタンスを持つクラスターを作成し、一部のリーダーインスタンスの容量をライターインスタンスから分離することができます。ライターインスタンスと 1 つのリーダーインスタンスのフェイルオーバー優先順位を 0 または 1 を指定します。他のリーダーインスタンスに 1 より大きい優先順位を指定します。これにより、ライターとリーダーの 1 つがアクティブなままであっても、優先度の高い階層にあるリーダーインスタンスは自動一時停止できます。

この場合、アイドル期間中に低容量にスケールダウンしつつ、クラスターが継続的に利用可能になるように、他のいくつかの手法を採用できます。
- ライターと優先順位が 0 または 1 のリーダーには、プロビジョンドインスタンスを使用できます。これにより、2 つの DB インスタンスは自動一時停止することなく、データベーストラフィックの処理やフェイルオーバーの実行のために常に利用可能となります。
- 優先度の高い階層の Aurora Serverless v2 インスタンスを含むカスタムエンドポイントを設定できますが、ライターまたは昇格階層 0 または 1 のリーダーを含めることはできません。これにより、レイテンシーの影響を受けない読み取り専用セッションを、自動一時停止されている可能性のあるリーダーにルーティングすることができます。このようなリクエストにリーダーエンドポイントを使用することを回避できます。Aurora は、常に稼働状態にあるリーダーインスタンス、または自動一時停止中のインスタンスの 1 つにリーダーエンドポイント接続をルーティングする可能性があるためです。カスタムエンドポイントを使用すると、迅速な応答または追加のスケーリング容量の設定に基づいて、異なるインスタンスグループに接続をルーティングすることができます。

DB クラスターのライターインスタンスでの Aurora Serverless v2 自動一時停止の仕組み

Aurora DB クラスターに DB インスタンスが 1 つだけ含まれている場合、DB インスタンスを自動一時停止および再開するメカニズムはシンプルです。これはライターインスタンスでのアクティビティにのみ依存します。開発とテストに使用されるクラスターや、高可用性が重要でないアプリケーションを実行するためのクラスターで、このような設定を使用する場合があります。単一インスタンスクラスターでは、Aurora はリーダーエンドポイントを介してライター DB インスタンスに接続をルーティングすることに注意してください。そのため、単一インスタンス DB クラスターの場合、リーダーエンドポイントに接続しようとすると、自動一時停止中のライター DB インスタンスが再開されます。

複数の DB インスタンスを持つ Aurora クラスターには、次の追加要素が適用されます。

Aurora DB クラスター内では、ライター DB インスタンスは通常頻繁にアクセスされます。したがって、1 つ以上のリーダー DB インスタンスが自動的に一時停止しても、ライター DB インスタンスはアクティブなままになることがあります。
リーダー DB インスタンスでの特定のアクティビティでは、ライター DB インスタンスが利用可能であることが必要です。そのため、すべてのリーダーインスタンスが一時停止されるまで、ライター DB インスタンスを一時停止することはできません。リーダーインスタンスを再開すると、アプリケーションがライターインスタンスに直接アクセスしていない場合でも、ライターインスタンスが自動的に再開されます。
フェイルオーバー昇格階層が 0 と 1 の Aurora Serverless v2 リーダーインスタンスは、ライターインスタンスと容量を同期するためにスケールします。したがって、Aurora Serverless v2 ライターインスタンスが再開すると、昇格階層が 0 または 1 の Aurora Serverless v2 リーダーインスタンスも再開します。

マルチ AZ クラスターでの Aurora Serverless v2 自動一時停止の仕組み

ライター DB インスタンスと 1 つ以上のリーダー DB インスタンスの両方を含む Aurora DB クラスター内では、他の DB インスタンスがアクティブな間、一部の Aurora Serverless v2 DB インスタンスが一時停止されることがあります。ライターインスタンスと、フェイルオーバー優先順位が 0 と 1 のリーダーインスタンスは、常にすべて同時に一時停止および再開します。優先順位が 0 または 1 以外のリーダーインスタンスは、他のインスタンスとは独立して一時停止および再開できます。

複数のリーダーインスタンスを持つクラスターでこの機能を使用すると、高可用性を犠牲にすることなくコストを管理できます。ライターインスタンスと別の 1 つまたは 2 つのリーダーインスタンスは常にアクティブ状態を維持でき、大量の読み取りトラフィックを処理するためにリーダーインスタンスが必要ない場合は、追加のリーダーインスタンスは一時停止することができます。

リーダーインスタンスが自動的に一時停止できるかどうかは、その容量が独立してスケールできるかどうか、または容量がライター DB インスタンスの容量に関連付けられているかどうかによって異なります。そのスケーリングプロパティは、リーダー DB インスタンスのフェイルオーバー優先順位に依存します。リーダーの優先順位が 0 または 1 の場合、リーダーの容量はライター DB インスタンスの容量を追跡します。そのため、リーダー DB インスタンスが最も広範な状況で自動的に一時停止できるようにするには、優先順位を 1 より大きい値に設定します。

リーダーインスタンスの再開にかかる時間は、ライターインスタンスの再開よりも少し長くなる可能性があります。インスタンスが一時停止されている可能性がある場合に最も迅速な応答を得るには、クラスターエンドポイントに接続します。

プロビジョンドインスタンスを持つクラスターでの Aurora Serverless v2 自動一時停止の仕組み

Aurora DB クラスター内のプロビジョンド DB インスタンスは自動的に一時停止しません。db.serverless インスタンスクラスを持つ Aurora Serverless v2 DBインスタンスのみが、自動一時停止機能を使用できます。

Aurora クラスターにプロビジョンド DB インスタンスが含まれている場合、Aurora Serverless v2 ライターインスタンスは自動的に一時停止しません。これは、リーダーインスタンスがアクティブな間、ライターインスタンスが利用可能である必要があるという要件のためです。Aurora Serverless v2 ライターがアクティブ状態を維持することは、フェイルオーバー優先順位が 0 と 1 の Aurora Serverless v2 リーダーインスタンスが、プロビジョンドインスタンスを含むハイブリッドクラスター内で自動一時停止しないことも意味します。

自動一時停止を使用する Aurora クラスターのモニタリング

Aurora をモニタリングするには、「Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング」のモニタリング手順と「Amazon Aurora のメトリクスリファレンス」に記載されている CloudWatch メトリクスを理解しておく必要があります。自動一時停止機能を使用する Aurora クラスターをモニタリングする場合は、特別な考慮事項がいくつかあることに注意してください。

インスタンスが一時停止されているため、Aurora Serverless v2 インスタンスがログデータやほとんどのメトリクスを記録しない期間が発生する場合があります。インスタンスが一時停止されている間に CloudWatch に送信される唯一のメトリクスは、CPUUtilization と ACUUtilization では 0%、ServerlessDatabaseCapacity では 0 です。
Aurora Serverless v2 インスタンスが想定よりも高頻度または低頻度で一時停止しているかを確認できます。これを行うには、ServerlessDatabaseCapacity メトリクスがゼロ以外の値からゼロに変わる頻度と、ゼロの状態がどれくらい続くかを確認します。インスタンスが想定どおりに一時停止を維持しない場合、コスト節約の効果が十分に得られません。インスタンスが想定よりも頻繁に一時停止および再開する場合、接続リクエストへの応答時にクラスターで不要なレイテンシーが発生する可能性があります。Aurora Serverless v2 インスタンスが一時停止できるかどうか、および一時停止する頻度に影響する要因の詳細については、「Aurora Serverless v2 自動一時停止機能の前提条件と制限」、「Aurora Serverless v2 が自動一時停止しない状況」、「Aurora Serverless v2 自動一時停止のトラブルシューティング」を参照してください。
Aurora Serverless v2 インスタンスの自動一時停止および再開オペレーションを記録するログファイルを調べることもできます。タイムアウト間隔の経過後にインスタンスが一時停止しなかった場合、このログファイルには自動一時停止が行われなかった理由も記録されます。詳細については、「Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング」を参照してください。

トピック

一時停止したインスタンスの確認
自動一時停止および自動再開のイベント
Performance Insights と拡張モニタリング
Aurora のメトリクス

Aurora Serverless v2 インスタンスが一時停止されているかどうかを確認する

Aurora Serverless v2 インスタンスが一時停止状態にあるかどうかを判断するには、インスタンスの ACUUtilization メトリクスを確認します。インスタンスが一時停止している間、そのメトリクスの値は 0 です。

Aurora Serverless v2 インスタンスが一時停止されている間も、そのステータス値は [利用可能] と表示されます。一時停止した Aurora Serverless v2 インスタンスが再開中である場合も同様です。これは、接続にわずかな遅延が発生した場合でも、このようなインスタンスに正常に接続できるためです。

Aurora インスタンスの可用性に関連するメトリクスでは、インスタンスが一時停止している期間をインスタンスが利用可能であった時間と見なします。

自動一時停止および自動再開オペレーションのイベント

Aurora は、自動一時停止および自動再開オペレーションの開始、完了、またはキャンセル時に Aurora Serverless v2 インスタンスのイベントを発行します。自動一時停止機能に関連するイベントは、RDS-EVENT-0370 から RDS-EVENT-0374 です。これらのイベントの詳細については、「DB インスタンスイベント」を参照してください。

Performance Insights と拡張モニタリングでの自動一時停止の仕組み

Aurora Serverless v2 インスタンスが一時停止している間、Aurora は Performance Insights または拡張モニタリングを通じてそのインスタンスのモニタリング情報を収集しません。インスタンスが再開されると、Aurora がそのようなモニタリング情報の収集を再開するまでに少し時間がかかる場合があります。

Aurora Serverless v2 自動一時停止機能が Aurora メトリクスとどのようにやり取りするか

Aurora Serverless v2 インスタンスが一時停止されている間は、ほとんどの CloudWatch メトリクスを出力したり、データベースログに情報を書き込んだりすることはありません。インスタンスが一時停止されている間に CloudWatch に送信される唯一のメトリクスは、CPUUtilization と ACUUtilization では 0%、ServerlessDatabaseCapacity では 0 です。

CloudWatch がインスタンスまたはクラスターの可用性とアップタイムに関連する統計を計算する際、Aurora Serverless v2 インスタンスは一時停止中でも利用可能であると見なされます。

AWS CLI または RDS API アクションを開始して、一時停止中の Aurora Serverless v2 インスタンスのログを記述またはダウンロードすると、そのインスタンスは自動的に再開され、ログ情報が使用可能になります。

CloudWatch メトリクスの例

次の AWS CLI の例は、時間の経過とともに変化するインスタンスの容量を観察する方法を示しています。この期間中、インスタンスは自動一時停止し、その後再開します。一時停止している間、ServerlessDatabaseCapacity メトリクスは 0 の値をレポートします。インスタンスがこの期間内の任意の時点で一時停止されたかどうかを判断するために、その期間中の最小容量がゼロだったかどうかを確認します。

次の Linux の例は、しばらく自動的に一時停止された Aurora Serverless v2 インスタンスを表しています。3 分間にわたり、毎分 ServerlessDatabaseCapacity をサンプリングします。最小 ACU 値が 0.0 であることから、インスタンスが各分のいずれかの時点で一時停止されたことが確認できます。



$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

次に、一時停止した Aurora Serverless v2 インスタンスへの接続を試みます。この例では、接続試行が成功しないように、意図的に間違ったパスワードを使用します。失敗しても、接続の試行により、Aurora は一時停止したインスタンスを再開します。



$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

次の Linux の例は、一時停止したインスタンスが再開され、約 5 分間アイドル状態を維持した後、一時停止状態に戻ったことを示しています。インスタンスは 2.0 ACU の容量で再開しました。その後、内部クリーンアップなどを実行するために、わずかにスケールアップしました。5 分間のタイムアウト期間内にユーザー接続の試行がなかったため、4.0 ACU から直接一時停止状態になりました。



$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

レポートの目的が、ワークロードを処理するためにインスタンスがいかに速くスケールアップしたかを示すことである場合、統計に Minimum ではなく Maximum を指定できます。キャパシティプランニングとコスト見積もりのためには、より長い期間を指定し、Average 統計を使用できます。これにより、高アクティビティ、低アクティビティ、一時停止状態の期間中の一般的な容量値を判断できます。一時停止と再開の前後の正確な時点での動作を確認するには、1 秒の期間を指定し、短い時間間隔を調べることができます。2024-08-02T22:13:00+00:00 などの出力のタイムスタンプ値は、--start-time と --end-time オプションの正確なパラメータを指定する形式を示しています。

Aurora Serverless v2 自動一時停止のトラブルシューティング

Aurora Serverless v2 インスタンスが想定した頻度で一時停止していない場合は、次の考えられる原因を確認してください。

実行中の Aurora バージョンがゼロ ACU の最小容量をサポートしていることを確認します。さまざまな Aurora バージョンの容量範囲については、「Aurora Serverless v2 の容量」を参照してください。
クラスターの最小容量値がゼロ ACU に設定されていることを確認します。
問題のインスタンスが、プロビジョニングされたインスタンスクラスの 1 つではなく、Aurora Serverless v2 インスタンスクラス db.serverless を実際に使用していることを確認します。
クラスターが「Aurora Serverless v2 自動一時停止機能の前提条件と制限」に記載されている互換性のない機能や設定を使用していないことを確認します。
Aurora Serverless v2 インスタンスが一時停止したとき、再開したとき、または Aurora が何らかの理由でインスタンスを一時停止または再開できなかったときを示すログファイルを調べます。詳細については、「Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング」を参照してください。
クライアントまたはアプリケーションで接続が長時間開いたままになっていないかを確認します。逆に、RDS Data API または Lambda 関数を使用するアプリケーションが頻繁にリクエストを送信しているために、インスタンスが十分にアイドル状態にならず、インスタンスが一時停止できなくなっていないかどうかを確認します。ConnectionAttempts や DatabaseConnections などの CloudWatch メトリクスを調べることができます。詳細については、「Amazon Aurora のインスタンスレベルのメトリクス」を参照してください。
リーダーインスタンスがほとんど一時停止しない場合は、フェイルオーバー優先順位を確認します。リーダーが読み取りスケーリングに使用され、フェイルオーバーの場合にスタンバイとして使用されない場合は、2～15 の範囲で優先順位を設定します。
ライターインスタンスがほとんど一時停止しない場合は、リーダーインスタンスの使用状況を確認します。ライターは、クラスター全体がアイドル状態の場合にのみ一時停止できます。これは、リーダーインスタンスへの接続によってライターが再開されるためです。
Aurora Serverless v2 インスタンスの再開中にアプリケーションで接続リクエストのタイムアウトが発生する場合は、アプリケーションコードや基盤となるデータベースフレームワークで使用するタイムアウト間隔を長くすることを検討してください。接続タイムアウトを長くすると、Aurora Serverless v2 インスタンスの再開中に接続が失敗する可能性が低くなります。ただし、タイムアウトが長くなると、アプリケーションがクラスターの可用性の問題を検出するのが遅くなる可能性もあります。

逆に、アプリケーションでインスタンスの一時停止が頻繁に発生しないように、自動一時停止の間隔を長くすることを検討してください。

アプリケーションの自動一時停止動作とクラスターの応答性の間に論理的なバランスが取れていない場合、そのクラスターは自動一時停止機能の使用に適していない可能性があります。
Aurora Serverless v2 インスタンスの一時停止時間を見積もる場合は、正確な予測を難しくする要因があることに注意してください。
- メンテナンスやマイナーバージョンアップグレードを実行したり、パラメータグループに変更を適用したりするために、インスタンスが定期的に再開する可能性があります。
- マルチ AZ クラスターの場合、1 つのインスタンスを再開すると、他のインスタンスも再開することがあります。リーダーを再開すると、必ずライターが再開されます。ライターを再開すると、必ず、フェイルオーバー優先順位が 0 と 1 のすべてのリーダーが再開されます。
数日間にわたって、現実的なワークロードで実際の一時停止時間を測定することをお勧めします。その後、これらの測定値を使用して、インスタンスの一時停止が予想される時間の割合の基準を設定します。
MySQL パージ、MySQL イベントスケジューラ、PostgreSQL 自動バキューム、pg_cron 拡張機能を介してスケジュールされた PostgreSQL ジョブなどの内部オペレーションが実行されない、または完了しない場合があります。インスタンスは、データベースへのユーザー接続が関与しないこうしたオペレーションを実行するために、自動的に再開しません。自動一時停止タイムアウト期間が経過した時点で、こうした内部オペレーションが進行中の場合、MySQL パージや PostgreSQL 自動バキュームなどのメンテナンスタスクはキャンセルされます。Aurora が一時停止オペレーションを開始する際、MySQL イベントスケジューラまたは PostgreSQL pg_cron 拡張機能からスケジュールされたジョブが進行中の場合もキャンセルされます。

スケジュールされたオペレーションを実行するためにインスタンスが定期的に起動することを確認する必要がある場合は、ジョブの開始時刻より前にインスタンスを再開するために接続を開始できます。また、ユーザーアクティビティの完了後に自動バキュームなどのオペレーションを長く実行できるように、自動一時停止タイムアウト間隔を長くすることもできます。また、Lambda 関数などのメカニズムを使用して、必要に応じてインスタンスが自動的に再開されるように、一定のスケジュールでデータベースオペレーションを実行することもできます。

Aurora Serverless v2 自動一時停止機能のアプリケーション設計に関する考慮事項

Aurora Serverless v2 DB インスタンスが自動的に一時停止された後に再開する場合、比較的小さな容量から開始してスケールアップします。この開始容量は、DB インスタンスが自動的に一時停止される直前に高い容量を持っていた場合でも適用されます。

この機能は、接続の確立に約 15 秒の間隔を許容できるアプリケーションで使用します。これは、1 つまたは少数の受信接続によって Aurora Serverless v2 インスタンスが再開される一般的なケースを考慮しています。インスタンスが 24 時間以上一時停止している場合、再開時間はそれより長くなる可能性があります。

アプリケーションが既に Aurora Serverless v1 とその自動一時停止機能を使用している場合は、接続試行に対してこのようなタイムアウト間隔が既に設定されている可能性があります。Aurora クラスターの停止/開始機能と組み合わせて Aurora Serverless v2 を既に使用している場合、自動一時停止された Aurora Serverless v2 インスタンスの再開時間は、通常、停止したクラスターを開始する時間よりもはるかに短くなります。

アプリケーションで接続ロジックをコーディングする際、最初の試行で一時的な原因によるエラーが返された場合は、接続を再試行します。(認証の失敗がエラーの原因である場合は、再試行の前に認証情報を修正してください。) 再開直後に発生するエラーは、タイムアウトであるか、データベースの制限に関連するエラーである可能性があります。再試行することで、Aurora Serverless v2 インスタンスが多数の同時接続リクエストにより再開されるというまれなケースで発生する問題に対処できます。この場合、一部の接続の処理に通常よりも時間がかかったり、最初の試行で同時接続の制限を超えたりすることがあります。

アプリケーションの開発およびデバッグ中は、クライアントセッションやプログラミングツールでデータベースへの接続を開いたままにしないでください。ユーザーが開始した接続が開いている場合、その接続が SQL ステートメントやトランザクションを実行していないかどうかにかかわらず、Aurora はインスタンスを一時停止しません。Aurora クラスター内の 1 つの Aurora Serverless v2 インスタンスを一時停止できない場合、クラスター内の他のインスタンスも一時停止できないことがあります。詳細については、「Aurora Serverless v2 が自動一時停止しない状況」を参照してください。

Aurora は、Aurora Serverless v2 DB インスタンスが再開を開始したとき、再開を完了したとき、何らかの理由でインスタンスが再開できない場合に、イベントを発行します。これらのイベントの詳細については、「DB インスタンスイベント」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Aurora Serverless v2 でのパフォーマンスとスケーリング

Aurora Serverless v2 への移行