Lorsque nous avons lancé Glassix, les nouvelles fonctionnalités étaient la priorité absolue, avant tout. Nos premiers clients n’ont pas perdu beaucoup de sommeil à propos du SLA de disponibilité ; Ils voulaient leur toute nouvelle interface utilisateur et la prochaine intégration de canal !

Lorsque nous avons signé nos premiers gros contrats, leurs priorités étaient différentes. S’ils se souciaient toujours de la fonctionnalité, ils se souciaient également de la résilience. Un centre de support client avec 40 agents par équipe ne pouvait pas se permettre de se déconnecter parce que nous avions un serveur paresseux.

Puis, il y a environ un an et demi (à peu près au même moment où ma fille est née), notre plateforme a commencé à répondre lentement à diverses demandes. Et par lentement, j’entends environ 20 secondes en moyenne. En tant qu’agent, il était presque impossible de travailler de cette façon. Ce problème (que nous avons découvert plus tard lié à une sauvegarde cachée dans notre fournisseur de cloud) s’est produit pendant environ 20 longues minutes chaque semaine jusqu’à ce que nous trouvions le problème.

Ce fut un signal d’alarme pour Glassix. L’entreprise, consciente de l’équilibre critique entre l’innovation et la fiabilité, a commencé à réorienter ses ressources vers le renforcement de son infrastructure.

Nous avons réalisé que nous devions agir rapidement sur certains de nos projets, et nous avons donc fait appel à des solutions d' externalisation et à des travailleurs indépendants, ce qui nous a permis d'atteindre nos objectifs dans les délais impartis.

Maintenant, en plus de la liste de contrôle habituelle, telle que la mise en cache, la mise à l’échelle horizontale et le CDN, nous avons également effectué les opérations suivantes :

Mode hors ligne

Même avec un signal réseau médiocre, vous pouvez toujours ouvrir et afficher des messages sur votre application WhatsApp . Vous pouvez même envoyer des messages, et une fois que vous êtes en ligne, ils seront envoyés automatiquement. Magie!

Même chose avec Glassix. Essayez-le maintenant : Connectez-vous et accédez à votre espace de travail Glassix. Vous pouvez afficher les messages et les images (qui étaient auparavant mis en cache), envoyer des messages, afficher les réponses prédéfinies, fermer des tickets et attribuer des conversations. Toutes ces actions sont mises en file d’attente et seront synchronisées une fois que vous serez à nouveau en ligne. C’est l’une de nos caractéristiques de résilience dont je suis le plus fier. Nous avons utilisé Workbox, qui simplifie le processus de création d’applications Web conviviales hors ligne, ce qui facilite la création d’expériences utilisateur fiables, même lorsque le réseau n’est pas fiable.

Notre mode hors ligne peut atténuer les problèmes de réseau que nos clients peuvent rencontrer.

Paires de services parallèles 

Nous utilisons tellement de bases de données et de services que j’en ai perdu le compte : MongoDB, SQL Server, Elastic search, Redis, Ably, des applications statiques, des fonctions serverless, et bien d’autres.

Les services couverts par un SLA avec une disponibilité de quatre neuf - soit 99,99 % - pourraient être indisponibles 52 minutes et 36 secondes par an. La disponibilité de 99,9 % permet 8 heures et 46 minutes de temps d’arrêt par an.

Supposons que chacun de ces services de base soit en panne pendant 2 heures au total une fois par an. Cela signifie que nous serons en panne pendant au moins 24 heures par an, ce que nous ne pouvons pas vivre ! 

Donc, bien sûr, chaque service cloud est livré avec une sauvegarde, mais d’après notre amère expérience, il en faut plus.

Notre solution coûteuse fonctionne bien : chaque service central dispose d’un service de redondance.

un. Le service de tables Azure s’exécute avec AWSdynamoDB.

b. SignalR avec Ably.

c. Les applications statiques sont répliquées sur 5 régions et mises en cache dans l’équilibreur de charge.

d. Fastly CDN avec Azure CDN.

e. Redis avec Elasticache.

f. Plusieurs domaines en cas de panne DNS : *.glassix.com et *.glassix.io

Et la liste s’allonge encore et encore.

Ingénierie du chaos

L’ingénierie du chaos est une approche disciplinée permettant d’identifier les défaillances avant qu’elles ne se transforment en pannes. En testant de manière proactive la façon dont un système réagit en cas de stress, vous pouvez identifier et corriger les défaillances avant qu’elles ne fassent la une des journaux. En gros, ça veut dire qu’il faut commencer à casser des trucs !

De cette façon, nous avons soigneusement identifié tous les points d’étranglement de notre plateforme et les avons résolus (avec d’autres services/une logique différente).

Aimez-vous votre service Redis ? Fermez-le (ou mieux encore, bloquez toutes les adresses IP ; de cette façon, vous atteignez toujours le délai d’expiration maximum configuré pour chaque requête). Nous avons découvert que vous ne pouvez pas vous connecter à notre application si Redis est en panne à cause de notre jeton CSRF.

Votre CDN ? Ratez ses enregistrements DNS et voyez ce qui se passe.

Nous avons découvert que sans le CDN, notre application se bloque. Nous avons donc implémenté une logique de nouvelle tentative partout : d’abord, nous chargeons à partir du CDN principal (Fastly) ; en cas d’échec, nous passons au serveur secondaire (Azure CDN), et en cas d’échec, nous accédons à l’hôte actuel.

Sacrifiez quelques-uns pour sauver le plus grand nombre

Ce concept en génie logiciel fait référence à la prise de compromis ou de décisions qui peuvent impliquer de sacrifier les performances ou les ressources de quelques composants ou processus pour améliorer la fiabilité et la stabilité globales d’un système logiciel. Ce concept est souvent appliqué à des situations où les ressources sont limitées ou où l’optimisation de chaque composant n’est pas faisable ou pratique.

Dans notre cas, nous avons défini des délais d’expiration courts pour les requêtes HTTP et SQL non critiques. Cela signifie qu’ils seront les premiers à tomber en panne une fois que SQL ou un autre service ne fonctionne pas bien, mais nous avons allégé la charge sur ces services en supprimant rapidement ces requêtes non critiques.

Disjoncteur

Il est essentiel d’échouer rapidement. Prenons un exemple : de nombreux utilisateurs accèdent à un service qui est en panne, comme dans une application bancaire où le service de compte échoue et submerge d’autres services tels que l’authentification. Cela peut épuiser les ressources, provoquant des défaillances généralisées du système. Les disjoncteurs des micro-services empêchent de telles défaillances en cascade en arrêtant rapidement les opérations pour protéger le système. Nous avons également mis en place un disjoncteur sur certaines de nos API HTTP non critiques. Une fois qu’un serveur détecte qu’il est proche de l’épuisement, il rejette automatiquement les requêtes non critiques. 

Ne mettez pas tous vos œufs dans le même panier

Les microservices peuvent améliorer la résilience globale de l’application. Si un micro-service échoue, cela n’entraîne pas nécessairement l’arrêt de l’ensemble de l’application. Ce confinement des défauts est un avantage significatif par rapport aux architectures monolithiques, où une seule défaillance peut avoir un impact sur l’ensemble du système.

Quelle est la prochaine étape ?

Ces vastes changements ne se sont pas produits du jour au lendemain. Nous avons dû les faire lentement, car ils affectent le cœur de notre plateforme. Nous continuerons à trouver un équilibre entre la recherche de fonctionnalités innovantes et la nécessité d’une plate-forme robuste et fiable. Cela signifie que nous continuerons à introduire des fonctionnalités de pointe tout en veillant à ce que la plate-forme de base reste solide et fiable.