Architecture serveur pour l'hébergement de l'application Java PLAY dans le cloud

Il s'agit plutôt d'un ensemble de questions que d'une question très spécifique. Au cours des deux dernières semaines / jours, j'ai intrigué ensemble des informations sur la façon d'héberger correctement une application JAVA PLAY "dans le cloud", car beaucoup de ces informations sont dispersées sur différents services, j'ai eu envie de rassembler tous ces petits morceaux en un seul, car beaucoup de choses sont importantes à voir dans un contexte complet. Cependant, j'ai déplacé mes considérations au bas de la question, car ce sont principalement mes opinions et des résultats subjectifs, dont je ne veux pas être tenu responsable. Si j'ai quelque chose de mal, n'hésitez pas à le signaler.

Hébergement Java PLAY + MySQL sur AWS pour une accessibilité mondiale

Notre scénario: nous avons une application assez simple écrite dans le framework Java PLAY ( https://www.playframework.com / ), fonctionnant sur iOS et Android ainsi qu'avec un système backend (pour l'administration, la gestion de contenu et l'API), stockant les données dans une base MySQL. Bien que la plupart des interactions des utilisateurs avec le serveur soient rapides et faciles (connexion, synchronisation de certaines données), il existe également des tâches plus gourmandes en données (télécharger des zips de données

Configuration de l'hébergement dans :

Mise à l'échelle horizontale: pour le début, seulement 1 instance EC2 avec notre application s'exécutera dans eu-1a. Nous devrons évaluer la quantité de ressources dont une instance a réellement besoin, si plus d'instances sont nécessaires et si plus d'instances profiteraient réellement à des temps de réponse plus rapides.

Mise à l'échelle horizontale entre les régions: une fois que l'application génère une charge utilisateur importante à partir d'une autre région, l'instance EC2 entière doit être dupliquée et une autre région, exécutant un réplica en lecture de base de données (voir Configuration d'une application Web disponible dans le monde entier sur amazon web services et https://aws.amazon.com/de/blogs/aws/cross-region-read-replicas-for-amazon-rds-for-mysql / ).

Mise à l'échelle verticale des instances EC2: lors de tests récents de l'ancienne configuration d'hébergement, la base de données s'est avérée être le goulot d'étranglement plutôt que l'application play et les spécifications matérielles de son serveur. Par conséquent il n'est pas encore tout à fait clair combien de mise à l'échelle verticale affecterait les temps de réponse. Si un t2.micro instance sert aussi bien qu'un m3.xlarge instance, bien sûr, nous préférerions grimper par le bas ici.

Mise à l'échelle verticale de RDS: nous devrons estimer la quantité de trafic sur le serveur de base de données et le processeur/RAM/etc. requis. Probablement que nous allons travailler notre chemin ici aussi.

Redirection globale: fait en utilisant Amazon Route 53 (?). Un utilisateur de Tokio doit être redirigé vers l'instance EC2 en cours d'exécution en Asie; un utilisateur de Rome à l'instance EC2 en Europe. Cela n'affecte pas seulement les appels d'API dans l'application, mais également la diffusion de contenu (dans les deux sens).

Questions ouvertes concernant la configuration

1. Cette configuration est-elle concluante? Est-ce que je manque des composants cruciaux?
2. Concernant la redirection globale: Amazon Route 53 est-il le bon outil? En quoi diffère-t-il de CloudFront (ce qui me semble être purement pour la distribution de contenu / médias?).
3. Comment définir les données/api correctes points de terminaison pour mon application? Bien sûr, je ne veux pas définir le point de terminaison de base de données d'un réplica de lecture de base de données lors du déploiement de l'application. Cela se produira-t-il également lors de la configuration AR53 (question 2)? Il en va de même pour les appels d'API, bien sûr, l'application devrait diriger ses appels vers https://myurl.com/api et à partir de là, il devrait être redirigé. Est-ce réaliste?

J'apprécierais beaucoup toutes sortes de pensées (!), également en ce qui concerne les informations de fond écrites ci-dessous. Si vous pouvez m'indiquer plus lire pour résoudre mes questions par moi - même, je suis également très reconnaissant-il y a tout simplement une énorme quantité d'informations à ce sujet, mais cela rend difficile d'affiner les réponses. J'ai des connaissances en hébergement / serveurs, mais je suis à peu près sûr qu'il y a de vrais experts qui attendent de me gifler avec des connaissances. :)

Renseignements généraux

Configuration actuelle de l'hébergement: un équilibreur de charge distribue le trafic sur 2 serveurs Linux racine, tous deux exécutant l'application PLAY, un d'entre eux tenant également l'installation MySQL.

La configuration actuelle de l'hébergement a 3 gros défauts:

1. Pas d'évolutivité verticale: la société d'hébergement prendrait de l'argent pour chaque étape de mise à l'échelle. Actuellement, les serveurs tournent au ralenti, mais si l'application explose, nous pourrions rapidement manquer de capacité. L'inactivité est toujours payée comme si elle était en permanence à pleine charge. C'est cher!!!
2. Pas de prise en charge du déploiement: actuellement, nous nous connectons via SSH, manuellement déployez les dossiers corrects dans le système de fichiers, recompilez sur le serveur, définissez des privilèges, appliquez des évolutions de base de données; faites de même pour le deuxième serveur (avec des paramètres de connexion db différents). Ce qui pourrait aller mal. ;)
3. Pas de disponibilité mondiale: installer un autre serveur dans une autre région du monde représenterait un énorme effort. Avoir une réplique synchronisée de notre base de données peut être fait, mais une fois de plus, le déploiement signifierait un temps d'arrêt, de la place pour les erreurs et donc du temps et de l'argent.

Options d'hébergement pour Java PLAY: Il y a beaucoup de différents articles de blog à ce sujet. En bref:

1. AWS: Amazon Web Services est l'un des premiers endroits où vous commencez à chercher. Ici, vous obtenez tout ce qui est possible, à un prix flexible. Vous vous configurez une instance EC2, un MySQL RDS et vous êtes prêt à partir-tout cela dans le niveau gratuit, afin que vous puissiez expérimenter, jouer, tester vos trucs.
2. Microsoft Azure: similaire à AWS en ce qui concerne la tarification et possibilité. Cependant, je n'ai pas plongé dans la configuration et le déploiement de notre application à des fins de test.
3. Heroku: déploiement super facile à partir de PLAY, serveurs évolutifs. Cependant (sur le premier coup d'œil?) manque de possibilité de fournir des régions éloignées avec un contenu à grande vitesse.
4. Jelastic: déploiement encore plus facile depuis PLAY / IntelliJ IDEA. Vous poussez l'image de votre application vers jelastic, jelastic la distribue ensuite à leurs fournisseurs d'infrastructure.
5. RedHat OpenShift (https://www.openshift.com / ): cela semble prometteur, mais pas aussi complet qu'AWS.

Beaucoup de choix et de configurations/prix possibles. Surtout après avoir découvert le déploiement à l'aide de boxfuse (https://boxfuse.com / ) J'ai fait mon choix pour AWS, car il offre absolument tout ce dont nous avons besoin à partir de 1 source. Boxfuse a de faibles coûts mensuels mais est parfaitement intégré à AWS. La mise à l'échelle est prise en charge ainsi que les 3 environnements communs (dev/test/prod). Le soutien est exceptionnel.