Comment utiliser Automatic Workload Management (WLM) pour gérer ma charge de travail dans Amazon Redshift ?

Brève description

Amazon Redshift Automatic Workload Management (WLM) gère dynamiquement la mémoire et la simultanéité, afin de vous aider à hiérarchiser les requêtes des charges de travail mixtes. Avec Automatic Workload Management (WLM), Amazon Redshift gère les affectations de ressources selon les conditions suivantes :

• Une fois la requête envoyée à Amazon Redshift, les ressources sont affectées en fonction de la priorité de requête.
• S'il n'existe pas de charges de travail concurrentes, les requêtes de priorité inférieure ont accès à toutes les ressources système.
• Pour les charges de travail simultanées, les requêtes de priorité supérieure sont choisies. Un plus grand nombre de ressources est attribué aux requêtes de priorité supérieure par rapport aux requêtes de priorité inférieure.
• Les performances prévisibles d'une charge de travail hautement prioritaire se font au détriment d'autres charges de travail moins prioritaires.
  Remarque : les requêtes de priorité inférieure peuvent progresser à un rythme plus lent. Toutefois, Amazon Redshift s'assure que les requêtes de priorité inférieure ne manquent pas de ressources.
• Les charges de travail de priorité inférieure peuvent s'exécuter plus longtemps en raison du statut de priorité ou de l'utilisation d'un nombre moindre de ressources.

Pour utiliser efficacement Amazon Redshift Automatic Workload Management (WLM), tenez compte des points suivants :

• Affectez des priorités à une file d'attente.
• Modifiez les priorités des requêtes.
• Surveillez les priorités de requête.
• Vérifiez que la requête est en cours d'exécution en fonction des priorités attribuées.

Solution

Affectation de priorités à une file d'attente

Pour gérer votre charge de travail à l'aide de Automatic Workload Management (WLM), procédez comme suit :

1.    Définissez et répartissez la charge de travail en catégories (telles que ETL, tableaux de bord et analyses).

2.    Identifiez les utilisateurs et regroupez selon la charge de travail.

3.    Créez et affectez différentes files d'attente à un groupe d'utilisateur ou à un groupe de requêtes. Pour plus d'informations, consultez Affectation de requêtes à des files d'attente.

4.    Activez la mise à l'échelle de la simultanéité pour les files d'attente, afin qu'Amazon Redshift ajoute automatiquement une capacité de cluster supplémentaire, si nécessaire. Par exemple, vous pouvez activer la mise à l'échelle de la simultanéité sur les files d'attente si vous avez tendance à subir des rafales de trafic. Pour plus d'informations, consultez Configuration d'une d'attente de mise à l'échelle de la simultanéité.

Voici un exemple de configuration JSON pour Automatic Workload Management (WLM) :

[ {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ "ETL_users" ],
  "user_group_wild_card" : 1,
  "priority" : "highest",
  "queue_type" : "auto",
  "auto_wlm" : true    
}, {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ "Dashboard_users" ],
  "user_group_wild_card" : 0,
  "priority" : "high",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "query_group" : [ "Adhoc_query" ],
  "query_group_wild_card" : 1,
  "user_group" : [ "Analytics_users" ],
  "user_group_wild_card" : 1,
  "priority" : "normal",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ ],
  "user_group_wild_card" : 0,
  "priority" : "low",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "short_query_queue" : true
} ]

Remarque : si vous ne définissez pas de priorité de requête, toutes les files d'attente ont automatiquement l'état de priorité « normal ».

Modification des priorités des requêtes

Dans Amazon Redshift, vous pouvez modifier la priorité de la file d'attente à l'aide de règles de surveillance des requêtes (QMR) WLM ou de fonctions intégrées.

Méthode 1 : règles de surveillance des requêtes WLM

Utilisez les règles de surveillance des requêtes WLM lorsque vous souhaitez gérer la charge de travail en fonction de limites de performances basées sur des métriques. Lorsque vous définissez vos règles de surveillance des requêtes WLM, spécifiez la métrique de priorité de requête et l'action de priorité de requête. Par exemple :

{
  "query_group" : [ ],
  "query_group_wild_card" : 0,
  "user_group" : [ ],
  "user_group_wild_card" : 0,
  "rules" : [ {
    "rule_name" : "long_running_queries",
    "predicate" : [ {
      "metric_name" : "query_execution_time",
      "operator" : ">",
      "value" : 3600
    } ],
    "action" : "change_query_priority",
    "value" : "high"
  } ],
  "priority" : "low",
  "queue_type" : "auto",
  "auto_wlm" : true
}, {
  "short_query_queue" : true
} ]

Méthode 2 : Fonctions intégrées

Important : les fonctions intégrées nécessitent des autorisations appropriées. Pour pouvoir utiliser une fonction intégrée, vous devez être superutilisateur ou un superutilisateur doit vous accorder l'autorisation d'en utiliser une.

Dans Amazon Redshift, les fonctions intégrées sont indépendantes des configurations WLM. Pour accorder à un utilisateur standard l'autorisation d'utiliser une fonction intégrée, créez une procédure stockée qui spécifie SECURITY DEFINER. Ensuite, accordez l'autorisation à l'utilisateur standard.

Un superutilisateur peut modifier la priorité de requête à l'aide des fonctions intégrées suivantes :

• Niveau requête : CHANGE_QUERY_PRIORITY
• Niveau séance : CHANGE_SESSION_PRIORITY
• Niveau utilisateur : CHANGE_USER_PRIORITÉ

Remarque : l'état de priorité « Critical » (Critique) ne peut être attribué qu'à l'aide de fonctions intégrées. Une seule requête critique est autorisée dans le système à tout moment.

Surveillance des priorités des requêtes

Pour vérifier la priorité d'une requête d'une file d'attente ou d'une requête active, exécutez la requête suivante :

select query, service_class, query_priority, state from stv_wlm_query_state where service_class>=100;

Pour vérifier la priorité d'une requête terminée, utilisez la requête suivante :

select query, service_class, service_class_start_time as starttime, query_priority

from stl_wlm_query where query=<query_id>;

Pour vérifier que la priorité de requête a été modifiée en raison d'une règle QMR, utilisez la requête suivante :

select * from stl_wlm_rule_action where query= <Query_ID> and action= ‘change_query_priority’;

Dans votre sortie, vérifiez la colonne action_value pour identifier la priorité modifiée de votre requête.

Pour vérifier vos configurations QMR, exécutez la requête suivante :

select * from stv_wlm_QMR_config where action= ‘change_query_priority’;

Pour vérifier la valeur actuelle du paramètre query_group exécutez la requête suivante :

select current_setting(‘query_group’);

Pour vérifier la configuration de la file d'attente Automatic Workload Management (WLM), exécutez la requête suivante :

select s.service_class,
rtrim(s.name) as name, s.num_query_tasks as slots, s.query_working_mem as mem, s.max_execution_time as max_time, s.user_group_wild_card as user_wildcard, s.query_group_wild_card as query_wildcard,
rtrim(c.condition) as condition, s.query_priority from stv_wlm_service_class_config s left join stv_wlm_classification_config c on s.service_class = c.action_service_class where s.service_class > 4 order by service_class;

Remarque : si auto_wlm est activé et a la valeur « true » (vrai), l'ID de la classe de service indique 100-107. Les colonnes num_query_tasks et query_working_mem indiquent également la valeur -1.

Vérification de l'exécution de la requête en fonction des priorités attribuées

Les requêtes sont envoyées aux files d'attente en fonction des priorités attribuées, des règles de surveillance des requêtes et des caractères génériques correspondants pour les groupes d'utilisateurs et les groupes de requêtes. Amazon Redshift attribue ensuite automatiquement la requête à la première file d'attente correspondante.

Si votre requête ne s'exécute pas dans la file d'attente souhaitée, vérifiez que les conditions suivantes sont remplies :

• User ou query_group a la valeur « superuser » (super-utilisateur): si votre groupe d’utilisateurs ou groupe de requêtes a la valeur « superuser », la requête s'exécute dans la file d'attente du superutilisateur (service_class = 5).
• L'utilisateur est répertorié comme membre d'un groupe d'utilisateurs, mais un groupe de requêtes différent est affecté à la requête : si une requête est affectée à un groupe de requêtes différent de son appartenance au groupe répertorié, elle s'exécute dans la première file d'attente correspondante. Par défaut, les requêtes dans Amazon Redshift s'exécutent en fonction de la priorité définie de la file d'attente.
• Autorisations incorrectes pour l'utilisation des fonctions intégrées : si vous utilisez des fonctions intégrées (comme CHANGE_QUERY_PRIORITY, CHANGE_USER_PRIORITY, et CHANGE_QUERY_PRIORITY), vous devez disposer des privilèges d'un super-utilisateur. Ou, un super-utilisateur doit vous accorder les autorisations appropriées pour utiliser une fonction intégrée.
• L'utilisateur est membre de plusieurs groupes : si vous êtes répertorié comme membre de plusieurs groupes, la requête est affectée à la première file d'attente correspondante. Les correspondances de file d'attente sont effectuées conformément aux règles d'attribution des requête WLM.

Pour vérifier qu'une priorité de requête a bien été modifiée, exécutez la requête suivante :

select query, service_class, query_priority, state from stv_wlm_query_state where query= <Query_ID>;

Pour vérifier qu'un utilisateur est répertorié comme membre de plusieurs groupes, exécutez la requête suivante :

SELECT usename, groname
FROM pg_user, pg_group
WHERE pg_user.usesysid = ANY(pg_group.grolist)
AND pg_group.groname in (SELECT DISTINCT pg_group.groname from pg_group);

Pour déterminer si un groupe de requêtes a été défini pour une requête, exécutez la requête suivante :

select q.userid, q.query, rtrim(q.label) as label, w.service_class, w.query_priority from stl_query q join stl_wlm_query w on q.query = w.query where q.query = <Query_ID>;

Vérifiez la colonne label (étiquette) dans la sortie pour vérifier l'appartenance à un groupe d'une requête. Si une requête n'a pas de requête ou de groupe d'utilisateurs correspondants, elle s'exécute dans la file d'attente par défaut.

---