Pourquoi votre architecture logicielle SIG n'est-elle pas native du cloud? Vous avez déplacé votre serveur SIG vers le cloud, votre architecture SIG est-elle native du cloud?
Réponse: Si vous déplacez simplement votre serveur SIG vers AWS ou Azure, votre SDI n'est pas cloud natif. C'est ce qu'on appelle le réhébergement ou Infrastructure as a Service (IaaS). Vous pouvez tirer certains avantages d'une base de données gérée dans le cloud comme AWS RDS, et votre instance de serveur SIG unique peut être mise à l'échelle selon vos besoins. Cependant, vous ne disposez pas d'une infrastructure véritablement élastique et évolutive qu'une architecture cloud native peut fournir.
Et qu'est-ce que cela signifie?
- Extension de la montée en charge
Pour atteindre une véritable évolutivité, vous devez mettre à l'échelle plusieurs serveurs derrière l'équilibreur de charge. Voir la solution Esri ci-dessous.
Déploiement multi-machine du cluster de serveurs SIG
Malheureusement, cette solution est statique (pas seulement parce que vous devez acheter une licence de base auprès d'Esri à l'avance). Il n'y a pas de mécanisme automatique pour ajouter des instances au cluster. Entrez le groupe de mise à l'échelle automatique AWS. AWS fournit un équilibrage de charge dynamique et le groupe d'autoscaling ajoute et supprime automatiquement des instances EC2 au cluster selon les besoins.
Pour que tout cela fonctionne, le serveur doit être sans état. Dans l'exemple Esri, vous avez peut-être remarqué que le «répertoire du serveur et le magasin de configuration» se trouvent dans un répertoire réseau partagé. Cela sert à deux fins. Vous devez stocker les tuiles mises en cache et les métadonnées de configuration sur les services et les couches. Voyons comment améliorer cela.
- Métadonnées de service et caches de tuiles
Commençons par stocker les métadonnées des services et des couches dans la base de données. L'un des avantages de cette méthode est que nous n'avons pas besoin de créer un plan de sauvegarde séparé pour la configuration du serveur et la base de données, et nous pouvons facilement interroger la configuration si nécessaire. Ne vous inquiétez pas, nous pouvons stocker plusieurs connexions dans les métadonnées afin que notre base de données opérationnelle puisse être sélectivement séparée de la base de données de métadonnées.
Mettez ensuite en cache toutes les métadonnées dans Elasticache Redis pour un accès mémoire ultra rapide. Maintenant, nous avons fait de notre mieux dans les métadonnées de service et de couche: vitesse et durabilité.
Vérifions ensuite notre cache de tuiles. Il peut s'agir d'une tranche raster ou d'un MVT. Mettons toutes les tranches dans un compartiment S3, puis mettons Cloudfront CDN dessus. N'oubliez pas de supprimer toutes ces tuiles raster vierges pour optimiser le stockage. Pouvez-vous sentir que votre carte est devenue plus fluide et plus sensible?
- Big Data
Si votre base de données ne peut pas évoluer avec vous lors de l'inévitable analyse des données géographiques IoT / drone / vision par ordinateur, quel est l'avantage de pouvoir répondre à des millions de requêtes Web par seconde? Le même concept de mise à l'échelle horizontale s'applique également, afin que vous puissiez effectuer un traitement de requête parallèle à grande échelle. Vous pouvez utiliser Hadoop, mais ceux qui savent écrire des fonctions de réduction de carte en géospatial sont très coûteux et même un peu snob. JK Corporation.
S'il existe un référentiel Big Data avec des capacités de requête spatiale, il dispose d'une interface de requête traditionnelle afin que vous puissiez le connecter à vos outils d'analyse et de reporting (tels que Tableau), ce serait formidable. bonnes nouvelles! Il existe deux types de bases de données Big Data: MemSQL avec interface MySQL et les données Citus avec interface PostGIS.
- GeoEvents (affaires géographiques)
Laissez-nous vous présenter les capacités de traitement de geoevent. La cartographie en temps réel peut être réalisée via des websockets, des webhooks et / ou Pubnub. Pour le géorepérage, vous devez envisager Azure Stream Analytics qui inclut des fonctionnalités géospatiales clés.
- Composable (composable)
Les modèles AWS CloudFormation vous permettent de combiner et d'ajuster la pile d'infrastructure selon les besoins via un modèle déclaratif. Considérez-le comme un installateur cloud flexible qui peut automatiser vos processus de développement et d'infrastructure. Si vous n'êtes pas familier avec ce concept, veuillez lire le code d'infrastructure.
- Accessible (disponible)
Le magasin d'applications cloud est ouvert! Cela s'appelle le marché AWS. En tant qu'acheteur d'applications d'entreprise, si vous ne traitez qu'avec le marché AWS, cela ne simplifiera-t-il pas votre essai, votre fourniture environnementale et vos achats? Si vous pouvez créer une pile d'infrastructure de données spatiales complexe à partir du marché en moins d'une heure en quelques clics, cela sera-t-il plus facile pour vous? Je ne dis pas qu'il n'y a qu'une seule instance AMI disponible.
- Azure / Docker / Kubernetes
Toutes ces choses natives du cloud peuvent être effectuées dans Azure et diverses plates-formes d'orchestration Docker (qui peuvent être dans Azure, AWS ou sur site). Par souci de simplicité, j'ai choisi d'utiliser des exemples de groupes AWS et de mise à l'échelle automatique pour illustrer une forme populaire d'infrastructure cloud native. Utilisez les exemples suivants de techniques similaires pour comparer les options avec awsazure et Docker. (Hors Google Cloud Platform)
- Compatibilité
- Publicité Shameless Plug
Si vous voulez voir comment tout cela fonctionne dans la vraie vie pour l'une des plus grandes marques au monde, contactez-nous - [email protected]. Consultez également quelques vidéos de produits pour voir comment nous simplifions la publication de services de données de localisation compatibles Esri et OGC. Nous acceptons actuellement un nombre limité de clients pilotes pour lesquels nous tirons parti de l'automatisation pour migrer gratuitement vos données et services / configuration de couche d'ArcGIS Server vers le cloud tout en maintenant la compatibilité avec vos applications et outils Esri existants.
https://www.linkedin.com/pulse/cloud-native-gis-architecture-mike-mcdougall/
Ce qui précède est un article sur LinkedIn sur le SIG cloud natif. En fait, je pense que l'article suivant est préférable
https://blog.csdn.net/supermapsupport/article/details/85988021