search

addok / addok

Search engine for address. Only address.
http://addok.readthedocs.org/
MIT License
326 stars 61 forks source link

Docker et addok #603

Closed Barbaro closed 1 year ago

Barbaro commented 4 years ago

Bonjour à tous,

J'ai tenté de déployer addok sous Docker en créant une image from scratch (je n'ai donc pas utilisé le projet github qui existe). Cela fonctionne parfaitement, et j'arrive à répartir la charge sur 4 conteneurs parfaitement.

Par contre, pour une raison obscure, dès que je dépasse 4 conteneurs, j'ai de manière à priori aléatoire des adresses en retour fausses. Disons que j'ai généralement un résultat cohérent, mais que de temps en temps j'ai un résultat incohérent qui sort de nulle part. Tous mes conteneurs pointent vers le même redis.

J'ai eu beau tenter de comprendre d'où pouvait venir le soucis, je sèche. Cela ne viendrait à priori pas d'un soucis de cache ou autre, le contexte 5+ conteneurs semble être seul déclencheur du soucis.

Avez-vous déjà eu un soucis lors d'une répartition de charge, sous docker ou non.

Merci pour vos réponses, Barbaro

jdesboeufs commented 4 years ago

Je ne peux malheureusement pas vous aider pour votre cas de figure. Pour notre architecture de production nous déployons systématiquement un conteneur addok pour un conteneur addok-redis.

cquest commented 4 years ago

Quel est l'intérêt d'avoir plusieurs conteneur avec la partie python d'addok qui requêtent le même redis ? C'est redis qui est le facteur limitant car mono-thread, alors qu'addok (python) est multi-thread. On peut remplacer redis par keydb pour est une version multithread de redis.

cryptobioz commented 4 years ago

On peut trouver un intérêt à avoir plusieurs instances d'Addok, notamment dans le cas d'un service haute disponibilité.

@Barbaro j'ai eu quelques soucis pour mettre en place une infra similaire à la votre. Lorsque que je faisais des tests de charge, j'obtenais régulièrement des erreurs 500 étranges. Ces dernières venaient en fait des clés temporaires stockées dans Redis. J'ai écrit un patch (#607) pour résoudre ce problème.

@cquest auriez-vous un peu de temps pour faire une review de la PR #607 ?

Barbaro commented 4 years ago

@cryptobioz Tu as une solution de contournement en attendant ? Même si je ne suis pas convaincu que ca corresponde à mon soucis de résultat incohérent par moments, en dépassant un nombre précis de conteneurs :)

cryptobioz commented 4 years ago

@Barbaro une solution de contournement ? J'ai rebuildé l'image Docker en installant Addok depuis ma branche git : 

...
RUN pip install git+https://github.com/cryptobioz/addok@fix-pid-redis-key
...

Pas sûr que ça règle ton problème mais tu peux toujours essayer ...

Comment est-ce que tu as détecté ces résultats incohérents ? Tu as des tests automatisés ou c'est juste à l'utilisation ?

cquest commented 4 years ago

Pour de la haute dispo, il est préférable d'avoir chaque instance d'addok avec son redis. Avec le recul, la partie python d'addok n'a de mémoire jamais planté sur adresse.data.gouv.fr, par contre redis a disparu 2 fois (en 4 ans). Pour les performances, 1 redis peut être saturé à partir de 8 threads addok python, d'où aussi l'intérêt de ne pas avoir plusieurs addok branchés sur le même redis.

cryptobioz commented 4 years ago

Pour de la haute dispo, il est préférable d'avoir chaque instance d'addok avec son redis.

Merci pour le conseil ! Dans les faits, cette architecture est assez peu flexible. Je comprends cependant que ce soit la meilleure stratégie pour atteindre les meilleures performances.

Avec le recul, la partie python d'addok n'a de mémoire jamais planté sur adresse.data.gouv.fr, par contre redis a disparu 2 fois (en 4 ans).

Dans un contexte de HA, je m'inquiète moins de la résilience d'Addok que celle des instances sous-jacentes. Dans le cas de la perte d'un nœud, je ne veux pas d’indisponibilité de service.

Pour les performances, 1 redis peut être saturé à partir de 8 threads addok python

C'est bon à savoir.

cquest commented 4 years ago

Sur adresse.data.gouv.fr j'avais mis en place:

Ceci permet de recharger les instances addok avec les données sans interruption de service et au cas où l'une des instances soit indisponible, l'autre traite les requêtes.

Pas de docker utilisé sur cette config.

jdesboeufs commented 4 years ago

Aujourd'hui la configuration a évolué à la marge, et fait environ 15 millions de requêtes par jour, en haute disponibilité.

Je peux vous dire que vos inquiétudes ne sont pas justifiées.

Nous avons actuellement 2 serveurs, avec sur chaque serveur 3 instances (1 addok avec gunicorn, 8 workers, 1 redis dédié). On est loin de la pleine capacité.

jdesboeufs commented 4 years ago

Je précise qu'on utilise https://github.com/etalab/addok-docker