リソース キューは、AnalyticDB PostgreSQL のリソース管理をどのように実装しますか?

背景

AnalyticDB for PostgreSQL (略称 ADB PG) は、PostgreSQL カーネル (略称 PG) をベースに Alibaba Cloud データベース チームによって開発されたクラウドネイティブのデータ ウェアハウス製品です。 ADB PG には、リアルタイムのインタラクティブ データ分析、HTAP、ETL、BI レポート生成などのビジネス シナリオにおける独自の技術的利点があります。金融、物流、インターネットなどの業界で広く使用されています。これは、従来のデータ ウェアハウスをクラウドに移行し、O と T を排除し、独自に構築した Greenplum を置き換えるためのベンチマーク クラウド データ ウェアハウス製品です。

データ ウェアハウス製品は、データ分析システムの重要なコンポーネントの 1 つです。さまざまなオンライン ビジネスでは、データ ウェアハウス製品の安定性と可用性に対して非常に高い要件が課せられます。効果的なリソース管理メカニズムがないと、データベース製品の安定性が低下し、接続数が OS の制限に達する、メモリが不足する、プロセスがフリーズするなどの問題が発生し、製品の可用性に影響を及ぼします。

リソース キューは、ADB PG のリソース管理方法です。データベースの CPU、メモリ、その他のリソースを制限できます。マルチテナントリソースを制限し、データベースの安定した動作を確保する上で一定の役割を果たします。名前が示すように、リソース キューは、データベース クラスター上で実行される SQL のリソースをキューの形式で管理します。各ユーザーについて、すべての接続は 1 つのキューにのみ属することができます。各キューは複数のユーザー接続を管理できます。指定されたリソース キューを持たないユーザーは、デフォルトのリソース キューによって管理されます。各キューのリソースの合計量を制限することで、特定の種類のビジネスまたは特定のユーザーが使用するリソースの合計量を制限できます。

オンライン取引プラットフォームの顧客 A である ADB PG を例に、リソース キューの使用方法を紹介します。顧客 A は、ADB PG をベースにデータ ウェアハウスを構築し、トランザクション データの保存に代表されるリアルタイム ビジネス、意思決定分析をサポートするために使用されるレポートビジネス。リアルタイム大画面表示に活用する可視化事業。 3 種類のサービスの異なる特性に基づいて、次の戦略に従ってリソース キューを構成します。

顧客Aのリアルタイムビジネスの典型的な例としては、Kafka->Flink->ADB PGリンクを通じてトランザクションデータがADB PGにリアルタイムに書き込まれることが挙げられます。このタイプのビジネスの典型的な特徴は、ピーク時の同時実行性が比較的大きく、単一の SQL リソースの消費量が低いことです。リソース キュー制限が実装される前は、ビジネスのピーク時に同時クエリが急増してデータベース接続がいっぱいになり、高可用性のライブネス クエリ実行が失敗し、インスタンスが使用できなくなることがよくありました。このタイプのビジネスでは、CPU の重みが高く、同時実行の制限が大きく (安全しきい値内)、単一の SQL メモリ共有が低いキューに関連付けられます。データの迅速な保存を保証するだけでなく、トラフィックのピークによるシステムの不安定化も防止します。

顧客 A のもう一つの代表的なビジネスは、レポート作成および ETL ビジネスです。このタイプのビジネスは、リアルタイム ビジネスのオフピーク期間中にスケジュールされ、意思決定をサポートするレポートが生成されます。このタイプのビジネスでは、大量のデータが処理され、大量のメモリが消費され、大量の一時ファイルが生成されます。このタイプのビジネスでは、CPU の重みが低く、同時実行の制限が低いが、メモリ共有率が高いキューを関連付けて、ビジネス ニーズを満たしながらメモリ使用量の上限を制御します。

さらに、お客様は、ADB PG データ ウェアハウスに基づくデータのリアルタイム視覚化もサポートします。このタイプの視覚化ソリューションは、同時実行性が非常に安定していることが多いですが、クエリのレイテンシに関して特定の要件があります。このタイプのビジネスでは、リソース キューを高い CPU 重み、低い同時実行制限、および広いオプティマイザー クエリ プラン消費シェアに設定し、ビジネスの安定性を可能な限り確保するために、適切なクエリ プランを生成しています。

次に、リソースキューの使い方、ステータス監視、実装の仕組みについて具体的に紹介します。

2. リソースキューの紹介

リソース キューは SQL 構成をサポートし、同時実行制限、CPU 制限、メモリ制限、クエリ プラン制限の 4 種類のリソース制限をサポートします。ユーザーは、SQL を使用してデータベース内に複数のリソース キューを定義し、各リソース キューにリソース制限を設定できます。データベースでは、各リソース キューは 1 人以上のデータベース ユーザーに関連付けることができ、各データベース ユーザーは 1 つのリソース キューにのみ属することができます。

さらに、リソース キューに送信されたすべての SQL ステートメントがキュー制限の対象となるわけではありません。データベースは、SELECT、SELECT INTO、CREATE TABLE AS SELECT、DECLARE CURSOR、INSERT、UPDATE、DELETE などの SQL ステートメントのリソース使用率のみを制限します。さらに、EXPLAIN ANALYZE コマンド中に実行された SQL ステートメントもリソース キューから除外されます。

リソース キューでサポートされるリソース制限構成は次のとおりです。

SQL ステートメントを使用して新しいリソース キューを定義します。

ACTIVE_STATEMENTS=3、MEMORY_LIMIT='1GB'、PRIORITY=LOW、MAX_COST=-1.0 を指定してリソース キュー etl を作成します。

アクティブステートメント:

キュー内で同時に実行できるクエリの数、つまり、キュー内で許可される同時実行クエリの最大同時実行値。データベースでは、データベースへの接続に ACTIVE_STATEMENTS の数より多く、最大接続数 MAX_CONNECTIONS より少ない接続が許可されますが、これらの SQL 接続はすぐに実行を開始せず、キューで待機します。

最大コスト:

クエリ プランのコスト制限。データベース オプティマイザーは、各クエリのコストを計算します。合計コストがリソース キューに設定された MAX_COST 値を超える場合、クエリは拒否されます。 ADB PG のデフォルト設定は 0 で、無制限を意味します。

メモリ制限:

ADB PG は、statement_mem を設定することで、各セグメント上の各 SQL ステートメントで使用されるメモリの上限を決定できます。メモリ制限にはデフォルト値がないため、指定しないままにしておくことができます。 MEMORY_LIMIT パラメータが設定されていない場合、リソース キュー内の SQL ステートメントに許可されるメモリ サイズは、statement_mem パラメータによって決まります。

リソース キューに MEMORY_LIMIT が設定されていない場合、各リソースに割り当てられるメモリ サイズは、サーバー構成パラメータ statement_mem になります。リソース キューの使用可能なメモリ サイズは、statement_mem と ACTIVE_STATEMENTS に基づいて計算されます。リソース キューに MEMORY_LIMIT が設定されている場合、単一の SQL ステートメントで使用されるメモリの量は、キュー内の平均割り当て値 (MEMORY_LIMIT/ACTIVE_STATEMENTS) と statement_mem の最大値によって決まります。具体的な計算方法については、以下の実装セクションを参照してください。

リソース キューで同時に実行できるクエリの数は、そのキューで使用可能なメモリによって制限されます。たとえば、キュ​​ー etl の場合、STATEMENTS=3 および MEMORY_LIMIT=2.1G を設定します。 statement_mem が設定されていない場合、各クエリはデフォルトで 700 MB のメモリを使用します。

SQL1 はキューに入り、700 MB のメモリを使用します。この時点でキュー内の残りメモリは 1.4G です。

SQL2 がキューに入り、statement_mem は 1.0 GB に設定されます。キュー内の残りのメモリは 0.4GB です。

この時点で、キューに残っているメモリは、SQL3 のメモリ使用量要件 (デフォルトでは 700 GB) を満たすことができません。そのため、キュー内の並列クエリの数はキュー制限に達していないにもかかわらず、SQL3 は実行できず、順番に待機する必要があります。

優先度：

データベースによって実行される SQL ステートメントは、所属するリソース キューの優先度設定に従って、使用可能な CPU リソースを共有します。優先度の高いキューのステートメントがアクティブに実行されているステートメントのグループに入ると、使用可能な CPU のシェアが高くなりますが、同時に、優先度の低いキューで既に実行されているステートメントのシェアも減ります。

クエリの相対的なサイズや複雑さは CPU の割り当てに影響しません。単純で安価なクエリが大規模で複雑なクエリと同時に実行され、それらの優先順位が同じに設定されている場合、利用可能な CPU リソースが均等に割り当てられます。新しいクエリがアクティブになると、CPU シェアが再計算されますが、優先度が同じクエリには引き続き同じ量の CPU が割り当てられます。

たとえば、管理者は、streaming、etl、prod の 3 つのリソース キューを作成し、それに応じて次の優先順位で構成します。

ストリーミング — 低優先度 ETL — 高優先度 prod — 最大優先度

etl キューのみでデータベース内で同時に実行されるクエリ 1 と 2 がある場合、優先順位が等しく設定されているため、CPU が均等に共有されます。

上記のグラフに示されているパーセンテージは概算です。高、低、中優先度のキューの CPU 使用率は、これらの比率を使用しても必ずしも正確に計算されるとは限りません。

ストリーミング キュー内のクエリの実行が開始されると、ETL キュー内の 2 つのクエリは引き続き同等の CPU シェアを維持しますが、優先順位の低いクエリ 3 はより低い CPU シェアで実行されます。

クエリが最高優先度のキュー prod に入ると、その CPU 使用率は最大優先度設定を考慮して調整されます。非常に単純なクエリかもしれませんが、完了するまで CPU の大部分を消費します。その他のクエリは優先順位が付けられ、CPU シェアが低くなります。

3. リソースキューの使用

3.1 リソースキューを作成する

ADB PG を使用すると、ユーザーは SQL を使用してリソース キューを作成し、さまざまなリソース制限を指定できます。新しいリソース キューを作成するには、CREATE RESOURCE QUEUE コマンドを使用します。

同時実行制限付きのキューの作成

ACTIVE_STATEMENTS 設定を持つリソース キューは、そのキューに割り当てられたロールによって実行できる同時クエリの数を制限します。

リソース キュー etl を (ACTIVE_STATEMENTS=3) で作成します。

つまり、ETL リソース キューに割り当てられたすべてのロールでは、システム上で同時に実行できるアクティブなクエリは 3 つだけです。キューにすでに 3 つのクエリが実行されていて、ロールがキューに 4 番目のクエリを送信した場合、スロットが解放されるまで 4 番目のクエリは実行できません。

メモリ制限のあるキューの作成

MEMORY_LIMIT 設定を持つリソース キューは、そのキューを通じて送信されるすべてのクエリによって使用される合計メモリを制御します。 ACTIVE_STATEMENTS と組み合わせて使用​​する場合、各クエリに割り当てられるデフォルトのメモリ量は MEMORY_LIMIT / ACTIVE_STATEMENTS になります。

たとえば、アクティブ クエリ制限が 10 で、合計メモリ制限が 2000 MB のリソース キューを作成するには、次のようにします (実行時に各クエリに 200 MB のセグメント ホスト メモリが割り当てられます)。

ACTIVE_STATEMENTS=10、MEMORY_LIMIT='2000MB' を指定してリソース キュー etl を作成します。

さらに、gp_vmem_protect_limit パラメータは、セグメントに割り当てられるメモリの合計サイズを制限します。このパラメータは優先度が高く、このパラメータを超えるとクエリがキャンセルされる可能性があります。

優先順位の設定

リソース キューによる使用可能な CPU リソースの消費を制御するために、ユーザーは適切な優先順位を割り当てることができます。

リソース キュー etl を (PRIORITY=LOW) に設定して変更します。リソース キュー etl を (PRIORITY=MAX) に設定して変更します。

3.2 リソースキューへのロール（ユーザー）の割り当て

リソース キューが作成されると、ユーザーは適切なリソース キューにロール (ユーザー) を割り当てる必要があります。ロールがリソース キューに明示的に割り当てられていない場合、ロールはデフォルトのリソース キュー pg_default に配置されます。

ALTER ROLE または CREATE ROLE コマンドを使用して、リソース キューにロールを割り当てます。例えば：

ALTER ROLE name RESOURCE QUEUE queue_name;CREATE ROLE name WITH LOGIN RESOURCE QUEUE queue_name;

リソースキューからロールを削除する

すべてのユーザーをリソース キューに割り当てる必要があります。特定のキューに明示的に割り当てられていない場合、ユーザーはデフォルトのリソース キュー pg_default に配置されます。ユーザーがリソース キューからロールを削除して、デフォルト キューに配置する場合は、ロールのキューの割り当てを「なし」に変更します。例えば：

ALTER ROLE role_name RESOURCE QUEUE なし;

3.3 リソースキューの変更

リソース キューが作成された後、ユーザーは ALTER RESOURCE QUEUE コマンドを使用してキューの制限を変更したり、DROP RESOURCE QUEUE コマンドを使用してリソース キューを削除したりできます。

リソースキュー構成の変更

ALTER RESOURCE QUEUE コマンドは、リソース キューの制限を変更します。リソース キューの制限を変更するには、キューに必要な新しい値を指定します。例えば：

リソース キュー etl を (ACTIVE_STATEMENTS=5) に設定して変更します。リソース キュー etl を (PRIORITY=MAX) に設定して変更します。

リソースキューの削除

DROP RESOURCE QUEUE コマンドはリソース キューを削除できます。リソース キューを削除するには、キューにロールが割り当てられておらず、キュー内で待機しているステートメントが存在してはなりません。

リソース キューの削除 etl;

4. リソースキューステータスの監視

4.1 キュー内のステートメントとリソースキューのステータスを表示する

gp_toolkit.gp_resqueue_status ビューを使用すると、ユーザーはワークロード管理リソース キューのステータスとアクティビティを表示できます。特定のリソース キューについては、実行を待機しているクエリの数と、システム内で現在アクティブなクエリの数が表示されます。システムで作成されたリソース キュー、その制限属性、および現在のステータスを表示するには、次の手順を実行します。

gp_toolkit.gp_resqueue_status から * を選択します。

4.2 リソースキュー統計の表示

リソース キューの統計とパフォーマンスを追跡する場合は、pg_stat_resqueues システム ビューを使用して、リソース キューの使用状況について収集された統計を表示できます。

SELECT * FROM pg_stat_resqueues;

4.3 リソースキューに割り当てられたロールの表示

リソース キューに割り当てられたロールを表示するには、pg_roles および gp_toolkit.gp_resqueue_status システム カタログ テーブルに対して次のクエリを実行します。

pg_roles、gp_toolkit.gp_resqueue_status から rolname、rsqname を選択します。ここで、pg_roles.rolresqueue=gp_toolkit.gp_resqueue_status.queueid;

4.4 リソースキュー内の待機クエリを表示する

ユーザーは、すべてのリソース キューの現在アクティブなクエリと待機中のクエリをすべて表示できます。

gp_toolkit.gp_locks_on_resqueue から * を選択し、lorwaiting='true' を指定します。

このクエリが結果を返さない場合は、現在リソース キューに待機しているステートメントがないことを意味します。

4.5 アクティブなステートメントの優先度の表示

現在実行中のステートメントを表示し、優先度、セッション ID、その他の情報を提供します。

gp_toolkit.gp_resq_priority_statement から * を選択します。

4.6 アクティブステートメントの優先度のリセット

ユーザーは関数 gp_adjust_priority(session_id, statement_count, priority) を使用して、現在実行中のステートメントの優先度を調整できます。この機能を使用すると、ユーザーはクエリの優先度を上げたり下げたりすることができます。例えば：

gp_adjust_priority(12, 10000, 'LOW')を選択します。

この関数のパラメータにおいて、session_id はセッション ID、statement_count はセッション内で調整する SQL のシーケンス番号、priority は調整する優先度を表します。 gp_resq_priority_statement ビューを通じて、既存のステートメントに関する上記の情報を照会できます。

gp_toolkit.gp_resq_priority_statement から * を選択します。

5. リソースキューの実装

ADB PG データベースは MPP アーキテクチャであり、1 つ以上のマスターと複数のセグメントに分割されます。データはランダムに、ハッシュ化、または複数のセグメント間で複製できます。 ADB PG では、リソース キューのリソース制限レベルはステートメント レベルです。つまり、トランザクション内にあるかどうかに関係なく、SQL ステートメント全体の実行中は常にリソース キューによって制限されます。

前述のように、リソース グループは同時実行性、CPU、およびメモリの制限をサポートしています。このセクションでは、これらのリソースを制限する実装の詳細について説明します。

5.1 同時実行の制限

ADBPG データベースはマルチプロセス モデルです。分散データベースの各ノードは複数のサブプロセスを開始します。各サブプロセスは、共有メモリ、共有セマフォ、共有メッセージ キューを通じてプロセス間通信を実現します。

リソース キューは分散ロックに基づいて実装されます。 ADBPG では、すべての SQL 接続は最初にマスター ノードに到達します。解析と最適化の後、エグゼキュータ レベルに到達すると、最初に ResQueueLock タイプの排他ロックを取得しようとします。

単一の ADB PG ノードでは、一度に 1 つのプロセスのみが ResQueueLock タイプの排他ロックを取得でき、各プロセスには 1 つのスレッドのみが含まれます。

前述のように、リソース グループは同時実行性、CPU、およびメモリの制限をサポートしています。このセクションでは、これらのリソースを制限する実装の詳細について説明します。

5.1 同時実行の制限

ADBPG データベースはマルチプロセス モデルです。分散データベースの各ノードは複数のサブプロセスを開始します。各サブプロセスは、共有メモリ、共有セマフォ、共有メッセージ キューを通じてプロセス間通信を実現します。

リソース キューは分散ロックに基づいて実装されます。 ADBPG では、すべての SQL 接続は最初にマスター ノードに到達します。解析と最適化の後、エグゼキュータ レベルに到達すると、最初に ResQueueLock タイプの排他ロックを取得しようとします。

単一の ADB PG ノードでは、一度に 1 つのプロセスのみが ResQueueLock タイプの排他ロックを取得でき、各プロセスには 1 つのスレッドのみが含まれます。

リソース キュー内の SQL の場合、使用できるメモリの上限は次のように計算されます。

1) リソース キューの memory_limit 値が設定されていない場合は、データベースの statement_mem 値が直接使用されます。

2) リソース キューのメモリ制限値が設定されている場合、リソース グループが使用できるメモリの合計量は、リソース キューに設定された memory_limit 値に基づいて計算されます。合計量をリソース キューに設定されている同時実行数で割ると、単一の SQL が使用できる上限値が得られます。次に、この上限と statement_mem の最大値を、SQL で使用される最終的なメモリ上限として取得します。

5.3 CPUの制限

リソース キューの CPU 制限は興味深い実装です。 ADB PG は、リソース キュー CPU 制限機能用の特別なプロセスであるスイーパー プロセスを開始し、各バックグラウンド プロセスの CPU 使用率を監視し、各バックグラウンド プロセスの CPU シェアを調整します。

このプロセスはデータベースから完全に独立しています。キャッシュやリソースをロードせず、トランザクションを開始したり、システム テーブルをクエリしたりすることはできません。そのアクティビティは、共有メモリの読み取りと書き込み、各プロセスの CPU 使用率の計算、CPU 割り当てシェアの変更です。実際に SQL を実行する各バックグラウンド プロセス (バックエンド) は、計算された CPU シェアに応じて一定時間スリープし、各 SQL の実際の CPU 使用率を調整します。

このプロセスの主なプロセスは上記のとおりです。そのプロセスは非常にシンプルで、継続的に掃除してスリープするだけです。

実際に SQL を実行する各バックエンド プロセスが起動されると、共有メモリに何らかのステータスが登録され、実行中に getrusage などのシステム コールが実行されて CPU 使用状況ステータスが更新されます。スイーパー プロセスは、これらの共有メモリの状態と設定されたリソース キューの CPU 使用率の値に基づいて、共有メモリ内の対応するバックエンド プロセスの CPU シェア (targetCPU) を更新します。バックエンド操作中、BackoffBackend が呼び出され、CPU シェアに応じて一定期間スリープし、全体的な CPU 使用率を調整します。

運用中、分散データベースの各コンピューティング ノードには、各ノードの CPU 呼び出しを調整するスイーパー プロセスがあり、リソース キューの CPU 構成がグローバルに有効になります。

VI.結論

リソース管理は、データベース クラスターのマルチテナント管理やきめ細かいリソース割り当てに非常に役立ちます。リソース キューは、分散データベース上の全体的なリソース管理と制御を実行でき、複数のテナントを分離し、データベース全体のスムーズな操作を保証する上で一定の価値があります。

ADB PG は、リソース キュー リソース管理方式に加えて、より細かいリソース制御を可能にするリソース グループ リソース管理方式もサポートしています。リソース グループは現在プライベート クラウド環境で利用可能であり、将来的にはパブリック クラウドでも徐々に機能を提供する予定です。リソース グループの基本的な使用方法とベスト プラクティスについては後ほど紹介します。