Quel type de configuration AWS est nécessaire pour exécuter une application de carte Web à bande passante faible à moyenne?

Quelqu'un a-t-il de l'expérience avec l'exécution de cartes Web (serveur de tuiles + scriptage JS client) sur Amazon Web Services (S3, EC2 etc ...)? Quel type de configuration AWS est nécessaire pour exécuter une application de carte Web à bande passante faible à moyenne, couvrant une petite zone (-ish) (taille de la ville au petit pays)?

Toutes les tuiles seraient pré-rendues et téléchargées sur S3. Idéalement, j'aurais besoin d'une application de service de tuiles sur le serveur Web qui pourrait servir des MBTiles (au lieu de télécharger des centaines de milliers de bitmaps de tuiles individuellement). Donc, une sorte d'instance EC2 serait nécessaire, mais quelle sorte?

Merci pour tout indice.

MISE À JOUR: juste pour développer ma question. Ce que je recherche en gros, ce sont des commentaires sur la viabilité d'AWS pour l'hébergement de vos propres cartes Web en tant qu'individu (ce qui signifie que cela ne devrait pas coûter trop cher, disons jusqu'à 30 $ / mois). J'héberge mes cartes Web depuis un certain temps par le biais de fournisseurs d'hébergement «ordinaires», mais ceux-ci ont leurs propres limites (la bande passante de téléchargement en est une, la vitesse en est une autre). Je suis également à la recherche de bonnes alternatives à AWS et de tout ce qu'il faut surveiller lors de l'utilisation des services cloud pour les cartes Web.

Lorsque vous choisissez une architecture pour un service qui repose tant sur une architecture «classique» comme les cartes Web, ne sous-estimez jamais l'efficacité des solutions d'hébergement plus traditionnelles comme les serveurs Cloud RackSpace ou Linode .

Vous aurez beaucoup moins de choix à faire (comme utiliser S3 ou non, des équilibreurs de charge ou non, des sauvegardes, etc. ou non et combien cela va coûter?) Dont le résultat est difficile à prévoir ET, plus important encore, vous pourrez utilisez des outils que vous connaissez déjà.

Ayant vécu la même chose il y a quelque temps, je peux vous dire que les facteurs critiques dans ma décision d'héberger un service de cartes Web sur Rackspace plutôt que sur AWS étaient:

1. Les serveurs Cloud sont (plus) résistants que les instances EC2. Les instances EC2 sont effectivement attendus à l' échec et ils vont échouer
2. Les volumes EBS échouent également (il y a beaucoup d'histoires tristes dans les nouvelles) et ont généralement de mauvaises E / S
3. à moins que vous ne choisissiez les instances plus importantes, la contention des E / S pourrait être un problème (surtout si vous prévoyez d'ensemencer les tuiles sur EC2, plutôt que de les copier). Cela pourrait également être un problème avec les bases de données MTBtiles
4. Chaque fois que vous redémarrez votre serveur, l'IP publique change: cela ne se produit pas sur Linode ou Rackspace
5. Vous devrez vous-même proposer une stratégie de sauvegarde et de restauration, tandis que Linode et Rackspace fournissent des instantanés et des restaurations automatiques quotidiens et hebdomadaires.
6. Si l'hôte exécutant votre VPS échoue, Rackspace se chargera de déplacer votre instance et de la redémarrer sur un autre serveur et ils le feront en 4h (c'est dans leur SLA). Cela m'est arrivé pendant mes vacances: c'était très professionnel. Linode devrait faire de même
7. Linode a une grande disponibilité SLA: 99,9% et ils revendiquent de grandes performances parce qu'ils ne surprovisionnent pas
8. Rackspace a récemment mis au point une stratégie de volume comme EBS, donc l'espace disque ne devrait plus être un problème. Auparavant, si vous aviez besoin de beaucoup d'espace disque, vous deviez obtenir une grande instance tandis que sur EC2, vous pouvez provisionner le stockage, le processeur et la mémoire avec un contrôle plus fin.

Avec cela, je ne dis pas qu'Amazon AWS est inférieur aux autres, je dis simplement que parfois les solutions d'hébergement traditionnelles peuvent évoluer aussi bien que celles basées sur le cloud. Un exemple notable est le réseau StackExchange lui-même.

Donc, dans votre cas, je démarrerais une grande instance sur Rackspace puis chargerais toutes les données dans une instance Postgis locale. Ensuite, après avoir configuré le moteur de rendu, j'amorcerais le cache. Une grande instance achèvera le processus d'amorçage assez rapidement afin qu'il ne devienne pas trop coûteux à exécuter. Vous pouvez stocker des tuiles dans les fs, MTBtiles, même sur S3 (btw, vous pouvez servir des données S3 sur un CDN avec CloudFront ).

Une fois l'amorçage terminé, je redémarrerais le serveur et le redimensionnerais en une petite instance (peut-être même 512 Mo) car à ce moment-là, il ne devrait servir que des données statiques.

Cela obtient une réponse un peu longue, donc je vais m'arrêter ici. Si vous voulez que j'élabore sur certains aspects, laissez simplement un commentaire.

Avis de non-responsabilité: je ne suis pas affilié à Rackspace, Linode ou à tout autre fournisseur que j'ai cité.

J'ai utilisé WebFaction pour héberger des données SIG dans une base de données Postgresql / PostGIS avec MapServer et je pense que le service est inégalé pour le coût <$10mensuel. Si vous souhaitez utiliser PostGIS 2.0, vous devez l'installer vous-même, ce qui est un peu délicat, mais ils fournissent PostGIS 1.5 par défaut (vous devez ouvrir un ticket de support). Il s'agit d'un service d'hébergement partagé sur CentOS où vous avez toute la souplesse nécessaire pour installer quoi que ce soit dans votre propre partie du serveur.

Je n'ai pas utilisé Webfaction pour servir des tuiles, mais elles fournissent 100 Go d'espace; Je ne sais pas si la RAM serait trop coûteuse car la valeur par défaut est de 256 Mo (et chaque 256 blocs coûte 7 $ de plus par mois)

Une autre possibilité qui utilise AWS:

Vous pouvez envisager d'utiliser la méthode AWS Lambda Tiler conçue par Seth Fitzsimmons. Il l'utilise pour le projet Open Aerial Map et je l'ai utilisé pour un projet client privé tout en travaillant chez Stamen Design.

Il y a un article de blog approfondi que j'ai écrit qui explique comment configurer AWS Lambda Tiler sur Medium.com . Notez que le blog ne couvre que les données raster en mosaïque, mais nous avons également utilisé ce processus chez Stamen pour piloter nos tuiles de carte Terrain Classic mondiales qui sont générées à partir d'une combinaison de données OSM et Natural Earth via PostgreSQL, PostGIS, Mapnik et CartoCSS.

L'un des avantages de cette approche est que vous n'avez pas de serveur de tuiles à entretenir et que vous ne payez que par utilisation de chaque appel de fonction AWS Lambda, ce qui, je suis assez certain, est bon marché pour les petits projets qui ne le font pas. recevoir une énorme quantité de trafic Web. L'un des inconvénients de cette approche est que les tuiles sont placées par l'utilisateur en panoramique et en zoomant sur la carte, de sorte que le premier rendu peut être lent, bien que vous puissiez pré-semer les tuiles à l'avance. Les tuiles sont écrites et stockées dans S3 après leur premier rendu, de sorte que le chargement ultérieur des tuiles est beaucoup plus rapide.

Pour obtenir une tarification détaillée des services AWS, vous pouvez utiliser la calculatrice en ligne située ici: http://calculator.s3.amazonaws.com/calc5.html

Pour une petite instance EC2 exécutant Linux, si vous êtes prêt à vous engager sur un an, vous pouvez acheter une instance réservée qui coûtera environ 25 $ / mois. C'est en comparaison à environ 44 / mois pour les prix à la demande ou les prix sans contrat.

Je pense que la réponse courte à votre question est que si vous recherchez un fournisseur d'infrastructure pour répondre à vos besoins personnels en matière d'application de cartographie Web, AWS pourrait être exagéré. Si vous recherchez un fournisseur informatique pour les applications de production, en particulier si elles nécessitent une haute disponibilité et une évolutivité, AWS est votre réponse. Cela devient encore plus vrai si vous créez des applications qui exploitent les nombreux services de collage fournis par AWS, tels que SQS, SNS, SWF, etc.

Quant au type d'EC2 dont vous avez besoin? C'est une fonction spécifique à vos applications. L'intérêt de l'informatique en nuage est que vous pouvez essayer avant d'acheter. Testez votre application sans engagement, et uniquement lorsque vous le savez, prenez une décision éclairée sur la validation d'un type EC2 sur une période de temps (l'achat RI).

Je ne suis pas un expert avec beaucoup ou vraiment aucune connaissance à ce sujet, à part que j'exécute un serveur Web sur amazon EC2 depuis un certain temps maintenant, donc ce n'est pas une réponse.

Je ne suis pas sûr que vous utilisiez ces outils à leur meilleur usage en pré-rendu et téléchargement.

• La plus grande partie de mes dépenses aws concerne mon transfert de données (ce dont vous parlez de chargement).
• Que doit faire d'autre votre serveur (sauf si vous utilisez des licences pour restituer des tuiles et que vous n'avez pas de licence pour AWS).

Si cela ne décourage pas ou ne repense pas, choisissez probablement d'abord votre serveur de carte préféré, puis choisissez un système d'exploitation pris en charge pour ce serveur de carte, puis accédez à AWS EC2 et trouvez l'instance qui répond le mieux à vos besoins (taille, mémoire, espace, région).
Il peut y avoir ou non une AMI contenant toute la pile dont vous avez besoin, alors configurez-la ensuite, puis installez votre pile.
Il y a une forte possibilité que vous accomplissiez tout cela gratuitement ou à bon marché.

Cela est vrai, vous pouvez opter pour AWS si vous utilisez leurs différents services car AWS est assez coûteux. Si vous voulez opter pour des prix moins chers avec les mêmes avantages que je recommanderais pour https://fxdata.cloud ou https://digitalocean.com car tous deux ont des services appréciables et des prix moins chers. Vous obtiendrez essentiellement toutes les options du système d'exploitation et du SGBD avec une grande fiabilité.