Architecture informatique pour l'achat de billets du Festival d'été de Québec

Aujourd'hui, l'achat de billets pour le Festival d'été de Québec était pénible pour les clients (Radio-Canada.ca, journaldequebec.com).

À partir du site http://infofestival.com/ il est possible d'aller sur le site des achats de billets. Le site est https://achat.infofestival.com/

Le site infofestival.com est en Ontario (Brampton) alors que achat.infofestival.com est dans les nuages, chez Amazon Web Services, Inc., dans la ville de Ashburn aux États-Unis.

L'entrée A dans le fichier de zone DNS pour infofestival:

infofestival.com.    31    IN    A    50.100.3.86

Voici les entrées DNS de type CNAME dans le fichier de zone pour achat.infofestival.com:


achat.infofestival.com. 300     IN      CNAME   sale-gtickets-1409583281.us-east-1.elb.amazonaws.com.
sale-gtickets-1409583281.us-east-1.elb.amazonaws.com. 60 IN A 23.23.167.37
sale-gtickets-1409583281.us-east-1.elb.amazonaws.com. 60 IN A 23.21.140.223
sale-gtickets-1409583281.us-east-1.elb.amazonaws.com. 60 IN A 107.22.217.101
sale-gtickets-1409583281.us-east-1.elb.amazonaws.com. 60 IN A 54.243.112.146


Donc, le système d'achat de billets implémente un balancement de charge sur 4 instances dans Amazon Elastic Compute Cloud. Le balancement de charge est fait avec Amazon Elastic Load Balancing.

Voici les 4 entrées A dans le fichier de zone DNS pour les 4 instances:

ec2-23-23-167-37.compute-1.amazonaws.com. 604800 IN A 23.23.167.37
ec2-23-21-140-223.compute-1.amazonaws.com. 604800 IN A 23.21.140.223
ec2-107-22-217-101.compute-1.amazonaws.com. 300    IN A 107.22.217.101

ec2-54-243-112-146.compute-1.amazonaws.com. 604800 IN A    54.243.112.146

L'hypothèse est que c'est infofestival.com qui a échoué sous les requêtes, et non achat.infofestival.com.

Une autre hypothèse est que les 4 instances parlaient au même engine de stockage d'information, et donc le balancement de charge était inutile.

Outils utilisés: dig, nslookup.

Ajout (2013-02-17):

@JeanSebTr et @j15e ont indiqué que les 4 instances EC2 -- ec2-23-23-167-37, ec2-23-21-140-223, ec2-107-22-217-101, ec2-54-243-112-146 -- ne sont pas les instances qui roulent l'application du #FEQ. Ces 4 instances EC2 s'occupent du balancement de charge sur d'autres instances EC2. Les problèmes techniques de hier étaient (probablement) sur les autres instances EC2 du #FEQ qui reçoivent les requêtes. J'ai beaucoup appris en discutant avec @JeanSebTr car il connait bien ELB.

Exemple d'architecture:

L'adresse MyLoadBalancer-2119387095.us-east-1.elb.amazonaws.com. est le balanceur.

Elle pointe vers une instance EC2 (ou plusieurs) qui roule le logiciel de balancement de charge d'Amazon Web Services, Inc.

Voici les entrées dans le fichier de zone DNS:

MyLoadBalancer-2119387095.us-east-1.elb.amazonaws.com. 53 IN A 107.20.157.169
 
ec2-107-20-157-169.compute-1.amazonaws.com. 300    IN A 107.20.157.169

Deux de mes instances EC2 sont enregistrées dans le balanceur et roule une application (Ray Cloud Browser).

ec2-23-23-55-35.compute-1.amazonaws.com. 603363    IN A 23.23.55.35
 

ec2-54-235-237-179.compute-1.amazonaws.com. 86400 IN A 54.235.237.179

Les visiteurs de http://myloadbalancer-2119387095.us-east-1.elb.amazonaws.com/client/ vont voir deux versions (car mes deux instances EC2 n'ont pas les mêmes données -- mon exemple ne fait pas de sens).

Comments

Popular posts from this blog

A survey of the burgeoning industry of cloud genomics

Generating neural machine instructions for multi-head attention

Adding ZVOL VIRTIO disks to a guest running on a host with the FreeBSD BHYVE hypervisor