AnalyticDBのインテリジェントなElasticモデルの概要

> 本記事は[こちらのブログ](https://www.alibabacloud.com/blog/introduction-to-the-intelligent-elasticity-model-of-analyticdb_601829?spm=a2c65.11461433.0.0.4ee35355ZPTNb4)を参考にしています。
> 翻訳にはアリババクラウドの[ModelStudio](https://www.alibabacloud.com/en/product/modelstudio)([Qwen](https://www.alibabacloud.com/en/solutions/generative-ai/qwen))を使用しております。

## はじめに
世界経済の減速が続く中、コスト削減と効率性の向上は徐々に最も多くの顧客にとっての主要なニーズとなっています。アリババクラウドのクラウドネイティブデータウェアハウスである[AnalyticDB for MySQL](https://www.alibabacloud.com/product/analyticdb-for-mysql?spm=a3c0i.29710023.6791778070.126.9a70513dkWdXVF)は、当初から弾性的モードを提供し、ユーザーにとってデータベースの利用をより便利でコスト効果の高いものにしています。昨年、AnalyticDB for MySQLは、弾性モードのオンラインリソースグループのユーザー体験を最適化するためのマルチクラスターエラスティシティソリューションを発表しました。今年はジョブリソースグループに焦点を当て、DynamicAllocationエラスティシティモデルをさらに提案しました。これは事前にリソース使用量を自動推定し、実行中に知能的にスケーリングし、リソースホットプールに基づいてエラスティシティの効率を最適化し、クエリ起動遅延の問題に対処します。

### 1. 張さんの困惑
ある日、張さんが上司から先月の販売状況を分析するタスクを受け取りました。そこで、彼は[AnalyticDB for MySQL](https://www.alibabacloud.com/product/analyticdb-for-mysql?spm=a3c0i.29710023.6791778070.126.9a70513dkWdXVF)コンソールを開き、オフラインクエリを提出する準備をしました。公式ドキュメントを確認すると、張さんはクエリのためのリソース量を手動で指定する必要があることに気づきました。しかし、データベースの専門家ではない彼は、公式ウェブサイトのアーキテクチャ紹介やリソース仕様書を何度も参照し、最終的に必要なリソースを用心深く見積もりました。大いに努力してクエリを提出したものの、その後すぐにクエリが長い間反応なかったことに気づきました。緊張しながらページを何度も更新し、ほぼ30秒後にようやくクエリが始まりました。半月後、上司から先月のデータベース費用が予想よりもずっと高かった理由を尋ねられると、張さんが平均リソース使用率を調べたところ特に高くないことが分かり、困惑して当直グループに問い合わせを出しました。このシーンは、多くの顧客がオフラインクエリを使用中に遭遇する共通の問題を反映しています。顧客体験を向上させるために、AnalyticDB for MySQLはインテリジェントエラスティシティモデルを導入し、エラスティシティの効率を最適化してこれらの悩みを解決することを目指しています。

### 2. インテリジェントエラスティシティモデル
オフラインクエリは高スループットのシーンに適しており、OLAPデータウェアハウスの主要な能力の一つです。[AnalyticDB for MySQL](https://www.alibabacloud.com/product/analyticdb-for-mysql?spm=a3c0i.29710023.6791778070.126.9a70513dkWdXVF)では、この能力は主にジョブリソースグループを通じて提供されます。ジョブリソースグループでは、クエリごとのリソーススケジューリングモードが採用されており、制御ノードが各クエリに対して独立したリソースを割り当て、異なるクエリ間でリソースが隔離されています。

#### ユーザー定義アロケーションモデル
初期のジョブクエリは、多くの他の製品と同様に、ユーザー定義のリソース使用法を取りました。クエリを実行する前に、ユーザーはクエリが必要とする総リソース量とタイプを指定しなければなりません。例えば、ユーザーが合計ACUが17コアで各ノードの仕様が4コアのクエリを実行するとすると、4つの4コアの計算ノードがそのクエリに割り当てられます。

#### DynamicAllocationモデル
##### 自動リソース見積もり
自動リソース見積もりは、autoWLMと呼ばれることもあります。これは、ユーザーの過去のクエリとリソース使用履歴に基づいて専用の機械学習モデルを訓練します。このモデルは、まずクエリが既存のパターンに一致するかどうかを判断するハイブリッドモデルです。一致する場合、モデルは過去のクエリデータと現在のテーブル統計に基づいてリソース使用量を予測します。一致しない場合、モデルはテーブル統計と最適化器によって解析されたクエリプランに基づいてリソース使用量を推定します。

未知のクエリパターンについては、複数回実行した後、システムは自動的に履歴パターン情報をデータベースに記録します。これにより、実行と訓練の迅速なイテレーションを通じて、新しいパターンは既知のパターンとなり、より良い見積もり精度を得るために左側の見積もり経路をたどるようになります。自動リソース見積もりを実装したことで、ユーザーは各クエリのリソース使用量を手動で指定する必要がなくなり、すべてのリソースの割り当てはモデルによって見積もります。

##### 知能的なスケーリング
動的リソース適用は、クエリが完了するまでリソースを保持し、その後解放する従来の弾性モデルとは異なります。代わりに、モデルによって評価されたかユーザーが手動で指定された使用量に基づいてリソースを自動的にスケーリングします。まず、最小リソース使用量(min)とスケーリングのステップサイズを計算し、最大リソース使用量(max)は指定されたリソース使用量となります。実行中に、現在の同時実行数と負荷を定期的にチェックして、自動的にスケーリングが必要かどうかを判断します。各スケーリング操作は、ステップサイズでリソースを調整し、総リソース使用量を[min, max]の範囲内に保ちます。同時実行数や負荷が低い場合、クエリは最大リソース割り当てを必要とせず、わずかな部分だけが必要です。しかし、ジョブモードでの課金は実際のリソース使用量に基づいているため、ジョブクエリのコストを効果的に削減することができます。

##### 遅延スケジューリング
デフォルトでは、ジョブモードはバッチスケジューリングを使用します。大規模なクエリでOOM（Out Of Memory）問題を避けるために、クエリが強制的にディスクに書き込まれ、そのためバッチスケジューリングの実行効率はMPP（Massively Parallel Processing）スケジューリングよりも劣ります。一方、小規模および中規模のクエリではメモリ不足が起こる確率が低く、実行効率が重視されるため、MPPスケジューリングが望ましいです。MPPスケジューリングとバッチスケジューリングのもう一つの大きな違いは、MPPスケジューリングがノード数に応じて実行計画を分割し、全ノードが準備されるまでスケジューリングを開始を待つことによってノード間のリソース使用率を最大化することにあるのに対し、バッチスケジューリングは任意の単一ノードが準備ができたらすぐに開始することができます。遅延スケジューリングを有効にすることで、AnalyticDB for MySQLは自動的にクエリのリソース使用量と推定実行時間を評価し、それが小規模または中規模のクエリであるかどうかを判定します。そうであれば、MPPスケジューリングに切り替え、必要な全リソースが割り当てられるまでスケジューリング処理を開始を待ちます。

### 3. エラスティシティ効率の最適化
エラスティシティ効率はサーバーレス分野で避けることができないトピックです。最も正確で知能的なリソーススケ
新しい弾性モデルの利点
### 概念紹介
- **RT(RunningTime)** : クエリの実行時間。
- **ACU-hours** : AnalyticDBの統一的な計測と課金を行う単位です。1 ACU-hourは1 ACUが1時間実行することを意味し、資源消費の期間を表します。1 ACUは1コア2GBです。

### リソースホットプール
ポイントクエリは少量のデータをスキャンするため、実行計画がシンプルで通常は1秒以内に完了します。ジョブモードでは、このようなクエリの実行時間がリソース要求時間を反映することがあります。ポイントクエリは、弾性効率の変化を明確に示すことができます。  
![7](https://yqintl.alicdn.com/2ec98e64bd84f0619d72b9f06043ff49a5a9c4aa.png)

上図は、リソースホットプール有無での20件のポイントクエリの実行時間を比較しています。リソースホットプールを有効にすると、リソース要求時間が約30秒短くなり、小・中規模クエリのパフォーマンスが最大88%向上します。

### 自動リソース見積もり
自動リソース見積もりにより、ユーザーは手動でリソース使用量を指定する必要がなくなります。クエリを提出後、AutoWLMは機械学習モデルを使用して、過去のクエリデータに基づいて合理的なリソース量を推定します。  
![8](https://yqintl.alicdn.com/a5525f1d479ad5f12ef3d09745959ff97b0ad3b7.png)

前図は、TPC-H 1TBデータセットにおける自動見積もり有無でのクエリのリソース使用量を比較しています。直接リソースを指定すると、すべてのクエリがデフォルトの64 ACUを使用します。一方、自動見積もりを使用すると、コスト優先とパフォーマンス優先を選択できるスライダーが提供され、ユーザーが自由に決定できます。どちらの選択肢でも、自動見積もりは異なるクエリ負荷に基づいて合理的なリソース割り当てを提供します。  
![9](https://yqintl.alicdn.com/9051c49a942df4572ffdf47fb2dcc9821ff9dafd.png)

コスト優先モードでは、全クエリの合計実行時間(RT)は直接リソース指定時と同じですが、総コスト（または総ACU-hours）が約60.5％削減されます。パフォーマンス優先モードでは、全クエリの合計実行時間(RT)が15％短くなりながらも、コストはまだ53.2％節約できます。

### 知能拡張
![10](https://yqintl.alicdn.com/f69fdae67baf3ce81435a9c7c56f0f014660539f.png)

上図は、DynamicAllocation知能拡張を使用する代表的なクエリのリソース使用量を示しています。初期には、実際の負荷が割り当てられたリソースを常に利用するため、クエリは一定期間フルロードで動作しながらリソースを継続的に拡大します。クエリが終了に近づくにつれて、書き込み元データソースからの同時制限により、リソース需要が減少します。そのため、システムはクエリが終了するまで自動的にリソースを縮小します。  
![11](https://yqintl.alicdn.com/746b016207707822329762c6b799012b211b0ccd.png)

TPC-H 100GBをテストした結果、上図はACU消費量を示しています。知能拡張を有効にすることで、ほとんどのクエリの負荷が大幅に低下し、有効化前の対比で全クエリの合計ACU時間が30.4％削減されました。

### 5. 総括
従来の弾性モデルと比較して、新しい知能弾性モデルは以下の三つの面で大幅に改善されています。

- **使いやすさ**: 自動リソース見積もりにより、ユーザーが手動でリソース使用量を設定する必要が消えた。
- **コスト**: 知能拡張により、並行性やデータソースの制限による空いた負荷が効果的に削減され、リソース利用率が向上した。
- **リソースホットプール**: 大きなリソースの浪費を大幅に減らし、小・中規模クエリのリソース割当を高速化して、RTを短縮しコスト削減に貢献した。

- **パフォーマンス**: リソースホットプールにより、以前の高いリソース割当時間を最適化し、小・中規模クエリのRTを大幅に向上させた。
- **リソース利用率の改善**: コスト削減にもかかわらず、パフォーマンス向上のためにさらに多くのリソースを割り当てることができるようになる。

### 6. 今後の計画
今後は、以下のような改善と強化を目指します。

- **自動配信**: 負荷見積もりに基づいて、小规模なクエリをオンラインリソースグループ、大規模なクエリをオフラインリソースグループに自動配信し、コストとパフォーマンスのバランスを取る。
- **弾性効率**: ネットワーク接続性を改善し、起動時間をさらに短縮する。
- **結果レポート**: コンソールにクエリレベルのレポートを追加し、各クエリの実行時間とACU消費量をユーザーがよりよく理解できるようにする。
- **複数段階スライダー**: 現在の自動見積もり機能に加えて、複数段階のスライダーを導入し、コストとパフォーマンスのバランスを選択する幅を広げるため、さまざまな顧客のニーズに応える。