Dans le monde des communications unifiées, la performance et la fiabilité sont essentielles. 8x8, l’un des leaders mondiaux des services de voix et de visioconférence cloud, a dû faire face à une explosion de la demande durant la pandémie de COVID-19. Les serveurs saturaient, la latence augmentait et les coûts du cloud devenaient intenables.
La solution ? Une migration vers des machines Arm64 basées sur les processeurs Ampere Altra, hébergées sur Oracle Cloud Infrastructure (OCI). Résultat : jusqu’à 30 % de performance en plus et 30 % d’économies.
Dans cet article, nous vous présentons cette étude de cas, les étapes de la migration et les leçons clés pour toutes les entreprises opérant des services cloud intensifs.
Les défis initiaux de 8x8
Une demande multipliée par 100 en quelques semaines
En tant que fournisseur de services de vidéoconférence chiffrée, 8x8 a vu en 2020 sa demande multipliée par des facteurs exponentiels avec le passage massif au télétravail.
Lorsque la pandémie COVID-19 a déclenché un basculement massif vers le télétravail et les outils de visioconférence, la charge sur les services de 8x8 est passée d’une vingtaine de serveurs à plusieurs milliers en quelques semaines.
Cette croissance exponentielle a mis à nu des goulots d’étranglement CPU dans le pipeline de traitement du trafic vidéo encrypté, notamment dans le routage, le cryptage/décryptage des paquets, la répartition de charge, les files d’attente réseau, etc.
Les problèmes rencontrés
-
Les machines devenaient saturées rapidement, incapables de suivre le flux de paquets entrant et sortant.
-
Les files réseau explosaient, causant des délais (latences) visibles pour les utilisateurs, des pertes de paquets, des interruptions audio/vidéo.
-
Les systèmes de log (notamment via syslog), les load balancers (HAProxy) et les scripts d’automatisation subissaient eux-mêmes des surcharges — créant des blocages en cascade.
-
Le coût du cloud est monté en flèche : les factures s’envolaient car chaque chargement supplémentaire d’instance multipliait les coûts.
Face à ce défi, l’équipe technique de 8x8 devait repenser l’architecture sous-jacente pour gagner en efficacité, tout en maîtrisant les coûts.
Anatomie d’une surcharge
Le rôle d’un routeur vidéo est complexe : lire les paquets réseau, les décrypter, les ré-encrypter, puis les dispatcher vers les sockets de sortie.
Ces opérations exigent des cycles CPU élevés et de faibles temps de latence pour éviter que les files d’attente ne gonflent.
En période de montée en charge, les files d’attente réseau s’allongeaient, ce qui introduisait de la latence visible — les paquets restaient bloqués dans les queues trop longues.
Les composants auxiliaires (HAProxy, système de log) devenaient également des points de congestion, rendant l’ensemble de la chaîne fragile.
Financièrement, l’augmentation rapide des instances provoquait une explosion des coûts mensuels, menaçant la viabilité du modèle.
Ce diagnostic a poussé l’équipe à envisager une alternative radicale à l’architecture x86 classique : une migration vers Arm64 / Ampere. Sans solution, la qualité d’expérience utilisateur aurait chuté, et les coûts auraient continué à grimper.
La migration vers Ampere et Arm64
Pourquoi Ampere ?
8x8 a choisi de migrer une partie de son infrastructure vers Oracle Cloud Infrastructure (OCI), parce qu’OCI proposait des instances Arm64 (basées sur Ampere Altra) à coût moindre.
Ces machines Arm64 se sont révélées jusqu’à 30 % moins chères par instance que les VM x86/Intel qu’ils utilisaient auparavant, tout en offrant jusqu’à 30 % de performance en plus pour certaines charges
Compatibilité logicielle
Le cœur de l’architecture logicielle de 8x8 repose sur Jitsi, projet open source pour la visioconférence, principalement écrit en Java, avec des liaisons JNI (interfaces natif).
La migration vers Arm64 aurait pu être complexe, car les composants natifs (bibliothèques de cryptographie, modules C/C++) devaient être recompilés ou adaptés.
Mais une opportunité a facilité cela : la plupart des modules utilisés disposaient déjà de versions compatibles Arm64, ce qui a limité l’effort requis. Les développeurs ont pu migrer l’essentiel du code Jitsi en une seule journée.
Par ailleurs, les scripts d’automatisation pour lancer des instances virtuelles ont été ajustés pour la nouvelle architecture, ce qui a pris quelques jours supplémentaires.
Objectifs techniques
Pour 8x8, une métrique clé était la latence réseau pour le traitement des paquets dans des conditions extrêmes. Ils visaient :
Ces percentiles sont essentiels : P95 capture la latence typique, tandis que P99 inclut les transactions les plus lentes, vitales pour l'expérience utilisateur en vidéoconférence.
Après migration, ces objectifs ont été atteints ou dépassés.
Résultats obtenus
Gains de performance et efficacité
-
Après migration, chaque instance Ampere était capable de réaliser 20 à 30 % de travail en plus comparé à auparavant, pour le même coût / taille.
-
L’objectif P95 ≤ 1 ms a été atteint, et le P99 est resté proche de 5 ms.
-
Le gain de performance fluide a permis de servir davantage d’utilisateurs avec moins d’instances.
Réduction des coûts
-
Les instances Arm64 offertes par OCI étaient jusqu’à 30 % moins coûteuses que les instances x86 équivalentes.
-
En combinant réduction de coût par instance et meilleure efficacité, le retour sur investissement sur cette migration a été immédiat et excellent.
Déploiement et mise en production
La migration de l’environnement de tests à la production s’est déroulée avec peu d’incidents.
L’effort total, y compris adaptation des scripts d'automatisation, révision des pipelines d’outillage, et monitoring, a pris environ deux semaines.
Le passage en production a confirmé les bénéfices escomptés sans régression notable.
Un pari gagnant et peu risqué
Malgré les appréhensions initiales (compatibilité, bugs inconnus, effort de migration), 8x8 a réalisé ce qu'il a décrit comme étant une “victoire facile” avec cette migration.
Les points soulignés étant :
-
Une architecture Arm64 / Ampere bien supportée, avec des bibliothèques existantes et une adoption croissante.
-
Un coût de migration en termes d’effort relativement faible comparé aux gains obtenus.
-
Depuis, 8x8 recommande systématiquement les instances Ampere comme première option lors de nouveaux déploiements.
-
Une adoption immédiate dans la stratégie de déploiement : désormais, les instances Ampere sont privilégiées en premier choix.
Quelques enseignements pour les entreprises
Ne négligez pas l’architecture matérielle
La migration d’architecture (x86 → Arm64) peut déboucher sur des gains notables de performance, latence et coût, si l’écosystème logiciel est compatible.
Le choix de processeurs (x86 vs Arm64) peut avoir autant d’impact que l’optimisation logicielle.
Vérifiez la compatibilité des bibliothèques natives
Avant de migrer, assurez-vous que toutes les dépendances critiques existent en version Arm64.
Adoptez une migration progressive
-
Adapter le code applicatif (Java, JNI)
-
Ajuster les scripts d’automatisation / provisioning
-
Tester intensivement en staging
-
Surveiller les percentiles de latence (P95, P99)
-
Migrer progressivement en production
Surveillez les bons indicateurs
Se focaliser sur les percentiles (P95, P99) de latence, pas seulement les moyennes.
Au-delà du CPU, gardez un œil sur la latence des paquets, les files réseau, et surtout le coût par utilisateur servi.
Calculez le retour sur investissement global
Même un petit effort de migration peut générer des économies substantielles et améliorer l’expérience utilisateur.
Conclusion
L’expérience de 8x8 démontre qu’il est possible de :
grâce à une migration ciblée vers des architectures cloud plus modernes comme Ampere Arm64.
Pour les entreprises qui gèrent des services en temps réel, cette étude de cas est une invitation à explorer de nouvelles options matérielles et cloud.
Votre entreprise envisage une migration vers Arm64 ? C’est peut-être le moment d’évaluer le potentiel de gains en performance et en coûts.
