Aurora Serverless v1 の仕組み - Amazon Aurora

Aurora Serverless v1 の仕組み

Aurora Serverless v1 がどのように機能しているのかがわかります。

Aurora Serverless v1 アーキテクチャ

次のイメージは、Aurora Serverless v1 アーキテクチャの概要を示しています。


        Aurora Serverless v1 アーキテクチャ

データベースサーバーをプロビジョニングして管理する代わりに、Aurora 容量ユニット (ACU) を指定します。各 ACU では、約 2 GB (GB) のメモリ、対応する CPU、およびネットワーキングが組み合わせられています。データベースストレージは、自動的に 10 ギビバイト (GiB) から 128 tebibytes (TiB) にスケールします (スタンダード Aurora DB クラスターのストレージと同じです)。

最小と最大の ACU を指定できます。Aurora の最小容量ユニットは、DB クラスターをスケールダウンできる最小の ACU です。Aurora の最大容量ユニットは、DB クラスターをスケールアップできる最大の ACU です。設定に応じて、CPU 使用率、接続、および使用可能メモリの各しきい値に関するスケーリングルールが、Aurora Serverless v1 により自動的に作成されます。

Aurora Serverless v1 は、AWS リージョン のリソースのウォームプールを管理し、スケーリング時間を最小限に短縮します。Aurora Serverless v1 は、Aurora DB クラスターに新しいリソースを追加する際、ルーターフリートを使用してアクティブなクライアント接続を新しいリソースに切り替えます。いつの時点においても、Aurora DB クラスターで実際に使用している ACU 分のみ課金されます。

Aurora Serverless v1 のオートスケーリング

Aurora Serverless v1 DB クラスターに割り当てられる容量は、クライアントアプリケーションによって生成された負荷に対応して、シームレスに拡大および縮小されます。ここでは、負荷は CPU 使用率と接続数です。これらのいずれかによって容量が制約されると、Aurora Serverless v1 がスケールアップします。 また、スケールアップすることで解決できるパフォーマンスの問題を検出すると、Aurora Serverless v1 もスケールアップします。

Aurora Serverless v1 で AWS Management Console クラスターのスケーリングイベントを表示できます。オートスケーリングの実行中に、Aurora Serverless v1 により、EngineUptime メトリクスがリセットされます。リセットメトリクス値の値は、シームレススケーリングに問題があったことを意味するものでも、Aurora Serverless v1 が接続を切断したことを意味するものでもありません。これは、新しい容量での稼働時間のスタート点に過ぎません。詳細については、「Amazon Aurora クラスターでのメトリクスのモニタリング」を参照してください。

Aurora Serverless v1 DB クラスターにアクティブな接続がない場合、容量ゼロ (0 ACU) にスケールダウンできます。詳細については、「Aurora Serverless v1 の一時停止と再開」を参照してください。

スケーリング操作を実行する必要がある場合は、Aurora Serverless v1 は初期にスケーリングポイントを特定しようとします。これは、クエリが処理されていない瞬間です。Aurora Serverless v1 は、 次の理由により、スケーリングポイントを見つけることができない場合があります。

  • クエリの実行時間が長い

  • トランザクションが進行中である

  • テンポラリテーブルまたはテーブルがロックされている

スケーリングポイントを見つけるときに Aurora Serverless v1 DB クラスターの成功率を上げるには、長時間実行されるクエリや長時間実行されるトランザクションを回避することをお勧めします。スケーリングをブロックするオペレーションとそれらを回避する方法の詳細については、「Aurora Serverless v1 を使用するためのベストプラクティス」を参照してください。

デフォルトでは、Aurora Serverless v1 は、スケーリングポイントを 5 分 (300 秒) で見つけようとします。クラスターの作成時または変更時に、別のタイムアウト期間を指定できます。タイムアウト期間は、60 秒~10 分 (600 秒) の間で指定できます。Aurora Serverless v1 が、指定した期間以内にスケーリングポイントが見つからない場合、オートスケーリング操作がタイムアウトします。

デフォルトでは、オートスケーリングがタイムアウトする前にスケーリングポイントを見つけられない場合、Aurora Serverless v1 はクラスターを現在の容量で維持します。[Force the capacity change] (容量の変更を強制する) オプションを選択して Aurora Serverless v1 DB クラスターを作成または変更するときに、このデフォルトの動作を変更できます。詳細については、「容量の変更のタイムアウトアクション」を参照してください。

容量の変更のタイムアウトアクション

スケーリングポイントが見つからずにオートスケーリングがタイムアウトした場合、デフォルトでは Aurora は現在の容量を維持します。[Force the capacity change] (容量の変更を強制する) オプションを有効にすることで、Aurora で変更を強制することを選択できます。このオプションは、クラスターを作成するときに、[Create database] (データベースの作成) ページの [Autoscaling timeout and action] (オートスケーリングのタイムアウトとアクション) セクションで使用できます。

デフォルトでは、[Force the capacity change] (容量を強制的に変更する) オプションは選択解除されています。スケーリングポイントが見つからずにスケーリング操作がタイムアウトした場合に Aurora Serverless v1 DB クラスターの容量を変更しないようにするには、このオプションをオフのままにします。

このオプションを選択すると、Aurora Serverless v1 DB クラスターを使用して、スケーリングポイントがない場合でも、容量変更を強制します。このオプションを選択する前に、次の選択の結果に注意してください。

  • 処理中のトランザクションはすべて中断され、次のエラーメッセージが表示されます。

    Aurora MySQL 5.6 - ERROR 1105 (HY000): The last transaction was aborted due to an unknown error. Please retry.

    Aurora MySQL 5.7 - ERROR 1105 (HY000): The last transaction was aborted due to Seamless Scaling. Please retry.

    このトランザクションは、Aurora Serverless v1 DB クラスターが利用できるようになり次第、再送信できます。

  • テンポラリテーブルとロックへの接続は削除されます。

    アプリケーションが切断された接続または不完全なトランザクションから回復できる場合にのみ、[Force the capacity change] (容量を強制的に変更する) オプションを選択することをお勧めします。

Aurora Serverless v1 DB クラスターを作成するときに AWS Management Console で行った選択は、SecondsBeforeTimeout および TimeoutActionプロパティの ScalingConfigurationInfo オブジェクトに格納されます。クラスターを作成すると、TimeoutAction プロパティの値は次のいずれかの値に設定されます。

  • RollbackCapacityChange - この値は、[Roll back the capacity change] (容量の変更をロールバックする) オプションを選択したときに設定されます。これがデフォルトの動作です。

  • ForceApplyCapacityChange - この値は、[Force the capacity change] (容量の変更を強制する) オプションを選択したときに設定されます。

次に示すように、describe-db-clusters Aurora Serverless v1 コマンドを使用して、既存の AWS CLI DB クラスターでこのプロパティの値を取得できます。

Linux、macOS、Unix の場合:

aws rds describe-db-clusters --region region \ --db-cluster-identifier your-cluster-name \ --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Windows の場合:

aws rds describe-db-clusters --region region ^ --db-cluster-identifier your-cluster-name ^ --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

例として、米国西部 (北カリフォルニア) リージョンにある、west-coast-sles という名前の Aurora Serverless v1 DB クラスターに対するクエリとその応答を次に示します。

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}' [ { "ScalingConfigurationInfo": { "MinCapacity": 1, "MaxCapacity": 64, "AutoPause": false, "SecondsBeforeTimeout": 300, "SecondsUntilAutoPause": 300, "TimeoutAction": "RollbackCapacityChange" } } ]

応答が示すように、この Aurora Serverless v1 DB クラスターはデフォルト設定を使用しています。

詳細については、「Aurora Serverless v1 DB クラスターの作成」を参照してください。Aurora Serverless v1 を作成した後、タイムアウトアクションやその他の容量設定はいつでも変更できます。この方法については、「Aurora Serverless v1 DB クラスターの変更」を参照してください。

Aurora Serverless v1 の一時停止と再開

Aurora Serverless v1 DB クラスターでは、アクティビティなしの状態が一定時間継続した場合に、一時停止させるような設定が可能です。DB クラスターを一時停止するまでのアクティビティなしの時間を指定します。このオプションを選択すると、デフォルトの非アクティブ時間は 5 分ですが、この値は変更できます。これは任意の設定です。

DB クラスターを一時停止すると、コンピューティングまたはメモリのアクティビティが完全に停止し、ストレージに対してのみ課金されます。Aurora Serverless v1 DB クラスターの一時停止中にデータベース接続がリクエストされると、DB クラスターは自動的に再開して接続リクエストに対応します。

DB クラスターがアクティビティを再開すると、Aurora がクラスターを一時停止したときと同じ容量になります。ACU の数は、クラスターを一時停止する前に Aurora がスケールアップまたはスケールダウンした程度によって異なります。

注記

DB クラスターを一時停止してから 7 日間を超えると、DB クラスターはスナップショットからバックアップされる場合があります。この場合、接続要求がある場合、Aurora は DB クラスターをスナップショットから復元します。

Aurora Serverless v1 のパラメータグループ

Aurora Serverless v1 DB クラスターの作成時に、特定の Aurora DB エンジンと、それに関連する DB クラスターパラメータグループを選択します。プロビジョニングされた Aurora DB クラスターとは異なり、Aurora Serverless v1 DB クラスターには単一の読み取り/書き込み DB インスタンスがあり、DB クラスターパラメータグループで構成されているだけで、— 個別の DB パラメータグループはありません。オートスケーリング中、Aurora Serverless v1 は、容量の増減に対してクラスターが最適に機能するように、パラメータを変更できる必要があります。したがって、Aurora Serverless v1 DBクラスターでは、特定のDBエンジンタイプのパラメータに加える可能性のある変更の一部が適用されないことがあります。

例えば、Aurora PostgreSQL-ベースAurora Serverless v1の DB クラスターは、クエリプラン管理のためにプロビジョンド Aurora PostgreSQL DB クラスターで使用される可能性のある apg_plan_mgmt.capture_plan_baselines とその他のパラメータを使用できません。

CLI コマンドの describe-engine-default-cluster-parameters を使用し AWS リージョン に対しクエリすることで、さまざまな Aurora DB エンジンのデフォルトパラメータグループのデフォルト値のリストを取得できます。--db-parameter-group-family オプションに使用できる値は次のとおりです。

Aurora MySQL 5.6

aurora5.6

Aurora MySQL 5.7

aurora-mysql5.7

Aurora PostgreSQL 10.12 (以降)

aurora-postgresql10

AWS アクセスキー ID と AWS シークレットアクセスキーを使用して AWS CLI を設定し、AWS CLI コマンドを使用する前に AWS リージョン を設定することをお勧めします。CLI 設定にリージョンを指定すると、コマンドの実行時に --region パラメータを入力する手間が省けます。AWS CLI の設定の詳細については、AWS Command Line Interface ユーザーガイドの「設定の基本」を参照してください。

次の例では、Aurora MySQL 5.6 のデフォルトの DB クラスターグループからパラメータのリストを取得します。

Linux、macOS、Unix の場合:

aws rds describe-engine-default-cluster-parameters \ --db-parameter-group-family aurora5.6 --query \ 'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \ --output text

Windows の場合:

aws rds describe-engine-default-cluster-parameters ^ --db-parameter-group-family aurora5.6 --query ^ "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^ --output text

Aurora Serverless v1 のパラメータ値の変更

パラメータグループを使用する で説明したように、デフォルトのパラメータグループの値は、そのタイプ (DBクラスターパラメータグループ、DBパラメータグループ) に関係なく、直接変更することはできません。代わりに、Aurora DB エンジンのデフォルトの DB クラスターパラメータグループに基づいてカスタムパラメータグループを作成し、そのパラメータグループの設定を必要に応じて変更します。例えば、Aurora Serverless v1 DB クラスターの設定の一部を変更して、クエリをログに記録したり、DB エンジン固有のログを Amazon CloudWatch にアップロードしたりできます。

カスタム DB クラスターパラメータグループを作成するには

  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

  2. [パラメータグループ] を選択します。

  3. [パラメータグループの作成] をクリックして、パラメータグループの詳細ペインを開きます。

  4. Aurora Serverless v1 DB クラスターに使用する DB エンジンに適切なデフォルト DB クラスターグループを選択します。必ず次のオプションを選択してください。

    1. [パラメータグループファミリ] で、選択した DB エンジンに適したファミリを選択します。選択内容の名前には、aurora- プレフィックスが含まれていることを確認してください。

    2. [Type] で、[DB Cluster Parameter Group] を選択します。

    3. [グループ名] と [説明] に、ご自身や、Aurora Serverless v1 DB クラスターとそのパラメータを操作する必要がある他のユーザーにとって、わかりやすい名前を入力します。

    4. [Create] を選択します。

カスタム DB クラスターパラメータグループが、お使いの AWS リージョン で使用できる、パラメータグループのリストに追加されます。これで、新しい Aurora Serverless v1 DB クラスターを作成する際に、このカスタムDB クラスターパラメータグループを使用できるようになります。カスタム DB クラスターパラメータグループが使用されように、既存の Aurora Serverless v1 DB クラスターを変更することもできます。ご使用の Aurora Serverless v1 DB クラスターがカスタム DB クラスターパラメータグループの使用をスタートしたら、AWS Management Console または AWS CLI を使用して動的パラメータの値を変更できます。

コンソールを使用して、次のスクリーンショットに示すように、カスタム DB クラスターパラメータグループの値をデフォルトの DB クラスターパラメータグループと比較した値を並べて表示することもできます。


          Aurora MySQL 用の CloudWatch Logs、および Aurora PostgreSQL の Aurora Serverless v1 DB クラスターに公開されたログ

アクティブな DB クラスターのパラメータ値を変更すると、Aurora Serverless v1 は、パラメータの変更を適用するために、シームレスなスケーリングをスタートします。Aurora Serverless v1 DB クラスターは「一時停止」状態にあり、変更を行うことができるように再開してスケーリングをスタートします。パラメータグループ変更のスケーリング操作は常に容量の変更を強制するため、スケーリング期間中にスケーリングポイントが見つからない場合、パラメータを変更すると接続が切断される可能性があることに注意してください。

Aurora Serverless v1 のログ記録

デフォルトでは、Aurora Serverless v1 のエラーログが有効になっており、Amazon CloudWatch に自動的にアップロードされます。また、Aurora Serverless v1 DB クラスターは、Aurora データベースエンジン固有のログを CloudWatch にアップロードします。これを行うには、カスタム DB クラスターパラメータグループで設定パラメータを有効にします。Aurora Serverless v1 DB クラスターは、使用可能なすべてのログを Amazon CloudWatch にアップロードします。CloudWatch を使用すると、ログデータの分析や、CloudWatch を使用したアラームの作成、メトリクスの表示を行うことができます。

Aurora MySQL については、次のログを有効にして、Aurora Serverless v1 DB クラスターから Amazon CloudWatch に自動的にアップロードすることができます。

Aurora MySQL ログ 説明

general_log

一般ログを作成します。オンにするには、1 に設定します。デフォルトはオフ (0) です。

log_queries_not_using_indexes

インデックスを使用しないスロークエリログにクエリを記録します。デフォルトはオフ (0) です。このログを有効にするには、1 に設定します。

long_query_time

高速実行クエリがスロークエリログに記録されないようにします。0 から 3,1536,000 までの浮動小数点数に設定できます。デフォルトは 0 (アクティブではない) です。

server_audit_events

ログにキャプチャするイベントのリスト。サポートされている値は CONNECTQUERYQUERY_DCLQUERY_DDLQUERY_DMLTABLE です。

server_audit_logging

この値を 1 に設定すると、サーバー監査ログ記録がオンになります。これをオンにしている場合は、CloudWatch に送信する監査イベントを、server_audit_events パラメータにリストアップすることで指定できます。

slow_query_log

スロークエリログを作成します。スロークエリログをオンにするには、1 に設定します。デフォルトはオフ (0) です。

詳細については、「Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用」を参照してください。

Aurora PostgreSQL については、Aurora Serverless v1 DB クラスターで次のログを有効にして、Amazon CloudWatch に通常のエラーログとともに自動的にアップロードすることができます。

Aurora PostgreSQL ログ 説明

log_connections

デフォルトで有効になっており、変更できません。これは、すべての新しいクライアント接続の詳細をログに記録します。

log_disconnections

デフォルトで有効になっており、変更できません。クライアントの切断をすべてログに記録します。

log_lock_waits

デフォルトは 0 (オフ) です。ロック待機をログに記録するには、1 に設定します。

log_min_duration_statement

ステートメントがログに記録されるまでに実行される最小時間 (ミリ秒単位)。

log_min_messages

ログに記録するメッセージレベルを設定します。サポートされている値は debug5debug4debug3debug2debug1infonoticewarningerrorlogfatalpanic です。パフォーマンスデータを postgres ログに記録するには、値を debug1 に設定します。

log_temp_files

指定されたキロバイト (KB) を超えるテンポラリファイルの使用を記録します。

log_statement

ログに記録される特定の SQL ステートメントを制御します。サポートされている値は noneddlmodall です。デフォルトは none です。

Aurora Serverless v1 DB クラスターの Aurora MySQL 5.6、Aurora MySQL 5.7、または Aurora PostgreSQL のログをオンにすると、CloudWatch でログを表示できます。

Amazon CloudWatch を使用して Aurora Serverless v1 ログを表示する

Aurora Serverless v1 は DB クラスターのカスタムパラメータグループで有効になっているすべてのログを Amazon CloudWatch に自動的にアップロード (公開) します。ログの種類を選択または指定する必要はありません。ログのアップロードは、ログ設定パラメータを有効にするとすぐにスタートされます。後でログパラメータを無効にすると、それ以降のアップロードが停止します。ただし、既に CloudWatch に公開されているすべてのログは、削除するまで残ります。

CloudWatch と Aurora MySQL ログの使用の詳細については、「Amazon CloudWatch でログイベントをモニタリングする」を参照してください。

CloudWatch と Aurora PostgreSQL の詳細については、「Amazon CloudWatch Logs への Aurora PostgreSQL ログの発行」を参照してください。

Aurora Serverless v1 DB クラスターのログを表示するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. AWS リージョン を選択します。

  3. [ロググループ] を選択します。

  4. リストから Aurora Serverless v1 DB クラスターのログを選択します。エラーログの命名パターンは、次に従います。

    /aws/rds/cluster/cluster-name/error

例えば、次のスクリーンショットでは、western-sles という名前の Aurora PostgreSQL Aurora Serverless v1 DB クラスターに対して公開されたログのリストを見つけることができます。また、Aurora MySQL Aurora Serverless v1 DB クラスター、west-coast-sles のリストもいくつか見つけることができます。目的のログを選択して、そのコンテンツの探索をスタートします。


          Aurora MySQL 用の CloudWatch Logs、および Aurora PostgreSQL の Aurora Serverless v1 DB クラスターに公開されたログ

Aurora Serverless v1 とメンテナンス

最新の機能、修正、セキュリティ更新の適用など、Aurora Serverless v1 DB クラスターのメンテナンスは自動的に実行されます。プロビジョニングされた Aurora DB クラスターとは異なり、Aurora Serverless v1 にはユーザーが設定可能なメンテナンスウィンドウはありません。ただし、AWS Management Console DB クラスターの [ メンテナンスと バックアップ ] で、メンテナンスウィンドウを Aurora Serverless v1 に表示することができます。次に示すように、メンテナンスが実行される予定日時と、Aurora Serverless v1 DB クラスターで保留されているメンテナンスがあるかどうかが確認できます。


        Aurora Serverless v1 DB クラスターでのメンテナンスウィンドウの例、ユーザー設定不可、保留中のメンテナンスなし

Aurora Serverless v1 は、可能な限り、中断せずに、メンテナンスを実行します。メンテナンスが実施される場合、Aurora Serverless v1 DB クラスターは必要な操作を処理するために容量をスケールアップします。スケーリングする前に、Aurora Serverless v1 はスケーリングポイントを探します。必要に応じて最大 7 日間行います。

Aurora Serverless v1 によりスケーリングポイントが見つけられない場合は、その 1 日の終わりにクラスターイベントが作成されます。このイベントは、保留中のメンテナンスについてと、メンテナンスを実行するためのスケーリングの必要性についてを通知します。通知には、Aurora Serverless v1 が DB クラスターを強制的にスケーリングを実行できる日付が含まれています。

そのタイミングまで、Aurora Serverless v1 DB クラスターではスケーリングポイントの検索が継続され、TimeoutAction 設定に従った動作が実行されます。つまり、タイムアウト前にスケーリングポイントが見つからない場合、RollbackCapacityChange に設定されているクラスターでは、容量の変更は放棄されます。また、ForceApplyCapacityChange に設定されている場合は、変更が強制的に実行されます。適切なスケーリングポイント以外で強制される変更と同様に、この変更でもワークロードが中断されることがあります。

詳細については、「容量の変更のタイムアウトアクション」を参照してください。

Aurora Serverless v1 とフェイルオーバー

Aurora Serverless v1 DB クラスターの DB インスタンスが使用不能になるか、その クラスターがあるアベイラビリティーゾーン (AZ) で障害が発生した場合、Aurora は別の AZ に DB インスタンスを再作成します。ただし、Aurora Serverless v1 クラスターはマルチ AZ クラスターではありません。これは、単一の AZ 内の単一の DB インスタンスで構成されているためです。このフェイルオーバーメカニズムは、プロビジョニングされたインスタンスや Aurora Serverless v2 インスタンスを持つ Aurora クラスターよりも時間がかかります。Aurora Serverless v1 のフェイルオーバー時間は、対象の AWS リージョン 内での、他の AZ の需要や利用可能な容量によって変動するため、定義されていません。

Aurora では、コンピューティング容量とストレージは分離されるため、クラスターのストレージボリュームは複数の AZ に分散されます。停止が DB インスタンスまたは関連する AZ に影響する場合でも、データは引き続き利用することができます。

Aurora Serverless v1 とスナップショット

Aurora Serverless v1 クラスターでは、クラスターボリュームは常に暗号化されます。暗号化キーは選択できますが、暗号化を無効にすることはできません。Aurora Serverless v1 クラスターのスナップショットをコピーまたは共有するには、独自の AWS KMS key を使用してスナップショットを暗号化します。詳細については、「DB クラスターのスナップショットのコピー」を参照してください。暗号化と Amazon Aurora の詳細については、「Amazon Aurora リソースの暗号化」を参照してください。