L'argument physique pour héberger au Canada le trafic canadien

L'affirmation

La plupart des arguments en faveur d'une infrastructure canadienne pour des charges canadiennes sont juridiques. Ces arguments sont réels mais négociables : des contrats, des avenants et des clauses types peuvent les déplacer. L'argument qui ne se négocie pas, c'est la vitesse de la lumière dans le verre, et pour une application bavarde il vaut plus de millisecondes que tout le réglage de serveur que vous ferez un jour.

Faites le calcul vous-même

Dans une fibre monomode, la lumière circule à environ deux tiers de sa vitesse dans le vide, soit à peu près 200 000 km par seconde, ou 5 microsecondes par kilomètre. Les tracés de fibre ne sont pas des lignes droites ; un facteur de 1,4 à 1,5 par rapport à la distance orthodromique est une hypothèse de planification raisonnable.

Toronto–Ashburn, en Virginie, fait environ 700 km. Avec le facteur de tracé, on obtient à peu près 1 000 km de verre. Aller-retour :

2 x 1000 km x 5 us/km = 10 000 us = 10 ms de plancher

Dix millisecondes, c'est le meilleur cas : avant les routeurs, avant la file d'attente au point d'appairage, avant TLS. Toronto–Toronto sur un trajet métropolitain reste sous 2 ms. Vous ne comblerez pas un écart de 8 ms en achetant des processeurs plus rapides.

Comment 8 ms deviennent 800 ms

Un chargement de page n'est pas un aller-retour. Prenez une page rendue au serveur tout à fait ordinaire, avec la base de données dans la même région que le serveur applicatif, mais toute la pile en Virginie et la cliente à Mississauga :

• Poignée de main TCP : 1 aller-retour
• Poignée de main TLS 1.3 : 1 aller-retour
• Requête et réponse HTML : 1 aller-retour
• Deux feuilles de style et polices sur une nouvelle connexion : 1 aller-retour
• Un appel XHR pour un en-tête personnalisé : 1 aller-retour

Cela fait cinq allers-retours. Au plancher de 10 ms entre Toronto et la Virginie, vous ajoutez 50 ms ; à 22 ms mesurés de façon réaliste, vous ajoutez 110 ms. Ajoutez maintenant une application qui enchaîne quelques appels d'API séquentiels depuis le navigateur — motif courant dans les tunnels de paiement — et le multiplicateur grandit sans que personne ne modifie une ligne de code.

La version qui fait vraiment mal, c'est la pile éclatée : serveurs applicatifs dans un pays, base de données dans un autre. Chaque requête de l'ORM devient un aller-retour transfrontalier. Une page qui émet 40 requêtes — ce qui n'a rien d'inhabituel pour un écran d'administration non optimisé — paie 40 x 22 ms = 880 ms d'attente pure.

Mesurez avant de débattre

Lancez ceci depuis un poste sur le réseau qu'utilisent réellement vos clients, pas depuis la fibre du bureau :

curl -o /dev/null -s -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://exemple.ca/

L'écart entre connect et time_namelookup vaut un aller-retour. L'écart entre ttfb et tls correspond au temps de réflexion réel de votre serveur. Si connect vaut 0,024 et que ttfb moins tls vaut 0,011, votre serveur est rapide et votre géographie est lente ; aucun profilage du code applicatif n'y changera quoi que ce soit.

Ce qu'un RDC règle, et ce qu'il ne règle pas

Un réseau de diffusion de contenu doté d'un point de présence à Toronto termine le TLS localement, ce qui retire deux des cinq allers-retours même si l'origine est lointaine. C'est réellement utile et peu coûteux. Ce que cela ne règle pas, c'est le trajet non mis en cache : tableau de bord authentifié, panier, requête de recherche, envoi de formulaire. Tout cela repart vers l'origine. Si l'essentiel de votre trafic est authentifié, le RDC améliore la partie de votre site qui était déjà rapide.

La question de la résidence, brièvement

La LPRPDE n'exige pas que les renseignements personnels demeurent au Canada. Elle exige un niveau de protection comparable par des moyens contractuels ou autres lorsque vous les transférez pour traitement, et de la transparence à ce sujet. Plusieurs lois provinciales du secteur public sont plus strictes ; si vous vendez à un conseil scolaire, à une régie de santé ou à une municipalité, attendez-vous à voir la résidence apparaître comme exigence ferme d'approvisionnement plutôt que comme préférence. Traitez la résidence juridique et la latence réseau comme deux décisions distinctes qui pointent, par coïncidence, dans la même direction.

Un choix par défaut raisonnable

1. Placez la base de données et les serveurs applicatifs dans la même zone de disponibilité. Interzone, c'est acceptable ; interrégion, c'est un signal d'alarme de conception.
2. Placez cette région sur le marché d'où provient la majorité de vos requêtes. Pour la plupart de nos clients, c'est Toronto ou Montréal.
3. Mettez un RDC en façade pour les ressources statiques et le HTML cacheable.
4. Conservez une copie de sauvegarde hors site dans une seconde région, idéalement chez un second fournisseur, et vérifiez que vos contrats autorisent cette région.

Si vos utilisateurs sont au Canada et que vos serveurs n'y sont pas, vous payez une taxe de latence sur chaque interaction, et vous la payez indéfiniment.