

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Exploitation d’Amazon ECS à grande échelle
<a name="operating-at-scale-best-practice"></a>

Lorsque vous commencez à exploiter Amazon ECS à grande échelle, réfléchissez à la manière dont les quotas de service et les limitations d'API pour Amazon ECS et ceux Services AWS qui s'intègrent à Amazon ECS peuvent vous affecter. 

**Topics**
+ [

# Quotas de service Amazon ECS et seuils de limitation d’API
](operating-at-scale-service-quotas-best-practice.md)
+ [

# Gestion des problèmes de limitation d’Amazon ECS
](operating-at-scale-dealing-with-throttles.md)

# Quotas de service Amazon ECS et seuils de limitation d’API
<a name="operating-at-scale-service-quotas-best-practice"></a>

Amazon ECS s'intègre à plusieurs d'entre eux Services AWS, notamment Elastic Load Balancing et Amazon EC2. AWS Cloud Map Grâce à cette intégration fine, Amazon ECS inclut plusieurs fonctionnalités telles que l’équilibrage de charge des services, la découverte de service, la mise en réseau des tâches et l’autoscaling de cluster. Amazon ECS et l'autre solution Services AWS qu'il intègre à tous les systèmes maintiennent les quotas de service et les limites de débit des API afin de garantir des performances et une utilisation cohérentes. Ces quotas de service empêchent également l’allocation accidentelle de ressources supérieures à celles nécessaires et protègent contre les actions malveillantes susceptibles d’augmenter votre facture.

En vous familiarisant avec vos quotas de service et les limites de débit des AWS API, vous pouvez planifier le dimensionnement de vos charges de travail sans vous soucier d'une dégradation inattendue des performances. Pour plus d’informations, consultez les sections [Quotas de service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html) et [Limitation des requêtes pour l’API Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html).

Lorsque vous effectuez une mise à l’échelle de vos charges de travail sur Amazon ECS, prenez en compte le quota de service suivant. Pour savoir comment demander une augmentation des quotas de service, consultez la section [Gestion de votre Amazon ECS et de vos quotas de AWS Fargate service dans le AWS Management Console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html).
+ AWS Fargate possède des quotas qui limitent le nombre de tâches exécutées simultanément dans chacune d'elles Région AWS. Il existe des quotas pour les tâches à la demande et Fargate Spot sur Amazon ECS. Chaque quota de service inclut également tous les pods Amazon EKS que vous utilisez sur Fargate. Pour de plus amples informations, consultez la section [Quotas de service AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-quotas.html#service-quotas-fargate) dans le *Guide de l’utilisateur Amazon Elastic Container Service pour AWS Fargate*.
+ Pour les tâches exécutées sur des instances Amazon EC2, le nombre maximal d’instances Amazon EC2 que vous pouvez enregistrer pour chaque cluster est de 5 000. Si vous utilisez l’autoscaling de cluster Amazon ECS avec un fournisseur de capacité de groupe Auto Scaling, ou si vous gérez vous-même les instances Amazon EC2 pour votre cluster, ce quota peut devenir un obstacle au déploiement. Si vous avez besoin de plus de capacité, vous pouvez créer d’autres clusters ou demander une augmentation de quota de service.
+ Si vous utilisez l’autoscaling de cluster Amazon ECS avec un fournisseur de capacité de groupe Auto Scaling, tenez compte du quota `Tasks in the PROVISIONING state per cluster` lors du dimensionnement de vos services. Ce quota est le nombre maximum de tâches dans l’état `PROVISIONING` pour chaque cluster pour lesquelles les fournisseurs de capacité peuvent augmenter la capacité. Lorsque vous lancez un grand nombre de tâches simultanément, vous pouvez facilement atteindre ce quota. Par exemple, si vous déployez simultanément des dizaines de services, chacun comportant des centaines de tâches. Dans ce cas, le fournisseur de capacité doit lancer de nouvelles instances de conteneur pour placer les tâches lorsque la capacité du cluster est insuffisante. Pendant que le fournisseur de capacité lance des instances Amazon EC2 supplémentaires, le planificateur de service Amazon ECS continuera probablement à lancer des tâches en parallèle. Toutefois, cette activité peut être limitée en raison d’une capacité de cluster insuffisante. Le planificateur de service Amazon ECS met en œuvre une stratégie de ralentissement et de limitation exponentielle pour réessayer de placer des tâches lorsque de nouvelles instances de conteneur sont lancées. Par conséquent, les délais de déploiement ou de réduction horizontale peuvent être plus lents. Pour éviter cette situation, vous pouvez planifier vos déploiements de service de l’une des façons suivantes. Déployez un grand nombre de tâches qui ne nécessitent pas d’augmentation de la capacité du cluster, ou conservez une capacité de cluster disponible pour le lancement de nouvelles tâches.

En plus de prendre en compte le quota de service Amazon ECS lors du dimensionnement de vos charges de travail, tenez également compte du quota de service pour Services AWS les autres services intégrés à Amazon ECS. La section suivante décrit en détail les principales limites de débit pour chaque service et fournit des recommandations pour faire face aux éventuels problèmes de limitation.

## Elastic Load Balancing
<a name="operating-at-scale-service-quotas-elb"></a>

Vous pouvez configurer vos services Amazon ECS pour utiliser Elastic Load Balancing afin de répartir le trafic de manière uniforme entre les tâches. Pour plus d’informations sur le choix d’un équilibreur de charge, consultez la section [Utilisation de l’équilibrage de charge pour distribuer le trafic d’un service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html).

### Quotas de service Elastic Load Balancing
<a name="elb-service-quotas"></a>

Lorsque vous mettez à l’échelle vos charges de travail, tenez compte des quotas du service Elastic Load Balancing suivants. La plupart des quotas de service Elastic Load Balancing sont ajustables, et vous pouvez demander une augmentation dans la console Service Quotas.

**Application Load Balancer**

Lorsque vous utilisez un Application Load Balancer, selon votre cas d’utilisation, vous devrez peut-être demander une augmentation de quota pour :
+  Le quota `Targets per Application Load Balancer`, qui correspond au nombre de cibles derrière votre Application Load Balancer.
+ Le quota `Targets per Target Group per Region`, qui correspond au nombre de cibles derrière vos groupes cibles.

Pour plus d’informations, consultez la section [Quotas pour vos Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html).

**Network Load Balancer**

Le nombre de cibles que vous pouvez enregistrer auprès d’un Network Load Balancer est soumis à des limites plus strictes. Lorsque vous utilisez un Network Load Balancer, vous souhaiterez souvent activer le support entre zones, ce qui implique des limites de mise à l’échelle supplémentaires sur les `Targets per Availability Zone Per Network Load Balancer`, qui correspond au nombre maximum de cibles par zone de disponibilité pour chaque Network Load Balancer. Pour plus d’informations, consultez la section [Quotas pour vos Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html).

### Limitation de l’API Elastic Load Balancing
<a name="elb-service-api-throttling"></a>

Lorsque vous configurez un service Amazon ECS pour utiliser un équilibreur de charge, les surveillances de l’état du groupe cible doivent réussir avant que le service ne soit considéré comme sain. Pour effectuer ces surveillances de l’état, Amazon ECS invoque les opérations de l’API Elastic Load Balancing en votre nom. Si vous avez configuré un grand nombre de services avec des équilibreurs de charge dans votre compte, vous risquez de constater un ralentissement des déploiements de service en raison d’une limitation potentielle spécifique aux opérations `RegisterTarget`, `DeregisterTarget` et `DescribeTargetHealth` de l’API Elastic Load Balancing. En cas de limitation, des erreurs de limitation apparaissent dans les messages d’événements de votre service Amazon ECS.

Si vous êtes confronté à une limitation d' AWS Cloud Map API, vous pouvez nous contacter Support pour obtenir des conseils sur la manière d'augmenter vos limites de limitation AWS Cloud Map d'API. Pour plus d’informations sur la surveillance et le dépannage de telles erreurs de limitation, consultez la section [Gestion des problèmes de limitation.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html) 

## Interfaces réseau Elastic
<a name="elastic-network-interfaces"></a>

Lorsque vos tâches utilisent le mode réseau `awsvpc`, Amazon ECS fournit une interface réseau Elastic (ENI) unique pour chaque tâche. Lorsque vos services Amazon ECS utilisent un équilibreur de charge Elastic Load Balancing, ces interfaces réseau sont également enregistrées en tant que cibles pour le groupe cible approprié défini dans le service.

### Quotas de service de l’interface réseau Elastic
<a name="eni-service-quotas"></a>

Lorsque vous exécutez des tâches utilisant le mode réseau `awsvpc`, une interface réseau Elastic unique est associée à chaque tâche. Si ces tâches doivent être atteintes via Internet, attribuez une adresse IP publique à l’interface réseau Elastic pour ces tâches. Lorsque vous mettez vos charges de travail Amazon ECS à l’échelle, tenez compte de ces deux quotas importants :
+ Le `Network interfaces per Region` quota qui est le nombre maximum d'interfaces réseau dans et Région AWS pour votre compte.
+ Le quota `Elastic IP addresses per Region`, qui correspond au nombre maximum d’adresses IP élastiques dans une Région AWS.

Ces deux quotas de service sont ajustables et vous pouvez demander une augmentation depuis votre console Service Quotas pour ces derniers. Pour plus d’informations, consultez la section [Quotas de service Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis).

Pour les charges de travail Amazon ECS hébergées sur des instances Amazon EC2, lorsque vous exécutez des tâches en mode réseau `awsvpc`, tenez compte du quota de service `Maximum network interfaces`, qui correspond au nombre maximum d’instances réseau pour chaque instance Amazon EC2. Ce quota limite le nombre de tâches que vous pouvez placer sur une instance. Vous ne pouvez pas ajuster le quota et il n’est pas disponible dans la console Service Quotas. Pour de plus amples informations, consultez la section [Adresses IP par interface réseau et par type d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) dans le *Guide de l’utilisateur Amazon EC2*.

Bien que vous ne puissiez pas modifier le nombre d’interfaces réseau qui peuvent être attachées à des instances Amazon EC2, vous pouvez utiliser la fonctionnalité de jonction d’interface réseau Elastic pour augmenter le nombre d’interfaces réseau disponibles. Par exemple, par défaut, une instance `c5.large` peut avoir jusqu’à trois interfaces réseau. L'interface réseau principale de l'instance est considérée comme une interface réseau. Ainsi, vous pouvez attacher deux interfaces réseau supplémentaires à l’instance. Dans la mesure où chaque tâche utilisant le mode réseau `awsvpc` nécessite une interface réseau, vous ne pouvez généralement exécuter que deux tâches sur ce type d’instance. Cela peut entraîner une sous-utilisation de la capacité de votre cluster. Si vous activez la jonction d’interface réseau Elastic, vous pouvez augmenter la densité de l’interface réseau afin de placer un plus grand nombre de tâches sur chaque instance. Lorsque la jonction est activée, une instance `c5.large` peut avoir jusqu’à 12 interfaces réseau. L’instance de conteneur a alors une interface réseau principale et Amazon ECS crée et attache une interface réseau « de jonction » à l’instance de conteneur. Par conséquent, avec cette configuration, vous pouvez exécuter 10 tâches sur l’instance au lieu des 2 tâches par défaut. Pour de plus amples informations, consultez la section [Jonction d’interface réseau Elastic](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html).

### Limitation de l’API d’interface réseau Elastic
<a name="eni-api-throttles"></a>

Lorsque vous exécutez des tâches qui utilisent le mode `awsvpc` réseau, Amazon ECS s'appuie sur le système Amazon APIs EC2 suivant. Chacun d'entre eux APIs a des limites d'API différentes. Pour plus d’informations, consultez la section [Limitation des requêtes pour l’API Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html).
+ CreateNetworkInterface
+ AttachNetworkInterface
+ DetachNetworkInterface
+ DeleteNetworkInterface
+ DescribeNetworkInterfaces
+ DescribeVpcs
+ DescribeSubnets
+ DescribeSecurityGroups
+ DescribeInstances

Si les appels d’API Amazon EC2 sont limités pendant les flux de travail d’allocation d’interface réseau Elastic, le planificateur de service Amazon ECS réessaie automatiquement avec des interruptions exponentielles. Ces tentatives automatiques peuvent parfois entraîner un retard dans le lancement des tâches, ce qui ralentit la vitesse de déploiement. En cas de limitation de l’API, le message `Operations are being throttled. Will try again later.` apparaît sur vos messages d’événement de service. Si vous respectez régulièrement les limites d'API Amazon EC2, vous pouvez nous contacter Support pour obtenir des conseils sur la manière d'augmenter vos limites de limitation d'API. Pour plus d’informations sur la surveillance et la résolution de ces erreurs de limitation, consultez la section [Gestion des problèmes de limitation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html).

## AWS Cloud Map
<a name="cloudmap"></a>

Amazon ECS Service Discovery permet AWS Cloud Map APIs de gérer les espaces de noms de vos services Amazon ECS. Si vos services comportent un grand nombre de tâches, tenez compte des recommandations suivantes. Pour de plus amples informations, consultez la section [Considérations en matière de découverte de service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations).

### AWS Cloud Map quotas de service
<a name="cloudmap-service-quotas"></a>

Lorsque les services Amazon ECS sont configurés pour utiliser la découverte de services, le `Tasks per service` quota, qui est le nombre maximum de tâches pour le service, est affecté par le quota de AWS Cloud Map `Instances per service` service, qui est le nombre maximum d'instances pour ce service. En particulier, le quota de AWS Cloud Map service réduit le nombre de tâches que vous pouvez exécuter à un maximum de 1 000 tâches par service. Vous ne pouvez pas modifier le quota AWS Cloud Map . Pour plus d’informations, consultez [Quotas de service AWS Cloud Map](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html).

### AWS Cloud Map Limitation de l'API
<a name="cmap-api-throttles"></a>

Amazon ECS appelle le`ListInstances`, `GetInstancesHealthStatus``RegisterInstance`, et `DeregisterInstance` AWS Cloud Map APIs en votre nom. Elles aident à la découverte de services et effectuent des surveillances de l’état lorsque vous lancez une tâche. Lorsque plusieurs services utilisant la découverte de services comportant un grand nombre de tâches sont déployés en même temps, cela peut entraîner le dépassement des limites de limitation des AWS Cloud Map API. Dans ce cas, vous verrez probablement le message suivant : `Operations are being throttled. Will try again later` dans votre service Amazon ECS, des messages d'événement indiquant un ralentissement du déploiement et de la vitesse de lancement des tâches. AWS Cloud Map ne documente pas les limites de limitation pour ceux-ci. APIs Si vous êtes confronté à un ralentissement dû à ces derniers, vous pouvez nous contacter Support pour obtenir des conseils sur l'augmentation des limites de limitation de vos API. Pour plus de recommandations sur la surveillance et le dépannage de telles erreurs de limitation, consultez la section [Gestion des problèmes de limitation.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)

# Gestion des problèmes de limitation d’Amazon ECS
<a name="operating-at-scale-dealing-with-throttles"></a>

Les erreurs de limitation sont classées en deux grandes catégories : la limitation synchrone et la limitation asynchrone.

## Limitation synchrone
<a name="synchronous-throttling"></a>

En cas de limitation synchrone, vous recevez immédiatement une réponse d’erreur d’Amazon ECS. Cette catégorie apparaît généralement lorsque vous appelez Amazon ECS APIs lors de l'exécution de tâches ou de la création de services. Pour de plus amples informations sur la limitation impliquée et les limites d’accélération pertinentes, consultez la section [Limitation de requête pour l’API Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html).

Lorsque votre application lance des demandes d'API, par exemple à l'aide du SDK AWS CLI ou d'un AWS SDK, vous pouvez remédier à la limitation des API. Pour ce faire, vous pouvez soit concevoir l’architecture de votre application de manière à gérer les erreurs, soit implémenter une stratégie de backoff exponentiel et d’instabilité avec une logique de nouvelle tentative pour les appels d’API. Pour de plus amples informations, consultez la section [Délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/).

Si vous utilisez un AWS SDK, la logique de nouvelle tentative automatique est intégrée et configurable.

## Limitation asynchrone
<a name="asynchronous-throttling"></a>

La régulation asynchrone se produit en raison de flux de travail asynchrones dans lesquels Amazon ECS CloudFormation ou Amazon pourrait APIs appeler en votre nom pour provisionner des ressources. Il est important de savoir lesquels Amazon ECS AWS APIs invoque en votre nom. Par exemple, l’API `CreateNetworkInterface` est invoquée pour les tâches qui utilisent le mode réseau `awsvpc`, et l’API `DescribeTargetHealth` est invoquée lors de l’exécution des surveillances de l’état pour les tâches enregistrées sur un équilibreur de charge.

Lorsque vos charges de travail atteignent une taille considérable, ces opérations d’API peuvent être limitées. En d'autres termes, ils peuvent être suffisamment limités pour dépasser les limites imposées par Amazon ECS ou par celui Service AWS qui est appelé. Par exemple, si vous déployez des centaines de services, chacun comportant simultanément des centaines de tâches qui utilisent le mode réseau `awsvpc`, Amazon ECS invoque des opérations API Amazon EC2 telles que `CreateNetworkInterface` et des opérations API Elastic Load Balancing telles que `RegisterTarget` ou `DescribeTargetHealth` pour enregistrer respectivement l’interface réseau élastique et l’équilibreur de charge. Ces appels d’API peuvent dépasser les limites de l’API, ce qui entraîne des erreurs de limitation. Voici un exemple d’erreur de limitation d’Elastic Load Balancing incluse dans le message d’événement de service.

```
{
   "userIdentity":{
      "arn":"arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForECS/ecs-service-scheduler",
      "eventTime":"2022-03-21T08:11:24Z",
      "eventSource":"elasticloadbalancing.amazonaws.com",
      "eventName":" DescribeTargetHealth ",
      "awsRegion":"us-east-1",
      "sourceIPAddress":"ecs.amazonaws.com",
      "userAgent":"ecs.amazonaws.com",
      "errorCode":"ThrottlingException",
      "errorMessage":"Rate exceeded",
      "eventID":"0aeb38fc-229b-4912-8b0d-2e8315193e9c"
   }
}
```

Lorsque ces appels d’API partagent des limites avec le trafic d’autres API de votre compte, il peut être difficile de les surveiller, même s’ils sont émis sous forme d’événements de service.

## Surveillance de la limitation
<a name="monitoring-throttling"></a>

Il est important d’identifier quelles requêtes d’API sont limitées et qui les émet. Vous pouvez utiliser AWS CloudTrail lequel contrôle la régulation et s'intègre à CloudWatch Amazon Athena et Amazon. EventBridge Vous pouvez configurer CloudTrail pour envoyer des événements spécifiques à CloudWatch Logs. CloudWatch Logs : log insights, analyse et analyse les événements. Cela permet d’identifier les détails des événements de limitation, tels que l’utilisateur ou le rôle IAM qui a effectué l’appel et le nombre d’appels d’API effectués. Pour plus d'informations, consultez la section [Surveillance des fichiers CloudTrail journaux à l'aide de CloudWatch journaux](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html).

Pour plus d'informations sur CloudWatch Logs Insights et des instructions sur la façon d'interroger les fichiers journaux, consultez la section [Analyse des données des CloudWatch journaux avec Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html).

Amazon Athena vous permet de créer des requêtes et d’analyser des données à l’aide du langage SQL standard. Par exemple, vous pouvez créer une table Athena pour analyser CloudTrail les événements. Pour plus d'informations, voir [Utilisation de la CloudTrail console pour créer une table Athena pour les CloudTrail journaux](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-ct).

Après avoir créé une table Athena, vous pouvez utiliser des requêtes SQL telles que la suivante pour examiner les erreurs `ThrottlingException`.

Remplacez le *user-input* par vos valeurs.

```
select eventname, errorcode,eventsource,awsregion, useragent,COUNT(*) count
FROM cloudtrail_table-name
where errorcode = 'ThrottlingException'
AND eventtime between '2024-09-24T00:00:08Z' and '2024-09-23T23:15:08Z'
group by errorcode, awsregion, eventsource, useragent, eventname
order by count desc;
```

Amazon ECS envoie également des notifications d'événements à Amazon EventBridge. Il existe des événements de modification de l’état des ressources et des événements d’action de service. Ils incluent des événements de limitation des API tels que `ECS_OPERATION_THROTTLED` et `SERVICE_DISCOVERY_OPERATION_THROTTLED`. Pour de plus amples informations, veuillez consulter [Événements d’action d’un service Amazon ECS](ecs_service_events.md).

Ces événements peuvent être consommés par un service, par exemple AWS Lambda pour effectuer des actions en réponse. Pour de plus amples informations, veuillez consulter [Gestion des événements Amazon ECS](ecs_cwet_handling.md). 

Si vous exécutez des tâches autonomes, certaines opérations API telles que `RunTask` sont asynchrones et les opérations de répétition ne sont pas automatiquement effectuées. Dans de tels cas, vous pouvez utiliser des services tels que EventBridge l'intégration pour réessayer des opérations limitées ou AWS Step Functions ayant échoué. Pour plus d’informations, consultez la section [Gestion d’une tâche de conteneur (Amazon ECS, Amazon SNS)](https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html).

## CloudWatch À utiliser pour surveiller l'étranglement
<a name="monitoring-throttling-cw"></a>

CloudWatch propose une surveillance de l'utilisation de l'API sur l'espace de `Usage` noms sous **By AWS Resource**. Ces métriques sont enregistrées avec le type d'**API** et le nom de la métrique **CallCount**. Vous pouvez créer des alarmes qui démarreront chaque fois que ces mesures atteignent un certain seuil. Pour de plus amples informations, consultez la section [Visualisation de vos quotas de service et définition des alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html).

CloudWatch propose également la détection des anomalies. Cette fonctionnalité utilise le machine learning pour analyser et établir des bases de référence en fonction du comportement particulier de la métrique sur laquelle vous l’avez activée. En cas d'activité inhabituelle de l'API, vous pouvez utiliser cette fonctionnalité avec des CloudWatch alarmes. Pour plus d'informations, consultez la section [Utilisation de la détection des CloudWatch anomalies](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).

En surveillant les erreurs de régulation de manière proactive, vous pouvez les contacter Support pour augmenter les limites de régulation pertinentes et également recevoir des conseils pour les besoins spécifiques de votre application.