Migrer des environnements depuis IoT Core

Last reviewed 2023-02-01 UTC

Google a annoncé l'abandon d'IoT Core. Ce document est destiné à vous aider à concevoir et à implémenter un plan de migration d'un environnement basé sur IoT Core vers un nouvel environnement qui ne dépend pas d'IoT Core pour les cas d'utilisation suivants :

  • Authentification des appareils de périphérie
  • Gestion des appareils de périphérie
  • Communication entre vos appareils de périphérie et Google Cloud

Ce document fournit également des conseils si vous souhaitez étudier l'opportunité d'effectuer une migration après l'abandon d'IoT Core et découvrir à quoi pourrait ressembler une migration.

Ce document fait partie d'une série de documents qui fournissent des informations sur les architectures IoT sur Google Cloud et la migration depuis IoT Core. Cette série comprend également les documents suivants :

Charges de travail à migrer

Ce document suppose que les charges de travail que vous souhaitez migrer depuis IoT Core comprennent les éléments suivants :

  • Partie qui s'exécute sur les appareils de périphérie (déployés aux arêtes de votre environnement et à proximité des données que vous souhaitez traiter)
  • Un backend qui s'exécute sur Google Cloud

Le schéma suivant montre l'architecture d'une charge de travail type utilisant IoT Core. Dans cette architecture, Cloud IoT intègre des appareils de périphérie dotés d'un backend qui s'exécute sur Google Cloud.

Flux d'événements provenant d'appareils de périphérie vers Cloud IoT (résumé dans le texte suivant)

Le diagramme précédent peut être résumé comme suit :

Pour planifier efficacement votre migration, nous vous recommandons d'effectuer une évaluation afin de mieux comprendre votre architecture d'environnement source. Dans ce cas, l'environnement source fait référence à votre environnement actuel basé sur IoT Core.

Ce document suppose que vous pouvez mettre à jour la configuration et les composants logiciels exécutés sur vos appareils de périphérie pour votre migration. Dans certains cas, cette approche n'est pas envisageable. Par exemple, vos appareils de périphérie ou vos processus de déploiement peuvent ne pas être compatibles avec ce cas d'utilisation. Dans ce cas, nous vous recommandons de supprimer les appareils de périphérie non compatibles avec les mises à jour. Pour en savoir plus sur la conception et l'implémentation de processus automatisés de provisionnement et de configuration pour les appareils de périphérie, consultez la page Bonnes pratiques pour le provisionnement et la configuration automatiques des systèmes et serveurs de périphérie et sur solution Bare Metal.

Concevoir la migration

Pour migrer votre environnement basé sur IoT Core, nous vous recommandons de suivre le framework de migration décrit dans la page Migration vers Google Cloud.

Le schéma suivant montre le parcours de votre migration.

Chemin de migration en quatre phases

Comme le montre le schéma précédent, ce parcours comporte quatre phases :

  1. Évaluation : au cours de cette phase, vous évaluez votre environnement source, vous déterminez les charges de travail et les appareils de périphérie que vous souhaitez migrer depuis Cloud IoT Core.
  2. Plan : au cours de cette phase, vous créez l'infrastructure de base sur Google Cloud, telle que la gestion de la hiérarchie des ressources et la configuration de l'accès au réseau.
  3. Déploiement : au cours de cette phase, vous déployez la nouvelle solution destinée à remplacer IoT Core, puis vous migrez vos appareils de périphérie vers la nouvelle solution.
  4. Optimisation : au cours de cette phase, vous optimisez votre environnement cible. Dans ce cas, l'environnement cible fait référence à l'environnement vers lequel vous effectuez la migration, qui n'est pas basé sur IoT Core.

Évaluer l'environnement source et les charges de travail

Au cours de la phase d'évaluation, vous rassemblez des informations sur votre environnement source, sur les appareils de périphérie et sur l'utilisation d'IoT Core dans votre organisation. Ces informations vous aident à concevoir un plan de migration et à vous assurer que vous disposez des ressources nécessaires pour la migration et pour votre environnement cible.

Lors de la phase d'évaluation, vous effectuez les opérations suivantes :

  1. Dresser l'inventaire des appareils de périphérie que vous avez enregistrés dans Cloud IoT Core
  2. Dresser l'inventaire des charges de travail de backend qui s'intègrent à Cloud IoT Core
  3. Catégoriser vos appareils de périphérie et vos charges de travail de backend
  4. Tester les produits et concevoir des démonstrations de faisabilité
  5. Calculer le coût total de possession
  6. Concevoir l'architecture de l'environnement cible
  7. Choisir les appareils de périphérie et les charges de travail de backend à migrer en premier

À la fin de la phase d'évaluation, vous disposez de deux inventaires : un inventaire de vos appareils de périphérie et un inventaire de vos charges de travail de backend.

Pour éviter les incohérences, nous vous recommandons de suspendre le déploiement des nouveaux appareils de périphérie et des charges de travail de backend avant de créer ces inventaires. Nous vous recommandons également de ne pas déployer de nouveaux appareils de périphérie et charges de travail en arrière-plan après avoir créé les inventaires.

Dresser l'inventaire de vos appareils de périphérie

Pour définir la portée de votre migration et concevoir votre plan de migration, vous devez connaître le nombre d'appareils de périphérie qui existent dans votre environnement source. Vous devez également comprendre comment les appareils interagissent avec IoT Core et, si vous pouvez les classer selon des caractéristiques courantes, par comportement, par but ou par dépendances.

Chaque appareil de périphérie que vous enregistrez dans IoT Core appartient à un registre IoT Core. La première étape de la création de l'inventaire de vos appareils de périphérie consiste à répertorier les registres IoT Core que vous avez créés. Vous collectez ensuite des informations sur les appareils de périphérie enregistrés dans chaque registre.

Pour créer l'inventaire de vos appareils de périphérie, tenez compte des informations suivantes sur chaque appareil de périphérie et découvrez comment l'appareil s'intègre à IoT Core :

  • Identifiants : rassemblez les informations suivantes sur les identifiants IoT Core des appareils de périphérie :

    • Identifiant défini par l'utilisateur
    • Identifiant non modifiable par le serveur et généré automatiquement par IoT Core lorsque vous enregistrez un appareil de périphérie dans IoT Core.
    • Nom de ressource qui identifie de manière unique l'appareil de périphérie à l'aide de l'identifiant du registre IoT Core sur lequel vous avez enregistré l'appareil de périphérie.

  • État du déploiement : évaluez l'état de déploiement actuel des appareils de périphérie. Par exemple, l'appareil de périphérie peut se trouver dans l'un des états suivants :

    • Pas encore fabriqué ou en cours de fabrication
    • Prêt à être déployé, mais pas encore enregistré dans IoT Core
    • Déjà déployé sur le site de destination et enregistré dans IoT Core

  • Type d'appareil IoT Core : évaluez le type d'appareil IoT Core. Chaque appareil de périphérie que vous enregistrez dans IoT Core peut agir de l'une des deux manières suivantes : Il peut s'agir d'un client qui se connecte directement à IoT Core. Il peut également s'agir d'une passerelle pour les clients que vous ne pouvez pas ou ne souhaitez pas connecter directement à IoT Core.

  • Protocole de communication : IoT Core accepte deux protocoles pour communiquer avec les appareils de périphérie : HTTP et MQTT. Déterminez le protocole utilisé par vos appareils de périphérie pour communiquer avec IoT Core. Pour le protocole MQTT, vous devez également déterminer la qualité de service sur laquelle reposent vos appareils de périphérie et vos charges de travail de backend.

  • Identifiants : IoT Core authentifie les appareils de périphérie à l'aide d'une paire de clés et de jetons de courte durée générés à l'aide de cette paire de clés. Il peut éventuellement vérifier la signature de la partie publique de la paire de clés à l'aide d'une méthode de validation basée sur un certificat. Évaluez la configuration de l'authentification des appareils de périphérie. Vérifiez si vous utilisez le mécanisme de validation basé sur un certificat pour le registre IoT Core auquel l'appareil appartient.

  • Métadonnées des appareils : dans IoT Core, vous pouvez définir des métadonnées pour chaque appareil de périphérie, sous la forme de paires clé/valeur. Par exemple, vous pouvez définir une empreinte matérielle, un numéro de série, des informations sur le fabricant ou tout autre attribut pertinent pour un appareil de périphérie. Vous pouvez définir des métadonnées lorsque vous ajoutez un appareil de périphérie à un registre IoT Core ou lorsque vous modifiez un appareil de périphérie déjà présent dans un registre. Les métadonnées ne sont jamais envoyées vers ou depuis un appareil de périphérie via IoT Core. Collectez les informations sur les métadonnées que vous avez définies pour l'appareil de périphérie.

  • État des appareils : dans IoT Core, chaque appareil de périphérie peut signaler des informations sur son état en tant que données structurées ou non structurées arbitraires. Par exemple, un appareil de périphérie peut signaler la version du micrologiciel en cours d'exécution. Il peut également signaler des informations sur son état, en fonction de métriques spécifiques. IoT Core publie les informations reçues sur l'état des appareils en tant que messages dans un sujet Pub/Sub que vous configurez. Évaluez la manière dont votre appareil de périphérie signale les informations sur son état et sur quels sujets Pub/Sub IoT Core publie ces messages. Déterminez les composants de votre architecture qui s'appuient sur les informations d'état des appareils de périphérie.

  • Événements de télémétrie : chaque appareil de périphérie que vous ajoutez à un registre IoT Core peut envoyer des événements de télémétrie sous forme de données structurées ou non structurées à IoT Core. IoT Core publie les événements de télémétrie reçus sous forme de messages dans un sujet Pub/Sub que vous configurez. Évaluez la manière dont votre appareil de périphérie signale les événements de télémétrie et les sujets Pub/Sub dans lesquels IoT Core publie ces messages. Déterminez les composants de votre architecture qui reposent sur les événements de télémétrie signalés par l'appareil de périphérie.

  • Configuration des appareils : dans IoT Core, vous pouvez définir la configuration d'un appareil de périphérie comme des données structurées ou non structurées arbitraires. IoT Core vous permet également de définir des mises à jour de la configuration d'un appareil en tant que nouvelles versions de cette configuration, qui seront ensuite transférées vers l'appareil de périphérie. Déterminez si l'appareil de périphérie reçoit la configuration de Cloud IoT Core et collectez des informations sur toutes les versions de configuration que vous avez définies.

  • Commandes : dans IoT Core, les appareils de périphérie peuvent recevoir des commandes d'IoT Core, puis réagir en conséquence. Déterminez si vos appareils de périphérie sont compatibles avec les commandes provenant d'IoT Core.

  • Mises à jour logicielles et de configuration : lors de la migration, vous devrez peut-être mettre à jour les composants logiciels exécutés sur l'appareil de périphérie ou la configuration de ces composants. Évaluez les mécanismes de mise à jour compatibles avec votre appareil de périphérie. Déterminez si l'appareil est également compatible avec un mécanisme de rollback afin de rétablir un état de fonctionnement connu en cas de problème lors de ces mises à jour.

  • Temps d'arrêt : pendant la migration, les charges de travail de backend ou d'autres parties de l'environnement source peuvent être indisponibles. Déterminez si votre appareil de périphérie prend en charge les temps d'arrêt, ses mécanismes de remplacement et la manière dont il récupère après les temps d'arrêt.

Dresser l'inventaire de vos charges de travail de backend s'intégrant à IoT Core

Après avoir créé l'inventaire de vos appareils de périphérie, vous rassemblez des informations sur les charges de travail de backend dans votre environnement source qui s'intègrent à Cloud IoT Core. Une charge de travail de backend peut s'intégrer à IoT Core de différentes manières :

  • En envoyant des commandes aux appareils de périphérie et en mettant à jour la configuration de vos appareils de périphérie à l'aide d'IoT Core
  • En s'abonnant aux sujets Pub/Sub sur lesquels IoT Core publie des messages sur les événements de télémétrie et l'état des appareils de périphérie
  • En s'intégrant aux API IoT Core directement ou en utilisant un outil de provisionnement de l'infrastructure. Par exemple, vous utilisez peut-être Terraform pour provisionner des registres et des appareils IoT Core.

Pour créer l'inventaire des charges de travail de backend qui s'intègrent à Cloud IoT Core, tenez compte des points suivants pour chaque charge de travail de backend :

  • Commandes et configuration des appareils : déterminez si la charge de travail de backend envoie des commandes aux appareils de périphérie et si elle met à jour leur configuration. Ces deux actions nécessitent une intégration avec les API IoT Core.
  • Événements de télémétrie et état des appareils : déterminez si la charge de travail de backend s'abonne aux sujets Pub/Sub où IoT Core publie des messages sur les événements de télémétrie et l'état des appareils.

  • Intégration à d'autres API IoT Core : déterminez si la charge de travail de backend interagit avec d'autres API IoT Core, en plus de celles permettant d'envoyer des commandes et de mettre à jour les configurations d'appareil. Par exemple, votre charge de travail de backend peut s'appuyer sur les API IoT Core pour effectuer les opérations suivantes :

    • Créer des registres IoT Core et mettre à jour leur configuration
    • Créer des appareils IoT Core et mettre à jour leur configuration
    • Collecter des informations sur les registres et les appareils IoT Core
    • Utiliser les métriques de journalisation IoT Core et les journaux d'activité des appareils

Catégoriser vos appareils de périphérie et vos charges de travail de backend

Après avoir créé les inventaires de vos appareils de périphérie et de vos charges de travail de backend, vous pouvez classer les éléments de chaque inventaire en fonction de leurs caractéristiques. Cette catégorisation vous aide à élaborer votre plan de migration et à choisir les appareils de périphérie et les charges de travail de backend à migrer en premier.

Pour classer vos appareils de périphérie, nous vous recommandons une classification basée sur les types d'interactions pouvant survenir entre les appareils de périphérie et les charges de travail de backend. Voici quelques exemples d'interactions :

  • Lorsqu'un appareil de périphérie envoie des données aux charges de travail de backend à l'aide d'événements de télémétrie ou d'informations sur l'état des appareils.
  • Lorsque les charges de travail backend envoient des instructions aux appareils de périphérie en utilisant des commandes ou des mises à jour de configuration d'appareils.

Pour chacun des types d'interactions précédents, les types de messages échangés lors de ces interactions sont différents. Toutefois, les messages ont des objectifs similaires. Certains appareils envoient des données d'un appareil de périphérie à des charges de travail de backend, telles que des événements de télémétrie et des informations sur l'état des appareils. Certains appareils envoient des instructions aux charges de travail de backend vers des appareils de périphérie, telles que des commandes et des mises à jour de configuration.

En fonction des types d'interactions proposés, nous vous recommandons les catégories suivantes pour vos appareils de périphérie :

  • Transmission uniquement : appareils de périphérie qui envoient des événements de télémétrie ou des informations sur l'état des appareils, mais ne reçoivent pas de commandes ni de mises à jour de configuration d'appareils de la part des charges de travail de backend.
  • Réception uniquement : appareils de périphérie qui n'envoient pas d'événements de télémétrie ni d'informations sur l'état des appareils, mais reçoivent des commandes ou des mises à jour de configuration d'appareils depuis des charges de travail de backend.
  • Réception et transmission : appareils de périphérie qui envoient des événements de télémétrie et des informations sur l'état des appareils, et reçoivent des commandes ou des mises à jour de configuration d'appareils depuis des charges de travail de backend.

Pour classer vos charges de travail de backend, vous pouvez suivre une approche semblable à celle que vous avez suivie pour classer les appareils de périphérie. En fonction des types d'interactions proposés, nous vous recommandons les catégories suivantes pour vos charges de travail de backend :

  • Réception uniquement : charges de travail de backend qui reçoivent des événements de télémétrie ou des informations sur l'état des appareils des appareils de périphérie, mais n'envoient pas de commandes ou de mises à jour de configuration d'appareils.
  • Envoi uniquement : charges de travail de backend qui ne reçoivent pas d'événements de télémétrie ni d'informations sur l'état des appareils, mais envoient des commandes ou des mises à jour de configuration d'appareils.
  • Envoi et réception : charges de travail backend qui reçoivent des événements de télémétrie ou des informations sur l'état des appareils des appareils de périphérie, et envoient des commandes ou des mises à jour de configuration des appareils.

Terminer l'évaluation

Après avoir créé les inventaires, vous devez effectuer les étapes suivantes de la phase d'évaluation :

Après avoir effectué ces activités, poursuivez la lecture de ce document.

Concevoir l'architecture de l'environnement cible

Après avoir effectué les activités d'évaluation précédentes, vous concevez l'architecture pour l'environnement cible.

Ce document porte sur la migration de l'environnement source vers l'environnement cible. Toutefois, la migration de votre environnement depuis IoT Core vous permet également de planifier de nouvelles fonctionnalités et mises à jour. Lorsque vous concevez l'architecture de l'environnement cible, tenez compte des limitations que vous avez pu rencontrer dans l'environnement source. Réfléchissez à la manière dont vous souhaitez configurer l'environnement cible pour éviter ces limitations. Vous pouvez également envisager de nouvelles fonctionnalités dont vous pourriez avoir besoin dans l'environnement cible.

Selon la classification de vos appareils de périphérie et de vos charges de travail de backend, les cas d'utilisation complémentaires suivants d'IoT Core issus de l'évaluation de l'environnement source peuvent s'afficher :

  • Ingestion de données provenant d'appareils de périphérie dans un backend exécuté sur Google Cloud
  • Exécuter des charges de travail de backend de gestion d'appareils de périphériesur Google Cloud

Pour réduire la complexité de votre migration, nous vous recommandons de vous concentrer sur les cas d'utilisation issus de l'évaluation de votre environnement source. Par exemple, si vous ingérez des données provenant d'appareils de périphérie, mais que vous n'utilisez aucune des fonctionnalités de gestion d'appareils IoT Core, nous vous conseillons de vous concentrer sur la conception de l'environnement cible. Cette approche vous permet de ne cibler que le cas d'utilisation de l'ingestion de données, sans avoir à vous préoccuper du cas d'utilisation de la gestion des appareils.

La conception de l'environnement cible peut varier en fonction des cas d'utilisation Cloud IoT Core que vous avez implémentés dans l'environnement source et de la manière dont vous souhaitez les mettre en œuvre dans l'environnement cible. Vous devez prendre en compte les facteurs suivants :

  • Si vous avez implémenté les deux cas d'utilisation dans l'environnement source, vous pouvez concevoir l'environnement cible de façon à les mettre en œuvre avec une seule solution. Vous pouvez également implémenter les deux cas d'utilisation séparément à l'aide de solutions distinctes.
  • Si vous implémentez un seul des deux cas d'utilisation dans l'environnement source, vous pouvez concevoir l'environnement cible pour mettre en œuvre ce cas d'utilisation avec une seule solution.

Le schéma suivant montre une série d'exemples de questions à prendre en compte lorsque vous décidez de concevoir l'architecture de l'environnement cible.

Les exemples de questions sont présentés dans le texte suivant.

Le diagramme précédent peut être résumé comme suit :

  • Avez-vous besoin d'ingérer des données à partir d'appareils de périphérie et de gérer des appareils de périphérie ?

    • Si c'est le cas, passez à la question suivante.
    • Sinon, passez aux questions sur le cas d'utilisation de la gestion d'appareils de périphérie.

  • Avez-vous besoin d'une seule solution pour implémenter les deux cas d'utilisation de l'ingestion de données et de la gestion d'appareils de périphérie ?

    • Si oui, déployez une solution pour l'ingestion de données et la gestion d'appareils de périphérie sur Google Cloud.
    • Sinon, déployez une solution de gestion d'appareils de périphérie sur Google Cloud, puis passez aux questions d'évaluation du cas d'utilisation de l'ingestion de données.

  • Avez-vous besoin de gérer les appareils de périphérie ?

    • Si oui, déployez une solution de gestion d'appareils de périphérie sur Google Cloud, puis passez aux questions d'évaluation du cas d'utilisation de l'ingestion de données.
    • Sinon, passez aux questions d'évaluation du cas d'utilisation de l'ingestion de données.

  • Avez-vous besoin d'ingérer des données provenant d'appareils de périphérie ?

    • Si c'est le cas, passez à la question suivante.
    • Sinon, soit vous avez effectué la migration, soit vous n'avez pas besoin de migrer votre environnement source. Dans les deux cas, vous pouvez mettre hors service l'environnement source.

  • Quel est le protocole de communication préféré ?

    • Si MQTT, déployez un agent MQTT sur Google Cloud.
    • Si HTTP ou gRPC, ingérez les données provenant d'appareils de périphérie à l'aide de Pub/Sub.
    • Sinon, évaluez les solutions d'ingestion de données compatibles avec vos protocoles de communication préférés.

Lors de la conception de l'architecture de l'environnement cible, tenez compte des points suivants :

  • La gestion de n'importe quel composant de l'architecture nécessite des connaissances et des efforts. Nous vous recommandons d'évaluer le nombre de ressources supplémentaires que vous devez prendre en compte pour l'environnement cible.
  • Le provisionnement de nombreux appareils de périphérie pose des problèmes de sécurité, d'évolutivité et d'exploitation. Pour en savoir plus sur le provisionnement des appareils de périphérie, consultez les bonnes pratiques pour le provisionnement et la configuration automatiques des systèmes et serveurs de périphérie et sur solution Bare Metal.
  • L'utilisation de Pub/Sub pour ingérer les données de vos appareils de périphérie vous évite d'avoir à gérer et faire évoluer une plate-forme de messagerie distribuée. Si vous utilisez Pub/Sub pour ingérer des données provenant de vos appareils de périphérie, pensez aux quotas et limites de Pub/Sub, en particulier si vous devez ingérer des données provenant de nombreux appareils.

  • Pour authentifier vos appareils de périphérie dans l'environnement cible et gérer leurs identités, nous vous recommandons d'évaluer les méthodes d'authentification et les stockages d'identifiants compatibles avec l'environnement cible. Comparez-les à celles que vous utilisez avec IoT Core dans l'environnement source.

    Une fois que vous avez recueilli ces informations, nous vous recommandons de suivre les instructions du guide de sécurité du backend IoT afin de concevoir et d'implémenter un mécanisme d'authentification et de gestion des identités pour vos appareils de périphérie.

Choisir les appareils de périphérie et les charges de travail de backend à migrer en premier

Après avoir conçu l'architecture de l'environnement cible, définissez les éléments suivants :

  1. Les catégories d'appareils de périphérie et de charges de travail de backend à migrer en premier.
  2. Les lots de migration (groupes d'éléments à migrer de l'environnement source vers l'environnement cible).

Définir les catégories d'appareils de périphérie à migrer en premier

Les catégories d'appareils de périphérie et de charges de travail de backend peuvent présenter différents défis et difficultés pour la migration. La migration d'appareils de périphérie de transmission uniquement peut ainsi être plus simple que la migration d'appareils de périphérie de réception et de transmission.

Pour mieux comprendre comment choisir les catégories d'appareils de périphérie et de charges de travail de backend à migrer en premier, consultez la page Choisir les applications à migrer en premier.

Cette section récapitule les considérations à prendre en compte pour chaque catégorie d'appareils de périphérie lorsque vous déterminez lesquels migrer en premier.

Appareils de périphérie de transmission uniquement

Ces appareils de périphérie envoient des événements de télémétrie et des informations sur l'état des appareils à l'aide de MQTT ou de HTTP.

Si les appareils utilisent MQTT, vous n'aurez peut-être besoin de mettre à jour leur configuration que pour la connexion à l'agent MQTT et l'authentification auprès de celui-ci dans votre environnement cible. Vous pouvez continuer à publier des événements de télémétrie et des informations sur l'état des appareils via l'agent MQTT dans l'environnement cible. Dans certains cas, il se peut que vous ne disposiez pas d'un agent MQTT dans votre environnement cible et que vous deviez migrer vers un autre type d'environnement cible, par exemple une solution tierce. Dans ce cas, vous devez évaluer les fonctionnalités et les interfaces d'intégration fournies par la solution. Vous pouvez ensuite concevoir et implémenter un plan de migration approprié.

Si les appareils utilisent HTTP, vous devrez peut-être mettre à jour leur configuration pour vous connecter et vous authentifier auprès de l'environnement cible. Vous devrez peut-être également refactoriser la sémantique de la communication entre les appareils pour tenir compte des différences dans votre environnement cible par rapport à l'utilisation des API IoT Core. Par exemple, si vous utilisez Pub/Sub dans l'environnement cible, vous pouvez passer de l'utilisation des API IoT Core pour publier des messages dans des sujets Pub/Sub à l'utilisation des API Pub/Sub pour le même objectif. Dans certains cas, vous n'utilisez peut-être pas Pub/Sub dans votre environnement cible. Vous devez donc migrer vers un autre type d'environnement cible, par exemple une solution tierce. Dans ce cas, vous devez évaluer les fonctionnalités et les interfaces d'intégration fournies par la solution tierce pour concevoir et implémenter un plan de migration approprié.

Appareils de périphérie de réception uniquement

Ces appareils de périphérie reçoivent des commandes à l'aide de MQTT et les mises à jour de configuration à l'aide de MQTT ou de HTTP. IoT Core n'est pas compatible avec HTTP pour l'envoi de commandes.

Si les appareils reçoivent des commandes et des mises à jour de configuration à l'aide de MQTT, des considérations semblables aux précédentes concernant les catégories d'appareils de périphérie s'appliquent. Pour migrer cette catégorie d'appareils de périphérie, mettez à jour la configuration des appareils de périphérie pour la connexion à l'agent MQTT et l'authentification auprès de celui-ci dans votre environnement cible. Vous continuez à vous abonner aux sujets MQTT où IoT Core publie des commandes et des mises à jour de configuration d'appareils. Dans certains cas, il se peut que vous ne disposiez pas d'un agent MQTT dans votre environnement cible et que vous deviez migrer vers un autre type d'environnement cible, par exemple une solution tierce. Dans ce cas, vous devez évaluer les fonctionnalités et les interfaces d'intégration fournies par la solution pour concevoir et implémenter un plan de migration approprié.

Si les appareils reçoivent des mises à jour de configuration via HTTP, des considérations semblables aux précédentes concernant les catégorie d'appareils de périphérie s'appliquent. Pour migrer cette catégorie d'appareils de périphérie, vous devrez peut-être mettre à jour leur configuration pour la connexion à l'environnement cible et l'authentification auprès de celui-ci. Pour recevoir les mises à jour de configuration, vous devrez peut-être refactoriser la sémantique de la communication pour tenir compte des différences dans votre environnement cible par rapport aux API IoT Core. Par exemple, si vous migrez vers un type d'environnement cible différent, tel qu'une solution tierce, vous devez évaluer les fonctionnalités et les interfaces d'intégration fournies par la solution pour concevoir et implémenter un plan de migration adapté

Appareils de périphérie de transmission et réception

Ces appareils de périphérie peuvent être les plus difficiles à migrer, car ils sont à la fois des consommateurs de données provenant de charges de travail de backend et des producteurs de données que les appareils de périphérie reçoivent. Dans ce cas, les considérations concernant la migration des catégories d'appareils de périphérie décrites ci-dessus s'appliquent. Vous devez donc être particulièrement vigilant pour gérer la migration de cette catégorie de charge de travail de backend.

Après avoir choisi les catégories d'appareils de périphérie à migrer en premier, choisissez les catégories de charges de travail de backend à migrer en premier.

Charges de travail de backend de réception uniquement

Ces charges de travail de backend sont découplées des appareils de périphérie qui produisent des événements de télémétrie ou des informations sur l'état des appareils. Par conséquent, leur migration peut être assez simple pour les raisons suivantes :

  • Les charges de travail de backend s'abonnent aux sujets Pub/Sub. Les appareils n'ont donc pas besoin de connaître les producteurs de ces informations afin de les utiliser. Normalement, vous n'aurez pas à mettre à jour la configuration du logiciel exécuté sur vos appareils de périphérie.
  • Les charges de travail de backend n'envoient pas de commandes ni de mises à jour de configuration d'appareils aux appareils de périphérie. Par conséquent, vous n'avez pas besoin de prendre en compte ce cas d'utilisation lors de la migration de ces charges de travail de backend.
  • Vous pouvez conserver les sujets Pub/Sub existants pour publier ou consulter des messages. Dans ce cas, vos charges de travail de backend peuvent rester abonnées aux sujets Pub/Sub existants si votre environnement cible continue de transférer des événements de télémétrie et des informations sur l'état des appareils à ces sujets Pub/Sub.

Charges de travail de backend d'envoi uniquement

Ces charges de travail de backend nécessitent une évaluation complète pour comprendre comment elles interagissent avec les appareils de périphérie lors de l'envoi de commandes et de mises à jour de configuration d'appareils, et comment les migrer vers l'environnement cible. Par exemple, si vous migrez vers un environnement cible avec un agent MQTT, ces charges de travail de backend peuvent migrer depuis les API IoT Core pour envoyer des commandes ou des mises à jour de configuration d'appareils pour publier des messages via MQTT. Dans certains cas, vous ne devriez pas avoir besoin d'effectuer une mise à jour logicielle ou de configuration sur vos appareils de périphérie. Par exemple, si les charges de travail de backend publient des commandes et des mises à jour de configuration au même format et dans les mêmes sujets MQTT où IoT Core publie des messages concernant les commandes et les mises à jour de configuration d'appareils dans votre environnement source. Si vous migrez vers un type d'environnement cible différent, tel qu'une solution tierce, vous devez évaluer les capacités et les interfaces d'intégration fournies par la solution pour concevoir et implémenter un plan de migration approprié.

Charges de travail de backend d'envoi et de réception

Ces charges de travail de backend peuvent être les plus difficiles à migrer, car elles sont à la fois des consommateurs de données provenant d'appareils de périphérie et des producteurs de données que les appareils de périphérie reçoivent. Dans ce cas, les catégories de charges de travail de backend décrites ci-dessus s'appliquent. Vous devez donc être particulièrement vigilant pour gérer la migration de cette catégorie de charges de travail de backend.

Définir des lots de migration

Pour réduire les risques et la complexité de la migration d'un grand nombre d'éléments dans un seul lot, vous devez diviser les éléments à migrer de chaque catégorie par lots de migration. Pour planifier des lots de migration, procédez comme suit :

  1. Concevoir des lots de migration en regroupant des éléments homogènes : pour regrouper les éléments à migrer par lots, nous vous recommandons de choisir un ensemble de critères afin que les éléments d'un lot de migration partagent des caractéristiques communes. Par exemple, vous pouvez regrouper les appareils de périphérie par lots en fonction des éléments suivants :

    • La région de déploiement
    • Le registre IoT Core dans lequel les appareils sont enregistrés
    • La présence de métadonnées d'appareils IoT Core pertinentes définies
    • L'état du déploiement des appareils

  2. Choisir la taille de chaque lot de migration : pour chaque catégorie d'éléments à migrer, nous vous recommandons de planifier les premiers lots de migration de cette catégorie pour être relativement petits. Vous augmentez la taille des lots à mesure que vous gagnez en expérience et en dynamique lors de la migration.

  3. Déterminer si vos lots de migration nécessitent des stratégies ad hoc : en fonction de la manière dont vous avez regroupé les éléments à migrer par lots de migration, la stratégie de migration à appliquer pour un lot de migration donné peut dépendre des caractéristiques des éléments de ce lot. Par exemple, pour migrer des appareils de périphérie regroupés par état de déploiement, vous devez prendre en compte les éléments suivants :

    • Si vos appareils ne sont pas encore fabriqués ou sont en cours de fabrication, vous pouvez demander au fabricant de mettre à jour leur configuration et le logiciel pour les migrer vers l'environnement cible.
    • Si vos appareils sont prêts à être déployés, mais ne sont pas encore enregistrés dans IoT Core, vous pouvez demander au déployeur de rappeler ces appareils de périphérie. Vous pouvez ensuite mettre à jour leur configuration et le logiciel pour les migrer vers l'environnement cible.
    • Si vos appareils sont déjà déployés sur leur site de destination et enregistrés dans IoT Core, vous pouvez mettre à jour leur configuration et le logiciel pour les migrer vers l'environnement cible, à distance ou sur site.

Planifier et établir vos fondations

Au cours de la phase de planification et de création, vous provisionnez et configurez l'infrastructure et les services cloud compatibles avec vos charges de travail sur Google Cloud comme suit :

  1. Créez une hiérarchie de ressources.
  2. Configurez Identity and Access Management.
  3. Configurez la facturation.
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurez la surveillance et les alertes.

Pour obtenir des conseils sur la création de l'infrastructure et des services cloud compatibles avec vos charges de travail et leurs dépendances, consultez la page Migration vers Google Cloud : établir les fondations. Suivez ces consignes pour établir les bases de vos environnements. Vous passez ensuite aux activités décrites dans les sections suivantes de ce document.

Migrer les appareils de périphérie et les charges de travail de backend

Une fois les bases de votre environnement cible créées, vous devez effectuer les opérations suivantes pour migrer vos appareils de périphérie et vos charges de travail de backend vers l'environnement cible.

  1. Provisionner et configurer les ressources pour implémenter l'architecture de l'environnement cible : lors de la première étape du processus de migration, vous créez et configurez l'infrastructure de la nouvelle plate-forme.
  2. Migrer des appareils de périphérie et des charges de travail de backend vers l'environnement cible : après avoir vérifié que l'environnement cible est prêt, vous pouvez migrer les charges de travail et les appareils de backend vers l'environnement cible. En fonction de l'architecture de votre environnement cible et de vos cas d'utilisation, vous pouvez adopter différentes approches. Ce document traite d'une stratégie de migration en deux étapes qui permet à votre environnement source et cible de coexister pendant un certain temps. Cette approche signifie que si des échecs se produisent pendant la migration, vous pouvez effectuer un rollback vers l'environnement source.
  3. Mettre hors service l'environnement source : après avoir vérifié que l'environnement cible est entièrement opérationnel, vous pouvez le mettre hors service.

Provisionner et configurer les ressources pour l'architecture de l'environnement cible

Au cours de cette phase, vous provisionnez et configurez l'environnement cible. Comme décrit dans la section Concevoir l'architecture de l'environnement cible, l'architecture de l'environnement cible peut être résumée comme suit :

  • Agent MQTT exécuté sur Google Cloud : vous exécutez un agent MQTT sur Google Cloud et transférez des événements de télémétrie et des informations sur l'état des appareils de l'agent MQTT aux charges de travail de backend. Vos charges de travail de backend publient des commandes et des contrôles dans le sujet MQTT.
  • Pub/Sub : vos appareils de périphérie publient des événements de télémétrie et des informations sur l'état des appareils dans Pub/Sub et reçoivent des commandes de Pub/Sub.
  • Plate-forme tierce d'ingestion de données et de gestion des appareils : vous configurez une solution tierce pour les événements de télémétrie et des informations sur l'ingestion des appareils et la gestion des appareils.

Pour plus d'informations sur chaque architecture, consultez la documentation sur les architectures d'appareils connectés sur Google Cloud.

Migrer des appareils de périphérie et des charges de travail de backend vers l'environnement cible

Après avoir provisionné et configuré les ressources dans votre environnement cible, vous migrez les appareils de périphérie et les charges de travail de backend vers l'environnement cible. Dans cette section, vous migrez des appareils de périphérie et des charges de travail de backend de l'environnement source vers l'environnement cible. Les environnements source et cible coexistent jusqu'à la mise hors service de l'environnement source.

Pour réduire les temps d'arrêt, le processus de migration comprend les phases suivantes :

  1. Surveiller les environnements source et cible
  2. Migrer les informations sur les métadonnées des appareils de périphérie depuis l'environnement source vers l'environnement cible. Cela inclut les identifiants, la configuration et l'état des appareils.
  3. Mettre à jour les appareils de périphérie pour se connecter à la fois à l'environnement source et cible
  4. Migrer des charges de travail de backend de l'environnement source vers l'environnement cible
  5. Mettre à jour les appareils de périphérie pour se connecter uniquement à l'environnement source

Nous vous recommandons de surveiller à la fois l'environnement source et cible pendant chaque phase de migration, et de vérifier les résultats de chaque phase avant de passer à la suivante.

En plus de surveiller l'environnement, vous pouvez mettre en place des tests par boîte noire pour vérifier si l'environnement fonctionne comme prévu. Prenons l'exemple d'un cas d'utilisation dans lequel votre charge de travail de backend envoie une notification par e-mail aux opérateurs lorsqu'elle détecte un événement spécifique, tel qu'une température supérieure à 50 degrés Celsius. Vous pouvez créer un scénario de test contenant des données de télémétrie pour une température supérieure à 50 degrés Celsius, et vérifier si la charge de travail de backend envoie un e-mail aux opérateurs.

Surveiller les environnements source et cible

Pour surveiller les environnements source et cible, nous vous recommandons d'utiliser les métriques suivantes :

  • Nombre d'appareils actifs : nombre d'appareils ayant récemment envoyé des données à IoT Core.
  • Nombre d'erreurs de communication des appareils : nombre d'erreurs rencontrées par les charges de travail de backend lors de la communication avec les appareils de périphérie, regroupées par type d'erreur, au cours d'une période donnée. Cette métrique est utile pour comprendre si les charges de travail de backend rencontrent des problèmes de communication avec les appareils de périphérie.
  • Nombre d'opérations d'appareil : nombre d'opérations effectuées par des appareils de périphérie, telles que les requêtes de connexion ou de déconnexion, la publication de messages, regroupées par type d'opération, au cours d'une période donnée. Cette métrique vous aide à savoir si les appareils de périphérie fonctionnent comme prévu. Par exemple, si les valeurs du nombre d'erreurs d'appareils et du nombre d'opérations d'appareils augmentent, l'environnement peut rencontrer des problèmes d'envoi de messages aux appareils de périphérie.
  • Nombre d'octets reçus : nombre d'octets reçus des appareils de périphérie au cours d'une période donnée. Cette métrique vous aide à comprendre les statistiques du trafic réseau entrant.
  • Nombre d'octets envoyés : nombre d'octets envoyés vers les appareils de périphérie. Cette métrique vous aide à comprendre les statistiques de trafic réseau sortant.
  • Débit des messages : nombre de messages traités par les charges de travail de backend au cours d'une période donnée. Cette métrique vous aide à déterminer si l'environnement évolue en fonction du volume de trafic entre les appareils de périphérie et les charges de travail de backend. Par exemple, si le nombre d'appareils actifs et le nombre d'opérations d'appareils augmentent, mais que le débit des messages évolue peu, vous pouvez vérifier si les charges de travail backend disposent de ressources suffisantes pour gérer l'augmentation des messages.
  • Latence de distribution des messages : temps écoulé après la publication d'un message par un appareil de périphérie et avant qu'une charge de travail de backend ne le reçoive pour traitement. Par exemple, si la valeur de latence augmente, vous pouvez vérifier s'il existe des problèmes qui ralentissent la distribution des messages.
  • Messages non distribuables : nombre de messages ne pouvant pas être distribués aux appareils de périphérie et aux charges de travail de backend. Si vous ne transmettez pas de messages aux clients, les appareils de périphérie ou les charges de travail de backend risquent de ne pas répondre.
  • Utilisation des quotas de ressources cloud : surveillez l'utilisation des quotas de ressources cloud pour vous assurer que l'environnement dispose de suffisamment de ressources pour évoluer.
Surveiller l'environnement source

Cloud Monitoring collecte automatiquement des métriques à partir d'IoT Core et de Pub/Sub. Par exemple, IoT Core expose les métriques device/active_devices, device/error_count et device/operation_count. Ces données vous aident à comprendre combien d'appareils de périphérie sont connectés à l'environnement source, et combien d'appareils de périphérie font face à des erreurs de communication avec IoT Core. Les métriques device/received_bytes_count et device/sent_bytes_count vous permettent de surveiller la consommation de bande passante réseau.

Pour surveiller l'état et la distribution des messages, vous devez utiliser le langage MQL pour mesurer le score d'état de latence de distribution d'un abonnement, le débit des messages et les messages non distribuables.

Surveiller l'environnement cible

Vous surveillez l'environnement cible pour savoir si la migration a réussi. Selon l'architecture de l'environnement cible, l'agent MQTT ou la plate-forme IoT tierce peut fournir les métriques suivantes :

  • Agent MQTT : si l'environnement cible est basé sur un agent MQTT, il peut fournir des métriques sur les appareils de périphérie et la distribution des messages. Pour surveiller les octets envoyés et reçus, reportez-vous aux métriques fournies par Cloud Load Balancing. Si l'agent MQTT s'exécute sur un cluster GKE, vous pouvez configurer Cloud Monitoring pour définir les métriques envoyées à Monitoring. Si l'agent MQTT s'exécute sur une instance Compute Engine, vous pouvez utiliser le tableau de bord par défaut ou installer l'Agent Ops pour collecter la télémétrie détaillée à partir de l'instance Cloud Monitoring.

  • Pub/Sub : si l'environnement cible est basé sur Pub/Sub, vous utilisez des sujets et des abonnements Pub/Sub. Par exemple, vous pouvez utiliser le langage MQL (Monitoring Query Language) pour effectuer une requête permettant de récupérer le score d'état de latence de diffusion pour un abonnement, le débit des messages et les messages non distribuables.

  • Plate-forme IoT : si l'environnement cible est basé sur une plate-forme IoT, celle-ci peut fournir des informations sur les appareils de périphérie et la distribution des messages. Si la plate-forme IoT tierce s'exécute sur un cluster GKE, vous pouvez configurer Logging et Monitoring pour configurer les métriques envoyées à Cloud Monitoring. Si la plate-forme IoT tierce s'exécute sur une instance Cloud Monitoring, vous pouvez utiliser le tableau de bord par défaut ou installer l'agent Ops pour collecter la télémétrie détaillée à partir de l'instance Cloud Monitoring.

Migrer les informations de métadonnées des appareils de périphérie de l'environnement source vers l'environnement cible

Pour migrer vers la nouvelle plate-forme IoT, vous migrez les informations de métadonnées des appareils de périphérie vers l'environnement cible. Pour migrer les métadonnées d'appareils de périphérie, tenez compte des catégories de métadonnées suivantes :

  • Identifiants des appareils : IoT Core authentifie les appareils de périphérie à l'aide d'une paire de clés et de jetons de courte durée. Suivez les étapes requises de l'environnement cible pour enregistrer des appareils dans l'environnement cible et créer des identifiants d'appareils dans celui-ci en fonction de son mécanisme d'authentification.

  • Configuration des appareils : votre environnement cible peut être une plate-forme IoT tierce qui fournit un service de configuration d'appareils et votre cas d'utilisation nécessite de configurer les appareils de périphérie avec le dernier état souhaité. Dans ce cas, vous devez migrer la configuration des appareils vers l'environnement cible. Pendant la migration, assurez-vous que la configuration des appareils est synchronisée entre l'environnement source et l'environnement cible. Si votre environnement cible est basé sur un agent MQTT ou Pub/Sub et qu'il ne permet pas de gérer la configuration des appareils, vous pouvez stocker les configurations d'appareils dans des buckets Cloud Storage comme archivage à long terme.

  • Informations sur l'état des appareils : assurez-vous que les appareils de périphérie mettent à jour leur état lorsqu'ils se connectent à l'environnement cible pour la première fois, afin que celui-ci dispose des informations les plus récentes sur l'état des appareils.

Une fois cette étape terminée, vérifiez si les informations et les identifiants des appareils requis sont correctement configurés, et si des appareils de périphérie peuvent se connecter à l'environnement cible et s'authentifier auprès de celui-ci.

Mettre à jour des appareils de périphérie pour se connecter à la fois à l'environnement source et cible

Lorsque vous atteignez cette étape, votre environnement cible est prêt à accepter les connexions provenant d'appareils de périphérie. Vous pouvez mettre à jour les appareils de périphérie pour les connecter à la fois à l'environnement source et cible afin d'envoyer des événements de télémétrie et des informations sur l'état des appareils. Lors de la mise à jour des appareils de périphérie, l'approche à suivre dépend de la catégorie d'appareils de périphérie.

Pour les appareils de périphérie qui envoient des événements de télémétrie ou des informations sur l'état des appareils, mais ne reçoivent pas de commandes ou de mises à jour de configuration d'appareils provenant de charges de travail de backend, vous devez effectuer ce qui suit :

  1. Mettez à jour les appareils de périphérie pour qu'ils envoient des événements de télémétrie et des informations sur l'état des appareils à la fois à l'environnement source et à l'environnement cible.
  2. Vérifiez que l'environnement cible reçoit correctement les événements de télémétrie et les informations sur l'état des appareils.

Inversement, pour les appareils de périphérie qui n'envoient pas d'événements de télémétrie ni d'informations sur l'état des appareils, mais qui reçoivent des commandes ou des mises à jour de configuration provenant de charges de travail de backend, vous procédez comme suit :

  1. Mettez à jour les appareils de périphérie pour recevoir les commandes et les mises à jour de configuration de l'environnement cible.
  2. Assurez-vous que vos appareils de périphérie signalent le résultat des mises à jour d'exécution ou de configuration de commande à l'environnement cible.
  3. Envoyez une commande et une mise à jour de la configuration de l'environnement cible aux appareils de périphérie.
  4. Vérifiez que l'exécution de la commande et de la mise à jour de la configuration a réussi.

Pour les appareils de périphérie qui envoient à la fois des événements de télémétrie et des informations sur l'état des appareils et reçoivent également des commandes ou des mises à jour de configuration à partir de charges de travail de backend, procédez comme suit :

  1. Mettez à jour les appareils de périphérie pour qu'ils envoient des événements de télémétrie et des informations sur l'état des appareils à l'environnement source et cible.
  2. Vérifiez que l'environnement cible reçoit correctement les événements de télémétrie et les informations sur l'état des appareils.
  3. Mettez à jour les codes des appareils de périphérie pour recevoir les commandes et les mises à jour de configuration de l'environnement cible.
  4. Assurez-vous que vos appareils de périphérie signalent le résultat des mises à jour d'exécution ou de configuration de commande à l'environnement cible.
  5. Envoyez une commande et une mise à jour de la configuration de l'environnement cible aux appareils de périphérie.
  6. Vérifiez que l'exécution de la commande et de la mise à jour de la configuration a réussi.

Une fois ces étapes effectuées pour votre cas d'utilisation, les appareils de périphérie de toutes les catélgories effectuent les opérations suivantes :

  • Se connectent à l'environnement source et cible.
  • Envoient des événements de télémétrie et des informations sur l'état des appareils à la fois à l'environnement source et à l'environnement cible.
  • Reçoivent des commandes et des mises à jour de configuration depuis l'environnement source uniquement parce que vous n'avez pas encore migré les charges de travail de backend.

Il est préférable d'éviter un scénario dans lequel les charges de travail de backend traitent le même message que les appareils de périphérie qui envoient à la fois aux environnements sources et cibles. Nous vous recommandons de configurer la durée de conservation des messages dans l'environnement cible à la valeur minimale possible. Cette approche vous permet de vérifier que l'environnement cible fonctionne comme prévu. Elle vous permet également de vérifier que les messages de l'environnement cible expirent avant de migrer les charges de travail de backend. Vous pouvez ajuster la configuration de la conservation des messages dans l'environnement cible après l'étape de migration suivante.

Si vos appareils de périphérie ne peuvent pas se connecter à la fois à l'environnement source et cible en raison de contraintes techniques ou réglementaires, vous devez d'abord les configurer pour qu'ils se déconnectent de l'environnement source. Vous pouvez ensuite les connecter uniquement à l'environnement cible. Dans ce cas, les charges de travail de backend qui sont toujours connectées à l'environnement source cessent de recevoir des événements de télémétrie et des informations sur l'état des appareils des appareils de périphérie. Les appareils ne peuvent plus envoyer de commandes ni de mises à jour de configuration aux appareils en périphérie.

Nous vous recommandons également de provisionner et de configurer un mécanisme de stockage de mémoire tampon. Cette approche vous évite de perdre des données lorsque votre appareil envoie des événements de télémétrie et des informations sur l'état des appareils à l'environnement cible lorsque vos charges de travail de backend sont toujours connectées à l'environnement source. Les charges de travail de backend peuvent ensuite utiliser ces informations lorsqu'elles se connectent à l'environnement cible. Par exemple, vous pouvez configurer la conservation des messages de l'environnement cible, en fonction d'un agent MQTT, de Pub/Sub ou d'une plate-forme IoT. Cette approche vous permet de conserver les messages non confirmés pendant le temps nécessaire pour effectuer la phase suivante de la migration, comme décrit dans la section ci-après.

Migrer des charges de travail de backend de l'environnement source vers l'environnement cible

Vous migrez vos charges de travail de backend vers l'environnement cible. Selon l'architecture de votre environnement cible, vous devez adopter différentes approches pour migrer la charge de travail.

Agent MQTT sur Google Cloud : si votre environnement cible est basé sur un agent MQTT, les facteurs suivants guident votre approche de migration :

  • Pour les charges de travail de backend qui reçoivent des événements de télémétrie ou des informations sur l'état des appareils des appareils de périphérie, mais qui n'envoient pas de commandes ni de mises à jour de configuration des appareils : configurez vos charges de travail de backend pour s'abonner aux sujets MQTT afin de recevoir des événements de télémétrie et des informations sur l'état des appareils provenant des appareils de périphérie.
  • Inversement, pour les charges de travail de backend qui ne reçoivent pas d'événements de télémétrie ou d'informations sur l'état des appareils, mais qui envoient des commandes ou des mises à jour de configuration d'appareils : configurez vos charges de travail de backend pour publier des messages afin d'envoyer des commandes et des mises à jour de configuration aux sujets MQTT pour les mises à jour de commande et de configuration dans l'environnement cible.
  • Pour les charges de travail de backend qui reçoivent à la fois des événements de télémétrie ou des informations sur l'état des appareils des appareils de périphérie, et envoient des commandes ou des mises à jour de configuration des appareils : configurez vos charges de travail de backend pour qu'elles s'abonnent aux sujets MQTT afin de recevoir les données de télémétrie, puis configurez vos charges de travail de backend pour publier des messages afin d'envoyer des commandes et des mises à jour de configuration aux sujets MQTT.

Pub/Sub : si votre environnement cible est basé sur Pub/Sub, les facteurs suivants guident votre approche de migration :

  • Pour les charges de travail de backend qui reçoivent des événements de télémétrie ou des informations sur l'état des appareils des appareils de périphérie, mais n'envoient pas de commandes ou de mises à jour de configuration des appareils : créez des abonnements Pub/Sub dans l'environnement cible, et mettez à jour vos charges de travail de backend pour qu'elles utilisent les abonnements nouvellement créés.
  • Inversement, pour les charges de travail de backend qui ne reçoivent pas d'événements de télémétrie ou d'informations sur l'état des appareils, mais envoient des commandes ou des mises à jour de configuration d'appareils : créez des sujets Pub/Sub et configurez vos charges de travail de backend pour publier des messages afin d'envoyer des commandes et des mises à jour de configuration aux sujets Pub/Sub.
  • Pour les charges de travail de backend qui reçoivent à la fois des événements de télémétrie ou des informations sur l'état des appareils des appareils de périphérie, et envoient des commandes ou des mises à jour de configuration des appareils : configurez vos charges de travail de backend pour qu'elles s'abonnent à Pub/Sub afin de recevoir des événements de télémétrie et des informations sur l'état des appareils. Configurez ensuite vos charges de travail de backend pour publier des messages afin d'envoyer des commandes et des mises à jour de configuration aux sujets Pub/Sub.

Plate-forme IoT tierce : si votre environnement cible est basé sur une plate-forme IoT tierce, vous devez suivre les instructions de la plate-forme IoT tierce pour configurer des intégrations entre les charges de travail de backend et la plate-forme IoT Vous vérifiez ensuite que les charges de travail de backend peuvent recevoir des événements de télémétrie et des informations sur l'état des appareils provenant des appareils de périphérie. Vous vérifiez également que les charges de travail de backend peuvent publier des messages pour envoyer des commandes ou des mises à jour de configuration d'appareils aux appareils de périphérie.

Pour vérifier que les appareils de périphérie et les charges de travail de backend fonctionnent comme prévu, nous vous recommandons d'effectuer les opérations suivantes :

  • Vérifiez que les charges de travail de backend reçoivent des événements de télémétrie et des informations sur l'état des appareils et réagissent correctement. Par exemple, si vos charges de travail de backend génèrent un tableau de bord en quasi temps réel pour surveiller des données de télémétrie spécifiques, vérifiez que le tableau de bord est mis à jour avec la dernière période de données.
  • Vérifiez que les charges de travail de backend envoient des commandes et des mises à jour de configuration aux appareils de périphérie comme prévu. Vérifiez que les appareils de périphérie réagissent également comme prévu.
  • Vérifiez que les appareils de périphérie signalent les événements de télémétrie et les informations sur l'état des appareils à l'environnement cible.

À ce stade, les charges de travail de backend effectuent les opérations suivantes :

  • Se connectent à l'environnement cible.
  • Reçoivent des événements de télémétrie et des informations sur l'état des appareils des appareils de périphérie en provenance de l'environnement cible.
  • Envoient des commandes et des mises à jour de configuration aux appareils de périphérie à partir de l'environnement cible

Vous pouvez maintenant mettre à jour la configuration de la conservation des messages de l'environnement cible que vous avez définie sur une valeur minimale lorsque vous avez connecté des appareils de périphérie à l'environnement source et cible et définissez-la en fonction de vos besoins.

Lorsque vous mettez à jour la configuration des charges de travail de backend pour recevoir des événements de télémétrie et des informations sur l'état des appareils à partir de l'environnement cible, les charges de travail de backend peuvent avoir besoin de temps pour appliquer cette configuration mise à jour. Pendant la phase transitoire, les charges de travail de backend ne peuvent pas consommer d'événements de télémétrie et d'informations sur l'état des appareils envoyés par les appareils de périphérie. Si vos cas d'utilisation nécessitent une intégrité complète des données, vous devrez peut-être configurer la durée de conservation des messages de l'environnement cible avant de mettre à jour la configuration des charges de travail de backend. Cette approche garantit que les messages n'expirent pas avant que les charges de travail de backend ne puissent appliquer la nouvelle configuration et les consulter.

Mettre à jour des appareils de périphérie pour se connecter uniquement à l'environnement cible

À ce stade, vous avez correctement migré vos appareils de périphérie vers l'environnement cible, mais ils utilisent toujours l'environnement source. Pour terminer l'étape de migration, mettez à jour vos appareils de périphérie pour qu'ils se connectent à l'environnement cible uniquement en supprimant les connexions et l'intégration à IoT Core. Une fois cette mise à jour effectuée, vos appareils de périphérie ne se connectent qu'à l'environnement cible.

Mettre hors service l'environnement source

Après avoir migré les appareils de périphérie et les charges de travail de backend vers l'environnement cible, et après avoir validé l'environnement cible, vous mettez hors service l'environnement source.

Pour mettre hors service l'environnement source, procédez comme suit :

  1. Supprimez les abonnements Pub/Sub aux sujets IoT Core.
  2. Supprimez les sujets Pub/Sub inutilisés. Si vous réutilisez des sujets Pub/Sub, veillez à ne pas supprimer les sujets créés par IoT Core. Vous pouvez trouver les sujets Pub/Sub utilisés par IoT Core à l'aide de la console IoT Core.
  3. Supprimez les appareils et les registres IoT Core.

Optimiser votre environnement après la migration

L'optimisation est la dernière phase de votre migration. Dans cette phase, vous améliorez l'efficacité de votre environnement. Vous exécutez ici plusieurs itérations d'une boucle reproductible jusqu'à ce que votre environnement réponde à vos exigences d'optimisation. Les étapes de cette boucle reproductible sont les suivantes :

  1. Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation.
  2. Définir vos exigences et vos objectifs d'optimisation
  3. Optimiser votre environnement et vos équipes
  4. Ajuster la boucle d'optimisation

Les sections suivantes s'appuient sur la documentation Migration vers Google Cloud : optimiser votre environnement.

Évaluer votre environnement cible, vos équipes et votre boucle d'optimisation

Tandis que la première évaluation porte sur l'environnement source, cette phase d'évaluation concerne la phase d'optimisation. Pour en savoir plus sur l'évaluation de votre environnement cible, de vos équipes et de votre boucle d'optimisation, consultez la page Mesurer votre environnement, vos équipes et votre boucle d'optimisation.

Définir vos exigences d'optimisation

Passez en revue les exigences d'optimisation suivantes que vous devrez peut-être respecter pour votre environnement cible :

  • Configurer le scaling automatique : utilisez les services Google Cloud tels que le groupe d'instances géré ou Google Kubernetes Engine pour effectuer un autoscaling horizontal ou vertical de votre solution IoT et de vos charges de travail de backend lorsque les charges augmentent. Cette approche permet de garantir que le stockage des données d'enregistrement et de télémétrie des appareils peut gérer un volume de données plus important lorsque vous déployez un parc d'appareils volumineux. Spanner étant une base de données transactionnelle distribuée, à disponibilité élevée et évolutive, il est recommandé de l'utiliser pour stocker vos données de télémétrie et les informations d'enregistrement d'appareils.
  • Améliorer le mécanisme de journalisation et de surveillance : optimisez et intégrez votre mécanisme de journalisation et de surveillance pour former une solution centralisée. Vous pouvez également améliorer certaines métriques de surveillance pour mieux comprendre comment les appareils de périphérie interagissent avec votre solution IoT. Vous devez également consigner et mettre en corrélation des activités telles que les événements de connexion, de déconnexion et de télémétrie. Nous vous recommandons également de surveiller les erreurs du système et des applications. Si possible, configurez une alerte lorsque certaines défaillances critiques se produisent au niveau du système.
  • Protéger vos charges de travail à l'aide des services de sécurité Google Cloud : Security Command Center est un service centralisé de signalement des failles et des menaces qui vous aide à renforcer votre stratégie de sécurité en évaluant votre niveau de sécurité et votre surface d'attaque des données. Il fournit un inventaire et la découverte des éléments, et peut vous aider à identifier les erreurs de configuration, les failles et les menaces. Security Command Center vous aide également à limiter et à corriger les risques. Pour savoir comment sécuriser vos charges de travail exécutées sur Google Kubernetes Engine (GKE), consultez la présentation de la sécurité dans Google Kubernetes Engine.

Terminer l'optimisation

Après avoir renseigné la liste de vos exigences d'optimisation, terminez la phase d'optimisation. Pour savoir comment procéder, consultez la page Migration vers Google Cloud : optimiser votre environnement.

Étapes suivantes