Database Autonomy Service (DAS) は、スケジュールされた自動スケーリング機能を提供します。 この機能を使用すると、特定の期間にデータベースインスタンスをスケールアップできます。 これにより、特定の期間内の大量のリクエストや、販売プロモーション中のトラフィックの増加など、データベース負荷の定期的な変化に対応できます。 指定されたスケーリング期間が経過すると、インスタンスは自動的に元の仕様にスケールバックされます。 これにより、ビジネス要件を満たし、コストを削減できます。
前提条件
管理するデータベースインスタンスは、次の要件を満たしている必要があります。
データベースインスタンスは、次のいずれかのタイプです。
ApsaraDB RDS for MySQL Standard Edition x86 アーキテクチャのインスタンス、または標準 SSD または Enterprise SSD (ESSD) を使用する General-purpose ApsaraDB RDS for MySQL High-availability Edition インスタンス。
説明スケジュールされた自動スケーリング機能は、読み取り専用の ApsaraDB RDS for MySQL インスタンスでは使用できません。
General-purpose または dedicated PolarDB for MySQL Cluster Edition クラスタ。
標準アーキテクチャの Redis Open-Source Edition のクラウドネイティブ (クラウドディスクベース) インスタンス、または標準アーキテクチャの Tair (Enterprise Edition) のクラウドネイティブ (クラウドディスクベース) インスタンス。
DAS 用のサービスロールが作成されています。 詳細については、「AliyunServiceRoleForDAS ロール」をご参照ください。
Alibaba Cloud アカウントに、スケールアップされたリソースのコストを支払うのに十分な残高があります。
注意事項
データベースインスタンスを定期的にスケールアップするには、データベースインスタンスに対してスケジュールされた自動スケーリングポリシーを設定する必要があります。
時間関連のパラメータはすべて UTC + 08:00 で表示されます。 このタイムゾーンがお客様のリージョンでサポートされていない場合は、パラメータを設定する前に時間を変換する必要があります。
データベースインスタンスには、各モードの自動スケーリングポリシーを 1 つだけ適用できます。
スケジュールされた自動スケーリングポリシーでは、再試行間隔はサポートされていません。 スケジュールされた自動スケーリングポリシーの実行に失敗した場合、システムはポリシーの実行を再試行しません。
インスタンスのスケールアップ後に [期間] パラメータまたは [スケールバック時間] パラメータが変更された場合、インスタンスは、2 つのパラメータのいずれかで指定された新しい時間に基づいて、以前の仕様にスケールバックされます。
次のシナリオでは、[期間] パラメータまたは [スケールバック時間] パラメータが指定されていても、データベースインスタンスが以前の仕様にスケールバックされない場合があります。
スケジュールされた自動スケーリングポリシーが実行された後、データベースインスタンスの仕様が手動または自動で再度変更されます。 インスタンスの仕様がポリシーで指定された仕様と異なる場合、データベースインスタンスはスケールバックされません。
データベースインスタンスの 1 つ以上のメトリックが特定の基準を満たしていません。 たとえば、スケジュールされた自動スケーリングポリシーに基づいて、インスタンスのメモリが 1 GB から 4 GB にスケールアップされるとします。 インスタンスがスケールバックされる前に 1 GB のメモリが使用されている場合、スケールバック操作中にメモリ使用量が 100% に増加するため、スケールバック操作は実行されません。 これにより、ビジネスの安定性とセキュリティが確保されます。
インスタンスが、仕様の変更が許可されていない状態 (仕様変更中または移行中など) です。
例
DAS は、インスタンスに対して 1 回または定期的にスケーリング操作を実行します。 DAS は、インスタンスを毎日、毎週、または毎月スケーリングする場合があります。 たとえば、ビジネスのピーク時間が毎月 1 日の 2:00 に始まり、毎月 3 日の 2:00 に終わる場合、スケジュールされた自動スケーリング機能を使用して、ピーク時間中にインスタンスをスケールアップし、オフピーク時間中にインスタンスをスケールバックできます。
課金
スケジュールされた自動スケーリングポリシーを作成する
DAS コンソール にログオンします。
スケジュールされた自動スケーリングポリシーを作成します。
[管理と設定] ページで、スケジュールされた自動スケーリングポリシーを作成します。
左側のナビゲーションウィンドウで、[リソース] > [自動スケーリング設定] を選択します。
[自動スケーリングポリシー] ページで、[ポリシーの追加] をクリックします。 [ポリシーの追加] パネルで、スケジュールされた自動スケーリングポリシーのパラメータを設定します。
表 1. パラメータ
パラメータ
説明
ポリシー名
ポリシーの名前。
モード
ポリシーのモード。 [スケジュールされた自動スケーリング] を選択します。
エンジンタイプ
データベースエンジンのタイプ。
仕様
選択したデータベースエンジンの仕様。
操作
実行される操作。 ApsaraDB RDS for MySQL インスタンスと Redis インスタンスでは、[インスタンス仕様の調整] のみがサポートされています。
PolarDB for MySQL クラスタでは、[インスタンス仕様の調整] と [読み取り専用ノード数の増加] がサポートされています。
有効期間
ポリシーが有効な期間。
開始時刻 は必須パラメータです。 このパラメータは、現在の日付以降の日付に設定する必要があります。
終了時刻 はオプションのパラメータです。
[繰り返し] パラメータを [N/A (1 回だけ実行)] に設定した場合、スケジュールされた自動スケーリングポリシーは 1 回だけ実行され、終了時刻 パラメータの影響を受けません。
[繰り返し] パラメータを [毎日]、[毎週]、または [毎月] に設定し、終了時刻 パラメータを空のままにした場合、スケジュールされた自動スケーリングポリシーは、指定されたサイクルに基づいて繰り返し実行されます。 終了時刻を指定すると、システムは終了時刻後にポリシーの実行を停止します。
繰り返し
スケーリング操作が実行される間隔です。有効な値:
N/A(1 回のみ実行)
スケーリング開始時間: このパラメーターを設定する必要があります。
期間: このパラメーターを設定するか、空のままにすることができます。正の整数に設定します。単位:時間。
このパラメーターを空のままにした場合、自動スケーリングポリシーの実行後、インスタンスはスケールバックされません。
このパラメーターを設定した場合、自動スケーリングポリシーの実行後、インスタンスは元の仕様にスケールバックされます。
毎日
スケーリング開始時間: このパラメーターを設定する必要があります。
スケールバック時間: このパラメーターを設定する必要があります。
スケーリング開始時間がスケールバック時間より前の場合、ポリシーが 1 回実行される 2 つの時点は同じ日になります。
スケーリング開始時間がスケールバック時間より後の場合、ポリシーが 1 回実行される 2 つの時点は同じ日になりません。インスタンスは、スケーリング開始の 1 日後にスケールバックされます。
説明スケールバック時間は、スケーリング開始時間より少なくとも 1 時間後である必要があります。
スケーリング開始時間は、前回のポリシー実行のスケールバック時間より少なくとも 1 時間後である必要があります。
終了時間を指定し、終了時間が最後のポリシー実行のスケーリング開始時間とスケールバック時間の間の日付に設定されている場合、最後のポリシー実行は実行されません。
毎週
スケーリング開始時間: このパラメーターを設定する必要があります。
スケールバック時間: このパラメーターを設定する必要があります。
スケーリング開始時間がスケールバック時間より前の場合、ポリシーが 1 回実行される 2 つの時点は同じ週になります。
スケーリング開始時間がスケールバック時間より後の場合、ポリシーが 1 回実行される 2 つの時点は同じ週になりません。インスタンスは、スケーリング開始後の翌週にスケールバックされます。
説明スケールバック時間は、スケーリング開始時間より少なくとも 1 時間後である必要があります。
スケーリング開始時間は、前回のポリシー実行のスケールバック時間より少なくとも 1 時間後である必要があります。
終了時間が最後のポリシー実行のスケーリング開始時間とスケールバック時間の間の日付に設定されている場合、最後のポリシー実行は実行されません。
毎月
スケーリング開始時間: このパラメーターを設定する必要があります。
スケールバック時間: このパラメーターを設定する必要があります。
スケーリング開始時間がスケールバック時間より前の場合、ポリシーが 1 回実行される 2 つの時点は同じ月になります。
スケーリング開始時間がスケールバック時間より後の場合、ポリシーが 1 回実行される 2 つの時点は同じ月になりません。インスタンスは、スケーリング開始後の翌月にスケールバックされます。
説明スケールバック時間は、スケーリング開始時間より少なくとも 1 時間後である必要があります。
スケーリング開始時間は、前回のポリシー実行のスケールバック時間より少なくとも 1 時間後である必要があります。
終了時間が最後のポリシー実行のスケーリング開始時間とスケールバック時間の間の日付に設定されている場合、最後のポリシー実行は実行されません。
[auto Scaling ポリシー] セクションで、作成したポリシーを見つけ、[アクション] 列の [適用] をクリックします。
[ポリシーの適用] ダイアログボックスで、ポリシーを適用するデータベースインスタンスを選択し、
アイコンをクリックします。
[確認] をクリックして、選択したデータベースインスタンスにポリシーを適用します。
[自律型関数設定] タブの [自律型関数管理] パネルで、スケジュールされた Auto Scaling ポリシーを作成します。
左側のナビゲーションウィンドウで、[インテリジェント O&M センター] > [インスタンス監視] を選択します。
表示されるページで、スケジュールされた Auto Scaling ポリシーを適用するデータベースインスタンスを見つけ、インスタンス ID をクリックします。インスタンスの詳細ページが表示されます。
インスタンスの詳細ページで、右上隅にある [自律型サービス設定] をクリックします。
[自律型関数設定]パラメーター タブで、 タブをクリックします。[適用済みポリシー] セクションで、 をクリックして、スケジュールされたスケーリングポリシーを作成します。詳細については、このトピックの セクションをご参照ください。
パネルの Auto Scaling[ポリシーを追加]推奨ポリシー セクションで、作成したポリシーを見つけ、操作 列の 適用 をクリックします。
説明ポリシーを変更するには、[アクション] 列の [変更] をクリックします。[ポリシーの更新] パネルで、ポリシー設定を変更します。
インスタンスにポリシーを適用しない場合は、[適用済みポリシー] セクションのポリシーの [アクション] 列にある [キャンセル] をクリックします。
[OK] をクリックします。
[アラート設定] セクションで、アラートテンプレートを設定し、アラート通知をサブスクライブします。これは、スケジュールされた Auto Scaling ポリシーのステータスをできるだけ早く把握するのに役立ちます。
システムはアラートテンプレートを推奨し、アラートテンプレートに必要な自律型イベントのアラートルールを追加します。プロンプトに従ってアラートテンプレートを設定できます。
説明データベースインスタンスのアラートテンプレートを設定している場合は、プロンプトに従って、必要な自律型イベントのアラートルールをアラートテンプレートに追加する必要があります。
データベースインスタンスのアラートテンプレートとアラートルールを設定する必要がある場合は、「アラートテンプレートを設定する」および「アラートルールを設定する」をご参照ください。
[連絡先グループの選択] セクションで、アラート連絡グループを選択します。
[連絡先の追加] をクリックして、アラート連絡先を追加します。
[連絡先グループの作成] をクリックして、アラート連絡グループを作成します。
管理するアラート連絡先を見つけ、[アクション] 列の [編集] または [削除] をクリックして、アラート連絡先の情報を変更するか、アラート連絡先を削除します。
詳細については、「アラート連絡先を管理する」をご参照ください。
[設定の送信] をクリックします。表示されるダイアログボックスで、設定を確認します。
スケジュールされた自動スケーリングの結果を表示する
DAS コンソールの左側のナビゲーションウィンドウで、[インテリジェント O&M センター] > [インスタンス監視] を選択します。
表示されたページで、スケジュールされた自動スケーリングが有効になっているデータベースインスタンスを見つけ、インスタンス ID をクリックします。インスタンスの詳細ページが表示されます。
インスタンスの詳細ページの左側のウィンドウで、[自律センター] をクリックします。
[自律センター] ページで、時間範囲を選択して、選択した時間範囲内に発生した [自動スケーリングイベント] を表示します。
[詳細] をクリックして、[自動スケーリングイベント] セクションでスケジュールされた自動スケーリングイベントの詳細を表示します。
よくある質問
インスタンスの仕様が上限に達した場合の対処方法を教えてください。
より高い仕様のインスタンスを購入することをお勧めします。たとえば、最大 104 個の vCPU と 768 GB のメモリをサポートする専用 ApsaraDB RDS for MySQL High-availability Edition インスタンスを購入できます。次に、インスタンスデータを新しいインスタンスに移行します。データベースインスタンスの仕様とデータ移行シナリオの詳細については、以下のトピックをご参照ください。
ApsaraDB RDS for MySQL: 仕様 と ApsaraDB RDS for MySQL インスタンス間でデータを移行する
PolarDB for MySQL: PolarDB for MySQL Enterprise Edition のコンピュートノードの仕様 と PolarDB for MySQL クラスタ間でデータを移行する
Tair (Redis OSS-compatible): インスタンス仕様 と Tair (Redis OSS-compatible) インスタンス間でデータを移行する
参照資料
インスタンスの仕様の変更方法については、次のトピックを参照してください。
ApsaraDB RDS for MySQL: インスタンスの仕様の変更
PolarDB for MySQL: クラスターの仕様を手動で変更する
Tair (Redis OSS-compatible): インスタンスの構成を変更する