[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