Database Autonomy Service (DAS) のAuto Scaling機能は、データベースインスタンスのリアルタイムパフォーマンスデータを監視します。 データに基づいて、DASはトラフィック例外を検出し、適切な仕様とディスクを推奨します。 これにより、データベースサービスはストレージとコンピューティングリソースを自動的にスケーリングできます。
背景情報
データベースO&Mスタッフは、ビジネスアプリケーション用のCPUコアやメモリなど、適切なデータベース仕様を選択する方法の問題に直面することがよくあります。 過度に高い仕様は、リソースの浪費を引き起こす。 仕様が低すぎると、コンピューティングリソースが不足し、ビジネスに影響を与えます。
ほとんどの場合、O&Mスタッフは、安定したビジネストラフィックのCPU要件を満たすことができる仕様を使用します。 たとえば、O&Mスタッフは、CPU使用率を50% 未満に保つために、4つのCPUコアと8 GBメモリの仕様を使用できます。 さらに、O&Mスタッフは、ビジネスの安定した運用を確保するために、200 GBなどの比較的高いディスク仕様を使用しています。
ただし、データベースアプリケーションのO&Mスタッフは、データベースリソースを使い果たすトラフィックの急増に遭遇することがよくあります。 この問題はさまざまなシナリオで発生する可能性があります。
新しいサービスがリリースされると、実際のビジネストラフィック量が推定量を超えます。 これにより、リソースが使い果たされます。 たとえば、大量のトラフィックが新しくリリースされたアプリケーションにルーティングされたり、トラフィックの多いプラットフォームで新しい機能がリリースされたりします。
いくつかのシナリオでは、予測できないトラフィックサージが発生する。 たとえば、イベントや有名人が激しい公の議論を引き起こしたり、インフルエンサーがファッショントレンドや突然の買い物をリードしたりします。
いくつかのシナリオでは、毎日のパンチインおよびパンチアウト活動、または週に数回実行される財務会計タスクなど、頻繁ではないが集中アクセスが必要です。 このようなシナリオでは、ビジネスのプレッシャーはほとんどの場合低くなります。 リソースを節約するために、O&Mスタッフは、既知のアクセスのピーク時間にもかかわらず、高い仕様を割り当てないことがよくあります。
ほとんどの場合、O&Mスタッフは、ビジネスに深刻な影響を与えるコンピューティングリソースの不足が突然発生する準備ができていません。 O&Mスタッフがよく扱う課題の1つは、リソース不足に対処する方法です。
コンピューティングリソースまたはデータベースのストレージリソースが使い果たされる可能性があります。
コンピューティングリソースが使い果たされると、CPU使用率は100% に達し、現在の仕様に関連付けられているコンピューティング機能はビジネス要件を満たすことができません。
ストレージリソースが使い果たされると、ディスク領域の使用量が100% に達し、データベースに書き込まれるデータ量が現在の仕様の上限に達します。 この場合、新たなデータを業務システムに書き込むことはできない。
前述の2つのタイプの問題を解決するために、DASは革新的なサービスを提供し、データベースサービスがストレージとコンピューティングリソースを自動的にスケーリングできるようにします。
このトピックでは、DAS Auto Scalingの技術的課題、ソリューション、およびコアテクノロジーについて説明します。
技術的な課題
コンピューティングリソースの仕様を変更して、データベースのパフォーマンスを向上させることができます。 コンピューティングリソースはCPUコアとメモリのみで構成されますが、運用環境で仕様を変更すると、データ移行、高可用性 (HA) 切り替え、プロキシ切り替えなどの複数の操作が必要になる場合があります。 これは大きな影響を与え、ビジネスに影響を与える可能性があります。
ほとんどの場合、ビジネストラフィックスパイクが発生すると、コンピューティングリソースが不十分になり、CPU使用率が100% に達することさえあります。
容量の増加により、リソース不足の問題が解決できますか?
データベースを使用する場合、CPU使用率の100% は、コンピューティングリソースが不十分なために発生する症状の1つにすぎません。 この症状はさまざまな根本原因によって引き起こされる可能性があり、さまざまなソリューションを使用して問題を解決できます。
たとえば、ビジネストラフィックが急増し、現在の仕様に関連付けられているリソースがコンピューティング要件を満たすことができない場合があります。 この場合、容量を増やすために適切な時点で自動スケーリングを実行できます。
別の例では、多数の低速SQLステートメントは、タスクキューに輻輳を引き起こし、コンピューティングリソースなどの大量のリソースを消費する。 この場合、上級データベース管理者 (DBA) の最初の応答は、緊急ソリューションとして容量が増加する代わりにSQLスロットリングを実装することです。
インスタンスリソースが不十分であることをシステムが検出した場合、DASは複雑な問題の根本原因を特定し、スロットリングや容量の増加などの根本原因に基づいて情報に基づいた決定を行う必要があります。
いつ容量の増加が行われますか?
適切な時点と容量増加の方法を決定します。
緊急解決策が緊急事態の評価に密接に関連しているため、容量を実行するための時点の決定の精度が向上します。 緊急アラートが過度に高い頻度で報告される場合、インスタンスは頻繁にスケールアウトされ、高い仕様を使用します。 これは不必要なコストを引き起こす。 緊急アラートが後で報告された場合、緊急事態がビジネスに与える影響はより長い期間続きます。 これはビジネスの失敗を引き起こすことさえあります。 リアルタイム監視シナリオでは、突然発生するエラーが次の瞬間に続くかどうかを予測するときに、非常に困難があります。 したがって、緊急警報を報告するかどうかを決定することは課題です。
ほとんどの場合、容量を増やすには、スケールアウトとスケールアップの2つの方法を使用できます。 スケールアウトでは、水平スケーリング用に読み取り専用ノードが追加されます。 スケールアップでは、インスタンス仕様は垂直スケーリング用にアップグレードされます。
スケールアウトは、読み取りトラフィックの量が比較的大きく、書き込みトラフィックの量が比較的小さいシナリオに適用できます。 ただし、従来のデータベースの読み取り専用ノードを作成するには、データ移行が必要です。 データ移行中に、プライマリノードで新しいデータが生成されます。 生成された増分データは、読み取り専用ノードに同期する必要があります。 このため、新たなノードの作成には多大な時間を要する。
スケールアップでは、既存の仕様がアップグレードされます。 アップグレードは一般的なプロセスに従います。 一般的なプロセスでは、最初にセカンダリデータベースがアップグレードされ、次にプライマリデータベースとセカンダリデータベースの間で切り替えが実行されます。 次に、新しいセカンダリデータベースの仕様がアップグレードされます。 このプロセスにより、ビジネスへの影響が軽減されます。 ただし、セカンダリデータベースがアップグレードされてプライマリデータベースとして機能した後も、データ同期とデータ遅延の問題は依然として存在します。
したがって、既存の条件と現在のインスタンスのトラフィックに基づいて、容量増加の実行方法を決定する必要があります。
容量増加を実行するために使用される方法はですか? 仕様はどのように選択しますか?
データベースを使用する場合、タイムインスタンスの仕様が変更されるたびに、さまざまな管理およびO&M操作が必要になります。 たとえば、物理マシンにデプロイされているデータベースの仕様を変更する場合などです。 ほとんどの場合、データベースの仕様が変更されるたびに、さまざまな操作が含まれます。 これらの操作には、データファイルの移行、制御グループ (cgroup) の分離と再割り当て、トラフィックプロキシノード間の切り替え、およびプライマリノードとセカンダリノード間の切り替えが含まれます。 Dockerベースのデータベースの仕様を変更するプロセスはより複雑です。 これは、Dockerイメージの生成、Elastic Compute Service (ECS) インスタンスの選択、利用可能な仕様の管理など、追加のマイクロサービス関連の操作を実行する必要があるためです。 したがって、適切な仕様を使用すれば、仕様変更の回数を効果的に減らすことができます。 これはあなたのビジネスの時間を節約します。
CPU使用率が100% に達し、仕様をアップグレードすると、2つのシナリオが発生する可能性があります。 1つのシナリオでは、コンピューティングリソースの負荷が減少し、ビジネストラフィックが安定します。 もう1つのシナリオでは、CPU使用率は依然として100% 、コンピューティング機能が強化されているためトラフィックが増加します。 最初のシナリオの結果は最適であり、期待されます。 ただし、2番目のシナリオの結果も一般的です。 2番目のシナリオでは、アップグレード後、新しい仕様がビジネストラフィック容量の要件を満たすことができません。 したがって、リソースはまだ不十分であり、ビジネスは依然として影響を受けます。
データベース動作情報に基づいて適切な高い仕様を選択する方法に関する意思決定は、容量増加の結果に影響を与える。
解決策
DAS Auto Scalingは、前述の3つの技術的課題の処理に役立ちます。 次のセクションでは、サービス機能、ソリューション、およびコアテクノロジーの3つの側面からDAS Auto Scalingについて説明します。 ApsaraDB RDS for MySQL、PolarDB for MySQL、ApsaraDB for Redisなど、複数の種類のデータベースが関係しています。 自動ストレージ拡張、仕様の自動スケーリング、自動帯域幅調整などの機能も含まれます。 さらなる説明のために、このトピックの最後にユースケースを提供します。
サービス機能
自動ストレージ拡張機能は、事前アップグレードを実行して、現在の仕様の上限に達しそうなインスタンスのディスク容量を増やすことができます。 これにより、完全に占有されているデータベースのディスク領域の影響を受けなくなります。 この機能では、ストレージ拡張のしきい値比を設定できます。 DASによって提供されるデフォルトの上限しきい値 (90%) を使用することもできます。 しきい値を超えると、DASはインスタンスのディスク容量を増やします。
DASは、データベースインスタンスの仕様を自動的に変更するための仕様の自動スケーリング機能を提供します。 この機能では、コンピューティングリソースを調整して、適切な量のコンピューティングリソースを使用してビジネス負荷のアプリケーション要求を処理できるようにします。 この機能では、急激なレベル、ビジネストラフィック負荷の期間、および最大仕様を設定できます。 仕様変更後に元の仕様にロールバックするかどうかも指定できます。
DASは、データベースインスタンスの帯域幅を自動的に変更する自動帯域幅調整機能を提供します。 この機能により、帯域幅を適切な仕様に調整できます。 このようにして、不十分な帯域幅の問題が解決される。
ユーザー操作の観点から、DAS Auto Scalingは通知を使用して、タスクに関する進行状況とステータス情報を表示します。 通知は、仕様の推奨、タスクのステータス、例外によってトリガーされるイベントの3つのタイプに分けられます。 例外によってトリガーされたイベントの通知は、仕様変更のタスクがトリガーされたことを通知します。 仕様推奨の通知には、ストレージ拡張と仕様変更の元の仕様と予想される仕様が記載されています。 タスクステータスの通知は、Auto Scalingタスクに関する進行状況とステータス情報を提供します。
ソリューション
次の図は、DAS Auto Scalingを使用して上記の機能を提供するための閉ループ手順を実装する手順を示しています。
閉ループ手順には、パフォーマンスデータ収集、意思決定センター、アルゴリズムモデル、仕様の推奨および検証、管理、およびステータス追跡のためのモジュールが含まれます。 これらの各モジュールは、次の機能を提供します。
パフォーマンスデータ収集モジュールは、インスタンスのリアルタイムのパフォーマンスデータを収集します。 パフォーマンスデータは、様々なパフォーマンスメトリック、仕様設定、およびデータベースインスタンスの運用に関するセッション情報を含む。
意思決定センターモジュールは、現在のパフォーマンスデータ、インスタンスのセッションリスト、および第1のチャレンジを処理するための他のデータに基づいて、グローバルな決定を行う。 たとえば、現在のコンピューティングリソースが不十分で、SQLスロットリングがこの問題を解決できる場合、このモジュールはSQLスロットリングが有効であると判断します。 ビジネストラフィックスパイクが発生した場合、このモジュールは自動スケーリングプロセスが継続すると判断します。
アルゴリズムモデルモジュールは、DAS Auto Scaling機能のコアモジュールです。 このモジュールは、DASがビジネス負荷に対して異常検出を実行し、データベースインスタンスの容量仕様に関する推奨事項を提供できるようにコンピューティングを実装します。 これにより、2番目と3番目の課題を処理できます。
仕様推奨および検証モジュールは、仕様に関する具体的な推奨を提供し、推奨仕様がデータベースインスタンスのデプロイメントタイプおよび実際の動作環境に適しているかどうかを確認します。 このモジュールは、推奨仕様が現在の地域に提供されている利用可能な仕様に含まれているかどうかを確認するための別の検証も実行します。 これは、推奨が管理モジュールによって実施され得ることを保証する。
管理モジュールは、提供された仕様推奨を配布および実装する。
ステータス追跡モジュールは、仕様が変更される前後にデータベースインスタンスで発生するパフォーマンスの変化を測定および追跡します。
次のセクションでは、DAS Auto Scalingでサポートされている次の3つの機能 (自動ストレージ拡張、仕様の自動スケーリング、および自動帯域幅調整) のビジネスシナリオについて説明します。
次の図は、ストレージ拡張ソリューションを示しています。 ストレージ拡張は、ユーザー定義のしきい値とアルゴリズムベースの予測の2つの方法でトリガーされます。 時系列予測アルゴリズムと過去の期間のデータベースインスタンスの使用ディスク容量に基づいて、アルゴリズムは次の期間で使用されるディスク容量を予測します。 使用されているディスク容量が短期間でインスタンスのディスク仕様を超えると、ストレージの自動拡張がトリガーされます。 ストレージの拡張が実行されるたびに、ディスク領域を少なくとも5 GB、最大で15% 増やす必要があります。 これにより、データベースインスタンスのディスク容量が十分に確保されます。
自動スケーリング機能がディスクに実装される時点は、指定されたしきい値と予測結果によって決まります。 90% など、ディスクの使用率が指定されたしきい値までゆっくりと増加すると、ストレージの拡張がトリガーされます。 ディスクの使用率が急速に増加し、アルゴリズムが短期間でスペース不足が発生すると予測した場合、Auto Scalingはディスクストレージの拡張とその理由に関する推奨事項も提供します。
次の図は、仕様の自動スケーリングのソリューションを示しています。 仕様を変更するプロセスにおいて、異常検出モジュールは、複数の次元からのビジネストラフィックスパイクによって引き起こされるトラフィック例外を識別する。 これらのディメンションには、1秒あたりのクエリ (QPS) 、1秒あたりのトランザクション (TPS) 、アクティブセッション、IOPSなどの複数のパフォーマンスメトリックが含まれます。 次に、意思決定センターは、仕様を変更するために自動スケーリング機能を実装するかどうかを決定する。 自動スケーリング機能が実装される場合、仕様推奨モジュールは、高仕様推奨を提供する。 そして、管理モジュールは、仕様を変更する。
トラフィック例外が終了した後、異常検出モジュールは、トラフィックが正常状態に戻ることを識別する。 そして、管理モジュールは、メタデータに格納されている元の仕様情報に基づいて、仕様をダウングレードする。 仕様を変更するプロセス全体が完了した後、ステータス追跡モジュールは、プロセス中のパフォーマンス変更傾向を提供し、結果を評価する。
仕様の自動スケーリング機能をトリガーするための適切な時点を決定するために、DASは、CPU使用率、ディスクIOPS、インスタンスロジック読み取りなど、インスタンスのさまざまなパフォーマンスメトリックに対して異常検出を実行します。 次に、システムは、指定された観測ウィンドウでカバーされる期間に基づいて仕様を変更する効果的な方法で、仕様の自動スケーリング機能をトリガーします。 仕様の自動スケーリング機能がトリガーされた後、仕様推奨アルゴリズムのモジュールは、トレーニングされたモデル、現在のパフォーマンスデータ、現在の仕様、および以前のパフォーマンスデータに基づいて計算を実装します。 このようにして、モジュールは現在のトラフィックに適したインスタンス仕様を提供します。 さらに、元の仕様へのロールバックをトリガーする時点を決定するために、DASは、静止期間における観測ウィンドウの持続時間とインスタンスのパフォーマンスデータも考慮します。 元の仕様にロールバックするための条件が満たされた後、ロールバックが実行されます。
次の図は、自動帯域幅調整のソリューションを示しています。 帯域幅を変更するプロセスにおいて、異常検出モジュールは、アウトバウンドおよびインバウンドトラフィック使用量に基づいてトラフィック例外を検出する。 次いで、意思決定センターは、帯域幅をアップグレードするために自動帯域幅調整機能を実装するかどうかを決定する。 機能が実装される場合、仕様推奨モジュールは、高仕様推奨を提供する。 次いで、管理モジュールは、帯域幅をアップグレードする。
トラフィック例外が終了した後、異常検出モジュールは、トラフィックが正常状態に戻ることを識別する。 そして、管理モジュールは、メタデータに格納されている元の仕様情報に基づいて帯域幅をダウングレードする。 帯域幅を変更するプロセス全体が完了した後、状態追跡モジュールは、プロセス中の性能変化傾向を提供し、結果を評価する。
自動帯域幅調整機能をトリガーするための適切な時点を決定するために、DASはインスタンスのアウトバウンドトラフィックとインバウンドトラフィックの異常検出を実行します。 次に、システムは、自動帯域幅調整機能をトリガーして、指定された観測ウィンドウがカバーする期間に基づいて帯域幅をアップグレードします。 自動帯域幅調整機能がトリガされた後、仕様推奨アルゴリズムのモジュールは、トレーニングされたモデル、現在の性能データ、現在の帯域幅仕様、および以前の性能データに基づいて計算を実施する。 このようにして、モジュールは、現在のトラフィックに適した帯域幅仕様を提供する。 さらに、元の帯域幅仕様へのロールバックをトリガーする時点を決定するために、DASはインスタンスのパフォーマンスデータも考慮します。 元の帯域幅仕様にロールバックするための条件が満たされた後、ロールバックが実行されます。
コアテクノロジー
DAS Auto Scalingは、Alibaba Cloudデータベースデータチャネルチーム、管理チーム、およびカーネルチームによって開発された包括的なテクノロジーに依存しています。 この機能は、次の主要テクノロジーに依存しています。
レイテンシが数秒のネットワーク全体のデータベースインスタンスのデータモニタリング。 データ監視および収集チャネルは、数秒以内にネットワーク全体のデータベースインスタンスのデータ収集、監視、表示、および診断を実装します。 リアルタイムで1秒あたり1,000万を超えるモニタリングメトリックを処理できます。 これにより、インテリジェントデータベースサービスの強固なデータ基盤が築かれます。
ネットワーク全体のインスタンスに関する統合管理タスクフロー。 管理タスクフローは、Alibaba Cloudネットワーク全体のインスタンスに対してO&M操作を実行します。 これにより、Auto Scalingテクノロジが期待どおりに実装されます。
予測と機械学習に基づく異常検出のための時系列アルゴリズム。 異常検出のための時系列アルゴリズムは、定期的な検出の実行、ターニングポイントの決定、例外の連続的な間隔の識別など、さまざまな機能を提供します。 このアルゴリズムを使用して、700,000を超えるオンラインデータベースインスタンスのデータを予測できます。 アルゴリズムを使用して翌日のデータを予測する場合、結果エラーが5% 未満のインスタンスの数は99% を超えます。 14日後の期間のデータが予測される場合、結果エラーが5% 未満のインスタンスの数は94% を超えます。
ディープラーニングに基づくデータベース応答時間 (RT) の予測モデル。 このアルゴリズムは、CPU使用率、論理読み取り、物理読み取り、IOPSなど、データベースインスタンスのさまざまなパフォーマンスメトリックに基づいて、実行中のインスタンスのRTを予測します。 予測結果は、データベースがBufferPoolメモリを削減するときの参照に使用されます。 これにより、Alibabaデータベース用に27テラバイトのメモリが節約されます。 27テラバイトのメモリ空間は、全メモリの約17% を占める。
クラウドコンピューティングアーキテクチャに基づく次世代PolarDB for MySQL。 PolarDB for MySQLは、クラウドコンピューティング時代にAlibaba Cloudデータベースチームによって提供されるリレーショナルデータベースです。 このデータベースでは、計算ノードはストレージノードから分離されています。 この機能は、Auto Scalingの強力な技術サポートを提供します。 これにより、データのレプリケーションとストレージによって引き起こされる追加のオーバーヘッドが防止され、ユーザーエクスペリエンスが大幅に向上します。
前述のテクノロジーでサポートされているDAS Auto Scalingは、さまざまなエンジンに基づいてさまざまな機能を提供します。 また、DAS Auto Scalingは、オートスケーリング中のデータの一貫性と整合性を保証し、ビジネスの安定性に影響を与えずに機能を実装します。 このようにして、あなたのビジネスは保護されます。 次の表に、さまざまなデータベースエンジンでサポートされる機能を示します。
機能
サポートされているデータベースエンジン
仕様の自動スケーリング
ApsaraDB RDS for MySQL標準SSDまたは拡張SSD (ESSD) を使用するHigh-availability Edition、ローカルディスクを使用する汎用ApsaraDB RDS for MySQL High-availability Edition、および汎用ApsaraDB RDS for MySQL Enterprise Edition
PolarDB for MySQLクラスタエディション
ApsaraDB for Redis Community Editionとメモリ最適化ApsaraDB for Redis Enhanced Edition (Tair)
自動ストレージ拡張
ApsaraDB RDS for MySQL標準SSDまたはESSDおよびApsaraDB RDS for MySQLクラスターエディションを使用する高可用性エディション
標準SSDまたはESSDを使用するApsaraDB RDS for PostgreSQL High-availability Edition
ApsaraDB MyBase for MySQL標準SSDまたはESSDを使用するHigh-availability Editionおよびローカルディスクを使用するApsaraDB MyBase for MySQL High-availability Edition
自動帯域幅調整
ローカルディスクを使用するApsaraDB for Redis
ユースケース
次の例は、Auto Scaling機能の使用方法を示しています。 この例では、Apsara RDS for MySQLインスタンスが使用されています。 この例では、持続時間が15分の観測ウィンドウが設定されています。 CPU使用率のしきい値は80% に設定されます。
上の図では、07:10にトラフィックの例外が発生したため、CPU使用率とアクティブセッション数が急増しました。 CPU使用率が80% に達し、リソースが比較的不足していることを示します。 インスタンスの読み取りおよび書き込みトラフィックの分析では、現在のトラフィックが主にデータの読み取りに使用されていることがわかります。 DAS Auto Scalingのアルゴリズムでは、2つの読み取り専用ノードを追加することで、CPU使用率を60% に削減できると判断されています。 実装後、リソース不足の問題は解決されます。 ただし、09:00にビジネスが増加したため、CPU使用率が再び急上昇しました。 この場合、再びリソースが比較的不足する。 分析によると、現在のトラフィックは主にデータの書き込みに使用されます。 DAS Auto Scalingのアルゴリズムでは、コンピューティングリソースの仕様をアップグレードすることで、CPU使用率を50% に下げることができると判断されます。 実装後、リソース不足の問題は再び解決されます。
上記の例は、DAS Auto Scalingがリソース不足の問題をプロアクティブにトラブルシューティングし、データベースビジネスの安定性を効果的に確保できることを示しています。