dé bron voor nieuws en achtergronden over online communicatie en informatiemanagement
28 april 2010 om 14:33
· Geplaatst in Artikel
Ondanks een forse uitbreiding van de capaciteit van de website van de KLM klapte klm.nl er op maandagmiddag 19 april toch uit. Een softwarefout die op zijn beurt weer veroorzaakt werd door de “afwijkende situatie” was de oorzaak. “Murphy op zijn best…”
Nog geen uur nadat Automatisering Gids op zijn website publiceerde dat KLM de capaciteit van zijn website had uitgebreid om de grote verwachte belangstelling het hoofd te kunnen bieden, ging de site down. Maar het was niet een gebrek aan capaciteit dat de site de das omdeed, maar een “applicatieve fout”, legt Mike Rodenburg, manager Architectuur Web Systems bij de KLM, uit. En die fout kon alleen optreden in de uitzonderlijke situatie waarin het luchtvaartwezen afgelopen weekeinde verkeerde.
Het probleem betrof de .nl-site van de KLM, niet de wereldwijde .com-versie. Allereerst is daarom de eerste pagina statisch gemaakt. Wereldwijd werd die gecached, zodat gebruikers in elk geval reponse kregen als ze de site opstartten. “De rest hebben we dynamisch gemaakt.” KLM had de site snel weer op gang, maar wel met langere responstijden dan normaal – tot 40 seconden.
Lees het AG-artikel van Tanja de Vreede
Interessant om te lezen hoe een organisatie omgaat met een situatie waarin uitzonderingen regel zijn. De KLM-website is natuurlijk een bedrijfskritieke omgeving. Men had getest op een situatie waarin er twee dagen lang vluchtvertragingen waren, maar op maandag had men al 4 volle dagen van vertragingen achter de rug. Omdat de vluchtinformatie weer uit een andere – met diverse andere luchtvaartmaatschappijen gedeelde – bron komt, kon het systeem de vele verzoeken niet meer verwerken.
Zie ook:
- Leeuwarden zoekt testers voor Drupal-site
- CBP: Privacy in kafkaëske situatie beland
- Open standaarden onder druk in EU
Permalink
Artikel in AG gelezen. Als ik tussen de regels door lees, dan zie ik dat de uptime van de site van KLM afhankelijk is van de drukte op externe systemen.
Naar de precieze oorzaak is het gissen zonder inside information. Maar je kunt in elk geval zeggen dat het systeem niet bestand is tegen te lange wachtrijen in de koppelingen met andere systemen. Aangezien wij heel vaak real-time koppelingen gemaakt hebben met potentiëel trage systemen die makkelijk overbelast kunnen raken, kan ik er uit onze ervaring een paar dingen zeggen over de oorzaken en kwetsbaarheden in de achterliggende architectuur.
Veelal heeft het te maken met het feit dat webapplicaties zelf geen echte controle over de timing en belastingsverdeling van hun koppelingen hebben, omdat ze onder een webserver draaien en de webserver de taken verdeelt met weinig inspraak.
1) Een webpagina moet data bij trage systemen ophalen voordat hij geserveerd kan worden. Als het te druk wordt, wordt dat externe systeem alsmaar langzamer en, loopt ook je eigen webserver vol met wachtende connecties. Bij grote drukte is het een kwestie van tijd voordat het omvalt. Oftewel: synchrone koppelingen. Alles hangt met alles samen, en als 1 schakel faalt, loopt alles uit de rails.
2) Er is gegokt dat wachtrijen nooit heel lang zullen worden. Dat zie je heel vaak: tot een bepaalde veronderstelde testbelasting gaat het goed, maar worden de rijen te lang dan treedt alsnog ergens in het hele systeem effect 1) op.
3) Vaak bestaat een vraag op een externe systeem uit meerdere stapjes na elkaar. Meestal zijn de meeste stapjes heel snel en maar 1 of 2 die heel traag zijn. De “snelle” stapjes zijn dan niet voorzien van architectuur om met wachtrijen om te gaan, terwijl het nodig is omdat ze worden opgehouden door andere, langzame stapjes. Dit kan effecten 1) en 2) exponentiëel verergeren.
4) Bij overbelasting verlaten veel mensen de pagina, terwijl die hele santenkraam van 1, 2 en 3 wel gewoon uitgevoerd wordt, voor niks. Dat stroopt op. Ook worden mensen ongeduldig en gaan alsmaar dezelfde pagina opnieuw opvragen waardoor er nog meer onnodige transacties veroorzaakt worden. Dit effect kan exponentieel verergeren bij overbelasting.
Omdat het gaat om 4 effecten waarbij alles met elkaar verband houdt en alles elkaar ophoudt, heeft bijplaatsen van hardware vaak weinig of geen nut. Je kunt je webserver capaciteit verdubbelen, maar als het externe systeem dan alleen maar harder op z’n donder krijgt en 10x zo traag wordt, ben je dus alleen maar verder van huis en je bezoeker ook.
Bovendien, als alle vliegtuigen aan de grond staan kun je wel boos opbellen met de baas van zo’n extern systeem, maar die heeft al 40 klanten die in z’n oor hebben lopen gillen en doet echt wat hij kan. En hij zal de capaciteit pas echt effectief en veilig kunnen uitbreiden als de piekdrukte voorbij is. Anders had ie het al vantevoren gedaan.
Een architectuur die anders omgaat met wachtrijen onder overbelasting is het enige alternatief.
Architectuur
Als je onder heel hoge belasting moet koppelen met heel trage systemen, dan is een andere architectuur nodig. Elke losse poging om gegevens bij externe systemen op te halen moet dan een losse taak worden in een wachtrij. Uiteindelijk moet de browser dan niets meer doen dan de status van de taak opvragen en even wachten. De wachttijd moet berekend worden met de drukte op de server, zodat de webserver niet alsnog inzakt vanwege een alsmaar groeiende zwerm van status-vraagjes.
De hoeveelheid gelijktijdige opvraag-taken die je bij het externe systeem doet, kun je dan zelf een plafond stellen. Bijvoorbeeld, als het systeem boven de 5 gelijktijdige vragen langzamer wordt, zet de limiet op 5. Dan wordt het zo snel afgehandeld dat het externe systeem het zo vlot mogelijk wegkrijgt.
Zo kun je taken van mensen die het te lang vonden duren en de pagina verlaten of herladen, direct uit de wachtrij halen. Zodat je de effecten onnodige bevragingen, effect 4), ook kunt bestrijden en je schaarse capaciteit zo goed mogelijk aanwendt.
Met de gedachte: als het externe systeem de drukte niet aankan, dan moet je zelf rekening houden met de beperkingen van het externe systeem. Door het zo te ontwerpen, dat het niet uitmaakt hoe langzaam het externe systeem is.
We hebben een dergelijke koppelingsarchitctuur inmiddels een aantal keren geïmplementeerd, en toegegeven, het is 6x zo veel werk en 6x zo ingewikkeld als traditioneel synchroon koppelen. Maar het is niet kapot te krijgen.
Ik nodig de deskundigen van KLM uit voor een weerwoord!!!
HTML-Tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
