[OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

marc marc marc_marc_irc at hotmail.com
Sam 22 Juil 18:46:41 UTC 2017


Le 22. 07. 17 à 15:23, Florian LAINEZ a écrit :
> J'ai été un peu perdu techniquement parlant à certains moments mais 
> globalement j'ai compris.
N'hésites pas à demander ce qui a besoin d'explication supplémentaire

Je vais séparer fortement ce que le(s) dev(s) peux/devrait faire de ce 
qu'il est possible de faire côté serveur/infra

> 1. Le cas du dev dans son coin
Pour lui le plus simple c'est d'encoder dans son application les url des 
différentes instances overpass api existante
Il est les tries
- soit en fonction de leur géographie (demander au serveur français pour 
un projet concernant des objets en France, ..)
c'est la solution est la plus efficace si les données sont géographique.
- soit il les appelle séquentiellement (le 1er puis le 2ieme puis le 
3ieme). c'est la solution la plus sympa pour la collectivité vu qu'elle 
réparti la charge.
- soit il appelle toujours le premier et ne passe au 2ieme qu'en cas 
d'erreur. c'est la solution faite quand un serveur est mieux qu'un autre 
(l'allemand répond + vite que le russe)
Le dev devrait aussi se tenir au courant des changements de serveur.
Le serveur allemand qui n'a temporairement pas de maj, c'est à savoir.
Le serveur francais qui est en "pause", c'est aussi à savoir.
Quand un server ne répond plus, c'es facile à détecter. quand il ne se 
met plus à jour, c'est compliqué.
Le dev doit réfléchir à un moyen de mettre à jour cette info dans 
l'appli sans devoir produire une nouvelle version (une solution est de 
téléchargé un fichier de conf au démarrage ou d'utiliser le dns, voir + 
bas).
Au minimum je pense qu'il devrait suivre la page concernée du wiki pour 
recevoir une alerte en cas de modif.

> 2. Le cas Jungle Bus
Ce genre de projet doit faire des stats anonyme de ce qu'il consomme.
Tant que le volume est petit comme tu le décris, c'est acceptable de le 
faire sur un overpass public.
Mais à un moment, le volume de ce qu'on demande engendre une charge non 
négligeable et il devient préférable d'avoir un cache local.
La limite entre "sans cache" <> "avec cache" est très subjective.
Il faudrait collectivement discuter d'un ordre de grandeur à communiquer.
Le moyen de maj du cache est par contre ULTRA critique !
faire une requête overpass à intervalle régulier pour maintenir un cache 
local d'une taille conséquent (par exemple les 2 millions de 
plateforme+bus_stop+stop_area+relation de bus) provoque quasi toujours 
une surconsommation de ressource.
Dans ces cas, il faut passer par un overpass privé.
Donc en simplifiant/caricaturant :
- soit faible volume -> requête overpass uniquement lorsqu'un 
utilisateur a besoin d'une donnée
- soit maj d'une db à intervalle régulier -> utiliser les extraits ou 
les diff planet/régionaux

 > le temps de chargement de plusieurs secondes est trop long
Un cache local ou un overpass local est aussi souvent un bon moyen de 
gagner en performance :-) Et le prix d'un serveur cloud est faible.

> On peut imaginer de demander à l'utilisateur de zoomer 
> plus pour un niveau de zoom minimum 13 ou 14)
Si la taille de la bbox est 2 fois + petite, la requête serra évidement 
2x + légère. mais ce n'est pas la piste la plus spectaculaire.
Si on exagère,l'utilisateur va être blasé ou faire plusieurs bbox
Il faut être raisonnable sans excès, les vrais gains sont ailleurs.

côté serveur/infra
il serrait utile d'avoir (au niveau mondial ou français) un 
enregistrement dns qui liste le(s) ip des overpass api fonctionnel
genre overpassapi.osm.org qui retourne ip1 ip2 ip3
au niveau mondial cela impliquerait que les serveurs web concerné 
reconnaisse le vhost en question.
Je sais pas s'il y a une liste entre sysadmin d'overpass api ?
a défaut on pourrait imaginer proposer une page wiki ultra light 
contenant uniquement les vhost des serveurs actifs idéalement suivit 
d'un mot world ou du pays si limité à un pays.
On peux aussi imaginer d'avoir un reverse proxy ultra léger qui redirige 
vers un overpass api en fonction de leur état et/ou géographique (si 
cela est facile a extraire de la requête)
Il pourrait aussi être censé que les projet ayant un budget envisage une 
petite contribution si l'infra associative le nécessite.
c'est parfois aussi une chose à penser à mettre dans le budget des 
projets bénéficiant de subventions/dons :)
Je parle bien évidement uniquement en mon nom, à titre de suggestion.

Cordialement,
Marc


Plus d'informations sur la liste de diffusion Talk-fr