Tag Archives: webcaching proxy

ArcGIS Content, het nieuwe keukengereedschap

In mijn vorige blog schreef ik over een kijkje in onze keuken. Over hoe we in 5 jaar tijd zijn gegroeid van een Nederlandse topografische basiskaart naar een breed pallet aan content en alle technologische uitdagingen die daarbij komen kijken. Maar we zitten niet stil, het aanbod blijft groeien en het gebruik neemt steeds meer toe. Dat betekent dat ons platform ook moet meegroeien. Als beheerder van de omgeving voor ArcGIS Content deel ik graag met jullie waar we nu en in de nabije toekomst aan werken: zeg maar het nieuwe keukengereedschap.

Het ‘DevOps-principe’

DevOps is een inkorting van Developers Operators en het houdt de samenwerking in tussen deze twee groepen. Maar belangrijker is de samenwerking tussen verschillende disciplines. Omdat het content-team een relatief klein team is, zijn de taken al multidisciplinair verdeeld tussen de medewerkers. Nu is het beheer daar ook in opgenomen en werk ik nauw samen met de content engineers, zodat we elkaars werk goed begrijpen en elkaars keuzes kunnen begrijpen en afstemmen. Dit heeft mij heel veel geholpen bij het ontwikkelen van scripts en snellere releases van de infrastructuur en content. Dit principe sluit ook heel goed aan bij het agile werken, iets wat we al geruime tijd gewend zijn om te doen.

Veranderingen: webcaching proxy

De architectuur voor ArcGIS Content verandert drastisch. De meest voor ons in het oog springende wijziging is de introductie van een webcaching proxy. In eerste instantie gaan de basiskaarten op specifieke proxyservers geplaatst worden, zodat de achterliggende servers worden ontlast. We hebben namelijk het punt bereikt dat een dedicated cache voor de basiskaarten efficiënter is dan steeds meer servers in te zetten, waar de caches ook gepubliceerd staan. De backend blijft uiteraard nog steeds ArcGIS en de webcaching proxy is niet meer dan een kopie van de cache van de ArcGIS-server. De REST-interface, het opvragen van de offline basiskaart-packages en dynamische mapservices blijven nog steeds het domein van ArcGIS. Echter, doe je als gebruiker een verzoek naar een plaatje van een basiskaart, dan komt dit verzoek nooit bij onze ArcGIS-server terecht, maar wordt direct door de webcache afgehandeld. Voor gebruikers overigens een wijziging waar niets van te merken is, alles blijft werken zoals het werkt en net zo snel als eerst. Wellicht zelfs iets sneller.

Een webcache is overigens pas interessant bij heel veel hits. Wij verwerken per dag meer dan vijf miljoen hits op alleen de basiskaarten. Voor deze basiskaarten zetten we nu al meerdere ArcGIS-servers in. Het inrichten en onderhouden van een webcache vergt veel kennis, tijd en extra computerkracht. Bij minder belasting is een webcache simpelweg niet rendabel en is out-of-the-box ArcGIS beter te gebruiken, of gewoon ArcGIS Online.

Veranderingen: automatisch ‘uitrollen’

Een andere belangrijke verandering in de infrastructuur is het automatisch ‘uitrollen’. We gebruiken hier een zogeheten end-state configuration tool voor. Wij geven in een configuratiebestand aan wat de beoogde configuratie is en deze programmatuur zorgt ervoor dat alle servers afgestemd worden op deze beoogde situatie. Dit heeft voor ons twee belangrijke voordelen. We kunnen zeer eenvoudig een kopie van onze omgeving inrichten voor testdoeleinden en we kunnen extra servers toevoegen als de belasting toeneemt. We weten via een dergelijke end-state configuration in elk geval zeker dat alle servers identiek aan elkaar zijn. Of het nu een loadbalancer, een ArcGIS-server of een webcache is.

Dit zijn mooie ontwikkelingen die technologisch gezien erg interessant zijn. Wie mij een beetje kent, weet dat ik urenlang kan doorpraten over dit werk en hoeveel plezier ik eraan beleef. Gelukkig houdt mijn werk na het inrichten van deze veranderingen niet op: we zijn bezig om het opslaan en verwerken van big data in de infrastructuur te verbeteren.

LinkedInFacebookTwitterDeel deze blogpost
Posted in Achter de schermen, Content | Tags: , , , | Plaats een reactie