Bonnes pratiques concernant le débit d'ingestion de données

Cette page décrit les bonnes pratiques à suivre pour optimiser le débit de données lors de l'ingestion de données dans l'API Cloud Healthcare. Ces recommandations sont destinées aux techniciens expérimentés dans la gestion du débit de données pour des systèmes à grande échelle.

Débit des données

Le débit de données correspond au nombre de ressources, telles que les ressources FHIR ou les instances DICOM, ou au nombre d'octets que l'API Cloud Healthcare ingère chaque seconde.

Contraintes liées au débit des données

La liste suivante décrit les raisons pour lesquelles le débit de données peut être limité:

• Vous n'aviez pas prévu de requêtes volumineuses qui entraînent des pics de trafic.
• Les contraintes de bande passante ralentissent l'ingestion de volumes de données importants envoyés en peu de temps.
• Plusieurs transactions simultanées modifient la même ressource de l'API Cloud Healthcare, ce qui provoque des conflits de données.
• Trop de petites demandes sont effectuées. Pour en savoir plus, consultez la section Éviter les petites requêtes d'importation et d'exportation.
• Trop d'opérations de longue durée sont exécutées simultanément, et la bande passante est limitée.
• Trop d'opérations de longue durée sont planifiées en même temps, ce qui entraîne des échecs.

Réessayer les requêtes ayant échoué

Si un client relance rapidement et à plusieurs reprises des requêtes après des échecs, cela peut dépasser les quotas de l'API Cloud Healthcare. Les sections suivantes décrivent comment relancer efficacement les requêtes ayant échoué.

Utiliser un intervalle exponentiel entre les tentatives avec la gigue et les files d'attente de nouvelles tentatives persistantes

L'intervalle exponentiel entre les tentatives avec la gigue introduite est une stratégie standard de gestion des exceptions pour les applications réseau. Un client relance régulièrement des requêtes ayant échoué avec des délais croissants de manière exponentielle entre les tentatives et avec un petit délai aléatoire.

Assurez-vous que la mise en œuvre de l'intervalle exponentiel entre les tentatives est idempotente pour chaque nouvelle tentative, en particulier si vous utilisez une logique personnalisée pour contourner les conditions d'échec. Pour en savoir plus, consultez la section 9.2.2 Méthodes idempotentes de la spécification HTTP.

La plupart des langages de programmation proposent des bibliothèques permettant de simplifier la mise en œuvre de l'intervalle exponentiel entre les tentatives et de stratégies de nouvelle tentative similaires. Pour les tentatives à long terme ou multiprocessus, mettez en œuvre une file d'attente de nouvelle tentative persistante. Cette file d'attente peut réinitialiser le mécanisme de nouvelle tentative si vous dépassez l'intervalle maximal entre les tentatives.

Utilisez un intervalle exponentiel entre les tentatives lorsque vous relancez ces requêtes:

• Opérations qui modifient une ressource ou un groupe de ressources FHIR.

• Requêtes de longue durée synchrones Réessayez en cas d'erreur au démarrage de l'opération ou en cas d'échec de cette opération.

  Les opérations de longue durée présentent des erreurs uniques qui peuvent vous obliger à implémenter les stratégies de nouvelle tentative suivantes:

  • Utilisez un bundle distinct pour stocker les données qui ont échoué à une opération d'importation ou de création.
  • Utilisez des requêtes synchrones pour les données qui n'ont pas pu être traitées.

Exemple d'algorithme d'intervalle exponentiel entre les tentatives

Un algorithme d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. L'algorithme suivant met en œuvre un intervalle exponentiel entre les tentatives tronqué avec la gigue:

1. Envoyez une requête à l'API Cloud Healthcare.

2. Si la requête échoue, attendez 1 + random-fraction secondes, puis effectuez une nouvelle tentative.

3. Si la requête échoue, attendez 2 + random-fraction secondes, puis effectuez une nouvelle tentative.

4. Si la requête échoue, attendez 4 + random-fraction secondes, puis effectuez une nouvelle tentative.

5. Continuez ce schéma en attendant 2ⁿ + random-fraction secondes après chaque nouvelle tentative, jusqu'à une durée de maximum-backoff.

6. Après deadline secondes, arrêtez de relancer la requête.

Lorsque vous appliquez l'algorithme, utilisez les valeurs suivantes :

• Avant chaque nouvelle tentative, le temps d'attente est de min((2n + random-fraction), maximum-backoff), avec n commençant par 0 et incrémenté de 1 à chaque nouvelle tentative.

• Remplacez random-fraction par une valeur fractionnelle aléatoire inférieure ou égale à 1. Utilisez une valeur différente pour chaque nouvelle tentative. L'ajout de cette valeur aléatoire empêche les clients de se synchroniser et d'envoyer plusieurs tentatives en même temps.

• Remplacez maximum-backoff par la durée maximale, en secondes, d'attente entre les tentatives. Les valeurs habituelles sont de 32 ou 64 (2⁵ ou 2⁶) secondes. Choisissez la valeur qui convient le mieux à votre cas d'utilisation.

• Remplacez deadline par le nombre maximal de secondes pendant lequel vous souhaitez continuer à envoyer des tentatives. Choisissez une valeur qui reflète votre cas d'utilisation.

Le client peut réessayer après avoir atteint l'intervalle maximum-backoff en utilisant la même valeur que l'intervalle entre les tentatives. Par exemple, si le délai maximum-backoff est de 64 secondes, réessayez toutes les 64 secondes. Assurez-vous que le client ne réessaie pas indéfiniment.

Implémenter une limitation du débit côté client avec le lissage du trafic

La limitation du débit protège les systèmes à grande échelle en évitant qu'ils ne soient submergés par un nombre excessif de requêtes. Si la limitation du débit côté client n'est pas suffisante, le système de quotas de l'API Cloud Healthcare peut limiter le débit de données. Pour en savoir plus, consultez les Bonnes pratiques de gestion des quotas.

Si vous avez des exigences supplémentaires, telles que la diffusion garantie après les nouvelles tentatives, les stratégies décrites dans Relancer les requêtes ayant échoué peuvent être insuffisantes. Le lissage du trafic est une technique de limitation du débit qui maintient le taux des requêtes côté client dans les limites de la bande passante. Les pics de charge sont ainsi répartis sur plusieurs heures ou minutes, ce qui améliore le débit. Lorsque le quota est limité, le lissage du trafic peut atteindre un débit plus élevé qu'en utilisant uniquement la répétition des tentatives, car il évite les refus et suit les unités de calcul.

Vous pouvez mettre en œuvre le lissage du trafic pour les opérations CRUD (création, suppression, mise à jour et suppression) synchrones, y compris fhir.executeBundle.

Exigences concernant le lissage du trafic

Pour implémenter le lissage du trafic, votre système doit implémenter les éléments suivants:

• Une file d'attente de traitement sauvegardée sur un espace de stockage avec redondance pour éviter les défaillances du disque.
• Nœuds de calcul coordonnés à extraire de la file d'attente de traitement
• Détection de l'utilisation globale pour ajuster le nombre de nœuds de calcul et leur vitesse de traitement en fonction des limites de quota
• Reprise après sinistre pour la file d'attente de traitement sauvegardée dans le stockage. En cas de sinistre, votre système doit pouvoir supprimer définitivement la file d'attente ou la récupérer.
• Réduction des opérations de longue durée pendant les heures de pointe Pour en savoir plus, consultez Planifier et utiliser efficacement les quotas et Mettre en file d'attente et gérer les opérations de longue durée.

Dans les cas suivants, le lissage du trafic peut n'être requis que pour une seule étape du pipeline:

• Limiter le nombre de nœuds de calcul extraits d'une étape précédente du pipeline.
• Limiter chaque nœud de calcul individuellement.
• Utiliser un coordinateur de pool de nœuds de calcul pour ajuster le taux de traitement des unités de travail individuelles, telles que les requêtes par seconde (RPS) ou les octets ingérés par seconde,

Limitation du débit dans d'autres zones de votre système

Vous pouvez utiliser des langages et des frameworks de programmation existants pour implémenter le lissage du trafic. Prenons l'exemple des projets Open Source et des solutions préconfigurées suivants:

• Limitation côté client dans Apache Beam Consultez la section Autoscaling horizontal pour savoir comment contrôler la limitation à l'aide des options numWorkers et maxNumWorkers.

• La classe Java RateLimiter de l'ensemble de bibliothèques Java principales de Google Gavave.

• Le module Python ratelimiter.

Pour le contrôle de flux, utilisez la bibliothèque cliente Pub/Sub de haut niveau.

Choisir entre le traitement asynchrone et le traitement synchrone

Une couche proxy côté client qui encapsule les requêtes adressées à l'API Cloud Healthcare, comme expliqué dans Gérer les erreurs sur plusieurs couches, peut également contrôler la limitation des services qui utilisent l'API Cloud Healthcare. Selon le type de lissage du trafic requis, utilisez l'une des options suivantes:

Asynchrone

Utilisez le traitement asynchrone pour mettre les requêtes en file d'attente et contrôler les nœuds de calcul. Une couche proxy écrit les requêtes entrantes dans la file d'attente et renvoie des réponses 200 OK après la mise en file d'attente de chaque requête. Cela fonctionne mieux pour les requêtes d'écriture, mais peut être utilisé pour les requêtes de lecture dans un framework d'opération de longue durée si les clients peuvent recevoir des résultats de lecture.

Synchrone

Le traitement synchrone fournit un mécanisme de retour simple si une unité de travail dépend de la fin d'une unité précédente. Une couche proxy retarde les requêtes sortantes en fonction des limites de débit par RPS ou en octets. Le client bloque et attend la réponse de la couche proxy.

La couche proxy peut ajuster sa limitation du débit en fonction du nombre d'instances ou se coordonner avec un processus de contrôleur qui ajuste la limite de débit à quelques secondes d'intervalle. Pour que la couche proxy puisse suivre le nombre d'instances et leurs limites de débit, chaque instance de proxy peut lire régulièrement un fichier ou effectuer un appel de procédure à distance (RPC) avec les limites de débit encodées.

Le traitement synchrone présente parfois les inconvénients suivants:

• Les ressources des couches client et proxy ne sont pas disponibles pendant que le client se bloque et attend une réponse. Cela peut entraîner des erreurs, des délais avant expiration et une baisse du débit de données, ce qui complique le scaling.

• Si la couche client et la couche proxy se déconnectent, davantage de travail est nécessaire pour s'assurer que les données ont été modifiées comme demandé.

Utiliser Cloud Tasks

Utilisez Cloud Tasks pour décharger les requêtes dans une file d'attente. Cloud Tasks définit et surveille automatiquement les quotas Google Cloud suivants:

• Taille maximale d'utilisation intensive et simultanéité maximale des requêtes à l'aide de l'objet RateLimits
• Limiter les nouvelles tentatives à l'aide de l'objet RetryConfig

Consultez la section Créer des files d'attente pour créer des files d'attente dans Cloud Tasks. La ressource Queue affiche les options que vous pouvez définir sur une file d'attente. Par exemple, vous pouvez utiliser l'objet RetryConfig pour mettre en œuvre un intervalle exponentiel entre les tentatives. Consultez la section Bibliothèques clientes Cloud Tasks pour connaître les bibliothèques spécifiques à chaque langage.

Lorsque vous utilisez Cloud Tasks, tenez compte des points suivants:

• Cloud Tasks ne garantit pas une distribution "exactement une fois". Lors d'une distribution de type "exactement une fois", toutes les requêtes contenant des données en double sont reconnues comme des doublons et ignorées par le serveur. Pour en savoir plus, consultez l'article After Lambda: traitement "exactement une fois" dans Dataflow, partie 1.
• La taille maximale des tâches peut être nettement inférieure à la taille maximale du groupe FHIR dans l'API Cloud Healthcare. Pour en savoir plus, consultez les pages Quotas et limites de Cloud Tasks et Quotas et limites de l'API Cloud Healthcare.
• Cloud Tasks présente des problèmes et des limites.

Combiner des bundles FHIR avec des limiteurs de débit

La répétition des tentatives des bundles FHIR avec un intervalle exponentiel entre les tentatives et des limiteurs de débit permet de maintenir un débit de données élevé et de gérer les pics de charge.

Un client peut envoyer des groupes FHIR par lot et transaction à Cloud Tasks, qui envoie les requêtes du groupe à l'API Cloud Healthcare. Si le limiteur de débit est atteint ou dépassé parce qu'il a atteint la taille de file d'attente maximale et qu'il manque d'espace disque, le client peut mettre en œuvre un intervalle exponentiel entre les tentatives pour mettre les groupes en file d'attente.

Pour éviter que la file d'attente du limiteur de débit ne soit saturée, surveillez les ressources suivantes:

• Quotas d'opérations FHIR dans l'API Cloud Healthcare
• Quotas du limiteur de débit
• Erreurs du limiteur de débit

Si la file d'attente du limiteur de fréquence devient pleine, votre système doit alerter une personne et empêcher le client d'envoyer des requêtes.

Utiliser des connexions HTTP persistantes (keep-alive réutilisable)

Par défaut, l'API Cloud Healthcare ouvre une nouvelle connexion TCP pour chaque requête CRUD. Cela nécessite un handshake TCP, ce qui peut entraîner une surcharge et dégrader les performances. Pour améliorer les performances, utilisez le message Keep-alive HTTP afin de garder la connexion TCP ouverte pour plusieurs requêtes.

Pour utiliser le message keep-alive HTTP dans HTTP/1.1, définissez l'en-tête Connection sur keep-alive:

Connection: keep-alive

HTTP/2 utilise une connexion TCP pour les requêtes séquentielles et simultanées, ce qui évite automatiquement cette surcharge.

La bibliothèque Python requests utilise le message keep-alive HTTP par défaut. Si vous utilisez Node.js, définissez keepAlive sur true lorsque vous créez un objet http.Agent, puis transmettez-le dans votre requête.

Utiliser un framework de test

Un framework de test garantit le bon fonctionnement de votre code et vous aide à effectuer les opérations suivantes:

• Préparez-vous aux pics de trafic soudains dans une application ou un pipeline.
• Vérifiez si l'intervalle exponentiel entre les tentatives et la limitation du débit côté client améliorent les performances. Les tests peuvent indiquer si ces implémentations génèrent des tâches en attente devant être gérées séparément.
• Séparez et contrôlez le trafic prioritaire. Par exemple, si un utilisateur attend une réponse, la charge de travail des tâches de traitement en arrière-plan peut être réduite pour garantir que l'expérience utilisateur n'est pas dégradée.
• Testez des stratégies de mise en file d'attente synchrones et asynchrones pour réguler le flux de trafic, ou vérifiez si la couche proxy gère les refus.
• Planifiez la reprise après sinistre. Cela nécessite généralement de réinitialiser le trafic entrant ou d'utiliser des files d'attente pour reprendre le trafic après la fin du sinistre.

Utilisez Cloud Monitoring

Surveillez vos environnements de test et de production à l'aide de Cloud Monitoring. Suivez ces recommandations:

• Intégrer Cloud Tasks à d'autres services de journalisation et de surveillance Google Cloud, tels que Cloud Audit Logs
• Créez des métriques personnalisées avec l'API Cloud Monitoring pour suivre des métriques clés telles que les tentatives, la taille et l'âge de la file d'attente.
• Créez des objectifs de niveau de service (SLO) et des indicateurs de niveau de service (SLI) pour vos environnements. Pour obtenir des recommandations, consultez la page Présentation des SLI.
• Créer des règles d'alerte à l'aide de l'observabilité Google Cloud Les règles d'alerte vous signalent des problèmes, par exemple si votre système est soumis à un stress ou nécessite une intervention humaine.
• Créez des playbooks opérationnels afin que les administrateurs système sachent quoi faire si une règle d'alerte envoie une notification.

• Utilisez les guides opérationnels dans un environnement de préproduction pour répondre aux scénarios suivants:

  • En attente causés par la limitation du débit
  • Rejet en raison d'un dépassement des limites de quota
  • Pics de trafic entrant

Éviter les erreurs 429 Resource Exhausted operation_too_costly

Effectuer des milliers de mises à jour parallèles chaque jour sur une ressource FHIR peut entraîner des conflits de verrouillage et de la latence, et empêcher l'exécution des transactions. Les transactions qui ne peuvent pas être finalisées peuvent créer un backlog d'erreurs 429 Resource Exhausted operation_too_costly:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to lock contention while executing transactional bundle. Resource type: FHIR_RESOURCE_TYPE",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

Dans cette erreur, le terme "coût" fait référence à l'utilisation des ressources et au débit des données, et non aux coûts facturés.

Une erreur 429 Too Many Requests n'indique pas toujours un problème de quota. Cette erreur peut se produire lorsque le serveur FHIR de l'API Cloud Healthcare détecte un conflit de verrouillage excessif sur les enregistrements de base de données. Cela peut se produire en raison de nombreuses opérations dans un bundle FHIR ou d'une combinaison d'opérations CRUD.

Imaginez le scénario suivant :

1. Un groupe de transactions FHIR qui met à jour une ressource Patient et d'autres ressources FHIR verrouille la ressource Patient jusqu'à la fin de la transaction.

2. Plusieurs bundles FHIR tentent de mettre à jour la ressource Patient en parallèle, et un conflit de verrouillage se produit. Les réponses d'erreur incluent un champ diagnostics avec le texte Resource type: PATIENT.

   Vous pouvez réessayer de mettre à jour la ressource Patient avec un intervalle exponentiel entre les tentatives, mais les longues périodes de conflit de verrouillage peuvent entraîner des délais avant expiration, une réduction du débit et une utilisation accrue des ressources.

3. Le serveur FHIR de l'API Cloud Healthcare détecte à terme un nombre de transactions en attente et les pertes de charge en renvoyant des erreurs operation_too_costly. Cela limite le trafic et empêche d'autres erreurs.

   Les erreurs operation_too_costly limitent toutes les opérations FHIR CRUD dans votre projet Google Cloud, ce qui affecte toutes les applications connectées à votre projet.

Résoudre les erreurs liées à 429 Too Many Requests

Pour résoudre les erreurs 429 Too Many Requests, effectuez une recherche dans Cloud Logging. Les erreurs contenant operation_too_costly indiquent un conflit de verrouillage. Si les erreurs sont causées par l'épuisement des ressources, recherchez d'éventuels problèmes de quota.

En cas de limitation, les groupes de transactions peuvent échouer en raison d'un niveau élevé de conflit de verrouillage et générer l'erreur suivante:

HTTP/1.1 429 Too many requests
...

{
  "issue": [
    {
      "code": "too-costly",
      "details": {
        "text": "operation_too_costly"
      },
      "diagnostics": "aborted due to cumulative heavy load or lock contention in this project while executing transactional bundle, please see https://cloud.google.com/healthcare-api/docs/troubleshooting#fhir_transaction_bundle_heavy_load for more information",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

Pour résoudre l'erreur, accédez au lien FHIR transactionnelle bundle annulé en raison d'une charge cumulative importante dans le champ diagnostics.

Éviter les lots volumineux

L'erreur 429 Too Many Requests est plus probable avec les bundles de transactions volumineux. Des bundles de n'importe quelle taille peuvent créer des goulots d'étranglement de débit. Testez différents lots pour trouver la taille optimale.

Les lots volumineux avec de nouvelles tentatives peuvent avoir des rendements décroissants et sont plus susceptibles de subir plusieurs échecs. Les clients doivent mettre en œuvre une logique supplémentaire pour gérer le sous-ensemble de ressources FHIR ayant échoué dans une transaction.

Les lots de lots peuvent rencontrer des erreurs 429 Too Many Requests et 413 Request Entity Too Large, ainsi que des goulots d'étranglement de débit s'ils sont volumineux ou si le nombre de RPS est élevé.

Évitez d'utiliser des lots volumineux comportant des milliers de transactions. Procédez plutôt comme suit :

• Utilisez des groupes de transactions plus petits qui acceptent la cohérence des données. Si les ressources FHIR ne dépendent pas les unes des autres, mettez-les à jour séparément. Par exemple, une ressource FHIR peut ne pas dépendre de la version spécifique d'une autre ressource du même bundle.
• Regroupez des groupes par lot et évitez les requêtes individuelles. Le traitement par lot peut améliorer les performances, mais les lots volumineux peuvent entraîner des erreurs et dégrader le débit de données. Les lots de lots de taille similaire ont moins de conflits, car ils ne sont pas verrouillés sur les mises à jour des ressources FHIR.

Les lots de petites transactions évitent les conflits, car ils ne comportent que quelques verrous à la fois et se terminent rapidement. Cela permet d'éviter l'accumulation de transactions empilées en attente.

Débit d'opération de longue durée

Consultez Débit des données de longue durée.

Options de stockage de données FHIR

Si votre volume de données FHIR est faible à modéré, utilisez fhir.create pour stocker des données. Pour stocker de grands volumes de ressources FHIR, utilisez fhir.executeBundle ou fhirStores.import. Pour en savoir plus sur chaque méthode, consultez la section Options d'importation FHIR.

Importer des ressources FHIR

Tenez compte des points suivants lorsque vous décidez d'utiliser l'importation FHIR:

• L'importation FHIR ne limite pas la taille totale des données importées. Si un groupe FHIR dépasse 50 Mo, vous pouvez importer les ressources FHIR dans Cloud Storage et les importer. Évitez les latences élevées ou les importations volumineuses, ou le débit de données risque d'être limité.

• L'importation FHIR est moins complexe que l'utilisation de bundles FHIR. Par exemple, vous n'avez pas besoin d'effectuer les opérations suivantes:

  • Diviser de grands groupes en plus petits
  • Gérer les planifications
  • Relancer les erreurs temporaires au niveau de la ressource ou du bundle

• L'importation FHIR n'applique pas l'intégrité référentielle. Pour en savoir plus, consultez la section Intégrité référentielle FHIR.

• N'utilisez pas l'importation FHIR lorsque la fraîcheur des données est une priorité élevée. Les importations peuvent être rapides, mais nécessiter plusieurs heures, voire plusieurs jours.

• Les importations FHIR fonctionnent mieux lorsque votre projet Google Cloud comporte peu d'opérations de longue durée.

• L'importation FHIR peut atteindre un débit de données élevé si votre application peut gérer les erreurs et les échecs en masse sur un sous-ensemble de ressources.

Utiliser des bundles FHIR

Utilisez des bundles FHIR au lieu de l'importation FHIR dans les cas suivants:

• La création d'un pipeline permettant de stocker et d'importer des données dans Cloud Storage coûte trop cher, en termes de coûts de facturation ou de bande passante réseau.

• L'intégrité référentielle doit être appliquée.

• La validation du profil FHIR doit être appliquée.

• Vous devez envoyer des notifications Pub/Sub lorsque des ressources FHIR sont stockées. L'importation FHIR n'est pas compatible avec les notifications Pub/Sub.

• La fraîcheur des données est une priorité. L'ingestion des données ne prend que quelques secondes ou minutes. Cependant, même dans un système bien structuré, le débit des données peut être limité par les éléments suivants:

  • Retards en amont dans le traitement des pipelines. Les pipelines peuvent avoir besoin de plus de temps pour préparer les données avant qu'elles ne puissent être ingérées.
  • Intervalles entre les tentatives, nouvelles tentatives et couches proxy de lissage du trafic

Les lots FHIR présentent les limites suivantes:

• Le quota et la facturation sont appliqués à chaque opération du groupe comme si chaque opération était exécutée indépendamment. Par exemple, si un lot comporte 10 opérations POST, 5 opérations GET et 1 opération DELETE, le quota et la facturation appliqués au groupe sont les mêmes que si ces opérations étaient exécutées indépendamment.

• Les groupes de transactions volumineux sont plus susceptibles de présenter des conflits de transactions qui entraînent des conflits de verrouillage. Pour en savoir plus, consultez Éviter les erreurs 429 Resource Exhausted operation_too_costly.

• Les bundles de lots peuvent améliorer le débit des données, mais n'offrent pas de fonctionnalités de cohérence transactionnelle telles que l'intégrité référentielle.

• Les lots volumineux peuvent avoir un débit réduit. Pour en savoir plus, consultez la section Éviter les lots volumineux.

Options de stockage de données DICOM

Vous pouvez utiliser les méthodes suivantes pour obtenir un débit de données élevé lorsque vous envoyez des données d'un système d'archivage et de communication d'images (PACS) vers l'API Cloud Healthcare:

L'adaptateur DICOM de l'API Cloud Healthcare Open Source utilisant le protocole DIMSE (DICOM Message Service Element)

L'adaptateur optimise le débit de données lorsque vous synchronisez un PACS avec l'API Cloud Healthcare. Avant la synchronisation, exécutez des tests de performances et vérifiez que l'adaptateur peut maintenir un débit de données maximal.

Utilisez cet adaptateur si vous ne pouvez pas importer de fichiers DICOM dans Cloud Storage à l'aide du service de transfert de stockage ou d'une autre option de transfert. Par exemple, vous ne pouvez peut-être pas répondre aux exigences suivantes concernant le service de transfert de stockage:

• installer un système de fichiers sur chaque machine hébergeant des agents dans votre pool d'agents afin de récupérer des données sources ;
• Si vous transférez des données à intervalles réguliers plutôt qu'un chargement par lot unique, vous devez mesurer l'évolution de la taille des données au fil du temps pour déterminer ce qui a changé.
• Maximisez les performances de transfert d'agent.
• Payer et attribuer du stockage Cloud Storage
• Valider des transferts de données vers Cloud Storage
• supprimer des ressources Cloud Storage après avoir importé des données dans l'API Cloud Healthcare et corriger les éventuelles erreurs d'importation.
• Planification d'intervalles d'ingestion par lots en fonction du réseau et de la capacité de stockage d'un système clinique

Nous vous recommandons d'utiliser le service de transfert de stockage pour un chargement par lot unique afin de remplir un magasin DICOM. L'utilisation du service de transfert de stockage nécessite régulièrement des tâches supplémentaires, comme l'utilisation d'un pipeline d'importation synchrone. Pour en savoir plus, consultez la page Détails du transfert du système de fichiers via le service de transfert de stockage.

dicomStores.import

Utilisez cette méthode pour stocker d'importants volumes de données DICOM.

Transaction de magasin DICOMweb

Utilisez cette méthode pour stocker des données DICOM par programmation.

Gérer le quota pour optimiser le débit des données

Les sections suivantes décrivent comment gérer et planifier les quotas pour optimiser le débit des données. Pour connaître les bonnes pratiques générales en matière de gestion des quotas, consultez la page Bonnes pratiques en matière de gestion des quotas.

Planifier des quotas pour un trafic prévisible

Planifiez vos exigences de quota en analysant d'abord le trafic quotidien typique de votre application cliente. Même si le trafic est prévisible, prévoyez plus de quota que nécessaire en moyenne. Cela vous permet d'éviter les erreurs et offre une marge de sécurité contre les pics de trafic ou les augmentations occasionnelles de l'utilisation quotidienne.

Le schéma suivant montre les requêtes adressées à l'API Cloud Healthcare dont la taille est cohérente et qui sont envoyées selon des modèles prévisibles:

Figure 1. Charge d'API agrégée par heure sur les ensembles de données et les datastores d'un projet Google Cloud.

Planifier un quota pour les requêtes volumineuses

Évitez de planifier des jobs par lot volumineux pendant les heures de pointe. Pour en savoir plus, consultez la section Favoriser les transactions à faible volume de manière régulière.

Le schéma suivant illustre un modèle de trafic prévisible. Toutefois, une requête par lot portant sur un volume important lors d'une période de pic de trafic dépasse le quota disponible. Cela peut entraîner des erreurs 429 Resource Exhausted pour toutes les requêtes de votre projet.

Figure 2. Répartition irrégulière de l'utilisation des ressources causée par une job par lot volumineuse pendant les heures de pointe

Si votre système dispose d'un quota de flexibilité supplémentaire, de petits pics de trafic ne provoquent pas d'erreurs ni n'entraînent d'erreurs de pic de charges prévisibles. Les petits pics doivent être répartis entre de nombreux datastores, applications et autres clients produisant une charge dans le projet Google Cloud.

Pour éviter qu'une seule job par lot volumineuse ne provoque des pics de trafic, consultez la section Éviter les groupes volumineux.

Demander un quota supplémentaire

Pour maintenir un débit de données élevé et éviter les erreurs 429 Resource Exhausted, consultez les bonnes pratiques de cette page, en particulier Gérer le quota pour optimiser le débit de données. Ces bonnes pratiques garantissent que votre application cliente est robuste et qu'elle peut s'adapter aux changements du volume de requêtes. Demander des quotas supplémentaires sans appliquer les bonnes pratiques a peu de chances d'éviter des erreurs à long terme.

Si vous mettez en œuvre les bonnes pratiques et que vous avez toujours besoin de quotas supplémentaires, consultez la section Bonnes pratiques pour demander des quotas supplémentaires.

Ressources de débit d'ingestion de données

Pour en savoir plus sur le débit d'ingestion de données, consultez la page Gérer le trafic et la charge de vos charges de travail dans Google Cloud.