# Aurora Serverless v2 DB クラスターの管理 Aurora Serverless v2 では、クラスターはプロビジョン済みクラスターと交換可能です。Aurora Serverless v2 プロパティは、DB クラスター内の 1 つまたは複数の DB インスタンスに適用されます。したがって、クラスターの作成、クラスターの変更、スナップショットの作成と復元などの手順は、他の種類の Aurora クラスターと基本的に同じです。Aurora クラスターと DB インスタンスを管理するための一般的な手順については、「[Amazon Aurora DB クラスターの管理](CHAP_Aurora.md)」を参照してください。 次のトピックでは、Aurora Serverless v2 DB インスタンスを含むクラスターの管理に関する考慮事項について説明します。 **Topics** + [Aurora Serverless v2 クラスターの容量設定](#aurora-serverless-v2-setting-acus) + [Aurora Serverless v2 の容量範囲の確認](#aurora-serverless-v2-checking-capacity) + [既存の Aurora Serverless v2 クラスターのプラットフォームバージョンの確認](#aurora-serverless-v2-checking-platform-version) + [Aurora Serverless v2 リーダーの追加](#aurora-serverless-v2-adding-reader) + [プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する](#aurora-serverless-v2-converting-from-provisioned) + [Aurora Serverless v2 ライターまたはリーダーをプロビジョン済みに変換する](#aurora-serverless-v2-converting-to-provisioned) + [Aurora Serverless v2 DB インスタンスの一時停止](#pause-when-inactive) + [Aurora Serverless v2 リーダーの昇格階層の選択](#aurora-serverless-v2-choosing-promotion-tier) + [Aurora Serverless v2 での TLS/SSL の使用](#aurora-serverless-v2.tls) + [Aurora Serverless v2 ライターとライターの表示](#aurora-serverless-v2.viewing) + [Aurora Serverless v2 のログ記録](#aurora-serverless-v2.logging) ## Aurora Serverless v2 クラスターの容量設定 Aurora Serverless v2 DB インスタンスを含むクラスターの設定パラメータやその他の設定、または DB インスタンス自体を変更するには、プロビジョン済みクラスターの場合と同様の一般的な手順に従います。詳細については、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。 Aurora Serverless v2 に固有の最も重要な設定は容量範囲です。Aurora クラスターの Aurora 容量単位 (ACU) の最小値と最大値を設定した後は、クラスター内の Aurora Serverless v2 DB インスタンスを積極的に調整する必要はありません。それは Aurora が行います。この設定は、クラスターレベルで管理されます。クラスター内の各 Aurora Serverless v2 DB インスタンスには、同一の最小 ACU と最大 ACU が適用されます。 以下の特定の値を設定できます。 + **[Minimum ACUs]** (最小 ACU) – Aurora Serverless v2 DB インスタンスは、この ACU の数まで容量を減らすことができます。 + **[Maximum ACUs]** (最大 ACU) – Aurora Serverless v2 DB インスタンスは、この ACU の数まで容量を増やすことができます。 Aurora Serverless v2 で使用可能な容量の範囲は、DB エンジンバージョンとプラットフォームバージョンの両方によって決まります。新しい DB エンジンバージョンでは、最大容量 256 ACU、最小容量 0 ACU、またはその両方を使用できます。さまざまな DB エンジンバージョンの容量範囲については、「[Aurora Serverless v2 の容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)」を参照してください。 最小容量を 0 ACU に設定することで有効になる自動一時停止と再開機能については、「[Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング](aurora-serverless-v2-auto-pause.md)」を参照してください。 Aurora Serverless v2 DB クラスターが最大 256 ACU までスケールアップできることを確認するための方法については、「[256 ACU へのスケーリングを許可する Aurora Serverless v2 DB クラスターのアップグレード](#setting-256-acus)」を参照してください。 **注記** Aurora Serverless v2 DB クラスターの容量範囲を変更すると、すぐに適用するか、次回の定期メンテナンス期間中に適用するかに関係なく、変更はすぐに反映されます。 Aurora Serverless v2 では、容量範囲を変更せずに現在の容量を直接設定することはできません。容量は、指定範囲内のワークロードに基づいて動的に調整されるためです。ただし、次の方法で間接的に容量に影響を与えることができます。 + **最小容量を調整する** – ワークロードが軽い場合は、一時的に最小容量を小さくしてベースライン容量を減らします。 + **スケーリングを一時的に停止する** – 容量を特定の値に固定するには、最小容量と最大容量を同じレベルに設定します。 + **バースト使用量に合わせてプロアクティブにスケールする** – ワークロードのバーストが予想される場合は、事前に最小容量を増やして、アクティビティの多い時間帯にベースラインをより高く維持します。 容量範囲の影響と、容量範囲をモニタリング、微調整する方法については、「[Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)」および「[Aurora Serverless v2 でのパフォーマンスとスケーリング](aurora-serverless-v2.setting-capacity.md)」を参照してください。目標は、ワークロードの急増時にはクラスターの容量を最大化し、クラスターがビジー状態でない場合は、コストを最小限に抑えるために容量を最小化することです。 モニタリングに基づき、クラスターの ACU の範囲を今よりも大きく、小さく、広く、狭くする必要があると判断したとします。AWS マネジメントコンソール、AWS CLI、Amazon RDS により、Aurora クラスターの容量を ACU の特定の範囲に設定できます。この容量範囲は、クラスター内のすべての Aurora Serverless v2 DB インスタンスに適用されます。 例えば、クラスターの容量範囲が 1 ～ 16 ACU で、2 つの Aurora Serverless v2 DB インスタンスが含まれているとします。このとき、クラスター全体で 2 ACU (アイドル時) から 32 ACU (フル使用時) の間のどこかで消費されます。容量範囲を 8 から 40.5 ACU に変更すると、クラスター全体でアイドル時には 16 ACU を消費し、フル使用時には最大 81 ACU を消費します。 Aurora は Aurora Serverless v2 DB インスタンスの特定のパラメータを、容量範囲内の最大 ACU 値によって決定される値に自動的に設定します。このようなパラメータのリストについては、「[Aurora Serverless v2 の最大接続数](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections)」を参照してください。このタイプの計算によって決定される静的パラメータの場合は、DB インスタンスを再起動すると、値が再評価されます。したがって、容量範囲を変更した後に DB インスタンスを再起動すれば、このようなパラメータの値を更新できます。このようなパラメータの変更を反映するために、DB インスタンスの再起動が必要かどうかを確認するには、DB インスタンスの `ParameterApplyStatus` 属性をチェックしてください。`pending-reboot` の値は、再起動によって一部のパラメータ値に変更が適用されることを示しています。 ### コンソール AWS マネジメントコンソール を使用することで、Aurora Serverless v2 DB インスタインスを含むクラスターの容量範囲を設定できます。 コンソールを使用する場合、最初の Aurora Serverless v2 DB インスタンスをクラスターに追加した時点で、そのクラスターに容量範囲を設定します。このような設定は、クラスター作成時、ライター DB インスタンスに **Serverless v2** DB インスタンスクラスを選択した場合に行う場合があります。または、クラスターに Aurora Serverless v2 リーダー DB インスタンスを追加する場合、**サーバーレス** DB インスタンスクラスを選択するときに行うこともあります。さらに、クラスター内の既存のプロビジョン済み DB インスタンスを**サーバーレス** DB インスタンスクラスに変換するときに行うこともあります。これらの手順の完全版については、「[Aurora Serverless v2 ライター DB インスタンスの作成](aurora-serverless-v2.create.md#aurora-serverless-v2-adding-writer)」、「[Aurora Serverless v2 リーダーの追加](#aurora-serverless-v2-adding-reader)」および「[プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する](#aurora-serverless-v2-converting-from-provisioned)」を参照してください。 クラスターレベルで設定した容量範囲は、クラスター内のすべての Aurora Serverless v2 DB インスタンスに適用されます。以下のイメージは、複数の Aurora Serverless v2 リーダー DB インスタンスによるクラスターを示しています。それぞれ、2 ～ 64 ACU の同じ容量範囲を持っています。 ![複数の Aurora Serverless v2 リーダー DB インスタンスによるクラスター](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png) **Aurora Serverless v2 クラスターの容量範囲を変更するには** 1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. リストから、Aurora Serverless v2 DB インスタンスを含むクラスターを選択します。クラスターには、少なくとも 1 つの Aurora Serverless v2 DB インスタンスが含まれていなければなりません。それ以外の場合、Aurora では **[Capacity range]** (容量範囲) セクションを表示しません。 1. **[アクション]**、**[変更]** の順に選択します。 1. **[Capacity range]** (容量範囲) セクションで、以下のものを選択します。 1. **[Minimum ACUs]** (最小 ACU) の値を入力します。コンソールには、許容される値の範囲が表示されます。最小容量は 0～256 ACU から選択できます。最大容量は 1～256 ACU から選択できます。容量値は 0.5 ACU 単位で調整できます。使用可能な容量の範囲は、DB エンジンバージョンとプラットフォームバージョンの両方によって決まります。 1. **[Maximum ACUs]** (最大 ACU) の値を入力します。この値は、**[Minimum ACUs]** (最小 ACU) 以上にする必要があります。コンソールには、許容される値の範囲が表示されます。以下の図は、その選択肢を示しています。 ![DB クラスターの容量の変更](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/sv2_capacity_settings_256_acus.png) 1. [**Continue**] を選択します。[**変更の概要**] ページが表示されます。 1. **[すぐに適用]** を選択します。 容量の変更は、すぐに適用するよう選択したか、次回の定期メンテナンス期間中に適用するよう選択したかに関係なく、すぐに反映されます。 1. [**クラスターの変更**] をクリックして、変更の概要の内容を受け入れます。[**戻る**] をクリックして設定を修正したり、[**キャンセル**] をクリックして変更を破棄することもできます。 ### AWS CLI AWS CLI を使用して Aurora Serverless v2 DB インスタンスを使用する予定のクラスターの容量を設定するには、[[modify-db-cluster]](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI コマンドを実行します。`--serverless-v2-scaling-configuration` オプションを指定します。クラスターには、既に 1 つまたは複数の Aurora Serverless v2 DB インスタンスが含まれている場合があります。または DB インスタンスを後で追加することもできます。`MinCapacity` および `MaxCapacity` フィールドに有効な値は以下のとおりです。 + `0`、`0.5`、`1`、`1.5`、`2` など、0.5 単位で最大 256 までです。最小 ACU 値 0 は、自動一時停止機能をサポートする Aurora バージョンでのみ使用できます。 使用可能な最大容量は、DB エンジンバージョンとプラットフォームバージョンの両方によって決まります。 この例では、`sample-cluster` という名前の Aurora DB クラスターの ACU 範囲を、最小 `48.5`、最大 64 に設定します。 ``` aws rds modify-db-cluster --db-cluster-identifier sample-cluster \ --serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64 ``` 容量の変更は、すぐに適用するよう選択したか、次回の定期メンテナンス期間中に適用するよう選択したかに関係なく、すぐに反映されます。 設定後は、Aurora Serverless v2 DB インスタンスをクラスターに追加でき、それぞれの新しい DB インスタンスは 48.5 から 64 ACU の間でスケーリングできます。また、新しい容量範囲は、クラスター内に既に存在していた Aurora Serverless v2 DB インスタンスに適用されます。DB インスタンスは、新しい容量範囲内に収まるように、必要に応じてスケールアップまたはスケールダウンします。 CLI を使用して容量範囲を設定するその他の例については、「[Aurora クラスターの Aurora Serverless v2 での容量範囲の選択](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2-examples-setting-capacity-range-for-cluster)」を参照してください。 Aurora Serverless を使用して AWS CLI DB クラスターのスケーリング設定を変更するには、AWS CLI の [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを実行します。`--serverless-v2-scaling-configuration` オプションを指定すると、最小容量および最大容量を設定できます。有効な容量値には次のようなものがあります。 + Aurora MySQL: `0`、`0.5`、`1`、`1.5`、`2` など、0.5 ACU 単位で最大 `256` までです。 + Aurora PostgreSQL: `0`、`0.5`、`1`、`1.5`、`2` など、0.5 ACU 単位で最大 `256` までです。 + 最小 ACU 値 0 は、自動一時停止機能をサポートする Aurora バージョンでのみ使用できます。 次の例では、`sample-cluster` という名前のクラスターの一部である `sample-instance` という名前の Aurora Serverless v2 DB インスタンスのスケーリングの設定を変更します。 Linux、macOS、Unix の場合: ``` aws rds modify-db-cluster --db-cluster-identifier sample-cluster \ --serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64 ``` Windows の場合: ``` aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^ --serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64 ``` ### RDS API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API オペレーションを使用して、Aurora DB インスタンスの容量を設定できます。`ServerlessV2ScalingConfiguration` パラメータを指定します。`MinCapacity` および `MaxCapacity` フィールドに有効な値は以下のとおりです。 + `0`、`0.5`、`1`、`1.5`、`2` など、0.5 単位で最大 256 までです。最小 ACU 値 0 は、自動一時停止機能をサポートする Aurora バージョンでのみ使用できます。 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API オペレーションを使用して Aurora Serverless v2 DB インスタンスを含むクラスターのスケーリング設定を変更できます。`ServerlessV2ScalingConfiguration` パラメータを指定すると、最小容量および最大容量を設定できます。有効な容量値には次のようなものがあります。 + Aurora MySQL: `0`、`0.5`、`1`、`1.5`、`2` など、0.5 ACU 単位で最大 `256` までです。 + Aurora PostgreSQL: `0`、`0.5`、`1`、`1.5`、`2` など、0.5 ACU 単位で最大 `256` までです。 + 最小 ACU 値 0 は、自動一時停止機能をサポートする Aurora バージョンでのみ使用できます。 使用可能な最大容量は、DB エンジンバージョンとプラットフォームバージョンの両方によって決まります。 容量の変更は、すぐに適用するよう選択したか、次回の定期メンテナンス期間中に適用するよう選択したかに関係なく、すぐに反映されます。 ### 256 ACU へのスケーリングを許可する Aurora Serverless v2 DB クラスターのアップグレード 場合によっては、Aurora Serverless v2 DB クラスターを 128 ACU を超える容量にスケールしようとすると、エラーメッセージが表示されることがあります。エラーメッセージは、新しいスケーリング範囲と互換性のないインスタンスを示します。これにより、容量範囲、DB エンジンバージョン、プラットフォームバージョン間の重要な関係が明らかになります。 128 を超える ACU をスケールできないのは、次の 2 つの理由のいずれかである可能性があります。 + 古い DB エンジンバージョン – DB エンジンバージョンを 256 ACU をサポートするものにアップグレードします。詳細については、「[Aurora Serverless v2 の容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)」を参照してください。 + 古いプラットフォームバージョン – Aurora Serverless v2 DB クラスターのプラットフォームをアップグレードします。これは、次のいずれかの方法で行うことができます。 + DB クラスターを停止し、再起動します。クラスターが再起動すると、最新のプラットフォームバージョンで稼働し、ACU のより高い最大値に対応できるようになります。 ただし、DB クラスターを停止および起動すると、通常数分のダウンタイムが発生します。詳細については、「[Amazon Aurora DB クラスターの停止と開始](aurora-cluster-stop-start.md)」を参照してください。 + ブルー/グリーンデプロイを使用します。詳細については、「[Amazon Aurora ブルー/グリーンデプロイの概要](blue-green-deployments-overview.md)」を参照してください。 1. ブルー/グリーンデプロイを作成する。詳細については、「[Amazon Aurora でのブルー/グリーンデプロイの作成](blue-green-deployments-creating.md)」を参照してください。 1. ステージング (グリーン) 環境の最大容量を 256 ACU に設定できることを確認します。 1. グリーン環境に切り替えます。詳細については、「[Amazon Aurora でのブルー/グリーンデプロイの切り替え](blue-green-deployments-switching.md)」を参照してください。 1. 元の DB クラスターを削除します。 **注記** AWS Secrets Manager でデータベース認証情報を管理している場合、ブルー/グリーンデプロイは使用できません。 Aurora Global Database はブルー/グリーンデプロイをサポートしていません。 **重要:** 新しいプラットフォームバージョンにアップグレードすると、以前のバージョンにダウングレードすることはできません。 ## Aurora Serverless v2 の容量範囲の確認 Aurora Serverless v2 クラスターの容量範囲を確認する手順では、最初に容量範囲を設定する必要があります。まだ完了していない場合は、「[Aurora Serverless v2 クラスターの容量設定](#aurora-serverless-v2-setting-acus)」の手順に従ってください。 クラスターレベルで設定した容量範囲は、クラスター内のすべての Aurora Serverless v2 DB インスタンスに適用されます。以下のイメージは、複数の Aurora Serverless v2 DB インスタンスによるクラスターを示しています。それぞれ、同じ容量範囲を持っています。 ![複数の Aurora Serverless v2 DB インスタンスのクラスターの詳細](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_identical_all_instances_in_tree_view.png) クラスター内の Aurora Serverless v2 DB インスタンスの詳細ページを表示することもできます。DB インスタンスの容量範囲は、**[Configuration]** (設定) タブに表示されます。 ![インスタンスタイプセクション、DB インスタンス設定ユーザーインターフェイスの一部](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png) また、クラスターの現在の容量範囲は、クラスターの **[Modify]** (変更) ページで確認できます。この時点で、容量範囲を変更できます。容量範囲の設定または変更が可能なすべての方法については、「[Aurora Serverless v2 クラスターの容量設定](#aurora-serverless-v2-setting-acus)」を参照してください。 ### Aurora クラスターの現在の容量範囲を確認する クラスターの `ServerlessV2ScalingConfiguration` 属性を調べることで、クラスター内の Aurora Serverless v2 DB インスタンスに設定されている容量範囲を確認できます。以下の AWS CLI の例では、最小容量が 0.5 Aurora 容量単位 (ACU)、最大容量 16 ACU のクラスターを示しています。 ``` $ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \ --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]' [ [ { "MinCapacity": 0.5, "MaxCapacity": 16.0 } ] ] ``` ## 既存の Aurora Serverless v2 クラスターのプラットフォームバージョンの確認 ### コンソール プラットフォームバージョンは、インスタンスの [インスタンスの設定] セクションに表示されます。 ![[インスタンスの設定] セクションのプラットフォームバージョン。](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-v2-platform-version.png) ### AWS CLI `describe-db-clusters` コマンドを使用して、既存のクラスターのプラットフォームバージョンを確認できます (複数可)。 **Example** ``` 1. aws rds describe-db-clusters \ 2. --db-cluster-identifier {{mydbcluster}} ``` ### デフォルトのプラットフォームバージョンの確認 #### AWS CLI `describe-serverless-v2-platform-versions` コマンドを使用して、プラットフォームバージョンの詳細を確認したり、新しいクラスターの作成時に取得するデフォルトのプラットフォームバージョンを確認したりできます。 **Example** ``` 1. $ aws rds describe-serverless-v2-platform-versions 2. { 3. "ServerlessV2PlatformVersions": [ 4. { 5. "Engine": "aurora-postgresql", 6. "ServerlessV2PlatformVersion": "3", 7. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2" 8. "ServerlessV2FeatureSupport": { 9. "MinCapacity": 0 10. "MaxCapacity": 256 11. }, 12. "Status": "available", 13. "IsDefault": True 14. }, 15. ... 16. ] 17. } 18. 19. # describing the default platform version for an engine 20. $ aws rds describe-serverless-v2-platform-versions --engine aurora-postgresql --default-only 21. { 22. "ServerlessV2PlatformVersions": [ 23. { 24. "Engine": "aurora-postgresql", 25. "ServerlessV2PlatformVersion": "3", 26. "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2" 27. "ServerlessV2FeatureSupport": { 28. "MinCapacity": 0 29. "MaxCapacity": 256 30. }, 31. "Status": "available", 32. "IsDefault": True 33. } 34. ] 35. } ``` ### 保留中のプラットフォームバージョンのアップグレードの確認 `describe-pending-maintenance-actions` コマンドを使用して、Aurora Serverless v2 DB クラスターに保留中のプラットフォームバージョンのアップグレードがあるかどうかを確認できます。 特定のクラスターで保留中のアップグレードを確認するには、`--resource-identifier` パラメータを使用して DB クラスターの Amazon リソースネーム (ARN) を指定します。 **Example** ``` 1. aws rds describe-pending-maintenance-actions \ 2. --resource-identifier arn:aws:rds:{{us-east-1}}:{{123456789012}} 3. :cluster:{{my-serverless-cluster}} ``` #### プラットフォームバージョンのアップグレードのスケジュール 保留中のプラットフォームバージョンのアップグレードを特定したら、`apply-pending-maintenance-action` コマンドを使用して、アップグレードを実行するタイミングをスケジュールできます。 プラットフォームバージョンのアップグレードをスケジュールするには、次のパラメータを指定します。 + `--resource-identifier` – Aurora Serverless v2 DB クラスターの ARN + `--apply-action` – `serverless-platform-version-update` を使用してプラットフォームバージョンのアップグレードを指定します + `--opt-in-type` – アップグレードを適用するタイミングを選択します。 + `immediate` – アップグレードをすぐに適用する + `next-maintenance` – 次のスケジュールでアップグレードを適用する ## Aurora Serverless v2 リーダーの追加 Aurora Serverless v2 リーダー DB インスタンスをクラスターに追加するには、「[DB クラスターに Aurora レプリカを追加する](aurora-replicas-adding.md)」と同じ手順に従います。新しい DB インスタンスに **Serverless v2** インスタンスクラスを選択する クラスター内のリーダー DB インスタンスが最初の Aurora Serverless v2 DB インスタンスの場合は、容量範囲も選択します。この設定は、このリーダー DB インスタンスと、クラスターに追加する他の Aurora Serverless v2 DB インスタンスに適用されます。各 Aurora Serverless v2 DB インスタンスは、最小から最大の ACU 値の間でスケーリングできます。 クラスターに他の Aurora Serverless v2 インスタンスが既に存在する場合は、**[リーダーの追加]** ダイアログにクラスターの現在の容量範囲が表示されます。その場合、容量を変更することはできません。次の図は、現在のクラスター容量のレポートを示しています。 ![Aurora Serverless v2 用インスタンス設定ユーザーインターフェイス](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png) クラスターに既にいずれかの Aurora Serverless v2 DB インスタンスを追加している場合、別の Aurora Serverless v2 リーダー DB インスタンスには、現在の容量範囲が表示されます。以下のイメージは、これらの読み取り専用のコントロールを示しています。 ![[リーダーの追加] インターフェイスに表示される Aurora Serverless v2 の容量設定](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png) クラスターの容量範囲を変更する場合は、「[Aurora Serverless v2 クラスターの容量設定](#aurora-serverless-v2-setting-acus)」の手順に従ってください。 複数のリーダー DB インスタンスを含むクラスターの場合は、各 Aurora Serverless v2 リーダー DB インスタンスのフェイルオーバーの優先度によって、その DB インスタンスのスケールアップとスケールダウンに重要な役割を果たします。最初にクラスターを作成するときに、優先度を指定することはできません。2 番目以降のリーダー DB インスタンスをクラスターに追加する場合は、この特性に注意してください。詳細については、「[Aurora Serverless v2 リーダーの昇格階層の選択](#aurora-serverless-v2-choosing-promotion-tier)」を参照してください。 クラスターの現在の容量範囲を確認できるその他の方法については、「[Aurora Serverless v2 の容量範囲の確認](#aurora-serverless-v2-checking-capacity)」を参照してください。 ## プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する プロビジョン済み DB インスタンスを変換することで Aurora Serverless v2 を使用できます。これを行うには、「[DB クラスター内の DB インスタンスの変更](Aurora.Modifying.md#Aurora.Modifying.Instance)」の手順に従います。このクラスターは、「[Aurora Serverless v2 の要件と制限](aurora-serverless-v2.requirements.md)」の要件を満たす必要があります。例えば Aurora Serverless v2 DB インスタンスでは、クラスターが特定の最小エンジンバージョンを実行している必要があります。 実行中のプロビジョン済みクラスターを変換して、Aurora Serverless v2 を利用するとします。その場合、切り替え処理の最初のステップとして、DB インスタンスを Aurora Serverless v2 に変換することで、ダウンタウンを最小限に抑えることができます。完全な手順については、「[プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する](#aurora-serverless-v2-converting-from-provisioned)」を参照してください。 クラスター内で変換する DB インスタンスが最初の Aurora Serverless v2 DB インスタンスである場合、**変更**オペレーションの一部として、クラスターの容量範囲を選択します。この容量範囲は、クラスターに追加する各 Aurora Serverless v2 DB インスタンスに適用されます。以下のイメージは、最小および最大の Aurora 容量単位 (ACU) を指定するページを示しています。 ![インスタンス設定ユーザーインターフェイス](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_settable_for_add_reader_modify_instance.png) 容量範囲の重要性についての詳細は、「[Aurora Serverless v2 の容量](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity)」を参照してください。 クラスターに既に 1 つまたは複数の Aurora Serverless v2 DB インスタンスが含まれている場合、**変更**オペレーションの際に既存の容量範囲が表示されます。以下のイメージは、その情報パネルの例を示しています。 ![容量範囲情報パネル](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_fixed_for_add_reader_modify_instance.png) Aurora Serverless v2 DB インスタンスを追加した後でクラスターの容量範囲を変更する場合は、「[Aurora Serverless v2 クラスターの容量設定](#aurora-serverless-v2-setting-acus)」の手順に従ってください。 ## Aurora Serverless v2 ライターまたはリーダーをプロビジョン済みに変換する Aurora Serverless v2 DB インスタンスをプロビジョン済み DB インスタンスに変換できます。これを行うには、「[DB クラスター内の DB インスタンスの変更](Aurora.Modifying.md#Aurora.Modifying.Instance)」の手順に従います。**[Serverless]** (サーバーレス) 以外の DB インスタンスクラスを選択します。 Aurora Serverless v2 DB インスタンスが Aurora Serverless v2 DB インスタンスの最大 ACU (Aurora 容量単位) より大きな容量が必要な場合、プロビジョン済みに変換する場合があります。例えば、最大の db.r5 および db.r6g DB インスタンスクラスは、Aurora Serverless v2 DB インスタンスがスケーラブルな容量よりも大きなメモリ容量を持っています。 **ヒント** db.r3 や db.t2 などの古い DB インスタンスクラスには、Aurora Serverless v2 で使用する Aurora バージョンでは使用できないものもあります。Aurora Serverless v2 DB インスタンスをプロビジョン済みに変換する際に使用可能な DB インスタンスは、「[DB インスタンスクラスでサポートされている DB エンジン](Concepts.DBInstanceClass.SupportAurora.md)」を参照してください。 クラスターのライター DB インスタンスを Aurora Serverless v2 から プロビジョン済みに変換するには、逆順で「[プロビジョン済みライターまたはリーダーを Aurora Serverless v2 に変換する](#aurora-serverless-v2-converting-from-provisioned)」の手順に従います。クラスター内のリーダー DB インスタンスの 1 つを Aurora Serverless v2 からプロビジョン済みに切り替えます。次に、フェイルオーバーを実行して、プロビジョン済み DB インスタンスをライターにします。 すべての Aurora Serverless v2 DB インスタンスをクラスターから削除した場合でも、以前にクラスターに指定した容量範囲はそのまま維持されます。容量範囲を変更する場合は、「[Aurora Serverless v2 クラスターの容量設定](#aurora-serverless-v2-setting-acus)」の説明に従って、クラスターを変更できます。 ## Aurora Serverless v2 DB インスタンスの一時停止 Aurora Serverless v2 DB インスタンスを自動的に一時停止および再開するように Aurora クラスターを設定できます。詳細については、「[Aurora Serverless v2 の自動一時停止と再開によるゼロ ACU へのスケーリング](aurora-serverless-v2-auto-pause.md)」を参照してください。 ## Aurora Serverless v2 リーダーの昇格階層の選択 複数の Aurora Serverless v2 DB インスタンスを含むクラスター、またはプロビジョン済み Aurora Serverless v2 DB インスタンスが混在するクラスターでは、各 Aurora Serverless v2 DB インスタンスの昇格階層の設定に注意してください。この設定は、プロビジョン済み Aurora Serverless v2 DB インスタンスと比較して、DB インスタンスに対してより多くの動作をコントロールします。 AWS マネジメントコンソールの **[データベースの作成]**、**[インスタンスの変更]**、**[リーダーの追加]** ページの **[追加設定]** で、**[フェイルオーバー優先順位]** の選択肢を使用して、この設定を指定します。既存の DB インスタンスのこのプロパティについては、**[Databases]** (データベース) ページのオプションの **[Priority tier]** (優先階層) 列に表示されます。このプロパティは、DB クラスターまたは DB インスタンスの詳細ページにも表示されます。 プロビジョン済み DB インスタンスの場合、階層 0 ～ 15 の選択によって、フェイルオーバーオペレーション中に Aurora がどのリーダー DB インスタンスをライターに昇格させるかを選択する順序のみを決定します。Aurora Serverless v2 リーダー DB インスタンスの場合、ライター DB インスタンスの容量に合わせてスケールアップするか、インスタンスそのもののワークロードに応じて独自にスケールアップするかどうかは、階層番号で決まります。階層 0 または 1 の Aurora Serverless v2 リーダー DB インスタンスは、最低でもライター DB インスタンスと同じ容量に維持されます。これにより、フェイルオーバー発生時にライター DB インスタンスから引き継ぐ準備が整います。ライター DB インスタンスがプロビジョン済み DB インスタンスの場合、Aurora では同等の Aurora Serverless v2 容量を推定します。この推定値を Aurora Serverless v2リーダー DB インスタンスの最小容量として使用します。 Aurora Serverless v2階層 2 ～ 15 の リーダー DB インスタンスは、最小容量に対する同じ制約はありません。アイドル状態の場合、クラスターの容量範囲で指定された Aurora 容量単位 (ACU) の最小値までスケールダウンできます。 以下の Linux AWS CLI の例は、クラスター内のすべての DB インスタンスの昇格階層を調べる方法を示しています。最後のフィールドには、ライター DB インスタンスの場合は `True`、すべてのリーダー DB インスタンスの場合は `False` の値が含まれています。 ``` $ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \ --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \ --output text 1 instance-192 True 1 tier-01-4840 False 10 tier-10-7425 False 15 tier-15-6694 False ``` 以下の Linux AWS CLI の例は、クラスター内の特定の DB インスタンスの昇格階層を変更する方法を示しています。このコマンドでは、まず新しい昇格階層で DB インスタンスを変更します。その後、DB インスタンスが再び利用可能になるのを待って、DB インスタンスの新しい昇格階層を確認します。 ``` $ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0 $ aws rds wait db-instance-available --db-instance-identifier instance-192 $ aws rds describe-db-instances --db-instance-identifier instance-192 \ --query '*[].[PromotionTier]' --output text 0 ``` さまざまなユースケースで昇格階層を指定する方法の詳細については、「[Aurora Serverless v2 でのスケーリング](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.scaling)」を参照してください。 ## Aurora Serverless v2 での TLS/SSL の使用 Aurora Serverless v2 では、クライアントと Aurora Serverless v2 DB インスタンス間の通信に対し、Transport Layer Security/Secure Sockets Layer (TLS/SSL) プロトコルを使用して暗号化することができます。サポートされる TLS/SSL バージョンは、1.0、1.1、および 1.2 です。Aurora での TLS/SSL の使用に関する一般的な情報については、「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。 MySQL クライアントを使用しての Aurora MySQL データベースへの接続の詳細については、「[MySQL データベースエンジンを実行している DB インスタンスへの接続](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html)」を参照してください。 Aurora Serverless v2 では、MySQL クライアント (`mysql`) および PostgreSQL クライアント (`psql`) で使用できるすべての TLS/SSL モードがサポートされます。これらには、以下の表に示すものも含まれます。 | TLS/SSL モードの説明 | mysql | psql | | --- | --- | --- | | TLS/SSL を使用せずに接続します。 | DISABLED | 無効化 | | 初期に TLS/SSL を使用して接続を試みますが、必要に応じて非 SSL にフォールバックします。 | PREFERRED | 優先 (デフォルト) | | 強制的に TLS/SSL を使用します。 | REQUIRED | require | | TLS/SSL を義務化し、認証機関 (CA) を検証します。 | VERIFY\_CA | verify-ca | | TLS/SSL を強制的に使用し CA を確認し、また CA ホスト名を確認します。 | VERIFY\_IDENTITY | verify-full | Aurora Serverless v2 は、ワイルドカード証明書を使用します。TLS/SSL を使用するときに "verify CA" または "verify CA and CA hostname" オプションを指定した場合は、まず [Amazon ルート CA 1 信頼ストア](https://www.amazontrust.com/repository/AmazonRootCA1.pem)を Amazon Trust Services からダウンロードしてください。ダウンロードした、この PEM 形式のファイルは、クライアントコマンドにより識別できます。これを PostgreSQL クライアントを使用して行うには、以下のように実行します。 Linux、macOS、Unix の場合: ``` psql 'host={{endpoint}} user={{user}} sslmode=require sslrootcert=amazon-root-CA-1.pem dbname={{db-name}}' ``` Postgres クライアントを使用した Aurora PostgreSQL データベースの動作の詳細については、「[PostgreSQL データベースエンジンを実行する DB インスタンスへの接続](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html)」を参照してください。 Aurora DB クラスターへの接続全般の詳細については、「[Amazon Aurora DB クラスターへの接続](Aurora.Connecting.md)」を参照してください。 ### Aurora Serverless v2 DB クラスターへの接続用にサポートされている暗号スイート 設定可能な暗号スイートを使用すると、データベース接続のセキュリティをより詳細に制御できます。データベースへのクライアント TLS/SSL 接続を保護するために許可する暗号スイートのリストを指定できます。設定可能な暗号スイートを使用すると、データベースサーバーが受け入れる接続暗号化を制御できます。これにより、安全でない暗号や使用されなくなった暗号の使用を防ぐことができます。 Aurora Serverless v2Aurora MySQL に基づく DB クラスターは、Aurora MySQL プロビジョン済み DB クラスターと同じ暗号スイートをサポートします。これらの暗号スイートについては、「[Aurora PostgreSQL DB クラスターへの接続用暗号スイートを設定する](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites)」を参照してください。 Aurora Serverless v2Aurora PostgreSQL に基づく DB クラスターは、Aurora PostgreSQL プロビジョンド DB クラスターと同じ暗号スイートをサポートします。これらの暗号スイートについては、「[Aurora PostgreSQL DB クラスターへの接続用暗号スイートを設定する](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites)」を参照してください。 ## Aurora Serverless v2 ライターとライターの表示 プロビジョン済み DB インスタンスと同じ方法で、Aurora Serverless v2 DB インスタンスの詳細を表示できます。これを行うには、「[Amazon Aurora DB クラスターの表示](accessing-monitoring.md#Aurora.Viewing)」の一般的な手順に従います。クラスターには、すべてまたは一部の Aurora Serverless v2 DB インスタンス、プロビジョン済み DB インスタンスが含まれる場合があります。 1 つまたは複数の Aurora Serverless v2 DB インスタンスを作成した場合、どの DB インスタンスが**サーバーレス**タイプで、どの DB インスタンスが**インスタンス**タイプであるかを確認できます。また、Aurora Serverless v2 DB インスタンスが使用可能な最小および最大の Aurora 容量単位 (ACU) を表示できます。各 ACU は、処理 (CPU) 容量とメモリ (RAM) 容量の組み合わせです。この容量範囲は、クラスター内の各 Aurora Serverless v2 DB インスタンスに適用されます。クラスターまたはクラスター内の任意の Aurora Serverless v2 DB インスタンスの容量範囲を確認する手順については、「[Aurora Serverless v2 の容量範囲の確認](#aurora-serverless-v2-checking-capacity)」を参照してください。 AWS マネジメントコンソール で、**[Databases]** (データベース) ページの **[Size]** (サイズ) 列に Aurora Serverless v2 DB インスタンスが表示されます。プロビジョン済み DB インスタンスには、r6g.xlarge などの DB インスタンスクラスの名前が表示されます。Aurora Serverless DB インスタンスでは、DB インスタンスクラスの場合は **[Serverless]** (サーバーレス)が、DB インスタンスの最小容量と最大容量と合わせて表示されます。例えば、**Serverless v2 (4 ～ 64 ACU)** または **Serverless v2 (1 ～ 40 ACU)** のように表示されます。 コンソールの各 Aurora Serverless v2 DB インスタンスの **[Configuration]** (設定) タブにも同じ情報が表示されます。例えば、以下のような **[Instance type]** (インスタンスタイプ) セクションが表示される場合があります。ここで、**[Instance type]** (インスタンスタイプ) の値を **Serverless v2** とすると、**最小容量**の値は **2 ACU (4 GiB)** で、**最大容量**の値は **64 ACU (128 GiB)** です。 ![インスタンスタイプセクション、DB インスタンス設定ユーザーインターフェイスの一部](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/serverless_v2_screencaps/serverless_v2_capacity_settings_shown_for_serverless_instance.png) 各 Aurora Serverless v2 DB インスタンスの容量は時系列でモニタリングできます。これにより、各 DB インスタンスが消費する ACU の最小、最大、平均を確認できます。また、DB インスタンスの最小容量または最大容量にどれだけ近づいたかを確認できます。これを AWS マネジメントコンソール で見るには、DB インスタンスの **[Monitoring]** (モニタリング) タブで、Amazon CloudWatch メトリクスのグラフを確認します。注目すべきメトリクスと、それを解釈する方法の詳細については、「[Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)」を参照してください。 ## Aurora Serverless v2 のログ記録 データベースのログをオンにするには、カスタムパラメータグループのコンフィギュレーションパラメータを使用して、有効にするログを指定します。 Aurora MySQL では、以下のログを有効にすることができます。 | Aurora MySQL | 説明 | | --- | --- | | `general_log` | 一般ログを作成します。オンにするには、1 に設定します。デフォルトはオフ (0) です。 | | `log_queries_not_using_indexes` | インデックスを使用しないスロークエリログにクエリを記録します。デフォルトはオフ (0) です。このログを有効にするには、1 に設定します。 | | `long_query_time` | 高速実行クエリがスロークエリログに記録されないようにします。0 から 31536000 までの浮動小数点数に設定できます。デフォルトは 0 (アクティブではない) です。 | | `server_audit_events` | ログにキャプチャするイベントのリスト。サポートされている値は `CONNECT`、`QUERY`、`QUERY_DCL`、`QUERY_DDL`、`QUERY_DML`、`TABLE` です。 | | `server_audit_logging` | この値を 1 に設定すると、サーバー監査ログ記録がオンになります。これをオンにしている場合は、CloudWatch に送信する監査イベントを、`server_audit_events` パラメータにリストアップすることで指定できます。 | | `slow_query_log` | スロークエリログを作成します。スロークエリログをオンにするには、1 に設定します。デフォルトはオフ (0) です。 | 詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。 Aurora PostgreSQL では、Aurora Serverless v2 DB インスタンスで以下のログを有効にできます。 | Aurora PostgreSQL | 説明 | | --- | --- | | `log_connections` | 成功した各接続をログに記録します。 | | `log_disconnections` | セッションの終了をログに記録します (セッションの実行時間も含まれます)。 | | `log_lock_waits` | デフォルトは 0 (オフ) です。ロック待機をログに記録するには、1 に設定します。 | | `log_min_duration_statement` | ステートメントがログに記録されるまでに実行される最小時間 (ミリ秒単位)。 | | `log_min_messages` | ログに記録するメッセージレベルを設定します。サポートされている値は debug5、debug4、debug3、debug2、debug1、info、notice、warning、error、log、fatal、panic です。パフォーマンスデータを postgres ログに記録するには、値を debug1 に設定します。 | | `log_temp_files` | 指定されたキロバイト (KB) を超えるテンポラリファイルの使用を記録します。 | | `log_statement` | ログに記録される特定の SQL ステートメントを制御します。サポートされている値は `none`、`ddl`、`mod`、`all` です。デフォルトは `none` です。 | **Topics** + [Amazon CloudWatch でのログ記録](#aurora-serverless-v2.how-it-works.logging) + [Amazon CloudWatch の Aurora Serverless v2 ログの表示](#aurora-serverless-v2.logging.monitoring) + [Amazon CloudWatch でキャパシティーを監視する](#aurora-serverless-v2.how-it-works.logging.monitoring) + [Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング](#autopause-logging-instance-log) ### Amazon CloudWatch でのログ記録 [Aurora Serverless v2 のログ記録](#aurora-serverless-v2.logging) の手順で、オンにするデータベースログを選択した後、Amazon CloudWatch にアップロード (公開) するログを選択できます。 Amazon CloudWatch を使用すると、ログデータの分析や、アラームの作成、メトリクスの表示を行うことができます。デフォルトでは、Aurora Serverless v2 のエラーログが有効になっており、CloudWatch に自動的にアップロードされます。また、その他の Aurora Serverless v2 DB インスタンスのログを CloudWatch アップロードできます。 次に、CloudWatch にアップロードするログを AWS マネジメントコンソール の**[Log exports]** (ログのエクスポート) 設定または AWS CLI の `--enable-cloudwatch-logs-exports` オプションで選択します。 CloudWatch にアップロードする Aurora Serverless v2 ログを選択できます。詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。 Aurora DB クラスターのタイプと同様に、デフォルトの DB クラスターパラメータグループを変更することはできません。代わりに、DB クラスターとエンジンタイプのデフォルトパラメータをベースに、独自の DB クラスターパラメータグループが作成できます。Aurora Serverless v2 DB クラスターを作成する前に、カスタムの DB クラスターパラメータグループを作成しておくことをお勧めします。これにより、コンソールでデータベースを作成するときに、パラメータグループを選択できるようになります。 **注記** Aurora Serverless v2では、DB クラスターと DB パラメータグループの両方を作成できます。 ### Amazon CloudWatch の Aurora Serverless v2 ログの表示 「[Amazon CloudWatch でのログ記録](#aurora-serverless-v2.how-it-works.logging)」の手順を使用してオンにするデータベースログを選択すると、ログの内容を表示できます。 CloudWatch、Aurora MySQL、Aurora PostgreSQL ログ使用の詳細については、「[Amazon CloudWatch でログイベントをモニタリングする](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor)」および「[Amazon CloudWatch Logs への Aurora PostgreSQL ログの発行](AuroraPostgreSQL.CloudWatch.md)」を参照してください。 **Aurora Serverless v2 DB クラスターのログを表示するには** 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. AWS リージョン を選択します。 1. [**ロググループ**] を選択します。 1. リストから Aurora Serverless v2 DB クラスターのログを選択します。ログの命名パターンは、次に従います。 ``` /aws/rds/cluster/{{cluster-name}}/{{log_type}} ``` **注記** Aurora MySQL 互換 Aurora Serverless v2 DB クラスターの場合、エラーがない場合でも、エラーログにバッファプールのスケーリングイベントが含まれます。 ### Amazon CloudWatch でキャパシティーを監視する Aurora Serverless v2では、CloudWatch を使用して、クラスター内のすべての Aurora Serverless v2 DB インスタンスの容量と使用率をモニタリングできます。インスタンスレベルのメトリクスを表示して、Aurora Serverless v2 DB インスタンスがスケールアップやスケールダウンした場合の容量を確認できます。また、容量に関連したメトリクスを他のメトリクスを比較することで、ワークロードの変化がリソース消費にどのように影響しているかを見ることもできます。例えば、`ServerlessDatabaseCapacity` と `DatabaseUsedMemory`、`DatabaseConnections`、`DMLThroughput` を比較すると、DB クラスターのオペレーション中の応答を評価できます。Aurora Serverless v2 に適用される容量に関連したメトリクスの詳細については、「[Aurora Serverless v2 の重要な Amazon CloudWatch メトリクス](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.viewing.monitoring)」を参照してください。 **Aurora Serverless v2 DB クラスターのキャパシティーを監視するには** 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. [**メトリクス**] をクリックします。使用可能なすべてのメトリクスが、サービス名ごとにグループ化されたカードとして、コンソールに表示されます。 1. [**RDS**] を選択します。 1. (オプション) **[Search]** (検索) ボックスを使用して、Aurora Serverless v2 に特に重要なメトリクスである `ServerlessDatabaseCapacity`、`ACUUtilization`、`CPUUtilization`、`FreeableMemory` を検索します。 CloudWatch ダッシュボードをセットアップし、容量に関連したメトリクスを使用して Aurora Serverless v2 DB クラスターの容量をモニタリングすることをお勧めします。詳細については、「[CloudWatch を使用したダッシュボードのビルド](https://docs.aws.amazon.com/autoscaling/application/userguide/monitoring-cloudwatch.html)」を参照してください。 Amazon Aurora での Amazon CloudWatch の使用の詳細については、「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md)」を参照してください。 ### Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング Aurora は、自動一時停止が有効になっている Aurora Serverless v2 DB インスタンスに対して別のログファイルを作成します。Aurora は、インスタンスが一時停止されていない 10 分間隔ごとにログに書き込みます。Aurora は、これらのログを最大 7 つまで保持し、毎日ローテーションします。現在のログファイルには `instance.log` という名前が付けられ、古いログには `instance.{{YYYY-MM-DD}}.{{N}}.log` のパターンで名前が付けられます。 このログは、自動一時停止が有効になっている Aurora Serverless v2 DB インスタンスではデフォルトで有効になっています。このログの内容は、AWS マネジメントコンソールで、あるいは AWS CLI または RDSP API を使用して表示できます。現在、このログを CloudWatch にアップロードすることはできません。 [DB インスタンスイベント](USER_Events.Messages.md#USER_Events.Messages.instance) にリストされているイベントは、次のような一時停止と再開のアクティビティの概要を示します。 + インスタンスが一時停止を開始したとき、および一時停止を終了したとき。 + インスタンスが再開を開始したとき、および再開を終了したとき。 + インスタンスが一時停止しようとしたが、一部の条件により一時停止できなかった場合。 `instance.log` は、Aurora Serverless v2 インスタンスが一時停止できる/できない理由について、より詳細な情報を提供します。 ログには、さまざまな理由でインスタンスが再開されたことが示される場合があります。 + **ユーザーアクティビティ**: データベース接続リクエスト。これには、インタラクティブなクライアントセッションからのリクエスト、RDS Data API コール、またはインスタンスからのログのダウンロードリクエストが含まれる場合があります。 + **バックグラウンドアクティビティ**: Aurora がインスタンスを再開するあらゆる理由を含む広範なカテゴリ。例えば、リーダーインスタンスへの接続リクエストによってライターインスタンスが再開されると、リーダーのログはユーザーアクティビティを示し、ライターのログはその再開リクエストをバックグラウンドアクティビティとして分類します。Aurora がユーザー接続リクエスト以外の理由でインスタンスを再開する理由については、「[自動一時停止した Aurora Serverless v2 インスタンスの再開](aurora-serverless-v2-auto-pause.md#auto-pause-waking)」を参照してください。 Aurora は、自動一時停止間隔が経過したときにインスタンスの一時停止を妨げる条件を認識していない場合、定期的にログに情報メッセージを書き込みます。1 つの DB インスタンスだけを持つクラスターの場合、ログには次のメッセージが含まれます。 ``` [INFO] No auto-pause blockers registered since {{time}} ``` 複数の DB インスタンスを持つクラスターの場合、メッセージは若干異なります。これは、いずれかのリーダーインスタンスでアクティビティがあるため、ライターが一時停止できない可能性があるためです。ライターで自動一時停止間隔が経過する前にリーダーのアクティビティが終了すると、ライターは予定時間に一時停止できます。 ``` [INFO] No auto-pause blockers registered since {{time}}. Database might be required to maintain compute capacity for high availability. ``` 一時停止オペレーションが開始し、インスタンスの一時停止が終了する前に新しいデータベース接続リクエストを受信した場合、ログには次のメッセージが含まれます。 ``` [INFO] Unable to pause database due to a new database activity ``` Aurora がインスタンスの一時停止を確実に妨げる条件を認識すると、ログにはそうした条件すべてを一覧表示するこのメッセージが含まれます。 ``` [INFO] Auto-pause blockers registered since {{time}}: {{list_of_conditions}} ``` そのため、Aurora は、自動一時停止機能と組み合わせて、レプリケーション、ゼロ ETL 統合、Aurora Global Database などを有効にすることを妨げません。このような機能を使用すると自動一時停止を有効にできない可能性がある場合は、ログで通知されます。 以下は、Aurora Serverless v2 インスタンスが自動一時停止タイムアウト間隔を経過しても一時停止できない理由を示しています。 + **自動一時停止タイムアウト前のデータベースアクティビティ**: DB インスタンスが、タイムアウト間隔が経過する前に接続リクエストを受信しました。 + **グローバルデータベースのメンバー**: DB クラスターが Aurora Global Database の一部である場合、クラスター内の Aurora Serverless v2 インスタンスは一時停止しません。クラスターは、スタンドアロンクラスターから Global Database クラスターに変更できます。そのため、以前に自動一時停止したインスタンスは一時停止を停止し、ログでこの理由を報告します。クラスターが Global Database のメンバーになると、明示的にデタッチするまで、スタンドアロンクラスターには戻りません。すべてのセカンダリクラスターをデタッチした場合でも、プライマリクラスターは Global Database の一部と見なされます。 + **レプリケーション機能の設定**: ライター DB インスタンスで、エンジン固有のレプリケーション (MySQL のバイナリログレプリケーションまたは PostgreSQL の論理レプリケーションのいずれか) が有効になっています。この条件は、ゼロ ETL 統合やデータベースアクティビティストリーム (DAS) など、レプリケーションの有効化が必要な別の Aurora 機能を使用していることが原因である可能性もあります。 + **継続的バックアップラグ**: Aurora ストレージシステムが現時点までストレージの変更の適用を完了していない場合、ライターインスタンスは変更の適用が完了するまで一時停止しません。この条件はライターインスタンスにのみ影響し、比較的短いことが予想されます。 + **サービスまたはユーザーのメンテナンスアクション**: メンテナンスオペレーションが開始されると、DB インスタンスはそのオペレーションが完了するまで再び一時停止しません。この条件には、アップグレード、クローン作成、構成設定の変更、アップグレード、ログファイルのダウンロードなど、ユーザーまたは Aurora が開始する可能性のあるさまざまなオペレーションが含まれます。このイベントは、インスタンスの削除をリクエストする場合も発生し、Aurora は削除メカニズムの一部としてインスタンスを一時的に再開します。 + **一時的な通信の問題**: Aurora が現在スケーリング設定の最小容量設定がゼロ ACU であるかどうかを判断できない場合、インスタンスは一時停止されません。これが発生することは非常にまれであると予想されます。