Guide du développeur pour la mise à l'échelle d'une application Ruby on Rails

Pour les créateurs de l'application, le fait d'avoir autant d'utilisateurs est à la fois un succès et un défi. La première chose à faire est de gérer l'intérêt croissant pour votre produit ou service. À l'inverse, une préparation technique insuffisante peut conduire à l'effondrement de l'application. Il est heureusement possible de résoudre ce problème. Vous apprendrez comment faire évoluer votre application Ruby on Rails avec notre aide.

Quelle est l'évolutivité du cadre ?

La mise à l'échelle d'un framework consiste à augmenter la capacité de l'application à générer davantage de requêtes par minute (RPM). Il est moins important de s'occuper du cadre lui-même que de l'infrastructure de l'ensemble du système de serveurs. Voyez comment cela fonctionne dans la pratique.

Prenons l'exemple d'un gratte-ciel doté d'un seul ascenseur pouvant accueillir quelques personnes. Il y a tellement de monde dans l'ascenseur qu'il ne peut pas fonctionner correctement en raison de l'intérêt élevé pour le paysage. Avant que le bâtiment ne soit achevé, il est essentiel de s'assurer que l'infrastructure appropriée est en place ou de développer une méthode pour transporter plus de personnes au sommet. L'ascenseur décrit ici équivaut à une application sans la mise à l'échelle appropriée. Il en résulte des pertes qui peuvent être extrêmement douloureuses.

Que se passera-t-il si vous ne faites pas évoluer votre application ?

Lorsque les applications ne s'adaptent pas à l'augmentation du trafic, elles peuvent devenir lentes et même tomber en panne. Ce n'est que le début des problèmes possibles. Les clients risquent de partir si la solution tarde à venir, et leur mécontentement se reflétera dans les commentaires en ligne. La mise à l'échelle doit être améliorée rapidement, et non minimisée.

Quels sont les obstacles auxquels vous pourriez être confronté lors de l'extension de votre application ?

S'il est facile de s'initier à la mise à l'échelle, il est difficile de la mettre en œuvre. L'architecture de l'application peut être l'un des obstacles. Il peut y avoir des problèmes avec le traitement des demandes, par exemple, si les solutions qui se trouvent dans une réalité de grand intérêt n'ont pas été mises en œuvre. Un code propre et modulaire est recommandé pour Applications de la RdR.

 Cette approche favorise l'intégration avec un plus grand nombre de systèmes de gestion de bases de données. En outre, il n'est pas difficile de placer des équilibreurs de charge pour traiter davantage de demandes.

Ruby on Rails est-il évolutif ?

Par conséquent, les applications Ruby peuvent être facilement mises à l'échelle. Il y a deux raisons à cela : les capacités de mise à l'échelle horizontale du langage et sa nature "thread-safe". En fait, il suffit de lancer plus de processus Ruby et de connecter plus de serveurs à votre application pour gérer plus de trafic. 

Conseils pour faire évoluer votre application Ruby on Rails

Si certaines d'entre elles sont spécifiques à Ruby on Rails, d'autres peuvent être appliquées à n'importe quel serveur d'application sans partage.

• La première règle consiste à mettre en cache, mettre en cache, mettre en cache et encore mettre en cache.

Les données peuvent être mises en cache sur le client et transmises au navigateur à l'aide de bibliothèques Ajax telles que JQuery. Apprenez à utiliser l'expiration et les balises, et à mettre en cache les réponses HTTP à l'aide des caches de passerelle / proxy inverse. Tirez parti de la mise en cache intégrée de Rails pour les actions, les pages et les fragments. Les résultats de votre base de données peuvent être mis en cache en utilisant Memcache au lieu de les extraire.

• Séparer les données de celles qui les servent

Ne mettez pas toutes vos données dans une seule base de données "par commodité". Des bases de données distinctes doivent être utilisées pour les ensembles de données indépendants. Mettez les ressources statiques à disposition par le biais d'un niveau distinct ou utilisez Amazon S3 ou Akamai pour les diffuser. Le coût est plus élevé, mais la mise à l'échelle est plus facile. Discutez avec votre DBA pour savoir si un modèle de données relationnel est nécessaire pour tous vos magasins de données, car les bases de données relationnelles s'adaptent à la hausse et non à la baisse. Si vos données sont plus simples, vous pouvez peut-être utiliser un magasin de données clé-valeur. Pour stocker et analyser de grandes quantités de données non structurées, utilisez Hadoop car il existe des clients Ruby. Si vous utilisez un système de fichiers, vous devez également être conscient de ses limites en termes d'évolutivité. Utilisez une copie de votre base de données principale au lieu de votre base de données de production si vous avez des besoins importants en matière de reporting de données.

• Minimiser et gérer les dépendances externes

Assurez-vous que le site ne dépend pas de services externes tels que les réseaux publicitaires ou les flux RSS. Veillez à disposer d'un plan de secours au cas où un service ne répondrait pas ou ne pourrait pas gérer le volume croissant de demandes.

• Maintenez vos gestionnaires de tâches et votre base de données à jour

Les requêtes SQL générées par n'importe quel ORM, y compris ActiveRecord de Rails, peuvent causer des problèmes de performance de la base de données. Si vous avez réalisé une intégration majeure, assurez-vous de vérifier votre journal des requêtes lentes pour vous assurer qu'il n'y a pas d'index de base de données "manquants" et que votre code Rails ne contient pas de find-all inappropriés. Vous devriez vérifier périodiquement votre base de données pour voir si des index ne sont plus nécessaires. Surveillez également l'utilisation des ressources de vos tâches planifiées et de vos tâches d'arrière-plan.

 Il n'est pas rare que les tâches se chevauchent au fur et à mesure que votre base d'utilisateurs augmente, et le traitement quotidien des journaux peut commencer à prendre plus de 24 heures ! Il est facile d'être pris au dépourvu par ce genre de choses. Veillez à ce que vos tâches soient séparées en plusieurs niveaux. À terme, vous souhaiterez peut-être passer à un gestionnaire de tâches basé sur les messages au fur et à mesure que votre entreprise se développera.

• Vos données relationnelles inévitables doivent être partagées (sharded)

Les bases de données MySQL doivent être partagées à des niveaux d'échelle élevés. Le processus de partage consiste à diviser votre ensemble de données en morceaux indépendants sur la base d'une clé. Le sharding basé sur l'ID de l'utilisateur peut être utilisé pour la plupart des sites Rails orientés vers le consommateur, mais il existe également des schémas de sharding basés sur l'âge des données ou la fréquence d'accès.

Conclusion

Selon le type de projet, les applications basées sur Ruby on Rails doivent être dimensionnées différemment. Comme beaucoup d'autres technologies, RoR n'est pas la réponse à tous les problèmes. Il est donc important de comparer le profil de votre entreprise avec les capacités de Rails avant de développer une application. Nous recommandons de travailler avec Société de développement Ruby on Rails Railscarma si vous avez besoin d'un expert Soutien aux RdR. Chaque étape de la développement d'applications sera prise en charge par notre équipe de professionnels expérimentés.