# Aurora レプリカでの Amazon Aurora Auto Scaling 接続およびワークロード要件を満たすために、Aurora Auto Scaling は、Aurora DB クラスター用にプロビジョニングされる Aurora レプリカ (リーダー DB インスタンス) の数を動的に調整します。Aurora Auto Scaling は、Aurora MySQL と Aurora PostgreSQL の両方で使用できます。Aurora Auto Scaling により、お使いの Aurora DB クラスターは急激な接続やワークロードの増加を処理できます。接続やワークロードが減ると、Aurora Auto Scaling は未使用のプロビジョニングされた DB インスタンスに対する料金が発生しないように、不要な Aurora レプリカを削除します。 スケーリングポリシーを定義して Aurora DB クラスターに適用します。*スケーリングポリシー*は、Aurora Auto Scaling で管理できる Aurora レプリカの最小数と最大数を定義します。そのポリシーに基づいて、Aurora Auto Scaling は Amazon CloudWatch メトリクスとターゲット値を使用して決定される実際のワークロードに応じて、Aurora レプリカの数を上下に調整します。 **注記** Aurora Auto Scaling は、ライター DB インスタンスのワークロードには適用されません。Aurora Auto Scaling は、リーダーインスタンス上のワークロードにのみ役立ちます。 AWS マネジメントコンソール を使用し、事前定義されたメトリクスに基づいてスケーリングポリシーを適用できます。代わりに、AWS CLI または Aurora Auto Scaling API を使用し、事前定義済みまたはカスタムのメトリクスに基づいたスケーリングポリシーを適用することも可能です。 **Topics** + [開始する前に](#Aurora.Integrating.AutoScaling.BYB) + [Aurora Auto Scaling ポリシー](#Aurora.Integrating.AutoScaling.Concepts) + [DB インスタンス ID とタグ付け](#Aurora.Integrating.AutoScaling.Concepts.Tagging) + [Aurora Auto Scaling と Performance Insights](#aurora-auto-scaling-pi) ## 開始する前に Aurora DB クラスターで Aurora Auto Scaling を使用する前に、まず、プライマリ (書き込み) DB インスタンスで Aurora DB クラスターを作成する必要があります。Aurora DB クラスター作成の詳細については、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」を参照してください。 Aurora Auto Scaling は、DB クラスターが利用可能な状態にある場合のみ、DB クラスターをスケーリングします。 Aurora Auto Scaling が新しい Aurora レプリカを追加すると、その新しい Aurora レプリカはプライマリインスタンスが使用するのと同じ DB インスタンスクラスになります。DB インスタンスクラスの詳細については、「[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。また、新しい Aurora レプリカの昇格階層は、最も低い優先順位 (デフォルトでは 15) に設定されています。つまり、フェイルオーバー時には、手動で作成されたものなど、優先順位の高いレプリカが最初に昇格されます。詳細については、「[Aurora DB クラスターの耐障害性](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance)」を参照してください。 Aurora Auto Scaling では、自身が作成した Aurora レプリカのみ削除されます。 Aurora Auto Scaling から益を得るには、お使いのアプリケーションが新しい Aurora レプリカへの接続をサポートしている必要があります。これを行うには、Aurora 読み込みエンドポイントを使用することをお勧めします。AWS JDBC ドライバーなどのドライバーを使用できます。詳細については、「[Amazon Aurora DB クラスターへの接続](Aurora.Connecting.md)」を参照してください。 **注記** Aurora グローバルデータベースは、現在、セカンダリ DB クラスターの Aurora Auto Scaling をサポートしていません。 ## Aurora Auto Scaling ポリシー Aurora Auto Scaling はスケーリングポリシーを使用して、Aurora DB クラスターの Aurora レプリカ数を調整します。Aurora Auto Scaling には以下のコンポーネントがあります。 + サービスにリンクされたロール + ターゲットメトリクス + 最小容量と最大容量 + クールダウン期間 **Topics** + [サービスにリンクされたロール](#Aurora.Integrating.AutoScaling.Concepts.SLR) + [ターゲットメトリクス](#Aurora.Integrating.AutoScaling.Concepts.TargetMetric) + [最小容量と最大容量](#Aurora.Integrating.AutoScaling.Concepts.Capacity) + [クールダウン期間](#Aurora.Integrating.AutoScaling.Concepts.Cooldown) + [スケールインアクティビティの有効化または無効化](#Aurora.Integrating.AutoScaling.Concepts.ScaleIn) + [自動スケーリングポリシーの追加、編集、または削除](#Aurora.Integrating.AutoScaling.Concepts.AddEditDelete) ### サービスにリンクされたロール Aurora Auto Scaling は、サービスにリンクされたロール `AWSServiceRoleForApplicationAutoScaling_RDSCluster` を使用します。詳細については、*Application Auto Scaling ユーザーガイド*の「[Application Auto Scaling のサービスにリンクされたロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。 ### ターゲットメトリクス このタイプのポリシーでは、ターゲット追跡スケーリングポリシー設定で、事前定義されたメトリクスまたはカスタムメトリクスとそのメトリクスのターゲット値を指定します。Aurora Auto Scaling は、スケーリングポリシーをトリガーする CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整値を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するため、必要に応じて Aurora レプリカを追加または削除します。メトリクスをターゲット値に近い値に維持することに加えて、ターゲット追跡スケーリングポリシーは、変化するワークロードによるメトリクスの変動に適応します。そのようなポリシーは、DB クラスターに使用可能な Aurora レプリカ数の急速な変動の最小化もします。 例として、事前定義された平均 CPU 使用率メトリクスを使用するスケーリングポリシーを挙げましょう。そのようなポリシーは、40 パーセントなどの指定された使用率に、またはそれに近い割合に CPU 使用率を維持できます。 **注記** 各 Aurora DB クラスターについては、各ターゲットメトリクスに対して 1 つの Auto Scaling ポリシーのみを作成できます。 Aurora Auto Scaling を設定すると、ターゲットメトリクス値はクラスター内のすべてのリーダーインスタンスの平均として計算されます。この計算は次のように行います。 + Auto Scaling で管理するか、手動で追加するかにかかわらず、Aurora クラスター内のすべてのリーダーインスタンスを含めます。 + カスタムエンドポイントに関連付けられたインスタンスを含めます。カスタムエンドポイントは、ターゲットメトリクスの計算に影響しません。 + クラスターのライターインスタンスは含めません。 メトリクスは、次のディメンションを使用して CloudWatch から取得します。 + `DBClusterIdentifier` + `Role=READER` 例えば、次の設定の Aurora MySQL クラスターを考えてみます。 + **手動インスタンス (Auto Scaling では制御されない)**: + CPU 使用率が 50% のライター + CPU 使用率が 90% のリーダー 1 (カスタムエンドポイント: `custom-reader-1`) + CPU 使用率が 90% のリーダー 2 (カスタムエンドポイント: `custom-reader-2`) + **Auto Scaling インスタンス**: + CPU 使用率が 10% のリーダー 3 (Auto Scaling を使用して追加) このシナリオでは、Auto Scaling ポリシーのターゲットメトリクスは次のように計算されます。 ``` Target metric = (CPU utilization of reader 1 + reader 2 + reader 3) / total number of readers Target metric = (90 + 90 + 10) / 3 = 63.33% ``` Auto Scaling ポリシーは、この値を使用して、定義されたしきい値に基づいてスケールインするかスケールアウトするかを評価します。 以下の点を考慮してください。 + カスタムエンドポイントはトラフィックを特定のリーダーにルーティングする方法を決定しますが、メトリクスの計算からリーダーを除外することはありません。 + 手動インスタンスは常にターゲットメトリクスの計算に含まれます。 + 予期しないスケーリング動作を回避するには、Auto Scaling 設定でクラスター内のすべてのリーダーインスタンスが考慮されていることを確認してください。 + クラスターにリーダーがない場合、メトリクスは計算されず、Auto Scaling ポリシーアラームは非アクティブのままになります。Auto Scaling ポリシーが効果的に機能するには、常に少なくとも 1 つのリーダーが存在している必要があります。 ### 最小容量と最大容量 アプリケーションの Auto Scaling が管理する Aurora レプリカの最大数を指定できます。この値は 0–15 に設定される必要があります。また、Aurora レプリカの最小数に指定された値以上である必要があります。 アプリケーションの Auto Scaling が管理する Aurora レプリカの最小数も指定できます。この値は 0–15 に設定される必要があります。また、Aurora レプリカの最大数に指定された値以下である必要があります。 Aurora Auto Scaling が機能するには、少なくとも 1 つのリーダー DB インスタンスが必要です。DB クラスターにリーダーインスタンスがなく、最小容量を 0 に設定すると、Aurora Auto Scaling は動作しません。 **注記** 最小容量と最大容量は、Aurora DB クラスターに対して設定されます。指定された値は、その Aurora DB クラスターに関連付けられたポリシーすべてに適用されます。 ### クールダウン期間 Aurora DB クラスターのスケールインやスケールアウトに影響するクールダウン期間を追加することで、ターゲット追跡スケーリングポリシーの応答性を調整できます。クールダウン期間を設定すると、その期間が過ぎるまでその後のスケールインやスケールアウトのリクエストがブロックされます。これらのブロックにより、スケールインリクエストのための Aurora DB クラスターの Aurora レプリカの削除、およびスケールアウトリクエストのための Aurora レプリカの作成を遅らせます。 以下のクールダウン期間を指定できます。 + スケールインアクティビティは、Aurora DB クラスターの Aurora レプリカ数を減らします。スケールインのクールダウン期間は、スケールインアクティビティが完了してから別のスケールインアクティビティが開始されるまでの時間 (秒) を指定します。 + スケールアウトアクティビティは、Aurora DB クラスターの Aurora レプリカ数を増やします。スケールアウトのクールダウン期間は、スケールアウトアクティビティが完了してから別のスケールアウトアクティビティが開始されるまでの時間 (秒) を指定します。 **注記** 後続のスケールアウトのリクエストが最初のリクエストよりも多くの Aurora レプリカを対象とする場合、スケールアウトのクールダウン期間は無視されます。 スケールインやスケールアウトのクールダウン期間を設定しない場合、それぞれのデフォルト値は 300 秒です。 ### スケールインアクティビティの有効化または無効化 ポリシーに対してスケールインアクティビティを有効化または無効化できます。スケールインアクティビティを有効にすると、スケーリングポリシーは Aurora レプリカを削除できます。スケールインアクティビティが有効な場合、スケーリングポリシーのスケールインのクールダウン期間がスケールインアクティビティに適用されます。スケールインアクティビティを無効にすると、スケーリングポリシーは Aurora レプリカを削除できなくなります。 **注記** スケールアウトアクティビティは、スケーリングポリシーが必要に応じて Aurora レプリカを作成できるように、常に有効にしておきます。 ### 自動スケーリングポリシーの追加、編集、または削除 AWS マネジメントコンソール、AWS CLI、または アプリケーションの Auto Scaling API を使用して自動スケーリングポリシーを追加、編集、または削除できます。自動スケーリングポリシーの追加、編集、削除の詳細については、以下のセクションを参照してください。 + [Amazon Aurora DB クラスターへの自動スケーリングポリシーの追加](Aurora.Integrating.AutoScaling.Add.md) + [Amazon Aurora DB クラスターの自動スケーリングポリシーの編集](Aurora.Integrating.AutoScaling.Edit.md) + [Amazon Aurora DB クラスターからの自動スケーリングポリシーの削除](Aurora.Integrating.AutoScaling.Delete.md) ## DB インスタンス ID とタグ付け Aurora Auto Scaling によってレプリカが追加されると、`application-autoscaling-` によってその DB インスタンス ID に `application-autoscaling-61aabbcc-4e2f-4c65-b620-ab7421abc123` などのプレフィックスが付けられます。 次のタグは DB インスタンスに自動的に追加されます。DB インスタンスの詳細ページの [**タグ**] タブで確認できます。 | Tag | 値 | | --- | --- | | application-autoscaling:resourceId | cluster:mynewcluster-cluster | Amazon RDS リソースタグの詳細については、「[Amazon Aurora および Amazon RDS リソースのタグ付け](USER_Tagging.md)」を参照してください。 ## Aurora Auto Scaling と Performance Insights Performance Insights を使用すると、他の Aurora リーダー DB インスタンスと同様に、Aurora Auto Scaling によって追加されたレプリカをモニタリングできます。 Performance Insights を使用して Aurora DB クラスターをモニタリングする方法の詳細については、「[Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。